Post on 18-Aug-2020
transcript
Radianz Messaging
SettleNET Gateway Application
Interface Specification
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 2 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 3 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 4 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 5 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 6 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 7 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).
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 8 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 9 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 10 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 11 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 12 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 13 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 14 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 15 of 53
4.6 Getting a receive message
This section describes how RECEIVE messages are generated.
Back Office Gateway Application Service
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 16 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 17 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 18 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 19 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:
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 20 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:
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 21 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 22 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.
Back Office Gateway Application Service
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 23 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.
Back Office Gateway Application Service
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?
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 24 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 25 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 26 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
be overwritten by the FTM.
Yes (no status file)
DONE File exists (delete failure)
An attempt is made to delete the file.
Yes (no status file)
DO Open (for read) failure
For example:
File is open by another process
Yes (no status file)
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.
Yes (no status file)
PENDING Open (for read) failure
For example:
File missing or file open by another process.
Yes (status file generated)
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 27 of 53
5.20.2 Receive 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)
DONE File exists (delete failure)
An attempt is made to delete the file.
Yes (no status file)
STATUS Create (for write) successful
If file already exists, it is overwritten.
No
Create (for write) failure
For example:
File already exists and is open by another process.
Insufficient disk space.
Yes (no status file)
DO Create (for write) successful
If file already exists it is overwritten.
No
Create (for write) failure
For example:
File already exists but is open by another process.
Yes (status file generated)
PENDING Create (for write) successful
If file already exists it is overwritten.
No
Create (for write) failure
For example:
File already exists but is open by another process
Insufficient disk space.
Yes (status file generated)
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 28 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging
Issue: 1.5 Date: 16/01/2019
Page 29 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 30 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
One per individual ‘operator’
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
One per individual ‘operator’
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 31 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 32 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 33 of 53
Field Col. Width Type Description
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 34 of 53
Field Col. Width Type Description
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 35 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 36 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)
The FTM has attempted to notify the
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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 37 of 53
Code (Hex)
Error Code Description
Status File Text Cause Action
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
0014 Receive only code
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
0016 Receive only code
0017 FEN rejected due to timestamp error
File transfer rejected by Recipient
or Communications Host (FEN timestamp)
The FTM has attempted to notify the
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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 38 of 53
Code (Hex)
Error Code Description
Status File Text Cause Action
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.
Check files and directories.
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
0021 Receive only code
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.
Check files and directories.
Resend file
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 39 of 53
Code (Hex)
Error Code Description
Status File Text Cause Action
0025 Error closing file Unable to close file The FTM has experienced an error closing a file.
Check files and directories.
Resend file
0026 Error moving file Unable to move file The FTM has experienced an error moving a file.
Check files and directories.
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 40 of 53
APPENDIX D2. Receive Status Codes
Code (Hex)
Error Code Description
Status File Text Cause Action
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)
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 41 of 53
Code (Hex)
Error Code Description
Status File Text Cause Action
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.
Check files and directories.
Re-receive file.
0005 Transmit only code
0006 Transmit only code
0007
to 000F
Spare
0010 Transmit only code
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
0013 Transmit only code
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 42 of 53
Code (Hex)
Error Code Description
Status File Text Cause Action
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.
Check files and directories.
Re-receive file
0017 Transmit only code
0018 Transmit only code
0019 Transmit only code
001A
to 001F
Spare
0020 Transmit only code
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
0023 Transmit only code
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 43 of 53
Code (Hex)
Error Code Description
Status File Text Cause Action
0024 Error deleting file Unable to delete file The FTM has experienced an error deleting a file.
Check files and directories.
Re-receive file
0025 Error closing file Unable to close file The FTM has experienced an error closing a file.
Check files and directories.
Re-receive file
0026 Error moving file Unable to move file The FTM has experienced an error moving a file.
Check files and directories.
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 44 of 53
Code (Hex)
Error Code Description
Status File Text Cause Action
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.
Contact BT Support Desk
Operator is unknown Originator has sent a file notification containing an unknown originator id.
Check that the originator configuration wasn’t recently deleted.
Contact BT Support Desk
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 45 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 46 of 53
Description ASCII Code
Disconnect
Connection Refuse
1000 Series Error Codes
(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
3000 Series Error Codes
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 47 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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 48 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
Contact SettleNET Support Desk
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 49 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.
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 50 of 53
Generator Error Code
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.
Re-send the file. If the problem persists contact the SettleNET Support desk.
CH ‘2111’ CH failed to allocate interim
storage file for inbound transfer.
Re-send the file. If the problem persists contact the SettleNET Support desk.
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.
Re-send the file. If the problem persists contact the SettleNET Support desk.
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
SettleNET Gatew ay Application Interface Specif ication
Radianz Messaging Issue: 1.5
Date: 16/01/2019
Page 51 of 53
Generator Error Code
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
Contact SettleNET Support Desk
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
Page 52 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