So when we left the previous post, we had completed much of the legwork required to enable communication between Policy Automation and Siebel Enterprise. A quick recap:-

Determinations Server uses web service-based communications with Siebel and therefore needs the EAI Object Manager to be online, and may use Workflows and Scripting, Web Services and other standard associated Siebel objects.

Web Determinations Server is typically embedded as a Symbolic URL but can also communicate with Siebel via the EAI Object Manager in the case of the custom versions provided with the Siebel Connector. In short, these two customized applications include a plugin to communicate the session data and more back to Siebel at the end of the Web Determination.

One repetitive theme that comes up whenever installing the Policy Automation Siebel Connector is the need to check and / or correct the following:-

Employee Symbolic URL (used for the AdminSmokeTest) – this is a reduced complexity, simple 4 argument Symbolic URL to call the testing rulebase. The Port might need to be changed to point to your Apache installation.

Policy Automation - Employee URL

Web Determinations Symbolic URL, a more complex set of arguments for launching the Web Determinations window from the Sessions applet. In both of the Symbolic URLs you may have to edit the order of the arguments by referring to the installation guide.

Policy Automation - Web Determinations URL

Inbound Web Services used for the mapping of data

Policy Automation - Inbound Web Services

Outbound Web Services used to call Policy Automation Determination Server.

Policy Automation - Outbound Web Services

So now we are ready to perform some tests of your new Policy Automation and Siebel environment. Go to the Smoke Test View and click either of the DS Server buttons. The SmokeTest runs a simple rulebase that returns TRUE if you are on the SADMIN record and FALSE if you are on any other record.

Policy Automation - DS Smoke Test

In both cases, if you are on the SADMIN record, you should see this.

Policy Automation - SmokeTest SADMIN

On another user you should see this instead.

Policy Automation - SmokeTest Other

Repeat the process with the Web Determinations buttons, and verify that you get this.

Policy Automation - Web Determination SmokeTest SADMIN

Policy Automation - Web Determination SmokeTest

A common issue at this stage is the Web Determinations give an ugly 500 error. If this occurs, change the Symbolic URL to the correct embedded web determination server name as shown below, then logout and login again, rinse and repeat.

Awesome. We have come a long way. We have a functioning Siebel – Policy Automation integration. Perhaps the key issue to remember is that each rulebase will require administration and technical steps – this is not a case of “integrate two applications now forget about it”. Each business ruleset will require us to think about how and when it will be triggered in Siebel, and how the rulebase maps to Siebel metadata. To get started on the concept, look in the Administration – Policy Automation Mapping and IO Mapping Views. Given that each rulebase may target different data, you will often be working in here.

Policy Automation - Mapping

 

Given that the output of each rulebase will be different, both in terms of actions, data and reports, take a moment to review the Decision Reports that your tests have generated.

Policy Automation - Decision Reports

Switch to the Decision Report Viewer to test whether you remembered to copy the provided XSLT into the Siebel Server XSLT folder.

Policy Automation - Decision Reports Viewer

In the next post we will show how to set up a new rulebase for integration with Siebel and get it properly integrated. Stay tuned.