Интересно для всех

Джерри Айрленд

Введение в Workflow
(Introduction to Workflow,
by Jerry Ireland, Rightsizing, Inc.)

Источник: доклад на форуме Open World, San Francisco, 2004, https://www.openworld2004.com/published/1041/1041_Ireland.doc

Механизм Workflow (последовательность выполняемых действий, автоматизация документооборота – словарь Lingvo) стал настолько неотъемлемой частью Oracle Applications E-Business Suite, что почти невозможно реализовать Applications без того, чтобы так не сделать несколько простых модификаций некоторых последовательностей выполняемых действий. Эта статья предоставляет описание основных компонентов workflow вместе с детальной информацией об объектах, которые составляют этот механизм. В презентации (https://www.openworld2004.com/published/1041/1041_Ireland.ppt) этого доклада показано построение с нуля законченного workflow-процесса при помощи программного средства workflow builder.

Компоненты Workflow.

Механизм (Workflow Engine)

Механизм workflow обеспечивает управление выполнением бизнес-процессов. Процессы могут быть выполнены в непосредственном или в фоновом режиме. В непосредственном режиме выполняется каждый этап, и процесс автоматически переходит к каждому следующему этапу. Для процессов, выполняемых дольше остальных, workflow может выполнять этапы в фоновом режиме. В этом режиме этап ждет, пока менеджер параллельного процесса не увидит его готовность к обработке. Этапы могут быть явным образом переключены в фоновый режим, или же они могут перемещаться в фоновый режим в зависимости от их “веса”. Значение “веса” может быть присвоено каждому из этапов произвольно. Опция профиля может установить workflow-порог для определения, какие из этапов выполнены в фоновом режиме.

Механизм workflow генерирует 100% аудит-данные. Начальное время, конечное время и статус каждого этапа в workflow-процессе сохраняются в оперативных журнальных (log) таблицах. Эти таблицы могут быть запрошены для получения информации о ходе выполнении любого процесса или для определения, какой этап выполняется в настоящий момент. Эти таблицы могут расти очень быстро, и требуется установка политики очистки дискового пространства для эффективности использования диска и повышения производительности workflow-процесса.

В одно и то же время могут быть задействованы несколько версий процесса. Когда процесс изменяется, новая версия сохраняется в базе данных с датой его вступления в силу. Любые процессы, выполняемые в тот момент, когда новая версия вступает в силу, продолжат свою работу с той версией, с какой они эту работу начали. А любые новые процессы начнут использовать уже новую версию. Это дает возможность выполнения новых действий, не переделывая пункты активных работ.

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

Монитор (Monitor)

Workflow-монитор обеспечивает быстрое краткое изложение ключевых активных в данный момент действий. В зависимости от обязанностей пользователя, он может легко проверять статус всех workflow-процессов. Это может быть сделано с помощью просмотра списка действий или диаграммs workflow-процессов, как показано далее. На диаграмме рассмативаемый путь подсвечен зеленым, так что легко видеть, какой конкретный экеземпляр workflow управляет процессом и какой этап выполняется в настоящее время.

Уведомления (Notifications)

Уведомления могут использоваться, чтобы автоматически войти в контакт с пользователями для предупреждения его об исключительной ситуации или для получения ответа в случае невозможности разрешения без человеческого участия. Уведомления можно рассылать по индивидуальным или по workflow-ролевым адресатам. Роли workflow-процесса не надо путать с ролями базы данных, хотя они используются аналогичным образом. Они делают легким изменение участников без изменения самого процесса.

Система уведомлений включает механизм Automatic Notification Forwarding для автоматической рассылки уведомлений. Он пользуется правилами, которые установлены для отправки уведомлений в случаях, когда пользователь недоступен (отпуск, пропуск по болезни). Он также позволяет пользователю передать задачу кому-либо еще.

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

Сервисы каталога (Directory Services)

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

• WF_USERS – Users, Customer Contacts, Local Users (Пользователи, Клиентские Контакты, Локальные Пользователи)
• WF_ROLES – Users, Responsibilities, Positions, Engineering Approval Lists, Local Roles (Пользователи, Обязанности, Позиции, Списки Технических Соглашений, Локальные Роли)
• WF_USER_ROLES - Users of Responsibilities, Employees in Positions, Employees in Eng Approval Lists, Local User Roles (Обязанности Пользователей, Позиции Служащих, Служащие в Списках Технических Соглашений, Локальные Роли Пользователей)

Эти представления содержат информацию от многих различных прикладных модулях. Это делает возможным использование в своих интересах множество иерархий и ролей базовых обязанностей, которые определены по всей системе. Представление также включает “Local” таблицы, и, таким образом, могут использоваться все списки получателей уведомлений.

Бизнес-События (Business Events)

Система бизнес-событий предназначена для того, чтобы после свершения события предпринять конкаретные действия. В некоторых определенных местах бизнес-процесса происходят события. Другие процессы, такие как PL/SQL-процедуры или workflow-процессы, могут быть подписаны на эти события. Если события происходят, процессы выполняются. Это обеспечивает надежный способ выполнения определенных действий без изменения стандартного кода. С каждым новым релизом вводится все большее и большее число бизнес-событий.

Загрузчик (Loader)

Загрузчик используется для перемещения описания workflow-процесса от файла формата *.wft в базу данных. Построитель Workflow Builder использует его для связи с базой данных, или же Загрузчик может быть использован из командной строки.

Построитель (Workflow Builder)

Workflow Builder - это программное обеспечение клиента, используемое для графического определения и изменения workflow-процессов.

Экран Workflow Builder разделен две части: дерево навигатора, которое дает иерархическое представление различных объектов, которые составляют workflow-процесс и диаграммер, который использует графический метод управления и просмотра процессов. Окна свойств используются для детального рассмотрения каждого объекта workflow-процесса. Эти объекты собираются в папки, названные datastores. Datastore называют или именем wft-файла, который вмещает объекты, или именем связи базы данных, используемой для извлечения из нее объектов. Каждый из объектов в пределах datastore организован с помощью Item Types (Тип элемента). Все объекты определяются тремя параметрами – внутренним именем (internal name), отображаемым именем (display name) и описанием (description). Внутреннее имя – набор символов на верхнем регистре без двоеточий и конечных пробелов. Оно используется в таблицах базы данных, API и в PL/SQL-кодах для идентификации объекта. Внутренние имена неизменяемы с момента создания объектов. Отображаемое имя – это пользовательский вариант имени, используемый монитором и любым списком значений приложениях. Описание применятся строго для внутреннего использования, таких как документация.

Тип элемента (Item Type)

Все другие объекты определены типами элементов. Типы элементов обычно организуются, исходя из ключевых элементов базы данных, таких как, заголовок заказа, строка заказа и т.д.

Internal Name – ограничено 8 символами. Оно повсеместно используется в базе данных как часть уникальной идентификации объекта. Поэтому хороший вариант внутреннего имени - как можно малое имя для уменьшения хранения. Даже небольшая экономия на внутреннем имени для типа элемента поможет сэкономить приличное место в базе данных, поскольку оно многокротно используется.

Persistence Type – определяет отрезок времени, в течении которого сохраняются текущие (runtime) данные:

Selector –PL/SQL-процедура, которая вызывается, когда инициализирован тип элемента процесса. Если тип элемента имеет или будет иметь более одного процесса, связанного с ним, следует определить PL/SQL-процедуру, которая будет определять, в какой ситуации какой процесс запустить. Например, у вас есть два различных процесса подтверждения предписаний, связанных с одним и тем же типом элемента. Процесс, который выполняет Oracle Workflow, может различаться в зависимости от того, как и где возникло предписание. Ваша selector-функция может определить, какой процесс будет соответствовать определенной ситуации. Процедура может также быть использована для инициализации атрибутов и определения контекстной информации для соединения с формами и другими процессами.

Построение Блоков(Building Blocks)

Есть несколько стандартных блоков, используемых в workflow-процессе. Они не появляются на процессной диаграмме, но используются для построения и определения совершаемых процессов. Стандартные блоки не версионны. Они всегда записываются по предыдущей версии (об этом позже).

Атрибуты (Attributes)

Атрибуты - это свойства, связанные с данным типом элемента. Они похожи на глобальные переменные, которые могут быть обновлены/упомянуты в Функциях (Functions) и Сообщениях (Messages). Они также используются для передачи данных от процесса к процессу. PL/SQL API могут управлять этими атрибутами. Атрибуты сохраняются в текущих (runtime) таблицах.

Атрибуты также могут быть определены в пределах контекста Функций и Сообщений.

Type – определяет категорию любого атрибута – текст, номер, данные, форма, URL, … Каждый тип может также иметь дополнительный параметр, такой как, номер формата или длина текста.

Default Value (значение по умолчанию) – может быть установлено для некоторых начальных значений.

Справочные Типы (Lookup Types)

Справочные Типы - это статические списки значений. Они используются для определения результатов, возвращаемых процессами, уведомлениями и функциями.

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

Многие справочные типы предопределены в Standard Item Type. Многие из них отражают стандартные списки значений прикладных модулей.

Справочный Код (Lookup Code)

Справочные коды определяют список значений для Справочных Типов.

Сообщения (Messages)

Пользователь просматривает Сообщения через страницу уведомлений или электронную почту. Сообщения могут требовать ответа или просто предоставлять информацию. Сообщение должно быть присоединено к уведомлению для использования в процессе.

Priority – не затрагивает обработку или поставку сообщений.

Тело сообщения определяет содержание сообщения. Оно может быть отформатировано в текстовом или в HTML формате. Если в HTML Body остается пустым, то при применении формата HTML используется Text Body. В HTML Body могут быть вставлены команды форматирования HTML.

Атрибуты сообщения могут использоваться в тексте, и значение атрибута может изменятся в процессе выполнения. Используйте внутреннее имя атрибута, определенное с помощью префикса & для ссылки на атрибут.

Сообщение ограничено 4000 байтами или 32,000 при замене атрибутов.

Subject – значение по умолчанию для Display Name, но оно может быть изменено.

Результат Сообщения (Message Result)

Результат сообщения должен быть определен всякий раз, когда уведомление, к которому оно присоединено, ожидает результат. Internal Name становится RESULT.

Lookup Type – должен быть тем же самым, поскольку используется в определении Notification Result Type.

Default – может быть установлено или на постоянное значение или на значение атрибута Item Type.

Атрибуты Сообщений (Messages Attributes)

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

Параметры те же что и атрибут Item Type с дополнительным параметром Source, который определяет, используется ли атрибут для Send или Respond.

Внутреннее имя ‘RESULT’ зарезервировано для результата сообщения. Внутреннее имя для атрибута ‘Respond’ должно соответствовать имени атрибута объекта.

Атрибуты сообщения наиболее часто используют Lookup Types и Item Attributes. Копируйте атрибуты объекта так часто, как только возможно.

Описания атрибутов ‘Respond’ отображаются, как инструкции для конечного пользователя, и должны описывать, как с точки зрения пользователя, должен быть введен ответ.

Действия (Activities)

Действия workflow-процесса - это узловые точки в определении процесса. Каждая точка имеет окно свойств, связанное с ней, также как и у других объектов. Все они имеют дополнительный параметр Icon для определения изображения на процессных диаграммах. Заданное по умолчанию изображение существует для каждого типа действий. Есть еще много поддерживаемых значков для выбора, а также могут использоваться дополнительные заказные значки.

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

Множественные версии деятельности могут быть сохранены в базе данных, так что отдельные версии деятельности могут быть активны в любое данное время. Версии детально будут рассмотрены позже.

Уведомления (Notifications)

Уведомления используются, чтобы послать сообщения.

Function Name (Имя функции)– эту процедуру вызывают, чтобы выполнить специальную обработку, когда сообщение отправлено, передано или отвечено. Это можно использовать для фильтрации, какое уведомление отправлено, или для процесса голосования, или дальнейшей проверки правильности ответа.

Function Type (Тип Функции) – PL/SQL, External, External Java

Result Type (Тип Результата) – выбирает справочный тип, который обеспечивает соответствующие справочные коды для желательного ответа на данное уведомление. Оставьте его пустым, если никакого ответа не требуется.

Message (Сообщение) – объект сообщения с содержанием для отправки.

Expand Roles (Расширения Ролей) – если это выбрано, то будет отослано отдельное уведомление каждому участнику роли. Иначе посылается только одно уведомление.

Performer (Исполнитель) – является получателем сообщения. Может определятся постоянным сообщением или атрибутом объекта типа Role. Исполнитель находится на вкладке Node и применим для уведомлений.

Timeout (время ожидания) – должен быть установлен на вкладке Node, если workflow-процесс НЕ ДОЛЖЕН продолжаться без ответа.

Функции (Functions)

Функция выполняет PL/SQL-процедуру или вызывает внешнюю функцию. Могут быть определены атрибуты деятельности, чтобы передать глобальную информацию в/из процедуры.

Function Name (Имя функции) – процедура, которая будет вызвана этой деятельностью

Function Type (Тип функции)– Pl/SQL, External, External Java

Result Type (Тип Результата) – выбирает справочный тип, который обеспечивает соответствующие справочные коды для желательного ответа на данное уведомление. Оставьте его пустым, если никакого ответа не требуется. Возвращаемое значение обеспечивает возможность перехода в процессе.

Cost (Стоимость) – является относительным числом для индикации того, как много процессов будут запущены при вызове процедуры. Если значение больше чем “Threshold” (по умолчанию 50), то процедура будет выполняться в фоновом режиме.

Процессы (Processes)

Процесс – графическое представление делового процесса – “The pretty diagram”. Показывает функции, уведомления и подпроцессы.

Runnable (Работоспособный) – указывает, что этот процесс может быть инициализирован, как процесс верхнего уровня и выполнен независимо. Должно быть без контроля типов для подпроцесса, вызванного другим процессом.

Узел (Node Tab)

Закладка узла используется для доступа к информации об определенном образце деятельности в пределах процесса.

Lable (Метка) – внутреннее имя этого узла. Имя может использоваться для определения действия в пределах данного процесса. Используется некоторыми API.

Start/End (Начало/Завершение) – используется для определения является ли узел первым (Start), последним (End) или внутренным (Normal) узлом процесса. Любой узел может быть и начальным, и конечным узлом. Это не те стандартные функции Start и End, которые тявляются NOOP (пустыми командами).

Comment (Комментарий) – только для внутренней документации

Timeout (Время ожидания) – может быть установлен для действия. Если достигнут указанный timeout, то действие заканчивается и возвращается с результатом по timeout.

Time Type (тип времени) –

Relative (относительный) – определяет дни, часы и минуты

Priority и Performer (Приоритет и Исполнитель) – применимы только к уведомлениям

Атрибуты Узла (Node Attributes)

Все атрибуты, определенные для деятельности, показаны списком внизу закладки Node Attributes. Для этих атрибутов могут быть установлены значения, так что для вызванной процедуры они будут доступны. Атрибут может быть выбран с использованием раскрывающегося списка Name или нажатием по атрибуту из списка. Значение может быть введено, как константа Type или Item Attribute. Введите Value для константы или имя Item Attribute. В раскрывающемся списке будут показаны только Item Attributes правильных типов. Если тип Node Attribute справочный (Lookup), то поле значения обеспечит раскрывающийся список, соответствующий справочным кодам.

Переходы Между Действиями

Нажатие правой кнопкой мыши на действие (activity), удерживание нажатой кнопки и перемещение к следующему действию создает переход между действиями. Если первое действие определило результат, выберите значение, чтобы определить, продолжится ли процесс на этом пути. Есть несколько специальных значений результата, которые могут быть использованы.

• Default (по умолчанию) – этот путь выбран для возвращения значений, для которых не был задан определенный путь
• Any (Любой) – этот путь будет выбран, независимо от значения результата
• Timeout (по истечении времени ожидания) – этот путь будет назначен, если был определен timeout и время ожидания уже истекло.

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

Обработка Ошибок (Error Processing)

Обработка ошибок может быть определена на уровне процесса и отменена на уровне Функции (Function) или Уведомления (Notification). Это определяется на закладке Detail для действия, используя поля Error Item Type (тип ошибки элемента) и Error Process (ошибочный процесс). Эти два поля определяют внутреннее имя workflow-процесса, который должен быть выполнен в случае возникновения ошибки. Далее представлены workflow-процессы обработки ошибок:

• DEFAULT_ERROR – заданный по умолчанию процесс обработки ошибок, выполняемый, когда не определен ни один другой workflow-процесс
• RETRY_ONLY – делает повторение
• DEFAULT_EVENT_ERROR – заданный по умолчанию процесс обработки ошибок событий

Существует возможность модификации этих workflow-процессов для изменения поведения по умолчанию при обработке ошибок для всех действий.

Сохранение определений на ПК (Save definition to PC)

Как только были созданы объекты для workflow-процесса, данные могут быть сохранены на ПК в локальном системном файле, например, в файле *.wft. Просто введите директорию и имя файла или воспользуйтесь кнопкой Browse. Сохранение вызовет проверку правильности определения workflow-процесса. Обычно встречающиеся ошибки запутывают беспомощного исполнителя уведомлениями или неопределенными атрибутами действий.

Для просмотра реальной ошибки нажмите на “+”, чтобы развернуть сообщение. Некоторые ошибки могут быть легко исправлены, а некоторые могут потребовать большого количество технической работы.

Нажмите кнопку Save для сохранения работы.

Workflow-процессы могут быть сохранены на диск ПК с ошибками.

Эти ошибки должны быть исправлены и PL/SQL-процедуры должны быть переписаны, прежде чем workflow-процессы будут записаны в базу данных.

Сохранение в Базе Данных (Save to the Database)

Щелкните по кнопке Database, чтобы открыть поля базы данных. Ведите User, Passoword и Connect – строку соединения с базой данных. Поле Effective предназначено для будущих расширений. Workflow-процесс обеспечивает разные версии, и данные Effective будут определены, когда будет задействована новая версия.

Workflow-процессы сохраняются в базе данных в двух различных режимах. Чтобы определить, какой режим надо использовать, откройте диалоговое окно Help в меню ‘About Oracle Workflow Builder’ (“О построителе Oracle Workflow”). Если значение ‘Allow modifications of customized objects’ (“Разрешить модификацию настроенных объектов”) закрыто, то по ‘Save’ (“Сохранить”) переписываются защищенные объекты с присвоением соответствующих значений доступа. Также перезаписываются все ранее настроенные объекты. Если ‘Allow modifications of customized objects’ не запрещено, то ‘Save’ будет работать в режиме ‘upgrade’ (“обновление”). В этом случае workflow-процесс сохраняет отредактированные версии защищенных объектов, присваивая соответствующий уровень доступа, и не переписывает ранее настроенные объекты.

Versioning (Контроль Версий)

Множественные версии всех объектов деятельности могут быть сохранены в базе данных с различными фактическими датами. Любые экземпляры workflow-процессов, которые являются активными в момент, когда новая версия становится вступает в силу, продолжат свою работу с использованием той версии, с которой они начинали. А все новые экземпляры начнут использовать новую версию. При надлежащей осторожности это может позволить гладко заменить одну версию на другую. Проблемы возникают, когда изменения происходят с объектами, не поддерживающими множества версий – все объекты Building Block и PL/SQL-процедуры, вызываемые workflow-процессами. Например, если установлена новая PL/SQL-процедура и если она использует новый атрибут объекта, то все предыдущие версии будут ошибочны, так как новый атрибут не был проинициализирован при старте workflow-процесса. Или запуск скрипта инициализации нового атрибута может вызвать эту специфическую проблему у всех активных workflow- и обнаруживающих ошибки или инициализирующих атрибуты на лету процессов.

Об Авторе

Jerry Ireland (jerryi@rsiz.com) – соучредитель Rightsizing Inc., консалтинговой фирмы, специализирующейся на Oracle и Oracle E-Buisiness Suite. Он имеет более чем 23 летний опыт работы с Oracle. Он был в числе директоров Oracle Development Tools User Group (сокращенно OCSIG) с момента ее зарождения и много лет был связан с Oracle Applications User Group (OAUG). Jerry был председателем нескольких конференций ODTUG, его часто приглашают в роли спикера и члена комиссий конференций ODTUG и OAUG. Mr. Ireland признан в качестве ведущего архитектора и разработчика высокоэффективных приложений Oracle. Jerry также участвовал во встречах комитетов Very Large Database (VLDB) и Massive Open System Environment Standards (MOSES).