В книге представлен типовой шаблон документа «Проектное решение концепция ролей и полномочий» на примере внедрения программного продукта SAP.
Шаблон документа позволит Вам не только сократить ваши трудозатраты на создание аналогичного документа, который вы можете использовать в качестве образца, но и расширит кругозор в части ведения проектной документации по направлению контроллинг на предприятиях, внедряющих программный продукт SAP.
Проектное решение – это промежуточное или окончательное описание объекта проектирования, необходимое и достаточное для продолжения или окончания проектирования или вариант проекта, удовлетворяющий требованиям технического задания (ТЗ) (промежуточное или конечное описание объекта проектирования).
Шаблон титульного листа проектного решения
Сокращения, используемые в настоящем документе, приведены в Таблице 1
Термины, используемые в настоящем документе, приведены в Таблице 2.
Настоящий документ разработан в рамках проекта по созданию Корпоративной информационной системы автоматизации финансово-хозяйственной деятельности (далее – КИС ФХД).
Назначением настоящего документа является описание ролевой модели доступа к информационным ресурсам КИС ФХД.
Данный документ предназначен для специалистов, обеспечивающих реализацию проектных решений по КИС ФХД, а также техническое и организационное сопровождение КИС ФХД в процессе ее промышленной эксплуатации
Общий порядок доступа к КИС ФХД
Доступ пользователей к информационным ресурсам КИС ФХД предполагает выполнение процедур аутентификации и авторизации на следующих уровнях:
на уровне терминальных ферм, расположенных на ресурсах информационной вычислительной инфраструктуры Корпоративного ЦОД;
на уровне прикладного ПО КИС ФХД.
Аутентификация и авторизация пользователей КИС ФХД на уровне терминальных ферм Корпоративного ЦОД используются при доступе пользователей КИС ФХД к прикладному ПО КИС ФХД. Аутентификация и авторизация пользователей КИС ФХД на данном уровне выполняются на контроллерах доменов (лесов доменов), в состав которых входят терминальные фермы Корпоративного ЦОД, на основе групп безопасности Active Directory. Предоставляемые на данном уровне права доступа (полномочия) обеспечивают доступ пользователей КИС ФХД к прикладному ПО Системы.
Процедуры аутентификации и авторизации пользователей КИС ФХД на уровне прикладного ПО КИС ФХД выполняются с использованием встроенных средств ПО SAP. Предоставляемые на данном уровне полномочия обеспечивают доступ пользователей КИС ФХД непосредственно к информации, обрабатываемой и хранящейся в КИС ФХД, а также к средствам автоматизированной обработки этой информации. Проверка предоставленных полномочий осуществляется встроенными средствами прикладного ПО SAP автоматически при попытке доступа к информационным ресурсам КИС ФХД.
В состав КИС ФХД входит Подсистема аналитической отчетности, обеспечивающая возможность хранения и анализа обрабатываемых в КИС ФХД данных, а также формирования на основе этих данных различных отчетов. Управление доступом пользователей к Подсистеме аналитической отчетности выполняется в рамках отдельной ролевой модели, отличной от ролевой модели доступа пользователей к основным функциональным возможностям КИС ФХД.
Управление (определение, предоставление, изменение, аннулирование) полномочиями доступа пользователей КИС ФХД к информационным ресурсам Системы на уровне прикладного ПО SAP обеспечивается в рамках ролевых моделей доступа, описание которых приведено в настоящем документе.
Принципы формирования полномочий доступа
Полномочия на доступ к функциональности и информационным ресурсам Системы определяются ролевой моделью доступа. Ролевая модель обеспечивает разграничение доступа пользователей КИС ФХД к информационным ресурсам на уровне прикладного ПО КИС ФХД.
Полномочия пользователей КИС ФХД на доступ к информационным ресурсам определяются с учетом:
категорий пользователей Системы;
уровней доступа к информационным ресурсам Системы;
разделения функциональных обязанностей;
Категорирование пользователей КИС ФХД
Пользователи КИС ФХД в зависимости от целей использования информационных ресурсов Системы разделяются на две основные категории. В рамках каждой отдельной категории с учетом круга решаемых задач выделяются различные типы пользователей.
Пользователи КИС ФХД разделяются на следующие основные категории:
Бизнес-пользователи КИС ФХД используют информационные ресурсы КИС ФХД в решениях бизнес-задач в соответствии с назначением КИС ФХД. Бизнес-пользователи, в зависимости от реализуемых в КИС ФХД функций разделяются на отдельные типы. Основные типы бизнес-пользователей КИС ФХД и описание выполняемых ими функций приведено в Таблица 3.
Обслуживающий персонал КИС ФХД обеспечивает функционирование Систем с заданными параметрами качества и в соответствии с показателями назначения КИС ФХД. Обслуживающий персонал разделяется на отдельные типы, в зависимости от реализуемых по отношению к КИС ФХД функций.
Типы обслуживающего персонала КИС ФХД и описание выполняемых ими функций приведено в Таблице 3.
Основные типы бизнес-пользователей и обслуживающего персонала.
Подсистемы аналитической отчетности и описание выполняемых ими функций приведено в Таблице 4.
Уровни доступа к информационным ресурсам
Доступ пользователей КИС ФХД к информационным ресурсам Системы осуществляется на двух различных уровнях:
на уровне терминальных ферм, расположенных на ресурсах информационной вычислительной инфраструктуры Корпоративного ЦОД;
на уровне прикладного ПО Системы.
Настоящая Концепция определяет правила разграничения доступа пользователей КИС ФХД на уровне прикладного ПО Системы.
В соответствии с архитектурой КИС ФХД правила разграничения доступа на уровне прикладного ПО Системы реализуются встроенными средствами прикладного ПО SAP.
Встроенные средства прикладного ПО КИС ФХД позволяют ограничить доступ пользователей КИС ФХД к информационным ресурсам Системы на следующих уровнях:
В зависимости от функциональных обязанностей пользователю должны быть присвоены соответствующие системные роли для работы в Продукте. Присвоение ролей пользователю может быть осуществлено несколькими способами:
с помощью транзакции ведения пользователей SU01 ;
Присвоение роли в транзакции SU01¶
Для присвоения роли пользователю выполните следующие действия.
Присвоение роли в транзакции PFCG¶
Для присвоения пользователя роли выполните следующие действия.
Ролевая модель xDE для SAP ERP¶
В Продукте предусмотрено разделение полномочий пользователей по ролям, представленным в таблице ниже.
Таблица 76 Роли xDE для SAP ¶
Сотрудник, ответственный за добавление исходящих документов в очередь отправки. Инициатор не имеет персональной электронной подписи и не может выполнять подписание документов.
Сотрудник, ответственный за подписание электронной подписью отправляемых контрагентам или полученных от контрагентов документов.
Бухгалтер налогового направления
Сотрудник, ответственный за подготовку налоговой отчетности (формирование выгрузки юридически-значимых документов для ФНС).
Сотрудник, ответственный за мониторинг состояния системы и выполнение настроек.
Также в продукте имеется механизм настройки дополнительного ограничения доступа пользователей в следующих разрезах:
Ящик оператора ЭДО;
При этом базовая ролевая модель (Инициатор, Подписант, Бухгалтер налогового направления, Администратор) для разграничения доступности в разрезе функций Продукта сохранена.
Пользователю также должны быть присвоены прочие роли, существующие в системе Заказчика, необходимые для обеспечения функциональной деятельности, например, полномочия на доступ к документам по бизнес-единицам и т.п.
Полномочия роли Инициатор¶
Инициатор имеет в системе SAP права и полномочия на следующие операции, связанные с обменом электронными юридически значимыми документами:
просмотр очереди исходящих документов (транзакция /TRL/XDE_OUTBOX );
постановка исходящих документов в очередь отправки.
Роль /TRL/XDE_INITIATOR содержит полномочия, представленные в таблице ниже.
Таблица 77 Полномочия роли Инициатор ¶
O (исходящие документы)
Полномочия роли Подписант¶
Подписант имеет в системе SAP права и полномочия на следующие операции, связанные с обменом электронными юридически значимыми документами:
просмотр очереди входящих/исходящих документов (транзакции /TRL/XDE_INBOX и /TRL/XDE_OUTBOX );
постановка исходящих документов в очередь отправки;
подписание/отклонение входящих/исходящих документов при помощи персональной электронной подписи.
В случае использования локального подписания на рабочем месте пользователя с ролью Подписант должно быть установлено ПО для выполнения подписания персональной ЭП (см. раздел Настройка рабочего места для локального подписания ).
Роль /TRL/XDE_SIGN содержит полномочия, представленные в таблице ниже.
Таблица 78 Полномочия роли Подписант ¶
01, 02, 08, 09, 14, 15, 16
ACCEPT, REJECT, REQ_REVOKE
Полномочия роли Бухгалтер налогового направления¶
Бухгалтер налогового направления имеет в системе SAP права и полномочия на следующие операции, связанные с обменом электронными юридически значимыми документами:
просмотр очереди входящих/исходящих документов (транзакции /TRL/XDE_INBOX и /TRL/XDE_OUTBOX );
выгрузка юридически значимых документов, печатных форм и файлов XML формата (транзакции /TRL/XDE_INBOX и /TRL/XDE_OUTBOX ).
Роль /TRL/XDE_OFFICE содержит полномочия, представленные в таблице ниже.
Таблица 79 Полномочия роли Бухгалтер налогового направления ¶
просмотр очереди входящих/исходящих документов (транзакции /TRL/XDE_INBOX и /TRL/XDE_OUTBOX );
повторная постановка документов в очередь, а также инициация повторного подписания/ отклонения/ аннулирования после технических ошибок (статус «E») при передаче документов (транзакции /TRL/XDE_INBOX и /TRL/XDE_OUTBOX );
удаление подлежащих отправке подписанных документов из очереди (транзакция /TRL/XDE_OUTBOX );
Роль /TRL/XDE_ADMN содержит полномочия, представленные в таблице ниже.
Сейчас я себе вынесу моск. Вы посидите рядом, посмотрите, покрутите пальцем у виска в мой адрес. Я пока разберусь для себя, что же все-таки входит в полномочия HR, какие они бывают.
Основные и привычные нам полномочия, которые определяются объектами полномочий. Наиболее известные это PLOGI, P_PORGIN, S_TCODE. С ними все понятно, все умеют работать. Задаем поля, определяем какие полномочия на какие объекты присваиваются. Из важного только то, что внутри одного объекта полномочий все поля читаются системой как логическое «И»: если инфотип 0008 И доступ на «чтение», то разрешить чтение. Один и тот же объект можно повторять в одной роли, тогда система будет читать объекты в одной или многих ролях по принципу «ИЛИ». Если в объекте 1 есть доступ на чтение ИТ0008 или в объекте 2 есть доступ на запись ИТ0008, то дать ИЛИ чтение, ИЛИ запись. В зависимости от того, что делает пользователь. Поэтому нужно аккуратно назначать множество ролей, так как в одной роли могут быть расширенные полномочия на что-то, когда в другой сокращенные. В итоге система даст полномочия по расширенной роли, ибо работает принцип «у кого-то в роли есть такие полномочия = ИЛИ».
Транзулька OOAC (ключики): ADAYS — определяет сколько дней после перевода сотрудника можно его видеть. Например, если поставить число 10 дней (календарных), то на 11 день вы не сможете его увидеть согласно вашим полномочиям. Если проще, то был человек в разделе персонала А, у вас в роли права на раздел персонала А. Его перевели в Б. На Б у вас нет полномочий. Если стоит 0 дней, то вы сразу же после перевода (в ИТ0001 поменяется раздел персонала) перестанете его видеть. Если поставить больше нуля, то после истечения этого количества дней вы перестанете его видеть. Параметр работатает только для тех инфотипов, которым поставили галочку в поле T582A-VALDT. И только для объекта P_ORGIN.
APPRO включает и выключает работу инфотипа 130. Этот инфотип позволяет ограничивать доступ к данным на период закрытия заработной платы, например.
DFCON — определяет как системе реагировать на уволенных и несписочных сотрудников, у которых в ИТ0001 в поле штатная должность стоят все девятки. Работает только при включенных контекстных полномочиях (об этом дальше). Есть следующие варианты:
1 — смотреть на организационную единицу, по умолчанию отклонить доступ
2 — не смотреть на организационную единицу, по умолчанию отклонить доступ
3 — смотреть на организационную единицу, по умолчанию предоставить доступ
4 — не смотреть на организационную единицу, по умолчанию предоставить доступ
Когда у вас есть S в 0001 ИТ, то система штатно отрабатывает по профилю структурных полномочий и выходит на объект P (лицо, оно же табельный номер). Если мы уволили человека, или он находится в несписке, то обычно мы храним только организационную единицу. В зависимости от того, как мы хотим назначать доступы, нужно выбрать 1 или 3.
Если нам все равно на организационную единицу, мы хотим таким людям назначить действие по-умолчанию, то это варианты 2 или 4.
INCON включает или выключает структурные полномочия и использование объекта полномочий P_ORGINCON
NNCON — включает или выключает пользовательские контекстные полномочия P_NNNNNCON (об этом ниже).
NNNNN — включает или выключает пользовательские обычные полномочия
ORGIN — включает или выключает использование стандартной проверки полномочий с помощью P_ORGIN
ORGPD — включает или выключает сам механизм использования структурных полномочий. Значения такие же, как у DFCON. Не понял в чем разница. Ушел думать дальше.
ORGXX включает или выключает расширенную проверку полномочий с помощью объекта P_ORGXX. Внутри объекта P_ORGXX можно расширить проверку полномочий на поля блока администраторов из ИТ0001 (администратор кадров, времени, зарплаты). Например, если вам мало разграничить полномочия по разделам персонала, но еще и нужно по отдельным людям, которые будут заниматься этими табельниками, то вполне можно ввести табельщиков как администраторов рабочего времени и раздать им полномочия по людям. Тогда не нужно использовать структурные полномочия, и одновременно можно разграничить доступ по бригадам или цехам в одном большом структурном подразделении.
PERNR — определяет доступ к самому себе. Если этот переключатель включен, то с помощью объекта P_PERNR можно переопределить полномочия своей же роли только для своего табельника. Например, я Поцелуев, главный зарплатчик. По своей роли я могу менять всем ИТ0008 и считать зарплату. Но я вредный, и иногда хочу поменять себе зарплату. Вот чтобы такого не случилось, вредный администратор добавляет в мою роль полномочия P_PERNR, где стоит PSIGN = E (Exclude — исключить) и AUTHC = W,D,S (удалить из моих полномочий права на изменение 8 ит для меня самого). Как система узнает что я, это я. Легко. В ИТ0105 мы записываем USER = VIRVIT для табельника 1235. Поэтому разумно мне, вредному Поцелуеву, не давать полномочия на изменение 105 инфотипа. Этот объект полномочий часто используется в ESS, когда мы хотим дать работникам поменять что-то в своих персональных данных. Чтобы они не могли менять у всех, мы даем права только на самих себя с помощью P_PERNR-PSIGN = I.
XXCON аналогичен ORGXX, но работает для контекстных полномочий, когда мы хотим сначала ограничить доступ по организационной структуре, а затем еще и администраторами добить полномочия. Капут, короче, полный, аллес. Объек для надругательства — P_ORGXXCON
С ключиками все, идем дальше.
Основные расширенные полномочия всего навсего расширяются ключиком в OOAC-ORGXX, а в роли добавляется объект P_ORGXX. Как уже было сказано задачей этого объекта является уточнить доступ внутри раздела/подраздела персонала, группы/категории с помощью полей Администраторов из инфотипа Организационное присвоение.
Контекстные расширенные аналогичны основным расширенным, только ключик XXCON и объект P_ORGXXCON.
Проверка самого себя P_PERNR. Рассмотрели выше для ключика OOAC — PERNR.
Полномочия P_TCODE это такая архаичная штука, которая зачем-то еще жива. Этот обьект полномочий определяет доступ исключительно к части HR транзакций, которые удовлетворяют условиям: а) код транзакции начинается с P*, б) внутри этой транзакции осуществляется проверка на объект полномочий P_TCODE. Найти такие транзакции можно в SE93 через Utilities — Find, Edit — All Selection. У меня таких набралось 301 штука. То есть сначала система проверяет на уровне базиса код транзакции по S_TCODE, а потом на уровне HR еще и P_TCODE. Это нужно для того, что в HR иногда одна транзакция вызывает другую, поэтому таким образом разграничиваются полномочия. Негуманно, но факт.
А теперь настало время ада. Есть структурные полномочия, а есть контекстные полномочия. Оставайтесь на связи, не перегрейтесь. Я закипаю.
Структурные полномочия решают одну простую задачу — к какому конкретному табельному номеру дать доступ. Неважно какой доступ, важно кому. То есть, задача структурных полномочий пробежаться по организационной структуре, собрать все объекты типа P Лицо и отдать их в механизм проверки стандартных полномочий P_ORGIN и P_ORGXX. Все.
Включаются структурные полномочия в OOAC — ORGPD. Структурные полномочия представляют собой Профиль структурных полномочий. Не путать с профилем полномочий обычных, который можно увидеть в SU01 (SAP_ALL это тоже профиль, для тех кто не знал). Профиль структурных полномочий определяет КАК пройти системе по организационной структуре и вытащить объекты типа P. Пройти по структуре мы можем по-разному.
Теперь расширяем понятие структурных полномочий на организационную структуру. Оргструктура это тоже объекты, такие же как P. Поэтому, определяя доступ к организационной структуре с помощью объекта полномочий PLOGI мы определяем КАКОЙ доступ дать к определенному объекту, а САМ объект можно получить через структурные полномочия.
То есть аналогия такова. Для администрирования персонала есть разграничение полномочий по разделу/подразделу/группе/категории. Для организационного менеджмента ничего такого нет, поэтому разграничение можно сделать с помощью путей анализа и корневых объектов. Например, задать всю структуру второго уровня, не ниже. Тоже вариант 😉
Профиль структурных полномочий определил объекты, к которым мы можем обратиться. Объекты полномочий PLOGI и P_ORGIN определили как мы можем обратиться к этим объектам. Вроде бы все логично. Теперь нужно связать меня, Поцелуева, он же в простоинтернетии VirVit, с нашим профилем структурных полномочий, который даст те или иные права мне.
Есть несколько вариантов решения задачи.
И есть окольное решение. Сделать связь US — O. Сделать свой функциональный модуль, который присвоить в профиль структурных полномочий, а профиль присвоить SAP*. Тогда доступ будет определяться исключительно на основании того, к какой организационной единице я привязан. Это наиболее гибкий путь. Для примера посмотрите функциональный модуль RH_GET_ORG_ASSIGNMENT.
Контекстные полномочия призваны свернуть мозг любому. Постараюсь объяснить на примере.
Проверка пользовательского объекта полномочий OOAC — NNNNN. А вот тут самое интересное. Мы можем сделать свой объект полномочий в транзакции SU21. В нем нужно прописать обязательные стандартные поля
AUTHC: Authorization Level
А еще можно нарисовать любые поля из структуры PA0001. Вы понимаете, какая это офигенная круть? А чтобы довести вас до экстаза, надо добавить еще поле TCD, которое будет заполняться кодом текущей транзакции. Таким образом, можно назначать полномочия в зависимости от транзакции, которую вы запускаете. Если это отчет для налоговой, где нужно дать доступ на ТОПов, то делаете все группы и категории = *, а TCD = 4-ФСС.
Полномочия на инфонабор в SQ02. При создании инфонабора можно заполнить поле Authorization group, которое затем позволит ограничить доступ к запросам (SAP QUery) на основании этой группы полномочий. Сама группа проверяется в объекте полномочий S_PROGRAM.
Обозначенная в заголовке статьи архитектура раскрыта кратко, только в разрезе, необходимом для понимания того, как работают полномочия в Fiori.
Что такое Front-end и Back-end?
Обозначенная в заголовке статьи архитектура раскрыта кратко, только в разрезе, необходимом для понимания того, как работают полномочия в Fiori.
Технические компоненты Fiori Launchpad
Рис. 1 Central UI и Gateway
Product UI – это транзакционные и аналитические приложения разных продуктов SAP (отображаются Fiori Launchpad в виде плиток), также расположенные на Fiori Front-end Server. Они не являются частью Central UI и нуждаются в специфичных для каждого продукта UI add-on-ах. Этих add-on-ов множество для самых разных областей бизнеса, и они устанавливаются на Fiori Front-end-сервер. Как видно ниже, в примере на рисунке 2, это несколько компонентов, начинающихся на буквы UI……….
Рис. 2 Product UI
Модель организации интерфейса Fiori для S/4HANA
Основные компоненты модели организации интерфейса Fiori: бизнес-роли, бизнес-группы, бизнес-каталоги, технические каталоги, технические back-end-каталоги, OData-сервисы.
Fiori-бизнес-группа формирует начальный экран рабочего места пользователя, то есть отображает плитки, добавленные в Fiori-группу из одного или нескольких каталогов. Группа, в свою очередь, добавлена в PFCG-бизнес-роль, а роль уже присвоена пользователю. Именование стандартных, поставляемых SAP бизнес-групп имеет следующий префикс – SAP_BCG_(GROUPNAME). См. Рис. 3.
ПРИМЕЧАНИЕ: если в группе содержится приложение из каталога, который не присвоен роли пользователя (забыли, к примеру, присвоить), то плитка этого приложения данному пользователю в Launchpad отображаться не будет.
Технический каталог – это набор приложений (плиток и target mapping), более широкий чем бизнес-каталог и состоящий из приложений, относящихся к какой-либо функциональной области (к примеру, FI, но не полностью, конечно). Имеется ограничение на количество объектов в техническом каталоге, связанное с производительностью системы (смотреть в технической документации). На объекты в техническом каталоге ссылаются плитки из бизнес-каталогов. Содержимое технических каталогов недоступно для вывода напрямую в виде плиток для пользователя. Вывод для пользователя выполняется только через бизнес-каталоги. Именование стандартных, поставляемых SAP технических каталогов имеет следующий префикс – SAP_TC_(CATALOGNAME). См. Рис. 3.
Технический back-end-каталог – это технический каталог для унаследованных приложений (транзакций и Webdynpro) из предыдущих версий SAP ERP. App Descriptors – так называются ABAP-транзакции для GUI HTML и Webdynpro-приложения, доставшиеся по наследству S/4HANA из предыдущей версии ERP и существующие в виде плиток в Fiori Launchpad, добавленные в технический back-end-каталог. Именование стандартных, поставляемых SAP технических back-end-каталогов имеет следующий префикс – SAP_TC_(CATALOGNAME) См. Рис. 3.
OData-сервисы – это сервисы, через которые приложения Fiori из Front-end взаимодействуют с Back-end, то есть обеспечивают передачу данных. Обычно они активируются во время первоначальной настройки после установки системы (Fiori Rapid Activation).
Рис. 3 Модель организации интерфейса Fiori
Рис. 4 Пример отображения в Fiori Launchpad двух групп плиток
Стандартные роли для работоспособности Fiori Launchpad
Для того, чтобы пользователь мог запустить Fiori Launchpad даже без плиток, то есть пустой, как самостоятельное приложение, обязательно необходимы стандартные роли. Данные роли генерируются при начальных шагах настройки системы, как правило автоматизированным сценарием, который носит название Fiori Rapid Activation. Этот сценарий обычно запускает специалист, инсталлирующий систему. Если при запуске сценария названия ролей принудительно не изменены, то по умолчанию их именование будет примерно таким (зависит от версии системы):
Групповая роль – Z_FIORI_FOUNDATION_USER
Архитектура SAP Fiori в разрезе системного ландшафта SAP
Данный раздел повествует не о полномочиях и не о всем, что с ними связано, а об устройстве системного ландшафта S/4HANA в сочетании с SAP Fiori-частью (она же часто в документации именуется SAP Gateway). Схема системного ландшафта будет влиять на то, как вы будете работать с каталогами Fiori и, соответственно, с полномочиями конечных пользователей, поэтому слегка затронем данную тему. Информацию по рекомендациям от SAP можно найти в интернете, введя в поиске «SAP Fiori Deployment Recommendations». Последняя на момент написания данной статьи версия рекомендаций — это 6 версия за октябрь 2020 года.
Рис. 5. Совместное размещение Fiori Front-End Server (FES) и S/4HANA типа Embedded on-Premise
Рис. 6. Отдельное размещение Fiori Front-End Server (FES) и S/4HANA типа Hub on-Premise
Где найти информацию о приложениях Fiori
Прежде чем приступать к внедрению системы, консультанты должны изучить функционал приложений, входящих в Fiori. Помимо группы транзакций, которые в S/4HANA вообще заблокированы как устаревшие, хотя некоторые ещё действуют параллельно с новыми приложениями Fiori, существует функционал, который реализован только на Fiori. Лучшим вариантом будет первоначально изучить функционал Fiori на песочнице, то есть тестовой S/4HANA-системе. Конечно, если таковая имеется. Вся текущая информация о приложениях и всех сопутствующих компонентах находится на портале SAP. Искать следующим образом – набрать в поиске google «Fiori library». Первая же строка будет ссылкой на библиотеку приложений Fiori Apps Reference Library (см. Рис 7).
Рис. 7. Поиск Fiori Apps Reference Library в поисковой системе
Так выглядит интерфейс Fiori Library (см. Рис 8). Доступ предоставлен для всех, войти можно и без S-user-а. Можно искать по множеству критериев, по системам и их версиям, по типу бизнеса и так далее. Можно найти по транзакции или по приложению, если оно известно. Всего на момент написания статьи около 12800 доступных приложений, и с каждой версией их количество увеличивается.
В интерфейсе Fiori Apps Reference Library (см. Рис 8) можно вбить в строку поиска один из известных объектов для изучения связанной с ним информации:
1) приложение Fiori – обычно имя приложения Fiori выглядит Fyyy (yyy цифры).
2) Имя ABAP-транзакции для поиска, к примеру, каталога, в который она может входить.
4) OData-сервис для поиска связанных с ним каталогов.
5) Каталог для обратного поиска OData-сервиса.
К примеру, поищем транзакцию fb02 (если транзакция отображается в поиске Fiori Library, это значит, что транзакция имеется в системе и включена в каталог). Если транзакция не найдена, значит, она не включена в каталоги. Она, возможно, существует, не заблокирована как устаревшая, но не включена в каталог. В этом случае надо самостоятельно делать технический каталог или включать в существующий технический каталог. И затем следующим шагом включать в бизнес-каталог.
Рис. 8. Интерфейс Fiori Apps Reference Library
Если Fiori-приложение или транзакция обнаружились в Fiori Library, они обязательно должны принадлежать «техническому каталогу». Чаще всего, но не всегда, они в дополнение к «техническому каталогу» могут принадлежать и к «бизнес-каталогу», и к «бизнес-группе». На рисунке 9 ABAP-транзакция FB02 входит в «технический каталог» SAP_TC_FIN_FO_COMMON. Но ни «бизнес-каталога», ни «бизнес-группы» для данной транзакции не существует. При необходимости «бизнес-каталог» и «бизнес-группу» можно создать самостоятельно.
Рис. 9. Транзакция FB02 входит в «технический каталог» SAP_TC_FIN_FO_COMMON
Транзакция FINTAP, также взятая для примера, входит в «технический каталог» SAP_TC_FIN_FO_BE_APPS и в «бизнес-каталог» SAP_SFIN_BC_AP_DOC_PROC. Также имеется стандартная SAP-бизнес-группа SAP_SFIN_BCG_SUPP_ACC и «бизнес-роль» SAP_BR_AP_ACCOUNTANT. Смотреть Рис. 10, 11. В данном случае, можно сразу присвоить пользователю существующую «бизнес-роль», и он сможет приступить к работе.
Рис. 10. Транзакция FINTAP
Рис. 11. Транзакция FINTAP
Последовательность запуска приложений Fiori
Названная в заголовке раздела последовательность изложена только для Fiori приложений, но не касается унаследованных ABAP транзакций и Webdynpro приложений.
Практический пример добавления в роль транзакции и Fiori приложения
Пример будет рассмотрен на варианте ландшафта типа hub для лучшего понимания того, как распределены полномочия между системами. Для примера можно взять ту транзакцию, что выше упоминалась в статье, то есть FB02. Необходимо найти в каком стандартном техническом или бизнес каталоге она содержится, а затем добавить её в Fiori Launchpad.
Первым шагом выполнить поиск транзакции FB02 через функцию «плитки/мэппинги целей». См. Рис. 12. В результате поиска можно убедиться, что плитка для транзакции FB02 находится в техническом каталоге SAP_TC_FIN_GL_BE_APPS.
