Scheduler
The Scheduler Service provides a comprehensive scheduling solution for developers. With CRUD operations and a range of scheduling functionalities, this service eliminates the need for developers to build their own proprietary scheduling services.
The Scheduler Service provides a robust interface for creating, reading, updating, and deactivating (CRUD) scheduled jobs. It is designed to support one-time and recurring jobs, premised on absolute times or time intervals. For improved ease of use, jobs specify essential details like endpoint URL, signature key, external ID, payload, and number of retries.
This service is optimized to balance between flexibility and scale, supporting a quota of 100K active jobs per application and scheduling jobs 10 years into the future. Additionally, it fosters a seamless workflow by providing notifications upon job completion, detailing the status of each job.
- ListExecutions - Use this endpoint to list completed jobs sorted by their status and the time range.
The Scheduler Service is versatile and finds utility across several use cases, as outlined below:
- Contracts: Automatically mark contracts as inactive after their end date.
- Indents: Implement timeout protocols for unplaced or unaccepted indents.
- Trips: Schedule regular ETA calculations to identify delayed trips.
- Vehicles: Update vehicle data based on government records for expiring insurance or registration.
- Invoicing: Automate the aggregation of charges and daily computation of usage-based billing.
When integrating with the Scheduler service, app developers must ensure their endpoint URL is optimized for quick response. The endpoint should be capable of returning a 2XX HTTP status code within 1000 milliseconds (1 second) to confirm successful execution. Should the service not receive a 2XX status within this timeframe, it is programmed to initiate a sequence of retries to ensure delivery. Here’s how the retry mechanism is structured:
5XX Responses: If a 5XX server error response is returned, indicating a server-side error, the Scheduler service will initiate a maximum of three retries. The retries are scheduled as follows:
- First Retry: 1 second after the initial attempt.
- Second Retry: 2 seconds after the first retry.
- Third Retry: 3 seconds after the second retry.
3XX and 4XX Responses: In cases where the endpoint responds with a 3XX redirection or 4XX client error status, the Scheduler service will not attempt a retry.
The CreateSchedule request requires the endpointUrl, signatureKey, startDate, and cron. The following example request creates a schedule with a start and end date of 2023-09-30.
Parameter | Data Type | Description | Example |
endpointUrl* | string | The URL to trigger the action. | |
signatureKey* | string | The key used for signing the request | abcdefghijklmnopqrstuvwxyz0123456789 |
payload | object | The payload to send in the request | OrderedMap { "key1": "value1" } |
startDate* | string | The start date for the scheduled job | 2023-09-30 |
endDate | string | The end date for the scheduled job | 2023-09-30 |
cron* | string | The cron expression for the recurring job | * * * * * |
Example JSON Request Body
The following is an example response showing the new schedule:
You can list all the schedules you've created by calling ListSchedules. If you know the ID of the schedule you want to access, you can also call GetSchedules with a schedule_id.
Example JSON Payload
To retrieve schedule execution, call ListExecutions with a scheduleId.
Example JSON Request Body
After creating a scheduled job, you can use UpdateSchedules with a scheduleId to update its attributes. In the request, include the parameters you want to update.
You can update the following fields:
- endpointUrl
- signatureKey
- startDate
- endDate
- cron
- isActive
The following example updated the endDate of the schedule we created to 2024-10-30.
Example JSON Request Body