radianz messaging · 4 message queue interface 12 4.1 overview 12 4.2 websphere mq versions 12 4.3...

Radianz Messaging

SettleNET Gateway Application

Interface Specification

SettleNET Gatew ay Application Interface Specif ication

Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

COPYRIGHT

Confidentiality statement This document and all information contained therein is provided to BT’s customers in confidence for the sole purpose of the use of, and in association with the BT Radianz

Messaging SettleNET service. The document shall not be used for any other purpose, shall be held in safe custody and shall not be copied, published or disclosed wholly or in part to any other party without BT’s prior permission in writing. These obligations shall not apply to

information which is published or becomes known legitimately from a source other than BT.

SettleNET is a registered trademark of BT.

Many of the product, service and company names referred to in this document are trademarks

or registered trademarks. They are all hereby acknowledged.

BT 2019, all rights reserved


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

Table of Contents

1 INTRODUCTION 6

1.1 Objectives 6

1.2 Scope 6

1.3 Assumptions 6

1.4 Document Structure 6

1.5 Terminology 6

2 SETTLENET, BT RADIANZ MESSAGING & IFM 8

3 BACKGROUND 9

3.1 Introduction 9

3.2 Installation Overview 9

3.3 Using the SettleNET (IFM) Gateway 10 3.3.1 Channels 10

3.4 Secure Communications Manager 10

3.5 Interfaces 11

4 MESSAGE QUEUE INTERFACE 12

4.1 Overview 12

4.2 WebSphere MQ Versions 12

4.3 Message Queues 12

4.4 Setting up MQTM 13

4.5 Putting a transmit message 14

4.6 Getting a receive message 15

4.7 MQ Message Header fields 16 4.7.1 Message ID (field MsgId) 16 4.7.2 Message Format 16 4.7.3 ReplyToQ, ReplyToQManager 16 4.7.4 Exemptions 16 4.7.5 EBCDIC Conversion 16

4.8 Message Sizes 16

4.9 Message Ordering 16


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

4.10 Backout Queue / Dead Letter Queue 17

4.11 Inhibiting Queues 17

4.12 Starting MQTM 17

4.13 Stopping MQTM 17

4.14 Automatic Queue Reconnection 17

5 FILE TRANSFER INTERFACE 18

5.1 Overview 18 5.1.1 Files 18 5.1.2 Messages 18

5.2 Setting up shared directories 19

5.3 Service ID, Application Service and Channel ID 19

5.4 Transmit Directory Structure 19

5.5 Receive Directory Structure 20

5.6 Status and Control files 20

5.7 File Names 21

5.8 File Format 21

5.9 Directory Clean Up 21

5.10 Transmitting a file 22

5.11 Receiving a file 23

5.12 Secondary Receive Directory 24

5.13 FTM Watchdog 24

5.14 Starting the FTM 24

5.15 Stopping the FTM 25

5.16 Directory Creation 25

5.17 Enabling and Disabling 25

5.18 Adding and Deleting Channels 25

5.19 Lost File Receipts 25

5.20 File Checking Order 26 5.20.1 Transmit Sub-Directories 26 5.20.2 Receive Sub-directories 27

6 FILE TRANSFER SERVICE COMMUNICATIONS PROTOCOLS 28


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

6.1 NFS 28

6.2 FTP 28

6.3 FTPS 28

6.4 SFTP 28

6.5 Samba 28

6.6 OpenText NFS Client (formerly Hummingbird) 28

7 CONSIDERATIONS 29

7.1 Load balancing and resilience 29

7.2 Event Logging 29

8 APPENDIX A. BT RADIANZ MESSAGING APPLICATION SERVICES 30

9 APPENDIX B. FILE/MESSAGE NAMING CONVENTIONS 31

10 APPENDIX C. FTM: STATUS FILE DATA FORMAT 32

11 APPENDIX D. FTM STATUS CODES 35

12 APPENDIX E. DISCONNECT REASON CODES (MQTM & FTM) 45

13 APPENDIX F. ERROR CODES (MQTM & FTM) 48

14 REFERENCES 52

Table of Figures Figure 1 - A Typical Back Office Connection (Physical) .......................................................................... 9 Figure 2 - MQ Message exchange for a single Channel ....................................................................... 12 Figure 3 - MQ TRANSMIT message handling ....................................................................................... 14 Figure 4 - MQ RECEIVE queue handling............................................................................................... 15 Figure 5 - File Transfer ........................................................................................................................... 18 Figure 6 - FTM Transmit handling .......................................................................................................... 22 Figure 7 - FTM Receive handling ........................................................................................................... 23 Figure 8 - Watchdog Directory Structure................................................................................................ 24


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

1 Introduction 1.1 Objectives

This document defines the interfaces available for connecting back office applications to Release 5.2 of the BT

SettleNET (IFM) Gateway application. These interfaces allow applications (or middleware products) to exchange data with one or more CREST Application Services.

1.2 Scope

This document is designed for back office application / middleware development and integration teams and:

Provides an overview of the SettleNET (IFM) Gateway application

Defines the MQ interface

Defines the File Transfer Interface

Specifies file transfer Status File formats

Lists Status and Disconnect reason codes

Provides file and message naming convention rules

Shows CREST related Application Services The document does NOT describe the way in which the SettleNET (IFM) Gateway application supports GUI

based services.

1.3 Assumptions

It is assumed the reader has some knowledge of IBM WebSphere MQ and file transfer concepts in general.

1.4 Document Structure

The second section of this document provides some background on BT Radianz Messaging. This is followed by a series of sections describing each interface. The document concludes with a number of appendices providing

detailed information on services, message/ file naming, status / error reporting.

1.5 Terminology

The document uses the following terms:

Application Service A computer application such as the CREST electronic share settlement system.

Channel A communications path which connects two network end users, such as an Application Service Provider and a user.

Communications Host A central BT Radianz Messaging computer system that

coordinates Gateway transfers and ensures message security, integrity and audit logging.

CREST Crest Application Service for DEX messages

CRISO Crest Application Service for ISO15022 messages

DEX Data Exchange Manual (or 'DEX' standards) – proprietary CREST message format

FIFO First In First Out

File An Application Service-specific file which may comprise


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

one or more discrete messages, depending on specific Application Service requirements.

File Transfer Manager (FTM)

The part of the Gateway application that sends and receives files via a shared directory structure.

Gateway Secure

Communications Manager (SCM)

Part of the Gateway application – a Windows service that manages and maintains FTM, and MQTM components.

IBM MQ Series ™ IBM messaging infrastructure now known as WebSphere MQ

IBM Websphere MQ ™ IBM messaging infrastructure

IP Internet Protocol

IP Connect BT Portfolio product, with variants for UK & Global (both implemented using MPLS technology)

ISO15022 ISO 15022 is a securities messaging standard. It replaces the previous securities messaging standard ISO 7775.

Message Queue Transfer Manager (MQTM)

The part of the Gateway that processes message received and sent via message queues.

MPLS Multi Protocol Label Switching. A standard for providing

faster and multiple IP Networks over a shared core physical infrastructure, each in a Virtual Private Network.

MQ Message Queue (used in this document only as a shorthand for “IBM Websphere MQ”)

MQ Channel An MQ channel connects an application to a queue

manager, allowing the application to read and write messages to an MQ queue

Platform An assembly of Hardware and/or Software and/or Network components that performs a defined set of functions.

BT Radianz Cloud BT Portfolio Product for secure network connectivity.

SettleNET The trademark for BT’s CREST connectivity service (that includes both CREST DEX and ISO 15022).


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

2 SettleNET, BT Radianz Messaging & IFM This chapter int roduces the SettleNET service owned and operated by BT.

BT, and its former subsidiary Syntegra, has operated SettleNET since 1996 providing secure and reliable connection to Euroclear CREST application services. BT has continually enhanced the underlying infrastructure to comply with evolving security and technical standards.

For some time BT has delivered SettleNET using ‘The Infrastructure for Financial Markets’ (IFM) a secure and resilient private network product. This has utilised ISDN and leased-line user connections and, more recently, introduced connections using BT Radianz Cloud and IP Connect network products.

BT has now integrated a number of its secure messaging operations into a single product known as ‘BT Radianz Messaging’and IFM is now superseded by BT Radianz Messaging.

The term ‘Infrastructure for Financial Markets (IFM)’ is still retained in some respects such as in the

SettleNET (IFM) Gateway application but will be phased out completely over time.

BT Radianz Messaging is a product delivering secure and cost-effective services to users in the Financial Services business. BT Radianz Messaging gateway systems delivered to customers include the bespoke

SettleNET (IFM) Gateway application that is required for CREST connectivity as well as new applications supporting a range of other services.

