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

WFM: DeployTask and Conditional Links

Adam Stoller

WFM (1.0.1.1)

Scenario:

alternative (WFM+Java required)? Are there other pros/cons to the above that might make one a significantly better option than the other?At this point, I'm thinking that I'll end up going with the "dummy" ExternalTask option - but I'm curious to see what others think (at least for a few days)

Find more posts tagged with

Comments

Adam Stoller

I may have figured it out ... at least as far as the WFM interface is concerned (we'll see when I get around to actually running the workflow ;-)

Use an OR gateway:

            +-->[A-Review]
[DT]-->[OR]-+-->[B-Review]
            +-->[No-Review]

This seems to satisfy the WFM validation step.

Crsb

Definitely A!
I personally got away from using conditional links and default gateways because sometimes it is not allowed to use them and some other times they are not flexible enough since they get evaluated as part of the workflow instantiation. I started using a URL task as a gateway (dynamic gateway) and I pass my transition links names as task variables(optional). the URL task has two lines of code to evaluate things (job variables, task comments...) then choose a transition. you can make the "dynamic gateway" as general as you want by passing things (expression to evaluate, variable to evaluate, transition names...) as task variables so you can reuse it as much as possible.
the default gateways and conditional links are still useful in simple workflows.
DG: dynamic gateway, fancy name for ET. Smiley Happy

            +-->[A-Review]
[DT]-->[DG]-+-->[B-Review]
            +-->[No-Review]

B is similar to A in way that you still have to write code to maintain. but writing a deploy task is not as easy writing code to evaluate and choose task.

Adam Stoller

Definitely A!
I personally got away from using conditional links and default gateways because sometimes it is not allowed to use them and some other times they are not flexible enough since they get evaluated as part of the workflow instantiation. I started using a URL task as a gateway (dynamic gateway) and I pass my transition links names as task variables(optional). the URL task has two lines of code to evaluate things (job variables, task comments...) then choose a transition. you can make the "dynamic gateway" as general as you want by passing things (expression to evaluate, variable to evaluate, transition names...) as task variables so you can reuse it as much as possible.
the default gateways and conditional links are still useful in simple workflows.
DG: dynamic gateway, fancy name for ET.
            +-->[A-Review]
[DT]-->[DG]-+-->[B-Review]
            +-->[No-Review]
B is similar to A in way that you still have to write code to maintain. but writing a deploy task is not as easy writing code to evaluate and choose task.

Well - if the condition was based on post-instantiation variables, then yes - 'A' is a reasonable choice, but given that the conditions are based solely on variables being set within the instantiation process, I think 'C' (using the OR gateway and conditional links) is a reasonable approach. Hopefully I'll get to verify the functionality before the end of next week (lots of code still to be written before this puppy can fly ;-)