Edit

InterAct Adapter Store and Forward

  • Article

In Store and Forward (SnF) mode, messages are delivered to a queue at send time, and are retrieved from the queue by the destination. When using SnF, the response comes from SWIFTNet SnF itself, and does not contain any feedback from the Responder.

Messages and files can be routed into queues with the same flexibility as a message routed to a server process when not using SnF. This definition is within MRR (inside of SWIFTNet). It is the Receiver who decides in which queue a message or file will be put after it is sent by the Sender. Putting a message or file in a queue is done by flagging the message for SnF delivery mode (within the RequestControl).

Retrieving a message from a queue can occur in two different modes, depending on the choice made by the application designer. These modes are called push and pull.

When using the push mode, the initiative to deliver a message resides with SWIFTNet SnF. The message is then “pushed” from SWIFTNet SnF and is received by an application server on SWIFTNet Link. The server application has to ensure that the message is safestored before responding with an acknowledgement. This acknowledgement indicates to SWIFTNet SnF how the message was received. An acknowledgement does not contain any other additional “business” logic.

Queues in SWIFTNet

Queues contain the messages and files that were sent by the Sender to be delivered to the specified Receiver. Queues contain as well the delivery notifications that are generated by SWIFTNet SnF.

Queues are defined and configured by the Receiver’s organization. The actual creation of a queue is done by SWIFT on request of the user. The Sender does not know anything about the queue in which the message will ultimately be put. That is entirely under control of the Receiver.

The queue Window Size attribute controls the maximum number of messages SWIFTNet SnF retrieves from a queue without acknowledgement. The receiver still has to acknowledge the message before the slot in the window is freed up.

Delivery into a Queue

For services using store-and-forward the Receiver decides which queue will be used to store the message that was sent in store-and-forward mode.

Delivery notifications are put into a queue of the Senders institution, to inform the Sender about the delivery status of a message sent. This is configurable with the send adapter properties.

Sessions

When acquiring a queue, a session is started. The Sw:SnFSessionId is returned for every message that is delivered by SWIFTNet SnF. The Sw:SnFSessionId contains the queue name, the session mode: push, and a session number. The session number is incremented for every session. An example is:

<Sw:SnFSessionId>bankwxyz_applicq1:p:000458</Sw:SnFSessionId>

The “p” indicates a push session. A session can also be seen as a reservation of the queue by an Authorizer. The subsequent messages have to be acknowledged by the same Authorizer.

Sessions are not applicable when sending messages to store-and-forward.

Push session SnF

The SnF sequence assumes the following:

  • The client process has done its job and can now terminate. To do this, the open security contexts must be cleaned up by issuing an SwSec:DestroyContextRequest. After the Sw:TermRequest, the process may exit().

  • Another client is started. The initialization steps are the same as for the first client. The release of the queue is by performing an SwCall with the Sw:ReleaseSnFQueueRequest as input primitive.

    SWIFTNet stops delivery of messages from the queue as soon as it successfully processes the release of the queue.

    The server processes one request at the time. SWIFTNet SnF delivers several requests out of the queue. These are buffered within the network and SWIFTNet Link until the server responds, or a timeout occurs.

    It is possible that some requests were already being delivered, but not yet acknowledged before releasing the queue. SWIFTNet SnF does not process any more acknowledgements for these messages until the queue is released. These messages will be re-delivered in a subsequent session.

    It is left to the local implementation whether the server application still responds with a positive acknowledgement for requests delivered from a queue after the client has issued the release of that queue, but typically this would not be the case.

See Also

InterAct Adapter Architecture
InterAct Adapter Components
InterAct Adapter Messages for Business Exchange
InterAct Adapter Client Application
InterAct Adapter Server Application
InterAct Adapter Security Architecture
InterAct Adapter End-to-End Reliable Delivery
InterAct Adapter Status Monitoring
InterAct Adapter Non-Repudiation