EAI Transports and Interfaces Overview

Siebel Enterprise Application Integration (EAI) provides mechanisms for exchanging data between Siebel Business Applications and external systems.

This chapter includes the following topics on these mechanisms:

About EAI Transports

Transports allow Siebel Business Applications to exchange data with external applications using standard technologies for both synchronous and asynchronous communication protocols.

Transports handle all data as binary data (bytes) because the IsTextData parameter that was available in previous releases is no longer supported. If you want to use character conversion on the transport, then you use the CharSetConversion parameter. Handling the data as binary defers any character set conversion until needed and avoids conversion at the transport level to prevent data corruption. For example, treating a UTF-8 encoded Extensible Markup Language (XML) document as text when the conversion executes leads to an XML string in the local code page, while its header still describes UTF-8. It is best to treat all self-describing data, including XML, as binary.

Character conversion is available in a number of business services. These business services are:

EAI Transport business services (MQ Series, MSMQ, JMS, HTTP, DLL, File)
XML Converter business services
Transcode Service business service

When business services are invoked from a workflow, the valid set of encodings is controlled by a picklist. If the business services are invoked through scripting or similar mechanisms, then the character set name is supplied textually.

Note: For data validation or conversion from one encoding to another, you can use the Transcode Service business service. For information about the Transcode Service business service, see Transcode Service Business Service

Transports provide connectivity to virtually any communication protocol that can represent data as text or binary messages, including MQSeries from IBM, MSMQ from Microsoft, Java Message Service (JMS), and HTTP. EAI Transports allow Siebel Business Applications to integrate with Web-based applications as well as legacy systems that are encapsulated using middleware. Transports are interchangeable. If you change technologies at any point, then you can reuse existing workflows and logic by switching the transport adapter.

Transports can:

Support bidirectional exchange of messages.
Run within the Siebel Application Object Manager.
Invoke and be invoked by Workflow Process Manager and EAI Dispatch Service.
Be invoked within an eScript or VBScript.
Send and receive messages in XML format.
Pass messages through, or convert messages into, property sets for XML and MIME messages.

Available transports include:

EAI MQSeries Server Transport. For information about these transports, see EAI MQSeries Server Transport
EAI MSMQ Transport. For information about this transport, see EAI MSMQ Transport
EAI JMS Transport. For information about this transport, see EAI JMS Transport
EAI HTTP Transport. For information about this transport, see EAI HTTP Transport
EAI DLL Transport and EAI File Transport. For information about these transports, see EAI DLL and EAI File Transports

Note: The transport business services are not re-entrant. This applies not only to receivers, but also to nonreceiver mode because users can define scripts in the business service that invoke the same business service. For more information about transport re-entrance, see About EAI MQSeries Transport Re-Entrance.

About EAI Transport Methods

The method on a transport adapter’s business service controls the action to be performed by the transport. There are two outbound methods and three inbound methods available for EAI Transports. Not every method is available on every transport. These methods are described in the following topics:

For each method, there are a number of common parameters, as shown in the second table in Common EAI Transport Parameters, as well as transport-specific parameters that are discussed in the respective chapter for each transport.

Outbound Methods for a Transport Business Service

Available outbound methods depend on the transport business service in use, such as EAI MSMQ Transport. The business service sends messages from the Siebel application using the appropriate communications protocol, such as MQSeries, MSMQ, HTTP, and so on. There are two outbound methods that you use to send requests from a Siebel application to another application:

Send. Sends a message from a Siebel application when the Siebel application does not require a response. This is an asynchronous request method (except for the EAI HTTP Transport, which expects a correct HTTP response), because the Siebel application does not wait for a response before continuing with the process.
Send and Receive (SendReceive). Sends a message from the Siebel application when the Siebel application requires a response before continuing. This is a synchronous request and response method, because it must receive a response before the Siebel application can continue.

Inbound Methods for a Transport Business Service

Available inbound methods depend on the transport business service in use, such as EAI MSMQ Transport. The inbound methods monitor a specified queue and upon receipt of a message, dispatch it to another service.

There are three inbound methods that can be used to receive requests from another application:

Receive. Receives an inbound request message and returns it to the caller of the transport.
Receive and Execute (ReceiveDispatch). Receives an inbound request message and calls another service with the inbound message as input. This called service is known as the Dispatch Service, and the method that is called is known as the Dispatch Method.
Receive, Execute, and Send (ReceiveDispatchSend). This is a request/response method. It receives an inbound request message, calls another service with the inbound message as input, and then sends the output of the called service as a response. To suppress the response, you can create an output property, on the dispatch service, of type EmptyResponse and set it to True.

Note: To receive a message and send a reply using the ReceiveDispatchSend method, you must use the <Value> process property in dispatched workflows to hold the message.

Note: There are server components (called receivers) first on the inbound methods that run as Siebel Server tasks. When running an EAI receiver such as MQSeries Server or MSMQ Receiver (using the methods ReceiveDispatch or ReceiveDispatchSend), if the dispatch service has an error, then the receiver shuts down. Check the Status column on the Component Tasks for details about the cause of the error.

Using Named Subsystems for Transport Parameters

Named subsystems are groupings of defined enterprise parameters that are stored in the Siebel Gateway. You use named subsystems to specify methods and parameters for EAI Transports. Transport business services take two subsystem names as parameters, which you define using the Siebel Server Manager:

Transport Connection Subsystem (ConnectionSubsystem)
Transport Data Handling Subsystem (DataHandlingSubsystem)

Values for parameters in a named subsystem are common to every user of the subsystem across the enterprise. Subsystem names themselves are parameters for server components. You can logically group parameters into various subsystems.

For the two EAI Transport named subsystem parameters, ConnectionSubsystem and DataHandlingSubsystem, two parameters exist for the EAI receivers: ReceiverConnectionSubsystem and ReceiverDataHandlingSubsystem. The EAI Receiver looks up these parameters from the server component parameters and copies the corresponding properties (ConnectionSubsystem and DataHandlingSubsystem) to the input property set of the transport business service.

Note: You must create named subsystems and specify the parameters for the subsystems. Then, you specify the named subsystems you created, for example, as business service user properties in a workflow or through scripting. You must specify named subsystem parameters by the values of their Alias fields in the Profile Parameters list.

The following subtopics are discussed in this topic:

Rules of Precedence for Parameter Specification

You can specify the two named subsystem parameters, ConnectionSubsystem and DataHandlingSubsystem, as either business service user properties or as run-time arguments. If you specify the parameters in both locations, then the business service user property takes precedence over the run-time arguments.

Note: For additional information about named subsystems, see Siebel System Administration Guide.

You specify every other parameter in one of the two named subsystems or as run-time arguments. Siebel EAI looks for the parameter in the ConnectionSubsystem or the DataHandlingSubsystem, depending on which parameter it is. If you specified the appropriate named subsystem, then Siebel EAI always looks for the parameter there.

If you do not specify the parameter in this named subsystem, even if you specified it as a run-time argument, then the run-time specification is ignored. Siebel EAI looks for the parameter in a run-time specification only if no appropriate named subsystem is specified.

Common EAI Transport Parameters

To configure the EAI Transports, you create named subsystems for data handling and connection parameters, as presented in the following table.

When You . . .	Use This Parameter . . .
Call any Business Service	DispatchService. This parameter must be used in conjunction with DispatchMethod.
Call any Business Service	DispatchMethod. This parameter must be used in conjunction with DispatchService.
Call the Dispatch Rule Set Business Service	DispatchRuleSet.
Call any Workflow	DispatchWorkflowProcess.

The data handling parameters are presented in the following table. These parameters are common to every transport method. After you create the named subsystems, you then specify these named subsystems as parameters in the service method argument or the business service user property.

