batchJob-BatchJobService

This service provides job control functions for provisioning jobs, including sending each provisioning job (as a batch job) to be run by the station’s JobService.

The BatchJobService is required in the Supervisor station to facilitate provisioning. After copying it from the batchJob or provisioningNiagara palettes into the Supervisor’s Services folder, you do not normally interface with it, apart from specifying the station’s alarm class to use for provisioning alarms.

The BatchJobService requires the Supervisor station to also have the HistoryService and JobService, otherwise the BatchJobService is in fault. Typically, any Supervisor already has these services.

In addition, the BatchJobService requires the Supervisor host platform to be licensed with the provisioning feature, or else the service is in fault.

Figure 7. BatchJobService properties

Property	Value	Description
Status	read-only	Reports the condition of the entity or process at last polling. `{ok}` indicates that the component is licensed and polling successfully. `{down}` indicates that the last check was unsuccessful, perhaps because of an incorrect property, or possibly loss of network connection. `{disabled}` indicates that the `Enable` property is set to `false`. `{fault}` indicates another problem. Refer to `Fault Cause` for more information.
Enabled	`true` (default) or `false`	Activates (`true`) and deactivates (`false`) use of the object (network, device, point, component, table, schedule, descriptor, etc.).
Job Queue	thread pool job queue	Manages the submission of provisioning batch jobs by using a thread pool, to ensure that the Supervisor’s CPU and network resources are not overtaxed by concurrent sessions. A single property, `Max Threads`, defaults to one (1), meaning only one provisioning job can run at a time. No special views or other features are provided. Only after determining the station has available resource overhead, should `Max Threads` be adjusted to values over 2 or 3. Otherwise, other tasks performed by the station may be affected.
Alarm Class	drop-down list	Specifies the alarm routing option for the component. `Replace` provides a selection list of a local alarm classes, from which to select one to use for all alarms received from this device. `Use Existing` routes alarms from this remote station to any matching alarm class, that is, one with an identical name as that in each alarm record. If the program finds no local matching alarm class, it uses the station's default alarm class. `Prepend` adds leading text (as specified) to the incoming alarm class string, then routes it to any local matching alarm class in the station. `Append` adds trailing text (as specified) to the incoming alarm class string, then routes it to any local matching alarm class in the station. The check boxes at the top of the Niagara Network Job Builder and Niagara Network Prototype View configure when to generate an alarm for a provisioning job that failed.
Summary Manager Type	read-only (defaults to batchJob: HistoryJobSummaryManager)	Reports the type of the class that manages summary logs. Developers who extend the BatchJobService can set this value to a custom manager that implements the BIJobSummaryManager interface.
Max Provisioning Threads	number from 1 through 10 (defaults to 1)	Starting in Niagara 4.7, provisioning allows job steps to run in parallel across multiple target stations. This property defines the maximum number of parallel jobs that can be run for a single provisioning job step. If there are more target stations than `Max Provisioning Threads` for a provisioning job, the system queues the remaining station jobs and runs them when the running jobs finish.

batchJob-BatchJobService

Figure 7. BatchJobService properties

Related Links