ActiveBatch System Objects
ActiveBatch System Objects consists of administrative jobs and their associated objects that are used by the system to execute various built-in tasks.
The System Objects view is accessed via Views > Administrator > System Objects. Depicted in the image below is what you can expect to see after the installation and configuration of the Job Scheduler. If you install and configure Instance and/or Template reporting, additional objects are added to this view.
The ActiveBatch database consists of pending, active and completed jobs. A completed job contains all details about the job and log files that were written when the job executed.
The component that manages and prunes unnecessary object history is DbPurge. DbPurge is implemented as a separate ActiveBatch job located within System Objects. The advantage of having DbPurge run as a standard job is that ActiveBatch features such as scheduling and alerts can be used as a part of the DbPurge process.
DbPurge prunes completed job history records which no longer need to be retained. DbPurge also deletes or archives job log files for jobs that use "Centrally Managed" logging. DbPurge obeys the retention criteria established for Plans and Jobs as per their individual Completion > "Save for" property setting. DbPurge obeys the Centrally Managed Log retention period (if enabled) configured on a job's Execution > Logging > "Retain for" property. As a mention, only jobs generate job log files (plans do not).
By default, the DbPurge job runs every morning at 1:00 AM. You can change the DbPurge schedule and other aspects of the job by using ActiveBatch Console and accessing DbPurge's properties. You may also run DbPurge manually through the Trigger command. DbPurge requires that the Job Scheduler is running.
By default, DbPurge will also produce a log of all its activities. This log is part of the standard instance execution of DbPurge and uses the ActiveBatch Centrally Managed Log Files feature.
If you examine DbPurge’s Job Properties (right-click on the DbPurge job in System Objects, then select Properties - this will tab the job's properties in the Main view) you will discover that the job runs as a Jobs Library Job type. The following parameters are specified with the job.
-
Audit Retention – String that controls the objects to purge and the amount of days to retain those audits.
-
Command Timeout – Determines how long the stored procedures can execute.
-
Batch Size – Determines the chunk size to be used in database calls.
-
Purge Timeout – Maximum overall length of time that DbPurge can execute.
IndexerJob
The Indexer job is used to index all objects and their properties to speed object search requests using the “Search” operation. By default, the Indexer job is executed whenever a new object is created. The Indexer job is also executed on an initial installation when a prior version of the database is promoted. You should not have to manually run this job unless directed by an ActiveBatch Technical Support Technician.
ServiceJob
This is an "empty" Jobs Library Job - It can be ignored as of this writing. It may be used in a future release of ActiveBatch.
JssQueue
This is the built-in Queue that points to the local Agent installed on the Job Scheduler system. It is used to run DbPurge. If you look it at the Properties of DbPurge - Jobs Library > Execution Properties > Queue - you will see it listed there.
DbPurgeSchedule
This is the schedule object associated with DbPurge. By default, it is configured to run DbPurge daily at 1am. If you look it at the Properties of DbPurge - Jobs Library > Triggers > Schedules - you will see it listed there.
AdminAccount - This is the built-in user account that is configured with the user that DbPurge will run with. If you look it at the Properties of DbPurge - Jobs Library > Execution Properties > User Account - you will see it listed there. Note: It is also used when running Instance Reporting and Template Reporting jobs, discussed below. The AdminAccount requires full control permissions.
DBSystem Account
This account is reserved for use by the ActiveBatch Technical Support Team, if needed.
Next, the System Objects described below will only be present if Instance and/or Template Reporting has been installed and configured.
If Instance Reporting and/or Template Reporting is configured (Configuring Instance Reporting, Configuring Template Reporting) a folder named Reporting will be listed in System Objects. The folder is shared by both features, but they have their own set of objects, described below.
Instance Reporting
See below the additional objects you will see when Instance Reporting is configured.
The UpdateReportingDatabase job is an ETL job that extracts instance data from the ActiveBatch transactional database and loads the Instance Reporting database for later report generation.
The FullProcessingSchedule is associated to the UpdateReportingDatabase job, set to run the job daily at 12am. If you look it at the Properties of UpdateReportingDatabase (Jobs Library > Triggers > Schedules) you will see it listed there. Depending on the frequency of the reports you desire, you may want to execute this job more or less frequently. If you change the FullProcessingSchedule schedule object, it is important that this job runs before DbPurge, and by default it does. The reason this is required is because the system needs to copy instances from the transactional database (ActiveBatch backend database) to the Instance Reporting database before instances are purged (part of the DbPurge process).
The InstanceReportingQueue is the Execution Queue associated with the UpdateReporting Database job and the ProcessReportingCube job. The queue points to the system where the jobs will run. If you look at the properties of either job, you will see it associated there (Jobs Library > Execution Properties > Queue).
The ProcessReportingCube processes the entire Instance Reporting cube, and is not scheduled to run by the system. It is there for convenience sake, if there is ever a need to process the entire cube (e.g. ActiveBatch Technical Support requests it be run, etc.). The UpdateReportingDatabase job that runs nightly partially processes the cube when new data is added, it does not process the entire cube (for performance reasons, and it is not required). To sum it up, the ProcessReportingCube job need not be run by the end-user unless ASCI indicates it should be.
The account the ProcessReportingCube and UpdateReportingDatabase jobs run under (Jobs Library > Execution Properties > User Account) is the AdminAccount, the same account used by DbPurge.
Template Reporting
If Template Reporting is configured, 3 additional objects will be added to the Reporting folder.
In the Queues subfolder, you will see a queue named TemplateReportingQueue. This queue points to the system where the UpdateTemplateReportingDatabase job will run. If you look at the properties of the job, you will see it associated there (Jobs Library > Execution Properties > Queue)
The UpdateTemplateReportingDatabase job is also added to the Reporting folder, and it updates the Template Reporting Database.
The TemplateProcessingSchedule is added to the Schedules subfolder. This object is associated to the UpdateTemplateReportingDatabase job, and determines when it will run. By default, it runs daily at 2:00 AM. If you look it at the Properties of UpdateTemplateReportingDatabase (Jobs Library > Triggers > Schedules) you will see it listed there.
The account the UpdateTemplateReportingDatabase Job runs under (Jobs Library > Execution Properties > User Account) is the AdminAccount, the same account used by DbPurge and the Instance Reporting jobs.