Connector für SAP Business Suite - API Beschreibung - Entwicklerhandbuch Teil 2 - SAP Portal Plugin

1. Entwicklungsziele

Folgende Entwicklungsziele standen für die Implementierung des SAP Portal Plugins im Vordergrund:

2. API Konzept

Aus den Entwicklungszielen ging eine kleine RFC-fähige API hervor, die im Wesentlichen folgende Funktionen implementiert: Weitere Details zur RFC API finden Sie hier.

Der Aufruf der RFC API erfolgt vom Fremdsystem (z.B. Intrexx) aus der Business Logik des Fremdsystems heraus über den SAP Java Connector.



Die Findung des geeigneten SAP Systems wurde bereits in Teil 1 der Api-Dokumentation beschrieben. Innerhalb des SAP Systems wird ein entsprechendes Verarbeitungsmodul aus der Kombination Externer Datahandler und Tabellenname ermittelt.

3. Erweiterungskonzept Verarbeitungsmodule

Für die Verarbeitungsmodule wurde das ABAP Objects Konzept benutzt, um Vorteile bei der Implementierung (vor allem durch die Vererbung) auszunutzen. Jeder Aufruf einer API-Methode ermittelt also eine ABAP Objects Klasse, an die die externe Anforderung als Methode weiter gereicht wird. Durch die Vererbung wird die Implementierung von generischen Verarbeitungsmodulen ermöglicht. Für einen lesenden Zugriff auf SAP Tabellen und Views sind z.B. eigentlich immer die selben Programmschritte notwendig. Es ändern sich nur der technische Name der Tabelle bzw. der View und die zu übertragenden Informationen (abweichende Tabellenstrukturen, Metainformationen). Die Anforderung des Lesezugriffs auf Tabellen und Views kann deshalb leichter über ein allgemeines Verarbeitungsmodul (z.B. "GENERIC_VIEW") gelöst werden, als ein schreibender Zugriff auf SAP Datenobjekte. Hier müssen Anforderungen wie Sperrkonzept, Prüflogiken u.ä. beachtet werden. Die Implementierung von schreibenden Zugriffen kann deshalb kaum generisch abgebildet werden, da man hier die objektspezifischen API Bausteine (z.B. BAPI) nutzen sollte. Die Grafik stellt noch einmal das Zusammenspiel zwischen System (abgebildet im externen Aufrufer), Datahandler und Datenobjekt dar. Vor allem der untere Teil stellt die Findung der ABAP Objects Klasse und den Aufruf der dort implementierten API-Methode dar.



Der Datenfluss sowie die Findung der Verarbeitungsroutinen im Zusammenspiel von Externem Aufrufer (hier Intrexx) und dem SAP Portal Plugin zeigt die folgende Abbildung.

4. Datahandler

Im externen System können verschiedene Datahandler notwendig sein, um die möglichen Datenobjekte voneinander abzugrenzen. Die folgenden Datahandler sind vom SAP Portal Plugin vordefiniert und können von den externen Systemen verwendet werden:

Datahandler Verwendung
GENERIC_VIEW Generischer Lesezugriff auf physisch vorhandene Tabellen und Views. Dieser Datahandler wird immer dann verwendet, wenn nicht explizit ein anderer Datahandler vorgegeben wird.
GENERIC_REPORT Generischer Lesezugriff für SAP Reports (SE38). Ermöglicht das Starten von (einfachen) Reports mit Parameterübergabe und Rückgabe der Ergebnisse in einer Tabellenstruktur.
GENERIC_STORE Ermöglicht das Ablegen von Daten in tabellenartigen Strukturen in SAP. Generisch bedeutet hier, dass trotz der physischen Ablage der Daten in SAP kein Entwicklungsaufwand notwendig sein muss. Dies kann beispielsweise durch Nutzen der Klassifizierung o.ä. Funktionen erreicht werden.
GENERIC_FUNCTION Ermöglicht funktionale Aufrufe in SAP bzw. EXIT-Funktionalität, mit der SAP die extern erfassten Daten prüfen kann. Die Datenhaltung erfolgt im externen System. Das Speichern eines externen Datensatzes wird an die API-Methode "modify" weiter geleitet.
GENERIC_BAPI Dieser Datahandler könnte verwendet werden , um einen generischen Zugriff auf SAP Business Objekte und deren BAPI-Methoden zu implementieren.
DEVELOPER_API Datahandler für alle nicht generischen Verarbeitungsmodule, die einen Teil oder die komplette API abbilden.

Die hier aufgeführten Datahandler werden vor allem für die Findung der richtigen Verarbeitungsmodule verwendet. Diese Datahandler sind nicht zu verwechseln mit zusätzlichen Verarbeitungsmodulen. Diese werden normalerweise mit Bezug zum Datahandler DEVELOPER_API angelegt.

5. RFC API

Entwicklungsobjekte

Die Entwicklungen (in früheren Releases der SAP Basis auch als Entwicklungsklassen bekannt) zur RFC API finden Sie im Paket "ZIA_INTREXX_API" in der Funktionsgruppe "ZIA_IXA_API". Für die externe Nutzung der Funktionalität des SAP Plugins reicht es aus, für diese Funktionsgruppe den externen Zugriff zu erlauben. Weitere Hinweise zum Berechtigungskonzept finden Sie hier.

Verwendete Strukturen

a) Kontrollstruktur

Die Kontrollstruktur (technisch "ZIA_IXA_API_INTREXX_CONTROL") wird als Import-Parameter "IS_CONTROL" jedes API-RFC-Funktionsbausteins verwendet, um bestimmte externe Parameter zur Verfügung zu stellen.

