Glossary

This glossary provides terms and definitions for IBM® Operational Decision Manager. It is only available in English.

The following cross-references are used in this glossary:

See refers you from a nonpreferred term to the preferred term or from an abbreviation to the spelled-out form.
See also refers you to a related or contrasting term.

A B C D E F G H I J K M N O P Q R S T U V W X

A

action: A business process that is generated in response to the processing of an event or a rule.
action column: The action part of a decision table.
action object: A subset of fields in the definition of an action.
action phrase: In the vocabulary, a phrase that specifies an action to be run. An action phrase corresponds to a method that has no return value in the business object model (BOM).
action rule: A business rule that can be edited in the rule editor. Action rules and decision tables.
action rule template: A partly completed action rule that can be used to create a series of rules with the same structure.
action set: Action sets consist of one or more actions to be carried out when the conditions defined in the rule are met.
action task: In a rule flow, a task that contains rule action statements. These action statements are run each time the task is called.
administrator: A person responsible for administrative tasks such as access authorization and content management. Administrators can also grant levels of authority to users.
Advanced Rule Language (ARL): An executable rule language that is used by the decision engine. Rules that are compiled into Advanced Rule Language (ARL) can reference any execution object and can invoke methods on these objects.
agenda: A logical workspace where rule instances that have conditions matching objects in the working memory are put.
ARL: See Advanced Rule Language.
attribute: A set of factors that are used as variables to determine the score of an entity. The value of an attribute can be a natural number, a floating point number, a Boolean value, a character, or a character string. An attribute can be the result of the execution of another rule or a combination of other attributes.
automatic variable: A variable that a user can declare as an instance of a specific business object model (BOM) class.

B

BAL: See Business Action Language.
baseline: See snapshot.
BOM: See business object model.
BOM property: A property added to a type in a business object model (BOM). Business properties extend the original type without altering its source.
BOM-to-XOM mapping: A mechanism that defines how business elements are mapped to the Execution Object Model.
boot BOM: A set of files that define the system types, such as string or number, for the Business Action Language (BAL).
branch: In a rule flow, a node that organizes conditional transitions. Several transitions can go to and from a branch node. All transitions created from a branch must have a condition, except the Else transition.
BRLDF: See Business Rule Language Definition Framework.
BRMS: See business rule management system.
bundle: In the OSGi service platform, a Java™ archive file that contains Java code, resources, and a manifest that describes the bundle and its dependencies. The bundle is the unit of deployment for an application.
Business Action Language (BAL): A business rule language that uses an intuitive and natural language-like syntax for writing business rules.
business analyst: A decision management user role that is responsible for modeling rule application projects.
business method: A method added to a type in a business object model. Business methods extend the original type without altering its source.
business object: An abstract representation of the fields that belong to the action definitions.
business object model (BOM): A representation of the core concepts of a business and their logical connections. The business object model is the basis for the vocabulary used in business rules. The elements of a business object model (BOM) map to those of a corresponding execution object model.
business policy: A set of rules that define business processes, industry practices, or the scope and characteristics of business offerings.
business rule: A policy, constraint, or required operation that applies to a specific set of business conditions or dependencies. An example of a business rule for a bank is that a credit check is not required when opening an account for an existing customer.
business rule application: An application in which the decision-making process is automated and managed by using business rules.
business rule language: A language for expressing rules with natural language terms and syntax.
Business Rule Language Definition Framework (BRLDF): A framework for defining custom business rule languages by using XML schemas and property files.
business rule management: The practices that control and manage business rules through their life cycles.
business rule management system (BRMS): A system designed to modify and manage business logic independently from the applications within an organization.
business subtype: A subtype of a type in a business object model (BOM). Business subtypes are used to extend an object model by using business methods and business properties.
business system: A group of diverse but interdependent applications and other system resources that interact to accomplish specific business functions.

C

category: A property that is set on an element of the business object model (BOM) and can be applied to business classes and filtered in business rules. This property allows the user to specify whether a business class and its members are visible in a rule.
category filter: A filter that is set on a business rule and removes the business element to which a category was attached from the completion menu.
client project for RuleApps: A predefined project for Eclipse that contains a class to run a rule set within a RuleApp.
condition: A test of a situation or state that must be in place for a specific action to occur.
condition column: The condition part of a decision table.
constant: In a business object model (BOM), a vocabulary element that verbalizes the public static final attribute of a class with the same type as the BOM class. See also verbalization.

D

dashboard: A graphical user interface that enables users to monitor and manage activities. A dashboard provides a consolidated view of status information that is obtained from various sources.
Decision Center console: A designated workspace where business users can work collaboratively to author, edit, organize, and search for business rules.
decision engine: An implementation of the rule engine that compiles rulesets into executable or intermediate code and can optimize the performance of the rulesets. See also rule engine.
decision operation: A function that defines the decision-making logic and the input and output data for a decision. A decision operation is implemented as a ruleset.
decision service: A set of related decisions that are contained in a business rule application. Rules make up the decision service and determine its behavior. Decision services can be organized into one or more rule projects.
decision table: A form of business rule that captures multi-conditional decision-making business logic in a table where the rows and columns intersect to determine the appropriate action. See also rule set.
Decision Warehouse: A warehouse that saves execution traces to a database so that users can query the data store to get information on particular executions or transactions.
deprecated: A feature that is supported but no longer recommended. Typically, a deprecated feature is replaced by a new one, and in the case that it becomes obsolete may be removed from future releases.
deployment: The process of transferring rules from a local development environment into an operational, or runtime, environment.
deployment configuration: The manner in which decision operations are packaged into RuleApps, managed, and then deployed to business rule applications.
developer: A decision management user role that is responsible for implementing the rule applications.
dictionary: A set of business model definitions that specify linguistic properties such as translation, plural form, and grammatical gender of one or more terms.
dynamic domain: A domain in which the set of possible values for a type is defined. With a dynamic domain, the set of values is stored and managed outside the business object model (BOM), and changes to the set of values are automatically reflected in the business object model. When rule authors write business rules using the type, they choose from a list of values that is created dynamically and is always up-to-date.

E

edit bar: A text field for authoring rules at the top of the decision table editor in Rule Designer.

end node: A node that identifies where a rule flow stops. A rule flow has at least one end node.
enriched attribute: An attribute for which the value of an object is accessed from an external data service.
entity: An object that has a unique identifier that permits other objects to refer to it logically. See also entity type.
entity aggregate: A value that is computed from a collection of entities.
entity relationship: A unidirectional association between entity types.
entity type: A set that identifies entities that share common attributes. For example, Joe Bloggs might be an entity that has an entity type "customer". See also entity.
execution component: A component that authorizes the execution of a rule set by the execution unit (XU).
execution object model (XOM): A model that references implementation objects used in rules.
execution unit (XU): A Jakarta EE connector or resource adapter that handles the low-level details of rule set execution for a rule execution server.
expected value: The average value for a given attribute for a population dataset. This value is ultimately used to determine reason code assignment, it is typically used for linear and logistic models where the interaction of variables is controlled.
Extensible Stylesheet Language Transformation (XSLT): An XML processing language that is used to convert an XML document into another document in XML, PDF, HTML, or other format.
external system: A system that exists outside a particular network.

F

Fastpath mode: A rule execution mode that uses an optimized sequential algorithm.
feature: A manifest file and a collection of OSGI bundles that correspond to a solution project.
final action: An action attached to a rule flow task that is done after the task has been run.
folder: A project element that can be used to group rules according to business logic.
fork: In a rule flow, a node that splits the execution flow into several parallel transitions. The transitions created from a fork do not have conditions.
function: A named group of statements that can be called and evaluated and can return a value to the calling statement.

G

global aggregate: A value that is computed from a collection of objects. Examples of global aggregates are average, count, maximum, minimum, and sum.
group: A collection of users who can share access authorities for protected resources.

H

hierarchical property: An extended rule property whose values are organized into a hierarchy.
homogeneous rule: A rule for which the conditions are written on the same type and number of objects.

I

ILOG® Rule Language (IRL): An executable rule language. Rules in ILOG Rule Language (IRL) can reference any execution object and invoke methods on these objects.
inbound binding: A definition that determines how inbound events via HTTP or JMS are received.
initial action: An action attached to a rule flow task that is done before the task is run.
input parameter: A parameter value that is provided as input to a rule set when it is run. It can be modified by the execution process and is provided as output when the execution is completed.
in parameter: A parameter value that is provided as input to the rule set at execution time.
insertion: The action of adding a new object into the object set provided to the rule engine for execution.
invocation: The activation of a program or procedure.
IRL: See ILOG Rule Language.

J

Java Message Service (JMS): An application programming interface that provides Java language functions for handling messages.
Java project for Rules: A predefined Java project for Eclipse that contains a single, runnable main class to run rules contained in a rule project.
JMS: See Java Message Service.
JMS destination: An object in which message queuing applications use the Java Message Service specification to put messages, and from which they can get messages.
JMS provider: A messaging engine that implements the JMS messaging specification, for example WebSphere® MQ or SIBus.
join: In a rule flow, a node that combines all the transitions created from a fork.

K

key performance indicator (KPI): A quantifiable measure that is designed to track one of the critical success factors of a business process.
KPI: See key performance indicator.

M

mapped condition: A mapped expression that specifies a mapping between the columns in a table and the fields of a business object, and an SQL WHERE clause that determines the data that is retrieved from the database. See also mapped expression, mapped key, mapped query.
mapped expression: A relationship between the data in a database and the fields of a business object, and an associated statement that determines the data that is retrieved from the database. See also mapped condition, mapped key, mapped query.
mapped key: A mapped expression that specifies a mapping between the columns in a table and the fields of a business object, and that specifies which of these fields are used to determine the data that is retrieved from the database. See also mapped condition, mapped expression, mapped query.
mapped query: A mapped expression that specifies an SQL SELECT query or a stored procedure call that determines the data that is retrieved from a database, and a mapping between the columns in the query result set and the fields of a business object. See also mapped condition, mapped expression, mapped key.
mapping: The relationship between fields in different abstractions of action objects.
memento: A memento is the externalized state of the rule engine, which is stored in such a way that it can be restored without breaking the rules of encapsulation. It comes from the behavioral pattern of the same name memento from the Gang of Four Design Patterns.
message: A set of data that is passed from one application to another. Messages must have a structure and format that is agreed by the sending and receiving applications. See also category.
message-driven rule bean: An enterprise bean that allows Jakarta EE applications to process messages asynchronously. The bean invokes the execution unit (XU) when a JMS message arrives and posts the results of the rule engine processing to a JMS destination.
method: A way to implement a function on a class.
migrate: You migrate when you transform your data, users, or code to use them in a new version of Operational Decision Manager. Every Operational Decision Manager migration happens after you upgrade to a new version, but not all upgrades require a migration. Updates rarely require a subsequent migration.

N

navigation phrase: In the vocabulary, a phrase that associates two business elements. A navigation phrase corresponds to a method that has a return value or an attribute in the business object model (BOM).
nonproduction system: A system on which application programs that are in development are run and tested.

O

operator: A building block that lets the user compare or establish relationships between the different parts of business rule statements.
outbound binding: A definition that determines how outbound events are delivered via HTTP or JMS to an endpoint.
out parameter: A parameter value that is set by the execution process and provided as output from the rule set after the execution is completed.

P

pattern

A reusable solution that encapsulates a tested approach to solving a common architecture, design, or deployment task in a particular context.
A model of physical or virtual assets that is used as a template for a solution. A pattern specifies components, links, and policies that follow architecture and design best practices and is used for repeatable deployment of applications, databases, and other resources. A pattern is deployed as a single virtual environment that includes hardware and the workloads that run on it and all related components, links, and policies.

persistence service

A service that provides private application programming interface (API) support to store and accesses executable resources.

phrase template

A pattern for the verbalization of a business element.

plug-in

A separately installable software module that adds function to an existing program, application, or interface.

point

The numeric value that is assigned to an attribute based on the value of the attribute and the interval in which the value is included.

point difference

The upper limit in a given interval for an attribute that is ultimately used to determine reason code assignment. Typically, this limit is used for linear and logistic models where the interaction of variables is controlled.

policy manager

A decision management user role who is responsible for enforcing decisions through the creation and maintenance of rules.

precondition

A group of rule statements in which the user defines global variables for a decision table or decision tree and conditions that must be met before any rows or branches in the decision table or tree can be run.

priority

A property that determines the order in which business rules are run in an application.

project

A specific organization of rules and other elements that facilitates the authoring and management of a logical grouping of rules.

property

A characteristic of an object that describes the object. A property can be changed. Properties describe an object name, type, value, or behavior, among other things.

publish

To send a rule to a server for storage and management.

Q

query: A statement, or combination of statements, that is used to search a rule project (or other scope) and to select rule project elements that meet certain criteria.

R

range: The categorization of an attribute into different segments.
range operator: The logic used when comparing two attributes in a range.
repo: See repository.
repository (repo): A persistent storage area for data and other application resources.
RetePlus mode: A rule execution mode for matching patterns with objects. The RetePlus mode is used by the rule engine to minimize the number of rules and conditions that need to be evaluated, compute which rules should be run, and identify in which order these rules should be fired.
retraction: The action of removing an object bound to a rule variable from the working memory.
role: A job function that identifies the tasks that a user can do and the resources to which a user has access. A user can be assigned one or more roles.
rule: A statement that defines or constrains some aspect of the business. See also business rule.
rule analysis: A mechanism for checking whether business rules are semantically consistent. Inconsistencies can be found either in the rule itself, or with respect to other rules.
RuleApp: A deployment and management unit for Rule Execution Server that can contain one or more rule sets.
RuleApp archive: An archive that allows RuleApps to be stored to a file system. RuleApp archives are saved in a strict directory structure.
RuleApp project: An Eclipse project that does the deployment of a RuleApp to a running Rule Execution Server.
rule artifact: An item used to express a business policy in a business rule application. Action rules and decision tables are examples of rule artifacts.
Rule Designer: A business rule application development tool integrated into the Eclipse development environment and dedicated to the creation and management of business rule applications.
rule editor: A graphical tool used to create rules.
rule engine: A software component that evaluates and runs business rules. See also decision engine.
Rule Execution Server: A module that integrates into the Jakarta EE environment, and as such offers the standard services of an application to run, control, and monitor rule sets contained in RuleApps.
Rule Execution Server configuration project: A project in which a server configuration persists. The configuration provides the information necessary to make a connection to the rule execution server when a RuleApp is applied.
Rule Execution Server console: A web user interface that provides support for deploying RuleApps and the management of executable resources on Rule Execution Server.
rule execution set: A collection of rules that are intended to be run together.
rule flow: A method of controlling and ordering the execution of rule artifacts. A rule flow is defined in terms of tasks.
rule instance: An occurrence of a rule that includes the combination of objects in the working memory that match the patterns specified in the rule. More than one instance of the same rule may exist in the agenda at any time because the rule patterns may be satisfied by more than one object or set of objects.
rule model: A model that defines the set of items that are managed in a rule project, and their associated properties.
rule package: A container for organizing rule artifacts according to business logic. Rule packages become folders after they have been published to Decision Center.
rule perspective: An Eclipse perspective that defines the initial set and layout of views in the workbench window that is used in the development of a rule project.
rule project: A project in which business rules and business object models are managed and organized.
rule project template: A pattern that defines the folder structure and options for a new rule project.
rule session: A runtime connection between a client and a rule engine. A rule session may consume initialized rule engine resources.
ruleset: A decision-making program that can be processed by a rule engine to yield a decision, based on input and output parameters. The decision-making logic is implemented as rules, decision tables, and ruleflows.
rule set: A set of rules that can be run by the rule engine and includes rule artifacts and non-rule artifacts.
rule set extractor: A mechanism for selecting the rules of the rule set to be deployed. Selection is typically based on the value of rule properties.
rule set interceptor: A mechanism that allows services to be added to an execution component transparently and to be triggered automatically when certain events occur.
rule set parameter: A parameter that can be defined to set and retrieve values on a rule set. Rule set parameters are accessible from outside of the rule set, and therefore are a bridge between the business logic and the application.
rule set signature: The list of in, out, and inout parameters of a rule set.
rule set variable: A variable that can be defined to be used in all the rule artifacts of a rule set.
rule task: In a rule flow, a task that refers to rule artifacts and orders them.
runtime rule selection: In a rule task, a way to filter rule artifacts at run time. Runtime rule selection is expressed in rule statements.

