Dynamic Rule Processing Mode Selection in BRMS

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current Business Rules Management Systems (BRMS) require specifying the processing mode at design time, which limits flexibility and can break other applications if changed during runtime, leading to duplication of effort and potential errors.

Innovation Solution

Allowing the specification of processing modes (inferential or sequential) to be passed as parameters during rule invocation, enabling dynamic selection of the appropriate rule module without requiring pre-defined modes, thus decoupling the processing mode from design time constraints.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If processing mode is specified at design time, then system configuration is simplified, but flexibility and adaptability are reduced

Engineering Contradiction:

Improvesystem configurationVSAvoidprocessing mode flexibility

Core Design Contradiction:

Ease of manufactureVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamic selection of processing modes by allowing the rule engine to switch between inferential and sequential processing modes at runtime based on parameters passed during rule invocation. This is achieved through a mode parameter that is evaluated at execution time, enabling the system to adapt its processing behavior dynamically rather than being fixed at design time.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The patent changes the processing mode parameter from a fixed design-time configuration to a dynamic runtime parameter. By passing the processing mode as a parameter during rule invocation and evaluating it at execution time, the system allows flexible switching between different processing modes without requiring system reconfiguration or redeployment.

Inventive Principle:

Principle #35Parameter changes

2Adaptability or versatility

If processing mode is changed during runtime, then flexibility is improved, but other applications may be affected and reliability is reduced

Engineering Contradiction:

Improveprocessing mode flexibilityVSAvoidapplication stability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent segments the rule processing functionality into separate rule modules, each capable of operating in its own processing mode. This modular architecture allows different rule modules to be invoked with different processing modes independently, so that changing the mode for one module does not affect other modules or applications.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent applies processing mode changes selectively to specific rule invocations rather than globally to the entire system. By passing the processing mode as a parameter during individual rule invocations, only the affected rule module is influenced, while other applications and rule modules continue to operate with their original settings, thus maintaining system-wide stability.

Inventive Principle:

Principle #16Partial or excessive action

3Adaptability or versatility

If multiple processing modes are supported, then versatility is improved, but device complexity increases

Engineering Contradiction:

Improveprocessing mode supportVSAvoidrule engine complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal rule module design that can handle multiple processing modes through a common invocation interface. The rule engine evaluates a mode parameter at runtime and routes the invocation to the appropriate processing logic, allowing a single rule module to serve multiple processing modes without requiring separate specialized modules for each mode.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS8954371B2Systems and/or methods for dynamic selection of rules processing mode

Publication Date: 2015.02.10 INTERNATIONAL BUSINESS MACHINE CORPORATION

AI summary

Certain example embodiments described herein relate to techniques for dynamically selecting rule processing modes. The processing mode does not need to be specified during rule design/authoring. Two sets of artifacts may be generated to support a desired processing mode. This may occur in the designer's local workspace, e.g., so that rule invocation can be tested locally. Additionally, or alternatively, both sets of artifacts may be installed on the rule engine running on a remote server when the project is deployed. The designer need not be aware that both sets of artifacts are being generated. In certain example embodiments, the designer may have the ability to sequence rules within metaphors (or decision entities such as decision tables), and/or the ability to sequence metaphors within rule sets. During rule invocation, a parameter may be provided to indicate the processing mode (e.g., sequential or inferential) to be used by the rule engine.