Transports and Interfaces: Siebel eBusiness Application Integration Volume III > EAI HTTP Transport >

Using the EAI HTTP Transport for Inbound Integration

The EAI HTTP Transport uses the Siebel Web Engine (SWE) to provide inbound messaging from an application that uses HTTP.

To use the EAI HTTP Transport for inbound integration, you must perform certain tasks that are not required when using the EAI HTTP Transport for outbound integration. First, you must be running the Siebel Web Engine (SWE) in order to use the EAI HTTP Transport. In turn, SWE requires that the Siebel Web Server, Siebel Gateway Name Server, and Siebel Server be installed, configured, and up and running.

NOTE:  Type http://Web_Server_Name URL on any machine that already has connectivity to the Web server to check the connectivity between the URL (for EAI HTTP Transport) issuing machine and SWE. This URL brings up the Home page of the Web server confirming the connectivity between SWE and the URL issuing machines.

Specifying HTTP Parameters for Inbound Integration

The EAI HTTP Transport is built into SWE. To use it, you first need to set certain configuration parameters for the virtual directory on the Web server. Your Siebel application installation includes a configuration file called eapps.cfg in the \bin subdirectory of your installation directory. This file is on the Web server side of your configuration, as opposed to on the Siebel Server side of your installation. You should review the configuration file to make sure that the parameters are set properly. Use named subsystems to dispatch to a workflow as described in the section Using Named Subsystems for Transport Parameters in EAI Transports and Interfaces Overview.

To configure the SWE to run the EAI HTTP Transport for inbound integration

1. Open your eapps.cfg file in a text editor.
2. Look for the section [/eai_lang]. Where lang is the three-letter language code for the language you are using, such as enu for U.S. English.
3. Add the EnableExtServiceOnly configuration parameter or set it as follows, if it already exists, to enable the HTTP inbound transport. This example shown is for use with UNIX in an English environment.

   [/eai_enu]
   ConnectString = Connect String
EnableExtServiceOnly = TRUE

   For the virtual directory, you need to set the ConnectString parameter. The syntax for the ConnectString is:

   ConnectString = siebel[.transport][.encryption][.compression]://SiebelServer :SCBPort/EnterpriseName/XXXObjMgr_lang

   Where:

   transport = TCPIP or http.

   encryption = none or mscrypto.

   compression = none or zlib.

   SiebelServer = the name of your Siebel Server.

   SCBPort = Listening port number for the SCBroker component (default is 2321).

   EnterpriseName = the name of your Siebel Enterprise Server.

   XXXObjMgr_lang = the type of Object Manager for the Siebel eBusiness application you are installing and the language code used for this installation.

   The following example shows the connect string using TCP/IP, with no encryption, no compression, and the server name and default port. In addition, you need to point to the Siebel Object Manager specific to the Siebel eBusiness Application you are installing.

   In the example connect string, the Siebel eBusiness Application installed is Siebel eSales, and the Siebel Object Manager is called EAIObjMgr.

   ConnectString = siebel.TCPIP.None.None://server1:2321/siebel77/EAIObjMgr_enu

4. Save and close the configuration file.

Setting Configuration Parameters for Siebel Server

You must also set certain configuration parameters for whatever Siebel Server you are using. The server component you are running must be a Client Application Manager component. Set this in the configuration file for the server component of your choice, or use named subsystems.

Calling EAI HTTP Transport Over a Network

The EAI HTTP Transport can be used in two modes:

• Session mode
• Sessionless mode

The following sections explain the use of these two modes.

Viewing the Session Mode Between HTTP Requests

This mode uses HTTP Session Cookie to retain the session information between the HTTP requests. The session mode can be viewed when a sequence of calls is supported from an HTTP application into the EAI HTTP Transport.

To view the session mode from an HTTP application into an EAI HTTP Transport

1. Log in to the Siebel application. If successful, an HTTP session cookie gets returned in HTTP set-cookie header.
2. Submit one or more requests.

   Each request is intended as a call to a Siebel business service. Requests must contain the session cookie from Step 1 in the HTTP cookie header.

3. Log off. The request must contain the session cookie from Step 1 in the HTTP cookie header. The cookie refers to the session to be closed.

   The Session cookie is passed to the caller after a successful login request as in Step 1. The caller then should use that cookie for subsequent data requests in Step 2 and the log off request in Step 3.

NOTE:  For session mode inbound HTTP requests, the expiration date of the cookie sent to the client application will not be set as it is expected that this cookie will be used to send multiple requests within the same session.

Login Examples for the HTTP Protocol

HTTP protocol requests can be represented as URLs for HTTP GET, and as a combination of URL and request body for HTTP POST. The following sections explain in detail how each of the session mode calls is configured.

Login HTTP Request Example 1

