Einführung in das BOPF Message Concept und die Fehlerbehandlung
Das Message Concept des Business Object Processing Frameworks (BOPF) unterscheidet sich sehr stark von anderen Konzepten der Nachrichtenbehandlung. Die Fehlerbehandlung wird auch häufig im Zusammenhang mit Nachrichten genutzt, um den Nutzer ein Feedback zu geben. Dieser Beitrag erklärt das Message Concept für Rückmeldungen an den Benutzer und die Verwendung der failed keys zur Fehlermitteilung an das Framework.
Rückmeldung an den Benutzer
Treten Fehler auf, wie beispielsweise bei fehlerhaften Eingaben, ist der Benutzer zu informieren um die Ursache zu korrigieren. BOPF nutzt für dieses Feedback ein objektorientiertes Vorgehen und verschalt Nachrichten mit einer ABAP-Klasse. Jede Nachricht ist dabei eine separate Instanz dieser Nachrichtenklasse. Der Nachrichtentext selbst wird dabei wie gewohnt über die Transaktion SE91 gepflegt. Dieser wird dann in der ABAP-Klasse verwendet und kann um zusätzliche Informationen erweitert werden.
Die ABAP Klasse erbt von der Klasse /BOBF/CM_FRW wie in folgender Grafik dargestellt.
Abbildung 1: BOPF Message Concept – Vererbung der Nachrichtenklassen
In dieser Oberklasse sind die zentralen Features des BOPF Message Concept bereits implementiert und können für die eigene Implementierung der Nachricht genutzt werden.
Um die Übersicht zu behalten empfiehlt es sich, für jedes Business Object eine eigene Nachrichtenklasse anzulegen. Pro Nachrichtenklasse können mehrere Nachrichten gepflegt werden:
Abbildung 2: Nachrichtentexte
Bei der Instanziierung wird über den Parameter TEXTID spezifiziert, welche Nachricht für diese Instanz genutzt werden soll.
Immer, wenn nun eine Nachricht ausgegeben werden soll, wird nun ein neues Objekt dieser Nachrichtenklasse erzeugt.
Zur Initialisierung eines Nachrichtenobjektes werden folgende Attribute benötigt:
| TEXTID | Schlüssel zur Identifizierung des Nachrichtentextes. |
| SEVERITY | Die Fehlerklasse der Nachricht (z.B. Error, Warning, …). Diese Werte liegen als Konstante vor. |
| SYMPTOM | Beschreibt wie mit der Nachricht umgegangen werden soll. |
| LIFETIME | Kann durch BOPF automatisch gesetzt werden. Definiert, wie lange die Nachricht gültig ist und kann vom Consumer (z.B. FPM UI) ausgewertet werden |
| MS_ORIGIN_LOCATION | Hierüber kann angeben werden, zu welcher Instanz und Entität die Nachricht gehört |
Es können bei Bedarf auch weitere Attribute angelegt werden, z.B. um Werte für die Nachrichten zu übergeben.
Das Attribut MS_ORIGIN_LOCATION gibt an, welches Feld für das Auslösen der Nachricht verantwortlich war. Bei einer näheren Betrachtung des Parameters ist zu sehen, dass dort das Geschäftsobjekt, der Knoten und der Instanz-Schlüssel des Knotens gespeichert werden.
Die Erzeugung eines Nachrichtenobjektes, z.B. bei einer Validierung, kann mit dem folgenden Code erfolgen:
| CREATE OBJECT lo_message EXPORTING textid = /mind2/cm_currency=>/mind2/cm_currency2 severity = /mind2/cm_currency=>co_severity_error symptom = /bobf/if_frw_message_symptoms=>co_bo_inconsistency lifetime = /bobf/if_frw_c=>sc_lifetime_set_by_bopf ms_origin_location = ls_location. |
Um die Nachrichten weiterzureichen, enthält jedes BOPF-Interface den Export-Parameter eo_message, welcher als Container für diese klassenbasierten Nachrichten dient:
| eo_message->add_cm( EXPORTING io_message = lo_message ). |
Fehler an das Framework übermitteln
Die Nachrichten dienen nur als Feedback an den Benutzer. Das Framework wertet diese Nachrichten nicht aus. Somit muss dem Framework auf andere Weise mitgeteilt werden, wenn ein Fehler vorliegt. Dies ist notwendig, damit das Framework die notwendigen Aktionen für den Fehlerfall, wie beispielsweise das Zurücksetzen von ungültigen Datenänderung, durchführen kann.
Dafür besitzt jedes BOPF Interface den Export-Paremter et_failed_key. Tritt ein Fehler für eine bestimmte Knoten-Instanz auf, wird dessen technischer Schlüssel dieser Tabelle hinzugefügt:
| ls_key–key = ls_root->key. APPEND ls_key TO et_failed_key. |
Das Framework prüft den Inhalt dieses Containers und erkennt daran, dass für die jeweilige Instanz eine Validierung, Aktion oder ähnliches fehlgeschlagen ist.
Die Verarbeitung wird dann ggf. abgebrochen, bis der Benutzer den Fehler korrigiert hat.
Vorteile des BOPF Message Concepts und der failed keys
Das Nachrichtenkonzept von BOPF bringt einige Vorteile mit sich, wie z.B. das vereinfachte Finden der Fehlerursache. Alle Nachrichten befinden sich in einem Container und beinhalten viele Informationen die beim Debugging unterstützen können. Dazu gehört zum Beispiel der Name der Validation, Determination oder Action die eine Nachricht ausgelöst hat.
Da die Nachrichten über eine ABAP-Klasse abgebildet sind, können diese leicht um weitere Informationen erweitert werden. Dieser Vorteil ist bereits bei der Verwendung des Attributs ms_origin_location zu erkennen. Über die Angabe dieser Informationen können Fehler bis auf das Attribut einer Instanz zurückverfolgt werden. Dies ist vor allem bei der Massenverarbeitung ein großer Vorteil, wenn man von hunderten gleich lautender Nachrichten überschwemmt wird. Der Consumer kann diese Location-Informationen auswerten. Der Floorplan Manager in Verbindung mit FBI unterstützt dies bereits out of the box: Die Felder mit den fehlerhaften Inhalten werden auf der Oberfläche markiert, so dass der Nutzer genau sieht, wo er eine falsche Eingabe getätigt hat.
Abbildung 3: Fehlermeldungen mit FBI
Das erhört die Benutzerfreundlichkeit einer Anwendung sehr stark. Der Entwicklungsaufwand für dieses Feature dagegen ist minimal.
Durch die failed keys entfällt die aufwendige Prüfung der Fehler, wie sie beispielsweise bei der Nutzung von sy-subrc nötig ist. Das Framework reagiert automatisch auf vorhandene Schlüssel im failed keys Container, ohne das der Entwickler weiter eingreifen muss.
Gibt es auch Nachteile?
Jedes Konzept hat Vor- und Nachteile, so auch das in BOPF eingesetzte Message Concept. Der Container für die Nachrichten wird nicht vom Framework selbst initialisiert. Dies kann etwas störend sein, da in jeder Entität vor der Verwendung geprüft werden muss, ob der Container bereits initialisiert wurde. Dies geht glücklicherweise mit wenigen Zeilen Code:
| IF eo_message IS NOT BOUND. eo_message = /bobf/cl_frw_factory=>get_message( ). ENDIF. |
Wie gefällt Ihnen das klassenbasierte Message Concept aus BOPF? Überwiegen Ihrer Meinung nach die Vorteile oder die Nachteile? Vielleicht können Sie sich ja auch noch ein weiteres Konzept vorstellen. Es würde mich freuen Ihre Meinung dazu erfahren zu können.
