Using the Queue instruction to run an activity asynchronously

Use the Queue instruction to start asynchronous execution of a second activity. The Queue instruction provides an alternative to the Call instruction, in situations where there is no need to wait for completion of the second activity, or where processing in parallel is feasible and beneficial.

Use the Queue instruction only when appropriate, where the queued activity can operate in a "fire-and-forget" style.

Use the Call instruction, not the Queue instruction, if parallel execution of the activity may introduce locking issues, deadlocks, race conditions or other concurrency risks into your application.
Use the Queue-for-Agent method, not the Queue instruction, to allow a background agent, operating as a separate process, to execute an activity asynchronously from the foreground processing, especially when locking is involved.
Like other processing that uses child requestors, this instruction requires a batch requestor from a limited pool. If using the queue instruction, set the agent/threadpoolsize value in the prconfig.xml file or Dynamic System Settings appropriately based on concurrency needs. Do not use this instruction if you have disabled child requestor processing by setting the agent/threadpoolsize value to 0 in the prconfig.xml file or Dynamic System Settings.

Parameters

The Queue instruction uses no parameters itself. Supply values for the parameters (if any) of the activity.

Parameter	Description
Activity (entered in the Method field)	Type `Queue` followed by one space and the Activity Name (second key part) of the activity to execute. Optionally, you can identify the Applies To key part of the called activity explicitly, using the format: Queue Data-Admin-Operator-ID.Analyze Queue MyCo-Finance-Work-Form990.Validate The explicit class format causes rule resolution to bypass all class hierarchy searches — the activity must be present in the specific class identified before the dot. (Other aspects of rule resolution operate normally.) Because use of explicit class names can introduce inflexibility, complicate debugging, and reduce opportunities for rule reuse, avoid this format whenever possible. When you save an activity, Queue steps that use this format cause a rule warning.
Pass current parameter page	Check to share the contents of the current activity with the queued activity (a form of call-by-reference). If checked, ensure that all needed input parameters of the queued activity are present with an appropriate value on this page before the Queue instruction occurs. Use care if you select this option. As both the calling and queued activities can update any `Out` parameter values on a common, shared parameter page, changes to the parameter page may occur in any order.
()	If Pass current parameter page is not selected, enter values for the input parameters of the activity. Input parameters that are required to have a non-blank value are marked with an asterisk.

Results

At runtime, the system uses rule resolution to locate and start the activity.

The activity does not receive a step page or a primary page.

Execution of the queued activity occurs asynchronously, in a child requestor. The execution progress of the two activities is not predictable and may vary from execution to execution.

Checking the method status

This method updates the pxMethodStatus property only if it fails. See How to test method results using a transition.

	transition
	Call instruction Connect-Wait method

Methods and instructions by function

Using the Queue instruction to run an activity asynchronously

Parameters

Parameter

Description

Results

Checking the method status