Lesson 23 — Independent Final Project: Warehouse Supervisor Improvements

Independent practice: 3 hours
Environment: SAP BTP ABAP Trial + Eclipse ADT + Fiori Elements Preview
Prerequisite: Complete the Lesson 23 guided project, at least through the working local RAP Stock Check app.

Replace ## with your two uppercase initials (for example AB) in every student-created object name. You have created a Stock Check application that stores checks in BTP and, where connectivity is available, reads S/4HANA Product IDs through a remote value help. A warehouse supervisor now wants the application to be easier to use and more reliable.

1. Business request

“When someone creates a stock check, they should be able to choose a real product, record where it was counted, and see a clear list of completed checks. They should not confuse a failed product lookup with a valid search that returns no matches. I also want proof that entering a quantity doesn't change actual S/4HANA stock.”

Your task is to improve the app you just built, not create another unrelated set of RAP objects.

Required deliverables

Deliverable	What you will demonstrate
Useful Stock Check UI	Create and display two different local checks
Product value help	Open it, choose a remote S/4HANA product, and save its ID locally
Product filter	Restrict the remote list to a known Product ID or Product Type
Empty-result behavior	Test a clearly nonexistent product without reporting a connection error
Query handling	Check that paging/count do not confuse the value-help dialog
Local/remote boundary	Show that Stock Check data is local but Product master data remains remote
Technical handover	Explain which components you changed and what was actually tested

2. Check your starting point

1. Open the ABAP perspective in Eclipse ADT.
2. In Project Explorer, expand your ZPKG_L23_## package (or your actual package).
3. Confirm these objects are active:
   • your local Stock Check database table and generated managed RAP BO;
   • the CDS projection, service definition and OData V4 UI service binding;
   • the CDS custom entity and its IF_RAP_QUERY_PROVIDER class;
   • the new Service Consumption Model ZSC_L23_PROD_## created in the guided lesson.
4. Run ZCL_L23_API_TEST_## again to confirm the S/4HANA destination is still reachable.
5. Open the OData V4 Service Binding and launch the Fiori Preview for StockCheck.

If remote access is unavailable, do not stop working on the local RAP portion. Follow Section 9's fallback, and clearly report which remote tests were not executed.

3. Task A — Make the Stock Check app usable

The default generator might create a form with field names that are technically correct but not especially helpful to warehouse staff.

Requirements

• Confirm the list and object page expose Product ID, Warehouse, Counted Quantity, Check Status and Notes.
• Rename field labels in the appropriate CDS metadata/UI layer if needed; do not rename physical database columns just to change a label.
• Choose a sensible display order: Product, Warehouse, Quantity, Status, Notes.
• Create two locally saved stock-check records with different Product IDs and warehouse codes. Use genuine remote Product IDs only if the value help is working; otherwise clearly identify any manually entered values.

Example annotation pattern

You can use @UI.lineItem and @UI.identification for display. In the generated projection, the field appears in a comma-separated select list:

@UI.lineItem: [ { position: 10 } ]
@UI.identification: [ { position: 10 } ]
ProductId,

If the generator places UI annotations in a metadata extension, update the existing annotations there instead. Metadata-extension elements end with a semicolon:

@UI.lineItem: [ { position: 10 } ]
@UI.identification: [ { position: 10 } ]
ProductId;

Do not paste this into the database table. Find the existing ProductId declaration in the UI-facing projection or metadata extension, then add or adapt UI annotations according to that file's annotation setup. A generator might already add UI annotations; avoid duplicates and conflicts.

Acceptance test: A colleague looking at your list can identify which product was checked, where, and how many units were counted without interpreting UUIDs.

4. Task B — Make the product selection useful

Test the remote Product custom entity behind the value help.

1. In the Fiori Create form, click the Product ID value-help icon.
2. Verify it lists real S/4HANA Product IDs and related fields (Product Type and Product Group).
3. Select one of the products from the actual result.
4. Save a local Stock Check referring to that product.
5. Open the saved check again. Verify the selected Product ID is persisted in your own RAP business object.
6. Explain: Which component provided the Product ID, and which component stored the stock-check row?

Product IDs such as A001 are examples, not guaranteed records in every tenant. Use whichever IDs your backend returns.

5. Task C — Filter the remote list

The warehouse supervisor wants to search only for relevant products.

Requirement 1: Exact product lookup

Use the Fiori value-help filter (if exposed), or adapt the custom query-provider test, to request a product known to exist in your tenant. Check that the results contain only that Product ID.

Your custom query provider translates fields like this:

Local OData property	ABAP proxy property path	Remote OData property
Product	PRODUCT	Product
ProductTypeName	PRODUCT_TYPE	ProductType
ProductGroupName	PRODUCT_GROUP	ProductGroup

Requirement 2: Product Type lookup

Choose a product type observed in your data (for example SERV if present). Use the Product Type filter in the Fiori value-help dialog if exposed, or send $filter=ProductTypeName eq 'SERV' to the local service's Product entity set with a bounded page such as $top=20. Verify that every returned product has that type.

