Failed EDI XML import in transportation management due to incorrect namespace URI in carrier integration

SCM Oracle Fusion Cloud SCM
, , , , , , , ,
1

We’re onboarding a new carrier for freight shipments and their EDI XML messages are failing to import into OTM. The error log shows “Invalid namespace URI - expected http://xmlns.oracle.com/apps/scm/transportation/shipment/v2 but found http://carrier-systems.com/edi/v1”.

Our carrier sends shipment status updates via XML that should populate into Manage Shipments. The XSD schema validation is rejecting their namespace. We’ve configured the carrier integration with their endpoint URL and authentication, but the namespace URI validation is blocking all messages.

Is there a way to configure namespace mapping for carrier EDI onboarding, or do we need to transform their XML format before importing? The carrier can’t change their namespace structure as it’s used across their customer base.

2

The OTM import process validates against Oracle’s standard XSD schemas. If the carrier’s namespace doesn’t match, you have two options: transform the XML before import using an integration layer, or configure a custom schema mapping. Most implementations use OIC or similar middleware to transform carrier-specific XML to Oracle’s expected format.

3

Let me provide a complete solution for handling carrier EDI XML with namespace mismatches in OTM. This requires understanding three key aspects:

1. XSD Schema Versioning and Namespace Requirements

Oracle Transportation Management in 24a uses strict XSD validation for all inbound EDI messages. The current shipment schema version is v2 with namespace:


http://xmlns.oracle.com/apps/scm/transportation/shipment/v2

This namespace URI is hardcoded in the import validation logic and cannot be configured to accept alternative namespaces. The schema version (v2) indicates specific element structures that differ from v1:

  • ShipmentHeader: v2 requires ShipmentNumber (mandatory), v1 used ShipmentId (optional)
  • StatusCode: v2 uses enumerated values (PLANNED, IN_TRANSIT, DELIVERED), v1 used free text
  • AddressStructure: v2 requires separate AddressLine1-4 elements, v1 used single Address element
  • DateTimeFormat: v2 enforces ISO 8601 format, v1 accepted multiple formats

Your carrier’s v1 schema will have structural incompatibilities beyond just the namespace URI.

2. Namespace URI Validation and Transformation Strategy

The namespace validation occurs at the XML parser level before business logic processing. The error “Invalid namespace URI” means the parser rejected the document immediately. To resolve this, implement a two-stage transformation in OIC:

Stage 1: Namespace Replacement

<xsl:stylesheet version="2.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:carrier="http://carrier-systems.com/edi/v1"
  xmlns:oracle="http://xmlns.oracle.com/apps/scm/transportation/shipment/v2">

  <xsl:template match="carrier:*">
    <xsl:element name="oracle:{local-name()}"
                 namespace="http://xmlns.oracle.com/apps/scm/transportation/shipment/v2">
      <xsl:copy-of select="@*"/>
      <xsl:apply-templates/>
    </xsl:element>
  </xsl:template>
</xsl:stylesheet>

Stage 2: Element Mapping for Schema Compliance

<xsl:template match="carrier:ShipmentId">
  <oracle:ShipmentNumber>
    <xsl:value-of select="."/>
  </oracle:ShipmentNumber>
</xsl:template>

<xsl:template match="carrier:Status">
  <oracle:StatusCode>
    <xsl:choose>
      <xsl:when test=". = 'shipped'">IN_TRANSIT</xsl:when>
      <xsl:when test=". = 'completed'">DELIVERED</xsl:when>
      <xsl:otherwise>PLANNED</xsl:otherwise>
    </xsl:choose>
  </oracle:StatusCode>
</xsl:template>

This two-stage approach ensures both namespace compliance and element-level schema validation.

3. Carrier EDI Onboarding Configuration

In Transportation Management Setup, configure the carrier integration with transformation awareness:

  • Carrier Profile: Create carrier with EDI capability enabled
  • Communication Method: Set to “Web Service” pointing to your OIC integration endpoint (not directly to carrier)
  • Message Format: Select “Custom XML with Transformation”
  • Transformation Service: Reference your OIC integration that performs the XSLT transformation
  • Schema Validation: Keep enabled - validation occurs AFTER transformation

The integration flow should be:


Carrier System → OIC (XSLT Transform) → OTM Import Service → Shipment Data

