Abhilash M S

Debatching and Batching in Biztalk 2004

One of the fairly common issue that most Biztalk designers face is the issue of Debatching and then Batching . Having faced a similar situation myself I must say that there is no best solution for this problme that I have so far come up with . Though there are different solutions that you could employ
Just to explain the problem first you have a set of files coming in say a folder ( transport does not matter ) and then each file consists fo a set of transcations . you need to process them indicvidually and then send them out as one file

The first instict is to use a Biztalk XML or flatfile dissasembler and then send the message to Messagebox ,and then process them independently. THe problem now comes of batching them back together.

Solution 1

Now if you have one file comeing in during an EOD process , doing ths split and then writing it to a file with append mode TRUE would do the trick ost of the times

But this is not a clean solution If you have more than one file coming in almost simultaneously this solution will not hold water as once Biztalk does thwe split it is not possile to identify the transactions to it's original source

Solution 2
A solution to this is to promote a context property in the pipeline and then in the orchestration decide which instance it belongs to create a unique guid based on the the context and then set the SourceFileName property and then use the append method
This is slightly more complicated as writing pipeline components is not the easiest things to do and you have to take care of your compoent to be streamig . Why it needs to be streamsing Read This

Pros: This is real Fast and great for CBR uses streaming XPATH

Cons: All or nothing. If something fails in the pipeline or map the entire message will be lost.


Solution 3

Another solution is not to split the message using the Docuement /Envelope schema and do this using XPATH . This solution makes us of XPATH to count and then uses XPATH to loop around message elements .To see a sample and a write up on this implementation try this


Pros: Excellent flexibility inside the Orchestration. Great control of the processing of your document! This process is sequential and ordered by default. Ability to loop over anything you can XPath and can easily (this is always a relative term) build mini-batches if needed. This is something Receive Pipelines are not able to do without extensive custom code.

Cons: Performance degrades quickly as message size increases. Downright slow on large messages and a resource hog. In some cases, the sequential and ordered processing of this type of debatching may be limiting to the process.



Solution 4
Ths issue with solution 3 above is performence when it comes to large messages ,Read the story of Biztalk and large files from Lee

The solution that we tried for our issue was to use a two stage orchestration. The first orchestration contains a map that promotes a unique value to an additional Node (effectively creating an intermediate schema) for every instance of the file.
This is then fed to a dissasembler but now each file retains information about its parent using the guid and then write out the guid value as file name with append mode on .

Solution 5

Send your output file out tho SQL and promote business fields that help you identify the batch use a SQL Receive port at periodic intervals to aggregate the result using some intelligent querying



So what is the best solution , It depends , as I said before there is no clean solution or a magic bullet .Depends really on the app that you are trying to build
but a thumb rule is for small messages you can get by with XPATH and go for pipeline based splitting for large messages

I welcome comments and opinions Ciao

BTS 2002 vs BTS 2004

I  have often been asked What is the big difference between Biztalk 2002 and 2004 , There are a lot to be frank But if I have to pick one , It will be the much better and unified subscribtion mechanism . If you want to learn more about Biztalk subscribtion Charles Young's Blog Post is a good start

Biztalk Cool stuff

Some of the good Biztalk cool Stuff available out there

BizTalk Server 2004 "deploy with Nant" template
Integrating BizTalk Server with Nant

BizTalk Server 2004 Pipeline Component Wizard 
VS.NET addin for quickly building pipeline components

BizTalk AutoDeploy Utility
VS.NET addin for quickly (re)deploying BizTalk Server solutions.  No need for Ant

BizTalk Server 2004 Performance Tool
Tool that allows for BizTalk Server tuning.

BizTalk Server 2004 Transactional .NET Adapter
adapter that allows for transactional message transmission to any .NET component.

BizTalk Server 2004 Tracking Playground
Tracking demo application showing how to make use of the tracking db views and WMI.

