Notes On Siebel

Browser Script “on the fly”

Top tip today from Neel over at Siebel Unleashed: using the IE address bar to enter browser script.

I’ve never thought of this, and the key point is worth repeating: script entered into the address bar after a javascript tag is executed by the browser, in exactly the same way as browser script. This means that if you edit the address to be:

javascript:alert(theApplication().GetProfileAttr("Me.First Name"));

…then the browser will popup a message box with the value of the First Name attribute - exactly as you’d expect if this statement was in browser script. Much faster than navigating to Administration - Personalization > Test, plus it retains current context.

Nice quick-and-dirty hack to check (or set) the value of browser objects. Good work, Neel!

2 comments May 20th, 2008

Improving List of Values performance

A quick titbit to get things rolling again after an extended silly season hiatus…

Whenever you need to access lists of values data in your configuration, note that of the business components defined on the S_LST_OF_VAL table, Picklist Generic is cached while List Of Values is not. The impact of this is that repeated queries to Picklist Generic will be served from the memory of the Object Manager, whereas queries to List Of Values will always hit the database. So for improved performance be sure to use Picklist Generic in your configuration, not List Of Values.

Caching behaviour is controlled by the business component property Cache Data: when this property is set to true then the database is only read once for a given query. You can see in Object Explorer that Picklist Generic has Cache Data set to true, while it’s false for List Of Values. This configuration allows the List Of Values BC to be used for managing LOVs, where it’s critical to always have the current database values, while Picklist Generic can be used where performance is more important.

5 comments January 14th, 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

Order of Events

A quick list, for reference:

• Runtime Applet.PreInvokeMethod
• Browser Applet_PreInvokeMethod
• Server WebApplet_PreInvokeMethod
• Runtime BusComp.PreInvokeMethod
• Server BusComp_PreInvokeMethod
• Runtime BusComp.InvokeMethod
• Server BusComp_InvokeMethod
• Runtime Applet.InvokeMethod
• Server WebApplet_InvokeMethod
• Browser Applet_InvokeMethod

Essentially, the Runtime Event occurs before the equivalent server script event for the same object, plus the Applet browser script events ‘wrap’ all server side events.All of which makes perfect logical sense, but it’s sometimes handy to see it written down in a list.

3 comments July 19th, 2007

Custom Popup Applets

Obviously, with every implementation we do we aim to rollout a ‘vanilla’ solution. By now, everyone has fully ‘bought in’ to that mantra and understands the ongoing benefits of not over-customising. Having said that, there are still situations that justify slight, er, tweaks to the Siebel application…

A recent one for me included giving the user a list of options on completing an action. Now, I could get the result I needed by navigating to a new view, but the UI was pretty unfriendly. What I really wanted was a modal popup dialog.

In Siebel 7+ it’s possible to launch a pop-up applet from a normal applet by using the ShowPopup method. Details are in Bookshelf -> Configuring Siebel eBusiness Applications -> Configuring Special Purpose Applets -> Configuring Pop-Up Applets Launched from Applets. To summarise the instructions:

1. Add a control to your applet
2. Set the control Method Invoked to ShowPopup
3. Set the control User Property Popup to the name of your popup applet

The popup applet specified in the user property must use a class derived from CSSSWEFramePopup. To see all possible classes select ‘Class’ in Tools Object Explorer and query for ‘Super Class’ = CSSSWEFramePopup: the standard class for a popup list applet is CSSSWEFrameListPopup. (What if you can’t see Class in the object explorer?) If you’re creating a new applet for your popup and you don’t expect edits in the popup, it’s simplest to configure your layout in ‘Base’ mode.

The popup applet can be based on any business component in currently active business object, and will appear in context. So you could launch a popup from the Orders applet, for instance, and list all child Order Line Items. Alternatively, you can base your popup on a VBC and display any random list of choices you desire. Because it’s all in context, capturing the user action and invoking a change on the launching business component is trivial.

So that’s all good and easy; not even too much customisation. Click a button, up pops our applet. Now, the challenge for any bored configurators out there is this: how do we automagically popup this applet on a new record when it’s written for the first time? Suggestions welcomed in the comments…

9 comments July 12th, 2007