Sunday, January 26, 2014

Is it possible to have Map Chaining on the Port Level

Firstly, let's understand what is Map chaining: The process of producing multiple documents from a single document by executing several maps to translate the single document.

So is it possible on the port level?

This has two answers, Yes and No depending upon how and where it is applied. 

To find out the working, I created a project with three document schema (Item, Product and Article) and a couple of maps and deployed it:

1. Map1: ItemToProduct
2. Map2: ProductToArticle

Scenario 1: Map chaining on a single port (Receive/Send Port)

In order to test map chaining on a single port, I configured ReceivePort with two maps as shown below and a send port configured to receive Article message.







After dropping the message at the receive location, the message was suspended. To check the what processing was done on the message before suspending, clicked on the Message Flow and it was clear that the ItemToProduct map was applied and the message was submitted to MessageBox. 






The second map was not applied, and this is because there is a 1:1 relation between the message and map. So after that one map is executed, EPM (End point manager) hands over the message to MessageAgent which takes over the later processing part of submitting the message to message box and querying for subscription. If no subscription found, it suspends the message.


So Map chaining is not possible on a single port.


Scenario 2: Map chaining on combination of Receive and Send Port


In order to test map chaining using combination of Receive Port and Send Port, I configured ReceivePort with the first map and a send port with the second map as shown below.










After dropping the Item message at receive location, article message was created at the destination. Both the maps were applied. 



So it is possible to achieve map chaining this way, but in between the intermediate message has to pass through MessageBox.

Can We Have Multiple Maps With Same Source Schema On The Port


Is it possible to have more than one map with same source schema on a port? There are two answers for it Yes and No.

Why Yes -- BizTalk won't stop you from configuring multiple maps with the same source. As it's perfectly legitimate to have a port associated with multiple maps.

Why No -- Irrespective of how many maps you have configured on the port, only the map which matches the MessageType of the message will be executed. And as soon as the first matching map is found, other maps are neglected. As the relation between message and map is 1:1, a message can be processed by a single map only (If and only if it's source type matches).

Let's consider this through a scenario:

We have three maps created with the same source schema, but different destination schema as shown below:



To test we deploy the application, and configure the receive port with all the three maps, as shown below:



An Item message was dropped in the receive location and the output was Artifact message, only one map was executed by the runtime.
That happens to be the first map from below, so does that mean runtime looks for map from bottom to up sequence?

To clarify this, I removed ItemToArtifact map, and tested again by dropping an Item message at receive location. And this time output was Product message. So the order in which the map gets selected can't be predicted.

But only one map is selected against a message in spite of having many maps with same source schema.

Wednesday, January 1, 2014

An activatable receive must be the first executable statement in a service



Whenever we add the Orchestration to a project, the first thing which is done almost every time is to add Receive shape as the first shape.  That’s because we need to apply some process when some particular piece of info (message) is obtained. Thus initiating the process designed in the orchestration.

Well this raised a question, can’t other shapes be used as the first shape in Orchestration?
To find out, I added a loop shape as a first shape with a Receive shape within it. Logically it seemed correct as I want to receive messages until the loop condition is satisfied.



When clicked on build following error appeared





With all said it’s obvious to think that  the first shape has to be Receive Shape . Well there are exceptions, shapes  like Group shape, Scope Shape, Listen Shape, Parallel shape  and orchestrations configured with parameters to enable invocation from other orchestration.



Will keep sharing as and when find something!!!!! Happy New year to all !!!!!!!