EAI Queue for Error Handling
The EAI Queue provides temporary storage for data in transit between Siebel Business applications and external applications and a means by which to monitor the data exchange. This temporary storage of data can facilitate error recovery in the event that the flow of data to or from Siebel is interrupted. Error Handling mechanism can be configured to push and pop messages from the EAI Queue based on an OOB Business Service “EAI XML Queuing Service”.Each entry in the EAI Queue may contain the following information:
■ XML file containing the data object in transit
■ Processing status of data object
■ Reference ID for data object in external application
■ Additional fields to be used for error information and other external application specific
information.
A business service API is also provided to the EAI Queue. This business service contains methods to update information held in the queue and allows other components in the Siebel application, as well as customers, to develop software to use the queue. The business service contains the following methods:
■ AddMessage. Adds an XML data object to the queue.
■ GetMessage. Retrieves an XML data object from the queue.
■ GetStatus. Retrieves processing status of the data object.
■ UpdateStatus. Updates the processing status of the data object.
■ DeleteMessage. Removes an XML data object from the queue.
Steps to Configure an EAI Queue:
1. Navigate to Sitemap –> Integration Administration Screen –> EAI Queue
2. Create a New Record
3. Fill in the name of the EAI Queue e.g., “TEST EAI Retry Queue” without the quotes.
Steps to use / send Error Messages onto EAI Queue:
1. Call OOB “EAI XML Queueing Service” from the Error Handling workflow process to post the error message onto EAI Queue using “AddMessage” method.

2. Pass on the Error XML to the Error Handling workflow which in turn would post it onto the EAI Queue.
3. Error Message logged into the EAI Queue are listed as shown below:

Advantages of this Approach:
1. This uses OOB Siebel functionality without extra license to incorporate Error Handling.
2. Number of Custom Objects required to build for Error Handling decreases, thereby increasing performance, reducing development time, easier to debug.
Bundle Product Operations [Interface Perspective]
Product Model has become complex and updating Bundle Products requires it to be locked before updating and Release after upsert operation is complete.
The underlying BusComp Class on Bundle Products takes care of this requirement if updates are done via UI.
What would you do if you have a requirement to update Bundle Products coming from external sources in the background [Non UI Context Update].
Here is a simple solution which can be used:
For those of you who need background on the Data Model used for Product here is a snapshot….
Products are loaded into S_PROD_INT via “Internal Product – ISS Admin” BC. Once Products are released, they are available via “Internal Products” BC.
Bundle Product is a Hierarchical data having a Parent Product [referenced from Internal Product BC] and one or more Child Products [referenced from Internal Product BC but are loaded into "S_ISS_SUB_OBJ" table via "ISS Product Bundle Admin BusComp" BC].
Normally for 1:M relationships, the Parent’s ROW_ID is stored in the foreign key column of the Child Records.
For Products the case is a bit different. The Foreign key column “Object ID” doesn’t store the Parent Product’s ROW_ID. Instead it stores the “VOD Id” [VOD Id refers to the ROW_ID of the latest version record of a given product and is available in S_VOD table].
Having said that, lets get to the expectation of this post…
Locking a Bundle Product — This is a simple operation to achieve. There is a flag field on S_PROD_INT which serves as the Lock Flag. The field is “VOD Locked Flag”. This flag value has to be set on the Parent Product to Lock it. Before you Lock the Parent, you might check if its already locked. Here is a simple code that does that:
var boProdAdmin : BusObject = TheApplication().GetBusObject("Admin ISS Product Definition");
var bcProdAdmin : BusComp = boProdAdmin.GetBusComp("Internal Product - ISS Admin");
var bcProdBndl : BusComp = boProdAdmin.GetBusComp("ISS Product Bundle Admin BusComp");
var bcProdVer : BusComp = boProdAdmin.GetBusComp("ISS Product Versions BusComp");
//Lock the Product if not locked.
with(bcProdAdmin)
{
ActivateField("Name");
ActivateField("VOD Locked Flag");
ClearToQuery();
SetViewMode(AllView);
SetSearchSpec("Name",psParentProd.GetProperty("Name"));
ExecuteQuery(ForwardOnly);
if(FirstRecord())
{
if(GetFieldVlaue("VOD Locked Flag") == 'N' || GetFieldVlaue("VOD Locked Flag") == 0)
{
SetFieldValue("VOD Locked Flag", 1);
WriteRecord();
}
}
} //End of Lock Product
Note: You might add more fields onto the Query operation to uniquely identify the Parent Product.
Release a Bundle Product — Once the Bundle Product is updated with changes, you have to Release it. Without performing this operation the latest changes will not be reflected for end users to use to the latest Bundle Product.
There is a method called “Publish” on the “Internal Products – ISS Admin” BC which should be used to “Release” the Product.
There are various methodologies available to invoke the BC Method.
If you are trying to release the Bundle Product from a workflow or a Business Service, consider using the following BS and its methods:
Business Service Method
SIA BC Utility Service BCInvokeMethod
SIS OM PMT Service Invoke BC Method
Invoke BC Method
Scenario: If you want to call a BusComp method in Workflow, Siebel provides a Business Service which can be leveraged to achieve this requirement.
Business Service: Product Manipulation Toolkit Business Service Methods
Method to be invoked: Invoke BC Method
This is a generic method that allows one to invoke a Business Component-based method from Workflow. A Business Service method is invoked from a workflow by default. This method acts as a bridge to allow one to pass in the Business Component name and the method name, along with the parameters and return value required from Workflow to the Business Component specified.
Arguments
[in] A string to specify the name of Business Component on which you want to invoke its method. (Required)
[in] A string to specify the name of the method in the specified Business Component that you want to invoke. (Required)
[in] A string to pass in the first argument to the method. (Optional)
[in] A string to pass in the second argument to the method. (Optional)
[in] A string to pass in the third argument to the method. (Optional)
[in] A string to pass in the fourth argument to the method. (Optional)
[out] A string to pass out the output of the method. (Optional)