Configuring Siebel Business Applications > About Business Components, Fields, Joins, and Links > About Business Components >

Overview of Business Components

A business component provides the foundation for controlling how Siebel CRM chooses, inserts, and updates data in underlying tables. The information that Siebel CRM stores in a business component is typically specific to an area, such as a product, a contact, or an account. This information might or might not depend on other business components. A business component can exist in one or more business objects. It can include a default sort specification or search specification that allows you to display records in the Siebel client in a predetermined sort order and according to a set of selection criteria. Multiple users can instantiate copies of the same business component. Siebel CRM includes the data modifications that one user makes in all instances of the business component. For more information, see Business Component and Options to Filter Data That Siebel CRM Displays in an Applet.

How Business Component Fields Reference Base Table Columns

Siebel CRM gets the main data for a business component from a base table and one or more joined extension tables. For example, the Account business component references the S_PARTY table, but the S_ORG_EXT joined extension table stores most of the data that the Account business component gets.

Siebel CRM assigns a base table to each predefined business component. The base table for a party business component includes the most important columns that provide data to fields that reside in the business component. The Table property of the business component references the base table. A single business component field references a single base table column.

Figure 11 describes an example of how fields in the Contact business component reference columns in the S_CONTACT table.

Figure 11. Example of How Fields in a Business Component Reference Columns in a Base Table

A business component does not always reference all columns that reside in the base table, but typically it does reference most of them. Implied fields in the business component represent system columns in the base table, such as ROW_ID, CREATED_BY, and LAST_UPD_BY. A system column does not require a field object definition in the business component.

For more information, see How an Implicit Join Creates a Relationship Between a Base Table and a Business Component.

A Business Component Can Reference Data from a Joined Table

A business component can reference data from an extension table and a joined table. A party business component is a business component that references the S_PARTY table as the base table. The main data for a party business component comes from a joined table. A join defines the relationship that exists between the business component and the additional table. For more information, see How the S_Party Table Controls Access.

A joined table provides rows on a one-to-one basis to the business component. The foreign key relationship that exists between the joined table and the base table of the business component creates this basis. For every record in the business component that corresponds to a row in the base table, a corresponding row can exist in the joined table. Every record in the base table does not include a record in the joined table.

Figure 12 describes fields in a business component that reference columns in a base table and a joined table.

Figure 12. How Fields in a Business Component Reference Columns in a Base Table and a Joined Table

You Can Reuse a Business Component

Figure 13 describes how you can create a business component once in terms of a logical collection of columns from one or more tables, and then use it in multiple business object contexts. For more information, see About Business Objects.

Figure 13. Example of How You Can Reuse a Business Component