The following is intended as a guide for implementing plugins that are loaded and invoked by the Oracle Web Determinations and Determinations Server extension framework.
All extension implementations must implement an interface that is descended from the super plugin interface Plugin. Typically, you are required to implement the most specific interface from this hierarchy, according to the type of plugin that you are writing. For example, if you wanted to implement a plugin that was an event handler for the OnSessionCreatedEvent engine event, you would implement the OnSessionCreatedEventHandler, NOT the generic EngineEventHandler interface.
Regardless of the specific interface implemented, all plugin implementations must conform to the following to be loaded and invoked properly by the extension framework:
The point at which an extension is registered and the registration arguments that are passed to it, is determined by its type. There are several types of plugins:
Install extensions to work on Oracle Policy Modeling Build and Run instances
There are two methods of installing extensions:
It is possible to automatically discover and register extensions when the applications start. Using this method, plugin installation is simply a matter of compiling the plugin libraries (.jar in Java or .dll in .NET) and deploying them to the plugins folder and restarting the application. This folder is located in <web root>/WEB-INF/classes/plugins in Java or <web root>/bin/pluginson .NET. Multiple plugins can be compiled into a single library or multiple plugin libraries can be used. Any third party dependencies must be copied into a location that will cause them to be automatically loaded when the applications starts such as <web root>/WEB-INF/lib in Java or <web root>/bin/ on .NET.
Note for Java deployments:
Because the Auto-Discovery mechanism requires the ability to introspect the class path, this method may not be available in certain application servers such as Oracle WebLogic Application server, when running the war file unexpanded. In such cases, plugins must be loaded using the manual configuration option
Manually configuring which plugins to load involves deploying the extensions, and any third party dependencies to a location that will automatically be loaded when the application starts such as <web root>/WEB-INF/lib in Java or <web root>/bin/ on .NET. The list of plugin classes to be loaded must then be manually specified in the plugin.libraries section in the application.properties file.
Installing extensions to enable Oracle Policy Modeling Build and Run instances to use those extensions is the same process as installing either onto the Determinations Server or onto a Web Determinations server.
The Oracle Policy Modeling Build and Run command invokes a Java web server as well, and its plugin folder can be found in the 'Release' folder directly in the project folder; for example, say we have a rulebase named 'MyRulebase', located in C:\projects\MyRulebase, the plugins folder will be located in the path:
C:\projects\MyRulebase\Release\web-determinations\WEB-INF\classes\plugins
Regardless of the specific interface implemented, all extensions must conform to the following to be loaded and invoked properly by the extension framework:
Code sample - sample plugin - RulebaseSpecificDataAdaptorpublic class RulebaseSpecificDataAdaptor implements DataAdaptorPlugin { //TIP: Each Plugin implements a Plugin Interface
/**
* Only provide this plugin if the Web Determinations session's rulebase is the 'SpecialRulebase' rulebase.
* The specific RegisterArgs object we get here is an instance of InterviewSessionRegisterArgs.
*/
public Plugin getInstance(InterviewSessionRegisterArgs args) { //TIP: Each Plugin interface implemented have different getInstance() argument
if (args.getSession().getRulebase().getIdentifier().equals("SpecialRulebase")){
return new RulebaseSpecificDataAdaptor ();
} else {
return null;
}
}
/**
* Parameterless constructor to conform to the plugin requirements
*/
public RulebaseSpecificDataAdaptor (){
}
...
Notes about Hot-swapping mode
If Hot-swapping mode is turned on, then:
- When a new rulebase is added, the Custom Service plugin will be given an opportunity to register a service against that rulebase.
- When a rulebase is deleted, any service registered against it will be automatically unloaded.
- Updating an existing rulebase is equivalent to a delete and load.
Do's and don'ts
- As part of the initialization logic implemented in your implementation of the getInstance method or the parameter-less constructor, DO NOT set a static (class-scope) reference to any of the objects encapsulated by the given RegisterArgs parameter.
- It is not permissible for plugins to directly alter the state of any of RegisterArgs members passed in the get instance method.
- Do not make assumptions about the number of times that the getInstance method is called. It is up to the logic implemented in this method to determine whether the plugin is to be available in a particular context. Every call to this method is another chance to the plugin to inform the application that it is ready to be used or to invalidate itself for use.
- Once the first call to the getInstance method returns, the plugin's code may be called at any point. That is, you may not make any assumptions about the order and number of calls into your code.