ODMRules node

Use the ODMRules node to execute a set of business rules. An ODMRules node can be used to execute rulesets that have XML parameters.

This topic contains the following sections:

Purpose
Terminals and properties

Purpose

You can use the ODMRules node in a message flow to execute a set of business rules.

Rulesets define ruleset parameters, which are used to pass data back and forth from the ruleset and the calling application. When executing a ruleset, XPath expressions are used to map parts of the message tree to and from ruleset parameters before and after ruleset execution. You can use the ODMRules node in an application, library, integration service, or REST API.

An ODMRules node executes rules contained in a ruleset using an embedded rule engine. When you deploy a BAR file that contains an appropriately configured ODMRules node, the ruleset is accessed, ready for execution.

You attach an ODM Server policy to an ODMRules node to control how it accesses the ruleset. Depending on the configuration of the ODM Server policy, when the ODMRules node is reached during message flow execution, it either executes a ruleset that is held on a remote Operational Decision Manager Rule Execution Server, or a ruleset archive that was downloaded previously from the ODM Rule Execution Server and stored on the local file system.

The set of rules to be evaluated for messages being processed by the ODMRules node is defined by the Ruleset path property. For information about how to configure this property, see Configuring the ruleset path.

For more information about using ODM business rules with IBM® App Connect Enterprise, see Using Operational Decision Manager (ODM) business rules.

The ODMRules node is contained in the IBM ODM drawer of the palette, and is represented in the IBM App Connect Enterprise Toolkit by the following icon:

Terminals and properties

The ODMRules node terminals are described in the following table.

Terminal	Description
In	The input terminal that accepts a message for processing by the node.
Out	The output terminal to which the message can be routed when processing completes successfully.
Failure	The output terminal to which the message is routed if a failure is detected during processing.

When you put an instance of the ODMRules node into a message flow, you can configure it. For more information, see Configuring a message flow node. The properties of the node are displayed in the Properties view. All mandatory properties for which you must enter a value (those properties that do not have a default value defined) are marked with an asterisk.

The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk on the panel if you must enter a value when no default is defined); the column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).

The ODMRules node Description properties are described in the following table.

Property	M	C	Default	Description
Node name	No	No	The node type, ODMRules	The name of the node.
Short description	No	No		A brief description of the node.
Long description	No	No		Text that describes the purpose of the node in the message flow.

The ODMRules node Basic properties are described in the following table.

Property M C Default Description mqsiapplybaroverride command property

Policy Yes Yes The name of an ODM Server policy, specified in the form {PolicyProject}:policyName. The policy can be used either to access the IBM Operational Decision Manager Rule Execution Server that hosts the ruleset that is to be run by the node, or to access a locally-stored ruleset archive that was previously downloaded from the ODM RES. Use the Browse button to select a policy from existing policy projects in the workspace. policyUrl

Ruleset path

Yes

Property	M	C	Description	mqsiapplybaroverride command property
Policy	Yes	Yes	The name of an ODM Server policy, specified in the form `{PolicyProject}:policyName`. The policy can be used either to access the IBM Operational Decision Manager Rule Execution Server that hosts the ruleset that is to be run by the node, or to access a locally-stored ruleset archive that was previously downloaded from the ODM RES. Use the Browse button to select a policy from existing policy projects in the workspace.	policyUrl
Ruleset path	Yes	Yes	The path to the ruleset, in the form `/RuleApp/RuleAppVersion/ruleset/rulesetVersion`, where `RuleAppVersion` and `rulesetVersion` either reference a specific version or specify that the latest available version should be used. For example: `/Sale/2.0/ApplyDiscount/1.2` or `/Sale/Latest/ApplyDiscount/Latest` or `/Sale/2.0/ApplyDiscount/Latest` When it is first referenced, the `Latest` version of a ruleset or RuleApp is loaded and cached at the application level. As a result, all message flows and nodes inside the application have the same `Latest` version, regardless of when they are first referenced. To re-evaluate what the `Latest` version is, stop and start the application. If the ruleset is overridden at deployment time, the overridden ruleset must have the same signature as the one discovered during development time. For more information, see Configuring the ruleset path.	rulesetPath
Parameters	Yes	No	A ruleset can contain one or more parameters. Most parameter values are read-only, except for the Data location, for which you must specify an XPath expression. The XPath expression specifies the location in the inbound message of the data for each parameter; for example, `$Root`. To set the data location by using the XPath Expression Builder, select a parameter, then click the ellipsis (...) button next to the corresponding Data location cell in the table. When you add data location XPath expressions, avoid accessing parent and child nested fields in a message tree, because a change that you make to a nested structure can be overwritten by a change to the parent structure. The direction of the parameters can be `IN`, `OUT`, or `INOUT`. If the parameters of the ruleset are changed in the ODM server, you must rediscover the ruleset by clicking the Browse button.

The path to the ruleset, in the form


/RuleApp/RuleAppVersion/ruleset/rulesetVersion

, where RuleAppVersion and rulesetVersion either reference a specific version or specify that the latest available version should be used. For example:

/Sale/2.0/ApplyDiscount/1.2

/Sale/Latest/ApplyDiscount/Latest

/Sale/2.0/ApplyDiscount/Latest

When it is first referenced, the Latest version of a ruleset or RuleApp is loaded and cached at the application level. As a result, all message flows and nodes inside the application have the same Latest version, regardless of when they are first referenced. To re-evaluate what the Latest version is, stop and start the application.

If the ruleset is overridden at deployment time, the overridden ruleset must have the same signature as the one discovered during development time.

For more information, see Configuring the ruleset path.

rulesetPath

Parameters

Yes

A ruleset can contain one or more parameters. Most parameter values are read-only, except for the Data location, for which you must specify an XPath expression. The XPath expression specifies the location in the inbound message of the data for each parameter; for example, $Root.

To set the data location by using the XPath Expression Builder, select a parameter, then click the ellipsis (...) button next to the corresponding Data location cell in the table.

When you add data location XPath expressions, avoid accessing parent and child nested fields in a message tree, because a change that you make to a nested structure can be overwritten by a change to the parent structure.

The direction of the parameters can be IN, OUT, or INOUT. If the parameters of the ruleset are changed in the ODM server, you must rediscover the ruleset by clicking the Browse button.

The Monitoring properties of the node are described in the following table.

Property	M	C	Default	Description
Events	No	No	None	Events that you define for the node are displayed on this tab. By default, no monitoring events are defined on any node in a message flow. Use Add, Edit, and Delete to create, change, or delete monitoring events for the node; see Configuring monitoring event sources by using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box.