job priorities unclear

tz8 · Post by **tz8** » Thu Dec 20, 2012 9:05 am

Good morning Ladies and Gents,

can someone please shed some light on job creation priorities? I created a timerFired script to monitor a network share and identify possible jobs:

- get a list of XML files in this directory

- crawl through XML list

--- see if XML is in arrived state

----- check if PDFs referenced in XML are also there and in arrived state

----- read XML contents into dataset

----- create a job from the XML with job priority 10 (highest i use in my environment) and sendToSingle

----- crawl through referenced PDFs

------- create a job from each PDF attaching the dataset to it, priority set to -1, and sendToSingle

when i check the messages i can see that although i give the XML job the highest priority there are PDF jobs being worked on first. How can i make sure that the XMLs i made a job of are actually being sent off first? Or do i really need to createPathWithName first and s.copy/File.remove the XML file to make sure the script will never find the XML file during it's next execution?

Thanks for your insights and ideas on that

dkelly · Post by **dkelly** » Fri Dec 21, 2012 3:35 pm

Switch docs claim that the groups jobs with the highest priority first and then the order they were queued. So you would expect the XML jobs to be run first then the PDF jobs.

Are the XML jobs just the dataset, just the XML or both XML file and dataset?

I wish that Switch would actually run the jobs created while the script is still running.

tz8 · Post by **tz8** » Fri Dec 21, 2012 3:53 pm

dkelly wrote: Switch docs claim that the groups jobs with the highest priority first and then the order they were queued. So you would expect the XML jobs to be run first then the PDF jobs.

i kinda expected this too, yeah

dkelly wrote: Are the XML jobs just the dataset, just the XML or both XML file and dataset?

just the XML

dkelly wrote: I wish that Switch would actually run the jobs created while the script is still running.
read this Enfocus? Listen to Dwight! Or there will be an apocalypse! I mean it!

freddyp · Post by **freddyp** » Mon Jan 07, 2013 12:08 pm

Sorry for my late reply, but I had a whole bunch of holidays I had to take.

Question: you are picking up the XML as a dataset and you are submitting both the XML and the referenced PDF as a job, why? When you submit the PDF job with the XML as a dataset you can always get hold of the XML file with the "Export metadata" element. I therefore see no reason to submit the XML as a job in your script, and that invalidates the need for playing with priorities. As I do not know what you are exactly trying to achieve there may be something I am overlooking, so please enlighten me.

Freddy

tz8 · Post by **tz8** » Mon Jan 07, 2013 3:02 pm

Hi Freddy and welcome back!

After the script element's success out connection i'm having a folder with 2 outgoing connections, one for the PDFs (that have the metadata attached) and one for all jobs (also the XML).

The PDF connection purely goes into production, and the 'all jobs' connection goes into the archive.

Making the XML a job of its own and moving the file into the archive preserves it's original creation date (which is important for invoicing the client), which would not work with an export metadata element.

Hope this explains my intentions

Cheers,

Thorsten

freddyp · Post by **freddyp** » Mon Jan 07, 2013 5:08 pm

OK, thanks, that explains why you inject the XML as a job. Next question: why is it important that the XML passes before the PDF? You write that the PDF goes into production and the XML into the archive. The chronology of these events would only be important when production picks up information from the XML in the archive. Is that so? If not, why would it be important that there are a few seconds of difference between the two events? If it really is important, then I would do what you describe in your original post: copy the XML file into the archive from within the script and delete the original.

Freddy

tz8 · Post by **tz8** » Tue Jan 08, 2013 3:08 pm

the XML refers to ehre the PDFs are. Once i found a complete order (all referenced PDFs are in arrived state) i want the XML to vanish as fast as possible so the next time the script is invoked the XML is not parsed again. I had that problem before i fiddled with the job priorities.

But why doesn't Switch create jobs directly when you create them in a script but only after the script has ended?

Cheers,

Thorsten