SCMS_BINARY_TO_XSTRING — Convert Binary Table to XSTRING
SCMS_BINARY_TO_XSTRING reassembles a binary table, a table of fixed-length raw or character chunks typically 255 bytes per row, into a single XSTRING value. It is released for customer use and is the standard bridge between line-oriented file content, such as what GUI_UPLOAD produces, and APIs or BAPIs that expect file data as one contiguous binary string.
This page covers what SCMS_BINARY_TO_XSTRING does, its parameters, why the FAILED exception matters more than it looks, and the recurring cause of corrupted files: a wrong INPUT_LENGTH value. It also covers how the function module fits alongside GUI_UPLOAD and BAPI attachment interfaces on both ECC and S/4HANA.
Published 16 Sept 2026· 1,039 words
What it does
SCMS_BINARY_TO_XSTRING converts content held in a binary table, a table of fixed-length raw or character rows commonly produced by GUI_UPLOAD, OPEN DATASET binary reads, or content repository calls, into a single XSTRING variable. It is a released utility function module in the content management area and is safe for customer code. Interfaces increasingly expect file payloads as XSTRING rather than as a line-oriented table, so this FM is the standard way to feed uploaded files into BAPIs, document attachment APIs, HTTP client bodies, or cryptographic function modules. It performs no interpretation of the payload, no character set conversion, and no validation of file structure. It purely reassembles bytes in their original order and trims the padding that binary tables carry on their last row, which is why the length parameter matters.
Parameters
- INPUT_LENGTH (importing, type I) - the exact byte length of the source content. Binary tables pad their last row to the fixed row length, so this value tells the function module where the real data ends and the padding begins.
- BINARY_TAB (tables parameter) - the source binary table, one row per fixed-length chunk, in the same order the file was read or uploaded. The function module reads it sequentially and does not sort or deduplicate rows.
- BUFFER (exporting, type XSTRING) - the resulting binary string, exactly INPUT_LENGTH bytes long on success. This is the value passed on to whatever API expects XSTRING content.
- FAILED (exception) - raised when the conversion cannot complete; see the exceptions section for what actually triggers it.
Exceptions
- FAILED is the only exception this function module raises, and it typically fires when INPUT_LENGTH is inconsistent with the content actually present in BINARY_TAB, for example a negative or zero length, or a length that implies more data than the table rows can supply.
- When FAILED is not caught, the calling program continues with whatever BUFFER held before the call, which in a freshly declared variable is initial. Downstream code then forwards an empty or stale XSTRING to a BAPI or attachment API, and that call frequently reports success because zero bytes is technically valid content for many interfaces.
- The visible symptom shows up much later than the actual fault: an email attachment that opens as zero KB, a document repository entry with no retrievable content, or a digital signature check failing on an empty payload. Tracing back from that symptom to a swallowed FAILED exception is the most common root cause path for this function module.
How to call it safely
Populate BINARY_TAB from the source read (a GUI_UPLOAD call in binary mode, or an OPEN DATASET loop) and capture the true byte count the source reports, not the row count multiplied by 255. Call the function module with EXCEPTIONS FAILED = 1 OTHERS = 2, and treat any non-zero SY-SUBRC as fatal rather than logging and continuing. After the call, check that XSTRLEN( BUFFER ) equals INPUT_LENGTH before passing BUFFER onward. If the two do not match, something upstream miscounted the length or the table content, and the caller should stop rather than forward a malformed payload.
ECC vs S/4HANA
SCMS_BINARY_TO_XSTRING behaves identically on ECC and S/4HANA; it is a low-level ABAP utility, not tied to any Fiori app, OData service, or business process, so there is no functional difference between releases. It has not been deprecated or replaced, and remains a normal building block in custom ABAP even under clean-core guidance, since it is plain data conversion rather than a business API. Newer custom developments sometimes favor stream-based or object-oriented conversion utilities where the surrounding framework already works with streams, but SCMS_BINARY_TO_XSTRING remains the direct and reliable choice when the source is genuinely a binary table.
Common pitfalls
- Passing INPUT_LENGTH as the row count times 255 instead of the file's real size. The extra padding bytes from the last row get appended into BUFFER, and the resulting file has trailing garbage: PDFs that render but fail validation, ZIP files that some tools open and others reject, and signed documents that fail hash checks.
- Ignoring the FAILED exception entirely, which turns a conversion failure into a silent empty attachment several calls downstream, usually surfacing as a user complaint days later rather than as an error at the point of failure.
- Assuming this function module does any codepage or line-ending conversion. It does not; a text file uploaded with the wrong encoding will convert cleanly into an XSTRING that still contains the wrong bytes, and the mismatch needs fixing at the point of upload or with a dedicated conversion step, not here.
- Calling it inside a tight loop for very large files. Assembling a large table into one XSTRING is a memory-bound operation, and repeated calls for chunked processing of very large files can be slower and more memory-hungry than a single call with the complete table.
Whose problem this is
This is a technical, developer-owned function module, not a business configuration object. Responsibility sits with whoever wrote the custom program or interface calling it: the ABAP developer for the upload, conversion, or attachment logic, and the integration or interface team if the XSTRING feeds a BAPI, web service, or document management call. Functional consultants only get involved once the symptom is traced back to a corrupted or empty file produced by this conversion step.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/scms-binary-to-xstringERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.