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

Question

Question

start rule

asked on January 31

I have a workflow (‘ABPP Employee Payroll - Process Documents and Status Changes’) that processes payroll documents that have been scanned as a batch and added to the repository via Import Agent. Each batch has an Identity page that that designates the employee whose folder to which the documents should be added. The workflow uses OCR to identify the document type and places the document in the correct sub-folder within the employee folder. This workflow was originally created for and ran to convert our paper employee files into the Laserfiche repository. It seldom has documents to process because I set up a different workflow that facilitates our users importing documents directly into the employee folder. I left this one scheduled in case the user has a larger quantity of documents to import for an individual and wants to use the batch input process rather than importing each document separately.

 

I am having an issue with the workflow start rule. I scheduled the workflow to run at 1:00 AM daily. The workflow starts at 1:00 AM every morning, just like the rule says. The problem is the workflow is also starting at 8:00 PM.

 

I have deleted the rule and re-published the rule several times. That has no effect, The workflow still shows up as executing at 8:00 PPM and 1:00 AM.

 

Has anyone else experienced this issue. If so, how was it resolved. If not, does anyone hae a suggestion?

 

The attached file contains screenshots from Workflow Designer and Windows Scheduler.

0 0

Answer

SELECTED ANSWER
replied on February 1

Yep, cloning servers would do it. Scheduled tasks would point to the original machine unless the rule is re-published.

0 0

Replies

replied on January 31

Hi Robert,

Check in the server's Task Scheduler and see if there's a duplicate entry for running at 8:00 PM. I have seen that even though you delete and republish the schedule from the WF Designer side, there may be a leftover scheduled task still running.

0 0
replied on January 31

The last page of the document attached to the original inquiry is a screen shot from Task Scheduler that shows two workflow tasks, one running at 12:30 AM and one running at 1:00 AM.

0 0
replied on January 31

Was this Workflow server moved to a different machine? Is it possible that the old one is still using the same SQL database?

0 0
replied on February 1

Miruna,

We began self-hosting last year. Everything was downloaded to a briefcase from the shared server and loaded onto our P01 servers (LFS, LFWF, SQL, etc.). Because we had nothing running in production at the time, we were using our new environment for development. When creating a workflow, I sometimes will create multiple versions to determine the most efficient method of performing a task. If the workflow will run on a condition or schedule, I create the rule and test it also. As we approached going live, our network administrator cloned the P01 servers to create a new environment for development (D01).

 

I actually found another difference between the two runs yesterday. In the tokens from the 8:00 PM run, the instance url started with 'http://PNP-LFWF-P01/WF/#/Search/PNP-LFWF-D01' whereas the 1:00 AM run instance url started with 'http://PNP-LFWF-P01/WF/#/Search/PNP-LFWF-P01'. I was unable to remote into PNP-LFWF-D01 and had to wait until this morning to talk to our network administrator.

After explaining the problem to our network administrator, he logged into PNP-LFWF-D01 where he found several LFWF tasks in Task Scheduler. He also found that the server had the incorrect time. He set the server to the correct time time. He also deleted all LFWF tasks on the server. Hopefully that will resolve the problem. I'll let you know, tomorrow.

0 0
SELECTED ANSWER
replied on February 1

Yep, cloning servers would do it. Scheduled tasks would point to the original machine unless the rule is re-published.

0 0
replied on February 2

Problem solved. 

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

Sign in to reply to this post.