Siebel Developer

Launching a Workflow Process from a Business Component

2010-11-23T00:44:00.004-06:00

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

2010-09-07T22:30:00.004-05:00

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

2010-09-04T00:22:00.000-05:00

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

2010-04-05T00:51:00.006-05:00

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?

2010-03-12T23:12:00.000-06:00

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

2010-02-28T23:32:00.000-06:00

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?

2010-02-18T23:48:00.006-06:00

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

2010-01-26T16:31:00.003-06:00

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

2010-01-20T23:07:00.010-06:00

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.

Setting the SSA Primary Field

2009-09-07T10:21:00.006-05:00

When I started configuring Siebel, I was mostly self-taught, which means that I usually settled for the first way I found of accomplishing my goal. Setting the primary record on a multi-value group through script is one example.

My method: query for the record I needed in the child buscomp, obtain the row id, and then use that row id to update the primary id field of the parent. For example, if I needed to set the primary position on the Account buscomp, I would begin by looking up the position id, then I would use a SetFieldValue statement to set the Primary Position Id with the id I had retrieved.

Wrong approach! That is the dangerous way. A scripting error will potentially corrupt your database in the same way direct sql could, by breaking its referential integrity. Directly setting a primary id field is not supported by Oracle.

The feature I didn't understand, which makes the process much easier and safer, is a system field called SSA Primary. You may have noticed this field in MVG Applet configurations. It's a system field, much like Created or Id, but it is different in two important ways:

The SSA Primary field does not correspond directly to a database column.
The SSA Primary field is editable.

Like other system fields, it is not listed in the Fields object in Tools, and you don't have to explicitly activate it in scripting.

Using the SSA Primary field, here is the correct way to use script to set the primary on an MVG, as recommended by Oracle:

Get the MVG business component using the BusComp.GetMVGBusComp method.
Use BusComp.SetSearchSpec and BusComp.ExecuteQuery methods to locate the correct record on the MVG business component.
Set the SSA Primary field with the statement BusComp.SetFieldValue("SSA Primary Field", "Y"), substituting the actual business component variable name.
Use BusComp.WriteRecord on the parent business component. This is because the Primary Id field is on the parent.

Some versions of Siebel Tools will give a semantic warning when you check the syntax after you try to set the SSA Primary field. This is a Siebel bug, and this warning can be safely ignored.

Update - Fixed a typo caught by commenter Duarte: Above instructions previously contained BusComp.SetFieldValue("SSA Primary", "Y") instead of BusComp.SetFieldValue("SSA Primary Field", "Y"). Thanks Duarte!

New Gadget from Impossible Siebel

2009-09-07T10:05:00.002-05:00

Jason at Impossible Siebel has developed the ImposSiebel Toolbar Beta, which is definitely worth a look. As he writes:

...this is a program which allows developers to hook into any Siebel session, in anyenvironment, and get quick access to the Siebel objects without going into Tools.

Who doesn't want that? I can see this as being especially helpful for developers working with the SI client, where there is no Help -> About View feature. From the screenshots, it looks great!

Using a Randomizer to Split EIM Batches

2009-08-07T21:41:00.004-05:00

EIM runs best when it imports data in batches of 5,000 to 10,000 records. There are potentially many techniques for dividing a large number of records into batches of this size. Here is my favorite:

Imagine the EIM_CONTACT table has 300,000 records that you want to import, but all of them contain the number 1 in the IF_ROW_BATCH_NUM column. Ideally, you would prefer to load the data in 60 batches of 5,000 records each, numbered 101 - 160. Use the following SESSION SQL step in the process to split the batches:

[SPLIT BATCHES]

TYPE = IMPORT

BATCH = 0

TABLE = EIM_CONTACT

SESSION SQL = "UPDATE SIEBEL.EIM_CONTACT SET IF_ROW_BATCH_NUM = floor(dbms_random.value(101, 160)) WHERE IF_ROW_BATCH_NUM = 1

The above EIM step is separated from all other functionality for clarity, but your own process will probably contain some differences. For example, the SESSION SQL could be part of your EIM IMPORT step, or the UPDATE statement could contain more columns.

Part of the guarantee of a randomizer is that generated numbers will spread equally across the available range, so you can assume that your data will be distributed evenly across the 60 batches.

Please notice that I'm assuming there are no records in batch number 0. Otherwise, they would be imported during this step. Also notice that I'm using functions specific to the Oracle database. Different databases have different functions for generating random numbers, but the technique is largely the same for any database you use.

The CancelQueryTimeOut Parameter

2009-08-05T21:51:00.004-05:00

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:

