SAP Library / RAP / CDS / OData / Cheat sheet
SAP RAP / CDS / OData cheat sheet
31 objects in 5 groups. Each links to its full reviewed page.
T-Codes16
- SEGWSEGW is used to model and implement classic custom OData V2 services using entity types, associations and generated provider classes. It is most useful when maintaining an existing SEGW service or analyzing model-to-runtime behavior in a classic Gateway implementation. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- /IWFND/MAINT_SERVICE/IWFND/MAINT_SERVICE is used to register, activate and manage SAP Gateway OData services and their system aliases. It is most useful when an OData V2 service is not available, points to the wrong backend, or requires registration after deployment. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- /IWFND/GW_CLIENT/IWFND/GW_CLIENT is used to execute and inspect OData/HTTP requests directly inside SAP Gateway without relying on the consuming frontend. It is most useful when testing service metadata, entity sets, filters, payloads, CSRF behavior or reproducing a failing request. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- /IWFND/ERROR_LOG/IWFND/ERROR_LOG is used to analyze SAP Gateway runtime errors with HTTP status, service context, exception details and replay options. It is most useful when a Fiori or OData request returns 4xx/5xx errors or fails in Gateway processing. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- ST05ST05 is the SQL/performance trace transaction. It records actual database calls, enqueue requests, RFC calls, and buffer activity for a chosen user during a defined recording window, then displays them as a sortable list. It is the tool used to see whether a slow transaction is spending its time in repeated or expensive SQL statements rather than in ABAP processing.
- SATSAT is the ABAP runtime analysis transaction that measures execution time, call counts, and aggregated database time for a program, transaction, function module, or RFC. It replaced the older SE30 transaction and gives a statement-level breakdown of where processing time is actually spent, distinguishing gross time (including called routines) from net time (own code only).
- SE24SE24 is the Class Builder, used to create and maintain global ABAP OO classes and interfaces: their attributes, methods, events, and inheritance relationships. It generates and stores method source code in system-managed includes rather than in a single flat program, which is the main source of confusion when developers try to edit or transport classes without understanding that structure.
- SE80SE80 Object Navigator provides one tree-based entry point to ABAP repository tools such as programs, classes, function groups, dictionary objects, screens, and packages. It does not own a separate business data model; it organizes underlying repository objects. For modern ABAP development, ADT may be preferred, but SE80 remains valuable for legacy and support work.
- SU53SU53 is used to show the most recent failed authorization check for the current user session. It is most useful immediately after an authorization error to identify the authorization object, field and attempted value. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
- PFCGPFCG is the transaction used to build, maintain, and generate authorization roles in SAP. It combines a menu of transactions or Fiori apps, a set of authorization objects with maintained values, and organizational level restrictions into a generated profile, which is then assigned to users. Role definition, profile generation, and user assignment are three separate saves.
- SICFSICF maintains the ICF service tree - the hierarchy of HTTP/HTTPS services (Fiori apps, OData endpoints, SOAP/REST services, ICF-based web services) that the Internet Communication Manager routes requests to. Activation is inherited down the tree, so a node showing active can still return 404 or 403 if a parent node above it in the path is inactive, wrongly authorized, or missing its handler class.
- SMICMSMICM is the monitor for the Internet Communication Manager, the OS-level process that handles inbound and outbound HTTP, HTTPS, and SMTP traffic for the ABAP stack. It shows whether ICM is running, which services and ports are active, connection and thread usage, and SSL/PSE status. It has no persistent business data of its own; everything shown is live process state plus profile parameters and trace files.
- ST22ST22 is used to analyze ABAP short dumps with runtime error, call stack, source extract, user and timestamp context. It is most useful when a dialog, background, RFC or update process terminates with an ABAP runtime error. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own logs or status information before changing configuration or data.
- SLG1SLG1 is the transaction that reads and displays the generic Business Application Log, a shared logging store that many SAP programs, batch jobs, and interfaces write into. It is a viewer, not a generator: nothing appears unless the calling program explicitly created and saved a log entry under a specific object and subobject key.
- SM59SM59 maintains RFC destinations, the stored connection parameters (target host, system, client, logon data) that let one SAP system call another system, an external program, or an HTTP service. A green connection test proves the network path and stored credentials work; it does not prove the actual interface call, which may use a different destination, user, or timeout, will succeed.
- SM21SM21 displays the kernel-level system log, which records work process starts and terminations, database connection errors, security audit events, and ABAP runtime failures at the operating system layer. It is a read-only viewer, not a database table browser. The underlying log is a rolling file per application server instance, so old entries age out and disappear once the buffer wraps.
Query Syntax & Concepts8
- OData query options and server side pagingOData query options such as $top, $skip, $filter, $orderby, $count and $expand let a client shape a result set. Server side paging is the backend deciding page size when the client omits $top. For managed RAP these are translated automatically into a database select with OFFSET/FETCH; for unmanaged RAP the developer's READ implementation must interpret and apply them, including computing the total record count, or paging silently breaks under volume.
- ETag and concurrency control in ODataAn ETag is a version marker the server returns with an entity, derived from a field such as a last-changed timestamp or version counter. The client must echo it back via an If-Match header on update or delete. If the current server value no longer matches, the request is rejected with 412 Precondition Failed, meaning someone else changed the record since it was read.
- OData batch requests and deep insertsA batch request bundles several OData operations into one HTTP call, with changesets as the atomic write unit inside it. A deep insert is a payload shape: creating a root entity and its child entities in a single nested JSON structure via navigation properties. They are often used together but solve different problems, and confusing the two is the most common source of bugs in create-heavy Fiori apps.
- OData V2 versus OData V4 for SAP developersOData V2 and V4 are distinct protocol versions with different metadata models and capabilities. RAP supports OData V4 natively and new RAP/Fiori Elements V4 scenarios often prefer V4, while V2 remains supported for existing Gateway/Fiori consumers and can also be exposed from RAP. Do not assume V4 means JSON batch: SAP Gateway V4 batch processing commonly uses multipart/mixed requests as documented.
- SAP Gateway OData Activation: Service, System Alias and ICFA classic SAP Gateway OData service must be registered/activated in the Gateway layer, mapped to the correct backend through a system alias when applicable, and reachable through active ICF services. /IWFND/MAINT_SERVICE manages service activation and aliases; SICF manages HTTP service nodes; /IWFND/GW_CLIENT tests requests. A working backend implementation can still return 'service not found' when any one of these layers is missing or mismatched.
- SEGW versus CDS based service exposureSEGW models classic SAP Gateway OData services and generates MPC/DPC classes, with application logic commonly implemented in DPC_EXT. CDS- and RAP-based exposure derives much more of the service model from CDS entities, service definitions and bindings, reducing hand-written provider code. For new S/4HANA development, CDS/RAP is normally preferred where it fits, while SEGW remains relevant for existing Gateway services and specific legacy scenarios.
- Service definition and service binding in RAPThe service definition is a DDLS source that declares which CDS entities (root and, via association, child entities) are exposed together as one OData service and under what entity set names. The service binding takes that definition, ties it to a protocol (OData V2 UI, OData V4 UI, Web API, INA) and a version, and publishes it as a runnable service in the gateway framework.
- Debugging an OData service end to endEnd-to-end OData debugging follows one failing request from the browser or API client through HTTP/ICF, SAP Gateway logs and payload, service routing, authorization, then the ABAP DPC or RAP behavior implementation and database access. The visible HTTP error is often only a wrapper, so use correlation IDs and backend logs to locate the actual exception or business message before setting breakpoints.
RAP / CDS Essentials2
- CDS view entities versus classic CDS DDIC viewsA classic CDS view declared with DEFINE VIEW creates a CDS artifact plus a generated DDIC SQL view name. A CDS view entity declared with DEFINE VIEW ENTITY is the newer model and does not create that separate classic DDIC SQL view object. View entities simplify activation and are the preferred basis for new CDS and RAP development, while classic CDS views remain common in existing code.
- Entity Manipulation Language in RAPEntity Manipulation Language, EML, is the ABAP statement set (READ ENTITY, MODIFY ENTITIES, EXECUTE, COMMIT ENTITIES, ROLLBACK ENTITIES) used to interact with a RAP business object from ABAP code instead of through OData. It looks like Open SQL but runs through the RAP runtime, meaning determinations, validations and authorization checks fire, and nothing reaches the database until a COMMIT ENTITIES triggers the save sequence.
Fiori Essentials4
- Fiori elements list report and object pageList Report and Object Page are the two standard Fiori elements floorplans used together to build a search-and-detail application: a filterable table of results (List Report) that navigates into a structured detail screen with sections, tables and facets (Object Page). Both are generated at runtime from CDS annotations and an OData service metadata document, not from hand-written UI5 views.
- Fiori elements versus freestyle FioriFiori elements generates the UI at runtime from OData metadata and CDS annotations, using standard floorplans like list report and object page. Freestyle Fiori is a hand-coded UI5 app with explicit views and controllers. The structural difference is who owns the screen: the framework, driven by annotations, or the developer, driven by JavaScript and XML views.
- SAP Fiori Architecture: Launchpad, UI5, Gateway and BackendA Fiori app runs SAPUI5 in the browser or launchpad shell, calls backend services—commonly OData/REST—through an HTTP/Gateway layer, and executes business logic and authorization in the S/4HANA backend or other service. In embedded S/4HANA deployments the frontend/Gateway components can run in the same system; hub deployments separate them. UI, service exposure, connectivity and backend logic remain distinct troubleshooting layers.
- Adaptation projects and Fiori extensibilityAn adaptation project is a Business Application Studio tool that lets a developer alter a standard Fiori elements app - hide fields, rename labels, add sections, extend controllers - without touching the original app's code. It produces a delta layer (an app variant descriptor plus change files) applied on top of the original manifest at runtime, so the standard app itself is never copied or modified.