none
How to route messages to Orchestrations based on Promoted Properies? RRS feed

  • Question

  • Hi,

    I was hoping for a bit of advice. Currently we have a BizTalk application which receives XML messages, via AS2, which are routed to 1 of 2 Orchestrations based on the message schema. I've got a requirement that messages with a certain promoted property value take a different route, namely going straight to a Send Port and skipping an Orchestration entirely.

    I believe that it's possible to set a filter directly on the Send Port so that the port only subscribes to the required messages. But how can I filter what goes to the Orchestration? I expect without a filter in place the Orchestration will be subscribed to the messages intended to go to the Send Port as well as the messages intended for it. As the split of messages going via Send Port vs the Orchestrations is going to be changing over time, I would rather handle this through configuration rather than making changes to the Orchestration and redeploying each time.

    Using BizTalk 2013 R2 and the current basic setup is as follows. We receive messages over async-AS2. A Send Port writes the AS2 payload to a Folder, which in turn gets picked up by a Receive Port (XML pipeline and inbound map). The Orchestration(s) bind to the Receive Port rather than directly to the MessageBox.  

    Any advice will be greatfully received.

    Thanks in advance

    Tuesday, February 13, 2018 9:34 AM

All replies

  • Hi,

    You should be able to use the "Filter Expression" property on the Receive shape in your Orchestration to further filter which messages are received.

    Br,
    Leo


    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!

    Tuesday, February 13, 2018 9:56 AM
  • Can you please explain the following?

    As the split of messages going via Send Port vs the Orchestrations is going to be changing over time, I would rather handle this through configuration rather than making changes to the Orchestration and redeploying each time.



    Mandar Dharmadhikari

    Tuesday, February 13, 2018 10:04 AM
    Moderator
  • Can you please explain the following?

    As the split of messages going via Send Port vs the Orchestrations is going to be changing over time, I would rather handle this through configuration rather than making changes to the Orchestration and redeploying each time.



    Mandar Dharmadhikari

    The messages contain a reference to a cost centre. Overtime we will be transiting the various cost centres from the current process (which uses the Orchestration) to the new process (the Send Port).

    I would prefer to avoid having to modify, compile and deploy the Orchestration each time we transition a cost centre. I would rather just change a value (or two) in the BizTalk administration console (i.e. configuration). The values would then be readily visible within the same tool, rather than one of the filters being set within the deployed Orchestration.

    Tuesday, February 13, 2018 10:45 AM
  • Hi,

    Not to my knowledge possible OOB, you'll need a deploy, but your could build customizations. E.g. the first action in the Orchestration could be to receive message and check against config if it should be processed or not.

    Br,

    Leo


    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!

    Tuesday, February 13, 2018 11:13 AM
  • In case of orchestration you cannot directly change or modify the filter used for subscription.

    Rather in case you are migrating step by step and do not want to redeploy the orchestration, here is what I suggest,

    Let the Orchestration subscribe to all the Cost Centers as it is doing now.

    Create a BRE policy where you pass the name of the cost center as the input and the BRE policy sends you an output flag which tells the orchestration to proceed with the request or not.

    If the Cost center is to be processed by the orchestration, you just let the orchestration continue. IN case ypou have migrated it, let the BRE output a false flag. 

    Now use a decide shape in the orchestration.

    If the flag value is false, terminate the orch instance using a terminate shape.

    Advantage of using BRE:

    You can create a new version of BRE policy for each migration and just deploy the version instead of the Orchestration. The orchestration by default will pick up the latest version of the BRE and you will not have any issue.


    Mandar Dharmadhikari

    Tuesday, February 13, 2018 12:24 PM
    Moderator
  • Here's what I would do.

    1. Create a custom Pipeline Component with a property called something like NewProcessCostCenters.
    2. When a message comes through it compares the Cost Center property to NewProcessCostCenters.
    3. Based on that outcome, it Promotes a custom Property, TargetApp or such, with MyOrch or MySendPort or something that works for you.
    4. Then, the Orchestrations subscribe to MyProps.TargetApp = MyOrch and the Send Port Filters on MyPros.TargetApp = MySendPort.
    5. Then as the cost centers are migrated, you just update the list in the component.
    • Proposed as answer by Leo Erlandsson Tuesday, February 13, 2018 3:31 PM
    Tuesday, February 13, 2018 1:02 PM
    Moderator