¶ File wait step
'File wait step' is found in the 'Common' category of workflow nodes.
¶ What it does
The File wait step node provides a mechanism for a workflow to wait until a file exists at a particular file path or location. Only when the file exists will the File wait node transition to the next step.
¶ Typical uses
Content >>>
¶ How to use it
In general this is controlled by two scripts, the File wait script and the State decision script. The File wait script is used to determine what file is being waited for, the State decision script determines what to do once a matching file has arrived.
The script to run when the waited for file has arrived.
// This script should exit with a result code that then gets mapped to the next state in the diagram
busby.exit(0)
Script that is run to return the name of the file to wait for.
// Return a string containing the full path and filename of a file (can contain globs https://en.wikipedia.org/wiki/Glob_(programming)).
// At the point this file exists the step calls the stateDecisionScript to move on to the next state
return '/file/is/here.txt'
¶ File wait script
The File wait script should return a string which specifies the filename that is being waited for. Usually this script uses some metadata from the incoming job,
so for example the following script uses a job's internal reference as the filename.
return path.format({
dir: '/mnt/myfolder/',
name: root.job.internalRef,
ext: '.mxf'
});
In this example the node path library is used, this is automatically included in Busby scripts. However as long as the script returns the correct string it can be made however it is most convenient.
It is also possible to use {% include {{site.includes.link}} url="https://en.wikipedia.org/wiki/Glob_(programming)" title="glob" %} based matching, which makes it possible to match files that match a pattern rather than match exactly. The following script will match any files that start with the job's internal reference.
return path.format({
dir: '/mnt/myfolder/',
name: root.job.internalRef + '*',
ext: '.mxf'
});
Instead of using a fixed path, a path derived from a location can be used. This approach allows the directory to be different depending on the deployment and/or the host that is currently set. In the example below a folder location called mylocation has been configured, and it is then referenced through the call to the busby.locations object.
return path.format({
dir: busby.locations.mylocation.mount,
name: root.job.internalRef,
ext: '.mxf'
})
When the service is checking for the incoming file, it waits for the file size to settle so that only complete files trigger the state decision script. Also zero size files are ignored, these are often created as placeholders by transfer systems that don't know the file size until the end of a write.
¶ State decision script
In general the state decision script works in the same way as for a script step node. The only difference is that the root object has an additional property called file, this property contains an object with name and path fields. This can be used to retrieve the exact name of the file that was monitored, which is particularly useful when using glob matching in the file wait script.
The following script snippet shows how to use the extension of the arrived file to decide which workflow state for the job to move onto next.
if (path.extname(root.file.name) === '.mxf') {
// handle mxf files
busby.exit(0);
} else {
// handle other files
busby.exit(1);
}
Detailed notes on the configuration editor can be found here
¶ How it works
Content >
Previous: Exception || Next: Manual step
Index of: Workflow Nodes
Back to: Configuration Editor