Go to Administration - Server Configuration -> Enterprises -> Component Definitions
Query for your Object Manager component and select it
In Component Parameters, ensure that "Advanced" parameters are displayed
Query for the CancelQueryTimeOut parameter
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)
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.

Manager Visibility

2009-05-13T14:26:00.004-05:00

Manager-based visibility is one of the toughest concepts for Siebel users to understand, and it also is a little tricky to simulate in a SQL-based query tool, so I thought I would post a summary of some of the basic concepts.

If I open a view with position-based team access control, such as one based on the Account business component, Sales Rep visibility returns all records where my position is on the sales team. By default, Manager visibility returns all those records, and also all records where one of my reports, direct or indirect, is primary on the sales team.

With single-position access control like with the Quote Bus Comp, Manager visibility returns all records associated with my position or with any of my reports positions.

With a business component such as Action, with person-based access control, records must be associated with my employee record or with the employee record of one of my reports. The reporting relationship is based on my currently active position. Subordinate positions must be the Primary Held Position of the subordinate's employee record for the employee to be included in the query. If the record has multiple owners, default functionality is to show only those records where the subordinate employee is the primary owner.

Views with Manager visibility can be based on business components that have a Person or Position type view mode. No special "Manager" view mode is required. Such views usually have names beginning "My Team's".

Person-based and position-based access control are based on a single relationship: between a position and it's parent position. Position is a party-based business component, and this relationship is defined on the S_PARTY table, with the column PAR_PARTY_ID joined to the parent record. Although every position can have only one parent, a position is subordinate to multiple positions for the purpose of manager visibility, because a position is subordinate to parent position's parent position, and etcetera. Therefore, manager visibility is actually based on an indeterminate number of iterations of the position/parent position relationship.

It would be extremely difficult to describe an unknown number of iterations of the position/parent position relationship with a single SQL statement. Siebel solves this problem by writing each position's reporting relationships to a table called S_PARTY_RPT_REL. A reporting relationship record is created for each related record, following the reporting chain through all iterations. This results in a many-to-many relationship, as each position can have many subordinate positions and each position can have a chain of parent and grandparent positions. Records in the S_PARTY_RPT_REL are created when a new record is inserted in S_POSTN, or when a user clicks on the "Generate Reporting Relationships" button in the Position administration view.

In a query to populate the My Teams view with data, S_PARTY_RPT_REL.PARTY_ID is set equal to the user's active position id. S_PARTY_RPT_REL.SUB_PARTY_ID joins to the applet's business component table and/or the sales team intersection table, depending on the business component.

For more about Manager visibility see the Siebel Security Guide in Siebel Bookshelf.

Get Rid of Dead Code

2009-05-01T23:39:00.007-05:00

How many Siebel developers believe that the best way to remove lines of code from an existing script is to put some comment characters in front of the un-needed code, preventing it from executing. Many developers will copy an existing line of code to change an operation or add a condition, "commenting" the original version instead of deleting it. -- Added 5/3

Good coding practice tells us to diligently and carefully comment and annotate changes to scripts, right? Lets take a step back for a moment and think it through. I'm not certain that the commented lines of script are very helpful, at least in most cases.

First of all, commented script rarely helps to trace the historical changes made in a script. If the commented changes are dated, as they often are, you might find the date helpful. But script comments don't lend themselves to historical analysis nearly as well as versioning. Comparing a previous version of a script with the current version, in a source control repository for example, is much easier than trying to decipher the versions from comments in the script itself. Especially considering that the comments from several changes are often mixed in together.

Secondly, commented script doesn't help much in understanding how the current version of the script works. Lets face it: when you examine a script, you are not looking at the code that is commented. You skip the comments and focus on the code that is still active. If the developer happened to leave some actual words among all the dead code, you might stop to read it, but you certainly won't spend much analysis to find out how the script used to work.

Thirdly, and perhaps most importantly, dead code can cause significant overhead on the Siebel server. Every development team that habitually comments unused blocks of script will soon find that an entire event handler has been commented. In fact, it is common to find Siebel repositories with multiple event handlers entirely commented out. Also common are scripted event handlers where no script is present at all. Event handlers are marked as scripted even if the script contains no executable code except the application-provided stub:

function WebApplet_PreCanInvokeMethod (MethodName,
&CanInvoke)
{
return (ContinueOperation);
}

These event handlers cause a measurable increase in CPU load, especially when the event is frequently encountered. The empty scripts also become a maintenance issue, increasing the time required to compile an srf.

So, get rid of all that dead code. If a scripted event handler is empty, completely delete the script record in the Tools list applet. If you are removing individual lines of script, make sure you fully document your changes in design documents, and use a source control system to keep previous versions of the script. But keep the script itself clean. A clean repository will be easier to maintain and provide less overhead on your Siebel server.

