Custom Java Libraries
At some point in time, a Policy Automation project may hit a potential roadblock because there is specific functionality that is used to perform some sort of check or calculation, and this functionality already exists in a Java library, or a Visual Studio DLL. It may be desirable to re-use the functionality in the Policy Automation deployment.
Re-using functions in this way requires specific handling as we will discover. Naturally one must consider the deployment – will Policy Automation be running under Apache or IIS for example (and thus, how will the functionality need to be packaged). A Custom Java Library can be developed to overcome the problem, assuming there are no more standard options. It should also be noted that the concept of Custom Java Libraries is available in a wide variety of situations to extend the Policy Automation engine – both for Web Determimations and Determination Server. Each kind of Custom Java Library requires a different set of programming guidelines or “template” which can be downloaded or copied and pasted from the documentaton.
When building a custom function library for whatever purpose, there are other twists and turns to be watched out for. As an example, when using the Debugger to run the following rulebase (assuming that you have written the necessary Java code to implement a custom function ):-
When you start to Build and Debug (without Screens), you get the following rather interesting message:-
The Policy Modeller uses .NET to power it’s debugging, so if you have not created a .NET implementation of your code you will get this. It will also occur in the Regression Tester which uses the same engine.
Using the “With Screens” option pushes your rulebase to the embedded Tomcat installation in your Policy Modelling environment,so you would expect to be able to use your function. There are still things to be aware of as we will see.
But we are getting ahead of ourselves. How do you go about creating a custom function for Policy Automation? It all starts with an XML file called extension.xml which is used to signal the existence of a Java file to Oracle Policy Automation. Here is a simple example, specifying the function that has been created in Java code “ODECalculate”.
<?xml version="1.0" encoding="utf-8"?> <extension> <functions> <function name="ODECalculate" return-type="text"> <arg name="arg1" type="text" /> <arg name="arg2" type="text" /> <handler platform="java" class="com.oracle.determinations.ODE.ODECalculate" /> </function> </functions> </extension>
This file, as you can probably see, defines the functions, their arguments and their implementation – here you can see this is using a Java implementation. If you added another handler for .NET you would probably have a line like this one.
<handler platform="dotnet" class="com.oracle.determinations.ODE.ODECalculate" />
This file is designed to be added to your Policy Automation Project in a folder like this one, inside your Development folders. Note the name of the folder used to contain the XML file as well as the XML file name.
Now that we have our file in place, we can begin creating a simple example function and actually writing some code. See you in part two!