Connector für SAP Business Suite - API Beschreibung - Entwicklerhandbuch Teil 3 - Implementierung eigener Verarbeitungsmodule
Überblick über notwendige API MethodenVererbte Attribute des Root Objektes
Vererbte Methoden des Root Objektes
Checkliste Anlegen eines neuen Verarbeitungsmoduls
Test und Debugging
Extern aktiviertes Debugging
API Beschreibung- Entwicklerhandbuch Teil 4 - Beispielcodings
Überblick über notwendige API Methoden
Die folgende Tabelle soll einen kurzen Überblick darüber geben, welche API Funktionen implementiert werden müssen, um eine gewisse externe Funktionalität zu erreichen.| Anforderung | Datahandler | get_DataObjects | get_MetaInfo | get_List | get_Detail | modify | delete | update_temp_key |
| Anzeigen von internen Tabellen | GENERIC_VIEW | O | X | X | ||||
| Suchhilfefunktionen | GENERIC_VIEW | O | X | X | ||||
| Funktionale Aufrufe | GENERIC_FUNCTION | X | ||||||
| Triggerfunktionalität mit Datenhaltung im externen System | GENERIC_FUNCTION | X | ||||||
| Datenmodellierung extern, Datenhaltung im SAP | GENERIC_STORE | X | X | X | X | X | ||
| Triggerfunktionalität mit Datenhaltung im SAP | DEVELOPER_API | O | X | X | X | O | ||
| SAP Business Objekte (z.B. Kunde) verfügbar machen | DEVELOPER_API | O | X | X | X | O |
Vererbte Attribute des Root Objektes
Die folgende Tabelle enthält Attribute, die während der Instanziierung der Verarbeitungsmodule gesetzt werden. Diese können innerhalb der API Methoden verwendet werden.| Attribut | Verwendung | Weitere Informationen |
| CURRENT_API_FUNCTION | Aktuell aufgerufene Funktion der RFC API | API RFC Funktionen |
| CURRENT_LOG_GUID | GUID innerhalb der LOG-Tabelle | Logging |
| CUST_GLOBAL | Globales Customizing | Grundeinstellungen |
| CUST_OBJECT | Customizing des Verarbeitungsmoduls | Registrierung Verarbeitungsmodule |
| CUST_MAPPING | Customizing der Findung | Mapping externer Datengruppen auf Verarbeitungsmodule |
| IX_CONTROL | Externe Kontrollstruktur | Kontrollstruktur |
| KEY_SEPARATOR | Trennzeichen für zusammengesetzte Tabellenschlüssel | Schlüsselinformationen |
| PARAMETERS | Ermittelte Parameter nach Priorität: Objekt -> Mapping -> Externe Parameter | Logging |
Vererbte Methoden des Root Objektes
Die folgende Tabelle enthält Methoden, die am Root Objekt implementiert sind und von Framework verwendet werden. Die Implementierungsbeispiele aus dem 4. Teil der API-Beschreibung - Beispielcodings - enthalten teilweise ABAP-Coding, die den Aufruf dieser Methoden demonstrieren. Über Redefinition bestehender Methoden innerhalb eigener Verarbeitungsmodule kann deutlich in die Standardverarbeitung eingegriffen werden (z.B. Konvertieren von Datentypen).| Methode | Verwendung | Weitere Informationen |
| Z_IF_IA_IXA_INTREXX_API* | API-Methoden | API Interface |
| CHECK_BAPIRET2 | Prüfen von BAPIRET2-Strukturen auf Fehler und Anhängen von Meldungen | |
| GET_FIELD | Ermittle den Einzelwert aus Tabelle mit eingehenden Daten | Datenaustausch |
| GET_FIELD_WITH_X_FLAG | Wie GET_FIELD mit Update-Information für BAPI-Aufrufe | Datenaustausch |
| GET_FIELDS_FROM_STRUC | Übertragen der eingehenden Daten in eine Transferstruktur | Datenaustausch |
| GET_NEW_NUMBER_KEY | Einfache Nummernkreisimplementierung | Nummernkreise |
| GET_SERVER_CONFIG | Ermittle Wert aus externem Konfigurationswert | Kontrollstruktur |
| LOCKING* | Abbildung des Sperrkonzeptes | Sperrkonzept |
| MAP_BAPIRET2_TAB_TO_IXA_MSG | Mappen von BAPI-Meldungen auf internes Format | |
| MAP_FIELDVALUE* | Wertkonvertierung von interner nach externer Darstellung (und umgekehrt) je Datentyp | Konvertierung Intern vs. Extern |
| MAP_INTREXX_LANGUAGE_TO_SAP | Mappen der Portalsprache Intrexx Xtreme in interne SAP Sprache | |
| MAP_IXA_MESSAGE_TO_BAL_LOG | Mappen der internen Nachrichten in das Format des Anwendungslogs | Erweitertes Logging von Messages |
| MSG_APPEND | Eine Meldung für den externen Aufrufer ergänzen | Meldungen |
| SET_FIELD | Einen Einzelwert an den Export übergeben | Datenaustausch |
| SET_RESULTS_FROM_STRUC | Eine Transferstruktur an den Export übergeben | Datenaustausch |
Checkliste Anlegen eines neuen Verarbeitungsmoduls
Anlegen einer Klasse
Jedes Verarbeitungsmodul besteht aus einer ABAP Objects Klasse, die von einer Root Klasse des Portal Frameworks vererbt wird. Starten Sie dazu beispielsweise die Transaktion SE80. Durch das Kontextmenü (rechte Maustaste) kann man hier eine neue ABAP Klasse anlegen.
Geben Sie der neuen Klasse einen technischen Namen (evtl. nach Ihrer hausinternen Namenskonvention) und eine Bezeichnung.
Danach öffnet sich über den markierten Button ein zusätzliches Eingabefeld, in dem Sie angeben können, von welcher bereits existierenden Klasse die neue Klasse vererbt werden soll. Geben Sie hier eine Klasse des Frameworks an.
Beispiele:
- Z_CL_IA_IXA_OBJECT (WAS 6.x)
- Z_CL_IA_IXA_OBJECT46 (SAP Basis 4.6)
Falls Sie die neue Klasse nicht dem lokalen Paket $TMP zugeordnet haben, sollte sich nach dem Bestätigen mit Klick auf Sichern ein Popup für die Transportabfrage öffnen. Die neue Klasse wurde angelegt und kann jetzt aktiviert werden. Die Aktivierung wird beispielsweise über die Schaltfläche
gestartet.
Es öffnet sich eine Auwahl der zu aktivierenden Objekte.
Nach dem Bestätigen ist die neue Klasse aktiviert und kann verwendet werden.
Redefinition der API Methoden
Das Erweiterungskonzept des Portal Frameworks besteht darin, das die ermittelten Verarbeitungsmodule die entsprechenden API Methoden des API Interface überschreiben. Hier wird beispielhaft die API Methode GET_DETAIL redefiniert. Dazu platzieren Sie den Cursor auf der API Methode und klicken die Schaltfläche
.
Die ABAP Workbench erzeugt daraufhin eine Vererbung der gewählten Methode mit einem Coding-Vorschlag zum Aufruf der gleichnamigen Methode des übergeordneten Objektes.
Hier ist es sinnvoll, die geerbte Methode des übergeordneten Objektes aufzurufen und davor oder danach eigenes Coding zu platzieren. In vielen Fällen wird allerdings die gesamte Methode neu implementiert werden müssen. Der grundsätzliche Rahmen für so eine Neuimplementierung könnte wie im folgenden Coding dargestellt verwendet werden:
method Z_IF_IA_IXA_INTREXX_API~GET_DETAIL.
* -------------- init
cv_processed = 'X'.
ev_error = 'X'.
* -------------- get inbound parameters
* -------------- initial check routines
* -------------- process
* -------------- fill outbound parameters
* -------------- finally set no error
ev_error = ' '.
endmethod.
Anlegen einer Transferstruktur
Für die tabellarische Übertragung von Daten über die API an einen externen Aufrufer wird eine Transferstruktur eingesetzt. Den Aufbau dieser Struktur (z.B. Feldnamen und technische Eigenschaften dieser Felder) ermittelt der externe Aufrufer über die API-Methode GET_METAINFO. Die Erfahrung zeigt, dass es sinnvoll ist, diese Transferstruktur im ABAP Dictionary als Struktur zu definieren. Dann kann man diese Struktur z.B. wie eine Tabelle behandeln und die API Methoden für das registrierte Verarbeitungsmodul des Datahandlers GENERIC_VIEW verwenden (z.B. GET_METAINFO). Im Folgenden wird das Anlegen einer solchen Transferstruktur beispielhaft beschrieben. Transferstrukturen enthalten meistens eine Untermenge tatsächlich vorhandener SAP Tabellen oder Views bzw. die Felder von BAPI-Strukturen. Wenn möglich, sollte man hier die gleichen Feldnamen verwenden, die die eigentlichen SAP Verarbeitungsfunktionen (z.B. BAPI Funktionsbausteine) verwenden. Ein Übertragen der Daten ist dann zeitsparend über das ABAP Kommando MOVE-CORRESPONDING möglich. Transferstrukturen können SAP Daten in einer Tabellenzeile definieren, die tatsächlich so gar nicht vorhanden bzw. nicht über Joins ermittelbar sind. Beispiele dafür sind:- Kundenstammdaten mit Adresse und Kommunikationsdaten in einer Zeile
- Aufbereitete Textfelder (z.B. Textfeld zum Statuscode)
In einem Popup wird der technische Name der neuen Struktur abfragt.
In der Strukturpflege definieren Sie dann die Feldnamen und Datenelemente Ihrer Transferstruktur. Die Transferstruktur sollte alle später für die Identifikation notwendigen Schlüsselfelder enthalten.
Aktivieren Sie die Struktur.
Registrieren des Verarbeitungsmoduls
Die neu angelegte Klasse muss im Customizing für Verarbeitungsmodule registriert werden. Der folgende Screenshot zeigt die Registrierung der vorher beispielhaft angelegten Verarbeitungsklasse, die sich nur auf die Transferstruktur YIXAPI_DEMO mit dem Schlüsselfeld PARTNER bezieht.
Alternativ ist es auch möglich, generische Verarbeitungsmodule ohne festen Bezug zu einer Transferstruktur zu implementieren. Dort wird die tatsächliche Transferstruktur aus anderen Parametern generisch ermittelt (z.B. aus dem extern verwendeten Datengruppennamen). Als Namenskonvention für den notwendigen technischen Namen OBJECTTYPE seien folgende Prefixe empfohlen:
- Generische Module - GENERIC_*
- Module mit BAPI Bezug - BAPI_*
Findung des Verarbeitungsmoduls
Das soeben registrierte Verarbeitungsmodul wird noch nicht durch das Framework gefunden. Hierfür muss das Customizing der Findung gepflegt werden. Der folgende Screenshot zeigt dies für das aufgeführte Beispiel.
Das neue Verarbeitungsmodul ist zukünftig erreichbar über den Datahandler DEVELOPER_API und die externe Datengruppe YIXAPI_DEMO.
Test und Debugging
Dieser Abschnitt beschreibt Möglichkeiten, wie neue Verarbeitungsmodule sowie deren Findung getestet und debugged werden können.Test der Findung über die RFC API
Die extern aufgerufenen RFC Funktionen der RFC API sind im Kapitel API RFC Funktionen aufgeführt. Jedes dieser RFC Funktionen lässt sich über die Transaktion SE37 ABAP intern testen und debuggen. Das folgende Beispiel zeigt dies anhand der implementierten API-Methode GET_DETAIL des Verarbeitungsmoduls aus dem Kapitel Checkliste Anlegen eines neuen Verarbeitungsmoduls. Der extern aufgerufene RFC-Funktionsbaustein für die API-Methode GET_DETAIL ist Z_IA_IXA_API_GET_DETAIL. Diese wird jetzt mit SE37 gestartet.
Ein Fenster mit der Funktionsbaustein-Schnittstelle wird geöffnet.
Eine wichtige Rolle für die Findung des Verarbeitungsmoduls spielt der Parameter IS_CONTROL. Mit Klick auf die Schaltfläche
kann der Parameter bearbeitet werden.
Eine optisch bessere Ansicht wird mit Klick auf die Schaltfläche
hergestellt. Für den Test reicht es hier aus, die Felder IX_DATAGROUP und IX_DATAHANDLER zu füllen. Die Werte müssen die gleichen sein, die für die Findung eingetragen wurden.
Nach dem Bestätigen und der Rückkehr in die Schnittstellenansicht kann der RFC Funktionsbaustein mit der Taste F8 oder mit Klick auf die Schaltfläche
gestartet werden. Abhängig vom verwendeten API Baustein sind ggfs. noch weitere Parameter zu füllen.
Nach dem Start enthält die Schnittstellenansicht die Rückgabewerte.
Ein initialer Export-Parameter EV_ERROR ist ein gutes Zeichen dafür, dass ein Verarbeitungsmodul mit diesen Parametern gefunden und ausgeführt wurde. Um herauszufinden, ob das richtige Verarbeitungsmodul gestartet wurde, kann ein Breakpoint in der korrespondierenden API-Methode des Verarbeitungsmoduls platziert werden.
Debugging in SAP
Dieser Abschnitt beschreibt eine Debugmöglichkeit ohne externen Aufruf. Hiermit kann der ABAP-Entwickler die grundsätzliche Funktionalität eines Verarbeitungsmoduls testen, bevor ein externer Verbraucher die RFC API Funktionen remote aufruft. Dazu ist innerhalb des ABAP-Codings ein Breakpoint (z.B. am Anfang der API-Methode) mit der Taste STRG-SHIFT-F12 oder mit Klick auf die Schaltfläche
zu platzieren.
In neueren Releases (Basis SAP Gateway >6.10) kann jetzt ein Auswahlfenster zum Typ des anzulegenden Breakpoints geöffnet werden. Hier ist dann ein Session-Breakpoint auszuwählen.
Der Breakpoint wird im Coding angezeigt.
Danach ist der Test durch den Aufruf des zuständigen RFC Funktionsbausteins zu wiederholen. Die Transaktion SE37 muss dazu neu gestartet werden. Der Debugger wird beim Erreichen des Breakpoints aufgerufen.
Der ABAP-Entwickler kann jetzt wie gewohnt im Debugmode testen und Fehler suchen.
Externes Debugging
Externes Debugging ermöglicht Fehlersuche und Test von ABAP-Coding, das extern aufgerufen wird (z.B. via RFC vom Portal). Dadurch lassen sich auch Fehler finden, die darin begründet sind, dass der externe Aufrufer Parameter anders füllt als dies vorgesehen ist. Diese Option steht in SAP Systemen zur Verfügung, die eine ABAP Basis >= 6.10 einsetzen. Das externe Debugging muss in den Einstellungen der ABAP Workbench (Transaktion SE80, Menü Hilfsmittel / Einstellungen) aktiviert werden.
Auch das Debugging von Benutzern, die vom ABAP-Entwickler oder Anmeldenamen abweichen, ist möglich. So lässt sich z.B. auch der technische Benutzer überwachen, mit dem sich der externe Aufrufer an die RFC API anmeldet. Dabei ist zu beachten, dass der hier eingetragene Benutzer ausreichend berechtigt (z.B. Debugging, ABAP Entwicklung) und als Dialog-Benutzer kategorisiert ist (z.B. auch nur temporär während der Testphase). Beim Erscheinen des Auswahlpopups für den Typ des Breakpoints ist hier Externer Breakpoint auszuwählen.
Damit der Breakpoint für den externen Aufrufer wirksam wird, muss sich das externe System evtl. neu anmelden. Wird der Debugger nach dem Aufruf der API-Funktion nicht geöffnet, obwohl der interne Test funktioniert, enthält die SAP-Dokumentation zum externen Debugging weitere Hinweise für die Fehlersuche. In den meisten Fällen wird man in den *.TRC Dateien der remote verwendeten RFC API fündig.