Tag: Connector Framework

Excel as an OPA Data Connection

Excel as an OPA data Connection

In the English-speaking world there is an expression about the month of March that I like very much : “Mad march hares” (referring to those big goofy rabbits-on-steroids that start running about and looking for a partner right about now).

Well, we have been engaged in some madness here at the OPA Hub Website this week too.

It starts with a simple statement. We like to do demonstrations, and we often need a Data Connection to be able to do a proper demonstration “end to end” so to speak. And the scenario of the demonstration can change every day as we do things for different customers. So we are always looking to find ways to make it as easy as possible to do that. Let’s look at some of the options:

This feature allows us to create “fake” Connections simply by copying and pasting a template GetMetadata Response into the dialog. Nice, but this only handles the basic modelling and mapping experience. There is no data.

Readers will know that we are great fans of this product, and Mantis are also sponsoring our Website this half year (full disclosure). It should be evident from the videos we’ve done that we love it. But it requires a database, and that takes a little time to set up.

  • Excel as an OPA Data Connection

Yes, well, I will admit I was sceptical when I thought about it. But why not? The big advantages are obvious : if we have the metadata in the Excel, we can change field names and table names in 2 seconds. And creating test data is as easy as copy and paste. And you already have Excel on your machine!

Let’s think about the basic mechanics of how this works. I am afraid that this solution is easiest  to implement if you are in Private Cloud. Public Cloud is possible but it takes a bit more work. A local installation (where you have a local Virtual Machine for example) is also possible. We decided to go for the Private Cloud solution for our proof of concept. What do we need?

  • A Web Server – in our case Internet Information Server.
  • A Web Service – in our case written in Visual Basic as an old-fashioned ASMX file.
  • Microsoft Excel – accessible to the Web Server.
  • Oracle Policy Automation Hub – that can access the Web Service URL mentioned above.
  • Oracle Policy Modeling – that can access the Oracle Policy Automation Hub mentioned above.

Great Learning Opportunity

The great thing about doing something like this, however crazy, is the learning experience it gives us. If you want to get down and dirty to understand the nuances of DataTables, UpdateTables and MetaTables and all the other myriad structures in the Connection API, this is the way to get to grips with it – line by line and XML dump by XML dump.

Before going any further, yes, we know it is definitely not supported to do remote automation with Microsoft Office but this is a proof of concept! There will inevitably be some setup challenges to ensure that the Identity used by your IIS Application has also access to Excel, and you probably will spend a fair amount of time staring at DCOM error messages. We used this article as our debugging tool.

Starting Out – Getting the Stub Code

In Visual Studio, the best way to leverage the standard Connection API WSDL is to download it from your OPA Hub Connections Detail Page. Drill down on an existing Connection and find the download in the Actions menu.

Excel as an OPA Data Connection 1

Then you can use the Microsoft SD tool wsdl.exe to import a WSDL (like the one you have just downloaded) and turn it into a bit of stub code. You can generate it in Visual C# or Visual Basic, using a command line like this one:

WSDL.exe [/language:] [/protocol:] [/namespace:] [/username] [/password] [/domain] [/out:] <url or path>

Language can be VB, VC or even JS. Once you have your file generated, then you can create a new Web Service Project in Visual Studio (Community Edition or a more professional one if you have it). At this point you should have all of the standard service endpoints (CheckAlive, GetMetadata and so on) all in the code marked up as not being implemented. If you deploy your Web Service, sure you can call it with Soap UI but nothing will happen.

As you probably know, the basic set of endpoints for a useful Connection are

  • CheckAlive
  • GetMetadata
  • Load
  • Save


These will be our target for the prototype. CheckAlive is super simple since it returns an empty CheckAlive response. This is the trigger for the lovely green tick mark you see in the Connections list. If the web service responds with a CheckAlive response, you get a green tick:

Excel as an OPA Data Connection 3

The code is two lines long, thanks to the stub we imported earlier.


Obviously to be able to use the Connection, we need to be able to Model our data source. So the Excel spreadsheet is going to contain two tables. One for data, one for metadata. To keep things simple, the Excel spreadsheet just has two named ranges, and a place to name our object:

Excel as an OPA Data Connection

For our proof of concept, we are going to assume that the user of the Excel sheet remembers to keep the metadata and data synched (if the name of a field changes in the metadata, then the headings need to change in the data table). Not very hard to remember! The data table can contain as many rows as you want since it is just a named range.

Now that we have this structure built into the Excel, we need to implement the GetMetadata endpoint, so we can use these fields in our Modeling.

The obvious thing is to read the metadata from Excel, and then format it into a GetMetadata Response. And it works. The IIS Web Service opens Excel (!) and reads the information before formatting it and sending it back.

Excel as an OPA Data Connection 6

Since this is running from the Web Server, we can access this Connection Web Service from anywhere, and nobody would know there is an Excel spreadsheet behind it. Edit the Excel, change the field names and data, refresh the Connection and ready to go!

We’ll look at the Load and Save endpoints, as well as discussing more about the actual mechanics in the next post.

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.

Logo by Southpaw Projects LLC