Workday errors in plain English.

Submit an Error
errors / raas / raas-studio-400-qname-stray-question-mark-extra-path

RaaS Call From Studio Fails With QName Validation Error From a Stray Question Mark in Extra Path

✓ Verified RaaS (Reports as a Service) 3 lookups
The error com.capeclear.capeconnect.transport.BadRequestException: error from returned HTTP status: 500 400 : Validation error occurred. Element or attribute do not match QName production: QName::=(NCName':')?NCName.

What it means

A Studio integration's Extra Path expression used a second question mark to introduce the report's second launch parameter instead of an ampersand. Only the first parameter after the report path should be prefixed with a question mark, every parameter after that needs an ampersand. The extra question mark breaks how Workday parses the request and surfaces as a generic QName validation error that has nothing to do with the date values themselves.

Troubleshooting

  1. Pull the exact resolved Extra Path string from the integration event log, not just the expression source, to see the literal query string being sent.
  2. Count the question marks in that resolved string, a RaaS Extra Path with launch parameters should only ever have one, immediately after the report's alias.
  3. Check each subsequent parameter separator, every parameter after the first must use an ampersand, a second question mark is the most common mistake when parameters were added one at a time.
  4. Confirm the fix by resolving the corrected Extra Path and checking that it reads as a single valid query string before redeploying.
⚡ Quick fix

Change the separator before the second (and any later) launch parameter in the Extra Path expression from a question mark to an ampersand, keeping only one question mark immediately after getExtrapath().

✓ Permanent fix

When building Extra Path expressions with multiple launch parameters, template the pattern once, one question mark after the report alias and an ampersand before every parameter after that, and reuse it rather than hand-assembling the query string for each new report call.

Was this helpful?

Related errors