If you are deploying a process to a production server, you can specify process version and other details to override the server defaults.
During the creation of the Process Deployment Descriptor file, you can select deployment options for new and running versions. If you do not change any settings, the server uses the defaults, as described below.
By default the Process Server generates an execution log for running processes. You can enable this setting to override the engine default, and then view or download an execution log for a running or completed process. An execution log provides start/end times for activity execution and other details, and helps you troubleshoot faulted processes. The logging levels are:
System Default. Setting that is enabled in the Process Console that applies to all processes without a Process Logging override. The server is set to Execution by default.
None. No logging occurs as processes run. Performance is enhanced with logging disabled.
Full. All execution statements are logged, including the
Will Not Execute
statements for deadpath activities. For example, all fault handling statements that are not executed are logged.
Execution (default). All execution statements are logged, except for
Will Not Execute
statements. Using this setting instead of Full can greatly decrease the size of the log file.
Execution with Data. All execution statements are logged, except for
Will Not Execute
statements, including variable, expression, and partner link data. Using this setting can greatly increase the size of the log file.
Persistence refers to storage of active processes deployed to a server. When a process runs on the Process Server, all state and variable data is stored in the server database by default. However, for performance reasons and database size considerations, you may want to set a lower level of persistence.
If your process uses a wait activity or a retry policy, you must select the Persist or Full level.
You can make persistence setting selections as follows. Your selection is validated when you save the PDD.
|
The default setting. For each process instance, all state information is stored for a running, faulted, and completed process. In the event of a server failure, a running process can be fully recovered. The recovery is possible because Process Server maintains journaling (a journal of the changes intended for the database) for this setting.
| |
|
Same storage setting as Full, but without journaling. A running process is suspended. The process is recoverable if the system goes down, but needs to be looked at since no journaling was done, so recovery marks this type as suspended. This is the minimum persistence level to support Suspend on Uncaught Fault (see
Suspending a Process on Uncaught Faults).
|
Cannot select this setting if the process uses WS-Reliable Messaging.
If you reach the Activity Execution Limit set in the Tenant Detail and persistence is not set to this minimum level, the Suspend on Uncaught Fault flag is ignored and the process is terminated.
|
|
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 settings above, but allows you to view a graph of the process on the Active Processes detail page in the Process Console, where 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.
|
For Final, Brief, and None, the process cannot contain the following constructs:
Multiple receive activities
People activity (on-premises only)
Process:Subprocess invoke handler
|
|
This is the minimum level for process logging (described in the section above), but does not allow for viewing a graph of the active process. Stores only the start and completion times as well as final state (completed or faulted). 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 Process Console's Active Processes page.
| |
You can assign a group name to one or more processes. The group name is a selection filter for viewing a list of deployed or active processes in the Process Console.
Suspend on Uncaught Fault
According to the WS-BPEL 2.0 specification, a process with an uncaught fault must exit. However, you can suspend this process on an uncaught fault to perform process exception management, if desired.
You can make selections as follows:
|
The current engine setting for all processes. The default engine setting is to disable suspension on uncaught fault.
|
|
Do not allow this process to suspend on an uncaught fault. The process will terminate abnormally. This setting overrides the engine setting.
|
|
Suspend this process on an uncaught fault to put it in a suspended-faulting state. You can then perform process exception management on the faulting process, followed by retrying or completing the faulting activity or scope. This setting overrides the engine setting. For details, see
Process Exception Management.
|
Suspend on Invoke Recovery
For invoke activities that do not complete due to the node failure, you can suspend the process upon recovery. The process is suspended at the pending invoke, and you can perform process exception management, is desired.
You can make selections as follows:
|
The current engine setting for all processes. The default engine setting is to disable suspension upon process recovery when there is a pending invoke.
|
|
Do not allow this process to suspend at a pending invoke after process recovery. The process will terminate abnormally.
|
|
Suspend this process on recovery when there is a pending invoke to put it in a suspended state. You can then perform process exception management on the process, followed by retrying or completing the invoke. This setting overrides the engine setting.
|
Process Instance Retention
Once you deploy a process to the Process Server, and begin to execute it, the completed and faulted process instances are stored in the Informatica Business Process Developer database. Process Server administrators can delete old processes from the database on an automatic schedule, based on the number of days, hours or minutes you want to retain old processes before deleting them.
You can specify how many days (or hours or minutes) to retain a completed or faulted process in the Informatica Business Process Developer database by adding a retention number in the PDD. This number can be modified for the process in the Process Console.
If you don't specify a value for retention, the default engine value is applied to the process. This value is relevant only if automated database maintenance is enabled.
Note that only one version of a process can create new process instances.
|
By default, the Process Server auto-increments the version number for new versions. Auto-incrementing is based dropping the minor version number and incrementing the major version number by one. For example, 1.5 becomes 2.0.
To define your own version number for this process, type in a number, such as 1.5.
|
|
If the online (effective) date is blank or in the past, then the process immediately becomes the online (current) version. The online version for a given process is the one capable of creating new process instances. If the date is in the future, the server makes this version the online version when the effective date arrives.
If you intend to deploy your process to a server in a different time zone, be sure to edit the deployment descriptor file to include a time zone expression. For details, see
What is Process Versioning?.
|
|
If the offline (expiration) date is blank, then the process will not go offline.
Providing an offline date is useful if you want the process to run for a limited period of time. An offline process version cannot create new process instances, but running process instances complete normally.
You can specify an offline date. If you intend to deploy your process to a server in a different time zone, be sure to edit the deployment descriptor file to include a time zone expression. For details, see
What is Process Versioning?.
|
Running Process Disposition
|
By default, the all process instances are maintained. The default value of Maintain Version allows process instances created under previous versions to run to completion when this version becomes online.
You can select Migrate Version to convert process instances running against an earlier version to use the new version. Be sure to check the Server Log for warnings that are generated if an incompatibility occurs.
Select Terminate to terminate processes running under previous versions on the offline date of the new version, regardless of whether or not the process instances are complete.
|
