SAP EML (Entity Manipulation Language)

Einführung

SAP Entity Manipulation Language (EML) ist eine ABAP-Sprache, die verwendet wird, um das Verhalten von Business-Objekten im Kontext des RESTful Application Programming-Modells (auch bekannt als SAP-ABAP-RAP). Die mit dem SAP-ABAP-RAP-Modell entwickelten Business-Objekte können nicht nur vom OData-Protokoll (Web API, Fiori UI) sondern auch in ABAP über EML-Anweisungen konsumiert werden.

Es gibt zwei Varianten von EML:

  • Standard-API: Verwendet die Signatur von Geschäftsobjektentitäten
  • Generische API: Wird für den dynamischen Verbrauch des Geschäftsobjekts verwendet

Die Generic API dient der dynamischen Integration von Business-Objekten in andere Frameworks, wie zum Beispiel das Cloud Data Migration Cockpit. Generische API ist nicht in unserem Geltungsbereich. Wir werden uns auf Standard-APIs konzentrieren.

Die Standard-APIs werden verwendet, wenn das Zielgeschäftsobjekt statisch angegeben wird. Es bietet READ- und MODIFY-Anweisungen für den Zugriff auf transaktionale Szenarien von Objekten und COMMIT-Zugriffe zum Auslösen der Sicherungssequenz. Mit diesen Syntaxen können wir das Transaktionsverhalten ( Create, Update, Delete, Actions, Read ) von Geschäftsobjekten ausführen, die in der Verhaltensdefinition definiert sind.

SAP EML-Szenarien

Die folgende Tabelle gibt Ihnen einen Überblick über verschiedene SAP-EML-Szenarien:

SzenarioProduktbeschreibungRelevante EML-Anweisungen
Entwickeln (BO mit IN LOCAL MODE innerhalb seines eigenen Verhaltenspools)Wenn Sie im EML-Entwicklungsszenario die Funktionalität für Ihr eigenes BO in einem eigenen Verhaltenspool bereitstellen, verwenden Sie IN LOCAL MODE. Es umgeht die Zugriffs-, Berechtigungs- und Funktionsinstanzkontrolle. Sie können es mit CRUD und Aktionen verwenden.· LESEN/LESEN von VERBINDUNG

· ERSTELLEN/DURCH VERBINDUNG ERSTELLEN

· AKTUALISIEREN/AKTUALISIEREN NACH VERBINDUNG

· LÖSCHEN/LÖSCHEN NACH VERBINDUNG

· AUSFÜHREN

· AUGMENTIERUNG DURCH VERBINDUNG

Konsumieren (BO aus anderem Verhaltenspool/freigegebene Objekte)Im Konsumszenario können Sie EML verwenden, um andere BOs in oder freigegebenen BOs zu konsumieren. Hier dürfen Sie nicht IM LOKALEN MODUS verwenden.· LESEN/LESEN von VERBINDUNG

· ERSTELLEN/DURCH VERBINDUNG ERSTELLEN

· AKTUALISIEREN/AKTUALISIEREN NACH VERBINDUNG

· LÖSCHEN/LÖSCHEN NACH VERBINDUNG

· AUSFÜHREN

· ERLAUBNIS BEKOMMEN

· SPERRE EINSTELLEN

TestUm das BO außerhalb des ABAP-Verhaltenspools zu testen, können Sie EML-Anweisungen verwenden. Hier ist es zwingend erforderlich, die COMMIT-Anweisung zum Beenden der RAP-LUW hinzuzufügen. Wenn die Implementierung innerhalb des Verhaltenspools erfolgt, wird das Speichern vom Framework durchgeführt und wir müssen dort kein explizites COMMIT schreiben.· LESEN/LESEN von VERBINDUNG

· ERSTELLEN/DURCH VERBINDUNG ERSTELLEN

· AKTUALISIEREN/AKTUALISIEREN NACH VERBINDUNG

· LÖSCHEN/LÖSCHEN NACH VERBINDUNG

· AUSFÜHREN

· ERLAUBNIS BEKOMMEN

· SPERRE EINSTELLEN

· GESELLSCHAFTEN ENGAGIEREN

· ROLLBACK-ENTITIES

 

SAP EML-Syntax

Die SAP EML-Syntax besteht aus drei Hauptabschnitten:

  • LESEN
  • ÄNDERN
  • VERPFLICHTEN

 

READ-Syntax

READ wird verwendet, um die Daten abzurufen, oder Sie können sagen, die Daten der Entität lesen. Die Syntax unterstützt:

  • Lesen: Lesen Sie die Entität
  • Nach Zuordnung lesen: Untergeordnete Entität mit übergeordnetem Schlüssel lesen

 

Kurze Syntax –

