Advanced Oracle Policy Automation – Temporal to Entity Conversions

Disclaimer: There will be advanced concepts that require the reader to have a firm foundation in OPA.

Intro

This post is a simple post to demonstrate more complex Temporal to Entity conversions than is found in the Oracle Help Documentation.

OPA help document on converting temporal values

 

These examples use the following OPA entities:

 

Data Model

The example model consists of 4 entities (assuming global as one of the 4 entities.)

Global

  • The event - This is all the historical events captured in the source system. It includes status, asset, recoupment, payment, and adjustment events.
  • The context - This exists to allow us to compare different assessment dates and different dates of known circumstance.
  • The plan - This is the basic plan for payment OPA gives back to the system.

Recommendation: Consider putting a description of your entities and relationships at the top of the rule documents.

See the following example (which we will use) of documenting entities and relationships in a Word document:

 

Source

Target

Type

Text

Reverse Text

Identifying Attribute

Global

the plan

Containment

the plans

 

the plan id

Global

the context

One to One

the latest context

 

 

Global

the plan

One to One

the payment plan

 

 

Global

the event

Containment

the events

 

the event id

Global

the context

Containment

the contexts

 

the context

the context

the event

Many To Many

the asset events

 

 

the context

the event

Many To Many

the payment events

 

 

the context

the event

Many To Many

the case status events

 

 

the context

the event

Many To Many

the recoupment events

 

 

the context

the context

One To One

the prior context

the next context

 

the plan

the plan

One To One

the next plan

the prior plan

 

Example 1 - Entity / Relationship Legend

We need to take temporal attributes and turn them into a "plan" in the plan entity. I will demonstrate this in Word and add a few "real world" twists, such as creating the entity data from more than one source attribute.

We also need to take a temporal attribute and create context entities. I will do this in Excel. In addition to demonstrating Excel for temporal conversions, we will add the complexity that each change point needs to create two entities.

Be aware that temporal-to-entity conversion generally involves rule loop warnings between step 2 and step 3.

 

Example 1: The Plan Entities Created via Word Rules.

This example creates the plan from multiple attributes, at least one of which is temporal. In my experience, that is a bit more of a real-world example.

"The plan" entity is the output equivalent of "the event" input entity. Historical events come in to OPA, get processed, and "a plan of actions" is put together going forward by OPA.

Here is example output plan data. In this case, OPA created the plan. The plan is to have no recoupment, $0.00 adjustment, and to make two payments over the next two months…  OPA came up with this in a project to be provided in the next blog post.

the plan id

the next plan

the plan amount

the plan next date

the plan record date

the plan status

the plan type

1

2

(uncertain)

5/31/2016

5/31/2016

not required

recoupment

2

3

0

6/1/2016

5/31/2016

planned

adjustment

3

4

  1. 22.5

7/1/2016

6/1/2016

planned

payment

4

5

  1. 22.5

(uncertain)

7/1/2016

planned

payment

 

We want to collect data from multiple intermediate attributes to populate this plan entity. These include:

  • The most recent historical recoupment status
  • The latest adjustment amount
  • The latest assessment date
  • The payment plan (a temporal currency attribute)

In this example, we should have only one recoupment event and one adjustment event in the plan. The first event for the plan should be a recoupment the second event should be an adjustment. If there is no recoupment, that plan will have a status of "not required," and if there is no adjustment, the plan amount will be $0. Adjustments must be called out for our financial system, which is why they are categorized differently from the payments.

Starting at plan ID number 3, all the payments for the next period should be listed. These come from the temporal attribute "the payment plan".

 

Step 1:

Step 1 is to create the initial entity.

In the OPA Help documentation, this is the rule "the first change point (the first change date) exists". For this example, we use a special set of one-to-one relationships that should be defined in the model:

Source

Target

Type

Text

Global

the plan

One to One

the first plan

 

The rule is simple. In our case, plans with ID 1 and 2 always exist, so I don't need to put a conditional. However, sometimes there will be no payments, so plans 3 onwards are questionable. In any case, we only have to get the ball rolling by creating the first plan.

the first plan (1) exists

 

Step 2:

Step 2 is to populate the attributes in any newly created entities.

Of particular interest is the attribute that represents the next "change point" created from our temporal attribute. We create links between our entities from a prior change point entity to the next change point entity. We query our temporal value(s) for the next change point (usually with WhenNext(a,b) or WhenLast(a,b) ) and put it in our current entity. In Oracle's documentation example, Oracle uses the attribute "the change point's next date". In our example, we use the attribute "the plan next date".

