Object List
This section describes the purpose of the Object List object and its properties. Below you will find a general overview, followed by a detailed description of Object List Properties as they appear in the various Object List categories (tabs).
The Object List object serves as a collection point of one or more objects that you want to associate with a Job or Plan for related use. The purpose of this object is to allow this “associated list of ActiveBatch objects” to be shared by other related Jobs or Plans. This way if you need to add or remove an object, you make the change in a single object instead of having to modify many Jobs or Plans that are using the same embedded list.
The list of associated objects are used for two main purposes:
-
Service Library objects that must be associated so you can use their underlying Web Services methods in Jobs Library Job steps.
-
Any ActiveBatch object that you intend to access at run-time through variable substitution. It’s this second purpose that makes up the predominant use of the list. By including the object within an Object List, proper security can be determined when the object is associated. If the object is used at run-time and has not been placed in an Object List, an “access denied” will be issued and the run-time association will not occur.
Note: At this time, Schedule and Calendar objects serve no useful purpose within an Object List.
Objects are associated at the root of the Job Scheduler, and on Jobs and Plans. To associate an object to a Job, access the Job’s Associations property sheet, click on Associate, navigate to, then select the object you wish to use. To associate the object to the Scheduler root or a Plan, access the desired object's property sheet, click on Associate, navigate to, then select the object you wish to use. Alternatively, you can quickly associate the selected object to the desired Plan or Job by dragging the object (in the Object Navigation pane) and dropping it on the target object.
If you intend to associate the same objects between related Jobs and/or Plans you should consider making that associatiate using the Object List object rather than just embedding the Service Library within multiple Jobs or Plans.
To create an Object List, right-click on the desired container (Scheduler root, existing Folder or Plan) in the Object Navigation Pane, select New, then select Object List. When you’ve completed the Object List property settings, you must click the Save or the Save and Close button to save the Object List. Click the X on the tab of the New Object List if you wish to cancel the creation of the Object List. When you save the Object List, it will instantly appear in the Object Navigation pane (if auto refresh is enabled). To modify an existing Object List, right-click on the Object List in the Object Navigation pane, then select Properties.
General
This tab allows you to name and describe the Object List.
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 field indicates whether the object is enabled or disabled for use.
Read Only: This checkbox, when enabled, means the Object List’s properties cannot be changed. You must have “Modify” access permission to the Object List object to set this feature. To clear the read-only attribute, uncheck the box.
The Objects property sheet consists of associated objects (if any). In the example below, there are 4 associated objects. The Object ID, Name, and Full path are provided.
Associate: This button allows you to associate new object(s) to the Object List. After clicking on the button, the Associate dialog will appear as depicted in the image below.
Navigate to the desired object(s), click on the checkbox to the left of the object name, then click OK. The object(s) will be added to the Object List.
Disassociate - This button allows you to disassociate (remove) objects from the list. Select the object(s) you wish to disassociate, then click the Disassociate button. Use of the Ctrl or Shift keys to multi-select objects is supported.
Edit an associated object:
Select an object in the list, then double-click on it. The property sheets of the selected object will be tabbed in the Main view (providing you have the appropriate permissions granted to access the selected object).
The Analytics properties are depicted in the image below. This section details any changes made to the Object List object, and provides you access to the object's revision history.
This selection allows you to view the audits that are created when the Object List object is initially defined. Changes made to the object are audited.
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
User is allowed to read the object.
Write
User is allowed to write the object.
Modify
User is allowed to modify the object (Read + Write)
Delete
User is allowed to delete the object.
Use
Account is allowed to use the object.
Manage
Account is allowed to perform Enable/Disable operations.
Take Ownership
User is allowed to take ownership.
Change Permissions
User is allowed to change permissions for the object.
Full Control
All of the above access is enabled.
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.