Note: For any references to IFM in this document, other than those associated with the SettleNET (IFM)

Gateway application (e.g. within menus etc.), please assume BT Radianz Messaging is inferred.

In summary – IFM is now a merged part of BT Radianz Messaging. BT now delivers the SettleNET service using BT Radianz Messaging but with the accredited IFM Gateway application still currently supplied in

support of CREST connectivity.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

3 Background 3.1 Introduction

CREST is the central securities depository (CSD) in the UK for the electronic settlement of UK securities operated by Euroclear UKI. SettleNET is BT’s service for CREST connectivity delivered using the BT Radianz

Messaging product. BT Radianz Messaging is designed for market needs, employing industry standard cryptographic techniques to

protect transactions with the expected high degree of fault tolerance and network resilience. This is underpinned by a responsive support service, for initial contact, through ordering and deployment to ongoing day-to-day support.

BT Radianz Messaging employs cryptographic techniques to protect and conceal transactions in transit; non-repudiation services are provided for conflict resolution. For SettleNET, central site systems provide full audit

trail services, recording and archiving all traffic. Customer site installations can be scaled to suit needs enabling the best cost/resilience balance for each

institution. This ranges from a simple connection with single gateway to a multi-gateway configuration with fully resilient multi-path network connectivity.

3.2 Installation Overview

SettleNET installation options include:

One or more network connections A choice of BT Radianz Cloud, BT IP Connect UK or BT IP Connect Global.

One or more Gateways Depending on disaster recovery and/or resilience requirements

One or more managed firewalls Depending on disaster recovery and/or resilience requirements

NB: The interface information within this document is valid for all site configurations.

Figure 1 shows the layout of the BT SettleNET equipment in relation to an institution’s infrastructure.

Figure 1 - A Typical Back Office Connection (Physical)

The BT equipment is remotely managed by BT and provides connection to the BT Radianz Messaging global network. It is recommended best practice that connection to the BT equipment is made via a perimeter firewall.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

The SettleNET (IFM) Gateway application can support concurrent connections to multiple Application Services (e.g. CREST CRISO) however more than one Gateway might be preferred for load balancing and/or resilience.

For resilience, a SettleNET (IFM) Gateway application can be configured as a primary or warm standby backup. For load balancing, an array of Gateways and communications links can be deployed. A BT Customer

Account Manager can provide information on the options available. BT Radianz Messaging is subject to market appropriate technology refresh and service enhancements, such as

withdrawal of – and migration from – older network services such as leased lines and dial-up to one of the network connection services listed above. Future enhancements will continue to support the existing interfaces but also make available new methods of connection. Readers requiring further information regarding BT

Radianz Messaging enhancements should contact their SettleNET Relationship Manager.

3.3 Using the SettleNET (IFM) Gateway

Business transactions can be submitted:

Interactively using the CREST graphical user interface (GUI) or a 3rd party suppliers GUI,

In batches using file transfer services,

In messages via IBM MQ message queues.

This document does NOT describe the way in which the BT SettleNET (IFM) Gateway application supports GUI based services. Readers requiring information regarding GUI services should see Ref 1. or contact a their SettleNET Relationship Manager.

3.3.1 Channels

Data is transported over BT Radianz Messaging through logical channels. CREST provides a number of Application Services (see Appendix A) within each of which multiple channels,

termed in CREST as Operators, can be configured. BT configures the Application Services within the BT SettleNET (IFM) Gateway application in order to ensure

the appropriate security. The Gateway user must then configure the required channels (Operators) for each Application Service.

In practice Channels might be defined in order to separate live business data from test and trial traffic or might be used to allow different business units within an organisation to interact with the Application Service independently. Business transactions submitted through each channel are segregated and processed

independently, with transmit and receive traffic handled concurrently.

3.4 Secure Communications Manager

The central component of the SettleNET (IFM) Gateway application is the Secure Communications Manager

(SCM). The SCM: o Manages the MQ and FTM Gateway interfaces o Receives business data from the back office infrastructure via an interface

o Secures the data o Transmits the secured data to the CREST Application Services o Receives secured data from CREST Application Services

o Verifies the authenticity and integrity of the data o Transmits the data to the back office infrastructure via an interface.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

3.5 Interfaces

Messages and files can be passed using an established messaging infrastructure or a simple file based

interface:

1. Message Queues: a set of message queues are configured to connect back office applications to the

SCM. Transmit queues hold messages destined for the peer Gateway or target Application Service; receive queues hold message data received by the SCM from the peer Gateway or the Application Service. The SCM uses the Message Queue Transfer Manager (MQTM) to service the queues for all

peer connections and Application Services. 2. File Transfer: the Gateway application shares one or more file system directory structures with back

office systems. These shared file systems are used to deposit Files ready for the SCM to retrieve and process. Similarly, response and unsolicited data sent by the Application Service is received by the SCM and written this shared file system area, where it can be retrieved by the back office system.

Some Application Services (such as CREST DEX) allow Files to contain a number of individual messages, allowing Back Office applications to batch up transactions for faster transmission and processing. The File Transfer Manager (FTM) is used by the SCM to manage the directories used for all

peer Gateway connections and Application Services. The file transfer interface allows both manual or automated File submission and receipt


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

4 Message Queue Interface 4.1 Overview

IBM Websphere MQ ™ and IBM MQ Series ™ are trademarks of IBM.

Back Office applications can interface with the SettleNET (IFM) Gateway application using Websphere MQ (formerly IBM MQ Series). The Gateway Message Queue Transfer Manager (MQTM) component:

Monitors transmit queues for messages

Allows the SCM to process and transmit them to an Application Service or peer Gateway

Removes them from transmit queues

Places messages successfully received by the SCM onto receive queues

Attempts automatic retry in the event of failure.

Keeps an audit trail that records information about each MQ message processed.

This interface can be used to submit individual ISO 15022 messages, DEX messages, DEX files or any other format messages and files subject to BT Radianz Messaging size limits (see ‘3.7 Message Sizes’).

4.2 WebSphere MQ Versions

From time to time, IBM may issue reviews and patches to the Websphere MQ product. Contact the SettleNET Customer Support team for assistance and details of supported software versions.

4.3 Message Queues

Message queues are hosted on the Back Office infrastructure; MQTM uses IBM MQ client residing on the Gateway to access the queues.

For each Channel (CREST ‘Operator’):

a transmit queue is used to put messages for transmission across BT Radianz Messaging, and

a receive queue is used to deliver messages received across BT Radianz Messaging.

The MQTM reads the message content from the transmit queue but leaves each message on the queue until it has been successfully transmitted. Once successfully transmitted, the message is removed from the queue.

Consequently if the communications fails or i f the SettleNET (IFM) Gateway application itself fails during processing, then the message is not lost. The Gateway application has inbuilt retry mechanisms that will result in successful transmission once the problem has been resolved.

TX Queue

RX Queue

Dead Letter Q

Gateway

MQTM

BT

Secure Network Receive

Transmit

Figure 2 - MQ Message exchange for a single Channel


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

When a message is received and verified, the MQTM puts the message onto the receive queue and acknowledges the message to the sender. The receive queue is only updated when the message has been

successfully received by the Gateway application; truncated or failed messages are not put onto the receive queue.

4.4 Setting up MQTM

The Back Office MQ administrator is responsible for setup and maintenance of the MQ Queue Manager(s) and actual MQ Queues. A ServerConn channel must be defined for each Queue Manager in order to support MQ

client connections from Gateways. This is outside the scope of this document. Corresponding MQ Queue related configuration must be performed at the Gateway for every SettleNET

Channel that is to be set up. This is managed and maintained through the Gateway Configuration GUI accessed from the Windows ‘Start’ menu.

The MQTM supports multiple Channels connecting a Back Office application through to CREST Application Services. Each Channel is split into a transmitter and a receiver.

Application Services are pre-configured by BT and will appear automatically within the Gateway Configuration GUI.

e.g. The pre-configured Service ID ‘CRISO’ and Mode ‘LIVE’ represents Euroclear’s live CREST ISO Application Service. See Appendix A for currently provided Application Services.

For each Application Service the Gateway user must input the SettleNET Channel (CREST Operator) details. For each Channel the following must be configured

Channel ID

Status: Enabled/ disabled

Transmit Queue Manager Name

Transmit Queue Name

Transmit Backout Queue

Transmit MQ ServerConn Channel Definition: o ServerConn Channel Name o Connection Name e.g. <IP address>(<port>)

Receive Queue Manager Name

Receive Queue Name

Receive Backout Queue

Receive MQ ServerConn Channel Definition:

o ServerConn Channel Name o Connection Name e.g. <IP address>(<port>)

