OData integration with external TMS fails due to XML mapping error in transportation-mgmt (si-2211)

SCM SAP IBP
, , , , , , , ,
1

We’re experiencing critical failures in our OData integration between SAP IBP transportation-mgmt and an external TMS system. The integration worked fine initially, but after updating our TMS to version 3.2, shipments are not syncing properly.

The error logs show XML schema validation failures when the middleware attempts to map OData metadata from IBP to the TMS format. Specifically, the ShipmentHeader entity is being rejected with “Element ‘PlannedDeliveryDate’ is not expected” errors.

Our middleware (SAP CPI) shows the OData metadata structure from IBP includes fields that don’t align with the TMS XML schema expectations. We’ve checked the $metadata endpoint and confirmed IBP is sending the correct structure per si-2211 documentation.

This is blocking 200+ daily shipments and causing significant delays. Has anyone dealt with OData-to-XML mapping issues in transportation integrations after TMS upgrades?

2

Thanks for the quick response. I compared the schemas and you’re right - the TMS changed several field names and added mandatory namespace prefixes. The date fields now require ‘tms:’ namespace prefix and some fields were renamed.

I’m working on updating the XSLT mapping in CPI, but I’m concerned about future schema changes. Is there a way to make the mapping more flexible?

3

Check if your TMS vendor provides WSDL or OpenAPI specifications for their updated API. Many modern TMS systems are moving away from pure XML and offering REST endpoints that might be easier to integrate with IBP’s OData services.

If they don’t have REST APIs yet, at least request their XSD schema files for each version. You can use these to auto-generate validation rules in CPI and catch breaking changes during testing rather than production.

4

For resilience against schema changes, consider implementing a two-layer mapping approach in CPI. Create an intermediate canonical format that sits between IBP’s OData structure and the TMS XML schema. This way, when either system changes, you only need to update one transformation layer instead of the entire mapping.

Also, add schema validation steps in your iFlow with proper error handling. This helps catch mapping issues before they reach the TMS and provides clearer error messages for troubleshooting.

5

Let me provide a comprehensive solution addressing the OData metadata alignment, XML schema validation, and middleware mapping challenges:

OData Metadata Analysis: First, retrieve the current metadata structure from IBP transportation-mgmt:


GET https://[tenant].sapibp.cloud/sap/ibp1/transportation/Shipments/$metadata
Authorization: Bearer [token]

Export this to XML and compare against your TMS 3.2 XSD schema. Document all field name discrepancies, namespace changes, and data type modifications.

XML Schema Validation Setup: In SAP CPI, create a validation step before transformation:

  1. Import the TMS 3.2 XSD schema into your CPI tenant
  2. Add an XML Validator step in your iFlow immediately after receiving OData response
  3. Configure validation to fail fast with detailed error messages
  4. This catches schema mismatches before attempting transformation

Middleware Mapping Solution: Implement a three-stage mapping pattern:

Stage 1 - OData to Canonical (Groovy script):

def shipment = message.getBody(String)
def canonical = new JsonBuilder()
canonical.shipment {
    id message.properties.get('ShipmentID')
    deliveryDate message.properties.get('PlannedDeliveryDate')
}

Stage 2 - Field Name Mapping (maintain in Value Mapping):

Create Value Mappings in CPI for field name translations:

  • Source: IBP_PlannedDeliveryDate → Target: TMS_DeliveryDatePlanned
  • Source: IBP_ShipmentHeader → Target: TMS_Header

Stage 3 - Canonical to TMS XML (XSLT with namespace handling):

<xsl:template match="shipment">
  <tms:Shipment xmlns:tms="http://tms-vendor.com/v3.2">
    <tms:DeliveryDatePlanned>
      <xsl:value-of select="deliveryDate"/>
    </tms:DeliveryDatePlanned>
  </tms:Shipment>
</xsl:template>

Additional Recommendations:

  1. Version your iFlow configurations - maintain separate versions for different TMS schema releases
  2. Implement retry logic with exponential backoff for transient failures
  3. Add monitoring alerts for schema validation failures
  4. Create a regression test suite with sample OData responses and expected TMS XML outputs
  5. Document the field mapping matrix and share with both IBP and TMS teams

For Future TMS Upgrades:

  • Request XSD schemas during UAT phase
  • Run parallel testing with old and new schemas
  • Use CPI’s multi-version iFlow capability to switch between mappings
  • Implement feature toggles to rollback quickly if issues arise

This approach has resolved similar integration issues in transportation-mgmt scenarios and provides the flexibility to handle future schema changes with minimal disruption. The key is isolating the transformation logic into maintainable layers rather than monolithic XSLT mappings.