RuleScript Part 1 : What, Why, Where
I hope you all enjoyed the holiday season. Stepping lightly into 2019, we begin with a series on RuleScript. For a long time I have had an article on the tip of my tongue, and it just needed an example to round it out. So this series has now finally seen the light of day. Before we begin the actual work let us set the stage.
What is RuleScript?
RuleScript is an experimental feature that is not enabled in Oracle Policy Modeling by default. You must request access from Oracle Support.
There may be times where you are implementing non-business algorithms that are better placed out of the view of the non-technical people in the team. RuleScript can access Attributes, Entities and everything you know and love about Oracle Policy Automation. Your RuleScript can update other attributes and read values as if it was written in Word or Excel. But it is written somewhere else, out of the way of the policy authors. They benefit from what you have done without getting bogged down in it.
Why Not RuleScript?
This is an experimental feature. It may disappear tomorrow. It may radically change. It may make upgrading harder.
Where is RuleScript?
You write the rules in your Project, just like anything else. Astute readers will see there is another button in this Project in the Rules tab:
If you cannot see the button, as described above, get in touch with Oracle Support. Be ready to explain why you need it, and review the example use cases using the URL link above to see if you are on the right track.
How do I use RuleScript?
- All RuleScripts need a header to be completed. In this example, a brand new file has been added:
Notice the last commented line
// RuleScript() <- ()
This cannot be removed (otherwise your Script is no longer a RuleScript) and must be completed for your code to actually work. You must complete both the right hand and left hand side of the expression. Here is an example:
You can read this line :
// RuleScript(theresults,resultstep,totaltime,resultstepnumber) <- (origin,destination, thestations,thechildstations,childstation_cost_minutes,child_station,station)
as “The following RuleScript will need to read the attributes and relationships on the right, and write to the stuff on the left”. This tells you two important things :
- The attributes, entities and relationships must exist, and have names associated with them, before you can write RuleScript with them.
- Failure to add all the attributes and so on to the list, causes an error with a remark like “Not authorised to access attribute name“
There are several other things that you need to know about the RuleScript experience :
Debugging. You can use console.log (but not alert) to push messages to the console. But this is not the Browser console (in fact they will not show up there, as they are not executed in the Browser). Rather it is in the Data tab of the Debugger (notice the messages at the bottom of the window):
Editing. The attributes and other elements of your Project that appear in your RuleScript files can be traced in the usual way, and show up when you right-click the attribute for example in the Modeling interface:
The Scenario for Today
In this series, we are going to implement something different than a traditional rule, in order to show the concepts and also the differences with the Rule authoring you already know. We are going to implement an algorithm in RuleScript and use it in our Project. This is called Dijkstra’s algorithm and is in my opinion relevant today, since it deals with networks and nodes and might well come in handy in your daily life.
Read on into part two for more information about the Project and the rather cool idea (in my opinion) behind it all…