Organizing ActiveBatch Objects

As you look through the ActiveBatch manuals and learn about all the various ActiveBatch objects that can be created, a question you will ultimately need to answer is “How do I best organize all the related objects that my business application needs?” This section will help you answer that question using best practices.

 

It is recommended that you place all the objects your plans and jobs may need within an organizational plan or folder. This has several benefits other than organization. First, if you ever need to migrate objects, moving the plan and/or folder with everything contained is much simpler and less prone to error than migrating each object individually (which can be further problematic when objects have dependencies). Second, when testing, you can always delete the plan or folder and know that everything inside the object will also be deleted. Next, add jobs to plans with the intent on triggering the plan. Plans are triggerable, folders are not.

 

 

In the image above, you can see the folder named Database Jobs. In this folder, a folder named Objects contains the non-executing objects. By ‘non-executing’ we mean those objects that are not executed (like a plan or job). Therefore, non-executing objects are user accounts, queues, schedules, alerts, etc. By adopting this convention as a Best Practice, it becomes very simple to find objects regardless of the application. In general, keep the non-executing (shared) objects "close" to the jobs and plans that are using them. In the above example, the non-execution objects are stored in the Objects folder, and the (3) plans are using some or all of the objects stored there.

 

The three (3) plans named Plan A, B, and C are meant to be triggered and consist of other nested plans and/or jobs. ActiveBatch supports the referencing of an object anywhere within the namespace (assuming, of course, your security permits that access). For example:

 

 

Observe the path specification to “LocalAgent”. Clicking on the Queue dropdown would reveal the navigation tree for the currently connected Job Scheduler. Within this tree you could select any queue (assuming the above example) within your system. The point we are making is that Folders and/or Plans do not have to be isolated.

 

For those users who do want a level of isolation, Virtual Root is the facility you will want to examine. Briefly, Virtual Root is a feature that allows users to connect to either a plan or folder object (a folder object is recommended). When connected this way, the user's scope is limited - regarding what they can see and access in the Navigation Pane and Instances views. Regarding the objects, users will see the contents of the connection point (child and nested child objects of the connection point). If you organize your objects as described above, it does make using a virtual root connection more viable, because the non-executing objects will be "in-scope" to the connection point (this is true, when using the above example image and connecting to the Database Jobs folder). If all the non-executing objects are child objects of the connection point, they will be accessible to the end-user connecting to a virtual root.

 

Assume a user is connecting to the Database Jobs folder using the virtual root feature. When they view a job's queue, they will not see the connection point folder name in the queue dropdown, but rather, they will see the child objects of the connection point. Since the queue and user account is stored in the Objects folder, you see that folder name followed by the queue and user account name. Observe the difference between the image below (connected to the virtual root) and the one above (when connected to the Scheduler root).

 

 

In this case “/LocalAgent” and /TestUser" is relative to our new virtual root Database Jobs. When a user is connected to a virtual root, that user cannot access any objects that are out-of-scope. By out-of-scope we mean that the objects are located at the same or higher path level of the connected folder.

 

As an analogy, consider the SUBST command in Windows. “SUBST D:   C:\Test” creates a drive “D” that actually points to “C:\Test”. There is no capability that exists to address objects at a higher level than C:\TEST (for example, C:\ or C:\ANOTHER-TEST are inaccessible through D:).  Consider this example. Suppose we placed “LocalAgent” at the Job Scheduler root level and then connected into the system at <SchedulerName>/Database Jobs”. What would the “Queue” property look like then?

 

 

The above figure shows what would be displayed. The queue is inaccessible to the user who has connected to a virtual root, since the queue is stored at the root level, which is a "higher" level and out of the user's scope. Accessibility does not impact functionality. That is, when the job is triggered, it will run on the system that the LocalAgent Queue points to.