Производительность и надежность Workflow в DAX2009

[db]

Имеющие опыт практического применения workflow в DAX2009 поделитесь пжл своими мыслями по след вопросу

Требуется построить процесс утверждения некоторых документов. Выбор между стандартом и разработкой своего решения без использования стандарта и WF.

1. Одновременных экземпляров процесса десятки тысяч
2. Любые зависания, запаздывания, задвоения и прочие глюки недопустимы. Всё всегда должно просто работать и не вызывать вопросов

Насколько стандарт адекватен этим условиям?

Опять же просьба обсуждать задачу именно эту техническую задачу с данными условиями, а не спрашивать зачем это надо и кто будет нажимать кнопку десятки тысяч раз

DAX2009 SP1 EE RU8

[fed]

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

1. Это очень трудно отлаживать. Приходится отлаживаться в батче, а это свои неудобства создает.Кроме того - часть кода вызывается из web service и у меня вообще не получилось его отлаживать.
2. Крайне плохо восстанавливается после ошибок. Ну то есть - если по какой-то причине у тебя в очереди застряли битые сообщения (скажем от старых версий обработчика wf или что-то подобного), то вычишать их приходится руками или специальным джобиком (мне пришлось написать). То есть - обработчик там работает так: выбирает из очереди 10 (не помню точно) сообщений и обрабатывает их (типа следующие обработаем при следующей активации). Если часть из этих сообщений битые (ну скажем - несовместимы со свежей версией обработчика wf или их родительский документ был удален или что-то подобное), эти сообщения не помечаются как обработанные, но не помечаются и как ошибочные. ПО мере того как мусор накапливается, процент нормальных (не битых) сообщений становиться все меньше и меньше и, соответственно, их шансы попасть в обработку - все меньше и меньше. Рано или поздно, workflow останавливается, потому что сообщение об утверждении доходит до следующего адресата только через 10-12 часов (остальное время wf напряженно обрабатывал битые сообщения).
3. Эээ. Счас уже точно не помню, но на ранних этапах проекта, разработчикам (еще до того как я начал этим проектом заниматься.) пришлось запретить часть проверок безопасности в пакетном обработчике WF. Они очень медленно отрабатывали при большом числе групп пользователей и сообщения, опять таки, застревали и тормозили.

Уходя от конкретики в теорию:

1. .NET WF - сам по себе странная штука. Такое ощущение что кто-то решил написать API для разработки конечных автоматов, но потом, для продвижения своих идей в MS (внутреннего PR то есть), переименовал свою систему в Workflow Engine. Хоть WF и можно использовать для автоматизации некоторых типов WF, по сути своей, это finite state automat. Число алгоритмов и ситуаций, которые действительно легче реализовать с помощью этой абстракции - достаточно мало.
2. Интеграция всего этого с Аксаптой - крайне overengineered и тяжела в изучении и понимании. Я эту поделку раз в три месяца чиню и через три месяца все заново вспоминаю - так все неортогонально и странно. Странненькое ядро .net WF было еще более странно отображено в структуры Аксапты.Явно видно, что интеграцию делали люди, которые в жизни не занимались ни одной прикладной задачей. Некоторые простейшие формы (например - список ждущих моего утверждения документов) - отсутствуют. Предполагается что пользователь должен кликать по пришедшим к нему алертам и там все утверждать. При этом из за кривости структур данных, внятная реализация таких форм относительно затруднена.
3. Ну и наконец, поскольку 2009ая не особо хорошо интегрируется с .net, отладка всего этого затруднена, а установка требует некоторых магических жестов по настройке WF-host в IIS

Краткое резюме - крайне не рекомендую.

[Ivanhoe]

Немного добавлю. В целом с большим объемом, действительно, будут проблемы. Но на паре сотен одновременных согласований работает нормально. Как плюс - настройка правил консультантом (пользователем), без программирования (в рамках реализованной модели).

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

Форма для отслеживания "моих документов для согласования" есть - Основное / Запросы / Журнал документооборотов. Там хитрая логика на форме, для не админов будут показываться только WF которые имеют отношение к пользователю.

Знаю проектов 5 на которых в целом работает и выполняет поставленные задачи. Тяжелую проверку на права везде отключали.

[trud]

