Today I come across the item on the frequencies of the FTP scheduler being set to send flat files over to our remote FTP server. As usual, I request the local country IT lead to define the schedules that they may have planned for the scheduling but I realize I have missed out an important component – the naming convention of the file for each EDI message which is a text file.
In this system that we implemented, the critical component is the file name format that each country will be sending over to one remote FTP server. We have defined a country folder for each, breakdown into detailed sub-folders for manageability. From the system, each time a status flag for a particular form is updated it generates one text file for that, being differentiate by country code and time stamp that is obtained from the system clock on the time this file is generated. The logic of the various status flag for that form is to update by sequence of events, capturing by time stamp. In the real world, no more than 2 different status flags is updated at the same time for the same form. However if we are to perform batch run of multiple files of the same form to ftp over to the remote FTP server, the remote server’s extraction logic does not recognize which files of that form to be processed first.
To avoid this situation, we need to define operation processes to determine the gap in the timings of various cutoffs to send the files over to remote FTP server in which will process these files to send over to the Customer’s system. As such, this means that at certain stages of the processes we need to ensure what activities must have taken place to enable the scheduling to occur. At the same time, this will also impact the return of messages back to Customer’s system after the network recovery from loss of network connections. This is something that need to work in details and to be agreed by both organisations.