Цикл ожидания в асинхронном бизнес-процессе

[Артем Enot Грунин]

Я думаю вам нужно почитать про Windows Workflow Foundation в .NET 4.0. Рабочие процессы CRM построены на базе этой технологии.
Все запущенные процессы хранятся в таблице текущих операций. Ожидающие процессы - не исключение. Раз в какое-то время (где-то есть информация раз в сколько, кажется это задается в реестре или в базе) асинхронный сервис CRM пробегает по этой таблице и последовательно выполняет шаги процессов. У него есть на это определенный интервал времени и если он не успевает в него уложитья, то процесс складывается обратно в базу, а сервис засыпает до следующего запуска. Кривизна архитектуры состоит в 2 моментах:
1. Если операции внутри шага не успели завершиться до таймаута - шаг считается не выполненным, процесс завершается и в следующий раз будет выполняться с этого же шага. В этом случае какие-то операции могут быть выполнены дважды или трижды. Поэтому следует избегать длительных ожидающих операций в кастомных шагах. Если они необходимы - используйте плагины.
2. Если ожидающих процессов много, или журнал не чистится, асинхронный сервис может подавиться потоком информации и не будет успевать выполнять процессы за свой рабочий интервал. Процессы зависнут в состоянии ожидания.

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

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