The Channel ID is defined by the Gateway administrator for use with the Application Service (e.g. CREST Operator). This is distinct from the underlying MQ channel names.

Application Services or individual Channels can be enabled and disabled using the Gateway configuration GUI. When a Channel or Application Service is disabled, the MQTM does not service the associated message queues.

MQ Backout queue name (BOQ) (optional): the name of the backout queue used to return poisoned or failed messages. If not specified, the queue manager Dead Letter Queue (DLQ) is used instead.

Channels can be added or deleted using the configuration GUI. The Gateway must be stopped and restarted for these changes to take effect.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

4.5 Putting a transmit message

This section describes how TRANSMIT messages are processed.

Back Office Gateway Application Service

Figure 3 - MQ TRANSMIT message handling

Note: Messages are only removed from the queue when they have been successfully transmitted to

the Application Service or have been placed onto the BOQ/DLQ.

Back Office puts message in TRANSMIT queue

MQTM browses the TRANSMIT queue and detects message

SCM transmits message to Application Service

Successful?

MQTM removes message from TRANSMIT queue

MQTM reports error

Yes No

Yes

Receive and authenticate message data

Is msg valid?

Yes

No

Yes

Send to BOQ/DLQ

Retry? Yes No

Yes

Remove from TRANSMIT queue and Send to BOQ/DLQueue


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

4.6 Getting a receive message

This section describes how RECEIVE messages are generated.


Figure 4 - MQ RECEIVE queue handling

Note: Only messages successfully received by the SettleNET (IFM) Gateway application are placed

in the receive queue. Where failures occur, events are logged at the Gateway to indicate the failure. The MQTM will not Acknowledge the receipt until the message has been placed in the receive queue. If the queue manager is not running or the queue configuration is incorrect, then a NAK is passed back to the Application Service.

Application Service sends message

notification

MQTM accepts

notification

Application Service sends message data

MQTM receives and verifies message data

Successful? Yes No

Yes

MQTM ACKs/NAKs Application Service

MQTM puts message in

RECEIVE queue

MQTM discards message and reports error

Back Office gets message from RECEIVE queue

ACK/NAK


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

4.7 MQ Message Header fields

IBM Websphere MQ messages have standard message header (MQMD) fields, some of which are mandatory

and some optional. Messages exchanged with the MQTM have the following header field restrictions: 4.7.1 Message ID (field MsgId)

Each inbound message for a specific BT SettleNET Channel must be uniquely identified by the standard MQ message ID field. MQ defines message IDs as 24 bytes. ID information in the field is left justified and unused

character positions must be padded with binary zeros or spaces. Refer to Appendix B for information on message identification for particular Application Services.

If a message contains an invalid message ID, then the message is moved to the dead letter queue.

4.7.2 Message Format Message content must be in an alpha numeric format, using either ASCII CCSID 850 or EBCDIC encoding.

In the case of EBCDIC, a conversion to ASCII CCSID 850 will enable the messages to be processed normally by CREST, as per Section Error! Reference source not found..

4.7.3 ReplyToQ, ReplyToQManager Inbound and outbound queue naming is static. It is not possible to specify the reply queue / manager for

inbound messages. Outbound messages generated by the SettleNET (IFM) Gateway application will not use these fields.

4.7.4 Exemptions All other header fields may be present in transmit queue messages but are ignored.

4.7.5 EBCDIC Conversion

Customers who have an IBM WebSphere MQ server may choose the define queues to use a Coded Character Set ID (CCS ID) that encodes messages in EBCDIC. The BT gateway uses ASCII CCSID 850 by default. The MQ client library converts the message payload by default between ECBDIC and ASCII appropriately but may

not convert the message headers, including the MQ Message ID. The Admin GUI contains a checkbox that should be used to enable EBCDIC conversion if required. This should be set for each service (e.g. CREST, CRISO).

4.8 Message Sizes

The maximum data file size that can be transmitted across BT Radianz Messaging is 4 megabytes. The

minimum data file size is 8 bytes. Note that some implementations of IBM Websphere MQ may have different message size limits; this may require a smaller message limit for an infrastructure with more restrictive size limits.

4.9 Message Ordering

The Gateway application will process messages in transmits queues in standard first-in/first-out (FIFO) order. Messages can be assigned a message priority which can be used to put higher priority messages into the

queue ahead of lower priority messages. Message queues defined with a Message Delivery Sequence as FIFO ignore priority.

Messages remain in the transmit queue until they have been successfully transmitted to the Application Service. Only when this is complete is the message removed and the next processed


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

When a Gateway is configured to support a number of Channels (using MQ and/or file transfer), each Channel is processed independently and concurrently with equal priority.

4.10 Backout Queue / Dead Letter Queue

Failed messages are put to the channel Backout Queue if configured or the Queue Manager Dead Letter Queue. Either the BOQ or the DLQ must be defined otherwise the gateway will report errors.

The SettleNET (IFM) Gateway application reads a message from a queue and attempts sending it. This may succeed or fail. If the failure is transient then the Gateway application will retry a number of times until the

transfer is successful or retries are exhausted. Messages with a permanent reason for failure are not retried (e.g. invalid format messages).

4.11 Inhibiting Queues

Back Office MQ Administrators can inhibit put and get operations on queues. Where a Gateway application is repeatedly experiencing processing errors, the administrator may inhibit the TRANSMIT queue until the problem has been resolved.

4.12 Starting MQTM

When the Gateway application is started, the MQTM automatically attempts connection to the transmit and receive queues. Any messages queued for inbound processing are read and processed individually. If queue connection fails, the MQTM reports suitable error events and periodically retries queue connection (see 7.2 for

more details on event logging).

4.13 Stopping MQTM

The Gateway application operator can choose to stop the application in Now mode or Drain mode. If Now is

chosen, the MQTM interrupts current message processing (both inbound and outbound) and stops immediately. If Drain is chosen, the MQTM completes any transfers in progress and then stops.

4.14 Automatic Queue Reconnection

The SettleNET (IFM) Gateway is designed to operate continuously without operator intervention. Typically, it can be expected that Back Office components may be subject to planned and unplanned outage, in which case the queue infrastructure may be down. In this case the MQTM may experience queue connection failures, and

will log events to alert support staff and repeatedly retry re-connection.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

5 File Transfer Interface 5.1 Overview

Back Office applications can interface with the SettleNET (IFM) Gateway application using one or more shared disk directory structures. Communication protocol options between the BOS and the Gateway are discussed in

section 6. The Gateway File Transfer Manager FTM component:

Monitors transmit directories for Files

Allows the SCM to process and transmit them to an Application Service or peer Gateway

Removes Files from transmit directories

Sends and receives Files at the same time.

Places Files successfully received by the SCM into receive directories

Generates status files to indicate the result of File processing

Attempts automatic retry in the event of failure.

Keeps an audit trail that records information about each File processed.

5.1.1 Files This interface can be used to exchange files of any format subject to BT Radianz Messaging size limits (see ‘3.7

Message Sizes’). An individual message can be written as a discrete file or multiple messages can be combined into a batch file depending on the requirements of the target Application Service.

File transfers are managed by the File Transfer Manager (FTM). The FTM uses a fixed directory structure shared with the Back Office application. Files are placed in TRANSMIT sub-directories for transmission. Received files are placed in RECEIVE subdirectories ready for processing by the Back Office.

Status files are created to provide notification for each file transmission. Control files indicate the processing status of a file. Control and status files have the same filename as the data file but are created in different

directories.

Submit

Retrieve Gateway

FTM CH1 App1

FTROOT

CH2

Detect

Deposit

BT

Secure Network Receive

Transmit

Housekeep

Figure 5 - File Transfer

5.1.2 Messages

This interface can be used to deliver individual messages with each message being written as a discrete file.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

5.2 Setting up shared directories

The shared directory structure consists of nested directories that reflect the ServiceID, Application Service, and

Channel ID. For each ServiceID configured for the Gateway application, a separate directory structure is created. The directory structure can be created on the Gateway system's hard drive or on another computer system to which the Gateway application has network access.

Note: The FTM must have read/write access to the shared directories.

The File Transfer Root Directory (FTROOT) is used by the Gateway as the ‘root’ of the shared directory

structure for a particular ServiceID. The user must create an FTROOT directory for each ServiceID, and then use the Gateway Configuration GUI to inform the FTM of each directory path.

For example:

C:\SettleNET\Hosts\CREST An FTROOT on a Gateway system hard drive

\\MY_COMPUTER\BT\CRISO FTROOT on a network drive

If the root directory resides on a remote file system, the path to the directory should follow the Universal Naming Convention (UNC):

\\server\share\path

Note: All of Microsoft’s Windows Operating Systems specify that a UNC root path name must comprise the

