23.03.2022 23:32
Latyshenko 0 266 Источник

Введение

MDF бизнес-правила выполняются в той же последовательности, в которой они присвоены соответствующему событию.[1] Однако последовательность самих событий фиксирована и не может быть изменена. Аналогично каждое сообщение выводится в момент, отведенный для него в рамках последовательности событий.

Заранее определенная последовательность событий описана в руководстве Implementing the Metadata Framework (§ 11.1.3 Order of MDF-Based Rule Execution, стр. 140), в котором, к сожалению, не показаны ни полная последовательность событий, ни особенности в порядке сообщений.

В этой статье мы предоставим упущенные детали о последовательности событий и сообщений для MDF-правил.

Сценарий «Правила для объектов на базе MDF»

Вышеупомянутый документ объясняет, что каждый сценарий для бизнес-правил имеет свой собственный момент в рамках события, вкратце, независимо от фактического порядка в рамках события, правила сценария «Базовый» выполняются перед аналогичными правилами сценария «Правила для объектов на базе MDF».[2]

Однако данное руководство также упоминает, что правила сценария «Базовый» вовсе не должны использоваться для MDF-объектов, особенно для новых внедрений.

Мы полностью поддерживаем данную рекомендацию, так как бизнес-правила сценария «Правила для объектов на базе MDF» имеют много преимуществ по сравнению с правилами базового сценария.

Более того, если вы уже привязали базовое правило к MDF-объекту, то мы рекомендуем изменить сценарий при помощи инструмента «Изменить сценарий» (см. Рисунок 1). Подробнее о данном инструменте см. в руководстве Implementing Business Rules in SAP SuccessFactors, § 10 Changing a Rule Scenario, стр. 71.

Рисунок 1. Инструмент «Изменить сценарий» бизнес-правила
Рисунок 1. Инструмент «Изменить сценарий» бизнес-правила

Последовательность событий

Последовательность событий MDF-объекта зависит от операции, выполняемой с данным объектом: «Просмотреть», «Создать», «Вставить новую запись», «Исправить» («Редактировать») и «Удалить». На Рисунке 2 показана последовательность событий после каждой операции.

Например, как показано на Рисунке 2, операция «Вставить новую запись» сначала вызывает событие «По загрузке», за которым следует событие «По изменению поля» с назначениями «Оценить» и «Проверить», за которым следует событие «Сохранение» с назначениями «Документооборот», «Оценить» и «Проверить», за которым следует событие «Проверка», за которым следует диалоговое окно «Подтвердить запрос» для документооборота, за которым следует событие «После Сохранения» с назначениями «Проверить» и «Оповещение», за которым может следовать событие «По загрузке». Разъяснение см. на Рисунке 2 для операции «Вставить новую запись».

Событие «По загрузке» предназначено для операции «Посмотреть», однако данное событие также вызывается всеми другими операциями («Создать», «Вставить новую запись», «Исправить» и «Удалить»). Операции «Создать», «Вставить новую запись» и «Исправить» вызывают событие «По загрузке» по-разному, более того, одна и та же операция вызывает данное событие по-разному в Профиле сотрудника и в инструменте «Управлять данными». Операция «Удалить» вызывает событие «По загрузке» для записи, действующей на сегодняшнюю дату, и также по-разному в Профиле сотрудника и инструменте «Управлять данными». Принимая во внимание все перечисленные различия, событие «По загрузке» следует использовать с осторожностью и тщательно тестировать.

Событие «По изменению поля» может быть вызвано бизнес-правилом, присвоенным другому событию «По изменению поля». Кому-то может показаться, что это открывает новые горизонты для автоматизации, однако подобные настройки излишне сложны и, более того, могут привести к циклическим ссылкам, поэтому, как правило, таких настроек лучше избегать.

Рисунок 2. Последовательность событий и MDF-правил после операций «Просмотреть», «Создать», «Вставить новую запись», «Исправить» и «Удалить» для MDF-объектов
Рисунок 2. Последовательность событий и MDF-правил после операций «Просмотреть», «Создать», «Вставить новую запись», «Исправить» и «Удалить» для MDF-объектов

1 Если данные вводятся в Профиль сотрудника, то только одно информационное сообщения может быть сгенерировано в рамках события «По загрузке», и только из экрана «История изменений». 2 Данная операция может вызывать событие «По загрузке» либо в Профиле сотрудника, либо в инструменте «Управлять данными». 3 Если данные вводятся в Профиль сотрудника, то только одно информационное сообщение может быть сгенерировано в рамках события «По изменению поля». 4 Если данные вводятся в Профиль сотрудника, то информационные сообщения не генерируются из экрана «История изменений» в рамках события «Удалить». 5 После удаления записи, отображается запись, действующая на сегодняшний день, а если таковой нет, то самая ранняя будущая запись, что, в свою очередь, вызывает соответствующее событие «По загрузке»

На Рисунке 3 показано, из каких элементов состоит последовательность событий.

