Welcome to the OPA Hub!


Category Archives: Migration

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.

OPA 12 – Project Migrator OPMMigrator

OPA 12 – Project Migrator OPMMigrator

Sitting in the BIN  folder of your Oracle Policy Modeler application, probably in your Program Files (x86) or similar, you will of course find the OPM executable but you will also find the OPMMigrator utility. It is a command line executable, although it does require .NET 4.0 Client Profile to be installed (you probably have that anyway, but it is a quick download if not). It targets older versions of Projects to migrate them to the latest format. For example, perhaps you have version 10 Projects to bring into a version 12 environment.

The command line is pretty straightforward, with the first argument being the location of the Project File to be migrated, and the second one the folder where the new, migrated Project should be created.

OPA 12 -Migration Tool Command Line

Of course in a simple Project File, the output is pretty straightforward:

OPA 12 - Simple Migration Output

The output is also available in a log file called migration.log which will be in the destination folder you supplied (in my case, e:\migrated\XXX.

Working with more complex Projects you will find several other kinds of output. Firstly you may have files that are currently set in your Project to be not included in the Build. These will be ignored:

OPA 12 - More Complex Migration Output

Finally, there will necessarily be situations where files are not migrated at all, so you will see a WARNING in the migration log. Screen Flows are a good example, since they are no longer used in version 12:

OPA 12 - Migration Ignore Screen Flow

File Locking Issue

On longer Project migrations you might encounter a small issue as well. Several times, the Migration tool seemed to hang at the end of the process. In the screenshot above, you can see that the migration has, apparently, been completed. But the cursor is still not available. Likewise, the folder shows a log file of zero bytes:

OPA 12 - Migration Log File Zero Byte Issue

Annoyingly, the Migration tool kept a lock on the file and folder for an eternity (I left it running for 4 hours) but it still was not finished. I was able to verify this by trying to delete the new folder, Windows replied:

OPA 12 - Migration Folder Still In Use

Try as I might (checking for exclusive access to the folder and file / rebooting the machine) I could not get this to work. I of course also tried running the Command Prompt as Administrator of the local machine. Still no solution. The Project migrated successfully but the log file was never written.

As a workaround I used the old technique of sending the output of the Command Prompt to a Text File using a redirection operator “>”:

OPA 12 - OPA Log to Text File

When I ran this command, the new “home-grown” output file was successfully created as it sent the visual output to the text file, and the command ran without issue. And, happily, the command executed and released the lock on any file. So I ended up with two log files : my own, home-grown one and the official one, sitting inside the migrated Project folder. A small price to pay.