nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dynamically adding a task

jodell

I need to associate a series of workflow file lists into a release "package." The workflows are from different branches and the number of workflows may not be known in advance.

Using nested workflows I have been able to associate a known number of sub-flows to a parent and capture the file lists.

The problems that I am having is this:
How do I add additional tasks (nested wf) to an established job? (I am assuming that this will be some type of CGI)
How do I loop back to the "add child" step without waiting on the child? (Note that I am looking more for concurrent execution [sub-wf creation] than waiting for transition)

Any help would be great, and code snippets for what I have already can be posted on request.

Find more posts tagged with

Comments

Migrateduser

Maybe I'm not understanding your questions correctly, and I don't know what you're asking at all in your second question. But to try and help with the first question:
How do I add additional tasks (nested wf) to an established job?
I think you have to plan in advance for such things and code them into your wft and use an externaltask to check flags you have set up in advance (probably parent workflow variables) to check and see if the cgitask (or whatever it is) is needed and execute it if so, skip it if not. I am not aware of any way to add a task after a workflow has been instantiated.

I am using multiple nested workflows and am using several workflow variables in the parent to maintain the state of each child in real-time so that any child knows the state of any other child and can utilize dependencies if necessary. Externaltasks allow me to go down forks in the workflows by checking state and chooing the right path at that moment in time.

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

Test.zip

jodell

Hmmm... So if I don't know exactly how many sub-flows I will need I am SOL. I thought about using an external task to create the sub-flow as an independent job, and have a workflow variable contain all the sub-flow ids. When the subflow is created it would have a variable that would contain the ID of the master process so it could update the master file list. I expect that this will have problems but it might be the best approach.

Question 2 is based on the idea of a task that creates additional nested WF tasks for the parent workflow. I wanted the workflow to allow the creation of an arbitrary number of additional subflows at any given time before the subtask has completed. If I use the concept of the approve task I can create an unlimited number of subflows, but they are serial in nature and only one can exist at a given time.

I am not sure this is any clearer, but if your answer to the fist question is correct the second question doesn't matter.

Migrateduser

There may be other ways. I know people have kicked off workflows from externaltsk scripts - the only problem is they won't be "child" workflows in the sense of having a truly nested workflow. But you could certainly pass the parent ID to the newly instantiated workflow somehow and still be able to communicate between the 2. I think you still can do what you want (kick off new workflows on the fly) it just might be a little more tricky to monitor and control.

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

Adam Stoller

Just thinking off the top of my head here - long overdue for sleep - how about you have a wftask that has the sole responsibility of prompting (in the TAG_info section) for the number of sub-workflows you need, and then having *that* wftask generate as many wftask's as you need to support those sub-sub-workflows.

The sub-sub workflows would have to go through two redirections to get to the true parent [grand-parent] workflow in order to get/set data (or you could have the intermediary workflow collect all that information first, and then when the grand-child workflows finish and pass information to it, have it turn around and pass the information back to the grand-parent workflow)

There might be an easier way - but that's what came to my mind when I read your post.

--fish
(Interwoven Senior Technical Consultant)