The Deployed Process Version Detail page displays all the details from the process deployment descriptor as well as the process definition.
The sections of this page are described in the following topics:
•Process Version Life Cycles
•Updating a Process Version
•Setting a Process Version Offline or Online
•Logging Level
•Process Version Persistence Type
•Exception Management Type
•Invoke Recovery Type
•Process Instance Retention
•Deployed Process Detail Graph
The Deployed Process Version Detail page also shows endpoint reference details and other related details:
Role
Explanation
My Role
My Role partner link endpoint reference details are generated from information in the deployment descriptor. Rest your mouse on the partner link type to view the associated namespace. Select the Service Name link to view the WSDL file for the Web Service exposed by the partner link. Select View in the Policy column to view any attached policy assertions.
Partner Role
Partner Role partner link endpoint reference details are generated from information in the deployment descriptor. Rest your mouse on the partner link type to view the associated namespace. Select a static endpoint type from the Linkage column to view the endpoint definition.
Indexed Properties
Indexed Properties, if any, are displayed.
Event Filters
Event Filters, if any, are displayed. An event filter specifies process events that are passed to the Event Manager for processing. Event services, deployed to the Catalog, act upon the events.
Resource Usage
Resource Usage shows WSDL, schema, and other files and their target namespace referenced in this process. Select a Resource to view the resource definition.
Understanding Process Version Life Cycles
Process versioning allows different versions a process to exist in Process Server. Process versioning allows you to control when processes become effective and for how long. You can also control what happens to processes created by older versions when a new version becomes effective. While multiple versions of a process can exist concurrently, only the latest effective version can create new process instances.
The latest effective version is in an online state. Other states are:
•Online pending: describes versions that have an effective date in the future.
•Offline pending: describes versions whose expiration date has arrived, but running process instances are still active.
•Offline: describes expired versions that no longer have running process instances.
The process deployment descriptor (PDD) can contain a version element whose attributes describe how a deployment is versioned. These selections are all optional and have default values as described below.
The following example shows the syntax for version information in the .pdd file.
•effectiveDate is the date the new version becomes the current version and all new process instances run against it.
Depending on the disposition selected for running processes, some may continue to run until they finish using the older version. The effective date is an XML schema date/time value. The time expression includes a time zone, indicated as the midnight hour plus or minus the number of hours ahead of or behind Coordinated Universal Time (UTC) for the computer’s time zone. In the example above, the computer time zone is Eastern Standard Time, which is five hours behind UTC. If you do not provide an effective date, it defaults to the date and time the process is deployed to the server.
•expirationDate is the date, beyond the online date, the current version expires.
An offline version is not capable of creating new process instances. Once all of the running processes tied to an offline pending version complete, the version becomes offline. All process instances for the current version run to completion. The expiration date is an XML schema date/time value. (Same as effective date). If you do not provide an expiration date, the version does not expire until you manually set it to offline in the Application Integration Console or until a newer version is deployed.
•id is the process version number in major.minor format.
You do not need to provide a version number as Process Server auto-increments new versions. The server increments a version number by dropping the minor value and adding 1 to the max number. For example, version 1.5 increments to version 2.0.
•runningProcessDisposition is the action Process Server takes on any other versions of the same process that currently have processes executing after this version’s effective date arrives.
Values for runningProcessDisposition are:
- Maintain. All process instances for the previous versions should run to completion. This is the default value.
- Migrate. All running process instances created by previous versions will have their state information migrated to use the newly deployed process definition once its effective date arrives. If there are incompatible changes between the versions, descriptive warning messages are written to the Application Integration Console Server Log. Refer to the Migrating Running Processes when Warnings are Generated for details.
- Terminate. Indicates that all process instances running under previous versions should terminate on the effective date of the new version, regardless of if the process instances are complete.
Updating a Process Version
You can view this property on the Deployed Process Version Detail page.
The options for updating a process version are:
•Depending on the version status (Online, Online Pending, Offline, Offline Pending), you may be able to update the online date, offline date, and running process disposition. For example, you can add an Offline Date to the online version, and select Update.
•You can also set the Process Instance Retention Days and update the process version. For details, see Process Instance Retention.
The options for setting a process version offline or online are:
•To inactivate this version at a specified date and time, type in the values in the Offline Date fields.
•To inactivate this version immediately, select Set to Offline. No new process instances can be instantiated from this version. The status is Offline Pending until all running processes complete.
•If you had previously set this version offline, you may be able to restore it. To restore this version to the online or online pending (future) version, select the available option, Restore to Online or Restore to Online Pending.
Setting the Logging Level
You can set this property on the Deployed Process Version Detail page.
You can view or download an execution log for a running or completed process. An execution log provides start and end times for activity execution and helps you troubleshoot faulted processes. The following list describes the different logging levels:
•None: The Process Server does not log any information. Use this option to enhance engine performance.
•Fault: The Process Server logs only fault information. If no faults occur in a process, the Process Logging level defaults to None. Select Fault to reduce the size of the log file.
•Execution: This is the default option. The Process Server logs all execution statements except for Will Not Execute statements. Select Execution to decrease the size of the log file.
•Execution with Service Data: The Process Server logs all execution and fault information, as well as some WSIO activity information. For execution information, Process Server logs deadpath states, terminations, ready-to-execute, and so on. For WSIO, Process Server logs invokes, picks, and receives, but excludes information related to data assignment or changes.
•Execution with Data: The Process Server logs all execution statements except for Will Not Execute statements, but includes variable, expression, and partner link data. Select Execution with Data to decrease the size of the log file.
•Full: The Process Server logs all execution statements Will Not Execute statements for deadpath activities. For example, the Process Server logs all fault handling statements that are not executed.
•System Default: When you use this option, the logging level for the process version corresponds to the process logging level property that is set on the corresponding Process Server.
To improve processing speed, perform no logging or minimum logging. Informatica recommends that you use the None or Terse logging levels.
Persistence refers to storage of active processes. By default, when a process runs on the server, all state and variable data is stored in the Process Server database. However, this setting can be changed in the PDD file to increase server performance and reduce database size.
Persistence setting selections are as follows:
Setting
Explanation
Full (default)
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.
Persist
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.
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 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.
Brief
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.
None
No process information is stored in the server database when a process terminates. The process instance is not listed in the Processes page.
For invoke activities that do not complete because of a node failure, you can suspend the process upon recovery. The process is suspended at the pending invoke, and you can perform process exception management.
An individual process can override the engine setting with an entry in the Process Deployment Descriptor (PDD) file. The settings are:
Setting
Explanation
System Default
The current engine setting for all processes. The default engine setting is to disable invoke recovery; however, the current setting may be different.
False
Do not allow a pending invoke activity to suspend upon recovery. The process will terminate abnormally. This setting overrides the engine setting.
True
Suspend a pending invoke on recovery to put it in a suspended-faulting state. You can then perform process exception management on the invoke activity, followed by retrying or completing the faulting activity or scope. This setting overrides the engine setting.
Process Instance Retention
You can view the Process Instance Retention property on the Deployed Process Version detail page.
You can specify how long to keep completed and faulted processes in the Process Server database before deleting them on an automated schedule. This setting is available in the following locations:
•Process Deployment Descriptor editor in Process Developer. You can add the setting to a process’s deployment descriptor.
•The Deployed Process Version detail page of the Application Integration Console. Add or change the setting for a deployed process.
•The default retention days setting for all processes on the Application Integration Console. The setting for an individual process overrides this setting.
The retention setting applies to a process version with a status of online or online pending, and not to offline pending or offline versions. The schedule begins on the completed date or faulted date of each process, as shown on the Processes page. For example, if a process instance completes on December 31, and the retention setting is 30 days, the process instance is deleted from the database on the next scheduled deletion after January 30.
3If multiple versions exist, from the Deployed Process Detail page, select an online or online pending version to open the Deployed Process Version Detail page.
4In the Process Instance Retention field, specify the number of retention days, hours, or minutes for the process version.
5Select Update. The change takes effect immediately for all completed and faulted processes.
For details about scheduled database maintenance, see Storage.
Deployed Process Detail Graph
The Deployed Process Detail Graph page presents many details about a process instance:
•An Outline view shows the structural elements of a BPEL process. You can select an element to view its properties and values.
•A Graphic view shows the main process flow. If the process has event handlers, fault handlers, and compensation handlers, you can view them by selecting a tab. You can also select an activity to view its properties.
•A Properties view appears for a selected element. For example, when the Process element is selected from the Outline view, you can see process properties and their current values.
