Connector für SAP Business Suite - API Beschreibung - Entwicklerhandbuch Teil 3 - Implementierung eigener Verarbeitungsmodule

1. Ü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.

AnforderungDatahandlerget_DataObjectsget_MetaInfoget_Listget_Detailmodifydeleteupdate_temp_key
Anzeigen von internen TabellenGENERIC_VIEW OXX
SuchhilfefunktionenGENERIC_VIEW OXX
Funktionale AufrufeGENERIC_FUNCTION X
Triggerfunktionalität mit Datenhaltung im externen SystemGENERIC_FUNCTION X
Datenmodellierung extern, Datenhaltung im SAPGENERIC_STORE XXXXX
Triggerfunktionalität mit Datenhaltung im SAPDEVELOPER_API OXXXO
SAP Business Objekte (z.B. Kunde) verfügbar machenDEVELOPER_API OXXXO

2. 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.

AttributVerwendungWeitere Informationen
CURRENT_API_FUNCTIONAktuell aufgerufene Funktion der RFC APIAPI RFC Funktionen
CURRENT_LOG_GUIDGUID innerhalb der LOG-TabelleLogging
CUST_GLOBALGlobales CustomizingGrundeinstellungen
CUST_OBJECTCustomizing des VerarbeitungsmodulsRegistrierung Verarbeitungsmodule
CUST_MAPPINGCustomizing der FindungMapping externer Datengruppen auf Verarbeitungsmodule
IX_CONTROLExterne KontrollstrukturKontrollstruktur
KEY_SEPARATORTrennzeichen für zusammengesetzte TabellenschlüsselSchlüsselinformationen
PARAMETERSErmittelte Parameter nach Priorität: Objekt -> Mapping -> Externe ParameterLogging

3. 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).

MethodeVerwendungWeitere Informationen
Z_IF_IA_IXA_INTREXX_API*API-MethodenAPI Interface
CHECK_BAPIRET2Prüfen von BAPIRET2-Strukturen auf Fehler und Anhängen von Meldungen
GET_FIELDErmittle den Einzelwert aus Tabelle mit eingehenden DatenDatenaustausch
GET_FIELD_WITH_X_FLAGWie GET_FIELD mit Update-Information für BAPI-AufrufeDatenaustausch
GET_FIELDS_FROM_STRUCÜbertragen der eingehenden Daten in eine TransferstrukturDatenaustausch
GET_NEW_NUMBER_KEYEinfache NummernkreisimplementierungNummernkreise
GET_SERVER_CONFIGErmittle Wert aus externem KonfigurationswertKontrollstruktur
LOCKING*Abbildung des SperrkonzeptesSperrkonzept
MAP_BAPIRET2_TAB_TO_IXA_MSGMappen von BAPI-Meldungen auf internes Format
MAP_FIELDVALUE*Wertkonvertierung von interner nach externer Darstellung (und umgekehrt) je DatentypKonvertierung Intern vs. Extern
MAP_INTREXX_LANGUAGE_TO_SAPMappen der Portalsprache Intrexx Xtreme in interne SAP Sprache
MAP_IXA_MESSAGE_TO_BAL_LOGMappen der internen Nachrichten in das Format des AnwendungslogsErweitertes Logging von Messages
MSG_APPENDEine Meldung für den externen Aufrufer ergänzenMeldungen
SET_FIELDEinen Einzelwert an den Export übergebenDatenaustausch
SET_RESULTS_FROM_STRUCEine Transferstruktur an den Export übergebenDatenaustausch

4. 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:


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.
Dieser Vorschlag geht davon aus, dass die Methode im Fehlerfall jederzeit durch den ABAP Befehl "EXIT" verlassen werden kann. Erst zum Schluss wird das Fehlerflag wieder gelöscht.

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: Die aufgerufende API Methode ist dafür verantwortlich, dass alle notwendigen Konvertierungen erfolgt sind, bevor die Daten in die Ausgangsparameter der API Methoden gestellt werden. Eine Transferstruktur wird entweder über die Transaktion SE11 oder wiederum in der ABAP Workbench SE80 angelegt.



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: Sonst sollten die technischen Namen Bezüge zum hausinternen Projekt enthalten und Hinweise auf die zu erwartende Funktionalität bieten (z.B. "*ORDER*").

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".

5. 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.

6. Extern aktiviertes Debugging

Eine weitere Möglichkeit, den Debugmode zu aktivieren, stellt das extern verwendete SAP RFC SDK zur Verfügung. So ist es zum Beispiel bei Verwendung des SAP Java Connectors möglich, den Debugmode extern zu aktivieren (siehe Dokumentation zum SAP Java Connector). Externe Aufrufer, welche den SAP Java Connector verwenden, stellen evtl. Parameter zur Verfügung, die dieses Verhalten auslösen. Eine Einschränkung dieses Verfahrens ist, dass dies nur unter MS Windows stabil funktioniert und eine SAPGUI auf dem Rechner des externen Aufrufers installiert sein muss. Dass schließt meistens diese Alternative schon aus, da der Server im Rechenzentrum nicht für Entwicklung und Tests verwendet werden sollte.

7. Weitere Informationen

API Beschreibung- Entwicklerhandbuch Teil 4 - Beispielcodings