2Integration Objects
Integration Objects
This chapter describes the structure of Siebel integration objects. It describes the Integration Object Builder wizard, which assists you in building your own integration objects based on Siebel objects.
The chapter consists of the following topics:
About Integration Object Terminology
This chapter describes concepts that are often referred to using inconsistent terminology on different systems. The following table has been included to clarify the information in this chapter by providing a standard terminology for these concepts.
Table Integration Object Terminology
| Term | Description |
|---|---|
Component |
A constituent part of any generic object. |
Field |
A generic reference to a data structure that can contain one data element. |
Integration message |
A bundle of data consisting of two major parts:
|
Integration object |
An integration object of any type, including the Siebel integration object, the SAP BAPI integration object, and the SAP IDOC integration objects. |
Integration object instance |
Actual data, usually the result of a query or other operation, which is passed from one business service to another, that is structurally modeled on a Siebel integration object. |
Metadata |
Data that describes data. For example, the term data type describes data elements such as char, int, Boolean, time, date, and float. |
Siebel business component |
A Siebel object type that defines a logical representation of columns in one or more database tables. A business component collects columns from the business component’s base table, its extension tables, and its joined tables into a single structure. Business components provide a layer of abstraction over tables. Applets in Siebel Business Applications reference business components; they do not directly reference the underlying tables. |
Siebel business object |
A Siebel object type that creates a logical business model using links to tie together a set of interrelated business components. The links provide the one-to-many relationships that govern how the business components interrelate in this business object. |
Siebel integration object |
An object stored in the Siebel repository that represents a Siebel business object. |
Siebel integration component |
A constituent part of a Siebel integration object that represents a Siebel business component. |
Siebel integration component field |
A data structure that can contain one data element in a Siebel integration component. Represents a Siebel business component field. |
About Integration Objects
Siebel integration objects allow you to represent integration metadata for Siebel business objects, XML, and other external data structures as common structures that the Enterprise Application Integration (EAI) infrastructure can understand. Because these integration objects adhere to a set of structural conventions, they can be traversed and transformed programmatically, using Siebel eScript objects, methods, and functions, or transformed declaratively using Siebel Data Mapper.
The typical integration project involves transporting data from one application to another. For example, if you want to synchronize data from a back-office system with the data in your Siebel application. You might want to generate a quote in the Siebel application and perform a query against your Enterprise Resource Planning (ERP) system transparently. In the context of Siebel EAI, data is transported in the form of an integration message. A message, in this context, typically consists of header data that identifies the message type and structure, and a body that contains one or more instances of data-for example, orders, accounts, or employee records.
When planning your integration project, consider several issues:
How much data transformation does your message require?
At what point in the process do you perform the data transformation?
Is a confirmation message response to the sender required?
Are there data items in the originating data source that will not be replicated in the receiving data source, or that will replace existing data in the receiving data source?
This guide can help you understand how Siebel EAI represents the Siebel business object structure. It also provides descriptions of how Siebel EAI represents external SAP R/3 structures.
About Integration Object Base Object Types
Each integration object created in Siebel Tools has to be based on one of the base object types presented in the following table. This property is used by adapters to determine whether the object is a valid object for them to process.
Table Integration Object Base Object Types
| Base Object Type | Description |
|---|---|
None |
For internal use only. |
SQL |
Used for manually creating integration objects. Only the EAI SQL Adapter accepts integration objects of this type. |
SQL Database Wizard |
Used by the Database Wizard for the integration object it creates. Only the EAI SQL Adapter accepts integration objects of this type. |
SQL Oracle Wizard |
Used by the Oracle Wizard for the integration object it creates. Only the EAI SQL Adapter accepts integration objects of this type. |
Siebel Business Object |
Used by the Integration Object Builder wizard for the integration object it creates. The EAI Siebel Adapter accepts only the integration object of this type. |
Table |
Obsolete. |
XML |
Used to represent external XML Schema such as DTD or XSD. For information on DTD and XSD, see XML Reference: Siebel Enterprise Application Integration. |
About the Difference Between Integration Objects and Integration Object Instances
Understanding the difference between integration objects and integration object instances is important, especially in regard to the way they are discussed in this chapter.
An integration object, in the context of Siebel EAI, is metadata; that is, it is a generalized representation or model of a particular set of data. It is a schema of a particular entity.
An integration object instance is also referred to as a Siebel Message object.
An integration object instance is actual data organized in the format or structure of the integration object. The following figure illustrates a simple example of an integration object and an integration object instance, using partial data.
Any discussion of integration objects in this book will include clarifying terms to help make the distinction, for example, metadata or Siebel instance.
About Integration Object Wizards
Within Siebel Tools, there are multiple wizards associated with integration objects:
One that creates integration objects for internal use by the Siebel application
Others that create integration objects for external systems based on Siebel objects
the following figure shows the logic of the Integration Object Builder and Generate XML Schema wizards. The Code Generator wizard (not shown) works in the same manner as the Generate XML Schema wizard, but it generates Java classes.
The following are the integration object wizards:
Integration Object Builder wizard. This wizard lets you create a new object. It supplies the functionality for creating integration objects from Siebel business objects or integration objects, based on the representations of external business objects using XML Schema Definition (XSD) or Document Type Definition (DTD). Access this wizard from the New Object Wizards dialog box in Siebel Tools. After selecting the EAI tab, double-click Integration Object to start the Integration Object Builder wizard.
Generate XML Schema wizard. This wizard lets you choose an integration object and output XML schema in XML Schema Definition (XSD) standard, Document Type Definition (DTD), or Microsoft’s XDR (XML Data Reduced) format. In the Integration Objects list in Siebel Tools, select an integration object. Then click Generate Schema to start the Generate XML Schema wizard.
Code Generator wizard. The third wizard lets you create a set of Java class files based on any available integration object or Siebel business service. In the Integration Objects list in Siebel Tools, select an integration object. Then click Generate Code to start the Code Generator wizard.
About the Structure of Integration Objects
The Siebel integration object provides a hierarchical structure that represents a complex data type. Most specifically, prebuilt EAI integration objects describe the structure of Siebel business objects, SAP IDOCs, SAP BAPIs, XML, and external data. Most integration projects require the use of an integration object that describes Siebel business objects, either in an outbound direction such as a query operation against a Siebel integration object, or in an inbound direction such as a synchronize operation against a Siebel integration object.
Creating and Maintaining Integration Objects describes how to create integration objects. The initial process of using the Integration Object Builder wizard is essentially the same for every integration object type currently supported.
Siebel business objects conform to a particular structure in memory, although it is generally not necessary to consider this structure when working with Siebel Business Applications. However, when you are planning and designing an integration project, it is helpful to understand how a Siebel EAI integration object represents that internal structure.
An integration object consists of one Parent Integration Component, sometimes referred to as the root component, or the primary integration component. The Parent Integration Component corresponds to the primary business component of the business object you chose as the model for your integration object.
For example, assume you chose the Account business object (on the first panel of the Integration Object Builder wizard) to base your integration object myAccount_01 on. The Account business object in Siebel Tools has an Account business component as its primary business component. In the myAccount_01 integration object, every child component will be represented as either a direct or indirect child of the primary business component named Account.
Each child component can have one or more child components. In Siebel Tools, if you look at the integration components for an integration object you have created, then you see that each component can have one or more fields. The following figure illustrates a partial view of a Siebel integration object based on the Account business object, with the Business Address component and the Contact component activated.
The following figure represents part of the structure of the Account integration object. The Account parent integration component can have both fields and child integration components. Each integration component can also have child integration components and fields. A structure of this sort represents the metadata of an Account integration object. You can choose to inactivate components and fields. By inactivating components and fields, you can define the structure of the integration object instances entering or leaving the system.
The following topics are also discussed:
About the Cardinality of Child Integration Components
By default each child integration component created in Siebel Tools is assigned a cardinality value of Zero or More. The values Zero or More, or Zero or One, mean that the corresponding integration component is optional. Setting the value to One, or One or More, means at least one integration component instance must be included in the hierarchy. When the cardinality value is set to One, you must have one and only one instance of the integration component in the hierarchy. The following table information lists possible cardinality values.
Table Cardinality values of Child Integration Components
| Cardinality | Integration Component Instance |
|---|---|
One |
An integration component is mandatory and limited to one instance. |
One or more |
An integration component is mandatory and must contain at least one instance. |
Zero or more |
An integration component is optional, and more than one instance is allowed. |
Zero or one |
An integration component is optional, but if there is one present, then the limit is one. |
Custom Integration Component Fields
In some cases, you might want to pass custom attributes that are not necessarily part of the actual data but related to the context of the data. You can use various means such as SOAP headers and transport headers to pass such custom fields, or you can have them as part of the integration schema as custom integration component fields.
Custom attributes can be added manually to integration objects as integration component fields. The integration component field type (Type property in the Object List Editor, Field Type in the Properties window) of custom attributes must be set to Custom. XML style can be chosen as Attribute or Element, appearing in the schema as XML attributes and XML elements, respectively.
The new custom attributes will appear in the schema generated from the integration object, like any other integration component field.
Integration Components and Associations
Siebel business objects are made up of business components that are connected by a link. An association is a business component that represents the intersection table that contains these links. The integration component definition of associations is similar to that of multivalue groups (MVGs). User properties Association and MVGAssociation on the integration component denote that the corresponding business component is an associated business component or an associated MVG, respectively. For fields that are defined on MVG associations, External Name denotes the name of the business component field as it appears on the parent business component, and the user property AssocFieldName denotes the name of the business component field as it appears on the MVG business component.
For example, the Contact business object is partly made up of the Contact and Opportunity business components. The association between these two business components is represented by the Contact/Opportunity link with a value or a table name in the Inter Table column. The Integration Object Builder wizard creates a new integration component for the integration object, based on the Contact business object that represents the association. As shown in the following figure, the Opportunity integration component has one user property defined: Association, set to a value of Y.
Multivalue Groups Within Business Components
Multivalue groups (MVGs) are used within Siebel business components to represent database multivalue attributes. MVGs can be one of two types: regular MVGs or MVG Associations.
An integration object instance most often has multiple integration component instances. For example, an Account can have multiple Business Addresses but only one of these addresses is marked as the primary address. A business requirement might require that only the integration component instance that corresponds to the primary MVG be part of the integration object instance. In relation to Account and Business Addresses this means that only the primary address will be part of the Account integration object instance. The primary address can be obtained by one of the following steps:
Creating a new MVG on the Account business component that uses a link with a search specification only returning the primary address record.
Exposing the primary address information on the Account business component level using a join that has the primary ID as source field. Note that in this case the primary address information corresponds to fields on the Account integration component instance and not the fields on a separate Address component instance.
In Siebel Tools, if a Siebel business component contains an MVG, then the MVG is represented by several objects as illustrated in the following topics.
Multivalue Fields in a Business Component
For example, as illustrated in the following figure, the Account business component contains a multivalue field, Address Id. The multivalue link property of Address Id has the value Business Address.
Multivalue Links in a Business Component
The Business Address multivalue link associated with the Address Id multivalue field in the previous figure has the value Business Address as its Destination Business Component, as shown in the following figure.
Fields in a Business Component After Adding a Multivalue Link
The fact that the Business Address multivalue link has Business Address as its Destination Business Component means that there is another business component named Business Address. The Business Address business component contains the fields that are collectively represented by Address Id in the Account business component, as shown in the following figure.
Graphical Representation of a Business Component and a Multivalue Link
The following figure shows a graphical way to represent the relationship between Account business component and the Business Address multivalue link.
The more table-like representation in the following figure shows how the Business Address multivalue link connects the two business components. The child points to the Business Address business component, which contains the multiple fields that make up the MVG.
Creating a Siebel Integration Component to Represent an MVG
To create a Siebel integration component to represent an MVG, it is necessary also to create two integration components:
The first integration component represents the parent business component. In the example, this is the Account business component. This integration component contains only the fields that are defined in the parent business component, but which are not based on MVGs. The Multivalue Link property and the Multivalue property are empty for these fields.
The second integration component represents the MVG business component. In the example, this is the Business Address business component. The second integration component has one integration field for each field based on the given MVG in the parent business component. An integration component user property will be set on this integration component to tell the EAI Siebel Adapter that it is based on an MVG business component. If the MVG is a regular MVG, then the user property is named MVG. If the MVG is an Association MVG, then the user property is named MVGAssociation. In both cases, the value of the user property is Y.
The following figure shows an integration component based on an MVG and its user property value in Siebel Tools.
The EAI Siebel Adapter business service must know the names of the MVG fields as they are defined in the parent business component, which in this example is Account, and also the names of the MVG fields as they are known in the business component that represents the MVG, which in this example is Account Business Address. As shown in the following figure, the integration component fields represent the MVG.
To represent both names, each field is assigned an integration component field user property named MVGFieldName, or AssocFieldName if the integration component user property is MVGAssociation. The value of the integration component field user property is the name of the field shown in the parent business component, which in this example is Business Address.
Setting Primaries Through Multivalue Links
Primaries are set through multivalue links. However, do not use multivalue links for modifying the linked component. To modify the linked component, use links. If you must set primaries in addition to modifying the linked component, then use an MVG or MVGAssociation integration component user property set to Y, and an MVGLink integration component user property whose value is the child business component. For example, the Account_Business Address integration component of the Account IO integration object has the integration component user properties MVG (whose value is Y) and MVGLink (whose value is Business Address).
Validation of Integration Component Fields and Picklists
If an integration component field is created for a Siebel business component field, and the business component field is based on a picklist, then the EAI Siebel Adapter or the Object Manager validates the field. To have the validation done using the EAI Siebel Adapter, the integration component field has a user property with the name PICKLIST and a value of Y; otherwise, validation is done by the Object Manager.
If the EAI Siebel Adapter validates the integration component field, and if the pickmap for the picklist contains more than one field, then, when designing the integration object, you must decide the following:
Which of the fields to use as a search criterion
Which fields to simply update if input values are different from those in the picklist (provided that the picklist allows updates)
Do not use the PICKLIST property on custom integration component fields. It is designed for static picklists, based on longer columns of the S_LST_OF_VAL table. Any input value provided in the input integration component field for search in picklist fields based on columns such as DESC_TEXT (Description field of the Picklist Generic business component) or NAME (Name field of the Picklist Generic business component) will deliver no result or an incorrect result because the string in the search expression will be truncated to 30 characters.
Example of an Integration Object Based on the Order Entry Business Object
An example is an integration object based on Order Entry business object. The root component of the Order Entry business object is Order Entry - Orders with a field Account, whose pickmap contains a large number of fields such as Account, Account Location, Account Integration Id, Currency Code, Price List, and so on. One of the tasks the integration object designer must perform is to determine which of these fields is used to identify the account for an order.
If the PicklistUserKeys user property on the integration component field that is mapped to the field with the picklist (in the previous example, Account) is not defined, then any integration component fields that are mapped to columns in the U1 index of business component's base table, and are present in the pickmap will be used by the EAI Siebel Adapter to find the matching record in the picklist (in the previous example, Account and Account Location).
In cases where the default user key for the picklist does not satisfy your business requirements (for example, you want to use only Account Integration Id instead of the default user key to pick an Account), or you want to make the user key explicit for performance reasons, then use the PicklistUserKeys user property.
The value of the PicklistUserKeys user property is a comma separated list of integration component fields that are used to find the matching record in the picklist (for example, 'Account, Account Location' or 'Account Integration Id').
For the EAI Siebel Adapter to use the fields referenced in PicklistUserKeys user property, the fields must be included in the pickmap of the underlying business component field. Note that if the business component field names and integration component field names, listed in the PicklistUserKeys property, are not the same, then the picklist must contain external names of the fields listed in the PicklistUserKeys user property.
If there is a field present in the business component and in the pickmap, and it is stored in the base table, then the EAI Siebel Adapter can use the picklist to populate this field, only if this field is present and active in the integration component. This field must also be present in the input property set, and cannot be empty.
Calculated Fields and Integration Objects
Calculated fields are inactive in an integration object when it is created. They are inactive for the following reasons:
Performing calculations on fields requires extra processing time.
If the calculated field is based on a field that is not included in the integration object, then errors might arise when the calculated field is updated but the field used for the calculation is not.
If your business needs require it, activate the calculated fields in integration objects.
Inner Joins and Integration Components
When inner joins are used, records for which the inner joined field is not set are not returned in any query. By default the wizard inactivates such fields. If your business needs require these fields, activate them.
For example, assume that Account business component has an inner join to the S_PROJ table, with Project Id field being the source field in the join specification, and the Project Name field being based on that join.
If an integration component, with an active Project Name field is mapped to the Account business component, then when this integration component is queried only accounts with Project Id field populated will be considered.
Because Project Id is not a required field in the Account business component, not every account in the Siebel Database is associated with a project. So, having Project Name active in the integration component limits the scope of the integration component to only accounts associated with a project. This typically is not desirable, so the wizard inactivates the Project Name field in this example.
If the business requirement is to include the Project Name field, but not to limit the integration component’s scope to only accounts with the project, then you can change the join to S_PROJ in the Account business component to an outer join. For information on joins, see Using Siebel Tools.
Defining Field Dependencies
Define dependency between fields by using the user properties of the integration component field. The names of these user properties must start with FieldDependency, and it is recommended that the value of each property contain the name of the field on which the associated field is dependent. The EAI Siebel Adapter processes fields in the order defined by these dependencies, and generates an error if cyclic dependencies exist.
The EAI Siebel Adapter automatically takes into account the dependencies of the fields set by a PickList on the fields used as constraints in that PickList. For example, if a PickList on field A also sets field B, and is constrained by field C, then this implies dependencies of both A and B on C. As a consequence, the EAI Siebel Adapter sets field C before fields A and B.
Repository Objects
For the EAI Siebel Adapter to deal with repository objects, a user property REPOBJ must be defined on the root integration component. If this property is set to Y, then the EAI Siebel Adapter sets a context on the repository so that the rest of the operations are performed in that context.
About Integration Component User Properties as Operation Controls
Each business component, link, and MVG has properties such as No Update, No Delete, and No Insert. So do integration components, in the form of integration component user properties. These user properties, listed in the following table, indicate the operations that can and cannot be performed on an object.
Table Operation Controls for Integration Components
| User Property | Description |
|---|---|
NoDelete, NoInsert, NoQuery, NoSynchronize, NoUpdate |
Indicate which operations cannot be performed on the corresponding business component. Can take the value Y or N. If any of these user properties are set to Y, then the corresponding business component method is used to validate the operation. When the business component attempts to perform a restricted operation, an error is raised. NoUpdate can also be set on integration component fields. For more information on business component properties, see Configuring Siebel Business Applications. |
IgnorePermissionErrorsOnUpdate, IgnorePermissionErrorsOnInsert, IgnorePermissionErrorsOnDelete |
Suppress the errors that arise from having the NoUpdate, NoInsert, and NoDelete user properties set to Y, respectively. The errors are ignored and processing continues. |
AdminMode |
When set to Y, indicates that the update of the corresponding business component is to be performed in Admin Mode. Admin Mode turns off all insert and update restrictions for the business components used by a view, including those specified by business component user properties. You can set the AdminMode user property on integration objects or integration components. For more information on Admin Mode, see Configuring Siebel Business Applications. |
For the EAI Siebel Adapter to successfully perform an operation, that operation must be allowed at all levels. If the operation is allowed at every level except the field level, then a warning message is logged in the log file and processing continues. Otherwise, an error message is returned, and the transaction is rolled back.
Permissions on integration components are checked by the EAI Siebel Adapter, and permissions on business components, links, and fields are checked by the Object Manager.
About Integration Component Keys
There are multiple types of integration component keys:
User Key. See User Keys.
Status Key. See Status Keys.
Hierarchy Parent Key. See Hierarchy Parent Keys.
Hierarchy Root Key. See Hierarchy Root Keys.
Modification Key. See Configuring the EAI Siebel Adapter Business Service for Concurrency Control.
User Keys
A user key is a group of fields whose values must uniquely identify a Siebel business component record. During inbound integration, user keys are used to determine whether the incoming data updates an existing record or inserts a new one. The Integration Object Builder wizard automatically creates some user keys based on characteristics discussed in User Key Generation Algorithm. Make sure that the generated user keys match your business requirements; otherwise, inactivate them or add new user keys as appropriate.
In Siebel Tools, user keys are defined as Integration Component Key objects, with the Key Type property set to User Key.
Integration component keys are built by the Integration Object Builder wizard, based on values in the underlying table of the business component on which the integration component is based. Integration objects that represent Siebel business objects, and that are used in insert, update, synchronize, or execute operations, must have at least one user key defined for each integration component.
A sequence of integration component user keys is defined on each integration component definition, each of which contains a set of fields. During processing of integration component instance, the EAI Siebel Adapter chooses to use the first user key in the sequence that satisfies the condition that all the fields of that user key are present in an integration component instance. The first instance of each integration component type determines the user key used by all instances of that type.
For example, consider the Account integration object instance with only the Account Name and Account Integration Id fields present. When the EAI Siebel Adapter performs validation, it first checks the Account Name and Account Location fields (the first user key for the Account integration component). In this example, because the Account Location field is missing, the EAI Siebel Adapter moves to the second user key, Account Integration Id. The Account Integration Id field is present in the integration component instance and has a value, so the EAI Siebel Adapter uses that as the user key to match the record. Now if the same instance also had the Account Location field present, but set to null, then the EAI Siebel Adapter would pick the Account Name and Account Location combination as the user key. This is because Account Location is not a required field.
A new user key is picked for each integration object instance (root component instance). However, for the child component instances, the user key is picked based on the first child instance, and then used for matching all instances of that integration component within the parent integration component instance.
For example, if a Siebel Message contains two orders, then the user key for order items is picked twice, once for each order. Each time, the user key is selected based on the first order item record and then used for all the siblings.
User Key Generation Algorithm
The Integration Object Builder wizard computes the user keys by traversing several Siebel objects, including the business object, business component, table, and link. This is because not every table user key meets the requirements to be used as the basis for integration object user keys.
To understand how the Integration Object Builder wizard determines valid integration component keys, you can simulate the process of validating the user keys. For example, you can determine the table on which your business component is based by looking in Siebel Tools.
To find the user keys for a table
Select the Business Component object in the Object Explorer.
The Business Components list appears in the Object List Editor.
Select a business component.
Click the link in the Table column.
The Tables list appears, displaying the table associated with the business component (for example S_CONTACT).
Expand the Tables object in the Object Explorer, and then select User Key.
The User Keys list displays the user keys defined for that table.
For example, as shown in the following figure. the table S_CONTACT has several user keys.
Not every user key will necessarily be valid for a given business component. Multiple business components can map to the same underlying table; therefore, it is possible that a table’s user key is not valid for a particular business component, but is specific to another business component
Each User Key Column child object defined for a given user key must be exposed to the business component in which you are interested. For example, the following figure shows three user key columns for the user key S_CONTACT_U1.
If the columns of the user key are exposed in the business component, and those columns are not foreign keys, then the Integration Object Builder wizard creates an integration component key based on the table’s user key. The Integration Object Builder wizard also defines one integration component key field corresponding to each of the table’s user key columns.
The Integration Object Builder wizard builds the integration component keys based on these table user keys. As illustrated in the following figure, the wizard defines one integration component key for each table user key column.
Each valid integration component key contains fields. For example, as shown in the following figure, for the Contact integration component, User Key 3 is made up of five fields: CSN, First Name, Last Name, Middle Name, and Personal Contact.
When the Integration Object Builder wizard creates these integration component keys, it attempts to use the appropriate table user keys, that is the user keys that help to uniquely identify a given record. In some cases, you might find that certain integration component keys created by the Integration Object Builder wizard are not useful for your particular needs. In that case, you can manually inactivate the keys you do not want to use by checking the Inactive flag on that particular user key in Siebel Tools. You can also inactivate user key fields within a given user key.
Status Keys
It is useful to know the status of your integrations. For example, if you are sending an order request, then you might want to know the ID of the Order created so that you can query on the order in the future. You can set the StatusObject method argument of the EAI Siebel Adapter business service to true to return an integration object instance as a status object.
The status returned is defined in the Integration Component using Status Keys. A Status Key is an Integration Component key of the type Status Key. Fields defined as part of the Status Key are included in the returned StatusObject.
If a Status Key is not defined for the Integration Component then neither the component nor any of its children are included in the returned object:
To include descendants of an Integration Component without including any of its fields in the returned status object, specify an empty Status Key.
To include information about which one of the update, insert, or delete operations was performed during an upsert request or synchronize request, include a field named Operation in the Status Key.
Status Key Examples
For example, the AccountAshish integration object has an Account integration component with an integration component key called StatusKeyAshish, with the integration component key fields AshishName, AshishId, and AshishHomePage (the following figure).
Example with No Status Object
When no StatusObject business service method argument is defined, as in this input XML file for an upsert operation using the EAI Siebel Adapter business service
<?Siebel-Property-Set EscapeNames="true"?> <PropertySet> <SiebelMessage MessageId="42-1PGR" IntObjectName="AccountAshish" MessageType="Integration Object" IntObjectFormat="Siebel Hierarchical"> <ListOfAccountAshish> <Account Main_spcPhone_spcNumber="+33123456789" Primary_spcOrganization="Default Organization" Home_spcPage="mycompany.com" Location="France" Name="Ashish 9 Telecom"/> </ListOfAccountAshish> </SiebelMessage> </PropertySet>
all of the fields in the integration component are returned:
<?Siebel-Property-Set EscapeNames="true"?> <PropertySet ErrorContextIntComp="" ErrorContextSearchSpec="" OMErrorCode="" PrimaryRowId="42-C739Q" OMErrorSymbol="" ErrorCode="0x0" ErrorSymbol=""> <SiebelMessage MessageId="42-1PGR" MessageType="Integration Object" IntObjectName="AccountAshish" IntObjectFormat="Siebel Hierarchical"> <ListOfAccountAshish> <Account Main_spcPhone_spcNumber="+33123456789" Primary_spcOrganization="Default Organization" Home_spcPage="mycompany.com" Location="France" Name="Ashish 9 Telecom"/> </ListOfAccountAshish> </SiebelMessage> </PropertySet>
Example with Status Object
When the StatusObject method argument is set to true, as in this input XML file:
<?Siebel-Property-Set EscapeNames="true"?> <PropertySet StatusObject="true"> <SiebelMessage MessageId="42-1PGR" IntObjectName="AccountAshish" MessageType="Integration Object" IntObjectFormat="Siebel Hierarchical"> <ListOfAccountAshish> <Account Main_spcPhone_spcNumber="+33123456789" Primary_spcOrganization="Default Organization" Home_spcPage="mycompany.com" Location="France" Name="Ashish 9 Telecom"/> </ListOfAccountAshish> </SiebelMessage> </PropertySet>
only the fields in the status key are returned:
<?Siebel-Property-Set EscapeNames="true"?> <PropertySet ErrorContextIntComp="" ErrorContextSearchSpec="" OMErrorCode="" PrimaryRowId="42-C739Q" OMErrorSymbol="" ErrorCode="0x0" ErrorSymbol=""> <SiebelMessage MessageId="42-1PGR" MessageType="Integration Object" IntObjectName="AccountAshish" IntObjectFormat="Siebel Hierarchical"> <ListOfAccountAshish> <Account Id="42-C739Q" Home_spcPage="mycompany.com" Name="Ashish 9 Telecom"/> </ListOfAccountAshish> </SiebelMessage> </PropertySet>
For more information on the EAI Siebel Adapter business service, see EAI Siebel Adapter Business Service.
Hierarchy Parent Keys
The Hierarchy Parent Key is used for integration objects that have a homogeneous hierarchy. This key must have only the Parent Id. The Hierarchy Parent Key is used for maintaining the hierarchy and keeping the data normalized.
For example, when you insert quotes, each quote item in turn can have more quote items. In this case, the first quote item inserted by the EAI Siebel Adapter has the Parent Id set to blank, but for each child quote item, the EAI Siebel Adapter checks the keys to figure out which fields are to be set. If the Hierarchy Parent Key is not defined, then the child quote item is inserted as a new quote item without a link to its parent (denormalized).
Hierarchy Root Keys
The Hierarchy Root Key is an optional key that is useful only when integration objects have a homogeneous hierarchy. You can use this key to improve performance. The Hierarchy Root Key must have only one field, Root Id, which the EAI Siebel Adapter populates with the value of the ID field in the component instance that is in the root of the homogenous hierarchy. For example, assume quote Q1 has quote items A, B, and C where each of the quote items has child quote items (A1, A2, B1, B2, ...). If you want to update the quantity requested for all quote items starting with the root quote item B, then it is faster if the data is denormalized. Using the Hierarchy Root Key, you can search for all records with Root Id equal to the Row Id of B, and set the QuantityRequested field for each item.
About EAI Siebel Adapter Access Control
You can use the following mechanisms to control the access of the EAI Siebel Adapter to the database:
Restricted access to a static set of integration objects. You can configure the EAI Siebel Adapter business service, or any business service that is based on the CSEEAISiebelAdapterService class, to restrict access to a static set of integration objects. To do this, set a business service user property called AllowedIntObjects, which contains a comma-separated list of integration object names that this configuration of the EAI Siebel Adapter can use. This allows you to minimize the number of integration objects your users must expose outside of Siebel Business Applications through HTTP inbound or MQSeries Receiver server components. If this user property is not specified, then the EAI Siebel Adapter uses any integration objects defined in the current Siebel Repository.
ViewMode. You can specify the visibility mode of business components that the EAI Siebel Adapter uses. This mode is specified as the integration object user property ViewMode. This user property can take different values, as defined by LOV type REPOSITORY_BC_VIEWMODE_TYPE.