Ahmad Khalifa's World

Siebel CRM has some great references that come with it like the Bookshelf, Metalink, and the Essentials course materials if you can get your hands on them, but sometimes navigating through all this is difficult and you just want a quick reminder of the tools available to you. This is what this article is for. Basically, its a Howto for some common scenarios that you run into often and just serves to remind you of the options you have and how to implement them. Of course, whenever possible, the location of the original references in the Bookshelf is given.

The most common development tasks revolve around the following:

• Presentation - making fields Readonly, manipulating Applet contents, etc..
• Data - Data management, data models, fields, and records
• Validation - Performing validation on user input
• Performance - Basically fixing slow modules

Presentation
Manipulating presentation in Siebel has the same goals as any other business application. You might want to prevent a user from filling in a field, show different fields to different users, prioritize fields differently, etc...
Howto make fields Readonly
The most common task is making fields readonly, where they appear non-editable and grayed out. You have several options, depending on what you want to achieve and your specific implementation.

For instance, if you want to make fields appear as readonly constantly, you would use the field's 'Readonly' property, either at the Applet level, or at the Business Component level. How you make the choice between Applet level and BC level depends on your implementation. If you need that field readonly for specific views, but you want to be able to change it through other methods, like other views, scripting, integration, etc... you would use the Applet's 'Control' or 'List Item' property. If you don't want that field changed on that entity (represented by the BC) ever, then you would use the BC field's Readonly property.

Siebel also provides several means of making ALL fields appear as readonly. To make all fields appear as readonly you also have a property at the Applet level and at the BC level. That property is the 'No Update' property. If you set the 'No Update' property to TRUE, that makes Siebel show all the fields for all the records in that applet as readonly. Choosing between Applet level and BC level would be done using the same reasoning used in figuring out the use of the field level 'Readonly' property.

These properties provide you with a declarative way of manipulating the fields constantly across all records. To manipulate the readonly of the fields conditionally (i.e. based on certain condition like field values) you would turn to the use of 'User Properties'. The readonly user properties are set at the BC level and they get their instructions from a BC calculated field. The calculated field would return the boolean value 'Y' if it wants to turn on the readonly, or it would return boolean 'N' if it wants to keep the field in editable mode. Of course, the 'Readonly' properties would override the user property's condition by making the field readonly always.

To control one specific field, you would use the user property 'Field Read Only Field: ' and give it the value of the calculated field that controls it, where would be the field you want to make readonly.
example - you would add this property to the Account BC
Property Name: Field Read Only Field: Status
Property Value: Calc Account Status Is Readonly

In this example, we want to make the Status field readonly for everyone who is not the owner this account. The calculated field Calc Account Status Is Readonly would contain a calculated expression similar to this:
IF([Primary Owner Id] <> LoginId(), 'Y', 'N')
This expression would return Y if the logged in user is not the owner of the account, and so only the owner of the account would be able to change the value of the Account Status.

The same applies to making the whole record as readonly based on a condition. The user property used would be 'BC Read Only Field'
example - you would add this property to the Account BC
Property Name: BC Read Only Field
Property Value: Calc Account Is Readonly
This time, the calculated expression would control the readonly of ALL fields in the BC.
The calculated field Calc Account Is Readonly would contain a calculated expression similar to this:
IF([Status] = 'Deactive', 'Y', 'N')
This expression would return Y if the Account is in status Deactive, and so preventing further modifications of it.

Depending on which record is the selected record, Siebel would evaluate these user properties and make a decision for each record of which field needs to be readonly and which needs to be editable. This is some of the abstraction that Siebel provides its developers that makes it easily customizable.

Because the decision is made through a calculated field, you can make that decision based on many areas of the application. You can use the current BC's fields, the parent BC's fields (through the function ParentFieldValue()), Calculated Functions like 'LoginId()', 'Timestamp()', and you can even pass the decision to a Business Service through the function 'InvokeServiceMethod()'. But be aware of the performance of the application, specially when you have a field appearing in a list applet, you don't want to make the decision based on queries because that would be a serious performance hit, as the readonly status of the fields is gathered by the application many times through out the applet's lifecycle.

References:
User Properties - Siebel Bookshelf: Developer's Reference
Field Properties - Siebel Bookshelf: Object Type Reference (or hit F1 in Tools)

Howto manipulate Applet contents
There are several scenarios where you would manipulate applets instead of just showing the default layout. There are several options available for list applets and form applets.

For list applets, you can control the number of rows. The default number of rows shown is sufficient for most scenarios, but sometimes you either want to show a different number of rows for usability and readability of the view, or you can use the 'More Info' toggle feature to allow the user to double the number of rows displayed.

If you want to change the number of rows for a single applet from being the default of 10 rows, you use the HTML Number of Rows property of the applet. If you want to override the default of 10 for ALL applets of your application, you can use the Application's CFG file to control that. This would be in the CFG file in this form:
NumberOfListRows = 10

If you want to add the 'More Info' toggle button to allow the user to double the number of records displayed, then you would add the ToggleListRowCount control to the applet. The idea behind this control is simple. You add a control of type 'Link', give it the name and MethodInvoked of 'ToggleListRowCount' and the Bitmap 'BTTNS_MORE'. Of course you would add it to the layout at the usual position.

For form applets where you usually see only one record, you don't control the number of rows or records, but you control the fields that are displayed. There are two ways to do that. You can control the fields displayed by default which would be more relevant to most users and use the 'More Info' to show the extra fields. Or, you would control which fields are displayed according to the data in the applet by using the Applet Toggle feature.

To designate fields in the displayed by default or the 'More Info' fields, you set the Web Template Item's mode. In other words, to make a field appear in an applet only when the user clicks the 'More Info' button, you would do so for a specific web template. You would navigate to the applet's Web Template Items, then find your control in the items and in the 'Mode' property you would set it as More.

The 'More Info' approach is more for the readability of the view, and it doesn't enforce or hide any specific fields on the user, however, the Applet Toggle feature does have a lot of uses in some common business scenarios. You configure the applet toggle by specifying for a field, which values would show alternative applets, and you would design those applets to resemble the original applet with the difference of the fields you need.

Applet Toggle comes with a performance hit to it, but its usually negligible. The cost of switching the applets when the value changes is little and the problems that you would usually run into would exist with one of the applets used, so if your applets are OK, the Toggle would not be a problem.

Toggles are easy to implement but hard to maintain. The recommendation is to toggle for a few values on one field only. For example, for an Account applet, you would toggle based on 'Status' only and for a few values like 'Active', 'Inactive', 'Suspended'. The overhead with such toggle is that when adding a new field to the Account, you have to add it to all three applets for the different status values you have, and in the same location to make the toggle as seamless as possible.

If you want to add a toggle to an applet, you would use the 'Applet Toggle' child type of the Applet. There you would create a record for each value that you want the applet to have a different layout for. In that record, you enter information such as, 'Applet' that designates the applet to switch to, and 'Auto Toggle Field' and 'Auto Toggle Value' that tell Siebel which field to match to which value to change to that applet. The applets you toggle to must all have the same BC as the originating applet.

Consider the applet Account Profile Applet and its toggles. Out of the box, this applet would toggle to six other applets depending on the Type of the Account. All other applets are based on the Account BC. What you see in the Applet Toggle section is, the name of the applet followed by the same field to toggle from, and the values for the Type that would qualify each applet, followed by a sequence number.