Сугубо с моей точки зрения тему путей анализа очень сильно недооценивают в мире. Эту тему даже бочком обходят на проектах, так как мало кто ее нормально понимает. Я сейчас работаю на проекте с Романом metha и вижу его заходы на PPOME, где эти самые пути анализа используются вдоль и поперек, и с уверенностью могу вам сказать, что Ромка единственные в мире, кто эту тему понимает (из тех, кого я видел), и через пару лет мы с ним сваяем расчет зарплаты на PPOME и путях анализа 🙂 Бойтесь.
Сегодня речь пойдет об этих самых путях анализа, приправах для их приготовления и инструментах для воплощения самих сокровенных фантазий в жизнь. Дословно путь анализа можно перевести как путь, по которому система анализирует связи между объектами организационного менеджмента и выводит иерархию этих объектов. То есть берем любой объект OM? и просим систему построить от него иерархию (дерево с листочками) вверх или вниз. При этом мы с помощью пути анализа объясняем какие веточки и как нужно собирать, что выводить, а что пропустить.
Прежде чем я начну, а я начну, я вам рекомендую потратить вечером или утром пару часов, чтобы самим поставить задачу и поиграться с решением на путях анализа. Понимание работы этого инструмента сильно поможет вам, просто поверьте, а поймете потом.
Чтобы было нагляднее, давайте поставим боевую задачу. Сейчас модно делать различные сравнительные анализы (бенчмарки по-модному), когда нужно сравнить сколько численность, стоимость, какая эффективность одной и той же работы в разных подразделениях компании. Например, сколько стоит заменить картридж в Москве и Владивостоке, если у компании есть филиалы в обоих городах, в обоих городах есть ИТ-отдел. Ставим укрупненную задачу — сделать функциональную структуру компании. Это означает, что мы должны для каждого филиала определить свою функцию.
Функция у нас будет выражена объектом организационного менеджмента, который связывается с подразделениями филиалов, отвечающих за нее.
Открываем ракурс T777O, где нам нужно создать новый объект — Функция.
В ракурсе T777I пропишем 1000 и 1001 инфотипы для нашего объекта, чтобы его можно было создать и связать с другими объектами.
В ракурсе T778V создадим новые соединения для управления функцией.
Прописываем временные привязки AZ01/BZ01.
Давайте проверим, что все создается. В PP01 создаем запись для нашего объекта 90 и связываем его с подразделением.
Руками мы что-то создали, но неплохо бы это визуализировать. Начнем с транзакции OOAW — Evaluation Paths — настройка путей анализа (оно же в ракурсе T778A). Здесь мы будем создавать путь анализа, который скажет системе как визуализировать созданную нами структуру.
Первая подзадача — вывести функции у подразделений.
Создаем такой путь анализа.
И вот так выглядит результат в транзакции PPST.
Вторая подзадача — вывести все подразделения, где есть указанная функция.
Создаем такой путь анализа.
И вот так выглядит результат в транзакции PPST.
Вроде бы уже становится понятнее, но что дальше-то? Дальше нам нужно сделать инструмент ведения таких структур удобным. Для этого используется транзакция PPOME/PPOSE и ракурсы ведения. Давайте сделаем один.
Перед началом работы рекомендую включить технические ключики для PPOME. В транзакции SU3 устанавливаем два параметра:
OM_FRAM_SCEN_DISPLAY = X
OM_TABTYPE_DISPLAY = X
OM_OBJM_SCEN_DISPLAY = X
OM_ARRAYTYPE_DISPLAY = X
OM_DIS_OBJECTMANAGER = X
OM_FRAMEWORK_OBJ_NR = X
Вот так это будет выглядеть.
Теперь обратимся к настройке PPOME для отображения и управления такой структурой. Практически вся настройка осуществляется в кластере ракурсов T77FRAMEWORK (транзакция SM34).
Разберем все ракурсы в левой части.
Tab Page Definition. Здесь мы можем определить закладки для типов объектов оргменеджмента. Можно определить свою закладку как для инфотипа (поле infotype + галочка Infotype-specific), так и общую, которая будет применяться для разного типа объектов (например, BASIC, которая применяется для отражения 1000, 1002 ИТ).
Definition Service. Определяет набор так называемых сервисов для транзакции. Сервисы могут быть как для отображения ракурсов (тип сервиса GOWD), для отображения детальный данных объекта (тип сервисы DETA), отражение статических страничек (тип сервиса HTML).
Attribute Service позволяет определить для сервисов, которые отображают иерархию объектов, путь анализа, по которому и будет происходить выборка. Например, вот так.
Scenario Group Definition определяет что-то, что я не очень понимаю что.
Scenario Definition (Hierarchy Framework), как бы это по-проще сказать, определяет транзакции для создания, ведения и просмотра набора сервисов/ракурсов. Тут мы можем создать свои транзакции для ведения своих объектов, иерархий. Если вспомнить, что оргструктура используется во многих модулях системы, а не только в HR, то полет фантазии может стать неограниченным.
Icon Legend указывает какие иконки нужно отразить в легенде. Сами коды иконок хранятся в пуле ICON (SE80) и одноименной таблице ICON.
Tab Page in Scenario for each Object Type из названия говорит сам за себя — определяет какие закладки (странички) в области детального просмотра привязаны к объектам оргменеджмента для нашего сценария. В моем примере это отражение стандартной закладки для объектов типа O с 1000, 1002, галочкой штаб. А для всех остальных упрощенный формат.
Request Definition самое сложное и интересное. Здесь мы определяем какие сервисы должны вообще вызываться и работать в рамках наших транзакций. Есть недокументированная фича (или я забыл, где видел эту документацию), но для всех сценариев обязательны следующие запросы:
DISPLAY_EMPTY_DETAIL_FRAMEWORK
SHOW DETAIL (GENERAL)
SHOW INITIAL SCREEN
TABCHANGE
То есть выглядеть это будет вот так с учетом моего одного сервиса, который отражает бизнес-функции.
Есть подозрение, что перечень сервисов можно изменить, если использовать свои функциональные модули для инициализации функциональности PPOME (так проще называть Hierarchy Framework): NF_GET_INIT_EVENT_WORKPLACE и NF_GET_INIT_EVENT_OBJMANAGER.
Request in Scenario for each Object Type
Что у нас получается. Есть сценарий. В нем прописан запрос ZVIRVIT, для которого указан сервис ZVIRVIT (с типом GOWD). Выше, в разделе Definition Service, мы определили этот самый сервис и привязали к нему путь анализа, который и выводится в область иерархии.
Как-то так это выглядит:
Полезняшки:
RHRELAT0 — Allowed Relationships of Object Types
Транзакция PPST (или отчет RHSTRU00) — Structure Display/Maintenance
Транзакция PPSC — Create/Change Structure
Как-нибудь, расскажу про настройку средств поиска, допданных для соединений и другие вкусняшки.