C_ABAPD sample questions & answers

A logistics company on the ABAP environment runs a transactional app for shipment records built on a RAP business object. The business object defines a determination that fills a derived total weight whenever line items change, and a validation that blocks saving when the total exceeds the route limit. A developer is asked to add a background job that bulk-loads shipments from a partner feed. To keep it fast, the developer writes the job to insert rows directly into the underlying database tables of the business object. After the load, business users report that some bulk-loaded shipments show a blank total weight and a few breach the route limit, while shipments created through the app are always consistent. The developer confirms the same tables, fields, and data values are involved in both paths. The team needs the bulk load to produce shipments as consistent as those created interactively, without weakening or duplicating the rules already defined once on the business object. The correction must route the bulk creation through the layer that runs the business object's logic, so determinations and validations execute for loaded shipments exactly as they do for interactive ones.

Which approach makes the bulk-loaded shipments consistent with interactively created ones?

A retail analytics team on the ABAP environment maintains a report that lists each store with its total sales for a period. The current implementation reads the list of stores into an internal table, then loops over the stores and, for each one, issues a separate database read to sum that store's sales. With a handful of stores the report was fine, but after the chain expanded to several thousand stores it became very slow and occasionally times out, even though the underlying tables are correctly indexed and the result figures are correct. A developer must make the report scale without changing what it shows. The team has confirmed the slowness grows with the number of stores, and that each loop pass triggers its own round trip to the database. The correction must move the heavy aggregation work to where the data lives instead of pulling rows into the application server and combining them there, so the database returns the per-store totals in as few requests as possible. The result must remain identical; only the way the totals are produced should change so the report stays responsive as the store count grows.

Which change makes the report scale while returning the same totals?

A utilities provider on the ABAP environment is building several new custom tables that all store a "contract status" field. A developer types the status as a plain character field of fixed length directly on the first table and hardcodes the list of allowed values in the program that fills it. As more tables and programs are added, problems appear: one table accepts a status value the others reject, two programs disagree on the permitted codes, and a planned report cannot offer a consistent value help because each field is defined independently. The data values are valid in isolation, but there is no shared definition of what "contract status" means or which values are allowed. The developer must redefine the field so that every table and consuming program shares one definition of its technical type, its allowed value range, and its semantic meaning, and so that future tables reuse it instead of redeclaring it. The correction must centralise the field's type and permitted values in the dictionary so consistency and value help follow automatically wherever the field is used, rather than depending on each program to enforce the rules by hand.

How should the contract-status field be defined so all tables and programs share one consistent definition?

A healthcare services company on the ABAP environment exposes patient billing data through a CDS view that several apps and reports consume. To stop unauthorized users from seeing other regions' data, a developer adds an authorization check in one report that reads the view, filtering rows by the user's assigned region. Testing through that report looks correct. Soon after, a data-protection review finds that a second app and an ad-hoc query tool read the same CDS view directly and return billing rows for every region to any user who can open them, because the region restriction lives only inside the one report. The view itself enforces nothing, so each new consumer would have to re-implement the same check, and any consumer that forgets it leaks data. The developer must restrict read access at the view so the rule applies to every consumer automatically, regardless of which app or tool reads it. The correction must attach the region restriction to the CDS entity itself so authorized scope is enforced once, centrally, rather than being repeated in each consuming program and missed by some.

How should read access to the patient billing data be restricted so every consumer is covered?

A manufacturing customer on the ABAP environment has a pricing method in a shared class that occasionally returns the wrong discount for one combination of inputs reported by a key user. A developer can reproduce the bug manually and sees roughly where the logic is wrong. Leadership wants the fix today, but the same method is reused by several applications, and a previous "quick fix" to it reintroduced an old defect that was only noticed weeks later in production. The developer must correct the discount logic in a way that proves this specific case is handled and protects the method against future regressions, without relying on someone manually re-testing every consumer each time the method changes. The team wants the corrected behavior captured so the build itself will catch it if the logic breaks again. The correction must add an automated check that pins the expected discount for the reported combination and then fix the logic so that check passes, giving repeatable evidence rather than a one-off manual confirmation that the case now works.

What is the most reliable way to fix the discount defect and guard against regressions?

A consumer-goods company running SAP S/4HANA Cloud needs an extra approval check when sales orders above a threshold are created, plus a custom field shown on the order. Under deadline pressure, a developer proposes copying a standard application object into the customer namespace and editing the copy, because that is the fastest way to inject the logic. A senior reviewer warns that this path tends to break at the next upgrade and pulls the team away from a clean core. The company has committed to staying upgrade-stable so future updates apply with minimal rework. The developer must deliver the approval logic and the custom field using extension capabilities that are released for this purpose, so the core stays unmodified and the extension survives upgrades. The correction must use the platform's released extension points and public interfaces rather than altering or copying standard objects, keeping the solution within clean-core boundaries while still meeting the business requirement for the added check and the new field.

How should the approval check and custom field be delivered while keeping the core clean and upgrade-stable?