На одном и проектов пришлось внедрять сию функциональность.
В итоге все конечно получилось, но после "обработки напильником". т.е. предстоит решить все проблемы о которых пишет fed.
По поводу отладки - с помощью формы tutorial_workflowProcessor можно что-то поотлаживать, в целом этого хватало
По поводу зависших сообщений - тут все просто решается модификацией. т.е. если сообщение не обрабатывается несколько раз, то просто переводим его в ошибку и в дальнейших выборках не берем. Стандартный обработчик будет его выбирать все время
По поводу скорости - переход в каждый статус это 1-2 секунды 100% работы ядра процессора на IIS(что в это время происходит, это загадка) т.е. это стоит иметь в виду при планировании мощности сервера
Следующая проблема - это то, что пакетный сервер работает минимум раз в минуту, а перевод из статуса в статус может состоять из 10 шагов к примеру(зависит от кол-ва настроек). Поэтому пришлось полностью переписывать обработчик, по следующему алгоритму - сделать группировку по экземплярам документооборота для обработки, по каждому экземпляру запустить свое пакетное задание, в котором выбирать сообщения данного экземпляра 10 раз, и по каждому запускать обработку. Это дало гарантированный переход со статуса в статус в пределах 1-2 минут
Еще одна проблема - это отчетность по документообороту - в том дереве которое есть в стандарте намешаны системные и пользовательские события, использовать его очень сложно. т.е. пришлось еще разрабатывать отчет

т.е. мое резюме - использовать все же можно, но не "из коробки". В конце мы делали нагрузочный тест, в целом все работало без сбоев
Также стоит иметь ввиду архитектурное ограничение на отсутствие мгновенности в плане смены статусов(минимум это будет 1-2 минуты). если это нужно, то стандартный документооборот не ваш выбор

[db]

Цитата:

Сообщение от trud

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

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

[trud]

ну у нас где-то 300 счетов обработалось за 15 минут. Под обработкой подразумевается шаг Начало(он самый тяжелый из всех шагов). но сам документооборот был довольно навороченным, состоял из многих subworkflow. кол-во экземпляров по сути регулировалось в параметрах АОСа - это кол-во пакетных заданий. там было что-то около 20. было вроде как по 2 ядра на АОСе и на IIS. они грузились на 100% при этом
по времени тут точно не месяца, по сути единственное что можно улучшать это обработчик, но он не очень сложный. все остальное скрыто в недрах .net. т.е. тут все днями измерялось

[fed]

Цитата:

Сообщение от Ivanhoe

Форма для отслеживания "моих документов для согласования" есть - Основное / Запросы / Журнал документооборотов. Там хитрая логика на форме, для не админов будут показываться только WF которые имеют отношение к пользователю.

Угу. Но среднестатистическому начальнику нужна формочка, в которой он может быстро просмотреть и поутверждать/поотвергать попавшие к нему документы. Мои турецкие коллеги сделали мегаформу, у которой в левой панельке список документов на утверждение, а в правой - грид с полями из специальной группы полей Workflow исходного документа, При переходе между документами разных типов, гриды с содержимым документа динамически делаются видимыми или невидимыми. В принципе этот механизм какое-то время работал, но на реальных объемах - дико тормозил и глючил (не из за WF, просто динамически создаваемые формы - нестабильны). В итоге - механизм они, кажется, заменили на более уродливый, при котором поля из той же группы полей дисплейным методом сцепляются в одну большую строку и выводятся в основном гриде. А справа вывешивается кнопочка с доступными действиями.

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

Цитата:

Сообщение от db

Насколько стандарт адекватен этим условиям?

Стандарт неадекватен сам по себе

Из практического опыта был год использования стандартного workflow с допилами.
Масса негатива от пользователей была.
Запоздалая реакция на действия пользователя, периодические зависания с пожиранием всей памяти на машине с IIS, трудоемкость поиска источников проблем.

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

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

[Narayana]

А как обстоят дела в Ax 2012?
Только собрался это внедрять и тут такой заряд "позитива"... )

[Vadik]

Цитата:

Сообщение от fed

Краткое резюме - крайне не рекомендую.

