Workflow Policy (далее WFP) — довольно сложный инструмент. Но при этом он очень полезный и любой уважающий себя Seibelman должен уметь им пользоваться. В данной статье я постараюсь рассказать про этого зверя более простым языком (как минимум по-русски), нежели это описано в документации к системе.

Самая простая аналогия WFP из большинства известных конструкций — это триггеры базы данных. На самом деле WFP и является набором триггеров, но об этом позже. Что такое триггер? Можно получить ответ на вопрос, обратившись к Википедии, но кратко говоря — это обработка некого события в базе данных, например вставка записи, удаление записи, изменение записи. При наступлении определенного события можно написать свой обработчик. В прочем я уверен все это и так знают, а кто не знал, тот уже прочитал на wiki.

Мне очень нравится краткое определение WFP из bookshelf:

 Модуль Workflow Policy позволяет задавать правила, которые могут вызывать workflow процесс. Правило состоит из одного или более условий. Когда данные условия выполняются — запускаются действия для данного правила

Иначе говоря мы можем, подобно триггерам, мониторить значения конкретных столбцов конкретных таблиц и выполнять ряд действий при изменении, добавлении или удалении значений в этих столбцах. Весь модуль WFP настраивается в разных местах. Начнем с объектов, которые определяются в тулзах.

Workflow Policy Column

Этот объект Вы найдете в Siebel Tools в дереве объектов. Суть очень проста. В этот список заносятся столбцы таблиц, изменение которых мы сможем мониторить. Атрибуты: название, проект, имя таблицы и имя столбца.

Workflow Policy Object (WPO), Workflow Policy Component (WPC), Workflow Policy Component Column (WPCC)

Все эти понятия очень похожи на бизнес объект, бизнес компонент, поля бизнес компонента. WPO объединяет в себе набор WPC, связанных между собой. Один из WPC — главный. Каждый WPC состоит из набора WPCC — колонок, которые выбираются из описанных выше Workflow Policy Column.

wfp_1

Получается структура, аналогичная бизнес объектам и их дочерним составляющим. Разница в том, что этим объекты не компилируются, хоть и настраиваются через тулзы, а это позволяет нам без кода, компиляции и остановки сервера внедрять новую функциональность в систему!

Workflow Policy Programm

Здесь определяется шабон процесса, который будет выполняться при срабатывании правила. Наиболее интересным и часто используемым является программа Run Workflow Process. А вообще тут можно создавать свои программы на любой вкус. Более подробный  материал можно посмотреть в документации.

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

В приложении переходим на экран «администрирование — бизнес процессов / Группа правил потока операций». Выглядит он примерно так:

wfp_2

 

Здесь мы создаем группу правил (или как написано в локализованном на русский язык Сибеле «Группу политик»). В саму группу уже входят конкретные правила. Создаем правило. Для его создания нужно указать название правила и объект — тот самый Workflow Policy Object, который настраивается в тулзах. Важный момент: для каждого правила мы можем задать отсрочку срабатывания. Для этого у нас есть параметры: продолжительность и единицы. Если мы выставлии продолжительность = 30 , а единицы = Minute(s), то при срабатывании какого-то правила его обработка начнется только через 30 минут. При этом если через 30 минут условия правила уже не будут выполняться, то обработки не будет! Теперь проваливаемся по ссылке в это правило и попадаем уже на такой экран:

wfp_3

 

Здесь в верхнем апплете создаются правила, а в нижнем апплете описываются условия срабатывания для каждого правила. Причем в условиях мы уже оперируем WPCC, которые также предварительно настроены в Siebel Tools. Условия пишутся довольно просто, хотя и не на нашем любимом языке выражений. Все еще проще: поле условия — это WPCC, операция — простейшие операции (операции сравнения: <,>, =, <>, >=, <=; проверки на произведенное действие: IS ADDED, IS DELETED, ID UPDATED; проверка на заполненность: IS NULL, IS NOT NULL; проверка на вхождение подстроки: LIKE, NOT LIKE; вхождение в множество: IN, NOT IN; вхождение в интервал: BETWEEN). Более подробно познакомиться с правилами построения условий можно здесь.

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

wfp_4

Здесь нужно создать запись. Название — произвольное, а вот программа — это та самая Workflow Policy Programm, описанная выше. Как я уже говорил, самая интересная — это Run Workflow Process. В тулзах определялся шаблон программы, а здесь мы уже придаем этому шаблону конкретику с помощью аргументов. В случае с Workflow мы указываем название процесса. При этом в параметр Object Id будет передаваться id той записи, в рамках изменения которой сработало правило.

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

