When Large XML Breaks SOAP in SAP CPI: Understanding CXF Limits, Misleading Errors, and the Real Fix

[ysimalatsar]

Prerequisites:

Recently we faced an issue: a large EPCIS payload caused CPI’s SOAP Adapter to crash with pretty technical error text:

Error Details

org.apache.camel.InvalidPayloadException: No body available of type: java.lang.String but has value: org.apache.camel.component.cxf.converter.CachedCxfPayload@22fcc44c of type: org.apache.camel.component.cxf.converter.CachedCxfPayload on: Message. Caused by: Error during type conversion from type: org.apache.camel.component.cxf.converter.CachedCxfPayload to the required type: java.lang.String with value org.apache.camel.component.cxf.converter.CachedCxfPayload@22fcc44c due to java.lang.IllegalStateException: Current event not START_ELEMENT or END_ELEMENT. Exchange[69E7F6624A5A223-000000000000000A]. Caused by: [org.apache.camel.TypeConversionException - Error during type conversion from type: org.apache.camel.component.cxf.converter.CachedCxfPayload to the required type: java.lang.String with value org.apache.camel.component.cxf.converter.CachedCxfPayload@22fcc44c due to java.lang.IllegalStateException: Current event not START_ELEMENT or END_ELEMENT], cause: java.lang.IllegalStateExcept...

Nothing in this exception suggests “your XML is too big” and the message was only 10M which is below default 40M SOAP Adapter max.

The Real Cause: Apache CXF XML Security Limits

CPI’s SOAP Adapter is built on Apache CXF and Apache Camel.
Before CPI ever sees the message, CXF enforces several safety thresholds:

Our EPCIS messages contained more than 100K child elements — far beyond the 50,000 limit.

Once CXF hits a threshold, it stops parsing.
Camel then tries to convert an incomplete payload into a String or DOM — and fails with a meaningless type-conversion exception.

Why You Cannot “Fix the XML”

In many regulatory or B2B integrations, the message structure is dictated by standards.
In this case, reducing batch size or restructuring XML was not feasible:
the EPCIS payloads legitimately exceeded CXF’s defaults.

So we raised an SAP ticket.

SAP’s Proposed Solution

SAP confirmed the issue and outlined the steps needed to resolve it:

1. Provide your CPI/Integration Suite tenant URL. SAP adjusts parameters at the tenant runtime level.
2. Specify the new maxChildElements limit. Choose a value based on your maximal observed EPCIS batch size.
3. Approve a maintenance window for restart. SAP must restart your tenant’s processing node to activate new CXF settings. Downtime: 15–20 minutes.

💡Why a Tenant Restart Is Required — Even in a CI/CD Cloud

This is a common point of confusion.

CPI feels like a CI/CD-managed cloud service, so why does SAP need a restart? Here’s the reason in simple terms:

CPI is cloud-hosted, but each tenant still runs on Java/Camel runtimes.

When SAP changes CXF parser limits, they are modifying JVM-level runtime properties that Camel and CXF read only at startup.

Just like changing JVM memory parameters, thread pools, or parser configurations:
these cannot be hot-reloaded.

So the restart isn’t a flaw — it’s a consequence of:

• the underlying Java processes
• Camel routing engines
• CXF parser initialisation

It is normal and expected behaviour

✔️Key Takeaways

• CPI SOAP Adapter errors can be misleading when XML is too large.
• The real limits come from Apache CXF, not SAP configuration mistakes.
• EPCIS and similar standards may exceed maxChildElements.
• XML cannot always be made smaller — sometimes the standard dictates structure.
• SAP can raise limits, but must restart the tenant to apply changes.