server name and a minimum of two directory levels, as illustrated above.

Once the FTROOT and Application Services and Channels have been configured, the entire directory structure

below FTROOT is created automatically.

5.3 Service ID, Application Service and Channel ID

Each ServiceID is represented by a FTROOT directory. The directory name is not significant but it is suggested the name is chosen to reflect the ServiceID.

e.g. C:\SettleNET\Hosts\CREST A ServiceID has associated Application Services e.g. Live, Trial etc. The number and naming of these will

depend on the particular ServiceID. e.g. C:\SettleNET\Hosts\CREST\LIVE

C:\SettleNET\Hosts\CREST\TRIAL Channels for transmitting to an Application Service must be configured. This creates another subdirectory layer

below the Application Service e.g. C:\SettleNET\Hosts\CREST\LIVE\OPER01

Note that the Channel name is specific to a particular Application Service. CREST\LIVE\OPER01 is NOT the same Channel as CREST\TRIAL\OPER01

5.4 Transmit Directory Structure

The TRANSMIT directory structure is used for transmit File processing and comprises the following sub-directories:


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

DO Control files that tell the FTM that a file in the PENDING directory is ready to be transmitted.

DONE Control files that show files have been processed by the FTM

FAIL Files for which transmission was unsuccessful.

PENDING Files queued for transmission.

STATUS Status files that show the outcome of completed transfers.

SUCCESS Files that have been successfully transmitted.

e.g.

C:\SettleNET\Hosts\CREST\LIVE\OPER01\TRANSMIT\DO, C:\SettleNET\Hosts\CREST\LIVE\OPER01\TRANSMIT\DONE etc.

5.5 Receive Directory Structure

The Receive directory comprises the following sub-directories:

DONE Control files that show files have been processed by the FTM and that their STATUS files and SUCCESS files (if applicable) are available.

STATUS Files that show the outcome of completed transfers.

SUCCESS Files that have been successfully received.

DO (Private)

FTM directory containing incoming control files. The content of this sub-directory must only be accessed by the FTM.

PENDING (Private)

FTM directory containing incoming files. The content of this sub-directory must only be accessed by the FTM.

e.g. C:\SettleNET\Hosts\CREST\LIVE\OPER01\RECEIVE\STATUS,

C:\SettleNET\Hosts\CREST\LIVE\OPER01\RECEIVE\SUCCESS etc.

5.6 Status and Control files

Each file will have some corresponding status and control files. If a file is created as follows:

C:\SettleNET\Hosts\CREST\LIVE\OPER01\TRANSMIT\PENDING\1234567

Then the corresponding status and control files would be: C:\SettleNET\Hosts\CREST\LIVE\OPER01\TRANSMIT\STATUS\1234567

C:\SettleNET\Hosts\CREST\LIVE\OPER01\TRANSMIT\DO\1234567 C:\SettleNET\Hosts\CREST\LIVE\OPER01\TRANSMIT\DONE\1234567

Similarly, with receive: C:\SettleNET\Hosts\CREST\LIVE\OPER01\RECEIVE\PENDING\1234567

C:\SettleNET\Hosts\CREST\LIVE\OPER01\RECEIVE\SUCCESS\1234567 Then the corresponding status and control files would be:


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

C:\SettleNET\Hosts\CREST\LIVE\OPER01\RECEIVE\STATUS\1234567

C:\SettleNET\Hosts\CREST\LIVE\OPER01\RECEIVE\DO\1234567 C:\SettleNET\Hosts\CREST\LIVE\OPER01\RECEIVE\DONE\1234567

Status files contain diagnostic information used to describe whether or not the file transfer has been successful. The format of a status file is detailed in Appendix C.

Control file content is not important – it is their presence or not that is important to the SettleNET protocol. For convenience and simplicity, it is recommended that control files are created as zero length files.

5.7 File Names

Filenames follow a 7.3 name format. e.g. the following filename are valid:

0000001 0000001.920

Refer to Appendix B for information on file naming for particular Application Services.

5.8 File Format

The maximum data file size that can be transmitted across the BT Radianz Messaging into CREST is 4 megabytes. The minimum data file size is 8 bytes.

The format of files is defined by the provider of the Application Service. FTM places no restriction on file content (beyond file size).

5.9 Directory Clean Up

The FTM does not delete processed files; instead the Back Office application is responsible for clearing out

redundant files from the following directories for each Application Service Channel: TRANSMIT\STATUS

TRANSMIT\SUCCESS TRANSMIT\FAIL (failures only) TRANSMIT\DONE

RECEIVE\STATUS RECEIVE\SUCCESS RECEIVE\DONE


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

5.10 Transmitting a file

This section shows how the FTM directory interface is used to transmit a file for a particular Channel via the

Gateway FTM. In Figure 6 - FTM Transmit handling, all the action happens within the TRANSMIT directory tree.


Figure 6 - FTM Transmit handling

Note: Control files in the TRANSMIT/DO directory are processed alphabetically

Receive and authenticate

message data

Back Office creates File in PENDING

Back Office creates DO control file

FTM detects DO file and creates corresponding

STATUS file

FTM transmits file to Application Service

Successful?

FTM moves PENDING file to SUCCESS

FTM moves PENDING file to FAIL

SCM moves DO file to DONE

Back Office detects DONE file, reads STATUS file code

Successful?

Remove SUCCESS, STATUS and DONE files

Remove / move FAIL, STATUS and DONE

Investigate & perhaps retry

Yes No

Yes

Yes No

Yes


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

5.11 Receiving a file

This section shows how the FTM directory interface is used to receive a file. In Figure 7, all the action takes

place in the RECEIVE directory tree.


Figure 7 - FTM Receive handling

Yes

Application Service sends file notification

FTM creates PENDING file

FTM creates

STATUS file

FTM creates DO file

Application Service sends file FTM writes file

to PENDING

Successful?

Yes No

Yes

FTM ACKs / NAKs Application Service and updates STATUS appropriately

FTM moves PENDING to SUCCESS

FTM deletes PENDING file

FTM moves DO to DONE

Back Office detects DONE file, reads STATUS file

Process SUCCESS, Remove STATUS and DONE

files

Remove STATUS and DONE files

No

Yes

ACK/NAK

Successful?


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

5.12 Secondary Receive Directory

The optional secondary receive directory protects against the possible loss of a file that has been received by

the Gateway application, for which receipt has been acknowledged but which has not been processed by the user. For example:

The FTM receives a file and notifies the sender that it has been received. At this point, the Gateway application and the sender deem the file transfer to be successful and the file is

deleted from the sender’s transmission queue.

For some reason (such as disk failure), the received file is lost before it can be processed by the recipient.

The secondary receive directory ensures that when a file is received by the Gateway application it is copied into a secondary directory on a different disk drive, preferably on a different machine. If there is subsequently a

problem with one of the copies the other should be intact. If during file receipt one of the receive directories encounters a problem, the entire transfer is deemed to have

failed. Only when a file is received into both directories is the receipt considered to be a success . The secondary receive directory option is configured using the Gateway Configuration GUI.

5.13 FTM Watchdog

The WATCHDOG file is automatically created and periodically updated by the FTM component within SCM. This file can be monitored to detect when the SettleNET (IFM) Gateway application has stopped running or has lost connection to the FTROOT shared directory structure. If the file’s timestamp doesn’t change for a period,

then the Gateway application has stopped running. The update frequency for the watchdog file is configured by the user through the Gateway Configuration GUI.

The WATCHDOG file can be regularly checked for the time of its last update. If the update time has not changed for a period of time (recommended to be 4 times the file’s update frequency) the SCM is assumed not to be running and therefore not transmitting or receiving files / messages.

The WATCHDOG file is situated in the GATEWAYS directory structure located under the file transfer root directory. The GATEWAYS directory has a sub-directory with the same identifier as the Gateway. This sub -

directory contains the WATCHDOG file, as follows:

WATCHDOG

GWAYABCD

GATEWAYS

FTROOT

Figure 8 - Watchdog Directory Structure

5.14 Starting the FTM

When the Gateway application is started, the FTM checks that the expected directories exist; if any are missing,

the FTM creates them. When all the directories exist, the FTM begins its normal process of detecting files for transmission and awaiting files for receipt.

If for any reason the directories cannot be created, the FTM handler is not started by the Gateway. The operator must rectify the problem before restarting the Gateway application.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

5.15 Stopping the FTM

The Gateway application operator can choose to stop the application in Now mode or Drain mode. If Now is

chosen, the FTM interrupts the file(s) it is transmitting or receiving, fails the transfer and stops immediately. If Drain is chosen, the FTM completes the transfer(s) in progress and then stops.

5.16 Directory Creation

Directories are created when:

