Show TOC Anfang des Inhaltsbereichs

Prozessdokumentation Fehler melden und behandeln  Dokument im Navigationsbaum lokalisieren

Einsatzmöglichkeiten

Die Möglichkeiten zur Fehlerbehandlung hängen von der gewählten Kommunikationsart ab:

·        Bei asynchroner Kommunikation kann die Anwendung auf Sender-Seite nur Fehler behandeln, die beim Versenden der Message auftreten können (Beispiel: Ausgangsqueue ist voll). Diese Fehler können Sie über die Ausnahmeklasse CX_AI_SYSTEM_FAULTabfangen und persistieren. Für die Empfänger-Seite können Sie wie im synchronen Fall Fault Messages definieren, die dann aber nur an das Monitoring (nicht an den Sender) weitergegeben werden.
Lesen Sie auch den Abschnitt Acknowledgments, wenn von Seiten des Senders auf asynchrone Fehler reagiert werden soll. Die Web-Service-Laufzeit unterstützt nur synchrone Kommunikation.

·        Bei synchroner Kommunikation können Sie mit Hilfe von Fault-Messages Fehler behandeln, die auf Empfänger-Seite aufgetreten sind. Um einen Fehler zurückzumelden, schickt die Proxy-Laufzeit die Fault-Message vom Empfänger zum Sender zurück, der darauf reagieren kann.

Ablauf

Das hier dargestellte Beispiel arbeitet mit der standardisierten Struktur der XI-Laufzeit. Um auf Empfängerseite eine Ausnahme auszulösen und auf Senderseite zu behandeln (im Quelltext über die Kommentare mit dem Doppelkreuz (#) gekennzeichnet), gehen Sie bei Verwendung der Web-Service-Laufzeit gleich vor. Die Struktur der Fault-Message ist in beiden Fällen durch die WSDL-Beschreibung vorgegeben und der Exception-Klasse zu entnehmen.

Beispiel einer Fehlerbehandlung

Aufruf beim Sender und Fehlerbehandlung

Aufgerufener Service beim Empfänger

DATA:

 lo_mes TYPE REF TO
     
[Client-Proxy-Klasse],

 l_sys_exc TYPE REF TO
        cx_ai_system_fault,
 l_app_exc TYPE REF TO
        cx_ai_application_fault.

CREATE OBJECT lo_mes.

TRY.

 CALL METHOD
  lo_mes->EXECUTE_SYNCHRONOUS
    EXPORTING
      OUTPUT    = ls_request
    IMPORTING
      INPUT     = ls_response.

[...]

CATCH cx_ai_system_fault
            INTO l_sys_exc.

* handle system error
    EXIT.

CATCH cx_fault_1
            INTO l_app_exc.

* handle application error 1

[...]

* ############################

CATCH cx_fault_n
            INTO l_app_exc.

* ############################

* handle application error n

CATCH cx_ai_application_fault
            INTO l_app_exc.

* handle other
* application errors

ENDTRY.

METHOD EXECUTE_SYNCHRONOUS.

 DATA:

   l_standard_data
       TYPE
[StandardFaultDataType],
   l_detail_data TYPE
[DetailType],
   l_additional_data_1
       TYPE
[AdditionalFaultData_1], 

[...]

   l_additional_data_n
       TYPE
[AdditionalFaultData_n].

[...]

 IF [Fehlerbedingung n].

  l_standard_data-fault_text = ...
  l_standard_data-fault_url = ...
  l_detail_data-severity =  ...
  l_detail_data-text     =  ...
  l_detail_data-id       =  ...
  l_detail_data-url      =  ...

  APPEND l_detail_data 
    TO l_standard_data-fault_detail.

  l_additional_data_n    =  ...

* ####################################

  RAISE EXCEPTION TYPE CX_FAULT_N
    EXPORTING
      standard = l_standard_data
      addition = l_additional_data_n.

* ####################################

 ENDIF.
ENDMETHOD.

 

...

       1.      Löst eine Anwendung auf der Empfänger-Seite einen Fehler aus, wandelt die ABAP-Proxy-Laufzeit die zugehörige Ausnahmeklasse in eine Fault-Message um und überträgt sie zum Sender-System.

       2.      Im Sender-System interpretiert die ABAP-Proxy-Laufzeit die Fault-Message und löst die Ausnahme zum Client-Proxy aus.

       3.      Im Sender-System kann die Anwendung die Ausnahme über einen Try/Catch-Block abfangen und behandeln. Mit Hilfe der Super-Ausnahmeklasse CX_AI_APPLICATION_FAULT können Sie - ähnlich wie mit der Anweisung WHEN OTHERS in einer CASE-Anweisung - alle übrigen Anwendungsfehler abfangen.

 

 

 

Ende des Inhaltsbereichs