Skip to content
  • There are no suggestions because the search field is empty.

Operate PBRS API Services, Queues, Collaboration and Failover

Monitor API execution, control scheduler services, and understand the API prerequisites for collaboration and failover.

Review status: Draft for Development and Support review. Routes and models labelled validation required must be tested against the supported PBRS build before publication.

Service operations

Operation Documented route Effect
Ping GET /api/service/ping Returns 1 when the API is running.
Scheduler status GET /api/service/isschedulerrunning Returns whether the scheduler is running.
Start scheduler GET /api/service/startscheduler Starts scheduling; state-changing.
Stop scheduler GET /api/service/stopscheduler Stops scheduling; state-changing.
Configuration path GET /api/service/getconfigpath Returns the PBRS configuration path.
Update collaboration settings POST /api/service/updatecollaborationsettings Updates supported collaboration fields; administrative.

Administrative warning: StartScheduler, StopScheduler, GetConfigPath, and UpdateCollaborationSettings should be restricted to trusted administrative integrations. The use of GET for state-changing start and stop operations is unusual and must be protected from accidental invocation.

Execution monitoring

  • GetExecutionStatus returns execution identifiers, schedule identifier, process ID, status, entry and completion timestamps, RunBy, ResultJson, and server name.
  • GetExecutionQueue adds schedule type and schedule name and is documented as covering waiting work, executing work, and executions from the previous 12 hours.
  • GetNumberOfFreeThreads reports available execution capacity.
  • CancelExecution attempts to cancel asynchronous work.

Use the PBRS API Execution Queue screen

  1. Open System Monitor in PBRS.
  2. Select API Execution Queue.
  3. Locate the execution by time, schedule, or other recorded correlation details.
  4. Compare the PBRS execution log with the ExecutionId and timestamps stored by the calling application.

The API article and PBRS interface article should use the same status terminology and identifiers so administrators can correlate an external request with PBRS activity.

Collaboration prerequisites

  • Install and start the PBRS API on every participating server.
  • Ensure each PBRS instance is reachable through the internal network.
  • Match required email, database, and system settings between the primary and collaborator servers.
  • Move the primary database to the required enterprise SQL Server configuration and connect collaborators to the primary scheduler database.
  • Understand that collaborators process schedules assigned by the primary and do not run their own local schedules.

Collaboration and failover behavior

The public guide documents Server Affinity and Round-Robin collaboration methods. Failover is configured on the backup server using the scheduler option Use as a backup scheduler server (Failover), followed by a server restart. The failover server monitors the primary and becomes the main scheduler if the primary fails.

Boundary: An API call is not a complete collaboration or failover deployment. Follow the full PBRS failover procedure and validate database, network, credential, and delivery dependencies on every server.

Separate operational responsibilities

Use this article as the operating overview. The secure-deployment article owns service and network hardening. The monitoring-and-recovery article owns polling, queue correlation, cancellation, long-running jobs and delivery verification. Collaboration and failover guidance owns distributed execution prerequisites and server behavior.

Minimum health record

  • PBRS build and server name
  • API and scheduler service state
  • Available execution threads and queue depth
  • Schedule identifier, execution identifier and RunBy value
  • Start time, terminal state and sanitized ResultJson
  • Expected artifact and destination-delivery result

Scheduler start and stop operating procedure

  1. Record why the scheduler is being stopped, the owner and the maintenance window.
  2. Inspect active and waiting API executions before calling StopScheduler.
  3. Stop external producers from submitting new work where practical.
  4. Call the supported stop operation and verify scheduler state.
  5. After maintenance, start the scheduler and verify state, queue depth and free threads.
  6. Determine how schedules due during the outage are handled before allowing automated catch-up.
  7. Run a controlled schedule and confirm delivery.

Development must define whether stop is graceful, what happens to executing and queued jobs, and how missed schedules are calculated. Do not use start/stop endpoints as a nightly batch-control mechanism until these semantics are verified.

Collaboration and failover implementation details

The operator procedure must cover the API on every server, internal reachability, the shared enterprise SQL database, matching email/database/system settings, the collaboration endpoint or configuration-share connection, remote Windows credentials, stopping the remote editor/scheduler during enrollment, Server Affinity versus Round-Robin, backup-scheduler designation and the required restart. Link to the full PBRS interface procedure rather than reproducing screenshots in the endpoint reference.

Documentation standard: Record the PBRS build used for verification, test in a non-production environment, redact credentials and customer data, and confirm the saved PBRS state after every write.