The Gateway application starts

A Channel is added

The CREATE DIRECTORIES button is selected in the Gateway Configuration GUI.

5.17 Enabling and Disabling

When a Channel or Application Service is enabled, the FTM scans appropriate directories for files to transmit or receive.

If a Channel or Application Service is disabled, the FTM stops scanning the Channel or Application Service directories. It is also prevented from receiving files or messages. If a Channel or Application Service is disabled while a file transfer is in progress, the transfer is allowed to complete but new transfers are prevented from

starting.

5.18 Adding and Deleting Channels

Channels can be added or deleted at any time whether the Gateway application is running or not. When a

Channel is added, its directories are created. When the Channel is enabled, the FTM starts to scan its directories, thus rendering the Channel operational.

If a Channel is deleted while the Gateway application is running, an active file transfer is allowed to complete but no new transfer is started. Deleting a Channel removes it only from the Gateway application configuration; it does not delete its directory structure.

5.19 Lost File Receipts

On rare occasions a file receipt may fail to reach the file's sender. A file is sent by the FTM. The target Application Service receives the file and attempts to notify the FTM that the

file has been received but the notification fails. The FTM and the target are therefore out of step. The FTM tries to resend the file. If the original file has not been removed from the target’s receive directories a duplicate file is detected and the resend fails. The FTM reports that the transmission has failed.

To resolve the problem, the sender must contact the receiver to verify that the file was received or to arrange for the file to be retransmitted.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

5.20 File Checking Order

The FTM checks appropriate sub-directories before transmitting or receiving a file. The following tables show

the result of checking particular transmit and receive sub-directories. 5.20.1 Transmit Sub-Directories

Sub-Directory Name

Condition Notes Transfer Failure

SUCCESS File already exists User data cannot

be overwritten by the FTM.

Yes (no status file)

FAIL File already exists User data cannot



DONE File exists (delete failure)

An attempt is made to delete the file.


DO Open (for read) failure

For example:

File is open by another process


STATUS Create (for write) successful

If file already exists, it will be overwritten

No

Create (for write) failure

For example:

File already exists but is open by another process.

Insufficient disk space.


PENDING Open (for read) failure

For example:

File missing or file open by another process.

Yes (status file generated)


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

5.20.2 Receive Sub-directories

Sub-Directory Name

Condition Notes Transfer Failure

SUCCESS File already exists User data cannot



DONE File exists (delete failure)

An attempt is made to delete the file.


STATUS Create (for write) successful

If file already exists, it is overwritten.

No


For example:

File already exists and is open by another process.



DO Create (for write) successful

If file already exists it is overwritten.

No


For example:

File already exists but is open by another process.


PENDING Create (for write) successful

If file already exists it is overwritten.

No


For example:

File already exists but is open by another process




Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

6 File Transfer Service Communications Protocols Your Back Office System (BOS) is connected to the BT Gateway system by a LAN allowing you to transmit files

from your BOS to your Gateway, To allow this communication between the BOS and the Gateway, several network protocols are supported. The protocol options are listed below.

Contact the SettleNET Customer Support team for assistance and details of supported software versions.

6.1 NFS

Network File System (NFS) is a file system protocol allowing a user on a client server to access files on another server over a network as if the remote files were local.

6.2 FTP

File Transfer Protocol (FTP ) is a standard network protocol used to transfer files from one server to another server over a network.User authentication is normally in the form of an unencrypted username and password. For secure transmission that encrypts the username and password FTP can be secured using FTPS or SFTP.

6.3 FTPS

FTPS is a network protocol, based on tunnelling FTP over the network using a Secure Sockets Layer (SSL) connection, to enable secure file transfers between hosts. Unlike standard FTP, FTPS encrypts data, preventin g sensitive information from being transmitted in the clear over a network.

6.4 SFTP

SFTP is a network protocol, based on tunnelling FTP through a Secure Shell (SSH) connection, to enable secure file transfers between hosts. Unlike standard FTP, SFTP encrypts data, preventing sensitive information from being transmitted in the clear over a network.

6.5 Samba

Samba is software that can be run on a BOS plat form other than Microsoft Windows, e.g. UNIX, Linux, IBM System 390, OpenVMS. It allows the BOS host to interact with Microsoft Windows on the SettleNET Gateway as if it were a Windows file server.

6.6 OpenText NFS Client (formerly Hummingbird)

OpenText NFS Client (formally known as Hummingbird) allows Microsoft Windows operating systems to securely access files residing on UNIX, Linux, VMS and other NFS-enabled BOS hosts.


Radianz Messaging

Issue: 1.5 Date: 16/01/2019

of 53

7 Considerations

7.1 Load balancing and resilience

BT Radianz Messaging provides both load balanced and resilient connectivity, depending on requirements. With load balancing, a number of Gateways would be operational at the same time. Each Gateway has

separate FTM/MQTM configuration for transmit and receive handling. With resilience, there would be one or more primary Gateways with backup Gateways that can be enabled

when failure of a primary occurs. Under normal circumstances, the backup Gateway is in a dormant state with SCM services stopped. When a failure occurs with the primary Gateway, service on the primary Gateway should be stopped and those on the backup Gateway started.

For a purely resilient architecture, both primary and backup Gateways should be configured to use identical FTM/MQTM configuration so that the backup Gateway processes Back Office data in exactly the same manner

as the primary. The primary Gateway must be stopped before the backup is started to avoid conflict. For mission critical applications a typical installation has a bank of Gateways load-balancing traffic plus a

number of backup Gateways that can be quickly reconfigured to assume the traffic load of a failing device, network link, or Back Office link. In this case, the FTM/MQTM configuration for the backup Gateways would be modified to match that of the failed Gateway.

Beyond the Gateway and network access points, all components of the BT Radianz Messaging network leading to the Application Services are fully resilient. Should one of the resilient paths to an Application Service fail, the

Gateway automatically routes traffic via an alternate communications path. For further information on resilience/load balancing planning, please contact your BT Account Manager.

7.2 Event Logging

Communication errors between the SettleNET (IFM) Gateway application and CREST Application Services have events logged to describe any failure. The logging mechanism writes event details to a text logfile, and sends messages to one or more event listeners. BT Radianz Messaging network management centres collect

these events and alert support staff to issues. These events can also be viewed using the Customer Information Interface (CII). The CII provides a simple

event display and can be used to collect the events from a number of different SettleNET (IFM) Gateway applications. CII can be deployed on a Windows machine within the Back Office infrastructure. The CII is described in detail in Ref 1


Radianz Messaging Issue: 1.5

Date: 16/01/2019

of 53

8 APPENDIX A. BT Radianz Messaging Application Services

The table below shows Application Services available through BT’s various Connectivity Services, and the names of the Application Service Providers.

IFM’s Connectivity Service

Service ID

Application Service Type Application Service Name

IFM Channel Usage Application Service Provider

SettleNET

CREST

Live CREST DEX CREST;LIVE One per individual ‘operator’

Euroclear

CREST DEX trialling CREST;TRIAL One per individual ‘operator’

1st CREST DEX testing CREST;TESTE

One per individual ‘operator’

2nd

CREST DEX testing CREST;TESTF


3rd

CREST DEX testing CREST;TESTG One per individual ‘operator’

Further CREST DEX services

CREST;????? One per individual ‘operator’

IFM ‘Loop Back’ test CREST;XTEST

One for CHANNELX BT

One for CHANNELY

CRISO

Live CREST ISO 15022 CRISO;LIVE One per individual ‘operator’

Euroclear

CREST ISO 15022 trialling CRISO;TRIAL One per individual ‘operator’

1st CREST ISO 15022 test CRISO;TESTE


2nd

CREST ISO 15022 test CRISO;TESTF One per individual ‘operator’

3rd

CREST ISO 15022 test CRISO;TESTG One per individual ‘operator’

Further CREST ISO 15022 services

CRISO;????? One per individual ‘operator’

‘Loop Back’ test CRISO;XTEST One for CHANNELX

BT One for CHANNELY



Date: 16/01/2019

of 53

9 APPENDIX B. File/Message Naming Conventions Files transferred using FTM directories require Filenames.

Messages transferred using MQTM require MessageIDs.

The Gateway SCM mandates both Filenames and MessageIDs follow the same general formatting rule: fffffff[.sss]

An Application Service might further require service specific use within this formatting. The table and text below show just such requirements for the CREST DEX and ISO Application Services

CREST DEX fffffff is a unique increasing file sequence number (0000001 onwards). Back office applications should not repeat or skip numbers in the transmit sequence. Must be exactly 7 digits. No spaces.

.sss Split code indicator, used where the Application Service splits an outbound file

into more than one file, split codes increase from 001 onwards. Not required for inbound (to CREST) files

