Oracle Policy Automation Integration Architecture

While waiting for more meaningfull stuff to happen I thought its good time, space and location (Pyrmont 3.2) to write about the Oracle Policy Automation(OPA) Integration Architecture. Specifically, We will write about Integration with Siebel 8.X . OPA version 10.2

A starting point for what OPA is, what it does, what value it brings or add. just call an Oracle Sales Representative (they know a bit about it, and you might end up buying the product for yourself, and then keep wondering what to do with it. Perhaps, make your household decisions, like what to feed the cat tonight, will be made using OPA).

OPA Architectures – The OPA architecture you choose to deploy, will determine your Integration strategy. 2 options available:

1. Web Determinations – In this case, OPA opens as a web application. An interactive session is established with an end user, and the user is presented with an outcome (or decision) at the end of the assessment.

2. Determinations Server – Here OPA works like a black box. It expects to receive a bunch of input arguements, and then makes a (smart) decision, and returns that to the user/ system, that initiated the request. Synchronous request – response.

To enable the basic integration framework, 3 main steps are necessary:

1. Download, install and import connector objects

2. Establish end points

3. Smoke test!

1. OutOfTheBox (OOTB) – OPA ships with a connector for Siebel (bunch of sif files – views, applets, business objects and components, business services, symbolic URL’s, Web Services – XML’s. The connector is like an adapter. to enable communication between 2 applications (Siebel & OPA in this instance). Follow the installing connector guide(available from google / Oracle Portal) through to completion. By the end of it, the connector should be imported, installed and compiled in your Siebel repository / SRF

2. End points are hosts or locations, where the instance of the siebel application and OPA applications reside. The Inbound Web Services (which goes with the Web Determinations Architecture) bindings points to the location of the Siebel EAI object manager, and make look something like this:

http://<SiebelServerHostName:Port#>/<EAI_objmgrName>/start.swe?SWEExtSource=SecureWebService&amp;SWEExtCmd=Execute&amp;UserName=<user_name>&amp;Password=<password>

The bindings(or end points) for the Outbound Web Service might look something like:

http://<OPAMachine_HostName:Port#>/siebel-determinations-server/assess/soap/generic/10.0/AdminSmokeTest where AdminSmokeTest is the rulebase name.

There is also some configuration required on the OPA application side( which is discussed in the various OPA help topics and guides) , the main one being updating the siebel-data-adapter.properties file. The file contains vital information about the Siebel EAI object manager (which is the same as the URL for port binding on the inbound web service definition) . How this works, is discussed later.

3. Once the correct end points have been established you are ready to Smoke it! (I mean, smoke test it) . So – navigate to the Siebel view (Think its called Policy Automation Smoke Test View) . Click to fire messages (both WD, DS ) – and you should see screen pop ups, dialogue boxes, et all. Funky stuff, isnt it?! It was my Bazinga moment when I smoke (tested) for the first time!

How it works?

Web Determinations – Launch OPA from Siebel(or other application), it invokes the OPA API (and reads the data adapter properties file mentioned above). Then talks to Siebel via the Siebel Inbound Web Service, to create a new OPA session(or launch existing one), and pre seed the OPA interview. OPA screen is presented to the user in the web browser. User answers interview questions, and proceeds to next screens. In the backend, the smart OPA engine makes decisions in real time, and determines which screens(and interview questions) to present next. The engine keeps collecting data (in the form of attributes and responses from the user), and then finally comes to an outcome, and the rationale for outcome. Submitting (or saving the session) will bring back all data into the default OPA tables in the Siebel database. Job done!

Determinations Server – No interactive session with the user. ALL data is sent in the one call to OPA, which infers and makes a decision, and ‘publishes’ the results back to Siebel (or initiating application) , usually in the form of a dialogue box. All data (attributes – base and inferred) are of course saved in Siebel database.

The connector for OPA 10.4 seems to have some enhanced capabilities – especially around mappings to base Siebel fields. I shall add more to this post if and when I get a chance to dig into it.