BAPI_MESSAGE_GETDETAIL — Read SAP Message Short and Long Text
BAPI_MESSAGE_GETDETAIL returns the short message text and long text for a SAP message ID and message number, substituting up to four message variables and formatting the long text in the requested output format. SAP's BAPI documentation uses it as the BapiService.MessageGetDetail service. It is read-only and requires no commit.
Reference for BAPI_MESSAGE_GETDETAIL, the BapiService method used to resolve SAP message IDs/numbers into readable short and long text for error handling, logs, and remote BAPI clients.
Published 20 Sept 2026· 669 words
What it does
BAPI_MESSAGE_GETDETAIL resolves a technical SAP message identifier into user-readable text. Given a message class/ID and message number, it can substitute MESSAGE_V1 through MESSAGE_V4 into the text and return both the short message and long text. SAP's own BAPI programming examples use this service when a caller receives a BAPIRET2 message and needs the explanatory text rather than only ID/NUMBER/variables.
Important parameters
SAP's documented example shows ID, NUMBER, LANGUAGE, TEXTFORMAT, MESSAGE_V1 through MESSAGE_V4, MESSAGE, RETURN, and the TEXT table. Preserve the original BAPIRET2 fields so the resolved text matches the message that the business BAPI actually returned.
For a business-API message lookup, identify the exact message class and number and the language and variables required to render it. The resulting long text may contain placeholders; preserve the original structured message ID, type, number and variables in logs rather than saving only a localized sentence. If the displayed text differs by user, compare the message language/template and runtime variables before diagnosing different business outcomes. Confirm the exact active SE37 signature because text format and option flags may differ across releases.
- ID — SAP message class, corresponding to BAPIRET2-ID.
- NUMBER — message number within the class.
- LANGUAGE — optional output language; use the SAP language key expected by the interface.
- TEXTFORMAT — requested long-text format such as ASCII or HTML where supported.
- MESSAGE_V1 to MESSAGE_V4 — runtime values substituted into the message placeholders.
- MESSAGE — resolved short text; TEXT — returned long-text lines; RETURN — service-level result.
Commit behaviour
BAPI_MESSAGE_GETDETAIL is read-only. It does not change application or repository data and requires no BAPI_TRANSACTION_COMMIT. It can be called after another BAPI returns messages, including on an error path where the caller intends to roll back the business transaction.
Return handling
Check RETURN for errors in resolving the message, then use MESSAGE and TEXT only when the message ID/number and language were valid. Do not throw away the original technical message fields after rendering the text; support teams often need ID, NUMBER and variables because translated wording can differ by logon language.
- Keep ID/NUMBER/V1-V4 in logs alongside the rendered text.
- A missing long text is not necessarily a failure if the message class has only a short text.
- Do not treat rendered message text as a stable machine key; program logic should use technical message fields or documented return semantics.
- When many messages are processed, avoid repeatedly resolving the same message metadata unnecessarily.
ECC vs S/4HANA
SAP continues to document BAPI_MESSAGE_GETDETAIL as the BapiService.MessageGetDetail method in BAPI programming guidance. It remains useful for classic BAPI/RFC clients in S/4HANA on-premise/private-cloud systems. New REST/OData APIs typically return their own structured error payloads, so this BAPI is most relevant when the source error itself uses SAP message class/number semantics.
Common pitfalls
- Passing BAPIRET2-NUMBER into ID or otherwise swapping message class and message number.
- Dropping MESSAGE_V1 to MESSAGE_V4, which produces incomplete or misleading resolved text.
- Using a two-character ISO language code when the interface expects a SAP language key.
- Writing program logic against translated message text instead of technical return fields.
- Assuming every SAP message has a maintained long text.
Whose problem this is
ABAP/integration developers own correct extraction of BAPIRET2 fields and message rendering. Functional teams own the business cause represented by the original message. Translation/application owners maintain the underlying message texts; Basis is normally not involved unless the issue is broader repository/transport consistency.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-message-getdetailERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.