Never point OTM directly at the carrier endpoint when namespace/schema differences exist. Always use middleware for transformation.

Complete OIC Integration Pattern:

  1. REST/SOAP Adapter: Receive carrier XML message
  2. Stage 1 Transformation: Apply namespace replacement XSLT
  3. Schema Validation: Validate against intermediate schema (optional but recommended)
  4. Stage 2 Transformation: Apply element mapping XSLT
  5. Oracle OTM Adapter: Send transformed XML to OTM import service
  6. Error Handling: Capture validation failures and notify carrier via callback

Handling Schema Version Differences:

Since your carrier uses v1 and Oracle expects v2, create a comprehensive mapping document:

  • Download Oracle’s Transportation Shipment XSD v2 from the OTM documentation
  • Obtain carrier’s XSD v1 specification
  • Map each carrier element to corresponding Oracle element
  • Identify missing required elements (Oracle v2 has ~15 mandatory fields)
  • For missing elements, define default values in your XSLT

Example default handling:

<xsl:template match="carrier:Shipment">
  <oracle:Shipment>
    <xsl:apply-templates/>
    <!-- Add required elements missing from carrier v1 -->
    <oracle:ShipmentMode>TRUCK</oracle:ShipmentMode>
    <oracle:ServiceLevel>STANDARD</oracle:ServiceLevel>
  </oracle:Shipment>
</xsl:template>

Testing and Validation:

  1. Test transformation with sample carrier XML in OIC
  2. Validate transformed output against Oracle XSD v2 using XML validator
  3. Submit test message to OTM sandbox environment
  4. Review import log for any remaining validation errors
  5. Iterate transformation logic until clean import

Alternative Approach (Not Recommended):

Some implementations try to work around namespace validation by:

  • Removing namespace declarations entirely (creates non-standard XML)
  • Using Oracle’s SOAP envelope to wrap carrier XML (bypasses validation but fails at business logic layer)
  • Requesting Oracle Support to disable namespace validation (not supported in SaaS)

These approaches cause downstream issues and should be avoided. Proper XSLT transformation is the supported and reliable method.

For your specific carrier onboarding, implement the two-stage XSLT transformation in OIC, ensure all v2 mandatory elements are populated (with defaults if needed), and configure the carrier profile to use your transformation service endpoint. This will resolve both the namespace URI validation error and ensure complete schema compliance for successful shipment data import.

4

We do have OIC available. Would the transformation need to replace the namespace URI in every XML element, or just the root element? The carrier’s message structure otherwise matches Oracle’s shipment schema - it’s really just the namespace declaration that’s different.

Also, does OTM support custom XSD schema registration for carrier-specific formats, or is transformation the only approach?

5

You need to transform the entire namespace throughout the document, not just the root element. XML namespace applies to all child elements unless overridden. In OIC, use an XSLT transformation that replaces the carrier namespace with Oracle’s expected namespace.

Here’s a basic XSLT pattern:

<xsl:template match="carrier:*">
  <xsl:element name="oracle:{local-name()}" namespace="http://xmlns.oracle.com/apps/scm/transportation/shipment/v2">
    <xsl:apply-templates/>
  </xsl:element>
</xsl:template>

OTM doesn’t support custom schema registration for carrier EDI. The import process strictly validates against Oracle’s published XSD versions. This is intentional to maintain data integrity across the transportation management data model.

6

Yes, you’ll likely need element mapping beyond just namespace replacement. Schema versioning often involves element name changes or structural differences. Compare the carrier’s XSD with Oracle’s Transportation Shipment XSD v2 to identify:

  • Renamed elements (e.g., carrier uses “shipmentId” but Oracle expects “ShipmentNumber”)
  • Different cardinality (carrier might have single Address element where Oracle expects multiple AddressLine elements)
  • Additional required elements in Oracle’s schema that carrier doesn’t provide

You’ll need a comprehensive XSLT that handles both namespace transformation and element mapping. The namespace URI validation is just the first check - even with correct namespace, element-level validation will fail if names don’t align with the v2 schema.

7

That XSLT approach makes sense. One concern: the carrier’s schema version is v1, but Oracle’s is v2. If we just replace the namespace, will there be element name mismatches that cause validation failures? Should we be mapping specific elements in addition to the namespace transformation?