Советы по разработке оптимальных бизнес-процессов

На партнерском форуме в 2007 году Натальей Евдокимовой был сделан доклад на тему оптимальной разработки бизнес-процессов. Данная тема периодически всплывает в запросах в службу ТП. И я решил поднять его, немного дополнив.


Как это работает.
Модуль "Управление процессами" функционально состоит из двух частей: сервиса DocsVision Workflow Service, и процесса ExecLogic.exe. Сервис осуществляет подготовку процесса к запуску и другие системные операции. ExecLogic.exe непосредственно выполняет функции. Если посмотреть загрузку процессора через Performance Monitor, то можно увидеть, что нагрузка идет пиками.

Происходит это потому, что ExecLogic обрабатывает пакеты функций не постоянно, а периодами - тиками. Последовательность действий такова.

• Построение списка активных процессов
• Сортировка процессов по приоритетам
• Исполнение процессов по приоритетам
• Проверка нормативного времени тика
  

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

• Наивысший (процесс гарантированно обрабатывается каждый тик)
• Высокий (процесс гарантированно обрабатывается каждый третий тик)
• Обычный (процесс гарантированно обрабатывается каждый пятый тик)
• Низкий (процесс гарантированно обрабатывается каждый седьмой тик)
• Самый низкий (процесс гарантированно обрабатывается каждый девятый тик)

Слово «гарантированно» не означает то, что процесс с приоритетом «Обычный» будет обрабатываться только на каждый третий тик: в случае, если не будет процессов с более высоким приоритетом он может быть обработан и раньше, хотя бы каждый тик, как процесс с наивысшим приоритетом.
С введением приоритизации связано введение возможности ограничения времени тика . Этот параметр можно указать в консоли настройки, задается в секундах. Этот параметр задает промежуток времени, при превышении которого обработка процессов прекращается и начинается ожидание следующего тика. На практике реальное время тика может быть несколько выше введенного желаемого. Это связано с тем, что некоторые могут выполняться довольно продолжительное (а самое главное совершенно непредсказуемое по длительности) время, причем прерывать их выполнение Workflow не имеет права. Также, тик может выполняться дольше чем хотелось бы в случае, если в системе присутствует большое количество процессов с наивысшим приоритетом (или приравненных к ним): тик не прерывается до тех пор пока не будут обработаны все процессы с наивысшим приоритетом. К процессам приравненным к процессам с наивысшим приоритетом относятся процессы для которых подошло время их гарантированной обработки (каждый третий тик для обычного приоритета и так далее…).

Параметрами обработки можно управлять. Назначение и подробное описание приведено в статье http://dvprofessionals.blogspot.com/2009/08/workflow.html

Немного о функциях.
Условно функции можно разделить на 3 группы:

1. Функции, которые работают с данными в базе: мониторинг, универсальный обмен, и т.п. Таких большинство.
   
2. Функции, которые работают со внешними системами: мониторинг 1С, CRM и т.д
3. Функции, который работают только на стороне Workflow: объединение, разветвление, сценарий (в некоторых случаях)
   

Понятно, что основную роль в производительности может играть отклик сервера DocsVision.

Как правильно стоить схему процесса.
 Операции получения данных и преобразования переменных следует объединить в одну функцию универсального обмена данными
Неправильно:

Правильно:

К свойству нужно обращаться по имени, а не по индексу.
Не правильно:

Правильно:

Необходимо делать параллельные ветки, там где это возможно.
Не оптимально:

Оптимально:

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

У циклических процессов, которые работают постоянно, отключайте ведение журнала. А так же удаляйте все завершенные подпроцессы. Настроить автоматическое удаление можно в свойствах процесса, на вкладке "Дополнительно", по кнопке "Завершение процесса".

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

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

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


Конец. Внимание опрос. Есть желание написать подробно, как читать сообщения в журнале Workflow. Но поскольку в версии 4.3 структура журнала поменялась, то нужно делать два описания, либо под какую-то наиболее актуальную версию. Вопрос в том, какая версия для вас актуальна: 4.3. или все, что раньше?

Читать дальше