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

Unmanaged - Die zu implementierenden Methoden

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.

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.

Integration: SAP LUW und RAP

• RAP orientiert sich am klassischen SAP LUW, automatisiert jedoch viele Schritte:
  • Verteilte Steuerung: SAP LUW bleibt bestehen, aber RAP übernimmt die Transaktionslogik.
  • Consistency: RAP validiert und speichert Daten gemäß den SAP LUW-Prinzipien.
  • Flexibilität: Entwickler definieren Verhalten in der Behavior Implementation (z. B. Validierungen, Autorisierungen).

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.

Service Definition und Service Binding sind nicht Bestandteil des Business Objects

Business Object mit einer Entität

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;
  }
}

Schlüssel in einem BO

Es gibt zwei Optionen: Semantic Key oder GUID/UUID

Semantic Key

Der Semantic Key muss selber vergeben werden. Es besteht die Gefahr von Kollisionen mit bestehenden Datenbankeinträgen.

GUIDs

Die GUIDs sind global eindeutig. Darum eignen sie sich sehr gut als Schlüssel. Und vor allem für eine automatische Schlüsselvergabe. Versehentliche Kollisionen sind quasi ausgeschlossen. Aber für die Lesbarkeit ist es eine Katastrophe.

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

Sperren

Im RAP gibt es die folgenden Konzepte gegen gleichzeitige Bearbeitung.

Sperren beim Draft Handling

Bei Draft Handling wird die Entwurfsversion zusammen mit Zeitstempel und Bearbeiter in der Draft-Tabelle abgespeichert. Dieser Tabelleneintrag wirkt wie eine exklusive Sperre für Fiori Anwendungen. Allerdings verfällt die Sperre nach einer gewissen Zeit. Danach greift aber ggf. noch die optimistische Sperre, um Lost-Update-Situationen zu vermeiden.

Automatische Nummernvergabe

Falls als Primärschlüssel UUIDs verwendet werden, kann die Nummernvergabe vollautomatisch (managed) erfolgen. Es muss nichts implementiert werden.

Die folgenden Dinge müssen in der Verhaltensdefinition festgelegt sein:

Im Kopf der Verhaltensdefinition

define behavior for <My_CDS_View>
early numbering
...
{
    field ( numbering : managed ) <Feldname>;
}