We are populating our plan every day a payment is to be made (every day that the temporal payment value is not equal to $0.)

The plan record date is the actual planned date of the payment. You will notice we have a rule loop here. I use the plan next date to populate the plan record date. I use the plan record date plus one day to determine the plan next date. The loop continues until there are no more times that the next payment plan is certain to not equal $0.

All the rest of the items are the attributes we must infer, because the entity itself is inferred. I have four other attributes.

 

Step 3:

Step 3 is to create the subsequent entities. In the OPA help documentation, this is the rule "the next change point (the change point's next date) exists".  Because recoupments and adjustments only have 1 entity, only the payment plans need conditional creation. For this, we need a self-referential relationship from the plan to the plan.

Source

Target

Type

Text

Reverse Text

the plan

the plan

One To One

the next plan

the prior plan

 

 

or we can do this with the table equivalent…

Everything is now done for the plan.

 

Example 2: The Context Entity via Excel Rules

Is everyone familiar with this rule?

today = the current date

 

If not familiar, this blog may not be your cup of tea…

Ever consider making that temporal??? I have considered it, and for good reason.

Unfortunately, I can't make "today" temporal and simply work with the results, because OPA does not support making temporal attributes temporal. If I made the current date temporal, I would mess up every temporal attribute that relies on the current date. It is really a bummer, but Oracle has no plans to allow temporal values of temporal attributes.

The net result is that if we want to compare temporal timelines, we must have different entities for each timeline.  This is the "OPA Context Pattern" described in another blog.

the context

the context assessment date

the context prior assessment date

the context circumstance date

the context prior circumstance date

1

2/29/2016

2/29/2016

2/29/2016

1/31/2016

1

2/29/2016

1/31/2016

1/31/2016

1/31/2016

1

1/31/2016

(unknown)

1/31/2016

(unknown)

 

Let's create this context in Excel and set several of the entity's attributes at the same time in a table.

 

Step 1

This rule creates the first context entity in Excel. "the latest context" is a one-to-one relationship.

 

 

the latest context

1

 

 

Step 2

If there is more than one context, this will be the first context.

If there is only one context, this will be the result.

This will be any context between the first and the last.

This will be the last context.

the context

1

> 1

 

Certain
(
WhenLast
(
Latest(),
ValueAt(Latest(),today) <> today
)
)

Uncertain
(
WhenLast
(
Latest(),
ValueAt(Latest(),today) <> today
)
)

for
(
the next context,
Certain
(
WhenLast
(
the context prior circumstance date,
the context prior circumstance date <> today
)
)
)

for
(
the next context,
Uncertain
(
WhenLast
(
the context prior circumstance date,
the context prior circumstance date <> today
)
)
)

the context assessment date

the latest assessment date

for(the next context, the context prior assessment date)

the context prior assessment date

the latest assessment date

uncertain

the context assessment date

for
(
the next context,
ValueAt
(
WhenLast
(
the context prior assessment date,
the context prior assessment date <> today
),
today
)
)

the context circumstance date

the latest assessment date

for(the next context, the context prior circumstance date)

the context prior circumstance date

ValueAt
(
WhenLast
(
Latest(),
ValueAt(Latest(),today) <> today
),
today
)

uncertain

for
(
the next context,
ValueAt
(
WhenLast
(
the context prior circumstance date,
the context prior circumstance date <> today
),
today
)
)

for
(
the next context,
ValueAt
(
WhenLast
(
the context prior assessment date,
the context prior assessment date <> today
),
today
)
)

 

Step 3

This creates subsequent context entities in Excel based on having prior assessment dates to evaluate for outcomes.

 

Certain(the context prior assessment date)

the prior context

the context + 1

In this vertical Excel rule style, for step 2 we can write rules that create lots of attributes and lay them out in the same order/fashion as our debugger shows them. I find debugging much easier if debugger and rules match. See the picture below:

Wait a second! Is Fowler using temporal Visualization to compare entity values and NOT for examining temporal values? Sure I am, after all, what's in a name??? I want these entities compared together.  My choice for side-by-side comparison is either to “use temporal visualization”, “create an interview screen to review the results together”, or of course muck with showing entities in tabs in OPA Excel test cases.  Using the temporal visualization for entities can be faster and more flexible.