Biztalk future - it won't going to die soon

I think that in the last two years there was a lot of online BUZZ regarding the Biztalk Server will go out of support.
I believe that this won't happen in the nearest time.
Microsoft can't kill its middleware Integration solution. There are thousands of production Biztalk environments world wide.
Biztalk will stay as a on premise server solution for some time, yes Microsoft roadmap is to move toward the  cloud solution. AppFabric with Service Bus, Integration Services, Cache Service and other services will eventually implement the current Biztalk capabilities, the solution won't be called Biztalk.
Microsoft aims to create a single middleware solution for cloud and On-Premises projects.
Today Microsoft focus is on the cloud. And it will take time , years, to implement Biztalk functionality on the AppFabric cloud solution.
Migration probably won't be smooth but eventually it will work, from what I saw online the migration process won't be able to handle whole applications, only artifacts (Orchestrations, maps, pipelines and ...).
But I am sure that Microsoft will provide the needed support in a reasonable TCO to move from Biztalk Server to the AppFabric next-Generation middleware solution.

Microsoft will continue to the develop and invest in Biztalk Server project till the cloud AppFabric project will have the needed and current Biztalk capabilities.
The Biztalk project will be evolved in a moderate speed and investment.

Biztalk has a great integration features, like:

• Orchestrations - machine based integration flows, custom XBPEL files. The current .Net developers familiar with the Windows Workflow Foundation (WF). In the last 2010 version you still can't execute the WF on Biztalk runtime engine, but it is part of the product roadmap.
• PUB/SUB engine - everything in Biztalk is based on the Publish/Subscribe patterns against the MessageBox DB for prof and cons.
  This architecture is a major pitfall for low latency solution. But on the contrary it enables loosely couple integration solutions.
  For low latency you can combine Biztalk map and adapter functianlity with WF in a regular .Net project in VS2010 and above. 
• Integration by  Windows Azure Connect  with Azure windows services.
• B2B - EDI, SWIFT
• BAM
• BRE
• ...

A nice recorded presentation from the WPC2011 by Tony Meleg's provides Microsoft long time strategy and commitment for Microsoft's Application Infrastructure future.

In conclusion 

Biztalk will stay in the market for a long time, eventually Biztalk capabilities will be implemented on the Azure AppFabric solution.

Consuming Web Service with SOAP header by Biztalk 2006

There are a lot of information about this subject on-line,
but I think that it not so correct.

The steps to create a working solution are :

1. You need a WSDL which includes the declaration of the SOAP headers elements that are needed. It won't work if you define an external schema for it. as it is described in many posts.

2. Create a property schema with the target namespace set to http://schemas.microsoft.com/BizTalk/2003/SOAPHeader, the root node name set to exactly the same as the root node name in SOAP header, and the Property Schema Base property set to MessageContextPropertyBase.

3. Set the context of the request message with a XML of the SOAP Header structure.

XMLDOM = new System.Xml.XmlDocument();
XMLDOM.LoadXml(@"123456Silver"); WSReqMsg(SubmitPurchaseOrder.SOAPHeaderPropertySchema.Priority) = XMLDOM.InnerXml;


If you have an WSDL which not defines SOAP Header but it's needed (like WS-Security or WS-addressing) by WS provider you will need to ask the provider to provide updated WSDL or to update it by yourself. Otherwise it won't work in Biztalk 2006 with SOAP adapter.

If you need to update the WSDL I suggest you to do it by exposing Orchestration as Web Service with the Web Service Wizard tool. You can use the defined property schema and you need to define custom schema which will include the needed SOAP Header.
During the wizard you can choose to expose SOAP Headers.

In Biztalk 2006 R2 and later you can use WCF adapter which solve this issue without the need to update WSDL.

MQSeries 2.0 Adapter Latency HotFix

If you working with the MQSeries 2.0 biztalk adapter and letancy is your concern you definitely need to install this hotfix.
By this hotfix you change the adapter working mode from polling to event driven when receiving messages from queue.

