Intelligent Advisor and Siebel 21 #4 : Checkpoints in Interviews

Posted on February 15, 2021August 4, 2021 by Richard Napier

In the fourth part of this series we look at two major Workflow Processes / web service operations that are part of the standard setup of the White Paper integration with Siebel 21 : OPA SetCheckpoint and OPA GetCheckpoint.

These Checkpoints functionalities are obviously useful for any Intelligent Advisor Interview that needs to support checkpoints, and naturally will be appreciated by users when they have to pick up an interview half-completed either by themselves or by someone else. A reminder for those who are not familiar with checkpoints. They allow the user to leave an interview and then resume it, recovering the data they entered, because behind the scenes a snapshot of the session is saved somewhere (in Siebel in this case) and retrieved when resuming.

One of the traps of this set of Checkpoint operations is that they require you to have implemented, at least in part, the version 10 connector. Let me explain. The table used by the Checkpoints mechanism S_PA_DSCN_RPT to store the data of the session will only exist in your Repository if you have installed the version 10 connector. This table formed part of the package of tables used in that version. I find it a shame that the Siebel – Intelligent Advisor integration White Paper assumes that there are no new Siebel to Intelligent Advisor customers. Anyway, putting aside that slightly political debate, here is what you need to do:

Download and unzip the version 10 connector for Siebel from edelivery.oracle.com. In the various subfolders of the installer, look for the SiebelObjects folder and find the SIF file called pa-release.sif.

Intelligent Advisor and Siebel 21 #4 : Checkpoints

Extract that SIF file.
Create a project called Table Policy Automation and lock it (remember that Tables are not managed using Workspaces as of 21.1)
Edit the SIF file so that it only contains the Table called S_PA_DCSN_RPT. This should not be too hard since the XML format of the SIF file makes editing easy. And yes, I know you are not supposed to do that but we’re all adults here.
Import the table.
Apply the changes to the Schema using the Siebel Tools Apply button.

Now, if you have not already done so, go ahead and

Create a new Workspace for your Checkpoints edits
Import the Business Object, Business Component and the two Workflow Processes (OPA Get Checkpoint and OPA Set Checkpoint) from the White Paper Zip file SIFs.

Intelligent Advisor and Siebel 21 #4 : Checkpoints Table

The Checkpoints table now exists in your database, and you now have a Business Object and Business Component sitting on top. Which means the Workflow Processes should be able to query or insert records in that table. Eagle-eyed readers will notice that this table was not destined originally to hold checkpoints (the clue is in the name of the table) but the presence of a CLOB column makes it a good target for the Checkpoint as the Base64 string will store nicely in there.

Before you update your Web Service and deliver the Integration Objects and Workflow Processes, remember to remove the Default String for the Object ID in the OPA Set Checkpoint Workflow Process Properties which someone left behind by accident – otherwise you will just get errors when you try and set a checkpoint.

Everything should now just work fine (assuming you have an Interview that uses checkpoints. Let’s look at a similarly simple Project like the one we used in the previous chapters of this series and uncover some things you will have to think about. What we want to do is this (as an example):

Intelligent Advisor and Siebel 21 #4 : Checkpoints Setting in OPM

We want to be able to select the Checkpoints options. But even if you have set up the two new operations in Siebel, cleared the cache and so on:

The Checkpoints option will not be accessible to you. Why? Because even though the White Paper says it has added the correct attribute to the XSLT file, I found that it had not. So you need to edit the GetMetaDataResp.xsl XSLT file and either add it as a fixed value or do something clever, but you need that attribute to be true if you want your connection to use Checkpoints:

Intelligent Advisor and Siebel 21 #4 : Checkpoints Attribute in XSL

Now we can launch the interview and test it. At which point we have another issue that in anything other than the short term you will need to fix:

The OPA Set Checkpoint Workflow Process assumes that the ID to use for the Checkpoint is the first parameter in the URL. So if you need to launch your Siebel-connected interview with http://localhost:7003/opa/web-determinations/startsession/XXX?id=1-IU3 (where Id is a Siebel Row Id) then that will load the Siebel row – just as we explained in the Load Workflow – but it will also use the same ID for the Checkpoint. So what, you say?

The issue is that the OPA Set Checkpoint Workflow Process does an Upsert into the Checkpoints Business Component, using the parameter as a the key. So there is only going to be one checkpoint for that record as the Upsert will find it and update it with the new Checkpoint. In reality you will need to go back to this Workflow Process and add more complexity to it – handle a second parameter in the URL, or add more criteria to the Upsert query (for example there is a Field called Configuration Name which currently has a fixed value – perhaps save the interview name in this field to at least have a checkpoint per interview (and change the query to accomodate it) or better still adopt a second parameter for the checkpoint id with something like a timestamp in it.

Please understand I’m not criticising the White Paper – they do mention that the Checkpoints mechanism needs more work – I’m simply trying to let you know before you get stuck.

So now you should be able to launch an interview with startsession and your Siebel ID, save a Checkpoint at a Screen of your choice, and then launch it with resumesession and get the relevant data back in the browser: