sap-integration-cloud

# sap-integration-cloud — Integration Suite + Datasphere ## 1. Environment Intake Checklist 1. **Integration scope** — CPI (Cloud Platform Integration) / Datasphere / API Mgmt / Event Mesh? 2. **Source/Target** — S/4 (Cloud/OnPrem) / SuccessFactors / Ariba / 3rd party? 3. **Protocol** — REST / SOAP / OData / IDoc / SFTP / JDBC? 4. **Authentication** — OAuth / Basic / Certificate / SAML? 5. **Specific issue** — iFlow design, error handling, perf, certificate, monitoring? Also collect these before proposing a fix: - **SAP source release** — ECC 6.0 EhP or S/4HANA release year. - **Deployment** — On-Premise, RISE/Private Cloud, or S/4HANA Cloud Public Edition. - **Industry and data class** — finance, HR, health, trade, or other regulated data. - **BTP landscape** — region, subaccount, Cloud Foundry environment, dev/test/prod tenant. - **Artifact identity** — package, iFlow name, deployed version, last transport/change time. - **Failure window** — first failure time with timezone, frequency, last successful message. - **Correlation evidence** — sanitized MPL Message ID and business correlation key. - **Contract** — sender/receiver schema version, Content-Type, encoding, cardinality rules. - **Endpoint** — destination alias, Cloud Connector location ID, receiver service and timeout. - **Security** — authentication type and certificate/secret expiry date, never the secret itself. - **Business impact** — delayed, missing, duplicated, or incorrectly transformed documents. - **Replay risk** — whether the receiver is idempotent and who approves business reprocessing. Do not wait for perfect intake before helping. If context is missing, label the diagnosis provisional and provide only read-only evidence checks. ### 1.1 Evidence privacy contract - Never request or reproduce a production payload containing 주민등록번호, 계좌, 급여, 건강정보, 이메일, 전화번호, access token, client secret, or private key. - Request only field names, schema fragments without values, redacted error text, counts, timestamps, hashes, message status, and correlation IDs. - Replace business identifiers consistently so one sanitized message can still be correlated across CPI, PI/PO, and ECC/S/4. - Treat CPI Trace and attachment logging as temporary data collection. Use a bounded window, minimum users, and the approved retention/deletion process. - If a payload sample is essential, reproduce the structure with synthetic data in a lower tenant. ## 2. Module Coverage ### 2.1 Integration Suite Components | Component | Purpose | |---|---| | **CPI (Cloud Platform Integration)** | iFlow-based message routing/transformation | | **API Management** | API design, gateway, throttling, security | | **Event Mesh** | Event-driven messaging (pub/sub) | | **Open Connectors** | Pre-built non-SAP connectors | | **Integration Advisor** | Schema design assistance | ### 2.2 Datasphere - Successor to SAP DWC (Data Warehouse Cloud) - Spaces (data isolation) + Local Tables + Views + Federation - Connect S/4HANA Cloud / on-prem / BW / non-SAP via Data Provisioning Agent ## 3. CPI / iFlow Patterns ### 3.1 Common iFlow Shapes - **Request-Reply** — sync API call - **Splitter** — message → multiple - **Aggregator** — multiple messages → 1 - **Content Filter** — header/payload filtering - **Mapping** — Message Mapping (graphical) or Script (Groovy) ### 3.2 Typical Flows - **S/4 to SuccessFactors** — employee replication - **SuccessFactors to S/4 HCM** — org data sync - **S/4 to Ariba** — material/vendor master via CIG - **Bank file (MT940)** — FTP → CPI → S/4 FF.5 ### 3.3 Canonical iFlow failure sequence Use this order for every active CPI incident. Do not jump from a generic error headline straight to certificate rotation or mapping changes. #### Step 1 — Message Processing Log (MPL) **T-code**: not applicable (BTP SaaS) **Menu path**: `Integration Suite > Monitor > Integrations and APIs > Monitor Message Processing` Collect read-only metadata: 1. iFlow and deployed artifact version. 2. MPL Message ID, start/end time, status, and processing duration. 3. Sender, receiver, adapter type, and failed branch. 4. Exception class/category and the first error in the causal chain. 5. Retry count and whether the same business key previously completed. 6. A nearby successful message with the same interface and version. The last exception line is not always the first failure. Build a timeline and identify the earliest failed boundary. #### Step 2 — Failed step or mapping **T-code**: not applicable **Menu path**: `Integration Suite > Monitor > Message Processing > <Message> > Log/Trace` - If the first failing node is Message Mapping, compare the deployed source and target schemas. - Check XML namespace URI and QName, not only the visible element name. - Check required/optional occurrence, repeating node context, default value, and empty-string rules. - For JSON, compare property type, array/object shape, null handling, and numeric/date format. - For Groovy or script steps, identify the exact step and sanitized exception line; do not ask for credentials or full payload dumps. - Enable Trace only for an approved, short, lower-environment reproduction whenever possible. **Falsification**: if the same deployed version and sanitized contract-test message pass the mapping, or if the first error occurs before the mapping step, reject the mapping hypothesis. #### Step 3 — Payload schema and contract **T-code**: not applicable **Menu path**: `Integration Suite > Design > Integrations > <iFlow> > Resources/Mapping` - Verify sender schema version against the version packaged with the deployed iFlow. - Validate Content-Type, character encoding, namespace, mandatory nodes, and allowed values. - Compare one failed and one successful message by structure and hashes, not raw PII values. - Check whether an upstream optional field became mandatory downstream. - Confirm value mapping has the expected source agency, source identifier, target agency, target identifier, and effective lifecycle. - Treat a schema drift as a producer/consumer contract issue, not automatically as CPI defect. **Falsification**: if schema validation succeeds with the exact failed structure and the mapping output matches the receiver contract, move the primary hypothesis to the endpoint boundary. #### Step 4 — Endpoint, network, and receiver **T-code**: not applicable for BTP checks **Menu path**: `BTP cockpit > Connectivity > Destinations` and `Cloud Connector Admin UI > Cloud To On-Premise` - Classify receiver response: authentication, authorization, route, media type, throttling, timeout, or application failure. - Check destination URL/alias, proxy type, location ID, and connection test without exposing secrets. - Check Cloud Connector subaccount state and the exact allowlisted virtual host/path. - Compare receiver availability from its own monitor; a CPI timeout does not prove receiver outage. - For TLS, compare certificate chain, hostname, validity window, trust store, and client certificate. - For rate limits, compare failure timestamps and response headers with the agreed quota. **Falsification**: if the receiver accepts an equivalent sanitized request through the same destination and the MPL shows no network/auth error, reject the endpoint hypothesis. ### 3.4 Multi-hop correlation rule For `source → PI/PO → CPI → target`, create one timeline: | Boundary | Evidence | Primary monitor | |---|---|---| | Source application | document key hash, send time, application log | `SLG1` | | PI/PO Integration Engine | PI message ID, pipeline status, error category | `SXMB_MONI` | | CPI | MPL Message ID, failed step, deployed version | Integration Suite Monitor | | ABAP SOAP runtime | Web Service message ID and provider/consumer error | `SRT_MONI` | | Receiver | response status, application correlation ID | Receiver-native monitor | Never compare payload values across systems in an external chat. Use sanitized correlation IDs, timestamps, structural hashes, and record counts. ## 4. Datasphere Patterns ### 4.1 Architecture - **Space** — isolation (sandbox / production / per-business unit) - **Local Table** — physically stored - **Remote Table** — federated (live query) - **View** — virtual model - **Analytic Model** — for SAC consumption ### 4.2 Data Provisioning - **DP Agent** — on-prem to cloud bridge - **Replication Flow** — real-time data sync - **Data Flow** — ETL-like batch ## 5. Critical Issues ### CPI / iFlow - **iFlow not triggering** — sender adapter config, polling schedule, certificate expired - **Mapping error** — schema mismatch, missing required fields, type conversion - **Memory exceeded** — large payload, split before processing - **Certificate expired** — STRUST equivalent in BTP Keystore, alert before expiry - **Reprocessing failed message** — Monitor → Messages → Retry ### Datasphere - **Federation slow** — push-down vs materialize trade-off - **Replication lag** — Replication Flow monitoring - **Space sharing fail** — Privilege Sharing config ### Cloud Connector - **Tunnel not connecting** — outbound 443 firewall, regional endpoint - **System mapping fail** — virtual host vs internal host ## 6. Protocol-specific diagnostic playbooks ### 6.1 SOAP from CPI to ECC/S/4 1. Start with CPI MPL and locate the receiver SOAP step. 2. `SRT_MONI` — menu: `SAP Easy Access > Tools > Administration > Monitor > Web Services > Message Monitor`; match sanitized timestamp/message ID and inspect provider/consumer error. 3. `SOAMANAGER` — menu: `SAP Easy Access > Tools > Administration > SOA Management`; display binding, logical port, endpoint, authentication, and service state. 4. `STRUST` — menu: `SAP Easy Access > Tools > Administration > Trust Manager`; display the relevant trust/client PSE chain and validity. Never export a private key. 5. `SMICM` — menu: `SAP Easy Access > Tools > Administration > Monitor > ICM Monitor`; check recent HTTP/ICM errors only when the failure reaches the ABAP HTTP layer. **Primary hypotheses**: - Binding/endpoint mismatch: supported when `SRT_MONI` cannot route to the configured service; falsified when the same binding handles a comparable request successfully. - Trust failure: supported by handshake/certificate-chain evidence; falsified when the same PSE and hostname complete a TLS handshake during the incident window. - Application fault: supported when transport succeeds and the provider returns a business fault; falsified when no request reached the provider runtime. **Fix and rollback**: change a binding, certificate alias, or iFlow only in dev/test first. Use a backend TR where customizing requires it and approved content transport for CPI. Preserve the prior binding/exported configuration and prior iFlow version for rollback. ### 6.2 PI/PO coexistence or migration 1. `SXMB_MONI` — menu: `SAP Easy Access > Process Integration > Monitoring > Integration Engine`; display the PI/XI message status, pipeline step, interface, and timestamp. 2. Match it to the CPI MPL using a sanitized correlation key and time window. 3. Determine which runtime owns routing. Do not assume that a CPI deployment removed the old PI route. 4. Compare counts at source, PI/PO, CPI, and receiver to detect loss or dual delivery. 5. Run a one-message canary with a non-posting or idempotent receiver before cutover. **Falsification**: if only one runtime receives the canary and end-to-end counts reconcile, reject the dual-route hypothesis. If the PI message never left the source-facing channel, investigate PI before CPI. **Rollback**: retain the last approved PI/PO routing/configuration until CPI canary, reconciliation, and business sign-off pass. Revert the traffic switch, not business data, when the cutover fails. ### 6.3 IDoc adapter 1. `WE02` — menu: `SAP Easy Access > Tools > ALE > Administration > Services > IDoc Display`; display control record, status history, partner/message type, and timestamps. 2. `WE20` — menu: `SAP Easy Access > Tools > ALE > ALE Administration > Runtime Settings > Partner Profiles`; display sender/receiver partner profile and message type. 3. `WE21` — menu: `SAP Easy Access > Tools > ALE > ALE Administration > Runtime Settings > Ports`; display the assigned port and destination relationship. 4. `IDX1` — menu: `SAP Easy Access > Process Integration > Configuration > IDoc Adapter > Ports`; display IDoc adapter port assignment where PI/PO is in scope. 5. `IDX2` — menu: `SAP Easy Access > Process Integration > Configuration > IDoc Adapter > Metadata`; compare metadata release/schema only where PI/PO IDoc adapter metadata is used. 6. Use `BD87` only after the cause is fixed, a lower-environment test passes, duplicate impact is assessed, and the operator approves a bounded reprocessing set. **Relevant records** (technical table names, not T-codes): ```text EDIDC — IDoc control record and technical routing metadata. EDIDS — chronological status records; use it to find the first failing status. IDoc data-record table — data segments; treat as sensitive and do not request raw segment values externally. ``` **Falsification**: if the IDoc has a successful outbound status and CPI never receives it, test the adapter/network boundary. If CPI received and parsed it, reject partner-profile absence as primary. **Rollback**: restore the prior partner-profile/port configuration through the approved backend TR. For replay, stop at the pre-approved message set and reconcile document keys after each batch. #### 6.3.1 Define what "stuck" means Do not use “IDoc adapter stuck” as a root cause. Classify the observed boundary first: | Observed state | Meaning to test | Next read-only boundary | |---|---|---| | No IDoc in backend | Application/output never created it, or selection window is wrong | Application log and source document/output status | | Outbound status `30` persists | Ready for dispatch; output mode/job scheduling may be involved | `WE20`, then scheduled dispatch job in `SM37` | | Outbound status `02` | Error passing data to port | Status long text, `WE20`, `WE21`, destination/endpoint evidence | | Outbound status `03` | Passed to port; not proof of target business posting | CPI MPL at matching time/correlation | | CPI MPL exists but starts/fails at adapter | Endpoint, identity, envelope, or adapter parsing boundary | MPL causal error and deployed adapter configuration | | CPI MPL passes adapter and fails later | Not an IDoc transport stuck; diagnose failed iFlow step | Mapping/schema/receiver playbook | | Inbound status `64` persists | Ready for application processing in ABAP | Partner/process-code/application scheduling boundary | | Inbound status `51` | Application document not posted | Status long text and application log; not primarily CPI transport | | Inbound status `53` | Application document posted | Reconcile the business object, not the adapter | Status interpretation is direction-specific. Always ask whether the operator is looking at an outbound IDoc in the source or an inbound IDoc in the target. #### 6.3.2 IDoc-specific environment intake Collect without requesting segment values: - ECC EhP or S/4HANA release year and deployment model. - Direct ABAP-to-CPI route or PI/PO coexistence hop. - Direction relative to ABAP and CPI. - Message type, basic type, extension name, sender/receiver partner type, logical partner hash. - Port type/name hash, output mode, immediate versus collected dispatch behavior. - One affected IDoc number hash and one recent successful IDoc number hash. - Full status sequence with timestamp/timezone and sanitized status long text. - CPI package, iFlow, deployed version, adapter role, MPL Message ID if one exists. - Change timeline for `WE20`, `WE21`, certificate/security material, endpoint, and iFlow transport. - Whether the receiver posts business data and how duplicate documents are prevented. #### 6.3.3 Read-only evidence ladder 1. `WE05` — menu `SAP Easy Access > Tools > ALE > Administration > Services > IDoc Lists`; establish affected count, direction, message/basic type, status distribution, and time window. 2. `WE02` — menu `SAP Easy Access > Tools > ALE > Administration > Services > IDoc Display`; inspect one affected and one successful control/status history. Do not copy segment values. 3. `WE20` — display partner/message-type parameters, process code or outbound parameters, receiver port, output mode, and change alignment. 4. `WE21` — display the referenced port and destination/endpoint relationship. 5. `SM37` — menu `SAP Easy Access > Tools > Administration > Monitor > Job Selection`; display the relevant scheduled dispatch/application job and job log only when status indicates a scheduling boundary. A green job alone does not prove it selected the affected IDoc. 6. CPI MPL — menu `Integration Suite > Monitor > Integrations and APIs > Monitor Message Processing`; match timestamp/correlation and decide whether the adapter received the message. 7. If PI/PO is a real hop, use `SXMB_MONI`; do not add PI/PO merely because it existed historically. For technical field-level evidence, describe names and sanitized values only: ```text EDIDC.STATUS — current IDoc status EDIDC.MESTYP — message type EDIDC.IDOCTP — basic type EDIDC.CIMTYP — extension EDIDC.RCVPRT / RCVPRN — receiver partner type / redacted partner EDIDS.STATUS with log date/time — chronological status history IDoc data-record table — segment structure is sensitive; do not export raw values ``` #### 6.3.4 General cause taxonomy with two or more falsifiers **H1 — The source application did not create the IDoc** Supporting evidence: no matching IDoc in `WE05`, while the business/output trigger was expected. Falsify H1 when both applicable checks show otherwise: - A matching IDoc exists with the expected message type and creation time. - The same source document produced an outbound status sequence. - CPI MPL already contains the same sanitized business correlation. **H2 — Collected dispatch or background scheduling is holding ready IDocs** Supporting evidence: status `30` grows, output mode is collected, and the selecting job did not process the affected time/partner/message range. Falsify H2 when: - The affected IDoc already moved past the ready-for-dispatch boundary. - The dispatch job selected the exact affected range and status still changed to a port error. - A direct/immediate test IDoc is equally stuck before scheduling becomes relevant. **H3 — Partner profile or port routing is inconsistent** Supporting evidence: `WE20` references an unintended/missing port or the message-type parameters do not match the intended route, especially after an aligned change. Falsify H3 when: - The same partner, message type, and port successfully dispatch messages after the incident began. - The affected IDoc is already present in CPI MPL, proving that route reached the tenant. - Displayed partner/port configuration and the approved baseline are identical. **H4 — Endpoint, trust, or communication identity prevents delivery** Supporting evidence: status long text and CPI/connector evidence agree on connection, handshake, authentication, or authorization failure at the same timestamp. Falsify H4 when: - CPI MPL receives and parses the affected IDoc envelope. - A synthetic canary through the same endpoint, identity alias, and route succeeds in the incident window. - The first failure occurs in a downstream mapping or receiver step after adapter acceptance. **H5 — Basic type, extension, or envelope metadata is incompatible** Supporting evidence: the adapter rejects parsing/metadata and the affected basic type/extension differs from the deployed contract. Falsify H5 when: - A recent message with the same message/basic/extension combination passes the same deployed adapter. - MPL proves parsing completed and the first failure is a downstream step. - The deployed schema/metadata version matches the source and a structural contract test succeeds. **H6 — CPI runtime backlog, retry, or resource pressure delays accepted messages** Supporting evidence: MPL exists, many messages remain processing/retrying, and queue/duration growth began at the same time without a source dispatch gap. Falsify H6 when: - No MPL exists because the message never reached CPI. - Comparable messages have normal wait/duration and there is no growing processing/retry set. - A single canary fails deterministically at the same mapping/endpoint step rather than waiting. **H7 — The target ABAP application rejected an inbound IDoc** Supporting evidence: CPI completed delivery but the target inbound IDoc has status `51` and an application-specific status message/log. Falsify H7 when: - No inbound IDoc exists in the target and CPI did not complete the receiver step. - The inbound IDoc has status `53` and the expected business key is present. - The first error occurs in source dispatch or CPI before target delivery. #### 6.3.5 Safe fix and rollback pairs | Confirmed cause | Safe fix after lower-environment test | Rollback | |---|---|---| | Dispatch schedule/output mode | Correct selection/schedule through change control; verify one synthetic IDoc | Restore previous output mode/job schedule and stop new dispatch | | Partner/port mismatch | Correct `WE20`/`WE21` through an approved backend TR | Import/restore prior partner and port configuration | | Certificate/identity | Add and canary-test a new alias before switching | Repoint to preserved previous alias; revoke new credential later | | Metadata incompatibility | Version the adapter schema/mapping and test same basic type/extension | Redeploy previous iFlow version and restore prior metadata artifact | | CPI backlog/resource pattern | Remove confirmed bottleneck and release a bounded canary | Restore prior concurrency/flow version and pause replay |