In this example, if the call completes successfully, it will return a session cookie.

Using HTTP GET

URL  = http://webserver/path/start.swe?SWEExtSource=source&SWEExtCmd=ExecuteLogin&UserName=username&Password=password

Using HTTP POST

URL  = http://webserver/path/start.swe

HTTP Body  = SWEExtSource=source&SWEExtCmd=ExecuteLogin&UserName=username&Password=password

Table 14 presents each of the Login HTTP Request variables for session mode.

Example Login URL

http://www.myserver.com/eai/start.swe?SWEExtSource=SiebelQuery&SWEExtCmd=ExecuteLogin&UserName=user1&Password=login123

Login HTTP Request Example 2

In this example, for the call to complete successfully, it must include the session cookie from the login.

Using HTTP GET

URL = http://webserver/path/start.swe?SWEExtData=data text

Using HTTP POST

URL = http://webserver/path/start.swe

HTTP Body = data text

where data text is the business service input data. Most of the time, this is the text of an XML document that on the server side is converted to a PropertySet and passed to the business service.

Example Request URL

http://www.myserver.com/eai/start.swe?SWEExtData=<?xml version="1.0" encoding="UTF-8"?><SiebelMessage MessageId="" MessageType="Integration Object" IntObjectName="Sample Account">

   <ListofSampleAccount>

      <Account>

         <Name>A. K. Parker Distribution</Name>

         <ListOfContact>

            <Contact>

               <FirstName>Stan</FirstName>

               <LastName>Graner</LastName>

            </Contact>

         </ListOfContact>

      </Account>

   </ListofSampleAccount>

</SiebelMessage>

To use this URL, you change the WebServer address www.myserver.com to the actual server URL you will be using. Data that is sent as part of the URL should be Unicode-encoded before being URL-encoded. POST requests can send the data without URL encoding and should include the Content-Type HTTP header. The Content-Type should specify the charset of the incoming data as in Content-Type=text/xml;charset="UTF-8".

NOTE:  For XML messages being received by way of the Inbound HTTP Transport, only a Unicode (UTF-8 or UTF-16) format (with accordant encoding XML-processing header attribute and encoded XML data) is allowed. No ISO or Windows code pages are accepted.

Logoff HTTP Request

This request must include the session cookie from Login.

Using HTTP GET

URL = http://webserver/path/start.swe?SWEExtCmd=Logoff

NOTE:  HTTP GET should always be used for the Logoff HTTP Request.

Example Logoff URL

http://www.myserver.com/eai/start.swe?SWEExtCmd=Logoff

EAI HTTP Transport in Sessionless Mode

Using the EAI HTTP Transport in sessionless mode allows you to use one URL to perform Login, Request, and Logoff in a single HTTP request. This mode does not use session cookies because there is no login session between the HTTP requests. The disadvantage of this mode is the overhead incurred by the Siebel Object Manager needing to log in with every request.

Example of URLs Used for the HTTP Inbound Transport

In this example, the URL describes the parameters for the HTTP Inbound Transport call over HTTP.

Using HTTP GET

URL = http://webserver/path/start.swe?SWEExtSource=source&SWEExtCmd=Execute&UserName=username&Password=password&SWEExtData=data text

NOTE:  Unlike session mode, the SWEExtCmd is Execute, not ExecuteLogin.

Using HTTP POST

URL = http://webserver/path/start.swe

HTTP Body = SWEExtSource=source&SWEExtCmd=Execute&UserName=username&Password=password&SWEExtData=data text

NOTE:  When using the sessionless mode with the POST method, the XML data text must be URL-encoded to prevent any errors.

Table 15 presents each of the variables for sessionless mode.

Example Sessionless Mode URL

NOTE:  This sample URL should be entered as a single line of text. The URL is presented here on separate lines for clarity.

http://www.myserver.com/eai/start.swe?SWEExtSource=SiebelQuery&
SWEExtCmd=Execute&UserName=user1&Password=login123
&SWEExtData=<?xml version="1.0" encoding="UTF-8"?><SiebelMessage MessageId="" MessageType="Integration Object" IntObjectName="Sample Account">

   <ListofSampleAccount>

      <Account>

         <Name>A. K. Parker Distribution</Name>

         <ListOfContact>

            <Contact>

               <FirstName>Stan</FirstName>

               <LastName>Graner</LastName>

            </Contact>

         </ListOfContact>

      </Account>

   </ListofSampleAccount>

</SiebelMessage>

To use this URL you will:

• Change the WebServer address, www.myserver.com, to your actual Web server URL.
• Verify that the SWEExtSource argument has a corresponding section in your eai.cfg file in the [HTTP Services] section.
• Change the Username and Password arguments to a valid system user, such as "SADMIN/SADMIN."