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

Determining which callback was transitioned

Johnny

Hi Guys,

Problem:
I have a large workflow that has one central 'coordinator' group task which has several successors for various tasks which could be deployment, promoting to another branch etc. They all return to this central coordinator task where they could perform another action including ending the job.

I obviously want all the various tasks in the different routes from the coordinator task to be owned by the user who took the coordinator task, but i dont think i should need to stick a change owner task infront of each of the successors.

I have changed the standard changeowner script to accept multiple tasks to be changed in the one execution.

Possible solution:
Rather than sticking a whole heap of changeowner tasks infront of each successors, I was wondering if i could have each successors point to this one changeowner task, and based on the successor number (or callback) that reached the changeowner task, it will then set the callback to the same number, so effectively transitioning down the right successor by proxy.

I cant see a way for an external task to figure out which successor number/index was used to activate it.

Any ideas on solving something like this?... Group tasks are a real pain because of these sorts of problems. Maybe there is an easier way than this idea

thanks guys

John Cuiuli

Find more posts tagged with

Comments

Adam Stoller

I suppose you could use a job-variable (or task-variable) to indicate which path you want to transition down after setting the owern of the other tasks.

I usually package the whole thing up into one script and just make sure I know the names of the tasks I want to change owner on, then I just do a series of GetTaskByName() and SetOwner() calls - yeah, you still have to have the one externaltask after the grouptask in order to set other task ownerships, but you don't need N different externaltasks to do that.

You might be able to have the externaltask run concurrently with the grouptask - have it poll to see if the grouptask has been taken ownership of and then perform all the ownership settings - of course there's a chance that the owner of the grouptask will transition before the externaltask has completed all of it's work - but you could probably make the other tasks dependent upon both tasks transitioning into them.. probably needs a bit more thinking and diagramming to make sure all the pieces fit though.

--fish
Strolling Prime Minister of no fixed address

Johnny

Sorry I dont see how the first two ideas would work.

The concurrent task is a way, but rather not have tasks polling, just doesnt seem ideal.

Maybe I didnt make alot of sense last time, but what i have is a grouptask that has a 5 different successor sets (IE 5 different transition routes).

So I would need one changeowner task sitting infront of each of those 5 routes to change the owner of all the tasks down that particular route.

Instead of doing that I was wondering if there was a way to determine which successor set was selected in a previous task to reach a current task.

Meaning, all 5 successor sets would all transition into one task which would be the changeowner task (which changes a number of task owners) and then based on the successor set of the previous task would transition with the same number.

IE successor set 4 was chosen to get to change owner so change owner does a callback 4 to continue down that route.

I have no idea if its possible to find that out, or even if it is the best way of doing it.
I would like to find a nice clean way of changing all or a series of tasks no matter how many forks may be in the job.

Thanks

John Cuiuli

suj

I am not sure of this...but there is a GetTransitionMade() method in WFTask.pm...never tried this..but sounds like it may suit your need...on an earlier situation i had the same requirement where i replaced user tasks with cgi tasks just to do some manipulation based on the successorset...

Johnny

Thanks so much thats exactly what I was after!

It wasnt in the perldoc so i didnt pick it up.
I was going through the task object looking for something, but its actually stored in the job object, which obviously makes more sense!

Thanks again

John Cuiuli

Adam Stoller

If it's not documented in the perldoc - then it may nolt be considered officially supported and tghus may be subject to change in an upgrade without notice... I'd suggest contacting Support to see if you can get confirmation of whether or not it is supposed to be part of the API - if so, file a bug report about the lack of documentation. If not, file a feature request for an officially supported way to do what you're looking for.

--fish
Strolling Prime Minister of no fixed address