|Bookshelf Home | Contents | Index | PDF|
The information stored in a business component is usually specific to a particular functional area, such as a product, a contact, or an account. This information may or may not depend on other business components. Business components can be included in one or more business object definitions. They can have default sort or search specifications that allow you to expose records in the user interface in a predetermined sort order and according to a set of selection criteria. Multiple users can instantiate copies of the same business component. Data changes made by any one user are reflected in all instances of the business component.
The main data for a business component comes from a base table and one or more joined extension tables. For example, the Account business component is based on the S_PARTY table, but most of the data retrieved by the business component is stored in the joined extension table, S_ORG_EXT.
Every business component, except virtual business components, has a base table assigned to it. For non-party business components the base table provides the most important columns for use as fields in the business component. The base table is assigned to the business component with the Table property in the Business Component's object definition. Fields in the business component map to columns in the base table.
Figure 28 shows an example of fields in the Contact business component that map to corresponding columns from the business component's base table, S_CONTACT.
NOTE: Business components do not need to include all of the columns in the base table, although typically it will include most of them. In particular, system columns in the base table such as ROW_ID, CREATED_BY and LAST_UPD_BY are automatically represented in the business component through implied fields. System columns do not require field object definitions in the business component.
In addition to including data from base tables, business components can also include data from extension tables and joined tables. For party-based business components, the main data for the business components comes from a joined table. The relationship between the business component and the additional table is defined using a join.
A joined table provides rows on a one-to-one basis to the business component as a result of a foreign key relationship between the joined table and the business component's base table. That is, for every record in the business component (which corresponds to a row in the base table) there can be a corresponding row in the joined table. However, not every record in the base table will have a record in the joined table.
Figure 29 shows fields in a business component mapping to columns in a base table and a joined table.
Business components can be defined once in terms of a logical collection of columns from one or more tables, and then used in many different business object contexts, as shown in Figure 30.
|Configuring Siebel eBusiness Applications|