Фухх… вроде бы все. Ага, если бы! У нас еще много впереди, но подведем промежуточный итог. Мы создали всю необходимую структуру, набор правил и обработку. Все здорово! Но даже если станцевать фламенко вокруг сервера, то работать ничего не будет.  Есть еще два важных этапа, которые нужно пройти.

Генерация триггеров

Помните, что в начале статьи я говорил: WF Policy  на самом деле и является набором триггеров. Так вот теперь  разберем этот момент подробнее. Мы задали правила и условия для их срабатывания. Но при этом должно быть нечто, которое реально бы мониторило изменение значения в конкретном поле конкретной записи. А это и есть триггер на уровне базы данных. Поэтому после создания группы политик, нам нужно эту группу применить. Для применения нужно сгенерировать триггеры. Для генерации существует специальный компонент Generate Triggers, который нужно запустить на выполнение с набором параметров:

EXEC : TRUE
Remove : FALSE
Privileged User : SIEBEL
Privileged User Password : пароль от SIEBEL

Если кто-то не совсем понимает где это делать, то объясню подробней. В тонком клиенте Siebel есть такой экрначик «Администрирование- настройка сервера / Задания». На нем мы видим конкретные задание тех или иных компонент и можем запустить какое-либо задание руками. Для этого в верхнем апплете нужно создать новую запись и ввести название компонента.wfp_5

 

Ниже нужно ввести параметры, которые я описал чуть выше. Потом нажимаем кнопку «Отправка задания» и обновляем данные в апплете, чтобы увидеть статус задания. Когда он станет «Успех», это значит, что триггеры сгенерированы. Проверить это очень просто. Заходим в базу данных в схему Siebel и ищем триггеры на те таблицы, столбцы которых использовались в условиях правил. Они должны иметь суффикс ESCL и выглядеть примерно так:

wfp_6

Мы сгенерировали триггеры! Мы крутые перцы! Но и это еще не все.. Если мы внимательно изучим сам код триггеров, то увидим, что все его действия приводят к тому,что он вставляет какие-то записи в таблицу S_ESCL_REQ. А что дальше? А дальше последний шаг.

Workflow Monitor Agent

Чтобы наконец-то наш фунционал заработал нам нужен постоянно работающий процесс, который в случае срабатывания правил будет их обрабатывать. Этот процесс реализуется компонентом Workflow Monitor Agent. Этот компонент натравливается на группу правил (workflow Policy Group) и работает только с правилами из этой группы. Создать компонент можно на экране «Администрирование — Конфигурирование Сервера / Предприятия / Определения компонентов». Стандартный монитор агент тут уже есть. Если он еще не используется, то можно взять его. Если же он занят, то создаем новый копированием существующего. Важный параметр — Group Name. Значение этого параметра должно содержать имя группы правил. Теперь перейдем на экран «Администрирование — Настройка сервера / Компоненты». Найдем наш компонент и включим его нажатием кнопки «Запуск».  Важное замечание: если Вы создали новый компонент, то обратите внимание на значение параметра «Default Tasks». По умолчанию оно равно нулю. Если его так и оставить, то даже запущенный компонент не будет работать. Его нужно установить в 1 и тогда все будет круто!

Наконец-то!!! Мы сделали все, что могли. Теперь можно проверять работу Вашего функционала. На этом настройка  Workflow Policy закончена. но есть еще одна тема, которой я уже частично коснулся. Хочу прояснить как работает этот агент.

При срабатывании триггера, как я уже писал, появляется запись в таблице S_ESCL_REQ. Таблица содержит id записи, на которую сработал триггер, id группы правил, id конкретного правила и название таблицы, триггер которой сработал. Монитор агент когда ему нечего делать спит по несколько секунд, а потом смотрит в эту таблицу не появилось ли ничего нового. Если агент видит новую запись и у данного правила есть отсрочка по времени, то он создает запись в таблице S_ESCL_STATE. Данная запись там лежит столько времени, сколько указано в правиле. По окончании времени если правило по-прежнему выполняется, то запись переносится в таблицу S_ESCL_ACTN_REQ, иначе запись просто стирается. Если же отсрочки по времени не было, то сразу создается запись в S_ESCL_ACTN_REQ. Когда запись попадает в S_ESCL_ACTN_REQ, то начинается выполнение процесса, который описан в действиях к конкретному правилу. при корректном окончании процесса агент чистит все эти таблицы. Если в таблицах скапливаются записи (в основном можно смотреть первую таблицу S_ESCL_REQ), то значит что-то идет не так и стоит проверить функционал на наличие ошибок.

Чтож, на этом статья закончена! Надеюсь эта информация была полезна! На практике я не часто видел применение WF Policy, однако я сам ее применял и очень доволен результатом. Советую и все остальным. Удачи!