Nr Feldname Datenelement Datentyp Länge Beschreibung
1 IX_DATAGROUP ZIA_IXA_DATAGROUP CHAR 30 Name der externen Datengruppe
2 IX_DATARANGE ZIA_IXA_DATARANGE CHAR 30 Datengruppen können u.U. in verschiedenen Sichten verwendet werden. Dieses Feld enthält die technische Bezeichnung der Sicht des aufrufenden Systems.
3 IX_DATAGROUP_EXT ZIA_IXA_DATAGROUP_EXTERN CHAR 30 Dieses Feld enthält den Namen einer Datengruppe des aufrufenden Systems (SAP-extern), die mit der in Feld (1) angegebenen Datengruppe korrespondiert. Das Feld wird kaum verwendet und enthält beispielsweise den Wert aus (1).
4 IX_SESSION ZIA_IXA_SESSION CHAR 40 Enthält die externe Session ID im Internet und kann als Identifizierung von zusammenhängenden Aufrufen verwendet werden.
5 IX_USER ZIA_IXA_USER CHAR 30 Enthält den Benutzernamen innerhalb des externen Systems.
6 IX_USERGROUP ZIA_IXA_USERGROUP CHAR 30 Enthält die Benutzergruppe des externen Systems.
7 IX_LANGUAGE ZIA_IXA_LANGUAGE CHAR 2 Enthält die aktuell verwendete Sprache des externen Systems.
8 IX_SAPINSTANCE ZIA_IXA_SAP_INSTANCE CHAR 20 Name der Datenquelle des aktuellen Systems im externen aufrufenden System.
9 IX_SAPID ZIA_IXA_SAPID CHAR 20 Installationsnummer des SAP Systems.
10 IX_SYSID SYSYSID CHAR 8 SID des SAP Systems.
11 IX_CLIENT SYMANDT CLNT 3 Mandant des SAP Systems.
12 IX_PRODUCTIVE ZIA_IXA_PRODUCTIVE CHAR 1 Kennzeichen: produktives System.
13 IX_LICENSE ZIA_IXA_LICENSE CHAR 60 Lizenzschlüssel.
14 IX_SRVCFG ZIA_IXA_SRVCFG CHAR 255 Server Konfiguration.
15 IX_DATAHANDLER ZIA_IXA_DATAHANDLER CHAR 20 Externer Datahandler.
16 IX_DHNDL_VAR ZIA_IXA_DATAHANDLER_VARIANT CHAR 30 Variante des externen Datahandler (z.B. default).
17 PARAMETER_1 ZIA_IXA_PARAMETER CHAR 50 Extern gepflegter Parameter (1).
18 PARAMETER_2 ZIA_IXA_PARAMETER CHAR 50 Extern gepflegter Parameter (2).
19 PARAMETER_3 ZIA_IXA_PARAMETER CHAR 50 Extern gepflegter Parameter (3).
20 PARAMETER_4 ZIA_IXA_PARAMETER CHAR 50 Extern gepflegter Parameter (4).
21 PARAMETER_5 ZIA_IXA_PARAMETER CHAR 50 Extern gepflegter Parameter (5).

Für die Findung der tatsächlichen Verarbeitungsmodule (objektorientierte ABAP Objektinstanzen) werden die Felder 1, 2 und 15 verwendet. Weitere Informationen finden Sie hier. Die Felder 3-8 sind reine Information über das aufrufende System, können aber innerhalb der Verarbeitungsmodule relevant sein (z.B. bei der Auswertung der externen Sprache). Durch die Felder 9-14 können Aufrufe des falschen SAP Systems (z.B. falscher Mandant, Produktivsystem) verhindert werden. Man kann mit diesen Felder auch ein Lizenzmodell abbilden. Die Felder 15-16 enthalten Informationen zum extern verwendeten Datahandler. Dabei kann die Variante des Datahandlers beispielsweise das Verhalten des Verarbeitungsmoduls steuern (Vorschlagswert "default"). Auf die Findung des Verarbeitungsmoduls hat das Feld 16 keinen Einfluss. Das Verhalten des Verarbeitungsmoduls kann zusätzlich über max. 5 Parameter gesteuert werden (Felder 17-21).

b) Datenobjekte

Innerhalb der API Funktion "get_DataObjects" können mögliche Datenobjekte des Verarbeitungsmoduls ermittelt werden. Die technischen Namen und eine Beschreibung werden dort als Tabelle (technischer Name der Struktur "ZIA_IXA_API_INTREXX_DATAOBJ") an das externe aufrufende System zurückgegeben.

Nr Feldname Datenelement Datentyp Länge Beschreibung
1 DATAOBJECT ZIA_IXA_DATA_OBJECT CHAR 40 Technischer Name des Datenobjektes
2 DESCRIPTION ZIA_IXA_DATA_OBJECT_TEXT CHAR 79 Beschreibung des Datenobjektes

c) Datenaustausch

Der Datenaustausch zwischen dem externen aufrufenden System und dem SAP System erfolgt in beide Richtungen über eine Tabelle mit einer festen Struktur (technischer Name "ZIA_IXA_API_INTREXX_FIELDS"), die unabhängig von den zu übertragenden Datenobjekten ist.

Nr Feldname Datenelement Datentyp Länge Beschreibung
1 LIST_RECORD ZIA_IXA_RECORDNUMBER INT4 10 Datensatznummer
2 STRUC_NAME ZIA_IXA_STRUCTURE CHAR 30 Strukturbezeichnung
3 STRUC_RECORD ZIA_IXA_RECORDNUMBER INT4 10 Datensatznummer innerhalb der Strukur
4 FIELD_NAME ZIA_IXA_FIELDNAME CHAR 30 Feldname
5 FIELD_VALUE ZIA_IXA_FIELDVALUE CHAR 255 Feldwert

Mit dieser Struktur kann jede SAP-interne Tabellenstruktur (z.B. eine interne Tabelle) abgebildet werden, ohne dass die API geändert werden muss. Ausnahme sind komplexe Strukturen, die Tabellen oder Referenzen einbinden. Das Feld (1) enthält immer die Nummer des übergebenen Datensatzes und lässt sich leicht über den SY-TABIX der zu übergebenen Tabelle abbilden. Das Feld (4) enthält den Namen der Spalte (bzw. Feldnamen der Struktur) und Feld (5) den eigentlichen Wert. Die Felder (2) und (3) sind dafür vorgesehen, Unterstrukturen (z.B. bei der Übertragung von Aufträgen mit Positionen) aufzunehmen. Dazu muss das aufrufende System in der Lage sein, diese abhängigen Daten innerhalb eines Aufrufes zu verarbeiten. Für den regulären Aufruf ohne abhängige Daten sind die Felder wie folgt gefüllt: Das folgende Beispiel zeigt die Transformation einer internen SAP-Tabelle in die API-Übergabetabelle für den Datenaustausch.



d) Schlüsselinformationen

In direktem Zusammenhang mit der Struktur für den Datenaustausch steht die Struktur für den Austausch von Schlüsselinformationen (technischer Name "ZIA_IXA_API_INTREXX_KEYS"). Vor allem innerhalb der API-Methode "get_Detail" wird diese Struktur benötigt, um jedem Datensatz innerhalb der Struktur für den Datenaustausch, gekennzeichnet über das Feld "LIST_RECORD" - einen eindeutigen Schlüssel zuzuweisen.

Nr Feldname Datenelement Datentyp Länge Beschreibung
1 LIST_RECORD ZIA_IXA_RECORDNUMBER INT4 10 Datensatznummer
2 LIST_KEY ZIA_IXA_KEYFIELD CHAR 128 Schlüsselfeldwert

In der Annahme, dass im vorhergehenden Beispiel das Feld "PARTNER" ein eindeutiger Schlüssel ist, müsste die Tabelle für die Schlüsselinformationen wie folgt aussehen:



Da es innerhalb des SAP-Systems die Möglichkeit gibt, einen Datensatz durch eine Kombination von Feldern eindeutig zu kennzeichnen, muss hier eine spezielle Vorgehensweise in den Verarbeitungsmodule geprüft werden, um Datensätze, die mit "get_List" gelesen wurden, auch in den anderen API-Methoden (z.B. "get_Detail") eindeutig zu identifizieren. Bei den meisten SAP-Tabellen existiert durch das Mandantenkonzept ohnehin bereits ein Primary Key, der aus mindestens zwei Datenbankfeldern zusammengesetzt ist. Das Client-Feld kann aber im Zusammenhang eines externen Aufrufs vernachlässigt werden, da die Anmeldung bereits an einem Mandanten erfolgt. Der Zugriff auf andere Mandanten bzw. auf mandantenunabhängige Daten sollte kritisch geprüft werden. Als geeignet hat sich beispielsweise die Vorgehensweise erwiesen, mit der alle tatsächlichen Schlüsselfelder der SAP-Tabelle (allerdings ohne den Mandanten) mit einem Trennzeichen getrennt in das Feld "LIST_KEY" geschrieben wurden. Das folgende ABAP Coding könnte beispielsweise verwendet werden, um einen aus drei Tabellenfelder bestehenden eindeutigen Schlüssel zu erzeugen:
concatenate lv_key1 
						lv_key2 
						lv_key3<
						into lv_key_extern
						separated by '~'.
