DTA processing properties

The Gateway Server can be configured to send files to and receive files from an SVPCo Distributed Traffic Agent (DTA). The DTA uses Sterling Commerce® Connect:Direct® to communicate between the bank and the DTA. Connect:Direct is a separate product that must be installed before you configure the Gateway Server for DTA support. Gateway can start multiple Connect:Direct connections to send and receive multiple files at the same time. The number of Connect:Direct connections used to send files is equal to maxOutFileThreads, and the number of Connect:Direct connections that are used to receive files is equal to maxFileThreads. However, the number of Connect:Direct connections that run is restricted by the Connect:Direct license.

Note: When a DTA is used, Gateway requires that you install the Sterling Commerce Connect:Direct Java™ API. It includes a JAR file, cdjai.jar, that contains the Java version of the Connect:Direct APIs. The cdjai.jar file must be added to the system class path before the Gateway Server is started.

The following forms of data can be sent between the bank and the DTA:

An X9.37 file. SVPCo refers to this file as the payload.
A transmittal message.

The transmittal message describes the payload and is used for notification purposes. Transmittal messages are sent by using either IBM® MQ or Sterling Commerce Connect:Direct. Since DTA is not allowed to push data into the bank and it is more difficult to use Connect:Direct in this case, consider sending transmittal messages by using IBM MQ.

Note: When IBM MQ is used to send transmittal messages, Gateway Server needs the Java IBM MQ support loaded. Ensure that the com.ibm.mq.jar and connector.jar files are in the system class path before the Gateway Server is started.

Because the payload can be large, it must be passed to and from the bank and DTA by using Sterling Commerce Connect:Direct.

To communicate with a primary and a secondary DTA, set up two Gateway Server instances. Configure one Gateway Server to communicate with the primary DTA and the other Gateway Server to communicate with the secondary DTA. A Gateway and its configured DTA send and receive files from each other. If two DTAs are configured (primary and secondary), and each is for a specific Gateway Server, the pickup zone for each DTA needs to be shared if the DTAs share a IBM MQ queue.

If the DTAs share a IBM MQ queue, but do not share a common pickup zone, both of the Gateway Server instances try to process the IBM MQ messages for both DTAs. When a Gateway Server attempts to process a file that is not on the DTA that it is monitoring, it receives an error when it tries to retrieve the file. That Gateway Server produces messages that indicate the file could not be retrieved. The Gateway Server puts the IBM MQ message back on the queue so the other Gateway Server can retrieve the file. All files are eventually processed, but both Gateway Server instances have errors. This problem is resolved by using separate IBM MQ queues for each Gateway Server or by using a shared pickup zone for both DTAs.

If the sending of an outgoing transmission to the configured DTA fails, the Gateway Server instance places the failing file in the path set in the out2ndSourcePath outgoing file processing keyword. This keyword is the outgoing source path of the other Gateway instance. To handle problems when transmissions are being sent, consider setting both Gateway instances to point to each other. This configuration automatically routes DTA transmit failures to the source path of the other Gateway instance for transmission to the other DTA. When both DTAs are inaccessible, the files are marked so that they are not continuously passed back and forth between the instances when the transmissions fail.

If these two Gateway Server instances are set up on the same server, specify different serverPort numbers for each Gateway Server instance. Define unique directory sets for each instance, particularly for the intermediate path. The ftpRelativePath must be updated to reflect the unique path of the intermediate directory. The relative path starts from the root directory of the FTP daemon that is running on the Gateway Server.

Also, define unique directories for each Gateway Server instance for other paths such as dtaRcvFileTransmittalPath, dtaSndFileTransmittalPath, and dtaProcessNotificationPath.

The following table shows the configuration options that are used to control how files are sent to and received from a DTA. If IBM MQ is not used for transmittal messages, ignore the IBM MQ parameters.

Table 1. DTA processing properties
Keyword	Values or example	Description
dtaMsgMode	OFF, MQ, MQUNIX, or CD	Mode that is used for transferring DTA transmittal messages to and from the DTA. If DTA is not in use, do not set this field or set it to OFF. MQ and CD are used when DTA is running on Windows. MQUNIX is used when DTA is running on UNIX or Linux®. The Gateway does not support CD mode when DTA is running on UNIX or Linux.
dtaTransmittalID	example.com	Each transmittal message contains an identifier that uniquely identifies the bank from which it came. Enter a unique value for the institution.
dtaSystemID	TEST01, PROD01	Identifies whether the payload is being sent to a test or production DTA system. Each DTA has an associated system ID; this keyword is the system ID. This value is put in the transmittal message that is sent to the DTA.
dtaRcvFileTransmittalPath	/opt/ibm/ftm/runtime-processing/inbound/dta/transmittals/source/primary	The path to store transmittal messages related to receiving a file from the DTA. Received transmittal messages include inRoute and delivered. The Gateway sends a pulled and a validated (or unprocessable if the file fails to pass validation) message to the sending point. When end-of-day runs, Gateway Server deletes all files in this path that are older than fileKeepDays. Note: The DTA files for outbound Gateway are at /opt/ibm/ftm/runtime-processing/outbound/dta/transmittals/source/primary.
dtaSndFileTransmittalPath	/opt/ibm/ftm/runtime-processing/inbound/dta/transmittals/destination	The path to store transmittal messages related to sending a file to the DTA. The Gateway sends a ready message and receives an inRoute, delivered, pulled, and validated (or not able to be processed) transmittal message from the receiving point. When end-of-day runs, Gateway Server deletes all files in this path that are older than fileKeepDays. Note: The DTA files for outbound Gateway are at /opt/ibm/ftm/runtime-processing/outbound/dta/transmittals/destination.
dtaProcessNotificationPath	/opt/ibm/ftm/runtime-processing/inbound/dta/notifications	The path to store process notification messages received from the DTA. Generally, the DTA sends process notification messages as a result of an error condition on the DTA. For example, error conditions such as loss of connectivity with the super DTA or the receiving bank DTA. When end of day runs, Gateway Server deletes all files in this path that are older than fileKeepDays. Note: The DTA files for outbound Gateway are at /opt/ibm/ftm/runtime-processing/outbound/dta/notifications.
dtaMaxFileRetrievable	0	The maximum number of times Gateway tries to retrieve a file before it skips the file and commits the message.
dtaReceiveRetries	20	The maximum number of times to retry looking for completion of file copying from DTA to local directory. The default value is 20 and the range is 1-100.