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

Entwicklungsziele
API Konzept
Erweiterungskonzept Verarbeitungsmodule
Datahandler
RFC API
Verarbeitungsmodule
Customzing
Berechtigungskonzept
Sonstige Frameworkfunktionen

API Beschreibung- Entwicklerhandbuch Teil 3 - Implementierung eigener Verarbeitungsmodule

Entwicklungsziele

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

• Keine JAVA Anpassungen für Anforderungen aus dem SAP-Umfeld
  Bei der Umsetzung von Portalprozessen im SAP Umfeld ist es wünschenswert, dass die Aufwände für die Realisierung von Oberflächen, Portalapplikationen und Rechtekonzepte erträglich bleiben. Unabdingbar ist aber die Klärung der Funktionalität (Pflichtenheft) und die Analyse der Umsetzbarkeit in den bestehenden SAP Funktionen. Das meist führende SAP-System bestimmt das Datenmodell und die umsetzbare Funktionalität. Für die Konzeption des Plugins war es deshalb wichtig, dass das Erweiterungskonzept innerhalb von SAP ABAP realisiert wird und die Schnittstelle zwischen den Systemen starr bleibt.
• Verwendung von Funktionen, die nicht als BAPI/RFC verfügbar sind
  Die SAP stellt über BAPIs und RFC-fähige Funktionsbausteinen eine Vielzahl von Funktionen bereit, die durch externe Systeme verwendet werden können. Vor allem die BAPIs sind Business-Objekt-orientiert ausgelegt und sollten den Anforderungen eines universellen Connectors genügen. Allerdings reicht eine Vielzahl der verfügbaren BAPIs (abh. vom Release) meist nicht aus, sind unvollständig oder teilweise fehlerhaft implementiert und jedes BAPI reagiert unterschiedlich. Wichtige Funktionen für Kundenprojekte sind oft nicht für externe Systeme verfügbar und müssten als BAPI bzw. RFC-Funktion realisiert werden. Für die Konzeption des Plugins wurde deshalb der Weg einiger weniger API-Methoden gewählt, die über RFC angesprochen werden können. Diese Aufrufe werden dann an andere Funktionen weitergeleitet, die die externen Anforderungen erfüllen.
• Definierte und überschaubare RFC API
  Der hier diskutierte Ansatz ermöglicht es vor allem, die Angriffsfläche auf das SAP System möglichst klein zu halten. Ein Wildwuchs von RFC Funktionen wird vermieden. Das Berechtigungskonzept ist leichter zu realisieren, da alle externen Aufrufe über ein gemeinsames Eingangstor kommen.

API Konzept

Aus den Entwicklungszielen ging eine kleine RFC-fähige API hervor, die im Wesentlichen folgende Funktionen implementiert:

• Get_MetaInfo
• Get_List
• Get_Detail
• Modify
• Delete

Weitere Details zur RFC API finden Sie hier.

Der Aufruf der RFC API erfolgt vom Fremdsystem (z.B. Portalsoftware Intrexx Xtreme) 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.

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.

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.

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:

• STRUC_NAME = "DEFAULT"
• STRUC_RECORD = "0"

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.

Nr	Feldname	Datenelement	Datentyp	Länge	Beschreibung
1	TYPE	BAPI_MTYPE	CHAR	1	Meldungstyp
2	MESSAGE	BAPI_MSG	CHAR	220	Meldungstext
3	TECH_ID	SYMSGID	CHAR	20	Nachrichtenklasse
4	TECH_NO	SYMSGNO	NUMC	3	Nachrichtennummer

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:

Meldungstyp	Bedeutung im SAP	Externe Bedeutung für das aufrufende System
E	Es sind Fehler aufgetreten.	Fehlermeldung ausgeben.
A	Die Funktion musste abgebrochen werden.	Fehlermeldung ausgeben.
X	Es ist eine schwere Ausnahme aufgetreten.	Fehlermeldung ausgeben.
W	Die Funktion wurde mit Warnungen beendet.	Funktion erfolgreich. Evtl. Warnmeldung ausgeben.
I	Die Funktion wurde erfolgreich beendet. Es liegen Meldungen zur Information des Anwenders vor.	Funktion erfolgreich.
S	Die 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).

Nr	Feldname	Datenelement	Datentyp	Länge	Beschreibung
1	SELPOS		NUMC	4	Position der Filterzeile. Wird für die Sortierung verwendet.
2	COMBINE		CHAR	5	Art 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.
3	LPARENTHESIS		INT1	3	Anzahl der öffnenden Klammern
4	FIELDNAME		CHAR	30	Feldname des gefilterten Datenobjektes
5	OPERAND		CHAR	2	Operand (s. mögliche Werte)
6	VALUE_LOW		CHAR	70	Feldwert
7	VALUE_HIGH		CHAR	70	Feldwert2 für Intervall-Operanden
8	RPARENTHESIS		INT1	3	Anzahl der schließenden Klammern

