Using Classes and Methods in BizTalk Orchestrations

Question

I have inherited supporting and making BizTalk applications as part of my development role. I'm a general C# developer so I was pleased to see I can create Classes and call the Methods from the Expression shape of an Orchestration. This means I can do all the data manipulation using code I am familiar and faster with rather than learn the BizTalk ways.

At this point I am not concerned with if it's a good idea or not.

Are there any purely technical reasons I should not do this?

Answer 1

You would have to make sure that whatever external methods you are calling is muli-threading capable and can handle high throughput.

If you don't achieve the above then you will either get some very strange issues (caused by cross thread contamination) or you will cause a bottle neck in BizTalk which will reduce message throughput.

You also need to make sure that errors are handled, retried and propagated back correctly to the calling Orchestration on failure. I came across one solution where the developer for some reason had decided to call a web service using an external class. Every so often this web service would throw an error, but the class would just pass the error message as it was back to the Orchestration as if it was a valid response message. This would cause a failure later on in the Orchestration when it tried to use the message and it did not match the expected message. When I got allocated budget I replaced this class with a properly configured send port, which also automatically retried the message when it encountered the web service error and then it successfully processed.

Answer 2

Technically you are adding deployment and maintaining complexity with the externals assemblies, for example any change in some contract will require changes in the assembly and the orchestration. And you're losing all the advantages of the BizTalk mapping engine for data transformation which is in general an easy part to learn.

Answer 3

I say this, it's very important for future maintainability to develop BizTalk apps in the "BizTalk Way".

For example, if you did message manipulation in an external class that should have been done in a Map or with XPath, I would fail that in Code Review and you'd have to refactor.

The reason is because whoever might take this over from you should expect a BizTalk app. I've seen situations such as you describe and it does make it harder to upgrade, enhance, support new business requirements because now the developer has to accommodate the BizTalk and external processes.

Answer 4

Technically using .NET classes does not break anything in the BizTalk. Lots of BizTalk components are based of .NET framework such as Adapters, pipeline components etc. In my view, use the best of both BizTalk and .NET depending on the scenarios. eg if you need to map an inbound XML to outbound XML use BizTalk maps as they are lot easier and quicker to implement, in this scenario using a .NET class is more tedious then using map. I don't think there is a big learning curve in using BizTalk features such as Maps, orchestrations, pipeline components.