ABAP RAP Glossary

    0
    33

    ABAP RAP stands for the ABAP RESTful Application Programming Model. The following terms of the ABAP RAP Glossary are listed, that are relevant for RAP.

    ABAP Behavior Pool (ABP) πŸ’‘

    A dedicated class pool in ABAP specifically designed for defining and implementing behavior logic for RAP business objects (BO). It plays a central role in organizing the behavior implementation. It contains local handler and saver classes within the CCIMP include, which handle the actual behavior logic. The global class is prefixed with BP_ but doesn’t directly define the behavior.


    ABAP Contract Checks βœ…

    Contract checks in ABAP are designed to ensure that development and runtime interactions align with defined standards:

    • RAP BO Contract Checks: Validate that the consumer and provider implementations adhere to the RAP BO’s predefined rules, ensuring seamless integration and compliance.
    • Transactional Contract Checks: Ensure data consistency during transactional phases, leveraging SAP’s LUW concept.

    ABAP Entity Manipulation Language (EML) πŸ”„

    A subset of ABAP designed to interact with RAP business objects. Unlike general ABAP code, EML specifically focuses on accessing and modifying business objects within the RAP model, facilitating streamlined transactional operations and behavior handling. Through EML statements, programs can perform operations on BOs, utilizing the transactional buffer. EML is often used in ABAP behavior pools for accessing and modifying BO data.


    ABAP RESTful Application Programming Model (RAP) 🌐

    A programming model adhering to REST architecture principles. This involves stateless interactions, resource-based operations, and the use of standard HTTP methods like GET, POST, PUT, and DELETE to facilitate client-server communication. In RAP, ABAP operates as a stateless web server, with OData handling client requests. The model relies on Core Data Services (CDS) for data modeling and includes:

    • CDS entities for querying.
    • RAP BOs for transactional operations, managed by providers or ABAP behavior implementations.

    ABP Auxiliary Class πŸ”§

    A globally defined class with special permissions to access RAP BOs. It offers reusable methods to streamline the development of behavior logic within an ABAP behavior pool.


    Abstract BDEF Extension ✨

    A development object that extends abstract behavior definitions in RAP using the extension statement.


    Ancestor Association πŸ›οΈ

    A hierarchical association in a RAP BO composition tree. It targets entities higher in the hierarchy, such as a BO’s root, and helps derive paths to master entities for authorization, locking, or ETag purposes.


    Base BDEF 🌐

    Also referred to as the projected BDEF, it serves as the foundational behavior definition for projections. It can be either managed or unmanaged.


    BDEF Derived Type πŸ”¬

    A data type derived from a RAP behavior definition, typically representing internal tables or structures. These types facilitate communication between RAP BO consumers and providers and are used in handler methods.


    BDEF Extension πŸ”„

    A repository object that adds to a RAP behavior definition. Extensions can be layered and categorized into:

    • Base extensions
    • Projection extensions
    • Abstract extensions

    BDEF Privileged Mode ⚑

    An operational mode that bypasses certain authorization checks, allowing privileged actions when consuming RAP BOs via EML.


    BDEF Strict Mode β€Ό

    A configuration that enforces stringent syntax rules in RAP behavior definitions to ensure best practices and prevent outdated constructs.


    CDS Root Entity πŸ› 

    The primary entity in a CDS composition tree, designated with the ROOT keyword. It typically represents the root node of a RAP BO.


    CDS Virtual Element 🎨

    A runtime-calculated field in a CDS projection view that isn’t stored in the database. Virtual elements are processed using RAP query engines and related frameworks.


    CRUD Operations πŸ”§

    Basic operationsβ€”Create, Read, Update, and Deleteβ€”used for managing persistent data. In RAP, these are implemented in behavior definitions via syntax elements like create, read, update, and delete.


    Draft-Enabled RAP BO 🌐

    A RAP BO configured for draft handling, allowing temporary states before finalizing and committing data. This is achieved using the WITH DRAFT syntax in RAP BDL.


    Entity Behavior Definition πŸ”„

    A component of RAP’s behavior definition, outlining behavior for specific entities. Each definition includes:

    1. Entity characteristics (before the curly braces).
    2. Entity behavior body (within the braces).

    Managed RAP BO Provider βœ…

    This provider type manages transactional buffers and ensures behavior implementation for managed RAP BOs, based on predefined RAP behavior definitions.


    RAP Authorization Control πŸ”’

    Mechanisms in RAP to restrict access to data or operations based on user permissions. Authorization can apply globally or at the instance level.


    RAP Behavior Definition Language (BDL) ✨

    A syntax framework for defining RAP behavior. BDL source code specifies the operations, validations, and actions of RAP BOs.


    RAP BO 🌐

    A business object in RAP with defined behavior, often implemented through CDS entities and behavior definitions. BOs handle queries, transactional operations, and more.


    RAP BO Consumer πŸ”§

    An entity that interacts with a RAP BO, either through ABAP EML in programs or via the RAP transactional engine handling external requests.


    RAP BO Extensions 🎨

    Enhancements to RAP BOs, implemented through repository objects. These include:

    • CDS extensions
    • Behavior extensions
    • Service definition extensions

    RAP Concurrency Control πŸ”

    Mechanisms to manage concurrent data access, ensuring consistency:

    • Optimistic Control: Uses ETags to handle potential conflicts. For instance, if multiple users attempt to update the same data, the ETag helps detect changes made by others, ensuring only the latest version is saved.
    • Pessimistic Control: Implements locks to prevent simultaneous modifications.