Service Logic Implementation
Hi,
I am trying to implement a service logic in BizTalk . The flow of data is such that once the BizTalk gets the initial payload it send it acro0ss to first application say A, this A will send back the response to BizTalk which again prepare some paykload and send it to B while receiving the response from B it will call A and C then it will compare the response from A and C depending upon which it will call D. Again response from D and C will decide whethere to call A or terminate the process.
Thus it will lots of recursive call to A and other application which can't be implemented through Loop Shape . SO whether in this case Ishould develop a single Orchestration or develop a number of orchestration depending upon the number of application that has to be integrated. But again recursive calling will be a problem and there will be lots of Orchestration parameter that needs to be passed between orchestration.
Please suggest me correct architectur to develop the Orchestration.
Thanks,
Hi,
First I completely agree with Ibrahim in that it's hard to give specific advice on a solution like this as we don't have the full picture and I think that the two patterns in his post could be very useful.
However, when that is said I'm gonna do the complete opposite and try and answer your question. 
As I understand your question you basically communicate with a number of systems after each other and use the response to decide on which system to communicate with next as you build up your end message. And as I see it some of your concern is if you should split your orchestration in sub-orchestrations to reuse the logic used to communicate with each system - right? And in your case that sounds like an ok idea to me. Having the mapping from your internal message format to a request message, the port and the mapping from the system response back to your internal format sounds like a good candidate for reuse to me - especially if your are going to call it multiple times as you are in your solution. However I think you should start as simple as possible and just get the thing working using one single orchestration. Then you can refactor this and move shapes that you can reuse into sub-orchestrations later in the process. That also makes it easer to determine the complexity in that and to decide if it's worth it or not (it's really easy to just cut and paste shapes into new orchestrations as you probably know).
Hope that help you some even if it's probably just simple common sense to you.
Richard Hallgren
http://www.richardhallgren.com
Thanks a lot Guys.
Here I am going to explain the architecture that I had adopted for developing a solution .
What I had done is I had divided the whole solution in three part
1. Orchestration A- for initiating the process and caallin those web service which are called only once.
2. Orchestration B- for the web services which we are calling recursively
3. Orchestration c- for the web services which are called by the Orchestratiob B and also return the result to B.
Thus in this way I was able to call recusively almost all the web service which need to be called from the orchestration.
