The Session tab

With the Session tab, you can configure the sharing of the tag data store between workers (instances of the stub), so that messages can be processed based on information that was captured from previously processed messages.

The image shows a table of operations with associated delay types and configuration information.

For an overview of reply sequencing that uses sessions, see Reply-sequenced stubs.


The following options are available for sharing the tag data store between events:
No data is shared. If the stub uses reply sequencing, selecting this option has the following effects:
  • Reply sequencing is disabled
  • All references to the SESSION/GROUPn/ReplyId tag are removed
  • Guards are changed for the events
  • Any functions that were created for the events are removed
All events in the stub share the same tag data store.
The stub worker (stub instance) identifies the tag data store to use based on values that were stored from the input message. This process enables data that was previously put in a store to be located. For example, if the session state is identified by its source host and port, you can specify host;port (separated by semicolons) in the Keys field. This process creates tags that are named SESSION/KEY/host and SESSION/KEY/port in the tag data store. On the Input page, store incoming values from the input message by specifying these tags, as shown in the following figure.
A UDP transport is shown, with the SESSION/KEY/host tag specified in the Action column.
All workers (stub instances) that store the same values into these tags can then use the same tag data store and therefore have access to all data that was previously put in the store.

If you select the Share the tag data store across all events received on a single connection... option, all events that are received by the stub on the connection for a connection-oriented transport (such as TCP) share the same session. This statement is true regardless of any of the other options for sharing tag data stores that you might specify. The session is uniquely associated with the connection itself. The tag data store is shared across all events in the session. This option is not available for connectionless transports such as HTTP or WebSphere® MQ.


Events can be filtered in the input message in one or both of the following ways:
  • Creating guard conditions
  • State matching
To enable state matching, click Show State on the Events page.
Two additional columns are then displayed for events: From State and To State. When you click a cell in either column, you can select a state that is defined on the Session page or define a new state. If you specify a "from" state, event matching fails unless the session is in the specified state. If you specify a "to" state, the current state of the session is changed to the specified value when the handler finishes.

You can define as many states as you need in the States table, and then select one of them as the Initial State. The current state of the session is stored in the SESSION/STATE tag and can be overwritten, as with any other mutable tag.

Data models

If you want to associate a data model with the stub, select one from the list. For more information about data models, see The Data Model view.