This blog post is part of a series to support those moving to Intelligent Advisor Cloud ahead of Premier support for Intelligent Advisor on-premises, formerly known as Oracle Policy Automation, ending in September 2025.
This post specifically explains how to work with your newly migrated project in Oracle Policy Modeling v12.
Familiarize yourself with OPM v12
User interface
The OPM v12 interface is structured in 4 tabs:
- The Project tab is where you define project-level considerations and assets that apply across the policy model (for example, translations, forms and test cases).
- The Rules tab is where you define the logic (decisions) behind the interview.
- The Data tab is where you manage individual data items and mappings to other systems.
- The Interview tab is where you define how the interview will present to the end user.
There is also a toolbar that includes a Debug button, a Search button, and a help button that opens the documentation.
To find out more, see Policy Modeling User Interface. The topic Walkthrough of Policy Modeling is another great way to gain a rapid overview of how OPM v12 works.
Example projects
OPM v12 comes pre-installed with numerous example projects demonstrating its key features and uses across a broad range of industries. Familiarize yourself with these examples to see how you might be able to refine or redevelop your project in new ways. TIP! Once you’ve opened an example project, you can see what it would look like to an end user by hitting the Debug button to run the interview in the Debugger. Most examples are also deployed online if you want to view them in a web browser.
Interviews
Perhaps one of the biggest changes you will notice when moving to v12 are the out-of-the-box solutions for screen elements and flows that previously needed to be hand-crafted. Have a look at the Overview of Designing Interviews and Interview Options topics to learn more.
TIP! It is important to design interview experiences that are accessible to people with disabilities. In v12, you can choose the level of Web Content Accessibility Guidelines (WCAG) that you want to validate your screens against. Learn more in Design Accessible Interviews.
Files and folders
The Policy Modeling Files and Folders topic explains the v12 project directory. Supplementary documentation in the v10.4 project folders, for example, non-rule Word documents that were in /Project/Documents/Design or /Project/Documents/Source in v10.4, are migrated to the Others folder.
Fix issues and errors
After you have familiarized yourself with OPM v12, you should check for any issues, warnings and errors in your migrated project.
Upgrade issues
On the Rules tab there is an Upgrade Issues button. Click this button to see if there are any rules that behave differently after upgrade from v10.4.
You will need to address these differences. Note that Excel rule documents are not checked for differences in behavior so you will need to check these yourself.
Examples of issues where rules behave differently after upgrade from v10.4:
- Changed from scope-for to attribute
- Changed from subtraction to attribute
- Changed from division to attribute
- Changed from concatenate to attribute
- Changed from attribute to YearDifference
- Changed from Minimum() to addition
- Changed from Maximum() to subtraction
TIP! Hint text will often be provided to help you resolve the issue.
If there are no rules in the project, the Upgrade Issues window will show “No saved upgrade data”.
Warnings and errors
If there are any warnings or errors in your migrated project, you will be alerted to these by a warning icon on the Rules, Data and Interview tabs. You will need to address any errors before you can build the project. You can click on an error or warning to go to the source of the problem so that you can fix it.
Examples of errors in migrated rules:
- Cannot determine an automatic type for attribute {0}. Please choose one manually.
- Invalid conclusion. A rule must conclude one of the following: Boolean attribute, direct attribute assignment, relationship membership, entity instance existence, or an event. (OPA-E00452)
- The left side of ‘=’ in a conclusion must be an attribute. (OPA-E00501)
- Ambiguous expression {0}. Please use parentheses to clarify.
Examples of errors in migrated screens:
- The input attribute ‘{0}’ does not belong to the entity ‘{1}’. OPA-E00394)
- The substitution attribute ‘<x>’ in stage title ‘<y>’ does not belong to the entity ‘Global’. (OPA-E00462)
- Invalid HTML attribute specification in caption. The use of the “width” attribute is not allowed. (OPA-E00495)
- To generate accessible PDF choose PDF/UA in Generated PDF Options. (OPA-E00851)
TIP! Most error text will either provide guidance on the resolution, or give an error code that can be searched for in the documentation (Oracle Policy Modeling Error Codes) for more details.
Address customizations
Since many features that required customizations in v10.4 are now available out-of-the-box in v12, existing v10.4 customizations should be reviewed against current v12 functionality.
Custom functions
OPM v12 allows rule authors (not programmers) to define their own rule functions with parameters as part of the project data model, and call these functions from rule documents. For more information, see Overview of Custom Functions.
Custom properties
Custom (user-defined) properties were used in v10.4 to extend or customize a project by allowing metadata to be associated with different elements (attributes, controls, entities, folders, relationships, rules, screens and the project). Suggestions for replacing some v10.4 custom properties with v12 functionality are provided below:
| Custom property use case in v10.4 |
How to implement in v12 |
| To format an attribute or an attribute value. For example, to format an attribute value to be title case or an attribute to appear in bold. |
|
| To map each attribute to a data item in an external application |
|
| To identify the owner of rules (eg. rule_property[Maintenance:Business Rule Team]) or the date the rule was last amended (eg. rule_property[Updated:2006-06-17]) |
|
| To make a whole screen display differently. For example, to have a different watermark or size of font from other screens |
|
| To control the appearance of inferred attributes on screens |
|
| To make radio buttons appear down the page (instead of across the page) |
|
| To enable a question based on the answer to another question on the same screen |
|
| To specify the product version or product name. For example, ‘Build number 121’. |
TIP! Use the custom properties report to identify the custom properties in your v10.4 project that will need replacing in your v12 project.
Custom interview styling
Check if your v10.4 project has a messages.properties file and/or an appearance.properties file (in the \Release\web-determinations\WEB-INF\classes\configuration folder) as these may contain interview customizations that you want to implement in your v12 project.
Understand changed features
You will find that your v10.4 project used features that have changed in v12 or do not have a direct equivalent. Use the table below to help you work out how those features can be handled in v12.
| Feature in v10.4 |
How to implement in v12 |
|
| Interview screen order (data review screens) |
Use goal setting, screen navigation, and hiding and showing screens in an interview |
|
| Commentary |
Use alternative methods such as adding definitions to terms using HTML, adding labels directly to the interview screen, or adding links to other HTML pages such as other webpages or the v10.4 commentary HTML files |
|
| Rule browser |
Use the context menu on an attribute or entity to see how rules are used in rules |
|
| Rule loop metadata |
No equivalent – you will need to investigate any rule loop warnings and can hide them if you have confirmed that the rule loop is safe |
|
| Rule fragments |
Use rule tables to prove conditional calculations. You can use the v10.4 Rule Browser to find all rule fragments and compare to your equivalent v12 rule. |
|
| What-If analysis documents |
|
|
| Structural elements in rules |
Use reference tags. Note that the automatic generation of structural attributes from these elements no longer occurs. This will have implications for your migrated rules. |
|
| Decision reports |
Use explanations |
|
| XML lists (for lists of values) |
Use value lists |
|
| Modules |
Use inclusions |
TIP! The topic Migrate a Version 10.4 Project goes into greater detail on the differences between v10.4 and v12 projects that warrant consideration and require changes.
Validate your v12 project
After you have resolved any errors and issues in your migrated project and implemented any new functionality, you should then validate your project to ensure that it still works as expected. To do this you should:
- Update or create tests
- Conduct unit testing for individual components and the project
- Perform regression testing
- Perform language and translation testing
For more information, see Overview of Testing Rules and Interviews.