Long-running Form process and workflow interactions

asked on June 23, 2019

I've been considering writing a Forms process that would call a workflow. The purpose of the workflow would be to delay the next Forms process step until certain conditions occur in a relational database. When the these conditions occur, the workflow would complete, and allow the next step to occur in the Forms process, queuing up tasks that can then be completed.

The potential problem is that this workflow could take several months to complete, during which time the Forms process and the workflow would both be running.

One person I respect advised me against this strategy, saying that a system reboot could kill the Forms process and/or the workflow. Once this happens, he said, these could not be restarted.

Should I worry about that, or can Laserfiche Forms and Workflow services keep running, picking up where they left off after a system reboot or crash?

I'd appreciate a second opinion on this, since these long-running processes would greatly simplify this particular problem compared to other approaches I can think of.

Thanks!

1 0

SELECTED ANSWER

replied on June 23, 2019 • Show version history

The short answer is that they won't always be stopped by reboots and such, but it can, and will, happen. Especially with such a long-running process.

We have some processes that can run for a long time like that, and every so often issues will arise. Reboots have a low chance of causing issues, but server issues have a high chance of breaking any active workflows/processes.

My recommendation would be to:

Have the initial form log the submission to a database
Have a scheduled workflow that runs daily, hourly, whatever you want
Have the workflow check for the necessary changes, then invoke a second Forms process

This approach does split submission from the rest of the process, but it is also far less susceptible to these types of issues because you don't have an "active" process that can break if something goes wrong.

Reports can join data from the two processes together, and you could include the instance and submission Id from the initial form so you can use Retrieve Business Process Variables later to pull the original data and plug it into the second part of the process.

2 0

replied on June 26, 2019

This is a bit more scary than necessary. While correct, it should be noted that "active workflows/processes" only applies to instances that are doing work at a given moment. Any instance waiting for user action, timers or any other type of condition to be satisfied are saved in the database and not considered actively running. They are unaffected by a server restart or even by a service crash.

The process described in the original post will spend most of its life in a waiting state.

2 0

replied on June 26, 2019 • Show version history

I agree, and I didn't mean to imply it would be common, just that it has happened to us more than once so it is a real possibility.

Definitely important to note that only "active" process would be affected, but Murphy's Law has burned us many times in that regard lol.

The process he described will be waiting on changes in an external data source, so depending on how many instances he has, a consolidated process could be more efficient anyway.

I suppose it really comes down to risk analysis. A broken process would be rare, but the other half of that is how bad it would be if it did happen.

1 0

Question

Question

Long-running Form process and workflow interactions

Answer

Replies

Sign in to reply to this post.