Workflow против Callouts

Microsoft Dynamics CRM 3.0 предоставляет ряд возможностей, которые позволяют расширить функционал системы в области автоматизации бизнес-процессов. К таким возможностям можно отнести использование .NET сборок для расширения функционала Workflow и создание специальных процедур - Callout. .NET сборка - библиотека, которая с помощью конфигурационного файла один раз подключается к системе, а, затем, функционал данной библиотеки можно использовать сколь угодно много раз не будучи разработчиком. Callout-ы - по сути, триггеры, которые позволяют "повесить" дополнительные обработчики на различные события, такие как: создание, обновление, слияние и т.д. (кстати, кто сдавал локализованный вариант экзамена Customization знает, что в переводе Callout - выноска :) ). Callout-ы также подключаются с помощью конфигурационного файла, но, для того, чтобы использовать их функционал, необходимо знать, как устроена данная библиотека/процедура и ее использование невозможно через редактор бизнес-процессов Workflow Manager. Соответственно, очень часто встает вопрос: "Какое средство необходимо использовать для решения данной конкретной задачи?". И иногда принимается неверное решение, что ведет к дальнейшему переделыванию системы, увеличения срока внедрения, росту расходов на проект и т.д. Чтобы снизить данные риски, давайте посмотрим, когда лучше использовать Workflow, а когда - Callout-ы.

Надо понимать, что любое бизнес-правило, которое задается с помощью Workflow, может быть также задано и с помощью Callout-ов. Разница только в способе подключения библиотеки и возможность использования данного правила в дальнейшем бизнес-аналитиком (т.е. человеком, который не является разработчиком и не знает как писать на .NET) с помощью Workflow Manager.

Если нам надо, чтобы наше правило мы могли использовать в дальнейшем, и люди, которые будут использовать это правило, не являются разработчиками и не знают систему очень глубоко, то предпочтительней использовать Workflow. Действительно, подключение .NET сборки к системе занимает чуть больше 10 строчек в конфигурационном файле. А после этого данное правило будет доступно для всех бизнес-аналитиков, которые используют Workflow Manager. При этом, конечно, надо учитывать, что есть ряд ограничений, присущих именно .NET сборкам:

• Одно из самых главных - асинхронный режим работы. Т.е. мы не можем заранее предсказать, когда закончится выполнение того или иного правила. По сути, все правила Workflow попадают в очередь и постепенно исполняются. Соответственно, НЕЛЬЗЯ (или точнее, не рекомендуется) использовать .NET сборки для синхронизации данных между Microsoft Dynamics CRM и сторонними системами.
• Другое ограничение (не менее важное) - количество событий, по которым может срабатывать правило. Это Создание объекта (Create), Назначение другому пользователю (Assign To), Изменение статуса (Change). Кроме того, существует возможность ручного запуска (Manual) правила.
• Можно создавать workflow правила для собственных объектов, но только для тех, за которые отвечают пользователи (т.н. User-owned). Примерами user-owned объектов являются: Организации, Контакты, Возможные сделки и т.д.

Таким образом, если нам можно использовать асинхронный режим работы в нашей бизнес-логике, мы хотим запускать обработчик при наступлении одного из трех условий (Create, Assign To, Change) или вручную, работаем с сосбтвенными объектами, за которые отвечают пользователи, и хотим в дальнейшем использовать это правило через Workflow Manager, то можно воспользоваться .NET сборками. 

Если же нам требуется синхронный режим работы (синхронизация данных между системами) или требуется запускать обработчик по условию, которого нет в Workflow Manager, или мы хотим как-либо обработать данные ДО их передачи в систему или мы работаем с собственными объектами, за которые отвечает организация (т.н. org-owned), то в этом случае мы обязаны использовать механизм Callout-ов.