optimize Biztalk projects by using outer mapping tools

I suggest everyone who work with biztalk to look at the xslt the mapper makes. You will be amezed with the poor xslt that it generates.

There is a good feature in the map properties which allows you to insert xslt for the map to run.
My recomendation is to use biztalk map only as a host and to make the xslt with other tool like Altova MapForce.

By this you will gain better performance of the mapping process.

Memory Leak using Biztalk mapper

In one of our ESB projects that I worked on with my team we encountered on a huge memory leak issue with biztalk projects. In our project we had a couple orchestrations and maps (simple, only text functoids).
The problem was that after running the map the first time the memory usage jumped for 200-300 MB. After working on 4/5 messages the biztalk host service took about 2 GB of memory. And with no load at all messages began to stuck. Messages run into message box but no dequeue was made at all (Tracking DB).
The messages was about 1-2 kb size and the orchestration was standart work flow, without any looping.

After some resarch made by us and my work colegue Matanya Weinshtock that found the next kb :
http://support.microsoft.com/kb/918643

summary of it :

The System.Policy.Security.Evidence object is often used in transforms and can consume a lot of memory. Whenever a map contains a scripting functoid that uses inline C# (or any other inline language), the assembly is created in memory. The System.Policy.Security.Evidence object uses the object of the actual calling assembly. This situation creates a rooted object that is not deleted until the BizTalk service is restarted.Most of the default BizTalk functoids are implemented as inline script. These items can cause System.Byte[] objects to collect in memory.

Suggested Solution by Microsoft

To minimize memory consumption, we recommend that you put any map that uses these functoids into a small assembly. Then, reference that assembly.

The Solution

We decided not split each map to different assemblybecause as you can see at kb almost all of the functoids are implemented with inline scripts.
I suggest the next develop metodology with biztalk project :

Alwayes split the project to at least three projects :

1. Schema project.
2. Maps project.
3. Orchestration project.
   

with this develop metodology we succeded to almost stop the leaking at all.

Again don't take biztalk as It is simple and supposed to work, always check it.

MQ correlation set initialization in biztalk

WMQ manager can generate a unique message id (MQMD_MsgID) for you if you put message to queue with MQMD_MsgID set to null.
In MQ/MQC biztalk adapters there is a great feature to get the MQMD_MsgID after putting the message to WMQ queue using solicit response port. After putting the message to queue you get an xml which includes the MQMD_MsgID.

So if you want to send a request and get the response by WMQ you need to do the next steps :

1. Create send solicit-response port, configure it to Mqseries/MQC adapters.
2. Create Correlation Set based on MQSeries.Biztalk_CorrelationID
   
1. Add Mqseries.dll to your project, from Biztalk bin directory.
2. Create the correlation type,You can make the correlation only by the MQSeries.Biztalk_CorrelationID because the adapters update it automatically. On send to queue they copy the MQMD_MsgID to MQSeries.Biztalk_CorrelationID and on the receive the adapter copies the value of MQSeries.Biztalk_CorrelationID to MQMD_CorrelationID.
3. Initialize the Correlation set using "dummy send" port (Null/Nope adapters)
   You cannot initialize it on the receive shape like in the following orchestration , because you will get this error when compile : "in a sequential convoy the ports must be identical" .
   
   
   
   you get this error because biztalk cannot determine which message it will get first, the message of the solicit-response (receive shape which initialize the correlation set) or the message of the response followed up the Correlation set.
4. Set the follow correlation set attribute on the needed receive shape.
   
   enjoy
   
   

<

Biztalk and MQ Correlation Set with NOPE/ NULL adapter causing Race Condition.

In my integration scenario I needed to implement request/response interface between application running on Mainframe (Supplier) platform and windows (Biztalk ) . The communication between the platforms done with WMQ.

General MQ Stuff

