Маршрутизация сообщений из мостов в назначения в проекте службы BizTalk

Обновлено: Август 2015 г.

Осуществляйте маршрутизацию сообщений из одного компонента в другой с помощью условий маршрутизации.

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

В этом разделе данные действия рассматриваются на примере сценария. Предположим, что XML-сообщение в следующем формате должно обрабатываться с помощью Односторонний мост XML:

<PaymentHistory xmlns:ns0="http://Integration.PipelineChaining">
  <BaseData>
    <Amount>10.4</Amount> 
    <CurrencyCode>CurrencyCode_0</CurrencyCode> 
    <EntryDate>1999-05-31</EntryDate> 
    <EntryTime>13:20:00.000-05:00</EntryTime> 
    <PaymentMode>Mode_0</PaymentMode> 
    <StatusCode>StatusCode_0</StatusCode> 
    <PurposeCode>PurposeCode_0</PurposeCode> 
  </BaseData>
</PaymentHistory>

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

Это довольно просто. Необходимо задавать назначение маршрутизации, куда направляется входящее сообщение после обработки мост. Существует несколько рекомендаций касательно того, куда может направляться сообщение из Односторонний мост XML или из Мост XML "запрос-ответ". Дополнительные сведения об этих рекомендациях см. в разделах Constraints on Using an XML One-Way Bridge и Constraints on Using an XML Request Reply Bridge.

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

  1. Создайте Проект служб BizTalk, как описано в разделе Приступая к работе с проектом Visual Studio.

  2. Добавьте в Проект служб BizTalk компоненты, как описано в разных темах раздела Создание полнофункциональных конечных точек обмена сообщениями в Azure.

  3. Выберите компонент Соединитель в категории Мосты в панели элементов.

  4. Поместите указатель мыши в правый конец компонента (отмечаемый красной точкой при перемещении курсора по компоненту), который выступает в качестве источника сообщения. Указатель мыши изменяется и показывает маленькую букву "S", означающую, что этот компонент добавляет источник (source) сообщения. Щелкните эту точку, и удерживая кнопку мыши, перетащите ее в левый конец целевого компонента (в этой точке курсор снова изменяется, чтобы показать маленькую букву "T", указывающую, что это целевой (target) компонент), а затем отпустите кнопку мыши. Теперь два компонента соединены. Обратите внимание, что можно соединить один исходный компонент с несколькими целевыми компонентами.

    noteПримечание
    Для текущего этапа поток сообщений всегда должен начинаться с Односторонний мост XML или с Мост XML "запрос-ответ". После этого можно направлять сообщение в любой компонент, при условии, что соблюдаются ограничения. Ограничения перечисляются в разделах Constraints on Using an XML One-Way Bridge и Constraints on Using an XML Request Reply Bridge.

    Действуя в соответствии с этим примером сценария, необходимо соединить Односторонний мост XML с односторонней внешней службой, с односторонней конечной точкой ретрансляции и с очередью Служебная шина.

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

Исходя из примера сценария, приведенного выше, условие маршрутизации должно строиться на основе способа оплаты, который указывается элементом PaymentMode в XML-сообщении. Чтобы реализовать эту бизнес-логику в Проект служб BizTalk, потребуется создать фильтры маршрутизации для каждого условия. Следующая процедура показывает, как это делается.

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

Следующая процедура показывает, как можно установить условия маршрутизации в Проект служб BizTalk.

  1. Щелкните правой кнопкой мыши соединитель маршрута между Односторонний мост XML и односторонней внешней службой, а затем выберите пункт Свойства. В панели свойств нажмите кнопку с многоточием (…) для свойства Условие фильтра, чтобы открыть диалоговое окно настройки фильтра маршрута.

  2. В диалогом окне выберите параметр Фильтр и укажите следующую строку фильтра:

    PaymentMode='credit_card'
    
    noteПримечание
    Для выражений фильтра необходимо использовать стандартный синтаксис SQL 92.

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

    Нажмите кнопку ОК, чтобы сохранить изменения и выйти.

  3. Аналогично, для соединителя между Односторонний мост XML и односторонней конечной точкой ретрансляции укажите следующую строку фильтра:

    PaymentMode='cash'
    
  4. Если в качестве способа оплаты не используются ни наличные, ни кредитная карта, то сообщение должно направляться в очередь Служебная шина. Чтобы добиться этого в потоке сообщений, необходимо открыть диалоговое окно настройки фильтра маршрута для соединителя между Односторонний мост XML и очередью Служебная шина и выбрать Сопоставить все. Таким образом указывается, что если ни одно из условий фильтра не выполняется, то обрабатывается это условие, и сообщение будет направляться в очередь Служебная шина.

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

  1. Дважды щелкните мышью Мост XML (Односторонний мост XML или Мост XML "запрос-ответ") и выберите пункт Свойства. В панели свойств нажмите кнопку с многоточием (…) для свойства Таблица порядка маршрутизации.

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

  3. Нажмите кнопку ОК, чтобы сохранить изменения и выйти.

