Question

Workflows triggers themselves

Workflow Laserfiche

Updated October 30, 2014

asked on October 29, 2014 • Show version history

- We have a primary site and a DR Site
- We are using DSFR replication to replicate the repository (along with all folders e.g Volumes, search indexes etc)
- Replication is two sided where the updated files gets replicated to the other site (like primary gets replicated to the DR site and when primary site is down then DR gets replicated to the primary site)
- LF Repo database is mirrored
- We perform a Fail-over/DR process where:
   - Turn off the LF Server and LF Full Text Indexing services
   - Take the main DB down and bring mirrored DB up
   - Turn ON the LF Server and LF Full Text indexing services at the DR site.
   - We have a script written which uses the backed-up .wfi files and publish the workflows at DR workflow server.

Now this is where the problem starts, Workflow starts triggering in the repository and starting picking up the documents for the starting rules which were successfully triggered in the LF repo at primary site even weeks before.

What makes the workflow does that?

So we are using updated copy of repo db (mirrored db copy) + we are using the updated repo folders (using dsfr replication) + we are just publishing the .wfi files to the DR workflow server. What makes the workflows trigger by their own.

It is the workflow subscriber which triggers the WF events and as the WF subscriber at the DR WF server never received any events in the repo, then why is it triggering the workflows? Is it some flag gets transferred as part of replicated Repo OR mirrored Repo DB?

1 0

Answer

SELECTED ANSWER

replied on October 29, 2014

The Subscriber keeps track of the last event it read from the activity log. The value is stored in the registry, so when you first configured Workflow on the failover machine. So when you bring it back up, it reads the value and starts processing the activity log from that event on.

The last event is stored in the ASN value under HKLM\Software\Laserfiche\Workflow\Monitored Repositories\<Repository ID>. When you bring the machine up, you need to set that to -1, so the Subscriber will only process new events.

2 0

Replies

replied on October 29, 2014

Not 100% sure exactly all the odds and ends, but I believe workflow stores ongoing workflow statuses and you may be backing them up and restoring them to the secondary repository whereas they think those are already ongoing so it tries to start/continue where it can.

I am sure a Laserfiche Employee will chime in with more information though. I look forward to seeing what they believe is happening

1 0

replied on October 29, 2014

Hi,

I am not sure if it is the case, but we had a similar problem!, in our case we had to put a codition in the starting rule like "User does not equal WorkflowUser", and than our workflow stopped to star for themselfs.

1 0

replied on October 29, 2014

@Kenneth,

That's what I think and I hope someone from LF would be able to answer this :)

@Vitor,

This is not the reason. We already have the workflow user rule applied to avoid re-triggering of workflow for 'Change Entry' event.

Thanks anyways guys.

1 0

replied on October 29, 2014 • Show version history

Thanks for the useful details Miruna. This does seems like the issue and I will give it a quick test.

So, I have navigated to: HKLM\Software\Laserfiche\Workflow\Monitored Repositories\ and I can see two entries (Two folders) for the same repository. For both folders, (Default) and Server Data are same but ASN is different? Is this normal or I need to get rid of one?

Also, where would I be setting the value to -1 for subscriber not to process previous events? Do I need to create a new key/word in registry for this?

Thanks for your help.

1 0

replied on October 29, 2014

The repositories are identified by the repository ID from the Laserfiche Server. So those are not the same repository if you see separate IDs. Did you make copies of a repository?

0 0

replied on October 30, 2014 • Show version history

I am checking with my customer if they might have created a copy of the repository (as I can only see a single copy at the moment).

I have also asked them to provide the uuid value from the [dboptions] table and this will verify which key is the right key.

Re-read your reply and I can see that you meant to set ASN value to -1 (currently it says 4804784). Got it

Thanks

1 0

You are not allowed to follow up in this post.

Question

Question

Workflows triggers themselves

Answer

Replies

Sign in to reply to this post.