A Regular Expression Validation

2009-04-23T22:56:00.000-05:00

Data Validation Manager is great, but what would validation be without Regular Expressions? Here's how I used both to meet a business requirement.

The requirement arose from some errors logged when Siebel would attempt to send email to invalid addresses. We wanted to notify a user who entered invalid characters in the email address field. Of course, this edit wouldn't guarantee that addresses entered would actually exist, but it would at least ensure that people wouldn't separate two addresses with a colon (':') instead of a semicolon (';'), which is what was happening.

Step 1: Create a Business Service

Create a new Business Service with a method containing the following code snippet:

var sPattern = Inputs.GetProperty("Pattern");
var sSample = Inputs.GetProperty("Sample");
var rExp = new RegExp(sPattern);

if(rExp.test(sSample))
{
Outputs.SetProperty("Result", 1);
}
else
{
Outputs.SetProperty("Result", 0);
}

Step 2: Create a Data Validation Rule

Our Data Validation Rule Set is called "Employee Email Validation". In the data validation rule, use the new business service to test a business component field against a regular expression pattern. Use the following syntax for the pattern:

InvokeServiceMethod("ABC Validation Service", "Validate", "Pattern='^(([a-zA-Z0-9_\-\.]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5}))+([;,](([a-zA-Z0-9_\-\.]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5}))+)*$', Sample=eval([EMail Addr])", "Result")<>0

The regular expression pattern above was adapted from one available on the website http://www.regular-expressions.info/, where you can quickly learn how to get started with regular expressions. Also note the use of the eval() function, which will result in the contents of the Business Component Field being passed to the business service instead of the literal field name. See Metalink Doc ID 782338.1 (login required) for Oracle's How-To article for using eval() with InvokeServiceMethod() for a very similar application.

Step 3: Create a Runtime Event

Your next step is to create a Runtime Event manually through the Administration - Runtime Events screen. For our data validation, we created an Action Set for the Employee WriteRecord event.

Action Type: BusService

Business Service Name: Data Validation Manager

Business Service Method: Validate

Business Service Context: "Rule Set Name", "Employee Email Validation", "Enable Log", "Y"

Please note that although we did our validation on the Employee BusComp, it doesn't work on the Administration - User -> Employees. We have a custom view created on the Employee BusComp that exposes the email field. I'm not actually sure why it doesn't work in the vanilla view, but I'll post an update if I find out.

Step 4: Update Enterprise Parameter

A security feature introduced with Siebel 7.7 restricts the InvokeServiceMethod function to only business services that are registered on the Query Access List. The parameter can be set at the enterprise level or the component (e.g., Object Manager) level. However, since component-level settings always override enterprise settings, setting the parameter at the component level would preclude the use of any other business services that are registered at the enterprise.

Enterprise Parameter Name: Business Service Query Access List

Enterprise Parameter Value: ABC Validation Service

A common Siebel software limitation applies here. Only a maximum of 100 characters can be used to specify business service names in this parameter. You should carefully plan which business services you want to use with InvokeServiceMethod. Do not leave spaces between multiple business service names, but separate names with commas, and do not use quote marks.

Conclusion

After setting up a very simple business service to evaluate regular expressions, we can create any number of complex validations to display a message when a pattern is matched, with no additional scripting at all. For example, another requirement to validate the format of an identification number in a free text field was accomplished with a second data validation using the same business service.

If you are new to regular expressions, take a look. They are incredibly useful.

Two-Track Development: Part 1 - Establish a Process

2009-01-07T16:10:00.011-06:00

Siebel projects often have lengthy development cycles, and enterprises often find that they need to manage overlapping releases where a development cycle is not complete before work begins on the next effort. Faced with such a requirement, project teams find themselves in the unenviable position of maintaining two Siebel development repositories at once, one for each project.

In the image to the left, you can see two development paths, one for Q1 and one for Q2. The Q1 path has an active development effort, with ongoing test cycles in QA and UAT. The Q2 path does not have a UAT environment, because only the Q1 path will be migrated to production. After the Q1 path deploys, Q2 will become the primary path, including DEV 2, TEST 2, and UAT. A new Q3 path can be created with the DEV 1 and TEST 1 environments.

To allow development to proceed on the Q2 path, the Q2 team must always be working with the latest version of the code from the previous project. The latest changes from the Q1 path must be merged to the Q2 path so that Q2 developers are working with an environment that looks like the one they will ultimately release. In other words, the Q2 repository includes a superset of Q1 and Q2 changes, just as the production repository will after Q2 deploys.

