Launching a Workflow Process from a Business Component

One way to replace business component scripting with more declarative configuration is by using Siebel Workflow. A workflow process can perform many of the same operations that you can configure with eScript. If you want to execute a workflow when a BusComp field is updated, you can invoke it from scripting in the SetFieldValue event of the business component. There is, however, the option of using business component user properties for a completely declarative solution.

An example of using the applet version of the Named Method n user property to invoke a workflow process can be found in Siebel Bookshelf. The same user property is available for business components. An example of a named method declaration follows:

User Property Name: Named Method 1
User Property Value: "MyInvokeWFMehod", "INVOKESVC", "Employee", "Workflow Process Manager", "RunProcess", "'ProcessName'", "'The Do Something Cool Workflow Process'", "'WorkPhone'", "[Work Phone Number]", "'Login'", "[Login Name]", "'RowId'", "[Id]"

In this example, "MyInvokeWFMehod" is the name I give to the named method. "Employee" is the name of the business component. "The Do Something Cool Workflow Process" is the name of the workflow process. After the workflow process name, a series of name-value pairs are additional parameters passed to the workflow. "WorkPhone" and "Login" are process properties of the workflow process. Each process property name can be followed by a bracketed field name or business component expression. "RowId" is a method argument of the Workflow Process Manager business service that passes its value to the "Object Id" process property of the workflow.

Please note that parameter names and literals must be in quotes, despite the fact that the user property arguments are already in quotes, which results in the strange syntax of "'Literal Value'".

Another user property is also usually required to invoke the named method, unless the named method is already invoked by the business component itself. To invoke the named method upon a field being updated, use the On Field Update Invoke n user property. For example:

User Property Name: On Field Update Invoke 1
User Property Value: "Work Phone Number", "Employee", "MyInvokeWFMehod"

When the "Work Phone Number" field of the "Employee" business component is updated, the "MyInvokeWFMehod" named method is invoked, which calls the "RunProcess" method of the "Workflow Process Manager" business service, which acts as a proxy for the "Workflow Process Manager" server component, which executes the "The Do Something Cool Workflow Process" process, using values passed from the business component directly into workflow process properties.

In summary, use the On Field Update Invoke n business component user property together with the Named Method n business component user property and your own workflow process for a completely non-scripted way to add complex logic to the event of updating a business component field.

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.

Workflow Policies vs Workflow Processes

Building a solution with Siebel Workflow often involves the use of both Workflow Policies and Workflow Processes. Siebel Workflow, taken together, is a complete application for automating server processes defined using declarative relationships between logical objects. As a Siebel Developer, you need to understand the difference between a Workflow Policy and a Workflow Process.

A Workflow Process is a program that runs on the Siebel server. It is defined through a graphical interface as a set of steps. When the process runs, a single record is processed. The workflow process steps are performed as a series of data operations.

A Workflow Policy is a specific event that occurs on the Siebel database. Based on a database trigger, it can include many complex criteria, but it ultimately evaluates to a true/false condition to determine whether to execute a program or not. Commonly, a Workflow Policy will execute a Workflow Process.

Do not be confused between the Business Object that is part of the Workflow Process definition and the Workflow Policy Object that is part of the Workflow Policy definition. A Workflow Process runs on the business layer of the Siebel object model. The Business Object that helps define a Workflow Process is the same Business Object that governs the logical data entity relationships between Business Components in Siebel screens and views.

A Workflow Policy Object is also configured in Siebel Tools, and it also represents a logical data entity, but it seems closer to the data layer of the Siebel object model. Workflow Policy Objects, Components, Columns, and Component Columns are a objects that do not contain or enforce any business rules. They are essentially columns and tables, and the relationships between them.

By first understanding the basic differences between these two core components of Siebel Workflow, a Siebel Developer can begin to grasp the basics of the powerful business process automation application known as Siebel Workflow.

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.

Interview Question #2 - What is a Siebel Operation Step?

