There are two usage types for the plain HTTP adapter:

• Synchronous processing

• Asynchronous processing

In principle, both scenarios are possible at the Integration Engine HTTP inbound and outbound channels.

In special cases for particular external servers with CGI scripts, for example marketplaces, it is possible to send the payload as an HTML form using HTTP post. The payload is enhanced correspondingly.

You communicate with the Integration Engine plain HTTP inbound channel using a URL (Uniform Resource Locator). The HTTP body is used as the payload for the message. The payload does not contain an envelope with control data for the message you want to create. You must code the control data in the URL as parameters; these parameters are obligatory to be able to generate a message.

Queries entering the plain HTTP adapter must have the following syntax:

The query string contains the following data:

• Sender Namespace
• Sender Interface
• Sender Business System
• Quality of Service (BE or EO)
• Message ID (optional)

The message ID is 32 characters long and must only comprise the characters 0 to 9 and A to F. It is persisted and can therefore be checked for duplication. If the HTTP client (the sender system) cannot provide a message ID, the plain HTTP adapter generates a message ID and forwards it to the application through the Integration Engine. You can then carry out a duplication check at document level, for example, by using the order number.

The plain HTTP outbound channel is a service provided by the Integration Engine. The system communicates with this interface when technical routing determines a corresponding end point for the logical receiver from logical routing. The system sends the payload of the message to a URL using HTTP, without being enhanced with an envelope.

The plain HTTP adapter gives the receiver system the following specifications:

• Encoding (Default UTF-8)

• URL Encoding

• Prolog

• Epilog

• Host, port and path including query string

• Proxy host and proxy service (optional if there is a firewall between the plain HTTP adapter and the receiver system)

• User and password (optional for an authentication in the receiver system)

• The following are specifications that are only possible using an HTTP destination:

• SSL ID (Secure Socket Layer), if you want to use SSL encoding

Some external systems, for example, Web servers in marketplaces, can only process data if it is sent as an HTML form using HTTP.

A typical HTML form comprises named fields. When transferring a completed form to the server or a CGI program, the data must be transferred in such a way that the CGI script can recognize the fields that make up the form, and which data was entered in which field.

The plain HTTP adapter constructs this format using a prolog and an epilog. Therefore, there is a particular code method that separates form fields and their data from each other. This code method uses the following rules:

• Individual form elements, including their data, are separated from each other by the character &.
• Name and data of a form element are separated from each other by an equals sign (=).
• Blanks in the entered data (for example, in multiple words) are replaced by a plus sign (+).
• All characters with the (enhanced) ASCII values 128 to 255 (hexadecimal 80 to FF) are transcribed using a hexadecimal sequence, beginning with a percentage sign (%) followed by the hexadecimal value of the character (for example, the German umlaut ö in the character set ISO-8859-1 is transcribed as %F6).
• All characters that occur in these rules as control characters (&, +, = and %) are also transcribed hexadecimally in the same way as high value ASCII characters.