The other way around

Day 7

For my brother Lee he only needed to use his connection in one direction, from his Windows node to the remote UNIX node.

If he had needed to do it the other way around this is what I would have told him.

The concepts are the same, just presented differently as I said previously. We already have the netmap configuration, but we will need to make a configuration to allow the remote UNIX machine to send files to our local node.

The files that are received by our local node from the CD.REMOTE will have to be owned by a user account on our local node.  We could just use any local user account but it would be better to create a user specifically for this purpose and lock down the directories as mentioned previously when we set up the UNIX side of the configuration.

First let's set up Connect:Direct to allow a local user appusr1 to work with Connect:Direct.  Double-click the "User Authorities" in the left pane of the Connect:Direct Requester.  As you can see in the image below there are some entries that start with an asterisk which indicates they are templates.  In our case we are defining appusr1 as a non-administrative user of Connect:Direct.

Click the "New Genuser" and fill in as below. The controls will inherit from the templates you saw earlier and of course you can override those values here if you desire.

So how do we associate a incoming remote transfer with the local user we want to own the files?  This is done using the proxy definition.  Double-click "Proxies" in the left hand pane of the Requester and enter the fields as below.

So we are saying here that the remote user appusr1 from the remote node CD.REMOTE will be mapped to the local user appusr1.  It doesn't have to be the same name as I have done here.  Normally I create user accounts that reflect the name of the application that will consume the file if a suitable user account doesn't already exist.

If we didn't define a proxy for the remote Connect:Direct user, the remote Connect:Direct process would have to supply a SNODEID containing a local user account name on our local node together with a password.

This is not good for several reasons.  It is not a good idea to advertise local account information to anyone outside of your organisation.  Also hard coding passwords in scripts of any kind is also not a good idea because they might be seen, and if you have an information security department they will want you to change your passwords frequently which would mean amending all your scripts that contain passwords frequently.

The nice thing about Connect:Direct proxies is that the remote node doesn't care about what local user account you might be using, and they do not have to supply a password.  If their user is authorised to use Connect:Direct on the remote node they do not need to do anything regarding the user being used as you have covered that in the proxy definition.

For my brother's connection they were not using Secure+ to encrypt the data in transit or use it to authenticate using digital certificates.  If you read my post "Secure IT" then you will know that I always use Secure+.  In a later post I will give an example of doing just that.

Making a connection

Day 4

For a quick test of the connection you can double click on the “Send/Receive File” in the left hand pane of the C:D Requester. You should be presented with something that looks like this:

In the main tab here you can see the key information for the test transfer. The SNODE is the secondary node i.e. the other node called “CD.REMOTE” in my example. The location of the file to transfer is next, and then the destination file name. 

It would be a good idea to agree on the destination file name with your corresponding number in charge of the other Connect:Direct node. This is so there are no surprises, like overwriting an important file or accidentally having your file processed. Ideally the file being transferred should not contain any actual data, and the name of the file should make it clear that it is not a data file. The other node can be configured to have a default download directory that is separate from any real data directories if his system is a production machine.

The Connect:Direct administrator of the other node will need to know which user name you are using for the Connect:Direct process so he can configure his system to allow your transfer to go through. You will probably already know who you are logged on as, but it is also displayed in the bottom right hand corner of the Connect:Direct Requester application window.

For now press the “OK” button and you should see something like the next image on your display:

Here you can see that the bottom horizontal pane in the Requester is showing a Connect:Direct process called “SENDRECV” from a node called “NICKE” to another node called “CD.REMOTE”. The “Status” & “Queue” columns may change quickly. In this screen above you see the process is pending execution. When the process finishes the “Status” & “Queue” will be blank as the process is no longer running and therefore is not in a queue.

The question is though was it successful or not? Double click on the 'Select Statistics' in the left pane and select a time period and press enter. You will see a lot of horrible information. The good news is that you are only really interested in the column labelled 'CC' which stands for 'Condition Code' which should be 0 if everything is OK. 

The rows that you are interested in are those that have a RecID column of 'CTRC' which stands for Copy Termination ReCord. If you see the row that is associated with your process number when you submitted the process when you clicked 'OK' on the 'Send/Receive File' form, you can double click it to get all details of the transfer. 

You can scroll down to see source/destination file names bytes transferred etc. So hopefully now you have proved that you can send a file to the other side.

Configuring the Connect:Direct Netmap

Day 3

This might be a good time to point out to you that Connect:Direct uses two TCP ports; 1363 for API/command-line/C:D-Requester connections and port 1364 for Connect:Direct Server to Server connections. These are the port numbers by default and of course you can change those if you need to.

A Connect:Direct node keeps a list of other Connect:Direct nodes that it connects to. This list is called the “netmap”. It maps a Connect:Direct node name to an ip-address and port number. Connect:Direct can connect via other network protocols such as SNA and DECNET, but TCP/IP is by far the most common and I will assume its’ use throughout. This is so the node knows how to contact the other node when it needs to. The node being connected to also needs a corresponding entry in its’ “netmap” too. In the left hand panel of the Connect:Direct Requester double click on the “Netmap” entry under your node name. This will list the contents of the netmap. Right mouse click in the middle panel and select the “Insert...” menu item.

Essentially you only need to give the name of the remote node and the ip-address and port number, and select the only mode listed “Mode1”. All the other values can take the defaults. You will not have to fill in the tab labelled “APPC”, and on the “Communication Path” tab there is just one path to choose, so that’s easy!

Click “Ok” to exit the “Node Properties” dialog box and you should be presented with something like the following:

Right mouse click and select “Apply” to make your changes to your node’s configuration.

Now all you have to do is get your remote administrator to configure his netmap with your node.

In the next post I’ll describe how we test this connection.

Configuring the C:D Requester

Day 2

Before we get into the configuring of Lee’s Connect:Direct Windows, I’d like to just give few more details about testing the connectivity to the remote Connect:Direct node. The possible outcomes from the “telnet” test are “refused”; probably a firewall not configured appropriately. “failed” means that there was nothing listening on that port, probably because the remote Connect:Direct node was not running. “Timeout” means that no route to the remote address was found. If you get this then you will probably want to perform a “tracert” and see where the connection is being held up. It could be a router or even a routing rule on the server depending on where the “tracert” shows where the problem is. 

The outcome you are looking for is when the “telnet” program actually connects on the port you gave it. This shows that something at that address was listening on the said port and accepted your connection request. If this happens you won’t see anything useful in the “telnet” screen so just kill the command prompt window.

It was also be a good idea for someone at the remote node to perform a similar exercise to prove that the network connectivity is actually in place before troubleshooting the Connect:Direct configuration.

For configuring Connect:Direct Windows we will be using the Connect:Direct Requester program that you should be able to find after clicking the start menu button then “Programs” and then “Sterling Commerce Connect:Direct ...” and then click on “C:D Requester”. Hopefully you will see something similar to the image below:

 

If you installed Connect:Direct Windows or if you have previously configured the C:D Requester to point to your Connect:Direct node then you should see your node name in the left hand panel in the nodes tab. In the above picture you can see my node name NICKE. If you don’t have any nodes listed there then you will have to look in the “Node | Connection Settings | Insert Node” menu and configure your connection to your local node. 

When you have something like the left panel above then we can configure the connection to the remote node.