Оригинал статьи.

Как видно, совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.

—Антуан де Сент-Экзюпери, «Планета людей»

Введение

MDF-объекты и бизнес-правила широко используются в Платформе, Подборе, Адаптации, Employee Central и других модулях SuccessFactors. И, естественно, есть много информации о каждом конкретном признаке MDF-объектов, и каждом сценарии, каждой функции бизнес-правил, что очень помогает при настройке конкретных правил и решении точечных проблем.

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

В этой статье мы дадим общие рекомендации по созданию клиентских решений, основанных на большом количестве бизнес-правил для MDF-объектов. А также поделимся дополнительной информацией, которая поможет консультантам по Employee Central использовать правила более эффективно.

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

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

У сценария «Правила для объектов на базе MDF» много преимуществ, включая следующие:

• Он дает доступ только к тем функциям, которые применимы для данного конкретного Назначения;
• Он полностью встроен в Центр расширений;^[1]
• Он предоставляет возможность навигации из бизнес-правила в события, вызывающие данное правило, как показано на Рисунке 1.

Рисунок 1. Переход из бизнес-правила к событиям, вызывающим правило, и в Центр расширений с помощью инструмента «Назначение правил»

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

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

Идентификатор правила

При создании MDF-правила для MDF-объекта, вы видите поля как на Рисунке 2.

В этой статье мы подробно расскажем о трех из них: Имя правила, Идентификатор правила и Назначение. Подробности о других полях см. в руководстве Implementing the Metadata Framework (MDF), § 11.1.1 Configuring a Business Rule for MDF, стр. 136.

Рисунок 2. Базовая информация о бизнес-правиле для MDF-объектов

Поле «Идентификатор правила» можно изменить только тогда, когда данное правило не присвоено к определению объекта.

Данный идентификатор используется как для выгрузки/загрузки бизнес-правила, так и для выгрузки/загрузки его присвоения к соответствующему объекту определения.

Мы рекомендуем рассматривать идентификатор в качестве «Биографической справки» о бизнес‑правиле и хранить в данном поле неизменяемые факты о правиле, чтобы было удобно идентифицировать, искать, экспортировать и импортировать правила и их присвоения.

Ниже приведено несколько примеров фиксированных фактов о правиле:

• Аббревиатура проекта внедрения;
• Код соответствующего объекта основы (напр., JobClassification);
• Назначение («Инициализировать», «Проверить», «Оценить», «Документооборот», «Оповещение» и «По загрузке»);^[2]
• Код поля, для которого создано данное бизнес-правило (напр., externalCode, если правило выполняет автонумерацию, или department, если правило наследует данные из отдела в позицию).

Далее приведено несколько примеров данного поля: ACME_Position_Initialize, ACME_Position_externalCode_Evaluate, ACME_Position_Workflow, ACME_Position_department_Evaluate, ACME_Position_jobCode_Evaluate.

Поле «Идентификатор правила» вмещает 127 символов, и этого достаточно для всех фиксированных фактов о бизнес-правиле.

Имя правила

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

• «Настроить бизнес-правила», где правила создают, просматривают, изменяют и удаляют;
• «Настроить определения объектов», где бизнес-правила присваивают следующим событиям: «По изменению поля», «Инициализация», «Проверка», «Сохранение», «После сохранения» и «Удаление»;
• «Управлять данными», где в «Конфигурации объектов» бизнес-правила присваивают событию «По загрузке» для стандартного пользовательского интерфейса MDF-объекта;
• «Управлять пользовательским интерфейсом конфигурации», где бизнес-правила присваивают событию «По загрузке» для настраиваемого пользовательского интерфейса MDF-объекта.

Будучи изменяемым и видимым в пользовательских интерфейсах, имя правила идеально подходит для хранения пояснений по изменяемым настройкам бизнес-правил, включая следующие:

• Действия, которые планируют сделать с данным бизнес-правилом (напр., «Будет удалено», «Будет замено», «Потребует корректировки», «Корректируется» и т.п.);

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

В идеале имя должно хранить все ключевые факты об изменяемых настройках данного бизнес-правила и помогать вам понять правило еще до того, как вы его откроете. Также хорошей практикой является дублирование идентификатора правила в имени правила (чтобы таким образом продемонстрировать, что соглашение именований не изменялось).

В Таблице 1 приведены примеры бизнес-правил с пояснением соответствующих ключевых фактов. Поле «Имя правила» вмещает 128 символов, и этого достаточно для всех ключевых фактов о правиле.

Таблица 1. Примеры имен бизнес-правил, содержащих ключевые факты об изменяемых настройках

Порядок правил с назначением «Оценить» в рамках одного события

Бизнес-правила одного события выполняются в той же последовательности, в которой они присвоены данному событию. И единственным исключением тут являются правила с назначением «Документооборот», которые имеют фиксированные позиции в рамках событий «Сохранение» и «Удаление».

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

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

И наоборот, бизнес-правила с назначением «Оценить» часто выстраивают в цепочки по типу «поставщик-потребитель», что применимо только к событиям «По изменению поля» и «Сохранение».

На Рисунке 3 показан пример подобного события с шестью бизнес-правилами, сгруппированными в три относительные позиции.

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

Если вы выстраиваете бизнес-правила в цепочки по типу «поставщик-потребитель», то рекомендуется указывать в поле «Имя правила» порядок выполнения каждого правила (т.е. относительную позицию). Как показано на Рисунке 3, удобно использовать шаг 10 или более для нумерации относительных позиций, чтобы не приходилось перенумеровывать старые относительные позиции по мере добавления новых промежуточных позиций.

Рисунок 3. Пример, когда шесть бизнес-правил сгруппированы в три относительные позиции

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