ABAP Cheat Sheets

ABAP Cheat Sheets provide a collection of information on selected ABAP topics in a nutshell, focusing on ABAP syntax and including code snippets. They are designed to be used alongside demonstration examples that can be imported into an ABAP system using abapGit to run and verify syntax in action.

Key Characteristics

• Focus: Primarily targets ABAP for Cloud Development (the restricted language version used in the SAP BTP ABAP Environment), but also covers Standard ABAP (unrestricted/classic ABAP).
• Content: Includes syntax summaries, code snippets, and links to the official ABAP Keyword Documentation (F1 help) for deep dives.
• Nature of Examples: Most executable examples, code snippets, and object names (classes, methods, interfaces) are non-semantic. They are intended to illustrate ABAP statements and functionality, not to demonstrate best practices or real-world business logic.

This repository provides a comprehensive collection of ABAP cheat sheets covering various topics from basic data types to advanced RAP (RESTful ABAP Programming Model) and Generative AI. Each cheat sheet typically includes a markdown guide and a corresponding executable ABAP demo class or program to illustrate the concepts in practice.

Key topic areas include:

• Core ABAP: Data types, internal tables, structures, string processing, and program flow logic.
• Modern ABAP: ABAP Cloud, RAP (Entity Manipulation Language and Behavior Definition Language), and CDS View Entities.
• Advanced Programming: Object-Oriented ABAP, Dynamic Programming, Constructor Expressions, and Design Patterns.
• Database & Data: ABAP SQL, AMDP (ABAP Managed Database Procedures), and working with XML/JSON.
• System & Security: Authorization checks, SAP LUW (Logical Unit of Work), and Exception handling.
• Specialized Topics: Regular Expressions, Generative AI in ABAP Cloud, and ABAP Unit Testing.

The Multiton design pattern is a variant of the Singleton pattern used to manage a fixed set of distinct instances rather than just one.

While a Singleton ensures only one instance exists for an entire application, a Multiton manages multiple unique instances differentiated by unique keys (e.g., an ABAP enumerated type).

Key characteristics:

• Controlled Instantiation: A factory method manages a mapping between keys and instances in an internal table.
• Instance Reuse: If a requested key already exists in the internal table, the existing instance is returned. If not, a new instance is created, stored, and then returned.
• Flexibility: It allows for multiple controlled instances, each suited for different contexts or configurations, while still preventing uncontrolled proliferation of objects.

// Conceptual logic of a Multiton factory method
READ TABLE instance_table INTO DATA(ref) WITH KEY ikey = key.
IF ref-instance IS NOT BOUND.
  ref-instance = NEW #( key ).
  INSERT VALUE #( ikey = key instance = ref-instance ) INTO TABLE instance_table.
ENDIF.
instance = ref-instance.

The Abstract Factory pattern is used to create families of related objects (products) without specifying their concrete classes. It ensures that the objects created are compatible with each other within a specific variant.

Key Characteristics:

• Family of Products: It manages multiple related objects (e.g., in a restaurant: starters, main dishes, and desserts) that must work together.
• Consistency: It ensures that a specific variant (e.g., a 'Vegan' menu) only uses compatible components (e.g., no meat in starters or main dishes).
• Abstraction: It uses abstract classes for products and an abstract factory class to define the creation interface. Concrete factories then implement these methods to return specific product types.

Abstract Factory vs. Factory Method:

The Command design pattern wraps operations and their required details into individual objects. This abstraction allows you to:

• Store commands for later execution.
• Pass commands as arguments to methods.
• Execute commands in a specific order.
• Implement undo and redo functionality by maintaining a history of command objects.

Core Components

• Command Interface/Abstract Class: Defines a generic method (e.g., execute) for running the operation. Parameters are typically passed via instance attributes rather than method arguments to maintain a generic signature.
• Concrete Command Classes: Implement the interface. They hold a reference to a Receiver and the specific data needed for the operation (e.g., new dimensions for a resize command).
• Receiver Class: Contains the actual business logic and implementation of the operations (e.g., the code that actually changes an image's width).
• Invoker Class: Triggers the command execution (e.g., via an exec_cmd method) but remains unaware of how the receiver performs the work.
• Client: The orchestrator that creates the command objects and links them to the appropriate receivers.

The Composite design pattern is used when you need to work with objects that form hierarchical, tree-like structures. It allows you to treat individual objects (leaves) and compositions of objects (composites) uniformly through a common interface.

Key Components:

• Component Interface: Defines common operations shared by all implementing classes (both leaves and composites).
• Leaf Class: Represents individual objects without subordinates. It implements the component interface.
• Composite Class: Represents complex objects consisting of subordinate objects (which can be leaves or other composites). It implements the component interface and typically delegates processing to its subordinates (e.g., aggregating results).

Benefits:

• Uniformity: Clients can address any object in the hierarchy (the root, a branch, or a leaf) using the same interface without needing to know the specific type of object.
• Flexibility: You can add new types of leaves or composites without affecting existing client code.

The Mediator design pattern is used to reduce complexity when a group of objects interact with each other. Instead of objects communicating directly (which leads to tight coupling), they communicate through a central Mediator object that orchestrates and manages the interactions.

Key Components:

• Mediator Interface: Defines methods for communication between members.
• Concrete Mediator: Implements the interface and holds references to all member objects. It is responsible for the operational flow and sequence of logic.
• Members: Individual objects that interact with each other only by notifying the mediator. They do not need to know about the implementation of other members.

Benefits:

• Avoids tight coupling and dependencies between member objects.
• Improves maintainability by centralizing the operational flow.
• Enables greater flexibility in how objects interact.