Decision Node

RE: Decision Node

bryant.st39 — Tue, 30 Jun 2020 01:30:43 GMT

We considered using a similar approach with a DB table...we may revisit that idea. I agree, testing is very easy when using proper process models with gateways to control flow logic. One advantage we've found with this approach is "integration testing" is simply testing decisions (logic) to launch the next process. We can test the entire flow without starting a single process. Consequently, testing each "sub-process" becomes like a unit test.

RE: Decision Node

Stefan Helzle — Mon, 29 Jun 2020 18:44:36 GMT

I understand. We just built an application where dynamic routing is based on a 3 parameters routing configuration maintained in a db table. We use a separated script task as well. Makes testing a real challenge.

RE: Decision Node

bryant.st39 — Mon, 29 Jun 2020 15:31:26 GMT

We do use this for process dispatching. We typically put it in a script task before the "Start Process" node to help with debugging. We've found this design pattern useful for quickly building out processes with many different re-routing requirements or complex rules for determining which path to take.

RE: Decision Node

Stefan Helzle — Mon, 29 Jun 2020 14:05:40 GMT

OK. This looks like very generic process dispatching. Do you put that into a "Start Process" node? In my experience this makes debugging and issue analysis quite difficult. Are you sure you want to do that?

RE: Decision Node

bryant.st39 — Mon, 29 Jun 2020 13:58:11 GMT

Thanks. That is basically what we are doing....I just wish we could reference process models or constants directly in the "Choice Values" or directly in the table.

RE: Decision Node

Stefan Helzle — Mon, 29 Jun 2020 13:47:39 GMT

You can create a list of constants for comparing decision inputs like this.

RE: Decision Node

bryant.st39 — Mon, 29 Jun 2020 12:24:50 GMT

We have a workaround that will prevent us from "hard coding" process model ids...but it still seems like there should be an easier way.