Portals are a widely used deployment among enterprises, both internally and externally. While they are an excellent means of providing a single access point to, and integration of, information across an organization, they do however come with their own unique set of programming problems.
Oracle Web Determinations provides an interactive front-end through which rulebases authored using Oracle Policy Modeling can be accessed; but for those wishing to provide a similar experience for portal users, it is generally not the best option.
While it is possible to expose Web Determinations deployments through a portal by using either iFrames or a more complicated portlet-bridge approach, the best and most scaleable option is to produce an Interview Portlet. This provides access to all of the more complex features of the Portlet API as well as providing a properly integrated deployment.
A basic implementation of Web Determinations embedded in a portal can be found here:
Tutorial: Embed Web Determinations within my portal - a simple implementation
Although a portlet is designed around the Interview Service, it is possible that the Interview API will be chosen instead. The changeover of calls to the Interview API from the service only needs to be done in one location, however other changes are required. The JSP and portlet all reference the proxy classes in order to read and write the request and response objects from the Interview Service and these references need to be changed to utilize the API classes; for this reason, it is worthwhile giving consideration to what will be your chosen architecture in order to avoid the need for a switch later in the development cycle.
Where a change may be needed or the possibility of needing to use both the Interview Service and API is present, consider extending the functionality of the Interview Interface to completely wrap all the required classes, instead of directly referencing either the API or proxy classes; in this way it will only be necessary to swap the interview interface, though the development effort required is increased.
While the Assess Service provides lightweight stateless access to deployed rulebases, the Interview Service has been built on top of the same platform that powers Web Determinations, providing you with a Web Service enabled method through which to conduct interviews. With the state stored in the Determinations Server, developers are free to concentrate on the specifics of rendering and displaying question and result screens to the user, without having to worry about the specifics of session storage and management.
The following are lists and descriptions of the available methods, as well as an example of a common process and an advanced process:
The available methods and a description of each follows:
OpenSession, CloseSession
These methods start or end of any interaction with the Interview Service, all methods require a session token to be provided when then OpenSession method is first called. This token uniquely identifies the particular in-memory session. In order to stop the Web Server running out of memory, care should be taken to close sessions once the user has finished.
LoadCase, SaveCase, ListCases
These are the session management methods that provide the means to save and list the available session in the session store. Because loading and saving are done using the Data Adaptor loaded on the Determinations Server, it is also possible to share the data store with Web Determinations, by using the same Data Adaptor.
ListGoals, ListScreens
These methods list the goals and screens that are available in the rulebase. the screen listing can be filtered by Entity, Entity Instance, Attribute and Relationship.
Investigate
The Investigate method is the crux of the entire service and is used to investigate a particular goal or flow. The next question screen required is returned by this method in response to either a blank request or a request containing a populated screen.
GetScreen, SetScreen
These methods allow you to get and set screens outside the context of the interview and are often used to retrieve screens such as the Data Review screen.
GetDocument, GetDecisionReport
These methods get either a populated document or decision report using the information stored in the session memory.
GetUserSetData
The GetUserSetData method retrieves the data in the session that has been set by the user. It is important to note that this concept is separate from the idea of base level, intermediate and goal attributes.
The following describes the process for a typical interaction with the Interview Service, involving a simple interview such as that for which support is implemented in the portlet as described in the Tutorial: Embed Web Determinations within my portal - a simple implementation.
odsServer/ListRulebases
Request a list of the rulebases loaded into the Determinations Server and present the list to the user. This stage may or may not be recommended depending on the particular usage of the Determinations Server; not all rulebases loaded into the Determinations Server are suitable for running an interactive interview.
odsInterviewService_TestRulebase/OpenSession
The Determinations Server opens a new session in memory and returns a session token (token) that can be used to refer to the aforementioned session.
odsInterviewService_TestRulebase/ListGoals
By providing the token to the Determinations Server, a list of the available goals for the particular rulebase is provided, which can be presented to the user, allowing them to choose which goal to investigate.
odsInterviewService_TestRulebase/Investigate
At this point, a back and forth communication with the Determinations Server will be started, the first of which contains the token and the goal that is to be investigated. The response will contain a definition of the first screen to render to the user for them to complete. Further request and response pairs will contain populated screens and the next screen required respectively, until the goal is reached.
odsInterviewService_TestRulebase/CloseSession
Upon completion of the process, pass the token to a CloseSession request in order to "destroy" the session and free up memory for subsequent sessions.
The following additional requests can be made during the life-cycle of a session:
odsInterviewService_TestRulebase/SaveCase
At any point during the investigation process, the user may want to save their session, or you may want to have it saved for them automatically. This is done by calling the SaveCase method with the token and an identifier under which the case is to be saved. Loading the case in future is managed by using a LoadCase request containing that same identifier.
odsInterviewService_TestRulebase/GetDecisionReport
Once a goal has been reached (through being known, unknown or uncertain), you can then elect to retrieve and render the decision report for the user by passing the token and the goal in which you are interested.
odsInterviewService_TestRulebase/GetDocument
Upon completion of an investigation, it is common for the Summary screen to contain references to documents. These documents are dynamically generated based on the session context and can be retrieved by using the GetDocument method. This method should only be called when all of the required information is contained in the session, commonly indicated by the presence of a link appearing on the Summary screen.
odsInterviewService_TestRulebase/GetScreen
Two of the most commonly used screens are the Summary and Data Review screens. These can be accessed through the GetScreen method and rendered to a user in preference to a custom goal listing or a session data presentation.
Tutorial: Embed Web Determinations within my portal - a simple implementation