Ü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 |
|
|
CURRENT_LOG_GUID |
GUID innerhalb der LOG-Tabelle |
|
|
CUST_GLOBAL |
Globales Customizing |
|
|
CUST_OBJECT |
Customizing des Verarbeitungsmoduls |
|
|
CUST_MAPPING |
Customizing der Findung |
|
|
IX_CONTROL |
Externe Kontrollstruktur |
|
|
KEY_SEPARATOR |
Trennzeichen für zusammengesetzte Tabellenschlüssel |
|
|
PARAMETERS |
Ermittelte Parameter nach Priorität: Objekt -> Mapping -> Externe Parameter |
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 |
|
|
CHECK_BAPIRET2 |
Prüfen von BAPIRET2-Strukturen auf Fehler und Anhängen von Meldungen |
|
|
GET_FIELD |
Ermittle den Einzelwert aus Tabelle mit eingehenden Daten |
|
|
GET_FIELD_WITH_X_FLAG |
Wie GET_FIELD mit Update-Information für BAPI-Aufrufe |
|
|
GET_FIELDS_FROM_STRUC |
Übertragen der eingehenden Daten in eine Transferstruktur |
|
|
GET_NEW_NUMBER_KEY |
Einfache Nummernkreisimplementierung |
|
|
GET_SERVER_CONFIG |
Ermittle Wert aus externem Konfigurationswert |
|
|
LOCKING* |
Abbildung des Sperrkonzeptes |
|
|
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 |
|
|
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 |
|
|
MSG_APPEND |
Eine Meldung für den externen Aufrufer ergänzen |
|
|
SET_FIELD |
Einen Einzelwert an den Export übergeben |
|
|
SET_RESULTS_FROM_STRUC |
Eine Transferstruktur an den Export übergeben |
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
SAP Trust Manager SSO configuration
API Beschreibung Teil 1 - Übersicht
API Beschreibung Teil 2 - SAP Portal Plugin
API Beschreibung Teil 4 - Beispielcodings
Entwicklerhandbuch Teil 2 - Integrationsszenario SAP-Fremddatengruppe
Entwicklerhandbuch Teil 3 - Integrationsszenario Skripting
Entwicklerhandbuch Teil 4 - Personalisierter SAP Zugriff / Single Sign On (SSO)
Senden Sie uns eine E-Mail