A request-reply channel is used with a Universal Messaging connection alias when the alias is used to send requests or receive replies as part of a request/reply or publish-and-wait scenario. Select the Enable Request-Reply Channel and Listener check box to use a dedicated request/reply channel and listener with the alias.

When the Enable Request-Reply Channel and Listener check box is selected, Integration Server does the following when the Universal Messaging connection alias starts:

The request/reply channel name includes a string identifying the Integration Server, the client prefix, and the text “RequestReply”. The request/reply channel name also includes a unique ID generated the first time that Integration Server starts. A stateful Integration Server persists the unique ID to disk and uses the same request-replay channel name across restarts. However, if Integration Server is stateless (for example, when running in a stateless container), the generated ID is not saved to disk and does not persist across Integration Server restarts. This results in the creation of new request-reply channel on Universal Messaging every time Integration Server restarts. Over time, the unused channels build up on Universal Messaging.

To prevent the buildup of unused request-reply channels, select the Auto Delete Request-Reply Channel (on disconnect) check box. Integration Server automatically deletes the request-reply channel shortly after disconnect from Universal Messaging. If the connection to Universal Messaging is lost and then restored quickly (that is, before the channel is deleted), Integration Server uses the same request-reply channel upon reconnecting. Automatically deleting the request/reply channel effectively makes the request-reply channel a temporary channel.