Integrate an interview experience within an existing application or process
Create your own interview user experience
Embed Oracle Web Determinations inside a frame
Configure Oracle Web Determinations' look and feel to appear embedded
Integrate Oracle Web Determinations into a parent application's workflow
To get Oracle Web Determinations to embed inside a frame, you need to turn off the commentary frameset and tell Web Determinations to target the current frame rather than the top frame. This can be done by going to appearance.properties and making the following settings:
use-session-frameset=false frameset-top-target=_self commentary-target=commentary_frame
The application can then be started by either going to the main page using
http://<server>:<port>/<webapp>
http://<server>:<port>/<webapp>.aspx
Or you can start a session for a rulebase directly by going to
http://<server>:<port>/<webapp>/startsession/<rulebase>/<locale>
http://<server>:<port>/<webapp>/startsession/<rulebase>/<locale>.aspx
This following discusses how to configure the Oracle Web Determinations' theme/skin/UI so that it appears to be part of the parent application.
The first thing to change in order to embed Oracle Web Determinations into an application are: the colors used, the text font/size, image and branding. Changing these will achieve the most in terms of making Oracle Web Determinations feel part of the parent application.
A lot of configuration is available in the appearance.properties, such as the body text font and color as well as styling of various Web Determinations page components (progress bar, menu bar, header, and so on).
While there is a lot of configuration available, only some parts of Web Determinations' look and feel can be controlled via appearance.properties. The appearance.properties file allows easy modification of commonly-customized Web Determinations areas.
Specific styling changes not possible in appearance.properties can be made by modifying the main.vm.css - located in <OWD webapp>/WEB-INF/classes/templates/main.vm.css. Note that this requires knowledge of HTML and CSS.
Here are a list of things to consider changing in Web Determinations that are configurable in appearance.properties:
The following two screen shots demonstrate the difference that can be made with a few tweaks in the appearance.properties.
Oracle Web Determinations has some page components that can be removed so it does not look like a stand-alone application. Some page components can be disabled via appearance.properties, while others need to be disabled manually by manipulating the Web Determinations templates. Note that manipulating templates requires knowledge of Velocity.
The Web Determinations Header and Footer would be the primary components to be removed for embedding Web Determinations. As the Header and Footer cannot be disabled via appearance.properties, this needs to be done manually by modifying the Web Determinations templates. A main template is a template that contains the <html> tag; for example, start_screen, summary_screen, question_screen.
The next set of components that can be removed from Web Determinations are the bars - the menu bar, progress bar, and status bar. They can be completely disabled via appearance.properties.
Below is an example of what it would look like if the menu, status, and progress bars are disabled.
If the parent application has a layout or characteristics that are unique and do not follow standard web layout, the Oracle Web Determinations page layout may need to be tweaked to match.
This is not a simple change, and is considered advanced customization. Customizing the Web Determinations Velocity templates allows for nearly limitless changes, but can also reduce stability and maintainability.
To prevent reduction in stability and maintainability,
Some examples of page layout and specific modifications are:
This following describes an approach to integrating Oracle Web Determinations into a parent (web) application's workflow/process. This means that part-way through the workflow, the parent application will hand over data to Web Determinations, which will then conduct an interview.
Data (both provided and determined) during the Web Determinations Interview is then passed back to the parent application. The parent application can then use the data passed back for further analysis or to drive the workflow.
Integrating an Oracle Web Determinations Interview inside an application's workflow means that the application can leverage Web Determinations' capability for handling complex determination scenarios.
To integrate the Web Determinations Interview, the parent application needs to:
Pre-seeding a Web Determinations Interview makes the integration with the workflow seamless - the user does not have to re-enter data that was provided already to the parent application (either via a previous form on the same workflow or another workflow/app altogether).
The parent application can feed data to the Web Determinations Interview by using the Load action. The data can be a mixture of:
The Web Determinations Load action uses the Data Adaptor to fetch and load data to a fresh Interview, 'pre-seeding' the Interview before it begins. More information about pre-seeding and Data Adaptor can be found in Data Adaptor - Common Scenarios
To start a Web Determinations Interview, a specific URL needs to be constructed. The URL construction works for both starting a fresh Interview and pre-seeded Interview, although the latter is probably the expected usage when integrating.
Web Determinations has a REST-based URL, allowing for a specific rulebase, locale, goal, and session ID to be provided. This avoids the user having to manually make the selection for those items, and helps with a seamless integration.
The REST URL to construct for starting the pre-seeded Web Determinations Interview is as follows:
http://<OWD_webapp>/startsession/<rulebase_name>/<locale>/<goalID>?caseID=<caseID#>&user=guest
Description:
The parent application has a few options to retrieve the data from a Web Determinations Interview session.
To resume the original workflow, the Web Determinations Interview needs to direct the user to the next form in the workflow after the Interview is completed.
There are many different approaches for this since web applications vary in implementation. Some are complex and dynamic, employing heavy Javascript/AJAX while others are simple and rely on basic URL request/response to drive the flow.
For basic (non-dynamic) webapp setups, the Web Determinations Interview can change the URL of the frame (or the parent page) to the next form in the workflow.
To achieve this:
Some web applications employ DHTML/Javascript, and can control the page or frame's URL. In this case, Web Determinations may only need to be able to signal via Javascript that it has completed, and the parent application's DHTML/Javascript architecture can resume control of the workflow
Oracle Web Determinations allows you to deploy Oracle Policy Modeling rulebases into a configurable and extendable web application out of the box.
There is a comprehensive extension architecture available to Technical Consultants/System Integrators with extension points to accommodate specific project implementation needs.
Web Determinations extensions are custom Java or .Net classes/packages that are developed by System Integrators and deployed onto a Web Determinations web application.
There are two main types of Interactive Extensions:
When extending Web Determinations, both of these extension types do not need to be used exclusively. They both provide complementing extension points so it is most likely that the both Plugins and Event Handlers will be used to achieve the desired project-specific behavior.
In the context of Oracle Web Determinations, the word Plugin is ambiguous as it can mean either a single class that implements an exported interface, or the compiled JAR or DLL containing multiple class definitions; from this point on, these are referred to as plugin class and plugin archive respectively, and the interface they implement is a plugin interface.
Plugins are constructed in two stages:
There are several varieties of plugin interface:
Some examples:
To create a plugin:
When deploying Oracle Web Determinations, plugin archives must be placed in a specific location within the deployed web application (classes/plugins). This location cannot be changed by configuration. In Java, plugin classes must be archived into a JAR (no naked .class files). Other non-plugin files, such as dependencies or configuration files for the plugin classes, may also be placed in the plugins directory; they will be ignored by Oracle Web Determinations.
On application servers which allow us to search the plugins directory (such as Tomcat and IIS) every JAR (for Java platforms) or DLL (for .NET platforms) in the plugins directory will be examined to determine if it is a plugin archive. For the convenience of the systems administrator who may wish to deploy large numbers of plugin dependencies without incurring extra delay at startup, subdirectories of the plugins directory will not be searched.
On application servers which do not allow us to search the plugins directory (such as WebLogic and WebSphere) plugin archives must be named explicitly in the Oracle Web Determinations configuration file.
On any application server, even if the plugins directory can otherwise be searched, when plugins are specified in the configuration file, no other unnamed plugins will be loaded. This allows for consistent behavior when the same Oracle Web Determinations deployment is moved between application servers. It also allows an Oracle plugin archive to be overridden by a customer plugin archive while still being available for the customer plugin archive to use.
Plugins are initialized in batches, according to the interfaces they implement. Note that within each batch, the order of initialization is not specified:
- all Engine Singleton plugins
- all Platform Singleton plugins
- all Engine Session plugins
- all Platform Session plugins
Oracle Web Determinations is heavily multithreaded, and attention must be paid to threading issues to produce correct behavior.