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 is the case for pipelined requests, requests made using a persistent connection, and requests that form a logical sequence, as well as for individual standalone requests. You need to consider how the application's state will be managed between requests. If you need to share data across the request sequence, between different programs or instances of the same program, you can do this using CICS-managed resources, or using 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, each new step in the sequence is initiated by the Web client. 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) that the end user can use to compose the next request. However, you cannot easily enforce the correct sequence of requests. In particular, the planned sequence can be disrupted if:
  • The client is a Web browser, and the end 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 end user abandons the activity altogether, by shutting down the Web client or by changing to some alternative activity with the Web client.
The end user might also delay initiation of any request in the sequence.

You should 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, you should ensure the data is cleaned up if the request sequence does not complete or is delayed excessively. If your application programs update protected resources, you should ensure that updates that must be committed or backed out together are made in the same transaction. (This means that a single request from the Web client should be designed to complete the update.)

The ideal 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. A pseudoconversational model may be required, where the application's state must be managed between requests. This can be arranged using the following techniques: