Difference between Job spec & WFT

Hi,
I was wondering whether the Job specification file and workflow template are the same. If they are different , can we have <template_script> perl code in a Job specification file? Iam asking this because when i try to use iwjobc with a job specification file that contains some perl code in <template_script> it says "junk found after line......".
Can a <wftask> invoke a child workflow template without the user interaction? If it can invoke, can anyone show an example snippet where <wftask> invokes a child workflow without user interaction?

Thanks...

Find more posts tagged with

Comments

Migrateduser

A wft file and a job spec are different. A job spec is purely XML - therefore you cannot have any <template_script> code embedded in it. A <wftask> cannot invoke a child workflow without user interaction (didn't we already discuss this? were you hoping someone else would give you the answer you were hoping for?).

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

GodBlessMe

Thanks Smith...

james1

Actually, I do believe that if you provide a wftask with a jobfile instead of a wftfile, then the job specification will be compiled and invoked as soon as the wftask is activated, rather than requiring end user interaction.

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

I stand corrected. I assumed since the original poster had claimed to have tried this, it worked the same as a wftfile. However if he had <template_script> stuff embedded in his job spec, it didn't get invoked immediately because it was invalid. Thanks for the clarification, James.

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

GodBlessMe

So if i specify the jobfile="path/to/my/wft" ,can it contain the <template_script>?

Migrateduser

No.

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

GodBlessMe

Can I in some way pass the values from a DCR attached to the Parent workflow to the child workflow(thru some variables defined in the parent that can be accessed in the dhild) ?
Thanks.

Adam Stoller

Let's try taking this from the top:

If you are using a wft (workflow template), as opposed to a job description file, you can prompt for information when the workflow is instantiated and/or you can embed other code (within <template_script> sections) in the workflow template.
If you are using a job description file, you cannot prompt for information during instantiation nor can you utilize <template_script> elements within the file.
If you are using a <wftask (nested workflow task) you can specify either a wftfile (interactive, allows <template_script>) or a jobfile (non-interactive, no <template_script>).
If you are using an <externaltask> or <cgitask> to initiate the job - you are using a job description file (non-interactive, no <template_script>) and the owner of the task must be within the master.uid file so that iwjobc can be run.
If you are using an <externaltask> or <cgitask> to initiate the job, you could have the same script that is initiate the job actually construct the job file - and thus programmatically fill in all the variables that you would otherwise have done via <template_script> sections within a wft.
If you are going to use the above approach, and basically have a set (1 or more) of "standard" workflows that you want to run, but which you wish to fill-in information before they are run, I would recommend creating what I call a template workflow (different than a workflow template) which is a pure XML job description file that contains key words (e.g.: __JOBOWNER__, __FILELIST__, etc.) within it.

Before running iwjobc what you do is take your template workflow, pre-process it to substitute values for the keywords described above, and write the result into a temporary file (e.g.: /tmp/taskid.xml), you then run iwjobc -i on the temporary file to compile/invoke it, and then remove the temporary file (once it has been processed with iwjobc the actual job description file is no longer needed.)

Hopefully the above captures pretty much everything that's already been thrashed about in this thread (and a few others?) as well as providing a bit more insight into how to do the various things you might want to do.

In your case - if you want to parse a DCR to extract information to use within a nested workflow (or even a non-nested workflow) - use an <externaltask> to do the parsing and to use that information to fill-in-the-blanks / construct the job description file, and then invoke that job using iwjobc -i via a task owned by someone within the master.uid file (e.g.: iwui on Unix, or Administrator on Windows)

Read through this a couple of times and think about it a bit - I think all the information you need to do what you want is here.

--fish
(Interwoven Senior Technical Consultant)