MSDN Library

Назначение и этапы мостов

Обновлено: Июль 2015 г.

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

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

  • Проверка сообщений. Мост XML поддерживает проверку входящих XML-сообщений на соответствие схеме XSD. Сообщения, не прошедшие проверку, отклоняются.

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

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

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

  • Виртуализация расположений. Мост XML предоставляет элементарную виртуализацию расположения внутренних служб. Клиенты отправляют сообщения в конечную точку Мост XML, предоставленную в облаке, а не в фактическую службу (которая может располагаться в облаке или локально). Затем мост направляет сообщения во внутреннюю службу на основе правил маршрутизации.

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

В этом разделе рассматриваются разные этапы Мост XML. Обратите внимание, что каждый этап не является обязательным, и может быть включен или выключен.

Стадия проверки — это первая стадия в Мост XML. Она обеспечивает проверку XSD XML-сообщений на соответствие указанных схемам. Схемы, которые должны применяться при проверке, задаются при настройке мост. Один Мост XML может получать и обрабатывать XML-сообщения с использованием разных схем. На стадии проверки в зависимости от входящего сообщения подбирается соответствующая схема и используется для проверки. После проверки сообщения на соответствие схеме стадия проверки активизирует свойство X_PIPELINE_MESSAGETYPE в сообщении. Значение этого свойства представляет собой комбинацию целевого пространства имен схемы и имени корневого узла, например, http://IntegrationServices.Schema#RootNode. Если проверка сообщения завершается неудачно, либо по причине отсутствия соответствующей схемы, либо по причине неоднозначного соответствия (найдено несколько схем), возникает исключение.

Инструкции по настройке стадии проверки см. в разделе Создание одностороннего моста XML или Создание моста XML "запрос-ответ".

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

 

Операция Описание

Назначение свойства из заголовка

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

  • Протокол SOAP

    • Действие

    • MessageId

    • ReplyTo

    • Кому

    • Настраиваемые заголовки SOAP

  • HTTP — стандартные заголовки HTTP

  • FTP/SFTP

    • FileName

    • ServerAddress

    • Папка

Инструкции по настройке заголовка для назначения свойств см. в разделе Create an XML Bridge или XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

использование распространяемых системой свойств;

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

  • RequestId — уникальный идентификатор запроса, назначенный сообщению.

  • MessageReceivedTime — метка времени, отмечающая время получения сообщения в конечной точке моста.

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

  • SourceType — тип источника, используемый в рабочей области конструирования, из которого мост получает сообщения.

Инструкции по использованию распространяемых системой свойств см. в разделе Create an XML Bridge или XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Извлечение

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

Инструкции по настройке операции извлечения см. в разделе Create an XML Bridge илиXML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Поиск

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

В данном выпуске на стадии обогащения поддерживается поиск данных только в База данных SQL Microsoft Azure. Другими словами, База данных SQL Microsoft Azure — единственный "поставщик" данных для поиска, поддерживаемый в текущем выпуске. Сведения о поставщике данных для поиска хранятся в файле LookupProviderConfigurations.xml, который добавляется в Проект служб BizTalk. В одном XML-файле можно задавать несколько поставщиков, в соответствии с фактом, что в рамках одной стадии обогащения можно выполнять поиск в нескольких источниках данных База данных SQL Microsoft Azure. Типичное определение поставщика в файле LookupProviderConfigurations.xml выглядит следующим образом.

<ArrayOfLookupProviderConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/WindowsAzureServiceBus/Bridge">
  <LookupProviderConfiguration i:type="SqlTableLookupProviderConfiguration">
    <ProviderName>...</ProviderName>
    <ConnectionString>...</ConnectionString>
    <QueryInColumnName>...</QueryInColumnName>
    <QueryOutColumnName>...</QueryOutColumnName>
    <TableName>...</TableName>
  </LookupProviderConfiguration>
</ArrayOfLookupProviderConfiguration>