BizTalk Server 2004 Management Tool
This is good...

BizTalk Explorer
Doing what VS.NET allows you to do, without VS.NET :-)

BizTalk Server Service Windows
Allows for more flexible service windows.

BizTalk Server POP3 Adapter
Inbound email messages in BizTalk Server

BizTalk Server TIBCO Adapter
Rudimentary sample

BizTalk Server SQL BLOB Adapter
Readingand writing message to binary SQL columns.

Biztalk for Dummies

I have heard this was apopular question at MSFT interviews "How do you sell excel to your grandmother ?" well No this blog is not about that but then this blog is about how to explain Biztalk to a Business Analyst.One who is not so comfortable with all the geeky terms that we are so used to . I recently had to do one of these myself and I had to kind of get creative with ti . So thought I would just blog about that and see how it goes
Let us first take a look at the architecture of Biztalk from The MSFT Site


To put things in perspective let us consider this Huge Shipping Port were there is lots of ships , barges coming and going . Now I am trying to draw a parallel here

The Port basically deals in containers to carry Goods and Biztalk in XML to carry data

Containers or goods could be brought in using different modes of transport
Big cargo ships , small passenger ships , By Road at times , small Boats, It does not matter how the cargo is delivered into the port , it does not change the later part of processing of the cargo . Same is true for Biztalk which has a number of transport mechanisms like FTP , HTTP, SQL , SMTP , as in the port it does not matter how the data came in what matters is their routing information or who tgat data needs to go .

For identifying the destination of the Goods , This may go through Customs , Transit Inspection and maybe finally broken down to individual goods at times and goes to a cleared warehouse from where they are dispatched based on destination . The same thing happens in the recieve pipeline stage of Biztalk . The file goes through Dissasembly , Party resolution to the SQL server Messagebox . By this time incoming XMLSchema#RootNode is promoted based on which the message is picked up Orchestrations which do some processing on them and return them back to message box .
Consider this as importing some raw material like wood and doing some value add ( make them chairs for instance )
and then on the send side pretty much the reverse happens they are prepacked assembled and encoded and send out using approporiate transports available

What I described above is a publish-subscribe model . Now you can have messages in Biztalk follow a CBR ( Content Based Routing MOdel ) . In that case tha anology is a a conatiner which reaches a port for forwarding . or a transit port , here there is no signinficant value add on the goods but you can change some fringe level properties or change the way the data is represented

Epilogue
There are lot of flaws in this theory but for a person who is wuite new to Biztalk this is as good as a start as any.


PS: The views expressed in these essays are those of the author, and in no way represent, nor are they endorsed by Microsoft oranyone else, as far as I know.

Boy you never know these days , this legal-mumbo jumbo

Biztalk Accelerator for Rosettanet Releases

Biztalk 2004 Accelerator for Rosettanet released.I have been involved with the accelerator for some time in 2003 so I feel very good personally about this. It was really a great experience working at microsoft although I later moved on from seatlle I think this is the last of the Biztalk 2004 accelerators from Microsoft The key features Certified RosettaNet Ready™ RNIF 2.0. Full compliance with the RosettaNet Implementation Framework (RNIF) versions 1.1 and 2. Rapid development. Out-of-the-box implementation of all existing Partner Interface Processes (PIPs) Support for CIDX. Support for the Chemical Industry Data Exchange (CIDX) Chem eStandards version 2.0.2 Built-in management console. Built-in management tools for managing all RosettaNet-based trading partners and existing processes from a single console Orchestration of RosettaNet processes. BizTalk Orchestration Designer makes it easy for users to visually modify private processes and orchestrations that integrate with public RosettaNet business processes. Definition and documentation of schema. BizTalk Editor enables users to easily define and edit document schema for any structured document type, including all RosettaNet messages. Flexibility for custom RosettaNet solutions. The software development kit and comprehensive documentation help users develop tailored RosettaNet solutions.