DMCommunity.org announced its Challenge “Rebooking Passengers from Cancelled Flights” in Oct-2016 and until now 4 different solutions have been submitted. It is a relatively complex use case for decision modeling. In this post I will describe different implementation approaches for this challenge and will discuss good and not so good DMN constructs used to support the underlying decisioning logic. I hope this post will initiate more discussions which may lead to the future DMN improvements by replacing the existing programming constructs to more business-friendly representations.

Here is the “business” problem:

A flight was cancelled and we need to re-book passengers to other flights considering their frequent flyer status, miles, and seat availability. How the re-booking logic can be formulated by a subject matter expert?

Probably using plain English similar to this one:

“First, order all passengers using their GOLD, SILVER or BRONZE status. If two passengers have the same status use miles as a tiebreaker. Then, choose the first passenger from the sorted list and try to find a suitable flight for this passenger. A “suitable” flight should have the same departure and arrival airports as the cancelled flight and it also should still have an available seat. If there are two suitable flights, choose the one with an earlier departure time. Do the same for the second passenger from the sorted list, then for the third passenger, etc.“

While it is sounds like a quite clear description of the “business logic”,  its representation as an executable decision model is not a simple task. Really, you need to sort lists of passengers and flights,  use tiebreakers, iterate through passenger and flight lists while controlling seat availability. No wonder that well-known DMN experts selected this challenge to demonstrate the most complex DMN constructs. Please take a closer look at the complete, working solutions provided by Bruce Silver and Edson Tirelli. Here I will reproduce only a fragment from Bruce’s DMN-based solution:

Edson’s solution is using similar logic and DMN constructs but looks somewhat different:

Whether you like these solutions or not, the important fact is that they both work and produce correct results. Being an experienced software developer myself, I can appreciate how they use typical programming constructs such as:

• if-then-else statements and for-loops
• functions with formal parameters
• filters
• dynamically built lists
• elegant sorting facilities and
• even a hidden recursion.

At the same time, I have to admit that it took me several reads to understand how these DMN FEEL Level 3 constructions might work. Probably most of us would not even dare to show these “not so business friendly” DMN examples to potential business users unless someone wants to discredit the young standard. But what do software developers think about them?

For example, one of OpenRules developers was very upset with both these solutions. I told him: “It is easy to criticize someone’s solution, but your critique should be constructive. Could you offer a better solution in OpenRules?” Instead, he quickly submitted his pure Java solution to the DMCommunity Challenge. I had to admit that it did look simpler to compare with above DMN-based solutions. The business rules approach always has to fight against pure Java solutions, and in this case my defense of the DMN-based solutions sounded like this:

“At the very least you don’t want to hard-code in Java such business logic as comparison of passengers. Look how nicely Edson presented the comparison logic in this decision table:

If a customer decides to add more comparison criteria like ‘US Veteran’ or ‘Passenger traveling with a child’, one can naturally extend this decision table but multiple embedded IF-THEN-ELSE statements in your Java code would look ugly.”

He responded: “In this case keep the passenger comparison logic in a decision table but use basic Java instead of this strange programming language to represent above algorithms.”

So, I decided to try my own implementation of this Challenge. Finally, last week I found time to do it using our latest OpenRules DMN-implementation. I started with a pure passengers sorting decision model and then I expanded it to the complete flight re-booking decision model.

My challenge was to avoid using complex DMN programming constructs while trying to stay as close as possible to the commonly used DMN decision tables.

I would not say that I am satisfied with what I managed to do so far. However, I decided to share my current implementation with the readers and let them decide if I am at least moving in the right direction.  So, be patient and follow my explanations below.

============ OpenRules-based Implementation  =============

DRD

My objective was to build a decision model called “DecisionFlightRebooking” which on the top-level can be described using the following Decision Requirement Diagram (DRD):

Java Classes

To deal with this problem, we will need two arrays Passengers and Flights, which I decided to present in the Java class Problem:

I also added two Java beans Passenger and Flight that extend the standard OpenRules class ComparableDecisionVariable: 

public class Passenger extends ComparableDecisionVariable {
    String name;
    String status;
    int miles;
    // Getters and Setters
}

public class Flight extends ComparableDecisionVariable {
    String number;
    String from;
    String to;
    Date departureTime;
    Date arrivaTime;
    int capacity;
    String status;
    boolean suitable; // for a particular passenger
    int flightScore;
    // Getters and Setters
}

High-Level Decision

On the very high level we can define the decision table “DetermineFlightRebooking” the unconditionally execute two actions:

The first action will sort all passengers and the second action will iterate over already sorted passengers and rebook them one by one.

Sorting Passengers

The ActionSort will use the following passenger comparison decision table “ComparePassengers” (that it is very similar to the Edson’s decision table above):

This table will be used to compare any two passengers: a passenger with the higher score has a preference during sorting. Here the elements of the array “Passengers” have type “Passenger”.

Rebooking One Passenger

The second action of the high-level decision table “DetermineFlightRebooking” will iterate over already sorted array of “Passengers” and rebook them one by one by executing the rules “RebookOnePassenger”.  In plain English it should do the following for each considered passenger:

1. Evaluate all flights by marking them as suitable or not for this passenger
2. Sort all flights for this passenger
3. Select the very first flight from the sorted list of flights
4. If it is suitable, assign it as a new flight to the considered passenger and decrement the remaining capacity of this flight. If it is not suitable, this passenger cannot be re-booked (a new flight is “?”).

This logic can be represented in the following decision table:

The first action iterates over the array “Passenger Flights” applying to each flight the following rules:

The second action sorts “Passenger Flights” by every two flights using the following decision table:

This table uses comparison operators such as “< time” to compare Flight 1 Arrival with Flight 2 Arrival. Here we added the word “time” to the operators because by default the operators “<“, “>”, and “=” compare dates without considering time, but in this particular case arrival time is also important.

After flights are sorted, the very first flight is the one, which we want to assign to the current passenger. So, the third action iterates over the array “Passenger Flights” applying to each flight the following rules:

Only the first flight will be assigned (of course if it is suitable) and Flight Capacity for this flight will be decremented by removing an assigned seat.

Glossary

To make it all work, I needed to add more business concepts and decision variables to the table Glossary:

When I ran this decision model, I received the expected results:

==== Rebooked Passengers
Passenger [name=Jenny, status=GOLD, miles=500000, flight=UA123] - rebooked to UA456
Passenger [name=Harry, status=GOLD, miles=100000, flight=UA123] - rebooked to UA456
Passenger [name=Igor, status=GOLD, miles=50000, flight=UA123] - rebooked to UA789
Passenger [name=Dick, status=SILVER, miles=100, flight=UA123] - rebooked to UA789
Passenger [name=Tom, status=BRONZE, miles=10, flight=UA123] - rebooked to ?

Conclusion. I believe that the described implementation demonstrates that it is possible to implement even quite complex decision logic using the basic DMN-like decision tables and to avoid complex programming constructs currently included in the DMN FEEL. Hopefully, future DMN releases will find better solutions while avoiding programming.