A critical piece of what makes DMN accessible to business users is its expression language FEEL. FEEL variable names are business-friendly. Because they are simply the labels of the shapes in the Decision Requirements Diagram (DRD), FEEL names may contain spaces and other punctuation not allowed by other expression languages. OK, you already know this. But when you publish a DMN model as a collection of executable decision services, a non-DMN client can't invoke it using FEEL.
BPMN's advocates - myself included - like to proclaim that the language allows non-programmers to define executable processes themselves. But that's only one-third true. Yes, in BPMN 2.0 the executable process steps through the shapes of the diagram as drawn by the modeler. That in itself was a monumental achievement a decade ago. "What you model is what you execute," we liked to say. But it left out two key ingredients that still required programming.
It's now 10 years since finalization of BPMN 2.0, the acknowledged standard business process description language. BPMN has been widely adopted, by tool vendors and end users alike, but there are still some folks just discovering it for the first time. Because of BPMN's outward similarity to traditional swimlane flowcharts, many of those users think they understand BPMN but are making some fundamental mistakes. This month's post attempts to set things straight by explaining the basic concepts of BPMN.
They used to say Seinfeld was a show about Nothing. But given its enduring influence on popular culture, Nothing is clearly not nothing. Attention must be paid. In DMN, as well, Nothing demands attention. In simple models like the ones we study in my DMN Method and Style Basics and Advanced training, it doesn't come up. But in many real-world decision models, Nothing pops up all over the place, often unexpectedly.
By:
Bruce Silver
September 23, 2020
dmn
Read More
One of the basic principles of DMN is that decision services are stateless, meaning that given the same set of input data values, the service output will always be the same. But sometimes it is convenient to break that rule with tool-specific extensions. For example, in Trisotech Decision Modeler the FEEL built-in functions Today and Now, which return the current date and date/time, respectively, break the rule. If you wanted to strictly comply with DMN you would need to define those as input data and, if necessary, look up the values before executing the DMN service.
Last time I talked about how information is passed to a BPMN process from outside. All modelers need to understand that. This month I'm going to talk about data inside a BPMN process. If you are a typical process modeler, this is something you can usually safely ignore, because it pertains only to executable models. But recently it came up in a question from a former student, and I see there was also some recent discussion of it on LinkedIn, where my name was invoked.
One aspect of BPMN that usually surprises newbies is attention to what entities or actors are inside the process vs outside. In traditional flowcharting, for example, the Customer is often represented as a swimlane in the Seller's process, but not so in BPMN. A BPMN process represents one participant's view of the steps, that of the process automation engine... no matter that few BPMN models are intended for automation. The Seller typically has no knowledge of the Customer's process.
Last month I provided a brief overview of the Case Management Model and Notation (CMMN) standard. As it does for BPMN, Method and Style provides CMMN with additional diagrammatic conventions aimed at making the logic understandable from the printed diagrams alone. These conventions are formulated as "style rules" that can be applied as validation in a CMMN tool, such as Trisotech Case Modeler. As described in that post, CMMN's event-condition-action (ECA) style defines through declarative logic flexible patterns of case behavior that can be fully automated on a CMMN engine.
They said it would never happen, but it has. CMMN Method and Style is now available. Here are the Table of Contents and Preface. Table of Contents Preface. v Method and Style. vi BPMN Method and Style. vi CMMN Method and Style. vii Structure of the Book. vii Acknowledgments ix 1. What Is CMMN?. 1 What Is Case Management?. 1 Applications of Case Management. 2 Evolution of Case Management. 3 CMMN Overview.
Case Management Model and Notation (CMMN) is the poor stepchild of process modeling standards. It was developed a decade ago, around the same time as BPMN 2.0 and largely as a reaction to it by vendors who believed that "real" business processes were about knowledge workers interpreting documents, not web services orchestration following rigid rules. In case management, the order of actions typically cannot be precisely defined at design time, and many different things happen concurrently.