Ну зачем же людей пугать-то. У нас работает, но не на таких объемах - порядка сотни параллельных инстансов, достаточно простые процессы одобрения из 2-5 шагов, нет сотен пользователей и групп (это все у нас пока на 4.0). Написали вэб-интерфейс для массового одобрения, вэбсервис - работает вполне нормально. По сравнению с купленным когда-то аддоном для 4.0 - так вообще сказка. Не делали инагрузочного тестирования на десятках тысяч инстансов, но если люди говорят что есть проблемы с производительностью в 2009, полагаю так оно и есть
По поводу "написать свое, с блэкджеком и шлюхами" - ну, если получится что-то универсальное - молодцы, что еще сказать. Пока все что видел - какие-то неуниверсальные стремные поделки (возможно, просто не везло)
P.S. По поводу workflow в 2012 (она у нас пока в тестовой эксплуатации) - мне пока все нравится. Нагрузочное тестирование надо будет сделать кстати, хотя мы за тысячу параллельных инстансов выйти по моим ощущениям не должны
P.P.S. Понимаю что задача поставлена техническая, но можно как-то сам сценарий использования обрисовать? Если эти десятки тысяч кнопок не люди нажимают, то кто - роботы ? А зачем эти автоматические нажатия через workflow пропускать - чисто ради истории ? Тогда наверное проще сбоку что-то незамысловатое прикрутить, особенно в свете проблем с производительностью в 2009

[belugin]

В 2012 используется WF4, где, как говорят, существенно увеличили производительность. К тому же теперь не нужен IIS - он встроен, прямо в АОС. Но у меня реального опыта с ним нет - поэтому не скажу насколько он лучше 2009

[Vadik]

Цитата:

Сообщение от belugin

В 2012 используется WF4, где, как говорят, существенно увеличили производительность. К тому же теперь не нужен IIS - он встроен, прямо в АОС. Но у меня реального опыта с ним нет - поэтому не скажу насколько он лучше 2009

Не скажу за производительность, но помню пляски с настройкой нескольких инстансов WF на одном хосте в 2009 - и как же хорошо стало с 2012

[fed]

Цитата:

Сообщение от Vadik

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

А зачем универсальное ? Все равно приходиться конкретные бизнес-процессы автоматизировать. Эти бизнес-процессы ВСЕ РАВНО программировать как-то придется. (Таблички там создавать, разноски писать, с логистикой и сводным интегрировать и тп). Если эти бизнес-процессы уже запрограммированы (и на это эдак 4-5 человеко-месяцев потрачено),то потратить 3-5 дней на то чтобы приделать простенькую цепочку утверждений - не так уж затратно. При этом эту разработку сможет обычный средненький X++ программист выполнить и не придется для поддержки гуру вызывать.
Ну то есть - я понимаю, когда системы workflow используют для СЛАБОФОРМАЛИЗУЕМОГО документооборота. Типа сидит у нас какая-нить проектно-исследовательская контора, обменивается служебными записками, проектной документацией, спецификациями, письмами заказчиков и тп. Мы тут прикручиваем документооборот, определяем типы документов, типы аннотационных полей для каждого документа, состояния документа и определяем цепочки утвреждений для документа. Вот тут workflow очень даже хорош и уместен.
Но мы говорим о ERP-системе. ERP-система по определению работает со стандартизованными и формализованными документами и операциями. Я вообще не понимаю, зачем здесь документооборот настраиваемый ? Все равно ведь если бизнес-процесс поменяется, придется не только цепочку утверждений перепрограммировать, но и, с большой вероятностью, все остальное. А тут получается что мы угрохали на разработку модуля кучу времени (потраченного с пользой кстати) и потом еще тратим кучу времени на интеграцию всего этого с workflow (который из аксапты торчит как больной палец). И все ради того чтобы консультанты могли без программирования workflow перенастраивать ? Да не смешите меня - если что-то у заказчика поменяется то все равно программировать придется.
Да и как я и говорил - иногда программирование намного быстрее и дешевле настройки. WF - это как раз наиболее яркая иллюстрация этого правила.

[fed]

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

[George Nordic]

Коллеги, а никто со сторонними BPM системами не интегрировался?

