Can anyone tell me the difference between Adding or Attaching a monitored repository in Workflow Configurator? I recently setup a test box for a client and what I did was make copies of both Workflow and Repository db as well as Repository files as well. I then ran the RepoUUID Updater and then setup a test Repository as well as using a Test Workflow db (so we don't impact production). However, whenever I go to Workflow Configurator...only the Production Repo is listed...and if I click "Attach", the Copied (test Repository) is not listed...so I hit Add and add it no problem. The issue is any documents that were in a workflow, won't work...as if they're stuck in "limbo". If I create a new document, it works fine...I'm almost positive this has to do with Attaching vs. Adding the monitored repository, but how can I attach one if it's not listed?
Question
Question
Answer
The SQL database? You want to copy the SQL database the Production repository is using. Otherwise, you would have 2 repositories sharing the same database and overwriting each other's data.
Replies
Attach is used when a repository is monitored by multiple Workflow Servers.
Are we talking about documents from the original repository being stuck? Or are we talking about their copies in the new repository not proceeding through workflows that were started in the old repository?
I guess the latter? I didn't really see it as a "New Repository"...simply the same repository with a different name/db.
Those are not expected to continue since they are now in a different repository.
How is what I did any different than moving the db and repository to another server? It's not a "New Repository" as I didn't create a new repository, I simply Registered (not created) the copied repository files, and used the renamed SQL db's.
By changing the repository's ID, it essentially became a new one. Repositories are identified to WF by ID, name and server.
When you move a repository from one server to another, the ID does not change. You still have to put in redirects for Workflow to know how to handle connection profile updates.
When you make a copy and change the ID, it is a new repository which just happens to look a lot like the old one. There is no way to tell WF to transfer running workflows to this new repository.
Ok..makes sense....so then when I move the production Repository to the new server, and create the new Workflow Service on that server...should I be "Adding" or "Attaching" the Monitored Repository? The last time I did this I added, and it broke the workflows because the WFUser$ password was reset.
It's not clear to me what the end goal is here. This new WF Server is now running with its own database. Are you planning on keeping the old WF Server around to finish off its running instances?
The goal is that the customer is moving their Laserfiche system to a new server. However, the last time we did an upgrade (from v8 to v9) the workflows had all sorts of issues, and instead of being down for a few hours, it was a few days. So they wanted to setup a test environment to make sure everything works before we make the switch. We got temporary licenses from Laserfiche to setup a test environment, so I wanted to test the Workflows "as is" to make sure everything works. The repository files and the WF Server will be on the new server, but the db's are staying put on the SQL Server. Obviously, I had to make copies of the db's and repository files so not to interrupt production, but I couldn't confirm that documents that were "in a workflow" would pick up where we left off before the move (because I changed the Repo ID). Does this clear up what I'm trying to do?
Cloning a working production environment for testing purposes is slightly more complicated than what you are doing. Ideally, you would set it up on a separate domain given how Workflow references servers and repositories. I'm guessing that's probably not an option for you currently.
For upgrade testing purposes, I would do the following:
- copy the repository to the test server
- set up the same version of Workflow you have on the production server with a new database.
- export the Workflow rules from the production server and import them into the new server (and update the connection profiles in the process to point to the copied repository)
- trigger the rules that would have longer running instances to make sure everything is working
- upgrade Workflow on the test server
- double-check everything is working as expected
This would accomplish the same end goal of checking that running instances will complete as expected after an upgrade without trying to get instances from the old repository to work in a new repository.
Miruna,
Couple of clarifications:
I copied the Repository to the test server, should I create a new db for the Repository or use the existing (will that effect the Production)?
The SQL database? You want to copy the SQL database the Production repository is using. Otherwise, you would have 2 repositories sharing the same database and overwriting each other's data.
Great..that's what I thought...but wanted to make sure.