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

[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

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