Designing a decision service using DMN models

The DMN specification defines three incremental levels of conformance in a software implementation. A product that claims compliance at one level must also be compliant with any preceding levels. For example, a conformance level 3 implementation must also include the supported components in conformance levels 1 and 2. For the formal definitions of each conformance level, see the OMG Decision Model and Notation specification.

The following are summaries of the three DMN conformance levels:

Red Hat Decision Manager provides design and runtime support for DMN 1.2 models at conformance level 3, and runtime-only support for DMN 1.1 models at conformance level 3. You can design your DMN models directly in Business Central or import existing DMN models into your Red Hat Decision Manager projects for deployment and execution. Any DMN 1.1 models that you import into Business Central, open in the DMN designer, and save are converted to DMN 1.2 models.

A decision requirements diagram (DRD) is a visual representation of your DMN model. This diagram consists of one or more decision requirements graphs (DRGs) that represent a particular domain of an overall DRD. The DRGs trace business decisions using decision nodes, business knowledge models, sources of business knowledge, input data, and decision services.

The following table summarizes the components in a DRD:

Table 1.1. DRD components

Component		Description	Notation
Elements	Decision	Node where one or more input elements determine an output based on defined decision logic.
	Business knowledge model	Reusable function with one or more decision elements. Decisions that have the same logic but depend on different sub-input data or sub-decisions use business knowledge models to determine which procedure to follow.
	Knowledge source	External authorities, documents, committees, or policies that regulate a decision or business knowledge model. Knowledge sources are references to real-world factors rather than executable business rules.
	Input data	Information used in a decision node or a business knowledge model. Input data usually includes business-level concepts or objects relevant to the business, such as loan applicant data used in a lending strategy.
	Decision service	Top-level decision containing a set of reusable decisions published as a service for invocation. A decision service can be invoked from an external application or a BPMN business process.
Requirement connectors	Information requirement	Connection from an input data node or decision node to another decision node that requires the information.
	Knowledge requirement	Connection from a business knowledge model to a decision node or to another business knowledge model that invokes the decision logic.
	Authority requirement	Connection from an input data node or a decision node to a dependent knowledge source or from a knowledge source to a decision node, business knowledge model, or another knowledge source.
Artifacts	Text annotation	Explanatory note associated with an input data node, decision node, business knowledge model, or knowledge source.
	Association	Connection from an input data node, decision node, business knowledge model, or knowledge source to a text annotation.

The following table summarizes the permitted connectors between DRD elements:

Table 1.2. DRD connector rules

Starts from	Connects to	Connection type	Example
Decision	Decision	Information requirement
Business knowledge model	Decision	Knowledge requirement
	Business knowledge model
Decision service	Decision	Knowledge requirement
	Business knowledge model
Input data	Decision	Information requirement
	Knowledge source	Authority requirement
Knowledge source	Decision	Authority requirement
	Business knowledge model
	Knowledge source
Decision	Text annotation	Association
Business knowledge model
Knowledge source
Input data

The following example DRD illustrates some of these DMN components in practice:

Figure 1.1. Example DRD: Loan prequalification

The following example DRD illustrates DMN components that are part of a reusable decision service:

Figure 1.2. Example DRD: Phone call handling as a decision service

In a DMN decision service node, the decision nodes in the bottom segment incorporate input data from outside of the decision service to arrive at a final decision in the top segment of the decision service node. The resulting top-level decisions from the decision service are then implemented in any subsequent decisions or business knowledge requirements of the DMN model. You can reuse DMN decision services in other DMN models to apply the same decision logic with different input data and different outgoing connections.

Friendly Enough Expression Language (FEEL) is an expression language defined by the Object Management Group (OMG) DMN specification. FEEL expressions define the logic of a decision in a DMN model. FEEL is designed to facilitate both decision modeling and execution by assigning semantics to the decision model constructs. FEEL expressions in decision requirements diagrams (DRDs) occupy table cells in boxed expressions for decision nodes and business knowledge models.

For more information about FEEL in DMN, see the OMG Decision Model and Notation specification.

