WS_UPLOAD — WS_UPLOAD Legacy File Upload Function Module
WS_UPLOAD is an old, unreleased function module that reads a file from the SAPGUI frontend PC into an ABAP internal table. It predates GUI_UPLOAD, requires an active dialog SAPGUI session, and fails outright in background processing. It survives mainly in legacy custom programs and should not be used in new development.
This page covers WS_UPLOAD, the legacy frontend-to-server file upload function module, focusing on why it fails in batch contexts, which exceptions actually matter in production, and how silent exception-swallowing corrupts uploaded data. It also covers its relationship to GUI_UPLOAD and its status under S/4HANA clean-core guidance.
Published 16 Sept 2026· 1,022 words
What it does
WS_UPLOAD transfers a file selected on the frontend workstation (the PC running SAPGUI) into an ABAP internal table on the application server, the reverse operation of WS_DOWNLOAD. It dates from before the GUI_UPLOAD/GUI_DOWNLOAD family existed and relies on an older frontend control interface for the actual file transfer mechanics. It is not released for customer use and has carried a superseded status for a long time, but it remains present and callable in many systems because it was widely copied into custom programs written in the 1990s and 2000s. Because the transfer mechanism depends on a live SAPGUI session talking to the frontend PC, the module has no way to function when there is no frontend attached, which is the single most common cause of production failures involving it.
Parameters
- FILENAME (import) - full path and file name on the frontend PC, character type
- FILETYPE (import) - transfer mode, typically ASC for text files, BIN for binary, or DAT for delimited data records
- The receiving TABLES parameter - an internal table populated with one row per uploaded line or record; the exact parameter name and any secondary optional parameters (item count limits, truncation length, codepage override, error tolerance flags) vary by release and should be confirmed against the actual signature in the target system rather than assumed
- Exceptions parameter list, which must be declared explicitly on the CALL FUNCTION statement to be caught at all
Exceptions
This is the section that actually matters when something goes wrong.
- FILE_OPEN_ERROR - the path does not exist on the frontend, is locked by another process, or the user lacks permission; the calling program should stop and message the user rather than proceed
- FILE_READ_ERROR - the file opened but reading failed partway through, for example a dropped network drive or an antivirus lock; if swallowed, the internal table ends up with a partial file silently treated as complete
- INVALID_TYPE - the FILETYPE value passed is not recognized, almost always a typo hard-coded in the calling program rather than a runtime condition
- INVALID_TABLE_WIDTH - the internal table's line length does not match what the chosen FILETYPE expects; unchecked, this manifests as truncated or field-shifted data rather than an obvious error
- NO_BATCH - the function was called without an active SAPGUI, most commonly because the containing program was scheduled as a background job; this is the exception seen most often in production incidents involving this module
- UNKNOWN_ERROR - a catch-all usually pointing to a frontend control or SAPGUI version incompatibility
- If none of these are checked, SY-SUBRC after the call is meaningless and the calling logic proceeds on an empty, partial, or garbled table with no visible error anywhere in the trace
How to call it safely
Call it with an explicit FILENAME pointing at a frontend path, FILETYPE set deliberately rather than defaulted, and the receiving table structured to exactly match the record layout implied by that filetype. List every exception on the CALL FUNCTION statement and test SY-SUBRC immediately afterward; a return code of zero does not guarantee useful data, so the row count of the receiving table should be validated separately, since an empty source file uploads cleanly with no exception at all. Check SY-BATCH or the execution context before the call, because WS_UPLOAD cannot succeed without an attached SAPGUI and there is no graceful fallback.
ECC vs S/4HANA
WS_UPLOAD is technically still callable on S/4HANA as inherited ABAP, but it has no place in a clean-core extension and is not part of any released extensibility concept. GUI_UPLOAD has been the standard replacement for a long time and should be used for any frontend file upload still required in dialog programs. On S/4HANA, frontend file upload of any kind is increasingly avoided in favor of server-side file staging or OData-based upload interfaces suited to Fiori and RAP development. Finding WS_UPLOAD in a codebase during an S/4HANA readiness assessment is a legacy-code flag, not a runtime blocker, since the module keeps working until the calling program hits the NO_BATCH condition or is otherwise retired.
Common pitfalls
- Program is scheduled as a background job and fails immediately with NO_BATCH because there is no SAPGUI session available to run the file transfer
- Receiving internal table structure does not match the record width implied by FILETYPE, producing INVALID_TABLE_WIDTH or, when the exception is ignored, silently shifted field values
- Copied legacy example code ignores all listed exceptions and only checks whether the resulting table is non-empty, missing partial-load and truncation scenarios entirely
- Frontend file saved in a different codepage than the active SAPGUI session, producing garbled characters with no exception raised because encoding mismatch is not treated as an error condition by this module
- New development calls WS_UPLOAD out of habit or because it appears in an old copy-paste template, when GUI_UPLOAD is the documented, better-behaved replacement
Whose problem this is
This is a development-team problem. The ABAP developer or team maintaining the custom program that calls WS_UPLOAD owns any failure traced to it. Basis gets involved only when the root cause is genuinely frontend-side, such as a SAPGUI security policy blocking file transfers or a mismatched frontend patch level. Functional consultants encountering this error should route it straight back to development rather than treating it as a configuration issue.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/ws-uploadERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.