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; } } }

Parallel tasks

Valentine

Given
task A

nested workflows (sub_a, sub_b, sub_c), after execution the nested workflow returns to the task "a".

Task "A" can start multiple nested workflows that will run in parallel.

If all of the nested workflows are running, I can query active tasks with "iwquerytasks" and get all of the active tasks (including all of the tasks in the nested workflows).

As soon as one of the sub-workflows finished, and transitions to the "Task A'.

I can no longer get the active tasks. They appear to be in limbo. I can't see in in "My Tasks" on the workflow tab, and can't get them through iwquerytasks.

I thought about using "resets" and "inactivate", but it does not look like a solution.

Find more posts tagged with

Comments

kaalraa

Given
Task "A" can start multiple nested workflows that will run in parallel.
If all of the nested workflows are running, I can query active tasks with "iwquerytasks" and get all of the active tasks (including all of the tasks in the nested workflows).
As soon as one of the sub-workflows finished, and transitions to the "Task A'.
I can no longer get the active tasks. They appear to be in limbo. I can't see in in "My Tasks" on the workflow tab, and can't get them through iwquerytasks.

Task A being the the task from the parent workflow would transition further and wait before EndTask prior to complete all the nested wfs.

As far as i understood your problem... try to put up a dummy task just before the EndTask of the parent workflow and link all the nested wftasks to that dummy task with an AND task. It will wait for all nested tasks being invoked to complete... and then only transition to End.

Still you have any issue... please post your code so that anyone can review over here.

nettai

hey

i have a small query, how are your sure that only one of the sub task has been finsihed and rest of them are still active but not viewable.

can you share the same with me.

thanks,
Karthik

Valentine

hey

i have a small query, how are your sure that only one of the sub task has been finsihed and rest of them are still active but not viewable.

can you share the same with me.

I can see them if I go to the TS interface and "View Jobs" or "View Tasks".

Valentine

Still you have any issue... please post your code so that anyone can review over here.

Well... Task A remains active during the whole process. I'm not sure if the dummytask before the end will help. Since not all of the sub workflows might be launched.

trying to figure out how to insert xml into the message ...

Valentine

[HTML]

[/HTML]

Pass

I am looking for a Teamsite Developer for Contract role in Surrey, London , UK

strong Perl experience . Any one interested or know someone who is available

Please call me asap if available !!

Regards

James

Parity Resources
MOB + 44 77 99 88 1847

Adam Stoller

[HTML]

[/HTML]

The above code defines "TaskA" which has 3 possible successors ("sub a", "sub b", "sub_c") - those successors do not run in parallel - they are independent choice / selections.

I suggest you spend a bit more time with the manuals and make sure you understand how to write a workflow to do what you are describing.

With respect to

As far as i understood your problem... try to put up a dummy task just before the EndTask of the parent workflow and link all the nested wftasks to that dummy task with an AND task. It will wait for all nested tasks being invoked to complete... and then only transition to End.

it doesn't really matter what kind of task you have following the tasks (CreateSubA, CreateSubB, CreateSubC) that follow "taskA" - but it does matter that you have the activation of that task clearly defined to be an "AND" operation requiring that all predecessors complete before it becomes active. It is also clear, from the above code, that you didn't understand what was being suggested here either - since you defined three independent tracks with a single CreateSubX and dummytask for each one - and not what was being suggested by either you or kaalraa - which is a successor that fires off three concurrent tasks, each of which creates a sub-workflow, and each of which then needs to callback / transition to a single task that will wait for all of them to complete.

If/when you do repost your code - please include the definitions / specifications of:

tasks are either wftask's or externaltasks. TaskB can be any kind of task you want - including an endtask - but we still need to see how you are defining it.

ISCBorisB

iwquerytasks peculiarities aside...
What is the problem you are trying to solve?

Valentine

well.
Yes, technically they are not parallel, but...

Since TaskA is always active, user can always go to the TaskA and select one more path for the workflow.

At most there will be 3 parallel tasks, at least 0.

kaalraa

Task "A" can start multiple nested workflows that will run in parallel.

It means code should be like this:

<usertask name="TaskA">
<successors>
<successorset description="sub a">
<succ v="createSubA" />
<succ v="createSubB" />
<succ v="createSubC" />
</successorset>
</successors>
</usertask>

Moreover you dummy task should be linked to endtask of parent wflow. Dummy task would be successor to an AND task... and all tasks; createSubA, createSubB, createSubC should linked to AND task.

Just the number of parellel successors to TaskA.. should link to the AND task. This is what i was saying.

Well... Task A remains active during the whole process.

If this is the case... then you have to debug as what exactly the issue is and the question asked by nettai is quite logical.

ISCBorisB

The above code defines "TaskA" which has 3 possible successors ("sub a", "sub b", "sub_c") - those successors do not run in parallel - they are independent choice / selections.

I'm just guessing here but it seems that he allows the user to choose subWFs to start. Sure, they are not parallel per se but you'll be
back to A immediately after starting "sub b" for example. Then you can start "sub a", etc... The end result is a collection of nested jobs all the same.

If I can hazard another guess, he probably needs to check somewhere if "sub x" exists before starting another instance of it. Hence a query...

Valentine

I'm just guessing here but it seems that he allows the user to choose subtasks to start. Sure, they are not parallel per se but you'll be
back to A immediately after starting "sub b" for example. Then you can start "sub a", etc... The end result is a collection of parallel jobs all the same.

If I can hazard another guess, he probably needs to check somewhere if "sub x" exists before starting another instance of it. Hence a query...

Yes. It is up to user to start the parallal tasks.

- All of the tasks are visible in the TS interface
- there is a CGI script in picture that uses iwquerytasks and the wofklowid to find all of the active tasks and subworkflow active tasks.

