Oracle Web Determinations is capable of serving multiple rulebases through the same instance of Web Determinations, meaning that it is necessary to configure the look and feel and the extension just once, after which they will automatically be applied to each rulebase.
To do this, simply deploy each rulebase zip file to the location specified in the configuration file and start the application. When you open a web browser, the default page of your Web Determinations deployment will display the list of rulebases that have just been deployed.
Instead of taking the application offline to deploy rulebase changes,you can use hot swap mode.This requires the following parameters in the configuration file to be set as follows:
load.rulebases.as.resource = false
rulebase.path = /WEB-INF/classes/rulebases
allow.rulebase.hotswap = true
To test this, do the following:
By default, rulebases are set up to be deployed to the 'bin/rulebases' directory of the web application. However, adding, deleting or modifying the files contained in this directory can lead to issues due to the way that ASP .NET recycles application domains. In short, changing the contents of a virtual directory at runtime may cause ASP .NET reload the whole application which will have the effect of destroying any active interview sessions. Therefore, if you are intending to use the rulebase hot-swapping feature, it is strongly advised that you change the location of your rulebase directory to one that is located outside the application's virtual directory. This can be done by:
The following provides a discussion of the steps required and the available options for implementing a rulebase-specific interview look and feel in Web Determinations.
Oracle Policy Modeling provides a way to attach key/value property pairs to individual screens and controls at rulebase authoring time. These are then exposed to the templates that render the Web Determinations user interface through the platform's screen and controls API.
Take for example, a rulebase in which some controls have a custom property called 'template', which maps onto the path of a template to be used instead of the default template to render that particular control. Additionally, in this example, this functionality is to only be available to this one rulebase, perhaps because access to this rulebase is only granted to a small group of trusted rulebase engineers. Call this rulebase 'alternative'.
The following is a fragment of the default template for cycling through the controls on a screen and calling the template for each control type to render the specific control:
#set( $controlList = ${screen.getControls()} ) #foreach( $control in $controlList ) <div class="control-item"> #parse( "controls/${control.getControlType()}.vm" ) </div> <span class="control-clear"></span> #end
The name of the template used to render a particular control is retrieved through the getControlType method on the control object. This is the logic that will be altered for this example:
#set( $rulebase = ${screen.getInterviewSession().getRulebase().getName()} ) #set( $controlList = ${screen.getControls()} ) #foreach( $control in $controlList ) <div class="control-item"> #if( $rulebase == "alternative" && ${control.hasProperty("template")} ) #set( $alternativeTemplate = ${control.getProperty("template")} ) #parse( "${alternativeTemplate}" ) #else #parse( "controls/${control.getControlType()}.vm" ) #end </div> <span class="control-clear"></span> #end
Templates can be modified to check for a specific rulebase or set of rulebases, and to alter the functionality and/or look and feel of the application for that particular session. This is what we have done above using the specific case of custom properties attached to controls. Another option would be to parse an alternative/extra CSS template for particular rulebase(s) and not for others. There are, however, a couple of things to bear in mind about rulebase-specific configuration: