Clean Core Architecture Guide #50

SAP Clean Core GraphQL & Apollo Federation on BTP Guide

⏱️ 15 min read 🏢 Enterprise Architectural Blueprint 🚀 Milestone Guide #50

Core Architectural Mandate: In a modern multi-experience Clean Core landscape, frontend applications (React, Next.js, mobile apps, customer portals) should never be tightly coupled to disparate SAP OData endpoints and external SaaS APIs. A side-by-side Apollo Federation Gateway running on SAP BTP consolidates these services into a single unified Supergraph schema with field-level precision and zero core modification.

1. The Problem: OData Waterfall Cascades & Over-Fetching

While SAP OData V4 is ideal for SAP Fiori Elements applications, external digital experience platforms suffer from severe architectural impedance:

Architectural Attribute	Direct OData V4 Consumption	BTP Apollo Federation Gateway
Roundtrips per Screen	5 - 15 sequential HTTP requests (Sales, Invoices, Partners, Tracking)	Single HTTP POST query
Payload Size	Heavy over-fetching (unwanted entity properties transferred across WAN)	Exact field-level precision (client specifies required keys)
Multi-Source Federation	Client manually aggregates SAP, Stripe, Salesforce, and ServiceNow	Unified declarative Supergraph resolved automatically by Gateway
Clean Core Boundary	Exposes internal S/4HANA OData endpoints directly to public Internet	Clean BTP side-by-side perimeter with OAuth2 token exchange

2. Anatomy of Apollo Federation v2 on SAP BTP

In Apollo Federation v2, each bounded domain operates an independent Subgraph. The Apollo Router (deployed as a high-speed Rust container on SAP BTP Kyma or Cloud Foundry) merges these subgraphs into a single composition graph without runtime coordination:

// S/4HANA Order Subgraph Schema
extend schema @link(url: "https://specs.apollo.dev/federation/v2.0", import: ["@key"])

type SalesOrder @key(fields: "id") {
  id: ID!
  orderNumber: String!
  netAmount: Float!
  currency: String!
}

// Payment Subgraph Schema (Stripe/Adyen Bridge)
extend type SalesOrder @key(fields: "id") {
  id: ID! @external
  paymentTransaction: PaymentRecord
}

Master Clean Core Side-by-Side Enterprise Architecture

Explore complete architectural patterns for Apollo Federation, SAP BTP API Management, OAuth2 Principal Propagation, and Event-Driven Architecture in The SAP Enterprise Architecture Suite.

Get the Full Architecture Suite (FLASH80 - 80% Off) →

3. Eliminating the N+1 Problem with DataLoaders

When resolving nested relationships (e.g. fetching line items or customer master records for 50 sales orders), naive GraphQL resolvers execute 50 individual OData calls.

In Clean Core architecture, developers deploy DataLoader batches:

The DataLoader captures all 50 IDs requested across the GraphQL execution tick.
It combines them into a single SAP OData V4 $filter=SalesOrder eq '1000' or SalesOrder eq '1001' query (or an OData $batch request).
The response payload is mapped back to the respective promises in memory, reducing 50 network calls to exactly 1 call to S/4HANA.

4. Principal Propagation & Security Perimeter

The BTP Apollo Federation Gateway acts as a secure identity broker:

The client authenticates via corporate IdP (Azure AD / Okta / SAP IAS) and passes a JWT bearer token.
The Apollo Gateway validates the JWT, strips sensitive internal headers, and exchanges the token via the SAP BTP Destination Service.
The request arrives at SAP S/4HANA with the verified enterprise user identity (ABAP SY-UNAME), enforcing standard RAP and DCL authorizations.

Summary Architectural Checklist

✅ Zero S/4HANA Core Modifications: Uses released standard OData V4 services.
✅ DataLoader Enabled: All nested resolvers wrapped to eliminate N+1 latency.
✅ Declarative Federation: Entities linked across systems via semantic keys (@key(fields: "id")).
✅ OAuth2 Token Exchange: User identity propagated end-to-end to ABAP authorization checks.

← Back to Interactive GraphQL Architect Tool