5:40 p.m.
Hey Drools Flow Crowd,
Would appreciate your thoughts on:
Validation One Node
||
\/
Validation Two Node
||
\/
Validation Three Node
||
\/
Validation Four Node
...
...
If any errors are found at any validation node, the process should
terminate with proper logging, etc..
What would be your approach of a clean way to do it in order to avoid
cluttering the process definition with a splitter after individual
"Validation XYZ Node":
Validation One Node
||
\/
SPLITTER => Finalize => End ( or Fault node, which is
as dirty )
||
\/
Validation Two Node
||
\/
SPLITTER => Finalize => End
||
\/
Validation Three Node
||
\/
SPLITTER => Finalize => End
||
\/
Validation Four Node
...
...
Thanks for your input,
/Anatoly
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-Validatio...
Sent from the Drools - User mailing list archive at Nabble.com.
12:40 p.m.
In my current application, we throw a runtime exception on validation to
terminate the flow and dispose session. Is there any issue with this method?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-Validatio...
Sent from the Drools - User mailing list archive at Nabble.com.
8:29 p.m.
well, I guess that depends on a use case.
What if you want to have some skip / retry policy in place?
Also a workflow client ( that called this process ) now need to be aware
that somewhere inside this process ( subflow of a subflow of a subflow... )
there is a ValidationException that will be thrown: not a nice way to have
your workflow APIs built.
But if it works for you, it is fine. I just find it really strange that
Drools Flow fails to see the importance of Java exceptions, e.g. there is no
way to register a real [ Java ] exception handler to the process.
The only two non-existing at this moment solutions for the flow above would
be:
1. Use a process ( / subprocess ) wide Java exception handler, that you can
register ( e.g. ValidationExceptionHandler ), that would know exactly what
to do in case an exception occurs.
2. Use Activities ( e.g. work items ) that are capable of more than one
transition coming out of them, and use the second transition to point to the
Validation Error
I still need to set some time aside to think of some other solutions, but I
would appreciate some external thoughts as well.
Thank you,
/Anatoly
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-Validatio...
Sent from the Drools - User mailing list archive at Nabble.com.
10:28 p.m.
Hi Anatoly,
Just saw your original post.
"
What would be your approach of a clean way to do it in order to avoid
cluttering the process definition with a splitter after individual
"Validation XYZ Node":
Validation One Node
||
\/
SPLITTER => Finalize => End ( or Fault node, which is
as dirty )
||
\/
Validation Two Node
||
\/
SPLITTER => Finalize => End
||
\/
Validation Three Node
||
\/
SPLITTER => Finalize => End
||
\/
Validation Four Node
...
...
Could the validations be done in rules as opposed to individual nodes? And
then have a single splitter that check the value of some object to determine
whether to exit or not?
dave
On Wed, Jun 2, 2010 at 2:29 PM, tolitius <webakaunt(a)gmail.com> wrote:
well, I guess that depends on a use case.
What if you want to have some skip / retry policy in place?
Also a workflow client ( that called this process ) now need to be aware
that somewhere inside this process ( subflow of a subflow of a subflow... )
there is a ValidationException that will be thrown: not a nice way to have
your workflow APIs built.
But if it works for you, it is fine. I just find it really strange that
Drools Flow fails to see the importance of Java exceptions, e.g. there is
no
way to register a real [ Java ] exception handler to the process.
The only two non-existing at this moment solutions for the flow above would
be:
1. Use a process ( / subprocess ) wide Java exception handler, that you can
register ( e.g. ValidationExceptionHandler ), that would know exactly what
to do in case an exception occurs.
2. Use Activities ( e.g. work items ) that are capable of more than one
transition coming out of them, and use the second transition to point to
the
Validation Error
I still need to set some time aside to think of some other solutions, but I
would appreciate some external thoughts as well.
Thank you,
/Anatoly
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-Validatio...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:21 a.m.
Hey David,
Yea, that would be a valid approach in some of the cases, but..
In this case the client would like to see ( explicit ) nodes in a
process definition. The reason for this is that a certain chain of
validators may include nodes that invoke validation on external systems,
e.g.:
Validation One Node ( may be a RuleFlow node )
||
\/
Validation Two Node ( call external system A to validate
)
||
\/
Validation Three Node ( may be a RuleFlow node again that
would know that system A validation has passed )
||
\/
Validation Four Node ( call external system B to validate
)
... ... ...
So, yes, it in theory all can be done in one method/rulegroup all
together, but then it defeats the purpose of the "process definition" that
can directly map to the business requirements ( and more importantly change
visually when requirements change ).
But thanks for your input, I will appreciate anything else you may have :)
/Anatoly
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-Validatio...
Sent from the Drools - User mailing list archive at Nabble.com.
5076
days inactive
5078
days old
4 comments
3 participants
participants (3)
-
David Sinclair -
tolitius -
xdirewolfx