Notes On Siebel

Siebel User Group Australia Event - 21 February

For all Sydneysiders reading: the next Siebel User Group event will take place on the 21st February. We’re back at the AGSM for a panel discussion on The Role That Siebel Plays In Your Enterprise, after which there’ll be the usual opportunity to catch up with past and future colleagues.

It’s a good broad topic with excellent panellists who I expect them to make my moderating role largely redundant. The last two SUGA events have been oversubscribed well in advance, so get on and register now.

1 comment February 7th, 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

More on Script Assist

A great update on the Script Assist functionality I mentioned a while back. In a comment on my original post, Jake pointed out a “*huge* performance impact when the method listing and autocomplete options were enabled on scripted BCs in v8″.

Now, an anonymous commenter posts that this problem has been recently fixed and “should be available as a QF and in the FixPacks”. The comment also highlights some of the additional scripting improvements in 8.0 that I hadn’t come across - including “Fix & Go” debugging, Siebel’s version of Visual Studio’s “Edit & Continue” - and signposts an “upcoming 8.1 feature, Script Performance Profiler”.

I’m very (inordinately?) pleased with the additional information. Partly because the improvements are all good, legitimate changes that drag Siebel Tools towards with other fully featured development environments, but moreso because it’s great to see an employee of Oracle monitoring and feeding back directly into the development community. This is exactly the sort of thing I was hoping to see when I started the blog… may a thousand geeky conversations bloom

2 comments October 29th, 2007

Why there may be a place for Direct SQL

Over at Service Oriented Shenanigans Graham’s written a good, provocative piece titled Why Direct SQL is a very stupid thing to do. I’m happy to be baited… I started to respond there, but it turned into something worth a full post. Hopefully trackback pulls the whole conversation together like it’s supposed to…

Graham argues that because Siebel implements referential integrity through the repository rather than through database rules, it’s idiotic bypass all these rules and run SQL directly against the database. I’d make a few points:

• If you’re using Siebel Remote, then direct SQL could be additionally stupid. Any changes made directly to the database are not be propagated to the transaction log, so won’t be routed to the local databases, so your server will be out of sync with your remote clients… Nasty!

• If, however, you’re NOT using Siebel Remote, or you’re re-extracting all your local databases anyway, then I’d argue that there is a place for direct SQL. A limited place, sure, requiring utmost care, diligence etc etc, but at the end of the day it’s just another tool to only be used when appropriate. Siebel Expert Services will happily run direct SQL when the alternatives are ridiculously cumbersome. The alternatives (e.g. EIM, EAI) are also quite capable of significantly damaging your database and also require an appropriate level diligence: developers shouldn’t lapse into thinking that just because things are being done with the ‘proper’ methods they can’t do harm (EIM Delete in the wrong mode, anyone?).

• If you use direct SQL to insert a record, then you won’t get a Siebel Row Id. The procedures to generate a Row Id are in the database and could be called directly, but this really is idiotic. (I actually worked on an implementation where Siebel Expert Services had done this - hmmm…)

So don’t use direct SQL to insert records, and don’t break your referential integrity, but do remember that SQL is just another tool, with pros and cons to be weighed against the alternatives. And don’t come crying to me if you break your database and your architect justifiably calls you an idiot.

3 comments October 17th, 2007