Workday errors in plain English.

Submit an Error

Studio Integration Fails on Put Integration Message: Invalid Rich Text Internal Syntax

✓ Verified Workday Studio 4 lookups
The error Integration Failed. com.capeclear.mediation.MediationException: application=<APP_NAME> - Workday Out transport id=IntegrationsWebServiceNoStoreMessage encountered problem sending to endpoint 'https://wd5-services1.myworkday.com/ccx/service/<TENANT>/Integration_Metadata/v20' with operation 'Put_Integration_Message_Request'. Details: MSG_SENSITIVE:<GUID> application=<APP_NAME> - Code: SOAP-ENV:Client.validationError, Reason: Validation error occurred. Invalid Rich Text internal syntax: Unexpected char in markup at 58 Root Cause: BadRequestException :

What does "Integration Failed. com.capeclear.mediation.MediationException: Workday Out" mean in Workday Studio?

The integration tried to write a message back to Workday and Workday rejected the text. Integration message bodies are treated as Rich Text, so any angle bracket or markup character in them has to be escaped first. Something in the assembly, very often an error handler logging the payload it just failed on, put raw XML straight into the message. The character offset in the error is the position in the message text, not in your source file.

Quick fix

Stop passing raw payload into the integration message. Log a fixed description plus a safe identifier such as a record key, and the run will report its real error instead of failing on the report.

Permanent fix

Escape anything variable before it reaches Put Integration Message, and treat that as a rule for every error handler rather than fixing the one that failed. Where you need the offending payload for diagnosis, write it to an attachment or a file instead of into the message body, which keeps the full content available without putting markup through Rich Text validation. Then fix the upstream condition, because a handler that no longer crashes will now surface the original error on every failed run.

Troubleshooting

  1. Note that this is a reporting failure, not the original failure. Something else went wrong first and the handler that tried to record it is what actually broke.
  2. Find every step that writes an integration message, then check which of them can receive raw payload content rather than a plain sentence.
  3. Look hardest at error handlers. Passing the failed message straight into the log text is the usual cause, and it explains why the error looks intermittent: it only appears when the underlying problem occurs.
  4. Reproduce with a payload containing an angle bracket. If the message writes cleanly with plain text and fails with markup, escaping is confirmed as the cause.
  5. Only then go after the original failure the handler was trying to report, since that is the problem the run actually hit.
Was this helpful?

Related errors