This interview question uses a technical term to test a Siebel Developer's understanding of a topic. "Siebel Operation" can be almost anything to someone who does not have a basic familiarity with Siebel Workflow, but it is an everyday term for any Workflow Developer.

Q: Please explain what a Siebel Operation is, and how it is used.

A: At minimum, the candidate should know that a Siebel Operation is a type of Workflow Process Step. If the candidate does not volunteer this information without additional prompting, he or she is not a Workflow Developer.

Candidates should know that a Siebel Operation can be used to Insert or Update records as part of a Workflow Process. A candidate should know the difference between a Workflow Process and a Workflow Policy or Workflow Policy Program. Siebel Operation is a term that is only used in connection with Workflow Processes.

In addition to Insert and Update, recent versions of Siebel have other types of operations. Most Siebel Workflow Developers know that a Query operation is now available. Since Siebel 8.0, there are Upsert and looping operations: PrevRecord, NextRecord, and QueryBiDirectional. In my experience, knowledge of these operations is less common; it can be difficult to find a developer who can explain how to build a loop in a Workflow Process.

Workflow Process Steps operate on the business layer of Siebel, as opposed to the database layer. A Business Component that is associated with the Workflow Process's Business Object is required for any Siebel Operation. Workflow Developers should know these things, although a little prompting may be required.

A good Workflow Developer should also know about the Siebel Operation Object Id process property, which is updated after an Insert, Update, or Upsert operation. If one record is inserted or updated, this process property will contain the row id of the affected record. If more than one record, the property will contain an asterisk: '*'. If no records are affected, the property will not contain a value.

VBC Compatibility Mode

The Query method of a VBC Business Service in Siebel versions later than 7.5 has an Inputs property set whose structure can be difficult to navigate. Take a look at the XML representation from Siebel Bookshelf:

<siebel-xmlext-query-req>
  <buscomp id="1">Contact</buscomp>  
  <remote-source>http://throth/servlet/VBCContacts</remote-source>  
  <max-rows>6</max-rows>  
  <search-string>=([Phone] IS NOT NULL) AND ([AccountId] = "1-6")</search-string>  
  <search-spec>  
    <node node-type="Binary Operator">AND     
      <node node-type="Unary Operator">IS NOT NULL       
        <node node-type="Identifier">Phone</node>         
      </node>        
      <node node-type="Binary Operator">=         
        <node node-type="Identifier">AccountId</node>         
        <node value-type="TEXT" node-type="Constant">1-6</node>      
      </node>    
    </node>  
  </search-spec>  
  <sort-spec>  
    <sort field="Location">ASCENDING</sort>     
    <sort field="Name">DESCENDING</sort>   
  </sort-spec>
</Siebel-xmlext-query-req>

I've found that the search-string node of the property set isn't particularly useful unless your back-end data source has a column structure that matches your VBC. In the example above, you can quickly see how difficulty it could be for a Siebel developer to write a script to parse a property set containing a search-spec node with any complexity.

In Siebel versions prior to 7.5, the Inputs property set was much simpler. Below, see an eScript snippet that unloads a search specification in the query method of a VBC Business Service using the older format of input:

var child = Inputs.GetChild(0);
var sPolicyNumber = child.GetProperty("Policy Number");
var sLastName = child.GetProperty("Date of Birth");
var sFirstName = child.GetProperty("First Name");

Where query specifications are entered into a form applet as field, the old format lets you easily retrieve input values and manipulate them in eScript variables.

For Query input in the earlier, simpler format, add the following Business Component User Property to your VBC:

Name: VBC Compatibility Mode
Value: Siebel 7.0.4

Interview Question #1 - What is a Link?

I've decided to add a new feature to this blog. With this post, I am introducing a series of interview questions that Siebel developers and development leads should consider when preparing for technical interviews. I've interviewed many developers, and I've been interviewed quite a few times as well, and I have a pretty good idea of what makes a good technical interview question.

