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.

Setting the SSA Primary Field

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:

1. The SSA Primary field does not correspond directly to a database column.
2. 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:

1. Get the MVG business component using the BusComp.GetMVGBusComp method.
2. Use BusComp.SetSearchSpec and BusComp.ExecuteQuery methods to locate the correct record on the MVG business component.
3. Set the SSA Primary field with the statement BusComp.SetFieldValue("SSA Primary Field", "Y"), substituting the actual business component variable name.
4. 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

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!