Der umgekehrte Weg kann über
split lv_key_extern 
										at '~' 
										lv_key3 
										into lv_key1 
												lv_key2
												lv_key3
implementiert werden. Als Trennzeichen können natürlich auch andere Zeichen außer "~" verwendet werden. Es sollte ein Zeichen verwendet werden, das nicht in den Schlüsselfelder der Tabelle vorkommen wird. Lässt sich nicht ausschließen, dass das gewählte Trennzeichen in Schlüsselfeldern vorkommt, kann auch ein Mapping über eine GUID Funktion abgebildet werden. GUIDs (Global Unique ID; weltweit eindeutige Identifikationsnummer) können innerhalb des SAP-Systems mit dem Funktionsbaustein "GUID_CREATE" erzeugt werden.

e) Meldungen

Meldungen, die in SAP erzeugt werden können (z.B. Warn- oder Fehlermeldungen) können auch für das externe aufrufende System von Bedeutung sein. Deshalb ist es generell möglich, Nachrichten an das externe System in einer Meldungstabelle (technischer Name "ZIA_IXA_API_INTREXX_MESSAGES") zu übertragen.

NrFeldnameDatenelementDatentypLängeBeschreibung
1TYPEBAPI_MTYPECHAR1Meldungstyp
2MESSAGEBAPI_MSGCHAR220Meldungstext
3TECH_IDSYMSGIDCHAR20Nachrichtenklasse
4TECH_NOSYMSGNONUMC3Nachrichtennummer

Die verwendete Struktur ähnelt der aus den BAPIs gewohnten Struktur "BAPIRET2". Auf die eher technischen Informationen wurde allerdings verzichtet, da die externen Systeme meistens nicht in der Lage sind, diese Informationen zu verarbeiten. Relevant sind in diesem Umfeld nur die Felder 1-2, die den Meldungstyp und den anzuzeigenden Text enthalten. Die Felder 3-4 sind SAP-spezifisch und nur zur Fehlersuche durch Entwickler/Administratoren mit SAP Zugriff geeignet. Der Meldungstyp aus Feld 1 bestimmt den Erfolg einer Aktion. Das externe System sollte die übergebenen Werte wie folgt interpretieren:

MeldungstypBedeutung im SAPExterne Bedeutung für das aufrufende System
EEs sind Fehler aufgetreten.Fehlermeldung ausgeben.
ADie Funktion musste abgebrochen werden.Fehlermeldung ausgeben.
XEs ist eine schwere Ausnahme aufgetreten.Fehlermeldung ausgeben.
WDie Funktion wurde mit Warnungen beendet.Funktion erfolgreich. Evtl. Warnmeldung ausgeben.
IDie Funktion wurde erfolgreich beendet. Es liegen Meldungen zur Information des Anwenders vor.Funktion erfolgreich.
SDie Funktion wurde erfolgreich beendet. Es liegen Statusmeldungen vor.Funktion erfolgreich.

f) Filterkriterien

Filterkriterien – wie sie z.B. bei der Selektion von Daten in der API-Methode "get_List" verwendet werden – werden innerhalb der API tabellarisch übergeben (technischer Name der Struktur: "ZIA_IXA_API_INTREXX_FILTER").

NrFeldnameDatenelementDatentypLängeBeschreibung
1SELPOSNUMC4Position der Filterzeile. Wird für die Sortierung verwendet.
2COMBINECHAR5Art der Kombination zur Vorgängerzeile. Mögliche Werte: <AND|OR>. Für die erste Filterzeile spielt dieses Feld keine Rolle und wird nicht ausgewertet. Trotzdem wird es mit AND gefüllt.
3LPARENTHESISINT13Anzahl der öffnenden Klammern
4FIELDNAMECHAR30Feldname des gefilterten Datenobjektes
5OPERANDCHAR2Operand (s. mögliche Werte)
6VALUE_LOWCHAR70Feldwert
7VALUE_HIGHCHAR70Feldwert2 für Intervall-Operanden
8RPARENTHESISINT13Anzahl der schließenden Klammern

Mögliche Operanden (Feld 5) sind:

OperandBedeutung
EQ=gleich
NE<>ungleich
LE<=kleiner gleich
GE>=größer gleich
LT<kleiner
GT>größer
BTbetweenim Intervall von <value_low> und <value_high>
CPlikeentspricht dem Muster

Mit dieser Tabelle können selbst komplexe WHERE-Klauseln mit Klammerungen übergeben werden. Das Beispiel
WHERE  ( FIELDNAME1 = 'HAMBURG' OR FIELDNAME1 LIKE '*dorf' ) AND ( FIELDNAME2 = 1 OR FIELDNAME2 = 2 )
würde wie folgt abgebildet werden:



Als Wildcard wird das Zeichen * verwendet. Dieses muss dann ggf. je nach tatsächlichem Verfahren in das für Datenbanken übliche Zeichen % gemappt werden.

g) Angeforderte Datenfelder

In manchen Funktionen wird eine Tabelle (technischer Namen der Struktur "ZIA_IXA_API_INTREXX_RQ_FLDS") mit den Feldnamen übergeben, die übertragen werden sollen. Hintergrund dieser Funktionalität ist, dass nur Informationen übertragen werden müssen, die vom externen aufrufenden System auch verarbeitet (z.B. angezeigt) werden. Die führende SAP Tabelle enthält z.B. für den Geschäftspartner (Tabelle "BUT000") mehr als 80 mögliche Spalten. In vielen Szenarien werden nur ungefähr 10 Spalten extern benötigt. Es würden also ohne diese Funktionalität 8mal so viele Felder übertragen werden, wie benötigt. Diese unnötigen Datentransfers führen bei großen Selektionen unweigerlich zu Performanceproblemen. Die Tabelle enthält nur eine Spalte, die mit den Feldnamen der benötigten Felder gefüllt ist. Ist diese Tabelle leer, wird alles übertragen.

h) Sortieranweisungen

Für die sortierte Selektion von Daten sind Anweisungen notwendig, die in einer Tabelle (technischer Name der Struktur "ZIA_IXA_API_INTREXX_ORDERBY") übergeben werden.

NrFeldnameDatenelementDatentypLängeBeschreibung
1ORDERPOSNUMC4Position innerhalb der Tabelle
2FIELDNAMEZIA_IXA_FIELDNAMECHAR30Feldname
3ORDERTYPEZIA_IXA_ORDERBY_ORDERCHAR1Sortierung; mögliche Werte:
A - aufsteigend
D - absteigend

API RFC Funktionen

Dieser Abschnitt beschreibt die extern aufgerufenen API Funktionsbausteine. Allen gemeinsam ist, dass bestimmte Parameter in allen Funktionen verwendet werden, die im Detail später nicht mehr beschrieben sind.

ParameterBedeutung
IS_CONTROLKontrollstruktur; enthält Informationen zum Aufrufer und wird zur Ermittlung des Verarbeitungsmoduls verwendet.
ET_MESSAGESEnthält Meldungen der Struktur
EV_ERROREnthält "X", wenn der Aufruf der API-Methode mit Fehlern beendet wurde. Bei fehlerfreier Ausführung ist dieser Parameter nicht gefüllt. Evtl. vorhandene Fehlermeldungen enthält der Parameter "ET_MESSAGES".

a) get_DataObjects

Die API-Methode "get_DataObjects" ermittelt die möglichen Datenobjekte eines Verarbeitungsmoduls. Extern wird dazu der RFC Funktionsbaustein "Z_IA_IXA_API_GET_DATA_OBJECTS" aufgerufen.
FUNCTION z_ia_ixa_api_get_data_objects.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"	IMPORTING
*"		VALUE(IS_CONTROL) TYPE  ZIA_IXA_API_INTREXX_CONTROL
*"		VALUE(IV_MAX_ROWS) TYPE  SYTABIX DEFAULT 100
*"		VALUE(IV_WILDCARD) TYPE  ZIA_IXA_FIELDVALUE OPTIONAL
*"	EXPORTING
*"		VALUE(EV_ERROR) TYPE  XFELD
*"	TABLES
*"		ET_MESSAGES STRUCTURE  ZIA_IXA_API_INTREXX_MESSAGES OPTIONAL
*"		ET_DATA_OBJECTS STRUCTURE  ZIA_IXA_API_INTREXX_DATAOBJ OPTIONAL
*"----------------------------------------------------------------------
Eine Einschränkung über Wildcards (Parameter "IV_WILDCARD"; Wildcardzeichen *) ist zu ermöglichen. Aus Performancegründen kann die maximale Anzahl der Treffer über den Parameter "IV_MAX_ROWS" eingeschränkt werden. Die Werte 0 oder <0 bedeuten, dass keine Treffereinschränkung aktiv ist. Die verfügbaren Datenobjekte werden im Parameter "ET_DATA_OBJECTS" an das aufrufende System übergeben.

b) get_MetaInfo

Die API-Methode get_MetaInfo ermittelt die technischen Eigenschaften eines Datenobjektes. Extern wird dazu der RFC Funktionsbaustein "Z_IA_IXA_API_GET_METAINFO" aufgerufen.
FUNCTION Z_IA_IXA_API_GET_METAINFO
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"	IMPORTING
*"		VALUE(IS_CONTROL) TYPE  ZIA_IXA_API_INTREXX_CONTROL
*"	EXPORTING
*"		VALUE(EV_ERROR) TYPE  XFELD
*"	TABLES
*"		ET_MESSAGES STRUCTURE  ZIA_IXA_API_INTREXX_MESSAGES OPTIONAL
*"		ET_RESULT_VALUES STRUCTURE  ZIA_IXA_API_INTREXX_FIELDS OPTIONAL
*"		ET_RESULT_KEYS STRUCTURE  ZIA_IXA_API_INTREXX_KEYS OPTIONAL
*"----------------------------------------------------------------------
Die technischen Eigenschaften werden in den Parametern "ET_RESULT_VALUES" und "ET_RESULT_KEYS" übertragen (weitere Informationen unter Datenaustausch und Schlüsselinformationen). Entgegen der dort dargestellten Füllvorschrift wird hier eine abweichende Datenübertragung abgebildet. Grundlage für die Übertragung sind Informationen in der Struktur "DFIES". Diese werden beispielsweise über den SAP Funktionsbaustein "DDIF_FIELDINFO_GET" ermittelt. Welche Informationen der Struktur "DFIES" das externe aufrufende System für seine Zwecke verwendet, entscheidet dieses für sich. Sicher ist, dass das Feld "FIELDNAME" grundlegend für die externe Abbildung sein wird. Die folgenden beiden Abbildungen zeigen die notwendige Transformation der technischen Informationen in die Export-Parameter. Die Tabelle "ET_RESULT_KEYS" enthält die Feldnamen des Datenobjektes, "ET_RESULT_KEYS" weitere Details zum Feld.



c) get_List

Die API-Methode "get_List" ermittelt Datensätze zu einem Datenobjekt. Extern wird dazu der RFC Funktionsbaustein "Z_IA_IXA_API_GET_LIST" aufgerufen.
FUNCTION z_ia_ixa_api_get_list
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"	IMPORTING
*"		VALUE(IS_CONTROL) TYPE  ZIA_IXA_API_INTREXX_CONTROL
*"		VALUE(IV_MAX_ROWS) TYPE  SYTABIX DEFAULT 100
*"		VALUE(IV_START_ROW) TYPE  SYTABIX DEFAULT 0
*"		VALUE(IV_ORDERBY) TYPE  ZIA_IXA_FIELDNAME OPTIONAL
*"		VALUE(IV_CHECK_LANGUAGE) TYPE  XFELD DEFAULT ' '
*"	EXPORTING
*"		VALUE(EV_ERROR) TYPE  XFELD
*"		VALUE(EV_COUNT) TYPE  ZIA_IXA_LIST_COUNT
*"	TABLES
*"		IT_FIELDS STRUCTURE  ZIA_IXA_API_INTREXX_FIELDS OPTIONAL
*"		ET_MESSAGES STRUCTURE  ZIA_IXA_API_INTREXX_MESSAGES OPTIONAL
*"		ET_RESULT_VALUES STRUCTURE  ZIA_IXA_API_INTREXX_FIELDS OPTIONAL
*"		ET_RESULT_KEYS STRUCTURE  ZIA_IXA_API_INTREXX_KEYS OPTIONAL
*"		IT_FILTER STRUCTURE  ZIA_IXA_API_INTREXX_FILTER OPTIONAL
*"		IT_REQUESTED STRUCTURE  ZIA_IXA_API_INTREXX_RQ_FLDS OPTIONAL
*"		IT_ORDERBY STRUCTURE  ZIA_IXA_API_INTREXX_ORDERBY OPTIONAL				
*"----------------------------------------------------------------------
Die einschränkenden Merkmale werden im Parameter "IT_FILTER"(vgl. Filterkriterien) übergeben. Alternativ wurde die Möglichkeit geschaffen, über die Felder IT_FIELDS (vgl. Datenaustausch) eine einfache Selektionsmaske zu implementieren. Die Tabelle "IT_FIELDS" würde dann Feldnamen und die gewünschten Werte (auch mit Wildcard) enthalten, über die selektiert werden soll. Welche der beiden Selektionsmöglichkeiten umgesetzt wird, entscheiden das externe aufrufende System und das ermittelte Verarbeitungsmodul. Wenn möglich, sollte die Alternative über "IT_FILTER" umgesetzt werden. Die Anzahl der ermittelten Datensätze wird im Parameter "EV_COUNT" übergeben. Aus Performancegründen wurde über die Parameter "IV_MAX_ROWS" und "IV_START_ROW" ein Offset-Zugriff auf die Daten ermöglicht. Damit kann ein externes Blättern in sehr großen Datenmengen ermöglicht werden, indem nur "<IV_MAX_ROWS>" Datensätze ab dem "<IV_START_ROW>" Datensatz übertragen werden. Der Wert 0 im Parameter "IV_START_ROW" deaktiviert diese Funktion. Benötigt das externe aufrufende System eine Sortierung der Daten, kann es dies durch den Parameter "IT_ORDERBY" (vgl. Sortieranweisungen) bzw. "IV_ORDERBY" bekannt geben. Eine Sortierung der Daten beim Aufrufer ist nicht sinnvoll, da dies nur funktioniert, wenn alle Daten übertragen werden. Bei großen Datenmengen, die nur via Offset-Zugriff sinnvoll verarbeitet werden können, ist eine Sortierung kaum möglich. Der Parameter "IT_ORDERBY" hat Priorität vor "IV_ORDERBY". Ist die Tabelle gefüllt, wird diese Sortieranweisung verarbeitet. Der Parameter "IV_CHECK_LANGUAGE" steuert die Auswertung der externen Anmeldesprache. Gerade bei der Selektion von sprachabhängigen Customizingtabellen kann dieser Parameter (aktiviert durch "X") das Filtern aller Datensätze steuern, die nicht der externen Sprache entsprechen. Die ermittelten Datensätze werden in den Parametern "ET_RESULT_VALUES" und "ET_RESULT_KEYS" bereitgestellt. Das Füllen dieser Ergebnistabellen wird in Kapitel Datenaustausch und Schlüsselinformationen detailliert beschrieben. Der Parameter "IT_REQUESTED" (vgl. Angeforderte Datenfelder) enthält die Datenfelder, die vom Aufrufer explizit angefordert werden. Auch hiermit lässt sich die Performance von Selektionen positiv beeinflussen, in dem nicht angeforderte Datenfelder nicht übertragen werden. Ist dieser Parameter nicht gefüllt, werden alle Datenfelder übertragen.

d) get_Detail

Diese Methode ermittelt Details eines Datensatzes, der eindeutig über den übergebenen Schlüssel identifiziert wird. Extern wird dazu der der RFC Funktionsbaustein "Z_IA_IXA_API_GET_DETAIL" aufgerufen.
FUNCTION z_ia_ixa_api_get_detail
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"	IMPORTING
*"		VALUE(IS_CONTROL) TYPE  ZIA_IXA_API_INTREXX_CONTROL
*"		VALUE(IV_KEY) TYPE  ZIA_IXA_FIELDVALUE
*"	EXPORTING
*"		VALUE(EV_ERROR) TYPE  XFELD
*"	TABLES
*"		ET_MESSAGES STRUCTURE  ZIA_IXA_API_INTREXX_MESSAGES OPTIONAL
*"		ET_RESULT_VALUES STRUCTURE  ZIA_IXA_API_INTREXX_FIELDS OPTIONAL
*"		IT_REQUESTED STRUCTURE  ZIA_IXA_API_INTREXX_RQ_FLDS OPTIONAL
*"----------------------------------------------------------------------
Der Parameter "IV_KEY" enthält den Schlüssel des Datensatzes, so wie er beispielsweise durch die API-Methode "get_List" ermittelt wird (vgl. Schlüsselinformationen). Die Ergebnisse werden im Parameter "ET_RESULT_VALUES" übergeben. Das Füllen dieser Tabelle beschreibt das Kapitel Datenaustausch. Da nur ein Datensatz betroffen sein kann, werden folgende Konstanten vorausgesetzt: Die Datenmenge kann über den Parameter "IT_REQUESTED" (vgl. Angeforderte Datenfelder) begrenzt werden, falls gefüllt.

e) modify

Die API-Methode "modify" erlaubt das Einfügen neuer bzw. das Ändern existierender Datensätze. Extern wird dazu der RFC Funktionsbaustein "Z_IA_IXA_API_MODIFY" aufgerufen.
FUNCTION z_ia_ixa_api_modify
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"	IMPORTING
*"		VALUE(IS_CONTROL) TYPE  ZIA_IXA_API_INTREXX_CONTROL
*"		VALUE(IV_KEY) TYPE  ZIA_IXA_FIELDVALUE OPTIONAL
*"	EXPORTING
*"		VALUE(EV_ERROR) TYPE  XFELD
*"		VALUE(EV_KEY) TYPE  ZIA_IXA_FIELDVALUE
*"	TABLES
*"		ET_MESSAGES STRUCTURE  ZIA_IXA_API_INTREXX_MESSAGES OPTIONAL
*"		ET_FIELDS STRUCTURE  ZIA_IXA_API_INTREXX_FIELDS OPTIONAL
*"		IT_FIELDS STRUCTURE  ZIA_IXA_API_INTREXX_FIELDS OPTIONAL
*"----------------------------------------------------------------------
Der Parameter IV_KEY enthält den Schlüssel eines existierenden Datensatzes (vgl. Schlüsselinformationen). Ein Wert -1 bzw. ein nicht gefüllter Parameter "IV_KEY" kennzeichnen einen neuen Datensatz. Die Datenfelder werden im Parameter "IT_FIELDS" (vgl. Datenaustausch) übergeben. Alter und neuer Schlüssel (bei neuen Datensätzen) werden im Parameter "EV_KEY" erwartet. Prinzipiell können Anforderungen bestehen, dass einzelne Datenfelder innerhalb der Verarbeitungsmodule angepasst werden sollen. Deshalb müssen im Parameter "ET_FIELDS" die tatsächlichen Werte an den Aufrufer zurückgegeben werden. Zur Vereinfachung kann "ET_FIELDS" als Kopie von "IT_FIELDS" erzeugt werden. Die API-Methode "modify" kann eine Besonderheit für den Datahandler "GENERIC_STORE" enthalten. Dieser Handler ermöglicht – laut Definition aus dem Kapitel Datahandler - die Modellierung von Datengruppen im externen Aufrufer und die Speicherung der Daten im SAP. Dazu muss das SAP-System Informationen über die Beschaffenheit der eintreffenden Daten aus dem externen System erhalten. Dies wurde in den Referenzimplementierungen mit Intrexx so gelöst, das im Parameter "IT_FIELDS" zusätzlich zu den Datenfeldern ("STRUC_NAME = "DEFAULT"") Informationen über die Metainformationen ausgetauscht werden ("STRUC_NAME = "TRANSFER""). Der folgende Screenshot zeigt die Funktion im Debugmodus.

f) delete

