Topic Options
#43152 - 04/18/13 10:49 AM Folder capture
stuartg Offline
OL Expert

Registered: 03/06/03
Posts: 713
Loc: Swindon, England
The folder capture task in V7.5 always creates the folder if it does not exist. Is it possible to change this behaviour to match that of V5 where the task simply failed if the folder did not exist?
Alternatively can I somehow set the folder capture task to take one file then stop rather than trying to capture everything in the folder?
The newly created empty folders are causing me problems.
Thanks
Stuart

Top
#43155 - 04/18/13 11:35 AM Re: Folder capture [Re: stuartg]
Raphael Lalonde Lefebvre Offline
OL Expert

Registered: 10/14/05
Posts: 4953
Loc: Objectif Lune Montreal
Stuart,

This behavior cannot be changed, this is the way it works. I am not sure why you find it annoying, since it seems to me like hotfolders should always be present. Can you give us more details on why this is a problem for you?

I suppose that as a workaround, you could use a small script right after the Folder Capture, and check if the folder is empty, and if is, delete it. (you need a script to delete folders) However, this risks causing errors once the folder is deleted, as it will try to capture from an non-existing folder. This risks filling the log with error message, and I can't guarantee that this will not cause other, unexpected behaviors.

Regards,
Raphaël Lalonde Lefebvre

Top
#43171 - 04/19/13 05:43 AM Re: Folder capture [Re: stuartg]
stuartg Offline
OL Expert

Registered: 03/06/03
Posts: 713
Loc: Swindon, England
Raphaël
Thanks for your reply.
The name of my folder (to be captured) is taken from a datafile.
So my folder capture task takes a file from W:\SAPPrinting\Printers\@(1,1,1,9,KeepCase,NoTrim).

So far, so good. The captured file goes through various processes and usually gets printed.
My process then returns to the folder capture task to look for the next file to capture. But the current datafile has now changed and usually has a planetpress trigger in front. So now the data selection @(1,1,1,9,KeepCase,NoTrim) returns "%!PS-Adob" and this is used as the folder name.

On V5 this just generated an error and the process stopped at this iteration. On V7 a folder called %!PS-Adob is created. I'm not too bothered by this but these folders are visible to my users, and when they delete it as unwanted, it just reappears within seconds as the process runs again.

I think that this behaviour should be configurable. Its a generalisation to assume that all folder capture tasks are looking at a "hot folder". In my case, I just want to take a specified file from a specified folder.

Other options I have are
Put the folder name in a jobinfo instead of a file - the job infos will get overwritten by the other tasks
Put the folder name in a global variable - ok, but I have a lot of these processes and this would mean a lot of variables to create.

I will experiment with local variables.
Stuart

Top
#43179 - 04/19/13 10:46 AM Re: Folder capture [Re: stuartg]
Raphael Lalonde Lefebvre Offline
OL Expert

Registered: 10/14/05
Posts: 4953
Loc: Objectif Lune Montreal
Quote:

I think that this behaviour should be configurable. Its a generalisation to assume that all folder capture tasks are looking at a "hot folder". In my case, I just want to take a specified file from a specified folder.



I don't think adding an option would be worthwhile, because once again, generally speaking: why would you NOT want to create a folder that you are going to look into? (call it a generalisation, but in the many years that I've worked with PlanetPress, this is the first time this request comes up) The only thing this would do is fill up the log with error messages that it cannot find the folder you are attempting to look into, as well as bring the problematic of error handling. (should the Folder Capture fails, by default, it will ignore it and move to the next task using your current data file, so you'd have to make sure this doesn't happen. Not hard to fix, but still...)

In this case, the reason you don't want the folder to be created is because it's using the trigger's value as the folder name. However, the issue here is not that the software creates a folder that doesn't exist, but rather a logistic issue where Workflow is using the wrong data selection for it's folder capture. So instead of changing the software, the solution is to fix the logistic. Some suggestions:

- If the data has moved due to the trigger on the first line, you can change the data selection line to use another line.
- You could remove the trigger that's causing issues using Add/Remove Text actions. (and use the same action to add it back later on if you need to)
- If you have files that have triggers and some that don't, you can add conditions to check for the trigger, and handle the files accordingly.

Also, for your idea of using job infos, if that isn't suitable because they risk being overwritten, you can use local variables instead. Each processes can have their own local variables, and you can add as many as you want, so you'll never have to fear of them being overwritten.

Regards,
Raphaël Lalonde Lefebvre

Top
#43201 - 04/22/13 10:08 AM Re: Folder capture [Re: stuartg]
Philippe F. Offline
OL Expert

Registered: 09/06/00
Posts: 1933
Loc: Objectif Lune, Montreal, Qc
Stuart,

Since your file name is dynamic, it's safe to assume the Folder Capture task isn't the first task in the process. That means you could insert a one-line script immediately before it in the process so you can check whether the folder exists or not (remember that the script can be used as a condition task). So in essence, your script would look like this:


Script.ReturnValue = Createobject("Scripting.FileSystemObject").FolderExists(Watch.ExpandString("W:\\SAPPrinting\\Printers\\@(1,1,1,9,KeepCase,NoTrim)"))


_________________________
Technical Product Manager
I don't want to achieve immortality through my work; I want to achieve immortality through not dying - Woody Allen

Top