Parameter Name	Description
CharSetConversion	CharSetConversion specifies if and how a character set conversion needs to occur before or after sending or receiving data from the external system. Legal values are None, UTF-8, and UTF-16. Default is None. Use the default value for this parameter for selfdescribing content such as XML and MIME. When used with a Receive method, CharSetConversion implies that the external data being read is in whatever charset specified by this setting and must be converted to String. Therefore, the output `<Value>` is a String whenever CharSetConversion is specified. If no CharSetConversion is specified, then the output `<Value>` is in binary and retains its original encoding. When used with a Send method, CharSetConversion defines the character set for the output data. The data in `<Value>` is converted to the character set specified by CharSetConversion. Depending on the value of this parameter, transport business services do implicit character set conversions, if necessary. Note that same CharSetConversion is assumed for requests and responses.
ConverterService	Default is EAI XML Converter. This is the name of the business service to use for serializing property sets to a buffer and unserializing buffers to property sets. This parameter receives arguments through business service user properties if the converter service can accept them. Note: You cannot use an arbitrary service as a converter service.
DispatchMethod	DispatchMethod parameter specifies the dispatch method. Specification of DispatchService is mutually exclusive with specification of a DispatchRuleSet or a DispatchWorkflowProcess. This parameter is only applicable for the ReceiveDispatch and ReceiveDispatchSend methods.
DispatchRuleSet	DispatchRuleSet specifies the name of the dispatch rule set for the Dispatcher Service. Specification of DispatchRuleSet is mutually exclusive with specification of DispatchWorkflowProcess or Dispatch Service. This parameter is only applicable for the ReceiveDispatch and ReceiveDispatchSend methods.
DispatchService	DispatchService specifies the dispatch service. Specification of DispatchService is mutually exclusive with specification of a DispatchRuleSet or DispatchWorkflowProcess. This parameter is only applicable for the ReceiveDispatch and ReceiveDispatchSend methods.
DispatchWorkflowProcess	DispatchWorkflowProcess specifies the name of the workflow to dispatch to. Specification of DispatchWorkflowProcess is mutually exclusive with specification of DispatchRuleSet or Dispatch Service. This parameter is only applicable for the ReceiveDispatch and ReceiveDispatchSend methods.
IgnoreCharSetConvErrors	Default is False. This parameter specifies whether character set conversion errors are ignored. If False, with any such errors, then the transport service propagates the error.
Impersonate	Default is False. This parameter indicates whether or not the receiver executes the incoming request using the default credentials of the receiver or those provided in the incoming XML document. If this parameter is set to True, then the receiver analyzes the incoming XML document (`<SiebelMessage>` element) for the eaiusername and eaipassword credential attributes. If these credentials are found, then the receiver attempts to relogin with the credential. If the Impersonate parameter is set to True and the credentials are not found or are not a valid Siebel username or password, then an error message is returned.
RollbackOnDispatchError	Default is True. This parameter indicates whether or not to roll back transport transaction if a Dispatch Method fails. This parameter is only available for the transactional transports MQSeries Server and MSMQ.
SiebelTransactions	Default is True. This parameter indicates whether or not to nest the Siebel transaction within the transport transaction. This parameter is only available for the transactional transports MQSeries Server and MSMQ. If this parameter is set to False, then the transaction support is turned off at the transport level. This setting means that if the transaction fails, then there is no rollback at the Siebel transaction level.

About Object Interfaces and EAI

Object Interfaces allow integration between the Siebel application and external applications. Object Interfaces can be called by eScripts and VB or used within a workflow. The workflow can use other business services and transports as needed.

Available object interface support includes Siebel Java Data Beans for integration with Java EE applications. For information, see Integrating Siebel Business Applications with Java Applications.

Database-Level Interfacing

In addition to transports and object interfaces, Siebel Business Applications provide Enterprise Integration Manager (EIM) for high-volume data exchange and batch loading. You use the set of interface tables that serve as intermediate tables between your external data source and the Siebel Database.

Note: For more information about Siebel EIM and the interface tables, see Siebel Enterprise Integration Manager Administration Guide.