RSS Подписка на статьи RSS Подписка на комментарии Панель инструментов

Блог профессионалов стал частью сайта технической поддержки DocsVision http://support.docsvision.com. Новые материалы будут появляться уже на этом сайте.

Поиск

Ярлыки

авто генерация кода (1) Администрирование DocsVision (60) Атрибутивный поиск (3) База данных (24) Базы знаний (1) Безопасность (1) Бизнес-процессы (20) Блог (2) Вы увидите это первыми (1) Групповые политики (1) Диаграммы (2) Задания (2) Интеграция (2) Карточки DocsVision (14) Конструктор Решений (11) Маркетинг и продажи (4) Навигатор (3) Новое (3) Новости (32) Опрос (4) Опросы DocsVision (4) Оптимизация (3) Отчеты (2) Ошибки (1) Поддержка (14) Полезные ссылки (1) Представления (4) Производительность (5) Разбор полетов (18) Разработка для Workflow (7) разработка карточек (2) Разработка на платформе DocsVision (41) Разработка решений (43) Расширение платформы (1) Расширенные отчеты (9) Решения на платформе DocsVision (6) Сервисы DocsVision (3) Сканеры (3) Справочник сотрудников (1) Справочник типов (1) Установка (1) Утилиты (13) Шлюз в SharePoint (8) Штрихкод (2) Cкрипты карточек (7) DocsVision внутри (1) DocsVision Live (1) FileStream (1) FireFox (2) Opera (1) Powershell (5) Safari (1) SharePoint2007 (1) SharePoint2010 (2) Silverlight (1) UltraViews (1) Vista (1)

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

На партнерском форуме в 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. или все, что раньше?

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

8 коммент.:

Unknown комментирует...

Пишите про 4.3, все там рано или поздно будем :)

Eugene Barmin комментирует...

DV 4.3 актуальна почти всегда, т.к. даже "старые" проекты стараемся развивать и переводить на актуальные версии DV.

sergejh комментирует...

Тем не менее, на 4.1 еще можем быть и месяц, и два и три.
Спасибо за советы, может быть полезно.

Irhen комментирует...

Спасибо за статью.
Про журнал workflow: для версии 4.1 тоже было бы полезно увидеть описание, т.к. действительно переводиться в ближайшее время будут не все проекты. А кто-то ещё и на 4.0 пока остаётся.
И ещё: у вас в пункте "К свойству нужно обращаться по имени, а не по индексу" два одинаковых скриншота для правильного и неправильного вариантов.

Михаил Захаров комментирует...

Спасибо, сейчас исправлю.

Ice комментирует...

Да, производительность Workflow - это очень больной вопрос... такие статьи однозначно нужны. Михаил, а можете объяснить, почему всё-таки сценарии в БП обрабатываются быстрее сервером Workflow и создают меньшую нагрузку, чем кубики? Кубики же по сути генерируются также в код на сервере Workflow. Имеет, например, смысл заменять одним сценарием один кубик унифункции или один кубик унив. обмена? Или эффект есть только когда одним сценарием заменяется много кубиков? Всё это происходит за счёт того, что каждый кубик отдельно обрабатывается на сервере. А один сценарий всегда выполняется за один тик, каким бы длинным он ни был? А кубик мониторинга имеет смысл заменять кубиком сценария. И там и там поисковый запрос... Ответьте, пожалуйста, вопрос очень актуален.

Михаил Захаров комментирует...

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

1. Сценарий выполняется быстрее обычной ф-ции не во всех случаях. В основном, когда в сценарии сделано "мультидействие", например в цикле перебирается коллекция. В обычном случае цикл получения элементов коллекции и их обработка занимает несколько кубиков

2. Функции - кубики могут обрабатываться в несколько потоков одновременно.

3. Кубик мониторинга заменять на сценарий нет смысла.

redzmey комментирует...

а можете привести пример как правильно искать запись универсального справочника из определенной ветки по названию записи?

Отправить комментарий