Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
In this example, we are going to demo how we can use Business rules engine in BizTalk to route messages dynamically.
Here is our scenario. We receive a message having a node called PartyName. Based on the value of PartyName the business rules policy named 'ResolverRules' will fetch the endpoint and adapter type from from a SQL table named 'RulesResolver'. This policy will be called from an orchestration which will use a dynamic send port based on the endpoint fetched by the rules. Advantage: This will help us accomplish a decoupled messaging scenario. All we need to do is add the new PartyName and the corresponding endpoints, adapter Used information in the SQL table and the orchestration dynamic send port will take care of the routing. Which essentially means a single send port can cater to multiple send end points.
DEMO:
STEP1: CREATING THE RULE Create a DB and table in your SQL server. The table will have three columns for party name adapter type and end point. Our orchestration will fetch all these information via the rules engine and assign it to the dynamic send port properties. Our table is going to look something like this.
https://psrathoud.files.wordpress.com/2015/02/dbtable.png
Open the Business Rules Composer. Go to the facts explorer > Vocabularies tab> Select Vocabularies, right-click and pick Add New Vocabularies. Name your vocabulary as appropriate. Click your newly created vocabulary and pick Add new definition. We are going to define two definition one will fetch our endpoint and other will fetch the party name.
https://psrathoud.files.wordpress.com/2015/02/setvocabulary.png
Once done right-click on your vocabulary version and pick Publish. Without publishing the vocabulary we wont be able to use that in our rules policy. Also once the vocabulary is published it cannot be modified.If need arises we will have to publish a new version and use that instead. https://psrathoud.files.wordpress.com/2015/02/vocabularypublish.png
Now once vocabulary is ready we are going to create rules policy based on the DB facts and the XSD. To reference the XSD we will select the XML schemas tab and right-click Schemas > Browse to the XSD file we have created in the BizTalk solution also holding our orchestration.
https://psrathoud.files.wordpress.com/2015/01/setxml.png?w=300
We are now ready to define our rules policy now. Click Policies and pick add new policy. Name it appropriately. After you are done configuring your policy the end result should look like this. The conditions we have defined has used the vocabularies we defined in the earlier step. Please go ahead and deploy the policy. Without deploying the orchestration will not pick the rules.
https://psrathoud.files.wordpress.com/2015/01/policy.png?w=300
Now our Rules Policy is ready to be used. STEP 2: CREATING THE ORCHESTRATION TO CALL RULES. Please create an orchestration looking resembling the following picture.
https://psrathoud.files.wordpress.com/2015/02/orchestration2.png
You will have to add System.data, System.transaction and Microsoft.RulesEngine reference in the solution. Create three variables in the transaction scope of the call rule shape of the following types. Microsoft.RuleEngine.DataConnection System.Data.SqlClient.SqlConnection System.Data.SqlClient.SqlTransaction The expression shape in the orchestration is going to look like this.
https://psrathoud.files.wordpress.com/2015/01/orchexpressions.png?w=300
Use the call rule shape to point to our Rules policy. Configure the input parameters, in this case two one message and other rules connection. The last send port is dynamic and we will pass the port parameters in the last expression shape which in turn are derived from the message returned by rules policy. Notice the expression to assign the end point. Now we can deploy this and our solution will be ready for testing. Please leave a comment if you have any questions.