Creating AT Jobs through a Perl callout

I'm working on a Perl callout that will allow specific users to schedule submit jobs for a later date. I've already got the whole thing set up, from credential checks to listing files to the selection of desired files to the submit and deployment date scheduling... except one small item... the AT job that actually kicks off the silly thing at the specified time...

It seems that iw-perl can't set AT jobs. (TS 5.5.2 on Win2000 server). Does anyone know a way around this? If not, any ideas on how I can use a custom callout to schedule an event in the future?

(A little background)
The whole point is really for file submission to be scheduled, not the deployment. We have strict deployment schedules already, so if a file is submitted it will be deployed at the next deployment (this is an over-simplification, since WF is used for all file submissions and only a sum total of three people can get around that... only these three will have access to the callout). So, if someone needs a file to go out on Saturday night and no earlier, it can pass the WF process, and sit in the web team's box for final approval. Instead of approving it, we can instead schedule it's final submission for the following day and go home. That's the idea anyway, except I know of no way to schedule events on the fly with a command line script except for using an AT job...

Any help would be appreciated
Thanks
-mike

Michael Langford, Webmaster - CARE USA
151 Ellis Street, Atlanta, GA, 30303
http://www.care.org/

Find more posts tagged with

Comments

tvaughan

I had similar troubles about a year ago trying to let users schedule deployments via a custom menu item we have.

Everything was set up correctly, and it worked from the command line, but it wouldn't work from the GUI. I forget what the ultimate reason was (maybe something about iwui not being able to write to the necessary cron/atjobs directory???) but I eventually scrapped the whole thing.

This was on 5.5.2/Solaris 8

Tom

JonathonG

Any reason you don't want to use workflow for this? You could use a dummytask just before the submittask. You would probably have a CGI task just before the dummytask to set the timeout on the dummytask.

Jonathon
Independent Interwoven Contractor

carnix

I'm not sure I understand what you mean...
You mean just set a time out that makes the task sit idle for 21600 second (6 hours, for example) before executing?

That would work, in fact, that would work better than trying to re-tool my existing file re/generation scripts to work outside of a workflow (they are all keyed off of a $this_task->IsValid() check, for example, and all the functions look for task and workflow ids).

(I had written here a question on how to do workflows, but as I wrote it, I realized how to do it... so to confirm)

To kick off a workflow, scheduler.wft, I would use the following commands:

first create a job
iwjobc.exe scheduler.wft

then, add files with iwaddtaskfile.exe. Loop to add more than one.

finally, iwinvokejob.exe to run the workflow. The first task is a dummy that does nothing but sit and way for a number of seconds, then going on. The second task does the voodoo. All non-interactive.

Is this correct? Seems right... I've never tried anything like this, so it's sort of new ground for me. One question though, how can I pass the variable delay time to the dummy? Would I use iwjobvariable?

Thanks for the advice!
-mike

Michael Langford, Webmaster - CARE USA
151 Ellis Street, Atlanta, GA, 30303
http://www.care.org/

JonathonG

Well, I was actually thinking you would add this to the end of your existing workflows. But, I suppose you could create a new one.

How did you want this initiated? I assume a user in your web group is going to be specifying the timeout. So, the User-Level interaction would be:
1) Log in to TeamSite
2) Navigate to directory containing files for delayed submit
3) Select files
4) Click "File->New Job"
5) Select "Delayed Submit" job type
6) On Job form, fill in timeout value (could even be an exact date/time)
7) Click "Run Job"

From the system perspective, you would need a WFT containing the following:
1) A TAG_INFO section that provides a way for the user to enter the timeout value
2) A dummytask as the start task that has its timeout value set from the value entered by the user (using __VALUE__). This task should include the <files> element that all start tasks have.
3) A submittask as the successor to the dummytask. All files selected by the user will be submitted.
4) An endtask as the successor to the submittask.

That should give you a pretty good idea. If something's not clear, post again.

Jonathon
Independent Interwoven Contractor

Migrateduser

We do this a slightly different way. Instead of using a dummytask as the delay task, we use a cgitask that remains active during the delay. The user sets the date & time to delay the process until, then that info is stored in a config file on the filesystem. A cron job wakes up every minute and checks to see if any delay job's wake-up time has passed and if so, performs a callback on the cgitask. It's primitive, but what it allows is for the user to restart the CGI to change the delay time or kick off the next task immediately if they so choose. It offers more flexibility is all. And it works like a champ - it's been in our workflows for over 3 years.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

carnix

Hmmm. I think I see what you mean. I was looking at if from a custom menu item... What you're talking about would actually show up on the workflow options when a user starts a job. We have a "No Workflow" option already, only available to web staff (same group this callout would be use by). If I simply add a dummy task to handle the delay BEFORE the submit task that run the generation scripts (user don't get to submit non-dcr files ever, and they don't get to specify where files go, it's all handled through generation scripts at the end of the workflows), the place I ask for comments and a due date could also be expanded to include a delay until timer...

Ah.

That would work much better...

Thanks!!!
-mike

Michael Langford, Webmaster - CARE USA
151 Ellis Street, Atlanta, GA, 30303
http://www.care.org/