READ_TEXT — READ_TEXT function module for SAPscript long text

READ_TEXT reads long text objects stored in SAPscript text tables (STXH header, STXL lines) for a given text ID, language, object type and name. It is the standard low-level API used to retrieve item text, header text, purchase order notes, customer master text, and any custom long text created against a text object registered in text object customizing. It returns a THEAD structure describing the text found and a table of TLINE records holding the raw text lines in SAPscript line format, including control blocks for formatting. It is released for customer use and is one of the most widely called function modules in the system, invoked both from print programs and from ad hoc reporting where a text needs to be pulled outside its normal display context.

Call it with OBJECT, NAME, ID and LANGUAGE fully populated and always check SY-SUBRC afterward. If the result is NOT_FOUND, decide explicitly in the calling program whether that is acceptable for this business scenario or whether a fallback language or fallback text ID should be tried with a second, separate call, rather than assuming LINES is unchanged from a prior attempt. After a successful call the caller still owns reassembling LINES into a flat string or into a formatted stream, honoring the TDFORMAT and TDLINE columns; a naive concatenation discards line-break and formatting control information that downstream print forms rely on. When the text is destined for a SAPscript or Smart Form output, it is usually better to let the form's own text node resolve the text than to pre-read it here and pass a flat string, since that bypasses the form's built-in language and fallback handling.

READ_TEXT is unchanged in S/4HANA; SAPscript long text storage was not restructured in the move to HANA, so the same STXH/STXL structures and the same function module signature apply. It is not part of the released API allowlist for S/4HANA extensibility, and it is not positioned as a clean-core-compatible interface; side-by-side extensions on BTP that need document long text are expected to use a released OData or BAPI-based text service where one exists for the relevant object rather than calling this function module directly over RFC. Inside the classic ABAP stack it remains the standard tool with no announced deprecation or replacement.

This is ABAP development's problem, since it is invoked from custom code, user exits, and print or output logic rather than configured through the IMG. Functional consultants own the upstream data question: whether the relevant text ID exists for the object and whether users are actually maintaining the long text, which is the more frequent root cause of empty output than a coding defect. Basis has no role unless the failure traces back to archive access on ARCHIVE_HANDLE.

READ_TEXT is the read counterpart to SAVE_TEXT, which writes to the same STXH and STXL tables under the same ID/OBJECT/NAME/LANGUAGE key combination. Both rely on text object customizing, which defines which application area owns a given TDOBJECT and what key structure NAME must follow. Both are frequently wrapped by custom function modules that add caching, default-language fallback, or plain-text conversion around the raw SAPscript line format.