BizTalk MVP Sandro Pereira has just released a free ebook about mapping in BizTalk. Get it here: http://sandroaspbiztalkblog.wordpress.com/2014/09/28/biztalk-mapping-patterns-and-best-practices-book-free-released/
Category: Mapping
Code Camp Spring 2013 – BizTalk Intro to Messaging Presentation Slides
Post this under the “better late than never” category. Sorry, guys.
Anyway here are the slides I promised over a week ago. If you’d like the source code, please contact me.
Exception from HRESULT: 0x80131942
My team was working on some pretty tight deadlines when this beauty showed up on a suspended message:
Exception from HRESULT: 0x80131942
That was all that was there–nothing else. A quick web search turned up a few articles, with most pointing to something going on in the maps. However, there are apparently a number of issues tied to this exception.
In our case the cause of this exception was trying to use “” (empty quotes) to represent an empty string inside of a functoid. You need to make sure that you just leave it blank.
So this:
Should have been this:
Easy, right? As usual, the exception doesn’t always point to an obvious answer. This is just one more thing to check for if you see it.
Also, thanks to Yair Z for a post that helped point us to maps. Obviously, we had a different issue than he did, but you might find his info regarding xsl:imports useful if your cause of the error wasn’t the same as ours.
Book Review: BizTalk 2010 Recipes-A Problem-Solution Approach
BizTalk 2010 Recipes: A Problem-Solution Approach by Mark Beckner is a great book for the BizTalk developer who would like a basic step-by-step instruction list or a reference book on how to perform most tasks in the BizTalk environment. BizTalk is a large and difficult product to learn and master and Beckner’s book provides a great resource for the beginning to intermediate level BizTalk developer to do just that.
The layout of the book is very straightforward. A standard BizTalk task is presented, step by step instructions are provided to complete the task and then an explanation of some of the major technical points is given. I found the first section of the book on the new features of BizTalk 2010 to be particularly useful and recommend it for any user of previous BizTalk versions to get up to speed.
Beckner writes in a very accessible style. The book is an incredibly easy read. The examples are appropriate and “real world” enough to be useful and the explanations are technically sound and understandable. It is also covers all the basic functionality within BizTalk–schemas, maps, orchestration, BRE, etc. as well as some of the less-used features such as EDI.
Although I really liked Beckner’s writing style and the step-by-step approach to performing BizTalk tasks, I felt that the book does in some ways falls short of the goal provided in the title. While I was looking for a resource for discussion and insight into solving more Business or Architectural oriented problems, I found the approach in BizTalk 2010 Recipes to be more of a run-down of BizTalk features and a description of how to use them.
That is a valuable service all in itself, and I highly recommend this book for that use. However, if you’re really looking for something to help with BizTalk “recipes” from a business problem or architectural patterns point of view, another book such as Seroter’s BizTalk SOA book might serve that purpose better.
Dynamic Map and Pipeline Execution in a BizTalk Orchestration: A Case Study
Sometimes you just don’t know what needs to happen until it’s time for it to happen. Most business process software requires the ability to alter its path while en route to wherever it may be going. Recently, I worked on a project that had a similar requirement.
Here’s a very high level view of the process/requirements:
- Data is received in the form of a message in a canonical format.
- Based on the client identified in the message, a number of output documents would need to be generated. The number and type must be changed easily as new clients came on board or as old clients added or changed output types.
- After the messages are sent, the canonical message must be allowed to be processed further from its original state.
In most cases, the ESB toolkit would have been a great fit for this type of work except for a couple of things: additional processing needed to take place against the original canonical message after the maps and pipelines had done their work; and the number of maps and pipelines that needed to be executed against the canonical schema was not known until runtime.
For our solution we decided to use a single Orchestration for the ability to maintain state of the original message (the last requirement), but also for ease in development.
Once we received the canonical message, the first step was to retrieve a list of output messages that would be required for the given client. Each output needed two pieces of information: the map that would be required to extract the specific data from the canonical message, and the special pipeline required to create the flat-file or other output needed (as necessary). We used the BRE to determine which maps and pipelines were needed for the outputs. Creating some fairly simple rules, we generated output that conformed to the following schema definition:
As a point of interest (and necessity), we did not use the CallRules shape in BizTalk to execute the policy that returned our map list document. We used .NET code in a separate assembly accessed from within an expression shape. For info on how to do this, see my previous post on Calling the BRE from .NET Components.
Once it was known which maps and pipelines needed to be executed, it was just a matter of doing the work. A looping structure was used to iterate through each output document required.
Once we retrieved the info required to identify the System.Type of the map from our list, we could then run the map. Inside a message assignment we executed the following code to create the mapped output.
We then needed to execute the pipeline. Once again, we used our BRE-generated document to tell us which pipeline to use. After capturing the type, we executed the pipeline:
After pipeline processing, we could then send the pipeline output to where it needed to go through a dynamically-bound port, once again using the BRE to get the information required to determine the correct location.
We then took the original message and sent it on its way for further processing.
For more info regarding dynamic map execution or calling pipelines from within an orchestration, see these MSDN articles:
Maps: http://msdn.microsoft.com/en-us/library/aa950573(BTS.70).aspx
Pipelines: http://msdn.microsoft.com/en-us/library/aa562035(v=bts.70).aspx
Extremely Talented Monkeys 