ActiveVOS Designer User’s Guide

General Deployment Options

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.

Process Logging

By default the ActiveVOS 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:

Process Persistence

Persistence refers to storage of active processes deployed to a server. When a process runs on the ActiveVOS 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.

Note: 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:

Full

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 ActiveVOS maintains journaling (a journal of the changes intended for the database) for this setting.

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, you must select this setting. For details, see Partner Role Invoke Handlers and WS-Reliable Messaging.

Persist

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.

Final

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 ActiveVOS 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.

Brief

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.

None

No process information is stored in the server database when a process terminates. The process instance is not listed in the Administration Console’s Active Processes page.

Process Group

You can assign a process 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 ActiveVOS server Administration Console. The Group Name is also useful for deploying a group of BPEL processes containing a People Activity. Refer to the ActiveVOS BPEL for People documentation for more information.

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:

System Default

The current engine setting for all processes. The default engine setting is to disable suspension on uncaught fault.

False

Do not allow this process to suspend on an uncaught fault. The process will terminate abnormally. This setting overrides the engine setting.

True

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 which 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:

System Default

The current engine setting for all processes. The default engine setting is to disable suspension upon process recovery when there is a pending invoke.

False

Do not allow this process to suspend at a pending invoke after process recovery. The process will terminate abnormally.

True

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 ActiveVOS server, and begin to execute it, the completed and faulted process instances are stored in the ActiveVOS database. ActiveVOS 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 ActiveVOS database by adding a retention number in the PDD. This number can be modified for the process in the ActiveVOS server Administration 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.

Versioning

Note that only one version of a process can create new process instances.

Process Version

By default, the ActiveVOS 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.

Effective Date

If the effective date is blank or in the past, then the process immediately becomes the current version. The current 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 current 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?.

Expiration Date

If the expiration date is blank, then the process will not expire.

Providing an expiration date is useful if you want the process to run for a limited period of time. An expired process version cannot create new process instances, but running process instances complete normally.

You can specify an expiration 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 effective.

You can select Migrate Version to convert process instances running against an earlier version to use the new version. This is useful if you have made only a small change to the BPEL process and want to apply the change to process instances already running. The only permitted changes are expressions.

Select Terminate to terminate processes running under previous versions on the effective date of the new version, regardless of whether or not the process instances are complete.

For details, see What is Process Versioning?

If you do not change the defaults, the .pdd file does not include any version details. To add or change version details, see Using the PDD Editor Source View.