Siebel EAI Integration - Guaranteed Delivery of Interfaces

This article discusses guaranteed delivery of interfaces with regards to Siebel EAI Integration. We use Siebel EAI to integration with external systems. If an interface is invoked that such that the Siebel system is required to send integration data to an external system, it is crucial that the Siebel system is able to deliver that data (even when there is no communication between the systems). For example, if the integration is triggered through a runtime event within the application and the integration should execute in the background without the user being aware then the assumption is that the integration will be successful. What if there is no communication to the external system at the time of integration? I have put together the following concepts in an attempt to guarantee delivery of integration for Siebel systems. Identify the Siebel errors that are related to interface communication problems When an outbound interface using Siebel EAI is triggered and the integration fails due to transmit/communication problems we want the ability to resubmit the integration. These errors are not related to the data within the Siebel application, there should be no need for user intervention to fix these problems. The following are a list of some of the errors I have found related to transmit/communication problems: SBL-EAI-04116 HTTP Internet Exception during 'Data Send': 'The connection with the server was reset SBL-EAI-04311 Operation '%1' is expecting a response but no response was received SBL-EAI-04308 Operation '%1' of Web Service '%2' at port '%3' failed with the following explanation: "Server Error" SBL-EAI-04115 Error invoking service '%1', method '%2' at step '%3'. Cannot connect to the server From the above list of errors I am able to use the following key expressions which could be used to search a Siebel exception and identify that a communication/transmission error has occurred: Server Error no response was received Cannot connect to the server the server was reset Build an auto resend architecture Using the key expressions above, create a new LOV Type and enter each of these key expressions as LOV values for this type. Now we create a business service which will take the error message as input then check for each LOV if the LOV value key expression is found in the error message using Clib.strstr: strCheckError = Clib.strstr(strErrMsg, strKeyExpression); if (strCheckError != null && strCheckError != "") { //match } If we get a match that identifies a communicatoin/transmission error then we will want to log this integration into a table. This could be a custom table which stores the Object Id and any other parameters required such that a batch workflow could simply read the record and resubmit the workflow. Create a workflow that will read each record in the table and resubmit the workflow for each record. Schedule this workflow to execute as a repeating component request. Ensure that HTTP Sleep Time timeout parameter is configured in alignment with project standard/agreement with external system/agreement with exchange infrastructure The timeout of interfaces should be configured in alignment with the agreed timeout between external system and Siebel system stakeholders. The is especially important for my current client which many of the interface between the Siebel application and external systems are routed through exchange infrastructure SAPXI. Therefore I need to ensure that the timeout of these interfaces in the Siebel Application are in alignment with the timeout configured within SAPXI. This would be a problem if they are not configured - for example if SAPXI is configured with timeout of 3 minutes and the Siebel application is configured with a timeout of 2 minutes. Then when the Siebel application sends an outbound integration and times out after 2 minutes, SAPXI could receive response within 2.5 minutes send the response back to the Siebel Application and we have a problem. The HTTP Sleep Time parameter identifies the timeout period (in milliseconds) for the workflow to wait before erroring with error message: SBL-EAI-04311 Operation '%1' is expecting a response but no response was received This parameter is defaulted at 120000 (2 minutes). You cannot change this parameter through Administration - Server Configuration (at the Siebel Gateway Nameserver directly). I am using Siebel 8.0.0.5 - I believe this is a problem for all Siebel versions but am not sure. The way we can change this parameter is through script on the actual business service that is calling the outbound interface. For example the following script would set the timeout to 4 minutes (this script was taken from metalink3 doc id: 859193.1): function Service_PreInvokeMethod (MethodName, Inputs, Outputs) { // Double up the sleep time. 4 minutes Inputs.SetProperty("HTTPSleepTime", "240000"); // continue operation to all method calls. return (ContinueOperation); }

Related White Papers

4 Comments

Great article..thanks for sharing. Design assumes that there are only 4 listed types of error that one can encounter for transmission of the msg. One has to lookout for other error codes, if any, and keep adding them in logic, if we want to resend the transaction for these error codes.

Also, aligning timeouts in Siebel/middleware/target system for an outbound IF is straight forward as explained above. You just need to ensure Siebel does not timeout before middleware/external application does.

However, I'm facing challenge with synching up timeout for inbound IF. I have an inbound interface which have multiple steps including a Siebel operation step to insert an SR. My middleware timesout in 60 seconds. I do not want SR to be created (technically: committed in DB) if operations times out in middleware.

In case of server hangs or other performance related issues, if SR creation is successful but takes more than 60 secs, middleware terminates the connection and does error handling. In such case, I have to either prevent the SR from being created or roll back the transaction.

1. Create a WF. The First step in the WF could be using the BS ( EAI Transaction Service) which marks the start of the transaction using begin transaction method. Perform Siebel EAI Operation as second step and Final step before returning he call would be to commit or rollback using same EAI Transaction Service but this time using method End Transaction. Configure this WF to be a Siebel Web Service

2. In m/w you could then call the synchronous WF based siebel web service. The Siebel Web service will start a transaction and will always commit or rollback. You can update m/w table to confirm that the commit occured.

Second Solution:
Create a UI Data Web Service in Siebel and then from m/w call the WS and have retry option incase of failure. Depending on the m/w retry could be configured to a finite number within a finite set of time. oracle BPEL m/w allows such retries to a HTTP WS

I am getting the same problem what USER_2127838 is getting.
which we are getting Timeout exception for the inbound web service.
If we do request from SOAP UI or other webservice tools to Siebel server, only some times we are getting Timeout exception.
Is there any solution for that.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.