none
How to Transform and route a message to multiple recipients using BRE?

    Question

  • Hi

     

    I have an information transfer process of employees to multiple recipients according to following two messages attribute: CurrentActivityCenter and PreviousActivityCenter.

     

    IF (

    (CurrentActivityCenter >= 10 && CurrentActivityCenter < 20)

    ||

    (PreviousActivityCenter >= 10 && PreviousActivityCenter < 20)

    )

    {

                    //Transform and send message to recipient-1.

    }

    IF (

    (CurrentActivityCenter >= 20 && CurrentActivityCenter < 30)

    ||

    (PreviousActivityCenter >= 20 && PreviousActivityCenter < 30)

    )

    {

                    //Transform and send message to recipient-2.

    }

     

    I use independent itineraries for each recipients and I use BRI for determine the itinerary to assign to the message and my rule is configured in BRE.

     

    However, it can satisfy both conditions and apply only one itinerary. For Example, when the message has CurrentActivityCenter = 11 and PreviousActivityCenter = 25.

     

    What alternatives do I have to transform and route the message to multiple recipients using BRE?

     

    Thanks


    Alejandro González J.
    Wednesday, January 05, 2011 4:28 PM

Answers

  • Hi Alejandro,

    I understand, I missed "OR". 

    I did not think about case when both conditions are satisifed. Yes having independent itineraries is possibale way.

    It gets complicated but there is other way I  would think of.  to have one itinerary.  Create a Custom Itinerary Service Using a BizTalk Orchestration.   Look at Resolving a Dynamic Send Port in a BizTalk Orchestration using ESB Toolkit 2.0 

    Idea here is loop through "n" resolvers (Lets say BRE). BRE does rule check and provides you transformation information and end point configuration. (Make each rule as different policy in that way each resolver calls a policy)

    then You can perfrom dynamic transformation inside orchestrations How to Use Expressions to Dynamic Transform Messages Using Dynamic Transformation and dynamic routing (using dynamic ports).

    End of the resolvers (2 in your case). you advance itinerary and step out.

    Thanks,

    TenaliNaga

    Thursday, January 06, 2011 8:34 PM
  • This is more a archtitecture/deisgn question than it is how to do... Simply because there are many ways to handle this situation..

    We had a similar situation where we needed to determine the routing capability based off logic that said things like, A subscriber is interested in the message based off of 1 or more rules. Thus if a message came in, it had to be evaluated through a group of rules for each possible recipient. If any of the rules were satisfied for a given subscriber, then that recipient would get a copy of the message. (Similar to what BizTalk already does with its pub/sub mechanism)

    The key to overstanding how to figure something like this out is first using basic BizTalk design, and not thinking about ESB at this point. We know that BizTalk routes by way of promoted properties/filters/subscriptions etc...

    Thus what you need is a way to get a message in, and when it comes in, run it through some rules which evaluate and then use an action to promote the values you need for subscription for BizTalk routing. Here's an example,

     

    We needed to route a message based on an action value (let's say Action="NorthGroup"). For each subscriber, there would be a rule that checks maybe a database of entries that says when that subscriber is insterested, and one of those entries would be "when action is = "NorthGroup". the rule fires. What this rule action does is change the value of Action or someother value in the message to a value that adds the number of interested subscribers like SubScriberList="Subscriber1|SubScriber2|Subscriber3" etc. Each fired action simply adds to the list.

    Once all the rules have run, you'll need another component that runs let's say inside the disassembly pipeline stage that parses this list and simply creates a copy of the message for each subscriber in the list, promoting what every properties/values that need promoting for BizTalk to do the routing.

    At this point, Normal ESB Processing and design could come into place.

    Using a design like the one above would require running the rules inside a Rcv Pipeline component, or just using the BRE Resolver to do this, as well as using a Disassembler pipeline component (either custom, or the ESB Dispatcher Disassembler) to create copies of the message. THere's no need to use an orchestration or anything. It's a very high performing design, however the side effects are: 

        - Hard to Debug when things go wrong

        - No visibility into the process

        - More Complex design/solution

        - Would definitely require documentation, so new projects/updates/implementation don't screw it up

     

    The Pros are:

      - Elegant design

      - Speed/performance

      - Very Agile, you could easily add more rules/subscribers/logic as time goes on

      - Using BizTalk's capabilities for how they were meant to be used

     

     


    MCT, MCSD.NET, MVP
    Friday, January 07, 2011 4:06 PM

All replies

  • Hi Alejandro,

    You can use one itinerery to accomplish your task.

    Based on the content of message you wish to 1) perfrom dynamic transformation then 2) perfrom dynamic endpoint resolution.

    The link  shows how to insert records into any table in oracleDB. It has similar analogy. Based on message type (which is content for you) 1) incoming data is transformed for a specific oracle-insert request (you will use your rule) then 2) based on message type end point resooultion is performed (you will use your rule).

    Your itinery will look similar (except part that i had response coming back after insert from oracleDB mapped again using ItineraryService4 which can be ignored).

    Thanks,

    TenaliNaga

     

    Wednesday, January 05, 2011 5:45 PM
  • Hi TenaliNaga

     

    Thanks for your contribution.

     

    Your solution allows dynamic routing and dynamic transformation, but It doesn’t solve the problem about “I want to multiple rules are complied and the message must be transformed and routed to multiple recipients”.

     

    My policy has multiple rules:

     

    Policy: EvaluateEmployee
    	Rule1X
    		Conditions:
    			(CurrentActivityCenter >= 10 AND CurrentActivityCenter < 20) 
    			OR
    			(PreviousActivityCenter >= 10 AND PreviousActivityCenter < 20)
     
    		Actions:
    			Set Transform Transform Type to Map1
     
    	Rule2X
    		Conditions:
    			(CurrentActivityCenter >= 20 AND CurrentActivityCenter < 30) 
    			OR
    			(PreviousActivityCenter >= 20 AND PreviousActivityCenter < 30)
     
    		Actions:
    			Set Transform Transform Type to Map2

     

    I create a similar policy for routing.

     

    When a message arrive with attribute CurrentActivityCenter = 15 and attribute PreviousActivityCenter = 25, both rules are complied. The original message must be transformed and routed to TWO RECIPIENTS.

     

    To transform and route I implemente a custom ItineraryMessagingService as shown in this post:
    http://diagonaltechblog.blogspot.com/2010/04/route-and-map-single-message-to.html

    But, How do I evaluate
    multiple rules?

     

    Thanks for your help.


    Alejandro González J.
    Thursday, January 06, 2011 3:13 PM
  • Here are couple of thoughts, but I am really not sure if these can be applied in ESB or there may be better ways available with ESB.

    1. If there are fixed recipients (like two in this case), have a separate policy for each recipient and have separate steps to resolve the transformation and routing for each recipient

    2.Set a flag based on the evaluation of rules to some context property  and use it as filter on send port for each recipient.

     

    HTH.


    Please mark it as answer by clicking on "Propose As Answer", if it helps. My Blog : http://dotnetizen.blogspot.com
    Thursday, January 06, 2011 7:58 PM
  • Hi Alejandro,

    I understand, I missed "OR". 

    I did not think about case when both conditions are satisifed. Yes having independent itineraries is possibale way.

    It gets complicated but there is other way I  would think of.  to have one itinerary.  Create a Custom Itinerary Service Using a BizTalk Orchestration.   Look at Resolving a Dynamic Send Port in a BizTalk Orchestration using ESB Toolkit 2.0 

    Idea here is loop through "n" resolvers (Lets say BRE). BRE does rule check and provides you transformation information and end point configuration. (Make each rule as different policy in that way each resolver calls a policy)

    then You can perfrom dynamic transformation inside orchestrations How to Use Expressions to Dynamic Transform Messages Using Dynamic Transformation and dynamic routing (using dynamic ports).

    End of the resolvers (2 in your case). you advance itinerary and step out.

    Thanks,

    TenaliNaga

    Thursday, January 06, 2011 8:34 PM
  • This is more a archtitecture/deisgn question than it is how to do... Simply because there are many ways to handle this situation..

    We had a similar situation where we needed to determine the routing capability based off logic that said things like, A subscriber is interested in the message based off of 1 or more rules. Thus if a message came in, it had to be evaluated through a group of rules for each possible recipient. If any of the rules were satisfied for a given subscriber, then that recipient would get a copy of the message. (Similar to what BizTalk already does with its pub/sub mechanism)

    The key to overstanding how to figure something like this out is first using basic BizTalk design, and not thinking about ESB at this point. We know that BizTalk routes by way of promoted properties/filters/subscriptions etc...

    Thus what you need is a way to get a message in, and when it comes in, run it through some rules which evaluate and then use an action to promote the values you need for subscription for BizTalk routing. Here's an example,

     

    We needed to route a message based on an action value (let's say Action="NorthGroup"). For each subscriber, there would be a rule that checks maybe a database of entries that says when that subscriber is insterested, and one of those entries would be "when action is = "NorthGroup". the rule fires. What this rule action does is change the value of Action or someother value in the message to a value that adds the number of interested subscribers like SubScriberList="Subscriber1|SubScriber2|Subscriber3" etc. Each fired action simply adds to the list.

    Once all the rules have run, you'll need another component that runs let's say inside the disassembly pipeline stage that parses this list and simply creates a copy of the message for each subscriber in the list, promoting what every properties/values that need promoting for BizTalk to do the routing.

    At this point, Normal ESB Processing and design could come into place.

    Using a design like the one above would require running the rules inside a Rcv Pipeline component, or just using the BRE Resolver to do this, as well as using a Disassembler pipeline component (either custom, or the ESB Dispatcher Disassembler) to create copies of the message. THere's no need to use an orchestration or anything. It's a very high performing design, however the side effects are: 

        - Hard to Debug when things go wrong

        - No visibility into the process

        - More Complex design/solution

        - Would definitely require documentation, so new projects/updates/implementation don't screw it up

     

    The Pros are:

      - Elegant design

      - Speed/performance

      - Very Agile, you could easily add more rules/subscribers/logic as time goes on

      - Using BizTalk's capabilities for how they were meant to be used

     

     


    MCT, MCSD.NET, MVP
    Friday, January 07, 2011 4:06 PM