Tag: Siebel Integration

Oracle Policy Automation and Siebel Innovation Pack 16 #6

Oracle Policy Automation and Siebel Innovation Pack 16The final post in this series looks at some of the “extras” that facilitate the integration of Oracle Policy Automation and Siebel Innovation Pack 16. By “extras” I mean other Web Services provided by Oracle Policy Automation, which will need to be taken into consideration when designing how these two applications can best work together but that are not directly related to the subject of getting the two applications to integrate using Applets, Integration Components, Workflow Processes and so on. Some of the content that follows is license-dependent, but should be of interest to any Oracle Policy Automation person.


Given that there are a number of different services to review, this post therefore is necessarily a mixture of many things. To summarise, there are

  • Administrative Services : The REST API of Oracle Policy Automation allows the creation of users of all the main types (integration users as well as normal ones) and also for the automation of deployment, and retrieval of associated information.
  • Execution Services : Assess, Interview and Answer (and the Server service, although it does not really need to be covered here).
  • Batch Execution Service : The REST API for Batch Execution allows for batched execution of goal determination

Together these are referred to as the Determinations API. The API is version specific in the sense that features are constantly being added (for example, integration user management is new to release 18A) so make sure you are using the correct WSDL file. For specific Oracle Policy Automation rulebases you can download the WSDL easily and that is shown in the videos below.

Assess Service

The Assess Web Service is probably the most famous service from a Siebel developer perspective, since it allows Siebel Enterprise to call Oracle Policy Automation and obtain an XML response (in the manner of a typical SOAP Web Service). It is often used therefore when no user interface is required.

The above video provides a short overview of how to derive the necessary information from Oracle Policy Automation and to use it in standard Web Service fashion. Developers should note that the post-processing of the Response will most likely occur in a Siebel Workflow Process or Script, in order to parse the response and deal with it.

As such, accessing an Oracle Policy Automation rulebase with Assess can be done very simply indeed. If the Oracle Policy Automation rulebase you are working with has a Connection in it (to Siebel or anything else) then you may also wish to use the Answer Service (see below).

Interview Service

The Interview Web Service was heavily used in the Oracle Policy Automation and Siebel Innovation Pack 15 integration, in order to mimic the behavior of the standard Interview using the Siebel Open UI framework. This Service is best suited to applications needed to provide the Interview User Interface in another technology (a Java application, a Silverlight Client, a Visual Studio application or whatever). It has a number of specifics and developers must manage session control, as the short video below illustrates.

Answer Service

The Answer service is reserved for Projects where there is a Connection object in Oracle Policy Automation, and as such provides a SOAP-based tool to pass data sets to the Project and receive the response. Amongst other things, therefore, it can be used to test the behaviour of an Oracle Policy Automation project when the external application (for example Siebel Enterprise) is not available.

REST API Services

As outlined above, there are in fact two REST API areas of interest : the administrative platform and the Batch Assessment service. Both require OAuth2 authentication and session management.

What’s Left – Oracle Policy Automation and Siebel Innovation Pack 16

So what is there still to do, for the Siebel Developer who has followed all the different posts and videos in this series? Well of course it is not possible to show everything, so here are the main points that you will now need to finish on your own : but most of them are entirely non-specific to Oracle Policy Automation and Siebel Innovation Pack 16.

There are of course many different things that you might want to do with Oracle Policy Automation and Siebel Innovation Pack 16, so at the OPA Hub Website we are always happy to hear from our readers with comments and questions : all you have to do is post at the bottom of the article. We obviously cannot run your project from here (but if you want us to, just get in touch!)  but you should feel free to contact us with questions, ideas for articles or anything else that is Oracle Policy Automation-related.

As Siebel Developers will know, Siebel Enterprise is now in version 17 and the next big thing, Siebel 18, is expected soon. The good news is that almost all of the steps shown here are completely identical in the newer version, since the changes are architectural rather than functional for the most part. If you come across anything completely different then, again, just let us know. We do plan on providing an update to this post series as and when the Siebel 18 is made generally available.


The OPA Hub hopes you all enjoyed the different posts in this series. For your bookmarks, here are the other posts in the series:

Oracle Policy Automation and Siebel Innovation Pack 16 #5

Oracle Policy Automation and Siebel Innovation Pack 16 #5

So, following on from the previous post in this series, where we looked at testing the Load and Save operations using Oracle Policy Automation and Siebel Innovation Pack 16 (as opposed to simple SOAP UI testing which is good, but will only get you so far), this post takes a slightly different turn and investigates two operations that are not strictly speaking required to be implemented.

