The creation of T-workflows is an easy but sensitive operation; to improve their implementation and functionality, the following recommendations are provided:
•All T-workflows begin on the "start" block and must finish on the "end" block.
•Make sure all the block outputs are connected to a subsequent block.
•Design T-workflows in a way to prevent an endless lopped execution.
However, a system watchdog will automatically stop the execution of any T-workflow detected as "looped".
•Divide extended T-workflows into sub-workflows and launch them from a main T-workflow using the T-workflow action.
•Use "Send email using dbMail" actions to notify a process's success or failure.
•Set assets as "not to be broadcasted" and "ok to broadcast" at the start and end of asset production T-workflows.
•Use "MD5 checksum" actions when copying files (e.g. HSM archive) to generate a security file hash as well as when retrieving files (e.g. HSM restore) to check the consistency of the security file hash of retrieved files. It is important to note that the MD5 checksum is only applied to single metafiles; it does not support copy action performed on bundled files.
NB: MD5 Checksum must be performed on the same source and same destination cloud device before and after an archive process.
•Remember that it is possible to narrow T-workflow processes to specific types of assets.
•Consult the wide range of templates to create custom actions that will allow you to suit your system better.
•Use a Flexi-metadata set action at the end of a T-workflow to store its final status on metadata (e.g. QC status); it will allow other T-workflows to use a Flexi-metadata check action to query its current status.
Metadata can be a boolean (yes, no) or an array (done, done with errors, not done, etc.).