Tackle Siebel Performance Problems

As you read this, try to recall how many times has this happened to you. The development team has slogged for more than a few weeks to produce a piece of art and deploy it in dev environment. Everyone’s happy and, within no time, it is promoted to QA. If you have a “proper” QA, there is a big chance that someone starts complaining about performance of the new/existing view.

First, you try denial and try to concentrate on more immediate issues at hand, but finally comes a day when you scramble to put together resources to resolve the problem.

I have been in more than a few projects and believe me when I say this – most project teams end up in the above situation, unless they have put in a process to tackle Siebel performance problems as part of their development process. And what do you know, the biggest surprise is not many teams do that.

I believe the development team becomes so engrossed in their day-to-day work, no one really finds time to do anything except create, modify, fix and forget cycle. I gets worse- performance problems have a cascading effect. They inflict major damage to user community in terms of positive mind share and that damage is not easily reversible. So, it’s good to start early.

Let us try to outline what can be done.

Control the UI #

A client I worked with had his users believe that a list applet can only contain 20 fields. Too many fields being pulled from too many sources may be good to look at, but are they really doing anything there? Could you accomplish the same using reports (preferably OLAP!), could you convince the user that an extra click can retrieve the data but that click is going to save him 2 seconds to view most wanted data?

Best practices are your best friends #

Never under estimate best practice just because everyone echoes the same things. Never allow non-indexed searches, control searches using home page / find dialog / custom query applets, never have MVFs without primaries, index all foreign keys, do not script for something that can be accomplished in an alternate way, but at the same time do not be afraid of scripts when they can save a bunch of queries using Siebel operation steps in a workflow.

Use light BC #

Some of the OOB classes are heavy and come with a cost. For example, order line item updates may fire numerous queries for repricing the order. The cost is decreased by a large magnitude just by using a clone BC based on CSSBusComp class and doing a reprice after all updates. It may be interesting to note that there are several cloned business components already available OOB in v7.7+, take a look around

Async it! #

Evaluate whether your user may proceed with his work while you accomplish work in the background. For example, clicking on Submit button changes the order status and returns control to user, while working away in the background.

Don’t cut slack with your review process #

Examine and evaluate every join, every new field exposed newly on applet, every field that needs force-active or link-specification to be TRUE. Balance these factors against the performance trade-offs. For example, consider a one off query when you can afford it instead of just turning on Force-Active an d including the field in all queries

Put in a robust performance measuring mechanism #

Measure performance before and after proposed changes. Do not talk in terms of time or number of seconds, always do comparison using consistent gets. These gets will tell you how much work the DB has to do for retrieving the data that more or less remains the same across environments and regardless of “how much” data is present or the load on DB servers.

Also, try to leverage easier/effective ways to monitor Siebel performance .