Rule Execution Server persistence layer

File persistence

File persistence targets the Java SE platform. It is useful for developers who test on a single local instance of the application server.

RuleApp archives are JAR files. JAR files provide efficient packaging and access to distributed content. When a RuleApp archive is extracted, its contents is written to a root directory as a single JAR file.

Rulesets with no managed Java XOM

The root directory is named yourWorkingDir/res_data by default. You can change this name by using the res-setup Ant task. The default res_data directory, or your customized root directory, is structured as follows:

• One subdirectory for each level of the canonical ruleset path.

  • RuleApp
  • RuleApp version number
  • Ruleset
  • Ruleset version number
• Each version subdirectory contains files that store the properties of the ruleset and ruleset archive.

  • The description.txt file describes the RuleApp or ruleset. It is not mandatory.
  • The display_name.txt file contains the alternative name of the RuleApp or ruleset. It is not mandatory.
  • The creation_date.txt file contains the creation date of the RuleApp or ruleset. It is mandatory.
  • The properties.txt file contains the properties of the RuleApp and ruleset. It is mandatory only for the ruleset, as it contains at least the status of the ruleset.
  • The ruleset archives are extracted as JAR files from the RuleApp (ruleset.jar).

The following tree illustrates that structure.

Rulesets with managed Java XOM

The root directory is named yourWorkingDir/res_xom by default. You can change this name by using the res-setup Ant task. The res_xom directory, or your customized root directory, is structured as follows:

• Two files for each deployed resource:

  • One file for the initial content of the JAR file. This file takes the initial file name, combined with the version number computed during the deployment process. For example: myjarfile_1.0.jar
  • One file for the checksum value (SHA-1 algorithm). This file takes the name of the previous file with an additional .sha1 file name extension. For example: myjarfile_1.0.jar.sha1
• One subdirectory for each library name. This subdirectory contains a subdirectory for each version of the library. Each version-number subdirectory contains a .ref file which contains the list of URIs in the library.

If the name of a library contains a slash ('/') character, a subfolder is added. As an example, the creation of the myLib/myTag version 1.0 results in the following subfolders: ./res_xom/myLib/myTag/1.0

The following tree illustrates this structure.

Database persistence

The following diagram shows the relational tables for RuleApps and rulesets.

The following diagram shows the relational tables for execution traces.

The following diagram shows the relational tables for XOM resources and libraries.

Database schemas

Rule Execution Server uses a simple database schema that relies on the following tables. In addition to these tables, a view is created to list all the enabled rulesets dynamically, if the targeted database management system supports the feature. All database management systems support it, except MySQL 3.x and 4.x. Indexes are created to speed up the search.

The following table describes the database schema for RuleApps.

Table 1. Database schema for RuleApps

Column Name	Mandatory	Database Type	Comments
ID		INTEGER	The value is autogenerated and handled directly by the database. Autogeneration is database dependent.
NAME		VARCHAR(256)	This column stores the name of the RuleApp.
MAJOR_VERSION		INTEGER	This column stores the major version number of the RuleApp.
MINOR_VERSION		INTEGER	This column stores the minor version number of the RuleApp.
CREATION_DATE		BIGINT	This column stores the creation date of the RuleApp as a long data type.
DISPLAY_NAME		VARCHAR(256)	This column stores a possible alternative name of the RuleApp.
DESCRIPTION		VARCHAR(256)	This column stores a text that describes the RuleApp.

The following table describes the database schema for rulesets.

Table 2. Database schema for rulesets

Column Name	Mandatory	Database Type	Comments
ID		INTEGER	The value is autogenerated and handled directly by the database. Autogeneration is database dependent.
NAME		VARCHAR(256)	This column stores the name of the ruleset.
MAJOR_VERSION		INTEGER	This column stores the major version number of the ruleset.
MINOR_VERSION		INTEGER	This column stores the minor version number of the ruleset.
CREATION_DATE		BIGINT	This column stores the creation date of the ruleset as a long data type.
DISPLAY_NAME		VARCHAR(256)	This column stores a possible alternative name of the ruleset.
DESCRIPTION		VARCHAR(256)	This column stores a text that describes the ruleset.
RULEAPP_ID		INTEGER	This column stores the ID of the RuleApp to which the ruleset belongs.

The following table describes the database schema for RuleApp properties.

Table 3. Database schema for RuleApp properties

Column Name	Mandatory	Database Type	Comments
ID		INTEGER	The value is autogenerated and handled directly by the database. Autogeneration is database dependent.
RULEAPP_ID		INTEGER	This column stores the ID of the RuleApp to which the property belongs.
NAME		VARCHAR(256)	This column stores the name of the property.
VALUE		VARCHAR(2000) or TEXT (for MySQL and Sybase)	This column stores the value of the property.

The following table describes the database schema for ruleset properties.

Table 4. Database schema for ruleset properties

Column Name	Mandatory	Database Type	Comments
ID		INTEGER	The value is autogenerated and handled directly by the database. Autogeneration is database dependent.
RULESET_ID		INTEGER	This column stores the ID of the ruleset to which the property belongs.
NAME		VARCHAR(256)	This column stores the name of the property.
VALUE		VARCHAR(2000) or TEXT (for MySQL and Sybase)	This column stores the value of the property.

The following table describes the database schema for ruleset resources.

Table 5. Database schema for ruleset resources

Column Name	Mandatory	Database Type	Comments
ID		INTEGER	The value is autogenerated and handled directly by the database. Autogeneration is database dependent.
RULESET_ID		INTEGER	This column stores the ID of the ruleset to which the resource belongs.
DATA		BLOB named archive	This column stores the value of the resource.

The following table describes the database schema for XOM resources.

The following table describes the database schema for managed Java XOM libraries.

The following table describes the database schema for managed Java XOM libraries.

Database connections

When connecting to a database, Rule Execution Server relies on the persistence services offered by the application servers or a web server. In Java SE mode, it uses a direct JDBC connection.

JDBC drivers handle the connection to the database. The readme file of the product distribution provides the list of tested database drivers.

Database scripts

Before you can use Rule Execution Server with database persistence, you must create some resources, such as tables and indexes, in the database. Each application server has it own way of handling these persistence services. For more information, see the documentation of your application server.

The product distribution provided SQL scripts for you to create database tables. You can find these scripts in <InstallDir>/executionserver/databases/<database>. The databases directory also contains a readme file. You can use any tool that can handle SQL to import and run the scripts. The following table lists the tools available for the supported databases, in alphabetical order. For more information, see the documentation of these tools.