Inventory Management System — SAP ABAP RAP

A self-built SAP ABAP RAP application for real-time inventory/stock monitoring, developed on the SAP BTP ABAP Environment using the RESTful ABAP Programming Model (RAP) and Core Data Services (CDS).

Built during my full-time training toward the SAP® Certified Associate – Back-End Developer – ABAP™ Cloud certification, this project focuses on real-time computed status logic and Fiori-driven visual feedback rather than simple data entry.

Overview

The application tracks stock levels per product against a defined minimum stock level, automatically classifying each product's status and surfacing it visually in the Fiori UI as a traffic-light indicator. It also includes a custom action to trigger an inventory alert notification.

Key Features

• CDS-based data model: separate Product (master data) and ProductStock (inventory) entities, linked via association
• Value Help (F4) for product selection, with fuzzy search enabled (fuzzinessThreshold) for a more forgiving search experience
• Automatic stock status calculation: each stock record is classified as STOK YOK (out of stock), KRITIK (critical, at/below minimum level), or NORMAL
• Traffic-light UI: the calculated status drives a StockCriticality field (red / yellow / green) that is rendered directly in the Fiori Elements list, using the criticality UI annotation
• RAP Determination (determineProductDetails): automatically re-reads and recalculates product name, category, status, and criticality whenever the stock quantity or product reference changes — no manual refresh needed
• RAP Validation (validateQuantity): blocks saving if the entered stock quantity is negative, with a clear German-language error message
• Precheck on Create (precheck_create): prevents duplicate stock records from being created for the same product
• Live UI refresh via Side Effects: total_quantity changes automatically trigger a refresh of the full record ($self) in the UI
• Custom static Action (sendInventoryReport): triggers an inventory alert "report", using an abstract entity (Z_A_MailParameter_OD) to pass the recipient's e-mail address as an action parameter

E-Mail Integration — Simulated vs. Productive Code

The action currently runs in a simulated mode: it logs a JSON payload representing the outgoing e-mail (recipient, subject, body) and confirms success to the user via a standard RAP message — no e-mail is actually sent.

A productive implementation is also written and included in the code, but intentionally commented out: it uses cl_http_destination_provider to resolve an SAP BTP Destination (SAP_SMTP_SERVER) and sends the notification via HTTP POST. This path could not be tested end-to-end because my SAP BTP trial account does not have the authorizations required to configure and use a Destination Service instance. Rather than leave broken or untested code active, I kept the simulated version live and preserved the productive version for reference.

Tech Stack

• ABAP RESTful Application Programming Model (RAP) — Managed Implementation
• Core Data Services (CDS Views), CDS Value Help, CDS annotations for Fiori (criticality, lineItem, identification)
• ABAP Behavior Definitions: Determinations, Validations, Prechecks, Actions, Side Effects
• SAP Fiori Elements (OData V4 UI Service)
• SAP BTP ABAP Environment
• SAP BTP Destination Service / HTTP Client (cl_http_destination_provider, cl_web_http_client_manager) — implemented, not live-tested (see note above)

Status / Notes

This is a personal training project, not a productive system. It was deliberately designed to combine several RAP behavior concepts (determination, validation, precheck, action, side effects) in a single coherent business scenario, rather than demonstrating each in isolation.