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!

Author: Richard Napier

Richard Napier joined Siebel Systems in 1999 and took up the role of managing the nascent Siebel University in Southern Europe. He subsequently was Director of Business Development and Education for InFact Group (now part of Business & Decisions) for 8 years. He now runs Intelligent Advisor IT Consulting OÜ. Owner of intelligent-advisor.com, he also is Co-Founder of the Siebel Hub.

2 thoughts on “Policy Automation 12 and Siebel – Where’s my connector?

  1. Great blog post Richard, and thanks for the feedback on the difficulty of using the existing documentation to get Siebel and OPA working well together. We are working to provide improved documentation in an upcoming OPA release.

    Davin Fifield. VP OPA Product Development.

    1. Hello Davin. An honor to have you visit our humble blog. Firstly, thanks for the feedback. Secondly that is great news. Finally, we would be very happy to test drive the material for you on a clean Siebel platform and see if it all makes sense! Cheers, Richard and Raj.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Logo by Southpaw Projects LLC