ABAP RAP

CRUD-Szenarios

(C) Brandeis Consulting📁

Scope

In diesem Foliensatz geht es ausschließlich um die Standard Features des Managed Szenarios. Die folgenden Aspekte sollen gelernt werden:

  • CRUD Anwendungen
  • Behavior Definitionen
  • Child Entities anlegen, bearbeiten und löschen

CRUD Anwendung

(C) Brandeis Consulting📁

Ablauf Interaktionsphase und Speichersequenz

Quelle
(Aus der SAP Dokumentation)

(C) Brandeis Consulting📁

Managed vs. Unmanaged

Managed

Beim Managed Szenario kümmert sich das RAP Framework um die CRUD Operationen:

  • Create
  • Read
  • Update
  • Delete

Darüber hinaus werden Sperren automatisch verwaltet. Neben den CRUD Operationen kann eigene Geschäftslogik implementiert werden, z.B. in Form von Aktionen, Ableitungen und Validierungen.

Unmanaged

Alles muss selber implementiert werden. Das ist ideal, wenn bestehende Anwendungslogik weiterverwendet werden soll. Dafür gibt es zwei lokale Klassen in der Implementierung

(C) Brandeis Consulting📁

Unmanaged - Die zu implementierenden Methoden

Interaction Phase

CLASS lhc_ZI_TASKS_UM DEFINITION 
                 INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS get_instance_authorizations 
               FOR INSTANCE AUTHORIZATION IMPORTING keys 
               REQUEST requested_authorizations 
               FOR zi_tasks_um RESULT result.

    METHODS create FOR MODIFY
      IMPORTING entities FOR CREATE zi_tasks_um.

    METHODS update FOR MODIFY
      IMPORTING entities FOR UPDATE zi_tasks_um.

    METHODS delete FOR MODIFY
      IMPORTING keys FOR DELETE zi_tasks_um.

    METHODS read FOR READ
      IMPORTING keys FOR READ zi_tasks_um RESULT result.

    METHODS lock FOR LOCK
      IMPORTING keys FOR LOCK zi_tasks_um.
ENDCLASS.

Save Sequence

CLASS lsc_ZI_TASKS_UM DEFINITION INHERITING FROM cl_abap_behavior_saver.
  PROTECTED SECTION.

    METHODS finalize REDEFINITION.

    METHODS check_before_save REDEFINITION.

    METHODS save REDEFINITION.

    METHODS cleanup REDEFINITION.

    METHODS cleanup_finalize REDEFINITION.

ENDCLASS.
(C) Brandeis Consulting📁

RAP Business Object (BO)

Ein RAP Business Object (BO) besteht aus den folgenden Komponenten:

Datenmodell (CDS Views)

Abbildung des BO Datenmodells auf die Datenbanktabellen.

Verhaltensdefinition (Behavior)

  • Nummernvergabe
  • Sperren
  • Aktionen
  • Validierungen
    ...

Implementierung - (ABAP Klassen)

Ausprogrammierung des Verhaltens, soweit das nicht generisch implementiert ist, z.B. im Managed Szenario

Das BO muss noch keine Oberflächeneigenschaften definieren.

(C) Brandeis Consulting📁

Business Object

Transaktionale RAP Anwendungen basieren auf einem sogenannten Business Object. Dieses besteht wiederum aus

  • Der Datenstruktur (CDS Root View Entity)
    • Kern des BO, definiert die Datenstruktur.
  • Der Verhaltensdefinition (Behavior)
    • Definiert das Verhalten des BO.
  • Der Service Definition (Service Definition)
    • Gibt an, welche Teile des BO für OData-Services freigegeben werden.
  • Das Service Binding* (Service Binding)
    • Bindet das BO an ein Protokoll (z. B. OData V4).
(C) Brandeis Consulting📁

Eine Entität (Behavior)

Im einfachsten Falle haben wir exakt eine Entität. Dieser CDS View wird dann als ROOT View angelegt. Dazu wird dann eine Verhaltensdefinition angelegt werden.

Das Mapping muss noch ergänzt werden. Es ist wichtig, damit die Felder des BO auf die Felder der DB-Tabelle abgebildet werden.

managed implementation in class zbp_i_jb3_projects unique;
strict;

define behavior for zi_jb3_projects //alias <alias_name>
persistent table ZBC_PROJECTS
lock master
authorization master ( instance )
//etag master <field_name>
{
  create;
  update;
  delete;
  mapping for zbc_projects
  {
    ProjectKey = project_key;
    Name = name;
    ProjectManager = project_manager;
    ChangedBy = changed_by;
    ChangedAt = changed_at;
    CreatedBy = created_by;
  }
}
(C) Brandeis Consulting📁

Mehrere Entitäten zu einem BO

Die BO Struktur mit CDS Views definiert

