InBound/OutBound Maps with same MessageType- Order of Execution

Few days ago, there was a question in Biztalk forum which has triggered this post of mine.It was about the sequence in which BizTalk will execute the inbound maps configured in a receive port .

As we know, when two maps “Map A”  and “Map B”  that takes different input schema types  “Schema1” and “Schema2”  respectively will behave as follows.

When “Schema 1″ is received,” Map A” executes and for “Schema 2” it will be “Map B”.All is well till this.

What happens when multiple maps with the same schema type are input configured as inbound maps. Say the maps are taking the inputs as follows.

INPUT         MAP NAME OUTPUT
Schema 1           Map A               Schema 1
Schema 1           Map B               Schema 2
Schema 1           Map C               Schema 1

In this case, BizTalk will execute only one of the maps when an XML instance of “Schema 1” is received even though all the three Maps should have.But this is not the issue on focus..Things were well until this question raised. Which of the maps will execute?

Will they execute in the order they are configured in the port – NO.

Or in the order of their names- NO.  So how it works. Here are my findings on this.

I tested this scenario by configuring 3 maps A, B and C and all taking  the same “Schema 1” as their input. I added a C# script in all the maps to write the map’s name in the event log when it executes. This way we would know which map got executed.

This is how my port was configured.

Map Configuration in the Port

When Schema 1 was posted to the receive location, the event viewer log confirmed that “Map C” was executed.But,Why Map C?

After a few hours of search in the management database, I found that “admsvr_GetRecvPortTransformAssemblyName” is the SP responsible for selecting the map to execute.

 

Stored Procedure Code

1. BizTalk picks the “MessageType” of the received msg(Promoted by XMLReceive pipeline ).It will be “http://MapTests.Schema1#Root” in our test scenario.
2. Checks for this MessageType in “bt_DocSpec” table and picks the corresponding “docspec_name” column’s value.It will be “MapTests.Schema1” in our case.
3. Picks the receive port’s GUID from “bts_receiveport” table.
4. Inner Joins the results from points 2 and 3 and  gets the list of map IDs matching these conditions.

The result contains the GUIDs of  all maps that takes “http://MapTests.Schema1#Root” as input and configured for this receive port.

There were 3 GUIDs returned(one for each map A,B&C) when I executed the  first highlighted part of the SP with our test case inputs.

SELECT @nMapID = ms.id FROM bt_MapSpec ms

INNER JOIN bt_DocumentSpec ds ON ds.docspec_name = ms.indoc_docspec_name

INNER JOIN bts_receiveport_transform rpt ON rpt.uidTransformGUID = ms.id

INNER JOIN bts_receiveport rp ON rp.nID = rpt.nReceivePortID

WHERE ds.msgtype =“http://MapTests.Schema1#Root”

AND rp.uidGUID = “4c160275-98c6-4f60-a0bf-9c9b5ccd958b”

AND rpt.bTransmit = “False”

The result was as follows.

MapIDs returned

Since “SELECT @nMapID = ms.id” in the query will always hold the last value of the result returned, @nMapID will be equal to ”68bfd6c1-eb61-40e4-9dec-a183a4f189fd” in our test scenario.

I customized the second part of our SP “admsvr_GetRecvPortTransformAssemblyName“ a little to take in all the GUIDs returned(for our understanding and analysis) that we just obtained as result.(Remember our @nMapID is actually having only ’68bfd6c1-eb61-40e4-9dec-a183a4f189fd”) .

SELECT ba.nvcFullName, bi.FullName FROM bts_assembly AS ba

INNER JOIN bt_MapSpec AS ms ON ba.nID = ms.assemblyid

INNER JOIN bts_item AS bi ON ms.itemid = bi.id

WHERE (ms.id IN (‘6abc55b3-24b1-4c9a-9919-84e6ca81cf25’, ‘761be6b1-f7e8-4bc7-b855-8d99203df47c’, ’68bfd6c1-eb61-40e4-9dec-a183a4f189fd’))

The result of this query resolves half the mystery.

Query Results

So, the MapName for the GUID that @nMapID holds will be “Map C” which will be the one that executes.

IMPORTANT POINTS – MUST READ:

• This order of the result IS NOT THE SAME  and changes if anything gets deployed. I tried deploying another set of maps that are not related to our sample project and our test scenario executed “Map A” instead of “Map C” this time but our query returned “Map A” as the final row.
• BUT the last row of the result from the following query will be the map that executes. SELECT ms.idFROM bt_MapSpec ms INNER JOIN bt_DocumentSpec ds ON ds.docspec_name = ms.indoc_docspec_name INNER JOIN bts_receiveport_transform rpt ON rpt.uidTransformGUID = ms.id                                                                                         INNER JOIN bts_receiveport rp ON rp.nID = rpt.nReceivePortID                                                                                                                WHERE ds.msgtype = <MessageType> AND rp.uidGUID = <ReceivePortGUID> AND rpt.bTransmit = <PortTransmitType>
• Maps that have multiple Inputs cannot be configured  EXACTLY as InBound maps. Eventhough they can be configured, the first input schema that was used while developing the map will be used as input.                                                                                              REASON: BizTalk runtime’s decision of the map to execute also depends on the “MessageType” property(as we saw in the SP).Thisgets proved at “WHERE ds.msgtype =” of the SP “admsvr_GetRecvPortTransformAssemblyName” . Here it takes only one messagetype and hence thus one input.
• MessageType MUST be promoted to have the InBound Maps work. Passthru will not help.
• These applies to the OutBound Maps as well.( the SP names and tables are different but follows the same naming conventions as the ones related to InBound maps).

CONCLUSION:

Even though we can find how the map selection happens during execution, in an environment where multiple deployments happen, the order in which the SP returns the result will keep varying thus leaving the Map that will be executed unpredictable. So, Watch On!