Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Prerequisites
There is a list of prerequisites that apply to this configuration.
Please make sure that these requirements are met before proceeding with the configuration.
Some SWIFTNet prerequisites have to be met in order to send InterAct or FileAct messages:
If Role-Based Access Control (RBAC) is used, then SWIFT delivers only those InterAct or FileAct files
for which the sender is a customer with an appropriate RBAC profile. (More RBAC information for
FileAct and Interact).
SWIFT uses the rules defined in the Message Reception Registry (MRR) to determine where to
deliver traffic. (More information)
1
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
Configuration example:
2
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
Defining an Endpoint
An Alliance Gateway endpoint provides a way to specify the end destination for a SWIFTNet Link request
message received from the network.
Endpoints provide the routing configuration for messages entering Alliance Gateway through the SWIFTNet
Interface.
Configuration steps for defining an endpoint can be found in the Alliance Access Configuration Guide.
There is, however, an important difference between Real-Time traffic and Store and Forward traffic:
3
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
Configuration example:
For Real-Time traffic, the SNL Endpoint will depend on the Real-Time service definition. Such a service will
have what is called Primary or Backup route End Point (1 or more) and this is what needs to be specified in
the SNL Endpoint in Gateway. This information is extracted from the last cn levels in the Primary or Backup
Route and order reversed.
Example:
4
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
5
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
The traffic can be segregated based on the routing criteria defined in the Endpoint definition. More
information can be found in Alliance Gateway Administration and Operational guide.
Example for FileAct RealTime doing further segregation, e.g. service name:
Example for InterAct RealTime doing further segregation, e.g. service name:
6
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
If you already have a Gateway connection defined to the Gateway which is configured for FileAct
messaging, you can skip this step.
Otherwise, you can configure your Gateway connection as per the Alliance Access Configuration Guide.
Example of configuration:
7
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
Example of an emission profile for a specific service and FileAct Real-Time traffic:
Example of an emission profile for a specific service and InterAct Real-Time traffic:
8
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
9
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
Please note that you can only have one Real-Time reception profile per SAG connection. This profile will
receive all Real-Time (InterAct and FileAct) traffic for that connection.
Next to the actual output messages, you can also receive delivery notifications.
Three types of delivery notifications exist:
1 Delivery notifications can be received as system messages in which case there is a _SI_from_SWIFTNet
routing rule that forwards these messages to _TR_REC; this is possible only for S&F traffic (InterAct and
FileAct) and when the emission profile parameter Delivery Notif via SysMsg is selected; otherwise, the
delivery notifications are received as internal messages see item 3 below.
2 - Positive Delivery Notifications activated when the emission profile checkbox is ticked; checkbox is
available only if the Messaging Service is FileAct or InterAct & FileAct and the Delivery Mode is Real-Time.
3 (internal - pseudo) InterAct Delivery notifications are automatically forwarded to the MXSystem queue
with a copy to the _TR_REC routing point; this copy instance is not visible in the Access routing windows.
By default, these notifications are completed, unless you add a routing rule in the _TR_REC routing point to
forward them to the _TR_Notif routing point. You can then modify the existing routing rules to adapt them
to your specific needs. Exit points MX/FileDeliveryNotifAck and MX/FileDeliveryNotifNak exist by default in
routing point _TR_Notif.
A Delivery_requested routing keyword can be used to indicate whether a delivery notification was
requested. The value of the keyword is either true or false. This keyword can be used only for routing
FileAct messages.
Store-and-forward queues can contain both messages and delivery notifications (positive or
negative, as specified at message emission time). Messages are stored in store-and-forward queues
as according to the MRR routing rules. Alternatively, you can also select a Delivery Notification
Queue in your emission profile that is used to store store-and-forward delivery notifications.
The SAA Traffic Reconciliation component must reconcile the delivery notification with the original
message instance. To do this, the pseudo MX delivery notification message, or the delivery
notification system message (depending on the setting of the emission profile field Delivery Notif
via SysMsg), is created and routed to the _TR_REC queue through an internal routing rule.
In case of Real-Time: see tip 5017844 - How to route Delivery Notification for FileAct Real-time messages.
10
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
These parameters trigger the usage of features within SWIFTNet or describe what a messaging interface
must do with traffic sent or received. The Application Service Profile parameters determine how Alliance
Access handles these features.
The installation steps and download link for the latest ASPs are provided here.
You can implement RMA for non-FIN services by using bootstrap (also known as local) authorisations for
services that are in a migration period, that is, existing services that originally did not require authorisation.
Implementing RMA for non-FIN services involves adding bootstrap authorisations in the Alliance Access
RMA data store. For bootstrap authorisations, no RMA messages are exchanged over SWIFTNet. Create a
Bootstrap Authorisation should be performed using RMA GUI.
FileAct Tools:
11
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015
12