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