SAP Integration, BTP & Cloud Development

Modern integrations consume APIs instead of direct database access. SAP's standard protocol for app integration is OData (Open Data Protocol) — RESTful, with metadata describing entities, relationships, and operations.

SAP Gateway exposes OData services from ABAP:

" Service built from CDS view ZC_SalesOrder with @OData.publish
" Registered in /IWFND/MAINT_SERVICE, consumed at:
" /sap/opu/odata/sap/ZSD_SALES_ORDER_SRV/SalesOrderSet('4500000123')

Key OData operations:

HTTP	Operation	Use
GET	Read	Query entities, filter, expand associations
POST	Create	Create sales order, notification
PUT/PATCH	Update	Change fields on existing entity
DELETE	Remove	Delete (where allowed by business rules)

S/4HANA Cloud APIs ship pre-built OData services for core processes. On-premise customers use API Hub documentation to discover service names, payloads, and required authorizations.

Security: API calls require authentication — OAuth 2.0 (common on BTP and cloud), basic auth (discouraged), or SAP logon tickets in trusted RFC scenarios. Never expose OData without authorization checks; CDS @AccessControl.authorizationCheck enforces ABAP auth objects at the data layer.

Pagination and performance: Use $top, $skip, $filter — pulling entire tables crashes gateways and violates audit policy.

SAP BTP (Business Technology Platform) is SAP's cloud PaaS for extending and integrating SAP — without modifying core ERP (keep the clean core).

Major BTP capabilities:

Service	Purpose
Integration Suite (CPI)	Cloud-based iPaaS — connect SAP to Salesforce, AWS, partners
Extension Suite	Build side-by-side extensions (CAP, RAP on BTP ABAP Environment)
HANA Cloud	Managed database for analytics and apps
Workflow / Build	Process automation and low-code apps
Destination & Connectivity	Secure tunnels to on-premise systems without opening inbound firewall ports

Side-by-side extension pattern: Core S/4HANA stays standard; custom logic runs on BTP and calls published APIs. Upgrades hurt less because Z-code in the core is minimized.

[Partner SaaS] ←→ [SAP Integration Suite CPI] ←→ [S/4HANA OData/API]
                         ↕
                   [BTP Extension App]

Subaccounts and environments: BTP organizes resources into global account → subaccount → environment (Cloud Foundry or Kyma). Destinations store connection details; Cloud Connector bridges on-premise securely.

Employees in integration roles should know which landscape (dev/test/prod BTP subaccount) maps to which SAP backend — cross-wiring causes real invoices in test systems.

SAP supports multiple integration styles; choice depends on partner capability, volume, and latency requirements.

IDoc (Intermediate Document) — SAP's canonical asynchronous message format for B2B and internal ALE distribution:

Partner → IDoc (ORDERS05) → SAP → Post sales order
SAP → IDoc (INVOIC02) → Partner → Receive invoice

IDocs flow through ALE (Distributed) or EDI (External). Monitoring: WE02 (display IDoc), BD87 (reprocess failed). Status codes 51/56 indicate application errors needing functional fix.

RFC / BAPI — synchronous remote function calls. BAPIs are RFC-enabled, documented business objects (BAPI_SALESORDER_CREATEFROMDAT2). Prefer OData for new web integrations; BAPIs remain common in legacy middleware.

SAP Integration Suite (CPI) — graphical iFlows map messages:

1. Sender adapter (HTTP, SFTP, SOAP, OData).
2. Mapping (Message Mapping, Groovy script, XSLT).
3. Receiver adapter (S/4 OData, IDoc, third-party REST).

[SuccessFactors] → CPI iFlow (transform) → S/4 Employee OData API
[S/4 IDoc DESADV] → CPI → [Warehouse WMS REST]

Error handling: CPI provides retry, alerting, and MPL (Message Processing Log). Design idempotent receivers — the same IDoc may arrive twice after network retry.

When to use what:

• Real-time UI → OData/REST.
• High-volume batch partners → IDoc or file + CPI.
• Legacy SAP-to-SAP → IDoc/RFC still prevalent.

ABAP RESTful Application Programming (RAP) is SAP's framework for building Fiori-ready, OData-backed apps on S/4HANA — replacing many custom MVC Web Dynpro patterns.

RAP stack (simplified):

CDS Data Model → Behavior Definition (BDEF) → Service Definition → OData Binding → Fiori App

Behavior pools define create, update, delete, and validations on business objects. EML (Entity Manipulation Language) replaces direct table updates in UI code.

Cloud ABAP Environment (BTP) runs RAP extensions side-by-side — same concepts, restricted whitelists of released APIs (Communication Scenarios).

Security & compliance:

• SU01 / PFCG — users and roles; principle of least privilege.
• SOD analysis — GRC prevents toxic role combinations.
• Secure coding — no hard-coded credentials; use SM59 destinations and BTP secrets.

Change management & transports:

DEV (client 100) → QA (client 200) → PRD (client 300)
         Transport request (SE09/SE10) moves objects

Never configure directly in production. CTS+ transports ABAP objects; gCTS (Git-enabled CTS) integrates with version control for modern teams.

Monitoring toolbox:

Tool	Purpose
SM21	System log
ST22	ABAP runtime dumps (short dumps)
SM37	Background job status
WE02 / CPI MPL	Integration message tracking
Solution Manager / Focused Run	Centralized ops dashboards

Production incidents often trace to failed transports, expired certificates on CPI connections, or OData services missing authorizations — check integration logs before re-running failed business transactions.