SE37 — Function Builder for testing and building function modules
SE37 is the Function Builder, used to create, change, test, and debug function modules and BAPIs. It is the standard way to run a function module in isolation with test data before or instead of triggering it through the actual calling program. Function modules live inside function groups, which own the shared global data and main program, and that grouping is the source of most confusion.
SE37 covers how to test and troubleshoot function modules and BAPIs directly, without going through the calling transaction or interface. It focuses on the diagnostic gap between an isolated SE37 test run and the same function module executed inside a real LUW, which is where most false negatives and false positives come from.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,220 words
Purpose
SE37 is the workbench tool for creating, displaying, changing, testing, and debugging function modules, including BAPIs and RFC-enabled modules. A function module is not a standalone program: it belongs to a function group, and the function group is the actual ABAP main program that holds the shared global data, the TOP include, and the internal subroutines the module can call. Activating one function module recompiles the whole group. This matters because global data set by one function module in a group persists for other function modules in the same group during the same session, which is why a function module can behave differently when called in isolation through SE37's test screen versus when called as the fourth step in a chain of calls within the same logical unit of work.
When it is used
SE37 gets used whenever a BAPI, an update function module, or an interface routine misbehaves and someone needs to confirm whether the fault sits in the function module itself or in the data passed to it. A functional consultant reaches for it after a BAPI call from a batch job, IDoc processing, or a custom report returns an unexpected exception or a blank result, to re-run the same BAPI standalone with the exact same import values and see the raw export parameters and messages. It sits upstream of debugging a full transaction: instead of stepping through the whole calling program, the function module is isolated and tested directly. There is no Fiori equivalent; this is purely a development workbench tool, not a business-facing app.
How to use it in practice
- Enter the function module name in the initial screen, using F4 with a pattern such as BAPI_* or Z* if the exact name is not known
- Choose Display to inspect the interface and source without changing anything, or Change if editing rights and a transport request are available
- From the Function Module menu or with F8, switch to the test screen
- Populate the import parameters, tables, and any structures required, matching the values seen in the failing call as closely as possible
- Execute; inspect the export parameters, changed tables, and any exception raised in the result screen
- If the standalone run does not reproduce the fault, set a breakpoint in the source and re-trigger the module from its real calling program instead of from SE37 directly
Key data objects
- TFDIR - function module directory, linking the function module name to its generated program and function group
- ENLFDIR - extended function module directory, holding attributes such as remote-enabled status, update-task setting, and short text pointers
- TLIBG - function group master table, one row per function group
- TLIBT - function group text table, holding the group's short description in each language
- The parameter interface itself (import, export, changing, tables, exceptions and their types) is stored in the function builder's own metadata tables, which are not normally queried directly through SE16 since they are maintained exclusively through SE37 or SE80
How to prove it in the data
In SE16, open TFDIR, filter FUNCNAME on the module name, and confirm the linked program (PNAME) and function group area match what the calling program expects. Cross-check ENLFDIR for the same function name to see whether the remote-enabled flag or update-task flag is set the way the calling code assumes. If a transport or version mismatch is suspected, compare the object's entry in TADIR against the package shown in SE37's attributes, and check whether the active version differs from what a long-running work process still has buffered.
ECC vs S/4HANA
SE37 is unchanged on S/4HANA. It still creates and tests both classic function modules and BAPIs, and BAPIs remain a primary integration surface even where new development favors class-based methods. There is no Fiori replacement, since this is a developer tool rather than a business transaction; the only shift is that new custom logic is more often built as a class method tested through SE24 rather than as a new function module, while the existing function module landscape stays fully relevant for testing and troubleshooting.
Common pitfalls and how to diagnose them
- Global data contamination - a function module tested alone in SE37 starts with clean global data for its function group, but in production the same group may already have global data set by an earlier call in the same session; test standalone first, then retest by triggering the module through its real caller if results differ
- Update task timing - a function module coded to run 'IN UPDATE TASK' does not execute synchronously when called directly from application logic; testing it from SE37 in immediate mode can mask an update-task-specific failure, and the real symptom only shows up in the update records after a commit
- RFC and destination issues - a function module marked remote-enabled can still fail across systems if the target destination, user, or authorization context differs from the local test user in SE37; test both locally and against the actual RFC destination before concluding the module itself is broken
- Silent exceptions - SE37's test screen displays a raised exception clearly, but the original calling program may have caught that same exception without handling it or displaying anything, producing a dump or silent failure downstream; always compare what SE37 shows against what the caller's exception table actually declares
- Version and buffer mismatch - a function module edited and activated does not take effect in a long-running background work process until its buffer is refreshed or the process restarts; a fix that tests correctly in SE37 but does not appear in production points here first
- Direct modification of standard modules - editing and activating an SAP-delivered function module directly to patch a bug creates an unreleased modification that upgrade tools will flag later; the change belongs in the sanctioned enhancement or correction channel, not as a live edit in SE37
Whose problem this is
SE37 is an ABAP developer's tool, but functional consultants use its test screen constantly to isolate a BAPI or interface failure before escalating. A good handover includes the exact function module name, the import parameter values used, the export result or exception received, and whether the fault reproduces standalone in SE37 or only inside the full calling transaction, since that distinction points the developer straight at global data or update-task timing.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/se37ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.