The internal listener is an iSM-managed queuing protocol that accepts messages from other channels for asynchronous execution. The primary responsibilities of the internal listener are:
- Provide an opportunity to change from one threading model to another.
- Alleviate stress on another channel by executing work independently of the response to the sender.
- Break up (modularize) the application for simpler development and maintenance.
When the Internal Emit service (com.ibi.agents.XDInternalEmitAgent) is used in a process flow, the message is immediately added to a named internal listener queue.
When the Internal Emit service sends the message to the internal queue, it immediately completes, passing the document out for any further processing. A common use of the internal listener is to have the first channel perform required preliminary processing and then immediately send a receipt message, or Message Delivery Notification (MDN), while the actual business processing proceeds without reference to the actual source. In the AS2 protocol, the logic in the internal listener channel could prepare an asynchronous notification of the result of the business processing. The recipient would need to correlate a result received asynchronously with the original message. Because the internal listener channel displays the original transaction ID, the asynchronous message can contain the required information to assist in the correlation.
The following diagram illustrates the link between two channels. The inlet and outlet handling is shown as purple boxes. The process flow in the first (top) channel sends the message to the internal listener channel (shown on the bottom), and then immediately proceeds to complete operation of the first stage.
The internal listener channel can operate on a different number of threads than the original recipient of the message. For example, it may be necessary to receive messages on a single thread to preserve input message number tracking. However, once the message is determined to be in the correct sequence, the actual execution can proceed on multiple threads.
Alternatively, it may be required to receive on a large number of threads, but for a final stage of execution, only one thread might be possible. This type of requirement can occur because of restrictions on a resource (for example, a fixed number of connections to an online system, such as SAP) or the need to control output sequence numbering in some manner.
The internal listener provides the following types of application flow throttling control:
- Passivation
Passivation refers to sending instructions to other listeners (channels) to cease acquiring messages from their own input sources. The internal listener does this by allowing the configuration of a high and low mark.
When the number of messages on the internal listeners queue exceeds the high mark, the passivation is sent to the identified channels. The internal listener continues to acquire messages from its queue, and when the number in the queue reaches the low mark, the identified channels are reactivated. Channels that are not passivated can continue to acquire messages for their processing and add messages to the internal queue.
- Inhibition
Inhibition can be configured for a channel, which causes the internal queue to reject attempts to add to the queue while the number of messages on the queue exceeds the high mark. The inhibition state is reset when the queue reaches the low mark. The process flows attempting to add to the inhibited queue enter a pause state, and the add attempt may time out. In such a timeout case, a status document is passed down the timeout edge of the feeding process flow, if available. The use of inhibition can have a cascading impact on the application, causing a general pause in processing while the internal channel catches up with the required work.
The internal channel also supports message priority. Usually, a message is placed on a queue at a middle priority. Using priorities allows the sender to reorder message execution through the channels as required. As a best practice, iWay recommends using priorities only if required. Use priorities one value up or down from the original value. Avoid using the highest priority value (9). Priorities are relative to other messages, and higher numbers do not necessarily result in faster processing.