Page History
...
LANSA Composer provides the WAIT_FILESREADY activity to assist with many such situations. If you are using the WATCH_DIRECTORY activity, you may need to use it in conjunction with the WAIT_FILESREADY activity for a robust solution.
You can refer to the EXAMPLE_WATCH01 Processing Sequence for an example of using the WATCH_DIRECTORY activity in conjunction with the WAIT_FILESREADY activity.
...
| Note | ||||
|---|---|---|---|---|
| ||||
This activity requires that the LANSA Integrator JSM is executing on a JVM at Java 7 or above. |
| Note | ||||
|---|---|---|---|---|
|
...
Unlike many other iterator activities, this activity will iterate indefinitely unless you take specific action in the iterator block to exit the iteration. It is designed to be used in a potentially long running processing sequence that perpetually waits on a message arriving at the specified message queue and then processes the message or initiates another processing sequence to process the message. For more information refer to Considerations for Extended Duration Processing Sequences. |
Restarting the WATCH_DIRECTORY activity
The WATCH_DIRECTORY activity supports processing sequence restart if an error occurs while it is active. However, it is possible that some previously queued file system events may have been lost when the activity restarts. Your solution may need to take account of this.
If your solution uses the "drop-box" approach where the directory should always be empty of anything but unprocessed files, then you will probably specify *YES for the EXISTINGCONTENTS parameter. In this case the existing contents of the specified directory will be enumerated and iterated when the processing sequence restarts, and you will usually need to take no further action with respect to the processing sequence restart support.
INPUT Parameters:
DIRECTORY: Required
This parameter must specify the full path to the directory to be watched.
RECURSIVE: Optional
This parameter specifies whether descendant directories of the specified directory are also watched. The default value is *NO which means that descendant directories are not watched. Specify *YES if you want the activity to watch the descendant directories. If you specify *YES and you are watching for *CREATE events (see the WATCHEVENTS parameter), then any new sub-directories that are created while this iterator activity is active will also be watched.
EXISTINGCONTENTS: Optional
This parameter specifies whether the activity enumerates and iterates for the existing contents of the specified directory when the activity starts up or when it is restarted.
...
Alternatively, specify *NO if you do not want the activity to process the existing directory contents. In this case, your solution will receive notifications only for files that are added, changed or deleted after the iterator activity begins processing.
WAIT: Optional
Specifies the length of time (in seconds) that the activity will wait, on each iteration, for a watched event to occur in the specified directory.
...
If you specify the special value of 0 (zero), it means that the activity does not wait for a watched event to occur in the specified directory.. Instead the next iteration is performed immediately. Use of this value is not generally recommended with the WATCH_DIRECTORY activity as it may result in your long-running processing sequence being heavily CPU intensive, instead of simply entering an idle/wait state when it has no work to perform.
WATCHEVENTS: Optional
This parameter specifies the types of file system events that the activity watches for in the specified directory. The default value is *CREATE which means that the activity watches only for new files or sub-directories.
...
Note that if you specify *YES for the EXISTINGCONTENTS parameter, then your solution may also receive *EXISTS events, irrespective of your choices for the WATCHEVENTS parameter.
OUTPUT Parameters:
EVENTOUT:
Upon each iteration, the value of this output parameter will indicate whether a watched file system event occurred, and, if so, the type of event. It may have one of the following values:
...
*OVERFLOW: indicates that the file system may have reported events faster than they can be retrieved or processed by this activity. In this case, some events may have been lost. If you process this event, you might use it to re-examine the contents of the directory being watched. The remaining output parameters values are not filled when this event occurs. Your solution may receive this event irrespective of the value(s) specified for the WATCHEVENTS parameter.
FILEPATHOUT:
Upon each iteration, for events *EXISTS, *CREATE, *MODIFY and *DELETE, this parameter will contain the full path of the file or sub-directory affected.
ISDIROUT:
Upon each iteration, for events *EXISTS, *CREATE and *MODIFY, this parameter will contain 'Y' if the event refers to a sub-directory. Otherwise the event refers to a file.
SIZEOUT:
Upon each iteration, for events *EXISTS, *CREATE and *MODIFY, this parameter will contain the size in bytes of the affected file or sub-directory.
LASTMODOUT:
Upon each iteration, for events *EXISTS, *CREATE and *MODIFY, this parameter will contain the last modified date and time for the affected file or sub-directory.