Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This activity is intended for use in processing sequences that identify and process newly-discovered files.  For example, a processing sequence that uses the WATCH_DIRECTORY activity may need to also use this activity.

...

This activity will usually appear in some sort of loop in a processing sequence – for example inside the block associated with an instance of the WATCH_DIRECTORY activity:

  • When executed inside the loop, the processing sequence usually wants to add a newly-discovered file to the cache provided by the WAIT_FILESREADY activity. 
  • It will usually request that the activity also return a file that is considered "ready" for further processing, if there is one.
  • Both these operations can be done in one call to WAIT_FILESREADY when you use the default *PUTGET value for the OPERATION parameter.

...

Once you have understood these two things, then you are a well on the path to being able to implement the WAIT_FILESREADY activity successfully in your solution.

You can refer to the EXAMPLE_WATCH01 Processing Sequence for an example of using the WAIT_FILESREADY activity.

...


Note
iconfalse
titleNote

This activity requires that the LANSA Integrator JSM is executing on a JVM at Java 7 or above.

Note
iconfalse
titleNote

...

The file status and metrics checked by the WAIT_FILESREADY activity to determine "ready" state will be sufficient for many solutions.  However some applications may call for checks that are not performed by WAIT_FILESREADY.  You should make sure you understand the characteristics of the environment in which you propose to use WAIT_FILESREADY to make sure that the activity is suitable for your purpose.

Restarting the WAIT_FILESREADY activity

The WAIT_FILESREADY activity supports processing sequence restart if an error occurs while it is active.  However, the contents of the files cache are not automatically restored.  Consequently, it is possible that some previously cached files may have been lost when the activity restarts.  Your solution may need to take account of this.  Often, when used with the WATCH_DIRECTORY iterator activity with *YES specified for the EXISTINGCONTENTS parameter, for example, the loss of the cache will not be significant, and no special action will be required.

INPUT Parameters:

OPERATION: Optional

This parameter specifies the action(s) that the activity is to perform.  The default value used is *PUTGET.

...

  *LOG: writes a processing sequence log entry for each file remaining in the cache.  The log entry identifies the file and a value that indicates the last reason that the file was evaluated to be not "ready".  This operation is intended for use during the design phase of your solution – it should not normally remain in a completed solution.

FILEPATHPUT: Optional

If *PUT or *PUTGET is specified for the OPERATION parameter, this parameter must specify the full path to the file that is to be added to the files cache.

INTERVALS: Optional

If *PUT or *PUTGET is specified for the OPERATION parameter, this parameter specifies the intervals (in seconds) at which the file's "ready" status will be evaluated.  In other words, the file's status will not be evaluated until at least this number of seconds has elapsed since the file was added or since the last status check was performed.

If you do not specify a value, the default value used is 40 (seconds).

READYREPEATS: Optional

If *PUT or *PUTGET is specified for the OPERATION parameter, this parameter specifies the number of consecutive times the file must be assessed as "ready" before it is finally released from the cache in response to a *GET or *PUTGET operation.

If you do not specify a value, the default value used is 3 (three).  Note that, when used with the default value of 40 for the INTERVALS parameter, this will result in at least two minutes elapsed before the activity will consider the file as having reached "ready" status, even if no changes to the file occurred after it was added to the files cache.

EVALUATE: Optional

If *PUT or *PUTGET is specified for the OPERATION parameter, this parameter specifies the criteria or file attributes that are considered when subsequently evaluating the file's "ready" status. One or more of the following values (each value should be separated by at least one space) could be entered:

...

NB: You must specify quote marks around the list of value(s) to distinguish them from built-in variable names.

LOGBOOKMARK: Optional

This parameter applies only when *PUT or *PUTGET is specified for the OPERATION parameter and a file is successfully retrieved from the files cache.  It specifies that the resulting log entry should be bookmarked, so that it can more easily be located when displaying the Processing Sequence Log.  The default value, *YES, specifies this behavior.  The value of *NO prevents the log entry being bookmarked.

OUTPUT Parameters:

RESULTPUT:

If *PUT or *PUTGET is specified for the OPERATION parameter, this output parameter will contain the result of the *PUT operation.  It will contain one of the following values:

...

Note that the error condition does not result in the activity ending with an error status – in other words, a CATCH processing sequence directive will not be fired for this condition.  You need to test the value of the RESULTPUT operation if you wish to specifically handle the 'ER' case.

RESULTGET:

If *GET, *PUTGET or *GETNOTREADY is specified for the OPERATION parameter, this output parameter will contain the result of the *GET or *GETNOTREADY operation.  It will contain one of the following values:

...

Your processing sequence should, at the minimum, test for the 'OK' result code and treat it as the trigger for further processing of the file that was retrieved.

FILEPATHGET:

If *GET, *PUTGET or *GETNOTREADY is specified for the OPERATION parameter and if the RESULTGET output parameter contains 'OK', then this output parameter will contain the file path of the file that was retrieved from the cache.

REASONNOTREADY:

If *GETNOTREADY is specified for the OPERATION parameter and if the RESULTGET output parameter contains 'OK', then this output parameter will contain a value that indicates the reason that the file was last evaluated to be not "ready".  The reason codes can include *NOTEVALUATED. *ZEROLEN, *SIZE, *LASTCHANGED, *READABLE, *LOCKABLE and *READYREPEATS.

COUNTWAITING:

Irrespective of the requested operation or its result, this output parameter will contain a count of the number of files remaining in the files cache.