The definition of the Oracle Policy Automation Connector Framework contains a boolean tag as to whether checkpoints are enabled in a given Connection. And these checkpoints are the subject of this post. Firstly, what is a checkpoint?

A checkpoint is a point in an interview, after which the contents of the Screens (Controls, for example data you have entered) is saved in a specific format, namely as an encoded Base64 string. This string of course needs to be saved somewhere : for example in a table in your Siebel database. Once it is saved, it can be used to open the Interview once again, through the integration between Oracle Policy Automation and Siebel Innovation Pack 16, and the session can be resumed. Obviously this has a great advantage of being simpler than trying to save all the data you have into Siebel Business Components, especially given that the Interview might not be complete yet.

So you can think of checkpoints, and their two operations SetCheckpoint and GetCheckpoint, as sort of temporary saves. When you save the checkpoint you do so with an identifier (so, an id as in previous operations). But the process of SetCheckpoint and GetCheckpoint is completely separate from Load and Save : they are two different mechanisms to handle two different business needs.

Here is a screenshot of what it looks like residing in a Siebel Table, which you will learn more about in the videos and presentation:

Oracle Policy Automation and Siebel Innovation Pack 16 - Checkpoints

The use of the Siebel Row Id means that it is relatively simple to create an Applet that sits on top of the Business Component, because you might use it as a Child Applet with the Obj Id Val as your key to finding stored sessions for your Customer or whatever it is.

The usage of these stored sessions requires a slightly modified URL to open the Interview, which you will learn about in the videos as well. In both cases (starting or resuming an Interview) a Symbolic URL, or a JavaScript embed, will be enough to call the Interview from the Siebel side.

From the Design perspective, implementing Checkpoints in your Screens is very simple, assuming you have selected a Connection that supports them. For example, the screenshot below illustrates the options available when designing the Interview. Note how you can select the relevant Screens or all of them. Selecting all Screens ensures that the Base64 string is pushed to the storage table after each Screen.

OPA 12 - Oracle Policy Automation and Siebel Innovation Pack 16 Checkpoints 2

Now that you have the details of this new part of the Oracle Policy Automation and Siebel Innovation Pack 16 integration, here are the videos to help you go further, and the links to the other parts of the series.

In this topic, learn about the two optional (but very useful methods) called Get and SetCheckPoint. This presentation explains the prerequisites and pitfalls.


In this topic, learn how to implement these methods in Siebel, build them into your Oracle Policy Automation Project and how to test and verify their functionality.


Links to Oracle Policy Automation and Siebel Innovation Pack 16 Series


In the next part of this series we will look at other Services available to Siebel developers in Oracle Policy Automation and Siebel Innovation Pack 16.

Oracle Policy Automation and Siebel Innovation Pack 16 #4

Oracle Policy Automation and Siebel Innovation Pack 16 #4

Welcome back to part four of our ongoing series about Oracle Policy Automation and Siebel Innovation Pack 16 . This post continues with the setup and testing that began three posts ago. For reference here are the links to the previous parts of the series:

Oracle Policy Automation and Siebel Innovation Pack 16 Load and SaveThis particular article continues working on the core data transfer operations, namely Load and Save. I also have a tendency to call the Save operation Submit, because it reminds me that not only must the request be submitted to Siebel to save any mapped out data, but a response needs to be sent back from Siebel to Oracle Policy Automation to, for example, display a message in Oracle Policy Automation confirming that the save was a success (or whatever).

This need for a two step approach (Save in Siebel and Respond to Oracle Policy Automation) means your Workflow Process is likely to have both typical Siebel Operations to update the database but also typical transformation and response creation like the previous operations.

The example Workflow Process for Save will require, therefore, quite a bit of work before it is fully functional. In the video I try to highlight this, but it is worthwhile mentioning the key issues again here:

  • You will need to extract any data from the hierarchy sent to your by Oracle Policy Automation
  • You might well need to use scripting if the hierarchy you receive has multiple entity instances (for example, the Oracle Policy Automation Project infers multiple vehicles and you want to save each of them in Siebel).
  • You will need to make sure that you create a Response that updates one of the input mapped, load after submit attributes to show it in the Interview.