Обратите внимание, что в приведенном выше фрагменте для атрибута type элемента LookupProviderConfiguration зафиксировано значение SqlTableLookupProviderConfiguration. Это объясняется тем, что в настоящее время можно выполнять поиск в таблице только в База данных SQL Microsoft Azure.

Поиск данных в База данных SQL Microsoft Azure имеет некоторые особенности.

  • Можно выполнять поиск только в таблице База данных SQL Microsoft Azure.

  • Поиск должен выполняться с использованием пары "ключ-значение".

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

  • Можно искать значение в нескольких источниках данных. Это означает, что можно выполнять поиск в нескольких таблицах База данных SQL Microsoft Azure или в нескольких источниках данных База данных SQL Microsoft Azure.

Инструкции по настройке операции поиска см. в разделе Create an XML Bridge илиXML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

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

На стадии обогащения выполняется создание свойств и назначение этим свойствам значений. Но возникает вопрос: что можно делать с этими свойствами? Как они могут облегчить выполнение задач? Такие свойства можно использовать двумя способами.

  • С помощью этих свойств можно устанавливать условия фильтра для направления сообщений в разные назначения. Инструкции по тому, как это делается, см. в разделе The Routing Condition.

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

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

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

  • Нельзя передавать свойства и их значения в другие компоненты Конфигурация моста, такие как односторонние/двусторонние конечные точки ретрансляции или односторонние/двусторонние конечные точки внешней службы. Если требуется передать значения свойств в такие сущности, следует назначить эти значения свойств заголовкам исходящих сообщений. Дополнительные сведения см. в Действия маршрутизации и ответа: устранение несоответствия протоколов.

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

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

  • Стадия преобразования устанавливает соответствие этого типа сообщения с типом сообщения исходной схемы в сопоставлении.

  • Если стадия проверки отключена, то стадия преобразования сопоставляет входящее сообщение с исходной схемой сообщения. Если разрешение происходит, то активизируется свойство MessageType сообщения.

В текущей версии поддерживаются только преобразования из одного источника в одно назначение. Дополнительные сведения см. в Обучение и создание сопоставлений и преобразований сообщений. Инструкции по настройке стадии преобразования см. в разделе Create an XML Bridge или XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

Стадия обогащения после преобразования аналогична стадии обогащения до преобразования. Единственное различие заключается в том, что на стадии обогащения после преобразования можно обогащать преобразованное сообщение. Эта стадия настраивается тем же способом, что и стадия обогащения до преобразования. Инструкции по настройке стадии обогащения после преобразования см. в разделе Create an XML Bridge или XML Request-Reply Bridge : Configuring the Enrich Stage for the Response Message.

noteПримечание
Все свойства, извлеченные или найденные до стадии преобразования, остаются доступными в преобразованных сообщениях. Ранее извлеченное или обогащенное свойство будет переопределено, если оно изменяется на стадии обогащения после преобразования.

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

  • Схемы. Схемы имеют расширение XSD.

  • Преобразования. Преобразования имеют расширение TRFM; в рамках этапа преобразования может существовать несколько преобразований.

  • Сборки. В сборках содержится логика настраиваемой обработки, которая может быть включена на определенных стадиях моста.

  • Сертификаты. Используются для безопасного преобразования сообщений.

noteПримечание
Файл конфигурации моста не является артефактом, поскольку он не может совместно использоваться разными мостами. Файл конфигурации моста связан с определенным мостом.

Приложение службы BizTalk может иметь несколько мостов, и каждый мост может использоваться несколькими преобразованиями и схемами. Поэтому типичное приложение Службы BizTalk может иметь большое число преобразований и схем. Однако наряду с этим не все преобразования и схемы могут требоваться для каждого Мост XML. Следовательно, должен быть способ связи преобразований и схем с мостом. Эту связь можно задать при настройке моста.

Связывание схем и преобразований см. в разделе Создание одностороннего моста XML или Создание моста XML "запрос-ответ".

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

См. также

Основные понятия

Что такое мосты?

Показ:
© 2016 Microsoft