Die Datenstruktur von Business Objekten wird durch eine Root View Entity festgelegt.

  • COMPOSITION Beziehungen zu Bestandteilen des BOs: Ist Teil von...
  • ASSOCIATION Beziehungen zu anderen BOs: Bezieht sich auf...

(C) Brandeis Consulting📁

Feldeigenschaften

Die Feldeigenschaften werden innerhalb der Verhaltensdefinition vergeben. Die Notation dazu ist:
field ( <Feldeigenschaft> [,<Feldeigenschaft2>] ) <Feldliste>;

Liste der Feldeigenschaften

  • numbering:managed - Automatische Nummernvergabe von UUIDs
  • readonly - Nicht eingabebereit
  • readonly:update - Nur bei Anlage Eingabebereit, danach gesperrt
  • mandatory - Kennzeichnung auf der Oberfläche als Pflichtfeld. Eine Prüfung muss selber implementiert werden!
  • mandatory:create - Pflichtfeld für die Anlage eines Datensatzes. Prüfung durch das Framework
(C) Brandeis Consulting📁

Mapping der Felder

Zuordnung der Felder zwischen Business Object und Datenbanktabelle.

  mapping for zbc_tasks
  {
    TaskKey = task_key;
    Summary = summary;
    Status = status;
    Project = project;
  }

Mit dem Zusatz CORRESPONDING werden gleichlautende Felder automatisch gemappt:

  mapping for zbc_tasks corresponding
  {
    TaskKey = task_key;
  }

Ableiten des Mappings aus dem CDS View

Regulärer Ausdruck, um eine Feldliste des CDS Views in ein Mapping zu konvertieren:
ersetze (( key )|( ))(.*?)( *) as (.*), durch $6 $5 = $4;

Demo

(C) Brandeis Consulting📁

Sperren

Unterscheidung zwischen

  • Pessimistischer Sperre - Analog SAP GUI, vor dem Wechsel in den Änderungsmodus wird eine Sperre angefordert. Vor der Änderung wird die Sperre gesetzt und erst danach zurückgegeben. Damit werden alle Konflikte vermieden. Bei Draft Szenarien erfolgt die pessimistische Sperre über die Draft-Tabelle.
  • Optimistische Sperre - Beim Schreiben wird geprüft, ob sich die Version seit dem Anfang des Bearbeitens verändert hat. Also lediglich eine Erkennung von veralteten Daten. Für diese Erkennung wird das ETag-Feld verwendet. Typischer Kandidat als ETag-Feld: der letzte Änderungszeitstempel.
(C) Brandeis Consulting📁

Projektionen

Wenn wir allgemeine Views bzw. Anwendungen spezialisieren wollen, beispielsweise weil das gleiche BO Rollenspezifisch unterschiedlich bearbeitet werden soll, dann können wir Projektionen auf unsere bestehende Modelle anlegen.

Wir spezialisieren also unserer Services für eine Anwendungsfall.

  • Alle notwendigen Projektionsviews anlegen (
    • define .... as projection on ...
  • Assozationen umbiegen auf deren Projektionsviews
    • ... : redirected to composition child ...
    • ... : redirected to parent ...
  • Behavior Projezieren
  • definieren der verwendeten Aktionen
    • use ...
  • Anlegen der Service Definition und des Service Bindings
(C) Brandeis Consulting📁

Draft 1

  • Definition:
    Draft Handling ist eine Funktion im SAP Restful ABAP Programming Model (RAP), die es Nutzern ermöglicht, Änderungen an Daten zwischenzuspeichern, ohne sie sofort zu speichern oder endgültig zu übernehmen.
  • Ziel:
    • Benutzerfreundlichkeit verbessern, indem unvollständige oder fehlerhafte Eingaben zwischengespeichert werden.
    • Vermeidung von inkonsistenten Datenständen.
  • Draft-Objekt:
    • Eine temporäre Kopie des Hauptobjekts (Business Object), die Änderungen speichert, bevor sie übernommen werden.
  • Automatische Sperrmechanismen:
    • Drafts sind benutzergebunden und verhindern derzeit noch parallele Bearbeitungen (Stand: Nov 2024 wer weiß :-)
  • Trennung von Draft- und Persistenzlogik:
    • Änderungen am Draft beeinträchtigen das Hauptobjekt nicht.
(C) Brandeis Consulting📁

Draft 2

  1. Erstellung eines Drafts:

    • Änderungen werden in einem separaten Draft-Datensatz gespeichert.

  2. Weiterbearbeitung:

    • Der Benutzer kann den Draft zu einem späteren Zeitpunkt öffnen und bearbeiten.

  3. Finalisierung:

    • Der Draft wird entweder:
      • Persistiert (Änderungen übernommen).
      • Verworfen (Änderungen gelöscht).
(C) Brandeis Consulting📁