Object Check-Out and Check-In
ActiveBatch supports multiple users connecting to a Job Scheduler and adding, modifying and deleting objects. If two or more users happen to access the same object at the same time, the check-in feature manages this. For example, if two users modify the same object but change different properties, the changes are merged when they are checked in (both changes are saved). Alternatively, if two users modify the same property(s), the check-in process considers this a conflict that must be resolved. This section discusses Check-out, Check-in and other related concepts.
Whenever you create a new object, modify an object or delete an object you will be performing a “Check-Out” operation. Whenever you attempt to apply that change (new, modify, delete) to the ActiveBatch Job Scheduling system you will be performing a “Check-In” operation. Check-Out and Check-In operations can be implicit or explicitly performed. Likewise, these operations can also be performed in an exclusive or non-exclusive fashion.
Implicit Check-Out/In
An implicit Check-Out is paired with an implicit Check-In. This means that when you open an object’s properties and begin to make a change, an implicit Check-out operation is performed (the check-out occurs automatically, under-the-hood). If you click the Save or Save and Close button to apply the changes, an implicit Check-in operation is performed. Finally, if you discard your changes, an implicit “Undo Pending Changes” operation will occur which effectively cancels the Check-Out.
Note: To modify an object, you need to be granted Modify rights to the object you are attempting to change.
As stated above, an implicit check-out will occur when you modify an object's properties by right-clicking on it, then selecting properties (see the image below that depicts the "Properties" menu item at the bottom of the list of menu options). An implicit check-out will also occur if you double-click on a job (in the Navigation pane), which when doing so, tabs the properties of the job in the Main view.
You can only modify an object definition. An instance (i.e. past Plan/Job/Reference) cannot be changed.
Explicit Check-Out/In
An explicit Check-Out is an operation performed before any modifying action is taken. In other words, as the word “explicit” means, you perform a Check-Out operation prior to creating, modifying or deleting any objects. See below the Check Out menu option.
Note: To modify an object, you need to be granted Modify rights to the object you are attempting to Check Out.
The Check-Out operation can be performed on one or more selected objects. When you select an explicit Check-Out the following dialog is displayed.
Explicit Check-Out offers you a choice of Exclusive or Non-Exclusive Check-Out. By default, the “Exclusive…” checkbox is not selected. This means your Check-Out supports collaboration. Others may also check the object out and make changes. If you elect to make the check-out exclusive, then no one else can have the object checked out (and no one can check out the object after you do).
While an implicit Check-Out can only be performed on a single object and is transient (meaning that once you decide to apply or discard changes, your check-out is ended), an explicit check-out can be performed on multiple objects and held until you decide (to either check-in and commit the changes or undo the pending changes).
When an object is checked out, its icon is changed in the Navigation pane. A green check mark appears to the left of the object's icon. This allows you to visually determine whether an object has been checked out by you.
Note: The icon denoting a checked out object is only seen by the person who performed the check-out operation. For others to see which objects have been checked out, please read the “Pending Changes” section.
Check-Out Restrictions
The following circumstances may leave objects as checked out regardless of any implicit or other operations.
-
Job Scheduler service is started during an Import operation.
-
Database service is restarted during an Import operation.
-
COM script is terminated during an Import operation.
-
An ActiveBatch job with an Import Object job step is aborted or otherwise terminated.
Pending Changes
To see a list of objects which are currently checked-out, click on the “Pending Changes” view. See Views > Developers > Pending Changes. The view will be tabbed in the Main view, as depicted in the image below.
Pending Changes View
This view shows all objects which have been checked out; both implicit and explicit. The figure above shows a single object that is checked out. The Filter option allows you to select a user who has objects checked out. The Pending Changes view is not real time refreshed so a Refresh button is available. Please note that any operations you issue against a checked out item also apply when the item is checked in.
Besides listing checked out objects (for all or a specific user) you can also use this view to Check-In object(s) or Undo Pending Changes.
Note: An ActiveBatch Administrator can Undo Pending Changes for any user. This can be helpful if an object has been exclusively checked out and needs to be freed.
Testing Pending Changes
When you’ve checked out various objects, ActiveBatch does provide a limit method of testing those changes before you check them back in.
To test checked out objects, you must issue a Trigger Advanced operation (a right-click menu option) and ensure the Test Pending Changes checkbox is selected. The checkbox will be enabled by default if the object you have selected is checked out. If the object you have selected is not checked out, but your intention is to test an underlying object, you must manually enable that checkbox.
With the Test Pending Changes enabled, any object that you have checked out will be used and subject to being triggered. If “Test Pending Changes” is not enabled, then all objects are taken from the Scheduler database (i.e. objects which are checked out by you will not be referenced).
Note: Selecting Test Pending Changes is limited to Trigger Advanced (the Trigger operation will always perform a Test Pending Change if the object has been checked out). You cannot test alternate scheduling (Date/Time, Events, etc.) because testing of checked out objects is limited to your scope. In addition, if you disable an object that is also checked out, it’s the checked out object that’s disabled; not the server version. Someone else who doesn’t have a checked out version of the object would need to perform operations on the server version.
Check-In
Checking objects in which have been explicitly checked out requires a Check-In operation. When you right-click on an object, a similar dialog to Check-Out will appear. Check-In does support multi-object selection. This means that just as you can check out multiple objects you can also check in multiple objects at the same time by simply ensuring they are selected when you request the Check-In operation.
A confirmation message box will appear to confirm the requested check-in.
Note: Note: When you create a new object and associate that object to an existing object, the newly created object may seem to have lost its association. In fact, it hasn’t but will only be seen once you explicitly check-in the newly created object.
Conflict Resolution
Since ActiveBatch allows you to check-out objects in a non-exclusive manner what happens when two (or more) people change the same properties in the same object? How does the system know what to apply? For that matter, what is a conflict anyway? If I add a variable “A” to a Plan and another colleague adds variable “B” to the same plan, is that a conflict? Finally, if a conflict is detected how does the resolution work? Whose change is applied?
First, let’s define “conflict” in terms of this section. A “conflict” occurs when two or more users modify an object’s property. If the property is a collection of properties, a conflict occurs when the same label is modified. For example, if I change the Description property in Job A and you change the User Account object reference in Job A; that is not a conflict. On the other hand, if we both change the Description property in the same object; it is a conflict. For collections, as in our variable collection, if you change “A” and I change “B” in the same job; that would not represent a conflict. If, on the other hand, we both changed “A”; that would represent a conflict.
When objects are checked-in, the object is compared to the original pre checked-in object to produce a delta of the differences made to the modified object. If the object is changed before you applied your changes (i.e. checked-in) ActiveBatch determines if a conflict occurred based on the rules noted above.
The above figure shows two different users who have checked out the same object. Unknowingly, user Testuser1 changes the working directory of job EOD to c:\testuser1 and has checked that change in. User Testuser2 is also in the process of making a change to the same object and property but intends to change it to c:\testuser2. When testuser2 checks the object in, the following merge conflict dialog appears.
The above dialog consists of two parts. The top portion contains one or more objects that are to be checked in but are exhibiting a property merge conflict. When you select an object to resolve in the top portion the bottom part displays the property(ies) in conflict. The properties are arranged in category order for ease of identification. The left part is the property’s value that is present on the server (or the Job Scheduler’s database). The right part is the property’s value (local) that is in conflict.
You have four (4) possible actions: (1) you can Cancel the merge entirely and research what the proper value should be (2) you can select the Server value (3) you can select the Local value or (4) you can change the “Local Value” to another value not represented by the Server or Local values.
In the middle portion of the property conflict area, you will see two (2) radio-style buttons side-by-side. Click on the appropriate radio button for the value you want to use. If many properties are present and you want to use all the properties from either the Server or Local object, note the checkboxes that appear and click the appropriate checkbox as a convenience. In that case, all the appropriate radio button will be enabled. As you resolve each conflict the number of “Resolved” conflicts located in the bottom left hand portion of dialog increases. Once all the conflicts have been resolved, the “Conflict” button will be enabled and you will be able to complete the check-in process.
Changeset
As you check in one or more objects, a changeset is created. A changeset is a collection of objects, usually related, that from an atomic change. In other words, the author intended for all these objects changes to be checked in together and if, for some reason, an issue arises, it may be that the entire set of changes need to be rolled back. You can view changesets on any object including the Job Scheduler itself by right-clicking at selecting “View…” followed by “Changeset History”.
In the above image, the left side panel shows each changeset. Each changeset consists of an ID, the username of the person who made the change (or import), the date and time the change was checked into the system, the number of objects that the change consisted of and a comment concerning the changeset itself. Selecting a changeset will cause the right-side window to display those objects that are included as part of that changeset. While Changeset History is useful for tracking the various changes made to one or more objects, you can also perform several operations on the changesets themselves. The operations are Rollback Changeset, Restore Changeset and Restore All.
Rollback Changeset applies to the specific selected changeset and rolls that back using the prior version of the object(s) in the changeset. In other words, the prior version of the object not the prior changeset.
Restore Changeset applies to the specific selected changeset and rolls back only those objects that appeared in the changeset from the latest changeset to the selected one. Any objects that do not appear in the selected changeset are ignored.
Restore All applies to the specific selected changset and rolls back all objects that appear in any of the changesets beginning with the latest changeset to the selected one. So unlike Restore Changeset, this operation will restore all objects back to a specific version that appeared on the system at a specific time.