Notes On Siebel

Shell command for Browser Script

A question on the Oracle discussion forum last week prompted me to dig out a MetaLink article that I’ve never noted here. The question was “How to call a local executable from the browser”: the answer is to use browser script to instantiate a Windows Scripting Host ‘Shell’ ActiveX object, like so:

var objWSH = new ActiveXObject("WScript.Shell");
objWSH.Run("notepad.exe");

More detail on using the ActiveXObject is available in the post on Client-side DLLS.

Add comment May 5th, 2008

Phone Number fields in Integration Objects

I’ve mentioned previously that Siebel’s handling of phone numbers can cause havoc for EAI. The post on International Phone Formats outlines how Siebel stores phone numbers as a continuous string including the country code (+610298767654), appending a new line and format string to store special formats (+61041234567890<CR><LF>0000 0000 0000).

This fancy footwork works nicely in the UI, (mostly) displaying numbers in the expected format for the current country. However, imagine a standard Integration Object defined on business component Account, with a component field mapped to the Main Phone Number . Invoke an EAI Siebel Adapter Query for this integration object and the phone number result will be the database value - rather awkwardly including that unpleasant format string.

In older versions of Siebel, the only way around this ‘feature’ was to pass the integration object through a custom business service, stripping those format strings and rendering the phone number as desired: effectively, re-coding the function that Siebel apply at the UI. This was a pain.

Fortunately, Siebel 7.8 saw the introduction of the Integration Object User Property UseFormattedValues to force the EAI Siebel Adapter to use formatted values. If we add this undocumented user property to our Account Integration Object and set the value to Y, then the Siebel Adapter uses formatted values and Main Phone Number will contain exactly what you see in the UI. This eases the pain nicely.

If you’re more familiar with Siebel Scripting, this UseFormattedValues property forces the EAI Adapter to use Get/SetFormattedFieldValue-type requests, rather than Get/SetFieldValue. One restriction is that the User Property can only be applied to the whole Integration Object, not to individual fields - the property doesn’t work as an Integration Object Component User Property, nor as an Integration Object Component Field User Property. That’d be a feature request for future versions…

MetaLink mentions of UseFormattedValues are sparse, but there is a thin definition, plus a complaint about the inbound error handling.

Add comment April 29th, 2008

International Phone Formats

Since version 7, Siebel has had a somewhat confusing treatment of international phone numbers: numbers entered in the default format are stored simply with the country code, while numbers entered in any other format have a format string appended after a character return. All phone numbers are then displayed in either the default format or with their specific format string applied. You with me?

To illustrate with some examples….

Suppose the following default formats are defined using the PHONE_FORMAT LOVs:

The Display Value defines the format for the number, while the Order equates to a country code - so +1 for US, +61 for AUS.

Now, let’s assume we’re running the Siebel Client on an Australian workstation. How do different numbers get treated?

Essentially, non-American numbers get stored as a continuous string of numbers, including the country code and ‘+’ international indicator. If the number is entered in a format that matches the default format, then that’s it. If the number is entered with a specific format, then this format is appended to the phone number. The separator between the actual phone number and the format string is a character return plus line feed [CHAR(13) || CHAR(10)].

This vanilla behaviour causes all sort of problems with integration - CTI, EAI, SQL etc - to the extent that most 7+ implementations I’ve worked on have ended up with some form of scripting to get around it. I’ll talk about some of the impacts and workarounds in more detail in future.

2 comments November 13th, 2007