Powered By Blogger

Wednesday, January 7, 2015

Compensation Through Orchestration In BizTalk

Hi there,

Have you ever thought of rollback of a process through orchestration in BizTalk? Well, compensation is the feature which does that. Infact,compensation is the most underrated and underused feature in biztalk. A few days ago I was working on a R&D for a project to find out the features provided by compensation and to my surprise it stood to my expectations. But in this post, it would be difficult for me to explain the concept of compensation but rather I would be explaining the process which I incoporated in my sample project. I would advice you all to go through this fantastic blog by
Charles Young which clears the concept of compensation with transactions.Also, a very important point to keep in mind is that compensation works with those transaction which commits.

My Process







Explanation Of The Process:

The above process is a simple example of compensation on a customer order. In this sample i took one schema with two root nodes - CustomerDetails and OrderDetails with a one promoted common field (OrderID) for correlation.




In my process i've used L-R transaction for each scope (Scope_Customers and Scope_Orders).Scope_Main is also L-R and kept my whole orchestration as L-R.
Each scope has a compensation block with its respective logic for rollback - i.e. delete operation.
The whole process is a simple insertion process in which first the customer detail gets inserted followed by the order details. And the logic of the process is based on the fact that if any of the two individual L-R transaction scope fails then rollback happens i.e. compensation block gets fired if an exception is caught by the main L-R scope. 

Scenario:

The process is fired and insertion of customer details are done. Now insertion of order details starts, but what if  due to some issue an exception is caught and insertion of order detail fails? In this case compensation acts as a handy feature which roll backs the insertion done in customer table because it got committed. When the exception is caught by any of the exception handlers which resides in the main L-R scope then the respective comensate shape will get fired and will refer to the defined scope (In this case, Compensate_Customer will get fired  on Transaction_Customer).
Also, I've kept a tracking variable- Status (of boolean type) for the decide shape which fires an Email to the developer that an exception has been caught and rollback got initiated.Status = 0 is for no exception and should be kept under expression shape of CustomerInsert and OrderInsert.While Status = 1 should be kept under the expression shape of  each of the exception handlers.

Expression Shape Contents In Customer_Insert Scope

Expression Shape Contents In one of the exception handlers




Also, keep the synchronized property of each of the individual transaction scope(Customer and Orders) to True if you want exception to be caught and keep the RetryCount and RetryInterval on each of the send ports to 0.

Compensation can be used with atomic transactions also but i didn't use atomic transaction in my process as i was consuming services from a request-response port (WCF-CUSTOM) and atomic transaction doesn't allows that.

Hope this post comes useful to those who were confused with compensation like me :)

Thank You.

Regards,
Saurav Suman
Software Engineer @ Agility