Administration Console > Monitor > Process Monitoring

Process Monitoring

The Monitor menu in the Process Console provides access to process, task, and server monitoring options that include:

Active Processes

The Active Processes page shows a list of process instances that are executing or completed, along with the process version. States can be Running, Suspended, Completed, Compensatable (for a subprocess), or Faulted.
From the Monitor menu, choose Process Monitoring > Active Processes.
Select filter criteria to select specific processes. For details, see Using Selection Filters for Active Processes . For a Secure Agent, you can also show/hide system processes. For the Cloud Server, you have an option to hide/show both system and public processes.
Click Submit to view all processes or those that meet the filter criteria, if any.
After you submit the selection options, a list of Active Processes displays, as shown here for a Secure Agent:

Alarm Queue

Under Selection Filter, select these Alarm Queue options to determine which process activities appear when you view active alarms in the On Alarm list:
Deadline Between
Beginning and Ending date and time for alarm.
Process ID
Process instance ID. You can find this ID on the Active Processes page (see Examining Processes for more information).
Process Name
Local part of the process-qualified name (qname) .
The Group this process belongs to (optional). The Group name displays in the On Alarm list.
Hide System
Uncheck to display the default System processes. The System processes are hidden by default.

Receive Queue

View a list of active receive, onMessage, and onEvent activities. These activities are queued for incoming messages.
Receive Queue
Use the controls on this page to set the size for how many queued receives to hold in memory to reduce the number of queries to the database. Sizing depends on server memory constraints.
The information at the top of the page is as follows:
Unmatched Correlated Receive Timeout
The amount of time (in seconds) that the engine waits for a correlated message to be matched to a receive activity. This is only if the message arrives before the activity becomes active. If a correlated message takes longer than the specified time to be matched, the engine discards the message and you see a correlation violation exception
The default value is 30 seconds. To avoid a large number of unconsumed messages on the server, set this value to a low number to avoid a large number of unconsumed messages on the server. If you set this value to specify zero seconds, the engine discards all unmatched correlated messages immediately.
When you click the Clock icon, you see the duration-chooser dialog box.
For more details, see Server Properties.
Unmatched Correlated Receive Count
The maximum number of unmatched correlated receives the engine will hold in memory at a time. When this limit is crossed, the engine rejects unmatched correlated receives; starting from the oldest, to make room for newer receives. For more details, see System Performance.
Queued Receive Cache Size
The size of the cache memory that holds activity information when the system is busy with other requests.
You can also change any of the values displayed for these three fields.
If events are displayed, select a receive and then select a partner link to view details. A window opens where you can see the BPEL process location in which the receive activity executes. You can also see the correlation property alias and data, if any, associated with this receive activity
If you click on:
The information displayed for a receive queue item is:
Process ID
Process Instance ID. You can find this Id on the Active Processes page.
Partner Link
The partner link for the item in the receive queue. A partner link is a communication exchange between two partners. In the most basic form, the process is a partner link of an external service, receiving a request from it. A partner link defines the role that the process plays (if any) and the role that the partner service plays (if any) in the particular exchange
Port Type
The port type, which is a port type in WSDL is a set of related operations such as receive, reply, and invoke include operations.
The operation that just executed.
Note: Receives for system processes, especially for Human tasks, are not displayed, unless you ask for them by partner link name or Process ID.
Selection Filter
Select one or more options from the Selection Filter option list to view a selection of active receives. You can find this information on the page, which shows the BPEL source code
You do not need to enter the fully qualified name for the operation.

Dispatch Service

To see the Dispatch Service option, first select an agent from the Console.
Occasionally, a service has a heavily used process with one-way operation requests (as opposed to request-response types). One-way requests follow a fire-and-forget semantic that dispatches requests to the engine as fast as possible and does not wait for a reply. During runtime, if many thousands of these requests, plus request-response requests, try to execute simultaneously, the result can either be an overwhelmed invoked service or resources on the server.
You can solve this problem by using a Request Dispatch Service. This service controls the maximum number of concurrently executing requests by putting requests in queues and dispatching them in batches. It also controls the number of new requests dispatched while allowing running processes to complete.
The dispatch service applies to all inbound requests except for subprocess invokes.
Process Server has a default dispatch configuration. In addition, you can create a dispatch configuration for a service or process group. In a multitenant-enabled versions of Process Server, you can configure the service for each tenant.
You can also create your own configuration by selecting Monitor > Process Monitoring > Dispatch Services and then pressing the Add Configuration button.
At runtime, the dispatch configuration used for a request is chosen based on matching the configuration name in the following order of precedence: Service Name, Process Group, Tenant, System Default.
A dispatch server applies to all inbound requests except for subprocess invokes.