You are viewing limited content. For full access, please sign in.

Question

Question

New Feature - Workflow Error, Warnings & Messages trapping for activities

asked on October 22, 2015

Hi,

I see in some of the workflow result status that there are sometimes ERRORS, WARNINGS or MESSAGES reported on some activities like the followings:


Assign Field Values

- Entry is locked,
- Field value is too long to fit in a field
- One or more required fields were omitted

 

In order to design better workflows, I would like the following to be looked at:

I have tried using the Try-Catch activity but it only triggers when there is an error, and I think it would be great to have an option to allow trapping of messages as well, and we could then adapt the workflow behavior according to the situation.

I think it's important that we trap situations where metadata can't be written to a field so I would like the ability to have a trigger mecanism for this.


Also, if an entry is locked, the WF will be but into a Waiting state for a few minutes and then a retry will be performed.  The default retry is OK for many Workflows but I would like to see an option within activities that would bypass the default lock waiting period.  This would be very usefull in workflows that are part in a realtime process and need it to retry every few seconds, and this would release the document to the user a lot faster.

If you do implement this, I think this modification should be available to each activity that can be affected by a lock.

 

If there is an error or a message that was not properly handled within a Script or SDK Script, the Try-Catch is currently unable to trap it.  It would be good to allow trapping these situations.  


I have also seen the SEARCH activity to return no result because of an invalid response from the server.  when this happen, there is a warning message logged in the workflow status but there is no way to trap this within the Workflow and then create an alternative route to perform specific tasks for this situation.

 

Can this be added to the New Feature Request list?

 

Thank you

Daniel

0 0

Replies

replied on October 22, 2015

Hi Daniel, 

Thank you for the suggestions. We'll look at them for a future version. 

 

Also for error handling and retries, you can do some configuration in the Task Error Handler in the admin console. You can reduce the retry time and change how an error will be handled if it is encountered. This is server wide instead of workflow or activity specific, but if you always know how you'll want an error handled (such as a faster retry time for locked documents), you can do it here.

 

ErrorHandler.png
ErrorHandler.png (133.47 KB)
0 0
replied on October 23, 2015

Thanks Kevin.

I knew about these Workflow global settings and I do adapt them when required but for realtime workflows, we need specific settings that can override global settings for some of these errors.

Regards,

Daniel

0 0
replied on July 12, 2017

Any updates on this request?

I have a number of examples where a real-time/workflow specific option within activities that would bypass the default lock waiting period is needed.

0 0
replied on April 1, 2022

Hi,

Has this above scenario between captured . If not then what are the alternatives to convert an warning on the file lock to an error so can be handled in the catch block of a workflow. Struggling with the same . Immediate help would be appreciated.

 

Thanks

0 0
replied on April 1, 2022

Removing the task error handler will convert the warning into an error. We currently have no plans to make that behavior more granular at the workflow or activity level.

Could you describe the use case where it would be preferable to treat a temporary file lock as an error?

1 0
replied on April 4, 2022

Hi,

Repository  has shared configurable folder which has also has workflow configuration data which has a field which requires to be updated every half an hour through business process .

Observed Behaviour :  It remains in locked state resulting in our business process failure 

Reasons: 

1) User is  in process of updating some fields and forgets to close the update screen(retry also fails ).

2) After multiple updates folder gets locked and not able to remove lock through admin console thus resorting to Laserfiche Service restart.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.