CREST ISO fffffff Can be any unique alpha-numeric string up to 7 characters.

.sss Mandatory ISO 15022 message type

For example:

The following filenames or MessageIDs are valid and will be processed by the Gateway SCM:

1234567 (Format required for CREST DEX file transfer) 1234567.518 (Format required for CREST ISO messages)

The filename ‘1234567’ is suitable for the CREST DEX File Application Service. Note: If it then causes a response file greater than 4MBytes to be generated this will be split into a series of outbound Split files by CREST -1234567.001, 1234567.002, 1234567.003 etc.

If a message with the MessageId ‘1234567’ is passed to a CRISO Application Service it will be rejected due to a lack of message type.

On the other hand MessageId ‘1234567.518’ will be interpreted as ISO MessageID 1234567, message type 518 if passed to a CRISO Application Service but the filename ‘1234567.518’ will be rejected by CREST

DEX Application Services. For FTM, the Gateway will transmit files received in Alphanumeric order whatever order they are delivered to

the TRANSMIT directory structure. An MQ message ID is 24 bytes long. The MQTM uses up to the leftmost 11. The remainder of the ID field

must be padded with zero bytes or spaces.



Date: 16/01/2019

of 53

10 APPENDIX C. FTM: Status File Data Format

SSSS C W T NNNN EEEEE ZZZZZZZZZZ TTTTTTTTTT AAAAAAAAAA UUUUUUUUUUU

GGGGGGGG HHHHHHHH;M S/LLLLLLLL Fd/IIIIIIII rrr...rrr PPP...PPP

<Description>[<CR><LF>]

Note: The fields are separated from each other by a space character, they are left justified and if

necessary, are space padded.

Field Col. Width Type Description

SSSS 1 4 Hex File transfer status code (See Appendix D for a list of codes)

C 6 1 Decimal File split code. Possible values:

'0' Last

'1' More

Note: for CDS Application Services the value will always be 0

W 8 1 Text Origin of the end of transfer action, identified by the T

and NNNN fields:

'G' Gateway

'C' Network Comms Host

T 10 1 Text Type of the NNNN field.

Indicates the Network Protocol action that terminated the transfer:

'D' Disconnect

'J' End Of File

'L' FT Negative acknowledgement

'K' EOF acknowledgement

'?' None



Date: 16/01/2019

of 53


NNNN 12 4 Hex Reason code associated with the action which completed the Network Protocol transfer. Interpretation of this field depends on the T field, as follows:

If T is 'D', refer to Appendix E

If T is 'L', refer to Appendix F

EEEEE 17 5 Decimal Event code reported to the Gateway Management Agent at the end of transfer.

ZZZZZZZZZZ 23 10 Decimal File size in bytes

TTTTTTTTTT 34 10 Decimal The number of bytes transferred. (With successful transfers this is the same as the ZZZZZZZZZZ field).

AAAAAAAAAA 45 10 Decimal Number of transfer attempts

UUUUUUUUUUU 56 11 Text User identifier (For CDS Application Services this is the ‘R’ environment USERID)

GGGGGGGG 68 8 Text Gateway identifier

HHHHHHHH;M 77 10 Text H = Environment

M = Application Service

Length of Environment and Application Service can vary as long as they are separated by a semi colon (;) and their length does not exceed ten characters in total, for example:

‘R;CSDC’ for the ComputerShare DC application

‘CREST;L’ for the Live Crest DEX application

S/LLLLLLLL 88 10 Hex Local Gateway session identification number



Date: 16/01/2019

of 53


Fd/IIIIIIII 99 11 Hex Session identifier, as follows:

F indicates a file transfer session.

d indicates the initiator of the session as below:

'G'-Inbound session initiated by the Gateway.

'C'-Outbound session from the BT Radianz Messaging Network Comms Host

IIIIIIII-Session

number

rrr...rrr 111 22 Spaces Reserved for future use

PPP...PPP 134 70 (min)

Text Full path of relevant file (70 characters minimum but the field is expanded if the file path is longer due to a long base root directory)

<Description> 205+ 8...n Text Description of the transfer status. If the file path is more than 70 characters, the start column of this field is correspondingly greater than 205. A description of the EEEEE field is included within [ ] brackets.

[<CR><LF>] 2 Control Carriage Return/Linefeed



Date: 16/01/2019

of 53

11 APPENDIX D. FTM STATUS CODES Transmission errors are logged to the Gateway event log which can be viewed:

as a text file on the Gateway

through the CII event interface

at BT Radianz Messaging management centres.

In the tables in Appendices C1 and C2, the Action column specifies the 'action' to be followed in the event of a particular failure.

Note: It is important that the steps within each 'action' are performed in the order specified.

The 'actions' are as follows: Housekeep files:

1. Delete ‘STATUS’ file

2. Save and delete ‘SUCCESS’ file

3. Delete ‘DONE’ file

Resubmit file:

1. Save and delete the file from the ‘FAIL’, ‘SUCCESS’ or ‘PENDING’ directory

2. Save and delete ‘STATUS’ file

3. Save and delete control file from the ‘DO’ or ‘DONE’ directory.

4. Follow transmit GFEXP for the file

Re-receive file:

1. Save and delete the Application Service file from the ‘SUCCESS’ or ‘PENDING’ directory

2. Save and delete ‘STATUS’ file

3. Save and delete control file from the ‘DO’ or ‘DONE’ directory

Check Directories and Files

1. Ensure files do not already exist with the same name

2. Ensure Gateway has access to the directories

3. Check that there is sufficient disk space to send and receive files



Date: 16/01/2019

of 53

APPENDIX D1. Transmit Status Codes

Code (Hex)

Error Code Description

Status File Text Cause Action

0000 No error - transfer

completed successfully

No Error

File sent successfully Housekeep files

0001 Incorrect file size Incorrect file size (greater than maximum allowed)

The submitted file is greater than the permitted maximum.

Correct file and resubmit

Incorrect file size (less than minimum allowed)

The submitted file is less than the permitted minimum

Correct file and resubmit

0002 Security violation Security error (verification) Internal security check has failed Contact BT Support

0003 Spare

0004 Receive only code

0005 FEN rejected by

Recipient or BT Radianz Messaging Comms Host

File transfer rejected by Recipient or Communications Host (FEN)

The FTM has attempted to notify the

recipient of the file it wishes to send but this has been rejected.

Action dependant on FEN NACK code

(field NNNN in status file). See Appendix A.

0006 EOF rejected by

Recipient or BT Radianz Messaging Comms Host

File transfer rejected by recipient or Communications Host (FEN)


recipient that the entire file has been sent. On receipt the file has been rejected.

Action dependant on EOF NACK code

(field NNNN in status file). See Appendix A.

0007

to 000F

Spare

0010 File not found File does not exist The FTM cannot find the file that it is expecting.

Re submit ensuring the presence of the PENDING file.



Date: 16/01/2019

of 53

Code (Hex)



0011 File open error Unable to open file for reading The FTM has experienced an error opening a file.

Re submit the file ensuring that all files

exist and that the FTM has correct permissions.

Unable to open file for writing The FTM has experienced an error opening a file.

Check that Gateway has write access to the directories.

Check that file does not already exist.

0012 Spare

0013 Retryable

communications protocol error

Protocol error BT SettleNET protocol problem Contact BT Support

Protocol error (unexpected message received)

BT SettleNET protocol problem Contact BT Support


0015 Unexpected

disconnect by BT Radianz

Messaging Comms Host or Recipient

Session disconnected by

Recipient or Communications Host

During the transfer of the file the

connection to the recipient has been terminated by the recipient.

Resubmit file


0017 FEN rejected due to timestamp error

File transfer rejected by Recipient

or Communications Host (FEN timestamp)


Recipient of the file it wishes to send but this has been rejected by the recipient due to a timestamp tolerance validation check.

Check & adjust the Gateway clock. Re-start the Gateway and re submit the file.



Date: 16/01/2019

of 53

Code (Hex)



0018 Error reading file File read error The FTM has experienced an error reading from a file.

Check files and directories.

Resend file

File read error (unexpected EOF)

The FTM has experienced a premature end of file whilst reading from a file.


Resend file

0019 Invalid filename Invalid filename

Filename is too long Shorten file name

Resend file

001A

to 001F

Spare

0020 Unable to connect

to the BT Radianz Messaging Comms Host

Communications Host not available

The FTM was not able to establish a

connection to the BT Radianz Messaging Network.

Resend file


0022 General

communications

error detected after a session has been established.

Communications error Possible connect break Resend file

0023 Internal FTM

processing problem

Internal software problem (session thread creation)

FTM resource problem Contact BT Support

