Можно ли заменить плагины синхронными Бизнес-процессами?

 

Многие пользователи задают вопрос можно ли заменить плагины синхронными Бизнес-процессами.

В синхронных бизнес правилах конечно же есть много преимуществ, включая:
 - Использование схожего интерфейса со стандартными бизнес правилами, делает их создание быстрым и простым процессом, при этом  позволяя решать разнообразные задачи.
 - Можно создавать и изменять функциональность без навыков программирования.
 - Бизнес правила легко расширяются с помощью кастомных сборок, которые могут быть повторно использованы во многих местах.


Если мы можем использовать дополнительные сборки для расширения функциональности стандартного дизайнера БП (например, возможность обновления записей по связям 1:N и N:N), постает закономерный вопрос - зачем нам вообще использовать плагины?


Бизнес правила в реальном времени добавляют значительную мощность к фреймворку, делает решение более эффективным и снижает затраты на реализацию. Но стоит помнить, что  разработка плагинов, все таки остается важной частью Dynamics CRM решения и причины этому можно выделить такие:

 

Производительность


В большинстве случаев производительность следует рассматривать изначально придерживаясь лучших практик (например не выбирать и не обновлять больше данных чем это на самом деле нужно), с гарантией использования поддерживаемых и документированных методик. Если мы гарантируем, что наша система построена легко, последовательно и логично, то Dynamics CRM, как правило, обеспечивает производительность для нас и позволяет нам расширяться, когда это необходимо.

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

Если мы попытаемся оптимизировать все компоненты системы с самого начала, когда еще нету общей структуры, реально это может  сказаться на снижении общей производительности и в конечном итоге приведет к чрезмерно сложной системе, которая будет иметь более высокую общую стоимость поддержки.

Это правда, что плагины обыгрывают синхронные процессы с точки зрения производительности, но если частота операций будет низкой, то это, как правило не будет проблемой. Если же у вас есть логика, которая должна срабатывать с высокой частотой для многих пользователей одновременно, то это тот случай когда следует отказаться от БП в пользу плагинов.

В некоторых простых тестах, приводятся результаты в которых БП проигрывают почти в 2 разы по скорости простого апдейта записи.  Основная причина заключается в том что цикл работы плагина максимально эффективно встроен в работу платформы и выполняется внутри транзакции платформы, в то время как БП создает дополнительную транзакцию внутри родительской и требует намного больше sql запросов для создания контекста бизнес процесса.

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

Используя плагин, например, при обновлении записи через изменение объекта Target у вас будет всего один апдейт так как обновление будет проходить "в транзитном" цикле до обновления в базе данных.

Другая причина того что синхронные бп могут занимать больше времени кроется в том что запись из базы данных всегда извлекается полностью (со всеми полями), тогда как нужно всего 1-2 поля.

Мы сделали свой тест производительности для плагина и БП. Протестировали создание 100 звонков. В первом случае на создания звонка мы активировали БП с одним шагом - обновлением темы звонка на котором стартует процесс, во втором такую же логику но с помощью плагина на PreUpdate - обновления производилось через объект Target, в третьем случае та же логика с помощью плагина без Target - прямым апдейтом через CRM веб сервис.

Создание 100 звонков без дополнительной логики -  2.49 сек.
Создание 100 звонков + обновление темы через БП - 5.79 сек.
Создание 100 звонков + обновление темы плагином напрямую через веб сервис CRM - 4.14 сек.
Создание 100 звонков + обновление темы плагином через объект Target  - 2.60 сек.

 

Pre/Post Объекты

 

Когда вы используете плагины у вас есть возможность увидеть какие данные будут обновлены, как запись выглядела до транзакции и  как она будет выглядеть после транзакции. Бизнес правила не представляют такой функциональности и из за этого трудно получить предыдущее значение поля.

 

Персонализация 

 

БП разрешают вам только выбрать от имени кого будет запускаться процесс (владелец БП или текущий пользователь), тогда как плагин в дополнение дает вам полный контроль выполнения через SDK - как системный пользователь или как идентифицированный пользователь в разных участках во время выполнения транзакции.

 

Программный код или Настройка

 

С Бизнес Правилами ваша бизнес-логика, как правило, приводит к фрагментации на много родительских и дочерних БП, нет возможности задать порядок выполнения. Это делает модульное тестирование и контроль конфигурации гораздо сложнее. С плагином вы можете написать юнит-тесты и загрузку кода в TFS. С каждым изменением вы можете быстро увидеть отличия от предыдущей версии и легко настроить порядок, в котором выполняется код.

Хорошая практика иметь один синхронный БП на комбинацию событие/сущность и вызывать другие БП как дочернии оттуда, тогда у вас будет возможность задать порядок выполнения.

Очень веской причиной, чтобы использовать плагины является детерминистический характер их выполнения. Вы можете настроить порядок выполнения вашего кода просто последовательно вызвав логику в одном плагине, а затем написать Unit тесты для этой последовательности событий с помощью mock полностью за пределами Dynamics CRM среды.

 

Итого что лучше?

Что лучше?  Каждый вариант имеет свои преимущества и недостатки, так что все зависит от ситуации:

плагины:

- Если у вас уже есть плагин на сущности или он планируется, тогда и в последующей логике лучше от БП отказаться для того что бы сохранить процесс выполнения меньшем и детерминированным.

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

Бизнес правила:

- Очень веская причина, чтобы использовать БП является тот факт, что бизнес-пользователи могут самостоятельно создавать и поддерживать их в будущем, в то время как для плагинов требуется кодирование и развертывание.

детерминированным
очень веская причина, чтобы использовать RTWS является тот факт, что бизнес-пользователи могут создавать и поддерживать их в долю времени, которое требуется для кодирования и развертывания плагин и часто приводит к гораздо меньшим количеством ошибок из-за строительных блоков компонент на основе.