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