BPM Events automatically keeps a database image of its internal state for recovery purposes. When starting BPM Events through the Administration module of Business Process Portal, it automatically reloads the latest recovery backup (if any), and processes the event backlog generated in the database event queue while BPM Events is down. No data is lost due to a shutdown, whether voluntary (operator) or not (server crash). However, it is possible to make a fresh start using the "discardBPMEventsBackup" utility script (see the BPM Events User’s Guide).
Do not confuse starting BPM Events with loading (or reloading) an application. The following describes the difference between starting BPM Events and loading an application:
Starting BPM Events. Automatically triggers the recovery mechanism for all applications loaded during the latest shutdown. The internal state is recovered, as it was at the end of the processing of the latest event before shutdown. The processing proceeds, as if there was no interruption. If no application was running before, or if a new application requires starting, then load this application after BPM Events is started.
Loading an application. Involves loading rules using a procedure quite different from recovery. When you start BPM Events, if some applications were recovered, then do not load BPM Events again (in fact, you cannot unless you unload it first). When loading a rule module, the initialize{}section is automatically executed. It contains initialization statements that create and initialize infopads. This does not happen when recovering an application or a module.
Similarly, stopping BPM Events does not unload the application. The following describes the difference between stopping BPM Events and unloading an application:
Stopping BPM Events. BPM Events automatically shuts down so that it can restart and resume the processing of events as if there was no interruption. The latest state of all loaded applications is saved to the database, so that after recovery of these can resume without any intervention from the user.
Unloading an application. A unloaded rule module automatically execute its finalize{} section. The statements in this section will typically delete application objects (infopads) from both the memory and the database. If you unload an application, then you remove all trace of this application in the rule engine, including the recovery backup in the database. When restarting BPM Events, this application is not recovered. When you reload the application, it is similar to a new installation: the application state and objects are reinitialized.
Finally, the BPM Events Admin utility provides another mode of adding rules in the engine—the Replace command (for an application or for a single rule module). Replacing an application (or module) is intended for upgrading the rules of the application (or of the module), without affecting the objects currently manipulated by the application. Unlike unloading, which typically executes some final statements (like deleting the infopads), the Replace command only replaces the rules—no finalize{}or initialize{}section is executed when unloading then reloading.
Starting BPM Events. Automatically triggers the recovery mechanism for all applications loaded during the latest shutdown. The internal state is recovered, as it was at the end of the processing of the latest event before shutdown. The processing proceeds, as if there was no interruption. If no application was running before, or if a new application requires starting, then load this application after BPM Events is started.