Forward Error Handling

Verwendung

Forward Error Handling (FEH) ist eine Funktionalität, die von der ABAP-Laufzeit bereitgestellt wird. Sie kann bei der Implementierung von Service-Providern genutzt werden. FEH erlaubt die Verarbeitung von Fehlern, die auf der Provider-Seite bei der Ausführung einer asynchronen Service-Kommunikation festgestellt werden.

Asynchrone Kommunikation impliziert, dass der Empfänger eines Service-Requests einen Service-Aufruf empfangen und Fehler feststellen kann, die verarbeitet werden, sobald die Session der sendenden Anwendung beendet ist. Anders als bei der synchronen Kommunikation steht bei der asynchronen Kommunikation bei der sofortigen Rückgabe der Fehler durch den Empfänger weder die Session der sendenden Anwendung noch der Benutzer der Consumer-Anwendung für die rechtzeitige Behebung der Fehler zur Verfügung. Dies ist offensichtlich, wenn der Service sowieso uni-direktional ist, da keine „Zurückweisungsnachricht“ in der Interaktion zwischen Consumer und Provider vorgesehen ist - wie bei Inbound-Notification- und Information-Services. Dies gilt auch für Services, die den Transaktionsmustern Request-Confirmation und Query-Response folgen.

Sie können asynchrone Inbound-Service-Operationen so entwickeln, dass Forward Error Handling unterstützt wird. Dann verhält sich das System wie folgt, wenn während der Ausführung eines Service-Aufrufs ein Fehler festgestellt wird:

Die Zurückweisung erfolgt nicht sofort, damit der angeforderte Service ausgeführt werden kann.
Es wird nicht sofort eine „Zurückweisungsnachricht“ mit Fehlerinformationen an den Service-Consumer zurückgeschickt.

Stattdessen nutzt das System das FEH-Framework und versucht, das Problem auf der Provider-Seite zu lösen. Wenn z.B. davon ausgegangen wird, dass es sich um ein temporäres Problem handelt, kann das System versuchen, den Service-Aufruf nach einer bestimmten Zeitspanne erneut auszuführen. Es kann jedoch auch notwendig sein, einen Business User zur Lösung des Problems hinzuzuziehen.

Fehler treten in der Regel bei der Datenkonvertierung oder der Geschäftslogikverarbeitung auf. Stellt der Administrator oder ein Business User fest, dass das System versucht, die Fehler auf der Provider-Seite zu behandeln, können die Fehlermeldungen zur Problemlösung analysiert werden. Die Art der Problemlösung hängt vom Fehlertyp ab. Ein Fehler kann automatisch oder manuell gelöst werden oder zurückgewiesen und zurück an den Consumer delegiert werden.

Voraussetzungen

Zusätzlich zur generierten Proxy-Klasse benötigen Sie eine Klasse für die Service-Implementierung. Weitere Informationen finden Sie unter Point-to-Point-Kommunikation für asynchrone Services.

Vorgehensweise

Implementierungsübersicht

Alle Zugriffe auf Web-Services und XI-Laufzeitinformationen müssen in der Proxy-Klasse implementiert werden:

Deaktiveren Sie das erweiterte XML-Handling.
Anweisung Set update task local.

Die Proxy-Klasse ruft die Methode EXECUTE Ihrer Service-Implementierungsklasse auf.

Führen Sie innerhalb der Service-Implementierungsklasse Folgendes aus:

Rufen Sie das Mapping von der Eingangs-Message-Proxy-Struktur zur Geschäftslogik-API auf.
Sammeln Sie beim Auftreten von Fehlern die Daten für das Forward Error Handling bzw. initialisieren Sie das FEH-Framework, falls noch nicht geschehen.
Rufen Sie die Gechäftslogik-API auf.
Sammeln Sie beim Auftreten von Fehlern während der Geschäftslogikausführung die Daten für das Forward Error Handling bzw. initialisieren Sie das FEH-Framework, falls noch nicht geschehen.
Wenn bei der Service-Ausführung ein Fehler aufgetreten ist, z.B. im Mapping oder der Geschäftslogik, lösen Sie die Ausnahme aus, die Ihrer Fault-Message entspricht.

Implementierungsschritte für die Service-Klasse

Legen Sie eine DDIC-Struktur an, welche die kompletten API-Eingabeparameter enthält.

Falls für den Inbound-Service ein entsprechender Outbound-Confirmation- oder Response-Service existiert, sollten Sie außerdem das Feld RESPONSE_REGISTRATION, als GUID typisiert, sowie die Message-Header-Struktur-Message mit aufnehmen. Diese können in einer Bestätigungsnachricht erforderlich sein.
Legen Sie in der Methode EXECUTE eine Instanz der Klasse CL_FEH_REGISTRATION mit der statischen Methode S_INITIALIZE an. Bei Message-Paketen übergeben Sie abap_false im Parameter IS_SINGLE.

Wenn Sie die Service-Implementierung wie oben beschrieben konzipieren, schließen sich folgende Schritte an. Wenn Sie ein anderes Design bevorzugen, weichen die Folgeschritte leicht ab, aber Ihr Design muss das gleiche feststellbare Laufzeitverhalten gewährleisten, vor allem im Hinblick auf die Funktionen zum Neustart der Service-Ausführung.
Legen Sie eine PROCESS-Methode mit mindestens den folgenden Parametern ab:
- I_PRE_MAPPING
  
  Proxy-DDIC-Struktur mit der gesamten Message vor dem Inbound-Mapping (Typisierung optional).
- I_POST_MAPPING
  
  DDIC-Struktur mit den Daten nach dem Inbound-Mapping. Diese Informationen werden an die Geschäftslogik-API übergeben (Typisierung optional).
- I_REF_REGISTRATION
  
  Instanz von CL_FEH_REGISTRATION.
- <Fault message exception>
  
  Anstatt die Ausnahme in dieser Methode auszulösen, können Sie BAPIRETTAB zurückgeben und die Fehler in den zugrunde liegenden Methoden behandeln.
Diese Methode muss von der EXECUTE-Methode aufgerufen werden. Die PROCESS-Methode selbst kann von der Proxy-Implementierung mit gefülltem I_PRE_MAPPING und von der Retry-Callback-Methode aufgerufen werden. In Retry-Callback ist der Parameter I_PRE_MAPPING gefüllt, wenn der Fehler im Mapping aufgetreten ist. Ist der Fehler in der Geschäftslogik-API aufgetreten, dann ist der Parameter I_POST_MAPPING gefüllt.

Somit kann die PROCESS-Methode mit Vorab-Mapping-Daten oder Daten der Geschäftslogik-API aufgerufen werden.
Wenn I_POST_MAPPING falsch ist, rufen Sie die Inbound-Mapping-Methode auf.
Wenn bei diesem Mapping Fehler auftreten:
- Ermitteln Sie den Hauptfehler.
- Kategorisieren Sie den Fehler.
- Rufen Sie die COLLECT-Methode aus der Instanz I_REF_REGISTRATION auf.
  
  Die Parameter der COLLECT-Methode sollten wie folgt gefüllt sein:
  - SINGLE_BO
    
    Eingabedaten für das Mapping als Struktur.
  - SINGLE_BO_REF
    
    Referenz auf die Eingabedaten für das Mapping. Sie müssen entweder SINGLE_BO oder SINGLE_BO_REF angeben. Geben Sie auf keinen Fall beides an.
  - ERROR_CATEGORY
    
    Fehlerkategorie des Hauptfehlers aus Tabelle /SAPPO/SERR_CAT.
  - MAIN_MESSAGE
    
    Hauptfehlermeldung.
  - MESSAGES
    
    Tabelle der anderen Fehlermeldungen (optional).
  - MAIN_OBJECT
    
    Objekt, das die Fehler verursacht hat (-OBJCAT und -OBJTYPE wie in Tabelle /SAPPO/S_OBJECT, -OBJKEY sollte mit dem Objektschlüssel gefüllt sein).
  - OBJECTS
    
    Liste weiterer beteiligter Objekte (optional).
  - PRE_MAPPING
    
    Übergeben Sie abap_true.
- Überspringen Sie die nächsten zwei Schritte.
Rufen Sie die Geschäftslogik-API mit den gemappten Daten auf.
Wenn der API-Aufruf einen Fehler zurückgibt, gehen Sie wie folgt vor:
- Ermitteln Sie den Hauptfehler.
- Kategorisieren Sie den Fehler.
  
  Siehe dazu /SAPPO/SERR_CAT.
- Rufen Sie die Methode COLLECT aus der Instanz I_REF_REGISTRATION auf. Die Parameter der COLLECT-Methode müssen wie folgt gefüllt werden:
  - SINGLE_BO
    
    Eingabedaten für den API-Aufruf als Struktur.
  - SINGLE_BO_REF
    
    Referenz auf die Eingabedaten für den API-Aufruf. Sie müssen entweder SINGLE_BO oder SINGLE_BO_REF angeben. Geben Sie auf keinen Fall beides an.
  - ERROR_CATEGORY
    
    Wie in Schritt 5 oben beschrieben.
  - MAIN_MESSAGE
    
    Fehlermeldung aus dem Anwendungsaufruf.
  - MESSAGES
    
    Wie in Schritt 5 oben beschrieben.
  - MAIN_OBJECT
    
    Wie in Schritt 5 oben beschrieben.
  - OBJECTS
    
    Wie in Schritt 5 oben beschrieben.
  - PRE_MAPPING
    
    Übergeben Sie abap_false bzw. lassen Sie dieses Feld leer.
Wenn nun ein Fehler auftritt, lösen Sie die Ausnahme aus, die das Proxy für die Standard-Fault-Message Ihres Inbound-Services bildet.