Tag: Web Service

Oracle Policy Automation and Siebel Innovation Pack 16 #3

Oracle Policy Automation and Siebel Innovation Pack 16 #3

This the third post in this Oracle Policy Automation and Siebel Innovation Pack 16 series, following on from the first two which dealt with the “design time” or “metadata” related operations CheckAlive and GetMetadata. If you want to catch up here are the links to the previous parts.

Oracle Policy Automation and Siebel Innovation Pack 16 Workflow ProcessBoth of those operations are fundamental to allowing the Oracle Policy Automation Hub to understand the availability of your data source and the structure thereof.  Once they are operational, there are two main things to take into account. Firstly, the pattern of Workflow Process plus Inbound Web Service Operation is one that is maintained in every case, no matter what set of data you are retrieving. Secondly, the next stages of the Connection setup are common to many Siebel Integrations but there will be Oracle Policy Automation specifics : in the Load and Save operations you will handle getting data from Siebel to and Oracle Policy Automation Rulebase, and then returning any output to Siebel.

As in the previous cases the Oracle White Paper provides, in the associated Zip file, Workflow Processes and other objects that will be needed. As before, according to your business requirement and technical setup, you will need to edit those Objects in Siebel Tools and make further objects. Changes can be frustrating as you are likely going to be searching the Repository for variable names, or Object references, and sometimes you miss one or two.

In the examples shown in the video presentations and walk-through I have deliberately kept this Oracle Policy Automation and Siebel Innovation Pack 16 overview as simple as possible, for example by eliminating the processing of attachments, and by concentrating on the key steps in the Workflow Processes. So for today we will look at the Load operation. Because this operation will require testing, this post will look at setup and SOAP UI, and the following post will take that a step further and look at testing it with real Siebel data.

The Save (a.k.a Submit) operation is necessarily the most complex operation, dealing with the saving of data in Siebel but also the response back to Oracle Policy Automation – which means taking a request to deal with a response and responding with what feels like a request!


Oracle Policy Automation and Siebel Innovation Pack 16 Load And Submit Presentation

Oracle Policy Automation and Siebel Innovation Pack 16  Load and Submit Testing in SOAP UI


In this topic, take your first steps to testing your Load and Submit in the SOAP UI utility.


The OPA Assess Method in Oracle Policy Automation Determinations #1

The OPA Assess Method in Oracle Policy Automation Determinations #1

In this short series we are going to walk through using your Oracle Policy Automation Hub, which you have set up perhaps using our step-by-step guide, to create and execute a Web Service call using the OPA Assess method. This will require you to have the following ready to hand

  1. SOAP UI for testing purposes
  2. An Oracle Policy Automation Hub in your self-study environment
  3. Word and Excel
  4. The correct version of the Oracle Policy Modelling application for your Oracle Policy Automation Hub

Let’s get started:

For the purposes of this example, I created a simple Project that uses the following attributes. The details are not really important, but here is the rundown and the explanation.

  1. An entity named “the horse” and another called “the jockey”
  2. A relationship of type 1:1 between the horse and the jockey whose text is “the horse’s jockey”
  3. An attribute called “the jockey’s number” in addition to the default identifier attribute “jockey” which is automatically created
  4. An attribute called “the horse’s status”
  5. A Global attribute called “the date of the race”
  6. Make sure “all the instances of the horse” and “all the instances of the jockey” are changed to “the horses” and “the jockeys”
  7. Make sure that all attributes, entities and relationships have names specified. In my case for the relationships I used contracted versions of the actual text, such as “thehorsesjockey” and “thehorses” and “thejockeys”. You can use whatever you would like.

The following “rules” were added. In Excel, the horses are instantiated. The logic is puerile and not important.

OPA Assess Method

Then a couple of extra goals are set up in a Word document.

OPA Assess Method - Word RulesThe main reason for having this silly structure is to be able to demonstrate handling the following :

  1. Passing Global attributes and Entity attributes in the Request
  2. Returning Inferred Instances in the Response as well as other goals

Now you can upload your version to the Repository and Deploy the Project. Once deployed, log in to the Oracle Policy Automation Hub and make the following changes for the Project in question, in the Deployments section: change the available access methods:

OPA Assess Method Setup

This ensures that for testing purposes, your Project is only available through Determinations API.

Verify that in the Permissions section, the username and password is required for Determinations API calls.

OPA Assess Method Permissions

Next, ensure that the user that you intend to use for the Web Service access, has the Determinations API access as part of their permissions:

OPA Assess Method

Finally, click the Web Service URL in the Deployment details for your Project and save the resulting file to a suitable location, ready for use in SOAP UI. This takes a couple of steps.

You will have to enter your username and password. If you are unable to proceed past this point, check that your user has the permissions shown in the previous screenshot. Now download the most recent (in terms of version) Web Service definition by clicking the link shown. This is the file that you need in SOAP UI.

Open Soap UI and create a New SOAP Project for the OPA Assess Method. The dialog box for the New Project will look a little like this. The items marked are as follows:

  1. The file you just saved
  2. A name you want to give to this series of tests

OPA Assess Method Soap UI Setup

Once the Web Service definition has been imported you should be looking at something like this, in the SOAP UI window:

OPA Assess Method

Well done on getting this far, you are now ready to test and investigate your Web Service. In part two, you will configure both of the available methods (Assess and ListGoals) in order to complete your work. Onward to part two!

Combining Siebel IP 2016 and native OPA 12.x Interviews + Answer Service

Combining Siebel IP 2016 and native OPA 12.x Interviews + Answer Service

Combining Siebel IP 2016 and native OPA 12.x Interviews + Answer Service

The Oracle Policy Automation official blog came alive last week with it’s first post in over 6 months. This post, which included a white paper and a zip file of Siebel-related configurations (see my remarks at the end of this post), raised the topic of Oracle Policy Automation 12 with Siebel 16. The simple facts are, that the Siebel release cycle does not keep pace with the Oracle Policy Automation release cycle, at least in the domain of the integration with Siebel Open UI.

As you may already know, the previous major releases of Siebel Open UI (2015, then enhanced in 2016) introduced the concept of a “seamless” integration with Oracle Policy Automation. It required the following to be configured:

  • Mapping Oracle Policy Modeling Screens to Siebel Open UI Controls via static HTML files stored on the Siebel server, and a set of Siebel Workflows to handle the mapping and XSLT.
  • Exposure of the Siebel Web Service to the Oracle Policy Automation Hub Application via the Connections tab
  • Managing the different service calls via various Interview-based Siebel Workflows

Unfortunately, at the time of the release of this solution, not all Oracle Policy Modeling Interview Controls were supported (notably the Container and the Image Control were missing). Since that time, Oracle Policy Modeling has added further enhancements in both November 2016 and February 2017 releases (lots of new controls, better checkpoints) . The integration with Siebel therefore had lost further ground. It is not surprising therefore to see the proposal of a new solution supporting more features,notably more controls and checkpoints.

I had hoped to provide you with a demonstration, however, the two files linked in the article both respond with 404 errors. I have posted a request to have that seen to, and will report as soon as I can on Siebel integration with Oracle Policy Automation.

Siebel Open UI and Oracle Policy Automation 12 Integration Version 12 #2

[vc_row][vc_column][vc_column_text]Siebel Open UI and Oracle Policy Automation 12 Integration Version 12 #2

After I wrote the previous article, it struck me that Siebel people might need a bit of an overview of Integration with Oracle Policy Automation, before I plunged into the specific scenario of the Interview Service. Let’s be clear the Interview Service is just one of a series of Web Service connection points for Siebel people looking to get OPA into their Oracle Siebel CRM Application. In fact they are not limited to Web Services as far as integration is concerned. Let’s therefore take a moment in this post to review the options. I am writing here about Oracle Policy Automation 12.

Symbolic URL

Sometimes, a nice little frame in which Oracle Policy Automation is displayed is frankly good enough. The interface proposed to the user will of course be that of Oracle Policy Automation. In Oracle Policy Modeller we can implement custom style sheets for our interview, bringing it closer to the Siebel Open UI look and feel, and we can use the dynamic nature of the Symbolic URL principle to add pertinent information into the URL and to an extent pre-seed the interview with data in Siebel, using the recent addition to the Oracle Policy Modeller Edit Attribute Dialog.

