A script file must be specified when running Robo-FTP as a service. Special considerations apply when programming a script to be used in a service:

Continuous looping

A typical deployment of Robo-FTP as a service uses a script that runs in a continuous loop. One common way of doing this is with the GOTO and PAUSE commands, as shown in the following example:

:loop ;; "loop" label

FTPLOGOFF ;; main script contents: download files from "mysite"

FTPLOGON "mysite"

CD "C:\data"

RCVFILE "*"

PAUSE /for=300 ;; wait 5 minutes before the next round of downloads

GOTO loop ;; jump back to the "loop" label above

Another common design for service scripts uses the GOTO and CRON commands to suspend processing until it is time to awaken to perform one or more tasks at a specified time or date. Once the task is complete, the script loops back and is suspended until the next period of activity, as in the following example:

:loop

CRON ;; suspend execution until the next task

PERFORM %nextcmd ;; is ready to be performed

GOTO loop

Service scripts are also often designed for real-time processing so they are always looking for something to do. For example, the hot send and hot receive styles of service script constantly poll a folder for new files and then react accordingly when a new file is discovered.

See also: CRON, Control flow

Permissions

File and folder permissions must be considered when deciding which Windows account will be used to run the service. For example, the account used must have permission to log in as a service. Permissions are usually to blame if a script works fine when you run it in the main console windows but fails when launched as a service.

Network Access

The default service account is the built-in LOCAL SYSTEM account but it does not have access to network resources. Use a local or domain account with sufficient permissions (for example, NETWORK SERVICE) if your script reads or writes files on the LAN. Microsoft recommends using a UNC path instead of a mapped drive to access network files from a service. See: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685143(v=vs.85).aspx. Therefore, if DOSCMD seems like a good solution to an automation challenge involving a network resource you should consider Microsoft's warnings and any potential workarounds before deciding to map a drive in a Robo-FTP service script.

Error handling

The IFERROR command is a powerful tool in service scripts designed for unattended execution. Use this command to catch and recover from potential failures including network outages and unexpected changes to login credentials or permissions. Many script developers choose to send an automated email message alerting support staff when an unrecoverable error occurs.

Important

It is strongly recommended that you exhaustively test any script file that you intend to run as a service in the normal Robo-FTP console window before using it as a service.

Monitoring and logging

Unlike other Windows services, a Robo-FTP service does not log all results and errors to the System Event Log. Instead, you should use the LOGMSG, DASHBOARDMSG, or LOGNTEVENT script commands to monitor operation of a Robo-FTP service. Do not use commands like ASK and PROMPT because interactive commands are not permitted in service scripts. If you plan to install the service from the command line then the script should include the SRVNAME command so that the Monitor utility can connect to it.

Logging is an importing tool for diagnosing problems with service scripts because they are typically run without the normal Robo-FTP console window interface. The LOG and TRACELOG script commands are used to control logging.

Halting a service

Typically a running Robo-FTP service will remain active until the script executes the EXIT command. A service may be stopped manually using the Windows Service Manager, the Service Installer or the Enterprise Dashboard.

If your script logic contains steps that must not be interrupted, you can design it to use a special shutdown script for orderly termination.