Boxed expressions in DMN are tables that you use to define the underlying logic of decision nodes and business knowledge models in a decision requirements diagram (DRD) or decision requirements graph (DRG). Some boxed expressions can contain other boxed expressions, but the top-level boxed expression corresponds to the decision logic of a single DRD artifact. While DRDs with one or more DRGs represent the flow of a DMN decision model, boxed expressions define the actual decision logic of individual nodes. DRDs and boxed expressions together form a complete and functional DMN decision model.

The following are the types of DMN boxed expressions:

All Friendly Enough Expression Language (FEEL) expressions that you use in your boxed expressions must conform to the FEEL syntax requirements in the OMG Decision Model and Notation specification.

1.4.1. DMN decision tables

A decision table in DMN is a visual representation of one or more business rules in a tabular format. You use decision tables to define rules for a decision node that applies those rules at a given point in the decision model. Each rule consists of a single row in the table, and includes columns that define the conditions (input) and outcome (output) for that particular row. The definition of each row is precise enough to derive the outcome using the values of the conditions. Input and output values can be FEEL expressions or defined data type values.

For example, the following decision table determines credit score ratings based on a defined range of a loan applicant’s credit score:

Figure 1.3. Decision table for credit score rating

The following decision table determines the next step in a lending strategy for applicants depending on applicant loan eligibility and the bureau call type:

Figure 1.4. Decision table for lending strategy

The following decision table determines applicant qualification for a loan as the concluding decision node in a loan prequalification decision model:

Figure 1.5. Decision table for loan prequalification

Decision tables are a popular way of modeling rules and decision logic, and are used in many methodologies (such as DMN) and implementation frameworks (such as Drools).

Important

Red Hat Decision Manager supports both DMN decision tables and Drools-native decision tables, but they are different types of assets with different syntax requirements and are not interchangeable. For more information about Drools-native decision tables in Red Hat Decision Manager, see Designing a decision service using spreadsheet decision tables.

1.4.1.1. Hit policies in DMN decision tables

Hit policies determine how to reach an outcome when multiple rules in a decision table match the provided input values. For example, if one rule in a decision table applies a sales discount to military personnel and another rule applies a discount to students, then when a customer is both a student and in the military, the decision table hit policy must indicate whether to apply one discount or the other (Unique, First) or both discounts (Collect Sum). You specify the single character of the hit policy (U, F, C+) in the upper-left corner of the decision table.

The following are supported DMN decision table hit policies:

• Unique (U): Permits only one rule to match. Any overlap raises an error.
• Any (A): Permits multiple rules to match, but they must all have the same output. If multiple matching rules do not have the same output, an error is raised.
• Priority (P): Permits multiple rules to match, with different outputs. The output that comes first in the output values list is selected.
• First (F): Uses the first match in rule order.

