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

Ü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_MetaInfo	get_List	get_Detail	modify	delete
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 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 Auswahl 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:

Kundenstammdaten mit Adresse und Kommunikationsdaten in einer Zeile
Aufbereitete Textfelder (z.B. Textfeld zum Statuscode)

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:

Generische Module - GENERIC_*
Module mit BAPI Bezug - BAPI_*

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

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.

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.

Weitere Informationen

Allgemeines

Installation

Verbindung erstellen

Integration in Applikationen

SAP Skript Generator

SAP Trust Manager SSO configuration

API Beschreibung Teil 1 - Übersicht

API Beschreibung Teil 2 - SAP Portal Plugin

API Beschreibung Teil 4 - Beispielcodings

Entwicklerhandbuch Teil 1

Entwicklerhandbuch Teil 2 - Integrationsszenario SAP-Fremddatengruppe

Entwicklerhandbuch Teil 3 - Integrationsszenario Skripting

Entwicklerhandbuch Teil 4 - Personalisierter SAP Zugriff / Single Sign On (SSO)

Entwicklerhandbuch Teil 5 - Addons

Entwicklerhandbuch Anhang

Entwicklerhandbuch - Mustercodings