Bookshelf Home | Contents | Index | Search | PDF

Siebel Connector for SAP R/3 > Customizing Integrations > Defining Your Business Interface >

Finding the Appropriate Siebel Business Object

---

Siebel's database interface is based on business objects. A Siebel business object represents a data entity that may contain related data held in many tables. The business object is made up of business components that map to these tables. When you create an interface to the Siebel application, you create Siebel integration objects based on Siebel business objects. These integration objects have components created from the business components within the Siebel business object.

To create the appropriate Siebel integration object, you need to know the business object on which your integration object should be based. If the data you want to interface to in the Siebel Database is visible through specific Siebel views, you can determine the business object associated with those views.

Elements of the Siebel user interface correspond to business objects and business components. Figure 17 shows this relationship between the Siebel UI Layer, Business Object Layer, and Data Object Layer. Table 18 defines these elements. The figure illustrates the three layers: UI Layer, Business Object Layer, and the Data Object Layer. The UI Layer consist of List Columns, Applets, Views, Screens, and Applications. The Business Object Layer consists of Fields, Business Components, and Business Objects. The Data Object Layer consists of Columns and Tables.

Figure 17.  UI, Business Object, and Data Object Layer Relationships

Table 18.  Siebel User Interface Elements Defined

Element	Definition
Application	A collection of screens.
Screen	A collection of related views. Usually all views in a screen map to the same business objects.
View	A collection of applets that appears on screen at the same time. A view maps to one business object.
Applet	Allows access to the data of one business component for viewing, editing and modifying fields in that business component. Consist of multiple list columns or text box controls that display data.
Business objects	Represent the fundamental business entities in the enterprise.
Business Component	Represents a logical grouping of data from one or more tables.

To determine the object definitions behind a view, click on the Help menu and choose About View.

The About View window provides the following information:

View Title (for example: My SAP Accounts)
View Name (for example: My Organization SAP 4x Account Sales Area View)
View Applets (for example: SAP 4x Account Sales Area List Applet and SAP 4x Account Sales Area Entry Applet)
Record Row ID of the current record displayed (for example: 1-OCS6)

Using Siebel Tools and with the help of the Major Object Definitions diagram, you can identify the business object and the business components associated with the view or applets.

To identify a business object

Start Siebel Tools.
Navigate to the View option and query for the desired View.

The business object is one of the parameters in Properties.

To identify a business component

Start Siebel Tools.
Navigate to Applet View and query for the desired Applet.

The business component is one of the parameters in Properties.

Mapping Business Objects

Once you have identified the business objects on the Siebel applications and SAP sides, you need to consider the differences between these objects and how to physically map from one to the other. In particular you should consider:

Is modification to SAP necessary to support data or functionality contained in Siebel applications?
Is modification to Siebel applications necessary to support data or functionality provided by SAP?
Do you have a complete understanding of the business usage of each field in each object?
Can you create a field-by-field mapping document to determine if there are any specific business rules, format specifications, or changes in the definition of fields from one application to another that need to be changed within the Business Service Data Map?
Did you scrutinize key fields that provide unique identifiers for each application in how they are to be mapped?
Do specific rules need to be applied to each application to make sure the data is transferable? Should these rules be enforced procedurally or through specifically written code?
Should one application or the other be designated as the Master for specific types of data objects? Is the creation of the object allowed in only one application with read-only access for the other?
Does administrative information need to be created in either application to support the other?

Bookshelf Home | Contents | Index | Search | PDF