Good way to program an orchestration / processflow

Question

I'm programming a process in which clients will be separated in 3 different groups, and for every group a different action will be performed.

My question concerns the process of deciding which client will be in which group.

As input I received a flow diagram with 7 decision blocks.

I think you can imagine the flow chart:

If A and B and Not C and F then you are in group 1.

If A and not B and C and E you are in group B. If A and not B and C and not E but F you also are in group B.

Anyway, you probably get what I mean.

What I'm searching for is what is a good way to implement this?

We've come up with the following solutions

1 program the code like I've typed it:

if A() && !B() && C() || (D() && E()) groupA.Add(client)
if A() && !B() && C() && F()) groupB.Add(client)

2 program a BIG if / if / else

if A()
    if B()

    else
        if ! C()

        else
else
    if C()

    else

etc.

But.... both don't make me happy, so I was wondering if there was a better way of solving this?

Answer 1

There are definitely solutions out there which attempt to model flow charts in a generic way.

Things like windows workflow foundation, SSIS, routing in message queues etc.

But in my experience, unless the requirement comes from a technical source. ie IP routing, fail over dns etc where a technical spec for the form of the logic exists. Its best to make your code match the requirement document as closely to the way it describes the logic as possible

You will have holes in the logic and results that seem inconsistent, but your code will meet the requirement, and when the requirement changes in some weird way, you wont find yourself shoehorning it into a clever generic system which expects the logic to be expressed in a particular way.

This usually boils down to a big if block. but it will be easy to read and easy to change

---

Update: here's ways I've done it/seen it done in the past and regretted it

• OOP approach, persist logic objects in XML doc, data in another, with elements like <addPercentage conditional="xpath refernce to data doc" value="10">

the xpath soon got super complicated with custom expressions, users never bothered to use the interface, so devs get requests to change logic anyway.

• eval vb script stored in db

users cant do vb script, working out how a decision was made, next to impossible.

• eval SQL (because we know that)

users can't do sql either, same probs as with vb script

• websphere java orchestration with wcf services (because the consultants will setup a 'domain language'

users can't do java/'domain language' once the consultants leave. Hire new team of java devs, deployment/source control issues with web based IDE

• lisp interpreter. OMG No.

• windows workflow foundation

out of date even when we used it, over complicated for small tasks. difficult to explain to users

• SSIS/DTS packages because they have a drag and drop interface!

hacky tool for non programming db admins, version control, deployment, debugging, performance difficulties. not scalable.