When I interview someone, my questions are designed to discover what a candidate knows, not bolster my ego by proving that I know something the candidate doesn't. I focus on the fundamentals of Siebel configuration, allowing the candidate to demonstrate the depth of his or her knowledge.

Q: Please describe the Siebel configuration object called a "Link".

A: The candidate should be able to provide at least two of the following, but should not contradict any of them:

• A Link defines the relationship between Business Components.
• Links are used to define a Business Object; the relationships between the primary Business Component and other (child) Business Components in the Business Object are Links.
• A Link is not the same thing as a Multi-Value Link or a Multi-Value Group, but the definition of a Multi-Value Link does include a Link.
• A one-to-many Link makes a master-detail View possible.
• Links are defined on the Business Object layer, using Business Component Fields rather than Table Columns, although many-to-many links use Table and Column names to define the intersection table.
• The "Source" Field is on the Parent Business Component, while the "Destination" Field is on the Child Business Component.
• A Link can have a Search Specification.

It's ok to prompt the candidate with leading questions to develop a better understanding of the depth of his or her knowledge, asking open-ended questions wherever possible.

Check Your Data

It's simple to avoid, but it is surprising how often developers will make the mistake of implementing new functionality without first verifying that it will work with data that already inhabit the database.

For example, your organization might need to update an existing Siebel implementation. One of the new requirements is to evaluate a Contact's Date of Birth, calculating the Contact's age and only allowing certain functionality for Contacts that are older than a limit.

To do this, you might create a calculated field that tests the Date of Birth so that the field's value is TRUE if the Contact is too young. If the field's value is FALSE, the restricted functionality is allowed.

You know that you have to handle NULL, because your calculated field won't return either TRUE or FALSE if the Date of Birth is NULL. But the business requirement calls for making Date of Birth a required field, and you can assume that no new Contacts will be created without a Date of Birth. Unfortunately existing data might contain NULL values that will break this functionality, and a NULL value in a required field can cause more problems, even in screens and views unrelated to the new age restriction.

Some configurators forget to thoroughly test their new functionality against the data already existing in the database. This situation might not be caught in the test cycle if only a small percentage of records have NULL values. But a situation like this can cause big problems if it is not caught before the new functionality is deployed.

The best practice is to carefully test to be sure that new functionality works with old data.

Simple Input Validation through HTML Attributes

The best place to validate user input is at the source. If you can keep field validations in the browser, you can avoid unnecessary server requests and provide immediate user feedback while reducing the amount of bad data being submitted. This can be especially useful in the standard interactivity client because it can perform validations immediately, without waiting for the user to attempt to commit the record.

A Siebel form applet is an HTML form, and the controls are input elements on those forms. The HTML Attributes property of a Control object provides an opportunity to insert a JavaScript event to the input element.

For example, I recently implemented a query applet with a field validation on the Social Security Number control. To do so, I updated the HTML Attributes property of the control to

onkeyUp="if(/[^0-9\-]/.test(this.value) ){ alert('The Social Security Number field accepts only numeric data.'); this.value='';}"

The above validation intercepts the onkeyUp event of the input element, and uses a regular expression test to detect if the key pressed was any other besides a number or a hyphen. If an errant character is found, the applet displays a message and clears the control. This validation occurs entirely on the browser, but without adding any browser scripts to the applet.

Here's another example of a date validation on another control on the same applet:

onBlur="if(/^( *)((0[1-9]|[1-9]|1[012])[/](0[1-9]|[1-9]|[12][0-9]|3[01])[/](18|19|20)\d\d)( *)$/.test(this.value)||this.value==''){}else{alert('The Date of Birth field accepts date input in the M/D/YYYY or MM/DD/YYYY format');this.value='';}"

A somewhat more complex regular expression tests the format of a date. In this case, the expression doesn't test the input until the focus moves out of the field.

The HTML Attributes property of the Control object provides a clean, declarative approach for input validation.