When a Workday Document Transformation (DT) integration or a Workday Studio assembly fails during transformation—or completes with an empty output file, missing attachments, or rejected rows—the cause is almost always one of four things: a Saxon XSLT 2.0/3.0 strong-typing error that the compiler cannot catch at deploy time, an etv: or xtt: step attribute mismatch, an output="message" property that wiped the MIME attachments, or a mismatched wd: XML namespace against the upstream web service or RaaS version.

This guide walks through the exact runtime mechanics of Workday's Saxon processor, ETV (Enterprise Interface Builder Transformation Validation), and XTT (XML to Text Transformation) steps, and how to isolate and fix each failure.

1. Saxon XSLT 2.0 and 3.0 strong-typing and compilation errors

Workday Studio assemblies versioned 2017.05 and later run on Saxon 9.7 with support for XSLT 3.0 (including XSLT streaming) and XPath 3.0. In assemblies versioned 2022.47 or later, Workday sets Saxon as the default transformer automatically whenever use.saxon.transformer is true or omitted from the mediation context.

Two Saxon behaviors trip up stylesheets that previously compiled or ran in older environments:

Runtime type errors on <xsl:param> comparisons

XSLT 2.0 and 3.0 are strongly typed and do not allow an xs:string to be compared directly against a boolean true() or false() in XPath. If your stylesheet declares a parameter without a type (or as a string) and evaluates:

<xsl:param name="stringParam"/>
<xsl:if test="$stringParam = true()">

the XSL compiler will not report an error at deploy time because it cannot predict the runtime type of $stringParam in advance. Instead, Saxon throws a type error at runtime when the integration runs.

Fix: Compare the parameter as a normalized string (test="lower-case(normalize-space($stringParam)) = 'true'") or declare the parameter type explicitly (as="xs:boolean") only when every caller passes a boolean.

Failed to compile stylesheet. 1 error detected. Invalid value for @case-order

When upgrading legacy XSL or business form printing stylesheets, Saxon rejects <xsl:sort> elements that contain case-order="#default" with:

Failed to compile stylesheet. 1 error detected.
Invalid value for @case-order. Value must be one of (lower-first|upper-first).

Fix: Remove the optional case-order="#default" attribute (Saxon defaults to sorting uppercase letters first) or set it explicitly to case-order="upper-first" or case-order="lower-first".

Mixing assembly versions in a Studio collection

If you package multiple assemblies into an integration collection with different assembly version numbers, Workday Studio warns you because differently versioned assemblies can load conflicting Saxon versions and fail with class-loading errors at runtime. Align all assemblies in the collection to the same current assembly version.

2. How ETV and XTT transform steps work—and why attachments disappear

When a Cloud Connect integration chains into a Document Transformation system (or when a Studio assembly runs etv, xtt, and xslt mediation steps in sequence), each step transforms XML and annotates or formats the payload:

  • ETV (Enterprise Interface Builder Transformation Validation): Evaluates etv: attributes in the XML against integration maps, sequence generators, and validation severities (error, warning, info), writing validation messages to the consolidated integration log (or into a named MediationContext property if you configure message-property).
  • XTT (XML to Text Transformation): Reads xtt: attributes (xtt:separator, xtt:fixedLength, xtt:align, xtt:dateFormat, xtt:numberFormat, xtt:severity) on the XML elements to convert hierarchical XML into a flat delimited or fixed-width text file for a third-party payroll or benefits vendor.

Both the etv and xtt mediation steps configure input and output properties with five allowed targets: message, soapbody, attachment, rootpart, or variable.

The output="message" attachment trap

Look closely at the difference between output="message" and output="rootpart" in Workday's step properties:

output setting on etv / xtt / xslt Effect on the integration message
output="message" Creates a brand-new message, replacing the entire message and removing all existing MIME attachments.
output="rootpart" Replaces only the root part of a MIME message (or the message itself if not MIME) and preserves all existing MIME attachments.
output="variable" Writes the transformed output into a named MediationContext variable without mutating the root message or attachments.

If your Studio assembly or DT chain stores diagnostic payloads, prior vendor files, or split documents as MIME attachments and a downstream xslt, etv, or xtt step uses output="message", every attachment is silently wiped at that step. Switch the step's output to rootpart or variable (or write directly to a context variable from XSLT using Workday's mctx: URL protocol, such as <xsl:result-document href="mctx:vars/myVar">).

3. Why XSLT outputs a blank file or misses rows (wd: namespace mismatches)

When a stylesheet runs without throwing a Saxon error but outputs only a header row or blank fields, inspect the input XML payload against the stylesheet's xmlns:wd declaration and XPath expressions:

  1. RaaS vs. Web Service namespace URI: A custom report enabled as a web service (RaaS) uses a report-specific namespace (urn:com.workday.report/...), whereas Workday SOAP web services and Cloud Connect extracts use urn:com.workday/bsvc. An XPath expression written for wd:Report_Data/wd:Report_Entry will match zero nodes if the input is a wd:Get_Workers_Response envelope or if the xmlns:wd URI does not match the input document's namespace byte-for-byte.
  2. Unprefixed child elements in default namespaces: In XPath 2.0/3.0, an unprefixed node test like Report_Entry/Worker_ID matches elements in the null namespace unless xpath-default-namespace is declared on <xsl:stylesheet>. Either prefix every Workday element with wd: or set xpath-default-namespace on the stylesheet or template.
  3. ETV map lookup misses: When an etv:map attribute references an Integration Map name that does not match the integration system's configured map name, or when an incoming Workday reference value has no mapped external value and no default value, ETV logs a transformation error or warning and emits an empty value depending on the configured severity.

Debugging and testing XSLT, ETV, and XTT in kiweely

Instead of redeploying a .lar or DT stylesheet to Workday and waiting for a full connector launch just to test a one-line XPath or xtt: change, kiweely connects directly to the Workday Studio installed on this computer and to your Workday tenant. In one conversation, kiweely can pull the real XML output from a prior integration run, execute your XSLT/ETV/XTT transformation locally in Studio, write AUnit regression tests for edge-case rows, and pause a live debug run at the exact mediation step where a variable or MIME attachment changes—waiting for your approval before deploying or launching anything in the tenant.

Sources checked