Connecting to Workday is done through a standard REST WebService: a base URL, an authentication method, and a metadata URL pointing to the schema that describes the data. This is the same generic REST connection type used for other REST-based integrations, not something Workday-specific.
REST WebService Connection Configuration
Code
Internal identifier for the web service
Description
Human-readable label for what this connection is for
Authentication Type
Typically Basic auth (user ID + password) using a Workday integration user
Server Connect
Base URL of the Workday endpoint being called
User ID
Workday integration service account
Password
Credential for the integration user, stored securely
Metadata URL
Optional link to a JSON schema describing the objects and fields returned by this endpoint
Use SSL
Should always be enabled
What the endpoint points to:
The Server Connect URL can point at any Workday REST endpoint the customer wants to expose, not just a report. Workday reports (RaaS) are one common example, since they're easy for a customer to build and adjust themselves, but the same REST WebService setup works equally well against other Workday tables and endpoints. What changes from case to case is just the URL and, if used, the schema behind the Metadata URL; the connection setup itself stays the same.
What lives on the Workday side vs. the Rapidi side
Workday side: the customer configures and maintains whatever Workday object (report, table, or other endpoint) is being exposed, including its security and access.
Rapidi side: the REST WebService just needs the correct URL, credentials, and a Metadata URL pointing to the schema ( built by Rapidi). See Schema Structure & Field Management for how that schema is built and kept up to date.
Prerequisites
A Workday integration system user with access to the endpoint(s) being connected to.
The endpoint reachable over HTTPS from Rapidi.
Schema: a hosted, reachable JSON file describing the endpoint's objects and fields.
Comment Editor X