9.1 Workday Integration Architecture & Web Services

Workday Pro Platform Administrator Certification Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: The Workday Platform

1.1 Workday Products, Functional Areas & Product Touchpoints 1.2 The Object Management Model & Business Objects 1.3 Navigation & Search Techniques 1.4 Organizations in Workday

2 Chapter 2: Tenants & Release Management

2.1 Tenant Types & Tenant Management Tasks 2.2 Releases, Adoption, System Testing & Support

3 Chapter 3: The Configurable Security Framework

3.1 Components of the Configurable Security Framework 3.2 Core Security Group Types: Workday-Assigned, User-Based & Role-Based 3.3 Advanced Security Group Types

4 Chapter 4: Security Policies, Assignment & Troubleshooting

4.1 Domain Security Policies & Permissions 4.2 Assigning Roles & Security Group Membership 4.3 Troubleshooting Security Access Issues

5 Chapter 5: Business Process Definitions & Steps

5.1 The Business Process Framework & Definitions 5.2 Business Process Step Types 5.3 Step Configuration, Order & the Completion Step

6 Chapter 6: BP Security, Condition Rules & Troubleshooting

6.1 Business Process Security Policies 6.2 Creating & Testing Condition Rules 6.3 Using Reports to Troubleshoot Business Processes

7 Chapter 7: Report Foundations & Custom Reports

7.1 Business Objects, Fields, Related Business Objects & Data Sources 7.2 Standard Reports, Custom Report Types & the Report Writer 7.3 Worklets, Dashboards & Sharing Reports

8 Chapter 8: Calculated Fields, Alerts & Report Administration

8.1 Identifying & Maintaining Calculated Fields 8.2 Configuring & Testing Alerts 8.3 Scheduling Reports, Report Groups & Transferring Ownership 8.4 Troubleshooting Report Data & Access Issues

9 Chapter 9: Integration Architecture & Security

9.1 Workday Integration Architecture & Web Services 9.2 Workday Integration Tools & Choosing the Right One 9.3 Integration System Users & Integration System Security Groups

10 Chapter 10: Enterprise Interface Builders

10.1 Creating & Launching an Inbound EIB 10.2 Creating & Launching an Outbound EIB 10.3 Troubleshooting EIB Data Loads & Access Issues

9.1 Workday Integration Architecture & Web Services

Key Takeaways Explain This Topic AI

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.

Last updated: August 2026

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.