The information in this article applies to:
Product: Metastorm BPM
Version: 6.6.x 7.x
Issue
A user action is taken that reopens the folder. The stage after this action has a conditional action leaving it. For example, taking Action1, which leads to Stage1, reopens the folder. If a checkbox is checked on the form at Action1, the conditional action leaving Stage1 is started and the folder should move to Stage2. If the checkbox is unchecked, the folder remains at Stage1.
The issue is that when the checkbox is checked, sometimes the form and actions available at Stage1 are rendered in the browser and sometimes the form and actions available at Stage2 are rendered. If the form is refreshed, the correct form and actions are displayed.
In version 6.6.x, the user is presented with the following error message:
< \[sp\_update\_action\] > : Failed to obtain data.
Failed to invoke action.
In version 7.x, the user is presented with the following error message:
< \[esp\_update\_action\] > : Failed to obtain data.
Failed to invoke action.
The following warning may be written to the Windows application event log:
Failed to obtain data.
Resolution
The problem with the design is that a user action that reopens its folder then goes to a stage that has a conditional action leaving it.
This is a problem because reopening the folder is done in-line, synchronously, as part of the initial request to commit Action1. The conditional action, however, is executed by the Engine's event manager asynchronously, in a separate thread. Exactly when this occurs is impossible to say as this is determined by the event manager's load, speed of database access, speed of Engine server, and perhaps other variables as well.
Making a synchronous action depend on the performance of an asynchronous action is likely to result in unexpected behavior.
