Business rules types

A business rule is an action type in FlowX.AI that allows you to configure a script on a BPMN node. It’s a way to specify business logic or decision-making processes in a business process.

The script can read and write the data available on the process at the moment the script is executed. For this reason, it is very important to understand what data is available on the process when the script is executed.

Business rules can be attached to a node by using actions with action rules on them. These can be specified using MVEL expressions, or scripts written in JavaScript, Python, or Groovy.

For more information about supported scripting languages, see the next section:

Supported scripts

You can also test your rules by using the Test Rule function.

Configuration

To use a Business Rules Action, follow these steps:

1. Select a BPMN Task Node: Choose the BPMN task node to which you want to attach the Business Rules Action. This could be a Service Task, User Task, or another task type that supports actions.
2. Define the Action: In the task node properties, configure the “Business Rules Action” field and select the desired language (MVEL, Java, JavaScript or Python).
3. Write the Business Rule: In the selected language, write the business rule or decision logic. This rule should take input data, process it, and possibly generate an output or result.
4. Input and Output Variables: Ensure that the task node can access the necessary input variables from the BPMN process context and store any output or result variables as needed.
5. Execution: When the BPMN process reaches the task node, the attached Business Rules Action is executed, and the defined business rule is evaluated.
6. Result: The result of the business rule execution may affect the flow of the BPMN process, update process variables, or trigger other actions based on the logic defined in the rule.

Script engine per rule

Available starting with FlowX.AI 5.9.1.

Each business rule can run on either the current native script engine (the 5.9 default) or the legacy GraalVM engine, selected per rule. This lets you migrate scripts to native one at a time instead of all at once.

• Rules created before the move to native keep running on GraalVM, and the engine selector is available so you can switch them to native after testing.
• New rules run on native by default; the selector only appears for rules that support GraalVM.
• On platforms configured for native-only execution, the selector is hidden and all rules run on native.

The platform-wide default engine is set separately — see Supported scripts.

Script size and execution limits

JavaScript and Python rules that run on the native script engine are bounded by the worker pool limits of the process engine:

Limit	JavaScript default	Python default	Environment variable
Max input payload size	1048576 bytes (1 MB)	1048576 bytes (1 MB)	APPLICATION_SCRIPTENGINE_NATIVEENGINE_JS_MAXPAYLOADSIZEBYTES / APPLICATION_SCRIPTENGINE_NATIVEENGINE_PYTHON_MAXPAYLOADSIZEBYTES
Execution timeout per script	5000 ms	10000 ms	APPLICATION_SCRIPTENGINE_NATIVEENGINE_JS_EXECUTIONTIMEOUTMS / APPLICATION_SCRIPTENGINE_NATIVEENGINE_PYTHON_EXECUTIONTIMEOUTMS

The input payload includes the process data passed to the script. A large data model can exceed the payload limit even when the script is short. When this happens, the rule fails with an error stating that the request payload exceeds maxPayloadSizeBytes. To fix it, reduce the data passed to the script or ask your platform administrator to raise the limit for the affected language. See Script engine configuration.

Let’s take look at the following example. We have some data about the gender of a user and we need to create a business rule that computes the formal title based on the gender:

1. This is how the process instance data looks like before it reaches the business rule:

   {
       "application" : {
           "client" : 
           {
               "firstName" : "David",
               "surName" : "James",
               "gender" : "M",
               
           }
       }
   }
   

2. When the token reaches this node the following script (defined for the business rule) is executed. The language used here for scripting is MVEL.

if (input.application.client.gender == 'F') {
    output.put("application", {
        "client": {
            "salutation": "Ms"
        }
    });
} else if (input.application.client.gender == 'M') {
    output.put("application", {
        "client": {
            "salutation": "Mr"
        }
    });
} else {
    output.put("application", {
        "client": {
            "salutation": "Mx"
        }
    });
}

3. After the script is executed, the process instance data will look like this:

{
    "application": {
        "client": {
            "firstName": "David",
            "surName": "James",
            "gender": "M",
            "salutation": "Mr"
        }
    }
}

Flattened vs unflattened keys

With version 2.5.0 we introduced unflattened keys inside business rules. Flattened keys are now obsolete. You are notified when you need to delete and recreate a business rule so it contains an unflattened key.

Business rules examples

Examples available for v2.5.0 version and higher

We will use the MVEL example used above to rewrite it in other scripting languages formats:

MVEL

if (input.application.client.gender == 'F') {
        output.put("application", {
            "client": {
                "salutation": "Ms"
            }
         });
    } else if (input.application.client.gender == 'M') {
        output.put("application", {
            "client": {
                "salutation": "Mr"
            }
         });
    } else {
        output.put("application", {
            "client": {
                "salutation": "Mx"
            }
        });
    }

Python

    if input.get("application").get("client").get("gender") == "F":
        output.put("application", {
            "client" : {
                "salutation" : "Ms"
            }
        })
    elif input.get("application").get("client").get("gender") == "M":
        output.put("application", {
            "client" : {
                "salutation" : "Mr"
            }
        })
    else:
        output.put("application", {
                "client" : {
                    "salutation" : "Mx"
                }
            })

JS

if (input.application.client.gender === 'F') {
    output.application = {
        client: {
            salutation: 'Ms'
        }
    };
} else if (input.application.client.gender === 'M') {
    output.application = {
        client: {
            salutation: 'Mr'
        }
    };
} else {
    output.application = {
        client: {
            salutation: 'Mx'
        }
    };
}

Groovy

if (input.application.client.gender === 'F') {
def gender = input.application.client.gender
switch (gender) {
    case 'F':
        output.application = [client: [salutation: 'Ms']]
        break
    case 'M':
        output.application = [client: [salutation: 'Mr']]
        break
    default:
        output.application = [client: [salutation: 'Mx']]
}