When editing a Business Process Server application that does not yet have rules with the Business Process Server development tool (Progress Developer Studio for OpenEdge) and then open the Rule Designer, the main rule module file is automatically created. Additional rule modules are developed for an application, with a name that has the form of XYZ_rules.txt.
A rule module is a text file structured as shown in the following example:
The name myApp in the first line (application myApp) must be the same name as the application to which the module belongs. If the module is not attached to any existing application, then this defines a new application name.
The name myModule in the second line (module myModule) must be consistent with the rule file name: if the module name is monitor_policy_123, then the name of the file containing this module should be monitor_policy_123.txt. In addition, the main rule module of an application must have a module name which is the same as the application name, extended with "_rules". For example, if the application name is myApp, then name the main module for this application: myApp_rules and store in a file named: myApp_rules.txt. The header of a main module is then as follows:
application myApp
module myApp_rules
A module can import other modules. In that case, an import statement is added:
module myModule import moduleA, moduleB;
The previous example means that the two modules imported are loaded before myModule, at loading time. Normally, when a module M1 imports a module M2, it is because the execution of M1 rules also requires rules and objects from M2 to be loaded. However, one may also use the import mechanism to automatically load a set of modules along with the main rule module, when an application installs. If the imported module belongs to another application, then qualify it by this application name: myOtherApp::moduleB.
Rule Groups: After the two header lines above, the module contains a list of rule groups.
initialize{} section: This section contains a possibly empty sequence of actions, similar to those definable in the action part of a rule. It must NOT contain rules. These actions are automatically executed when the module is loaded in the rule engine (this happens when the application is installed through the Administration module, or loaded through BPM Events Admin). They usually perform initial setup tasks for the application, like creating infopads and initializing them. An important property of this section is that it never reexecuts during recovery.
reinitialize{} section: In general, this optional section is not necessary. It contains a sequence of actions, similar to those in the initialize section. These actions automatically execute when the module is recovered from a previous session, after BPM Events has stopped and restarted. They usually perform initial setup tasks for external systems, that may not have been aware of the last shutdown (in the case of failure), for example, reinitialization of connections, etcetera. Note that initialize section and reinitialize section are mutually exclusive: they are never executed together. See Administering and operating BPM Events, for more details on the difference between rule loading and recovery.
finalize{} section: This section contains a sequence of actions, similar to those defined in the action part of a rule. It must NOT contain rules. These actions automatically execute when the application module is removed from the rule engine. This happens when the application is uninstalled. These actions usually perform final cleanup tasks, like deleting infopads from memory and removing their image in the database.
The name myApp in the first line (application myApp) must be the same name as the application to which the module belongs. If the module is not attached to any existing application, then this defines a new application name.
