BPM Events automatically keeps a database image of its internal state for recovery purposes. When starting BPM Events, it automatically reloads the latest recovery backup (if any), and processes the event backlog generated in the database event queue while BPM Events was down. This procedure ensures no data is lost because of a shutdown, whether voluntary (operator) or not (server crash).
Do not confuse starting BPM Events (which automatically performs recovery of current applications) with Loading (or Reloading) an application.
Starting BPM Events. Automatically triggers the recovery mechanism for all applications that were 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. If a reinitialize{} section was specified, then it is executed immediately after recovery. This allows for some initial processing required in the case of recovery (for example, initial set-up of external systems). The event processing proceeds, as if no interruption occurred, with the current internal state. 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 them 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 (in that case, the reinitialize{} section is executed).
Similarly, stopping BPM Events does not unload the 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 these applications automatically resume without any intervention from the user. Therefore, always consider these applications as loaded, whether the server is stopped or active.
Unloading an application. An unloaded rule module automatically executes its finalize{} section, and then its execution state is removed from the server. The statements in the finalize{} section typically deletes 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 in the recovery backup in database. When restarting BPM Events, this application is not recovered. If you reload the application, then it is similar to a new installation; the application state and objects are reinitialized.
Starting BPM Events. Automatically triggers the recovery mechanism for all applications that were 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. If a reinitialize{} section was specified, then it is executed immediately after recovery. This allows for some initial processing required in the case of recovery (for example, initial set-up of external systems). The event processing proceeds, as if no interruption occurred, with the current internal state. If no application was running before, or if a new application requires starting, then load this application after BPM Events is started.