EAI Siebel Adapter vs. Generic Scripting for Updates

Say you have to update two fields in the Opportunity business component through Siebel Business Service script, what do you do?

Hint: You get down to business, as questions later.

Of course it goes without saying that the URS point designer, and will evaluate whether workflows or user properties can be used instead of scripts. That is another story for another day.

You’ll write the following script:

var boOpty = TheApplication().GetBusObject("Opportunity");
 var bcOpty = boOpty.GetBusComp("Opportunity");
 with (bcOpty) {
 SetViewMode (AllView);
 ActivateField("Name");
 ActivateField("Sales Stage");
 SetSearchSpec("Id", sId);
 ExecuteQuery(ForwardOnly);
 iIsRecord = FirstRecord();
 }
 if (iIsRecord) {
 bcOpty.SetFieldValue ("Name", "Desktops and Servers1");
 bcOpty.SetFieldValue ("Sales Stage", "02 - Potential Lead");
 bcOpty.WriteRecord();
 }

Nothing wrong with this.

But imagine you have to update 20 fields in opportunity, create notes for the opportunity, and update 5 fields in the opportunity’s contact and account.

You can certainly do all that writing additional lines of code. But there are a couple of challenges -

You have to find a way to commit/rollback all changes, or notify the caller that specific updates failed. For example you may not be able to update the status field in Contact while rest of the updates went through.
You add too many lines of code to perform query on the target business component, and to check whether records are returned from the query before going ahead with the updates
The performance of such a script is not going to be fantastic. Remember that each of the statements is an API call for Siebel

You can avoid all these problems by using integration object (IO) and “EAI Siebel Adapter” service for updates.

Though real-time interface guys have been using IO for a long long time, somehow the configuration team does not warm up to it.

Here’s how you can use IOs to accomplish the same objective -

var psUpdate = TheApplication().NewPropertySet();
psUpdate.SetType("SiebelMessage");
psUpdate.SetProperty("IntObjectName","SWIOpportunityIO");

var psTemp = TheApplication().NewPropertySet();
psTemp.SetType("ListOfSWIOpportunityIO");
psUpdate.AddChild(psTemp.Copy());

psTemp.SetType("Opportunity");
psTemp.SetProperty("Id",psIn.GetProperty("Opportunity Id"));
psTemp.SetProperty("Name","Desktops and Servers1");
psTemp.SetProperty("Sales Stage","02 - Potential Lead");

psUpdate.GetChild(0).AddChild(psTemp);
psIn.AddChild(psUpdate);

var bsEAI = TheApplication().GetService("EAI Siebel Adapter");
bsEAI.InvokeMethod("Upsert", psIn, psOut);

This looks intimidating at first, but is straightforward.

Integration objects are a reflection of business objects, and there are integration components under the IO that map to business components. You just create the hierarchical structure of the integration object, populate with values, and let it rip.

No activate fields, no checking of transaction completeness, no checking whether record exists - no fuss. All business layer validations and automations continue to be respected.

This method certainly will not help you if you’re trying to update a couple of fields in one BC. However as the input data complexity increases, you will see the real power of using the IO/EAI Siebel adapter Combination.

Do take note - the above code may look laborious, but there are many options to modularise this code and make it simpler to reuse. Take a look at Prototypes and Script Libraries in Siebel .

Recent Articles