pub.prt.admin:suspendProcesses

The service can be invoked either on a per-model basis or for all available models on a given Process Engine server. When this service is executed, the subscription triggers for the qualifying models are suspended and no new instances are created. In addition, any currently running instances are set to status = SUSPENDED. In the case of a cluster or a distributed Process Engine set up, the node that the service is invoked on is considered primary and it broadcasts the suspend action across all participating nodes that it is aware of.

ProcessModelID

String Optional. This is the process key for the model that the user wants to suspend. All versions of a given model are affected.

suspendAll

String Optional. Indicates whether or not the suspend action will affect all models or only the model that is specified as the value for the parameter ProcessModelID. The following values apply:

true — The ProcessModelID value, if provided, is ignored and the suspend action is applied to all available models, their corresponding process instances, and their subscription triggers.

false — Default. The suspend action is applied only to the process model defined in the parameter ProcessModelID (all process instances and subscription triggers).

message	String Optional. Displays any exceptions encountered during the service call.
success	String Optional. Returns one of the following: error — Indicates that one or more exceptions occurred during the service call. true — Indicates that the service call executed without any exceptions. It does not indicate that all internal tasks initiated by the service call have run to completion. To verify that the suspend action is complete, refer to the Usage Notes section.

This service is intended for use during scheduled maintenance periods that require processing to be paused for some duration of time. The service may be used to suspend processing in bulk, impacting either a single process model or all available models on the system.

The service affects all versions of targeted process models, and in the case of a cluster or distributed set up, the suspend action is relayed to all participating nodes. To suspend only a specific model, users can invoke this service and provide the appropriate value for the ProcessModelID input parameter. To suspend all models on a given system, invoke the service by setting the value of the suspendAll parameter to true.

The service suspends subscription triggers for all targeted services. Note that when the triggers are suspended, the change to the trigger state is persisted through subsequent server restarts. Transition triggers are not suspended, and some preliminary transition trigger processing may occur as the result of incoming documents. Incoming documents directed to suspended models will be cached until such time as the model is resumed.

This service may not work as expected for environments or process models that use volatile tracking. In this case, the suspend feature relies solely on the Process Engine cache in RAM to determine the instances that will be affected. However, due to its dynamic nature, the Process Engine cache may be momentarily out-of-sync, especially following a server restart or a package re-load. In such cases, suspending at the instance-level using webMethods Monitor may be the only alternative.

The suspend action is a series of independent tasks across all participating nodes. To verify that the suspend action is indeed complete, the users are advised to use the following actions:

Use the webMethods Broker (deprecated) trigger management page (Settings > Messaging > Broker/Local Trigger Management) in the IS Administrator interface to verify that all the qualifying subscription triggers are enabled.

Use the IS Administrator Service Usage page (Server > Service Usage) to ensure that there are no currently running threads. This may happen if there are any long-running services that are waiting to finish.