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

Quick Start Execute and Monitor a PBRS Schedule

Resolve a schedule, execute it asynchronously, and monitor the result to completion.

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

Prerequisites

  • The API service is installed and reachable.
  • The PBRS scheduler is running.
  • You have a valid access token.
  • The target schedule already exists.
  • You know either its UniqueId or its folder path, name, and schedule type.

Schedule type values

Value PBRS schedule family
report or single Single and Data-Driven schedules
automation Automation schedules
package Single and Data-Driven Package schedules
event Event-Based schedules
event-package or eventpackage Event-Based Package schedules

Recommended asynchronous workflow

  1. Call GET /api/service/ping.
  2. Call GET /api/service/isschedulerrunning.
  3. If necessary, resolve the UniqueId using POST api/folder/getuniqueidfrompath.
  4. Submit POST api/schedule/executescheduleasync.
  5. Store the returned ExecutionId.
  6. Poll GET api/schedule/GetExecutionStatus?ExecutionId={ExecutionId} at a controlled interval.
  7. Record the final status and parse ResultJson for the reported success value and error message.
  8. If the report should have been delivered, verify the destination and PBRS delivery log.
{   "ScheduleType": "report",   "UniqueId": 123456789,   "RunBy": "ExternalScheduler" }

Choose the execution operation

Operation Behavior
ExecuteSchedule Runs synchronously and waits for completion.
ExecuteScheduleAsync Returns an ExecutionId while the schedule continues to run.
ExecuteScheduleOnTimeAsync Runs asynchronously as though started by the scheduler and advances NextRun after completion.
CancelExecution Attempts to cancel an existing asynchronous execution using its ExecutionId.

Monitor capacity and queue state

GET api/schedule/getnumberoffreethreads returns the documented number of execution threads currently available. GET api/schedule/GetExecutionQueue returns waiting and executing work plus executions recorded during the previous 12 hours.

Delivery side effect: Executing a schedule can generate files, send email, and write to configured destinations. Use a controlled test schedule and test destinations during integration development.

Define success end to end

An accepted API call is not the same as a delivered report. Track each layer separately:

  1. The API accepted the request and returned an execution identifier.
  2. The scheduler started the requested schedule.
  3. The execution reached a terminal state.
  4. ResultJson indicates the expected report operations succeeded.
  5. The expected artifacts were created.
  6. Every required destination completed delivery.

Polling and retry method

Use bounded polling with exponential backoff and a client-owned maximum elapsed time. Retry transient reads; do not blindly retry a create, update, delete or destination change. After a timeout, reconcile PBRS state before deciding whether another write is safe.

Validate schedule type before execution

Use only the documented values report, single, automation, package, event, event-package, or eventpackage. Do not substitute a PBRS folder name or an informal type such as Custom. Support evidence shows that an accepted request can still produce no report when the schedule type is wrong.

Minimum production orchestration record

Store a client correlation ID, request time and timezone, PBRS server/build, schedule type, UniqueId, RunBy, returned ExecutionId, terminal state, sanitized ResultJson, expected artifacts and destination results. This is the minimum information required to reconcile ambiguous outcomes safely.

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.