Стоит ли использовать BizTalk Orchestration

В настоящее время я занимаюсь переносом существующего приложения (BizTalk 2004) на более новую версию BizTalk. Текущее решение принимает несколько типов документов EDI, при необходимости модифицирует их и отправляет в нашу устаревшую систему для загрузки и обработки.

Этот процесс разработан с использованием комбинации портов приема, компонента конвейера, портов и карт отправки, схемы и компонентов очереди сообщений. Это решение использует 10 портов отправки и получения для обработки различных аспектов процесса, таких как пакетирование EDI в отдельные сообщения, преобразование сообщений, обработка ошибок, проверка EDI и пакетирование сообщений EDI. Вся модификация EDI выполняется с использованием компонентов очереди сообщений.

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

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


biztalk biztalk-orchestrations
person BM.    schedule 22.05.2014    source источник
comment
Можете ли вы описать, что вы имеете в виду, говоря, что модификация EDI выполняется с использованием компонентов очереди сообщений? Очереди сообщений обычно являются лишь транспортным механизмом.   -  person Johns-305    schedule 22.05.2014
comment
Biztalk применяет карту к документу EDI, который является просто оболочкой XML. Затем преобразованный xml отправляется в очередь сообщений Microsoft. Компонент за очередью (просто a.net dll) изменит документ на основе бизнес-правил и отправит его обратно на biztalk для пакетной обработки.   -  person BM.    schedule 22.05.2014
comment
Итак, вы намереваетесь заменить .dll собственным приложением BizTalk?   -  person Johns-305    schedule 22.05.2014
comment
Вовсе нет ... DLL останутся на месте   -  person BM.    schedule 22.05.2014

Ответы (2)


arrow_upward
3
arrow_downward

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

  1. Является ли обработка транзакционной
  2. Важен ли порядок сообщений
  3. Собираетесь ли вы обрабатывать сообщение по бизнес-правилам
  4. Вам нужно вызывать внешние сборки

Цитата из "Microsoft BizTalk Server Pattern"

Оркестровка обходится дорого. Многие из этих затрат проявляются в виде обращений к ящику сообщений и обратно, что означает пересечение границы процесса, запись и чтение из базы данных - окна сообщений.

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

  1. Получите сообщение через адаптер, сохраните его в окне сообщения
  2. Получить сообщение для порта отправки

vs:

Шаги для подхода к оркестровке

  1. Получите сообщение через адаптер и сохраните его в окне сообщения.
  2. Получите сообщение, чтобы начать оркестровку
  3. Составьте карту, если вам нужно
  4. Снова получите элемент для порта отправки.

Выбирай с умом

person Bitmask    schedule 22.05.2014
comment
Даже №3 Использование бизнес-правил может быть выполнено в решениях только для обмена сообщениями с использованием структуры конвейера BRE brepipelineframework.codeplex.com (Полное раскрытие: Структура конвейера BRE написана моим коллегой). - person Dijkgraaf; 23.05.2014

arrow_upward
1
arrow_downward

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

person Dijkgraaf    schedule 22.05.2014