- Application Integration
- All Products
For each process instance, all running, faulted, and completed state information is stored. In the event of a server failure, a running process can be fully recovered. The recovery is possible because this setting tells Process Server to maintain a journal (a record of the changes intended for the database).
Note: If the process uses a WS-RM invoke handler for a partner role or a WS-Reliable Messaging policy assertion on a my role, full persistence is required.
Same storage setting as Full, but without journaling. If processes are running and the server fails, processes are suspended.
The process is recoverable if the system goes down, but needs to be looked at since no journaling was done. This process is marked as suspended.
Stores only the final state of the process (completed or faulted) and process variables. On a server failure, a running process is terminated. This setting makes fewer database writes than the previous two settings, but still allows you to view a graph of the process on the Active Processes Detail page in the
Application Integration Console. Here, you can see the execution path and final values of process variables. A process runs only in memory, and the Server Property called Process Idle Timeout has no effect on this persistence level.
This is the minimum level for process logging. Process Server stores only the start and completion times and the final state (completed or faulted). Also, it stores state and process variables only if the process faults. A process runs only in memory, and the Server Property called Process Idle Timeout has no effect on this persistence level.
No process information is stored in the server database when a process terminates. The process instance is not listed in the