Choose an interview technology

What do you want to do?

Integrate an interview experience within an existing application or process

Create your own interview user experience

Integrate an interview experience within an existing application or process

Go to:

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

Embed Oracle Web Determinations inside a frame

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

Java:

http://<server>:<port>/<webapp>

.NET:

http://<server>:<port>/<webapp>.aspx

 

Or you can start a session for a rulebase directly by going to

Java:

http://<server>:<port>/<webapp>/startsession/<rulebase>/<locale>

.NET:

http://<server>:<port>/<webapp>/startsession/<rulebase>/<locale>.aspx

 

Configure Oracle Web Determinations' look and feel to appear embedded

This following discusses how to configure the Oracle Web Determinations' theme/skin/UI so that it appears to be part of the parent application.

Page Styling - Colors, Fonts, and Images

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.

Example - appearance.properties untouched:


 

Example - appearance.properties optimized

 

 

Disabling Oracle Web Determinations page components

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.

Header and Footer

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.

Bars

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.

Example - Bars removed

Below is an example of what it would look like if the menu, status, and progress bars are disabled.


 

Modifying page layout and other specific modifications

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:

Integrate Oracle Web Determinations into a parent application's workflow

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.

How to integrate Oracle Web Determinations within a 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 the Interview

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

Starting the Interview

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:

High Level process for pre-seeding and starting an Oracle Web Determinations Interview
  1. The parent application workflow reaches the stage where it requires a determination
  2. The parent application's server-side has saved workflow data in a datasource that the Web Determinations Interview will require for pre-seeding
  3. The parent application calls the Web Determinations Interview to start, using a special (REST) URL
    1. the REST URL instructs Web Determinations to 'load' a specific ID (for example, the applicant's ID)
    2. the REST URL can also instruct Web Determinations to start on a specific Goal, therefore skipping the Summary Screen (which is crucial if Web Determinations is to be embedded)
  4. Web Determinations' Load action uses the Data Adaptor to load the ID.
  5. The Web Determinations Data Adaptor, which has been created specifically to access the parent application's datasource, accesses the datasource and retrieves the necessary data for pre-seeding the Interview
  6. The Data Adaptor loads the data into the Interview, and the Interview Engine does a 'think' with the present data to check if any goals have been determined (for integration with a workflow, it should not reach a goal)
  7. Web Determinations starts the Interview and presents a Question screen to the user
Retrieving the data from the Oracle Web Determinations Interview

The parent application has a few options to retrieve the data from a Web Determinations Interview session.

  1. Let the Data Adaptor save the data into a datasource; for example, database in the parent application.
    1. best approach
    2. Because it is attached to the default Data Adaptor 'Save' action, can be called via different means; for example, Extension event, REST URL
  2. Use an Extension event to access the Intervew session data, and save it into a datasource
    1. If the Data Adaptor 'save' action needs to be mapped to another save process, this is another option
    2. Cannot be called manually, so the event has to be triggered for the save to happen
  3. Create a Custom Screen that redirects to a URL link, supplying the data through a HTTP call
    1. Not the cleanest solution, low security, not suitable for anything but simple/primitive data
    2. Very flexible
    3. Can also serve dual purpose - to retrieve data from the Web Determinations Interview and also resume flow in the parent application workflow
Resuming the original workflow

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

Create your own interview user experience

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:

  1. Plugins
  2. Event Handlers

 

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.

What is a plugin?

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:

  1. At application startup, an instance is constructed by reflection, with a no-argument constructor.  This is called the factory instance
  2. Plugins are initialized by the factory instance, at different times and with different arguments for each different plugin interface. The factory instance is responsible for returning a fully-initialized actor instance which may be a copy of itself, or a newly constructed object. Alternatively, the factory instance may decline to attach by providing no actor instance at all; it is not really necessary to create factory instances as static methods with a specified name and signature could be used instead.

Kinds of plugins

There are several varieties of plugin interface:

Some examples:

General Procedure for the creation of a plugin

To create a plugin:

  1. Determine what plugin is to be extended
  2. Locate the Web Determinations plugin folder inside the web application
    1. Tomcat (Java) - default is in the WEB-INF\classes\plugins path in the interactive web application in the Tomcat webapps folder; for example:

      C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\interactive\WEB-INF\classes\plugins
    2. IIS (.Net) - by default, this in C:\inetpub\interactive\plugins



  3. Determine what plugin interfaces need to be implemented
  4. Create a class file, and implement the required interfaces and methods
  5. Develop the methods
  6. Package the class files
  7. Deploy the packaged source into the plugins folder
  8. Add needed class libraries in the lib directory
  9. Restart the server
  10. Test

Configure plugins from the System Administrator's perspective

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.

Plugin initialization order

Plugins are initialized in batches, according to the interfaces they implement.  Note that within each batch, the order of initialization is not specified:

  1. all Engine Singleton plugins
  2. all Platform Singleton plugins



  1. all Engine Session plugins
  2. all Platform Session plugins

Multithreading

Oracle Web Determinations is heavily multithreaded, and attention must be paid to threading issues to produce correct behavior.