Ftscripts can generally be restarted if, for example, they have been aborted due to a system crash. Restrictions apply only to the following activities:
executeScript, if repeatable=no was specified
createDirectory, if faultIfExists was specified
deleteFile or deleteDirectory if faultIfNotExists was specified
If the openFT-Script request is aborted during the processing of the statement then it is not possible to determine whether the activity has been completed. In the above cases it is not clear, when the restart is performed, how the Ftscript should continue to run.
If, for example, a directory that was to be created already exists then it is not possible to determine whether it was created by the aborted createDirectory activity or whether it already existed before the openFT-Script request was run.
If the restart operation encounters this type of ambiguous situation then it reacts as follows:
Activity | Response on restart |
| Activity aborted with the error ft_resumeForbidden |
| If the directory already exists then activity aborted with the error ft_recoveryCreateDirectory |
| If the file does not (or no longer?) exist(s) then the activity is aborted with the error ft_recoveryFailed |
This response may occur if the openFT instance has been switched. If the openFT instance is deleted then all running openFT-Script requests are interrupted. They restart when the instance is switched. In the above cases, processing waits for approximately 2 seconds for the end of the activity after interruption of the request. In the case of lengthy executeScript activities this may not be enough, with the result that this openFT-Script request is aborted with an error when a restart attempt is made.