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

Question

Question

Feature Request: Recovery from Database Connectivity

asked on April 17, 2016

Hi Laserfiche,

 

I had a system that experienced a database connectivity issue for a couple of minutes. Some workflows were at Search activity when the issue occurred, posted a warning and seemed to retry and recover. Great to see.

Other workflows were running the Fill PDF Form activity and terminated. It seems that the Fill PDF Form activity doesn't have the same level of resilience. I'd like to request it be enhanced.

-Ben

0 0

Replies

replied on April 18, 2016 Show version history

This one will rear up anytime you are accessing something that is (sort of in this case) external to the system. It probably failed because one of the fields you were trying to fill in on the PDF did not allow a blank field, like a date or drop down list. 

 

I'd suggest putting the activity in a try/catch. If it terminates, you can put a wait 10 minutes function in it then kick off the workflow again (and terminate this instance). I have to do this quite a bit with email functions where their email server is a little too busy at times.  

0 0
replied on April 18, 2016 Show version history

Chris, as I said, some other activities retry and recover from a momentary database outage, such as set template field.

Miruna,

I'll reply tonight.

 

 

 

 

 

 

 

0 0
replied on April 19, 2016 Show version history

Hi again Chris,

I was a bit short in my response  to you, hope I didn't sound dismissive (was replying through my phone)

 

Given other activities seem to be able to retry and recover (such as Assign Field Values), this post is to request that same resilience in other activities.

 

0 0
replied on April 18, 2016

What was the error in Fill PDF?

0 0
replied on April 19, 2016

Hi Miruna,

 

General Database Error. [9008]

 

-Ben

0 0
replied on April 19, 2016

In the PDF activity? 9008 should be in your list of recoverable errors in Task Error Handlers...

I'll give it a try.

1 0
replied on April 19, 2016 Show version history

I checked my config, it's in there with a retry of five minutes.

As an aside, how many times is the workflow suppose to retry before giving up? In the samples I've looked at, the workflow only needed to retry twice before successfully continuing.

0 0
replied on April 19, 2016

I've been searching for this but I can't find a thread the references this. I seem to recall having a similar issue back in 8.3 or 9 when try catch was relatively new.

The way I understood it the dbms 9008 error will retry an activity after the activity completes and it sees that it fails. But if the activity is performing an action that is outside of the system it cannot recover and this is one of the reasons try catch is useful. I don't know exactly how the pdf form fill works but I know it works directly on the document that is in the repository, not just within the laserfiche database like an assign field values would. In addition if a field was blank and it tries to fill in a blank in a date or a drop down, you'll error out as well but I don't believe it's a 9008 error. But if both are happening, I don't know which one it would report back?

 

So that's why I suggested putting it all in the try-catch. Hopefully Miruna will be able to determine what happens in that situation.

 

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

Sign in to reply to this post.