10Reusing Predefined Objects
Reusing Predefined Objects
This chapter describes how to reuse a predefined object. It includes the following topics:
It is recommended that you reuse predefined objects to configure Siebel CRM. You must avoid making significant configuration of Siebel CRM, and that you attempt to reuse and configure predefined objects where possible. Situations exist when reusing a predefined object is not appropriate and can cause problems. This topic describes when to reuse and when not to reuse a predefined Siebel object.
Reasons to Reuse or Not Reuse a Predefined Object
This topic describes reasons to reuse or not reuse predefined object.
Reasons to Avoid Extensive Customization of Siebel CRM
Customization is the act of performing significant modifications to the predefined product, such as making the following modifications:
Creating new modules that do not exist in the predefined Siebel application. This work typically involves configuring the database, and creating many new business components and business objects.
Modifying a significant number of predefined objects.
Making significant modifications to predefined behavior, such as visibility.
Making significant modifications to framework objects, such as JavaScript files.
Writing a significant amount of custom scripts.
Inappropriate customization of Siebel CRM can cause the following problems:
Decreased maintainability.
Increased cost of ownership.
Potential for decreased performance. A predefined Siebel application is tuned for performance.
Potential affect on future upgrades.
Increased testing effort.
Inconsistent application behavior.
Why Reusing Objects Is Important
Reuse involves building components that you can reuse and configure. Reuse allows you to limit the amount of customization in your deployment. Any modifications that you make to the predefined configuration must maximize reuse and allow for easy customization. Several ways exist to reuse components in Siebel CRM. For example:
Use predefined configuration objects. For example, business components, business objects, links, applets, views, and so on.
Use Siebel declarative configurations and tools to translate business requirements into application behavior. For example, Siebel Tools, Siebel Workflow, Task UI, personalization, run-time events, and state model.
Guidelines for Reusing a Predefined Object
This topic describes guidelines for reusing a predefined object. It includes the following information:
Reasons to Reuse a Predefined Object
The following reasons describe why it is recommended that you copy, and then modify a predefined object rather than create a new object:
Oracle configures many predefined objects for optimal performance. A custom object you create might not be configured for performance.
When troubleshooting, you can use the object in the sample database to revert back to the original object. You can use the comparison feature in Siebel Tools to determine what modifications were made to the object that might cause the problem.
Repository and application maintenance requires less time and fewer resources.
Eliminating unnecessary copies of objects reduces the amount of redundancy in the Siebel repository.
Oracle thoroughly tests a predefined object, so less effort is required to test Siebel CRM or to resolve an application error.
By reducing the number of repository objects that you must evaluate or upgrade, less effort is required when you upgrade Siebel CRM.
Guidelines for Reusing a Predefined Table
If you must create a custom business component because no predefined business component meets your requirements, then you must decide to reuse a predefined table or to create a new table. You must only reuse a predefined table that is a suitable fit. Several reasons exist for this guideline:
Oracle tunes the indexing for the table for the originally intended use. Using it for an alternative purpose might reduce performance.
The user key table for the unique indexes might not meet your requirements. For a predefined table, you cannot modify these objects. If a user key column does not contain the required data, then the uniqueness of the record, performance, and Enterprise Integration Manager might be compromised.
The dock object visibility rules might not meet your requirements. Modifying the rules for the table might compromise Siebel Remote. For more information, see Configuring Dock Objects for Siebel Remote
If you do not reuse a table appropriately, then future reuse of that table for the original purpose of the table might be difficult. For example, assume you use the S_CALL_LST table to store data that is not related to a call list. If you later implement predefined list management, then Siebel CRM displays data that is not related to the call list in the list management views. Adding a search specification to remove this data might compromise performance, and adding an index might or might not correct this problem. For more information, see Options to Filter Data That Siebel CRM Displays in an Applet.
You must not modify any repository table. If the Type property of a table is Repository, then it is a repository table.
For more information, see Reusing Predefined Objects.
Guidelines for Overloading a Table
You might overload a table if you reuse it multiple times on different business components, and if each business component includes a search specification in a Type field. For example, if you use the S_EVT_ACT table to store regular activities, audit logs, error logs, messages, EAI logs, and so on.
If you overload a table, then to prevent Siebel CRM from display data from one business component in another business component, it is often necessary to add a search specification that queries a Type field.
Overloading a table can cause the following problems:
The search specification that Siebel CRM uses to type the table into various business components might cause performance problems. Siebel CRM might not design the table to be overloaded. For example, it often uses the TODO_CD column of the S_EVT_ACT table to set the type of the table. Siebel CRM does not denormalize this table on to the S_ACT_EMP intersection table for activities and employees. A query that uses the sales representative visibility against a business component that references the S_EVT_ACT table might result in poor performance.
No guarantee exists that adding indexes against these type columns will resolve a performance problem because adding an index might compromise performance elsewhere. The fact that Siebel CRM might not denormalize a type column onto a position, employee, or organization intersection table might affect a query in some views.
Overloading a table increases the table size.
For more information, see Options to Filter Data That Siebel CRM Displays in an Applet.
Oracle Designs Some Tables to Be Overloaded
Oracle designs some tables in the Siebel schema to be overloaded. For example, the S_ASSET table uses the TYPE_CD column to set the type for various business components. Oracle denormalizes and indexes this column onto the S_ASSET_POSTN and S_ASSET_BU intersection tables to improve performance in SalesRep and Organization visibility views. Some XM tables, such as S_ORG_EXT_XM, are designed to be overloaded.
Guidelines for Using an Extension Table as the Base Table of a Business Component
You must never use an Extension or Extension (Siebel) table as the base table of a business component. Siebel Enterprise Integration Manager and Siebel Remote assume that the PAR_ROW_ID and ROW_ID columns on these tables are equivalent and that the PAR_ROW_ID column references a valid parent table record. For more information, see Extension Columns of a Siebel Table.
Guidelines for Creating a New One-To-One Extension Table
In most situations, you must extend the base table or reuse an ATTRIB column on a one-to-one extension table. Rare instances exist when you must create a new one-to-one table, such as to add a LONG column because you cannot add it to a base table and because Siebel CRM supports only one LONG column on a table. For more information, see Creating a LONG Column on an Extension Table.
Guidelines for Creating a New XM Table
In most situations you must reuse a predefined XM table to support a one-to-many relationship from a base table. If you use an XM table, then use the following guidelines:
Very few situations exist that require you to create a new XM table. Siebel CRM already tunes XM tables to support large data volumes and multiple data types. Before you create a new XM table, make sure to examine the predefined XM tables to determine whether one meets your requirements.
In some instances, a base table does not reference an XM table. Instead of reusing another unsuitable predefined table because it contains a foreign key to the base table, you must create a new table. For example, if you require a one-to-many business component from the S_EVT_ACT table, then you must create a one-to-many table rather than reuse a table that might be inappropriate, such as the S_ACT_TIMESTAMP table, provided that the business component does not store timestamp information.
For more information, see How an Extension Table Stores Custom Data.
Guidelines for Using a Table That Is Not an Intersection Table to Create an Intersection
You must reuse an intersection table only where it is a true intersection between two tables. The type of table must be Data (Intersection). Do not use a table that is not an intersection table as an intersection table only because it contains a foreign key to the table. This configuration can overload the table. For more information, see Reusing Predefined Objects
Do not use a one-to-many XM table as an intersection table. Siebel CRM does not tune an XM table for this usage, and using it as an intersection table might cause poor performance. To support one side of the relationship, you must create a custom foreign key. This configuration might cause problems with Siebel Remote and Enterprise Integration Manager.
If no suitable intersection table exists between two tables and one is required, then you must configure the database. For more information, see How an Extension Table Stores Custom Data.
Guidelines for Using a Table That Is Not Licensed
Do not reuse an unused table that is not licensed for your configuration.
Guidelines for Using the S_PARTY Table to Support a Custom Party Type
Using a custom party type compromises access control and remote visibility. For more information, see How the S_Party Table Controls Access.
Guidelines for Reusing a Predefined Business Component
Inappropriately using a predefined business component can make it difficult to use the same business component for the intended purpose in a future release. For example, if you use the Service Request business component to store financial transactions in one release, then you might be prevented from using the same business component to store actual service requests in a future release. For more information, see Guidelines for Creating a Business Component.
if you reuse a predefined business component, then use the following guidelines:
If you require a business component that is similar to a predefined business component, then do one of the following:
Create a new business component that references the predefined business component.
Modify the predefined business component.
Oracle prefers that you modify a predefined business component because it minimizes the number of business components in your configuration. This situation leads to a smaller repository that is easier to maintain and upgrade because it is more closely aligned with the predefined Siebel application.
Use the business component in a way that is consistent with the intended use of the business component. For example:
Use the Contact business component to store individual details for each contact at a customer site.
Use the Account business component to store details of the business relationship with the customer.
Do not use the Service Request business component to store information that is not related to a service request, such as a financial transaction or order history.
If you reuse a business component, then configure it to be as flexible and reusable as possible. For example:
In one release you use the Service Request business component to store customer complaints.
In another release, you use the Service Request business component to store addresses for customers who changed their address.
In these situations, you must use the Service Request business component rather than using the business component in a subsequent release for other service transactions. For example, you could use the SR Type field to distinguish between the two service transactions. Your business requirements must be as generic as possible to facilitate the use of a single business component.
Always configure Siebel CRM in a way that allows you to reuse a business component instead of creating a new business component. For example, Siebel CRM can allow one group of users to create new opportunities, but another group can only edit existing opportunities. Instead of creating a new business component and setting the No Insert property to TRUE, you can create a new applet and set the No Insert property to TRUE for the applet.
Guidelines for Copying a Predefined Business Component
If you copy a business component, then you must copy the links that this business component uses, and then update the copies with the new business component name. You can avoid errors if you copy and update links. For example, if you clone the Service Request business component and name the clone Service Request ABC, then you must copy the Service Request/Action link and name the copy Service Request ABC/Action.
Guidelines for Reusing a Predefined Business Object
It is recommended that you avoid copying a business object or business component, but copying might be appropriate in the following situations:
When you must include a business component twice in a business object. For example, the Account business object must include the Account business component and Sub Account business component.
When two business components contain different search specifications and predefault values for the Type field that differentiates the records of these two business components. For more information, see Options to Filter Data That Siebel CRM Displays in an Applet.
Guidelines for Reusing an Applet
To decide to reuse or create an applet, use the following guidelines:
If your requirements closely align with the functionality of a predefined applet, and if this applet only requires minor modification, then modify it. For example, to modify a title, deactivate, or add a few controls or list columns, or to modify display labels.
If the predefined applet meets your requirements for a relationship in the data model, such as between an opportunity and contacts, then copy this applet. You can then modify the new copy to make significant modifications, such as the applet layout, resequencing, inactivating objects, or adding many new controls and list columns. This configuration is easier to maintain and upgrade.
If your requirements demand a different drilldown to a different view, then copy a predefined applet, and then modify this copy.
If you cannot locate a suitable predefined applet, then create a new applet. For example, if your requirements demand that you display a new business component.
If you copy an object, then use the Upgrade Ancestor property. For more information, see Guidelines for Setting the Upgrade Ancestor Property.
For more information, see the following topics:
Guidelines for Reusing a Predefined View
To decide to reuse or create a view, use the following guidelines:
If the requirements for a new view closely align with a predefined view, but require simple modifications, such as modifying the view title, or moderate layout modifications, such as displaying a different applet or adding a toggle, then you can modify the predefined view.
For a view that consolidates two predefined views, it is recommended that you modify one of these views, and then use the Responsibility Administration screen to remove visibility from the redundant view.
If the requirements for a view do not align with a predefined view, and if the predefined view requires significant modifications, then you can create a new view. Typically these views implement new functionality that your implementation requires. For example, you might need a view to display new business objects or business components. In these situations, it is easier to maintain and upgrade a new custom view rather than modifying a predefined view.
If you copy an object, then use the Upgrade Ancestor property. For more information, see Guidelines for Setting the Upgrade Ancestor Property.
For more information, see the following topics:
Guidelines for Reusing a Predefined User Interface Object
Sometimes it is appropriate to copy a user interface object. For example, if your business requirements demand a significant modification to the look and feel of the object, then copying the object and setting the Upgrade Ancestor property makes certain that Siebel CRM preserves the modified look and feel following an upgrade. For more information, see Guidelines for Setting the Upgrade Ancestor Property.
If you only require a minor modification to the user interface object, then it is recommended that you use the predefined object because this configuration reduces the time you spend to configure and maintain the Siebel repository. The following reasons describe when it is appropriate to copy a user interface object:
When you require two different user interface objects to display different records that use different search specifications on applets. For more information, see Options to Filter Data That Siebel CRM Displays in an Applet.
When you require different read and write properties between two objects. For example, one applet is read-only and the other applet is editable. In this situation, only copy the object if the dynamic read-only business component user property does not fulfill this functionality.
When you require different drilldowns for different applets, depending on the view that contains them. In this situation, copy the object only if a dynamic drilldown does not fulfill this functionality.
If you copy an applet that uses a business component that references a specialized class, then use the following guidelines:
You must use the copied applet with the original business component, not a copy of the original business component.
To use a copied applet with a copied business component, you must modify the class of the copied applet.
For more information, see Caution About Using Specialized Classes.
Reasons Not to Reuse a Predefined Object
Reusing an object can result in problems.
Copying a Predefined Object Can Cause an Upgrade Problem
Copying an object can cause an upgrade problem that is difficult to debug. Functionality is often added to most of the predefined business components during major releases. This new functionality often depends on new fields, joins, and so on, that Siebel CRM adds to a predefined business component. During the upgrade, Siebel CRM adds these new fields only to the predefined business components that reside in your merged repository.
Copying an object can result in problems following an upgrade. These problems can be difficult to locate and debug. The errors often occur because some C++ code for the business component or applet class attempts to find a field that does not exist in your custom copy of that business component or applet. The only way to debug the problem is to compare your custom business component with the predefined business component, and to add any new fields and other child object definitions that Siebel CRM added in the new release. This work can be complex, requiring detailed knowledge of what Siebel CRM modified in the new release.
Copying a Predefined Object Can Cause Redundancy
Creating a new copy of a business component or applet can result in redundancy in your configuration. For example, if you create a copy of the Account business component and name it My Account, and use this copy on all of the views that reference accounts, then you must define copies of every applet that references accounts, and you must make sure each of these copies references the new My Account business component. It might be necessary for you to create a new business object, screen, and so on.
Copying a Predefined Object Can Increase Complexity
You might make a copy of an object in the belief that doing so will reduce problems during an upgrade. The assumption is that if the business component is named My Account, then the Application Upgrader will leave it alone during the upgrade, resulting in no problems after the upgrade. This assumption is misleading. The problems you might encounter with an upgraded configuration that contains a copied object might be more complex to solve than the problems that reusing a predefined object causes. It is easier to examine your Siebel application after an upgrade and remove various new controls and list columns from a predefined applet than it is to examine each custom business component and applet to identify the fields, joins, multi-value links, and so on, that you must troubleshoot.
Results of Reusing An Object Inappropriately
Reusing a Siebel module or repository object in a way that does not meet the original purpose of the object can cause the following problems:
Performance might be degraded. Oracle tunes the performance of the component or object for a specific purpose.
Future use of the object might be limited. For example, the Service Request business component stores a service interaction with a customer. If you modify this usage, you might limit your ability to use this business component for the original purpose in a future release.
Large amounts of customization might be required to make the improper use of an object work correctly. For example, if you reuse a table for an alternative purpose, then you must configure Siebel CRM so that it updates all required columns and adds a search specification to the business component. If you use a predefined business component for a purpose other than the original design intent, then specialized class behavior might exist that affects your ability to properly use the business component. It might be necessary for you to perform more customization to make the business component work so that it meets your requirements. For more information, see Options to Filter Data That Siebel CRM Displays in an Applet and Caution About Using Specialized Classes.
The intended purpose of the reused object might not be clear to future developers. For example, if you use the S_SRV_REQ table to store financial transactions, then this configuration is not clear to future developers because the table bears no relationship to financial transactions.
Upgradability might be decreased. Troubleshooting and reconfiguration might be required after an upgrade because the upgrade might revert an object to the original form. Modifications that Siebel CRM makes to objects during a repository upgrade depends on Siebel CRM using objects for their original purpose. An upgrade might include any of the following modifications:
Modify the table schema by adding or modifying unique indexes or required columns.
Modify the behavior of specialized classes.
Modify functionality. For example, access control, visibility, and so on.
Modify the party model.
Objects that Siebel CRM does not include in your licensed configuration might be included in your deployment.
Process of Determining Whether You Can Reuse a Predefined Object
This task is a step in Roadmap for Configuring a Siebel Application.
To determine whether you can or cannot reuse a predefined object, do the following tasks:
(Conditional) Determining Whether You Can Reuse a Predefined Table Column
(Conditional) Determining Whether You Can Reuse a Predefined Business Component Field
(Conditional) Determining Whether You Can Reuse a Predefined Business Component
It is recommended that you use the predefined objects, but there might be situations when it is difficult to determine to reuse a predefined object or to create a new object. This situation occurs if predefined objects cannot meet your requirements. You must determine the functional and technical fit of the proposed use. If the fit is appropriate, then you can reuse the object. If it is not appropriate, then you must create a new object. You must not reuse an object merely because another Siebel application does not already use it.
If no predefined object is suitable, then you must consider configuring the data objects layer. For more information, see Options to Configure the Data Objects Layer.
To determine whether an object is a functional fit to your business requirement, you can examine the table or business component that you intend to use.
Determining Functional Fit for Reusing a Predefined Object
This task is a step in Process of Determining Whether You Can Reuse a Predefined Object.
To determine functional fit for reusing a predefined object
Determine whether you must reuse the object rather than copy the object.
For more information, see Reasons to Reuse or Not Reuse a Predefined Object.
Determine whether you must copy the object rather than reuse the object.
For more information, see Guidelines for Reusing a Predefined Object.
Make sure the original nature and purpose of the Siebel object is compatible with your proposed use.
For example, storing customer complaints is compatible with the Service Request business component, but not for storing financial transactions.
Make sure relationships to other objects are compatible with your requirements.
The fact that an object contains the correct relationships is not sufficient for reuse. For example, you must not use the S_EVT_ACT table as an intersection table only because it contains two of the foreign keys that you require. Doing so can cause Siebel CRM to overload the table and degrade performance.
Determine whether the visibility properties of the object are or are not compatible with your requirements.
If the object is not a good functional fit, then reusing the object for that purpose might be inappropriate. The following are examples of improper use:
Using the S_PARTY table to store a nonparty entity.
Using an unused table for a custom business component if the table does not possess a relationship to the intended usage of the business component.
Using an unused table column or business component field that does not possess a relationship to the intended usage of the field.
Determining Technical Fit for Reusing a Predefined Object
This task is a step in Process of Determining Whether You Can Reuse a Predefined Object.
To determine technical fit for reusing a predefined object
Examine the following technical factors:
Performance factors
Size and type of columns and fields
Examine the following table schema factors:
Determine whether you must set columns to a default value.
Determine whether you must configure Siebel CRM to update the user key and unique index columns.
If you must perform a large amount of customization to use an unused table, then technical fit diminishes.
Determine the affect that the foreign key relationships have on Siebel Remote.
Foreign key relationships and Siebel Remote are closely interrelated. Simply using the correct foreign key might not make sure that Siebel CRM downloads the data to the Remote client. You must determine how reuse affects the dock objects and the rules that interact with the foreign keys. For more information, see Configuring Dock Objects for Siebel Remote
Determine the affects that foreign key relationships have on visibility.
Many columns that are not foreign keys can affect visibility. For example, S_PROD_INT.ENTERPRISE_FLG with a value of Y provides partial docking visibility to the product record. Misusing these columns can result in a significant negative affect on Siebel Remote.
Determining Whether You Can Reuse a Predefined Table Column
This task is a step in Process of Determining Whether You Can Reuse a Predefined Object.
Reusing a predefined table column if a good technical or functional fit does not exist can lead to a poor result. In this situation, it is better to create a new, custom field or column. For more information, see Options to Configure the Data Objects Layer.
To determine whether you can reuse a predefined table column
Consider the table columns that Siebel Remote uses:
Do not use a field or column that controls Siebel Remote behavior.
Siebel Remote uses the ENTERPRISE_FLG column to implement visibility on records that use normal visibility constraints. It might use other columns to control download behavior, such as the RTE_CONTACTS_FLG or RTE_PRSP_CONS_FLG column on the S_SRC table. For more information, see Configuring Dock Objects for Siebel Remote
- Click the Flat tab in Siebel Tools, and then submit one of the following queries to determine whether a dock object visibility rule uses a particular column:
Query the SQL Statement and DBX SQL Statement properties of the Dock Object Visibility Rule object for the column you are considering.
Query the Filter Sql Statement property of the Dock Object Table object for the column you are considering.
Note that you must display the object type known as the Dock Object and the children of this object type. For more information, see Displaying Object Types You Use to Configure Siebel CRM.
If you are in doubt about how a column might affect Siebel Remote, then see Getting Help From Oracle. For more information, see Siebel Remote and Replication Manager Administration Guide.
To reuse a table column or business component field that references a LOV (list of values) bounded column, make sure you use a bounded list that uses the same LOV type as the column object.
If the LOV Bounded property of the column is TRUE, then Enterprise Integration Manager enters data into the column only if the corresponding LOV type and value exist in the S_LST_OF_VAL table. For more information, see Creating a List of Values.
Consider the column type and size.
In most situations, you must not modify the type or size of the column. An exception is IBM DB2 for z/OS operating systems, which store the maximum size of a VARCHAR column in an index. For more information, see Implementing Siebel Business Applications on DB2 for z/OS.
Make sure a column you use is not obsolete.
Examine the Comments property of the column to determine whether the column is obsolete. You must not use an obsolete column because Siebel CRM might delete it in a future release.
Examine the Foreign Key Table property of the Column object to determine whether the correct foreign key relationship exists:
If a field on the business component already uses the key, then reuse that field rather than creating a new field. The original purpose of the unused foreign key field or column must match your intended use.
Do not use a foreign key column that does not contain the correct foreign key relationships.
For more information, see Guidelines for Considering a Foreign Key Relationship.
Use a one-to-one ATTRIB column.
If no other suitable field or column exists, then some one-to-one tables contain generic ATTRIB columns that you can use. For example, the S_CONTACT_X table. If you use an ATTRIB column, make sure you do the following:
- Extend a base table with a custom extension column instead of using an ATTRIB column in the following situations:
For foreign keys and the Primary ID Field. For more information, see About the Primary ID Field.
For a column that Siebel CRM frequently queries or is always present in the result set. For example, a field that is in the initial list view of a screen, or a field whose Force Active or Link Specification property is TRUE.
- If you reuse a predefined ATTRIB column, then make sure another field does not use it. If another field does use it, then choose another unused ATTRIB column.
For more information, see Options to Use a Predefined One-to-One Extension Table.
- Extend a base table with a custom extension column instead of using an ATTRIB column in the following situations:
Reuse an unused column for a new business component field.
You must verify that another field on the same business component does not already use the column. If more than one field references the same table column, then you might encounter a duplicate column insert error during a copy operation. In this situation, you must use the original Siebel field that references the column. Otherwise, use another appropriate column, such as a custom extension column or an unused ATTRIB column.
Use a user key column.
Note the following:
Do not use a column that is part of the user key of a table for any other purpose than how Siebel CRM intends to use this column. Doing so might result in degraded performance. For more information, see Siebel Performance Tuning Guide.
Do not enter data into a nonforeign key value or map the foreign key to a different table as a way to map a user key column that is a foreign key to a table. Enterprise Integration Manager (EIM) uses the user key to identify a unique record. Inappropriately entering data into a user key column that references a foreign key might prevent Enterprise Integration Manager from working correctly.
For more information, see How a User Key Creates a Unique Set of Values.
Guidelines for Considering a Foreign Key Relationship
You must not reuse a table only because it contains the necessary foreign key relationship. Instead, to add the required foreign key columns, you can do one of the following:
Configure the database.
Use the Siebel Dock Object Wizard.
Use the EIM Table Mapping Wizard.
Do not use a predefined column that is not a foreign key to store a custom foreign key. Doing so can affect Siebel Remote and Enterprise Integration Manager. This situation can cause problems when Siebel CRM creates EIM mappings or routes data to the user.
Determining Whether You Can Reuse a Predefined Business Component Field
This task is a step in Process of Determining Whether You Can Reuse a Predefined Object.
This topic describes the factors you must evaluate when you consider reusing a predefined business component field. Reusing a field if a good technical or functional fit does not exist can lead to a poor result. In this situation, it is better to create a new, custom field. For more information, see Process of Determining Whether You Can Reuse a Predefined Object.
To determine whether you can reuse a predefined business component field
Examine the Primary ID Field.
In some situations, you can configure the Primary ID Field for a multi-value link to improve performance. For more information, see About the Primary ID Field.
For a custom multi-value link, you must attempt to reuse an unused column or the Primary ID Field before you create a new custom extension column:
Make sure the Foreign Key Table property of the unused column references the table of the business component of the multi-value link.
Make sure the Primary Child Col property is TRUE.
Make sure the Primary Child Table, Primary Child Join Column, and Primary Join Column Name properties are set with an appropriate value.
For a many-to-many relationship, the Primary Inter Table Name must reference the intersection table. You cannot set these values for a base table column that is predefined. You must make sure that the unused field or column is the appropriate Primary ID Field.
If you cannot locate an appropriate unused primary field or column, then you must verify that another multi-value link does not already use it.
For more information, see Sharing a Primary for a Multi-Value Link.
If you cannot find a suitable unused Primary ID Field or column, then you must extend the base table and create a custom field.
Note that the EIM Table Mapping Wizard does not create an EIM explicit primary mapping object for a custom Primary ID Field. For more information, see Defining the Primary ID Field of a Multi-Value Link.
Make sure the field you use is not inactive.
Do not reactivate a field that is currently inactive in a predefined Siebel application for the following reasons:
The field might be obsolete. Siebel CRM might delete it in a future release.
The field might be part of future functionality that Siebel CRM has not yet implemented.
Make sure a specialized business component does not reference the field.
You can use a field on a specialized business component only for the purpose that Siebel CRM intends to use this field. An unintended use of this field might affect specialized behavior. For more information, see Caution About Using Specialized Classes.
Use a user key field.
For more information, see Determining Whether You Can Reuse a Predefined Table Column.
Examples of Reusing a Business Component Fieldor Table Column
The following are examples of how you might reuse a business component field or a table column:
Use the Last Name or First Name field of the Contact business component to store the name of a contact.
On the Account business component, instead of creating a custom extension column for a new field to store an email address, use the EMAIL_ADDR column of the S_ORG_EXT table.
On the Order Entry business component, use the Revision field to store the revision number. Specialized behavior controls this field. For more information, see Caution About Using Specialized Classes.
On the Campaign business component, use the Route Prospects field to store information that describes the campaign contacts that Siebel CRM routes to the Remote client. If you store other information, then Siebel Remote performance might be compromised.
Use the WEIGHT column on the S_CONTACT table to store the weight of the contact. Do not use it to store information that is not related to the weight of the contact.
The Comment property of a column often describes the intended purpose of the column. Use comments to help you decide when to reuse a column.
Sharing a Primary for a Multi-Value Link
It is recommended that you do not share a primary for a multi-value link that returns different result sets because it can corrupt the primary. For example, assume two multi-value links reference business components that reference the same table but use different search specifications. Sharing the Primary ID Field for the two multi-value links causes Siebel CRM to set the Primary ID Field to the value of No Match Row Id because the value of the Primary ID Field might reference a record that one of the multi-value links does not return. For more information, see Options to Filter Data That Siebel CRM Displays in an Applet.
Determining Whether You Can Reuse a Predefined Business Component
Where possible, it is recommended that you reuse a business component in the predefined repository. You must only reuse a business component that provides a valid functional and technical fit with your requirements. If no suitable predefined business component exists, then it might be necessary to create a new one. It might be necessary to configure the database to create a new table.
To determine whether you can reuse a predefined business component
Make sure the business component does not use a specialized class.
Instead of using a specialized business component, create a new business component. If you use a business component that references a specialized class for a purpose other than how Siebel CRM intends to use it, then the class code might create problems that are difficult to debug. For example, if you use the eEvents Parent Event business component to store data that is not related to events management, then the specialized code might result in the creation of an undesirable subevent. For more information, see Guidelines for Creating a Business Component That References a Specialized Class and Caution About Using Specialized Classes.
Make sure the business component does not reference the S_PARTY table.
You must never use a business component that references the S_PARTY table for a purpose other than how Siebel CRM intends to use the business component. A business component that references the S_PARTY table influences other areas, such as access control and Remote visibility.
Make sure the business component is licensed.
You cannot use a predefined business component that Siebel CRM does not license for your configuration.
Make sure the business component is not a repository business component.
Never configure a repository business component. The name of a repository business component begins with Repository.