Bookshelf Home | Contents | Index | Search | PDF

Siebel Tools Reference > Business Objects Layer > Multi-Value Links >

Primary ID Field

---

The Link and Multi Value Link object definitions have a set of properties that you can use to specify to the system how to obtain the record ID of the first record to display of the detail table each time the master record changes. These properties are Primary Id Field, Use Primary Join, and Auto Primary. Together they implement the primary ID field.

The basic concept behind a primary ID is that it is faster for a Siebel application to retrieve one primary record from the MVG business component through a join than retrieve all of them through a sub-query—especially since users can see values from only one child record until they open up the MVG applet. To create a primary field for a one-to-many or many-to-many relationship, complete the following procedure.

To configure a primary field for a 1:M or M:M relationship

1. Create a Primary Id column.
2. Create a field based on that Primary Id column.
3. In a Multi-Value Link, set the Primary Id Field attribute to the new Primary Id field.
4. Set the Use Primary Join attribute to TRUE.

For example, in the Account business component the primary ID field for the Address multi-value group is called Primary Address Id. The Account Address Mvg Applet displays the corresponding multi-value group. The primary record, indicated with a checkmark in the list column labeled Primary, has its row ID stored in the Primary Address Id field in the account record. Each time there is a different account record displayed, the multi-value fields for the Address load the primary Business Address record's values only. It is not necessary to query the Business Address business component for multiple rows. This can be a significant performance enhancement, especially in list applets.

NOTE:  In a multi-value group applet, the list column that displays the check mark (indicating the primary or nonprimary status of each record) obtains its data from a system field called SSA Primary Field. This field does not appear in the Object Explorer or Object List Editor, but may be referenced by a list column for this purpose.

The benefit of using a primary ID, from the system's standpoint, is that it converts a one-to-many relationship into a one-to-one relationship. This allows the row retrieval process to be simplified from a query with subqueries to a simple join query. This substantially improves performance, especially when the user is scrolling through the records of a list applet that displays the master.

The properties of Link or Multi-Value Link object types used to implement a primary ID field are as follows:

• Primary ID Field. This property specifies the name of the field in the master business component that holds the row ID values pointing to primary records in the detail business component.
• Use Primary Join. The Use Primary Join property is a TRUE or FALSE property that turns the Primary Join feature on or off. If TRUE, the primary detail record is obtained for each master record through a join on the primary ID field. If FALSE, the detail table is queried again with each master record change.
• Auto Primary. This property setting determines how row ID values are populated in the primary ID field, based on a system-supplied list column labeled Primary in the multi-value group applet. The user can manually select the primary. Auto Primary determines how, if at all, the primary selection is defaulted. The possible values for Auto Primary are DEFAULT, SELECTED, or NONE as follows:
  • DEFAULT. The first record automatically becomes the primary.
  • SELECTED. The highlighted record becomes the primary when the user views the multi-value group applet and then exits.
  • NONE. The user must manually specify the primary.

    SELECTED only pertains when there are several multi-value links pointing to the same detail business component. This is the case for the Bill To Business Address and Ship To Business Address multi-value links in a standard Siebel Sales application. These multi-value links exist under both the Order and Account business components. In this case, an example of the desired behavior is as follows: if a primary is not set for the Bill To address, then when the Siebel application does a separate query to bring back all addresses associated with the account (or order), it will check to see whether one of the addresses has already been selected as primary for the Ship To address and, if so, it will SELECT (that is, set) that address as the primary for Bill To address as well.

    When the Auto Primary property of a Multi Value Link object has a value of SELECTED, setting read-only properties at the applet level still does not force the SSA Primary Field to be read-only.

    NOTE:  If the destination business component of the Multi-Value Link is read-only, you may receive the following error message, "This operation is not available for a read-only field 'SSA Primary Field'." This is because the Primary ID field is automatically updated through the system field 'SSA Primary Field', which belongs to the destination business component. Additionally, if this business component is read-only, the field is read-only as well and cannot be updated.

Allowing Users to Set Primaries

You can set the MVG Set Primary Restricted: visibility_mvlink_name user property in the business component underlying the MVG applet to allow certain users to set primaries. Setting this user property to FALSE allows the Primary team member to be altered by someone other than the Manager or Siebel Administrator.

If this user property is not set, only Siebel Administrators (in Admin mode) and Managers (in Manager view mode) have the ability to change the Primary team member on opportunities, accounts and contacts.

For more information, see Configuration Guidelines.

Using the Check No Match Property with a Primary Join

When a multi-value link has been configured with a primary join—which is the typical situation—there are circumstances in which the foreign key used by this join to identify the primary record is unable to find the primary. For example, this can happen when the primary record has been deleted from the multi-value group or the multi-value group is newly created and has no records. In such cases, the multi-value link can be configured to update the primary foreign key to a value of NULL, or to a special value of NoMatchRowId, depending on your requirements. This behavior is configured through the Check No Match property of the Multi Value Link object type, and has performance consequences.

The purpose of the special "NoMatchRowId" value is to prevent secondary queries on foreign key values that are known to have failed, thereby improving performance, much in the same way that using a primary join improves performance.

The NoMatchRowId generating and testing behavior is activated by setting Check No Match to FALSE for the MVL. This setting has the following results:

• When the application encounters a master record where the primary foreign key is NULL or invalid, it performs a secondary query to determine if there are detail records in the multi-value group. If it finds there are no detail records, it sets the primary ID field to the special value NoMatchRowId.
• When the application encounters a master record where the primary foreign key has the value "NoMatchRowId," this indicates to the system that there are no detail records in the multi-value group and the secondary query is not performed.

If you set Check No Match to TRUE, the Siebel application will perform a secondary query whenever the outer join on the primary fails, or is set to NULL or NoMatchRowId. If the secondary query finds a matching detail record, it updates the foreign key with that record's row ID, provided the MVL has an Auto Primary property setting of DEFAULT. If no matching child record is found, or Auto Primary is set to NONE, the application leaves the existing value intact.

A Check No Match setting of TRUE can have serious negative performance consequences. If a multi-value group is sparsely populated (that is, most master records do not have any detail records in the multi-value group) and has Check No Match set to TRUE, it will be almost as slow as not having a primary join at all.

Check No Match should be set to FALSE for most multi-value links because of the performance consequences. It should only be set to TRUE if the multi-value group could possibly have records added to it without going through the MVG itself. For example, account addresses might actually be inserted by means of the Business Address multi-value group on the Contact business component instead of the Address multi-value group on the Account business component. Also, if records can be added to the detail business component through EIM, the TRUE setting is the appropriate one.

The Use Primary Join property should be set to TRUE if CheckNoMatch is TRUE. If CheckNoMatch is set to TRUE and Use Primary Join is FALSE, then the Siebel application will always do the secondary query to find the child records.

Bookshelf Home | Contents | Index | Search | PDF