In WMQ you have great feature for Correlation. When putting a message to a queue with MQMD_MsgID set to Null, WMQ Server generates a unique ID for this message and thus you can correlate the transaction with this MQMD_MsgID. The supplier get the message from queue, do it's stuff, sets the Correlation_ID of the response message to the MQMD_MsgID of the received message and puts it to queue.
All the client need to do is to listen on the queue for a message with Correlation_ID equal to it request MSG_ID.

Biztalk implementation

Biztalk support this way of work with it's MQSeries/MQC adapters using the solicit response port type. When issue the put to queue command with the adapter, you get the MQMD_MsgID which was assigned to your message by the WMQ Manger. The adapter copies it's also to the MQSeries.BizTalk_CorrelationId, thus you can work only with it and not using the MQMD_MsgID/MQMD_CorrelationID (on receive).

To implement this you need to do the next steps, by best practices :

1. Create solicit-response port for the destination wmq queue.
2. Create Correlation Set based on MQSeries.BizTalk_CorrelationId. this context property will be initiate automatically by the adapter with the MQMD_MsgID created by the WMQ Manager after issue the send to queue port.
   
3. Create "dummy send" port for dev null/ NOPE adapter for the Correlation Set initialization. (*)
   
4. Setting the Correlation set on the receive shape, waiting for the responce. The adapter will set the MQSeries.BizTalk_CorrelationId with the value of the MQMD_CorrelationID.
   
   (*) see my previous post on this subject.
   

The Problem

seems simple yes, but there is a huge problem in step 3 and 4 because they are not an atomic transaction.
What will happen if biztalk will get a response message prior the setting of the Correlation Set, you will get the no subscribers error, because the Orchestration did not succeeded yet to subscribe it self in the message engine for this particular message.

We got a Race Condition problem.
Yep I got it , the roundtrip of the message from Biztalk to Mainframe , suppliers work, and back took less time than the Correlation Set initialization in biztalk. Surprised I WAS too.


Solution

So to solve it I needed to write my own code for unique message id generation and set the correlation set before sending the request message with it.

Summery

Be aware of biztalk publish/subscribe latency.
On my next post I will give some tips for it optimization by administration table configuration. In this scenario it didn't help.

Biztalk SQL Server management and optimization

I found two great posts about biztalk server 2004/2006 DB optimization, deadlock solutions.
I suggest everyone who work with biztalk to read this posts.

1. http://support.microsoft.com/kb/917845
2. Biztalk core engine's WebLog - What you can and can't do with the Messagebox Database server.
   

Summery :

• Don't enable/use statistics.
• Shutdown the parallelism.
• Don't built maintenance plan for indexes, use only bts_RebuildIndexes stored procedure, shutdown biztalk engine first.
  
• Don't change the stored procedure code.
  

enjoy,

Biztalk 2006 MQSC adapter

Hi,

In this post I will explain the benefit of the MQSC (WMQ native api client adapter) over MQS (COM+ server adapter).

When working with wmq and Biztalk on multi server environment I suggest to work with the MQSC adapter and not with MQS adapter.

Because of the following arguments:

• MQSC Support clustered MQSeries Queue Managers.
• The MQS adapter make subscriber for each clustered queue, even if it is the same
  queue, but on different qmgr. Creates duplication of messages.
  
• MQSC Support clustered BizTalk servers.
• You can't difine with the MQS adapter a dynamic recieve loaction. Works only with local Qmgr on the biztalk application server.
• The COM+ level overhead of the MQS adapter.
• Can define by WMQ channel table file a simple fail over mechanism, using the wild char "*" in the qmgr name.
  

You can get the inforamtion about the MQSC adapter here :

http://msdn2.microsoft.com/en-us/library/aa772116.aspx

When using the MQSC adapter it is very important to set the transaction mode on (default off ) when integrating with WMQ queus. Otherwise duplication of messages can occur.