Managing application state across an HTTP request sequence

CICS® initiates a new alias transaction and a new program for each request made by a web client. This initiation is for pipelined requests, requests made using a persistent connection, and requests that form a logical sequence, and for individual stand-alone requests. Consider how the application state will be managed between requests.

About this task

To share data across the request sequence, between different programs or instances of the same program, use CICS-managed resources or elements of the requests sent by the web client.

When more than one exchange of a request and response between a web client and CICS is needed to complete a task successfully, the web client initiates each new step in the sequence. You can design the response sent by CICS to guide the web client, and any human user of the web client, to the next step. For example, the entity body can contain controls, such as links or buttons, with which the user can compose the next request. However, you cannot easily enforce the correct sequence of requests. In particular, the planned sequence can be disrupted for these reasons:
  • The client is a web browser, and the user types a known URL to initiate a particular request, rather than selecting a control in an HTML page provided by a previous response.
  • The user abandons the activity, by shutting down the web client or by changing to an alternative activity with the web client.
The user might also delay initiation of any request in the sequence.

You must design your application programs so that they can cope with delays or disruptions in the request sequence. For example, if you are sharing data across the request sequence, ensure that the data is cleaned up if the request sequence does not complete or is delayed excessively. If your application programs update protected resources, ensure that updates that must be committed or backed out together are made in the same transaction. So you must design a single request from the web client to complete the update.

The best situation for an application is that each exchange of a request and response is self-contained and completes an independent element of the task. However, this design is not always possible, especially when the task is complex, or when a web client has sent a pipelined sequence of requests. You might require a pseudoconversational model, in which the application state must be managed between requests. Use the following techniques:

Procedure

  • You can design the requests sent by the web client so that application state, or shared data, is incorporated in the request; for example, as part of a request URL that is used when the web client submits an HTML form.
    The next program can examine the request URL to obtain the shared data.
  • You can store small quantities of application state using hidden fields in an HTML form that is returned to the web client as a response.
    When the user performs the next action in the planned sequence, the request that is sent to CICS can include the hidden fields, which can be located and read by the next application program.
  • For larger quantities of state, and state with an extended lifetime, you can create a CICS-managed resource to maintain the application state, and pass a token that represents the resource.
    CICS provides sample state management programs, DFH$WBST and DFH$WBSR, that store application state in main storage or temporary storage queues, and provide tokens that application programs can use to access the information.
    A token can be conveyed from program to program in a pseudoconversation as a hidden field in an HTML form, or from interaction to interaction as a query string in a URL.
    Use this technique to preserve information throughout a pseudoconversation and also to preserve information throughout an extended interaction between a user and various CICS application programs, perhaps over several pseudoconversations.