Cloud File Access Trigger
The Cloud File Access trigger initiates a transfer as soon as a file is added to or modified in a container or bucket in the cloud.
The individual properties are:
| Property | Description |
|---|---|
| Container/Bucket Name | Enter the name of the container/bucket to be monitored. You can also select it from the drop-down menu. |
| Scan Interval | The container/bucket is checked for changes at the interval set here. |
| Read Binary Data | Select this option if you want to read a binary file. (e.g., *.doc, *.jpg, * .xlsx). |
| Read text | Read a plain text file and select the encoding. |
| Delete after successful transfer | Deletes the file from the container/bucket after a transfer has been successfully completed. |
| Destination container/bucket | Moves the file to any container/bucket after a transfer has been successfully completed. |
| Prepend UTC timestamp to the filename | If the file is to be moved, this option allows the current timestamp (UTC) to be added to the source filename. For example, the file “test.txt” becomes “20191204_095646_test.txt”. |
| Delete after Failed Transfer | Deletes the file from the container/bucket after a transfer has not been successfully completed. |
| Target Container/Bucket (Error) | Moves the file to any container/bucket after a transfer has not been successfully completed. |
| Prefix the filename with a UTC timestamp | If the file is to be moved, this option allows the current timestamp (UTC) to be added to the source filename. For example, the file "test.txt" becomes "20191204_095646_test.txt". |
| Time between retries | Time to wait between retries, in seconds. |
| Retries | If a file cannot be accessed, the system can retry. |
Interaction with Storage
The section on sequence diagrams explains how to interpret this diagram.
The Network File Access trigger and the Cloud File Access trigger operate according to the same pattern; they differ only in the connected storage (SMB or FTP share for one, S3 bucket or Azure Blob container for the other). Both access the storage in three separate phases: The trigger cyclically lists the files, the transfer reads the file contents, and the trigger then deletes the file based on the result. Note that the listing is the only trigger mechanism—despite the name “Fallback Scan Interval,” there is no event path through which the storage notifies the OPC Router on its own. Also note that the file contents are not read when the trigger is activated, but only during the transfer: A read error therefore appears as a transfer error and not as a trigger error.
The diagram shows both triggers in a skeleton: Round 1 is the cyclic enumeration by the observer thread, and this enumeration is the only triggering mechanism—there is no event path through which the storage notifies the OPC Router on its own. Round 2 is the reading of the file contents during the transfer, in the export phase; Round 3 is the result-dependent action on the storage device after the transfer ends. The three result branches show that “Leave as Is” is not a configurable option: “Move” and “Delete” are the same setting, and only in the case of “Aborted” or “No Result” does the file remain untouched and trigger again. The outer else branch shows the special case in which the queued job expires: The trigger then receives no result, the file remains in the processing queue, and is not triggered again.
Three rounds against memory: The trigger lists files cyclically, the transfer reads the file contents, and only after the transfer result is received does the trigger move or delete the file.