Integration objects in Siebel add the integration layer to Siebel business objects. They enable a customisable layer that can be used for data operations/mapping before the data reaches the business layer.

Integration objects come in two varieties -

1. External integration objects: these are the most reflection of data structure in external systems. They may be based out of the structure represented by XSD/DTD, from the database, From the structure defined in applications like SAP.

2. Internal integration objects: These represent the structure of data as it is stored in Siebel.

How to create integration objects? #

Just use the Siebel new object wizard to create integration objects.

Click File > New Object. Select “EAI” tab, select “integration object” in the option below and hit OK to see the below dialogue.

For creating external integration objects, Siebel wizards will prompt you to point to the specific database, to the XSD/DTD depending on the option chosen here.

For creating internal integration objects, Siebel will prompt you to choose a business object and select business components relevant to the IO.

Once the integration object is created by the wizard, you are free to customise it further as you see fit.

How do integration objects work? #

In the case of internal integration objects, Integration object/component maps to the business layer. While integration objects mapped to the Siebel business object, integration components map back to the Siebel business components. Although the integration components are contained within the integration object, the relationships are defined by the underlying BCs.

External integration objects map to whatever the data structure they were created upon.

In runtime any instance of the integration object is represented by a Siebel Propertyset. This is a hierarchical presentation of the data structure represented by the integration object. A PS set can have any number of children and properties.

The primary business component of the business object corresponds to the root IC/property set. Any business component having a relationship defined through the link will be represented as child integration components. Attributes of the business component become integration component fields/properties of a property set.

The simplest way to test this and visualise it is by using an OOB integration object to retrieve data in a simple client business service.

// Instantiate empty PS
var psIn= TheApplication().NewPropertySet();
var psOut = TheApplication().NewPropertySet();
var psTemp = TheApplication().NewPropertySet();

// Use OOB IO
psTemp.SetType("ListOfSWIOpportunityIO");
psUpdate.AddChild(psTemp.Copy());

// query criteria defined within IO
psTemp.SetType("Opportunity");
psTemp.SetProperty("Id",psIn.GetProperty("Opportunity Id"));

// Query Siebel
var bsEAI = TheApplication().GetService("EAI Siebel Adapter");
bsEAI.InvokeMethod("Query", psIn, psOut);

// Run this in debug mode, attach output to the actual output of business service, or write to a file to observe the structure

“EAI Siebel Adapter” Is one of the most common business services used to process integration objects. Have a look at that service in Siebel Tools to know all possible operations.

The whole purpose of providing internal and external integration objects is to map the data structure between an external system to Siebel.

A typical workflow representing this entire integration operation is depicted below -

Note that you may or may not have specific operations depending on your own implementation. For example many of the data structure mapping operations are generally pushed out to middleware. That is one of the ways to simplify integration within Siebel and receive/push out data in the Siebel supported format.

Interesting points about Integration Objects #

• Siebel integration objects handle transaction completeness automatically. By default the function on “all or none principle” - either all of the data ( parent/children) are updated, or none of it is. This is invaluable for not only the integration related tasks, but also for many of the operations internal to Siebel
• If you want to learn a whole lot about integration objects and property sets, get yourself tagged to the Siebel Telecom/Media project. Siebel order management and pricing make use a whole lot of IO/property sets.
• Many developers fall into the trap of manipulating Siebel property sets using custom business services. Usually it is far more efficient to do that using Data Transformation Engine(DTE) services. You can either write code in a business service based on a specialised class, or just use the OOB data mapper (see these data maps in Administration - Integration > Data Maps.)
• Although integration objects provide powerful tools to manipulate data structure and values, it is far more faster and architecturally cleaner to put this middleware system
  But developers do end up doing a lot of data manipulations within Siebel - Especially if they stick to the old school thought of not having any business logic in middleware. In this case evaluate if XSL-based transformations help
• Often developers use integration objects for anything related to XML processing. This ease simply a waste of CPU cycles/time if you’re doing XML processing in batch. Evaluate the use of standard ETL tools to read XML, put the data in staging tables, and process through Siebel EIM