Just a quick note about calling a BizTalk Orchestration exposed as a web service with the input and output schema that have the same type.
Many of these were released a few months ago in a beta form but now they are available on the Microsoft website.
NAcks or Negative Acknowledgments are small SOAP messages that exist in BizTalk when a messaging error occurs. This happens when adapters fail, pipelines fail, messages do not match subscriptions, ect.
Congratulations to everyone who is going to attend TechEd 2005 in Orlando, FL – since it is now sold out.
I just wanted to point out a few exciting instructor led labs that I will be leading. If you like my blog content, chances are you will like these labs.
These labs will give you a chance to walk through step-by-step the topics listed below. I will also be available to answer questions.
Using InfoPath SP1 and SharePoint 2003 to Design an Effective Tracking System for BizTalk Server 2004
Abstract: Learn how to utilize InfoPath SP1 through SharePoint to display business process exception returned from within a business process. Learn how to build a simple InfoPath form to display exception information, publish this form into SharePoint, use processing instructions to reference this form, and use delivery notification to catch delivery errors.
Using Sequential Message Processing and the Flat File Disassembler to Map a Large Flat File in BizTalk Server 2004
Abstract: In this lab, you will learn to use the native features of the Flat-file disassembler to break up a large inbound flat file into single messages to allow for easy processing inside BizTalk. Without this ability to break up the document, it would be difficult to process documents of this size. In order to maintain the order of the single messages inside the Message Box, the messages will be processed sequentially using a Convoy Messaging Pattern. Each record will be mapped and written in order to an output file. Delivery notification will be used to ensure sequencing and delivery of the single messages.
If you do not make it to my labs, you can always catch me in the cabana room or after these sessions if you have any questions or just want to say “HI”.
Message context is a critical part of message routing and processing inside BizTalk Server 2004. How this context is handled during mapping is different depending on the location of the mapping. The context is copied differently using Receive Port mapping verses Orchestration mapping.Why should you care? If you are using Direct Message Box Binding to route message out of an Orchestration you might not have the correct context propertied to route your message. This only impacts messages that needed to be routed out of an Orchestration based on a value in the original pre-mapped message. Let’s look at the two types of mappings and what happens to the context.Receive Port MappingThis is a common type mapping since it generally allows for greater flexibility. Receive port mapping occurs after the pipeline completes. This means that context properties will already be promoted by various stages of the pipeline. In this case, the new mapped message has all the original context values of the initial message with any duplicate values updated (i.e. like message type is now the type of the mapped message). In addition, any prompted values in the mapped message are now promoted into the context.To sum it up, Receive Port mapping yields a superset of message context data from both the original message and the new mapped message.Orchestration MappingOrchestration mapping behaves in a totally different manner. Using Orchestration mapping, the context of the original message is NOT copied automatically into the newly created message. But, any promoted fields in the new message are promoted into the message context after mapping. Getting the original message context into the new message is easy. Just add a Message Assignment shape after the transform but inside the same Construct. Add the following code: MessageOut(*) = MessageIn(*)This would look something like this:This will copy the entire context from the original message into the new message and result in a superset just like the Receive Port mapping. Individual message context fields can also be copied using this same method.To sum it up, Orchestration Mapping does not copy original message context by default.Overall, it is import to know what values are inside your message context as your message flows through your workflow process. This will ensure correct message routing and help resolve routing failures quickly.
The Convoy Deep Dive white paper and sample code is now available on MSDN. You can read the paper on-line and download the sample code here.
Microsoft has released 5 new White Papers today in a “Beta” mode. Full details on all 5 are available here.
In addition to all the other cool stuff available in BizTalk Server 2004 Service Pack 1 is the addition of the Additional Flat File Schema Properties to the schema properties window when working with Flat Files.
Microsoft BizTalk Server 2004 supports the use of convoy message processing, a new messaging pattern. Convoys are a messaging pattern and not a feature of BizTalk Server 2004. A convoy is not something a customer can use, like the Rules Engine, but instead it is something that the business process dictates and requires.
This paper discusses examples of business scenarios that require convoy message processing. After establishing a business need through the scenarios, this paper explains basic convoy theory and the different types of convoy messaging patterns. This paper discusses a solution to each business scenario and reviews each included sample.
View this whitepaper online at: http://msdn2.microsoft.com/en-us/library/ms942189.aspx
Today I was working on some content for Tech Ed when I found a major error in a sample I posted about 4 months ago.