Rule Execution Server Administration Artifacts

Online Helps > Rule Execution Server Console > Overview > Rule Execution Server Administration Artifacts

Rule Execution Server Administration Artifacts

The Web-based Rule Execution Server Console provides a way to manage and monitor RuleApps and the ruleset archives they contain, as well as transparent decision services.

The Console and Administators

The Rule Execution Server Console is primarily intended for system administrators to determine what rulesets are deployed, enable or disable them, and perform basic monitoring and statistical analysis. It allows users to deploy, change, and manage business rules as the application is running, that is, real-time changes to business rules. The model persists all changes made to a ruleset. The version log maintained by JRules records the details of the different versions of the ruleset including information of the user who modified data, time of modification, and any comments that have been made.

The console provides:

Remote management and monitoring through JMX.
An interface for performing management tasks.
Facilities to view event logs.
An interface to facilitate storage and replication of server configuration data.

The following concepts are essential to understand:

RuleApps

A RuleApp is a deployable management unit that contains one or more rulesets.

A RuleApp keeps a record of:

the RuleApp name
the RuleApp version
the number of rulesets managed by the RuleApp
the RuleApp creation date

A RuleApp can be created directly in the Rule Execution Server Console. The associated rulesets can then be specified later, see Adding RuleApps.

RuleApp Archives

A RuleApp archive is an archive that allows a RuleApp to be stored and retrieved to a file system.

The RuleApp archive is saved in a strict directory structure. The RuleApp descriptor file is stored in the META-INF directory of the archive. This descriptor file is named archive.xml. This descriptor contains the basic metadata of a RuleApp:

Name/version/status of the RuleApp.
Name/version/status of each ruleset.

A resource is searched for 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.

Rulesets

A ruleset is deployed to Rule Execution Server along with a ruleset archive. A ruleset archive is organized as follows:

a directory for each package in the ruleset:

a .irl file for each rule in the package

a .irl file for each rule task in the ruleset
a Ruleflow.irl file if the ruleset contains a ruleflow
a directory named META-INF

a descriptor.xml file--that includes the archive version and the ruleset signature. The version of JRules is included in this file. For example: <desc:jrules-version major="6" minor="5"/>
If the ruleset archive comes from JRules 6.5 then the index.xml will be in META-INF directory

a directory named RESOURCES that can contain:

a metadata.xml file--that includes the hierarchical properties and the property type declaration in XML format
a bominfo.xml--that includes the BOM paths
BOM2XOM files
XOM files
BOM files
engine.conf
a header.ilr file--that includes the ruleset header
If the ruleset archive comes from a previous version to JRules 6.5 then the index.xml will be in the RESOURCES directory

A ruleset can be added to a RuleApp. It can either be packaged within a RuleApp using the Rule Execution Server Console, or deployed within a RuleApp archive file.

Transparent Decision Services

A transparent decision service uses the integration of Rule Execution Server execution components to execute business rules in a Service Oriented Architecture (SOA). These components together with the Execution Unit (XU) administer the ruleset execution services.

The Rule Execution Server Console displays management and runtime information about the transparent decision service. Properties of the transparent decision service can be used to expose custom attributes and useful metadata.