Intermittent Problem with Chained Actions and Actions After 'Re-open Folder'

 

The information in this article applies to:

Product: Metastorm BPM (e-Work)
Version: 6.x 7.0-7.5.1.14 7.6.x

Issue

  • Calls on the %ToDoList or %WatchList functions can yield out-of-date results. This may result in unexpected behavior in the procedure or an error message such as Failed to chain action. This applies especially to actions after 'Re-open folder' and to chained actions.

    The attached ReOpenFolder procedure can be used to demonstrate this. The creation action "First action" is marked to re-open the folder upon submission. At the first stage are seven actions, each of which is marked to be available to the 'To Do list' dynamic role. This dynamic role resolves to a call on %ToDoList for this folder. Repeated attempts to create folders of this type are likely to demonstrate this problem, in that the re-opened form will not show all (or sometimes any) of the expected actions as being available. However, subsequently closing then re-opening the folder's form will show these actions correctly.

    This example is comparatively benign, as re-opening the form makes the correct actions available. However, we could just as easily have had a conditional action leaving the first stage with a %ToDoList expression as part of its "Only start action if" expression. In this case, the folder may not take the direction along the map intended by the procedure designer.

Discussion

  • Both %ToDoList and %WatchList resolve to SQL Select queries against the e-Work eAlert table, specifying a folder id and username, as well as alert type (todo or watch).

    The eAlert table is kept up-to-date by an engine component called the alert generator. In the interests of performance, this is an asynchronous component which runs in its own thread. Whenever an e-Work action is committed, a request is passed to the alert generator to ensure that the folder's alerts are kept up-to-date. While in most instances the alert generator operates in a timely manner, it is possible to have a lag or latency between an action being performed on a folder and the folder's alerts being updated.

    It is this latency that can be the cause of this problem. If, immediately after committing an action on a folder, a query is run against that folder's eAlert state (e.g. during a call to %ToDoList), it may be that the information returned is out-of-date.

 

Workaround

  • The obvious way to work around the problem is to avoid lookups against the eAlert table. Given that the eAlert table frequently ends up being rather large, this is a good practice anyway.

    Usually other ways can be found to achieve the same effect as that of making a %ToDoList call. For instance, in the case of the ReOpenFolder procedure, we know that when a folder is initially created and reaches the first stage, it is available to its originator. So instead of making the seven actions available to everyone on the ToDo list, simply make their roles the same as those of the first stage - orginator. No need for database lookups and no problem with latency.

 

Exception

  • There is one instance where this workaround will not work: if there is a loopback action that has the 'Remove from ToDo list' option set. Here there may be a divergence between the folder's ToDo list and the users who hold visibility roles at the stage. In this case, an alternative workaround can be used. Instead of removing references to %ToDoList or %WatchList, an additional %ExecSQL statement is added to the 'When action completed' expression for the loopback action: %ExecSQL("Update eAlert set eAlertType = '~' where eFolderId = '%FolderID' and eUsername = '%User.name'") This has the effect of issuing a temporary synchronous update against the eAlert table that should be sufficient to get around the problem and %ToDoList and %WatchList will return the correct results. Subsequently the alert generator will issue its own identical but delayed update.

 

Resolution

  • This issue is resolved in hot fix 15 for version 7.5 SR1 (7.5.1.15). This hot fix provides for a delay time to be specified for refreshing alert lists. See the Release Notes for hot fix 15 or later for 7.5.1 for more information.

  • NOTE: This fix is not included in version 7.6, 7.6.1, or 7.6.1.x. This is a known issue.

Tagged: