Delete Entry Activity Slowing Workflow Considerably

asked on June 24, 2020 • Show version history

I have a Workflow that moves a document from one folder to another and then attempts to delete & purge the original folder using the "Delete Entry" activity, but only if it's empty.

While other activities in the Workflow, such as the "Find Entry" activity are running in less than 2 seconds, the "Delete Entry" activity is taking anywhere from 30 seconds to 5 minutes to complete, as seen in the screenshot below.

It has slowed the process down so much that I've had to disable this portion. Below you can see how long it was taking with the "Delete Entry" activity enabled and then how much quicker it is once that is disabled.

When attempting to delete, it is not reporting errors that the entry is locked or anything like that. It just appears to be taking that long to delete the entry, possibly due to attempting to verify if it is empty. Has anyone else run into this issue?

1 0

replied on June 24, 2020

I am a little confused by your screenshots. Is the screenshot with all the times listed multiple workflow instances? Or is that all activities within one workflow? Can you post screenshots of the actual workflow so we can see what you are trying to do in the workflow? Show what happens after it tries to delete the folder?

0 0

View 2 previous replies

replied on June 24, 2020

Jennifer,

After digging into it a bit more, I ended up having to disable the "Delete Entry" activity to speed things up. I've updated the details in the post to better reflect the actual issue and clear up the confusion. Let me know if that makes more sense and thanks for the feedback.

0 0

replied on June 25, 2020

What are your repeat conditions? Does the repeat only run once or is the longer time because the repeat is running multiple times?

Are you attempting to check all the folders in a path? No sure what your update current folder to delete token activity is but since you have it outside the conditional sequence and outside the try catch it appears that it will run no matter what. Should it? Or should it have a different value if the folder was not deleted?

0 0

replied on June 25, 2020

If it deletes the folder, it is checking the parent folder and repeating up the path until it fails to delete something. These long times for it running are happening when it runs the first time prior to repeating up the parent folder path. However, taking it out of the repeater (to take that out of the equation) and running just the "Find Folder to Delete" and the "Delete Folder" activity are still resulting in long duration's.

0 0

replied on June 25, 2020 • Show version history

My guess is that it takes longer on the delete activity because it has to check and make sure there are no entries in it. Have you looked at the folder that take a long time to see how many files are in there. Is there a connection that the workflows that run the longest have the most files in the folder? When it checks to see if the folder is empty it might not stop as soon as it finds one file. It might check the entire database table to find ALL entries in that folder.

If you check for entries first and only try to delete it if it is empty you might see a speed up.

I have included a screenshot that takes most of what you are trying to do and blends it into the typical way I check for empty folders in my workflows. That might give you a couple ideas.

CheckFolderPath.jpg (45.74 KB)

| Download

0 0

replied on June 25, 2020

I have previously used the method you show but after the option was added to the "Delete Entry" activity to prevent it from deleting folders that are not empty, we've been using that. I may have to switch back though if the previous method runs more efficiently.

I only see this happening at one customer so my hope is that it is something specific to their environment. As their environment has gotten larger, we've seen the duration for this activity grow much faster than that of all other activities. The folders in question only have a few items at most in them so I hope it does not take that long to search through for that reason.

I am wondering though if in doing this search, the application actually runs a search on the toc table to see if there are any items that list this folder as it's parent. Thus as this toc table has grown a ton over the years, this slowdown is directly related to the millions of additional rows it has to search through.

I really appreciate the help in working through the possible issues on this! I'm going to try some variations to see if other activities, like you posted, work more efficiently in high-volume environments. If I track down anything on this, I will post the results for others that may encounter the issue.

0 0

Question

Question

Delete Entry Activity Slowing Workflow Considerably

Replies

Sign in to reply to this post.