Changing external assembly reference in Maps & Orchestrations

What do you do if for some reasons you have to change the name of external assembly that is being referenced by Maps and Orchestrations? The change can be for reasons like:

1) New SNK was created and hence the Public Token key changed. (Very rare to happen)

2) For some reasons the name of external assembly have to be changed. (We had to do this in our project. This was done in order to adhere to naming standards of Biztalk artifacts)

Standard way of doing this can be really tedious. As one have to go to each map and click on each "Functoid" and go to properties to change to new "Assembly name". Same thing will need to be done for Orchestrations.

If like us you have 20 maps with average 30 functoids per maps and 20 orchestrations then you need to keep 2 days aside for this "boring" job!

The second option can make your life easy and get you up and running in 30 mts as compared to 2 days. This is what you do:

1) Open the Map/Orchestration in Text Editor (Ultra Edit in our case)

2) Do a Find and replace in the whole file. "Find" "old assembly.dll" replace with "new assembly.dll".

3) Replacement will be done for "Assembly", "Class" and "Assembly Path" in the file.

4) Save the file and you are all set!! That easy!

Care should be taken while doing this operation as it is large scale "find" and "replace" operation.

Aggregating the "Split-Gatherer" Pattern using SQL

One of the limitations of BTS 2004 as compared to BTS2006 is its inability to “gather” the transactions it has split from the original file. “Splitting” can be achieved by combination of “Document” and “Envelope” schemas. In my present project, we needed to split the file and then add the “split” transactions on file -by- file basis. Presently, it is achieved by the “Convoy” design. This involves using “Correlation” dataset that waits for the field that is “correlated” (FileName in our case). It then adds all the “split” transactions for that file. Since we rely on “serial” processing as compared to “parallel” processing that orchestrations are intended for, this is not an optimum design. The major drawbacks of this approach is 1) It leads to “zombie” scenario in Biztalk. 2) Performance declines exponentially as the transaction volume increases.

These 2 scenarios were slowly taking menacing proportions. In order to counteract them our team came up with “SQL database” aggregator. It is simple in design and very fast. The files are split as before. But now each transaction is stored in SQL database as XML node. Parameters like Orchestration ID, FileName and Unique identifiers are passed along with the XML node. At the end the XML file is extracted by combining these nodes and using parameters passed to aggregate the correct transactions from the database. Stored procedures are used to Build the final XML .

Biztalk 2006 is cool!!

Finally I got some time to review 2006. Here are some features that you might find very useful in Biztalk 2006.

1) Calling Pipelines from Orchestrations using expression box

This can help in creating single common orchestrations for messages with different schemas as they can be routed using dynamic calls of "Pipelines" from Orchestration. This will be real cool!!

2) Flat File wizard for creating Schemas

This will be huge! From my experience, creating FF schemas are real pain. Imagine having wizard for it now.:)

3) Standard processing and Recoverable interchange process in Pipelines

In my present project we are using substantial .Net code to log the errors in pipelines. This actually slows down the processing time. This new feature will definitely help!

4) Can generate errors that can be subscribed by send ports using pass through. Use filter on original receive ports that we created. Catch the error message, change it and re process it. This is called “Failed message Routing”

5) POP for email receive

Biztalk 2004 CAN only send emails. 2006 will give ability to even receive and process them. Imagine activating Orchestration by sending an email.

6) Better BAM services

7) Interfaces

SAP adapter is standard with 2006!

8) Shared point adapter

9) Ordered delivery:

To achieve first-in-first-out or "Ordered" delivery is BTS 2004 we need MSMQ/T . But in BTS 2006, with little configuration the same thing can be achieved by using standard MSMQ. This is what is required.

1) Set Ordered Processing Property on Send Port
2) Set the same Order Processing property on Receive Port
3) Set MSMQ to transactional.