Enfocus Community

Hi,

I have only recently started to poke around Switch scripting and am unsure how I should start solving the following situation:

- as input my flow can get single files, but usually folders with subfolders so I have an Ungroup job in the beginning

- after ungrouping I send the individual files to another application via Generic Application element

- after that I would need the flow to wait until the generic application's out folder has received all the files that originally were in the now ungrouped job before moving on



How should I approach this problem? I have tried

- adding script element before the ungroup job to have a variable with job.getFileCount(), but I could not call the variable in another script element later on.

- job.getPrivateData("Ungroup.NumFiles") in the element where I need to compare the values but it seems that Ungroup does not automatically write that NumFiles value to its private data? Therefore, I also tried to setPrivateData("Ungroup.NumFiles",fileCount) with the variable I got from job.getFileCount(), but neither that could i call later on with job.getPrivateData("Ungroup.NumFiles")...



So how do these things work? Do I need to (and how to do it..) define a global variable that could be called from different elements in a flow? Or how should I work with the job's private data? I appreciate any assistance in getting me to the right direction.



best regards,

--patrik



-Edit-

one more thing: I'm also confused about when to use a script element and when to use a script expression e.g. in a connection. I can do more with a script element but are there cases where using script expression is the recommended way?

It is not obligatory to know the number of files in an ungrouped job. The "Assemble job" element has a property "Scheme" where you can choose "Ungrouped job". The "Assemble job" will wait until all the ungrouped files are there before recombining them into an assembled job. If you do not need the reassembled job, then do a "Dismantle job" on that one at the end.



As to the difference between a script and a script expression: a script expression is something that returns true or false when used on a connection to tell Switch whether or not to follow it, or it is used to fill in a value in a field (return value: a single string, a number, ...). Script elements can take in jobs, can create them, pass them along connections, etc. Big difference.



Although you do not really need it for your case you can store values for future use in the flow in two ways:

- there is (as you were hinting at) a way of managing global data. Read the Environment class in the Help and all will be clear.

- you can add a dataset to a job. Start reading from the Dataset and Document classes. This is a bit more involved, but very powerful.

Thank you for this clarification, freddyp! I hadn't thought of assembling a job in the middle of the flow (I have assembling in the end) but that could be one thing to try then. However, this addition to the Hold Job in Switch 11 update 3 just announced (http://www.enfocus.com/en/support/knowl ... 1-update-3) sounds promising, too! Have to look into that as well.



I really need to study more the scripting because it is such a powerful feature. However, it's always better to be able to use Switch's existing features instead of writing your own if existing ones can solve the problem. And that's the thing that need trial and error to get into "thinking Switch" and seeing the best ways to do things.



Thanks again, I'll get back to you when I hit the next wall.

--patrik

freddyp wrote: It is not obligatory to know the number of files in an ungrouped job. The "Assemble job" element has a property "Scheme" where you can choose "Ungrouped job". The "Assemble job" will wait until all the ungrouped files are there before recombining them into an assembled job.


Hmm... Somehow this does not work, the files continue through Assemble Job to another application without waiting for all the files to be present there first. As clarification, both the script I run via Generic Application and Photoshop which comes later in the flow, need GUI so my script gets mixed up if Photoshop activates before it has finished with all of the job's files first. That's why I need the files to wait before continuing to Photoshop. A timed Hold Job does not work, because the number of files in the jobs vary a lot so it does not work to set a fixed time to hold files.



So now I have an Ungroup Job with private key called "purku", then I take the files through the Generic Application and from its output folder Switch continues through a Assemble Job with Scheme "Ungrouped job", Private data key "purku", Number of files "Automatic"; is their something wrong with the setup?



Or could there be another way of achieving this "time out"? Similar time out I would also need in the end (after the last Assemble job) when all the files are ready and I want to have only one e-mail per job sent to inform that the job is ready; I haven't figured that out either, yet...



--patrik

Hmm... Somehow this does not work, the files continue through Assemble Job to another application without waiting for all the files to be present there first. As clarification, both the script I run via Generic Application and Photoshop which comes later in the flow, need GUI so my script gets mixed up if Photoshop activates before it has finished with all of the job's files first.


Check if all your connection conditions are correct. If one of the files that has to go to the generic application also follows another connection that ends up in the "Assemble job", that explains why you think it does not wait. It can help to hold the jobs after the "Generic application". Then you can see how many files actually end up in "Assemble job" that have not been processed by the generic application. If you see unexpected files in there it means you let them slip through the net.



There is nothing to figure out about the mail. After an "Assemble job" you have 1 job, so a "Mail send" will send 1 mail.

Thanks! That was it, I hadn't realised that having the flow divide before assembling would break it so switching (heh..) those around fixed it! The other assemble before mail had a similar problem but I think it'll get solved as well.



--patrik