I was watching History channel last night and they were discuss the Napoleonic wars. One of the main strategies used was “divide and conquer”, and it is normally a strategy that I talk about when doing BizTalk development. One of the main purposes of this blog is to give some reusables samples and walkthroughs that can be used as a template for other BizTalk projects. I am hoping that each of the pieces that I am providing can both demonstrate a concept and be used as a template for pieces for other larger BizTalk projects.
When I talk about “divide and conquer” with BizTalk, I am trying to show that you may be tempted to build the workflow of your orchestration and then add your ports and maps and schemas and then deploy it. For a simple workflow this is easy, but when you have a more complex workflow, this can become more cimbersome and difficult to maintain. You may end up sepnding a lot of time in Health and Activity Tracking for trivial issues. What I normally suggest is drawing the workflow, create several small samples that are just pieces of the full orchestration, get each piece working, add them to the full orchestration.
For instance, if you have a workflow like the following that processes an address change for a customer across multiple systems.
1) Receive a document from an external source (SAP, mainframe, FTP etc..)
2) Use a MAP to translate it into a SQL friendly schema to do a database lookup.
3) Use a SQL Request-Response port to verify that it is a valid customer
4) If it is not a valid customer, use a map to translate a response back to the originating source that there is no customer like this.
5) If it is valid, use a scope shape and Request response port to SQL Server to update the customer information
6) Add another port to send a request to a web service which might be a wrapper to Seibel or some other CRM system.
7) Add another send port to update a contact list for an older legacy system that is still in use.
8) You can do this in a parallel shape as separate called orchestrations, but you get the general idea here.
In this case I advocate breaking each of these tasks down into separate orchestrations like the following.
1) An Orchestration that receives a document, applies a map and sends it back out. You can then view the Schema and make sure everything looks correct.
2) Create an orchestration that has a file receive port that you pass just the SQL Schema, have the SQL request-response port and then just add another send port for the repsonse. The flow for this will be receive, send request, get a response, and Send the response. Once again you can view the results and make sure everything is working.
3) Create an orchestration with one with a receive shape, Construct Message, translate, and send shape. This will be for the case of an invalid message.
4) Continue on like this with each piece until you have each piece working.
This might be a bit of overkill, but once you get each piece working you can go back to the main orchestration and simply start adding the Schemas, Maps, Shapes, and ports that worked before and hopefully will have already worked out the problems with any of the messages and schemas and maps without having to spend a lot of time using Health and Activity tracking.
This is just a suggestion that will hopefully save you some development time. This is more of an Extreme Programming technique (http://www.extremeprogramming.org/) with BizTalk, but I find it much easier to build and troubleshoot problems. You end up with your major orchestration and then various smaller pieces. You can then use the smaller pieces to troubleshoot problems as you see them and to test modifications to your maps and schemas before bring them back into the main orchestration.
Let me know if anyone else has any thoughts or other practices they use for developing BizTalk applications.