ISCBorisB

Yes. It is up to user to start the parallal tasks.

- All of the tasks are visible in the TS interface
- there is a CGI script in picture that uses iwquerytasks and the wofklowid to find all of the active tasks and subworkflow active tasks.

I think you have a problem somewhere in your query, in the code parsing the result or both.

So, can you publish a query string and query results before and after the first subtask ends?
If you do, please run it from CLT and attach raw results without any "code massage" whatever

kaalraa

Yes. It is up to user to start the parallal tasks.

- All of the tasks are visible in the TS interface
- there is a CGI script in picture that uses iwquerytasks and the wofklowid to find all of the active tasks and subworkflow active tasks.

Technically, parellel tasks are quite different from the tasks which can be run simultaneously.

On the present scenario, it is better to provide the code of your wf/s as well as your CGI script.

ISCBorisB

Yes. It is up to user to start the parallal tasks.

Technically, parellel tasks are quite different from the tasks which can be run simultaneously.

All of it, starting with the thread Title is terminological misnomer. User does not start "Parallel tasks", he starts Nested Workflow(s)
with it's own tasks, parallel (inside this sub WF) or otherwise. Original and Sub Flows are independent, operationally their respective tasks are neither
"parallel" nor "simultaneous" whatever that means

Valentine

My fault. The tasks are simultaneous.

Here is the script:

first run: (4 tasks are active)

600852
601762
601805
601826

second run: (One of the nesetd workflows has finished)
600852

kaalraa

All of it, starting with the thread Title is terminological misnomer. User does not start "Parallel tasks", he starts Nested Workflow(s)
with it's own tasks, parallel (inside this sub WF) or otherwise. Original and Sub Flows are independent, operationally their respective tasks are neither
"parallel" nor "simultaneous" whatever that means

I used the word simultaneous as it CAN be; but never be in parellel.

Adam Stoller

Yes. It is up to user to start the parallal tasks.

- All of the tasks are visible in the TS interface
- there is a CGI script in picture that uses iwquerytasks and the wofklowid to find all of the active tasks and subworkflow active tasks.

What you have described - and what you've shown in code - do not align.

You seem to believe that a given task (TaskA) remains active until it's successors ("CreateSubA", "CreateSubB", and/or "CreateSubC") complete - not true.

You either have a serial process for initiating sub-workflows which the user is allowed to repeat multiple times, taking different paths from TaskA - or you have a concurrent process that fires off N different sub-workflows in parallel and then transitions somewhere in the parent job after all N of the sub-workflows have completed.

Right now you have what appears to be a half-baked idea of what you think you want to do with apparently insufficient knowledge and/or experience to figure out how to do it.

kaalraa

My fault. The tasks are simultaneous.
Here is the script:

first run: (4 tasks are active)
600852
601762
601805
601826
second run: (One of the nesetd workflows has finished)
600852

Could you please provide your parent workflow code??

kaalraa

Or, you need to hire someone who has these capabilities to do it for you.

This suits me well... :-). Waiting for a PM.

Valentine

You seem to believe that a given task (TaskA) remains active until it's successors ("CreateSubA", "CreateSubB", and/or "CreateSubC") complete - not true.

well ... What can I say. It stays active, due to the parallel transition to the dummy task and create the nested workflow. Not 100% active, it becomes active right after the nested workflow is instantiated.

Adam Stoller

well ... What can I say. It stays active, due to the parallel transition to the dummy task and create the nested workflow. Not 100% active, it becomes active right after the nested workflow is instantiated.

Okay I missed the dummytask transition back to TaskA. Yeah - that will make TaskA active again, though it isn't clear whether or not this is a "good" thing.

Let's start over -

There are a large number of possible scenarios here - but without understanding what you're using as requirements or constraints - suggesting a solution is kind of pointless.

ISCBorisB

well ... What can I say. It stays active, due to the parallel transition to the dummy task and create the nested workflow. Not 100% active, it becomes active right after the nested workflow is instantiated.

It does not stay active. You re-activate it. What happens is logistically the following:

1. User chose what WF to start (sub a/b/c)
2. You transition to two tasks, one to create WF(an assumption that you neither confirmed nor denied, wftask), another Dummy with 0 timeout
3. Dummy loops back to the original task immediately, not "right after the nested workflow is instantiated".
4 Original Task is now reactivated and User can chose again

Back to your query problem:
What are your "createSubX" tasks really? Are they wf tasks? If so, tasks you are looking for do not belong to the root WF.
Nested WF is a WF in its own rights, with ID and all. If anything, I'm surprised that you've got a "full" list of tasks before the first sub transition.

It may be an inconsistency in "iwquerytasks" behavior in respect to nested WFs, but your main problem is that you use "wrong" (root) WF ID to get tasks of branched WFs. You have to get sub WF ID and request by it

Valentine

What are your "createSubX" tasks really? Are they wf tasks? If so, tasks you are looking for do not belong to the root WF.
Nested WF is a WF in its own rights, with ID and all. If anything, I'm surprised that you've got a "full" list of tasks before the first sub transition.

It may be an inconsistency in "iwquerytasks" behavior in respect to nested WFs, but your main problem is that you use "wrong" (root) WF ID to get tasks of branched WFs. You have to get sub WF ID and request by it

They are external tasks, that generate a workflow spec, followed by the wftask.

It is my understanding that nested workflows are an active tasks within the parent workflow.

Therefore I get the listing of all the active tasks for the given workflow, and if they have any tasks I assume it is a nested workflow.

After one of them finishes, it looks like parent workflow loses any sense of active tasks, and all nested workflows become "parentless".