Seeding Parameters via URL

Assess Service

If you are looking to use Oracle Policy Automation as a back-end, zero user interface platform, then the Assess Service is going to probably be one of your chosen solutions. It has methods dedicated to passing in data and simply receiving the response. Of course it is up to you to provide the mechanism (probably some EAI Siebel Adapter, some transformation and a bit of Workflow Process) that is going to actually handle the input and output. This is pretty much what existed in version 10.

Answer Service

Newer than the Assess Service it has methods relating to the use of Connection objects in Oracle Policy Automation. In short, if you have Oracle Policy Modeller mapped to another application (let’s say a database or SAP or something) and you want to call it from Siebel, then you will need to know the data model that Oracle Policy Automation is expecting, so that you can build the right input. Enter the GetInputDataDefinition Action, followed in all probability by the GetAnswer action. Still fundamentally a “zero user interface” integration. We never see the Interview created in Oracle Policy Modeller.

Interview Service

As the name clearly shows, this service allows us to work though the Interview Screens of your Policy Model, and to handle all the different interactions (back, forward, save, close, and so on) that can occur. This service can then be connected to, for example Siebel CRM, and fancy techniques used to generate the user interface natively in Siebel Open UI, but based on the structure and logic of the UI built in Oracle Policy Automation. Look out for GetInputDataDefinition, StartInterview, Investigate, EndInterview, GetFiles and SnapshotSession actions. If you see them, then you are looking at the Interview Service.

Server Service

Last but by no means least, the Server service gives access to things like the Timezone settings as well as a list of deployed Rulebases.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]As ever the documentation can be found online.[/vc_column_text][/vc_column][/vc_row]

Policy Automation 12 and Siebel – Where’s my connector?

Policy Automation 12 and Siebel – Where’s my connector?

Those of you planning to migrate your “OPA” Policy Automation platform to the latest version of the on-premise (also known as Private Cloud) product are maybe struggling with the different way this new platform connects to your Siebel Enterprise instance. Let’s just remind readers that in the past, in version 10, a “Siebel Connector” integrated itself into the Oracle Policy Modelling tool.

OPA - Import Siebel Data Model 10.4

Users could import Siebel Integration Objects, suitably adjusted for Policy Automation, in a two or three step process. After that, the Siebel side of things was largely a fairly straightforward affair with Symbolic URL and other typical embedding as far as the Web Determinations were concerned, and lots of Workflow Processes and XML manipulation as far as the Determination Server was concerned.

Well, looking at the version 12 User Interface, you will see that much as changed. The Siebel menu is no longer present, cannot be installed, and on the CRM side, the Siebel Administration Views we were happily using (to provide the mapping with the Policy Automation Entities and Attributes) have disappeared.

OPA - Version 12 User Interface

So what happened?

The manner in which Policy Modeler reads the data model of Siebel, or indeed any other software package, has become much more generic. Although I, like most people, get fairly irritated when change is thrust upon me, I do understand that it it was not going to be possible to create a “XXX Connector” every time Policy Automation wanted to talk to something else to retrieve data. So a new approach had to be found.

To describe it simply, an abstraction layer has been added. Policy Automation now uses a generic mechanism to call any data source. It has clearly defined methods to do so. Your data source (ie Siebel) must comply with this or it will not be allowed to communicate with Policy Automation Hub, which in turn means your Policy Modelers will not be able to use the Siebel data structures to build rules.

Two Tasks

We need to build a mechanism in Siebel, that will respond as expected, when Policy Automation Hub contacts Siebel for information. At a simple level, we need to create two methods inside Siebel – one called CheckAlive, the other called GetMetadata. Both of these need to be exposed to the outside world as Web Service service ports. If these two respond in the way Policy Automation is expecting, then we will be able to use the Siebel Data Model that they are associated with, inside Policy Modelling. We could either build a new Web Service for each data model (each Integration Object in Siebel) or use only one Web Service and build lots of different operations with prefixes, so we (and Policy Automation Hub) know which operation corresponds to which Data Model.

Getting Started

Make sure the Policy Automation Hub is running and you can connect to it. Go to the Connections page.

