New Siebel Administration Book

There are few Siebel books on the market, so when I found out about a book by the author of one of my favorite Siebel blogs, I wanted to write a review right away. Oracle Siebel CRM 8 Installation and Management, by Alexander Hansal, is an introduction to many of the key administrative tasks in short, easy-to-understand sections.
Some of the sections of the book are quite strong. The chapter on Siebel Remote is very good. It covers the various types of mobile clients for various users, the process of extracting the mobile client for a user, initializing local databases, keeping them synchronized, and many more important tasks. In a 25 page chapter, Hansal provides an overview of Siebel Remote that an administrator can read before diving into the Siebel Bookshelf guide that is more than 10 times as long. Another chapter on system monitoring offers a good introduction to that topic, including a pretty detailed overview of SARM analyzer functionality.
Some chapters are weaker. The chapter on access control, for example, was sketchy and confusing. However, in the balance, the book offers valuable assistance to a Siebel Administrator who wants an overview of the various parts of the job.
The book cover claims that the book "offers a comprehensive understanding of Siebel CRM." It does not do that. Instead, the book offers an overview. As an overview, it's quite good. Administrators who are new to the role would do well to read this book from cover to cover. The high-level understanding offered there can be supplemented with deeper dives into Siebel Bookshelf as real-life situations arise.

Abstracting Database Passwords in Batch Scripts

Even when a Siebel implementation does not need to be SOX compliant, it is still important to develop and maintain processes to reduce errors and fraud. Separation of duties (SoD) is an important security principle in any enterprise application environment. For example, it is often best to prevent Siebel Developers from having administrative access, and to prevent Siebel Administrators from changing code.

One potential vulnerability is that command-line server manager connections require a username and password that authenticate against the Siebel database. People with this information can use a third-party tool to access and manipulate the Siebel database. In a production environment, administrators need these passwords, but they should be restricted as much as possible, especially from developers.

Scripts invoking the Siebel Server Manager command-line interface can be a powerful tool for automating server tasks, but connecting to the command-line interface on a Windows server requires the following syntax:

srvrmgr /g gateway1 /e enterprise1 /s server1 /u sadmin /p sadmin

In the above command the /u and /p arguments require a valid username and password using database authentication. A batch script containing this information challenges the SoD principle. Either an administrator manipulates the script to insert the password, or a developer does. Either way, the roles become blurred.

The solution to this problem is to isolate passwords and other environment-specific information from the script itself.

Consider the following excerpt from a Windows shell script:

call E:\secure\envvariables.cmd

E:\sba80\siebsrvr\BIN\srvrmgr /g %gateway_server% /e %enterprise_server% /s %siebel_server% /u %eimuserid% /p %eimpassword%

In the envvariables.cmd file, the following:

@set gateway_server=PRODGTWY
@set enterprise_server=Siebentprod
@set siebel_server=Siebprodbat1
@set eimuserid=EIMIMPORT
@set eimpassword=SecurePwd

It doesn't matter how much complex logic is added to the shell script containing the srvrmgr command, user names and passwords are segregated from the logic in a file that can only be modified by the system administrator. Moreover, environment information is also segregated, so the script can be migrated through UAT and Production without modification.

The CancelQueryTimeOut Parameter

Long-running queries can be the most aggrevating problem that Siebel users face, and the ability to cancel them is often highly valued. The Siebel High Interactivity client has this capability. When a query has been running for a few seconds, a little pop-up box appears with a "Cancel" button, allowing users to stop the query.

In Siebel 7.7 and 7.8, the parameter to enable this was in the [SWE] section of the application config file (such as fins.cfg). To enable the functionality, change the parameter in the file:

CancelQueryTimeOut = timeout

If timeout is 3, for example, the popup button will appear after 3 seconds. If the value is -1, the popup is disabled.

Unfortunately, many Siebel administrators may believe the CancelQueryTimeOut parameter simply doesn't work in Siebel 8.0. It does work, but it is incorrectly documented. Siebel Bookshelf erroneously says the functionality is enabled in the [SWE] section of the config file, but there is no [SWE] section in Siebel 8.0. In Siebel 8.0, CancelQueryTimeOut is available as an Object Manager parameter.

To enable the functionality in Siebel 8.0:

1. Go to Administration - Server Configuration -> Enterprises -> Component Definitions
2. Query for your Object Manager component and select it
3. In Component Parameters, ensure that "Advanced" parameters are displayed
4. Query for the CancelQueryTimeOut parameter
5. Update the parameter to the amount of time, in seconds, you would like to wait before the pop-up button appears on a long-running query (the default is -1, which means the functionality is disabled)
6. Restart the object manager component

I find that this parameter is very useful for improving user satisfaction and also reducing the number of orphan tasks on the object manager, which can occur when a user closes the browser before a query returns.

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.