Dealing with activity failures

[franck102]

Hi, we are trying to create management UI around process failures and we are running into two specific issues. This is in the context of numerous historical and long-running processes, so all queries must be paginated.

The fisrt issue is that the act_ru_job is the only table that has a trace of the failures (exception_msg_), but it doesn't have anything too useful to sort on (as far as the user is concerned). So if the process has been running for year it is going to be really hard for the user to locate today's failure. Wouldn't it make sense to add a failure timestamp (or end_time_ or something) to that table?

The second issue is that while the DefaultHistoryManager recordActivityStart call inserts a row in act_hi_actinst as soon as the activity starts (at the FULL audit level which we are using), the failures causes a transaction rollback and there is eventually no entry actually written to the DB.
The consequence is that for a failed activity the only information we have in the DB is a BPMN act_id, which isn't very useful to the user.
I am considering having recordActivityStart run in its own transaction, any guidance on how to properly implement this?

Thanks!
Franck

[jbarrez]

> Wouldn't it make sense to add a failure timestamp (or end_time_ or something) to that table?

It would, yes.

> The consequence is that for a failed activity the only information we have in the DB is a BPMN act_id, which isn't very useful to the user.

You could use this information to fetch the BpmnModel and get more information about the activity that failed.

> I am considering having recordActivityStart run in its own transaction

Not following what you mean with this

[franck102]

You could use this information to fetch the BpmnModel and get more information about the activity that failed.

Sure, but this is in the context of getting the "first" 20 failures or hundreds - and the fields available for pagination/sorting today are not very useful.
Take a system that has been running for a couple months and has hundreds of failures, there is no easy way today to get the 20 most recent ones to show the user, not without full table scans.

> I am considering having recordActivityStart run in its own transaction

Not following what you mean with this

Take a bogus Groovy script for example (var x = bogus_variable: when the activity starts, DefaultHistoryManager.recordActivityStart is called and queues an insert for act_hi_actinst; when the sctip fails however that insert is discarded as the transaction is rolled back.
As a result you can't match the job that failed with an activity in act_hi_actinst.

What I did for now is that I used a rollback listener to call recordActivityStart, this time after the transaction has been rolled back. I can now go from job-with-exception to execution to activity instance nad find out which activity triggered the failure.

[jbarrez]

> As a result you can't match the job that failed with an activity in act_hi_actinst.

True, but then again the entries in that table are meant for successfully completed activities, hence why the implementation  is what it is.

But you are correct about showing the most recent ones (for async continuations at least, timer jobs can be sorted)

[rahuls16]

…