Tier 3
BTP
CAP
Upgrade Safe

Side-by-Side Extensions

Tier 3 extensibility — build independent applications on SAP BTP that integrate with S/4HANA exclusively through released public APIs. The most decoupled, upgrade-safe extension pattern in the SAP ecosystem.

Side-by-Side Architecture

The extension runs entirely on SAP BTP. S/4HANA is accessed only through released OData V4 APIs or business events — never via direct RFC, direct DB connection, or unreleased APIs. The extension has its own HANA Cloud database for extension-specific data.

Side-by-Side Extension Architecture on BTP
Rendering diagram…

Executive Summary

Zero-rework upgrades
Side-by-side extensions are completely independent of the S/4HANA upgrade cycle. When SAP upgrades S/4HANA from 2023 OP to 2025 OP, a properly built side-by-side extension requires zero changes — as long as it exclusively uses stable released APIs (C1 contract). This is the most powerful and future-proof extension pattern available in the SAP ecosystem.

When to Use Side-by-Side (Tier 3)

Choose Tier 3 when the requirement cannot be met by in-system Tier 2 tools (BAdIs, Custom Fields, Custom Business Objects). The indicators below each justify a side-by-side approach:

Extension requires its own database (extension data not fitting in standard S/4 model)
Complex UI beyond what Custom Fields / Fiori Elements provides
AI/ML capabilities (connect to AI Core, Gen AI Hub)
Integration with non-SAP systems in the same flow
Extension logic requires significant compute (batch jobs, data processing)
Multi-system integrations (S/4 + Ariba + SuccessFactors in one flow)

Technology Stack for Side-by-Side Extensions

Backend
CAP (Node.js or Java) — Cloud Application Programming Model
Frontend
SAPUI5, Fiori Elements (OData V4 annotations), or SAP Build Apps
Database
SAP HANA Cloud (HDI container for CAP)
Auth
XSUAA + App Router
Connectivity
Destination Service + Cloud Connector (on-prem) or Private Link (PCE)
Deployment
Cloud Foundry Runtime or Kyma

CAP Service Definition (CDS)

The CAP CDS model defines both the remote S/4HANA API projection and the local HANA Cloud extension entities in one unified service. CAP handles the OData proxy automatically.

typescript
// CAP Service — Side-by-side extension consuming S/4HANA Sales Orders
// srv/sales-enhancement.cds

using {API_SALES_ORDER_SRV as external} from '../srv/external/API_SALES_ORDER_SRV';

service SalesEnhancementService @(path: '/sales-ext') {

  // Projection over S/4HANA Sales Order — read via OData V4
  @readonly
  entity SalesOrders as projection on external.A_SalesOrder {
    SalesOrder,
    SoldToParty,
    TotalNetAmount,
    TransactionCurrency,
    SalesOrderDate,
    // Extension custom fields (stored in HANA Cloud HDI)
    virtual approvalStatus : String,
    virtual assignedAgent   : String,
    virtual dueDate         : Date,
  }

  // Custom extension entity — purely in HANA Cloud (no S/4 involvement)
  entity SalesApprovals : managed {
    key ID           : UUID;
        salesOrder   : String(10);
        requestedBy  : String(100);
        approvedBy   : String(100);
        status       : String enum { pending; approved; rejected; } default 'pending';
        comments     : LargeString;
  }

  // Action: update approval status + notify S/4HANA via API
  action submitApproval(salesOrder: String, decision: String, comment: String) returns Boolean;
}

CAP Action Handler (TypeScript)

The action handler updates the local HANA Cloud record first, then calls the released S/4HANA OData V4 API to write the approval status back. Both operations are part of the same business transaction.

typescript
// srv/sales-enhancement.ts — Action handler
import cds from '@sap/cds'

export class SalesEnhancementService extends cds.ApplicationService {
  async init() {
    const s4 = await cds.connect.to('API_SALES_ORDER_SRV')

    this.on('submitApproval', async (req) => {
      const { salesOrder, decision, comment } = req.data

      // 1. Update local approval record in HANA Cloud
      await UPDATE('SalesApprovals')
        .set({ status: decision, comments: comment, approvedBy: req.user.id })
        .where({ salesOrder })

      // 2. If approved — update S/4HANA via released API
      if (decision === 'approved') {
        await s4.run(
          UPDATE('A_SalesOrder')
            .set({ YY1_ApprovalStatus_SDH: 'APPROVED' })
            .where({ SalesOrder: salesOrder })
        )
      }
      return true
    })

    await super.init()
  }
}

Enterprise Example: DEWA Procurement Approval Extension

Use case
High-value PO approval workflow (> AED 500,000)
Runtime
BTP Cloud Foundry (CAP Node.js)
S/4 API used
I_PurchaseOrder (OData V4, released C1)
Extension data store
SAP HANA Cloud (HDI container)
Notifications
Email + MS Teams via Integration Suite
Write-back
Released S/4HANA API — approval status update
S/4 modifications
Zero

Best Practices

Verify APIs on api.sap.com first

Always confirm the OData V4 API is released (C1 contract) on api.sap.com before implementing the integration — unreleased APIs can disappear after an upgrade.

Store only extension data in HANA Cloud

Never replicate full S/4HANA master data tables to HANA Cloud. Fetch live data via API. Replication creates sync complexity and data consistency risks.

Use CAP's remote service feature

CAP's remote service binding auto-generates OData proxy code — reduces boilerplate and keeps API integration in the CDS model layer.

Subscribe to API deprecation notices

Enable email alerts on SAP API Business Hub for the APIs you consume — gives advance warning before an API is retired in a future S/4HANA release.

Design as independent services

Extension APIs must not be tightly coupled to S/4HANA schema versions. Use abstraction layers so a minor S/4 OData field rename does not break the extension.

Common Pitfalls

Unreleased RFCs via Cloud Connector
Connecting to S/4HANA via RFC through Cloud Connector defeats the entire clean core purpose — RFC-based APIs have no stability contract.
Replicating large S/4 tables to HANA Cloud
Replicating sales orders, materials, or BP tables to HANA Cloud creates performance issues and sync complexity. Use live API calls instead.
Not handling S/4HANA API errors gracefully
If S/4HANA is unavailable, the extension must degrade gracefully. Do not let a down S/4 system make the entire BTP extension unavailable.
Side-by-side for use cases better served by a BAdI
If the requirement is a simple validation on a standard SAP document, a released BAdI (Tier 2) is faster to build and simpler to maintain.

Security Considerations

Sensitive business data on BTP
Side-by-side extensions handle sensitive business data (PO amounts, customer data, financials). Implement XSUAA scope-based authorisation on all CAP service endpoints. Use OAuth2SAMLBearerAssertion for principal propagation to S/4HANA to maintain a proper audit trail. Validate all inputs in CAP service handlers. Enable SAP BTP Audit Log service for all data modification operations — required for UAE PDPL compliance.