RAP - Unmanaged Szenario

Inhaltsverzeichnis

• Einleitung
• Funktionsweise
• Unterschiede
• Beispiel
• Fazit

In diesem Artikel werden wir uns einmal die Theorie zum unmanaged Szenario anschauen und in den beiden Folgeartikeln auf Beispiele eingehen, wie dieser mit lokalen APIs und im Remote Ansatz funktionieren kann. Dazu aber erst einmal etwas Theorie, wie das Szenario funktioniert.

 

Einleitung

Alles, was du bisher auf unserem Blog gelernt hast, beschreibt vor allem die Umsetzung im Managed Ansatz. Dabei übernimmt das RAP Framework die gesamte Arbeit der Datenverwaltung. Die Bereitstellung der Daten, die Aktualisierung, das Löschen, die Nummernvergabe, Draft-Handling und das Speichern wird vom Framework übernommen und muss nicht entwickelt werden. Möchtest du ein Objekt "Unmanaged" entwickeln, dann entscheidest du dich dafür, alles selbst zu entwickeln.

Dies ist für bestimmte Prozesse auch sehr sinnvoll, vor allem wenn es um Migration von bestehendem Coding und Funktionen ist. Alles war nach dem MVC (Model View Control) bereits sauber in ABAP entwickelt wurde, lässt sich zum Großteil wiederverwenden und einem unmanaged RAP Objekt wiederverwenden, um so Zeit und Kosten zu sparen.

 

Funktionsweise

Schauen wir uns einmal die verschiedenen Schritte an, bevor die Daten aus dem Frontend überhaupt auf der Datenbank landen. Dazu gibt es eine Übersicht von SAP, die wir dir hier im Detail noch einmal erklären. Bei RAP handelt es sich um eine "Stateless" Anwendung, jeder Zugriff auf das Backend erfolgt ohne eine offene Session, der User wird angemeldet, führt seine Aktion aus, erhält das Ergebnis und die Session wird im Backend wieder beendet. Die Kommunikation übernimmt der Browser, der immer dann eine Session Richtung Backend öffnet, wenn es zu Aktionen oder Datenabfragen kommt.

 

 

Insgesamt unterscheidet man in zwei Phasen:

• Interaktionsphase - In dieser Phase bedient der Anwender die Fiori Applikation, liest die Daten, filtert diese und fängt sie an zu verändern. Diese Änderungen werden im Transaktionalen Puffer gehalten, eine Art Zwischenspeicher im SAP-System. Die Änderungen befinden sich aber noch nicht auf der Datenbank.
• Speichersequenz - Der User klickt in der Anwendung auf Speichern, die Speichersequenz wird durchlaufen und die Daten aus dem Transaktionalen Puffer werden auf die Datenbank übernommen. Dabei werden Schlüssel vergeben, die Daten geprüft und zum Abschluss persistiert.

 

Unterschiede

Im Managed RAP Objekt übernimmt die beiden Phasen das RAP Framework und wir als Entwickler müssen nichts dazu entwickeln. Das spart eine Menge Zeit, Aufwand und Quellcode. Beim Unmanaged Ansatz übernehmen wir alles, was auf dem Schaubild zu sehen ist. Wir kümmern uns um die einzelnen Aktionen, den Transaktionalen Puffer und die Speichersequenz, um die Daten schließlich auf der Datenbank zu persistieren.

Der Vollständigkeit halber muss man aber noch sagen, dass es für das Managed RAP Objekt auch die Möglichkeit gibt, die Speichersequenz selbst zu implementieren, dies heißt dann "Unmanaged Save". Diese Methodik würden wir uns aber in einem späteren Artikel anschauen.

 

Beispiel

Wie sehen also nun die Unterschiede bei der Implementierung aus? Die Erstellung des Modells und der CDS Views muss erst einmal nicht abweichen, die erste große Änderung geschieht bei der Anlage der Verhaltensdefinition:

 

Der Implementation Type wird auf Unmanaged gesetzt, entsprechend sieht dann auch die Definition aus, auf Zeile 1 erkennt man den Typ der Definition:

 

Es wird auch die entsprechende Verhaltensimplementierung angelegt, diese ist allerdings leer und muss durch uns erst noch entwickelt werden:

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

    METHODS create FOR MODIFY
      IMPORTING entities FOR CREATE Unmanaged.

    METHODS update FOR MODIFY
      IMPORTING entities FOR UPDATE Unmanaged.

    METHODS delete FOR MODIFY
      IMPORTING keys FOR DELETE Unmanaged.

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

    METHODS lock FOR LOCK
      IMPORTING keys FOR LOCK Unmanaged.

ENDCLASS.


CLASS lhc_Unmanaged IMPLEMENTATION.
  METHOD get_instance_authorizations.
  ENDMETHOD.


  METHOD create.
  ENDMETHOD.


  METHOD update.
  ENDMETHOD.


  METHOD delete.
  ENDMETHOD.


  METHOD read.
  ENDMETHOD.


  METHOD lock.
  ENDMETHOD.
ENDCLASS.


CLASS lsc_ZBS_R_DMOUNMANAGED 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.


CLASS lsc_ZBS_R_DMOUNMANAGED IMPLEMENTATION.
  METHOD finalize.
  ENDMETHOD.


  METHOD check_before_save.
  ENDMETHOD.


  METHOD save.
  ENDMETHOD.


  METHOD cleanup.
  ENDMETHOD.


  METHOD cleanup_finalize.
  ENDMETHOD.
ENDCLASS.

 

Es werden zwei lokale Klassen implementiert, die von entsprechenden Standardklassen erben:

• CL_ABAP_BEHAVIOR_HANDLER - Entspricht der Implementierung für die Interaktionsphase.
• CL_ABAP_BEHAVIOR_SAVER - Definiert die Implementierung der Speichersequenz, die passenden Methoden stehen zur Verfügung.

 

Fazit

Anhand der heutigen Theorie sollte dir die Implementierung nächste Woche recht einfach fallen. Unmanaged bedeutet im Endeffekt mehr Implementierungsaufwand für dich, aber auch mehr Freiheiten bei der Gestaltung des Objekts und beim Aufbau der API. Grundsätzlich werden damit die Szenarien für Brownfield (bestehende Anwendung) und Remote-Szenarien abgebildet.