WF spanning multiple branches

OK, so here is the scoop. I have an implementation with 2 branches mapping to separate project (A&B). There has been no sharing of information between the 2 branches at all. My WF is ubiquitous, working for both branches the same. One restriction is that the WF was written to be on 1 branch at a time.

Now a manager has said they want a template on branch A, to read some data from branch B and push it live. OK, not too tough. The issue I am seeing is how to, if Joe edits the DCR on B, how should I push the updated data on A live ?

My choices (none of which I like) are:

A. Rewrite my workflow, so that it can handle multiple branches at a time. Significant effort, likely not worth the cost but the best solution.

B. Add a nested workflow (maybe a subset of the primary WF) that I can kick off in certain circumstances. Easier than above, though there are some restrictions with this that I may need to give on functionality. I never allow a file to be in 2 active jobs at the same time, but I do not know if I can enforce this restriction.

C. Manual process. Someone edits B, they need to remember to push A live. Otherwise know as not my problem. Since B will be updated weekly and the DCR on A every other week, not an awesome solution.

D. Hack. Write an external task that runs iwpt_compile, iw_submit, and opendeploy on its own and pushes the A DCR live if the B DCR is pushed. This is wrong on so many levels.

Any other options ? I am on 6.7.1 Win 2003 using WFTs and a very custom workflow.

Andy

Find more posts tagged with

Comments

Adam Stoller

Please clarify the scenario.

Now a manager has said they want a template on branch A, to read some data from branch B and push it live. OK, not too tough. The issue I am seeing is how to, if Joe edits the DCR on B, how should I push the updated data on A live ?

I think I was going to say more - but I got interrupted by a three-hour meeting so can't remember the context of what I was going to write

nipper

[QUOTE=ghoti]Please clarify the scenario.

Data in B is in a DCR. If DCR on B changes need to regenerate both A&B.If DCR on A changes, need to regenerate A (but read B to do so).

Adam Stoller

Now a manager has said they want a template on branch A, to read some data from branch B and push it live. OK, not too tough. The issue I am seeing is how to, if Joe edits the DCR on B, how should I push the updated data on A live ?
[...]
Data in B is in a DCR.
If DCR on B changes need to regenerate both A&B.
If DCR on A changes, need to regenerate A (but read B to do so).

Attach metadata on B to reference A (and perhaps vice-versa) - DB usage optional though it may help (haven't thought that far)

If B changes, the workflow process on B should either:

I don't think that's too different than what you came up with already, but perhaps takes it a step or two further in the brainstorming arena.

moonkhanna

OK, so here is the scoop. I have an implementation with 2 branches mapping to separate project (A&B). There has been no sharing of information between the 2 branches at all. My WF is ubiquitous, working for both branches the same. One restriction is that the WF was written to be on 1 branch at a time.

Now a manager has said they want a template on branch A, to read some data from branch B and push it live. OK, not too tough. The issue I am seeing is how to, if Joe edits the DCR on B, how should I push the updated data on A live ?

My choices (none of which I like) are:

A. Rewrite my workflow, so that it can handle multiple branches at a time. Significant effort, likely not worth the cost but the best solution.

B. Add a nested workflow (maybe a subset of the primary WF) that I can kick off in certain circumstances. Easier than above, though there are some restrictions with this that I may need to give on functionality. I never allow a file to be in 2 active jobs at the same time, but I do not know if I can enforce this restriction.

C. Manual process. Someone edits B, they need to remember to push A live. Otherwise know as not my problem. Since B will be updated weekly and the DCR on A every other week, not an awesome solution.

D. Hack. Write an external task that runs iwpt_compile, iw_submit, and opendeploy on its own and pushes the A DCR live if the B DCR is pushed. This is wrong on so many levels.

Any other options ? I am on 6.7.1 Win 2003 using WFTs and a very custom workflow.

Andy

Andy, although most of the above solutions and ones provided by Adam are equally good and perfect, I would split the complete logic. Do some of it into B's PT and some of it on one of Worklow's external task (Assuming the workflow has an external task) or maybe do all on B's PT

I was not able to understand your exact scenario very well as to number of DCRs etc. but thinking on the above lines may also be of help

ISCBorisB

If DCR on B changes need to regenerate both A&B.
If DCR on A changes, need to regenerate A (but read B to do so).

It doesn't look like you can make it very clean no matter how you slice it Smiley Sad

Scenario 2(A changes) does not really represent multi-branch WF, not in a sense of cross-branch File attachments anyway.

Scenario 1(B changes) can be covered outside of WF. You can intercept "B" Submit Event (for example) and run a handler to
Re-generate/Submit/Deploy(?) required "A" components. I do not think it is much better conceptually than what you've dubbed
"Option D" but at least it would allow better *Componentization* for various "B-related" Workflows.

Alternatively, you may consider *true* sharing so that you do not have to regenerate "A-assets" at all. Your description sounds like some
relatively new Project feature, you *may* have some wiggle room here. So, what if you generate TWO assets from "B", one that currently
exists and another that is just *referenced* from "A", not generated within it? Details of course will depend on generated format,
it can be SSI, asp/jsp includes, XML external Entities and the like.