RDA Corporation EAI Blog -
Discussing BizTalk Server, Enterprise Application Integration and SOA
Recently I gave a presentation on BizTalk Server 2009 at the Carolina Code Camp. The presentation covered the basics of BizTalk as well as the new features of BizTalk Server 2009.
I showed a short demonstration of a sample Purchase Order process. The components used were the Schema Designer, the Mapper, the Orchestration Designer, and the Consume WCF Service Wizard.
PowerPoint slides and demo code are available upon request.
After many hours of research and blog reading, I came to the conclusion that there is no out-of-the-box or additional download (from an Adapter Pack or similar) support for REST services in BizTalk 2009. My recommendation is to have a C# helper class make the call for you. This is not what I was hoping to discover, although it does make sense.
REST services do not employ formal contracts, while BizTalk relies heavily on strong-typing of messages, these two philosophies contradict.
The other issue is that BizTalk needs two pieces of data for message delivery, destination URI and the Message. REST embeds the message as part of the URI. Again, this is a contradiction in philosophies.
We can create a Dynamic Send port with the correct URI (message embedding included), however BizTalk must send a message along with the URI and REST services reject this additional payload. Also, Dynamic Send ports do not support two-way communication so there is no way to correlate the response message, even if we were to actually be able to get one from the REST Service.
Until Microsoft adds support for REST in BizTalk, the workaround is to use a .NET Helper Method to make the REST call for us.
Recently, a client was updating their message processing system from a collection of old VB6 applications to a BizTalk Server 2009 solution. One of the processes that they struggled with was updating their “special case” partners. I call these partners “special case” because they could not or would not adhere to the standardized schema for acknowledgment messages that was provided.
Each “special case” partner had their own message type, which changed without notice. The only thing that each had in common was that they agreed to put an acknowledgment bit somewhere within their return message. The placement of this acknowledgment bit was establish many years ago when the VB6 applications where written. The problem of extracting the bit was solved within the VB6 applications and the code was simply updated to C# to leverage the existing solution.
The other issue that was occurring is that each acknowledgment message had a different format, and non of them were valid XML. Most of the acknowledgments were actually screen scrapes from HTML pages with multiple root nodes and the message stuffed in at various places. BizTalk does not like to consume messages that have no schema/message type. To solve this issue, I had the client run the Flat File Schema Wizard to generate a Flat File Message with a single node and the entire contents of the message as its value (contained within CDATA markup to prevent corruption). The trick with this approach is the delimiter used to define the records. Since we only ever want one record, we need to choose a delimiter that has a very, very low probability of showing up in the incoming message. The delimiter I chose to use was “|abcdefghijklmnopqrstuvwxyz|”.
Now that the message was being consumed, it was a simple matter to use xpath to extract the string payload of the message and send it over to the existing C# helpers that know how to process it.
Introduction
I was recently asked to create a map to combine parent records with children records. The challenge was that the children records in the source document where not grouped with their parent record.
Mapping Unrelated Records
The message was similar to the following Xml where StatusItem is related by its ordinal position to DetailStatus/DetailItem. Look carefully at the message; the StatusItem parent node is SummaryStatus, which is at the same level in the Xml as DetailStatus. There is only one SummaryStatus node, and there are multiple DetailStatus nodes – all at the same level in the Xml.
<root>
<SummaryStatus>
<SummaryCode>102</SummaryCode>
<StatusItem>
<statusCode>item_0</statusCode>
</StatusItem>
<StatusItem>
<statusCode>item_1</statusCode>
</StatusItem>
<StatusItem>
<statusCode>item_2</statusCode>
</StatusItem>
</SummaryStatus>
<DetailStatus>
<DetailItem>
<statusCode>detail_0</statusCode>
</DetailItem>
</DetailStatus>
<DetailStatus/>
<DetailItem>
<statusCode>detail_1</statusCode>
</DetailItem>
</DetailStatus>
<DetailStatus/>
<root>
In reality a message similar to the above is being provided by an outside source and we cannot modify it. By convention we are given the assumption that there is a DetailStatus record for each StatusItem, however there is not always a DetailItem. Our job is to map the output and combine the StatusItem code with its each DetailItem code.
The output goal is similar to the following Xml:
<root>
<SummaryCode>102</SummaryCode>
<StatusItem>
<StatusCode>item_0</StatusCode>
<DetailItem>
<StatusCode>detail_0</StatusCode>
</DetailItem>
</StatusItem>
<StatusItem>
<StatusCode>item_1</StatusCode>
<DetailItem>
<StatusCode>detail_1</StatusCode>
</DetailItem>
</StatusItem>
<StatusItem>
<StatusCode>item_2</StatusCode>
</StatusItem>
</root>
The BizTalk map below works by using the Iteration Functoid comparing the position of the current SummaryStatus parent record to the position of the DetailStatus record. Additionally the Logical Existence Functoid is used so that if a DetailItem does not appear in the source message, then it won’t appear in the Target message.
External Links from MSDN
Previous Articles
