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:
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.
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.
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
- Oracle Policy Automation and Siebel Innovation Pack 16 #1
- Oracle Policy Automation and Siebel Innovation Pack 16 #2
- Oracle Policy Automation and Siebel Innovation Pack 16 #3
- Oracle Policy Automation and Siebel Innovation Pack 16 #4
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.