SAP System Exposure: The Complete Integration Capability Guide for ECC & S/4HANA
IMPORTANT NOTE:
This guide is based on practical hands-on experience across SAP ECC and S/4HANA landscapes. While we've referenced official SAP documentation and community resources throughout, capabilities may vary based on:
- NetWeaver version and support package levels
- Installed add-ons and components
- System configuration and authorizations
- SAP release versions.
For architecture decisions and production implementations, always consult:
- Official SAP Help documentation (https://help.sap.com)
- SAP Notes for specific component details
- SAP Business Accelerator Hub (https://api.sap.com) for released APIs
- Your SAP Basis team for system-specific configurations
This document focuses on what SAP systems CAN expose and consume. Integration middleware patterns (SAP Integration Suite, PI/PO) are mentioned for context but are not the primary focus.
1. INTRODUCTION
When I'm asked to integrate an external system with SAP, the first question isn't "which tool should I use?" It's "what can SAP actually expose?"
After few years working across SAP ECC and S/4HANA landscapes with Integration Suite, I've learned that understanding what's available in your SAP system is just as critical as knowing how to integrate it. Yet most integration guides skip this foundation and jump straight to implementation.
This is the reference guide, it maps every integration capability available in SAP ECC and S/4HANA On-Premises systems, explains when to use each protocol, and provides the checklists you need to prepare your systems for Integration Suite connectivity.
What You'll Learn:
- Complete inventory of integration capabilities in ECC & S/4HANA
- RFC/BAPI, IDoc, OData, SOAP, and file interface fundamentals
- Protocol comparison matrix with use case recommendations.
- System preparation checklists for production readiness
- Integration architecture patterns
- Decision framework for choosing the right protocol.
Who This Is For:
- Integration consultants working with SAP landscapes.
- Solution architects designing SAP integrations.
- Developers building connections to SAP systems.
- Functional consultants exploring integration possibilities.
- Anyone planning Integration Suite implementations.
Let's start with what SAP can actually give us.
2. SAP ECC INTEGRATION CAPABILITIES
SAP ECC has been the backbone of enterprise operations for decades., it provides robust, battle-tested integration interfaces that still power thousands of integrations today.
2.1 RFC (Remote Function Call) & BAPIs
RFC is SAP's proprietary protocol for synchronous communication between systems. BAPIs (Business Application Programming Interfaces) are standardized RFCs that provide access to SAP business objects and processes.
Key Characteristics:
- Synchronous: Call and wait for response
- Transactional: Can commit or rollback
- Type-safe: Strongly typed parameters.
- Widely available: Broad range of reusable standard BAPIs in ECC
Common BAPIs You'll Use:
BAPI Name | Purpose | Use Case |
BAPI_PO_CREATE1 | Create Purchase Order | External procurement systems posting POs |
BAPI_GOODSMVT_CREATE | Post Goods Movement | Warehouse systems updating inventory |
BAPI_MATERIAL_GETDETAIL | Get Material Master | E-commerce platforms fetching product data |
BAPI_ACC_DOCUMENT_POST | Post Financial Document | External systems creating FI documents |
BAPI_SALESORDER_CREATEFROMDAT2 | Create Sales Order | CRM systems posting orders to SAP |
BAPI_CUSTOMER_GETDETAIL | Get Customer Master | External apps accessing customer data |
NOTE:
BAPIs do NOT auto-commit. The calling program must explicitly control transaction boundaries:
To Save Changes: Call BAPI_TRANSACTION_COMMIT
To Discard Changes: Call BAPI_TRANSACTION_ROLLBACK
This allows multiple BAPIs to be grouped in a single Logical Unit of Work (LUW).
Reference: SAP Note 0131838
Technical Details:
- Access: Transaction SE37 (Function Builder)
- Discovery: Search pattern "BAPI_*"
- Testing: SE37 → Test/Execute
- Authentication: RFC destination in SM59
When to Use RFCs/BAPIs:
Use When:
- You need real-time, synchronous responses
- Transaction integrity is critical (commit/rollback)
- Complex business logic required
- Creating or updating SAP documents
- Reading data with complex selection criteria
Integration Pattern:
EXAMPLE SCENARIO:
Purchase Order Creation from Web Portal
Business Context:
Manufacturing company has external procurement portal where buyers create purchase requests. Once approved, these need to become POs in SAP ECC instantly.
Technical Setup:
- Source: Custom web portal (Node.js/React)
- Target: SAP ECC 6.0
- BAPI: BAPI_PO_CREATE1
- Frequency: Real-time (on PR approval)
- Volume: 50-100 POs per day
Process Flow:
2.2 IDoc (Intermediate Document)
IDoc (Intermediate Document) is SAP’s standard asynchronous integration mechanism.
It is designed for high-volume, reliable, loosely coupled data exchange between SAP and external systems.
An IDoc is:
- Self-contained
- Status-driven
- Processed independently of user interaction
This makes IDocs ideal for batch integrations, master data replication, and guaranteed delivery scenarios.
Key Characteristics:
- Asynchronous: Fire-and-forget or guaranteed delivery
- Bulk-friendly: Efficient for large volumes
- Loosely coupled: Systems don't need to be online simultaneously
- Status-tracked: Built-in monitoring (WE02, WE05)
IDoc Structure:
Common IDoc Types:
IDoc Type | Message Type | Purpose | Direction |
ORDERS05 | ORDERS | Purchase Orders | Outbound/Inbound |
INVOIC02 | INVOIC | Invoices | Outbound |
MATMAS05 | MATMAS | Material Master | Outbound |
DESADV01 | DESADV | Delivery Notes | Outbound |
WMMBXY03 | WMMBXY | Goods Movements | Outbound |
DEBMAS06 | DEBMAS | Customer Master | Outbound |
CREMAS03 | CREMAS | Vendor Master | Outbound |
Technical Details:
- Access: Transaction WE30 (IDoc Type Development)
- Partner Setup: WE20 (Partner Profiles)
- Port Config: WE21 (Port Definition)
- Testing: WE19 (Test Tool)
- Monitoring: WE02 (IDoc Display), WE05 (IDoc List)
- Triggering: Message Control, Change Pointers, IDOC_OUTPUT_* FMs
When to Use IDocs:
Use When:
- High-volume data transfer (thousands of records)
- Asynchronous processing acceptable
- Standard SAP business documents (PO, Invoice, etc.)
- Batch processing requirements.
- Need for guaranteed delivery with retry.
- Master data replication
Integration Patterns:
Outbound (ECC → External):
Inbound (External → ECC):
EXAMPLE SCENARIO:
Nightly Material Master Sync to Data Warehouse
Company needs to send all material master changes from ECC to external data warehouse every night for reporting and analytics.
Technical Setup:
- Source: SAP ECC 6.0
- Target: External Data Warehouse (Snowflake)
- IDoc Type: MATMAS05
- Frequency: Nightly batch (2 AM)
- Volume: 5,000-10,000 materials per night
End-to-End IDoc Asynchronous Integration Flow
- Material master records are created or updated in SAP ECC throughout the day (MM01/MM02).
- Change pointers capture only relevant delta changes for the MATMAS message type.
- At 2:00 AM, the BD21 batch job executes during off-peak hours.
- The system reads accumulated change pointers.
- A MATMAS05 IDoc is generated for each changed material.
- IDocs are sent via partner profile WAREHOUSE using an HTTP port.
- SAP CPI receives the IDoc XML through the IDoc adapter.
- CPI parses the hierarchical IDoc structure.
- Business data is transformed into a target JSON format.
- Records are grouped into batches of 1,000 for optimized processing.
- CPI posts each batch to the Snowflake bulk API.
- On success, IDocs are updated to status 53 (Posted).
- On failure, IDocs move to 51 (Error) and are retried in the next batch cycle.
- A consolidated processing report is emailed to the data team at 3:00 AM.
2.3 SOAP Web Services
SAP ECC exposes business functionality as SOAP-based web services.
These services are WSDL-driven, XML-based, and follow a strict request–response contract over HTTP/HTTPS.
SOAP services are widely used in legacy enterprise landscapes, especially where Java or .NET middleware already exists.
Key Characteristics:
- Standards-based: WSDL, SOAP 1.1/1.2, WS-* standards
- Synchronous: Request-response pattern
- Platform-agnostic: Any SOAP client can consume
- Structured: XSD-defined schemas
Technical Details:
- Access: Transaction SOAMANAGER (Service Administration)
- Development: SPROXY (Proxy Development)
- Types:
- Provider Services (ECC exposes to external)
- Consumer Services (ECC consumes from external)
When to Use SOAP:
Use When:
- External system requires SOAP/WSDL
- Enterprise service repository already defined.
- Need WS-Security features.
- Cross-platform integration with Java/.NET systems
Integration Pattern:
EXAMPLE SCENARIO:
Legacy Java Middleware Posting Financial Documents
Existing Java-based middleware system (10 years old) collects invoice data from multiple subsidiaries and needs to post consolidated financial documents to ECC.
Technical Setup:
- Source: Java middleware (Spring Boot)
- Target: SAP ECC 6.0
- Service: FinancialDocumentCreate (Enterprise Service)
- Frequency: Real-time as invoices arrive
- Volume: 200-300 documents per day
Process Flow:
- Java app collects invoice from subsidiaries.
- Validates and enriches data.
- Builds SOAP XML per WSDL specification.
- Sends SOAP request to CPI endpoint.
- CPI routes to ECC SOAMANAGER
- Enterprise service validates structure.
- Calls backend BAPI for FI posting.
- Document posted, accounting entries created.
- Returns FI document number in SOAP response.
- Java app stores document number for reference.
2.4 File Interfaces
File interfaces are one of the oldest and most reliable integration mechanisms in SAP ECC, designed for scheduled, high-volume, non-real-time data exchange.
Data is exchanged using physical files that are picked up, processed, and archived in batch cycles.
This pattern is still widely used for:
- Vendor uploads
- Price lists
- Mass master data changes
- One-time or recurring migrations
File Formats:
- Flat files (fixed width, delimited)
- CSV/Excel
- XML
- Custom formats
Technical Approaches:
- Output: Report programs, BDC, LSMW
- Input: Batch Input (BDC), Direct Input, BAPI calls
When to Use Files:
Use When:
- Batch processing windows.
- Large data migrations
- Legacy system integration
- Offline scenarios
Example Scenario: Nightly Vendor Price Upload (CSV)
The procurement team receives daily price updates from multiple vendors.
Each vendor uploads a CSV file containing updated material prices, which must be reflected in SAP ECC before business hours.
Technical Setup
- Source: Vendor SFTP servers
- Integration Layer: SAP CPI
- Target: SAP ECC 6.0
- File Type: CSV
- Schedule: Nightly (4:00 AM)
- Volume: ~50 files, 10,000–15,000 records
Process Flow (Clear & Sequential)
- Vendors upload CSV price files to the SFTP server between 1:00–3:00 AM
- At 4:00 AM, SAP CPI scheduler triggers the batch job
- CPI connects to SFTP and downloads all available files
- For each file, CPI:
- Identifies the vendor from the file name
- Parses the CSV line by line
- Validates mandatory fields and price values
- For each valid record:
- CPI calls BAPI_MATERIAL_SAVEDATA
- Updates the vendor price / info record
- Processing continues even if individual records fail
- CPI writes:
- Success entries to the success log
- Failed records to the error log with reason
- Processed files are archived to /archive
- A summary report is generated
- Email notification is sent to the procurement team
2.5 OData Services via SAP NetWeaver Gateway
SAP NetWeaver Gateway is a fully supported SAP component that enables ECC to expose RESTful OData services with JSON and XML support.
Key Characteristics
- Protocol: HTTP/HTTPS (RESTful)
- Data Format: JSON or XML (via $format=json or Accept header)
- Query Capabilities: $filter, $select, $expand, $orderby, $top, $skip
- CRUD Operations: GET, POST, PUT, PATCH, DELETE Self-Describing: $metadata endpoint
Technical Access
- Service Builder: Transaction SEGW (Service Artifact Generation Wizard)
- Service Registration: Transaction /IWFND/MAINT_SERVICE
- Service Testing: Transaction /IWFND/GW_CLIENT
- Error Monitoring: Transaction /IWFND/ERROR_LOG
- ICF Nodes: Transaction SICF (activate HTTP services)
OData Query Examples
Basic Read: GET /sap/opu/odata/sap/Z_PRODUCT_SRV/Products
Filtering: GET /sap/opu/odata/sap/Z_PRODUCT_SRV/Products?$filter=Price gt 100
JSON Format: GET /sap/opu/odata/sap/Z_PRODUCT_SRV/Products?$format=json
Metadata Discovery: GET /sap/opu/odata/sap/Z_PRODUCT_SRV/$metadata
When to Use Gateway OData
Use When:
- Building Fiori applications on ECC
- Modern web/mobile applications need REST APIs
- External developers need API access
- JSON format preferred over XML
2.6 Event Mechanisms in ECC
SAP ECC provides several mechanisms to trigger integrations based on business events. While not as standardized as S/4HANA's Event Enablement Framework, these are widely used in production environments.
Available Event Mechanisms:
Change Pointers
Track changes to master data and trigger IDoc generation.
Technical Details:
- Purpose: Master data change detection (Material, Customer, Vendor)
- Transaction BD50: Activate change pointers
- Transaction BD51: Activate for message types
- Transaction BD52: Assign fields to monitor
- Transaction BD21: Create IDocs from change pointers
- Processing: Batch-driven (scheduled job RBDMIDOC)
Workflow Events
Trigger when specific business transactions occur.
Technical Details:
- Purpose: React to business document lifecycle events
- Transaction SWE2: Event Type Linkages
- Transaction SWEL: Event Trace
- Event Pattern: BusinessObject.EventName Example: BUS2032.CREATED (Sales Order Created)
- Subscribers: Workflows, function modules
Output Determination (Message Control)
- Application-specific (MM, SD, FI)
- Condition-based triggering
- Can generate IDocs, emails, print outputs
- Transaction:
NACE(Output Control)
BAdIs (Business Add-Ins)
- Enhancement points in standard SAP code
- Can call external systems via RFC
- Transaction:
SE18(BAdI Definition),SE19(BAdI Implementation)
User Exits / Enhancement Points
- Custom code injection points
- Can trigger HTTP calls, RFCs to external systems
- Transaction:
CMOD(Enhancements)
3. SAP S/4HANA ON-PREMISE INTEGRATION CAPABILITIES
S/4HANA builds on everything ECC provides and adds modern integration capabilities that change the game.
3.1 EVERYTHING ECC HAS, ENHANCED
RFCs/BAPIs:
- All ECC BAPIs available
- New S/4HANA-specific BAPIs
- Better performance (HANA database)
- CDS view consumption via RFCs
IDocs:
- All ECC IDoc types
- Improved processing speed
- Better error handling
- Enhanced monitoring
SOAP Services:
- All enterprise services
- Service adaptation framework
- Better performance
3.2 ODATA SERVICES (Enhanced in S/4HANA)
OData is the REST-based protocol that makes SAP data accessible like modern APIs. OData introduces true RESTful APIs, designed for:
- Web applications
- Mobile apps
- External developer consumption
- Real-time queries
S/4HANA enhances OData capabilities with native support, pre-built APIs, and the RAP framework for OData V4.
What's Enhanced from ECC:
- OData V2 embedded by default
- OData V4 support via RAP framework (new capability)
- Pre-built released APIs in SAP Business Accelerator Hub
- HANA-optimized query performance
Why OData Matters
- REST over HTTP
- JSON-first
- Queryable data access
- Self-describing APIs
Key Characteristics:
- RESTful: Standard HTTP methods (GET, POST, PUT, DELETE)
- JSON/XML: Modern data formats
- Query-capable: $filter, $select, $expand, $orderby, $top, $skip
- Self-documenting: $metadata endpoint
- Stateless: No session management needed
SAP Gateway Architecture:
Standard S/4HANA APIs (Examples):
API Service | Business Purpose | Key Entity Sets |
API_PURCHASEORDER_PROCESS_SRV | Purchase Order lifecycle management | A_PurchaseOrder, A_PurchaseOrderItem |
API_PRODUCT_SRV | Material / Product master data | A_Product, A_ProductDescription |
API_SALES_ORDER_SRV | Sales order processing | A_SalesOrder, A_SalesOrderItem |
API_BUSINESS_PARTNER | Unified business partner model | A_BusinessPartner, A_BPContactAddress |
API_MATERIAL_STOCK_SRV | Inventory and stock levels | A_MaterialStock |
Technical Details:
- Service Registration: /IWFND/MAINT_SERVICE
- Testing: /IWFND/GW_CLIENT
- Development: SEGW (Gateway Service Builder)
- Monitoring: /IWFND/ERROR_LOG
OData Query Capabilities
Basic Read
GET /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/A_PurchaseOrder
Filtering
GET .../A_PurchaseOrder
?$filter=DocumentDate ge datetime'2025-01-01'
and PurchaseOrderType eq 'NB'
Selecting Specific Fields
GET .../A_PurchaseOrder
?$select=PurchaseOrder,Supplier,DocumentDate,TotalAmount
Expanding Navigation Properties
GET .../A_PurchaseOrder('4500000001')
?$expand=to_PurchaseOrderItem
Pagination
GET .../A_PurchaseOrder?$top=100&$skip=0
Response:
"__next": "...&$skiptoken=100"
Metadata Discovery
GET /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/$metadata
Returns:
- Entity sets
- Properties
- Associations
When to Use OData
Use When
- Modern web or mobile applications
- Real-time queries required
- REST/JSON integration
- Flexible query support needed
EXAMPLE SCENARIO: Mobile Sales App Querying Products
Business Context:
Sales representatives use mobile app to check product availability, pricing, and specifications while visiting customers. Need instant access to product catalog with real-time stock levels.
Technical Setup:
- Source: React Native mobile app
- Target: S/4HANA On-Premise
- API: API_PRODUCT_SRV, API_MATERIAL_STOCK_SRV
- Frequency: Real-time as sales rep searches
- Volume: 500-1,000 queries per day
Process Flow:
- Sales rep searches "Bearing" in mobile app
- App sends HTTP GET to CPI endpoint
- CPI forwards to S/4HANA Gateway
- Gateway routes to Data Provider Class
- DPC queries HANA database (ultra-fast)
- Returns matching products as JSON
- For each product, fetch stock level
- Combine product + stock data
- Response returns to mobile app
- Rep sees list: 15 products with prices and stock
3.3 CDS Views as Integration Endpoints
Core Data Services (CDS) views are HANA-optimized semantic data models defined in S/4HANA. They represent business entities and logic at the database level and can be exposed directly for integration.
CDS views can be:
- Exposed as OData services via SAP Gateway
- Consumed internally or externally via RFC-enabled function modules
Key Benefits
- High performance: Logic is pushed down to the HANA database
- Pre-aggregated data: Reduces processing in the application layer
- Embedded business logic: Calculations, annotations, and semantics included
- Rich relationships: Associations allow navigation across related entities
Process Flow
CDS View → Gateway Service → OData → Integration Suite
3.4 SAP Business Events & Real-Time Integration
S/4HANA introduces native event-driven integration capabilities, allowing systems to react immediately to business changes instead of relying on batch jobs or polling.
Key enhancements include:
- Standardized business event triggers
- Improved change detection
- Workflow-driven event publishing
- Native integration with SAP Event Mesh
Note: Event Mesh provides additional capabilities like publish/subscribe, guaranteed delivery queues, and multiple independent subscribers.
Event-Driven Integration Pattern
S/4HANA Business Event → Event Mesh Topic → Multiple Subscribers (CPI iFlows) → External Systems
Typical Use Cases
- Purchase order approved → Notify procurement portal
- Stock level falls below threshold → Trigger replenishment
- Sales order created → Update CRM system
- Invoice posted → Notify payment or reporting systems
EXAMPLE SCENARIO:
Real-Time Stock Alerts to E-Commerce
E-commerce website needs instant notifications when product stock falls below threshold to display "Low Stock" warnings and trigger replenishment.
Technical Setup:
- Source: S/4HANA On-Premises
- Targets: E-commerce website, Replenishment system, Analytics dashboard
- Event: Material.StockChanged
- Frequency: Real-time (as goods movements occur)
- Volume: 2,000-3,000 events per day
Step-by-Step Flow
- Goods Issue Posted
- A goods issue is posted in S/4HANA using transaction MIGO.
- Stock Update in HANA
- The stock quantity is immediately updated in the HANA database.
- Business Event Triggered
- The system triggers the business event Material.StockChanged.
- Event Published
- The event is published to SAP Event Mesh.
- Topic: inventory/changes
- Parallel Event Consumption
- Multiple systems subscribe to the same event and process it independently.
Subscriber A – E-Commerce System
- Receives the event through a CPI iFlow
- Updates the product page inventory
- Displays a “Low Stock” indicator (e.g., “Only 75 left”)
Subscriber B – Replenishment System
- Evaluates stock against reorder threshold (100 units)
- If below threshold:
- Creates a Purchase Requisition
- Notifies the purchasing team
Subscriber C – Analytics Dashboard
- Updates real-time inventory charts
- Stores event data in the data warehouse for reporting
- Independent Processing
- Each subscriber processes the event independently and in parallel.
- Acknowledgement
- Each system sends an acknowledgement back to Event Mesh.
Events are published once and delivered to multiple consumers in parallel, without tight coupling.
4. INTEGRATION SCENARIOS & COMPARISON
Now that we understand what each system offers, let's look at how to choose the right protocol and see complete integration scenarios.
4.2 Decision Tree
4.3 Cross-Protocol Integration Scenarios
Scenario 1: Manufacturing Company - Complete Landscape
Integration Breakdown
- Web Portal → SAP ECC (Purchase Orders)
- Protocol: REST → RFC/BAPI
- Purpose: Real-time purchase order creation
- Volume: ~100 purchase orders per day
- SAP ECC → Data Warehouse (Material Master)
- Protocol: IDoc → JSON
- Purpose: Nightly master data synchronization
- Volume: ~10,000 materials per night
- Mobile App → SAP S/4HANA (Product Catalog)
- Protocol: REST → OData
- Purpose: Real-time product search and availability
- Volume: ~1,000 queries per day
- SAP S/4HANA → E-Commerce Platform (Stock Alerts)
- Protocol: Business Events via Event Mesh
- Purpose: Real-time inventory notifications
- Volume: ~3,000 events per day
5. System Preparation Checklists
Before starting integration development, systems must be technically and operationally ready. The following checklists reflect production-grade prerequisites.
5.1 SAP ECC Preparation
Technical Configuration
RFC Destinations (SM59)
☐ HTTP/RFC destination created for Integration Suite
☐ Connection test successful
☐ Timeout parameters adjusted
☐ Trusted RFC configured (if applicable)
IDoc Configuration (If IDocs Are Used)
☐ Partner profiles maintained (WE20)
☐ Inbound parameters
☐ Outbound parameters
☐ Message types assigned
☐ Ports configured (WE21)
☐ HTTP port to Integration Suite
☐ Port connectivity tested
☐ Message control configured (for outbound IDocs)
☐ Application (ME, VL, VF, etc.)
☐ Output type
☐ Medium = 6 (IDoc)
☐ Test IDocs generated successfully (WE19)
Web Services (SOAMANAGER)
☐ Service definitions created
☐ Endpoints configured and reachable
☐ WSDL accessible externally
☐ Authentication configured
User & Authorization
☐ Technical user created (SU01)
☐ Required authorizations assigned:
☐ S_RFC
☐ S_IDOCDEFT
☐ Relevant business authorizations
☐ Password policy compliant
☐ Dialog access restricted for security
Network & Security
Firewall Rules
☐ Outbound: ECC → Integration Suite (HTTPS 443)
☐ Inbound: Integration Suite → ECC (HTTP/HTTPS)
☐ IP whitelisting completed
SSL / TLS Configuration
☐ Certificates imported (STRUST)
☐ Certificate chain verified
☐ Expiry monitoring in place
Cloud Connector (If On-Premise Connectivity Is Required)
☐ Installed and connected to BTP subaccount
☐ Access control rules defined
☐ Resource mapping configured
☐ Audit logging enabled
5.2 SAP S/4HANA Preparation
All ECC prerequisites apply, plus the following.
OData / Gateway Configuration
☐ Services activated (/IWFND/MAINT_SERVICE)
☐ System alias assigned
☐ Service registration complete
☐ ICF nodes active (SICF)
☐ Service testing completed (/IWFND/GW_CLIENT)
☐ $metadata accessible
☐ Entity sets queryable
☐ CRUD operations verified
☐ Authorization configured (S_SERVICE, PFCG roles)
Custom OData Services (If Applicable)
☐ Data model designed (SEGW)
☐ DPC_EXT implemented
☐ Runtime objects generated
☐ Service registered and tested
Event Configuration (If Event-Driven Integration Is Used)
☐ Business events identified
☐ Event Mesh connectivity established
☐ Topic and queue structure defined
☐ Payload format designed
☐ End-to-end testing completed.
CDS View Exposure
☐ CDS views created and optimized
☐ Exposed via OData
☐ Authorization validated
☐ Performance tested.
5.3 SAP BTP Integration Suite Preparation
Platform Enablement
☐ Integration Suite provisioned
☐ Cloud Integration enabled
☐ API Management enabled (if required)
☐ Event Mesh enabled (if required)
☐ Integration Advisor enabled (if B2B scenarios)
Connectivity
☐ Destinations configured
☐ HTTP destinations to ECC/S/4HANA
☐ Authentication defined
☐ Proxy type set (Internet / On-Premise)
☐ Cloud Connector configured
☐ Location ID assigned
☐ Virtual host mapping
☐ Access control lists maintained
Security
☐ Credentials stored securely
☐ OAuth tokens configured (if applicable)
☐ Certificates uploaded and validated
☐ Secure parameters used for sensitive values
☐ Known hosts configured for SFTP
Design & Operations
☐ Integration packages created
☐ Naming conventions defined
☐ Versioning and transport strategy agreed
☐ Message monitoring enabled
☐ Alerts configured
☐ Log retention policy set
☐ Operational dashboards created
6. INTEGRATION ARCHITECTURE OVERVIEW
Understanding how all pieces fit together:
Component Explanations
Cloud Connector
- Provides a secure tunnel between SAP BTP and on-premise SAP systems
- Eliminates the need for VPN connectivity
- Enables resource-level access control
- Supports audit logging for compliance and security monitoring
CPI Adapters
- Enable protocol translation (RFC ↔ REST, IDoc ↔ JSON, SOAP ↔ HTTP)
- Handle authentication and credential management
- Support connection pooling for performance optimization
- Provide built-in retry mechanisms for transient failures
API Management
- Enforces rate limiting and quotas
- Supports API key and OAuth-based validation
- Offers analytics and usage monitoring
- Includes a developer portal for API discovery and onboarding
Event Mesh
- Supports publish / subscribe messaging
- Provides queue-based guaranteed delivery
- Enables topic-based routing
- Allows multiple subscribers to process events independently
7. Key Takeaways
Understanding System Capabilities
SAP ECC Strengths
- Mature and stable RFC/BAPI framework
- Robust IDoc infrastructure for asynchronous processing
- Battle-tested reliability in enterprise landscapes
- Rich Enterprise Services Repository
SAP S/4HANA Advantages
- Native OData / REST APIs
- Built-in event-driven integration
- High performance powered by SAP HANA
- CDS views for optimized data access
- Includes everything ECC offers — enhanced and modernized
SAP BTP Integration Suite as the Bridge
- Centralized protocol translation
- Secure cloud connectivity
- End-to-end orchestration layer
- Enterprise-grade monitoring and governance
Protocol Selection Guidance
- RFC / BAPI: Synchronous transactions with immediate validation
- IDoc: Bulk data processing with guaranteed delivery
- OData: REST APIs for modern applications
- SOAP: Legacy enterprise web services
- File Interfaces: Batch processing and data migrations
- Events: Real-time, decoupled integration (S/4HANA)
Preparation Is Critical
- System configuration must be completed before development
- Security and authorizations must be production-ready
- Network connectivity should be fully tested
- Monitoring and alerting should be established early
8. What’s Next
This blog explained what is possible.
The next blogs series will be focused on how to implement.
Acknowledgments & Corrections
This document was refined based on valuable feedback from the SAP Community, particularly regarding:
- NetWeaver Gateway as a standard, supported component in ECC
- JSON support in OData V2 for both ECC and S/4HANA
- BAPI transaction control requirements
- Event architecture distinctions
I welcome continued feedback to ensure this remains an accurate, community-validated resource.
Bluesky