Die API-Methode "delete" ermöglicht das Entfernen von existierenden Datensätzen aus dem Datenobjekt. Extern wird dazu der RFC Funktionsbaustein "Z_IA_IXA_API_DELETE" aufgerufen.
FUNCTION z_ia_ixa_api_modify
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"	IMPORTING
*"		VALUE(IS_CONTROL) TYPE  ZIA_IXA_API_INTREXX_CONTROL
*"		VALUE(IV_KEY) TYPE  ZIA_IXA_FIELDVALUE OPTIONAL
*"	EXPORTING
*"		VALUE(EV_ERROR) TYPE  XFELD
*"	TABLES
*"		ET_MESSAGES STRUCTURE  ZIA_IXA_API_INTREXX_MESSAGES OPTIONAL
*"		ET_FIELDS STRUCTURE  ZIA_IXA_API_INTREXX_FIELDS OPTIONAL
*"----------------------------------------------------------------------
Der zu löschende Datensatz wird über Parameter "IV_KEY" identifiziert (vgl. Schlüsselinformationen). Der Parameter "ET_FIELDS" (vgl. Datenaustausch) enthält die Datenfelder des gelöschten Datensatzes.

g) update_temp_key

Die API-Methode "update_temp_key" ermöglicht das gleichzeitige Halten der Daten im externen System und im SAP. Extern wird dazu der RFC Funktionsbaustein "Z_IA_IXA_API_UPDATE_TEMP_KEY" aufgerufen.
FUNCTION z_ia_ixa_api_update_temp_key
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"	IMPORTING
*"		VALUE(IS_CONTROL) TYPE  ZIA_IXA_API_INTREXX_CONTROL
*"		VALUE(IV_KEY) TYPE  ZIA_IXA_FIELDVALUE OPTIONAL
*"		VALUE(IV_KEY_NEW) TYPE  ZIA_IXA_FIELDVALUE OPTIONAL
*"		EXPORTING
*"		VALUE(EV_ERROR) TYPE  XFELD
*"		VALUE(EV_KEY) TYPE  ZIA_IXA_FIELDVALUE
*"	TABLES
*"		ET_MESSAGES STRUCTURE  ZIA_IXA_API_INTREXX_MESSAGES OPTIONAL
Mit dieser API-Methode können Szenarien abgebildet werden, in denen die extern erfassten Daten erst durch das SAP-System geprüft werden (API-Methode "modify"). Im SAP bekommen die Daten einen temporären Schlüssel (z.B. GUID). Erst nach einer fehlerfreien Prüfung durch das SAP werden die Daten extern gespeichert. Der dort vergebene Schlüssel wird dann erneut an SAP gesendet, um die Beziehung zwischen den Daten zu erhalten. Der Parameter "IV_KEY" enthält den temporären Schlüssel, "IV_KEY_NEW" den Schlüssel aus dem externen System. "EV_KEY" enthält den Schlüssel, unter dem der Datensatz zukünftig im SAP identifiziert werden kann. Dieser sollte den Wert aus "IV_KEY_NEW" enthalten. Das Verhalten solcher Szenarien hängt vor allem vom Zusammenspiel externer Aufrufer und SAP-internes Verarbeitungsmodul ab.

6. Verarbeitungsmodule

Als Verarbeitungsmodule werden hier ABAP Objects Klassen bezeichnet, welche nach der Objekterzeugung die Aufrufe aus der RFC API entgegen nehmen und verarbeiten.

API Interface

Die API-Methoden der Verarbeitungsmodule sind im Interface "Z_IF_IA_IXA_INTREXX_API" implementiert.



Jede API-Methode aus RFC API hat im Interface eine Entsprechung. Zusätzlich sind noch zwei weitere Interface-Methoden verfügbar:

MethodeBedeutung
INITIALIZEWird sofort nach dem create object innerhalb der RFC API aufgerufen. Kann zum Initialisieren von Default-Werten u.ä. verwendet werden.
PREPARE_USAGE_AFTER_CREATIONDer Aufruf erfolgt vor dem Aufruf der eigentlichen API-Methode. Diese Methode eignet sich zum Erstellen von dynamischen Datenstrukturen oder dem Setzen von Parametern.

Die API-Methoden des Interfaces bilden die Parameter der RFC API 1:1 ab. Das folgende Beispiel zeigt die API-Methode "get_List" im Interface.



In jeder Interfacemethode fehlt der Parameter "IS_CONTROL". Dieser ist als Attribut "ME->IX_CONTROL" der Objektinstanz verfügbar (vgl. Root Objekt). Zusätzlich ist der Parameter "CV_PROCESSED" in jeder API-Methode des Interfaces enthalten. Über diesen Parameter kann die RFC API erkennen, ob die aufgerufene API-Methode durch das Verarbeitungsmodul zur Verfügung steht. Auf diese Weise wird z.B. im externen aufrufenden System erkannt, dass ein Verarbeitungsmodul ein "modify" nicht zur Verfügung stellt.

Jede Implementierung muss diesen Parameter CV_PROCESSED auf "X" setzen, unabhängig davon, ob die Methode fehlerfrei oder mit Fehlern verarbeitet wurde.

Zum Melden von Fehlern steht der Parameter "EV_ERROR" im Zusammenhang mit der Meldungstabelle "ET_MESSAGES" zur Verfügung (vgl. API RFC Funktionen).

Root Objekt

Als Mutter aller Verarbeitungsmodule wird die Klasse "Z_CL_IA_IXA_ROOT" verwendet. Alle Verarbeitungsmodule müssen von dieser Klasse bzw. einer der Nachfahren dieser Klasse vererbt sein. Dieses Root-Objekt ist eher abstrakt, implementiert aber das API Interface aus Api Interface und einige Attribute und Methoden. Die folgende Abbildung zeigt das Root-Objekt mit einigen Musterimplementierungen für Verarbeitungsmodule als Nachfahren, wie sie für SAP Gateway Systeme sowie (abwärtskompatibel) für SAP-Systeme mit 4.6 Basissystem zur Verfügung stehen.

Registrierung von Verarbeitungsmodulen

Neue Verarbeitungsmodule können einfach durch Vererbung bestehender Klassen aus der CORE API (vgl. Root Objekt) oder bereits vererbten eigenen Verarbeitungsmodule erzeugt werden. Das Anlegen neuer Verarbeitungsmodule wird im Kapitel Implementierung eigener Verarbeitungsmodule beschrieben. Jedes Verarbeitungsmodul muss registriert werden, bevor es verwendet werden kann. Dies erfolgt über eine Customizingtabelle und ist in Kapitel Customizing - Findung von Verarbeitungsmodulen dokumentiert.

Findung von Verarbeitungsmodulen

Aus dem externen System (z.B. Intrexx) stehen Informationen zur aufrufenden externen Datengruppe zur Verfügung. Das sind in jedem Fall der Datahandler und eine eindeutige Kennung des Datenobjektes. Diese Informationen und weitere sind über die Kontrollstruktur verfügbar.

Über diese Informationen wird ein Verarbeitungsmodul über eine Customizingtabelle ermittelt (beschrieben in Kapitel Mapping externer Datengruppen auf Verarbeitungsmodule). Sollte es nicht möglich sein, über das dort abgebildete Mapping zwischen externen Datengruppen und SAP-internen Verarbeitungsmodulen einen passenden Eintrag zu ermitteln, wird das Verarbeitungsmodul verwendet, das unter 0 als Voreinstellung konfiguriert wurde. Meistens wird dies das Verarbeitungsmodul für den Datahandler "GENERIC_VIEW" sein, da ein Zugriff auf SAP Tabellen und Views am wahrscheinlichsten ist.

