Inbound ASI–Keeping it simple

 

What is the easiest way to setup a new inbound web service in Siebel ? Well, a lot depends on the actual requirement, the complexity of the schema, error handling features etc. If the requirement is really simple, I try to go for an Application Service Interface or ASI. And specially if the requirement calls for multiple operations at a single web service, then ASI is the way to go.

An Application Services Interface (ASI) is a release-independent interface published by Oracle that allows you to integrate Siebel applications with external applications. An ASI is a collection of related methods; each method contains input and output parameters. The methods and parameters are listed on the business service definition. Simple method parameters (such as a string or number) are defined directly in the service definition. Hierarchical method parameters are defined using integration objects

Lets assume that the requirement here is to expose a query operation as a web service. The end point would invoke a Siebel web service which would extract data in a schema. Simple query operation. Here is how to do it in an ASI.

Step 1 : Define your schema. Decide upon an already present Integration Object or design a new IO from scratch. Here I’m choosing a custom Service Request IO, with attachments as the child IC. Don’t forget to decide upon the user keys and status keys.

 

Step 2: Define the ASI business service. Create a new business service, and set the class as CSSEAIDataSyncService. Define a method for this BS as QueryPage. Here I have added one more method for InsertOrUpdate.

 

Define the arguments of the methods. There has to be at least one argument of type Integration Object. Mention the IO name you had chosen in Step1

Two Business Service User properties are required.

Instead of creating the BS, an existing ASI can be simply cloned, in which case you would only need to change the IO name.

 

Step 3: Expose the BS as an Inbound web service.  Compile the IO and BS. On Siebel 8, simply right click the BS and choose deploy as web service. Or you could setup the service yourself.

In the application, go to Sitemap > Administration – Webservices > Inbound Webservice.

In service name, give any name and set the namespace. The namespace can be taken from the IO userproperties.

In Service Port, choose the newly created BS. Set the binding and transport values. Here I have chosen SOAP_DOC_LITERAL and HTTP Transport

In the Operations applet, the methods of the custom BS will be available. Set them up, and clear the cache.

That’s it, your done !!  You can generate the WSDL, and this can be consumed by the end point. The end system will get to see the various operations exposed under the service.

Here is how the WSDL looks when consumed in XML Spy:

And on choosing QueryPage method, XML Spy will generate this SOAP Request.

Regarding the different methods that can be exposed, there are six to choose from. And if needed, you can also provide datamappers for the request or response.

ASIs implement error handling in their own way and return SOAP fault codes back to the calling system.

Siebel ASIs are prebuilt and can be used immediately. ASIs provide a release-independent integration interface to the Siebel application, which remains unchanged with each upgrade to a new release. This is one of those few areas in Siebel where there is an upgrade-proof guarantee from Siebel/Oracle.

Scripting and Task Based UIs

Siebel 8's task based user interface (TBUI) is a nifty feature, but it still needs some more polishing though. A really simple looking requirement came up the other day, and I was surprised that there was no out of box feature I knew to support it.

The requirement was to conditionally disable tasks in the Task View pane applet. The Task Groups have to be associated with the triggering views, and when the logged in user enables the tasks by clicking on its button, an applet opens up in the UI on the left side, always showing all the tasks associated with the current opened view.

Now we wanted to conditionally disable certain tasks depending upon the user's position, and there was no way of achieving this. On searching on the bookshelf, I found a way to trigger the task  from script.

if (name == "Test")
{

var inputPropSet;
var outputPropSet;
var taskUIsvc;

inputPropSet = theApplication().NewPropertySet();

outputPropSet = theApplication().NewPropertySet();

taskUIsvc = theApplication().GetService("Task UI Service (SWE)");

inputPropSet.SetProperty("TaskName","Create a Contact");

the outputPropSet is created. outputPropSet is not used to send results back to the task UI--!>

taskUIsvc.InvokeMethod("LaunchTaskFromScript",inputPropSet,outputPropSet);

return ("CancelOperation");

}

So now, instead of showing the tasks in the task pane applet,  we trigger it from scripts behind buttons in the UI. We have buttons for different tasks, and the buttons themselves are enabled/disabled based on positions.

I'm hoping Siebel provides an vanilla way of achieving conditional task enabling/disabling in the UI soon.