0024 Error deleting file Unable to delete file The FTM has experienced an error deleting a file.


Resend file



Date: 16/01/2019

of 53

Code (Hex)



0025 Error closing file Unable to close file The FTM has experienced an error closing a file.


Resend file

0026 Error moving file Unable to move file The FTM has experienced an error moving a file.


Resend file

0027 Session closed down

Session closed down Gateway has been stopped using ‘Now’ option while file transfer was in progress.

Restart Gateway and resend file

EEEE Transfer incomplete

Transfer incomplete Transfer has not completed Wait for completion

Fxxx These are errors

for which a

STATUS file can not be generated. These error codes

appear only in the event details written to the audit

trail event log and the Customer Information Interface.

F001 Error finding file Find file error Possible loss of connection to remote directory(s)

Resend file

F002 File already exists File already exists SUCCESS or FAIL file already exists Housekeep files

Resend or re-receive file

F003 Spare

F004 Receive only code



Date: 16/01/2019

of 53

APPENDIX D2. Receive Status Codes

Code (Hex)



0000 No error - transfer

completed successfully

No Error File received successfully Housekeep files

0001 Incorrect file size Incorrect file size (greater than maximum allowed)

Originator has attempted to send a file

that is greater than the permitted maximum.

Contact BT Support

Incorrect file size (received less than expected)

The size of the file received is less than

the size that the FTM had been notified of at the start of the transfer.

Re-receive file.

Incorrect file size (received more than expected)

The size of the file received is greater

than the size that the FTM had been notified of at the start of the transfer.

Re-receive file.

0002 Security violation Security error (verification) Internal security check has failed Contact BT Support

Security error (FEN session number)

Security error (FEN ordinal number)

Security error (EOF session number)

Security error (EOF ordinal number)

Security error (EOF final MAC)



Date: 16/01/2019

of 53

Code (Hex)



Security error (MBI inconsistent)

0003 Spare

0004 Insufficient file

space to create a file

Insufficient file space The FTM is unable to reserve enough disk space for it to receive the file.


Re-receive file.

0005 Transmit only code


0007

to 000F

Spare


0011 File open error Unable to open file for writing The FTM has experienced an error opening a file.

Check that Gateway has write access to the directories.

Check that file does not already exist.

0012 Spare


0014 Non retryable

communications protocol error

Protocol error BT SettleNET protocol problem Contact BT Support

Protocol error (unexpected message received)

BT SettleNET protocol problem Contact BT Support



Date: 16/01/2019

of 53

Code (Hex)



0015 Unexpected

disconnect by BT Radianz Network

Comms Host or originator

Unexpected disconnection by

Originator or Communications Host

During the receipt of the file the

connection to the originator has been terminated by the originator.

Re-receive file

0016 Error writing to file File write error The FTM has experienced an error writing to a file.


Re-receive file




001A

to 001F

Spare


0021 Gateway has failed to send the FEN

Failed to acknowledge transfer attempt to Gateway

The FTM was unable to receive the file

because it was unable to send the positive file acknowledgement.

Analyse events for the likely cause of the transmission failure.

0022 General

communications error detected after

a session has been established.

Communications error Possible connection break Re-receive file




Date: 16/01/2019

of 53

Code (Hex)



0024 Error deleting file Unable to delete file The FTM has experienced an error deleting a file.


Re-receive file

0025 Error closing file Unable to close file The FTM has experienced an error closing a file.


Re-receive file

0026 Error moving file Unable to move file The FTM has experienced an error moving a file.


Re-receive file

0027 Session closed down

Session closed down Gateway has been stopped using ‘Now’ option whilst file transfer was in progress.

Re-receive file

EEEE Transfer incomplete

Transfer incomplete Transfer has not completed Wait for completion

Fxxx These are errors

for which a STATUS file can

not be generated. These error codes will appear within

the event details written to the audit trail event log and

the Customer Information Interface.

F001 Transmit only code

F002 File already exists File already exists SUCCESS or FAIL file already exists Housekeep files

Re-receive file



Date: 16/01/2019

of 53

Code (Hex)



F003 Spare

F004 Error detected in received FEN

User identifier is unknown Originator has sent a file notification containing an incorrect user id.

Contact BT Support Desk

Gateway identifier is unknown Originator has sent a file notification containing an incorrect Gateway id.


Operator is unknown Originator has sent a file notification containing an unknown originator id.

Check that the originator configuration wasn’t recently deleted.


Operator is disabled Originator has sent a file notification for an originator channel that is disabled.

Enable Originator channel

Re-receive file

File transfer mode is disabled Originator has sent a file notification for an Application Service that is disabled.

Enable Application Service

Re-receive file



Date: 16/01/2019

of 53

12 APPENDIX E. DISCONNECT REASON CODES (MQTM & FTM) Values for the status file field NNNN after a disconnection.

The following is a list of reason codes that are generated as a result of either a disconnection or connection refusal between the FTM and the BT Radianz

Messaging Communications Host. The end columns in the table indicate the possible source of the Error, GW = Gateway, and CH = Communi cations Host.

Description ASCII

Code Disconnect

Connection Refuse

0 Series Error Codes

No Error '0000' CH or GW CH or GW SDU Protocol Version Number invalid '0001' CH or GW CH or GW Time Invalid '0002' CH CH Invalid MAC '0003' CH or GW CH Invalid Session Number '0004' CH or GW CH or GW Initiator Field address is invalid '0005' CH or GW CH or GW Responder Field is invalid. '0006' CH or GW CH or GW Field too long. The quantity of data transmitted was not the same as the PDU length field. '0007' CH or GW CH Unexpected message - a PDU type arrived that was invalid (For example an end of file notification before

the FEN) '0008' CH or GW CH

Interactive Message Sequence Number is invalid '0009' CH or GW Invalid Field within PDU (For example a field contained alphabetical characters where a numerical value was expected)

'000A' CH or GW CH

Incorrect Type of high level protocol (E.g. File transfer session attempted on an interactive port) '000B' CH or GW CH or GW PDU Protocol Version Number invalid '000C' CH Spare '000D' Security MAC generation/encryption failed. '000E' GW Timed out waiting to receive a message. '000F' GW Error encountered during receive. '0010' GW Error encountered when formatting a message for transmit. '0011' GW Application Closing Down ‘0012’ CH or GW PDU length out of range ‘0013’ CH CH PDU contains invalid encryption method ‘0014’ CH CH



Date: 16/01/2019

of 53

Description ASCII Code

Disconnect

Connection Refuse


(Errors From The Common Gateway Services)

CGS - Software Failure '1001' GW GW CGS - Security Fault '1002' GW CGS - Internal Software Error - Attempt to destruct a session before it was disconnected. '1003' GW


The Gateway encountered an error whilst writing to a file '3001' GW The recipient was sent a file different in size to that specified in the FEN. '3002' GW The recipient detected an invalid security chain indicator. '3003' CH or GW CH Spare '3004' ‘Back Office’ transfer incomplete. '3005' GW Spare '3006' Invalid IOFN number. '3007' CH or GW Spare '3008' Received file shorter than length specified in FEN '3009' GW Received file greater than length specified in FEN '300A' GW Error searching an operator directory '300B' GW Error opening a file '300C' GW Error reading a file '300D' GW Error deleting a file '300E' GW Inbound file not found '300F' GW File already exists preventing transfer '3010' GW Failed to send FEN-ACK ‘3011’ GW Unable to start FT session thread ‘3012’ GW

4000 Series Error Codes (Workstation Interactive Error Codes)

Interactive Service is disabled '4000' GW NSL Field too long. '4001' GW Workstation Link failed. '4002' GW

6000 Series Error Codes (NSL Error Codes)

The Workstation disconnected with an abnormal reason code ‘6000’ WS



Date: 16/01/2019

of 53

Description ASCII Code

Disconnect

Connection Refuse

Spare '6001' Spare '6002' Spare '6003' Spare '6004'

7000 Series Error Codes (Comms Host Error Codes)

This comms host is not "hot" (try another one) '7000' CH CH Gateway is barred. '7001' CH CH Request for uninitialised destination connection '7002' CH CH CH - Failed to establish a connection to Application Service '7003' CH CH Invalid Application Service identifier '7004' CH CH GW configuration is invalid '7005' CH Far end connection broken. '7006' CH CH Session terminated because CHA was changed to a WARM state. '7007' CH Session terminated due to an operator (ACI) 'STOP session' command. '7008' CH Far end connection is barred. ‘7009’ CH CH Zero Data Block Size received ‘700A’ CH A Data Block has been received which is too large ‘700B’ CH Too many bytes have been received for the file size given in the corresponding FEN ‘700C’ CH Session terminated because Comms Host Gateway configuration was refreshed. '700D' CH Session terminated because Comms Host Application Service configuration was refreshed. '700E' CH CDU Protocol violation '700F ' CH MH Internal error. '7010' CH Security system error occurred. '7011' CH Failed to read Gateway configuration file entry. ‘7012’ CH Inconsistent data in Interactive Response. ‘7013’ CH Data block received out of sequence ‘7014’ CH Gateway connection Unexpectedly broken (Note this will never be transmitted, and is used in the Comms Host audit log)

