Folder stuck at system stage with timed action

Hello, I have a folder sitting in a system stage and doesn't seem to want to move. I had originally created a timed action to fire seven days before a certain date. That date has well and truly passed and the folder is still sitting at the system stage. The system stage is the first stage of a sub-process (in case that makes any difference).

I've tried creating a user action to force it to move, but that just gives me an error saying "an error occurred during this process"

I've tried creating a flag from the system stage to take the folder to the next stage. I created an admin page with simple button press to raise the flag, and tried raising the flag from command prompt. Both did nothing.

Previously a different folder had the same problem. I tried moving it manually by updating in the database. This worked, but a few minutes later the folder disappeared completely, never to be seen again, for some reason.

I'm pretty much out of ideas now. I've done about a day and a half's worth of Googling with no result.

Any help with this would be greatly appreciated.

Find more posts tagged with

BPM

Comments

Jacob_Eastman

System actions all run off the eWait table. When a folder gets to a stage that has system actions (like timed actions) a row in the eWait table is created to handle this. Sometimes, a folder will fail to advance due to some error (database issues or the code related to the action failed). The error causing the folder to not move should be logged in the eLog table. Check the eLog table first for any related errors.

Instead of advancing the folder, I'd recommend using a user action loopback to the same stage. This will recreate the eWait entries (as if the folder had just entered the stage again) and the system actions will be processed again.

However, it sounds like there may be more going on with your process. If the above does not fix the issue I'd recommend opening a support ticket (email support@opentext.com) so we can look into your issue in more depth.

Manderson_Kenyon

Creating a loop-back worked for me. Thanks very much.

I'm going to keep an eye on if/how often it happens.

Jerome_Pearce

For future reference, bear in mind that loopback timed actions will not fire after another loopback action if they are set in the past. If these have failed, you cannot get them to trigger like this.

eWait entries for flags are not entered for existing folders. This is actually a real pain, and actually very easy to fix, but even after asking for years, it has not been. We have a form that generates and runs the required SQL to add these entries in our PM Tools solution (link below).

Generally, we expect timers will fail one in a few hundred, or even thousand, times. To manage this, we add a second timed action as a 'belt and braces' fix. If the process is critical, we have even added a third. Only if the engine event manager dies (a problem in a very few past versions) will the process then fail.

Manderson_Kenyon

Thanks for your responses guys,

I've made a user loop-back action and it successfully pushes the folder through to the next stage.

I still have the problem, however, of folders getting stuck. It seems to be happening to most, if not all folders coming through this stage.

Does anyone know why this might be happening, and is there anything I can do to correct it? I've included a new screenshot of the process, along with the logic that triggers the timed event.

Jerome, I read in some of your other posts about issues with loop-back timers. Could this be related? I.e. something to do with DB vs engine clocks?

Thanks again for your help,

Kenyon.

Zhao_Xiao-ou

Hi,

Can you try to set the timed action as priority 1 and the conditional action as priority 2. Only to calculate time on the timed action and leave the conditional action blank (no condition), This way, the folder has at least a free exit point.

Brian Mellert

I haven't tested to see if it may be the case, so this is only off-the-cuff.

I see your timed event timer is 7 days after current time. I wonder if when it comes time to check the value, "current time" is now again now, so 7 days from now is still in the future. (e.g. the original date was 4/1, making the timed date 4/8, but when 4/8 rolls around the time calculation is now 4/15). Just a guess.

What shows, if anything, for the time records in eWait for one of these folders?

If using CurrentTime this way causes the issue, perhaps assign a variable to use as the "times up" date? (Presuming you can't use Entered, Updated or Deadline dates instead.)

Manderson_Kenyon

I've implemented this change. I'll keep an eye on how it works out.