I thought I'd start a new thread on this so the details don't get lost in the other thread about transition comments. Looking at my problem another way, I have a parent workflow that kicks off up to 5 concurrently nested child workflows using <wftask>. I would like to turn these WFTs into job spec files so that I can use the <jobfile> option rather than the <wftfile> option in order to kick off these child workflows with no user interaction. I have figured out a way to easily turn my WFTs into job specs, however I need to do this in real time just prior to the <wftask> in an externaltask because the child job spec requires data from the parent in order to fill in all the proper details (such as task owners, areapaths, etc.) . The problem is more than one person could potentially be executing the parent workflow at the same time, for different sites. So if I create a child job spec I need to name it uniquely so that if someone else comes along and runs the same workflow, that child job spec does not get overwritten. The problem is, I can't dynamically change the name of the <jobfile> file. It becomes hardcoded at the time the parent job is instantiated, so it can't reflect the dynamically named job spec. I don't see a way around this. Now I'm stuck again, at least until we upgrade to 6.0 which won't happen anytime soon.
A question about the background flag in the 6.0 <wftask>...
If I have a WFT file that has no TAG_info info in it - there's no UI for the workflow but there is a lot of perl code that sets up the various elements of the resulting job spec, and I use the background="t" flag, will it do the right thing and kick off the workflow automatically or will it barf because there are no TAG_info elements in my WFT?
Dave SmithSr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