In Siebel, make sure that you have created and compiled your Integration Object – the data model you want to expose to Policy Modelling. Now navigate to Administration Web Services – Inbound Web Services. Search for the following record:-

OPA - Sample Metadata

Reviewing the detail of this record by scrolling down the page, you will see two service ports:-

OPA - Service Ports

You will see that the detail is very standard Siebel. Each service port Method looks also very straightforward:-

OPA - Operation Detail

The Request Filter Method and Response Filter Method are Siebel Business Service calls that are used to clean up the Request and Response XML. But otherwise keen-eyed readers will see RunProcess. Yes, each of these calls a Siebel Workflow Process.

The Recipe

So if we want to build our own connector, we need (in total) for our recipe:-

  • Integration Object
  • Workflow Process(es)  for the two methods
  • Web Service to expose these (the WSDL will be used in the Policy Automation Hub)

The CheckAlive Workflow (called, in my Siebel Tools, OPA Metadata Service – CheckAlive) is entirely generic and simply prepares to respond with a single tiny piece of XML. Using SOAP UI or a similar tool you can test it, provided the Web Serviice shown further up in this article is Active and you Clear Cache before downloading the WSDL into your testing tool.

When you look at the OPA Get Meta Data Service For PUB Sample Intake Contact Workflow, you will see that it also is highly generic, the only thing that really has any impact is the Integration Object name in the highlighted step:

OPA - GetMetadata Wokflow

I am not going to tell you how to copy or edit these Workflow Processes (this is an Oracle Policy Modelling blog, after all!) but you can hopefully see the way forward. Base your work on these two Workflow Processes,making one small change to the Get IO Definition step.

Then create an identical(ish) copy of the Web Service – making sure that you correct the URL and add the correct items to the Service Ports and Operations. In both cases, if you have added new Workflow Processes, you will need to use the Add button to create them before selecting them. The user experience is, well, less than optimal. But Siebel developers will be comfortable with it.

Finally dowload the Web Service from Siebel by clicking the Generate WSDL button after clearing the cache. Using your favorite tool, test the responses:-

OPA - SOAPUI CheckAlive Request Response

The interesting one of course will be GetMetadata – the Reponse should be your Integration Object, translated into a generic set of “Table” objects so that Policy Automation Hub recognizes them. They remain just as you defined them, but rejigged to match the required format of the new generic Policy Automation abstraction layer.


OPA - GetMetadata SOAP UI

Policy Automation Hub

Finally we can return to Policy Automation Hub and attempt to connect to our Siebel Web Service.

Hub - Siebel Connection

The most common mistakes are:

  • The wrong URL
  • Failing to setup Siebel’s Operations for username and password authentication
  • Failing to add the correct SOAP Action Pattern

If you are using prefixes on your Method Names (so the method names are not exactly what Policy Automation Hub is expecting) then you need to add a SOAP Action Pattern. Suppose my Operation Name defined in the Siebel Web Service is OPAHLS_GetMetadata and others that are similar but with different prefixes – I am using a prefix to distinguish between different data models that are being loaded. You need to add something like


This tells Policy Automation Hub to look for the prefix OPAHLS_ in this case, and {0} represents the actual, expected Operation Name. Thus OPAHLS_GetMetadata and so on.

Click the Save button and wait. Hopefully you will be greeted by the green checkmark, symbol of relief and hope for the future.

Now go into your Policy Modelling version 12 application, create a new Project and go get some data from the Policy Automation Hub. Firstly go to  the Data Tab and click the Connection Settings button. Login with your User and Password for the Hub.

OPA Hub - Get Connection List

Now select the Connection you just created.

OPA Hub See Connections

Finally, set up the initial mapping of your Integration Object.

OPA Hub - Set Load and Save

You can now begin to create Entities and map them to your Siebel data model through the binding list.

OPA Hub Create Entity

Now I don’t often get angry but the documentation for this (at least on the Siebel side) is utterly lacking in detail, clarity or coherence. And the Policy Automation side is not much better. Once you have got through this little walkthrough I hope that it has become clearer. In the next part of this article, in the near future, we will look at how Siebel calls the Web Determination for embedding purposes in Policy Automation version 12 Private Cloud.

Until then, have fun!

Logo by Southpaw Projects LLC