none
One Http Receive location and Multiple Orchestration Bound to it. RRS feed

  • Question

  • Hi All,

    I have a base application called A. It only has a Receive Location of HTTP type.

    I have N different applications which have the receive location of HTTP type. I have added the reference of the Application A to each of these N applications and bound my N orchestrations to only the single receive location in Application A.I have tried hitting different orchs using the same receive location and it works fine.

    I want to know what are the pros and mainly cons of this type of the architecture. Please provide your valuable suggestions.

    Thank You.

    regards,

    Mandar Dharmadhikari

    Thursday, June 19, 2014 10:27 AM
    Moderator

All replies

  • the cons is that the since the N applications are dependant on your Application A.

    if you want to update Application A, i mean if you want to redeploy , you have to first remove this Application A reference in all those referred N applications.

    And pros is you already experienced, you can use in any other applications.


    Please mark the post as answer if this answers your question. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, June 19, 2014 10:33 AM
  • Hi Ravindar,

    I completely agree that it will be nightmare deployment wise. But other than that are there any disadvantages of inter application referencing?

    Regards,

    Mandar Dharmadhikari

    Thursday, June 19, 2014 10:37 AM
    Moderator
  • No, the issue is pretty much to full extent the problems you will encounter during deployment. This is due to constraints set in the management database. Applications are only used on a more logical scale in BizTalk. They have more or less nothing to do with the actual processing logic underneath, but provide you with a way to group artefacts and configuration to ease administration (except for deployments of course).

    Thursday, June 19, 2014 10:42 AM
  • With your application structure, you will be triggering multiple processes/orchestration when you receive a message from application-A’s HTTP receive location.

    There are more cons than pros (other than reusability) with this structure.

    Your multiple orchestrations are tightly bound to application-A’s HTTP receive location. Try to have direct bound Orchestrations in this case.

    Your flow seems to have message distributor where your receive the message from a receive location and number of different processes for the received message. Deployment  would be an issue and manageability would become an issue in long run.<o:p></o:p>

    (Sometimes it may not be possible to suggest something just based on application structure, you got to know the business requirements)



    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.


    Thursday, June 19, 2014 10:43 AM
  • well..application referencing is actually suggested because you will be reusing the existing components.

    if maintenance is not a problem for you, then i think you can go for it. I don't see any major disadvantages


    Please mark the post as answer if this answers your question. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, June 19, 2014 10:44 AM
  • Yes Ashwin's point is to be considered here, if that creates a tightly coupled architecture, then it is not suggested.


    Please mark the post as answer if this answers your question. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, June 19, 2014 11:01 AM
  • If you have the receive port/location (and no other artifacts or references) in Application A, the chances of any risk is very limited.

    Moreover, you need to reference Application A in other applications if and only if you have opted to use "Specify Later" binding. It is recommended to consider using direct binding, if possible.


    Thanks, Murugesan M - Please Mark as the Answer, if this answers your question. Please vote as helpful, if this post is helpful.

    Thursday, June 19, 2014 12:17 PM
  • While there's nothing technically wrong with it, I would not reuse a Receive Location like this.

    The only reason I would consider and offer is that by sharing the Receive Location, you cannot stop the message flow on an individual Application basis.

    Thursday, June 19, 2014 12:26 PM
    Moderator
  • Dear BoatSeller,

    can You please explain it in a bit detail?

    Thank You,

    Mandar Dharmadhikari

    Monday, June 23, 2014 7:24 AM
    Moderator
  • Hi Mandar ,

    It realy depends on the granularity  of the solution which you are providing . By single receive location you dont have much control on the data flow of other child Orchestration which again can casue you the tightly coupled between your application .

    So its always advisable to have a Architecture structure where you have fine control over the BizTalk Artifacts ,Message flow and  better way to deal with the exception.

    Thanks

    Abhishek

    Monday, June 23, 2014 8:16 AM
  • Dear BoatSeller,

    can You please explain it in a bit detail?

    If you have AppA and AppB both sending messages to Receive Location A, you cannot stop incoming messages from AppA or AppB individually.

    So, it there was a problem with the BizTalk app that processed messages from AppA, you'd have to stop processing AppB messages as well in order to fix it.

    By using separate Receive Locations, you can pause AppA or AppB independently.

    Monday, June 23, 2014 12:16 PM
    Moderator
  • Can we avoid this using Direct Bound ports or are there any cons in  that approach also?

    Regards,

    Mandar Dharmadhikari

    Tuesday, June 24, 2014 12:47 PM
    Moderator
  • Again the same ,

    If you are bounding the receving Orchestration direct to message box, than you dont have control over the Message flow ,say you want to shedule the Orchestration to run on a specified interval of time .

    See all depends on what you want to achieve and what is the business requirment .

    Depending upon the requirment you need to find the best feasible method to implement your Schenrio.

    Thanks

    Abhishek


    Tuesday, June 24, 2014 12:52 PM
  • Can we avoid this using Direct Bound ports or are there any cons in  that approach also?

    When you say "Direct Bound", do you mean from the Orchestration perspective or BT Admin perspective?  The terms in the UI are slightly overlapping, though mean different things.

    Either way, it's really not a pro/con debate, they work mostly the same. The only difference is that using a Specify Later Port in the Orchestration, then Binding it in BT Admin add a specific Subscription entry for that Port in addition to the MessageType and any other Filters you may have added. So, that Orchestration Port will only receive messages that came from that one specific physical Port.

    Tuesday, June 24, 2014 1:43 PM
    Moderator
  • Dear Boatseller,

    Please let me explain my doubt in detail.

    I created N orchestrations all having differnet functionality.

    2) I used the direct bound port on the recieve location on each one of the orchestrastion.

    3) I deployed all of the orchestrations

    4) In admin console i created only one HTTP recieve location and I started hitting the orchestration

    Here everything went fine the messages were routed perfectly to the required orchs.

    My question is whether is it a good approach or not??

    Saturday, June 28, 2014 2:59 PM
    Moderator
  • Yes, that's perfectly fine.

    Saturday, June 28, 2014 6:35 PM
    Moderator