To successfully manage the process, it helps to have a regular merge schedule. At a pre-specified interval, such as once per week, a dedicated team member can discover changes to the DEV 1 environment, mediate conflict resolution between those changes and required configurations in the DEV 2 environment, and propagate those changes into the DEV 2 environment.

Once all changes have been merged into DEV 2, they will follow the normal promotion process to system test and, ultimately UAT and production.

How can this work? Over the next several posts I'll discuss some of the issues involved, along with some technical hints. I'll be relying especially on a process developed by a colleague of mine, Ashutosh Nigam.

Fusion Links

2008-05-29T21:13:00.003-05:00

I was looking around at SiebelGuide.com today and found a blog post linking to an Oracle demo I really enjoyed. The demo discusses the Siebel Adapter, which I have not had an opportunity to use, for Oracle Fusion Middleware. In the demo, you get to see how to create a JCA interface for querying an Account, and then how to access that interface with a BPEL process. I have a little bit of familiarity with the BPEL process manager, and I can tell you it is as cool as it looks.

Oracle has a Best Practice Center portal for researching integration options with Fusion and Siebel. It can be a great place to start if you want to develop a deeper understanding of what the Oracle Application Server has to offer to Siebel implementers.

On Field Update Invoke

2008-05-27T21:39:00.004-05:00

The On Field Update Invoke user property is a clean way to run some custom functionality when a BusComp field is updated. If you reflexively assume that you need to put script in the SetFieldValue event, you should consider this user property to execute your specialized functionality instead.

The syntax is as follows:

User Property Name: On Field Update Invoke n
User Property Value: "[FieldToCheck]", "[BusCompName]", "[MethodName]", "[Condition]"

Condition is an optional parameter. If you leave it out, the method will be called any time the field is updated. If you include it, the condition must be true for the method to be invoked.

FieldToCheck is also optional. If the parameter is omitted, include double quotes as a placeholder. The method will be invoked any time the BusComp is updated, as if it were called from the BusComp_WriteRecord event. If the parameter is present, the user property works just like BusComp_SetFieldValue; the update happens as soon as the cursor leaves the FieldToCheck field.

Note that you can run a BusComp method on a different BusComp than the one that spawns the event. Specify the BusCompName and the MethodName. Siebel does this quite extensively (for updating child records when a parent record is updated, for example) to implement vanilla functionality. The BusComp method is invoked on another business component in the active Business Object.

It is also important to understand what methods can be called from this user property. It can be used to call an eScript function. You can add eScript to the BusComp_PreInvokeMethod event to capture the invocation and call a function on the current BusComp, and from there invoke a workflow process or business service.

The user property can also invoke methods on the Business Component Class that would normally be invoked through the InvokeMethod method. For example, you could call the CompleteActivity method on an Activity. Be aware of the specialized methods that are available for the class you are using.

If your implementation includes Siebel Order Management, Signals can also be raised from this user property. For any of the Order Management Business Components, if a method is not found on the business component itself, Siebel will raise a signal if it exists.

Whatever you choose, Siebel recommends the On Field Update Invoke user property as preferable to adding scripting to the BusComp_SetFieldValue event. The SetFieldValue event is inefficient, and even though the On Field Update Invoke user property may invoke a custom script, it can be more efficient than invoking the same script from the SetFieldValue event.

Workflow Monitor Agent

2008-05-22T21:08:00.002-05:00

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

2008-05-21T21:09:00.004-05:00

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

2008-05-20T21:12:00.000-05:00

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:

Set the Text Length attribute on the Short Name field to 30
Create a User Property object as a child of the Field.
Set the Name attribute of the User Property to "Text Length Override".
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

2008-05-19T21:22:00.004-05:00

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.

First Post

2008-05-17T16:02:00.000-05:00

Hi!

This post kicks off what I hope will become a valuable resource for Siebel Developers of all levels of experience. Something I've learned is that the Siebel toolset is complex enough that everyone can continue to grow in knowledge, even after working with it for years. We all develop habits with our favorite techniques, but the best of us also experiment to discover new ways of making the software do what we need it to do.

In this blog, I hope to touch on many different areas of interest to those of us who work with Siebel. I plan to get into configuring screens and views, as well as more advanced topics such as integration with EAI and EIM, server management, and scripting. If you have a topic you'd like to hear about, please post in comments and I'll consider your topic for a future post.

Siebel has changed over the years, and not all of us are working with the same version. When I am posting about a topic, I will try to highlight version differences when I am aware of them. Comments from developers who work with different versions are also helpful in filling the gaps in my experience. My current job has me working with Siebel 7.8, and I am not an Oracle employee, and those two factors will obviously influence what I choose to write about, but I intend this forum to extend to areas of interest to Siebel developers everywhere.