The query provider maps the local property ProductTypeName to the ABAP proxy property path PRODUCT_TYPE in create_by_range( iv_property_path = ... ). The proxy translates this to the remote OData property ProductType. Use PRODUCT_TYPE only in the proxy code; a direct request to the remote API would use $filter=ProductType eq 'SERV'.

Debugging hint: Put a breakpoint in ZCL_L23_PRODUCTS_## at the loop over lt_ranges, run the value help, and inspect ls_filter-name and ls_filter-range. Use the debugger rather than guessing whether the value-help dialog sent PRODUCT or PRODUCTTYPENAME.

Requirement 3: No results

Choose an unlikely Product ID, for example ZZ_L23_DOES_NOT_EXIST. A valid, executed read that returns zero matching rows is not the same thing as a failed connection. Record the actual response and your observation.

6. Task D — Verify count and paging

Fiori may request only one page of product results and the total number of matching products.

1. Inspect the query provider's call to io_request->get_paging( ) and its use of set_top() and set_skip().
2. Inspect the request_count() and get_count() calls.
3. In the Fiori value-help dialog, load a first page and, if supported by the UI, load or scroll to another page.
4. Check that items are not obviously duplicated across pages, and that the count is not simply the current page size.
5. Explain why an explicit Product-ID sort is useful for stable paging.

Your provider already maps supported sorting on Product, Product Type and Product Group; inspect get_sort_elements( ) and the Product tie-breaker. The provider deliberately rejects free-text search and other unsupported operations. Use documented filter controls, not the generic search box, to test exact lookups.

7. Task E — Test the failure paths without breaking the tenant

Explain and, where safe, demonstrate the difference between these problems:

Failure	Likely layer	Evidence
Product API can't be reached	Communication arrangement / remote service	ZCL_L23_API_TEST_## error or query-provider exception
Product ID doesn't match any remote record	Valid remote query with empty data	Zero results, no connection exception
Local stock check cannot be saved	Generated RAP BO or draft state	Fiori form/save error; inspect local BO
Product value help isn't shown	Projection annotation, service definition, binding metadata	Missing icon/entity; inspect ADT objects

Do not delete a communication arrangement, change credentials, or send POST/PUT/DELETE to the shared S/4HANA Product API for a negative test. Use inspection, the debugger and normal read-only queries.

8. Optional challenge — Strengthen the business rules

If you finish the required tasks, add one small improvement to the local Stock Check RAP BO, not to SAP's Product API. Examples:

• Make Warehouse and Product ID required fields in the appropriate RAP behavior/field control, with a suitable server-side check where needed.
• Reject a negative Counted Quantity using a RAP validation on save. Reuse the validation pattern learned in earlier RAP lessons.
• Restrict CheckStatus to a small documented set of values using a RAP validation, with a helpful error message.

Use the actual generated root CDS element names, behavior definition and behavior pool. The RAP generator may have created a draft-enabled behavior; ensure any changes are compatible with the generated draft implementation. A UI-only field requirement does not automatically protect API calls from other clients.

Optional means optional: The core project is complete without this validation challenge. Do not destabilize the working Fiori application just to add extra behavior at the end of the course.

9. If remote Product API access is unavailable

Complete the following verified local work and document the limitation honestly:

1. Show the generated local Stock Check Fiori application.
2. Create and save two local rows with clearly labeled manually entered sample Product IDs.
3. Show the CDS Custom Entity and the query-provider class activated if possible.
4. Execute ZCL_L23_API_TEST_## and capture the actual error or blocked-connection result.
5. Explain the data flow that would be used when the remote connection works.
6. Mark the remote value-help acceptance test not verified, rather than passing it with static/manual data.

There is no requirement to build a mock S/4HANA Product API just to complete this final-day project.

10. Final handover and demonstration

Present your application as though you're showing the result of one day's development to a team lead.

Demonstration sequence

1. Open the stock-check Fiori list.
2. Explain where the local records are stored.
3. Open the Product value help and show a remote product (if connected).
4. Create a new Stock Check with an actual product ID.
5. Save and display that new local row.
6. Show one product filter or empty-result test.
7. Explain why this solution does not modify S/4HANA Product master data.

Handover template

Project: BTP Stock Check Side-by-Side Extension

BTP package:
Local RAP table:
Generated RAP root and projection:
Service definition / binding:
Remote custom entity:
Query-provider class:
SCM created in this project and communication scenario:

Features demonstrated:
Remote tests executed successfully:
Local CRUD tests executed successfully:
Known limitations:
One production improvement I would prioritize:
Why this is a Clean Core / side-by-side approach:

Completion checklist

• I have a working local Stock Check RAP/Fiori app.
• I can distinguish local transactional data from remote Product master data.
• Product value help uses the S/4HANA Product API through the new SCM created in this project if connectivity permits.
• I used a documented filter or observed the actual limitation.
• I understand paging and total count in the custom query provider.
• I have tested a valid empty result and described an actual failure case.
• I did not edit SAP standard tables or send write requests to the shared S/4HANA Product API.
• I can demonstrate the final solution and provide an honest technical handover.

Success: You can build a modest application on SAP BTP, integrate it with S/4HANA through a supported API, identify problems by layer, and show a working feature to another developer.