Рисунок 3. Элементы последовательности событий
Рисунок 3. Элементы последовательности событий

Подробности о последовательности событий см. в руководстве Implementing the Metadata Framework (MDF), § 11.1.3 Order of MDF-Based Rule Execution, стр. 140.

Момент для бизнес-правила с назначением «Документооборот» в рамках событий «Сохранение» и «Удаление»

На Рисунке 2 бизнес-правила с назначением «Документооборот» отмечены серым цветом, потому что они не зависят от порядка присвоения в «Определении объекта» и всегда выполняются в момент, специально для них отведенный:

  • По событию «Сохранение» данное бизнес-правило выполняется первым;

  • По событию «Удалению» данное бизнес-правило выполняется последним.

Подробности см. в руководстве Implementing the Metadata Framework (MDF), § 12.2 Need to Know About Workflows in MDF, стр. 162.

Последовательность действий «Генерировать сообщение»

Действие «Генерировать сообщение» используется для вывода всплывающих сообщений из правил с назначениями «Проверить», «Оценить» и «По загрузке». Сообщения выводятся в фиксированные моменты в рамках последовательности событий, как показано на Рисунке 2. В рамках каждого момента, сообщения отображаются в том же порядке, в котором они были сгенерированы соответствующими бизнес-правилами.

Все сообщения, сгенерированные одним событием, группируются по тяжести («Ошибка», «Предупреждение» и «Информация») и отображаются по завершении соответствующего события. Диалоговое окно выводит только группу сообщений с наивысшей тяжестью:

  1. Если есть хотя бы одно сообщение об ошибке, то диалоговое окно выводит только сообщения об ошибке;

  2. Если есть хотя бы одно предупреждение и нет ни одного сообщения об ошибке, то диалоговое окно выводит все сообщения, включая информационные, в виде одного предупреждения;

  3. Если нет ни сообщений об ошибке, ни предупреждений, то диалоговое окно выводит все информационные сообщения.

Предупреждения и информационные сообщения, сгенерированные событиями «Сохранение», «Проверка» и «После сохранения», дополнительно группируются по степени тяжести и выводятся до/после диалогового окна «Подтвердить запрос» для документооборота, как показано на Рисунке 4.

Если считать последовательность всех всплывающих окон, сгенерированными данными событиями, то диалоговое окно «Подтвердить запрос» выводится четвертым по счёту, а именно: после диалогового окна с предупреждениями по событиям «Сохранение» и «Проверка» и до сообщений об ошибке по событию «После сохранения».

Ниже представлено несколько примеров использования разных типов сообщений:

  • Сообщение об ошибке по событию «После сохранения» (см. номер 5 на Рисунке 4) является последним моментом, когда можно блокировать сохранение записи, что удобно использовать для проверки настроек в продуктивной системе.

  • Предупреждения по событию «После сохранения» вовсе не следует использовать, так как в нормальной ситуации они не отображаются.

  • Информационные сообщения по событию «После сохранения», напротив, более предпочтительны, так как два других события («Сохранение» и «Проверка») могут смешивать информационные сообщения с предупреждениями.

Рисунок 4. Последовательность вывода сообщений разной степени тяжести, сгенерированных для событий «Сохранение», «Проверка» и «После сохранения»
Рисунок 4. Последовательность вывода сообщений разной степени тяжести, сгенерированных для событий «Сохранение», «Проверка» и «После сохранения»

Заключение

Последовательность событий, бизнес-правил и сообщений – сложная тема, которая не в полной мере описана в справочных руководствах. Технические детали, предоставленные в этой статье, помогут читателю лучше понять MDF бизнес-правила и значительно улучшить решения, основанные на MDF-объектах.

Список литературы

  1. Латышенко В. В. Build Custom Solutions Using Business Rules for MDF Objects [Электронный ресурс] // SAPinsider. 2022. URL: https://sapinsider.org/expert-insights/build-custom-solutions-using-business-rules-for-mdf-objects/ (Дата обращения: 23.03.2022).

  2. Implementing Business Rules in SAP SuccessFactors. Document Version: 2H 2021 – 2022-03-18 [Электронный ресурс]. URL: https://help.sap.com/doc/8c6720bf5d0b4715ab10fb1b4f69c4f2/latest/en-US/SF_PLT_Implementing_Business_Rules.pdf (Дата обращения: 23.03.2022).

  3. Implementing the Metadata Framework (MDF). Document Version: 2H 2021 – 2022-03-18 [Электронный ресурс]. URL: https://help.sap.com/doc/067c84408d824c7382637fc264e11310/latest/en-US/SF_IMP_MDF.pdf (Дата обращения: 23.03.2022).

[1] За исключением MDF-правил с назначением «Документооборот», которые выполняются в отведенный для них момент.

[2] За исключением бизнес-правила, запускающего документооборот в рамках события «Сохранение», когда MDF-правило с назначением «Документооборот» предшествует базовым правилам.

Комментарии (0)