The following information provides guidelines and details for programmatically setting up Plugin classes, and loading them into either a Web Determinations server or the Determinations Server.
From a technical viewpoint, extensions are Java or .Net classes that implement Java/.Net interfaces to provide plugins to either Web Determinations or the Determinations Server. As illustrated in the topic Introduction to extensions, there are two main types: Plugins and Event Handlers; each type has several subtypes.
The interfaces that need to be implemented for each subtype differ; this information can be found in the plugin-specific topics.
The general approach to developing and implementing a plugin is:
Programmatically, Event Handlers are actually a type of plugin in that an Event Handler's interface inherits from the plugin interface.
Each Web Determinations plugin class implements at least one interface; for example:
.. public class DataSubmissionAborter implements BeforeSubmitDataEventHandler { ..
A Web Determinations plugin class can also implement more than one interface for convenience, although it might have an effect on maintainability.
Below is a list of specific plugin types (and the corresponding interface).
| Plugin Type |
Interface |
Ancestor Interface |
|---|---|---|
| Data Adaptor |
DataAdaptorPlugin |
EnginePlugin |
| Document Generator |
DocumentGenerationPlugin |
EnginePlugin |
| Commentary Provider |
CommentaryProviderPlugin |
EnginePlugin |
| List Provider |
ListProviderPlugin |
EnginePlugin |
| Custom Screen Provider |
CustomScreenProvider | PlatformPlugin |
| Custom Control Provider |
CustomControlProvider | PlatformPlugin |
| Web Determinations Formatter |
WebDeterminationsFormatter |
PlatformPlugin |
The Web Determinations web application comes with default Plugin implementations for each type of plugin; for example, XDSDataAdaptor for DataAdaptorPlugin.
As mentioned in Introduction to plugins, only one plugin can be loaded per Web Determinations interview (with the exception of Document Generator plugins). This means that if the developer chooses to develop a custom plugin for one of the plugin types, the custom plugin overrides the default plugin implementation.
The plugin developer can still access the functionality provided by each of the default plugin implementation as each implementation is in the Web Determinations library (the .jar or .dll file, see Create a plugin ). For example, the developer can create a custom DataAdaptorPlugin that simply calls the corresponding XDSDataAdaptor method except for specific circumstances which then uses the custom DataAdaptorPlugin logic.
Regardless of the specific interface implemented, all plugin implementations must conform to the following to be loaded and invoked properly by the Oracle Web Determinations plugin framework:
Sample Plugin - RulebaseSpecificDataAdaptor
public 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 (){
}
...
For a more comprehensive example of sample code, see Data Adaptor - pseudo code.
There are much more Event Handler interfaces to implement than plugins. To see the full list of Event/Event Handlers to implement, see Events and Event Handlers
As mentioned before, Event Handlers are also plugins and so must conform to the same rules outlined in Plugin rules above.
Below are the steps in which an Event is fired and an Event Handler consumes it:
Each Event type is fired at different times during the Web Determinations interview, and expose different data to each other; it is therefore important to understand:
In addition to the plugin rules, all Event Handlers must implement the handleEvent(Event event) function. The Event input argument is specific to each Event Handler since each Event Handler is setup to receive a specific Event.
See the sample code below; because it is an OnInvestigationEndedEventHandler, the handle() method receives an OnInvestigationEndedEvent object.
public class RulebaseSpecificHandler implements OnInvestigationEndedEventHandler{ //TIP: Similar to Plugins, each Event Handler implements an interface based on the Event type it handlles
/**
* Check the type of event and output a message accordingly.
*/
public void handleEvent(OnInvestigationEndedEvent event, Object sender) { //TIP: Each Event Handler
handleEvent() has different Event and sender objects passed in //handler logic
}
/**
* 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(PlatformSessionRegisterArgs args) { //TIP: Similar to Plugins, each Event Handler
interface implemented have different getInstance() argument
if (args.getContext().getInterviewSession().getRulebase().getIdentifier().equals("SpecialRulebase")){
return new RulebaseSpecificHandler();
} else {
return null;
}
}
/**
* Parameterless constructor to conform to the plugin requirements
*/
public RulebaseSpecificHandler(){
}
}
To find out what is involved in installing Web Determinations plugins into a Web Determinations server, go to the topic, Install and register plugins.