Объяснение схем конвертов BizTalk и выгрузка - PullRequest
0 голосов
/ 07 октября 2019

В настоящее время я изучаю 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-adapters/

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

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

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

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

1 Ответ

0 голосов
/ 07 октября 2019

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

Мое смутное представление о результате заключается в том, что он захватывает результирующую запись из нижнего узла и использует этот 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>

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

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

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

...