Перед отправкой сообщения получателю может потребоваться добавить некоторые настраиваемые заголовки сообщения или назначить значения стандартным заголовкам сообщения. Это можно сделать с помощью действия маршрута. Дополнительные сведения см. в Route Action.

Чтобы продолжить с тем же примером сценария, предположим, что сообщение должно отправляться в одностороннюю внешнюю службу с настраиваемым заголовком SOAP (CustomerName) и значением.

  1. Щелкните правой кнопкой мыши соединитель маршрута между мостом и односторонней внешней службой, а затем выберите пункт Свойства. В панели свойств нажмите кнопку с многоточием (…) для свойства Действие маршрута, чтобы открыть диалоговое окно Действия маршрута.

  2. В диалоговом окне Действия маршрута нажмите кнопку Добавить, чтобы открыть диалоговое окно Добавление действия маршрута. В диалоговом окне Добавление действия маршрута выполните следующие действия.

     

    Раздел Имя поля Описание

    Свойство (чтение из)

    Имя свойства

    Перечисляет все свойства, заданные в двух предыдущих стадиях обогащения в Мост XML "запрос-ответ". Выбирая здесь свойство, вы указываете, что значение выбранного свойства должно быть назначено соответствующему заголовку исходящего сообщения.

    Выражение

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

    • P1 + P2, где P1 и P2 — это два свойства, уже заданные в предыдущих двух стадиях обогащения;

    • 'Fabrikam', постоянное значение.

      ImportantВажно!
      Значение для выражения всегда необходимо указывать внутри одинарных кавычек (').

    ImportantВажно!
    Можно выбрать либо параметр Имя свойства, либо параметр Выражение. Эти параметры являются взаимоисключающими.

    Назначение (запись в)

    Тип

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

    В зависимости от назначения сообщения изменяются значения, доступные в раскрывающемся списке.

    • Если выполняется маршрутизация во внешнюю службу или в конечную точку ретрансляции (одностороннюю или двустороннюю), в раскрывающемся списке доступны значения SOAP и HTTP.

    • Если маршрутизация выполняется в очередь или в раздел, в раскрывающемся списке доступны значения SOAP и Brokered.

    • Если маршрутизация выполняется в назначение FTP, в раскрывающемся списке доступно значение FTP.

    • Если маршрутизация выполняется в назначение SFTP, в раскрывающемся списке доступно значение SFTP.

    • Если маршрутизация выполняется в BLOB-объект Azure, в раскрывающемся списке доступно значение Azure Blob.

    Пространство имен заголовка SOAP (только если для параметра Тип задано значение SOAP)

    Введите пространство имен настраиваемого заголовка SOAP, которому присваивается значение.

    ImportantВажно!
    Это поле будет затенено, если вы выберете стандартный заголовок в раскрывающемся списке Идентификатор. Указывать пространство имен требуется только для настраиваемых заголовков SOAP.

    Это поле также затеняется, если в поле Тип установлено значение HTTP или Brokered.

    Идентификатор

    Введите имя свойства заголовка сообщения, которому присваивается значение.

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

    Для других типов назначений, таких как FTP, SFTP и BLOB-объекты Azure, можно выбрать заголовки сообщений, в которые должно записываться значение свойства.

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

  3. Нажмите кнопку ОК в диалоговом окне добавления действий маршрута. Диалоговые окна будут иметь следующий вид:

    Действия маршрута

    Итак, что показывает это диалоговое окно? Оно показывает, что мост будет использовать значение свойства P1 (уже заданного в одной из предыдущих стадий обогащения) и назначать его специальному заголовку SOAP CustomerName с пространством имен http://schemas.microsoft.com/integration/promotedpropertiesinfo, а затем направлять его получателю сообщения.

    ImportantВажно!
    Если создать два действия маршрута в одном соединителе маршрута, указывающем на одно назначение, с помощью двух разных свойств, например P1 и P2, то ошибка построения не возникнет. Последнее действие маршрута переопределяет ранее заданные действия маршрута. В данном примере обрабатывается действие маршрута для свойства P2.

  4. Чтобы обновить или удалить действие маршрута, выберите его в диалоговом окне и нажмите пункт Правка или Удалить соответственно. Нажмите кнопку ОК в диалоговом окне Действия маршрута и нажмите кнопку Сохранить, чтобы сохранить изменения в Конфигурация моста.

См. также

Показ: