activate - equivilent to reset/inactivate?

This sounds a little confusing, so perhaps I'm looking at it the wrong way.

I'm dealing with a job containing a number of parallel tasks.

Most of these tasks should move together, IE... if one task becomes active, we'll use inactivate to inactivate the other parallel tasks.

I'm also looking at activating tasks in parallel based on the activation of one task.
This is where it is tricky/confusing.

So..

task A,B are active and their successor is C and D respectively.
Can the activation of C also activate D, so that A and B are no longer active and C,D are now both activate.

It's basically allowing one task to act on behalf of a bunch of others rather than moving them all manually.

It might be a job for an external task, but looking at the elements reset, inactivate - I thought I might be able to control this through the job spec itself..

Any ideas?

John Cuiuli

Find more posts tagged with

Comments

james1

I don't completely understand what you are trying to do, but from what I can tell I think you want:

Task C:
activation: A

Task

activation: A -or- B
inactivate: A, B

???

-- James

--
James H Koh
Interwoven Engineering

Johnny

I got it.

Use a dummy task to act as a proxy - inactivate previous tasks, while it's successors are the tasks you need to activate in parallel.

John Cuiuli

Johnny

It was a little confusing for me to explain - I keep thinking about successors, I realize they are just a means to activate a task (not the only means).

I meant

A,B active

If C or D become active, unactivate A & B and activate both C & D.

Think of it as two parallel lines moving together.

Using a dummy task does the trick.

Thanks.

John Cuiuli

james1

If I'm understanding you correctly, I don't think that your dummytask is necessary at all. But maybe it might make the bookkeeping a little simpler in your WFT.

Good luck
-- James

--
James H Koh
Interwoven Engineering

nipper

A&B are active, I assume one of those completes & then C & D become active ?

that sounds like a basic or condition A|B -> C|D

me

Johnny

Yep ... that worked.

Each task had the same successor sets and those tasks that it transitioned to inactivated the previous two.

So it looks like

A | B -> C & D

Thanks

John Cuiuli

nipper

so is it really that easy ? were you drunk ? OK, so that is a silly question.

test.jpg

test.zip

Johnny

You're so predictable!

It's ANZAC day soon, I'll be quite drunk then!

John Cuiuli

Johnny

OK, here's a problem I didn't think about. I doubt there is a decent solution.

My original idea for this work flow was a teamsite code project workflow.
It would hold all the files related to a piece of work being done in teamsite, version it all together and package/deploy etc.

The idea was to be able to manage more than one branch in parallel.
The most common set up is normally a usual teamsite code branch which holds iw-home files (.wft etc) and then at least one other website branch.

I wanted to be able to hold a set of files for each branch, but I can't see how that is possible.

Do tasks pass on their files to their successor?.. If so I may be able to manage something (which would lead me back to my original problem).

It looks like files are held at the job level, not the task level, which means I may only be able to hold one branch.

I thought about nested workflows, but I've never really liked them. I wanted it to be more seemless.

Thoughts?..

John Cuiuli

Johnny

OK,

Well so long as I keep the successor sets separate, it looks like I can maintain a separate list of files for each branch.

So how can one activation of a successor set trigger the activation from a successor set in a parallel task?.. I can't see that happening, unless I use an external task to proxy them through.

Also WFconstructor.pm attaches files to *all* start tasks, how would I handle this use case?
The document doesn't describe a files key for tasks, it's only in declare workflow which then adds them to all start tasks - not desirable.

Would nested workflows help here?.. I've really never seen a great use for them. Maybe I need understand the benefits more - what are people using nested workflows for?

Thanks

John Cuiuli

Adam Stoller

I'm not sure I understand what you're trying to do - but it sounds like you want to process files in multiple branches concurrently such that even though they aren't in the same branch they are treated as a "set".

If so - then yes, I think nested workflows would be the way to go. The parent workflow can be used to collect and setup the high-level information required to initiate multiple jobs - one for each branch/workarea involved in the "set" -- the child workflows would then be responsible for all the branch/workarea-specific reviews and approvals and submits.

You *might* handle the deployment in either the child or parent workflow -- to do so in the parent, you would need to pass information about the branch and file list from the child back to the parent so that the externaltask script used for the deployment can have a handle on it. To do it from the child is more straight-forward but it prevents you from deploying all the files in all the branches within a single transaction.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com