Configuring Siebel eBusiness Applications > Configuring Business Components >

Guidelines for Configuring Business Components

Often, during configuration, there is a need for a business component that is similar, but not identical, to an existing business component. In this case, you must choose between creating an entirely new business component based on the existing one or modifying the existing one for reuse. Modifying an existing business component is usually the better solution, because it minimizes the number of business components. This leads to a smaller repository, is easier to maintain, and is easier to upgrade (because it is closer to standard applications).

Always configure your application in a way that lets you reuse business components instead of creating new ones. For example, you can have an implementation where one group of users may create 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 define a new applet and set the No Insert property to TRUE for the applet.

If you must create a new business component, avoid copying business components based on a specialized class, unless you intend to create a true clone of the original business component (with the same functionality), and then apply minimal changes. For example, you may want to create a Locked Service Requests business component that displays only those Service Request records that have been locked using a business component User Property. In this example, you would copy the Service Request business component (defined by the specialized class CSSBCServiceRequest), set up the Lock Field business component User Property, and specify the conditions in which a Service Request should be locked. Next, you would identify a search specification for the business component that will retrieve only those Service Request records with the preceding conditions. The underlying behavior of the new business component remains the same as the original business component. You should avoid copying a specialized business component to reproduce an isolated feature associated with that business component.

• When naming currency code and exchange date fields, call them Currency Code and Exchange Date if they are the only such fields in the business component. If there are multiple instances of similar fields, prefix each with the name of the corresponding Amount column—for example, Revenue Currency Code and Budget Currency Code. The reason for this is that they are referenced by other fields when you specify the Properties Currency Code field and Exchange Date field. Defining the fields this way makes the reference easier to understand.
• The field URL must be named URL and the class of the Business Component must be set to CSSBCBase for the hyperlinking functionality to work correctly.
• Business components used to represent child entities should not have their parent entity in their name—for example, ABC Subsegment instead of ABC Account Subsegment. Similarly, the applets that are based on these child business components should only reflect the name of the business component itself—for example, ABC Subsegment List Applet instead of ABC Account Subsegment List Applet.

  NOTE:  The exception is when you need multiple variations of the same business component or applet. Typically, multiple variations are necessary if a particular entity is displayed as both a top-level applet and a child applet on other views, and the two applets are not the same. In such cases, put the name of the parent entity at the beginning of the child applet name. For example, the ABC Account Contact List Applet is a Contact List that is displayed as the child of an Account. It needs the word Account to distinguish itself from the standard ABC Contact List Applet, which is a different applet.

Related Topics

About Object Reuse

About Reusing Business Components.

About Copying Objects