Mögliche Operanden (Feld 5) sind:

Operand	Bedeutung
EQ	=	gleich
NE	<>	ungleich
LE	<=	kleiner gleich
GE	>=	größer gleich
LT	<	kleiner
GT	>	größer
BT	between	im Intervall von <value_low> und <value_high>
CP	like	entspricht 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.

Nr	Feldname	Datenelement	Datentyp	Länge	Beschreibung
1	ORDERPOS		NUMC	4	Position innerhalb der Tabelle
2	FIELDNAME	ZIA_IXA_FIELDNAME	CHAR	30	Feldname
3	ORDERTYPE	ZIA_IXA_ORDERBY_ORDER	CHAR	1	Sortierung; 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.

Parameter	Bedeutung
IS_CONTROL	Kontrollstruktur; enthält Informationen zum Aufrufer und wird zur Ermittlung des Verarbeitungsmoduls verwendet.
ET_MESSAGES	Enthält Meldungen der Struktur
EV_ERROR	Enthä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:

• LISTRECORD = "1"
• STRUC_NAME = "DEFAULT"
• STRUC_RECORD = "0"

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.

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:

Methode	Bedeutung
INITIALIZE	Wird sofort nach dem create object innerhalb der RFC API aufgerufen. Kann zum Initialisieren von Default-Werten u.ä. verwendet werden.
PREPARE_USAGE_AFTER_CREATION	Der 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.

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:

Feld	Bedeutung
DEFOBJECT	Legt das Verarbeitungsmodul fest, das verwendet wird, wenn dies nicht durch andere Einstellungen bereits vorgegeben ist. Voreinstellung ist das Verarbeitungsmodul GENERIC_VIEW.
LOG_ACTIVE	Aktiviert das Loggen aller API Aktionen.
BALLOG_ACTIVE	Aktiviert das Loggen aller Meldungen (vgl. Meldungen und Logging).
NEWDGREGISTER	Name 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.

Feld	Bedeutung
OBJECTTYPE	Eindeutiger 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.
CLASS	Der Name der Verarbeitungsklasse (ein Erbe des Root Objektes bzw. einer seiner Nachfahren).
STRUC_TRANSFER	Der 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_DATA	Kann verwendet werden, um interne Datenstrukturen generisch zu erzeugen.
MASTER_TAB	Kann verwendet werden, um generische Select-Statements zu verwenden.
CUSTOMIZING_TAB	Kann verwendet werden, um generische Zugriffe auf Customizingtabellen zu ermöglichen.
FIELD_KEY	Name 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.

Feld	Bedeutung
DATAHANDLER	Bestimmt den extern verwendeten Datahandler.
IX_DATAGROUP	Extern verwendete Datengruppe (z.B. Tabellenname).
IX_DATARANGE	Weitere optionale Einschränkung einer Sicht zur Datengruppe (im Normalfall leer).
IX_OBJECTTYPE	Festlegung, 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_LOCKING	Sperrkonzept aktivieren (= X).
IX_TIMEOUT	Timeout Parameter für das Sperrkonzept.
EXIT_FUNCTION	Dieser 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_DATAGROUP	Falls 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_ACTIVE	Falls der Parameter gesetzt (= X) ist, werden Meldungen für diese Datengruppe mitgeloggt.

Berechtigungskonzept

Der Zugriff auf SAP Datenobjekte wird im SAP Portal Plugin über die Berechtigungsobjekte

• ZIA_IXA_AC
• ZIA_PISAP

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:

Berechtigungsobjekt	Berechtigungen	Wert
ZIA_IXA_AC	Aktivität	01, 02, 03, 06, 16
	IXA: Funktion der Intrexx-API	delete, getdataobj, getdetail, getlist, getmeta, modify, update_k
ZIA_PISAP	ESB: API Funktion	GETDATA, GETDATAOBJ, GETDIST, GETF4, GETMETA
	ESB: ID einer Datasource	*
S_RFC	Aktivität	16
	Name des zu schützenden RFC-Objektes	RFC1, SDIFRUNTIME, SLCH, SLST, SYST, SYSU, ZIA_IXA_API
	Typ des zu schützenden RFC-Objektes	ID
	ESB: ID einer Datasource	FUGR
S_TABU_DIS	Aktivität	02
	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.

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

• MAP_FIELDVALUE_IX_TO_SAP - Mappe externe Darstellung nach Intern
• MAP_FIELDVALUE_SAP_TO_IX - Mappe interne Darstellung nach Extern

Durch Vererbung können eigene Konvertierungen implementiert werden.

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.