Inhalt dieser Dokumentation ist die Beschreibung des SAP Portal-Plugins (Codename "SAPPOPI"), das für die SAP-Anbindung von Intrexx entwickelt wurde. Das SAP Portal-Plugin besteht aus Entwicklungen mit Framework-Charakter im Kundennamensraum, die auch für andere Portalprojekte bzw. Schnittstellen mit externen Systemen verwendet werden könnten. Diese Dokumentation ist vor allem für SAP Entwickler gedacht, die SAP Daten für Intrexx oder andere externe Systeme zur Verfügung stellen möchten.
Zu den aktuellen Nutzungsbedingungen des SAP-Portal-Plugins informieren Sie sich bitte auf www.intrexx.com. Die Nutzung der SAP-seitigen Funktionalität in eigenen Projekten ist für SAP Kunden gestattet, solange kein Dritter eigene kommerzielle Lösungen oder Produkte über das SAP-Portal-Plugin in SAP Systeme integriert. Das SAP-Portal-Plugin wird auf freiwilliger Basis gewartet. Für Schäden, die durch die Nutzung des SAP Portal Plugins entstehen, wird keine Haftung übernommen.
Konzeptioneller Ansatz
Alle Intrexx Datengruppen besitzen ein Schlüsselfeld (Feldname "STRID"), das in allen portal-internen Tabellen den Datentyp "String" hat. Intrexx unterstützt den Anwender bei der Modellierung von untergeordneten Datengruppen (abhängigen Daten) und Referenzen. Wiederum gilt: Unterdatengruppen enthalten einen eigenen eindeutigen Schlüssel und den Schlüssel des Elterndatensatzes (z.B. "FKSTRID" und "STRID"). In Intrexx-Applikationen können Daten aus externen Anwendungen eingebunden werden, solange diese in Tabellenform vorliegen. Diese Fremddatengruppen stammen aus einer Datenquelle (bzw. Datenbankverbindung) und können in die Anwendungen integriert werden, ohne dass sich der Anwender zu viele Gedanken über die technischen Rahmenbedingungen machen muss. Einzige Einschränkung ist, dass die Fremddatengruppe ein Feld enthalten muss, das eine eindeutige Kennung für den Datensatz enthält. Der technische Datentyp ist dafür nicht vorgegeben.
Die Datenquelle, die im Intrexx Portal Manager (Modul "Integration") eingerichtet werden kann, enthält Informationen zum Typ (z.B. "JDBC" bzw. "SAP") und den jeweilig erforderlichen technischen Parametern (z.B. Verbindungsparameter, Anmeldeinformationen).
Plant man die Integration eines Fremdsystems wie SAP, bestimmt dieser datengruppenorientierte Ansatz das Design eines speziellen Connectors. Die meisten Informationen lassen sich als Tabelle darstellen und sind somit tauglich. Sogar SAP Reports (SE38 Programme) lassen sich technisch als virtuelle Tabelle darstellen, in dem man die Ausgabezeilen als Text betrachtet und aus der Ausgabe eine Tabelle mit den einzelnen Ausgabezeilen erstellt. Dies macht es aus Portalsicht erforderlich, einen weiteren Begriff – den Datahandler – einzuführen. So kann z.B. eine Datenquelle technisch der Tabellenzugriff im SAP R/3 Test auf die Tabelle ZKUNDEN sein. Allerdings kann ebenso ein Zugriff auf den gleichnamigen Report ZKUNDEN erfolgen. Der Datahandler bestimmt also die Zugriffsart und die Tabelle die technische Umsetzung. Jede Datengruppe lässt sich also eindeutig über die Kombination
-
Datenbankverbindung bzw. Datenquelle
-
Datahandler bzw. Zugriffsart
-
Tabelle bzw. Objektname
bestimmen.
Erweiterungskonzept Intrexx
Eine sehr hohe Anzahl von Anforderungen an Portalapplikationen wie Änderungen an der Benutzeroberfläche, neue Felder oder Änderungen des Prozesses sind bereits im Intrexx-Standard realisierbar. Erst spezielle Prüflogiken, komplexe Anforderungen an die Businesslogik oder die Anbindung von Fremdsystemen erfordern ggfs. den Weg der Erweiterung. Intrexx bietet drei grundlegende Erweiterungsmöglichkeiten:
-
JavaScript
Damit lassen sich vor allem einfache Prüfungen, Reaktion auf Ereignisse der Benutzeroberfläche oder das Ein- und Ausblenden von Felder aufgrund von Statusinformationen realisieren. JavaScript ist in die grafischen Tools des Portal Managers integriert, zählt allerdings zu den Expertenfunktionen.
-
Java Erweiterungen (Velocity)
Intrexx baut technisch auf einem Java-Framework auf. In dieses Framework können eigene Java-Klassen integriert werden, die eigene wieder verwendbare Funktionen implementieren oder spezielle Darstellungen auf der Oberfläche verwirklichen.
-
Eigene Businesslogik-Handler
Bestimmte Portalfunktionen werden über Businesslogik-Handler realisiert, die in Java implementiert sind. Datengruppenaktionen werden z.B. über solche Handler abgehandelt.
Für die Einbindung von Fremddaten als Intrexx-Datengruppe müssen also eigene Datengruppenhandler-Klassen entwickelt werden. Dieser Ansatz wurde für die Integration von SAP Systemen gewählt.
Dieser eigene Handler für den SAP Zugriff muss folgende API-Methoden implementieren:
-
Get_Meta_Information
Technische Informationen zum Datenobjekt (z.B. Feldnamen und technische Datentypen)
-
Parse_Data_Range
Selektion von Datensätzen eingeschränkt über Filter und ggf. sortiert und mit Offsetzugriff (z.B. 20 Datensätze ab dem 100.)
-
Parse_Data_Record
Detailinformationen zu einem bestimmten Datensatz
-
Modify_Record
Einfügen, Ändern oder Löschen von Datensätzen
Die technischen Namen der Methoden weichen von den tatsächlichen Namen ab, werden aber über Vererbung vorgegeben.
SAP Datenquellen
Die Kommunikation von SAP Systemen untereinander sowie der Austausch von Informationen mit Applikationskomponenten, Tools oder vielen externen Produkten wird über die RFC Technologie realisiert. Der Weg ist ausgereift und auf den meisten Plattformen sowie für die meisten Programmiersprachen verfügbar. Für die Java Welt steht seit Jahren der SAP Java Connector zur Verfügung, der sowohl von den eigenen Java-basierenden Lösungen als auch Standalone verwendet wird. Naheliegend ist die Verwendung des SAP Java Connector und die Verwendung der RFC Schnittstelle, da Intrexx-Portale vollständig auf Java basieren.
Findungskonzept
Die folgende Abbildung demonstriert die Findung der technischen Systeme aus den Fremddatengruppen heraus.
Vor allem die Datenquelle wird innerhalb des Portals verwendet, um das reale Ziel (technische Parameter) zu ermitteln. Datahandler und Tabellenname werden hauptsächlich im aufgerufenen System verwendet, um die richtigen Verarbeitungsroutinen aufzurufen.
Weitere Informationen
SAP Trust Manager SSO configuration
API Beschreibung Teil 2 - SAP Portal Plugin
API Beschreibung Teil 3 - Implementierung eigener Verarbeitungsmodule
API Beschreibung Teil 4 - Beispielcodings
Entwicklerhandbuch Teil 2 - Integrationsszenario SAP-Fremddatengruppe
Entwicklerhandbuch Teil 3 - Integrationsszenario Skripting
Entwicklerhandbuch Teil 4 - Personalisierter SAP Zugriff / Single Sign On (SSO)
Senden Sie uns eine E-Mail