direct fileact

Connectivity

Alliance Access 7.0

Direct FileAct

Information Paper

2 Direct FileAct Information Paper

Table of Contents Preface ................................................................................................................................................. 3

1 Overview .................................................................................................................................... 4

1.1 Current Situation ..................................................................................................................... 4 1.2 Evolution Rationale ................................................................................................................. 7

2 Direct FileAct Features ............................................................................................................ 8

3 Flows ........................................................................................................................................ 10

3.1 Back office Emission .............................................................................................................10 3.2 Response Files Concept .......................................................................................................12 3.3 Back Office Reception...........................................................................................................14 3.4 Manual Emission ...................................................................................................................15 3.5 Constraints ............................................................................................................................16

Legal Notices .................................................................................................................................... 17

Version 1.1 May 2010

March 2010 3

Preface Purpose of this document

This document provides an overall description of the Direct FileAct functionality, a new adapter of Alliance Access 7.0.

Intended audience

This document is intended for project managers, allowing them to validate the integration of a simple FileAct based integration, based on this new Direct FileAct feature provided by Access 7.0.

Related documentation

Alliance Access/Entry 7.0 Functional Overview

Alliance Access - System Management Guide

Alliance Access - Installation and Administration Guide

4 Access Direct FileAct Information Paper

1 Overview

1.1 Current Situation

Access 6.3 FileAct Support

With Access 6.3, the support for FIN and InterAct has been complemented with FileAct support, providing a single integration point for back office applications to exchange FIN and InterAct messages, as well as FileAct based exchanges.

In order to support the emission of files, a back office application communicating with Access 6.3 to exchange files needs to:

Provide the actual file to exchange (the payload file).

Specify the FileAct settings to be used for the transmission of the file.

When receiving a file, the back office application needs to:

Process the received payload file

Optionally, analyse the FileAct settings specified for the transmission of the file by the correspondent.

The XMLv2 format (Revision 1) is the basis to support the specification of the FileAct settings. This format has already been available in previous Access 6.x releases, in order to support InterAct messages (and also FIN messages). Some of the key fields that must be specified for an InterAct transaction are:

Sender DN and Receiver DN

Service Name and Request Type

InterAct format

With Access 6.3, the XMLv2 format has been revised (Revision 2) to also support the specification of FileAct settings. Some of the InterAct related fields are also applicable for a FileAct transaction. Additional fields, specific to a FileAct transaction have been added, like:

File logical name

File description

The file providing the XMLv2 definition only contains the FileAct settings. The actual payload file is provided separately. For a FileAct specification, the XMLv2 element does not provide the file content but instead specifies the name of the associated payload file.

Below an example of an XMLv2 specification for a FileAct transaction, referring to a payload file named 'payments.fct'.


March 2010 5

Note The XMLv2 also supports specification of FIN messages. This functionality is not relevant in the scope of this paper and will not be further detailed.

Note With Access 6.3, FileAct is only supported by the File Transfer adapter. FileAct support over IBM WebSphere MQ is planned for Access 7.0, via an enhanced version of the MQHA adapter. FileAct support over SOAP adapter is planned for a later release.

Back Office Integration Logic

In order to initiate a file exchange, a back office application must therefore provide two files to Access 6.3:

The payload file, which can be of any format

The companion file specifying the FileAct settings, in XML V2 format (revision 2).

Access 6.3 File Transfer adapter processes the XMLv2 file, and for a FileAct specification, locates the payload file whose name is provided in the XMLv2 body tag and emits it to SWIFTNet.

The File Transfer adapter can also produce the various notifications (network transmission status, delivery notification status) related to a FileAct transaction. These notifications are also available via XMLv2 based reports.

The picture below provides an overall view of the various elements used for a FileAct exchange, based on XMLv2 support:


Figure 1: Back Office FileAct Integration based on XMLv2

Pros

The main benefit of this integration enables the back office to precisely control all FileAct settings via the XMLv2 file and to have a detailed view on the transmission status.

It also enables to define an additional counterparty by adapting the back office application without requiring re-configuration of Access.

Cons

In case the payload file is already produced by a back office application, additional development effort will need to be invested to produce the additional XMLv2 file, and possibly to parse the XMLv2 based notification reports to analyse the various transmission and delivery statuses.

Application to Application Mode only

Access 6.3 FileAct support logic is mainly suitable for application to application communication, using the File Transfer adapter, in combination with the AFT license. The File Transfer adapter is configured in automatic mode, and automatically processes the files provided by the back office application.