‘7015’ CH

The Comms Host is returning the unadjusted CH time to the GW in the Con Refuse. (Note this is not

indicative of an error.) ‘7016’ CH



Date: 16/01/2019

of 53

13 APPENDIX F. ERROR CODES (MQTM & FTM) Values for the status file field NNNN after a negative acknowledgement.

The Generator column in the following table indicates the originator of the error, AH = Application Service, GW = Gateway, CH = Comms Host.

Generator Error

Code

Meaning Action

AH '0001' File too large Reduce file size to below the maximum size allowed and re -send it.

AH '0002' Invalid User Id Check that the user id has been configured correctly. Refer to the SettleNET User’s Guide

AH '0003' Invalid operator reference Check, using the Application Service GUI, that the file transfer operator used is known to the Application Service and has been enabled.

AH '0004' Invalid Gateway Id Check Gateway id configuration

AH '0005' Invalid MAC Contact SettleNET Support Desk

AH '0006' Invalid Timestamp Check Gateway time

AH '0007' Invalid Key Identifier Contact SettleNET Support Desk

AH '0008' File transfers currently disabled for File Transfer Operator

Check, using the Application Service GUI, that the file transfer operator has been enabled.

AH '0009' Duplicate file transfer sequence

number

The file sequence number used has already been submitted to the Application Service. Check,

using the Application Service GUI, what the next expected sequence number is.

AH '000A' File transfer sequence number too high.

The file sequence number used was not what the Application Service was expecting as the next in sequence. Check, using the Application Service GUI, what the next expected sequence

number is.

AH '000B' No connection to Gateway. Issued by the AH to the CH. This will not appear at the Gateway.

AH '000C' System mode does not match that of message

The contents of the file are not consistent with the mode (Live, test or trial) to which the file was submitted. Check that the file was submitted to the correct mode directory, consistent with the file contents.

AH '000D' Size of file does not match FEN overall file size

The total file size received did not match the size that the Application Service had been notified of. Retry but if problem persists contact the SettleNET Support desk.

AH '000E' File contains no data The file does not contain any messages. Check the file contents.

AH '000F' Invalid message type received during file transmission

Contact SettleNET Support Desk

AH '0010' Data block received out of

sequence




Date: 16/01/2019

of 53

Generator Error Code

Meaning Action

AH ‘0011’ File transfer sequence number

too low.

The file sequence number used was not what the Application Service was expecting as the

next in sequence. Check, using the Application Service GUI, what the next expected sequence number is.

CH or GW '2001' File too large Reduce file size to below the maximum size allowed and re -send it.

CH or GW '2002' Invalid User Id Check that the user id has been configured correctly. Refer to the SettleNET User’s Guide

CH or GW '2003' Invalid operator reference Contact SettleNET Support Desk

N/A '2004' Invalid Gateway Id Contact SettleNET Support Desk

CH '2005' Invalid final MAC in EOF notification

The file has failed the message authentication code check. Contact the SettleNET Support desk.

N/A '2006' Spare

N/A '2007' Spare

GW '2008' File transfers currently disabled for File Transfer Operator

The Application Service has attempted to return a file to an operator that has been disabled by the Gateway user. Enable the file transfer operator at the Gateway and contact the Application

Service Support desk to re-send the file.

'2009' Reserved

'200A' Reserved

CH '200B' No connection to Gateway. Contact SettleNET Support Desk

‘200C’ Reserved

‘200D’ Reserved

‘200E’ Reserved

‘200F’ Reserved

‘2010’ Reserved

CH '2100' Invalid IOFN [Note 1]

CH or GW '2101' Invalid Sender Address Contact SettleNET Support Desk

GW '2102' Reserved

GW '2103' A file of the same name already exists on the Gateway.

The Gateway is unable to receive a file because a file of the same name already exists in the receive ‘success’ directory for the particular operator (channel).

The Gateway is unable to send a file because a file of the same name already exists in one or more of the transmit directories for the operator.

CH or GW '2104' The recipient could not create

the file.

Failure to create a file. If the problem is Gateway related examine the event file for a possible

reason. Ensure that there is sufficient disk space and that file permissions allow Gateway access to the file transfer directories.

GW '2105' The Gateway disk is full. Check that there is sufficient disk space for the Gateway FTM to create files.

GW '2106' The Gateway could not update the status file.

Check the event file for a possible reason. Ensure that the file is not being locked by the Back Office application before the Gateway has completed its transfer.



Date: 16/01/2019

of 53


Meaning Action

CH '2107' Invalid session number (in FEN) Contact the SettleNET Support desk. Re-send the file.

CH or GW '2108' Invalid split code indicator Contact the SettleNET Support desk.

N/A '2109' Spare.

GW '210A' Invalid operator in the FEN. Note: Due to the nature of this error a status file is not generated. This code appears in an

event. The Application Service has attempted to return a file for a file transfer operator that is unknown to the Gateway. The operator may have been deleted, if so add the operator and

contact the Application Service Support desk to re-send the file

CH or GW '210B' Invalid file name. Check that the file name is of the correct length and that it is made up of alphanumeric characters.

CH or GW '210C' File size too small (less than 8 bytes)

A file that contains the file header and footer along with a message will never be this short. Check that the file has a valid structure.

GW '210D' FEN received for disabled file

transfer mode (Live/Test/Trial)

The Application Service has attempted to return a file for a mode that has been disabled by the

Gateway user. Enable the mode and contact the Application Service Support desk to re-send the file

GW '210E' Error preparing outbound file

transfer (deleting file)

The Gateway is unable to receive a file from the Application Service because it is unable to

delete an existing file. Check that the offending file is not locked by the Back Office application.

CH ‘210F’ CH failed to allocate memory storage for inbound transfer.

Re-send the file. If the problem persists contact the SettleNET Support desk.

CH ‘2110’ CH failed to create interim storage file for inbound transfer.


CH ‘2111’ CH failed to allocate interim

storage file for inbound transfer.


CH ‘2112’ Failed to connect to Gateway. Note: This code won’t appear at the Gateway. It is sent back to the Application Service. The CH was unable to establish a session with the Gateway.

CH ‘2113’ Invalid Application Service identifier.

An invalid Application Service identifier has been used. Contact the SettleNET Support desk.

CH ‘2114’ File size too large. Reduce file size to below the maximum size allowed and re -send it.

CH ‘2115’ Failed to read Gateway configuration file entry.


CH ‘2116’ Gateway is barred. Contact the SettleNET Support desk.

CH ‘2117’ Invalid session number in EOF Notification.

The session number used in the end of file notification does not match the session number carrying the file. Contact the SettleNET Support desk.

CH ‘2118’ Bytes transferred not equal to

bytes specified in FEN.

The total file size received did not match the size that the Application Service had been notified

of. Retry but if problem persists contact the SettleNET Support desk.

N/A ‘2119’ Spare



Date: 16/01/2019

of 53


Meaning Action

CH ‘211A’ Gateway connection was

broken.

Note: This code won’t appear at the Gateway. It is sent back to the Application Service.

The session between the CH and the Gateway was lost.

CH ‘211B’ Invalid length CDU received from Application Service

Note: This code won’t appear at the Gateway. It is sent back to the Application Service. A protocol error has occurred between the CH and the Application Service..

CH ‘211C’ Communications Host is in a WARM state

Re-send but if problem persists Contact SettleNET Support Desk

CH ‘211D’ Request for an uninitialised

Application Service service


CH ‘211E’ Security sub-system error An error has occurred validating the file. Re-send it and if the problem persists contact the SettleNET support desk.

IN CONFIDENCE SettleNET Gateway Application Interf ace Specif ication

BT Radianz Messaging

Issue: Error! Unknown document property name.

Date: 16/01/2019

of 53

14 References

Ref. Title Location

1. SettleNET Release 5 User Guide

Filed in BT’s MS SharePoint ISC Operational Document library

IN CONFIDENCE SettleNET Gateway Application Interf ace Specif ication

Offices worldwide © British Telecommunications plc 2019

Registered office: 81 Newgate Street, London EC1A 7AJ Registered in England No: 1800000

radianz messaging · 4 message queue interface 12 4.1 overview 12 4.2 websphere mq versions 12 4.3...

Documents