S

scenario: A real or fictitious use case that can be used to validate the behavior of rules with test suites or simulations. Each scenario contains all the necessary information required for rules to run properly.
scenario provider: An object that defines how scenarios are loaded for test suites and simulations.
sequential mode: A rule execution mode for stateless pattern-matching. With this mode, rules can be processed sequentially, which can improve the speed of rule processing in specific cases. The sequential mode can be selected for individual tasks in a rule flow.
server group: A group of Rule Execution Server for z/OS® instances that are configured to be transferred to another if a server fails or if there is a planned outage. A server group can include one to 32 server instances.
service: An external component that is called by a Java agent or rule agent to access external data or to do advanced computation.
simulation: A faster-than-real-time performance of a process. Simulation enables organizations to observe how a process works in response to variations of inputs to the process, just as in a real-life work environment.
snapshot: A capture of information at a specific time for analysis. The information can be data, a project, or a branch.
start node: A node that identifies where a rule flow begins. A rule flow has one and only one start node.
subflow task: In a rule flow, a task that refers to another rule flow. A subflow task can reference a rule flow in the current project, or in a parent project.
synchronization: The process of publishing and updating changes in a rule to a server.

T

task: The basic unit of organization in a rule flow.
technical rule: A rule written in a technical rule language, such as ILOG Rule Language (IRL).
test driver: A software module or application used to invoke a test and, often, provide test data, control and monitor execution, and report test outcomes. A test driver sequences and controls the automated execution of one or more tests.
test suite: A set of usage scenarios with which the user can verify that business rules are correctly designed and written. Running test suites produces a report comparing the expected results and the actual results obtained when applying rules to the scenarios.
transition: A connection between two tasks in a rule flow. Transitions are unidirectional, and they can have conditions attached to them.
transition condition: In a rule flow, a specification of a transition that dictates when the target task can be run.
transparent decision service: A web service for rulesets that are deployed to a Rule Execution Server instance.
type: In a WSDL document, an element that contains data type definitions using some type system (such as XSD).

U

update: You update Operational Decision Manager when you apply a fix pack or an iFix. In general, updating introduces corrections rather than new features.

upgrade: You upgrade Operational Decision Manager when you replace one version of the product with a newer one. Upgrading introduces new features as well as the corrections issued as fix packs and iFixes between versions. Sometimes when you upgrade you need to subsequently do a migration.

V

variable: A representation of a changeable value.
verbalization: The process of associating terms and phrases to elements of the business object model (BOM). See also constant.
version policy: A set of characteristics that determines how versions of RuleApps and rulesets are numbered and whether to augment or replace what is deployed on a Rule Execution Server instance.
vocabulary: The set of terms and phrases that are used for rule editing.

W

web service: An application that does specific tasks and is accessible through open protocols such as HTTP and SOAP.
working directory: The active directory. When a file name is specified without a directory, the current directory is searched.
working memory: A part of the rule engine that contains the current state of objects. It is this current state that determines which rules are added to the agenda, and in which order these rules are run.
WSDL document: A file that provides a set of definitions that describe a web service in Web Services Description Language (WSDL) format.
WSDL file: See WSDL document.

X

XOM: See execution object model.
XSLT: See Extensible Stylesheet Language Transformation.
XU: See execution unit.