Build any type of complex sFTP script and have it logic-enabled to address recovery steps.

In our last TechTip, we explained how to automate simple sFTP processes using only one CL program. This article will explain advance scripting techniques that also can be automated with just one CL program. We'll assume that you have already downloaded and installed ARP-SFTP.

If you've automated several sFTP processes, you most likely have run into situations where you wish you had decision-making capabilities built into your script. Yes, I mean with real "if-then" type of logic.

sFTP Server Setup

The first step is configuring a definition for the remote sFTP server that will store parameters for connecting and logging in. In this case, we're going to connect to a server that's used for storing EDI files. You can configure the server by using the command AWRKFTPSVR, as Figure 1 shows.

Figure 1: Configure the sFTP server.

First Scenario

Let's go through a scenario and show sample code of how to deal with it. The scenario: You've been told that there are several files in a directory named "outbox" that you need to retrieve from the EDI sFTP server. They're named dynamically with a date stamp, and after you download each file, you need to delete that file from your outbox directory.

In this scenario, we're going to connect to the sFTP server (named EDISFTP in our server configuration) that has EDI orders to retrieve, change into the directory named outbox, retrieve each file even though we don't know the name of it since it has a date stamp, and after confirming it was retrieved successfully, we'll delete it. To do this, we'll create a looping process in our CL program and start by issuing a list request to the server to pull the results of the list request into an internal file contained within the sFTP process. The looping process will retrieve each remote file name into a variable in our CL that will be used by our GET and DEL commands. We'll monitor to make sure the GET worked properly before the file is deleted from the directory. After confirming the delete worked properly, we'll retrieve the next filename in the list and repeat this process until all files have been retrieved and deleted from the outbox directory. Figure 2 and Figure 3 show the CL program used for this scenario.

Figure 2: The files are listed on the remote server, and those names are pulled into a GET request.

Figure 3: GET is confirmed before DELETE, and then the program loops to GET the next file.

This article took a new turn when we ran this script. Normally, our Windows-based sFTP server works without any issues, but something unexpectedly wonderful happened. The server had some sort of problem in the middle of the sFTP session, demonstrating the strength of the ARP-SFTP scripting tool. The remote server had three files on it, and the program failed trying to retrieve the second file. Luckily, with a CL-based sFTP script, you get an escape message and can prevent damage such as trying to delete a file that was not successfully retrieved. Figure 4 shows the joblog of the failed session. Figure 5 shows the files that were still left in the directory on the sFTP Server. Clearly, it's really important to have an intelligent script that can address unexpected errors. This was a great example of that.

Figure 4: The error was tracked in the joblog for easy resolution.

Figure 5: You can see that the remote server still has files that were not retrieved.

Second Scenario

Now let's go through a different scenario and show sample code of how to implement it. The scenario: You've been told to upload your EDI files into a directory named "putdir" using a date stamp for the name. After your put process completes normally, you need to move the files into a directory named "putdir/ready" for the server to process.

In this scenario, we're going to connect to the same sFTP server named EDISFTP. Our process will PUT one EDI file (but it could do multiple files) using today's date as the file name. We'll monitor to make sure the file transferred successfully and then move it into the directory to be processed by issuing a rename command.

Figure 6 shows the CL program for these commands.

Figure 6: This script contains the PUT and RENAME commands.

We ran our CL program, and the joblog is shown in Figure 7.

Figure 7: The joblog confirms successful completion.

Our two scenarios could have been combined into one CL program with all of the recovery logic embedded, but we separated the scenarios to make it easier to explain. In summary, you could build any type of complex sFTP script using this tool and have it logic-enabled to address recovery steps.

In our next TechTip, we'll look at advanced features in this free tool.

To download this free product, click here. If you have any questions, contact This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails