SOAP API integration fails in Integration Hub due to XML nam

BPM Mendix
, , , , , , , ,
1

We’re integrating with a legacy ERP system via SOAP API using Mendix 10.6 Integration Hub. The WSDL imports successfully, but when we call the service, we get namespace mismatch errors.

The external service expects:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:erp="http://company.com/erp/v2">

But Integration Hub generates:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ns1="http://company.com/erp/v2">

The ERP system rejects this with “Invalid namespace prefix” error. We need the exact prefix ‘erp’ instead of ‘ns1’. Is there a way to control namespace prefixes in Mendix SOAP calls, or do we need a custom Java action to manipulate the XML before sending?

2

Before going the custom Java route, check if the WSDL has namespace prefix hints in annotations. Some WSDLs include preferred prefixes that Mendix might respect. Also, verify the ERP vendor’s WSDL is actually valid - I’ve seen cases where they provide incorrect WSDLs that don’t match their actual implementation.

3

I validated the WSDL with multiple tools and it’s technically correct. The vendor confirmed their system does strict prefix matching for “security reasons” (which makes no sense to me). Looks like we need the custom Java action approach.

4

One alternative before writing custom Java - check if you can use a proxy service that normalizes the XML. Deploy a simple Node.js or Python service that receives Mendix’s SOAP call, transforms the prefixes, forwards to ERP, and returns the response. This keeps your Mendix code cleaner and makes the transformation logic reusable.

5

That’s frustrating - the ERP vendor insists they’re following SOAP standards. Can you point me to an example Java action for XML namespace manipulation? I’m not very familiar with Java XML processing APIs.

6

Here’s a comprehensive solution covering SOAP XML namespace mapping, WSDL import quirks, and custom Java action implementation:

1. Understanding the WSDL Import Issue:

Mendix Integration Hub generates namespace prefixes automatically based on import order. The WSDL structure affects this:

<!-- WSDL defines target namespace -->
<definitions targetNamespace="http://company.com/erp/v2"
             xmlns:tns="http://company.com/erp/v2">

Mendix sees tns but generates ns1, ns2 etc. for consistency across all imported services.

2. Custom Java Action for Namespace Prefix Mapping:

Create SOAPNamespaceMapper.java in your Mendix project:

public class SOAPNamespaceMapper extends CustomJavaAction<String> {
    public String executeAction() throws Exception {
        String inputXML = this.InputXML;
        Document doc = parseXMLString(inputXML);
        remapNamespaces(doc);
        return serializeDocument(doc);
    }
}

3. WSDL Import Workaround:

For services with strict prefix requirements, use a two-step approach:

  • Import WSDL to generate domain model and basic structure
  • Override the actual SOAP call with custom Java action
  • Keep domain model mapping but control XML generation

In your microflow:


// Instead of: Call SOAP Service directly
// Do: Build request object → Java action → Parse response
requestObject = createSOAPRequest();
rawXML = SOAPNamespaceMapper(requestObject);
responseXML = HTTPPost(url, rawXML);
responseObject = parseSOAPResponse(responseXML);

4. Complete Java Implementation:

import org.w3c.dom.*;
import javax.xml.parsers.*;
import javax.xml.transform.*;

private void remapNamespaces(Document doc) {
    Element root = doc.getDocumentElement();
    remapPrefixRecursive(root, "ns1", "erp");
}

private void remapPrefixRecursive(Node node, String oldPrefix, String newPrefix) {
    if (node.getPrefix() != null && node.getPrefix().equals(oldPrefix)) {
        doc.renameNode(node, node.getNamespaceURI(), newPrefix + ":" + node.getLocalName());
    }
    NodeList children = node.getChildNodes();
    for (int i = 0; i < children.getLength(); i++) {
        remapPrefixRecursive(children.item(i), oldPrefix, newPrefix);
    }
}

5. Alternative: XSLT Transformation:

For complex namespace requirements, use XSLT:

<!-- namespace-transform.xslt -->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="*[namespace-uri()='http://company.com/erp/v2']">
    <xsl:element name="erp:{local-name()}" namespace="http://company.com/erp/v2">
      <xsl:apply-templates select="@*|node()"/>
    </xsl:element>
  </xsl:template>
</xsl:stylesheet>

Apply in Java action using TransformerFactory.

6. Handling WSDL Import Quirks:

Common issues and solutions:

  • Multiple namespace declarations: Mendix consolidates them - verify all required namespaces are present
  • Nested complex types: May generate unexpected prefixes - test with sample data
  • Optional elements: Mendix includes nil elements - some services reject these

For optional element issues, add filtering:

// Remove nil elements before sending
NodeList nilElements = doc.getElementsByTagNameNS(
    "http://www.w3.org/2001/XMLSchema-instance", "nil");
for (int i = nilElements.getLength() - 1; i >= 0; i--) {
    Node nil = nilElements.item(i);
    nil.getParentNode().removeChild(nil);
}

7. Testing and Validation:

Create comprehensive test suite:


1. Generate XML with Mendix SOAP service
2. Apply namespace transformation
3. Validate against ERP's XSD schema
4. Test with ERP's validation endpoint (if available)
5. Compare with vendor-provided sample XML

8. Production Considerations:

  • Cache the XSLT transformer for performance (static initialization)
  • Log both original and transformed XML in development
  • Add error handling for malformed vendor responses
  • Document the specific namespace mappings required
  • Version control your Java action with WSDL version

9. Long-term Solution:

Work with ERP vendor to:

  • Understand why they require specific prefixes (likely legacy code)
  • Request relaxed validation or provide correct WSDL with prefix hints
  • Consider REST API alternative if available

This approach has successfully integrated with SAP, Oracle, and legacy mainframe SOAP services that have strict XML requirements. The key is intercepting and transforming XML at the right point in the integration flow.