9.1 Workday Integration Architecture & Web Services
Key Takeaways
- An integration transfers data between Workday and an external system, and Workday supports both inbound and outbound directions.
- Workday stores customer data as objects, and web service requests are the primary way integrations access that object data over HTTPS.
- SOAP messages are XML with a header and a body and are documented by a WSDL file, while REST is stateless and uses HTTP verbs mapping to create, read, update, and delete.
- Enterprise Service Brokers make up Workday's integration services: ESBg for SOAP and REST traffic and file transfers, ESBb for reports and attachments, ESBi for packaged integrations, and ESBc for Workday Studio.
- A custom report enabled as a web service - Reporting as a Service - requires no web service operation selection or hand-written request.
What an integration is
An integration transfers data between Workday and an external system. The integration system provides the methodology for communicating that data. Workday integrations support two-way data exchange:
| Direction | What happens |
|---|---|
| Outbound | Workday provides the data. You can transform the outgoing data before delivery - for example, extracting worker, payroll, or budget data and delivering it to a third-party payroll provider |
| Inbound | You import data into Workday - retrieving data from an external system, processing it, and importing it |
Workday integrations can export and import large volumes of data; run with parameters allowing full extracts or filtered extracts, and in some cases retrieve only data changed since the last extraction; obtain data from web service calls or from custom report data; run on a schedule or ad hoc; encrypt data; and complete most tasks in bulk that you can perform in the user interface.
Delivery methods include creating a file attachment, using an SFTP server, and having the external source make a direct web service call.
Objects and web services
Recall from section 1.2 that Workday stores all customer data as objects. That has a direct consequence for integrations: web service requests are the primary way to access Workday object data. Web services are one of the central components of the Workday architecture, and all communication with Workday services is via HTTPS requests.
A web service is a standardized method for processing messages between client and server applications. It carries out a specific set of operations that can be found and invoked over the network: a user or system sends a request, a server processes it and sends back a response. Web services use standardized protocols such as HTTP or HTTPS, and the request-response exchange typically uses XML.
SOAP and REST
| SOAP | REST | |
|---|---|---|
| Message shape | An envelope with a header (routing information) and a body (the data), created with XML | Resources addressed by URL |
| Description | A WSDL file - an XML file documenting what the SOAP service can do, its location, and how to use it | No WSDL; the client and server need only agree on message format |
| State | Conventional request-response | Stateless - the server has no knowledge of the client's state and vice versa, so messages can be processed in any order |
| Verbs | Operations defined by the service | HTTP verbs mapping to CRUD - Create, Read, Update, Delete |
Workday Web Services (WWS) is Workday's SOAP API, organized into web service operations per functional area. Workday also offers REST APIs.
Where the exam pushes: the WSDL belongs to SOAP, and statelessness belongs to REST. Those two facts separate the options in most architecture questions.
Reporting as a Service
A custom report can be enabled as a web service, producing Reporting as a Service (RaaS).
A custom report enabled as a web service does not require a user to select a web service operation or write a request.
RaaS is the bridge between the reporting module and the integrations module, and it is why section 7.2 stressed building Advanced reports when the report may ever feed an integration - only Advanced reports can be enabled as a web service.
The practical consequence: an outbound integration built on RaaS is only as correct as the report behind it. When such an integration delivers the wrong rows, you debug the report, using the method in section 8.4 - not the integration.
Workday architecture related to integrations
Users generally reach Workday through a browser. The User Interface Services (UI Server) handles user requests, presenting HTML forms while communicating with the Workday application using XML messages.
Integration traffic goes through a separate path: several Enterprise Service Brokers (ESBs) make up Workday's integration services.
| ESB | Handles |
|---|---|
| ESBg (Gateway) | SOAP and REST web service traffic, and transfers via HTTP, HTTPS, FTP, SFTP, FTPS, and email |
| ESBb (Blobitory) | Processes and stores reports and attachments |
| ESBi | Packaged integrations such as Payroll, Benefits, and Salesforce |
| ESBc (Cloud) | Workday Studio and customer-written integrations |
Both the user interface services and the integration services communicate with the Object Management System (OMS), which handles data encryption, persistence, security, and auditing, and contains:
- Object Transaction Service (OTS) - the transactional workhorse holding tenant business data, performing read and update transactions
- Two Object Reporting Services (ORS) - one offloading fast UI traffic, one running long-running, memory-intensive, background and scheduled reports, plus RaaS and direct web service reads
- Application Object Database (AOD) - synchronizes OTS and ORS with the database, and handles indexing and search
Finally, the Elastic (Compute) Grid processes units of work simultaneously across many nodes that Workday allocates and deallocates automatically. Its pools include a payroll grid pool for large payroll customers, multiple integration pools for different integration types, and a PDF print pool.
The examinable consequence: because RaaS and background reports run on the reporting ORS rather than the transactional service, a heavy integration report does not compete directly with users' interactive work. It also means integration output reflects a read of the reporting service, so an integration and a UI query can, in narrow circumstances, be observed at slightly different moments.
Change detection
Some integrations retrieve only the data that has changed since the last extraction. This is why an integration that "stops sending records" is often working exactly as designed - it has already sent them, and nothing has changed since. Before treating a small or empty output as a defect, establish whether the integration uses change detection.
Data Initialization Service
If your integration uses Data Initialization Service (DIS), data retrieval does not use web service requests, and is typically faster than calling SOAP, REST, or RaaS. DIS is the exception to "everything goes through web services," and it appears as a distractor precisely for that reason.
Which statement correctly distinguishes SOAP from REST in Workday's integration architecture?
An outbound integration built on Reporting as a Service is delivering the wrong set of records. Where should troubleshooting begin?
Which Workday service handles SOAP and REST web service traffic as well as transfers via SFTP and email?