Механизмы обработки ошибок при менеджменте бизнес-процессов с помощью BPM-системы ActiveVOS

Жмайлов Б.Б.
кафедра "Управление качеством", ДГТУ
докторант
Ростов-на-Дону

Кочнев С.В.
кафедра "Управление качеством", ДГТУ
инженер
Ростов-на-Дону

Введение

С обработкой исключительных ситуаций сталкиваются разработчики программных систем, систем управления базами данных (СУБД) и бизнес-процессов. Особенности данных областей определяют механизмы их обработки [1, 2]. Так, например, в области СУБД основным требованием является обеспечение согласованности данных. Это достигается с помощью механизмов журнализации и транзакций. Зачастую в целях повышения производительности игнорируется причина, повлекшая к появлению исключения. В области программирования стремятся по возможности точно ее определить и, в зависимости от нее, разрабатывают собственные обработчики, создавая, таким образом, устойчивые программы, толерантные к ошибкам. Для систем менеджмента бизнес-процессов существуют свои особенности. Поэтому целью данной статьи является обзор способов и описание особенностей обработки исключительных ситуаций с помощью системы управления бизнес-процессами (BPM-система) ActiveVOS.

Характеристика предметной области

К особенностям бизнес-процессов относится следующее:

1. бизнес-процесс может выполняться в течении длительного периода времени, который фактически не ограничен – месяц, год и т.д.;
2. не всегда, динамически, в ходе выполнения бизнес-процесса, можно получить причину исключения;
3. за один рабочий цикл (неделимую операцию-транзакцию) может осуществляться вызов нескольких методов Web-сервисов различных систем;
4. бизнес-процесс может оперировать большими объемами данных, потеря которых нежелательна.

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

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

Логика работы механизма компенсаций представлена на Рисунке 1. Компонент обработчика событий "OnEvent" получает сообщение об отмене заказа и передает его обработчику ошибок "CatchAll", который применяет механизм компенсации на ранее выполненные участки процесса, связанные с ним. Обработчик компенсации "Compensation" завершает откат работы сервиса "InvokeOrderInventory", вызывая метод "CancelOrderInventory" и отправку уведомления об отмене "ReplayCancelOrder". Все действия возвращаются в первоначальное состояние только в тех местах процесса, к которым был применен механизм компенсации.

Рисунок 1. Логика работы механизма компенсаций: 1 – обработчик событий; 2 – обработчик ошибок; 3 – область, для которой определен механизм компенсации

Как видно из Рисунка 1, обработка компенсаций связана с определенной областью "ScopeOneA". Эту область можно рассматривать как логическую единицу работы с заданным набором действий бизнес-процесса, которым требуется "откат" в первоначальное состояние и повторное выполнение, в то время как другие части процесса могут продолжать работать в обычном режиме.

В отличие от обработки компенсаций, обработчик ошибок незамедлительно срабатывает при возникновении исключительной ситуации. Обработчик исключений в BPEL-процессе останавливает выполнение той его области, с которой он связан, отменяя при этом все действия, которые были выполнены до ее появления.

К причинам возникновения исключительной ситуации можно отнести следующие:
• Операция веб-сервиса не может быть успешно завершена и возвращает ошибку;
• Внутренняя ошибка, которая произошла в самом процессе. Для ее идентификации можно использовать список стандартных BPEL ошибок;
• Действие <throw> или <rethrow> выдало ошибку.

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

Следует заметить, что отсутствует возможность реализации механизма компенсаций в области, на которую ссылается обработчик ошибок. В бизнес-процессе можно определить два типа обработчиков ошибок:

• "catch", который определяет набор пользовательских правил обработки ошибок, составленных на основе ее имени и/или переменной. Если имя отсутствует, то возможно перехватывать ошибки с определенным типом данных;
• "catchAll", который выполняется, если с помощью "catch" не удалось выявить каких-либо ошибок;

Пример реализации обработчика ошибок типа "catchAll" в бизнес-процессе для определенной его области представлен на Рисунке 2.

Рисунок 2. Реализация обработчика ошибок типа "catchAll"

Спецификация политики веб-сервисов позволяет их поставщикам и клиентам использовать возможность добавления стандартной политики для обработки исключительной ситуации. В бизнес-процесс возможно добавить одну или несколько таких политик [3]. Другими словами, в бизнес-процессе устанавливается связь между методами используемого внешнего Web-сервиса и способом обработки исключительной ситуации, которая может возникнуть при его вызове. Таким образом формируется политика правил обработки. Существует перечень стандартных политик правил обработки, которые поддерживаются BPM-системой ActiveVOS.

Рисунок 3. Бизнес-процесс обработки исключительной ситуации

Одним из эффективных, на наш взгляд, правилом является правило повторений. При этом можно указать интервал времени, через который будет осуществлен повторный вызов метода и количество этих повторений. Кроме того можно указать процесс, который будет вызываться при возникновении исключительной ситуации, в который можно передавать описание ее причины возникновения (Рис. 3). При инициализации данного процесса (метод "RecievRetryCheck"), на его вход поступает сообщение об ошибке, возникшее в методе, для которого установлено данное правило. Далее выполняется формирование письма (действие "PrepareEmail") и его отсылка заинтересованным лицам с помощью метода "SendStaffEmail". В нем указывается причина возникновения ошибки. После чего устанавливаются параметры правил повторений (действие "DoRetryLogic_CreateResponse"), которые возвращаются в основной процесс с помощью метода "ReplyRetryCheck". В качестве параметров повторений в данном случае указывается, что метод, при вызове которого возникла ошибка, необходимо повторять через 30 секунд. Фрагмент кода на языке BPEL для указания параметров повторений процесса:

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

Заключение

Таким образом, в BPM-системе ActiveVOS реализована возможность использования нескольких способов обработки исключительных ситуаций, возникающих при выполнении бизнес-процесса. Использование того или иного механизма определяется конкретными особенностями как самой ошибки так и эксплуатационными требованиями. Например, наш опыт промышленной эксплуатации такой системы, в случае когда необходимо вызывать в рамках одного процесса метод для вставки или обновления тысяч новых записей в СУБД в режиме реального времени показывает, что целесообразно использовать обработчик ошибок, организуя при этом несколько циклов для повторения процессов множественной вставки/обновления данных. Такой подход позволяет внести за первую итерацию цикла основную массу записей, а последующие итерации выполняются только в том случае, если на первой возникли ошибки, обеспечивая тем самым минимальное время выполнения процесса. Когда же в процессе используется важная информация и обеспечение режима реального времени не является обязательным, на наш взгляд необходимо использовать политику правил, реализуя стратегию повторений, что позволяет организовать надежное выполнение методов используемого сервиса.

Литература

1. Х.М.Дейтел, П.Дж.Дейтел Как программировать на Java: Книга 2. Файлы, сети, базы данных //-М.: Бином-Пресс, 2005 г., 664 с.
2. Эккель Б. Философия Java //-СПб: Питер 2009, 640 с.
3. ActiveVOS Designer User’s Guide Active Endpoints, 2004-2009 (Дизайнер ActiveVOS, руководство пользователя)

Copyright © 2010 Димитров В.П., Жмайлов Б.Б., Кочнев С.В.