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.

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.

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.