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.
Executive Summary
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:
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.
// 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.
// 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
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.
Never replicate full S/4HANA master data tables to HANA Cloud. Fetch live data via API. Replication creates sync complexity and data consistency risks.
CAP's remote service binding auto-generates OData proxy code — reduces boilerplate and keeps API integration in the CDS model layer.
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.
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.