SAP Integration Patterns for .NET

SAP integration is one of those topics where the documentation is either too abstract or too vendor-specific. After spending months building integrations between our .NET systems and SAP at Pacific Gold, here are the patterns that actually work in production.

The Landscape

There are several ways to connect .NET to SAP:

• RFC (Remote Function Call): Direct function calls to SAP modules. Fast, synchronous, but tightly coupled.
• IDocs (Intermediate Documents): Asynchronous document exchange. Better for batch operations and loose coupling.
• OData/REST APIs: SAP’s newer HTTP-based APIs. Cleaner but not available for all modules.
• HVR/CDC: Change Data Capture for real-time data replication. Great for reporting.

Pattern 1: RFC for Real-Time Lookups

When your application needs to validate a material number or check stock availability in real-time, RFC is the way to go. The SAP .NET Connector (NCo) makes this relatively straightforward:

public class SapMaterialService
{
    private readonly RfcDestination _destination;

    public MaterialInfo GetMaterial(string materialNumber)
    {
        var function = _destination
            .Repository
            .CreateFunction("BAPI_MATERIAL_GET_DETAIL");

        function.SetValue("MATERIAL", materialNumber);
        function.Invoke(_destination);

        // Map SAP structures to your domain model
        var header = function.GetStructure("MATERIAL_GENERAL_DATA");
        return new MaterialInfo
        {
            Number = header.GetString("MATERIAL"),
            Description = header.GetString("MATL_DESC"),
            Unit = header.GetString("BASE_UOM"),
        };
    }
}

The key lesson: always wrap SAP calls behind your own service interface. SAP function signatures are stable but verbose — abstracting them keeps your domain code clean.

Pattern 2: IDocs for Batch Sync

For synchronizing master data (customers, materials, pricing), IDocs are the better choice. They’re asynchronous, support retry logic, and SAP has built-in monitoring for failed IDocs.

We process incoming IDocs through a queue:

1. SAP sends IDoc to our middleware endpoint
2. We parse and validate the IDoc XML
3. Valid documents go to a processing queue
4. Each processor maps the IDoc to domain events
5. Failed processing gets logged with the original IDoc for replay

Pattern 3: HVR for Reporting

This was a game-changer for our PowerBI and Metabase dashboards. Instead of querying SAP directly (which SAP admins hate), HVR replicates SAP tables to a PostgreSQL database in near-real-time.

The replicated tables maintain SAP’s structure, so we built a view layer on top that transforms the cryptic SAP column names into something readable. Our dashboards query these views — fast, no load on SAP, and always up to date.

The Hardest Part

The hardest part of SAP integration isn’t the code — it’s understanding SAP’s data model. Field names like MANDT, MATNR, WERKS make sense to SAP consultants but are cryptic to developers. Invest time in understanding the SAP tables and relationships before writing a single line of integration code.

Build a data dictionary early. Document every SAP field you use, its meaning, and its constraints. Your future self will thank you.