OnDemand Queue

ActiveBatch provides a special built-in Queue named OnDemand. The OnDemand Queue is a type of Execution Queue An Execution Queue identifies the system where a Job will run. The system is specified in the Execution Queue's Machine property. The system entered in this property must have an ActiveBatch Execution Agent installed on it. When a Job is associated to an Execution Queue, it will always run on the system specified in Machine property, unless a manual override is performed (for example, using an instance's "requeue" operation) that is not associated with a machine. The OnDemand Queue cannot be deleted, copied or moved. It can be renamed, although its label cannot be changed.

 

There are 2 purposes of the OnDemand Queue.  Let us look at the first use.

 

Assume you wrote a script to start up a Windows Service for a machine. If you wanted to execute the Job on a specific machine, you would associated the Job to that machine’s Execution Queue. But what if you didn’t know what machine would need to run your script until just before the Job is to execute? The Trigger (Advanced) command provides you with the ability to specify a Queue when the Job is triggered. This means you could associate the Script Job to the OnDemand Queue, save the Job, then later issue a Trigger (Advanced) command specifying what Queue (machine) the Job instance should execute on. The instance would be instantiated on that Queue (the Job definition would still be associated with the OnDemand Queue). This means that you could have the same script run on different Queues (machines) at the same time, based “on demand”. To access the Trigger (Advanced) feature, right click on the desired Job in the Object Navigation Pane, then select Trigger (Advanced). A Trigger dialog window will appear, allowing you to select the Queue from a dropdown list.

 

Note: Jobs never execute on the OnDemand Queue. When manually triggering a Job associated to the OnDemand Queue, you must perform a Trigger (Advanced) operation and specify the Queue.

 

Next, there is another important use for the OnDemand Queue. Assume the first Job in a Job stream is associated with a Generic Queue A Generic Queue represents one or more Execution Queues. Each Execution Queue points to a system where ActiveBatch jobs run. Each system must have an ActiveBatch Execution Agent installed on it. When a Job that is associated to a Generic Queue is triggered, it will run on one of the Execution Queues that is a member of the Generic Queue. One of the key purposes of a Generic Queue is it supports Execution Agent high availability (active-active). Should one Agent and its assigned Execution Queue go offline for maintenance purposes or for unknown reasons, the surviving Execution Queue members of the Generic Queue can pick up the load. When a Job is associated to a Generic Queue, it means can run on more than one system - that is, it can run on members of the Generic Queue. On a per Job basis, you can set Job properties limiting the Execution Queue members the Job can run on, if desired. . It is associated with a Generic Queue because you would like to provide the Job with the flexibility to run on any member Execution Queue defined within the Generic Queue. When the first Job is triggered, the Job Scheduler will figure out which member Execution Queue to dispatch the Job to. That said, if you require following Job(s) to run on the same Execution Queue as the first Job, you can associate the following Jobs to the OnDemand Queue. When doing so, the following Jobs will automatically run on the Queue that the first Job ran on.

 

For example, assume JobA is associated to GenQ (a Generic Queue). GenQ has two Execution Queue members (EX1 and EX2). When JobA triggers, it can run on EX1 or EX2. For this particular instance, assume JobA executes on EX1. JobB, which is to follow JobA in the stream, must also execute on the same machine as JobA. This is simply a requirement you have. Perhaps JobA creates a file on the Agent system where it ran, and JobB needs to access it. The problem is how do you specify that JobB must run on the same Queue as JobA? If you associate GenQ to JobB, you would have a 50-50 chance of getting it to run on EX1. If you associate EX1 or EX2 to JobB, it would always run on the assigned Queue, so that is not a solution either. This is where OnDemand Queue becomes useful. By associating the OnDemand Queue to JobB, you are essentially saying “wherever the previous Job ran - that is where I want JobB to run as well”. This type of action is only available when a Job is triggered using Completion Properties (i.e. using a Completion Trigger A completion trigger provides the ability for a Job or Plan to trigger another Job or Plan after it completes. You can determine which jobs or plans to trigger based on how your Job or Plan completes. For example, you can trigger one set of jobs if your Job completes successfully, and another set if your Job fails. ). In this example, JobA would have a completion trigger configured to trigger JobB.

Security Implications of the OnDemand Queue

ActiveBatch provides several different access permissions for Jobs which are “triggerable”. First, an ActiveBatch Job must support the Trigger command, which means the Enable Manual Trigger property must be enabled (checked) to allow a user to issue a trigger command using AbatConsole or another user interface - for example, using the command-line utility).  iEnable Manual Triggers enabled by default. The Enable Manual Trigger checkbox is located on the Triggers property sheet of Jobs and Plans.

 

Note: Prior to ActiveBatch V10, the Enable Manual Trigger property was named ActiveBatch Event Triggers and had the same meaning. It was renamed for clarity purposes.

 

Next, you will want to control who can Trigger a Job and what Trigger features can be enabled. The Trigger security permissions are described below. These permissions are located on the Security property sheet of every Job.

 

Trigger

This level of access simply means that a named user or group is allowed to Trigger the Job (right-click on the Job in the Object Navigation pane and select Trigger). No other aspects of the Job can be changed. Trigger level access permission alone is not adequate if you are attempting to trigger an OnDemand Job - since a major requirement is the ability to specify a Queue for the Job to execute on.

Trigger w/ Queue

This level of access allows a user to both trigger and specify a Queue that the Job instance should execute on. This access permission is what is typically granted to a user who must trigger a Job associated with the OnDemand Queue. The user can now both trigger and specify a Queue (machine) for execution (right-click on the Job in the Object Navigation pane and select Trigger (Advanced), then select a Queue). Since the Trigger command requires access permissions, a very nice benefit can be obtained from letting other users issue a Trigger command. Let’s look at our earlier example on starting a Windows service. Normally starting a service would require Administrator level access and most administrators (with good reason) won’t just add a user to that group even if, on occasion, there’s justification in doing so.  On the other hand, what if you (an administrator) could submit a Job to the OnDemand Queue and allow a normal user the ability to trigger your Job for execution on their machine?  That way you wouldn’t have to give them your security credentials (a bad thing) and you wouldn’t have to add them to any Admin groups. That is precisely what Triggering an OnDemand Job allows. You simply submit a Job with your security credentials to an OnDemand Queue and allow (using ActiveBatch security) one or more users to issue a “Trigger with Queue” Advanced Trigger.

Trigger w/ Parameter

This level of access indicates that a user is allowed to trigger a Job and pass a new set of input parameters and/or variables to the Job instance. The permission only references "parameter" (it is listed as "Trigger w/Parameter" in the UI), but this permission, as stated above, also allows a user to modify variable values. The user must right-click on the Job in the Object Navigation pane and select Trigger (Advanced).  The Parameters and Variables options are part of the Trigger dialog.

Trigger w/ Credential

This level of access indicates that a user is allowed to trigger a Job and pass a set of security credentials that are to be used for this specific Job instance. By allowing different access permissions for the Trigger command, a Job designer can precisely indicate what can be triggered and where the Job can execute. To run the Job under a different User Account, the user must right-click on the Job in the Object Navigation pane, then select Trigger (Advanced). The Account Information to Run Job Under is an option in the Trigger dialog.