HTTP_BEGIN_INBOUND

This activity establishes an HTTP inbound session and returns a "handle" in the HTTP_HANDLE parameter that can be used to identify this session for use in other HTTP activities.

For more information on the use of HTTP activities and configurations in LANSA Composer to perform inbound (server) HTTP processing, please refer to:

HTTP Inbound (Server) Processing in LANSA Composer

 

To understand how your Processing Sequence containing the HTTP_BEGIN_INBOUND activity is connected with an inbound HTTP request, refer to:

Connect Your Processing Sequence to an Inbound HTTP Request

 

Related HTTP activities

When the HTTP inbound processing is complete, you should close the session using the HTTP_END activity.

In between the HTTP_BEGIN_INBOUND and HTTP_END activities, you may use one or more of the following activities, according to your requirements, to receive details and content of the inbound HTTP request:

HTTP_MULTIPART_GET Get inbound multipart component item HTTP_PROPERTY_GET Get HTTP protocol property value(s) HTTP_RECEIVE_FILE Receive a single file HTTP payload HTTP_RECEIVE_MULTI Receive HTTP payload as multipart content HTTP_RECEIVE_NAMEVAL Receive HTTP payload as name-value pairs

After successfully receiving the HTTP request, you may use one or more of the following activities to prepare and send the HTTP response:

HTTP_MULTIPART_SET Set outbound multipart component item HTTP_PROPERTY_SET Set HTTP protocol property value(s) HTTP_RESPOND_FILE Send file as response to HTTP request HTTP_RESPOND_MULTI Send multipart content as response to HTTP request HTTP_RESPOND_NAMEVAL Send name-value pairs as response to HTTP request HTTP_RESPOND_STATUS Send status as response to HTTP request

 

Eligibility for Processing Sequence Restart

When a LANSA Composer Processing Sequence run ends in error, it is often possible to restart it from the point of failure—once the cause of the failure has been corrected. This is a very powerful feature of LANSA Composer.

For a LANSA Composer solution using the HTTP activities, processing sequence restart is NOT possible between the HTTP_BEGIN_INBOUND and HTTP_END activities.

To maximize the benefit of LANSA Composer's restart capability, you should complete your HTTP request processing and execute the HTTP_END activity at the earliest opportunity. Once the HTTP session has been closed, normal restart eligibility resumes.

 

Example Processing Sequences using the HTTP Activities

The supplied example Processing Sequence EXAMPLE_HTTPUPLOAD demonstrates the use of HTTP_BEGIN_INBOUND and other advanced HTTP activities to process an inbound HTTP request and send a response.  Refer to the notes accompanying the example Processing Sequence for details.

Refer to Example Processing Sequences for information on installing and using the example Processing Sequences.

 

INPUT Parameters:

There are no input parameters.

OUTPUT Parameters:

HTTP_HANDLE:

If successful, the value of this output parameter identifies the HTTP inbound session established by this instance of the HTTP_BEGIN_INBOUND activity.  The same value must be specified as the HTTP_HANDLE input parameter value for all subsequent HTTP activities that are to operate on the same HTTP session.

HTTP_APPLICATION 

This value will contain the Application Name value from the HTTP inbound configuration that was matched to this HTTP inbound request.  For more information, refer to the description of Application Name in HTTP Configuration Details.

HTTP_QUERY_STRING 

This value will contain the query string from the URI.

If the full URI was  http://IBMServer:8080/xxxpgmlib/jsmdirect?ZZorders on IBM i or http://winserver:8080/composer/jsmdirect?ZZorders on Windows

then the query string would have a value of ZZorders.

HTTP_CONTENT_TYPE 

This parameter will contain the actual value of the CONTENT-TYPE HTTP header.  For example, text/plain.

HTTP_CONTENT_LENGTH 

This value will contain the content length of the content received on the HTTP inbound request.

HTTP_RESOLVED_TYPE 

The activity will resolve the content type received in the HTTP header to a single special value that best fits the conten type received.  For example, it will be set to *MULTIPART for a multipart message, or it may be set to values such as *TEXT, *XML etc.  Refer to the HTTP Configuration Details for a full list of types.

HTTP_REMOTE_ADDRESS 

This value will contain the IP address of the remote server.

HTTP_REMOTE_USER

This value will contain the remote user if available.

HTTP_SERVER_PORT

This value will contain the local port number that serviced this inbound HTTP message.

PROXY_REMOTE_ADDRESS 
PROXY_REMOTE_USER
PROXY_SERVER_PORT

These values may be received when the inbound HTTP request is received by and forwarded from the JSMPROXY proxy server.  They will contain values functionally equivalent to HTTP_REMOTE_ADDRESS, HTTP_REMOTE_USER and HTTP_SERVER_PORT respectively, but the values will be those received and forwarded by the JSMPROXY proxy server.