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!

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.

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.

• 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.

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…

This behaviour is supported everywhere there’s a many-to-many parent-child relationship. When defining a new field, the Join property is bound to the list of joins defined for the business component. So the trick is to create a basic join to the intersection table – no need to specify a join spec or any details – then you can define your new fields and, when you’re done, delete the join. Siebel will recognise it as an implicit join and pick up data from the intersection record used to retrieve the child.

- HTML Type: URL
- HTML Display Mode: EncodeData

This will URL-encode the field and wrap it in an HTML link tag <a></a>. As long as your field contains a valid URL, you’ll have a working hyperlink. In the high-interactivity client the URL will by default open in a new browser window; to support the same behaviour in the standard interactivity client, set:

- HTML Attributes: target=’_blank’

This approach doesn’t allow you to change the link title, however, so if it’s a big ugly URL you’ll have a big ugly field displayed in your applet. As an alternative, you can hand-code the hyperlink. Set the calculated value on your field as follows:

“<a href=’http://yourURL.com/yourtargetpage.html‘ target=_blank>Your Link Text</a>”

(Note the enclosing double-quotes.) Then set up your applet control:

- HTML Type: Field
- HTML Display Mode: DontEncodeData
- Runtime: Y

This tells the Siebel UI to interpret the contents of the field as raw HTML – so you see your hyperlink exactly as constructed.

This one is relatively simple but it is worth pointing out. Sometimes its the little things that make you weep for joy as a developer.

In the bad old days of Siebel (i.e. before 7.7), the world was running around clubbing each other over the head, saying “ugh” a lot and wearing animal skins. Then the light shone upon the world and we were given:

WriteRecordNew and WriteRecordUpdated.

These are Runtime Events that I noticed just recently. Many many times in config, you need to do something when a record is written. You place code on the WriteRecord event (so that you can avoid having to worry about the user doing Undo, stepping off a field and recorrecting etc). But then you need to do different things depending on whether the record is new or updated.

Usually what you needed to do was set some global variable when the NewRecord event fired, test that variable in WriteRecord, then clear the variable. It usually worked, but it was not elegant. I have seen implementations where the code on the WriteRecord event runs into the thousands. But we won’t mention those.

Now, the great and glorious Siebel gods have seen fit to now provide us with Runtime Events that distinguish between New and Updated records! Hallelujah brother!

State Model Rule Expressions use the same format as calculated field values, so the same MVG aggregate functions are available. The functions Count, Sum and EXISTS all derive a single value from a Multi Value Group and are an underused way to reduce scripting.

In the example given, Service Request has an MVG Action linked to the child Activities, so we can add a Multi Value Field to point to Action.Status. A rule expression Not EXISTS([Action Status]<>'Done') in the State Model transition gives the desired restriction.

There’s a good example of the EXISTS function in use in the vanilla Siebel 7 repository: see BC Contact field Exists New OutBound Email Activities.

When you execute any query, Siebel converts the user’s logical instructions to SQL. It doesn’t always do an optimal job, but you can usually be sure that most of the effort will be pushed to the database server. The problem with calculated fields is that certain functions don’t have standard cross-platform SQL equivalents.

The IIf function, for example, will never be translated to native SQL. When your field calculation contains an IIf statement, Siebel will write SQL to return a superset of data. The Siebel object manager is then left with the job of paging through the results, evaluating the calculation for each row. Needless to say, if the incomplete SQL returns a large dataset, this ain’t going to be fast.In any particular example it’s worth eyeballing the SQL to confirm where the calculation is happening, but you can definitely expect problems with the following functions:

• IIf
• IfNull
• ToChar
• Right

Unfortunately, there’s no configuration way to prevent searching on an unpleasant field. If you’re running into problems then you’ll have to hit the PreQuery event with some scripting…