Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a 09 cb cand_f
Similar a 09 cb cand_f (20)
Más de alvaro alcocer sotil
Más de alvaro alcocer sotil (20)
Último
Último (20)
09 cb cand_f
- 1. These training materials are confidential to Siebel. They may not be used to train anyone other than Accenture employees who have attended Siebel training. If the materials are marked "Restricted Use Allowed" you may use the information to help clients who are evaluating vendors, one of which must be Siebel and you may use the information to help clients which are implementing Siebel. If they are not so marked, then the information may only be used to help clients who are implementing Siebel. In either case, you can not; (a) use the materials if you are involved developing or are likely to be involved in developing a product competitive to Siebel (b)use the materials for a client who is a competitor of Siebel; or (c) provide the materials to any third party, whether it is a client or otherwise. If you are going to be discussing Siebel with a client and using these training materials as the basis of information you provide to the client, you must also make sure Accenture has a nondisclosure agreement in place with the client (as part of a Consulting Services Agreement or otherwise). Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 1
- 2. Please adjust volume to hear audio. Audio will play automatically for each slide upon advance. You may replay audio by clicking on the speaker icon in the upper right hand corner of each slide. Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 2
- 3. Configuring Business Components and Fields Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 3
- 4. Module Objectives 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 Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 4
- 5. Business Component Properties • Change the properties of business components to capture business logic • Commonly used properties include: Editing properties •No Delete •No Insert •No Merge •No Update •Even administrators cannot edit records if these properties are set Owner Delete Search Specification Sort Configuration Siebel 2001Specification ©Accenture ConfiguringKnowledge Check Return to Business Components and Fields - 5
- 6. Properties for Editing • Set these properties to FALSE at the business component level so that you can make exceptions at the applet level If you want even one applet to have edit privileges, you must set FALSE at the business component level You can also protect individual fields • Example Users can generally edit their personal contacts On the Contact Form Read Only applet, they can not edit these Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 6
- 7. Owner Delete Property • Set the Owner Delete property to TRUE to enable only the owner of a record to delete it The primary on a Team-Based business component is the effective owner of the record Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 7
- 8. Search Specification Property • Specifies records to be retrieved by the business component Typically used when there are multiple business components on the same main table • Example: The Personal Contact business component is distinguished from Contact by a search specification “Personal Contact” is a Boolean flag field Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 8
- 9. Search Specification Expression • Comparison operators e.g.: [Revenue] > 5000 • String Constants e.g.: [Type] <> “COST LIST” • Logical Operators e.g.: [Competitor] IS NOT NULL • Field in a Search Specification must be enclosed in square brackets e.g.: [Conflict Id] = 0 • The LIKE operator, used for text string comparison expressions, can use wildcards e.g.: [Last Name] LIKE “Sm*” • The Search Specification expression must be 255 characters or less. Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 9
- 10. Search Specification Expression Example • Example: For a given user, Contact(All) retrieves All contacts where the Personal Contact flag is “N” All personal contacts belonging to the user Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 10
- 11. Sort Specification Property • Determines the sort order of the retrieved records Use (DESC) or (DESCENDING) to sort that field in reverse order • E.g.: Start Date (DECENDING) • Example: Contacts are sorted by name Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 11
- 12. Sort Specification Performance Considerations • To ensure good performance, check whether an index exists for the business component base table Use the columns from the index as the sort specification, in the same order • Avoid using a sort specification that references columns in different tables because indexes refer to one table only Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 12
- 13. Field Properties • Customize fields by editing property values • Setting field properties at the business component level sets them across all applets Siebel 2001 Configuration ©Accenture Configuring Business Return to Knowledge Check Components and Fields - 13
- 14. Required Property • Set the Required property to True to prevent user from leaving field blank Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 14
- 15. Read Only Property • Set the Read Only property to True to prevent user from editing the value Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 15
- 16. Validation Property • Create a Validation property to ensure that field data is valid Rule is checked when you save the record Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 16
- 17. Validation Expression • Is expressed as a combination of: Logical operators e.g.: >=0 AND <=100 Constants e.g.: >=0 Field names e.g.: [Asset Asset Number] <> 100 • Can refer only to business component fields in the same record Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 17
- 18. Pre Default Values for Fields • Automatically assigns a value to a field for a new record User can modify the field if it is displayed and not set to Read Only • Example: Income Currency Code for a new Contact is set to a system default currency code Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 18
- 19. Post Default Values for Fields • Assigns a value to a field, if not entered by the user, before the record is inserted into the database • Example: If the user does not designate a contact as personal, the system assumes it is not Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 19
- 20. Calculated Fields • Derive their value from the values in other fields of the business component • Cannot be stored in the database So there is no associated column • Require setting the Calculated property to TRUE (shown as checkmark) Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 20
- 21. Calculated Value Property • Is an expression built from: Field names in the same business component Field names from the parent business component • Current business component must be the child in a detail view Standard functions String, numeric, and logical operators Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 21
- 22. Restrictions on Calculated Fields • Calculated fields are read-only • System does not validate values of calculated fields • Sorting on calculated fields is not supported • Cannot sort calculated fields in columns • Validation criteria is ignored • Querying on calculated fields is supported Performance depends upon whether the functions in the query expression can be incorporated into the SQL statement Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 22
- 23. Modifying a Field - Example Scenario: 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. Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 23
- 24. Modifying a Field - Example 1. In Siebel Tools/Object Explorer, select Projects definition. 2. Make a query by the Service project and lock it. Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 24
- 25. Modifying a Field - Example 3. In the Object Explorer, select Business Components definition. 4. In the Business Components applet, make a query by Service Request. 5. In the Object Explorer, expand the Business Components definition and select Single Value Field. Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 25
- 26. Modifying a Field - Example 6. In the Single Value Field Applet, make a query by Owned By Id field. 7. Set Post Default Value = System: CreatorId (Do not include the equal sign, “=“). 8. Add the following Comment: “Your initials” added post default value “Today’s Date” Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 26
- 27. Testing your changes - Example 9. Compile your changes. - Go to Tools/Compile Projects - Add the Siebel Repository File: C:Siebel7ClientOBJECTSENUsiebel.srf - Click Compile Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 27
- 28. Testing your changes - Example 9. Start the Siebel 7 Application from as SADMIN, sample database. 10. Select Service screen, My Service Requests view. 11. Add a new service request record. Leave the Owner Column in blank. 12. From the Applet Menu button select New Query then Run Query. A value for the Owner field will be added. Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 28
- 29. Lab Activity • Now is your chance to practice some of the concepts we've just covered. • Proceed to Lab 1 for this module. • Once you have completed this section, resume viewing the presentation where you left off. Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 29
- 30. Activity Recap Now that you have completed Lab 1, you should be able to answer the questions below. Try to answer each question; the answer will pop up as you advance the slide. Question Where can you find information about functions to be used as default values? How do you disallow updates to a Business Component? What do you have to do to see your changes in your application? Siebel 2001 Configuration ©Accenture Answer In Siebel Bookshelf, Tools Guide. Setting the No Delete, No Merge, and No Update properties to TRUE. Compile the project making sure you are compiling to the Siebel repository file: appDrive/clients/OBJECTS/ENU/siebel.srf Configuring Business Components and Fields - 30
- 31. Creating a New Business Component • Siebel business components capture most commonly-used business entities, but they do not cover every possibility • In order to capture a large amount of information, you can create new business components as children of an existing business component Used to add entities specific to your organization that are not in the Siebel repository Is an exception to the recommendation not to copy or modify existing business components • You base these business components on standard 1:M extension tables supplied by Siebel Systems • Example: Create College and Restaurant business components for sales organization Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 31
- 32. Standard 1:M Extension Tables • Predefined in the repository for many business components • Has name of main table appended with _XM Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 32
- 33. Multiple Business Components • You can use one _XM table to map multiple user-defined child business components • Each business component has a unique TYPE value Stored in the TYPE column of the _XM table • Each business component retrieves only those rows with its type value Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 33
- 34. User Key for _XM table • NAME, TYPE, and PAR_ROW_ID serve as a user key for the _XM table Must provide values for all 3 columns when creating a new record Combination must be unique • For business components with data that cannot be stored in a Varchar 100 column, you must still provide a unique value for NAME Workaround is to store value of ROW_ID in NAME Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 34
- 35. Create New Business Component • Create a business component (BC) to represent the 1:M extension table Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 35
- 36. Create fields for the Business Component • Add fields that map to: TYPE column • Set Predefault Value property to value used in the BC search specification PAR_ROW_ID NAME • Create additional fields for any other required data Choose an ATTRIB column with the right type and length Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 36
- 37. Relating the Child and Parent BCs • Associate the newly configured child business component with the parent by: Creating a link definition to relate child and parent records Including the child in the business object defined for the parent Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 37
- 38. Create the Link • Create a new 1:M link Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 38
- 39. Add Business Component to Business Object • Create a new Business Object Component definition for the child • Set the Link property Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 39
- 40. Displaying Data from the _XM Table • Build applets and views as required to display data from the child business component • Do not display the TYPE field to prevent users from changing the value Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 40
- 41. Summary 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 Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 41
- 42. Knowledge Check Take this opportunity to check your knowledge of the concepts presented in this module. Try to answer the questions on the slide. The answer for each question will pop up as you advance the slide. Each answer may link back to the area within the presentation where that concept is presented. At the end of the section referenced you will find a ‘Return to Knowledge Check’ hyperlink, which will take you back to this slide. Question Answer Describe the steps in configuring business components. Change the properties of business components to captur Describe the steps in configuring fields. • Customize fields by editing property values. • Setting field properties at the business component level Siebel 2001 Configuration ©Accenture Configuring Business Components and Fields - 42
Notas del editor
- 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