The forecast and schedule upload routes are being deprecated as they were not easily document-able or compatible with the SDK. The newer routes cover the same functionality and solve these problems. The legacy routes will not support new features going forward, and will be removed after Nov 27, 2022 or once we can confirm they are no longer in use, whichever is later.
Change Category
Informational
API
Change Context
The routes were not easily document-able or compatible with the SDK. The newer routes cover the same functionality and solve these problems.
Change Impact
These routes are only in use by a few customers and these customers have been notified directly.
These routes are being deprecated and will be removed. You should not start using them. Each route is replaced by 2 new routes and an intermediate POST to a signed S3 url.
The new routes are documented in detail in the developer center, but the general process to use them is:
EDIT: September 13, 2022 Added step 0
Subscribe to the appropriate notification topic for completion and error notifications. (schedules or shorttermforecasts)
Call the /uploadurl path of the route you wish to use to generate a signed S3 url for uploading your forecast or schedule.
Send a post request with your data to the returned upload URL.
Once a post request to the upload url has uploaded your data, call the import/update route, with the url, to process the import.
Date of Change
Nov 27, 2022
Impacted APIs
POST /uploads/v4/services/workforcemanagement/businessunits/{businessUnitId}/weeks/{weekDate}/shorttermforecasts
is replaced by:
Send a post request with your data to the returned upload URL.
-> Please teach me how to put the data
(how? put files as gzip?, file format? I want to know sample format)
Is there a way to check if it was uploaded correctly?
No matter what I upload, status code 200 is returned, but I don't know if the format is correct.
The schema is the same as it was previously, but is now documented in the developer center.
Is there a way to check if it was uploaded correctly?
Validation is done asynchronously and notifications are sent on the same notification topics as were used previously on the legacy upload routes. Any errors will be returned on that notification's metadata as before.
No matter what I upload, status code 200 is returned, but I don't know if the format is correct.
Amazon S3 is providing the link to upload this directly to a secure location, from which our service fetches and asynchronously processes the data once you call the route you mentioned under point 3. If you receive a 200 response from the PUT request, then you have successfully uploaded the data to the URL. As mentioned, actual validation will happen in a later step (this is not a change from how things were done previously).
Yes it's unfortunate that the extra step is needed but it's critical for performance as schedule data can become very large in its uncompressed state. Amazon S3, which backs the signed URLs being returned in step 1, does not do any processing of data so clients have to take the step. Most languages provide easy ways to gzip data so it shouldn't be too painful.