Workflow Monitor Agent

Siebel Bookshelf can be a little confusing in its discussion of Workflow Monitor Agent. If you don't read the Bookshelf chapter carefully, you can come away with the impression that Workflow Monitor Agents must be administered from the command line and dynamically configured.

The key to the whole thing, as far as I'm concerned, is the section in the middle of the page that talks about creating "a new workflow monitor agent Component Definition." For several reasons (possibly a future blog topic), it makes sense to split your Workflow Policies into several Workflow Policy Groups. Create as many as you need. For each one, create a separate Workflow Monitor Agent Component Definition. Follow the instructions in Bookshelf.

Set the Default Tasks to 1. This allows you to forget everything about administering Workflow Monitor Agent from the command line. The component will start and stop within the graphical interface.

Set sleep time to the desired amount. Set up an email address and mail server for automatic notifications, and tweak any other parameters that catch you interest.

Another Reason to Comment

Carefully commenting all updated repository objects has clear benefits. It helps trace repository changes back to the responsible configurators. It helps accomplish a sort of configuration management so that you have a rudimentary history of changes that were made to the repository.

Complicating repository configuration management is the fact that Siebel developers do not start with a blank slate. Unlike a discreet block of script, Siebel configuration might involve meeting a single requirement by changing the value of one or two properties on several pre-existing objects throughout many different projects in the repository. Careful commenting can provide information about what changes were made, and why, and when.

One drawback for commenting the Siebel repository objects is the relatively small size of the Comments attribute itself, which commonly contains information about several changes by different developers to meet more than one requirement. If each comment includes the initials of the developer, the date, the requirement number, and a description of the changes made, you will quickly run out of space. A good approach to keeping comments concise is to reference an external document, such as a detailed technical design.

With all the configuration management concerns, you might not consider another, possibly more important reason to carefully comment repository object changes. These comments can be invaluable during a repository upgrade.

During configuration, upgrading can be the last thing you want to consider, but if the project is successful, upgrading is inevitable. And the Siebel upgrade process includes a many tedious and time-consuming steps. After the repository merge, which is an automated process that transforms the repository objects from one version to the next, there are usually hundreds or thousands of conflicts that must be manually reviewed. The Reviewing Siebel Repository Object Property Conflicts process is one of the most difficult, tedious, and error-prone tasks of the entire upgrade.

The conflicts that must be manually reviewed are cases where there are three versions of the same repository object, and there is no clear path for the automated upgrade to take. Siebel provides an Attribute List View that makes the process as easy as possible, and you have a 90% chance that the automated merge has actually identified the correct "Standard Win" version. But, for the remaining 10% of the attributes, which can be literally hundreds of choices, developer comments can be the key to an informed decision.

Text Length Override

One of my favorite User Properties is "Text Length Override". It is a simple technique for enforcing the length of a text field without ugly popup messages.

If you have a business requirement to restrict user input to a certain number of characters, you have several options. You can find a database column that has the exact number of characters you need. You can create a field validation that will popup an error message if a user enters more characters than required. The user must correct the error condition before being allowed to step off the field. You can do something even more intrusive (with scripting, for example) to alert the user that he or she has made a mistake and/or fix the problem for them.

But a completely non-intrusive, transparent, and elegant way to address the situation is to use the Text Length Override User Property on the field. Text Length Override is a User Property that corrects what almost seems to be a defect in the normal functioning of a BusComp field.

It seems intuitive that a field attribute called "Text Length" would set a limit to the amount of text that could be entered into a field. Probably most people wouldn't bother to look that one up. But the fact is that Text Length does nothing at all unless combined with the Text Length Override User Property. The amount of text that a field will accept is normally determined by the size of the underlying database column.

So how does this work? Suppose the following:

• You have a BusComp Field called "Short Name".
• The field is mapped to a column called ALIAS_NAME, which is a varchar(100).
• The business requires that no more than 30 characters of text can be entered into Short Name.

Here's what you need to do if you want to prevent excess text from being entered, but you don't want a validation message to interrupt the user interaction with the view:

1. Set the Text Length attribute on the Short Name field to 30
2. Create a User Property object as a child of the Field.
3. Set the Name attribute of the User Property to "Text Length Override".
4. Set the Value of the User Property to "True".*

That's all. The User Property "overrides" the normal functionality of the Text Length attribute (it normally doesn't do anything), and limits the text to the Text Length specified.

* Siebel 8 Bookshelf says that you can set the value of the User Property to anything, even null, and the functionality will be the same. This is a change from previous versions.

Search Specification Performance

With a web-based application such as Siebel, performance is always a primary concern, especially database performance. Database performance problems can cause ripple effects, as a bad-performing query can cause an increased load on the database, making it slow to respond to other, simpler queries. If a query runs several times (for example, when a user scrolls through a list applet, causing multiple fetches from a slow-performing cursor) database performance problems can become the Achilles heel of a Siebel implementation, and network slowdowns can compound this problem, as multiple fetches are added to multiple network round trips.

One easy way to attack database performance from the outset is by examining Search Specifications and Sort Specifications configured in your Business Components, Applets, and Pre-Defined Queries. Searches and Sorts should use indexed columns whenever possible, and you should be careful not to defeat your indexes by searching on an expression that will not use one. For example, avoid using "OR" in your search expressions, because the expression is simply copied to the WHERE clause of the query, and databases generally do a full table scan on an "OR" condition.

If you have any doubts about the performance of a particular search, compile the SRF, spool the SQL, and ask your DBA to run the explain plan. He or she can tell you if your query is performing optimally. Siebel performance can be a little bit tricky, because you don't write the SQL yourself, and you can't actually provide database hints. But when you are writing Search Expressions, you may have more control over the generated SQL than you realize.