Ansicht
Dokumentation
ABENHANDLER_METHOD_MODIFY - HANDLER METHOD MODIFY
ABAP Short Reference Fill RESBD Structure from EBP Component StructureDiese Dokumentation steht unter dem Copyright der SAP AG.
FOR MODIFY
METHODS method_name FOR MODIFY
$[IMPORTING$]
create_import_parameter FOR CREATE entity_name
create_import_parameter FOR CREATE entity_name\association
update_import_parameter FOR UPDATE entity_name
delete_import_parameter FOR DELETE entity_name
action_import_parameter FOR ACTION entity_name~action
[RESULT action_export_parameter]
...
$[CHANGING failed TYPE DATA
mapped TYPE DATA
reported TYPE DATA$].
Wirkung
Die Methode MODIFY implementiert den Behandler zur Bearbeitung Änderungsvorgänge an den Entitäten im Kontext von ABAP RAP. Die Methode wird aufgerufen, wenn die Anwendung eine Änderungsanforderung bearbeitet, die mindestens eine in der Verhaltensdefinition angegebene Änderungsoperation (CREATE, UPDATE, DELETE, ACTION), enthält. Welche Operationen konkret gegeben sind, kann mit dem Befehl ... parameter IS [NOT] INITIAL ermitteln werden.
Ähnlich wie Methode READ ist die Methode MODIFY maßen- und bündelungsfähig (handelt Massenanforderungen und implementiert mehrere Operationen). Das Mehrfachvorkommen einer Operation in einer MODIFY-Methode ist jedoch verboten.
Es gibt keine Regeln für die Verarbeitungsreihenfolge einzelner Operationen innerhalb einer MODIFY-Methode. Die Anwendung arbeitet alle übergebenen Einzeloperationen in einer für sie sinnvollen Reihenfolge ab, zum Beispiel create-Operationen vor update-Operationen.
Der Methodenname method_name ist frei wählbar. Mit dieser Verallgemeinerung ist es möglich mehrere MODIFY-Methoden in einer Behandlerklasse unterzubringen. Dadurch kann zum Beispiel jede Aktion als eine Methode an derselben Behandlerklasse definiert werden. Dies ermöglicht die Verhaltensimplementierung eines Business-Objekts, ohne entsprechend viele Behandlerklassen einzuführen.
entity_name bezieht sich auf den Namen der Entität oder auf den Alias, sofern dieser in der Verhaltensdefinition definiert ist.
Eingabeparameter
Der Name des Eingabeparameters (zum Beispiel create_import_parameter) kann frei gewählt werden.
Der Zeilentyp der Eingabeparameter für entsprechende Operationen enthält (die zugehörigen Parameter sind mit "x" gezeichnet):
| Operation | ID | %CID | %CID_REF | %KEY | %PID | %CONTROL | %DATA | %PARAM |
| CREATE | - | x | - | - | - | x | - | - |
| UPDATE | - | - | x | x | x | x | x | - |
| DELETE | x | - | x | - | x | - | - | - |
| ACTION | x | - | x | - | x | - | - | x |
Ausgabeparameter
Der Name des Ausgabeparameters (zum Beispiel action_export_parameter) kann frei gewählt werden.
Für eine Aktion mit dem Zusatz RESULT ist ein benannter Ausgabeparameter zu befüllen. Andere Operationen haben nicht unbedingt sichtbare Ergebnisse. Wenn ja, dann werden die Ergebnisse in drei Rückmeldungsstrukturen failed, mapped und reported für Fehler, Mapping bzw. Meldungen implizit geschrieben. Sie können jedoch in der Methodensignatur mithilfe des generischen Typs DATA explizit als CHANGING-Parameter deklariert werden:
-
CHANGING failed TYPE DATA
mapped TYPE DATA
reported TYPE DATA
Die Parameter failed, mapped und reported haben keine festen Datentypen und werden stattdessen mit den von der Verhaltensdefinition abgeleiteten Typen zugewiesen.
Bemerkungen
- Die alte Syntax METHODS modify FOR BEHAVIOR ... ist auch gültig, wird aber nicht empfohlen.
- Das Schlüsselwort IMPORTING in der Syntax der Methode method_name ist nicht obligatorisch und kann vor dem Eingabeparameter angegeben werden.
- Die Parameter können auch explizit als REFERENCE (...) deklariert werden.
- Die Deklaration als VALUE (...) ist nicht erlaubt. Daher können die Eingabeparameter in einer MODIFY-Methode nicht geändert werden.
Beispiel
Im folgenden Beispiel werden die Daten aus dem ABAP-Flugdatenreferenzszenario (kurz: Flugdatenszenario) verwendet. Es stellt eine Legacy-Business-Logik dar, mit der Flugbuchungen erstellt und aktualisiert werden können. Die Wurzel-Entität Travel repräsentiert das Business-Objekt zur Verwaltung von Flugreisen. Das zugrundeliegende Datenmodell und das Verhalten der Wurzel-Entität Travel sind im Abschnitt CDS BDL - Beispiel beschrieben.
Das folgende Beispiel zeigt die Definitionen und die Implementierungen
- der Standardoperationen create, update und delete (zum Erstellen, Aktualisieren und Löschen der Instanzen der Entität Travel),
- der anwendungsspezifischen Aktion set_status_booked (zum Setzen des Reisestatus auf gebucht).
Im Beispiel sind die Operationen und die Aktion jeweils in den Methoden modify_create, modify_update, modify_delete und set_status implementiert. Die Grundstruktur der Implementierung der Methoden ist ähnlich. Zum Beispiel, die Implementierung der Methode modify_create umfasst
- eine Schleife für alle neu zu erstellenden Instanzen der Entität Travel,
- Aufruf des Funktionsbausteins der Legacy-Business-Logik /DMO/FLIGHT_TRAVEL_CREATE zum Anlegen neuer Travel-Instanzen,
- Meldungsbehandlung für die Verarbeitung von instanzspezifischen Meldungen im Fehlerfall (msgty = 'E' für einen Fehler, msgty = 'A' für einen Abbruch).
Der zweite Schritt kann fehlgeschlagene Schlüssel (ls_travel_create-%cid) und Meldungen (lt_messages) erzeugen. Fehlgeschlagene Schlüssel werden in der Tabelle failed gespeichert, während alle instanzspezifischen Meldungen in der Tabelle reported gespeichert werden. Im Erfolgsfall (lt_messages IS INITIAL) werden die Inhalts-ID (%CID) und der neue Schlüssel travel_id in die Tabelle mapped geschrieben.
Zur besseren Lesbarkeit sind die Methoden zur Behandlung der Meldungen in der separaten Klasse zcl_messages implementiert. Die Klasse zcl_messages ist im Abschnitt Beispiel - Behandlung der Meldungen beschrieben.
-
CLASS lcl_travel_handler DEFINITION
INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
METHODS modify_create FOR MODIFY
IMPORTING
it_travel_create FOR CREATE travel.
METHODS modify_update FOR MODIFY
IMPORTING
it_travel_update FOR UPDATE travel.
METHODS modify_delete FOR MODIFY
IMPORTING
it_travel_delete FOR DELETE travel.
METHODS set_status FOR MODIFY
IMPORTING
it_travel_set_status_booked
FOR ACTION travel~set_status_booked
RESULT
et_travel_set_status_booked.
ENDCLASS.
-
CLASS lcl_travel_handler IMPLEMENTATION.
METHOD modify_create.
DATA ls_travel_out TYPE /dmo/travel.
DATA lt_messages TYPE /dmo/if_flight_legacy=>tt_message.
LOOP AT it_travel_create INTO DATA(ls_travel_create).
CALL FUNCTION '/DMO/FLIGHT_TRAVEL_CREATE'
EXPORTING
is_travel = CORRESPONDING
/dmo/if_flight_legacy=>ts_travel_in( ls_travel_create )
IMPORTING
es_travel = ls_travel_out
et_messages = lt_messages.
IF lt_messages IS NOT INITIAL.
zcl_messages=>handle_messages(
EXPORTING
iv_cid = ls_travel_create-%cid
it_messages = lt_messages
CHANGING
failed = failed-travel
reported = reported-travel ).
CONTINUE.
ENDIF.
INSERT VALUE #( %cid = ls_travel_create-%cid
travel_id = ls_travel_out-travel_id )
INTO TABLE mapped-travel.
ENDLOOP.
ENDMETHOD.
METHOD modify_update.
DATA ls_travel_out TYPE /dmo/travel.
DATA lt_messages TYPE /dmo/if_flight_legacy=>tt_message.
LOOP AT it_travel_update INTO DATA(ls_travel_update).
ls_travel_update-travel_id = COND #(
WHEN ls_travel_update-travel_id IS INITIAL
OR ls_travel_update-travel_id = ''
THEN mapped-travel[ %cid = ls_travel_update-%cid_ref ]-travel_id
ELSE ls_travel_update-travel_id ).
DATA(ls_travelx) = zcl_messages=>map_travel_control(
is_travel = ls_travel_update ).
CALL FUNCTION '/DMO/FLIGHT_TRAVEL_UPDATE'
EXPORTING
is_travel = CORRESPONDING
/dmo/if_flight_legacy=>ts_travel_in( ls_travel_update )
is_travelx = ls_travelx
IMPORTING
et_messages = lt_messages.
LOOP AT lt_messages INTO DATA(ls_message)
WHERE msgty = 'E' OR msgty = 'A'.
zcl_messages=>handle_messages(
EXPORTING
iv_cid = ls_travel_update-%cid_ref
iv_travel_id = ls_travel_update-travel_id
it_messages = lt_messages
CHANGING
failed = failed-travel
reported = reported-travel ).
ENDLOOP.
ENDLOOP.
ENDMETHOD.
METHOD modify_delete.
DATA: lt_messages TYPE /dmo/if_flight_legacy=>tt_message,
ls_travel_out TYPE /dmo/travel.
LOOP AT it_travel_delete INTO DATA(ls_travel_delete).
ls_travel_delete-travel_id = COND #(
WHEN ls_travel_delete-travel_id IS INITIAL
OR ls_travel_delete-travel_id = ''
THEN mapped-travel[ %cid = ls_travel_delete-%cid_ref ]-travel_id
ELSE ls_travel_delete-travel_id ).
CALL FUNCTION '/DMO/FLIGHT_TRAVEL_DELETE'
EXPORTING
iv_travel_id = ls_travel_delete-travel_id
IMPORTING
et_messages = lt_messages.
zcl_messages=>handle_messages(
EXPORTING
iv_cid = ls_travel_delete-%cid_ref
iv_travel_id = ls_travel_delete-travel_id
it_messages = lt_messages
CHANGING
failed = failed-travel
reported = reported-travel ).
ENDLOOP.
ENDMETHOD.
METHOD set_status.
DATA lt_messages TYPE /dmo/if_flight_legacy=>tt_message.
CLEAR et_travel_set_status_booked.
LOOP AT it_travel_set_status_booked
ASSIGNING FIELD-SYMBOL(fs_travel_set_status_booked>).
DATA(lv_travel_id) =
fs_travel_set_status_booked>-travel_id.
IF lv_travel_id IS INITIAL OR lv_travel_id = ''.
lv_travel_id = mapped-travel[
%cid = fs_travel_set_status_booked>-%cid_ref
]-travel_id.
ENDIF.
CALL FUNCTION '/DMO/FLIGHT_TRAVEL_SET_BOOKING'
EXPORTING
iv_travel_id = lv_travel_id
IMPORTING
et_messages = lt_messages.
zcl_messages=>handle_messages(
EXPORTING
iv_cid = fs_travel_set_status_booked>-%cid_ref
iv_travel_id = lv_travel_id
it_messages = lt_messages
CHANGING
failed = failed-travel
reported = reported-travel ).
ENDLOOP.
ENDMETHOD.
ENDCLASS.
Vendor Master (General Section) General Data in Customer Master
Diese Dokumentation steht unter dem Copyright der SAP AG.
Length: 25153 Date: 20240523 Time: 181401 sap01-206 ( 169 ms )
