Tag: OPA 10

Oracle Policy Automation 10 and 12 Differences in Architecture

Oracle Policy Automation 10 and 12 Differences in Architecture

Oracle Policy Automation 10 and 12 Differences in Architecture

Looking once again into our virtual postbag, this question comes from our reader Deepanshu working in India. Like many people out there, he is wondering about the migration from OPA 10 to OPA 12. He asks some very important questions. Here is the content of his query, and hopefully we can answer it in this post about Oracle Policy Automation 10 and 12 Differences. If you have a question, you can ask it on LinkedIn too: click here.

“I have 3 doubts regarding the upgrade from version 10 to 12.

  • 1. Do we need to use Oracle Policy Automation Hub as mandatory. Can’t we deploy without the Oracle Policy Automation Hub?
  • 2. After deployment, our project package are stored in a Database? Wont that make database too heavy.
  • 3. Most importantly, How to promote code from lower environment to higher environment for example. (DEV to SIT) or ( UAT to PROD)”

Firstly thanks very much to Deepanshu – his questions are very clear and are obviously of interest to many. So let’s try and find  the answers!

To begin, sometimes a picture is more effective than words. Here is an architectural overview of an on-premise Oracle Policy Automation instance.

Oracle Policy Automation 10 and 12 Differences Architecture Diagram with Bullet Points

Let’s run through the different bullet points of this Oracle Policy Automation 10 and 12 Differences post:

  1. The Oracle Policy Modelling experience is much enhanced, but similar to the version 10 application in principle. Collaboration between developers is much better, as is sharing of content (like modules in version 10 but much better, called inclusions).
  2. The development of a rulebase and compilation (or validation as it is now called) produces a Zip file. Just like version 10.
  3. Unlike version 10, to deploy the Zip file you do not deploy it manually. The Oracle Policy Modelling application does it for you, when you click to deploy the rulebase.
  4. The Oracle Policy Automation Hub application automatically logs the version of your Project you have deployed and keeps a history of your Deployments and whether they are deployed to Web Determinations or Determination Server or both. You can also set up users, manage permissions, log development versions (without deploying them – called uploading to the Repository) and set up shared data sources called Connections.
  5. The Web Determinations server is still present.
  6. The Determination server is still present.
  7. The Document Generation server is still present.
  8. The Hub uses either Oracle or MySQL as a database to store administrative and history information only. The Hub web application uses a very small database to store user, permissions and history data about your deployments. Your rulebases are not executed from this database. They are executed as in version 10.
  9. Users consume your Web Determinations as usual in a Browser
  10. Or they consume your Determination Server rulebase as a Web Service, as usual
  11. They can also, if they are authorised, use the Mobile App and work on a device-specific App.

So not much has changed, really. But the real big improvements are pretty obvious.

Oracle Policy Automation 10 and 12 Differences

  • Built in version tracking, deployment tracking and collaboration tools : no more messing to integrate (poorly) with external tools.
  • Much better control of users, access to developing rulebases, integrations and so on.
  • Much more modern interface for the Oracle Policy Modelling tool.

Finally, how to manage the fact that you will probably have a Development , a Test and a Production environment? (at least). Version 12 Private Cloud provides a command-line toolset to perform the following tasks without having to open Oracle Policy Modelling. These are big improvements and part of the Oracle Policy Automation 10 and 12 Differences that I really appreciate :

  • Creating a new OPA project
  • Exporting data model and mapping information from an OPA project
  • Running test cases for a policy rulebase
  • Integrating policy model deployment into continuous integration and testing cycles
  • Automating the process of moving policy models between testing, development and production environments
  • Changing the news information shown when users login to Policy Automation Hub
  • Changing the logging level for OPA applications to assist in troubleshooting application issues
  • Configuring the settings that OPA should use to communicate with a private cloud memcached instance

Faced with all this, the Oracle Policy Automation Hub is clearly a massive benefit, and the fact that you deploy projects using a Hub as a central repository and management tool is actually a big advantage. Technically speaking, could you deploy without an Oracle Policy Automation Hub? Possibly, but you would lose all the benefits. And the Oracle Policy Automation Hub is installed as part of the setup and installation routine so there is not much extra work involved.

Find out more online at the Oracle website or in Getting Started with Oracle Policy Automation.

Back to Basics 6 – Always Check your Parse

Back to Basics 6 – Always Check your Parse

Back to Basics 6 – Always Check your Parse

This is of course connected to the previous remarks about constructing phrases with booleans or non-booleans. But I would like to take a moment to go a little further and remind those of you starting out of the importance of the parsing process. In some ways, the old Version 10 user experience, where the parsing engine results were popped up in Word directly, when you validated / compiled your work, was easier to explain. It oriented users towards the idea of checking the parse straight away:


In the above example, everything is fine. But the process was useful when the writer had failed to be clear in their ideas, because at least then the Select Parse window showed there might be a bit of a problem right after we clicked the button:


So in the case above, we can see that there are two verbs in our made-up phrase, and the parser has flagged that to us. In Version 12, the validation process no longer shows the dialog above – te process is largely silent and transparent. I can see this as a benefit in terms of experience but it takes away the immediate sense of checking the text and parse. To get the same sort of information you have to go into the Attribute list in the Data tab, double-click the Attribute and then click the Change button shown below:


I just think that it could be a little easier for users to find. But I’m just a slow learner. I would however say that this deserves to be in our top ten of back to basics items, since checking the parse and verifying the coherence of the generated text is something to get used to very early on. And it is valid for any language that is supported by Oracle Policy Modeler.

A quick thank you

While I am writing this, I want to thank all our readers and happily report that we have just gone past the 100 post mark. Here’s to the next 100!

Until the next time, take care!

Logo by Southpaw Projects LLC