• Collect (C+, C>, C<, C#): Aggregates output from multiple rules based on an aggregation function.

  • Collect ( C ): Aggregates values in an arbitrary list.
  • Collect Sum (C+): Outputs the sum of all collected values. Values must be numeric.
  • Collect Min (C<): Outputs the minimum value among the matches. The resulting values must be comparable, such as numbers, dates, or text (lexicographic order).
  • Collect Max (C>): Outputs the maximum value among the matches. The resulting values must be comparable, such as numbers, dates or text (lexicographic order).
  • Collect Count (C#): Outputs the number of matching rules.

1.4.2. Boxed literal expressions

A boxed literal expression in DMN is a literal FEEL expression as text in a table cell, typically with a labeled column and an assigned data type. You use boxed literal expressions to define simple or complex node logic or decision data directly in FEEL for a particular node in a decision. Literal FEEL expressions must conform to FEEL syntax requirements in the OMG Decision Model and Notation specification.

For example, the following boxed literal expression defines the minimum acceptable PITI calculation (principal, interest, taxes, and insurance) in a lending decision, where acceptable rate is a variable defined in the DMN model:

Figure 1.6. Boxed literal expression for minimum PITI value

The following boxed literal expression sorts a list of possible dating candidates (soul mates) in an online dating application based on their score on criteria such as age, location, and interests:

Figure 1.7. Boxed literal expression for matching online dating candidates

1.4.3. Boxed context expressions

A boxed context expression in DMN is a set of variable names and values with a result value. Each name-value pair is a context entry. You use context expressions to represent data definitions in decision logic and set a value for a desired decision element within the DMN decision model. A value in a boxed context expression can be a data type value or FEEL expression, or can contain a nested sub-expression of any type, such as a decision table, a literal expression, or another context expression.

For example, the following boxed context expression defines the factors for sorting delayed passengers in a flight-rebooking decision model, based on defined data types (tPassengerTable, tFlightNumberList):

Figure 1.8. Boxed context expression for flight passenger waiting list

The following boxed context expression defines the factors that determine whether a loan applicant can meet minimum mortgage payments based on principal, interest, taxes, and insurance (PITI), represented as a front-end ratio calculation with a sub-context expression:

Figure 1.9. Boxed context expression for front-end client PITI ratio

1.4.4. Boxed relation expressions

A boxed relation expression in DMN is a traditional data table with information about given entities, listed as rows. You use boxed relation tables to define decision data for relevant entities in a decision at a particular node. Boxed relation expressions are similar to context expressions in that they set variable names and values, but relation expressions contain no result value and list all variable values based on a single defined variable in each column.

For example, the following boxed relation expression provides information about employees in an employee rostering decision:

Figure 1.10. Boxed relation expression with employee information

1.4.5. Boxed function expressions

A boxed function expression in DMN is a parameterized boxed expression containing a literal FEEL expression, a nested context expression of an external JAVA or PMML function, or a nested boxed expression of any type. By default, all business knowledge models are defined as boxed function expressions. You use boxed function expressions to call functions on your decision logic and to define all business knowledge models.

For example, the following boxed function expression determines airline flight capacity in a flight-rebooking decision model:

Figure 1.11. Boxed function expression for flight capacity

The following boxed function expression contains a basic Java function as a context expression for determining absolute value in a decision model calculation:

Figure 1.12. Boxed function expression for absolute value

The following boxed function expression determines a monthly mortgage installment as a business knowledge model in a lending decision, with the function value defined as a nested context expression:

Figure 1.13. Boxed function expression for installment calculation in business knowledge model

1.4.6. Boxed invocation expressions

A boxed invocation expression in DMN is a boxed expression that invokes a business knowledge model. A boxed invocation expression contains the name of the business knowledge model to be invoked and a list of parameter bindings. Each binding is represented by two boxed expressions on a row: The box on the left contains the name of a parameter and the box on the right contains the binding expression whose value is assigned to the parameter to evaluate the invoked business knowledge model. You use boxed invocations to invoke at a particular decision node a business knowledge model defined in the decision model.

For example, the following boxed invocation expression invokes a reassign next passenger business knowledge model as the concluding decision node in a flight-rebooking decision model:

Figure 1.14. Boxed invocation expression to reassign flight passengers

The following boxed invocation expression invokes an InstallmentCalculation business knowledge model to calculate a monthly installment amount for a loan before proceeding to affordability decisions:

Figure 1.15. Boxed invocation expression for required monthly installment

The following is a real-world DMN model example that demonstrates how you can use decision modeling to reach a decision based on input data, circumstances, and company guidelines. In this scenario, a flight from San Diego to New York is canceled, requiring the affected airline to find alternate arrangements for its inconvenienced passengers.

First, the airline collects the information necessary to determine how best to get the travelers to their destinations:

The airline then uses the DMN standard to model its decision process in the following decision requirements diagram (DRD) for determining the best rebooking solution:

Figure 1.16. DRD for flight rebooking

Similar to flowcharts, DRDs use shapes to represent the different elements in a process. Ovals contain the two necessary input data, rectangles contain the decision points in the model, and rectangles with clipped corners (business knowledge models) contain reusable logic that can be repeatedly invoked.

The DRD draws logic for each element from boxed expressions that provide variable definitions using FEEL expressions or data type values.

Some boxed expressions are basic, such as the following decision for establishing a prioritized waiting list:

Figure 1.17. Boxed context expression example for prioritized wait list

Some boxed expressions are more complex with greater detail and calculation, such as the following business knowledge model for reassigning the next delayed passenger:

Figure 1.18. Boxed function expression for passenger reassignment

The following is the DMN source file for this decision model:

<definitions xmlns="http://www.omg.org/spec/DMN/20151101/dmn.xsd" xmlns:kie="https://www.drools.org/kie-dmn" xmlns:feel="http://www.omg.org/spec/FEEL/20140401" id="_0019_flight_rebooking" name="0019-flight-rebooking" namespace="https://www.drools.org/kie-dmn">
  <itemDefinition id="_tFlight" name="tFlight">
    <itemComponent id="_tFlight_Flight" name="Flight Number">
      <typeRef>feel:string</typeRef>
    </itemComponent>
    <itemComponent id="_tFlight_From" name="From">
      <typeRef>feel:string</typeRef>
    </itemComponent>
    <itemComponent id="_tFlight_To" name="To">
      <typeRef>feel:string</typeRef>
    </itemComponent>
    <itemComponent id="_tFlight_Dep" name="Departure">
      <typeRef>feel:dateTime</typeRef>
    </itemComponent>
    <itemComponent id="_tFlight_Arr" name="Arrival">
      <typeRef>feel:dateTime</typeRef>
    </itemComponent>
    <itemComponent id="_tFlight_Capacity" name="Capacity">
      <typeRef>feel:number</typeRef>
    </itemComponent>
    <itemComponent id="_tFlight_Status" name="Status">
      <typeRef>feel:string</typeRef>
    </itemComponent>
  </itemDefinition>
  <itemDefinition id="_tFlightTable" isCollection="true" name="tFlightTable">
    <typeRef>kie:tFlight</typeRef>
  </itemDefinition>
  <itemDefinition id="_tPassenger" name="tPassenger">
    <itemComponent id="_tPassenger_Name" name="Name">
      <typeRef>feel:string</typeRef>
    </itemComponent>
    <itemComponent id="_tPassenger_Status" name="Status">
      <typeRef>feel:string</typeRef>
    </itemComponent>
    <itemComponent id="_tPassenger_Miles" name="Miles">
      <typeRef>feel:number</typeRef>
    </itemComponent>
    <itemComponent id="_tPassenger_Flight" name="Flight Number">
      <typeRef>feel:string</typeRef>
    </itemComponent>
  </itemDefinition>
  <itemDefinition id="_tPassengerTable" isCollection="true" name="tPassengerTable">
    <typeRef>kie:tPassenger</typeRef>
  </itemDefinition>
  <itemDefinition id="_tFlightNumberList" isCollection="true" name="tFlightNumberList">
    <typeRef>feel:string</typeRef>
  </itemDefinition>
  <inputData id="i_Flight_List" name="Flight List">
    <variable name="Flight List" typeRef="kie:tFlightTable"/>
  </inputData>
  <inputData id="i_Passenger_List" name="Passenger List">
    <variable name="Passenger List" typeRef="kie:tPassengerTable"/>
  </inputData>
  <decision name="Prioritized Waiting List" id="d_PrioritizedWaitingList">
    <variable name="Prioritized Waiting List" typeRef="kie:tPassengerTable"/>
    <informationRequirement>
      <requiredInput href="#i_Passenger_List"/>
    </informationRequirement>
    <informationRequirement>
      <requiredInput href="#i_Flight_List"/>
    </informationRequirement>
    <knowledgeRequirement>
      <requiredKnowledge href="#b_PassengerPriority"/>
    </knowledgeRequirement>
    <context>
      <contextEntry>
        <variable name="Cancelled Flights" typeRef="kie:tFlightNumberList"/>
        <literalExpression>
          <text>Flight List[ Status = "cancelled" ].Flight Number</text>
        </literalExpression>
      </contextEntry>
      <contextEntry>
        <variable name="Waiting List" typeRef="kie:tPassengerTable"/>
        <literalExpression>
          <text>Passenger List[ list contains( Cancelled Flights, Flight Number ) ]</text>
        </literalExpression>
      </contextEntry>
      <contextEntry>
        <literalExpression>
          <text>sort( Waiting List, passenger priority )</text>
        </literalExpression>
      </contextEntry>
    </context>
  </decision>
  <decision name="Rebooked Passengers" id="d_RebookedPassengers">
    <variable name="Rebooked Passengers" typeRef="kie:tPassengerTable"/>
    <informationRequirement>
      <requiredDecision href="#d_PrioritizedWaitingList"/>
    </informationRequirement>
    <informationRequirement>
      <requiredInput href="#i_Flight_List"/>
    </informationRequirement>
    <knowledgeRequirement>
      <requiredKnowledge href="#b_ReassignNextPassenger"/>
    </knowledgeRequirement>
    <invocation>
      <literalExpression>
        <text>reassign next passenger</text>
      </literalExpression>
      <binding>
        <parameter name="Waiting List"/>
        <literalExpression>
          <text>Prioritized Waiting List</text>
        </literalExpression>
      </binding>
      <binding>
        <parameter name="Reassigned Passengers List"/>
        <literalExpression>
          <text>[]</text>
        </literalExpression>
      </binding>
      <binding>
        <parameter name="Flights"/>
        <literalExpression>
          <text>Flight List</text>
        </literalExpression>
      </binding>
    </invocation>
  </decision>
  <businessKnowledgeModel id="b_PassengerPriority" name="passenger priority">
    <encapsulatedLogic>
      <formalParameter name="Passenger1" typeRef="kie:tPassenger"/>
      <formalParameter name="Passenger2" typeRef="kie:tPassenger"/>
      <decisionTable hitPolicy="UNIQUE">
        <input id="b_Passenger_Priority_dt_i_P1_Status" label="Passenger1.Status">
          <inputExpression typeRef="feel:string">
            <text>Passenger1.Status</text>
          </inputExpression>
          <inputValues>
            <text>"gold", "silver", "bronze"</text>
          </inputValues>
        </input>
        <input id="b_Passenger_Priority_dt_i_P2_Status" label="Passenger2.Status">
          <inputExpression typeRef="feel:string">
            <text>Passenger2.Status</text>
          </inputExpression>
          <inputValues>
            <text>"gold", "silver", "bronze"</text>
          </inputValues>
        </input>
        <input id="b_Passenger_Priority_dt_i_P1_Miles" label="Passenger1.Miles">
          <inputExpression typeRef="feel:string">
            <text>Passenger1.Miles</text>
          </inputExpression>
        </input>
        <output id="b_Status_Priority_dt_o" label="Passenger1 has priority">
          <outputValues>
            <text>true, false</text>
          </outputValues>
          <defaultOutputEntry>
            <text>false</text>
          </defaultOutputEntry>
        </output>
        <rule id="b_Passenger_Priority_dt_r1">
          <inputEntry id="b_Passenger_Priority_dt_r1_i1">
            <text>"gold"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r1_i2">
            <text>"gold"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r1_i3">
            <text>>= Passenger2.Miles</text>
          </inputEntry>
          <outputEntry id="b_Passenger_Priority_dt_r1_o1">
            <text>true</text>
          </outputEntry>
        </rule>
        <rule id="b_Passenger_Priority_dt_r2">
          <inputEntry id="b_Passenger_Priority_dt_r2_i1">
            <text>"gold"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r2_i2">
            <text>"silver","bronze"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r2_i3">
            <text>-</text>
          </inputEntry>
          <outputEntry id="b_Passenger_Priority_dt_r2_o1">
            <text>true</text>
          </outputEntry>
        </rule>
        <rule id="b_Passenger_Priority_dt_r3">
          <inputEntry id="b_Passenger_Priority_dt_r3_i1">
            <text>"silver"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r3_i2">
            <text>"silver"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r3_i3">
            <text>>= Passenger2.Miles</text>
          </inputEntry>
          <outputEntry id="b_Passenger_Priority_dt_r3_o1">
            <text>true</text>
          </outputEntry>
        </rule>
        <rule id="b_Passenger_Priority_dt_r4">
          <inputEntry id="b_Passenger_Priority_dt_r4_i1">
            <text>"silver"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r4_i2">
            <text>"bronze"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r4_i3">
            <text>-</text>
          </inputEntry>
          <outputEntry id="b_Passenger_Priority_dt_r4_o1">
            <text>true</text>
          </outputEntry>
        </rule>
        <rule id="b_Passenger_Priority_dt_r5">
          <inputEntry id="b_Passenger_Priority_dt_r5_i1">
            <text>"bronze"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r5_i2">
            <text>"bronze"</text>
          </inputEntry>
          <inputEntry id="b_Passenger_Priority_dt_r5_i3">
            <text>>= Passenger2.Miles</text>
          </inputEntry>
          <outputEntry id="b_Passenger_Priority_dt_r5_o1">
            <text>true</text>
          </outputEntry>
        </rule>
      </decisionTable>
    </encapsulatedLogic>
    <variable name="passenger priority" typeRef="feel:boolean"/>
  </businessKnowledgeModel>
  <businessKnowledgeModel id="b_ReassignNextPassenger" name="reassign next passenger">
    <encapsulatedLogic>
      <formalParameter name="Waiting List" typeRef="kie:tPassengerTable"/>
      <formalParameter name="Reassigned Passengers List" typeRef="kie:tPassengerTable"/>
      <formalParameter name="Flights" typeRef="kie:tFlightTable"/>
      <context>
        <contextEntry>
          <variable name="Next Passenger" typeRef="kie:tPassenger"/>
          <literalExpression>
            <text>Waiting List[1]</text>
          </literalExpression>
        </contextEntry>
        <contextEntry>
          <variable name="Original Flight" typeRef="kie:tFlight"/>
          <literalExpression>
            <text>Flights[ Flight Number = Next Passenger.Flight Number ][1]</text>
          </literalExpression>
        </contextEntry>
        <contextEntry>
          <variable name="Best Alternate Flight" typeRef="kie:tFlight"/>
          <literalExpression>
            <text>Flights[ From = Original Flight.From and To = Original Flight.To and Departure > Original Flight.Departure and Status = "scheduled" and has capacity( item, Reassigned Passengers List ) ][1]</text>
          </literalExpression>
        </contextEntry>
        <contextEntry>
          <variable name="Reassigned Passenger" typeRef="kie:tPassenger"/>
          <context>
            <contextEntry>
              <variable name="Name" typeRef="feel:string"/>
              <literalExpression>
                <text>Next Passenger.Name</text>
              </literalExpression>
            </contextEntry>
            <contextEntry>
              <variable name="Status" typeRef="feel:string"/>
              <literalExpression>
                <text>Next Passenger.Status</text>
              </literalExpression>
            </contextEntry>
            <contextEntry>
              <variable name="Miles" typeRef="feel:number"/>
              <literalExpression>
                <text>Next Passenger.Miles</text>
              </literalExpression>
            </contextEntry>
            <contextEntry>
              <variable name="Flight Number" typeRef="feel:string"/>
              <literalExpression>
                <text>Best Alternate Flight.Flight Number</text>
              </literalExpression>
            </contextEntry>
          </context>
        </contextEntry>
        <contextEntry>
          <variable name="Remaining Waiting List" typeRef="kie:tPassengerTable"/>
          <literalExpression>
            <text>remove( Waiting List, 1 )</text>
          </literalExpression>
        </contextEntry>
        <contextEntry>
          <variable name="Updated Reassigned Passengers List" typeRef="kie:tPassengerTable"/>
          <literalExpression>
            <text>append( Reassigned Passengers List, Reassigned Passenger )</text>
          </literalExpression>
        </contextEntry>
        <contextEntry>
          <literalExpression>
            <text>if count( Remaining Waiting List ) > 0 then reassign next passenger( Remaining Waiting List, Updated Reassigned Passengers List, Flights ) else Updated Reassigned Passengers List</text>
          </literalExpression>
        </contextEntry>
      </context>
    </encapsulatedLogic>
    <variable name="reassign next passenger" typeRef="kie:tPassengerTable"/>
    <knowledgeRequirement>
      <requiredKnowledge href="#b_HasCapacity"/>
    </knowledgeRequirement>
  </businessKnowledgeModel>
  <businessKnowledgeModel id="b_HasCapacity" name="has capacity">
    <encapsulatedLogic>
      <formalParameter name="flight" typeRef="kie:tFlight"/>
      <formalParameter name="rebooked list" typeRef="kie:tPassengerTable"/>
      <literalExpression>
        <text>flight.Capacity > count( rebooked list[ Flight Number = flight.Flight Number ] )</text>
      </literalExpression>
    </encapsulatedLogic>
    <variable name="has capacity" typeRef="feel:boolean"/>
  </businessKnowledgeModel>
</definitions>

Red Hat Decision Manager provides the following DMN properties that you can configure when you execute your DMN models on Decision Server or on your client application:

Boxed expressions in DMN are tables that you use to define the underlying logic of decision nodes and business knowledge models in a decision requirements diagram (DRD) or decision requirements graph (DRG). Some boxed expressions can contain other boxed expressions, but the top-level boxed expression corresponds to the decision logic of a single DRD artifact. While DRDs with one or more DRGs represent the flow of a DMN decision model, boxed expressions define the actual decision logic of individual nodes. DRDs and boxed expressions together form a complete and functional DMN decision model.

You can use the DMN designer in Business Central to define decision logic for your DRD components using built-in boxed expressions.

For boxed expression types other than decision tables, you follow these guidelines similarly to navigate the boxed expression tables and define variables and parameters for decision logic, but according to the requirements of the boxed expression type. Some boxed expressions, such as boxed literal expressions, can be single-column tables, while other boxed expressions, such as function, context, and invocation expressions, can be multi-column tables with nested boxed expressions of other types.

For example, the following boxed context expression defines the parameters that determine whether a loan applicant can meet minimum mortgage payments based on principal, interest, taxes, and insurance (PITI), represented as a front-end ratio calculation with a sub-context expression:

Figure 3.12. Boxed context expression for front-end client PITI ratio

The following boxed function expression determines a monthly mortgage installment as a business knowledge model in a lending decision, with the function value defined as a nested context expression:

Figure 3.13. Boxed function expression for installment calculation in business knowledge model

For more information and examples of each boxed expression type, see Section 1.4, “DMN decision logic in boxed expressions”.

In DMN boxed expressions in Business Central, data types determine the structure of the data that you use within an associated table, column, or field in the boxed expression. You can use default DMN data types (such as String, Number, Boolean) or you can create custom data types to specify additional fields and constraints that you want to implement for the boxed expression values.

Custom data types that you create for a boxed expression can be simple or structured:

For boxed expression types other than decision tables, you follow these guidelines similarly to navigate the boxed expression tables and define custom data types as needed.

For example, the following boxed function expression uses custom tCandidate and tProfile structured data types to associate data for online dating compatibility:

Figure 3.16. Boxed function expression for online dating compatibility

Figure 3.17. Custom data type definitions for online dating compatibility

Figure 3.18. Parameter definitions with custom data types for online dating compatibility

The DMN designer provides the following additional features to help you navigate through the components and properties of decision requirements diagrams (DRDs).

A KIE container is local when the knowledge assets are either embedded directly into the calling program or are physically pulled in using Maven dependencies for the KJAR. You typically embed knowledge assets directly into a project if there is a tight relationship between the version of the code and the version of the DMN definition. Any changes to the decision take effect after you have intentionally updated and redeployed the application. A benefit of this approach is that proper operation does not rely on any external dependencies to the run time, which can be a limitation of locked-down environments.

Using Maven dependencies enables further flexibility because the specific version of the decision can dynamically change, (for example, by using a system property), and it can be periodically scanned for updates and automatically updated. This introduces an external dependency on the deploy time of the service, but executes the decision locally, reducing reliance on an external service being available during run time.

The Decision Server Java client API provides a lightweight approach to invoking a remote DMN service either through the REST or JMS interfaces of Decision Server. This approach reduces the number of runtime dependencies necessary to interact with a KIE base. Decoupling the calling code from the decision definition also increases flexibility by enabling them to iterate independently at the appropriate pace.

For more information about the Decision Server Java client API, see Interacting with Red Hat Decision Manager using KIE APIs.

Directly interacting with the REST endpoints of Decision Server provides the most separation between the calling code and the decision logic definition. The calling code is completely free of direct dependencies, and you can implement it in an entirely different development platform such as node.js or .net. The examples in this section demonstrate Nix-style curl commands but provide relevant information to adapt to any REST client.

For more information about the Decision Server REST API, see Interacting with Red Hat Decision Manager using KIE APIs.