The File Transfer adapter also supports manual session initiation by an operator. This method is not suitable for manually initiating a FileAct session, as the user cannot directly select the payload file, but must instead select the XMLv2 file, containing the FileAct settings. Access will then process the corresponding payload file specified in the element.

This working method is not practical for initiating a manual session. In order to support the User to Application mode, the user should be able to directly select the payload file. This method is not supported by Access 6.3 File Transfer adapter, which is always driven the by the XMLv2 file, containing either a FIN, InterAct or FileAct message.


March 2010 7

1.2 Evolution Rationale The primary objective of evolving FileAct support in Access 7.0 is to enable back office applications already producing the payload file to easily integrate with Access, and not requiring any specific development work to send these files over SWIFTNet FileActIn short, the back office can continue to simply produce the payload file. It can provide the files to Access that will generate the associated FileAct transaction.

This new Access functionality will greatly facilitate integration of existing back office applications producing files, which can kept unchanged, and which will rely on Access configuration to determine the FileAct settings to be used for the file exchange.

This evolution will be provided by a new type of file based adapter in Access 7.0, referred to as 'Direct FileAct' adapter, which can trigger a FileAct transaction by receiving a payload file only.

This capacity to handle a payload file only will also enable a user to manually initiate a FileAct exchange, allowing the user to directly select the payload file to initiate the transaction. Access configuration will determine the FileAct settings to be used for the exchange.

This adapter will be available as a licensable option in Access 7.0.

The remaining sections of this document explain the functionality of this adapter and how FileAct flows can be implemented using this adapter.

Note Direct FileAct can also benefit customers looking at prototyping a new FileAct integration before investing into an XMLv2 based integration.


2 Direct FileAct Features This direct integration of FileAct flows is a new feature supported by Access 7.0 only (it is not available for Entry 7.0). It is provided by a new file based adapter, with the connection method 'Direct FileAct', enabling the exchange of payload files to support FileAct exchanges.

The Direct FileAct adapter has common characteristics with the regular File Transfer adapter, sfor example:

Supports bi-directional exchange ('From' and 'To')

Specification of a data directories where the adapter processes (reads or writes) the payload files.

Supports manual initiation of the session by an operator, although a main difference for the adapter is to allow the direct selection the payload file (and not the selection of the XMlv2 file as in the File Transfer adapter).

Automatic initiation of a session, based on a polling time, to regularly scan payload files present in the data directory.

The Direct FileAct adapter has also some specific settings

FileAct specific configuration, holding the settings to be used for the FileAct exchange associated to the message partner.

As depicted in the picture below, the administrator will configure a Direct FileAct message partner for each service and correspondent to communicate with. Each message partner will statically hold the FileAct settings required to communicate with a specific correspondent.

Figure 2: Overall Direct FileAct Architecture

The Direct FileAct adapter will establish an association between a set of directories and a FileAct correspondent. The FileAct configuration is defined manually by the administrator for each message partner. An integration based on Direct FileAct is primarily intended for customers with simple FileAct integration needs communicating with a limited number of correspondents.

The Direct FileAct adapter supports the basic FileAct services. For advanced FileAct features like Y/T copy mode, or file distribution, an integration based on XMLv2 is required.


March 2010 9

For an emission flow, the Direct FileAct adapter supports the reception of the payload file from the back office, and the report of the associated FileAct network transmission and delivery statuses (if used).

Figure 3: Direct FileAct emission logic

For a reception flow, the Direct FileAct adapter will generate the payload file, named by combining the logical file name and the file transfer reference. The file will be stored in the data directory associated to the message partner, ready to be processed by the back office.

Figure 4: Direct FileAct reception logic


3 Flows This section explains the various flows supported by the Direct FileAct adapter:

File emission, either automatic or manual, with reception of transmission notification, and optionally, delivery notifications

File reception

3.1 Back office Emission The overall workflow supported for emission of files via the 'Direct FileAct' is shown below.

Figure 5: Direct FileAct detail emission flow

The different steps are:

1. The back office application drops a payload file into the data directory associated to a Direct FileAct message partner. In this example, the file is named filename.ext.

2. The Direct FileAct message partner automatically detects the file and processes it.

3. The Direct FileAct message partner creates a FileAct based message. The FileAct settings, required to exchange the file over SWIFTNet, are extracted from the FileAct configuration associated to the message partner.

The following FileAct settings are configured for the message partner and used to generate the FileAct message:

Requestor DN

Responder DN

Service

Request Type

Priority

Access automatically calculates the payload file digest, based on the digest calculation algorithm set in the File Digest Algorithm System Configuration parameter.

It is important to note that the generated FileAct message is identical to any other FileAct messages generated from another type of adapter. In other words, standard Access FileAct features (like message consultation, printing, routing, etc) can be applied on this message.

This FileAct message can also be consulted with the Web Platform and printed like any other FileAct messages in Access database (as for any FileAct message, the message


March 2010 11

details can be examined, but the actual file content is not viewable from the Web Platform).

4. Default Access routing rules are configured to send this FileAct message to the SWIFTNet interface, onto the appropriate emission profile.

The emission of the file over SWIFTNet FileAct is performed by the SWIFTNet Interface.

The following settings, stored in the SWIFTNet Emission Profile, are used to generate the final SWIFTNet FileAct transaction:

Delivery Mode (real-time or Store and Forward)

Delivery Notification settings (with corresponding Responder DN/Request Type or Delivery Notification Queue)

Non Repudiation Required

Signing Required

Windows Size and Retry Limit

5. On completion of file transfer, the routing rules defined at the _SI_to_SWIFTNet will typically generate a Transmission Notification Instance that is sent to another Direct FileAct adapter, configured in 'To' mode (i.e. emission to a back office).

6. The Direct FileAct adapter generates a response file to indicate the successful completion of the file transfer. This is indicated by the name of the response file generated : filename.ext.TransferRef.ok.

The response file itself is empty. The back office does not need to parse the file content. It simply needs to examine the filename extension to determine the status of the transmission.

In case of a failed transmission, the generated response file, also empty, will be named filename.ext.TransferRef.err.

The following steps only occur if the delivery notification option was requested for this FileAct exchange (available for Store and Forward FileAct mode only):

7. The Delivery Notification message is received from SWIFTNet. The message when routed to the TR_REC module will be reconciled with the original message instance.

8. As a result of TR_REC processing, a Delivery Notification Instance is created for the original message. This instance is routed to the Direct FileAct adapter, in 'To' mode.

9. The Direct FileAct adapter, generates another response file. For a successful delivery notification, the file is named filename.ext.SnFRef.dlok.

In case of an unsuccessful delivery notification, the file will be named filename.ext.SnFRef.dlnok.

Again, the response file is empty. The back office simply needs to look at the file name to determine the delivery notification status.


3.2 Response Files Concept

Overview

Direct FileAct provides a simple way for a back office application to be informed about the various statuses of the file transfer, i.e. the network transmission status and the eventual final delivery notification status.

This is the purpose of the Response Files, which are used to provide such notifications.

The Response File concept is based on the prime assumption that a back office application using Direct FileAct integration should require bare minimal development to integrate with Access. Also, the integration should not require the development in the back office application of logic to generate or parse XML based files.

This is the main driver for the following Response File concepts:

The notification information is provided by means of producing an empty file, with a file name convention to indicate the different statuses.

The response file itself is empty.

The integration of notification status is based on a simple, file name parsing logic, which is either already supported by a back office application, or can be easily integrated into a back office application by implementing file parsing logic in system scripts.

In the table below, the file initially submitted by a back office application for emission to SWIFTNet is filename.ext. Filename.ext* is the resulting file name, possibly updated to only contain the A-Za-z0-9._ characters (any other character in filename.ext being replaced by the _ character):

Response File Name Comments

Filename.ext*.StoredTransferRef StoredTransferRef is the reference assigned by SWIFTNet to the initial FileAct Input message sent by the sender to SWIFTNet

Filename.ext*.TransferRef.ok TransferRef is the reference assigned by SWIFTNet to the initial FileAct Input message sent by the sender to SWIFTNet. It is communicated to Access in the network acknowledgment.

Filename.ext*.[TransferRef.]err TransferRef is the reference assigned by SWIFTNet to the initial FileAct Input message sent by the sender to SWIFTNet. It is communicated to Access in the network negative acknowlegment (nak). It is present only if the message was rejected after the point where SWIFTNet assigns a TransferRef.

Filename.ext*.SnFRef.dlok SnFRef is the reference assigned by SWIFTNet to the initial FileAct Input message sent by the sender to SWIFTNet

Filename.ext*.SnFRef.dlnok SnFRef is the reference assigned by SWIFTNet to the initial FileAct Input message sent by the sender to SWIFTNet

Advanced Notification Features

