SAP Library / BTP Integration / Cheat sheet
SAP BTP Integration cheat sheet
34 objects in 4 groups. Each links to its full reviewed page.
T-Codes18
- WE02WE02 is used to display IDocs with control record, data segments and complete status history for interface troubleshooting. It is most useful when an inbound or outbound IDoc is missing, failed, stuck, duplicated or posted with unexpected application data. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- WE05WE05 is the IDoc list transaction used to search, filter and mass-monitor IDocs by status, message type, partner, date range or direction. It runs the same underlying selection logic as WE02 but presents results as a flat monitoring list rather than a single-IDoc tree, making it the transaction of choice when triaging a queue of failed IDocs rather than inspecting one document in detail.
- WE19WE19 is used to create controlled test IDocs from existing records, files or templates and execute inbound/outbound processing for analysis. It is most useful when reproducing an IDoc mapping or application-processing issue safely in development or quality systems. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- WE20WE20 maintains the ALE/IDoc partner profile: the record that tells the system, for a given partner and message type, which port to use outbound and which process code or function module to call inbound. A missing or wrong entry here is the single most common reason an IDoc fails to generate or fails to post on receipt.
- WE21WE21 maintains ports, the technical channel an IDoc travels through: transactional RFC, file, ABAP-PI, or XML/HTTP. The port itself carries no business meaning; it only becomes active once a partner profile in WE20 references it. Most 'port' problems are really partner profile or RFC destination problems being surfaced through the port screen.
- WE30WE30 is the transaction for creating and maintaining IDoc types: the segment hierarchy that defines the structure of an IDoc. It builds and releases the tree of segments (mandatory, optional, min/max occurrence) but does not define the segment fields themselves; field-level definition happens in WE31. Confusing the two is the most common source of wasted time.
- WE31WE31 is the transaction for creating, changing, displaying and releasing IDoc segment definitions, the field-level building blocks that get assembled into a basic IDoc type in WE30. The structural fact that causes most confusion: a segment has a draft definition and a separately released version, and changes to an already-released segment create a new version rather than overwriting the old one.
- WE41WE41 maintains the customizing table of outbound process codes used in ALE and EDI configuration. Each process code is a reusable label pointing to a processing type, typically the standard ALE layer or a specific function module, that governs how an outbound IDoc is technically handed off for dispatch. It is customizing, not a monitoring or execution transaction.
- WE42WE42 maintains the customizing table that links an inbound process code to the function module (or workflow) that actually processes an incoming IDoc's application data. Partner profiles in WE20 reference a process code, not a function module directly, so a missing or mistyped entry here breaks inbound processing even when the partner profile and the IDoc itself look correct.
- WE57WE57 maintains the assignment between a message type, an IDoc type or extension, and a business object type, stored in the EDIMSG table. SAP checks this entry during inbound IDoc processing before invoking the posting function module. Missing entries here are a frequent cause of inbound IDocs failing with a status 56 error even though the partner profile and process code look correct.
- BD64BD64 maintains the ALE distribution model, the definition of which logical system sends which IDoc message type to which logical system, with optional filters. It does not itself move data or configure the runtime path. The model must be generated into partner profiles (WE20) before any IDoc actually flows; a correct BD64 entry with no generated partner profile produces no traffic at all.
- BD87BD87 reprocesses failed or waiting IDocs after the underlying application, master-data, configuration, or communication cause has been corrected. Use it for recoverable IDoc statuses, review a small sample first, and confirm that reprocessing is safe and will not create duplicate business documents before running a larger population.
- SM58SM58 is used to monitor failed or pending transactional RFC LUWs and retry them after communication or application issues are resolved. It is most useful when asynchronous RFC calls remain in error after a target outage, logon problem or application failure. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- SRT_MONISRT_MONI is used to monitor asynchronous and synchronous ABAP web-service messages and inspect SOAP processing errors. It is most useful when a SOAP message fails, remains in error, or must be traced between application and web-service runtime. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- SOAMANAGERSOAMANAGER is used to configure and administer ABAP SOAP service providers and consumer proxies, logical ports and bindings. It is most useful when a SOAP web service must be activated, endpoint/security settings maintained, or a consumer proxy fails to connect. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- SM59SM59 maintains RFC destinations, the stored connection parameters (target host, system, client, logon data) that let one SAP system call another system, an external program, or an HTTP service. A green connection test proves the network path and stored credentials work; it does not prove the actual interface call, which may use a different destination, user, or timeout, will succeed.
- SMQ1SMQ1 displays the outbound queued RFC (qRFC) queues on the system where data originates, showing every LUW waiting to be transferred to a receiving destination in strict FIFO order per queue name. It is the first place to check when BW delta extraction, LO cockpit postings, or any qRFC-based transfer appears stuck before it even leaves the source system.
- SMQ2SMQ2 displays inbound qRFC queues on the receiving system - the entries (LUWs) waiting to be processed there. It is the mirror image of SMQ1, which shows the same transport from the sending side. Used when delta loads, IDoc transfers, or extraction feeds into BW appear stuck despite the source system reporting the data as sent.
IDoc Statuses5
- 03IDoc status 03 means the outbound IDoc was handed from the SAP application layer to the communication port (file, RFC, or similar) without error. It does not confirm the receiving system got it, converted it, or posted anything. For file ports with no acknowledgment loop this is often the correct final status, not a stuck interface.
- 51Status 51 means an inbound IDoc passed technical processing - syntax check, partner profile, port - but the application function module that should create the business document rejected it. The IDoc itself is intact; no sales order, material, vendor, or accounting document was created. The actual reason is attached as an application error message on the status record.
- 53Status 53 is an inbound success status meaning the application document (sales order, delivery, material document, financial posting, etc.) was created without error by the inbound function module. It is a terminal green status, not an error. Problems that surface after 53 usually sit in the posted document itself, or in a mismatch between what the IDoc carried and what the business expected, not in the IDoc processing chain.
- 64Status 64 is an inbound-only status meaning the IDoc has completed ALE inbound processing (syntax check, partner profile lookup, filtering, version conversion) and is queued to be handed to the application posting function module. It has not been posted yet. If it stays at 64 instead of moving to 53 or 51, the queue or background dispatch mechanism that should pick it up is stalled.
- 68Status 68 marks an inbound IDoc whose processing stopped with an error that the application or interface logic explicitly decided not to retry automatically. It differs from status 51 in that it is deliberately terminal - standard mass reprocessing usually skips it, so fixing it requires reading the attached status text, resolving the underlying data or duplicate issue, and manually re-triggering processing rather than relying on the normal worklist.
Message Types6
- ORDERSORDERS is the IDoc message type that carries a purchase order between two SAP systems or between SAP and a vendor/customer EDI subsystem. Outbound, it transmits a PO created in MM to a vendor. Inbound, it receives a customer's PO and triggers automatic creation of a sales order via a configured process code.
- INVOICINVOIC is the IDoc message type that carries an invoice or credit memo document between SAP and a trading partner or middleware layer. Outbound, it represents a billing document leaving SD for an EDI subsystem or integration platform. Inbound, it represents a vendor invoice arriving for posting into Logistics Invoice Verification or directly into FI.
- DELVRYDELVRY carries an outbound or inbound delivery document between two SAP systems, most commonly between an ERP/S4 core and a decentralized warehouse management system such as SAP EWM decentralized. It replicates delivery creation, change and confirmation so the receiving system can pick, pack and post goods movements against the same delivery number. It is not the customer-facing despatch advice, which is DESADV.
- MATMASMATMAS is the IDoc message type used to distribute material master records between SAP systems, or between an SAP system and a non-SAP system through middleware such as SAP Integration Suite. It carries basic data, descriptions, units of measure, valuation, plant, storage and sales view fields for a single material, moving outbound from the system that owns the master data.
- CREMASCREMAS is the IDoc message type that carries vendor master data (general data, company code data, bank details, purchasing organization data) between SAP systems, typically from a system of record such as an ECC or S/4HANA client, or an MDG hub, to receiving clients, procurement systems, or non-SAP downstream applications, keeping vendor records synchronized without manual re-entry.
- DEBMASDEBMAS is the ALE/IDoc message type that carries customer master data - general data, company code data, sales area data, partner functions and bank details - from the system of record to one or more receiving systems. It is used to distribute or replicate customer master changes, typically outbound from a central ERP or hub and inbound into a satellite ERP, CRM, or non-SAP system.
Key Concepts5
- SAP IDoc Architecture: Control Record, Data Segments and Status RecordsAn IDoc is a structured asynchronous integration document made of one control record, ordered data-segment records and a status history. EDIDC holds routing/control metadata, EDID4 stores segment payloads in extended format, and EDIDS records processing statuses and messages. The basic type/extension defines the segment hierarchy; partner profiles, ports and process codes determine how the document is sent or processed.
- SAP RFC Types: sRFC, aRFC, tRFC, qRFC and bgRFCSAP RFC variants solve different execution guarantees: synchronous RFC waits for the remote result; asynchronous RFC starts work without the same blocking response pattern; tRFC provides transactional exactly-once style delivery through persisted LUWs; qRFC adds queue-based serialization for ordered processing; bgRFC is the newer background RFC framework for reliable transactional or queued units with scheduler-controlled processing and improved administration.
- SAP Cloud Integration iFlow Architecture ExplainedAn SAP Cloud Integration iFlow is an integration process that receives a message through a sender adapter, applies routing/transformation/enrichment/security steps, and delivers it through one or more receiver adapters. The runtime message carries headers, properties and body through the process. Good iFlows separate connectivity, canonical mapping and business routing, and avoid embedding environment-specific URLs, secrets or retry logic directly in scripts.
- Cloud Integration Error Handling, Retry and IdempotencyReliable Cloud Integration design separates transient technical failures from permanent business errors, uses controlled retries only for operations that are safe to repeat, and carries a stable business/correlation key so duplicate processing can be detected. An exception subprocess can classify failures and route them to logging, alerting, retry or dead-letter handling. Blind retries are dangerous for non-idempotent create operations.
- SAP BTP Cloud Connector: On-Premise Connectivity and Virtual MappingSAP Cloud Connector creates an outbound-established secure tunnel from a customer network to SAP BTP and exposes only configured internal systems/resources through virtual hosts and access-control mappings. BTP applications use destinations through the Connectivity service; they do not open arbitrary inbound network access to the landscape. Cloud Connector provides connectivity and trust plumbing, not application authorization or business API semantics.