Direct FileAct

Connectivity
Alliance Access 7.0
Direct FileAct
Information Paper
Table of Contents
Preface .................................................................................................................................................3
1
Overview ....................................................................................................................................4
1.1
1.2
Current Situation .....................................................................................................................4

Evolution Rationale .................................................................................................................7
Direct FileAct Features ............................................................................................................8
Flows ........................................................................................................................................10
3.1
3.2
3.3
3.4
3.5
Back office Emission .............................................................................................................10

Response Files Concept .......................................................................................................12
Back Office Reception...........................................................................................................14
Manual Emission ...................................................................................................................15
Constraints ............................................................................................................................16
Legal Notices ....................................................................................................................................17
Direct FileAct Information Paper
Version 1.1
May 2010
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
March 2010
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 <Body> 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'.
Access Direct FileAct Information Paper
Version 1.1
May 2010
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:
March 2010
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 <Body> 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.
Version 1.1
1.2
May 2010
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
March 2010
Direct FileAct can also benefit customers looking at prototyping a new FileAct
integration before investing into an XMLv2 based integration.
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.
Version 1.1
May 2010
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
March 2010
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
10
Version 1.1
May 2010
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):
March 2010
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.
11
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.
12
Version 1.1
May 2010
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.
March 2010
13
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.
14
Version 1.1
3.4
May 2010
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.
March 2010
15
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.
16
Version 1.1
May 2010
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.
March 2010
17

Direct FileAct

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Direct FileAct

Uploaded by

Copyright:

Available Formats

Connectivity

Alliance Access 7.0

Current Situation .....................................................................................................................4

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

Back office Emission .............................................................................................................10

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

Direct FileAct Information Paper

Below an example of an XMLv2 specification for a FileAct transaction, referring to a payload

Access Direct FileAct Information Paper

Back Office Integration Logic

Figure 1: Back Office FileAct Integration based on XMLv2

Application to Application Mode only

Access Direct FileAct Information Paper

Direct FileAct Features

Figure 2: Overall Direct FileAct Architecture

Access Direct FileAct Information Paper

Figure 3: Direct FileAct emission logic

Figure 4: Direct FileAct reception logic

Back office Emission

Figure 5: Direct FileAct detail emission flow

Access Direct FileAct Information Paper

As a result of TR_REC processing, a Delivery Notification Instance is created for the

Response Files Concept

StoredTransferRef is the reference assigned by SWIFTNet to

TransferRef is the reference assigned by SWIFTNet to the

TransferRef is the reference assigned by SWIFTNet to the

SnFRef is the reference assigned by SWIFTNet to the initial

SnFRef is the reference assigned by SWIFTNet to the initial

Advanced Notification Features

Access Direct FileAct Information Paper

Figure 6: Direct FileAct advanced notification support

Back Office Reception

Figure 7: Direct FileAct detail reception flowt

A SWIFTNet FileAct transaction is received from a SWIFTNet Reception profile in

No response file is generated for this flow.

Access Direct FileAct Information Paper

This manual activation, when compared to a similar manual initiation supported by

No Y/T Copy support

Access Direct FileAct Information Paper

You might also like