Объяснение схем конверта BizTalk и дебатчинга

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

https://docs.microsoft.com/en-us/biztalk/core/walkthrough-using-xml-envelopes-basic https://blog.tallan.com/2014/12/23/typed-polling-with-wcf-адаптеры/

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

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

Вот тут и начинается мой вопрос. В схеме я устанавливаю XPath тела родительского узла равным XPath узла НАДЕЛЕМ над последним узлом, содержащим элементы результата. Почему я это делаю и что именно?

Мое смутное представление о результате заключается в том, что он захватывает результирующую запись из нижнего узла и использует этот Body XPath в качестве ссылки на то, где получить дочерние узлы / элементы для создания нового сообщения?


biztalk envelope-schema biztalk-2013r2
person mrc85    schedule 07.10.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

В схеме я устанавливаю XPath тела узла равным XPath узла ВЫШЕ последнего узла, содержащего элементы результата. Почему я это делаю и что именно?

Мое смутное представление о результате заключается в том, что он захватывает результирующую запись из нижнего узла и использует этот Body XPath в качестве ссылки на то, где получить дочерние узлы / элементы для создания нового сообщения?

У меня (тоже?) Были некоторые проблемы с пониманием аргументов, стоящих за формулировкой Body XPath, поскольку на самом деле вы выбираете конверт.

Что он делает: вы сообщаете BizTalk, что все записи ниже этого узла следует рассматривать как отдельные сообщения. Это не обязательно должна быть отдельная запись или даже один тип сообщения. Таким образом, вы можете собрать кучу разных сообщений из одного источника данных и обработать их все по отдельности.

Это не узел над «конечным / нижним» узлом как таковой, поскольку конверт может содержать кучу других типов (на случай, если вы хотите провести некоторую проверку на принимающей части).

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

<Envelope xmlns="http://BasicXMLEnvelope">
  <Error>
    <ID>102</ID>
    <Type>0</Type>
    <Priority>High</Priority>
    <Description>Sprocket query fails.</Description>
    <ErrorDateTime>1999-05-31T13:20:00.000-05:00</ErrorDateTime>
  </Error>
  <Error>
    <ID>16502</ID>
    <Type>2</Type>
    <Priority>Low</Priority>
    <Description>Time threshold exceeded.</Description>
    <ErrorDateTime>1999-05-31T13:20:00.000-05:00</ErrorDateTime>
  </Error>
  <Warning>
    <ID>333</ID>
    <Description>Just a warning.</Description>
    <WarningDateTime>2019-10-07T15:15:00.000+02:00</WarningDateTime>
  </Warning>
</Envelope>

Используя описанный метод дебатирования, это одно входящее сообщение приведет к появлению трех сообщений в окне сообщения;

<Error>
  <ID>102</ID>
  <Type>0</Type>
  <Priority>High</Priority>
  <Description>Sprocket query fails.</Description>
  <ErrorDateTime>1999-05-31T13:20:00.000-05:00</ErrorDateTime>
</Error>

... а также ...

<Error>
  <ID>16502</ID>
  <Type>2</Type>
  <Priority>Low</Priority>
  <Description>Time threshold exceeded.</Description>
  <ErrorDateTime>1999-05-31T13:20:00.000-05:00</ErrorDateTime>
</Error>

... а также ...

<Warning>
  <ID>333</ID>
  <Description>Just a warning.</Description>
  <WarningDateTime>2019-10-07T15:15:00.000+02:00</WarningDateTime>
</Warning>

... на который вы можете подписаться.

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

Альтернативой этому методу было бы просто выбирать по одной записи из источника.

person Ruud    schedule 07.10.2019
comment
Отлично, спасибо @Ruud - рад видеть, что иду верным путем! - person mrc85; 08.10.2019