This new feature – which is such a big one that we felt it deserved it’s own article – allows the developer of Projects to leverage the Web Authoring functionality to create a Decision Service of some kind, and then to reference that Service from a traditional Oracle Policy Modeling project. For some customers, this is going to be huge. Let’s look at a simple example.
A benefits calculation engine built in Oracle Policy Modeling has a large amount of complex rules. Some of these rules depend on rate scales, which vary over time and scenario. For example, a housing benefit needs to look up reference values in a rate card depending on whether you live in the 48 States or elsewhere. The rate is used in the Word and Excel documents of the Oracle Policy Modeling project.
You want to be able to update the rate cards without redeploying the Oracle Policy Modeling project – nothing has changed in the benefit calculator, other than the rates. Forcing, as happens today, the customer to update and redeploy or to update an Inclusion and redeploy the parent project means a whole release process is engaged (with corresponding delay) before the new value is operational.
To add another aspect to it, the customer wants to be able to hand off the management of the rates to another team who will not have access to Oracle Policy Modeling and who will not need to learn how to update and deploy a project. They just need to know how to login to the Hub, update a value in a table, and commit the change. And projects that use these references should not need to be redeployed. Well, now it is here!
The table shown above can now be referenced in Oracle Policy Modeling. The steps below, the user creates a new Reference, selects the Decision Service, then specifies the scope (Global, or for a specific relationship) before mapping the Oracle Policy Modeling attributes to the Decision Service References. The details are saved and stored in a file shown in the Rules tab (which for me is a little odd, I would have expected it maybe in the Data tab but that’s just me).
Now that the two are bound together, the maintenance of the rates in the Decision Service table can continue without any need to perform updates or refreshes in Oracle Policy Modeling. This is a big step forward for these scenarios. And to keep everything working as it should, we benefit from the following
- Decision Services have their own web-based debugging environment for testing separately from Oracle Policy Modeling
- In 21B, the Oracle Policy Modeling Debugger is now aware of any references to Decision Services in the project, and will ask the developer to login to the Hub so the data can be refreshed. Further details of how the debugging experience is managed and of the caching of Decision Service data for high performance can be found in the 21B documentation. So, we now have a Debugger that can reach out and pull the correct information from the Decision Service via the References in the project.
A quote from that page is a good way to frame this functionality for creating references.
This functionality allows business users to define shared lookup tables and rules in decision service projects for reuse in different Policy Modeling projects, without needing a desktop application install. The shared data and logic can then be instantly updated for multiple projects without redeploying them from Policy Modeling. Because decision services have clearly defined contracts, and those contracts are read-only to rule authors, the ability to allow non-experts to update reference data held in decision services is made a more reliable process.
Test a policy model containing decision service references in 21B Documentation for Oracle Intelligent Advisor
So the Decision Service concept just took a massive step forward with these References. Great stuff!
If you are looking for a video walkthrough of the above, you can find it on our Youtube Channel – don’t forget to subscribe for more Oracle Intelligent Advisor video content:
