Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015

Configuring Alliance Access and Alliance

Gateway for InterAct/FileAct Messaging
Description
This document describes the required configuration before you can send and receive FileAct or InterAct
messages.

The main tasks are:

For Alliance Gateway

o Defining a message partner
o Defining an endpoint
For Alliance Access
o Defining a Gateway connection
o Configuring SWIFTNet emission and reception profiles
o Installing Application Service Profiles (ASPs)
o Generate RMA Authorisation or Bootstrap Authorisation
o Send and Receive FileAct or InterAct message

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)

Alliance Gateway Configuration

Defining a Message Partner

If you already have a message partner defined for SWIFTNet traffic for your Alliance Access instance (e.g.
sni_<Access instance>), you can skip this step.

Otherwise, you can configure a Message Partner as shown in the guide.

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.

Example of general configuration:

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

Store and Forward (SnF) traffic:

Make sure that the FileAct or InterAct is allowed as a Traffic Type and that SnF is allowed as a Delivery
mode.

Configuration example:

Real-Time (RT) traffic:

In order to process Real-Time FileAct or InterAct traffic on your endpoint, you will have to add an additional
routing criteria to the existing Gateway endpoint for SNI. The Traffic Type should allow FileAct or InterAct
and the Delivery mode should be set to Real-Time.

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:

FileAct Service: swift.devsup.fa!x1

Primary route: cn=coex,cn=fasnl,cn=snl00399,ou=itl,o=swift, o=swift
The SNL endpoint will be fasnl_coex

4
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015

InterAct service: swift.devsup!x1

Primary route: cn=swhq,cn=iasnl,cn=snl00399,ou=itl,o=swift,o=swift
The SNL endpoint will be iasnl_swhq

Configuration example for FileAct RT:

Configuration example for InterAct RT:

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

Alliance Access Configuration

Defining a Gateway Connection
In order to connect to SWIFTNet, Alliance Gateway connections must be configured in Alliance Access.

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

Configuring SWIFTNet emission and reception profiles

In order to exchange messages through SWIFTNet, you must define, enable, and activate SWIFTNet
emission and reception profiles for FileAct messaging

The configuration steps for these profiles can be found here.

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

Example of a reception profile for Real-Time (InterAct and FileAct) traffic:

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.

Alliance Access Routing Rules

Inside of Alliance Access it is possible to route messages based on message keywords.
The list of message keywords specifies which routing keywords can be used for InterAct or FileAct
messages.

The messages or files will be received in the _SI_from_SWIFTNet routing point.

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.

In case of Store-and-forward: (copy from SAA config guide)

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

Installing Application Services Profiles (ASPs)

An Application Service Profile is a structured set of parameters that messaging interfaces and applications
use to send and receive traffic correctly on a particular SWIFTNet service.

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.

Generate RMA Authorisation or Bootstrap Authorisation

An authorisation is tied to a specific service for InterAct or FileAct. The application service profile for the
service specifies whether the traffic for that service requires authorisation before it is sent.
In the application service profile of the service, if the field RMAFeatureUsed is set to true, then the
messages for that service require authorisation. The Creation and Activation of Authorisations should be
performed using RMA GUI.

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.

More information can be found in Relationship Management Guide.

Send and Receive InterAct or FileAct message

Application Interface:

Direct FileAct (FileAct only)

File Transfer
SOAP
WebSphere MQ

Message Management GUI:

File Message: Send (FileAct only)

File Message: Get (FileAct only)
Create MX messages (InterAct only)
Create a Message from Message Template (InterAct only)

FileAct Tools:

11
Configuring Alliance Access and Alliance Gateway for InterAct/FileAct Messaging Sep 10th 2015

saa_rtfilegetrequest (AIX, Solaris, Linux, Windows)

Alliance Access Operator Profiles

The operator profile permissions needed to respectively send and get FileAct messages can be found in the
message management guide:

Send a File Manually (FileAct only)

Download a File Manually (FileAct only)
Create messages (InterAct only)

12