In this video which follows on from the previous set of SOAP UI tests, build and troubleshoot your Save operation with Siebel CRM to check for errors. There are lots of places where you will need to put in a bit of work on the example Workflow Processes (since they do not actually save much at all) and more complex (and therefore more interesting) business requirements may require a Business Service approach, namely to iterate through multiple instances of data returned to Siebel.

Whilst the videos cannot give you all the details, they definitely will put you in the right direction!

Oracle Policy Automation and Siebel Innovation Pack 16 Load and Save Testing in Siebel

Remember you can find the White Paper and associated files  (at time of writing) at this Oracle Website location.


In the next part of this series, we look at two supplementary operations, GetCheckpoint and SetCheckpoint : whilst a Connection does not have to support these operations, if you plan on allowing users to stop and resume their interview before it is finished then you definitely need these operations. See you next time!


Oracle Policy Automation and Siebel Innovation Pack 16 #2

Oracle Policy Automation and Siebel Innovation Pack 16 #2

Oracle Policy Automation and Siebel Innovation Pack 16 #2

Oracle Policy Automation and Siebel Innovation Pack 16 - Hub ConnectionFollowing on from the first post about Oracle Policy Automation and Siebel Innovation Pack 16 a few days ago, this post continues with a series of (hopefully) useful videos about the next steps. Last time, you had just built your Connection in the Oracle Policy Automation Hub and had checked to see if the green light came  on. In the video sequence today, you will test both of the design time methods (CheckAlive and GetMetadata) in your SOAP UI testing tool to ensure that you get something like the correct response.

Testing in SOAP UI can be very frustrating at first. You take the time to download the WSDL from Siebel Enterprise and import it into SOAP UI, fully expecting to work with it immediately. But there are a few traps. Firstly, the need to (unless you have switched off the requirement in the Oracle Policy Automation Hub, which would be very unwise in most circumstances) add wsse tags to the Header and provide a user name and password. Secondly, you may (probably) need to remove some extraneous tags on the SOAP Request, and finally if your Siebel environment is not up and running and the relevant Workflow Processes are not active, you won’t get much in the way of feedback :).


In this brief overview, we talk about the different big-picture steps to set up communication and how to go about it.

Setting Up a Connection for Oracle Policy Automation and Siebel Innovation Pack 16

In this part you walk through the practical steps to build a Connection, add or import the different Workflow Processes and Inbound Web Services to implement the first two operations and get ready to test them.

Build CheckAlive and GetMetaData Operations

This video walks through the technical steps in Oracle Policy Automation, Siebel CRM and SOAP UI to build these two operations according to the White Paper.


In the next few days, the Load and Submit operations, the core of the integration, will be worked through and examined in Siebel and Oracle Policy Automation terms.

Oracle Policy Automation 12 and Siebel IP 2016 – Installation and Configuration

Oracle Policy Automation 12 and Siebel IP 2016 – Installation and Configuration

Returning to this subject, at the request of one of our readers, we will look at the detailed steps to deliver the content of the Oracle White Paper recently published on the Oracle Blog. This post does not assume much Siebel experience, or for that matter Oracle Policy Automation experience, but you should at least be able to navigate your way round Oracle Policy Modeling and the Siebel client. We do assume the following setup

  • Siebel On Premise
  • Oracle Policy Automation On Premise or Cloud
  • Word and Excel installed
  • Oracle Policy Modeling installed

And so, on to the first step:

Install Siebel Tools

Much of the content delivered in the ZIP file that accompanies the Oracle Blog article is to be imported into your Siebel environment. In order to do this, you will need Siebel Tools. It goes without saying (but I will say it anyway) that anything you do in the next few steps can potentially damage your Siebel instance if you get it badly wrong (although with a degree of common sense you should be fine).

To install Siebel Tools, simply download Siebel Tools from edelivery.oracle.com and install it on your hard drive like any other Windows application. A good guide Siebel Tools installation guide [free registration required] is available on our sister site, the Siebel Hub.

Make the Metadata Changes

How you next proceed very much depends on your situation. If you are working as part of a team of developers, then you would Check Out the Projects you need before doing anything. For the purposes of brevity, I am going to assume you are on a self-study Siebel environment so you can safely login to Siebel Tools and connect to your Server database, something that you would never do in real life, and make the changes there directly.

