2016-09-13 9 views
1

У меня есть простой сценарий, когда мне приходится направлять сообщения из одной папки в другую. Теперь эти сообщения могут поступать из 10 разных источников (папка) и должны быть перенаправлены в 10 отдельных местоположений (папка).Маршрутизация сообщения того же типа сообщений из разных мест приема в Biztalk

Для примера. Рассмотрим SourceA, SourceB, SourceC ... - получайте адреса и DestA, DestB, DestC, ... - места назначения.

Итак, файл от SourceA должен быть перенаправлен на DestA и так далее.

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

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

2) 10 получают места, где все сообщения публикуются в окне сообщений и с одним динамическим логическим приемным портом в оркестровке.

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

Примечание: Тип сообщения & Данные в этих местах могут быть точно такими же. Таким образом, маршрутизация на основе некоторого поля данных невозможна.

Пожалуйста, дайте мне знать, если вам нужно уточнить.

ответ

2

Лучший ответ в этом случае является самым простым.

  • 10 Предоставляемая Порты/Locations
  • 10 Отправить Порты

Отправки Port Filter основана на BTS.ReceivePortName.

0

Если для маршрутизации нет свойства данных, вам потребуется свойство контекста, на котором вы можете маршрутизировать. В соответствии с ответом Johns-305 вы можете использовать BTS.ReceivePortName, если это сообщение только без оркестровок. Однако, если у вас есть Orchestration, вы либо должны либо удостовериться, что вы сохраняете BTS.ReceivePortName, либо используете другое свойство контекста, которое продвигается.

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

  • в WCF-WebHttp Получение расположений через метод HTTP- и URL Mapping
  • в WCF-WSHttp через его операцию
  • Другие порты, имея BRE Трубопроводный набор компонентов операции.
  • Из оркестровок, заданных с помощью имени операции из логического порта.
-1

Мой голос идет к Johns-305, если это действительно сценарий маршрутизации 1-1 ...Значение rcvLocation A всегда будет направлять на пункт назначения A, а затем просто масштабировать ваши места приема, чтобы разделить порты приема и соответственно подписаться на порты отправки.

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

Надеюсь, это поможет!