Configuring Siebel eBusiness Applications > Configuring Joins >

Guidelines for Configuring Joins

A join defines a logical relationship between the base table of a business component and another table. The join is a child object of a business component. Fields in a business component reference joins. A join should only be used when the resulting database join will retrieve no records (zero) or only one record. For example, a join is used to retrieve the primary Account for an Opportunity.

When configuring joins, consider the following:

• A business component may have more than one join with the same destination table if you specify an alias for each join using the Alias property. For example, the Action business component may have two joins to the S_CONTACT table, one to retrieve the owner of the person who created the activity, and another to retrieve the contact associated to the activity. In this example, the joins aliases are Owner and Primary Contact respectively.
• It is important that the Alias property of the join be distinct even though the destination table is the same. It is usually not a good practice to use the table name as the Alias name, even though this is common in the standard repository. This is because implicit joins will use the table name as the Alias to make sure that the explicit join name is not used instead. To make sure that no conflict exists, you should always give the join a distinct and custom alias name.
• For joins to nonparty related tables, the only column you can update is the field (in the parent business component) with the foreign key value. You must specify the table to join to and whether it is an outer join. You must also specify the join specification definition with the source field in the parent business component that stores the foreign key value and the destination column in the child table, which is usually ROW_ID.
• For joins to party-related tables, those that are extensions of the S_PARTY table (such as S_CONTACT, S_ORG_EXT, S_USER, or S_POSTN), require that the foreign key value be exposed as the source field. However, unlike joins to nonparty related tables, the destination Column must reference the PAR_ROW_ID column in the joined table.

Typical scenarios for creating new joins are:

• When a join to a particular table does not already exist within the business component definition and there is a foreign key value between the table the business component is based on and the joined table.
• When the foreign key value is stored in a field that is not already defined as a source in an existing join.
• When bringing in party data into a non-party business component, create a new join with the join specification based on PAR_ROW_ID.
• When bringing in party data into a party business component, use the appropriate explicit join.
• When mapping fields in party business components, use the implicit join for the extension table.