Платная - IBM Lombardi, бесплатные - сотни их... ELMA, BigAzy (http://www.bizagi.com/)

Из минусов - много дублирования, интеграция точек прохождения бизнес-процессов, 2 среды вместо одной. Зато - заточенные под управление процессами системы.

С Уважением,
Георгий.

Цитата:

Сообщение от Vadik

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

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

[Ivanhoe]

Цитата:

Сообщение от fed

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

Как раз все больше клиентов считают документооборот "само собой разумеющимся". И минимальный набор хотят всё на бОльшем количестве проектов.

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

Но есть же другие примеры - те же журналы ГК. Просто из коробки чуть более развитая система утверждения - чем плохо?

Из того, что обычно требуется в РФ на проектах:
1. Согласование платежей. Это либо стандартный журнал либо чье-нить решение а-ля "Казначейство" и заявка на оплату.
2. Согласование договоров.
3. Согласование бюджетов.
4. Согласование заказов на покупку, согласование заказов на продажу.
5. Реже - согласование карточек контрагентов, номенклатур, доверенностей и т.п.

Как правило в этих WF нужно провести документ по нужным сотрудникам для дозаполнения и/или контроля / одобрения. В итоге нужно получить один статус - "Утверждено", который позволяет далее использовать документ по стандартному назначению Dynamics AX.

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

P.S. В 2012 стало еще больше стандартных документооборотов (документов-оснований).
P.P.S. Просто добавить возможность согласовать документ (поменять один статус по аналогии с написанным выше) занимает у опытного разработчика день-два (AX 2009). После этого оно работает "как в стандарте".

[Vadik]

Цитата:

Сообщение от fed

А зачем универсальное ? Все равно приходиться конкретные бизнес-процессы автоматизировать

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

Цитата:

Ну то есть - я понимаю, когда системы workflow используют для СЛАБОФОРМАЛИЗУЕМОГО документооборота. Типа сидит у нас какая-нить проектно-исследовательская контора, обменивается служебными записками, проектной документацией, спецификациями, письмами заказчиков и тп. Мы тут прикручиваем документооборот, определяем типы документов, типы аннотационных полей для каждого документа, состояния документа и определяем цепочки утвреждений для документа. Вот тут workflow очень даже хорош и уместен

Не понял из примера, что за проектно-исследовательская контора, что за служебные записки и зачем исследовательской конторе ERP система. Не надо рассматривать workflow в AX как систему документооборота, это тупо цепочки одобрений. Выше уже привели пример с одобрением журналов ГК. Мы в качестве эксперимента срисовали с него одобрение складских журналов. Младшенький программист до этого workflow в глаза не видевший нарисовал его за четыре дня (с учетом тестирования, поддержки портала, пинания на предмет BP и вообще вылизывания кода). Консультант за полчаса настроит типичный сценарий для определенного склада\региона:
- Журнал инвентаризации перед разноской должен быть одобрен warehouse manager-ом (это обязательный этап)
- Журнал инвентаризации должен быть одобрен финансистом при превышении суммы приходования\списания к примеру $2000 или $100 по строке журнала
- Добавь к этому работающие "из коробки" оповещения, делагацию и эскалацию - ну плохо разве?
Ты бы знал, сколько "интересных" транзакций не было бы разнесено (а денег - потеряно или украдено) у нас в старой системе на 4.0 если бы имелся работающий механизм одобрений

[fed]

Понимаешь Вадик. Я раз в три месяца наблюдаю на работающей системе последствия доработки workflow неграмотными консами и разработчиками. На той же системе, я наблюдаю последствия доработки обычной X++ функциональности теми же неграмотными консами и доработчиками. Обычную функциональность диагностировать и чинить намного легче.
Если тебя окружают исключительно средние или хорошие консы и разработчики и у них есть время на то чтобы писать внятные ТЗ, программировать, тестировать, планировать релизы и тп - то могу только порадоваться за тебя. Но к сожалению, 80% проектов которые я вижу, не могут позволить себе такой роскоши. И для этих самых 80% проектов - workflow это просто еще одна замечательная возможность to shoot yourself in a foot.

[ice]

Цитата:

Сообщение от Vadik

Ты бы знал, сколько "интересных" транзакций не было бы разнесено (а денег - потеряно или украдено) у нас в старой системе на 4.0 если бы имелся работающий механизм одобрений

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