7. Customzing

Die Customizingtabellen des SAP Portal Plugins wurden teilweise ohne Tabellenpflegedialog angelegt, um abwärtskompatibel bis zur 4.6 Basis zu sein. Die Tabellen sind deshalb entweder über Transaktion SM30 oder über SE16 pflegbar. In den folgenden Abschnitten sind alle Screenshots über die Transaktion SE16 entstanden. Die Ansichten können je nach Systemversion und Pflegetransaktion voneinander abweichen.

Grundeinstellungen

Die Customizingtabelle "ZIAC_IXACONFIG" enthält Grundeinstellungen des SAP Portal Plugins.



Die Felder haben folgende Bedeutung:

FeldBedeutung
DEFOBJECTLegt das Verarbeitungsmodul fest, das verwendet wird, wenn dies nicht durch andere Einstellungen bereits vorgegeben ist. Voreinstellung ist das Verarbeitungsmodul "GENERIC_VIEW".
LOG_ACTIVEAktiviert das Loggen aller API Aktionen.
BALLOG_ACTIVEAktiviert das Loggen aller Meldungen (vgl. Meldungen und Logging).
NEWDGREGISTERName des Funktionsbausteins, der für den Datahandler GENERIC_STORE bisher unbekannte externe Datengruppen registriert.

Findung von Verarbeitungsmodulen

Die folgenden Customizingtabellen sind für die Findung von Verarbeitungsmodulen zuständig.

a) Registrierung Verarbeitungsmodule

Die Tabelle "ZIAC_IXAOBJECTS" enthält registrierte Verarbeitungsmodule. Hier sind vor allem die ABAP Objects Klassen hinterlegt.





FeldBedeutung
OBJECTTYPEEindeutiger Name für das Verarbeitungsmodul. Es wurde keine Namenskonvention festgelegt. Bisher wurden "GENERIC*" für generische Verarbeitungsmodule und "BAPI*" für BAPI-nahe Business Objekte verwendet.
CLASSDer Name der Verarbeitungsklasse (ein Erbe des Root Objektes bzw. einer seiner Nachfahren).
STRUC_TRANSFERDer Name einer DDIC-Struktur, der für den Datenaustausch mit dem externen Aufrufer verwendet wird. Ist dieser Wert gefüllt, kann die API-Methode "get_MetaInfo" auf diesen Wert zurückgreifen und braucht nicht redefiniert zu werden.
STRUC_DATAKann verwendet werden, um interne Datenstrukturen generisch zu erzeugen.
MASTER_TABKann verwendet werden, um generische Select-Statements zu verwenden.
CUSTOMIZING_TABKann verwendet werden, um generische Zugriffe auf Customizingtabellen zu ermöglichen.
FIELD_KEYName des Feldes innerhalb der <MASTER_TAB>, welches den eindeutigen Schlüssel enthält.
PARAMETER*Kann als zusätzliches Customizing verwendet werden, um beispielsweise mit einer Verarbeitungsklasse unterschiedliche Verhaltensweisen zu ermöglichen. Diese Parameter stehen innerhalb der Verarbeitungsklasse zur Verfügung (vgl. Vererbte Attribute des Root Objektes).

Unbedingt notwendig ist die Pflege des "<OBJECTTYPE>" und "< CLASS>". Falls "<STRUC_TRANSFER>" gepflegt und das Verarbeitungsmodul ein Nachfahre des "GENERIC_VIEW"-Verarbeitungsmoduls ist, kann die dort implementierte Methode "get_MetaInfo" verwendet werden.

b) Mapping externer Datengruppen auf Verarbeitungsmodule

Die Tabelle "ZIAC_IXAMAPOBJ" enthält Informationen darüber, welche externe Datengruppe auf welches Verarbeitungsmodul gemappt wird.



FeldBedeutung
DATAHANDLERBestimmt den extern verwendeten Datahandler.
IX_DATAGROUPExtern verwendete Datengruppe (z.B. Tabellenname).
IX_DATARANGEWeitere optionale Einschränkung einer Sicht zur Datengruppe (im Normalfall leer).
IX_OBJECTTYPEFestlegung, welches Verarbeitungsmodul für diese Kombination aus DATAHANDLER + IX_DATAGROUP [+ IX_DATARANGE] verwendet werden soll.
PARAMETER*Die Parameter können innerhalb der Verarbeitungsmodule als zusätzliche Steuerparameter verwendet werden.
IX_LOCKINGSperrkonzept aktivieren (= X).
IX_TIMEOUTTimeout Parameter für das Sperrkonzept.
EXIT_FUNCTIONDieser Parameter enthält den Namen eines Funktion sbausteins, der innerhalb der Verarbeitungsmodule als Exit verwendet werden kann. Ob dieser Exit benutzt wird, liegt am Verarbeitungsmodul
MAPPED_DATAGROUPFalls dieser Parameter gefüllt ist, wird der Parameter "IX_DATAGROUP" als Alias behandelt. Bei der Verarbeitung wird dann der Parameter "<MAPPED_DATAGROUP>" verwendet. Diese Option kann sinnvoll sein, wenn die gleiche Datengruppe (z.B. SAP Customizingtabelle) mit dem gleichen Verarbeitungsmodul (z.B. "GENERIC_VIEW") auf unterschiedliche Weisen verarbeitet werden soll (z.B. Variante 1: als reale Tabelle; Variante 2: als Texttabelle für das Auslesen von Customizingdaten)
TRACE_ACTIVEFalls der Parameter gesetzt (= X) ist, werden Meldungen für diese Datengruppe mitgeloggt.

8. Berechtigungskonzept

Der Zugriff auf SAP Datenobjekte wird im SAP Portal Plugin über die Berechtigungsobjekte geschützt. Zusätzlich sind noch weitere Berechtigungen notwendig, um den externen Zugriff via RFC zu ermöglichen. Im Einzelnen handelt es sich um folgende Berechtigungen, die dem Servicebenutzer für den Portalzugriff mindestens zur Verfügung stehen müssen:

BerechtigungsobjektBerechtigungenWert
ZIA_IXA_ACAktivität01, 02, 03, 06, 16
IXA: Funktion der Intrexx-APIdelete, getdataobj, getdetail, getlist, getmeta, modify, update_k
ZIA_PISAPESB: API FunktionGETDATA, GETDATAOBJ, GETDIST, GETF4, GETMETA
ESB: ID einer Datasource*
S_RFCAktivität16
Name des zu schützenden RFC-ObjektesRFC1, SDIFRUNTIME, SLCH, SLST, SYST, SYSU, ZIA_IXA_API
Typ des zu schützenden RFC-ObjektesID
ESB: ID einer DatasourceFUGR
S_TABU_DISAktivität02
Berechtigungsgruppe&NC&

