[
https://issues.apache.org/jira/browse/OOZIE-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141351#comment-16141351
]
Daniel Becker edited comment on OOZIE-3032 at 8/25/17 8:06 AM:
---------------------------------------------------------------
An idea on how to solve this:
We join all of E, F, G and H in the (partial) graph, and insert one or more
extra decision nodes _after_ the join node. These extra decisions use the EL
function *wf:transition* to query which transition was taken and make a
decision on where to go on based on that.
The question arises what we do with nodes that can be reached through a
conditional path but transition "nowhere", meaning it should go to "end". We
often cannot just transition to "end" because it may be embedded in (multiple)
fork / joins and we have to satisfy the Oozie constraints.
What we could do is insert a temporary node in the graph that means "go to the
next join and after that, make a decision and go to the next join again until
we reach "end"". This has the disadvantage that the number of decision nodes
goes up depending mainly on the number of fork / join pairs around the original
decision node.
was (Author: daniel.becker):
An idea on how to solve this:
We join all of E, F, G and H in the (partial) graph, and insert one or more
extra decision nodes _after_ the join node. These extra decisions use the EL
function *wf:transition* to query which transitin was taken and make a decision
on where to go on based on that.
The question arises what we do with nodes that can be reached through a
conditional path but transition "nowhere", meaning it should go to "end". We
often cannot just transition to "end" because it may be embedded in (multiple)
fork / joins and we have to satisfy the Oozie constraints.
What we could do is insert a temporary node in the graph that means "go to the
next join and after that, make a decision and go to the next join again until
we reach "end"". This has the disadvantage that the number of decision nodes
goes up depending mainly on the number of fork / join pairs around the original
decision node.
> API for workflows: decision nodes autogeneration (difficult cases)
> ------------------------------------------------------------------
>
> Key: OOZIE-3032
> URL: https://issues.apache.org/jira/browse/OOZIE-3032
> Project: Oozie
> Issue Type: Sub-task
> Components: client
> Reporter: Andras Piros
> Attachments:
> 20170825093712-incoming-conditional-branches-from-different-decisions-workflow.png,
> partial_dag.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
