Module Overview Welcome to Configuring business components and Fields To show how to configure business component and field properties to capture a company’s business logic. This module shows how to use editing properties to limit users’ abilities to edit BCs; how to use some other key properties for BCs, including searching and sorting; how to set and use properties on fields; and how to create calculated fields.
As a result of taking this module, you will be able to: Describe the necessary steps in configuring business components and fields Demonstrate creating a New BC Using the Standard 1:M Extension Table
We have already discussed in previous modules what a business component is, so you should be familiar with it’s definition. Just to quickly recap, a business component defines a logical entity that associates columns from one or more tables into a single structure. business components provide a layer of wrapping over tables, and the applets reference business components rather than the underlying tables. What we are going to discuss now is business components and their properties. A business component has some key properties that are commonly used. Amongst the many properties a business component contains are some editing properties such as: ‘No Delete’, ‘No insert’, ‘No Merge’, and ‘No Update’. These properties have been highlighted in the Properties Window showed in the slide. Now, the ‘No Delete’, ‘No Insert’, and ‘No Update’ properties are BC properties that when set to True result in no records to be deleted, added, and updated through the business component. Even administrators cannot edit records of the business component if these properties are set to true. When the ‘No Merge’ property is set to True the user will not be able to merge two existing records into a single record. An example of why you would use the ‘No Delete’ property would be to maintain record continuity. By doing this for example, users cannot delete or change price lists once they have been created In the next few slides, we will discuss the rest of the properties shown above.
Now setting the Editing Properties of ‘No Delete’, ‘No Insert’, ‘No Merge’ and ‘No Update’ to True at the business component level means that all applets created for that business component will have to have these rules enforced upon them – there can be no exceptions. However, if there are some applets that you want to enforce these rules upon and some applets that you don’t, a way to overcome this is to set the properties at the applet level rather than at the business component level. This means that if you set any of the properties to true at the applet level, the rules are only enforced upon the applet that you set the property for – not the whole business component. Therefore you can analyze the need for these rules at an applet level rather than at a business component level, giving you greater flexibility. An applet is a data entry form, composed of controls, that occupies some portion of the Siebel application window. An applet can be configured to allow data entry, provide a scrolling table of data rows, or display business graphics, a navigation tree, or a Web browser. It provides viewing, entry, modification, and navigation capabilities for data in one business component. There are two typical applets types: List Applet: allows simultaneous display of data from multiple records. Form Applet: presents business component information in a data entry form applet. We will go in more details about applet definition and configuration in Module 13. One example of when you might want to enforce some editing rules is in the case of Personal Contacts. A user might want to edit their details, however in the Contact Form Read Only applet, you will probably want to stop the user from making amendments. This would be done by setting all the edit properties to True in the Contact Form Read Only applet and leaving them as False in the other applets relating to personal contacts. One point to note is that you also have the option of setting these properties at an individual field level. This gives you further flexibility by allowing you to enforce rules on a field by field need.
Let us now discuss the Owner Delete property in further detail here. The Owner Delete property specifies who can delete the record, and in this case, if the Owner Delete property is set to TRUE only the owner of the record has the ability to delete it. There are a few ways to determine who is the owner of the record. For example; the owner of a record in a business component set up for team visibility mode is the primary position on the sales team; the owner when the business component is set up for employee-based personal visibility is the employee whose logon appears in the field pointed to by the Owner Visibility Field property; and the owner when set up for position-based personal visibility is the position in the field pointed to by the Position Visibility Field property. However, if the Owner Delete property is set to False, anyone can delete the record.
Now we will discuss the “Search Specification property”. This property of a business component is a conditional expression (part of SQL statement) that restricts the records retrieved. The Search Specification property is typically used when there are multiple business components on the same main table as a filter for the records so that only the appropriate records for each business component are received. If the value in the Search Specification property in a business component object definition is non-blank, the set of records provided to an applet using this business component is restricted. The Search Specification contains the names of one or more fields in the business component and various operators, combined to create a conditional expression. Records in which the value of the conditional expression evaluates to TRUE are provided to the applet for display; those records in which the expression evaluates to FALSE are excluded. The best way to describe the Search Specification property is by an example. Let’s use the Personal Contact business component. This business component will only want the records from the base table that are indeed Personal Contact records, and this can be determined through a Boolean flag field called ‘Personal Contact’. If this field is set to ‘y’, then the business component knows that the record is a Personal Contact. However, if the record is set to ‘N’, the business component will determine that it is not a Personal Contact and would therefore not want it included. This can be defined by setting the ‘Search Specification’ to [Personal Contact] = ‘Y’.
Now it is important to understand how to define a Search Specification Expression. Search Specification Expressions are built according to the following syntax rules: Standard comparison operators are used to compare a field to a constant, or one field to another field. These include =, <>, >, <, >=, and <=. Example: [Revenue] > 5000 String Constants are enclosed in double quotation marks. String values are case sensitive, so the use of uppercase and lowercase letters in the search specification should exactly match that of the records you want returned. Example: [Type] <> "COST LIST" The Logical Operators AND, OR, and NOT are used to negate or combine expressions. Case is ignored in these operators; for example, “and” is the same as “AND”). Example: [Competitor] IS NOT NULL and [Competitor] <> "N" A field name in a Search Specification must be enclosed in square brackets. Example: [Conflict Id] = 0 The LIKE operator may be used to create text string comparison expressions in which a field is compared to a constant, or a field to another field, and a match on only the first several characters is required. The wildcard characters “*” and “?” are used to indicate any number of characters, and a single character, respectively. Example: [Last Name] LIKE "Sm*“ In this example, the Last Name values of Smith, Smythe, Smallman, and so on would cause the expression to evaluate to TRUE. Now it is important to note that an applet Search Specification cannot be used to override the Search Specification of the underlying business component, if the business component has one. Rather than overriding the business component’s search specification, the applet’s search specification is appended to that of the business component. Search Specifications should appear in the business component or the applets that use it, but not both.
The graphic displayed above is an example of a Search Specification in which for a given user, the “Contact(All)” business component will retrieve only Non Personal Contacts unless the Personal Contact record belongs to the user. This Search Specification is defined above and it is the record highlighted green. The example requires the use of Operators, Logical Operators and Functions. One important thing to note is that the Name field must be enclosed in square brackets. It is also important to note that when working with Field Names, the Field Name used in the Search Expression must match the Field Name in the business component exactly.
Now let us discuss the “Sort Specification” property. The ‘Sort Specification’ of a business component is used to order the records retrieved. The value in the Sort Specification property, if it is non-blank, is the name of a field or list of fields that imposes a sort order on the records returned to an applet that is associated with this business component. The field or fields must be child object definitions of the business component. For example, the Contact business component (as delivered in Siebel applications) has a Sort Specification property value of “Last Name, First Name”. This indicates that contact records are provided in Last Name order, and where multiple contact records have the same Last Name, they are to be sorted within Last Name by First Name. An important point to note is if you wish to indicate that a field in the list sorts in descending order, you can include ‘(DESCENDING)’ or ‘(DESC)’ after the field name, as in “Start Date (DESCENDING).” If you do not specify a sort order, ascending order is used. When defining a Sort Specification, you should observe the following syntax considerations: Use commas to separate field names in a sort specification. Do not enclose the field name in square brackets, as in [Account Name]. Brackets are accepted in Search Specifications, but not in Sort Specifications. The Sort Specification Expression must be 255 characters or less. Again, it is important to note that when referencing field names, the field name used in the search expression must match the field name in the business component exactly.
Improperly chosen Sort Specifications can hurt performance. This is particularly true when the sorting is on fields based on joins. Indexes refer to one table only, so if a Sort Specification spans more than one table, performance may become an issue. To ensure good performance, check whether an index exists for the business component base table. If an index does exist, you should use the columns from that index as the sort specification in the same order as an index already exists and hence performance will not be compromised.
Just as we can set properties at business component level, we can also set them at the field level. This allows you to customize individual fields on the business component. It is important to note however, that setting field properties at the business component still sets them across all applets that reference those fields. In the next few slides, we will be discussing some of the field level properties that you as a Configurator can set.
Setting the Required property to TRUE requires a value to be entered into the field before the record can be written to the database. If you set a field’s Required property to True and then try and save or step off the record without entering a value within the field, Siebel will return an error message telling you that the field is required therefore you are not able to save or step off the record until you enter a value into the field.
Setting the Read Only property to TRUE prevents the field from being changed by the user. If you set a field’s Read Only property to True, Siebel will make the field Read Only, therefore not enabling you to change the field’s value.
A field’s Validation property restricts the values for a field or ensures the correctness of data entered, for a single value field. The rule that you have created is checked when you save or try and step off the record. Attempting to save a record when a field does not meet the validation requirements that you have specified, results in an error message being displayed by Siebel. An example for when you would need to create a field level validation is displayed above. In this example, a field level validation expression is written for the Warranty End Date to ensure that when creating a warranty for an asset, the end date must be a value that comes after the start date. The Validation Expression rules are discussed further in the next slide.
Now it is important to understand how to define a Validation Expression. The Validation property is expressed as a combination of logical operators, constants and field names. These were described in detail in the Search Specification Expression Slide and are used in the same way for the Validation property. One thing to note is that all validation expressions using field names can only refer to business component fields in the same record. That is, if you are using a field name within your Validation expression, the field name you are using to reference to must be a field on that current business component, and the value that will be returned is the value of that field IN THE CURRENT RECORD.
Now let’s discuss another field level property - the Pre Default property. The value defined in the Pre Default Property is the value assigned to an empty field when a new record is created through an Add New Record or Copy Record operation. The value can be changed by the user before the record is written to the database. The Pre Default value for the field is used even when the field is not exposed in the user interface. The values that can be used for the Pre Default property are System values, constants, expressions and Inherited Values. Some examples are shown in the above diagram. It is important to note that when using a system value, the word ‘System’ followed by a ‘:’ must be placed before the actual system value. If you do not include this prefix, Siebel will consider the value you have entered as a constant and place that string straight into the field as a Pre Default value. An expression such as: Expr: ‘Today() – 1’ can be used in which case the result that will be pre defaulted in the field will be a string representation of yesterday’s date. You can also use an Inherited Value such as Field: ‘FieldName’. In this case the ‘FieldName’ is a value in the current business component. It is important to note there that ‘FieldName’ does not work in the Pre Default value property if the field name is a join field. In the example given above for Parent: ‘AccountId’, the AccountId in the parent business component, in this case – Account is returned. You can have multiple “Parent:” constructs separated by commas; the list is checked from first to last until a value is found. If “Parent: FieldName” is used, the field in the parent business component must have the Link Specification set to True in order for values to be defaulted.
Now, let’s discuss another field level property - the Post Default property. The Post Default property defines the value used for an empty field when the record is initially written to the database. This value is not used if the field is left empty on subsequent updates to the record. The Post Default value for the field is used even when the field is not exposed in the user interface. The Link Specification property needs to be set to TRUE on the Parent business component for the parent syntax to work in the child business component’s linked field. The syntax for the Post Default property is the same as for the Pre Default property.
Now, let’s move on to another field level topic, Calculated fields. A Calculated field is a field whose value is derived from the values of other fields by some formula. You do not enter data into a calculated field; the system automatically determines the correct value based on the expression entered in the Calculated Value property. Calculated fields have a Calculated property of TRUE and a non-blank Calculated Value property. A calculated field obtains its values from other fields in the same business component, or from the master business component in an active link in which the current business component is the detail. The Calculated Value property contains an expression built from field names, standard functions, and string, numeric and logical operators. Calculated fields will be discussed in further detail over the next few slides.
The Calculated Value property specifies an expression for calculating the value of a field. A field’s Validation property restricts the values for a field or ensures the correctness of data entered for a single Value field The expression in the Calculated Value property is built from field names in the same business component or field names from the parent business components. Once again, the same rules as were present for Pre Default Value expressions apply for referencing fields in Calculated Values. I.e. The field value returned is that of the current record. Strings, numeric and logical operators can all be used when setting the Calculated Value property. Again, the rules that apply here are the same as in the Pre and Post Default Value fields. In addition to what has already been mentioned, there are a number of standard functions that can be used in a Calculated Value property. These can be found in the Siebel Tools Reference.
Calculated fields have the following rules and restrictions: Calculated fields do not support updates (even simple expressions like [Field]), therefore they are read only. You cannot sort on a Calculated field, this is not supported by Siebel. Calculated fields cannot be stored in columns therefore the column property in the business component is left blank for a Calculated field. Validation criteria on Calculated fields are ignored. Queries on Calculated fields are always supported. However, the performance will depend on the functions used in the expression.
In this example, we were asked to modify the Owned By Id field on the Service Request business component. They asked us to add the Creator Id field as a default value.
Now we will move to a different topic, which is creating a new business component. The need to create a new business component generally arises from the need to capture more information. In order to capture every possibility of data that your business may need, you may need to create new business components as children of an existing business component. This will add entities specific to your organization that are not currently in the Siebel repository. Now, generally it is an accepted guideline that we do not copy or modify existing business components, however, the need to capture more data for a business component is an exception. For example, you may have a need for three new multi-value fields in the Contact business component to store information on hobbies, and favorite restaurants for each contact. No business components exist for these entities. However, you can implement the same functionality using S_CONTACT_XM, the one-to-many extension table that extends the Contact business component. A one-to-many, rather than one-to-one, extension table is required because there can be many hobbies, prior companies, or areas of expertise for one contact. Since the relationship is one-to-many rather than one-to-one, a link is required rather than an implicit join. There is a fixed set of one-to-many extension tables supplied with Siebel applications, and you cannot create additional ones. However, you can extend existing one-to-many extension tables. You can use one-to-many extension tables to create multi-value groups and master-detail views that are based on custom business components—that is, business components not present in standard Siebel applications.
One-to-Many extension tables have a Type property value of Data (Public) rather than Extension. However, from a functional standpoint, One-to-Many extension tables are considered extension tables, and they have the same set of generic and system columns. They are predefined in the repository for many business components. The names of One-to-Many extension tables have the suffix _XM.
Multiple custom business components can be created using the same One-to-Many extension table. Each custom business component presents a different type of data for use in a different Multi-Value Group. The Detail business component contains one important property for use with a One-to-Many extension table: This property is the Search Specification. The Search Specification property should be set to restrict the records retrieved to only those with a specific value in the Type field. This is the same value that is specified in the Pre Default Value property for that field. In this way, the only records retrieved in the business component (and, indirectly, the Multi-Value Link and Multi-Value Group applet) are those designated as being in this Multi-Value Group. In the example given above, both the Colleges Attended business component and Favorite Restaurants business component can be mapped to the S_CONTACT_XM extension table. The ‘type’ field is used to store the value “College” for all records held for the Colleges Attended business component and the value “Restaurant” for all records held for the Favorite Restaurants business component. In each of these business components, a search specification should be set on the type field so that they receive only records belonging to their own business component.
Now let’s discuss another topic, that is the User Key for the _XM table. The extension table, like any other table has a user key that must be filled in and be unique for each record. For the 1:M extension table, the 3 fields that make up the user key are NAME, TYPE and PAR_ROW_ID. Typically, a business component would use the Name field to store the data it wants to place in the _XM table, however, the name field is constrained to a maximum of 100 characters and this must be unique. The reason that the Name field must be unique is because the user key – as a 3 field key, must be unique. Now because the relationship between the base table and the _XM table is 1:M, the PAR_ROW_ID will be duplicated for each record in the _XM table that relates to the same record in the base table. Furthermore, the type will not be a unique field because as we described earlier, the type will be repeated for each record that belongs to the same business component, this leaves the Name field and in order to make sure the key is unique, the value contained in the Name field must be unique. A way to ensure that the User Key for the _XM table is unique is to store the value of the ROW_ID in the name field and store the data for the business component in another field in the _XM table where it can be greater than 100 characters and does not need to be unique.
Now let’s move on to creating a new business component. The steps involved in creating a new business component to represent the 1:M extension table are as follows: Navigate to the business components object type in the Object Explorers window and either press on the “Add a new record” button displayed above or use your mouse to right click and select “New Record” Enter the following properties to create the business component: Name. The standards for creating a name were covered in an earlier module but just to recap, when entering a value into this field, use a tag such as company initials to distinguish the new business component from Siebel-supplied business components Table. You should set this property to be the name of the 1:M extension table Class. This property should be set to the class CSSBusComp which is the default class for business components Search Specification. This property should be set to match the unique ‘TYPE’ value for the business component. Project. This property should be populated with the appropriate project that the business component belongs to. Once you have filled in all these properties, you can step off the record to save it.
Now that we have created the business component, you will need to add fields to it. The fields you add will need to map to the ‘TYPE’, ‘PAR_ROW_ID’ and ‘NAME’ fields in the _XM table. To add fields to the business component: Navigate to the business components object type in the Object Explorers window and select the new business component you have created. From here, navigate to the Field Object type and either press on the “Add a new record” button or use your mouse to right click and select “New Record”. Add a new field that is mapped to the TYPE column. You can call the field anything you wish however you should set the Pre default value property to the value used in the BC Search specification. You should set the Type property accordingly. Repeat steps 2 and 3 to create a field that maps to the PAR_ROW_ID field of the _XM table Repeat steps 2 and 3 to create a field that maps to the NAME field of the _XM table Once you have created the 3 required fields, you can then create any additional fields that you may need to store any other data you may have. Any field that you may wish to add will need to be mapped to a spare field on the _XM table.
Now that we have created all the fields for our new business component, we are ready to associate it to the parent business component. You do this in two steps. Create a link definition to relate the child and parent records together Include the child in the business object definition for the parent. This is explained further in the next two slides.
The steps involved with creating a link are as follows: Navigate to the Links object type in the Object Explorers window and press on the “Add a new record” button or use your mouse to right click and select “New Record”. In order to create the link, you will need to fill out the following properties: Child business component. This property should be populated with the business component name that you have just created. Destination Field. This property should be populated with the foreign key of the base table. Name. This should be the name of both the business components that are being linked with a forward slash separating the two. Parent business component. This property should be populated with the name of the parent business component . Source Field. This property should be populated with the primary key of the _XM table. Once you have populated each of these fields, you can step off the record to save the link.
Now that you have created the link, you are ready to add the business component to the business object. The steps involved with doing this as follows: Navigate to the Business Objects object type in the Object Explorers window and select the Business Object that the parent business component belongs to. From here, select the business components object type from the Object Explorers window and select the Parent business component from the link. Navigate to the link property on the parent business component and enter the name of the link you just created in here. Once you have done this, you can step off the record to save your work.
Now that you have created the new business component and related it to it’s parent, you are ready to begin building applets and views as required to display data from the new business component. Creating applets and views will be discussed in greater detail over the next few modules so we won’t go into that right now, one thing that is very important to note though is that you must remember never to display the type field on an applet or view. The reason for this is that the type field should never be changed and if you display it on an applet, you run this risk. You should never have a need to display the type field because the value contained in this field should be the same for every record in that business component.
Now that you have completed this module, you should be able to: Describe the necessary steps in configuring business components and Fields Demonstrate creating a New BC Using the Standard 1:M Extension Table