Falls Sie den Servicebenutzer mit "SAP_ALL" ausstatten, denken Sie bitte daran, dass auch dieses Profil erst neu generiert werden muss, um die neuen Berechtigungsobjekte aus dem SAP Portal Plugin zu akzeptieren. Dies kann beispielsweise mit Transaktion "SU28" erfolgen. Sollte es zu Berechtigungsproblemen kommen bzw. Sie wünschen eine weitere Einschränkung, können Sie den Berechtigungstrace (ST05) dazu verwenden, die verwendeten Werte zu bestimmen.

9. Sonstige Frameworkfunktionen

Logging

a) Logging aller API Zugriffe

Die Tabelle "ZIAM_IXALOG" enthält Informationen über jeden Zugriff auf die RFC API, falls das Logging im Customizing (vgl. Grundeinstellungen) aktiviert wurde ("Flag LOG_ACTIVE").



Die Datensätze enthalten Informationen zum Ausführung sowie Informationen vom externen Aufrufer.



Über die Transaktion ZIA_IXA_LOG können diese Informationen durch einen Report ausgewertet werden.

Erweitertes Logging von Messages

Eine weitere Möglichkeit des Loggings und besonders für die Fehlersuche geeignet ist das Anwendungslog (Transaktion SLG1). Die wird über das Flag BALLOG_ACTIVE (vgl. Grundeinstellungen) aktiviert. Sind beide Loggings aktiviert, werden alle Fehlermeldungen des API Parameters "ET_MESSAGES" (vgl. Meldungen) in das Anwendungslog geschrieben und sind mit Transaktion SLG1 auswertbar.



Als Externer Identifikator wird dabei die Session-GUID aus dem Kapitel Kontrollstruktur verwendet. Diese enthält im Normalfall die Identifikation einer Internet-Session.



Über die Session-GUID können die Datensätze der Logtabelle "ZIAM_IXALOG" wieder miteinander verknüpft werden. Die Nachricht enthält in Klammern die SAP Nachrichtenklasse und Nachrichtennummer (falls verfügbar). Der Verursacher der Meldung kann dann evtl. über Transaktion SE91 und Verwendungsnachweis ermittelt werden. Weiterhin ist evtl. eine Fehlersuche im OSS möglich, falls die Meldungen aus BAPI-Funktionen stammen.

Tracemode für die Fehlersuche

Für die Fehlersuche bei Verarbeitungsmodulen kann dieses Logging auch auf Nachrichten erweitert werden, die keine Fehlermeldungen sind. Dies ermöglicht z.B. die Ausgabe von Warn- und Statusmeldungen beim Aufruf von BAPI-Funktionen. Aktiviert wird der Tracemode über das Flag "TRACE_ACTIVE" in der Findung der Verarbeitungsmodule (vgl. Mapping externer Datengruppen auf Verarbeitungsmodule.)



Sperrkonzept

Im SAP Portal Plugin wurde ein einfaches Sperrkonzept vorbereitet, welches für den Einsatz im statuslosen Internetumfeld am besten geeignet scheint. Innerhalb der RFC API kann jeder Zugriff auf ein Objekt überwacht werden. Es können so mehrere Internet-Benutzer parallel auf einen SAP Datensatz zugreifen und sogar in den Ändernmodus wechseln, ohne sich gegenseitig zu sperren. Allerdings wird dann nur der erste Schreibzugriff zugelassen. Alle späteren schreibenden Zugriffe werden verweigert. Die folgende Grafik zeigt dieses Verhalten.



Die API Zugriffe werden mit Fehlern abgebrochen. Der Grund wird dem aufrufenden System im Parameter "ET_MESSAGES" mitgeteilt.



Eine zusätzliche Sperre kann integriert werden, in dem die Verarbeitungsmodule intern die SAP übliche Sperrlogik abbilden. Bei lesenden Zugriffen macht dies allerdings wenig Sinn, da externe Aufrufer dadurch evtl. SAP Transaktionen sperren könnten. Im Allgemeinen sollte es reichen, die SAP Sperren zum Zeitpunkt der Änderung zu prüfen. Werden BAPI-Aufrufe verwendet, wendet SAP dieses Verfahren genauso an – die Sperre wird erst zum Zeitpunkt des Schreibens verwendet.



Das oben beschriebene Sperrkonzept wird in der Findung der Verarbeitungsmodule aktiviert (Flag "IX_LOCKING"). Über den Timeout Parameter "IX_TIMEOUT"; Angabe in Sekunden) können zusätzlich die schreibenden Zugriffe parametrisiert werden. Der Screenshot zeigt diese Einstellung für das Musterbeispiel aus dem Kapitel Verarbeitungsmodule. Hier wird das Sperrkonzept des SAP Portal Plugins sowie die SAP-üblichen Sperren des Geschäftspartners verwendet.



Sie können diese Logik über parallele Änderungszugriffe über externen Zugriff und gleichzeitige Bearbeitung des SAP Geschäftspartners in Transaktion BP testen.

EXIT Funktionen

Konzeptionell wurde der Einsatz von EXIT-Bausteinen vorgesehen, die in den jeweiligen Verarbeitungsmodulen aufgerufen werden können. Die Zuordnung ist im Customizing der Findung eines Verarbeitungsmoduls möglich. Der eigentliche Aufruf ist Sache des Verarbeitungsmoduls. Die Schnittstelle des Funktionsbausteines kann sich am Template "Z_IA_IXA_API_EXIT_TEMPLATE" orientieren. Geeignet ist der Einsatz vor allem innerhalb der API-Funktion "MODIFY", um Daten zu prüfen bzw. Anzupassen.

Nummernkreise

Über die Methode "GET_NEW_NUMBER_KEY" steht eine einfache Nummerkreisverwaltung zur Verfügung, die als Schlüssel einen hochzählenden Integerwert ermittelt. Die Nummernkreise kommen ohne SAP Nummernkreisobjekt aus und werden je externe Datengruppe verwaltet.

Konvertierung Intern vs. Extern

Im Allgemeinen verwenden externe Systeme eine andere Darstellung von Datentypen als SAP. Als Beispiel soll der Datentyp "Datum" dienen. Hier verwendet SAP intern die Darstellung "<JAHR><MONAT><TAG>" (z.B. "20070626"). Extern wird häufig "2007-06-26" verwendet. Das Root-Objekt verwendet intern die beiden Methoden Durch Vererbung können eigene Konvertierungen implementiert werden.

10. Externe Nutzung des SAP Portal Plugin

Das hier beschriebene Plugin wurde vorrangig für die externe Nutzung durch Non-SAP-Systeme entwickelt. Um die hier beschriebene Funktionalität nutzen zu können, müssen die API-Funktionen in der gewünschten externen Programmiersprache zur Verfügung stehen. Hier eignen sich vor allem die von der SAP AG ausgelieferten Connectoren (http://service.sap.com/connectors). Allen voran der SAP Java Connector (SAP JCo) und der .Net-Connector. Beide bringen Generierungstools mit, die für eine komplexe SAP RFC API Proxy-Module in der jeweiligen Programmierwelt anlegen. Für Java eignet sich hier der SAP Enterprise Connector, der im SAP Gateway Developer Studio zur Verfügung steht.

11. Weitere Informationen

API Beschreibung- Entwicklerhandbuch Teil 3 - Implementierung eigener Verarbeitungsmodule