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

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

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.

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 (https://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.

Weitere Informationen

Allgemeines

Installation

Verbindung erstellen

Integration in Applikationen

SAP Skript Generator

SAP Trust Manager SSO configuration

API Beschreibung Teil 1 - Übersicht

API Beschreibung Teil 3 - Implementierung eigener Verarbeitungsmodule

API Beschreibung Teil 4 - Beispielcodings

Entwicklerhandbuch Teil 1

Entwicklerhandbuch Teil 2 - Integrationsszenario SAP-Fremddatengruppe

Entwicklerhandbuch Teil 3 - Integrationsszenario Skripting

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

Entwicklerhandbuch Teil 5 - Addons

Entwicklerhandbuch Anhang

Entwicklerhandbuch - Mustercodings