RaaS calls in Orchestrate: namespaces, unexpected character errors, 401s and empty reports

The four causes, in the order to check them

A RaaS call from an orchestration fails for one of four reasons: the namespace path does not point at the report, the response is not in the format your next step parses, the credential does not authenticate, or the account it runs as is not allowed to see the report's rows. Read the RaaS step's response status code and body in the run before changing anything, because each cause leaves a different mark there.

• A failed request with no report output points at the namespace.
• A 2xx response that the next step cannot parse points at the format.
• A 401 points at the credential.
• A 2xx response with no rows, or a permission error, points at security or prompts.

Which component to call RaaS with

Orchestration Builder has a dedicated Send Workday RaaS Request component. It comes with the GET method and the Workday API address filled in, and you supply the report's namespace as a string in Expression Builder. Its reference page lists it in the Asynchronous, Business Process and Integration System templates, and says it cannot be used inside a Join Loop.

Workday built it for long-running reports: the report can take up to 1 hour to respond without timing the orchestration out, and the overall orchestration timeout resets when the response arrives. Some of Workday's sample flows call RaaS through Send Workday API Request instead, with a path such as /raas/{owner}/{Report_Name}?format=json.

If the logs of a long-running RaaS request show the text dsa added to the endpoint URL, Workday says it has no effect and can be ignored.

Namespace errors: the path does not reach the report

When a custom report is enabled as a web service (the Enable As Web Service check box on the report's Advanced tab), Workday generates a namespace in this form:

https://api.workday.com/raas/{user}/{report_name}

{user} is the report owner and {report_name} is the report name with spaces replaced by underscores. Three documented behaviours cause most namespace failures:

1. The namespace was edited. You can change a report's namespace, and Workday does not check that it is unique. If the namespace changes and the orchestration still requests the old one, the request fails.
2. You built the path from today's owner and name. Workday keeps the namespace fixed when the report is renamed or changes owner, so integrations keep working. The opposite also holds: a path you assemble from the current owner and current name can be wrong for a report that was renamed or transferred. Copy the namespace from the report definition instead of reconstructing it.
3. The owner's username contains a backslash. Workday states that GET RaaS requests for custom reports require the report owner's username to have no \ character.

To get the exact URL, open the report definition, choose Web Services > View URLs from the related actions, fill in the required prompts and copy the URL of the format you want.

In an Integration System orchestration, you can avoid hard-coding the owner. intsys.reportPath("Workers Report") returns the path of the first report matching that alias, in the form owner/report_name. Workday's Employee Demographic Outbound sample passes exactly that value into the RaaS step's path.

Unexpected character and parse errors: XML arrived where JSON was expected

When a RaaS call succeeds and the next step fails to read it, check the format first. Workday documents a trap on the Send Workday RaaS Request component: its Content Type setting on the General tab does not choose the format of the report output. To get JSON, add a query parameter on the Query Parameters tab with the key format and the value json.

The format values Workday lists for the report URL are csv, gdata, json, rss and simplexml; Workday XML, the sixth output option, has no value in that list. If the step's response body starts with <, a later stringAtJsonPath or iterator("$.Report_Entry[*]") is being handed XML. Fix the request, not the parser: add format=json and rerun.

Two smaller format points from the RaaS concept page:

• For CSV that uses UTF-8, add bom=true so that tools such as Microsoft Excel read the encoding correctly.
• Simple XML turns multi-instance fields on the primary business object into strings separated by semicolons, and outputs date-only fields without times. If a downstream step splits on commas or expects a time zone, that is why it misreads Simple XML.

If you genuinely want XML, ask for it on purpose and read it with the XML member functions. asXML() and asJSON() on a document only tell Orchestrate how to treat the bytes; they do not convert one format into the other.

Prompts that are passed but ignored

Report prompts go into the URL as query parameters named by the prompt's Label for Prompt XML Alias, shown on the report definition's Prompts tab. The value syntax depends on the prompt type:

In the Administrator Guide's URLs, the ! before WID is URL-encoded as %21, while the ! between WIDs is not. On the component's Query Parameters tab you enter the key and value, and Orchestration Builder adds the leading ? and the & separators for you. Workday's demographic sample does this with a key of Workers!Employee_ID and a value built with mkString("!") from a list of employee IDs.

Workday's docs do not say what happens to a parameter whose name matches no prompt, so do not count on an error to tell you. When the row count is wrong, compare the parameter names in the step with the Prompts tab, character for character.

401: the credential did not authenticate

A 401 means the call never got as far as the report. The Auth setting on the RaaS step uses a credential defined on the Credentials tab of the orchestration's Settings. The documented credential types are API Key, Basic Auth, OAuth and ISU. For an ISU credential, the integration system user has to exist, be assigned to the app in App Manager and have an API client created there.

Integration System orchestrations default to the Access Token From Initiating User endpoint scheme, so the call runs as whoever launched the integration. Workday recommends that default for integration apps and recommends an ISU credential only when the integration must use a different ISU from the one that launched it.

If the credential type is right and the 401 persists, the fault is in the ISU, its API client or its consent, not in the report. The layer-by-layer checks are in diagnosing ISU and API client 401s.

Empty reports: a 200 with no rows

RaaS applies the issuing account's object and data-level security, per Workday's WQL and RaaS comparison. Workday's integration security page says services return only the data the user is permitted to read, and return permission errors if the user has no access to an object. Report access is also restricted to accounts with permission to view the report and its data, as the Enable As Web Service option explains.

The consequence is that a report you see full of rows can return an empty Report_Entry to the orchestration, with a 200 status and no error, because the orchestration runs as a different account. Work through these in turn:

1. Find out which account the call runs as: the launching user, or the ISU named in the credential.
2. Confirm that account can view the report itself, through the report's sharing settings.
3. Confirm the integration system security group has the domain access for the report's data source and fields, and that Activate Pending Security Policy Changes has been run after any change.
4. Recheck the prompt names, as described above.

Workday's Employee Demographic Outbound sample guards against a silent empty result with a Continue on Conditions step right after its Send Workday RaaS Request step, fetchDemographicsReport:

data.fetchDemographicsReport.responseStatusCode.is2xxStatusCode()
data.fetchDemographicsReport.response.countItemsAtJsonPath("$.Report_Entry").greaterThan(0)

Each condition carries its own message, such as "Report returned no entries", so the run fails with a clear reason instead of producing an empty file. For report-side causes such as sharing and calculated-field security, see why shared users see empty report columns.

Timeouts and size limits that look like errors

Workday publishes different RaaS timeouts depending on where the call comes from: 6 hours for RaaS SOAP and REST requests from a tenanted host, and 5 minutes for RaaS calls through the Workday Cloud Platform gateway at api.workday.com. The Send Workday RaaS Request component waits up to 1 hour. RaaS returns up to 1 million rows and does not paginate. If a report is near any of these limits, the fix is a narrower report or a switch to WQL, which can paginate 10,000 rows at a time. The trade-offs are covered in RaaS vs WQL vs REST.

How to prove the fix

Rerun the orchestration and open the RaaS step in the run. Confirm three things there: a 2xx status code, a body whose first character is { when you asked for JSON, and an entry count equal to what the report returns in Workday for the same prompts, run as the same account. Matching counts are the proof that the namespace, prompts, credential and security all line up. A green run status alone does not show that.