The information returned by a response file is limited to the network status. It does not contain any additional information (such as detailed authentication information or reason for rejection or delivery notification). This is the consequence of providing a simple, file name based convention logic to return information to a back office application.

If a back office application can support more sophisticated integration logic, it is still possible to generate detailed notification information. As shown in the diagram below, it is possible to create, via Access routing, an additional copy of the transmission notification instance, and send this to a standard File Transfer adapter.


March 2010 13

This adapter will in turn generate an XMLv2 based notification report, containing all the details of the transmission notification.

Figure 6: Direct FileAct advanced notification support

The same logic can be applied to network delivery notifications.


3.3 Back Office Reception The overall workflow supported for reception of files via the 'Direct FileAct' is shown below.

Figure 7: Direct FileAct detail reception flowt

The different steps are:

1. A SWIFTNet FileAct transaction is received from a SWIFTNet Reception profile in Access. This can be a real-time or a Store and Forward transaction.

2. The resulting FileAct message is routed to a Direct File Message partner, configured in 'To' mode.

3. The Direct FileAct message partner generates a payload file, in the data directory configured for this message partner.

The payload filename is based on the incoming FileAct logical file name, possibly updated to only contain the A-Za-z0-9._ characters.

The SWIFTNet transfer reference is also appended to the filename, to ensure uniqueness.

4. The back office application processes the payload file present in the data directory.

No response file is generated for this flow.


March 2010 15

3.4 Manual Emission The Direct FileAct adapter, in 'From' mode, can be configured to support a manual initiation of a FileAct transaction. In that mode, the entitled operator will start a Direct FileAct session. The operator is required to select a payload file for this FileAct transaction.

The remaining steps are identical to an automatic initiation (See Back office Emission on page 10), starting at Step 3).

The generation of response file is also supported in this manual mode, although its usage might be very limited in a manual initiation scenario. The operator can instead use the Messenger function (or Message File on Workstation) to monitor the file emission progress.

Note This manual activation, when compared to a similar manual initiation supported by File Transfer GUI module on WebStation, only allows the operator to select the payload file. All other FileAct settings are controlled by Access, either via the FileAct configuration of the Direct FileAct adapter, or by the routing to the appropriate SWIFTNet Emission Profile for other FileAct transmission settings. In other words, the operator cannot control to what service, correspondent the file will be sent. It is only determined by the message partner that is used to manually start the session.


3.5 Constraints

Directory Mapping

The core design of the Direct FileAct adapter is a mapping between a directory with a correspondent for a given service. This configuration is primarily suited to handle a limited number of correspondents with a few services, in order to keep the number of directories to manage under control.

Duplicate detection

Direct FileAct shares the same logic for duplicate detection as for other FileAct flows in Access. For back office emission, the payload file itself is not checked for duplicate by Access, but the duplicate detection logic, based on the file digest calculation will apply to the File message. It will allow to detect file with an identical file digest and to potentially route these duplicate transactions in Access.

Digest Calculation

The global Access File Digest Algorithm system configuration parameter is used to select the algorithm used to compute the file digest for files sent over Direct FileAct.

Polling Timer

The scanning of Direct FileAct data directories (in From mode) is based on the frequency defined by the already existing Automatic Polling Timer System Configuration Parameter.

No LAU support

Direct FileAct adapter does not support the configuration of LAU settings to secure payload files.

If a secured, LAU based integration is required, the File Transfer adapter should be used instead, which fully support LAU based security via XMLv2 settings.

No File Compression

Similar to the FileAct support via XMLv2, as provided Access 6.3, the Direct FileAct adapter does not support automatic file compression.

No Y/T Copy support

Y-Copy and T-Copy modes are not supported by Direct FileAct.

At each launch of a Direct FileAct session, Access will verify the associated FileAct service configuration, and will abort the session if the service is configured in Y-Copy or T-Copy mode.


March 2010 17

Legal Notices Copyright

SWIFT 2010. All rights reserved.

You may copy this publication within your organisation. Any such copy must include these legal notices.

Confidentiality

This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside your organisation without the prior written consent of SWIFT.

Disclaimer

The information in this publication may change from time to time. You must always refer to the latest available version on www.swift.com.

Translations

The English version of SWIFT documentation is the only official and binding version.

Trademarks

SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the SWIFT logo, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners.

direct fileact

Documents

fileact support

fileact settings

simple fileact

direct fileact functionality

direct fileact features

new direct fileact feature

connectivity alliance

current situation access