In any case I suggest you observe closely the output of the import that follows, and back out of the import and back up (Tools > Add to Archive) any objects that are going to be updated or deleted.

  1. Unzip the attached OPA Siebel Generic WS Connector.zip
  2. Login to Siebel Tools as SADMIN to your Oracle Server DB (not Sample or XE)
  3. In Siebel Tools, in the menu, click Tools > Import from Archive and select the file  OPAGenericWSConnector.sif  from the SIF folder amongst the files you just unzipped
  4. In Siebel Tools, in the menu click Tools > Compile All Projects and compile the file into the SRF that is in your Client folder (Client\Objects\ENU\siebel_sia.srf for example). When the compile is complete, the SRF will also need to be moved to the Server\Objects\ENU folder which will require the Server to be stopped and restarted.

Deploy the Workflow Processes

  1. Still in Siebel Tools, in the Object Explorer Tree, select Workflow Process
  2. Search for OPA Get Checkpoint. If it is present, click the blue Publish icon on the Toolbar
  3. Repeat for OPA Load for Pub Sample Intake Contact, OPA Process Submit Data, OPA Set Checkpoint and OPA Submit for PUB Sample Intake Contact.
  4. Restart the Siebel Server and then login to the thin client http://yourwebserver/callcenter_enu or whatever your application is.
  5. Navigate to Administration –  Business Process > Workflow Deployment
  6. In the top part of the page, search in turn for each of the 5 workflows, each time clicking Activate when you find them.

Deploy the XSL Files

The XSL files need to be copied to the Server\XSLT folder, the c:\temp folder and the Client\XSLT folder. The reason for the c:\temp folder – which you should create if you don’t have one – is simple, some of the workflows dump files into that folder. You can change the folder location / modify the workflows later if you want.

Deploy the Policy Automation Projects

The demonstration processes use the Projects called ApplyForBenefits or Eligibility. you will need to unzip them (they can usually be found in the Tools\REPPATCH folder, and you can unzip them, open them in Oracle Policy Modeling and then deploy them to your Oracle Policy Automation Hub. One of them – ApplyForBenefits – needs to be replaced with the version in the Zip file, Policy Models folder version . This is because the original ones were written quite some time ago, and the Value Lists data type confuses things when upgrading them.

You should at least be able to get the Benefits and Eligibility projects deployed. When deploying, make a note of the Deployment name. You can use the default Collection, or better still create a new Collection and give your user the required rights to it.

Deploy the Web Services

The Siebel application is contacted by an Inbound Web Service whenever the Policy Automation Project loads or saves data. So the next step is to import a ready-made Web Service. In Siebel, go to AdministrationIntegration > Inbound Web Service. Search for OPA Generic Connection. If it already exists, rename it and save the changes. Then click the green button and import the Web Service in the unzipped files. It is called OPA Generic Web.XML When you have done that, click the Gear menu again and Clear Cache.

By now you basically have a Web Service which will come inbound into Siebel, and this will trigger one of the Workflow Processes you imported.  They will be represented by the different Service Ports of the Inbound Web Service. At the moment you only have two Service Ports, one called CheckAlive and one called GetMetaData. These are used when modeling a Policy that needs to reference Siebel business entities.

Getting the Connection into Oracle Policy Automation

Now. log in to the Oracle Policy Automation Hub and proceed to the Connections menu. You are going to create a new Connection. Bearing in mind that you are going to be communicating between Siebel and the Oracle Policy Automation Hub, it goes without saying that if you are using Self-Study environments of Siebel and Oracle Policy Automation, for example installed on a Virtual Machine, this is going to be a hell of a lot easier than it will be otherwise – you would have to take into account things like firewalls between Siebel and OPA and so forth. Assuming that both Siebel and OPA are installed on the same VM, this means you do not have to modify the Service Ports in Siebel (they are all pointing to something like this


The localhost being your web server.  This is the URL you will need for the Connection in the Hub. You can follow the other items from the PDF white paper but here is a screenshot anyway.

The areas highlighted in red are respectively the address of the Web Service, and the smaller red box is to highlight something you will need to check. It corresponds to the Service Port Operations prefix that may be present in your Web Service. If the prefix is present (these are used to help distinguish different calls to multiple OPA Web Services) you would see it here in Siebel:

The full line from the Oracle Policy Automation Hub SOAP Action Pattern might look therefore something like this


With those elements entered into Oracle Policy Automation, with your Workflow Processes active, your Web Service Cache cleared and your EAI Object Manager running on the Siebel Server, then you should be able to open Oracle Policy Modeling, create a Project and add a connection to the Siebel data Connection through the ribbon, connecting to your Hub and then to your Connection:

That concludes part one of this post. Part Two will be posted when part one is successful for you all.

Logo by Southpaw Projects LLC