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

Discussion

Discussion

Subscriber Trace clarification question

Workflow Version 11 Self-Hosted Administration
Updated October 2, 2024
posted on October 1, 2024

Something I have never really understood about Subscriber Trace in the LF WF admin console. Why are there event IDs for entries in one of my repositories, that are evaluating rules for workflow that are used in other repositories? 
Here is what I see. 

The entry changed event type is for a document in my Windows repo. All the starting rules that are evaluated are for workflows that run in a completely different repository. Actually a couple of different repositories. There are also results of workflow rules in my Windows repo, I just don't understand why WF would even bother with rules in different repos. Is there something to set up to prevent this? 

0 0
replied on October 1, 2024

Workflow is not necessarily bound to any particular repository; it is checking multiple repositories because your workflow server was attached to both of those repositories at some point.

It is not uncommon to have one workflow server covering multiple repositories; we have some that monitor multiple repositories and others monitoring only one.

It is generally recommended to specify a repository in your workflow rule conditions so it never starts workflows meant for another repository, but you can also control which repositories are monitored using the Repositories node in the workflow administration console.

 

Repositories Node (laserfiche.com)

2 0
View 1 previous reply
replied on October 2, 2024

I get that Workflow is not bound to a single repository. I guess what I thought is that since there are 2 place to set up the connection to the repo in Workflow Designer, it would filter with those connections. There is the starting rule connection profile or "Get Metadata from".

Then, there is the connection profile in the workflow itself. 

With both those configurations, I would think that the subscriber would use those to decide which starting rules to evaluate based on where the document is located. I have 5 repositories with 1 workflow server. It works, I just thought it would be nice to open subscriber trace and only see the rule evaluation for workflow specific to that repo. 

0 0
replied on October 2, 2024 • Show version history

A workflow can have multiple connection profiles, and it is entirely feasible to have a scenario in which a workflow rule is triggered by one repository, but the workflow itself also acts on entries in a different repository.

I have a few workflows like that, and in those scenarios, I don't want the rule to run for every connection profile; if it defaulted to that behavior there wouldn't be any control so although it might make sense in most cases, that sort of behavior would be very limiting for more complex processes.

As for the "get metadata from" option, that is not specifying a connection for the rule in general, it is there to pull the list of templates, fields, etc. needed to configure the rules.

Creating a Conditional Starting Rule (laserfiche.com)

The short version is workflows are not specific to a repository; they may only have one connection profile, but they never belong to a repository. This is where the rule conditions and monitored repositories come into play.

We run separate workflow servers for things we want completely isolated.

0 0
replied on October 2, 2024

Jason is right, though I am going to be a bit more pedantic and hopefully clarify what Lucas is seeing.

Workflow definitions that interact with a repository are tied to a repository by their connection profile. When one or more connection profiles are attached to a workflow, the first one in the list is automatically inherited by all activities and the user can change it on a case by case basis at the activity level.

Starting rules have no affiliation with a repository. The Subscriber will check all active rules for the specified condition type whenever an event of that type comes in from any of its monitored repositories. The connection profile in the starting rule editor is provided for ease of configuration at design time only, it does not attach that repository to the rule in any way.

In the single repository case, this is a distinction without a difference because everything starts from the expected repository and acts on the expected repository because there's no other possibility. In the multiple repository case, it's on the user to add "repository equals MyRepo" to starting rules to indicate which repository's events should trigger a given rule.

2 0
replied on October 2, 2024

Thanks Miruna, 

Are you saying that if all my workflows had the rule where "Repository equals *" those workflows would not show as being evaluated in the subscriber trace? 
The reason this came up was because one of my users said a document was moving like it should, I opened subscriber trace to look up the entry and see if it was because a rule wasn't met. Then my fellow LF person started asking about the trace and why there are so many rule evaluations that seem unnecessary. We also noticed that there seems to be some sort of limit on how many events are shown per repository. In the less used repos, the events are from weeks ago, in the heavily used repos, the events only go back an hour or 2. Is there a limit on what is shown? 

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

Sign in to reply to this post.

Details
Related Posts
Loading ...