SnF sessions

Messages and files that are sent using SnF delivery mode (see Delivery modes) are stored by SWIFT in an SnF queue, from which the receiver can retrieve them:
Sending messages and files using SnF delivery mode
When using SnF delivery mode, there are two ways to send a message and one way to send a file:
  • When sending a message, the sending application can specify the name of an input channel in the SendMsg request. When an MSIF SWIFT operator opens the input channel, the SIPN establishes an input-channel session with an MSIF transfer service, which passes to the SIPN all pending messages that specify that channel. The SIPN puts the messages into the appropriate SnF queues. The MSIF SWIFT operator discontinues an input-channel session by closing the corresponding input channel. An input channel cannot be used to transfer files.
  • If the sending application does not specify the name of an input channel in the SendMsg request, an MSIF transfer service passes the message or file to the SIPN without employing a channel session. The SIPN puts the message or file into the appropriate SnF queue.
Retrieving messages and files from an SnF queue
There are two ways to retrieve a message or file from an SnF queue.
  • An MSIF SWIFT operator can open an output channel. The SIPN establishes an output-channel session with an MSIF transfer service and passes to it the contents of the SnF queue (both messages and files). That MSIF transfer service initiates a new MsgReceived or FileReceived scenario for each message or file it receives. Each output channel is associated with exactly one SnF queue, although it is possible for several different output channels to be associated with the same SnF queue. The MSIF SWIFT operator discontinues an output-channel session by closing the corresponding output channel.
  • An MSIF SWIFT operator can acquire an SnF queue. The SIPN establishes a queue session with an MSIF transfer service and passes to it the contents of the queue (both messages and files). In FTM SWIFT this is called an SnF queue session. The MSIF SWIFT operator discontinues a queue session by releasing the corresponding SnF queue.
    Note: SnF queue sessions are deprecated. The preferred way is to use SnF output channels.

Only one of these types of sessions (output-channel or queue) can be active at any one time for a particular SnF queue. Each channel session is identified by a token, which is assigned by the SIPN when the session is established.

Periodically, an MSIF transfer service automatically contacts each SAG to ensure that active sessions have not terminated unexpectedly. It also automatically processes events sent by the SIPN that indicate when an active session has terminated prematurely.

SnF channels offer the following features:
  • When sending messages:
    Sequence numbering
    Each message that is transferred via a channel session is assigned a sequence number. This number is used to clarify exactly which messages have and have not yet been sent or received. This simplifies the handling of duplicate or out-of-sequence messages, and obviates the need for PDE or PDM indicators (see Possible duplicate handling) except in rare situations such as SnF system recovery.
    Transfer window
    To prevent an MSIF transfer service from passing to an input channel more messages than that channel can comfortably handle, you can propose a transfer window size for each input channel. The SIPN determines the size that is used based on this proposal. The window size limits the number of SnF requests for which a response can be outstanding at any one time for that channel. If this limit is reached, an MSIF transfer service stops placing requests into the channel until the number of requests between the most recent request and the oldest request for which a response is still outstanding drops back below the window size. If a window size option is not set for a channel, the default window size specified by the SIPN is used.
    Input timestamp
    After SWIFT receives a request message, it issues a response. If that response contains an input timestamp (that is, a value in its SnFInputTime field), this indicates that SWIFT was able to store the request in the appropriate SnF queue. If the response does not contain an input timestamp, this indicates that there is currently a gap in the sequence numbering. After a subsequent request resolves the gap, the corresponding response contains input timestamps for all unresolved requests. This makes it easier to determine which messages were successfully sent.
    Automatic resynchronization
    When a channel is reopened, SWIFT returns, in its response, information about previous transfers. If this information indicates a sequence number gap, the sequence numbers are automatically resynchronized.
    SnF system recovery
    Each input timestamp in a response specifies the ID of the current run of the SIPN SnF database that contains the SnF queue in which the corresponding request is stored. If an MSIF transfer service detects a higher level than expected, it automatically initiates the appropriate recovery procedure.
  • When receiving messages or files:
    Parallel sessions (shared queues)
    You can open more than one output channel to an SnF queue, to improve availability and throughput.
    Multi-BIC sessions
    Each SnF queue belongs to one BIC but can contain messages and files of different BICs. However, an output channel to an SnF queue that always belongs to one BIC must still be opened with a DN that belongs to the same BIC.
    Transfer window
    To prevent SWIFT from passing to an output channel more messages than an MSIF transfer service can comfortably handle, you can propose a transfer window size for each output channel. The SIPN determines the size that is used based on this proposal. The window size limits the number of SnF requests for which a response can be outstanding at any one time for that channel. If this limit is reached, the SIPN stops placing requests into the channel until the number of requests between the most recent request and the oldest request for which a response is still outstanding drops back below the window size. If a window size option is not set for a channel, the default window size specified by the SIPN is used.
    Delivery subsets
    For each output-channel session, you can specify which types of messages (InterAct, FileAct, or system) and which priorities of messages (normal or urgent) are to be passed via that session, and in which order. Only messages that meet the specified criteria are passed, and they are passed in the specified order.