bpmNEXT 2016 just concluded its fourth event this week in Santa Barbara, and it was even better than ever! One highlight for me was the rapid pace of progress in DMN implementation. Before this event I was beginning to despair that tool vendors would implement only the barest outlines of DMN, nothing that could fulfill the promise of a business-friendly, model-based, executable, tool-independent decision language. Instead I come away energized and excited! As I've written here before, fully implementing DMN includes five things:
- DRD
- Decision tables
- FEEL
- Boxed expressions
- XML serialization
FEEL is DMN's default expression language. It is defined in the DMN spec itself. Tools aren't required to use it, but unless tool vendors get together and pick some other language, say javascript, as their DMN expression language, without FEEL you won't have DMN models that are both tool-independent and executable. So it's a critical piece. The challenge for FEEL is the same as the challenge for any new language: An implementer needs to parse it and map it, including its built-in functions and operators, to some other language for which it has executable libraries. That is hard enough, but FEEL spices up the challenge by allowing spaces in the names of variables and functions. Most languages do not allow this, because it makes the parsing about 10 times more work.
In the form used in decision tables, FEEL is extremely simple, essentially either a literal value, simple comparison, or arithmetic expression. But in its full glory, FEEL can iterate over a list, perform table queries and joins, sort a list of values, perform type-checking, and more. So you don't need to exit DMN and use BPMN for iteration or SQL for querying. DMN expressions can do those things as well. So it's worth the effort to implement it in DMN tools.
FEEL is just an expression language, not a programming language. It is a formula that determines a value. It can reference a variable but it does not create variables or assign a value to a variable. In Excel terms, it is like a formula not a macro. Business users can create formulas; programmers create macros. There is a difference. Of course, to make decision logic executable, you need to have something that acts like the programming language, that creates variables and assigns values (from FEEL expressions) to them. In DMN, that something is defined graphically: It's the DRD, the decision tables, and other so-called boxed expressions. The text in the boxes of DRDs, decision tables, and boxed expressions is what defines the variables and value assignments.
All DMN implementations support decision tables. The boxed expressions that tools have been omitting are invocations and contexts. Invocation means a decision is calling a bit of reusable decision logic called a business knowledge model, or BKM. A lot of decision logic is reusable, so invocation is a necessary element. When a decision invokes a BKM, it has to provide a value to each of the BKM's input parameters. So you need a two-column table: parameter name and value (a FEEL expression). DMN defines the format of this table, a boxed expression.
Contexts allow a decision with complicated decision logic to simplify that logic by defining local variables. Graphically, a context is defined as another two-column table, a boxed expression. Each row in the table, called a context entry, defines a local variable by name and value. The FEEL expression for a context entry value can reference, in addition to the decision's information requirements, the local variables defined by previous context entries.
What makes it a little more complex is the fact that the value column in a context entry, a FEEL expression, can be any DMN expression type, including an invocation (another 2-column table) or even a full decision table. So it is possible to have tables nested inside other tables, and there is no limit to the number of nested levels possible. As a practical matter, tools will undoubtedly put some reasonable limit on this, but it could be a deterrent to implementation.
In order to fully realize the vision of a complete graphical decision language, both FEEL and boxed expressions of invocations and contexts should be considered as fundamental to DMN as DRDs and decision tables.
OK, so FEEL and boxed expressions, both powerful and key to fulfilling DMN's promise, but neither simple to implement. Here is what we saw at bpmNEXT:
- Oracle. Alvin To of Oracle showed a preview of their Decision Modeling Service, a full implementation of FEEL and boxed expressions, including iteration over both order items and cost center approvals per item.
- Trisotech. Denis Gagne of Trisotech showed a preview of their DMN Editor, with a really slick boxed expression layout and test-level execution in their Kommunicator portal. Very very cool!
- Camunda. As demonstrated by Jakob Freund, Camunda's FEEL implementation is just for decision tables, not the full language, but their implementation is open source and it will grow to full FEEL over time.
- WfMC. Keith Swenson of WfMC did not demonstrate an implementation but led a discussion around developing an open source implementation of DMN. There was resistance to an open source implementation of all of DMN but wide support for an implementation of FEEL. This is really exciting, because if tool vendors could realize the benefit of FEEL functionality without having to implement it themselves, they would likely adopt it. There is certainly plenty of room for differentiation among DMN products even if the FEEL libraries are common to all of them.
- Sapiens. Larry Goldberg of Sapiens Decision flashed a glimpse of their upcoming DMN implementation. He didn't focus on FEEL or boxed expressions, but instead showed a powerful tool for mapping the logical data used in decision logic to the physical data stored in databases and business systems, and synchronizing with that data at the point of execution.