none
Orchestration Design - One Receive Port, Multiple Send Ports RRS feed

  • Question

  • Hi there,

    I'm new to the Biztalk scene and would just like a little advice on desiging an orchestration if possible. The basic scenario is that our ERP system is going to generate a P/O request and pass it to Biztalk, the orchestration will probably be published as a webservice. The orchestration should then pick up which vendor the P/O is intended for (using the promoted fields) and pass it to that vendors' own orchestration (also published as a web service), to transform as necessary and pass on to the vendors own system in whatever format is required.

    Two questions really:
    1. Is that a good way to do it? Each vendors' own orchestration can then be updated and deployed seperately as necessary.
    2. In the main orchestration, what is the most efficient way of making the decisions. Bearing in mind we will have approximately 15 vendors to start with, increasing to anything up to 50 in the very near future. Should I be using the decision shape multiple times, i.e. check vendor code for match, if match pass to send port, if not, move on to next decision shape (could see this getting quite messy).

    Any pointers you could give me on this would be greatly appreciated.

    Regards,
    Terry.
    Wednesday, January 13, 2010 12:08 PM

Answers

  • Thanks for the answers folks, much appreciated. I'll look at each scenario, but I think the messaging only is probably the way to go on most. We will be getting synchronous responses from some supplier and asynchronous from others, so I'll have to work out what to do for the best there. At least now I've got some good info on which way to be heading with the development and can start some testing.
    Thursday, January 14, 2010 4:56 PM

All replies

  • Terry,

    IMHO you should use a messaging only scenario for this, unless there is the need to do more processing on the messages other than mapping them to the vendors format.
    Just let the receive location post the message from the ERP system to the messagebox, promoting the required fields. Set up a send port per vendor with the appropriate filter for this vendor an add a map to the sendport for transforming the message in the required format.

    Regards,

    René
    Wednesday, January 13, 2010 12:28 PM
  • You can add branches to a decide shape in an orchestration rather than cascading multiple decide shapes. But this is probably not the best way of doing this.

    I would have one orchestration consuming the P/O from your ERP. This orchestration would perform any logic required and then publish this message using a RoleLink or a single Direct Send port.
    Each vendor would have a send port, which would map your internal P/O  into a vendor specific message and send using a vendor specific protocol.

    You could use a RoleLink in your orchestration, which will match your the output message from your orchestration to a send port based on specific promoted properties (i.e. DestinationPartyId) - this can get a bit tricky.
    Alternatively you could use a Direct port on your orchestration and set Filters on each send port to subscribe to a message with the correct vendor identifier. You would promote the vendor identifier into the message context inside your orchestration

    This way you only need to add a send port  and a map for each vendor. You do not have modify a central routing orchestration and redeploy.
    Wednesday, January 13, 2010 12:41 PM
    Answerer
  • Hi Terry,

    Is your ERP system expecting just the ack message from your web service (asynchronus) or is it is waiting some kind of response that you can generate after processing (synchronus).

    In case your webservice is just returning the ack message, then you can promote property like vendor and write it to the message box using direct port.  Depending on your requirements, you may have one send port per vendor and have filter in the receive ports and maps in receive locations for transforming to vendor specific schema.  Alternatively you can have orchestration for each vendor (if you need some logic/processing suitable in orchestration).  The orchestration will get the message from MessageBox based on the promoted property vendor.

    In some situation, synchronus processing is unavoidable.  In that condition, one master orchestration may call sub-orchestrations based on some logic.  This is not very likeable solution as it is very tightly coupled. 

    Please try to design your solution in such a way that it just acknowledges to the ERP system that it received the message and then do rest of the processing asynchronously as mentioned in second para and also suggested by Greg and Rene.  You may send the confirmation number or any such vendor related information back to ERP system asynchronously using some methodology afterwards. 

    Regards,

    Tariq Majeed
    Please mark it as answer if it helps
    Thursday, January 14, 2010 3:37 AM
  • If you HAVE to use orchestrations (multiple transformations, etc), then the best approach would be to use a combination of the Business Rules Engine to 'decide' where the data is going: 15 to begin with, but more coming down the pipe, and then the BRE sends back some information that gets promoted with the message and it gets sent to the next orchestration. In this case you would want to use the Inverse Direct Binding so you can continually add more and more orchestrations to your solution. To learn more about it, Kevin Lam has a great couple of blog articles on how to do it: http://blogs.msdn.com/kevin_lam/archive/2006/06/14/631313.aspx
    Eric Stott [http://blog.biztalk-info.com] - Mark as Answer if this reply does.
    Thursday, January 14, 2010 6:24 AM
  • Thanks for the answers folks, much appreciated. I'll look at each scenario, but I think the messaging only is probably the way to go on most. We will be getting synchronous responses from some supplier and asynchronous from others, so I'll have to work out what to do for the best there. At least now I've got some good info on which way to be heading with the development and can start some testing.
    Thursday, January 14, 2010 4:56 PM