Siebel at the Doctor’s Office

Most of our clients know at least one place in their Siebel solution, where they can click and then go grab some coffee while waiting for a response. Perhaps, there are such places in your Siebel system as well? Are users telling you that Siebel is slow? And do you know how to approach those issues?

Here I will try to cover most of the common solutions or approaches that could be taken in order to tackle the slow performance. I will base my suggestions on the experience that I have gained in ten or so different Siebel engagements, as well as performing quite a few configuration reviews. Having been reviewed by some of my colleagues with significant experience in this area, this article became a comprehensive summary of performance-related Siebel knowledge – something you are likely to benefit from, right away!

“Everything in Siebel is slooow” – that’s one of the most common complaints you hear, but this statement is seldom true. More often than not, some follow-up discussion would reveal  that in fact only some areas appear to be slow, but those areas are typically used on a daily basis – hence the perception. The best way to approach this is to ask users – and not the only one who complained, but a few from different roles: “What are the three most annoying places, where you routinely see performance issues?” In their replies, you will most certainly see a pattern; what you need to do now is to address the highlighted areas, and then repeat the question again after a few months, in order to check the results and reveal the next set of pain points.

In most of the cases, however, the identified areas will fall into one of the categories:

1. Complaint: one of the areas is slow, e.g. most of the actions what we do on Assets are really slow. There can be multiple issues that should be checked and addressed separately.

   Cause: large amount of data. Typically you would know the areas, where you have most of the records in the database. If you don’t, check with your database administrators, as they could provide you with a good insight about the amount of data, as well as its growth trends. If there are such “heavy” entities, then there are multiple approaches to tackle that. Check the underlying configuration – could it be that it is not optimal? Perhaps, some of the data that currently resides in those large tables could and should actually be separated from the main entity – identifying it would also help! This could turn out to be a quite significant change, because in an established solution multiple things are tied together; however, despite the potential complexity, in some cases this could turn out to be the best option on the table.

   How to proceed:

   1. Verify that the database fields used in search and sort specifications contain indices. This is done best together by Siebel configuration team and the people, who can analyze database performance well. Typically this can be accomplished by analyzing long running queries and checking, whether the columns contain proper indices in Siebel configuration.
   2. Check for misconfiguration, such as too many fields being Forced Active. Although this seems like a purely technical peculiarity, its implication on performance is rather straightforward. When an entry is shown to a user, Siebel retrieves the data for the fields visible on user interface from the database; however, in addition to that Siebel also retrieves all the fields that have the Force Active property enabled in the configuration! Sometimes development teams neglect the performance impact of this property, and set it ‘just in case’. That might generate additional calculations or queries that might not be required by the business processes, as a result of which performance is lost. Indeed, it is a time consuming task to identify this kind of misconfiguration without any automation support, but even so it can be a sensible thing to do, if an area in question has significant performance issues.
   3. Start planning for data archiving. Typically, an enterprise would use a data warehousing solution that holds all the historical data. With that in mind, the right question is: do we really need to have the information about a call made by a client 6 years ago at our fingertips? Or, say, a notification of a message being successfully delivered to your EPR system... 2 years ago? Unfortunately, there’s no out-of-the-box solution readily available for Siebel, but there are things that you could at least consider: look into the data, how old is the information that you really need to store? Can the older data be deleted – or it might be required, even if on a very rare occasions? If you still need to access it, then moving it to the archive database could be a solution; then it could be retrieved by the administration team on demand. Alternatively, for an immediate accessibility the data could remain in Siebel database – which won’t yield any performance benefits, of course… Generally speaking, data archiving in Siebel is a story in and of itself, so I could probably address it separately later on.
2. Complaint: one particular view is slow, while other similar views seem to work fine. This most typically happens with views like “My Subordinates Sales Cases”, or if the view in question has been created for filtering, e.g. “My Incomplete Email Orders”.How to proceed: check with your configuration team, what search specification rules have been set for those views? Sometimes there are heavy calculations, sometimes fields that have not been properly indexed. Let your configuration team describe the search specification in business terms, and then check with your users – does it match their expectations? That way you can identify redundant, unnecessary or overly complex rules that therefore can be simplified, yielding a reduction in computational complexity and, hence, performance benefits!

3. Complaint: one particular user says that for him everything seems slow, but works much better for a colleague of his or her, even in the same view.How to proceed: maybe this particular user has created some slow-performing pre-defined queries of his own? This is the first thing you should be checking, and the easiest way to do it is to ask the user to press the Query and Execute button, in order to perform a query without any rules, i.e. removing the rules from a pre-defined query. If that relieves the problem – simply disable the pre-defined query, or assist the user with rewriting it properly.

Note that the above applies to issues introduced through configuration. There is, however, one extra case – and that case is Scripting. Applicable to almost any of the scenarios above, heavy scripts with additional queries or calculations on events like PreQuery, ChangeRecord or PreCanInvoke (this one runs most frequently, since it is checked on any change of each of the controls) that can severely impact your application are a definite subject for checking with your configuration team. I have seen cases when it is not possible to avoid using such heavy scripts, but either way those should be used with care.

All of the above relates to the navigation within the Siebel solution; there is, however, one typical area that has most of the performance issues, as stated in the beginning of the article: “press a button and get some coffee”. Sometimes those are processes that are triggered on a change or some other event; but the majority of such issues still are a result of a “button” being pressed.

Most certainly, if you have a button that takes a few minutes before it yields control back to the user, you need to tackle that one way or the other. You have more than one option: running the process in the background, re-thinking what the underlying process does and whether that is an optimal solution, checking the configuration – is it built according to the best practices? Are you using the full range of Siebel capabilities in this case?

Take your configuration team and check with them, what are the things that take so much time in the process, and try to optimize exactly that.

In the end, I would like to say that most performance problems will start showing up only when you accumulate more data, i.e. the solution gets used by more users, so be ready to review and improve the performance repeatedly, on a continuous basis. If you are facing performance issues developing a new solution, sit down with your development team and talk! You need to find the causes and solutions, as the performance will only get worse, so be sure to start tackling problems with as much handicap as you can possibly get!

Need assistance with configuration review and performance problem analysis? Give us a hint, we can help! And check out this slide deck for some more info: