How We Wired an E-Commerce Platform to SAP (and What We Learned the Hard Way)

The Problem Statement

If you've ever worked on an e-commerce platform that needs to talk to SAP, you already know the fun: two worlds with completely different ideas about data, timing, and what constitutes an "error." On one side, you've got a modern web application that needs sub-second responses during checkout. On the other, you've got an ERP system designed for batch processing and back-office workflows that communicates over SOAP.

This post walks through the architecture we built to bridge that gap — covering the data flow from storefront to SAP, how we handle failures (spoiler: there are many flavors), and design decisions we'd either repeat or do differently next time.

Architecture Overview: The Three-Layer Sandwich

┌──────────────────────────────────────────────┐
│   Web Layer (Controllers / API Endpoints)    │
│   Handles HTTP requests, auth, routing       │
├──────────────────────────────────────────────┤
│   Application Layer (Domain Services)        │
│   Orchestrates business logic, maps models   │
├──────────────────────────────────────────────┤
│   ERP Integration Layer (SOAP Clients)       │
│   Translates domain objects → SOAP calls     │
│   Manages credentials, timeouts, retries     │
└──────────────────────────────────────────────┘

The key insight: the integration layer is its own isolated project. When SAP changes its WSDL (and it will), the blast radius is contained to a single project.

Data Flow: From Cart to SAP

Two-Phase Order Handoff

Phase 1 — Order Simulation (during checkout)

[Customer Cart] → [YourOrderService].SimulateOrder()
    → Convert address DTO → [ErpAddress]
    → Convert line items → [ErpLineItem[]]
    → Load locale-specific ERP config
    → Call ERP SOAP endpoint: SimulateOrder
    → Parse response → extract tax + shipping totals
    → Return to checkout UI

Phase 2 — Order Creation (post-payment)

[OrderPlaced Event] → [YourOrderHandler].Handle()
    → Load ERP config for current locale
    → Check if real-time ordering is enabled
    → Build shipping + billing addresses
    → Call ERP SOAP endpoint: CreateOrder
    → On success: store ERP order number
    → On failure: set order status, notify admins

The Event-Driven Decoupling

// Illustrative — not actual production code
public class [YourOrderHandler] : INotificationHandler<[OrderPlacedEvent]>
{
    public async Task Handle([OrderPlacedEvent] notification, CancellationToken ct)
    {
        var erpConfig = _configProvider.GetErpConfig(currentLocale);
        if (erpConfig == null || !erpConfig.RealTimeOrderEnabled)
        {
            await _mediator.Publish(new [StaffNotification](order), ct);
            return;
        }
        var errors = _erpOrderService.CreateOrder(
            shippingAddress, billingAddress, lineItems,
            paymentInfo, erpConfig, out string erpOrderNumber);
        if (errors.Any())
            await HandleErpFailure(order, errors, ct);
        else
            await HandleErpSuccess(order, erpOrderNumber, ct);
    }
}

The SOAP Client: Configuration Matters More Than You Think

private [ErpSoapClient] BuildSoapClient()
{
    var binding = new BasicHttpBinding
    {
        Security = {
            Mode = BasicHttpSecurityMode.Transport,
            Transport = { ClientCredentialType = HttpClientCredentialType.Basic }
        },
        MaxReceivedMessageSize = 20_000_000,
        SendTimeout = TimeSpan.FromSeconds(90)
    };
    var client = new [ErpSoapClient](binding, new EndpointAddress(_erpEndpoint));
    client.ClientCredentials.UserName.UserName = _erpUsername;
    client.ClientCredentials.UserName.Password = _erpPassword;
    return client;
}

• 90-second timeout. SAP is not fast. Default WCF timeouts will kill you.
• 20MB buffer sizes. B2B order history responses can be massive.
• No client reuse. WCF channel faulting breaks all subsequent calls on a faulted instance.

Error Handling: The Taxonomy of SAP Failures

1. Pre-flight Validation

if (config.SalesOrganization.IsNullOrEmpty())
{
    errors.Add(new [ErpMessage]("E", "", "ERP config missing for this locale"));
    return errors;
}

2. SOAP Response Errors

var fatalErrors = erpResponse.Messages
    .Where(m => m.Type == "E" || m.Type == "Error")
    .Where(m => !(m.Number == "219" && m.Category == "V4"))  // Known non-fatal
    .Select(m => new [ErpMessage](m.Type, m.Number, m.Text));

3. Null Response & 4. Exception-Level Failures

Every layer of the response must be null-checked defensively. Network timeouts and SOAP faults are caught at the top level and trigger the admin notification pipeline.

Admin Notification Pipeline

Order sync fails
    │
    ├── Set order status → AwaitingExchange
    ├── Attach error note to order
    └── Send templated email to ERP admins
            └── Fallback: current locale → parent locale → English

Customer Sync: The Other Half

E-commerce → SAP:  New customer creation, address verification, VAT/PAN checks
SAP → E-commerce:  Address sync (SAP is master), customer number assignment
SAP → Identity:    SAP customer number pushed back to identity provider

Lessons Learned

1. SAP config is per-locale, not global. Model this from day one.
2. "Simulate before you create" saves orders. Catches pricing issues before payment.
3. Not all SAP "errors" are errors. Build a catalog of known non-fatal messages.
4. SOAP isn't dead, it's just hiding. Design the transport as a swappable layer.
5. Payment mapping is complex. Varies by processor and market.
6. Never trust negative values. Validate SAP tax/shipping totals before checkout.

Final Thoughts

Building an e-commerce-to-SAP integration is fundamentally a translation problem. Isolate the translation layer, validate aggressively at every boundary, and assume every SAP call can fail in ways you haven't imagined yet.

This post describes architectural patterns observed in production e-commerce SAP integrations. All identifiers, endpoints, and implementation details have been genericized.