Category: Web Services

Oracle Policy Automation and Siebel Innovation Pack 16 #6

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.

Overview

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 to Do with 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.

Finally

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 #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.

Next…

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!

 

Whats New in Oracle Policy Automation November 2017 #2

Whats New in Oracle Policy Automation November 2017 #2

As in the previous post in this series, the OPA Hub Website is concentrating on the new features, or “Whats New in Oracle Policy Automation November 2017” to be more precise. This is the second in the series. In this post we will explore two different functionalities that have been improved. Firstly, we have all probably at some point found ourselves creating attributes, and thinking about default values : setting them on the different screens of our Interview and so on. We probably also have then spent time creating Rule Tables to handle what happens when we have to default values based on the certainty of other information.

Default Values in Web Service inbound attributes

These days, managing default values in a Web Service environment just got easier. Consider the following simple example. The insurance premium is inbound in a data Connection. It is copied into an attribute called the baseline annual premium. If the inbound value is uncertain, then the default value (in this case £500) will be used. If the inbound value is different to £500, then that value will be used instead. If the inbound value is unknown, then the value of the baseline annual premium will be unknown.

Whats New in Oracle Policy Automation November 2017

Set True and False values in one shot

Another feature from the Whats New in Oracle Policy Automation November 2017 collection : in the same vein, you can now use the If function to set values for a true or false result of a condition, like you would for example in Microsoft Excel formulae. Think of it as “If(expression, value if true, value if false)”.

Whats New in Oracle Policy Automation November 2017

If the baseline annual premium is greater than 500, then the percentage of legal fees will be 100. Otherwise it will be 50. The documentation refers to “condition” but in different places it refers to Boolean attributes or conditions. In any case, it seems to work with both.

Both of these will provide decent shortcuts to existing workflow for developers looking to create cleaner rules. You can find the details in the online documentation here. Catch up with more “Whats New in Oracle Policy Automation November 2017” in the upcoming third post, where we will look at cool new features in the Interview.

PS : Note that my example assumes a Project using the English United Kingdom regional settings.

The OPA Assess Method in Oracle Policy Automation Determinations #2

The OPA Assess Method in Oracle Policy Automation Determinations #2

Following from the first part of this tutorial about Oracle Policy Automation and the Determinations API, you finished the previous post with your system all ready to go for the initial use of the Web Service and the two methods. Firstly, you will use the ListGoals method to practice but also to learn an important step, then the Assess Method (Oracle Documentation). In the setup of the previous part, we deliberately ensured that anonymous access would not be possible. As a result, you will need to do some extra work before you can try out your Web Service.

Viewing the ListGoals Request

If you open the ListGoals folder in the SOAP UI interface and examine Request 1, you will see something very similar to the following:

The OPA Assess Method in Oracle Policy Automation Determinations - ListGoals

 

Notice that in the example, I have edited the “show-version” tag to read “true” instead of the “?” which was previously present. Many times in the following examples you will need to either edit such elements, or remove them completely if the information is not mandatory. Clicking the green triangle present in the top left hand corner of the window does not, however, get us any kind of useful response. Rather we have an error, telling us that the request we sent did not contain information sufficient to authenticate our request.

Adding the Header information for the SOAP Request

The following screenshot shows the editing you will need to do in your request (on the left hand pane) in order to proceed any further. The header information will be needed in any request you make (ListGoals or Assess methods) in this environment at the current time.

The OPA Assess Method in Oracle Policy Automation Determinations : Authentication

Once you have made these changes, save the header somewhere useful since you will need it all the time in the following examples.

Click the green triangle again. If you are still getting error messages in the right hand side pane, remember that the OPA Hub User you are authenticating with, must have permission to use the Determinations API. Check that by logging in to the Oracle Policy Automation Hub as a Hub Administrator, and viewing the details of the user in question. For ease of viewing, I have highlighted the setting that needs to be checked in order for the user to be allowed to perform the steps you are trying to do:

Viewing the Results

Hopefully, your next attempt at clicking the green triangle is more successful. Here is an example of the result you might have, if you are usin the same Project as I demonstrated in the first part of this post.

The OPA Assess Method in Oracle Policy Automation Determinations : ListGoals Response

The following annotations might be useful

  1. Notice the version information. If you set the request “show-version” to false, this section will not appear.
  2. The global entity is clearly marked.
  3. Notice this attribute does not have a readable Id. If you have forgotten to add names to your important attributes, you will see auto-generated Ids like this one. This should be your cue to go back to your Project, add a name, upload and deploy your new version.
  4. This entity has a name.
  5. The entity name, text and type are all clearly visible.

TIP : You will probably want to go back and add names for all of the attributes (race date, imminent race, and so on) and deploy that version.

What have you obtained?

The output has listed the top-level goals for the Project. In our case, there are Global and entity-level goals that can be inferred by providing the right information to perform an assessment. The ListGoals lists, as it’s name suggests, the goals you can obtain outcomes for.

Armed with this information you are ready to go further. Let’s suppose you are interested in the goal called “h_status” in my example. We can attempt to obtain some output.

Assess Method Initial Call

Our first call will be made using a very cut-down version of the complete request. Since our Project contains no Properties, no Change Points and since we are going to ask for the same level of information about all of our attributes and get a level pf outcome information that is the same, no matter whether we are receiving (whether the outcome is uncertain or certain), the request can be cut down to look like this;

The OPA Assess Method in Oracle Policy Automation Determinations : Assess Request 1

Notice the outcome section where we have asked for the values of the horse and the horse status, and the global attribute race_date which we have entered as our request input. The result, assuming you have been using the same Project, would be something like the response below.

The OPA Assess Method in Oracle Policy Automation Determinations : Assess Response 1

In this output, the following areas are highlighted :

  1. The race date is reiterated
  2. The entity instances of the horse entity are shown, each with the name and the status
  3. The attributes are inferred as you would expect

Outcome Styles and Assess Method

In this first request, you set outcome style to “value-only”. Two other choices are possible at this juncture.  Change the outcome style for the horse status to “base-attributes”, as in the example shown below.

The OPA Assess Method in Oracle Policy Automation Determinations : Assess Request 2

Upon executing the request, you will notice that the outcome has more detail. This information is very useful, since it highlights the base attributes that are needed to infer the horse status. In this case specifically, the date of the race.

The OPA Assess Method in Oracle Policy Automation Determinations : Assess Response 2

Finally, change the outcome style of the same attribute to “decision-report”. Now the output will include the tree of decisions that lead to the output:

The OPA Assess Method in Oracle Policy Automation Determinations : Assess Response 2

So far so good  – Assess Method

So it is clear that the outcome style can not only assist us in understanding which attributes are needed as input (base attributes) but also in understanding the decision that was made (decision report). In the next part of this series we will investigate other tags in the request and response.

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!

Worldwide
Logo by Southpaw Projects LLC