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

Discussion

Discussion

After Migration Laserfiche Services to new Server a workflow began terminating

Workflow
Updated October 9, 2023
posted on October 5, 2023

We updated our workflow connection profile information after migrating the Laserfiche Server with the new server details.

However, a workflow began terminating on a step "Find Group" which was trying to access the old server even though the connection profile was configured for the new server.

Shouldn't all activities be using the connection profile to contact the Laserfiche Repository? We can't have individual activities making direct connections or they will fail unknowingly after a migration. We don't look at every activity in every workflow after moving servers, we just update the master config.

The activity just says Search In and defines the server name within it's own configuration rather than showing anything about the global connection profile.

 

0 0
replied on October 6, 2023 • Show version history

Edit: First, when migrating a repository, unless you are using DNS aliasing so the Laserfiche Server address doesn't change, you should always configure a Laserfiche Server and/or Repository Redirect because updating Workflow connection profiles does not affect running instances. Please note that Redirects are intended as temporary solutions to address currently running workflows and prevent published workflows from immediately breaking before you can update connection profiles and republish workflows.

-----------

Shouldn't all activities be using the connection profile to contact the Laserfiche Repository?

No, because not all activities strictly interact with the repository. There are a set of Workflow activities that deal with Trustees, which can be from either repository or AD/LDAP sources.

Trustees are users, groups, or managers that workflows interact with and are provided by Trustee Directories. Trustees are organized in Laserfiche or AD/LDAP trustee directories.

The Find User, Find Group, Find Manager, Route to User, and Route to Group activities deal with Trustees and are configured with Trustee Directory sources. It's similar to how the Insert/Query/Update Data, HTTP Forms Post/Web Request, and Email activities are configured with Data Source, Web Service, and Email Server source objects respectively.

When you Add/Attach a Monitored Repository in Workflow, the repository is automatically added as a Trustee Directory.

 

Assuming you updated the Monitored Repository registration with the new server, you should have a new/updated Trustee Directory for that repository as well.

My workflows often have the trustee-related activities configured to use an AD (LDAP) Trustee Directory rather than the repository one. Workflows can also have multiple different repository connection profiles. Workflow doesn't make any assumptions about how a repository connection profile you use might be related to a Trustee Directory you want to use.

I recommend mentally classifying these "trustee activities" like the Data/Web Request/Email ones. Their data source can be a repository, so if it is and you migrate/rename/etc. that repository, you need to go update the Trustee Directory references in those activities.

This is also a great example of why using DNS aliases is so helpful. Imagine you had a DNS alias of "lf-prod-lfs.example.com" pointing at the old repository server and used "lf-prod-lfs.example.com" in your Workflow Monitored Repository entries (and thus Trustee Directory entries), and repository connection profiles. After you migrate your repository to the new Laserfiche Server machine, you simply update the "lf-prod-lfs.example.com" DNS entry to point to it and you don't have to update a single thing in Workflow*.

*Except potentially Business Processes because of how publishing those to a Laserfiche Server instance works.

0 0
replied on October 9, 2023

The Laserfiche suite is broken up into about 12 independent services which are all connected to each other by whatever the last installer entered in the config. I assume this is for the freedom to move services wherever and however you want which is a great feature that is some customers make use of with multiple servers.

So the DNS option works if 12 different DNS configs were created and they were used during last install which is very rare. But I have made use of DNS in many situations.

I feel like what was configured on last install and DNS is something out of our control though, even if it is something we can recommend and use during new installs.

It is import that each service's configurator shows and allows updating the connection information to each other service. It seems all of the configs allow easily updating all other service connection(s) except WF and Forms.

WF and Forms may be the only services that can connect to one or more repositories/servers but that shouldn't change anything in being able to view and update those connections in the config. There is a connection to one or more server/repositories which could be referenced by multiple workflows or activities. If these were listed in the config they could be fixed in one shot like with moving any other service.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...