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

[Fighter]

Добрый день!

CRM 2011 Online.

В асинхронном бизнес-процессе требуется запустить процедуру ожидания. Кто знает, какой метод лучше использовать (точнее, какой метод будет меньше "грузить" сервер):

- использовать условие ожидания;
- использовать таймаут в процессе (например, ждать 2 часа, а потом проверить нужные условия...).

В конструкторе Бизнес-процесса эти условия называются соответственно:
1) - Подождать пока произойдет ...
2) - Время ожидания до ...

Понятно, что в первом случае CRM должен с некоторым интервалом мониторить заданные в условии поля записи. Интересует, какой это интервал? и как это скажется на производительности хостового сервера, если, скажем, подвесить процессов 50?

Понятно, что во втором случае - это заданный жестко таймаут. По идее, CRM должна запустить внешний счетчик времени и не лезть в запись. Т.е. бизнес-процесс как бы "висит", но ресурсы процессора тратятся минимально... Так ли это? Или все же CRM продолжает "лезть" в запись с заданным интервалом времени, и там смотрит условие тайм-аута, типа пора прекращать счет времени или ждем дальше...

Заранее спасибо!

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

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

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

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

[AndreyS]

На больших проектах со сложными процессами настоятельно рекомендуется избегать долгих wait.