READ ENTITY EntityName [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance RESULT et_result BY \association_name [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_rba ERGEBNIS et_result_rba LINK et_link_rba [FAILED ct_failed]. wobei EntityName: gibt die CDS-View-Entität an FIELDS: gibt das direkte Lesen für die angegebenen Felder an die Antwort zum fehlgeschlagenen Abrufen (Schlüsselwert, Fehlerursache usw.)

Lange Syntax-

READ ENTITIES OF RootEntityName ENTITY Entity_1 " Entity-Aliasname [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_1 RESULT it_result BY \association1_name [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_rba RESULT et_LINK .ult_ et_link_rba ENTITY Entity_2_name " Entity-Aliasname [FIELDS ( ...... ENTITY Entity_3_name " Entity-Aliasname ... [FAILED ct_failed].

Die lange Syntax ermöglicht es Ihnen, den READ-Vorgang mehrerer Entitäten von Business Objects, die durch den RootEntity-Namen angegeben sind, auf einmal zu vereinen. Außerdem können wir Aliasnamen von Entitäten verwenden, die in der Verhaltensdefinition definiert sind.

Beispiel:

LESEN SIE ENTITIES OF /dmo/i_travel_m ENTITY travel FIELDS ( travel_id agency_id customer_id booking_fee total_price Currency_code ) MIT ENTSPRECHENDEN #( keys ) ERGEBNISDATEN(ct_read_result) FAILED DATA(ct_failed) REPORTED DATA(ct_reported).

MODIFY-Syntax

Die MODIFY-Anweisung wird verwendet, wenn wir die Änderung von Daten in Entitäten durchführen möchten. Es enthält:

  • Erstellen
  • Von Assoziation erstellen
  • Aktualisieren
  • Löschen
  • Ausführen (für Aktion)

Kurze Syntax-

MODIFY ENTITY EntityName CREATE [FIELDS ( field1 field2 ... ) WITH] | [FROM] it instance_crt CREATE BY \association_name [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_cba UPDATE [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance_upd DELETE FROM it_instance_del EXECUTE action_name FROM it_instance_act [RESULT et_result_a] [FAILED ct_failed] [MAPPED ct_mapped] [REPORTED ct_reported].

Lange Syntax-

MODIFY ENTITIES OF RootEntityName ENTITY Entity1_name CREATE [FIELDS ( field1 field2 ... ) WITH] | [FROM] it_instance1_crt CREATE BY \association_name [FIELDS ( field1 field2 ... ) WITH] | [FROM] itinstance1_cba UPDATE [FIELDS ( field1 field2 ... ) WITH] | [FROM] itinstance1_u DELETE FROM it_instance1_del EXECUTE action FROM it_instance1_act [RESULT et_result] ENTITY Entity2_name CREATE FROM it_instance2_crt ... ENTITY Entity3_name ... [FAILED ct_failed] [MAPPED [REed_mapped] [MAPPED [REed_mapped]

Die lange Syntax ermöglicht das Zusammenfassen mehrerer MODIFY-Operationen von Entitäten, die durch RootEntity des Geschäftsobjekts angegeben werden. Wir können Aliasnamen für Entitäten angeben, wenn sie in der Verhaltensdefinition definiert sind.

Beispiel

MODIFY ENTITIES OF /dmo/i_travel_m ENTITY travel CREATE FIELDS ( travel_id agency_id customer_id begin_date end_date booking_fee total_price Currency_code Beschreibung total_status ) WITH lt_create MAPPED ct_mapped FAILED ct_failed REPORTED ct_reported.

 

COMMIT-Syntax

Die COMMIT-Syntax wird zusammen mit der MODIFY-Anweisung verwendet. Da die MODIFY-Anweisung die Daten auf Datenbankebene nicht ändert, ist es erforderlich, nach MODIFY COMMIT aufzurufen, um die Datenbankänderungen zu persistieren.

Die Modify-Anweisung setzt die Daten in den Transaktionspuffer, und die Pufferdaten werden gelöscht, nachdem die ABAP-Sitzung geschlossen wurde. Das bedeutet, dass wir eine Sicherungssequenz auslösen müssen, um die Daten aus dem Transaktionspuffer in der Datenbank zu speichern. Dieser Trigger wird durch Ausführen der COMMIT-Anweisung aufgerufen. Für Speichersequenzmethoden können Sie sich auf unsere vorherigen Artikel beziehen.

 

Einfache Syntax-

GESELLSCHAFTEN.

 

Lange Syntax-

COMMIT ENTITIES [ANTWORT VON rootentityname1 [FAILED ct_failed] [REPORTED ct_reported]] [ANTWORT VON rootentityname2 [FAILED ct_failed] [REPORTED ct_reported]].

Mit der langen Syntax können wir COMMIT für mehrere Entitäten aufrufen, indem wir explizit RootEntity-Namen angeben. Während die einfache Syntax COMMIT ENTITIES auch für mehrere Entitäten im selben funktioniert LUW. Hier müssen wir den RootEntity-Namen angeben.

Hinterlassen Sie eine Nachricht

Diese Seite verwendet Akismet, um Spam zu reduzieren. Erfahren Sie, wie Ihre Kommentardaten verarbeitet werden.