Rule Execution Server administration artifacts

System administrators use the web-based Rule Execution Server console to manage and monitor RuleApps, ruleset execution, and decision services.

System administrators use the Rule Execution Server console for the following tasks:
  • To determine what rulesets are deployed
  • To enable or disable rulesets
  • To view event logs
  • To manage the storage and replication of server configuration data
  • To make real-time changes to business rules: typically, they can deploy, change, and manage business rules while the application is running.
The Rule Execution Server database stores all the changes that are made to a ruleset, such as information about the user who modified it, time of modification, and any comments that were added.

RuleApps

A RuleApp is a deployable management unit that contains rulesets. RuleApps keep records of the following details:
  • RuleApp name
  • RuleApp version
  • Number of rulesets in the RuleApp
  • RuleApp creation date

You can create RuleApps directly in the Rule Execution Server console and specify the associated rulesets later. See Adding RuleApps.

RuleApp archives

A RuleApp archive is an archive that stores RuleApps in a file.
Attention: RuleApp archives are saved in a strict directory structure: if you change that directory structure, you invalidate the RuleApp.

The RuleApp descriptor file is named archive.xml and stored in the META-INF directory of the archive. The descriptor file contains the basic metadata of a RuleApp: the name, version, and status of the RuleApp and of each ruleset

You search for a resource in a path that begins with the parent element in the descriptor:
  • The path of a RuleApp is defined by the name and the version number of the RuleApp. No resources are associated with a RuleApp.
  • The path of a ruleset is defined by the name and the version number of the RuleApp, followed by the name and the version number of the ruleset. This hierarchy is called the canonical ruleset path.
The following ruleset paths are all valid. The last example shows a canonical ruleset path.
  • /rule8_8app/6_ruleset_6/1.0
  • /rule8_8app/1.0/6_ruleset_6
  • /rule8_8app/6_ruleset_6
  • /rule8_8app/1.0/6_ruleset_6/1.0

Rulesets

You can add a ruleset to a RuleApp in one of the following ways:
  • From the RuleApp View of the Rule Execution Server console.
  • By deploying the ruleset within a RuleApp file.

A ruleset is deployed to Rule Execution Server along with a ruleset archive.

Classic rule engine archives are organized as follows:
  • A directory for each package in the ruleset, with an .irl file for each rule in the package
  • An .irl file for each rule task in the ruleset
  • A Ruleflow.irl file if the ruleset contains a rule flow
  • A META-INF directory: contains an archive.xml file, which includes the archive version number and the ruleset signature.
  • A RESOURCES directory, which can contain:
    • A metadata.xml file, which includes the hierarchical properties and the property type declaration in XML format
    • A bominfo.xml file, which includes the BOM paths
    • BOM-to-XOM mapping files
    • XOM files
    • BOM files
    • The engine.conf configuration file
    • A header.ilr file, which includes the ruleset header
    • If the ruleset archive comes from a version of Rule Designer earlier than Version 6.5, the index.xml file is in the RESOURCES directory.

Decision engine archives contain the result of a further compilation of the rules:

  • Java™ bytecode when you compile from Rule Designer and select the Optimize ruleset loading (Java bytecode generation) option upon ruleset archive creation.
  • Rules and ruleflows in an intermediate representation when you clear the Optimize ruleset loading (Java bytecode generation) option or when you generate rulesets from Decision Center.

Java XOM resources and libraries

When you set up Java XOM management, the deployment of Java XOM to Rule Execution Server generates Java XOM resources and libraries. These artifacts are described in Java XOM artifacts.