Greetings, I have a bpmn that planned to check several of rules for decision making, it’s “model 1” in my screenshot above.
Prepare model, is just for initialization process, e.g: preparing object model, etc
Inside the system task of each rule, there might be process to call another API, DB, etc
Results of each rule will be stored as HashMap in process variables.
Decision maker will check on the HashMap, which rules are breaking and make another API call based upon the results.
So my problem is what if the rule is actually dependent each other ? Meaning to say, if rule 1 is break, no need to execute rule 2,3… But if rule 1 is passed then need to check the rule 2, and so on.
Looking for the documentation, instead of creating multiple decision gateway, my plan is to use message event, so I draw another bpmn (model 2) in my screenshot above
Question: Is my bpmn okay ? or actually there is another good practice to implement my case ? Thanks.
It depends on the meaning of “if rule 1 is break” how to proceed.
If it is an expected result, I would go for the gateway to destinguish between continuing or not. Create a understandable process model.
If it is an unexpected break, you could model an interrupting event subprocess and double the “Decision Maker” task, as the main process won’t continue any more.
Hi @Ingo_Richtsmeier, thanks for the answer.
Yes, “break” it’s an expected result, so meaning below model should be fine ? , I was worried there is actually another good practice for this case.
yes, it looks good. Could be even better with expressive names.
Instead if “Rule 1”, maybe call the task “Check something”. And label the gateway with a question and answer the question on the outgoing sequence flows.
I expect the chain of rules to be followed on the default flow, but this may be my misunderstanding (from the poor naming ).
Hi @Ingo_Richtsmeier,
Of course, all the labeling are actually already in place, I just extract the quick draft for this forum posting only. thanks for the correction
, I was worried there is actually another good practice for this case.
).
thanks for the correction