FTP automation is usually achieved by employing scripts or batch files. There's an easier way to do it.
When a system administrator wants something to be automated, like say an FTP upload or download, he usually turns to his bag of scripts.
The problem with using scripts
While scripts are very versatile and can be very handy for FTP automation, they can also be very hard to manage.
Companies encounter several changes over time. Business processes change. IT infrastructures change. Technologies change. Applications change. Business logics change. Even the person who originally wrote the scripts can move on to another company.
All these changes can render old scripts obsolete and cause errors. For certain business processes to work, old scripts will have to be troubleshooted and modified. That can be a problem for the person who has taken over. In most instances, it would be much easier for the new guy to discard the old scripts and write new ones.
Unfortunately, script writing requires additional skills. To write scripts, a system administrator should have some programming background and familiarity with scripting languages.
What if the new hire doesn't know how to write scripts? Or what if he/she is more accustomed to another scripting language? In fact, it's even possible for a person who uses exactly the same scripting langauge as the original script author to have difficulty understanding the "flow" of the original scripts. All these obstacles can cause serious downtime.
A better option for automating file transfers
In JSCAPE MFT Server, there's a better way to automate. It comes in the form of what are known as Triggers. Triggers can do practically everything a script can in the context of transferring files but in a much easier way.
It's presented in an intuitive graphical user interface (GUI) backed by a context sensitive help function that guides you throughout the trigger creation process. Through triggers, automated file transfers are easier to build, modify, reproduce, document, and audit.
A trigger generally consists of three parts: a trigger event, a set of trigger conditions, and one or more trigger actions.
A trigger event (or trigger event type) is any event occurring on the server that can be used to initiate a trigger. Some supported events include:
- the current time (used for scheduled file transfers),
- a file upload,
- a user login,
- an account deletion,
- an administrator account login,
- the arrival of an AS2 receipt,
- a data connection error,
- a directory creation,
- a DLP rule match,
- the arrival of an email,
- a file deletion,
- and many others.
So, basically, once you've assigned an event to a trigger and that event takes place, the trigger will fire.
Events can be very broad and can potentially launch several triggers listening to a particular event type. For example, any file upload can fire up 10 triggers if those triggers are all listening to the file upload event type. In order to let a trigger respond to a specific file upload, you use what are known as trigger conditions.
So, going back to that file upload example, you can specify that an affected trigger will only continue to execute if the file upload request involved a file named "specialupload.txt".
You can further specify that the upload should have been received at a particular server port, and that it should have happened at a particuar time of the day, and that the file was to be uploaded to a particular directory, and so on. A trigger defined by these trigger conditions will therefore continue executing if and only if all these conditions are satisfied.
You can build more complex expressions by combining variables, functions, constants, and operators. After that, you can test the expression to see if it works before proceeding with the trigger actions.
The variables and values you can use in a trigger condition will depend on the event type. So if a variable isn't present in a trigger, then it could be because that variable wouldn't make sense in the context of the event type that was used.
Once you're done narrowing down to the specific event that the trigger should respond to, the next thing would be to add one or more trigger actions. A trigger action is something the server would do in response to the trigger event (subject of course to the restrictions defined in the trigger conditions).
So, for example, you might like the server to:
- encrypt the uploaded file,
- scan the uploaded file,
- send out a notification email,
- zip the uploaded file,
- send out copies to 10 other servers,
- append the upload details to a report,
- initiate an AS2 transaction,
- move the file to another directory,
- move another file to another directory,
- decrypt the file (if it is encrypted),
- execute an HTTP request,
- and several others
Perhaps the best way for you to see how all these fit together is by browsing through some of the examples on this blog. Check out some of the examples we've shared below.
Some examples to follow
For more examples browse through our collection of articles on triggers.
Please note that the use of FTP is no longer recommended, especially if you transmit sensitive files. FTP is an insecure protocol that's vulnerable to man-in-the-middle and other attacks. To learn more about FTP's weaknesses and the more secure options for transferring files, please read the following articles:
Fortunately, JSCAPE MFT Server triggers can be applied to more secure protocols (like SFTP, FTPS, and HTTPS) too, as evidenced in some of the example links we shared earlier. Would you like to try your hand at using triggers? Download a free, fully functional evaluation edition of JSCAPE MFT Server now.