BizTalk 信封架构和分批说明

Question

I'm currently self-studying BizTalk as part of a new role, and have picked up the core concepts of developing Orchestrations and configuring pipelines. Recently I've been trying to get my head around debatching resultsets containing multiple records into separate messages using Envelope Schemas, and finally got it working last week by using the below tutorials;

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/

What I'm looking for if possible is for someone kind enough to give me an understanding of the mechanics involved so that I can confirm my understanding of the process to incorporate fully into my solutions.

My understanding is: The Receive Pipeline is using the XML Disassembler to break apart my message on the basis that I've flagged the receiving schema as an Envelope.

This is where my question kicks in. On the schema, I'm setting the parent node's Body XPath to that of the node ABOVE the final node containing the result elements. Why am I doing this, and what does it do exactly?

My vague grasp of the outcome is that it grabs the resulting record from the bottom node, and uses that Body XPath as a reference on where to obtain the child nodes/elements to create the new message?

Answer 1

On the schema, I'm setting the node's Body XPath to that of the node ABOVE the final node containing the result elements. Why am I doing this, and what does it exactly?

My vague grasp of the outcome is that it grabs the resulting record from the bottom node, and uses that Body XPath as a reference on where to obtain the child nodes/elements to create the new message?

I (too?) had some trouble understanding the reasoning behind the wording Body XPath, since it's actually the envelope you're selecting.

What it's doing: you're telling BizTalk that all records below that node should be treated as individual messages. It doesn't have to be a single record, or even a single type of message. So, you can collect a bunch of different messages from a single data source, and process them all individually.

It's not the node above the 'final/bottom' node per se, since an envelope can contain a bunch of other types (in case you want to do some validation on the receiving part).

The example from your first link allows pretty much any XML below the body, since it's using an Any element. That means I could just add a Warning record to their example:

<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>

Using the described debatching method, this single incoming message will result in three messages in the message box;

<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>

... and...

<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>

... and...

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

... to which you can then subscribe to.

This is - in my opinion - particularly useful if you have a single source of messages where each message is meant for another destination (eg different customers), or where the destination requires that each message is sent individually (eg a target invoice schema that allows only one invoice per file).

The alternative to this method would be to just select one record at a time from the source.