This recipe, taken from the recently published Oracle SOA Suite 11g Performance Cookbook gives guidance on how to avoid rule executions that will loop, potentiallyindefinitely! We’ll use an inbound XML fact and a local RL fact as an example.
You’ll need access to a SOA composite containing an OracleBusiness Rules component in JDeveloper to apply this recipe. We’ll assume youhave an XSD schema with an input type RequestInput containing input and bonusString types, and output String value called output in a type ResponseOutput.These aren’t efficient but serve as an example. We’ll step through adding arule to a composite and creating an RL fact.
How to do it...
1. Opena SOA composite. Right click on the Project and select Business Rules (ServiceComponents), use the search box if it is not immediately available.
2. Givethe rule a name and click the green plus icon to add the RequestInput to theinput and ResponseOutput to the output types.
3. Inthe rules designer, click on the Facts icon and select the RL Facts tab. Clickthe green plus icon, then right click and select edit.
4. Namethe RL Fact Customer Role and click the green plus icon to add a property. Namethe property Role and set its type to String. Add another property calledReward of type int.
5. SelectRuleset1 and click the green icon to Create a Rule
6. Inthe IF test set the condition to select RequestInput.input>=”200”.
7. Setthe THEN action to assert new CustomerAccount( Role:”GOLD”)
8. Clickthe green plus icon in the ruleset to add a rule 2. In the IF condition setCustomerAccount.Role==”GOLD”
9. Inthe THEN action set modify CustomerAccount.Reward=150
10. In the THENaction set modify CustomerAccount.Role=”SILVER”
11. To completethe ruleset so it will compile, add a third rule to assign the output of theCustomer.Account if it is “GOLD” as “high value” and a fourth rule to set it to“low value” otherwise.
How it works...
In this example we created a ruleset with rules thatchecked input XML facts and modified RL facts appropriately before assigning aresponse to an output XML fact.
Whilst the assignment in step 11 may seem odd, itillustrates an important facet of rule execution. When actions alter a valuethat is checked in another condition, in this case CustomerAccount.Role, then arule loop occurs. These loops can occur across a single rule, decision table ormultiple rules and decision tables in the same ruleset. It would be easy for abusiness user to inadvertently create a logic pattern that caused this loopingby applying an inefficient pattern such as a reward scheme in our example. Theloops created by these patterns have the potential to continue indefinitely,ultimately preventing further composites from being able to execute in the rulecontext.
To avoid this scenario we should construct our rule logicto try and prevent these scenarios from occurring. Runtime monitoring ishelpful in identifying these items when testing.
Oracle SOA Suite-Upcoming Events
Oracle SOA Suite-Upcoming Events
Oracle SOA Suite 11g Performance - Interactive Surgery Session
Monday, 9th of September 2013, 4pm - 5pm
Submit your performance problems for our experts to analyse during the webinar and you can win a copy of ‘Oracle SOA Suite 11g Performance Tuning Cookbook'!