OPA – Entities Adventures #4 Substitution and Screen Flows

The Workshop – Web Determinations

Returning after a brief hiatus and some much-deserved sunshine, the Mechanic and the Workshop we have built in the previous episodes (123) is ready for cars. We will begin by adding some visuals to our Rulebase to enable us to at least use the Web Determination for the purposes of demonstration, following which we will modify the Reference Relationship we built in the previous chapter.

To build a successful Web Determinatiion we need some visual stimulation. In the second part of this series we built a Screens File and created some basic visuals for adding Mechanics. Now we will add another Question Screen for Cars.

OPA - Cars Question Screen

It is for all intents and purposes structurally identical to the Mechanics Questions Screen we created earlier. But the next Question Screen is not. Add a Question Screen that asks the user to create Relationship information. For example, the below Screen is designed to let the End User tell us which Cars are being worked on by which Mechanic. This is done through a Relationship Input Control.

OPA - Relationship Entry Screen

Common Trap #7 Assuming that a Screen is going to be shown

If we Build and Run our Web Determination, ignoring the few errors regarding goals (since we have no Goal relating to the Global entity yet), we will see the following on our Summary Screen:

OPA - Summary ScreenThe Policy Automation engine is diplaying the only two goals we have right now, and they are completely independent so they show up on the Assessment Summary. Entering via the first one lets us create Mechanics. Entering via the second one lets us create Cars. But since there is no requirement in any logical sense, for there to be any stipulated relationshiip between them, the Relationship Input Control and Screen is never shown.

The Policy Automation engine sees no reason to display it – there is no goal that depends upon it. As humans we would say “but of course we need this data” but we don’t really. In the eyes of the Policy Automation Engine, “uncertain” or “unknown” are both perfectly acceptable values for the question “Who deals with which cars?“.

To force the display of a Screen, we need a Screen Flow. The idea of forcing Policy Automation to display a Screen might seem a little contrived (it is, in this case) but it can happen – information screens at the beginning of Interviews, Terms and Conditions, Confidentiality reminders and so on – and you need to display them.

Add a Screen Flow to your Project and Drag and Drop the Screens in the order shown below/. Notice that only two of our three Screens are visible, on account of the Entity value.

OPA - Screen Flow Part One

Add a second Screen Flow and complete it as follows:

OPA - Screen Flow Part Two

Then create a “Master” or “Parent” Flow, and bring them both under one Flow. Notice the selection box that allow us to add the Screen Flow relating to a Relationship.

OPA - Screen Flow Part Three


Finally add this to the Assessment Summary Screen using the New Flow button.

OPA - Screen Flow Part Four


Test your Web Determination. Observe that the Screen Flow order is followed, and the third Screen is displayed. But notice that there is a significant problem for the end user.

In our current Screen, it is impossible to see which Mechanic is being assigned which Car. Assuming I have two cars and two mechanics, I will see this twice:

OPA - Which Mechanic

Common Trap #8 Assuming Substitution will work always

In our case, “the mechanic” is not being substituted in this Screen. This is normal behavior and requires us to make use of the Public Name for the Attribute in question. In our case, we will edit the Question Screen as follows:

OPA - Substitution with Public Name Text

This will give the following, clearer output in the Web Determination.

OPA - Screen with Mechanic Name

As you have been following I am sure, we have been delivering this process using both the English and French languages. So let us look at the French version for completeness.

The majority of the work is as above, however we run into a problem regarding the Car and the entry of data when adding Car instances. The problem stems from the following:

Common Trap #9 Gender in non-English languages

In Oracle Policy Automation, an Entity is either a gender sensitive human, or an impersonal “It”. Unfortunately this is not the case in other languages. Consider the following Text Attribute, the registration of the car.

OPA - French Car Question Screen


The provided text is incorrect, since the “registration number” in French is feminine in gende. Changing the Default Gender won’t help, since instead of the “What is the …” we will get the equivalent of “Who is the registration number?”.

So we have to override the supplied text using the “Override” button and enter the text manually.

In the next chapter we will add more rules and experiment with Entity Functions, as well as modifying the cardinality of the Reference Relationship.

Author: Richard Napier

After 8 years in case management and ERP software roles, Richard Napier joined Siebel Systems in 1999 and took up the role of managing the nascent Siebel University in Southern Europe. He subsequently was Director of Business Development and Education for InFact Group (now part of Business & Decisions) for 8 years. He now runs Intelligent Advisor IT Consulting OÜ. Owner of intelligent-advisor.com, he also is Co-Founder of the Siebel Hub.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Intelligent Advisor IT Consulting Serving Customers Worldwide
Hide picture