Capgemini Oracle Blog

Capgemini Oracle Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Oracle Policy Automation in a web service environment: performance versus traceability

Category : BPM

One of the main benefits of Business Rules Management is traceability of decisions. This is a very important feature if your organization needs to comply to law and legislation and needs to be able to prove legitimacy retrospectively. Oracle Policy Automation (OPA) fills that need as the inferencing mechanism of the tool offers the possibility to create full decision reports for every decision that is made by the rule engine.
However, using OPA as a webservice might jeopardize traceability at the expense of performance. I want to explain in this blog, why this is the case and how you can avoid the problem.

Traceability options when using OPA as a webservice

When using OPA as a webservice, you need to create an input message that states which decision you want to be taken by OPA (known as the ‘outcome attribute’) and the way in which you want it to be represented in the output message (known as the ‘outcome style’).
The outcome attribute might be something like ‘the applicant is eligible for a mortgage grant’. This attribute will be inferred using other attributes and base values that are stated in the input message as well. Stating base values in the input is necessary because OPA is not plugged into a database from which it can gather data itself. It is possible to ask for multiple outcome attributes at the same time.

OPA uses three outcome styles:
1. Value only. This only returns the value for the outcome attribute. So eligibility might be true, false or unknown, but we will never know why.
2. Decision report. This will return a response that has a full decision report containing decision nodes that describe how the value of the outcome attribute was determined.
3. Base attributes. This will return the value for the outcome attribute and the base values that were used to make this decision.

When we look at these three options, it will be fairly easy to see that value only has no traceability whatsoever, decision report has full traceability, and base-attributes has limited traceability as it shows the top and the base of the decision tree, but no conclusions in between.

Why a webservice environment may cause you to lose traceability

In a webservice environment, performance is key. An average decision on eligibility in a legal environment may lead to very big XML messages when using the decision report style. Big XML messages may cause performance to drop, especially when the message needs to be carried on throughout the landscape. Just asking values (value only or base attributes) opposed to asking a full decision report does not vary much in decision taking time, but the size of the XML message may decrease considerably.

To speed up performance, you might choose to
  • Ask for value only or base attributes in the input message. This will decrease traceability immensely.
  • Store only certain parts of the decision and dump the XML message somewhere for future reference. However, this will not be the most user-friendly way to store your decisions, considering that end users are often not used to reading XML.
  • Define the decision structure in your input XML, so you will get the values you asked for. However, this strips all flexibility from the solution (think about what happens if you add a new key attribute. You will have to change your interface accordingly to identify the new rules in the output report)
So the question remains, how to optimize performance and still be able to store decisions in a traceable way?

How to make sure the system performs AND decisions can be traced retrospectively

There is a way to avoid big XML messages and at the same time be able to maintain traceable decisions in a flexible way. I will explain this through five simple steps:

1. Make sure you define the decision structure with the key attributes and their levels. For example:

2. Model your rules using this same decision structure.
3. Give every key attribute an ID with a prefix, for example DEC_.
4. Define two calls for your decision service:

  • The first to identify the key attributes of your decision by asking a decision report for a procedural attribute such as ‘the eligibility has been determined’, with no input data for base values. This will generate the decision structure as mentioned above in the output. By using the prefix for key attributes, these can be identified easily.
  • The second to identify the values for the key attributes by supplying all input data and asking for all key attributes with a base-attributes outcome to minimize output size.

5. To maintain the decision structure in the database, use the structure from the first call to identify the levels for the key attributes.

This way, you will keep
  • The XML message maintainable. This is a plus for performance.
  • The decision traceable. This is a plus for compliance.
  • The use of your rule engine flexible. This is a plus for future changes: adding a key attribute will not lead to an interface change. Simply deploying the new rules will deliver an extra key attribute in the first call.

About the author

Els Booij
Els Booij
After graduating in business studies (Msc), Els came to work for Capgemini in 2007. Since then she has worked on several projects as a business analist and later as a business architect, specialising in business process and rules management. Els is one of the lead consultants within Capgemini in the expertise of Business Rules Management and Oracle Policy Automation.

Leave a comment

Your email address will not be published. Required fields are marked *.