Execution Queue Object
This section describes the purpose of an Execution Queue object and its properties. Below you will find a general overview, followed by a detailed description of Execution Queue Execution Queue Properties, as they appear in the Execution Queue categories (tabs).
An Execution Queue identifies the machine where Jobs will run. The machine must have an Execution Agent
installed on it. The Job Scheduler uses the Execution Queue's machine property to identify what Agent system to connect to, in order to dispatch Jobs to it. The Scheduler-to-Execution Queue (Agent) connection is continuous, unless you stop either application (i.e. stop a Windows Agent service for maintenance purposes). Upon the creation of an Execution Queue, or the modification of an existing Execution Queue's machine property, or the disconnect of the Queue (e.g. a network problem), the Scheduler automatically attempts to connect to the system identified in the Execution Queue's machine property, until a connection is established (there is no time-out). In the case of a Job Scheduler service start up, the system automatically connects to all the Execution Queue's Agent systems. If there is a problem connecting to a system, the Execution Queue will display an icon next to it that indicates a connection has not been established.
An Execution Queue is a shared object that can be associated with Jobs and Generic Queues.
To add a new Execution Queue, right-click on the desired container (Scheduler root, existing Folder or Plan) in the Object Navigation pane, select New, then select Queue, then Execution Queue. The label of the new Queue must be unique to the container where it is being added. When you’ve completed the Execution Queue property settings, you must click the Save or the Save and Close button to save the Queue. Click the X on the tab of the New Execution Queue if you wish to cancel the creation of the Queue. When you save the Queue, it will instantly appear in the Object Navigation pane (if auto refresh is enabled) and should be ready for operations (if it goes into a "Started" state - meaning the Job Scheduler was able to successfully connect to the Agent system identified in the Queue's "machine" property). To modify an existing Queue, right-click on the Queue in the Object Navigation pane, then select Properties.
The image below depicts the General category for Queues. These fields describe the common aspects shared by all Queues (including Generic Queues).
Name: This mandatory property represents the name of the object. The name is limited to 128 characters. The object’s name should be unique to avoid confusion. We recommend that it also be somewhat descriptive so it’s easy to find. The name is used (by default) to identify the object in the Object Navigation pane and other places in the UI. This can be changed to the label, if desired. See "Display Mode" in the General Settings
Label: Every object must be uniquely labeled within the scope of the namespace. The label is limited to sixty-four (64) characters. The label is typically the same value as the name (it is auto-filled to match the name you enter); however, uniqueness is always enforced for an object’s label. The label is recorded in the ActiveBatch namespace. The characters that may be used for the label property are restricted to alphanumeric (A-Z, a-z, 0-9), space, period (.), dash (-) and underscore (_). The label itself must begin with an alphabetic character. The label is typically used when scripting. All searches are case-insensitive. ActiveBatch does allow you to search for objects using either the label or the name properties.
ID: This is a unique read-only number that can be used to retrieve the object. Is it assigned by the system when a new object is saved.
Full Path: This read-only property provides the full namespace specification of the object. It consists of the container(s) the object has been placed in, with the object’s label appended to the end. For example, the fullpath: /IT Jobs/Nightly Run/<object label>, is such that IT Jobs is a root-level Folder, Nightly Run is a Plan, followed by the label of the object you are creating.
Description: This free form property is provided so you can document and describe the object to others. The description is limited to 512 characters. Clicking on the pencil icon will pull up a mini text editor where you can more easily enter your description.
State: This read-only field indicates the current state of the Queue. See below the States of a Queue. See also Managing Queues.
State Description Started
Queue is started and can dispatch Jobs.
Starting
Queue is starting, however, Jobs cannot be dispatched due to unavailability of the Execution Agent (Agent is not running, its port is blocked, etc.). During this time, the Scheduler will continuously attempt to connect to the Execution Agent system identified in the Queue's machine property. When a connection is made, it will change to a Started state.
Stopped
Queue is stopped. Jobs cannot be dispatched to a stopped Queue. However, they will queue up when triggered and wait for the Queue to be started again. After the Queue is started, any waiting Jobs will start to be dispatched.
Closed
Queue is closed. Jobs cannot be dispatched to a closed Queue. They will not queue up if a trigger occurs. It is considered a "missed trigger" should a trigger occur for Job(s) associated with a closed Queue.
Read Only: This checkbox, when enabled, means the Execution Queue's properties cannot be changed. You must have “Modify” access permission to the Execution Queue object to set this feature. To clear the read-only attribute, uncheck the box.
The image below depicts the Properties pane for an Execution Queue.
Machine: This mandatory field indicates the machine that will be used to execute Jobs submitted to this Queue. You may enter any valid machine name, IP address or ActiveBatch Execution Agent published name. An ActiveBatch Execution Agent published name is one that has been published via Directory services. To indicate that this is a published name, enable the Active Directory Published Name checkbox. Alternatively, the syntax is AD://published-name. The Directory button allows you to find all published Execution Agents.
Note: Publishing an Execution Agent to a Directory Service requires a separate installation to extend the schema for AD or AD LDS. The installation kit can be downloaded from the ASCI website. Publishing Agents and other ActiveBatch components is optional.
If you are using the ActiveBatch VM-aware Host-based licensing model, then enable the Use VM-aware Host Licensing checkbox or alternatively, the syntax when specifying a host-name or IP-address is VM://host-name (or IPaddress). When both checkboxes are enabled for a published name and VM-aware host licensing, the syntax is VMAD://published-name. This syntactical difference is purely to let ActiveBatch know which licensing model is to be used for this machine.
Authentication Mode: ActiveBatch supports both non-encrypted and encrypted communications between the Job Scheduler and its Execution Agents. This facility allows you to select either the Job Scheduler default (which the ActiveBatch Administrator can set to either non-encrypted or forced encrypted) or encrypted SSL communication. When SSL encryption is selected, the ActiveBatch Administrator can also select whether valid SSL certificates must be in place for both the Execution Agent and the Job Scheduler machines. This can be important when one of these machines are on the Internet and you’re concerned about spoofing.
Auto Close/Stop: These options allow you to automate the stopping or closing of a Queue.
Close from… to…: This “from” and “to” time range indicates when a Queue is closed, during which time Job instances may not be submitted to a closed Queue (Job definitions may still be associated with a closed Queue). If jobs are triggered and the Queue is closed, it will be considered a "missed" trigger, where nothing will happen. The Job will not run, and the Job will not wait until the Queue is opened again. To enable this feature, click the checkbox and then enter a “from” and “to” time range. When configured, the Queue actions will occur every day of the week.
Stop from… to…: This “from” and “to” time range indicates when a Queue is to be stopped. Jobs that trigger when a Queue is stopped will Queue up and wait until the Queue is started again. To enable this feature, click the checkbox and then enter a “from” and “to” time range. When configured, the Queue actions will occur every day of the week.
Note: Stopping or closing a Queue does not impact jobs that are currently executing on the Queue. They will continue to run to completion.
Note: A more powerful facility to Stop and Start an ActiveBatch Queue exists within the Jobs Library (see the ActiveBatch category of Job Steps). You could associate the Jobs Library Job to a Schedule, therefore allowing more granular control of the days of the week the Queue actions should occur.
See also Managing Queues
Priority Fence: This property indicates a Job’s Queue priority (not the OS priority) that must be greater than that specified in the priority fence for the Job to be eligible for initial dispatch. For example, a Priority Fence of 100 means that only Job’s whose Queue priority is 101 or greater are initially eligible for dispatch. This property may be dynamically changed as required when processing a Job marked as “SLA” when the deadline appears to be in danger of being breached. The default value of zero (0) means that every Job’s Queue priority will allow passage through the fence.
Executing Job Limit: This field indicates the maximum number of Jobs that may simultaneously execute on this Execution Queue. A number from 1 to 32767 may be selected. The default is five (5). This number should be adjusted based on the types of Jobs you will be running. Please note that too high a number may have an adverse effect on overall execution machine performance.
Machine Characteristics: This read-only section indicates the static characteristics of the machine you’ve selected for this Execution Queue. Generic Queues use this information for selecting the most appropriate execution machine for a Job. This section will be blank until the Execution Queue is actually created and started.
User Characteristics: This section lists the current user characteristics associated with this Queue. Generic Queues use this information for selecting the most appropriate execution machine for a Job. To add a user characteristic, click the Add button. To edit or remove a user characteristic, select the characteristic from the list and click the Edit or Remove buttons. To obtain the current value of characteristics, press the View Values button.
The image below is displayed when you want to add or edit a user characteristic. User characteristics are uniquely named within a single Queue. Typically you will add the same named user characteristic to one or more Execution Queues associated with a Generic Queue. The purpose of user characteristics is to allow a Job that has been submitted to a Generic Queue to directly influence which machines should be considered eligible for running a Job.
Special reserved user characteristics beginning with the prefix ABAT$ are reserved to Advanced Systems. ABAT$QAFFINITY allows a user to select a preferred Execution Queue when that Queue is a member of a Generic Queue. This functionality is most appropriate when the Generic Queue represents a cluster.
Name: Enter a name which will represent this characteristic. The characteristic must be uniquely named only within the same set of Execution Queue queue members of a Generic Queue.
Description: A description for the user characteristic.
Type: You must select whether the characteristic value is a numeric or string value.
Value: This will represent the source of the value for this User Characteristic.
Constant Value: If this radio button is selected, a static value (integer or string depending on the Type) that is associated with the characteristic.
Active Variable: If this radio button is selected, the characteristic is populated from a data source. The characteristic can be populated more than once depending on the “Re-evaluation Rule”. The data source specification is identical to that of an Active Variable. Clicking on the dropdown handle produces a tree showing the various categories and Active Variable data sources available.
Credentials: All ActiveVariables are executed under established and explicit security credentials. This dropdown lists the eligible User Account objects that can be used. The two buttons to the right allow you to manage and/or create User Account object(s).
Re-evaluation Rule: A characteristic can be re-evaluation or re-populated. If Expires is greater than zero (0) the characteristic is re-evaluated every n seconds. If Never (Set once only) is specified the characteristic is populated only once.
Prior to V12, User Characteristics could only be expressed as constant value. Beginning with V12, User Characteristics can now be constant value or dynamic (through Active Variable). This dynamic characteristic feature allows you to use a variety of data sources in which to set a value. As the purpose of Characteristics is to influence workflow scheduling by indicating what resources need to be available in which to best execute a workflow, the dynamic aspects of characteristics are very powerful and very helpful.
For example, using Characteristics, you could use software discovery to indicate which class of machines (Queues) a given workflow could execute on; how much free space must be on the C: drive for a workflow to operate properly, etc. While constraints may serve a similar purpose, remember that a Characteristic is analyzed prior to selection of a machine. A constraint is analyzed once the machine has been selected.
Best Practice: When specifying User Characteristics (especially Dynamic), specify the characteristic on the Generic Queue. When dynamic characteristics are specified on a Generic Queue the system will evaluate that characteristic in the context of each Execution Queue member. User Characteristics specified on an Execution Queue have precedence over the Generic Queue and can therefore act as an override.
Variables are one of the most important and powerful aspects of ActiveBatch. Below you will find an image of the Queue's Variables category.
With variables you can pass data to other related Jobs as well as form constraints for proper execution of related Jobs. ActiveBatch variables represent data that can be passed to Jobs, Plans, programs or used anywhere variable substitution may be used within ActiveBatch. A variable can be exported to a Job by enabling it as an environment variable. The image above displays any variables associated with the Queue. The image depicts a simple constant variable named log_path that is being used to specify the location of log files.
Variables have the following order of precedence: Queue, User Account, Job, and containers (Folders/Plans and the root - starting with the parent container first). This means that the value of a variable associated with a Queue will have the final say as to that variable’s value. This is true because the system checks the Queue's variables first, to see if a referenced variable has been defined on the Queue. If it finds it there, the system stops searching for the variable definition and substitutes the variable with the value defined on the Queue. For example, suppose you wanted to assign a special directory to a variable when a Job is to run on a particular machine (or Queue). The above figure shows such a variable. Log_path might have been defined to a user’s profile directory within a Job or Plan. This facility (defining variables on a Queue) allows you to override on a machine or Queue basis.
Note: The variable resolution precedence, as described above, can be overridden by using special variable syntax that directs the Scheduler to go to a specific location to find the variable definition. See Overriding variable resolution order of precedence for more information.
You can associate alerts with a Queue. The purpose is to potentially alert you or others in the event of a Queue status change. You can embed the alert on a per-Queue basis, or share alerts among multiple Queues by creating an Alert object and associating the Alert object to the desired Execution Queues (using the Alert object is recommended, when possible).
The alerts for Execution Queues are:
Alert Description Object Modified
Object Definition has been modified.
Queue Starting
Queue is starting.
Queue Started
Queue has started (and is operational).
Queue Stopped
Queue has stopped.
Queue Connected
Queue is connected to Execution Agent.
Queue Disconnected
Queue is disconnected from Execution Agent.
Queue Closed
Queue is closed.
Queue Opened
Queue is opened.
Using this feature you can generate an e-mail, or any other supported action, if a Queue goes into one of the above states.
The Analytics properties are noted by two (2) sections: Counters and Audits, as depicted in the image below.
ActiveBatch maintains performance counters for all Queue objects. The counters fall into two categories: Operational and Historical counts.
Operational counts are those that accurately describe the current state of the Queue.
Historical counts are those that are accumulated while the product has been actively running.
Two (2) representations of the counters are shown: List and Graphical. As the counters are statically displayed, clicking the Refresh button allows you to retrieve the latest data.
There are two buttons relating to the counters. Clicking the Reset Averages button allows you to reset the average time counters. Clicking the Reset Counters button allows you to zero the historical counters.
You can examine the audit trail for a Queue. The audit trail contains all state changes or modifying operations made to a Queue.
The Audits panel includes controls that allow you to filter the audits based on start and end dates. You can also limit the audits retrieved to a maximum number. The refresh button allows you to retrieve any audits that were generated after this dialog was initially displayed.
Each audit is contained in a single line in date and time sequence. Audits are read-only and cannot be modified. An icon appears at the beginning of each audit to help visually signal the severity of the audit. If an audit policy
Opening an audit item (by double-clicking on the item), depending on the nature of the audit, will sometimes reveal additional information concerning the audit.
The Copy to Clipboard button copies the contents of the retrieved audits into a copy buffer that you can later paste into a document or other program.
The Print button allows you to print the retrieved audits.
The Revision History button allows you to select one or more audits concerning changes made to an object and perform a difference operation between the selected revised objects.
This tab is where object security is configured. Security in ActiveBatch mirrors how security is granted using Windows security. That is, permissions applicable to the object (Read, Write, Modify, Delete, etc.) are Allowed or Denied for the Active Directory users and/or groups assigned to the object.
When new objects are created, they will either be assigned factory default
When a default policy has been used to preset object security, the new object will either have:
The Inherit Security from Parent Object property checked (it is not checked by default). When checked, the listed users and/or groups along with their permissions granted will be read-only. The Add and Remove buttons will be disabled because security is being inherited from the object's parent container. When Inherit Security from Parent Object is checked, it is likely the ActiveBatch Administrator will be setting up security on parent container(s), and the Job author will not have to modify anything about security. This would require a larger discussion with an ActiveBatch Administrator who it typically tasked to manage object security, since there are options.
The Inherit security from Parent Object property is not checked. The users and/or groups are listed along with their permissions granted, but there is likely some differences when compared to the factory default security, since the purpose of setting a default policy for security is to add Active Directory groups and/or users (and their access permissions) that are specific to your organization. Since Inherit Security is not checked, the Add and Remove buttons will be enabled. When this is the case, Job authors will need to be advised if there needs to be any changes made to security when they create new objects.
As a best practice, it is best for an ActiveBatch Administrator to preset security using a default policy (for all object types) so Job authors do not have to manage security, which can be time consuming and error-prone. See the ActiveBatch Installation and Administrator's Guide for more best practice information regarding object security.
Below is a list of permissions related to this object.
Access
Description
Read
Account is allowed to view all properties of the Queue (properties and variables)
Read Properties
Account is allowed to view properties of the Queue
Read Variables
Account is allowed to view variables of the Queue
Write
Account is allowed to write to the Queue
Modify
Account is allowed to read/write any properties of the Queue (Read + Write)
Delete
Account is allowed to delete the Queue
Take Ownership
Account is allowed to take ownership of the Queue
Use
Account is allowed to submit Jobs to the Queue
Manage
Account is allowed to perform operations on the Queue (Enable/Disable or Start/Stop, Open/Close)
Change
Permissions
Account is allowed to change permissions (set security) on the Queue
Full Control
Account may issue all of the operations mentioned above
The owner of an object is always granted Full Control by the system, and their permissions cannot be changed or reduced. If another user takes ownership, then the original owner's access will depend on how security is set up (if they are a user or group that has been given access). The new owner will automatically be granted Full Control, and once again, their permissions cannot be changed or reduced.
To take ownership, you will need to be granted the Take Ownership permission. Click the Take Ownership button and confirm the action. Another way to take ownership is to right-click on the object in the Object Navigation pane, then select Advanced > Take Ownership.
To modify security, you need "Change Permissions" security granted.
The Deny permission is generally used for users who have been granted access based on a group membership, but there is a need to override this for a particular user. Deny takes precedence over Allow.
Below you will find the instructions on how to modify security when Inherit Security from Parent Object is not checked.
To edit an existing account, select the listed user or group, then change the permission using the Permissions list box (Allow or Deny access).
To remove an existing account name, select the listed user or group and click the Remove button.
To add a new user or group, click the Add button and follow the dialog as depicted in the image below.
The dialog is similar to that of other Windows objects, and leverages Active Directory services. The Locations button allows you to select either the Job Scheduler machine or any applicable domain. Clicking the Advanced button allows you to search for specific users and/or groups. Alternatively, you may enter object names (a user or group) in the large edit box. Clicking the Check Names button allows you to validate the accounts. Click the OK button to add the selected Account to the object’s security list.