Client Connection: IBM Sterling Connect:Direct

Fields with the asterisk * are mandatory.

Properties	Description
NAME *	Name of the Connect:Direct connection you are creating. The maximum number of characters is 128. Blanks and these special characters: ' " | are not supported.
DESCRIPTION	Description of the Connect:Direct connection you are creating. The maximum number of characters is 2048.
STATUS	Enable or disable the client connection. Possible values: Enabled (default value) Disabled
NODE NAME *	The Connect:Direct node name of the counterpart.
USERNAME	Insert the credentials to access the counterpart Connect:Direct node.
PASSWORD	Insert the credentials to access the counterpart Connect:Direct node.
DATA ONE C:D SERVER NAME *	This fields must contain one of the "Connect:Direct" protocol type servers defined in Setup → STENG, Clusters and Servers → New Server.
SCRIPT TO SEND FILES	The Connect:Direct CDP template to send a file to this Actor. See the note below this table.
SCRIPT TO RECEIVE FILES	The Connect:Direct CDP template to send a file to this Actor. See the note below this table.
CONFIGURATION TEST	Use this section to test that the Cluster and the STENG are connected correctly. Select a Cluster and a STENG you want to test and click the TEST button. Data One automatically selects a Cluster and a STENG to test the connection. Note that a Cluster will be selected only if it is the only one available. A message with a green check will confirm a successful connection. A message with a red exclamation mark will warn about an unsuccessful connection. The message also details the reason why the connection fails. The connection might not be successful for different reasons, each of them depending on the transport type and the configuration. The first time you try to test the connection, if trusting certificates are missing, an error message detailing the unsuccessful connection will appear. In this case, go to the Setup → Untrusted Cache → Certificates tab and trust the relevant certificates. Note that trusting certificates in the Untrusted Cache page may not be sufficient to establish a successful connection. Refer to the Untrusted Cache section of this documentation for all the details.

The receive and send file process template fields must contain the file name of CDP located in ${SPENG_HOME}/cfg/cdptemplates.

Connect:Direct Configuration

Share folders between PRIMEUR Data One and the Connect:Direct Node

When PRIMEUR Data One and the Connect:Direct Node reside on different machines, the first and most important step is to correctly manage shared folders between them. Connect:Direct sends and receives files based on folder policies and the cdp script must contain a direct reference to the filesystems. When Connect:Direct acts as a server, files are received on its filesystem in a folder specified by the sender. If Connect:Direct and PRIMEUR Data One do not reside on the same machine, files can be received only if they share a folder.

To configure the Data One Steng for the Connect:Direct server, follow these steps:

1. If the Connect:Direct server is remote, you must mount shared filesystems to exchange files. See How to remap shared folders below.

2. If the Connect:Direct server is remote, go to /ghibli-home/wlp/usr/servers/steng/cfg to configure the speng.cd.pathremap.table file according to the shared folder defined in the previous step.

3. Copy the Connect:Direct API library (CDJAI.jar) in this folder: /ghibli-home/wlp/usr/servers/steng/lib/cd.

Important Note: Once the installation and the configuration are completed, restart the STENG before starting the server!

How to remap shared folders

Once the two file systems are shared, you must remap the shared folders. To do this, edit the path remap configuration speng.cd.pathremap.table file in the directory /ghibli-home/wlp/usr/servers/steng/cfg.

This configuration file consists of several pairs of folder paths to remap incoming and outgoing files. Below, you can find some examples. Note: Paths may slightly change due to differences between Windows and Unix.

Paths may slightly change due to differences between Windows and Unix.

#########
## SpEng Path <----> Local CD Path
## ex:
## C:\share\cd=/home/connect/share/cd
##
## SpEng Path <----> Remote CD Path
## ex:
## /winCdrive/Out/=C:\Out\
#########

# First (incoming files)
C:\CDReceive=Z:\CDReceive

# Second (push files)
Z:\CDShared=C:\CDShared

# Third (pull files)
/winCdrive/Test/Out/=C:\Test\Out\
/masterInDirCd=C:\CDShared
C:/CDShared=Z:\CDShared

The first example applies to incoming files:

• "Z:\CDReceive" is the shared partition defined on the local machine (DataOne) • "C:/CDReceive" is the shared partition on the remote Connect:Direct server

The File received by the Connect:Direct server will be placed in the "C:/CDReceive" folder. The DataOne\CD connector will be prompted that a new file has arrived. In the DataOne machine, the file is stored in the "Z:\CDReceive" folder, where it is taken and moved in the DataOne filesystem.

The second example applies to push operations. Outgoing files are copied from the DataOne filesystem to the shared folder "Z:\CDShared". When the DataOne\CD connector submits the “cdp” script to the remote Connect:Direct server, the correct remapped folder "C:\CDShared" will be specified in the Connect:Direct server.

The third example applies to pull operations. For Windows convention, we will use "/winCdrive" to indicate the "C:" drive path. The first step is to define a valid path for the Connect:Direct machine, for example: "/winCdrive/Test/Out/SourceFile.txt" and a virtual destination path, for example: "/masterInDirCd/DestFile.txt". Here below, you can find the remapping operations that are executed:

• From /winCdrive/Test/Out/ to C:\Test\Out\ (remapped path to fetch the source file on the C:D remote node) • From /masterInDirCd to C:\CDShared (remapped path where the file is received on the C:D server) • From C:/CDShared to Z:\CDShared (remapped path when the file is received, see first example)

Suppose you need to use several ConnectDirect scripts (CDP) to connect with the same actor. In that case, you must define one or more REMOTE CONNECTION configurations, each one with the relevant RECEIVE FILE PROCESS TEMPLATE and SEND FILE PROCESS TEMPLATE.

Correct management of Connect:Direct process in status HOLD 🚀

When Connect:Direct detects a transport problem (e.g., an inactive partner), the operation to be performed at the end of the retry attempts is configured in the Connect:Direct netmap.cfg file. The operation to be performed can be either to delete or to hold:

• If delete is set, the process is deleted, and a record with the identifier PERR is issued in the statistics. Data One intercepts this record and acts accordingly, setting the transport to FAILED.

• If hold is set, the process is not deleted and set to HOLD. Data One intercepts this status and, when the set timeout expires, sets the transport to FAILED. If a process in HOLD is restarted in Connect:Direct (even after a long time), a mismatch between Connect:Direct and Data One could occur. To avoid the mismatch, a hold timeout can be set in jvm.options manually:

  • connect.direct.hold.timeout.sec=<seconds>

  • connect.direct.hold.delete=true|false

The addition and tuning of these parameters depend on the client's environment and system policies.

connect.direct.hold.timeout.sec=<seconds> It sets the number of seconds after which Data One considers a transport failed. Values:

• 0 / not defined / default: wait forever.

• > 0: seconds after which Data One considers a transport failed.

connect.direct.hold.delete=true|false It is evaluated only if connect.direct.hold.timeout.sec is set to a value higher than 0. Values:

• true: when the Connect:Direct process is restarted during the timeout, the Data One transport will also be restarted. If the timeout expires and the process is still on HOLD, the Data One transport will be set to FAILED and the Connect:Direct process will be deleted.

• false (default): after the transport is declared FAILED, the process in Connect:Direct is left in HOLD.