Anbindung von SAP R3 über die J2EE Connector-Architektur by usr10478

VIEWS: 282 PAGES: 119

									 Anbindung von SAP R/3 über
die J2EE Connector-Architektur
               Diplomarbeit
                    von
          Ludger Bischofs



          Oldenburg, 05. Juni 2002



     1. Gutachter: Prof. Dr. Hasselbring
        2. Gutachter: Prof. Dr. Winter
    Betreuer: Dipl.-Inform. Heiko Niemann
Inhaltsverzeichnis

1. Einleitung                                                                                                          7
   1.1. Hintergrund . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
   1.2. Problemstellung und Zielsetzung .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
        1.2.1. Theoretischer Teil . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
        1.2.2. Praktischer Teil . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
   1.3. Aufbau der Arbeit . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8

2. Connector-Architektur                                                                                              9
   2.1. Enterprise Application Integration (EAI) . . . . .                        .   .   .   .   .   .   .   .   .    9
   2.2. EAI und die J2EE-Plattform . . . . . . . . . . . .                        .   .   .   .   .   .   .   .   .   10
   2.3. Architekturüberblick . . . . . . . . . . . . . . . .                      .   .   .   .   .   .   .   .   .   12
        2.3.1. Die Systemkontrakte . . . . . . . . . . . .                        .   .   .   .   .   .   .   .   .   13
   2.4. Nicht verwaltete Umgebung . . . . . . . . . . . .                         .   .   .   .   .   .   .   .   .   14
   2.5. Verwaltete Umgebung . . . . . . . . . . . . . . .                         .   .   .   .   .   .   .   .   .   16
        2.5.1. Konguration des Ressourcenadapters . .                            .   .   .   .   .   .   .   .   .   17
        2.5.2. Verbindungsaufbau und Sicherheit . . . . .                         .   .   .   .   .   .   .   .   .   17
        2.5.3. Transaktionen . . . . . . . . . . . . . . . .                      .   .   .   .   .   .   .   .   .   18
        2.5.4. Ereignisse . . . . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   .   19
   2.6. Schnittstellen . . . . . . . . . . . . . . . . . . . .                    .   .   .   .   .   .   .   .   .   19
        2.6.1. Common Client Interface (CCI) . . . . . .                          .   .   .   .   .   .   .   .   .   20
        2.6.2. Kontrakt für das Verbindungsmanagement                             .   .   .   .   .   .   .   .   .   21
        2.6.3. Kontrakt für das Transaktionsmanagement                            .   .   .   .   .   .   .   .   .   22
        2.6.4. Kontrakt für das Sicherheitsmanagement .                           .   .   .   .   .   .   .   .   .   23

3. SAP R/3 Business Framework                                                                                         27
   3.1. Grundlagen und Aufbau . . . . . . . . . . . . . . . . .                               .   .   .   .   .   .   27
        3.1.1. SAP R/3 . . . . . . . . . . . . . . . . . . . . .                              .   .   .   .   .   .   27
        3.1.2. Business Framework . . . . . . . . . . . . . . .                               .   .   .   .   .   .   28
   3.2. Business-Objekte . . . . . . . . . . . . . . . . . . . . .                            .   .   .   .   .   .   29
   3.3. Business Application Programming Interfaces (BAPIs)                                   .   .   .   .   .   .   32
        3.3.1. Einsatzbereiche . . . . . . . . . . . . . . . . . .                            .   .   .   .   .   .   33
        3.3.2. Kommunikationsformen . . . . . . . . . . . . .                                 .   .   .   .   .   .   33
        3.3.3. Voraussetzungen für den Zugri auf BAPIs . . .                                 .   .   .   .   .   .   34



                                                                                                                       3
Inhaltsverzeichnis

         3.3.4. Vorteile von BAPIs . . . . . . . . . . . . . . . .                                           .   .   .   .   .   .   35
         3.3.5. Merkmale von BAPIs . . . . . . . . . . . . . . .                                             .   .   .   .   .   .   36
         3.3.6. BAPI-Aufrufe in externen Systemen . . . . . . .                                              .   .   .   .   .   .   37
         3.3.7. Transaktionsmodell für die BAPI-Entwicklung .                                                .   .   .   .   .   .   38
         3.3.8. Business Object Repository (BOR) . . . . . . .                                               .   .   .   .   .   .   40
    3.4. Integrationsdienst ALE (Application Link Enabling) . .                                              .   .   .   .   .   .   41
         3.4.1. Intermediate Document (IDoc) . . . . . . . . .                                               .   .   .   .   .   .   42
    3.5. Kommunikationsdienste . . . . . . . . . . . . . . . . .                                             .   .   .   .   .   .   44
         3.5.1. Remote Function Call (RFC) . . . . . . . . . .                                               .   .   .   .   .   .   44
         3.5.2. Distributed Component Object Model (DCOM)                                                    .   .   .   .   .   .   49

4. Zugri auf SAP R/3 über die Programmiersprache Java                                                                               51
    4.1. SAP Java Connector (JCo) . . . .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   51
         4.1.1. Verbindungsarten . . . . .                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   52
         4.1.2. BAPIs und andere RFMs                        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   55
         4.1.3. JCo Repository . . . . . .                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   55
    4.2. Ressourcenadapter . . . . . . . .                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   58
         4.2.1. SAP Resource Adapter . .                     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   58
    4.3. Java RFC Class Library . . . . .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   60
    4.4. SAP Business Connector (BC) . .                     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   62
         4.4.1. Funktionalität . . . . . . .                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   63
    4.5. Internet Transaction Server (ITS)                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   64
         4.5.1. Aufbau . . . . . . . . . . .                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   64
         4.5.2. Funktionalität . . . . . . .                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   65
    4.6. SAP DCOM Connector . . . . . .                      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   66
         4.6.1. Einsatzmöglichkeiten . . .                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   66
         4.6.2. Merkmale . . . . . . . . .                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   67
         4.6.3. Entwicklungsumgebungen                       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   68

5. Beispielszenario Materialverwaltung                                                                                               69
    5.1.   Der Weg zur Idee . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   69
    5.2.   Entwurf . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   70
    5.3.   Architektur . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   71
    5.4.   Vorgehensweise . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   72
    5.5.   Entwicklungsumgebung      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   72

6. Entwicklung des Ressourcenadapters                                                                                                75
    6.1. Entwurf . . . . . . . . . . . . . . . . . . . . . . .                                   .   .   .   .   .   .   .   .   .   75
         6.1.1. Unterstützte Schnittstellen . . . . . . . . .                                    .   .   .   .   .   .   .   .   .   76
         6.1.2. Schnittstelle für Applikationskomponenten                                        .   .   .   .   .   .   .   .   .   76
         6.1.3. Wahl der Zugrismethode . . . . . . . . .                                        .   .   .   .   .   .   .   .   .   76
         6.1.4. Architektur . . . . . . . . . . . . . . . . .                                    .   .   .   .   .   .   .   .   .   77
    6.2. Entwicklungsumgebung . . . . . . . . . . . . . . .                                      .   .   .   .   .   .   .   .   .   78



4
                                                                                 Inhaltsverzeichnis

   6.3. Packaging und Deployment . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    79
        6.3.1. Packaging . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    79
        6.3.2. Deployment . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    80
   6.4. Implementierung . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    81
        6.4.1. Nicht verwaltete Umgebung . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    81
        6.4.2. Interaktion interner Objekte . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    84
        6.4.3. Ausführung von EIS-Funktionen         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    85
        6.4.4. Transaktionen . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    88
        6.4.5. Verwaltete Umgebung . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    89
   6.5. Test . . . . . . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    91
        6.5.1. Nicht verwaltete Umgebung . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    91
        6.5.2. Verwaltete Umgebung . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    91
        6.5.3. Testgrenzen . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    92

7. Entwicklung der Beispielanwendung                                                                              93
   7.1. Vorgehensweise . . . . . . . . . . . . . . . . . . . . . .                       .   .   .   .   .   .    93
   7.2. BAPIs und Funktionsbausteine . . . . . . . . . . . . .                           .   .   .   .   .   .    93
        7.2.1. Anwendungsfall Material anlegen . . . . . . .                           .   .   .   .   .   .    93
        7.2.2. Anwendungsfall Materialsuche . . . . . . . . .                          .   .   .   .   .   .    95
        7.2.3. Anwendungsfall Materialdetails . . . . . . . .                          .   .   .   .   .   .    95
        7.2.4. Anwendungsfall Material ändern/löschen . . .                            .   .   .   .   .   .    95
   7.3. Entwurf und Implementierung . . . . . . . . . . . . . .                          .   .   .   .   .   .    95
        7.3.1. Entwicklung der Enterprise Java Beans (EJBs) .                            .   .   .   .   .   .    95
        7.3.2. Entwicklung des Clients . . . . . . . . . . . . .                         .   .   .   .   .   .    98

8. Zusammenfassung und Ausblick                                                                                  103
A. Packaging und Deployment                                                                                      105
   A.1. Application Deployment Tool . . . . . . . . . . . . . . . . . . . . 105
   A.2. Ressourcenadapter . . . . . . . . . . . . . . . . . . . . . . . . . . 105
        A.2.1. Deployment Descriptor . . . . . . . . . . . . . . . . . . . . 106

B. CD                                                                                                            107
Abbildungsverzeichnis                                                                                            109
Tabellenverzeichnis                                                                                              111
Abkürzungsverzeichnis                                                                                            113
Literaturverzeichnis                                                                                             118




                                                                                                                   5
Inhaltsverzeichnis




6
1. Einleitung

1.1. Hintergrund
Den Hintergrund dieser Diplomarbeit bildet das EKKIS-Projekt [Nie01], des-
sen Projektziel eine Veränderung der Systemarchitektur im Universitätsklinikum
Leipzig beinhaltet.
   Die zentrale Komponente des Klinikuminformationssystems ist ein SAP R/3-
System für die typischen betriebswirtschaftlichen Aufgaben. Dabei kommt das
Patientendaten-Management-Modul IS-H zur Verwaltung von Patientendaten
zum Einsatz.
   In nicht-betriebswirtschaftlichen Bereichen werden zur Zeit unterschiedliche
Systeme eingesetzt, die nicht auf R/3 basieren. Da viele dieser Systeme Patienten-
und Mitarbeiterstammdaten benötigen, wurden Datenverbindungen mit dem
R/3-System realisiert. R/3 selbst empfängt in der aktuellen Situation keine Da-
ten, sondern versendet diese nur.
   Durch einen Kommunikationsserver zwischen dem R/3-System und den Ab-
teilungssytemen wird eine lose Kopplung erreicht, in der Nachrichten asynchron
ausgetauscht werden.
   Ziel des EKKIS-Projektes ist es, den Übergang zu einer engen Kopplung zwi-
schen den klinischen Informationssystemen MCC und dem R/3-Modul IS-H wis-
senschaftlich zu begleiten.


1.2. Problemstellung und Zielsetzung
Die Diplomarbeit besteht aus einem theoretischen und einem praktischen Teil,
die im Folgenden beschrieben werden.


1.2.1. Theoretischer Teil
Innerhalb des theoretischen Teils dieser Diplomarbeit sollen die Zugrismög-
lichkeiten auf ein SAP R/3-System in Verbindung mit der J2EE Connector-
Architektur untersucht werden. Möglicherweise kommt dieser Ansatz als Inte-
grationslösung innerhalb des EKKIS-Projektes zum Einsatz.



                                                                                7
1. Einleitung

  Die Untersuchung und Beschreibung der Technologien erfolgt jedoch weitge-
hend unabhängig von der Zielsetzung des EKKIS-Projektes. Die Technologien
werden aus einer losgelösten Sichtweise betrachtet.
  Die Connector-Architektur des J2EE bildet in Verbindung mit den Zugris-
möglichkeiten auf SAP R/3 den Schwerpunkt dieser Diplomarbeit.

1.2.2. Praktischer Teil
Die Entwicklung einer beispielhaften Anwendung gehört zum praktischen Teil
dieser Arbeit. Zuvor betrachtete Technologien sollen verwendet werden, um auf
eine geeignete Art und Weise über die J2EE Connector-Architektur auf ein SAP
R/3-System zuzugreifen.
   Die Entwicklung eines Web-Clients für den Zugri auf SAP R/3 über einen
Browser ist ein optionaler Teil dieser Arbeit, der ebenfalls beschrieben wird.


1.3. Aufbau der Arbeit
Die Aufteilung dieser Diplomarbeit in einen theoretischen und einen praktischen
Teil spiegelt sich in dessen Aufbau wieder, der im Folgenden beschrieben wird.
   Kapitel 2 beschreibt die Connector-Architektur des J2EE und vermittelt not-
wendige Grundlagen für die späteren praktischen Kapitel. Die unterschiedlichen
Umgebungen für den Einsatz dieser Architektur werden aufgezeigt. Zusätzlich
werden wichtige Schnittstellen erklärt.
   Kapitel 3 vermittelt einen Einblick in das SAP R/3 Business Framework,
welches die grundlegenden Technologien für den Zugri auf ein SAP R/3-System
beinhaltet.
   Kapitel 4 konzentriert sich auf die Möglichkeiten des Zugris auf SAP R/3
über die Programmiersprache Java. Die im vorangegangenen Kapitel untersuch-
ten Technologien kommen dabei zum Einsatz.
   Kapitel 5 beschreibt den Weg zu einer Gesamtarchitektur für ein Beispielsze-
nario. Entscheidungen bezüglich der einzubeziehenden Technologien werden ge-
troen.
   Kapitel 6 gehört zu der praktischen Umsetzung des Beispielszenarios und
erläutert die Entwicklung und Implementierung eines Ressourcenadapters für den
Zugri auf SAP R/3.
   Kapitel 7 stellt die Entwicklung und Implementierung der Beispielanwendung
dar. Basierend auf dem Beispielszenario wird der zuvor entwickelte Ressourcenad-
apter verwendet, um über einen Web-Client auf ein SAP R/3-System zuzugreifen.
   Kapitel 8 beinhaltet eine kurze Zusammenfassung der Diplomarbeit und deren
Verlauf. Aufgetretene Probleme und Erfahrungen werden neben Verbesserungs-
möglichkeiten und zukünftigen Entwicklungen ebenfalls beschrieben.




8
2. Connector-Architektur

Die Java Connector Architecture (JCA) entstand aus der Idee heraus, die J2EE-
Plattform auf eine standardisierte Art und Weise mit heterogenen Anwendungen
integrieren zu können. In diesem Kapitel werden neben der Motivation, die zur
Connector-Spezikation führte, auch wichtige Zusammenhänge der Architektur
vermittelt. Als Grundlage dafür diente vor allem die Connector-Spezikation 1.0
[Sha01b].


2.1. Enterprise Application Integration (EAI)
In vielen Unternehmen taucht früher oder später der Wunsch auf, unterschiedliche
Anwendungen miteinander zu verbinden. Dies kann für innerbetriebliche Abläu-
fe von groÿem Vorteil sein. Beispielsweise könnte die Bestellung eines Kunden
aus dem Internet direkt in die betriebswirtschaftliche Anwendung eines Unter-
nehmens zur Erfassung von Kundendaten und der Erstellung von Rechnungen
übernommen werden. Der Austausch bzw. die Verarbeitung der Daten könnte
weitgehend automatisiert erfolgen.
   Enterprise Application Integration (EAI) stellt einen Ansatz für diese Integra-
tion von Applikationen und Datenquellen dar, der den Austausch von Daten und
die Verbindung von Geschäftsabläufen vereinfachen soll (siehe auch [Has00]).
   Vor EAI wurde oftmals versucht, dass Problem der Integration von Applika-
tionen und Datenquellen durch Eigenentwicklungen und Anpassungen zu lösen.
Da es sich bei den Anwendungen oftmals um spezielle Insellösungen auf unter-
schiedlichen Plattformen und mit unterschiedlichen Kommunikationsprotokollen
handelte, war eine Integration der Produkte nur mit hohem Entwicklungsaufwand
durchführbar.
   EAI stellt einen anderen Ansatz für die Lösung dieses Integrationsproblems
dar. Es deniert eine Standardvorgehensweise für die Kommunikation von Ap-
plikationen und Datenquellen. Durch die Unterstützung dieses Standards können
Applikationen auf einheitlichem Wege mit anderen Applikationen und Daten-
quellen kommunizieren. Einzelne Teile der Integration werden dadurch leichter
austauschbar.
   Problematisch bei der EAI erscheinen die technologischen Unterschiede der
Applikationen und Datenquellen, die berücksichtigt werden müssen, um möglichst



                                                                                9
2. Connector-Architektur

vielen Produkten eine Integration zu ermöglichen.
   In Anlehnung an das Buch J2EE Connector Architecture and Enterprise App-
lication Integration [RS01] sind in der Integrationsproblematik vier Unterschei-
dungsmerkmale für Enterprise Information Systems (EISs) zu berücksichtigen:

     • Grad der technologischen Unterstützung
       Dazu gehört beispielsweise die Möglichkeit der Durchführung von Transak-
       tionen oder die Unterstützung von Sicherheitsmechanismen.

     • Administrative und technologische Restriktionen
       Ein EIS kann Benutzern beispielsweise unterschiedliche Zugrismöglichkei-
       ten geben.

     • Fähigkeit der Integration mit anderen Systemen
       EIS wurden oftmals auf bestimmte Systemumgebungen zugeschnitten, wäh-
       rend die Kommunikation mit anderen Produkten nur eine untergeordnete
       Rolle spielte.

     • Systemdetails auf unterer Ebene
       Die Client APIs der EISs können sich unterscheiden. Neben der Verwen-
       dung unterschiedlicher Programmiersprachen kann ihre Komplexität stark
       variieren.


2.2. EAI und die J2EE-Plattform
Die Integration von J2EE-Applikationsservern mit heterogenen Anwendungen
war bis zur Einführung der J2EE Connector-Architektur kein erklärtes Ziel der
J2EE-Plattform [Rod01]. Die Lösung dieser Integrationsfrage ist sehr komplex,
weil eine grosse Zahl unterschiedlichster EIS-Systeme berücksichtigt werden muss
[JZ00]:

     • ERP-Systeme (Enterprise Resource Planning) wie z. B. SAP R/3

     • klassische TP-Systeme (Transaction Processing) auf Groÿrechnern

     • Legacy-Anwendungen, die mit beliebigen Programmiersprachen erstellt
       wurden

     • nicht relationale Datenbanksysteme wie z. B. IMS, UDS und CA-IDMS

  Bisher war eine anwendungsspezische Verbindung notwendig, um aus einer
Anwendung heraus über den Applikationsserver auf Informationen eines EIS zu-
greifen zu können. Ein hoher Entwicklungsaufwand war die Folge, der mit der



10
                                                        2.2. EAI und die J2EE-Plattform




                                                          ...



          Applikationsserver 1   Applikationsserver 2           Applikationsserver m




                                                          ...



                 EIS 1                   EIS 2                          EIS n


                   Abbildung 2.1.: m mal n-Integrationsproblem


Anzahl der EIS-Systeme und Applikationsserver wuchs. Für jeden Applikations-
server musste eine Verbindung zu jedem EIS hergestellt werden. Das kam bei m
Applikationsservern und n EIS-Systemen einem Aufwand von m mal n gleich.
Diese Problematik wird in Abbildung 2.1 dargestellt.
   Die Connector-Architektur ist eine Standardarchitektur für die Integration von
J2EE Applikationen mit EIS-Systemen, die keine relationalen Datenbanken sind.
Der Aufwand dieser Integration soll durch die Connector-Architektur reduziert
werden. EIS-Entwickler müssen ihre Produkte nicht mehr für jeden Applikati-
onsserver anpassen. Es reicht die Entwicklung eines entsprechenden Ressource-
nadapters für ihr EIS, der in jeden die Connector-Architektur unterstützenden
Applikationsserver integriert werden kann. Die Entwickler der Applikationsserver
müssen lediglich einmal die Connector-Architektur in ihr Produkt integrieren, um
beliebige Ressourcenadapter einbinden zu können.
   Der Ressourcenadapter stellt einen Software-Treiber auf Systemebene dar, der
von einer Java-Applikation verwendet werden kann, um eine Verbindung zum EIS
herzustellen. Dieser Ressourcenadapter kann als Plug-in-Erweiterung in jeden Ap-
plikationsserver eingebunden werden, der die Connector-Architektur unterstützt.
Durch diesen Standard reduziert sich der Aufwand der Integrationsproblematik
auf ein m + n-Problem (siehe Abbildung 2.2).



                                                                                       11
2. Connector-Architektur

           Applikationsserver                       Enterprise Information Systems

                                  Ressourcenadapter




           Applikationsserver

                                                      Enterprise Information System


                                       Ressourcenadapter




                       Erweiterung für die Einbindung von Ressourcenadaptern

                       Standard−Ressourcenadapter


                   Abbildung 2.2.: m + n-Integrationsproblem

2.3. Architekturüberblick
Die wichtigsten Komponenten der Connector-Architektur und deren Zusammen-
spiel können in der sogenannten verwalteten Umgebung (managed environment)
erklärt werden. Abbildung 2.3 soll die im Folgenden beschriebenen Zusammen-
hänge verdeutlichen.
  Die verwaltete Umgebung deniert ein Umfeld für eine J2EE-basierte, mehr-
schichtige und webfähige Applikation, die auf ein EIS zugreift. Die Applikation
besteht aus einer oder mehreren Applikationskomponenten wie Enterprise Java
Beans (EJBs) oder Java Server Pages (JSPs), die in einem Container ablaufen.
Die Container können folgende sein [Sha01b]:

     • Web-Container für JSPs, Servlets und statische HTML-Seiten

     • EJB-Container für EJB-Komponenten



12
                                                            2.3. Architekturüberblick

                              Container−Komponenten−
                                     Kontrakt
                                                          Applikationskomponente

                                                              Client API
     Applikationsserver


                                Systemkontrakte
                                                               Ressourcenadapter




                                           EIS−spezifische Schnittstelle

                                                           Enterprise Information
                                                                   System

          Abbildung 2.3.: Überblick über die Connector-Architektur

   • Applikationsclient-Container für eigenständige Applikationsclients

   J2EE Applikationskomponenten kommunizieren niemals direkt miteinander.
Die Kommunikation erfolgt stattdessen über den Container-Komponenten-
Kontrakt, der das Verbindungsstück zwischen einem Container und dem Ap-
plikationsserver darstellt. Der Kontrakt wird innerhalb der J2EE Spezikation
[Sha01a] deniert und soll an dieser Stelle nicht weiter betrachtet werden.
   Die Applikationskomponenten verwenden einen Ressourcenadapter, um auf
Funktionen des EIS zuzugreifen. Der Zugri auf den Ressourcenadapter erfolgt
über dessen Client API. Das Common Client Interface (CCI) kann beispielsweise
als standardisierte und vom EIS unabhängige Schnittstelle zum Einsatz kom-
men, die ohne Kenntnisse der EIS-spezischen Schnittstelle eingesetzt werden
kann. Der Ressourcenadapter selbst muss dagegen auf die spezische Schnittstel-
le des EIS zugreifen, um seine Aufgabe erfüllen zu können. Dabei kann es sich z.
B. um eine C-Bibliothek handeln, wodurch die Einbettung von Funktionen einer
anderen Programmiersprache in Java notwendig würde. Die Konvertierung von
Datentypen kann ebenfalls erforderlich sein.


2.3.1. Die Systemkontrakte
Die Einbindung des Ressourcenadapters in den Applikationsserver erfolgt über die
sogenannten Systemkontrakte. Diese regeln das Zusammenspiel von Ressourcena-
dapter und Applikationsserver. Ihre Implementierung wird durch die Connector-



                                                                                    13
2. Connector-Architektur

Spezikation zwingend gefordert.
   Ein Applikationsserver und ein Ressourcenadapter arbeiten zusammen, um al-
le systemnahen Mechanismen (Verbindungs-, Transaktions- und Sicherheitsma-
nagement) gegenüber den Applikationskomponenten transparent zu halten. Aus
diesem Grund werden zwischen dem Ressourcenadapter und dem Applikations-
server drei wichtige Systemkontrakte benötigt [Sha01b]:

     • Kontrakt für das Verbindungsmanagement
      Der Kontrakt für das Verbindungsmanagement erlaubt dem Applikations-
      server, Verbindungspools zum darunterliegenden EIS zu verwalten. Die Ver-
      wendung von Verbindungspools sorgt für eine bessere Ausnutzung von Ver-
      bindungen, deren Auf- und Abbau Ressourcen beansprucht. Dies führt zu
      einer Verbesserung der Skalierbarkeit und Erhöhung der Geschwindigkeit
      in der entsprechenden Umgebung, wodurch eine grosse Anzahl von Appli-
      kationskomponenten beim Aufbau einer Verbindung zum EIS unterstützt
      werden kann.

     • Kontrakt für das Transaktionsmanagement
      Der Kontrakt für das Transaktionsmanagement ermöglicht transaktionalen
      Zugri auf den Ressourcenmanager eines EIS. Dieser Kontrakt erlaubt ei-
      nem Applikationsserver, einen Transaktionsmanager für die Verwaltung von
      Transaktionen über mehrere Ressourcenmanager zu verwenden. Auch inter-
      ne Transaktionen innerhalb eines EIS werden unterstützt. In diesem Fall ist
      die Involvierung eines externen Transaktionsmanangers nicht erforderlich.

     • Kontrakt für das Sicherheitsmanagement
      Der Sicherheitsmanagement-Kontrakt soll einen sicheren Zugri auf ein EIS
      ermöglichen. Er bietet Unterstützung für eine sichere Applikationsumge-
      bung, die Sicherheitsprobleme minimieren hilft und vom EIS verwaltete
      Informationen schützt.

   Die Spezikation der J2EE Connector-Architektur deniert Schnittstellen für
die Implementierung der drei Systemkontrakte. Die meisten dieser Schnittstel-
len sind verbindlich und müssen vom Ressourcenadapter implementiert werden.
Nicht verbindliche Schnittstellen können vom Entwickler verwendet werden, um
ein einheitliches Programmmodell zu gewährleisten. Eigene Schnittstellen können
zusätzlich deniert werden.


2.4. Nicht verwaltete Umgebung
Neben der in Abschnitt 2.3 bereits erwähnten verwalteten Umgebung beschreibt
die Connector-Spezikation eine nicht verwaltete Umgebung (non-managed en-
vironment), die eine zweischichtige Applikation deniert. Ein Applikationsclient



14
                                                   2.4. Nicht verwaltete Umgebung


                                Applikationsclient


                                Ressourcenadapter
                     ConnectionFactory                    Connection



                     ConnectionManager



                 ManagedConnectionFactory          ManagedConnection




                     Enterprise Information System (EIS)

                             implementierungsspezifisch
                             Kontrakt der Connector−Architektur

       Abbildung 2.4.: Architektur in einer nicht verwalteten Umgebung


verwendet einen Ressourcenadapter direkt, um auf ein EIS zuzugreifen. Dies stellt
die einfachste Möglichkeit für den Einsatz eines Ressourcenadapters dar, weil kein
Applikationsserver benötigt wird.
  Da in der nicht verwalteten Umgebung in der Regel ein einfacher Standard-
Verbindungsmanager des verwendeten Ressourcenadapters zum Einsatz kommt,
werden Features der Connector-Architektur wie die Verwendung von Verbin-
dungspools meist nicht unterstützt.
  Abbildung 2.4 zeigt, wie ein Applikationsclient über einen Ressourcenadap-
ter auf ein EIS zugreifen kann. Die ConnectionFactory- Schnittstelle stellt eine
Schnittstelle des Common Client Interface (CCI) für die Erzeugung von Verbin-
dungen dar. Sie wird angesprochen, wenn eine neue Verbindung benötigt wird.
Diese Verbindungsanfrage wird an die ConnectionManager-Schnittstelle weiter-
geleitet, dessen Implementierung die Verwaltung der Verbindungen übernimmt.
  Die Erzeugung der physikalischen Verbindung erfolgt schlieÿlich über die
ManagedConnectionFactory-Schnittstelle. Die physikalische Verbindung zum
EIS wird durch eine Implementierung der ManagedConnection-Schnittstelle re-
präsentiert.
  Der Applikationsclient greift jedoch nicht direkt auf diese physikalische Ver-
bindung zu, um Funktionen auf dem EIS auszuführen. Er erhält ein Handle



                                                                               15
2. Connector-Architektur

auf Applikationsebene, bei dem es sich beispielsweise um eine dem CCI entspre-
chende Connection-Instanz handeln kann. Diese wurde über die zuvor erwähnte
ConnectionFactory-Schnittstelle erzeugt und wird für die Ausführung von Funk-
tionen auf dem EIS benötigt.


2.5. Verwaltete Umgebung
Die verwaltete Umgebung bildet den Schwerpunkt der Connector-Architektur.
Sie beschreibt, wie eine Applikationskomponente über einen Ressourcenadapter
auf ein EIS zugreifen kann. Im Gegensatz zur nicht verwalteten Umgebung sind
die Applikationskomponente und der Ressourcenadapter über Kontrakte mit ei-
nem Applikationsserver verbunden, der somit insbesondere in das Verbindungs-,
Transaktions- und Sicherheitsmanagement eingreift.
  In diesem Abschnitt soll die verwaltete Umgebung detaillierter betrachtet wer-
den als zu Beginn dieses Kapitels. Abbildung 2.5 verdeutlicht zusätzlich die Zu-
sammenhänge der verwalteten Architektur und deren wichtigsten Schnittstellen.

     Kontrakt der Connector−Architektur
                                                    Applikationskomponente
     implementierungsspezifisch




         Applikationsserver                              Ressourcenadapter

                 ConnectionManager             ConnectionFactory       Connection




      Sicherheitsmanager

                                          ManagedConnectionFactory
            Verbindungsmanager                                       ManagedConnection

                                          LocalTransaction

                   Transaktionsmanager
                                          XAResource


           ConnectionEventListener




                                             Enterprise Information System (EIS)


             Abbildung 2.5.: Architektur in einer verwalteten Umgebung



16
                                                       2.5. Verwaltete Umgebung

   Der Vergleich mit der nicht verwalteten Architektur zeigt, dass der prinzipielle
Zugri auf das EIS ähnlich verläuft. Der Unterschied liegt vor allem darin, dass
sich die Implementierung der ConnectionManager-Schnittstelle in der verwalte-
ten Architektur innerhalb des Applikationsservers bendet. Über die Systemkon-
trakte wird zudem der Zugri auf den Ressourcenadapter vom Applikationsserver
geregelt.
   Der Entwickler des Ressourcenadapters hat in der Regel keinen direkten Ein-
uss auf die im Applikationsserver ablaufenden Steuerungsmechanismen. Er im-
plementiert lediglich die von der Connector-Architektur geforderten Systemkon-
trakte des Ressourcenadapters.


2.5.1. Konguration des Ressourcenadapters
Kongurationsinformationen des Ressourcenadapters wie z. B. der Servername
oder die Portnummer können über ein sogenanntes Deployment-Tool gesetzt wer-
den. Ein so kongurierter Ressourcenadapter wird vom Applikationsserver für die
Herstellung physikalischer Verbindungen zum darunterliegenden EIS verwendet.


2.5.2. Verbindungsaufbau und Sicherheit
Die Applikationskomponente erhält die Instanz einer sogenannten Connection
Factory für die Erzeugung von Verbindungen über das Java Naming and Direc-
tory Interface (JNDI). Dabei kann es sich beispielsweise um eine Implementie-
rung der CCI-Schnittstelle ConnectionFactory handeln. Der JNDI-Name dieser
Connection Factory wird über den Deployment-Descriptor-Mechanismus für EJB-
Komponenten festgelegt. Dieser Mechanismus wird in Kapitel 6 in Verbindung
mit der Entwicklung eines Ressourcenadapters beschrieben. Als detaillierte Infor-
mationsquelle kann zudem die EJB-Spezikation [LGD01] herangezogen werden.
   Um an eine Verbindung zu gelangen, ruft die Applikationskomponente die
getConnection-Methode der Connection Factory auf. Diese Anfrage wird an die
ConnectionManager-Schnittstelle des Applikationsservers weitergereicht.
   Ein Verbindungsmanager innerhalb des Applikationsservers bearbeitet die An-
frage und sucht über einen internen Verarbeitungsmechanismus eine geeignete
Verbindung heraus. Dabei kann es sich um eine bereits bestehende Verbindung
aus dem Verbindungspool des Applikationsservers handeln, wenn diese für die
Anfrage geeignet erscheint.
   Vom Sicherheitsmanager verwaltete Sicherheitsmechanismen wie beispielswei-
se eine Login/Passwort-Kombination müssen übereinstimmen, um eine bereits
bestehende Verbindung verwenden zu können.
   Falls keine passende Verbindung existiert, erzeugt der Applikationsserver eine
der Anfrage entsprechende neue Verbindung und fügt diese seinem Verbindungs-
pool hinzu. Dies geschieht nur unter der Voraussetzung, dass die Sicherheitsbe-
dingungen erfüllt sind und eine Erzeugung der Verbindung zulassen.



                                                                                17
2. Connector-Architektur

            Client                       Applikationsserver



                                                X



                                         Applikations−         LocalTransaction−
                                            kontrakt           Kontrakt




                                                          TP System


                      Abbildung 2.6.: Lokale Transaktion


   Die Vorgehensweise bei der Verwaltung des Verbindungspools liegt beim Ap-
plikationsserver und wird nicht durch die Connector-Spezikation festgelegt.
   Der Applikationsserver verwendet die ManagedConnectionFactory-
Schnittstelle des Ressourcenadapters für die Erzeugung physikalischer Ver-
bindungen, bei denen es sich um ManagedConnection-Instanzen handelt. Er
liefert ein Handle auf Applikationsebene für diese physikalische Verbindung an
die Applikationskomponente zurück. Unter Benutzung des CCI handelt es sich
bei diesem Verbindungshandle um eine Connection-Instanz. Die Applikations-
komponente kann über Methoden dieser Instanz über den Ressourcenadapter
auf das EIS zugreifen.


2.5.3. Transaktionen
Für die Steuerung lokaler Transaktionen, die innerhalb eines EIS ablaufen, ver-
wendet der Applikationsserver die LocalTransaction-Schnittstelle des Ressour-
cenadapters.
  Lokale Transaktionen ohne die Verwendung eines Transaktionsmanagers wer-
den wie in Abbildung 2.6 gezeigt durchgeführt, wobei X eine EJB-Komponente
darstellt, die einen transaktionalen Zugri auf ein TP-System durchführt.
  Verteilte Transaktionen werden über einen Transaktionsmanager im Appli-
kationsserver geregelt. Dieser Transaktionsmanager verwendet die XAResource-
Schnittstelle des Ressourcenadapters für die Durchführung der Transaktionen.
  Der Transaktionsmanager des Applikationsservers verwaltet Transaktionen
über eigene interne Mechanismen, die durch die Connector-Spezikation nicht
vorgegeben werden.
  In Abbildung 2.7 ruft ein Client die EJB-Komponente X auf. Diese führt einen



18
                                                                     2.6. Schnittstellen

               Client                        Applikationsserver



                                            X                   Y



                                            Transaktionsmanager



                                                  XAResource−
                                                   basierter
                                                    Kontrakt




                                      TP System                     ERP System


               Abbildung 2.7.: XAResource-basierte Transaktion

Zugri auf ein TP-System durch und ruft die EJB Y auf, die wiederum ein ERP-
System anspricht. Der Applikationsserver verwendet einen Transaktionsmanager,
um transaktionalen Zugri über mehrere EIS Ressourcenmanager auszuführen.


2.5.4. Ereignisse
Die ConnectionEventListener-Schnittstelle informiert den Applikations-
server über unterschiedliche Ereignisse der physikalischen Verbindung
ManagedConnection. Es kann sich beispielsweise um Ereignisse über das
Schlieÿen der Verbindung, das Auftreten von Fehlern oder den Status von
Transaktionen handeln.


2.6. Schnittstellen
Bisher wurden grundlegende Zusammenhänge der Schnittstellen innerhalb der
Connector-Architektur beschrieben. Im Folgenden sollen wichtige Schnittstellen
im Einzelnen vorgestellt werden. Dieser Abschnitt bildet den Grundstein für das
Verständnis der späteren Implementierung und bietet eine detailliertere Beschrei-
bung der internen Zusammenhänge.
  Die Unterteilung der Schnittstellen erfolgt anhand der drei Systemkontrakte
für das Verbindungs-, Transaktions-, und Sicherheitsmanagement. Zuvor werden
jedoch wichtige Schnittstellen des Common Client Interface (CCI) vorgestellt, die
nicht zu den Systemkontrakten gehören.
  Es erscheint sinnvoll, sich die Zusammenhänge der im Folgenden beschriebenen



                                                                                     19
2. Connector-Architektur

Schnittstellen und Methoden anhand von Abbildung 2.5 auf Seite 16 zu verdeut-
lichen.
   Details zu den Schnittstellen können der Connector-Spezikation [Sha01b] oder
der Java-Dokumentation des J2EE SDK entnommen werden.


2.6.1. Common Client Interface (CCI)
Die folgenden Schnittstellen werden durch das Common Client Interface (CCI)
deniert und stellen ein standardisiertes Client API für den Zugri von Applika-
tionskomponenten auf heterogene EIS dar.


Schnittstelle ConnectionFactory
Die Schnittstelle ConnectionFactory stellt eine Connection Factory dar, welche
Verbindungen zu einem EIS erstellt.
   Eine Applikationskomponente kann über die getConnection-Methode der
ConnectionFactory-Schnittstelle an eine Verbindung gelangen. Es handelt sich
dabei um eine Connection-Instanz, die ein Verbindungshandle auf Applikations-
ebene darstellt.
   Die Verbindungsanfrage wird von der getConnection-Methode an die
allocateConnection-Methode der ConnectionManager-Schnittstelle weiterge-
leitet. Der Verbindungsmanager des Applikationsservers bzw. des Ressourcenad-
apters übernimmt dann die Erzeugung der physikalischen Verbindung. Alle spezi-
schen Anfrageinformationen werden über eine ConnectionRequestInfo-Instanz
an den Verbindungsmanager weitergereicht.
   Die Methode getConnection kann überladen werden, um zusätzliche Funktio-
nalität zur Verfügung zu stellen.
   Die ConnectionFactory-Schnittstelle muss nicht implementiert werden. Die
Funktionalität dieser Schnittstelle kann auf anderem Wege zur Verfügung gestellt
werden, solange die getConnection-Methode zur Erzeugung von Verbindungen
vom Ressourcenadapter unterstützt wird.


Schnittstelle Connection
Die Connection-Schnittstelle stellt ein Verbindungshandle auf Applikationsebene
dar, über das eine Applikationskomponente auf ein EIS zugreifen kann.
  Die close-Methode muss unterstützt werden, damit die Applikationskompo-
nente die Verbindung zum EIS trennen kann.
  Diese Schnittstelle wird von der Connector-Architektur nicht gefordert. Der
Ressourcenadapter muss lediglich ein Verbindungsobjekt mit einer entsprechen-
den close-Methode anbieten.



20
                                                              2.6. Schnittstellen

2.6.2. Kontrakt für das Verbindungsmanagement
Der Kontrakt für das Verbindungsmanagement ist für die Verwaltung physikali-
scher Verbindungen zuständig. Neben der Erzeugung und Beendigung von Ver-
bindungen liefert er auch Verbindungsinformationen wie Produktnamen und Pro-
duktversion des verbundenen EIS zurück.

Schnittstelle ManagedConnectionFactory
Die Schnittstelle ManagedConnectionFactory erzeugt physikalische Verbindun-
gen (ManagedConnection-Instanzen) und Connection Factory-Instanzen (z. B.
ConnectionFactory-Instanzen des CCI).
   Die createConnectionFactory-Methoden erzeugen neue Connection Factory-
Instanzen. Beim CCI sind das Instanzen vom Typ ConnectionFactory.
   Die Methoden createManagedConnection erzeugen neue physikalische Verbin-
dungen zum EIS in Form von ManagedConnection-Instanzen.
   Die matchManagedConnections-Methode wird insbesondere für die Verwaltung
des Verbindungspools des Applikationsservers genutzt und erlaubt Applikations-
servern, spezische Kriterien des Ressourcenadapters für die Suche einer pas-
senden ManagedConnection-Instanz zu einer Verbindungsanfrage zu verwenden.
Eine zu der Anfrage passende physikalische Verbindung wird zurückgeliefert, falls
sie bereits im Verbindungspool vorhanden ist.
   Ein Ressourcenadapter muss eine Implementierung dieser Schnittstelle besit-
zen.

Schnittstelle ManagedConnection
Eine ManagedConnection-Instanz repräsentiert eine physikalische Verbindung zu
einem EIS.
   Die Methode getConnection der ManagedConnection-Schnittstelle erzeugt ein
neues Verbindungshandle auf Applikationsebene. Unter Verwendung des CCI
handelt es sich dabei um eine Connection-Instanz.
   Die Methode destroy zerstört die physikalische Verbindung.
   Über die cleanup-Methode werden alle Client-spezischen Informationen der
ManagedConnection-Instanz gelöscht. Zusätzlich werden alle Verbindungshandles
ungültig, die durch diese Instanz erzeugt wurden.
   Der Ereignismechanismus innerhalb der Connector-Architektur kann durch
die addConnectionEventListener- und removeConnectionEventListener-
Methoden zum Einsatz kommen. Eine ConnectionEventListener-Instanz kann
so mit der ManagedConnection-Instanz verbunden bzw. wieder getrennt wer-
den. Ereignisse wie das Schlieÿen der physikalischen Verbindung oder Transakti-
onsnachrichten werden durch die ConnectionEventListener-Instanz entgegen-
genommen und weiterverarbeitet.



                                                                              21
2. Connector-Architektur

   Über die Methode setLogWriter kann die Ausgabe von wichtigen Log-
Informationen auf einen Ausgabestrom gelenkt werden. Die getLogWriter-
Methode liefert die aktuelle Instanz des Ausgabestroms zurück.
   Die Methode getMetaData liefert Metainformationen zur ManagedConnection
-Instanz und zum verbundenen EIS zurück.
   Die Connector-Spezikation fordert die Implementierung dieser Schnittstelle.


Schnittstelle ManagedConnectionMetaData
Die ManagedConnectionMetaData-Schnittstelle soll Metainformationen über
die ManagedConnection-Instanz und das verbundene EIS zurückliefern. Eine
ManagedConnectionMetaData-Instanz wird über die getMetaData-Methode der
ManagedConnection-Instanz zurückgeliefert. Diese Instanz muss den Produktna-
men und die Produktversion des EIS, die maximale Anzahl gleichzeitiger Verbin-
dungen und den zur Verbindung gehörenden Benutzernamen enthalten.
  Laut Connector-Spezikation muss diese Schnittstelle innerhalb des Ressour-
cenadapters implementiert werden.


2.6.3. Kontrakt für das Transaktionsmanagement
Es liegt am Ressourcenadapter und den Fähigkeiten des EIS, welche Arten von
Transaktionen unterstützt werden. Die Anforderungen an die Schnittstellen des
Transaktionsmanagements hängen von der Reichweite dieser Unterstützung ab.


Schnittstelle ManagedConnection
Neben den Methoden zur Unterstützung des Verbindungsmanagements ent-
hält die ManagedConnection-Schnittstelle Methoden für das Transaktionsma-
nagement. Dabei handelt es sich um die Methoden getLocalTransaction und
getXAResource, die eine LocalTransaction- bzw. XAResource-Instanz zurück-
liefern. Diese Schnittstellen werden für die Steuerung der Transaktionen benötigt.


Schnittstelle LocalTransaction
Die LocalTransaction-Schnittstelle unterstützt lokale Transaktionen, die auf
einem EIS ausgeführt werden. Ereignisse bezüglich der Transaktion werden durch
den bereits erwähnten Ereignismechanismus verfügbar gemacht. Die Methoden
begin, commit und rollback müssen implementiert werden. Sie steuern die lokale
Transaktion.
   Die LocalTransaction-Schnittstelle muss nur implementiert werden, wenn der
Ressourcenadapter lokale Transaktionen zulassen soll.



22
                                                               2.6. Schnittstellen

Schnittstelle XAResource
Die XAResource-Schnittstelle ist die Java-Variante der auf der X/Open CAE
Spezikation [XOp] basierenden XA-Schnittstelle.
   Diese Schnittstelle ermöglicht dem Ressourcenadapter, an verteilten Transak-
tionen teilzunehmen, die von einem externen Transaktionsmanager gesteuert wer-
den. Der Transaktionsmanager verwendet die XAResource-Schnittstelle, um die
Transaktionen zu verwalten.
   Die XAResource-Schnittstelle muss implementiert werden, wenn der Ressour-
cenadapter XA-Transaktionen ermöglichen soll.


2.6.4. Kontrakt für das Sicherheitsmanagement
Der    Kontrakt     für    das    Sicherheitsmanagement   erweitert   den
Verbindungsmanagement-Kontrakt durch das Hinzufügen von Sicherheits-
merkmalen.
  Der Sicherheitskontrakt unterstützt die Anmeldung am EIS auf zwei Arten
[Sha01b]:

   • Die Verbindungsanfrage an den Ressourcenadapter wird zum Applikations-
     server weitergereicht. Dieser sorgt für die entsprechende Bearbeitung der
     Anfrage unter Einbeziehung der Sicherheitsmechanismen.

   • Der Applikationsserver teilt dem Ressourcenadapter den Sicherheitskontext
     mit. Dies erfolgt über die Subject-Klasse des Java Authentication and Au-
     thorization Service (JAAS).

  Die folgenden Klassen und Schnittstellen werden in Verbindung mit der letzt-
genannten Anmeldungsvariante verwendet:

   • Klasse Subject
     Die JAAS-Klasse Subject repräsentiert eine Gruppierung relevanter Infor-
     mationen einer einzelnen Einheit wie z. B. einer Person. Diese Informationen
     beinhalten die Identitäten, die als Principal bekannt sind sowie sicherheits-
     bezogene Attribute, die auch Credentials genannt werden. Die Subject-
     Instanz wird dem Ressourcenadapter durch den Applikationsserver für die
     Authentisierung und Autorisierung übergeben.
     Mit Hilfe eines Authentisierungsvorgangs kann die Echtheit und die damit
     verbundene Glaubwürdigkeit einer Entität (z. B. Person mit einem Benut-
     zernamen) sichergestellt werden.
     Die Autorisierung klärt, ob die beteiligten Entitäten berechtigt bzw. willens
     sind, eine bestimmte Aktion durchzuführen.



                                                                               23
2. Connector-Architektur

     • Schnittstelle Principal
       Diese Schnittstelle repräsentiert eine abstrakte Darstellung eines Principals,
       der für die Repräsentation einer Entität verwendet werden kann.

     • Schnittstelle GenericCredential
       Die GenericCredential-Schnittstelle deniert einen Weg, an die Sicher-
       heitsinformationen eines Principals zu gelangen. Mit dieser Schnittstelle ist
       der Ressourcenadapter in der Lage, vom Applikationsserver übergebene Si-
       cherheitsdaten abzurufen.

  Zusätzlich zu den genannten Klassen und Schnittstellen des JAAS enthält der
Sicherheitskontrakt die Klasse PasswordCredential.

     • Klasse PasswordCredential
       Die Klasse PasswordCredential beinhaltet Benutzername und Passwort,
       welche vom Applikationsserver zum Ressourcenadapter weitergereicht wer-
       den können.

   Die Klassen und Schnittstellen des JAAS und die Klasse PasswordCredential
sind in die Verbindungsmanangement-Schnittstellen ConnectionManager,
ManagedConnectionFactory und ManagedConnection integriert, um den Sicher-
heitskontrakt zu unterstützen. Diese Schnittstellen werden im Folgenden beschrie-
ben.

Schnittstelle ConnectionManager
Die Methode ConnectionManager.allocateConnection wird von der Connecti-
on Factory-Instanz (z. B. ConnectionFactory-Instanz des CCI) des Ressourcena-
dapters aufgerufen. Sie übergibt eine Verbindungsanfrage vom Ressourcenadapter
an den Applikationsserver.
  In Abhängigkeit davon, ob der Applikationsserver oder die Applikationskom-
ponente für die Anmeldung beim EIS zuständig ist, ruft der Ressourcenadapter
die ConnectionManager.allocateConnection-Methode unterschiedlich auf:

     • Anmeldung durch den Container
       Die Applikationskomponente übergibt keine Sicherheitsinformationen.
       Stattdessen regelt der Applikationsserver die Übergabe der notwendigen
       Daten.

     • Anmeldung durch die Komponente
       Die Applikationskomponente übergibt explizit Sicherheitsinformationen.
       Der Ressourcenadapter übergibt der allocateConnection-Methode die be-
       nötigten Daten.



24
                                                              2.6. Schnittstellen

Schnittstelle ManagedConnectionFactory
Die ManagedConnectionFactory-Instanz wird vom Applikationsserver mit zu-
vor kongurierten Eigenschaften initialisiert. Diese Eigenschaften enthalten
Standard-Sicherheitsinformationen und EIS-spezische Daten wie Servername
und Portnummer, die für die Herstellung einer physikalischen Verbindung zum
EIS notwendig sind.
  Die Sicherheitskonguration der ManagedConnectionFactory kann durch die
Sicherheitsinformationen einer Komponente oder eines Containers überschrieben
werden.
  Die Methode createManagedConnection dieser Schnittstelle wird vom Appli-
kationsserver verwendet, wenn eine neue physikalische Verbindung zum EIS auf-
gebaut werden soll. Dieser Methode werden benötigte Sicherheitsinformationen
übergeben.
  Im Folgenden sollen Alternativen aufgezeigt werden, die sich ergeben, wenn
entweder der Applikationsserver oder der Ressourcenmanager die Anmeldung am
EIS vornehmen:

   • Kontrakt für den Applikationsserver
     Wenn der Applikationsserver die Anmeldung am EIS übernimmt, ruft er die
     createManagedConnection-Methode mit den erforderlichen Sicherheitsin-
     formationen auf. Diese Sicherheitsdaten können über vielfältige Wege über-
     tragen werden. Grundlage bildet der JAAS.

   • Kontrakt für den Ressourcenadapter
     Wenn der Ressourcenadapter die Anmeldung am EIS übernimmt, lie-
     fert der Applikationsserver einen null-Parameter anstatt einer Subject-
     Instanz an die createManagedConnection-Methode. In diesem Fall
     sucht der Ressourcenadapter nach Sicherheitsinformationen innerhalb der
     ConnectionRequestInfo-Instanz. Wenn er entsprechende Informationen
     ndet, werden diese verwendet, um die Verbindung zum EIS herzustellen.

 Der Ressourcenadapter muss die Methode createManagedConnection imple-
mentieren, um den Sicherheitskontrakt zu erfüllen.

Schnittstelle ManagedConnection
Ein Ressourcenadapter kann die Reauthentisierung einer physikalischen Verbin-
dung zum EIS unterstützen. Dies geschieht, wenn ein Applikationsserver die
getConnection-Methode mit einem unterschiedlichen Sicherheitskontext als dem
der bestehenden physikalischen Verbindung aufruft. Falls der Ressourcenadapter
keine Reauthentisierung unterstützt, sollte diese Methode eine Ausnahmebehand-
lung hervorrufen, falls der übergebene Sicherheitskontext ein anderer ist als der
bestehende.



                                                                              25
2. Connector-Architektur




26
3. SAP R/3 Business Framework

Dieses Kapitel soll grundlegende Kenntnisse über das SAP R/3 Business Frame-
work vermitteln. Das Framework umfasst unterschiedliche Technologien, die für
den Zugri auf R/3-Systeme von zentraler Bedeutung sind.
  Als wichtige Informationsquellen dienten das BAPI-Benutzerhandbuch der
SAP-Bibliothek [SAP] und das White Paper SAP Middleware Technologies
[SAP00b] von SAP. Der Abschnitt RFC-Programmierung basiert vor allem auf
dem Kapitel RFC-Programmierung in ABAP der SAP-Bibliothek [SAP].


3.1. Grundlagen und Aufbau
In den folgenden beiden Abschnitten soll ein Überblick über das SAP R/3-System
und den Aufbau des Business Framework vermittelt werden. Erst danach erfolgt
eine detailliertere Beschreibung einzelner Bestandteile.


3.1.1. SAP R/3
Das Produkt SAP R/3 der SAP AG stellt eine der umfangreichsten Lösungen für
betriebswirtschaftliche Bereiche wie z. B. Logistik und Personalwirtschaft dar1 .
Die Komplexität des SAP R/3-Systems resultiert aus der Tatsache, dass es nicht
für einzelne Kunden entwicklet wurde, sondern branchenneutral an verschiedene
Anforderungen angepasst werden kann.
  SAP R/3 kann auf verschiedenen Betriebssystemen (z. B. einige Unix-Varianten
und Windows NT) eingesetzt werden. Die Unternehmensdaten werden in zahlrei-
chen Tabellen in einer Datenbank gespeichert. Als Datenbank kommen Fremd-
produkte wie Oracle, Informix oder der Microsoft SQL-Server zum Einsatz.
  SAP R/3 verwendet eine dreistuge Client-Server-Architektur. Dabei handelt
es sich um eine Trennung in Präsentationsschicht, Anwendungsschicht und Da-
tenbankserver. Während die Präsentationsschicht Anwendungsdaten anzeigt und
Benutzereingaben entgegennimmt, laufen in der Anwendungsschicht die eigentli-
chen Abläufe und Funktionen des SAP-Systems ab. Der Datenbankserver ist nur
für die Datenhaltung zuständig.
 1 mySAP.com   ist der aktuelle Name dieses SAP-Produkts [RS01]




                                                                              27
3. SAP R/3 Business Framework

  Die Entwicklung innerhalb des SAP R/3-Systems erfolgt über die ABAP/4-
Programmiersprache. Ein zentraler Bestandteil der gesamten Architektur ist das
ABAP/4 Dictionary. Dabei handelt es sich um ein Verzeichnis über Felder, Ta-
bellen und Beziehungen innerhalb des Systems.
  Der konventionelle, interaktive Zugri auf das SAP-System erfolgt über das
SAPgui, welches den Benutzern ermöglicht, direkt mit dem SAP-System zu kom-
munizieren.

3.1.2. Business Framework
Das SAP R/3 Business Framework soll eine oene, komponentenbasierte Archi-
tektur anbieten, die eine Interaktion und die Integration von Softwarekomponen-
ten von SAP und anderern Herstellern ermöglicht. Es sieht eine Strukturierung
der R/3-Funktionalität in Anwendungskomponenten (Business-Komponenten)
und Objektmodelle vor und ermöglicht es Kunden und Partnern, eigene Kom-
ponenten an das R/3-System zu koppeln. Die Nutzung von objektorientierter
Technologie und Objektmodellen trägt wesentlich zur Komplexitätsreduzierung
des Gesamtsystems bei.
  Die Grundlage für die Komponentenentwicklung bei SAP ist die Architektur
des Business Framework. Die wesentlichen Bestandteile sind:

     • Business-Komponenten
      Business-Komponenten setzen sich aus Business-Objekten zusammen und
      sind eigenständig wartbar. Beispielsweise sind der Business-Komponente
      Human Resources unter anderem die Business-Objekte Employee (Mitar-
      beiter) und Applicant (Bewerber) zugeordnet. Geschäftsprozesse werden
      entweder innerhalb einer Business-Komponente implementiert oder können
      sich über mehrere Komponenten erstrecken (verteilte Geschäftsprozesse).

     • Business-Objekte
      Business-Objekte sind die Grundlage der objektorientierten Strukturie-
      rung des R/3-Systems. Sie kapseln betriebswirtschaftliche Daten und Funk-
      tionalität und denieren den Umfang und die Grenzen einer Business-
      Komponente.

     • Business Application Programming Interfaces (BAPIs)
      BAPIs bilden die Schnittstellen zu den Business-Objekten. Zusammen mit
      den Business-Objekten denieren und dokumentieren BAPIs den Schnitt-
      stellenstandard auf betriebswirtschaftlicher Ebene.

     • Integrationsdienst ALE (Application Link Enabling)
      Der Integrationsdienst Application Link Enabling (ALE) ermöglicht die
      Integration von Geschäftsprozessen, die über mehrere R/3- oder Fremdsy-



28
                                                           3.2. Business-Objekte

     steme hinweg abgewickelt werden. Grundlage dafür ist eine systemgrenzen-
     übergreifende Verteilung der betreenden Business-Objekte mit Hilfe des
     ALE-Verteilungsmodells.

   • Kommunikationsdienste
     Kommunikationstechnologien wie das Distributed Component Object Mo-
     del (DCOM) und Remote Function Call (RFC) werden vom Business Fra-
     mework verwendet, um auf BAPIs zuzugreifen.


3.2. Business-Objekte
Reale Objekte, wie z. B. ein Mitarbeiter oder ein Kundenauftrag, werden in be-
triebswirtschaftlichen Anwendungssystemen, wie dem R/3-System, als Business-
Objekte abgebildet. SAP-Business-Objekte kapseln die R/3-Daten und Ge-
schäftsprozesse und verbergen auf diese Weise die Struktur- und Implementie-
rungsdetails der zugrundeliegenden Daten. Dies entspricht dem Grundgedanken
der Objektorientierung.
   Um diese Kapselung zu erzielen, bestehen die SAP-Business-Objekte aus meh-
reren Schichten (siehe auch Abbildung 3.1):

   • Kern
     Der Kern ist die innerste Schicht des SAP-Business-Objekts und enthält
     die eigentlichen Daten des Objekts.

   • Integritätsschicht
     Die zweite Schicht, die Integritätsschicht, stellt die betriebswirtschaftliche
     Logik des Objekts dar. Sie umfasst Geschäftsregeln zur konsistenten Einbet-
     tung in das Umfeld und Einschränkungen bezüglich Werten und Domänen,
     die für das Business-Objekt gelten.

   • Schnittstellenschicht
     Die dritte Schicht beschreibt die Implementierung und Struktur des SAP-
     Business-Objekts und wird als Schnittstellenschicht bezeichnet. Sie deniert
     die Schnittstelle des Objekts zur Auÿenwelt.

   • Zugrisschicht
     Die vierte und äuÿerste Schicht eines Business-Objekts ist die Zugris-
     schicht. Sie deniert die Technologien, mit denen ein externer Zugri auf
     die Objektdaten möglich ist, z. B. COM/DCOM (Component Object Mo-
     del/Distributed Component Object Model).



                                                                                29
3. SAP R/3 Business Framework


                              Business−Objekt
                               Zugriffsschicht
                                − Internet (HTTP)
                                − COM (DCOM)
                                − CORBA
                                − ABAP (RFC)




                             Schnittstellenschicht
                                  − Attribute
                                  − BAPIs, Methoden
                                  − Ereignisse




                                Integritätsschicht
                        − Konsistenzbedingungen (objektbezogen)
                        − Business−Regeln (umgebungsbezogen)



                                      Kern
                                 − innere Struktur
                                 − Spezialisierung



               Abbildung 3.1.: Schichten eines Business-Objekts


  Die Schnittstellenschicht trennt die Daten eines Business-Objekts von den An-
wendungen und Technologien, mit denen auf diese Daten zugegrien wird. Nach
auÿen ist dadurch nur eine Schnittstelle von klar denierten Methoden sichtbar,
über die Anwendungen auf die Daten des Business-Objekts zugreifen können.
Deshalb reichen Informationen über diese Methoden aus, um das SAP-Business-
Objekt nutzen zu können. Kenntnisse über die Implementierungsdetails eines
Business-Objekts werden vom Anwendungsprogrammierer nicht verlangt.
  Die Methoden eines Business-Objekts stellen sein Verhalten dar und können
bei Ausführung den internen Status des Objekts, d. h. die Daten des Objekts,
verändern. Ein Beispiel für eine Methode, die für das Business-Objekt Employee
(Mitarbeiter) ausgeführt werden kann, ist die Methode zur Prüfung der Existenz
des Mitarbeiters.
  Business-Objekte werden entsprechend ihrer Art und Merkmale einer spezi-



30
                                                           3.2. Business-Objekte

schen Objektklasse zugeordnet. Die Objektklassen werden als Objekttypen be-
zeichnet. So gehören beispielsweise die einzelnen Mitarbeiter in einem Unterneh-
men alle zum Objekttyp Employee.
   Die Objekttypen sind Beschreibungen der tatsächlichen SAP-Business-
Objekte, die im R/3-System existieren können. Jedes einzelne SAP-Business-
Objekt ist also eine spezische Darstellung oder Instanz seines Objekttyps. So ist
beispielsweise der Mitarbeiter mit dem Namen Otto Müller und der Mitarbeiter-
nummer 911 eine Instanz des Objekttyps Employee.
   Anwendungsentwickler denieren bei der Programmierung objektorientierter
Anwendungsprogramme die Objekttypen, die von ihren Programmen verwen-
det werden sollen. Während der Laufzeit greift das Anwendungsprogramm dann
auf die spezischen Instanzen der denierten Objekttypen zu. Die Instanz eines
Business-Objekts spricht nur auf die Merkmale und Methoden an, die für ihren
eigenen Objekttyp deniert wurden.
   SAP-Business-Objekttypen werden durch folgende Eigenschaften deniert:

   • Objekttyp
     Der Objekttyp beschreibt die Merkmale, die alle Instanzen dieses Objekt-
     typs gemeinsam haben. Das sind beispielsweise der eindeutige Name des
     Objekttyps, seine Klassizierung und das Datenmodell.

   • Schlüsselfelder
     Die Schlüsselfelder eines Objekttyps bestimmen die Struktur eines Kenn-
     zeichnungsschlüssels, der einer Anwendung einen eindeutigen Zugri auf
     eine spezische Instanz des Objekttyps gewährt. Der Objekttyp Employee
     und das Schlüsselfeld Employee.Number sind Beispiele eines Objekttyps und
     eines entsprechenden Schlüsselfeldes.

   • Methoden
     Eine Methode ist eine Operation, die auf einem Business-Objekt ausgeführt
     werden kann und Zugri auf die Objektdaten ermöglicht. Eine Methode ist
     durch einen Namen und eine Reihe von Parametern und Ausnahmen de-
     niert, die zur Nutzung der Methode vom aufrufenden Programm bereitge-
     stellt werden. BAPIs sind Beispiele für derartige Methoden.

   • Attribute
     Ein Attribut enthält Daten über ein Business-Objekt und beschreibt ein
     bestimmtes Objektmerkmal. Employee.Name ist beispielsweise ein Attribut
     des Objekttyps Employee.

   • Ereignisse
     Ein Ereignis signalisiert, dass in einem Business-Objekt eine Statusände-
     rung eingetreten ist.



                                                                               31
3. SAP R/3 Business Framework

   Der Hauptvorteil dieser objektorientierten Technologie ist die Wiederverwend-
barkeit von Software, die durch die Ableitung neuer Objekttypen von vorhande-
nen Objekttypen erzielt wird. Wenn ein Objekttyp aus einem vorhandenen gene-
riert wird, wird der neue Objekttyp als Subtyp (oder Subklasse) und der vorhan-
dene Objekttyp als übergeordneter Typ (Supertyp oder Superklasse) bezeichnet.
Der Objekttyp Employee ist beispielsweise ein Subtyp, der vom übergeordneten
Typ Person abgeleitet wurde.
   Ein Subtyp erbt alle Eigenschaften und Methoden, die für den übergeordneten
Typ gültig sind, von dem der Subtyp abgeleitet wurde. Der Subtyp kann jedoch
auch über zusätzliche Eigenschaften und Methoden verfügen oder die Methoden,
die er vom übergeordneten Typ geerbt hat, mit einem anderen Verhalten imple-
mentieren. Die Tatsache, dass dieselbe Methode verschiedene Verhaltensarten in
unterschiedlichen Business-Objekttypen auslösen kann, wird als Polymorphismus
bezeichnet.


3.3. Business Application Programming
     Interfaces (BAPIs)
Den Kernbestandteil des SAP R/3 Business Framework stellen die SAP-Business-
Objekte dar. Sie decken einen groÿen Teil der betriebswirtschaftlichen R/3-Daten
und Prozesse ab.
  Ein BAPI (Business Application Programming Interface) ist als Methode eines
SAP-Business-Objekttyps bzw. SAP-Interfacetyps deniert. Die BAPIs bieten
stabile und standardisierte Methoden an, über die auf SAP-Business-Objekte
zugegrien werden kann. Zusammen bewirken die SAP-Business-Objekte und die
BAPIs eine objektorientierte Sicht auf die betriebswirtschaftliche Funktionalität
des R/3-Systems. Der externe Zugri auf die Objektdaten und Prozesse ist nur
mit Hilfe der BAPIs möglich.
  Die im SAP-Business-Objekttyp CostCenter (Kostenstelle) implementierte
Funktionalität ermöglicht beispielsweise das Auisten aller verfügbaren Kosten-
stellen. Zu diesem Zweck stellt der Business-Objekttyp CostCenter ein BAPI
GetList() zur Verfügung.
  Die BAPIs im R/3-System sind gegenwärtig als Funktionsbausteine realisiert,
die im Function Builder angelegt und verwaltet werden. Jeder Funktionsbaustein,
der einem BAPI zugrundeliegt, unterstützt das RFC-Protokoll und wurde einem
SAP-Business-Objekttyp im Business Object Repository (BOR) als Methode zu-
geordnet. Das BAPI wird verarbeitet, ohne Bildschirmdialoge an die aufrufende
Anwendung zurückzugeben.
  Durch diese Architektur kann SAP interne Änderungen an der Implementie-
rung eines BAPIs vornehmen, ohne die externen Anwendungen zu beeinträchti-
gen, die auf dieses BAPI zugreifen.



32
                    3.3. Business Application Programming Interfaces (BAPIs)

  Seit der ersten Verfügbarkeit der BAPIs in Release 3.1 des R/3-Systems stieg
deren Anzahl mit jedem neuen Release an. Dadurch verbesserte sich auch die
Möglichkeit des objektorientierten Zugris auf das R/3-System.


3.3.1. Einsatzbereiche
BAPIs eignen sich nach SAP-Angaben für folgende Projekte:

   • Integration von Fremdanbieteranwendungen mit einem R/3-System

   • Integration vorhandener betriebswirtschaftlicher Anwendungen mit einem
     R/3-System

   • Integration von neuen R/3-Komponenten, z. B. Advanced Planner & Opti-
     mizer (APO) und Business Information Warehouse (BW)

   • alternative Front-End-Schnittstellen zu einem R/3-System (z. B. Anwen-
     dungen in Visual Basic, Java oder C++)

   • Web-basierter Zugri auf ein R/3-System durch Internet- oder Intranet-
     Anwendungen

   • Komponententrennung innerhalb des R/3-Systems im Rahmen des Business
     Framework


3.3.2. Kommunikationsformen
BAPIs sollen für alle Arten von Kommunikationsteilnehmern in beliebigen Sze-
narien verwendbar sein. Um dieses Ziel zu erreichen, müssen sämtliche Kommu-
nikationsformen unterstützt werden:

   • synchrone und asynchrone Kommunikation:

         Synchrone Aufrufe von BAPIs erfolgen unter Verwendung des RFC.
          Von auÿerhalb kann auf BAPIs von jeder Entwicklungsplattform zu-
          gegrien werden, die das RFC-Protokoll unterstützt.
         Asynchrone Kommunikation wird über die ALE-Eingangsverarbeitung
          erreicht (siehe Abschnitt 3.4). Beim Aufruf des BAPIs im Sendersy-
          stem wird ein Intermediate Document (IDoc) erzeugt und an das Emp-
          fängersystem gesendet. Der Empfänger ruft das BAPI dann synchron
          mit den Daten aus dem IDoc auf.



                                                                           33
3. SAP R/3 Business Framework

     • Mensch-Maschine- und Maschine-Maschine-Kommunikation:
          Die Integration von Anwendungssystemen kann als Maschine-
           Maschine-Kommunikation angesehen werden. Im allgemeinen werden
           grössere Datenmengen ausgetauscht und hohe Anforderungen an die
           Performance gestellt. Aus diesem Grunde besitzen BAPIs, die in die-
           sem Kontext eingesetzt werden, eine gröbere Granularität.
          Alternative Frontends stellen eine Mensch-Maschine-Kommunikation
           dar. Für diese Art der Kommunikation verwendete BAPIs weisen in
           der Regel eine feinere Granularität auf. Sie müssen eine exible und
           fehlerfreie Kommunikation ermöglichen.

     • Die Kommunikation von eng verbundenen und von über das Internet
       gekoppelten Komponenten wird unterstützt:

       BAPIs können in Verbindung mit Kommunikationstechnologien wie COR-
       BA oder COM/DCOM verwendet werden. Der Zugri über das Internet
       kann z. B. durch den SAP Business Connector (siehe Abschnitt 4.4) erfol-
       gen.

3.3.3. Voraussetzungen für den Zugri auf BAPIs
Um BAPIs für den Zugri auf SAP-Business-Objekte nutzen zu können, soll-
ten allgemeine Konzepte der objektorientierten Technologie und Programmie-
rung bekannt sein. R/3-Grundkenntnisse sind sinnvoll, auch wenn für die Ar-
beit mit BAPIs keine Detailkenntnisse des R/3 Systems notwendig sind. Die
verwendete Entwicklungsumgebung, über die auf BAPIs zugegrien wird, muss
vertraut sein. In einer nicht-objektorientierten Programmiersprache werden RFC-
Programmierkenntnisse benötigt, um BAPIs über RFC aufrufen zu können.
  Für den Zugri auf eine BAPI-Methode muss ein Anwendungsprogramm fol-
gende Informationen über die aufzurufende Methode besitzen:

     • Name des BAPI
     • Importparameter für Daten, die vom aufrufenden Programm an das BAPI
       übergeben werden sollen.

     • Exportparameter für Daten, die vom BAPI an das aufrufende Programm
       zurückgegeben werden sollen.

     • Die Import-/Exportparameter (Tabellenparameter) für den Datenimport
       und -export.

  Das Anwendungsprogramm kann so auf SAP-Business-Objekte zugreifen und
dessen BAPIs verwenden, ohne Implementierungsdetails des Objekts zu kennen.



34
                    3.3. Business Application Programming Interfaces (BAPIs)

3.3.4. Vorteile von BAPIs
Die folgenden Punkte stellen einige Vorteile dar, die sich laut SAP durch die
Nutzung der BAPIs als Zugrismethoden auf die SAP-Business-Objekte ergeben.

   • Betriebswirtschaftlicher Standard
     Die Business-Objekttypen und ihre BAPIs bilden den Standard für die be-
     triebswirtschaftlichen Inhalte des R/3-Systems und ermöglichen die Inte-
     gration des R/3-Systems und anderer Softwarekomponenten auf betriebs-
     wirtschaftlicher Ebene.

   • Konformität mit Standards
     Eine Initiative der SAP mit Kunden, Partnern und führenden Normenor-
     ganisationen ist verantwortlich für die Entwicklung der BAPIs. Als Zielset-
     zung bildete sich die Entwicklung eines Kommunikationsstandards zwischen
     betriebswirtschaftlichen Systemen heraus.
     Der Zugri auf SAP-Business-Objekttypen und ihre BAPIs kann mit Hil-
     fe objektorientierter Schnittstellentechnologien, wie z.B. COM/DCOM
     (Component Object Model/Distributed Component Object Model) von Mi-
     crosoft erfolgen.
     Die Business-Objekte von SAP sind konform mit den Spezikationen der
     Open Applications Group (OAG) und entsprechen den CORBA-Richtlinien
     (Common Object Request Broker Architecture) der Object Management
     Group.

   • Stabilität und Abwärtskompatibilität
     Die Schnittstellen eines BAPI bleiben nach der Einführung und Freigabe
     durch SAP langfristig stabil. Anwendungen werden somit von Änderungen
     der zugrundeliegenden R/3-Software und -Daten nicht beeinusst. Erweite-
     rungen von BAPIs können durch Hinzufügen weiterer Parameter realisiert
     werden, ohne die Stabilität vorhandener Anwendungen zu beeinträchtigen.
     Neue Anwendungen können dagegen von der neuen Funktionalität protie-
     ren.

   • Objektorientierung
     BAPIs bieten den Zugri auf die Daten und Prozesse der SAP-Business-
     Objekte. Sie folgen dabei den Prinzipien der Objektorientierung. BAPIs
     können mit Hilfe objektorientierter Schnittstellentechnologien, wie z. B.
     COM/DCOM, aufgerufen werden und ermöglichen auf diese Weise die freie
     Interaktion der Softwarekomponenten von SAP und anderen Anbietern.



                                                                             35
3. SAP R/3 Business Framework

     • Oenheit
      Der Zugri auf BAPIs kann von allen Plattformen, die das SAP-Protokoll
      Remote Function Call (RFC) unterstützen, erfolgen.


3.3.5. Merkmale von BAPIs
Es gibt zahlreiche allgemeine Merkmale von BAPIs, die dem Entwickler vertraut
sein sollten, bevor eine Verwendung von BAPI-Aufrufen in Anwendungen erfolgt.

     • Namenskonventionen
      Ein BAPI wird durch den Namen des betreenden Business-Objekttyps
      gefolgt von dem Namen des BAPIs vollständig identiziert. Der eng-
      lisch gehaltene Name eines BAPIs beschreibt die Funktion, die das BA-
      PI am Business-Objekt ausführt. Für die Trennung der Namensteile wird
      ein Punkt verwendet. Beispielsweise lautet die vollständige Identizie-
      rung des BAPIs CheckAvailability() am Business-Objekt Material
      Material.CheckAvailability().

     • Standardisierte BAPIs und Parameter
      Es existieren standardisierte BAPIs, die für einen Grossteil der Business-
      Objekttypen implementiert werden können. Diese BAPIs stellen Grund-
      funktionen bereit, die z. B. das Auisten existierender Instanzen des
      Business-Objekttyps erlauben. Diese BAPIs erhalten an allen Business-
      Objekten den gleichen Namen und werden nach bestimmten Designvor-
      gaben implementiert.
      Das BAPI GetList() steht beispielsweise an vielen Business-Objekten zur
      Verfügung. CompanyCode.GetList() und Material.GetList() sind Bei-
      spiele dafür.
      Eine Standardisierung der Parameter ist weitgehend gegeben. An der BAPI-
      Schnittstelle werden standardisierte Parameter eingesetzt, die an den BA-
      PIs auf einheitliche Weise implementiert und benannt werden.

     • Datenbankkonsistenz
      Ein BAPI kann eine Instanz eines Objekts erstellen oder die Daten eines Ob-
      jekts verändern. Derartige Änderungen hinterlassen immer einen konsisten-
      ten Datenbankzustand. Alle Datenbankänderungen werden entweder voll-
      ständig oder überhaupt nicht ausgeführt. Das COMMIT WORK-Kommando,
      welches die Änderungen auf der Datenbank festschreibt, darf allerdings
      nicht vom BAPI selbst aufgerufen werden, sondern muss vom aufrufenden
      Programm ausgeführt werden.



36
                    3.3. Business Application Programming Interfaces (BAPIs)

   • Keine Dialogorientierung
     BAPIs liefern keine Bildschirmdialoge vom R/3-Server-System an die auf-
     rufende Anwendung zurück.

   • Berechtigungen
     Jede Benutzerinteraktion mit einem R/3-System setzt entsprechende Be-
     rechtigungen voraus. Die Benutzer der Anwendung, die BAPIs ausführt,
     müssen über die notwendigen Berechtigungen in den R/3-Stammsätzen ver-
     fügen, um den BAPI-Aufruf zu ermöglichen. Die Dokumentation der ein-
     zelnen BAPIs enthält nähere Informationen zu den erforderlichen Berech-
     tigungen.
     Jeder aufgrund unzureichender Berechtigungen fehlgeschlagene Ausfüh-
     rungsversuch eines BAPIs wird der aufrufenden Anwendung gemeldet.

   • Datentypen und Datenanzeige
     BAPIs sind betriebswirtschaftliche Programmierschnittstellen. Deshalb
     werden an der BAPI-Schnittstelle fast ausschlieÿlich neutrale (interne) Da-
     tentypen und Datenformate verwendet. Hierzu gibt es einige Ausnahmen,
     für die allerdings Konvertierungs-BAPIs zur Verfügung stehen. Genauere
     Informationen sind unter Service-BAPIs für Hilfsfunktionen im BAPI-
     Benutzerhandbuch der SAP-Bibliothek [SAP] zu nden.
     Die meisten von SAP unterstützten Datentypen können als BAPI-
     Parameter verwendet werden. Die Datentypen sind in den Struktureinträ-
     gen der einzelnen Parameter im ABAP Dictionary dokumentiert.

   • Verarbeitungsmodi
     BAPIs werden bei direktem Aufruf synchron abgearbeitet. Der Aufruf kann
     beispielsweise über das BAPI ActiveX Control, den R/3 DCOM Component
     Connector oder den unmittelbaren Aufruf des zugrundeliegenden Funkti-
     onsbausteins über RFC erfolgen.

   • Attribute von Business-Objekten
     Der Zugri auf die Attribute eines Business-Objekts erfolgt über die BAPI-
     Schnittstelle selbst. Ein Beispiel hierfür ist das BAPI GetDetail() am
     Business-Objekt CompanyCode.


3.3.6. BAPI-Aufrufe in externen Systemen
Ab Release 4.5A beschreiben BAPIs auch Schnittstellen, die auÿerhalb des R/3-
Systems implementiert sind und vom R/3-System in externen Systemen aufge-
rufen werden können. Diese BAPIs werden als BAPIs für den Outbound-Fall



                                                                             37
3. SAP R/3 Business Framework

bezeichnet. Die Ermittlung des Zielsystems für den BAPI-Aufruf wird über das
Verteilungsmodell des Application Link Enabling (ALE) ermöglicht.
   BAPIs für den Outbound-Fall werden im Business Object Repository (BOR)
als API-Methoden an SAP-Interfacetypen deniert. Im Gegensatz zu BAPIs an
SAP-Business-Objekttypen liegt diesen BAPIs im R/3-System keine Implemen-
tierung als Funktionsbaustein zugrunde.
   Auf diese Weise können Funktionen, die auÿerhalb des R/3-Systems implemen-
tiert werden, standardisiert und als BAPIs zur Verfügung gestellt werden.


3.3.7. Transaktionsmodell für die BAPI-Entwicklung
Eine Transaktion stellt in dem Transaktionsmodell der BAPI-Entwicklung eine
Verarbeitungseinheit oder Logical Unit of Work (LUW) dar. Eine LUW enthält
die Gesamtheit der Schritte einer Transaktion inklusive der Fortschreibung der
Datenbank (Verbuchung).
  Für das Transaktionsmodell gilt das ACID-Prinzip. Transaktionen sind dem-
nach:

     • Atomic (atomar)
       Transaktionen führen Datenbankoperationen entweder vollständig oder
       überhaupt nicht aus. Entweder werden alle relevanten Daten in der Da-
       tenbank verändert oder es erfolgt keine Modikation.

     • Consistent (konsistent)
       Eine Transaktion überführt einen konsistenten Zustand der Datenbank in
       einen anderen konsistenten Zustand. Keine der vorhandenen Integritätsbe-
       dingungen wird verletzt.

     • Isolated (isoliert)
       Eine Transaktion darf nicht durch eine andere Transaktion beeinusst wer-
       den. Es dürfen also keine funktionalen Abhängigkeiten zwischen zwei Trans-
       aktionen bestehen.

     • Durable (dauerhaft)
       Änderungen oder Transaktionen sind dauerhaft und können nicht zurück-
       genommen werden.

  Ein BAPI muss dem ACID-Prinzip entsprechen und somit transaktional sein.
Das BAPI-Transaktionsmodell soll dem Benutzer aber auch ermöglichen, meh-
rere BAPIs miteinander innerhalb einer LUW zu kombinieren. Das BAPI-
Transaktionsmodell besagt, dass sowohl einzelne BAPIs als auch die Kombination
mehrerer BAPIs in einer LUW transaktional sein müssen.



38
                    3.3. Business Application Programming Interfaces (BAPIs)

   In Release 3.1 war ein BAPI gleichbedeutend mit einer LUW oder Transaktion,
weil sie das COMMIT WORK-Kommando eigenständig durchführte. Die Dokumen-
tation der BAPIs, die einen COMMIT WORK ausführen, muss einen Hinweis darauf
beinhalten. Es ist die einzige Möglichkeit für den Benutzer, die Ausführung des
COMMIT WORK zu erkennen.
   Seit dem Release 4.0 werden von BAPIs im allgemeinen keine COMMIT WORK-
Kommandos mehr durchgeführt. Dadurch wird die Ausführung mehrerer BAPIs
in einer LUW ermöglicht. Zusätzlich zu den BAPIs aus Release 3.1 gibt es jedoch
noch wenige weitere BAPIs, in denen aus technischen Gründen ein COMMIT WORK-
Kommando enthalten ist.

Transaktionskontrolle beim Client
Das BAPI-Transaktionsmodell ermöglicht dem Benutzer eine explizite Transak-
tionssteuerung. Bei der Kombination mehrerer BAPIs kann der Aufrufer ent-
scheiden, wann das COMMIT WORK-Kommando ausgeführt wird bzw. ob eventuell
ein ROLLBACK WORK ausgeführt werden soll. Dies gilt allerdings nur, solange die
BAPIs selbst kein COMMIT WORK-Kommando ausführen.
   Es existieren folgende Einschränkungen bei der Kombination von BAPIs in
einer LUW:

   • Nach dem Aufruf einer schreibenden BAPI, die eine Instanz angelegt, mo-
     diziert oder gelöscht hat, kann ein lesendes BAPI nur auf die aktuellen
     Daten zugreifen, wenn vorher ein COMMIT WORK durchgeführt wurde.

   • Innerhalb einer LUW kann nicht zweimal schreibend auf die gleiche Instanz
     zugegrien werden. Ein Objekt kann z. B. nicht erst angelegt und dann
     verändert werden.

Transaktionshandling über Service-BAPIs
Eine BAPI-Transaktion muss über den Aufruf der BAPI Bapi-
Service.TransactionCommit() oder BapiService.TransactionRollback()
beendet werden. Dadurch wird das notwendige COMMIT WORK- bzw. ROLLBACK
WORK-Kommando ausgeführt. Die transaktionssteuernden BAPIs ste-
hen allerdings erst ab Release 4.5 zur Verfügung. In Release 4.0 kön-
nen stattdessen die Funktionsbausteine BAPI_TRANSACTION_COMMIT und
BAPI_TRANSACTION_ROLLBACK verwendet werden.

Nutzung des Verbuchers
Operationen, die die Datenbank verändern, müssen über die Verbuchung durch-
geführt werden. Andernfalls besteht die Gefahr, dass während des RFC-Aufrufs
unkontrollierte und unerwünschte Datenbank-Commits ausgeführt werden.



                                                                            39
3. SAP R/3 Business Framework

  Ausserdem darf der Aufruf eines BAPIs keine zusätzliche vom BAPI unab-
hängige LUW anstoÿen. Aus diesem Grund sind folgende Kommandos in einem
BAPI nicht erlaubt:

     • CALL TRANSACTION

     • SUBMIT REPORT

     • SUBMIT REPORT AND RETURN

  Weitere Informationen zu den zwei Transaktionsmodellen (mit und ohne Com-
mit) können im BAPI-Benutzerhandbuch der SAP-Bibliothek [SAP] nachgele-
sen werden.

3.3.8. Business Object Repository (BOR)
Das Business Object Repository (BOR) stellt den zentralen Zugrispunkt auf die
SAP-Business-Objekttypen und deren BAPIs dar. Es wurde ursprünglich für den
Workow entwickelt. Inzwischen wird das BOR neben der Speicherung von SAP
Business-Objekttypen und ihren BAPIs für den Archive Link, die Nachrichten-
steuerung und andere generische Objektdienste verwendet. Alle SAP-Business-
Objekttypen bzw. SAP-Interfacetypen und ihre Methoden werden im R/3 Busi-
ness Object Repository (BOR) identiziert und beschrieben. Das Business Object
Repository wurde mit R/3 Release 3.0 eingeführt.
  Mit der Einführung der BAPIs in R/3 Release 3.1 übernahm das BOR eine
wichtige neue Rolle. Es stellt jetzt den zentralen Zugrispunkt für externe An-
wendungen auf die SAP-Business-Objekttypen, SAP-Interfacetypen und deren
BAPIs dar.
  Das BOR stellt im Zusammenhang mit den BAPIs folgende Dienste zur Ver-
fügung:

     • Objektorientierte Sicht
       Eine objektorientierte Sicht auf alle Daten und Prozesse des SAP-Systems
       wird ermöglicht.

     • Ordnung der Business-Objekttypen
       Die verschiedenen Business-Objekttypen werden entsprechend ihrer Kom-
       ponentenhierarchie geordnet. Ein schnelles und einfaches Aunden der ge-
       suchten Funktionalität wird dadurch möglich.

     • Speicherung aller relevanten Informationen
       Alle relevanten Informationen zu den SAP-Business-Objekttypen bzw.
       SAP-Interfacetypen, ihren Schlüsselfeldern und den BAPI-Methoden, die
       benötigt werden, um die richtigen Objekttypdenitionen und BAPI-Aufrufe



40
                      3.4. Integrationsdienst ALE (Application Link Enabling)

     in ein Anwendungsprogramm zu integrieren, werden im BOR abgelegt. Da-
     durch wird die Anbindung von Middleware (z.B. DCOM Connector, Acti-
     veX Controls, CORBA Gateway) möglich.

   • Garantierung einer stabilen Schnittstelle der BAPIs
     Wenn Änderungen an der BAPI-Schnittstelle im BOR vorgenommen wer-
     den, wird automatisch geprüft, ob diese Änderungen gegenüber den ent-
     sprechenden Entwicklungsobjekten im ABAP Dictionary syntaktisch kom-
     patibel sind.

   • Versionskontrolle für die BAPIs
     Die Erweiterung einer BAPI-Schnittstelle durch zusätzliche Parameter wird
     im BOR dokumentiert. Dadurch ist jederzeit die Rekonstruktion einer frü-
     heren Schnittstellenversion möglich. Beim Anlegen eines BAPIs wird das
     Auslieferungsrelease der freigegebenen Version des BAPIs gespeichert. Das
     Gleiche erfolgt beim Anlegen jedes Schnittstellenparameters.

   • Instanzierung von SAP Business-Objekten
     Die Laufzeitumgebung des BOR empfängt Anforderungen von Client-
     Anwendungen zur Erstellung von Laufzeitobjekten und erstellt die entspre-
     chenden Objektinstanzen.



3.4. Integrationsdienst ALE (Application Link
     Enabling)
Application Link Enabling (ALE) ist eine Integrationstechnologie (Middlewa-
re) für die Integration von Geschäftsprozessen in einer verteilten Umgebung.
ALE integriert Geschäftsprozesse zwischen R/3-Systemen wie auch zwischen R/3-
Systemen und Fremdsystemen. Dabei werden Daten zwischen Anwendungssyste-
men kontrolliert ausgetauscht und konsistent gehalten.
  Die Anwendungssysteme eines ALE-Verbunds sind lose gekoppelt. Die Daten
werden asynchron ausgetauscht, wobei sichergestellt wird, dass sie auch im Emp-
fängersystem ankommen, wenn dieses zum Sendezeitpunkt nicht erreichbar ist.
Synchrone Verbindungen werden von ALE nur zum Lesen von Daten genutzt.
  Eine Dezentralisierung von betriebswirtschaftlichen Anwendungen bei gleich-
zeitiger Wahrung der Datenkonsistenz ist aus folgenden Gründen sinnvoll:

   • Die zunehmende Globalisierung der Märkte führt zur physischen Trennung
     von Organisationseinheiten. Geschäftsprozesse sind nicht auf ein einzelnes
     Unternehmen beschränkt, und in zunehmendem Maÿe werden Kunden und
     Lieferanten einbezogen.



                                                                            41
3. SAP R/3 Business Framework

     • Die Leistungsfähigkeit eines R/3-Systems kann durch die Verteilung be-
       triebswirtschaftlicher Anwendungen vergröÿert werden.

  ALE unterstüzt die Konguration und den Betrieb von verteilten Anwendun-
gen. Es umfasst einen betriebswirtschaftlich kontrollierten Nachrichtenaustausch
zwischen verteilten Anwendungen bei konsistenter Datenhaltung auf lose gekop-
pelten R/3-Systemen.
  Die Anwendungsintegration erfolgt nicht über eine zentrale Datenbank. Statt-
dessen greifen Anwendungen auf eine lokale Datenbank zu. Die Datenhaltung ist
redundant. ALE gewährleistet Verteilung und Abgleich von Stamm-, Steuer- und
Bewegungsdaten über asynchrone Kommunikation. Zum Lesen von Daten nutzt
ALE synchrone Verbindungen.
  Der Einsatz von ALE bietet eine Reihe von Vorteilen:

     • Verteilung von Anwendungsdaten zwischen R/3-Systemen unterschiedlicher
       Release-Stände

     • Datenaustausch wird nach Release-Wechsel ohne weitere Pege gewährlei-
       stet.

     • Kundenspezische Erweiterungen sind möglich.

     • Anbindung von Nicht-SAP-Systemen über Kommunikationsschnittstellen

     • Kopplung von R/3- und R/2-Systemen

  ALE bietet Funktionen zur Überwachung des Nachrichtenusses und zur Be-
hebung von Störungen.
  Die Grundlage für verteilte Anwendungen in einem ALE-Systemverbund ist
die asynchrone Verteilung von Nachrichten über die Ausgangs- und Eingangsver-
arbeitung.
  Grundlage für die Nachrichtenverteilung ist das im nächsten Abschnitt erläu-
terte Intermediate Document (IDoc). IDocs werden bei der Verteilung sowohl
über Nachrichtentypen als auch über SAP-Business-Objektmethoden (BAPIs)
erzeugt und versendet.


3.4.1. Intermediate Document (IDoc)
Das Intermediate Document (IDoc) ist ein von SAP standardisiertes Format
für Dokumente. Über IDocs können verschiedene Applikationssysteme über eine
Nachrichten-basierte Schnittstelle verbunden werden. IDoc stellt einen Datencon-
tainer für den Austausch von Informationen zwischen zwei SAP-Systemen oder
zwischen einem SAP-System und einem externen System zur Verfügung. IDocs
besitzen eine neutrale Datenstruktur. Sie können in einem Nicht-SAP-System



42
                      3.4. Integrationsdienst ALE (Application Link Enabling)

als Standardschnittstelle für den Datentransfer (Import und Export) verwendet
werden.
   Ein IDoc besteht aus einem Kontroll-Datensatz, der den IDoc-Typ, den
Nachrichten-Typ, den Sender und Empfänger des IDocs, eine Reihe von zusam-
menhängenden Datensegmenten bestehend aus fortlaufenden Segmentnummern
und Segmenttypen, und verschiedene Status-Datensätze enthält.
   Es können bestehende IDoc-Typen erweitert oder neue Typen erstellt werden.
Folgende drei IDoc-Varianten können unterschieden werden:

   • Standard-Basis-IDoc-Typen
     Alle mit SAP mitgelieferten Typen entsprechen diesem Typ und können
     vom Kunden erweitert werden.

   • Kunden-Basis-IDoc-Typen
     Darunter werden alle IDoc-Typen verstanden, die als neue Schnittstellen
     vom Kunden erzeugt wurden.

   • Erweiterte Typen
     Hier handelt es sich um vom Kunden erzeugte IDoc-Typen als eine Erwei-
     terung des Standard-Basic-IDoc-Typs.

  Die IDoc-Typen werden Release-unabhängigen Nachrichtentypen zugewiesen,
die ihrerseits Objekt-Typen im Business Object Repository (BOR) zugewiesen
werden. Die Datensegmente eines IDoc-Typs werden von Release-unabhängigen
Segmenttypen beschrieben und besitzen Release-spezische Segmentdenitionen,
die in internen Strukturen des Data Dictionary festgehalten werden. So können
unterschiedliche IDocs mit unterschiedlichen Inhalten zu unterschiedlichen Emp-
fängern gesendet werden, solange das Release des Empfängers dem sendenden
System bekannt ist.
  Asynchrone IDocs können übereinstimmend mit ihrer spezischen Asynchroni-
tät und Nachrichten-Charakteristik in folgenden Kommunikationsprozessen ver-
wendet werden:

   • Electronic Data Interchange (EDI) ist eine Applikation der IDoc-
     Schnittstellen-Technologie, deren Fähigkeiten für hohe Datenvolumen und
     Genauigkeit von Daten bereits über mehrere Jahre bekannt sind.

   • Über Application Link Enabling (ALE) kann eine grosse Spanne von
     Drittanbieter-Middleware und -Applikationen integriert werden.

   • Von den IDoc-Kommunikations-Kanälen werden unterschiedliche Protokol-
     le in der lokalen Umgebung unterstützt, um zu jedem System eine passende
     Verbindung herstellen zu können.



                                                                            43
3. SAP R/3 Business Framework

     • Im IDoc outbound processing werden Geschäftsdaten versendet.

     • Im IDoc inbound processing werden Geschäftsdaten empfangen und in
       der entsprechenden Geschäftsanwendung verarbeitet.

   Ab R/3-Release 4.0 sollen synchrone und asynchrone Schnittstellen als BA-
PIs implementiert werden. Wenn asynchrone Schnittstellen als BAPIs implemen-
tiert werden, muss für das BAPI eine BAPI-ALE-Schnittstelle vorhanden sein.
SAP stellt für viele BAPIs solche Schnittstellen zur Verfügung. Diese können
aber auch selbst generiert werden. Mit Hilfe der Schnittstellen können ALE-
Geschäftsprozesse implementiert werden.
   Die folgenden Arbeitsschritte erfolgen bei der Übertragung eines IDoc:

     1. Im Ausgangssystem wird ein IDoc mit den zu übertragenden Daten erzeugt
        und zur Versendung aufbereitet.

     2. Das IDoc wird an das Zielsystem übertragen.

     3. Im Zielsystem stöÿt das IDoc die Eingangsverarbeitung an. Im Einzelnen
        erfolgt die Bearbeitung der Daten den Einstellungen entsprechend bis zur
        Verbuchung in der Anwendung. Dies geschieht entweder automatisch oder
        mit manuellen Zwischenschritten.

   Die Ausgangs- bzw. Eingangsverarbeitung kann für jedes IDoc einzeln oder in
einer Paketverarbeitung erfolgen. Bei der Massenverarbeitung werden mehrere,
in einem Paket zusammengefasste IDocs in einem Schritt bearbeitet.
   Weitere Einzelheiten können im ALE-Programmierleitfaden der SAP-
Bibliothek [SAP] nachgelesen werden.


3.5. Kommunikationsdienste
Im Folgenden werden die Kommunikationsdienste RFC und DCOM für den Auf-
ruf von BAPIs und Funktionsbausteinen erläutert.

3.5.1. Remote Function Call (RFC)
Unter einem Remote Function Call (RFC) wird ein entfernter Funktionsaufruf
verstanden. RFC kann als eine SAP-Variante des Remote Procedure Call (RPC)
angesehen werden. Es handelt sich dabei um den Aufruf eines Funktionsbausteins,
der in einem anderen System ablaufen kann als das aufrufende Programm. Ob-
wohl die Möglichkeit besteht, einen Funktionsbaustein auch im selben System
über RFC aufzurufen, verfolgt der Grundgedanke des RFC vor allem Aufrufe
in unterschiedlichen Systemen. Das RFC-Schnittstellensystem ermöglicht Funk-
tionsaufrufe zwischen zwei SAP-Systemen (R/2 oder R/3) oder zwischen einem



44
                                                    3.5. Kommunikationsdienste

SAP-System und einem externen System (nicht SAP). Nicht-SAP-Systeme kön-
nen ebenfalls über die RFC-Schnittstelle miteinander kommunizieren.
   Das SAP-Schnittstellenprotokoll RFC setzt auf der Schnittstelle CPI-C (Com-
mon Programming Interface-Communication) auf. Mit Hilfe von CPI-C kann ei-
ne Programm-zu-Programm-Kommunikation zwischen SAP-Systemen (R/2 oder
R/3) oder mit externen Programmen und Systemen implementiert werden. RFC
erlaubt im Gegensatz zu CPI-C eine wesentlich vereinfachte Programmierung
von Kommunikationsabläufen, weil dem Programmierer grundlegende Teile der
Kommunikationssteuerung, der Parameterübergabe und der Fehlerbehandlung
abgenommen werden.
   Aus diesem Grund ist die CPI-C-Programmierung laut SAP nur in folgenden
Fällen erforderlich:


   • Das Programm kommuniziert mit Systemen ohne RFC-Unterstützung (R/2
     vor Release 5.0D).

   • Ein eigenes Protokoll soll auf der Basis von CPI-C deniert werden.

   • Ein bestehendes Programm, das CPI-C-Aufrufe enthält, soll gepegt wer-
     den.


   Falls keiner dieser Fälle zutrit, kann die RFC-Schnittstelle aufgrund der ver-
einfachten Programmierung bevorzugt werden.
   Das RFC-Schnittstellensystem stellt Aufrufschnittstellen für ABAP- und
Nicht-SAP-Programme bereit.
   Jedes ABAP-Programm kann einen entfernten Funktionsbaustein über die An-
weisung CALL FUNCTION...DESTINATION aufrufen. Der Parameter DESTINATION
gibt an, dass der aufzurufende Funktionsbaustein innerhalb eines anderen Sy-
stems abläuft als der Aufrufer. Die RFC-Kommunikation mit dem entfernten
System ndet als Teil der CALL FUNCTION-Anweisung statt. Die aufzurufenden
RFC-Funktionsbausteine in einem SAP-System müssen als echte Funktionsbau-
steine und als entfernt (remote) registriert sein. Dann kommt als Aufrufer jedes
beliebige ABAP-Programm in Frage.
   Falls es sich beim Aufrufer oder dem aufgerufenen Programm um ein Nicht-
SAP-Programm handelt, muss dieses so programmiert werden, dass es einen Part-
ner in einer RFC-Kommunikation spielen kann. Für die Unterstützung der Imple-
mentierung solcher RFC-Partnerprogramme bietet SAP externe Schnittstellen an.
Die RFC- und GUI-gestützten Schnittstellen können von externen Programmen
benutzt werden, um Funktionsbausteine in SAP R/2 oder SAP R/3- Systemen
aufzurufen. Auch ABAP-Programme in R/2 oder R/3 können die von externen
Programmen bereitgestellten Funktionen über diese Schnittstellen nutzen.



                                                                               45
3. SAP R/3 Business Framework

RFC in SAP-Systemen
In allen R/3-Systemen ist CALL FUNCTION ein integraler Bestandteil der ABAP-
Sprache (in R/2 ab Release 5.0). Diese Anweisung führt eine Funktion (einen
Funktionsbaustein) im selben System aus. RFC ist eine Erweiterung von CALL
FUNCTION in einer dezentralen Umgebung. Funktionsbausteine können über
einen RFC-Aufruf aus einem entfernten R/2- oder R/3-System heraus ausge-
führt werden. Dazu muss die CALL FUNCTION-Anweisung um einen DESTINATION-
Parameter erweitert werden. Dieser Parameter enthält alle für die Verbindung
zum Zielsystem benötigten Informationen.
   Unter OS/2, Windows und allen von R/3 unterstützten UNIX-Plattformen
steht eine RFC-Bibliothek (RFC API) zur Verfügung, über die RFC-
Funktionalität auch zwischen einem SAP-System (R/3 ab Release 2.1 und R/2 ab
Release 5.0D) und einem C-Programm verwendet werden kann. Für den Aufrufer
ist es unerheblich, ob der entfernte Funktionsbaustein in einem SAP-Programm
oder einem C-Programm abläuft.
   Die RFC-Schnittstelle entbindet den ABAP-Programmierer davon, eigene
Kommunikationsroutinen schreiben zu müssen, indem ihm folgende Arbeiten ab-
genommen werden:

     • die Konvertierung aller Parameterdaten in die vom entfernten System be-
       nötigte Darstellung
       Darunter fallen die Konvertierung von Zeichenketten sowie Hardware-
       abhängige Konvertierungen (z. B. Integer, Fixpunkt). Alle ABAP-
       Datentypen werden unterstützt. Dictionary-Strukturen werden nicht un-
       terstützt.

     • der Aufruf der benötigten Kommunikationsroutinen, um mit dem entfernten
       System kommunizieren zu können

     • die Handhabung der bei der Kommunikation aufgetretenen Fehler und die
       Benachrichtigung des Aufrufers im Bedarfsfall

   Alle Verarbeitungsschritte für den Aufruf entfernter Programme sind in der
CALL FUNCTION-Anweisung integriert und für den ABAP-Programmierer nicht
sichtbar.
   Für jeden als entfernt registrierten Funktionsbaustein wird automatisch ein
RFC-Stub generiert, der als Schnittstelle zwischen aufrufendem Programm und
Funktionsbaustein dient. Dieser Stub übernimmt die benötigten Verarbeitungs-
schritte, falls der Funktionsbaustein aufgerufen wird.
   Es wird zwischen einem RFC-Client und einem RFC-Server unterschieden. Der
RFC-Client ruft die RFC-Schnittstelle auf, um einen Funktionsbaustein aufzuru-
fen, der von einem RFC-Server bereitgestellt wird. Im Folgenden werden Funk-
tionsbausteine, die entfernt ausgeführt werden können, als RFC-Funktionen be-



46
                                                    3.5. Kommunikationsdienste

zeichnet. Die über die RFC-Bibliothek bereitgestellten Funktionen werden RFC-
Aufrufe genannt.
  Alle verfügbaren RFC-Funktionen in einem RFC-Server werden transaktio-
nal verarbeitet, wenn sie von einem RFC-Client aufgerufen werden. Das bedeu-
tet, dass der gesamte Kontext (alle global denierten Variablen im RFC-Server-
Programm oder im Hauptprogramm eines Funktionsbausteins) nach der Ausfüh-
rung der ersten RFC-Funktion im RFC-Server zur Verfügung steht.
  Die RFC-Verbindung wird nur in folgenden Fällen geschlossen:

   • wenn der Kontext des aufrufenden ABAP-Programms beendet ist

   • wenn die Verbindung im externen Programm explizit durch einen entspre-
     chenden Befehl abgebrochen oder geschlossen wird

Echtzeit-Kommunikation mit sRFC (synchronous RFC)
Die grundlegende Eigenschaft von sRFC ist der Aufruf von Funktionsmodulen
in entfernten Systemen in Echtzeit. Import- und Exportparameter, Tabellen und
Ausnahmen werden unterstützt. Seit SAP Basis Component Release 3.1G können
Parameter und Tabellen mit unterschiedlichen Datentypen verwendet werden. Ab
SAP Basis Release 4.6C können auch Zeichenketten, Byteketten und komplexe
Strukturen übermittelt werden. Bei komplexen Strukturen handelt es sich um
Strukturen oder Tabellen, deren Felder wiederum Tabellen sein können. Vor SAP
Basis Release 4.6C konnten lediglich ache Strukturen übermittelt werden.

Parallelisierung grosser Jobs mit aRFC (asynchronous RFC)
Grosse Jobs können in mehrere kleine Funktionsaufrufe aufgeteilt werden, die par-
allel ablaufen. aRFC ermöglicht den Aufruf und die Verwaltung dieser parallel
ablaufenden Funktionen. aRFC unterstützt Rückgabeparameter und ist nur in-
nerhalb einer ABAP-Umgebung verfügbar. Externe Programme können Threads
verwenden, um ein ähnliches Ergebnis zu erzielen.

Datenkonsistenz mit tRFC (transactional RFC)
Um die Ausführung von RFC-Funktionen verläÿlich, sicher und von der Ver-
fügbarkeit des RFC-Servers bzw. RFC-Server-Systems unabhängig zu machen,
wurde ab Release 3.0 für R/3-Systeme der transaktionale RFC eingeführt. Der
tRFC stellt im Gegensatz zu sRFC und aRFC sicher, dass der aufgerufene Funk-
tionsbaustein nur einmal im RFC-Server-System ausgeführt wird.
   Bei transaktionalen RFC-Aufrufen müssen die zu einer RFC-Funktion gehö-
renden Daten zunächst auf einer SAP-Datenbank im RFC-Client-System zwi-
schengespeichert werden. Nach erfolgter Verarbeitung müssen sie dem rufenden



                                                                              47
3. SAP R/3 Business Framework

ABAP-Programm zurückgemeldet werden. Um alles Andere kümmert sich die
tRFC-Komponente im R/3-System.
  Da bei externen Systemen eine Datenbank nicht immer verfügbar ist, wur-
de die Verbindung zu den tRFC-Schnittstellen so implementiert, dass die auf
RFC API basierenden Client- oder Server-Programme einige zusätzliche Verwal-
tungsfunktionen übernehmen müssen, um sicherzustellen, dass der entsprechende
Funktionsbaustein nur einmal ausgeführt wird.

Zuverlässiger Nachrichtenaustausch über qRFC (queued RFC)
qRFC ist eine Erweiterung des tRFC und bietet zuverlässige Kommunikation
mit der Garantie für die einmalige Ausführung von Funktionsaufrufen in fester
Reihenfolge. Es erlaubt die Bestimmung einer festgelegten Sequenz von Ausfüh-
rungen der Funktionsaufrufe. Dabei existiert ein Unterschied zwischen inbound-
und outbound-Warteschlangen, der davon abhängig ist, ob die Schlange im auf-
rufenden System oder im aufgerufenen System gepegt wird. qRFC bietet eine
Reihe von APIs an, um die Ausführung der Warteschlange zu kontrollieren. Es ist
mit dem SAP Basis Release 4.6B verfügbar, kann aber auch in allen Systemen bis
hinab zum 3.1I durch die Installation der entsprechenden Erweiterungen imple-
mentiert werden. qRFC kann sowohl in ABAP als auch in externen Programmen
verwendet werden.

Parameter in RFC-Aufrufen
Parameter werden bei einem RFC-Aufruf anders gehandhabt als bei einem lokalen
Aufruf.
   Bei TABLES-Parametern wird nur die eigentliche Tabelle, aber nicht der Tabel-
lenkopf übergeben. Falls keine Tabelle angegeben wird, verwendet der aufgerufene
Funktionsbaustein eine leere Tabelle.
   Um die Netzwerkbelastung bei der Parameter- und Ergebnisübergabe mög-
lichst gering zu halten, arbeitet RFC mit einem Delta-Verwaltungsmechanismus.
Als Parameter bei Funktionsbausteinaufrufen können interne ABAP-Tabellen
verwendet werden. Bei einem lokalen Funktionsbausteinaufruf wird eine Parame-
tertabelle by reference übergeben. Es muss also keine neue lokale Kopie angelegt
werden. RFC unterstützt die Übergabe by reference jedoch nicht. Aus diesem
Grund muss die gesamte Tabelle vom RFC-Client zum RFC-Server und zurück
übergeben werden. Sobald der RFC-Server die Tabelleneinträge erhält, legt er
eine lokale Kopie dieser Tabelle an. An den RFC-Client werden dann nur noch
die Delta-Informationen zurückgegeben. Diese werden gesammelt und erst über-
tragen, wenn die Funktionskontrolle zum RFC-Client zurückkehrt, so dass nicht
bei jeder Tabellenoperation eine Übertragung erfolgt.
   Bei der ersten Übergabe einer Tabelle erhält die Tabelle eine Objekt-ID und
wird im aufrufenden System als virtuelle globale Tabelle registriert. Diese Regi-



48
                                                    3.5. Kommunikationsdienste

strierung bleibt erhalten, solange weitere Aufrufe zwischen dem rufenden und dem
gerufenen System möglich sind. Bei folgenden Aufrufen werden also die Delta-
Informationen übergeben, um die lokale Kopie zu aktualisieren. Die Tabelle selbst
muss nur beim ersten RFC-Aufruf kopiert werden.

3.5.2. Distributed Component Object Model (DCOM)
Das Distributed Component Object Model (DCOM) von Microsoft ist ein Pro-
tokoll, das es Softwarekomponenten erlaubt, direkt über das Netzwerk auf eine
zuverlässige, sichere und eziente Art und Weise zu kommunizieren. DCOM ba-
siert auf der Spezikation des DCE-RPC der Open Software Foundation und
arbeitet mit Java Applets und ActiveX- Komponenten durch die Verwendung
des Component Object Model (COM). Details zu DCOM können unter [DCO]
nachgelesen werden.
   DCOM kann als standardisierte Grundlage für die Erstellung und die Integrati-
on verteilter Software-Komponenten angesehen werden. Es kann als Infrastruktur
für die Kommunikation von externen Client-Anwendungen mit SAP-Servern ge-
nutzt werden, so dass Client-Anwendungen der Zugri auf R/3-Komponenten
ermöglicht wird.
   BAPIs und Funktionsbausteine können mit dieser Technologie als COM-
Objekte in Erscheinung treten und die Laufzeitumgebung des Microsoft Tran-
saction Servers (MTS) nutzen.




                                                                              49
3. SAP R/3 Business Framework




50
4. Zugri auf SAP R/3 über die
   Programmiersprache Java

In Kapitel 3 wurde das SAP R/3 Business Framework behandelt. Während dort
grundlegende Technologien für den Zugri auf ein SAP R/3-System beschrie-
ben wurden, konzentriert sich dieses Kapitel auf den praktischen Einsatz dieser
Technologien mit Hilfe unterschiedlicher Produkte.
   Der Schwerpunkt liegt dabei auf einer Umsetzung des Zugris auf SAP R/3
über die Programmiersprache Java, weil diese aufgrund der Zielsetzung der Di-
plomarbeit innerhalb der Connector-Architektur zum Einsatz kommen soll. Bi-
bliotheken wie beispielsweise die RFC API werden aus diesem Grund nicht ex-
plizit beschrieben, wenn bereits entsprechende Java-Umsetzungen existieren.
   Produkte, die nicht direkt für einen Zugri über die Programmiersprache Java
entwickelt wurden, werden ebenfalls beschrieben, wenn sie beispielsweise wie beim
SAP Business Connector über Schnittstellen erreichbar sind, die auch von Java
aus genutzt werden können.
   Der SAP Java Connector (JCo) wird in diesem Kapitel detaillierter behan-
delt als die anderen Technologien, weil ihm in späteren Kapiteln eine besondere
Bedeutung zukommt.


4.1. SAP Java Connector (JCo)
Der SAP Java Connector (JCo) ermöglicht dem Programmierer, RFC-Programme
auf einem Nicht-SAP-System in Java zu schreiben, ohne direkt auf das RFC
API (Remote Function Call Application Programming Interface) zugreifen zu
müssen. Bei dem RFC API handelt es sich um eine C-Bibliothek. Der JCo setzt
auf dieser Bibliothek auf und kann als objektorientierte Schicht über dem RFC
API angesehen werden. Trotz seines Namens ist der JCo kein Connector bzw.
Ressourcenadapter im Sinne der J2EE Connector-Spezikation.
  Der JCo erlaubt Anwendungen die Kommunikation mit beliebigen SAP-
Systemen. Laut SAP [JCO] verbindet er eine einfach zu benutzende API mit
beispielloser Flexibilität und Geschwindigkeit. Aufrufe auf SAP-Systemen durch
Java und Aufrufe von Java durch SAP-Systeme werden unterstützt.
  Der JCo wird von SAP zur Verfügung gestellt und steht mit der Version 1.1.03



                                                                              51
4. Zugri auf SAP R/3 über die Programmiersprache Java

für die Betriebssysteme Windows NT, Windows 2000, Linux, Solaris, IBM-AIX,
HP-UX und OSF1-alpha bereit.
   Nach SAP-Angaben [JCO] ist der JCo die beste Wahl für die Entwicklung von
Java-Applikationen mit SAP-Funktionalität. Folgende Merkmale des JCo werden
als Begründung genannt, wobei die Abkürzung RFM für Remote Function Modu-
le steht und einen Funktionsbaustein beschreibt, der entfernt (remote) aufgerufen
werden kann:

     • RFC Middleware mit hoher Geschwindigkeit basierend auf dem Java Native
       Interface (JNI)

     • R/3 3.1H und höher werden unterstützt (und andere mySAP Komponenten,
       die BAPIs oder RFMs beinhalten).

     • Inbound- (Java Client ruft BAPI oder RFM) und Outbound-Aufrufe
       (ABAP ruft Java Server) werden unterstützt.

     • Synchrone, transaktionale (wichtig für IDocs) und queued RFCs werden
       unterstützt.

     • Connection Pooling (gut für Webserver) wird unterstützt.
     • Mehrere Plattformen werden unterstützt.
     • Eine komplette und korrekte Code-Page-Verarbeitung ist enthalten.
     • Der JCo ist einfach zu installieren und einzusetzen.

  Der JCo unterstützt neben sRFCs auch tRFCs und qRFCs [Sch02]. tRFCs
werden vorwiegend für den Transfer von ALE Intermediate Documents (IDocs)
verwendet. Zur Zeit behandelt die JCo-Dokumentation allerdings lediglich sRF-
Cs.

4.1.1. Verbindungsarten
Der JCo unterstützt zwei Programmiermodelle für die Verbindung zu SAP-
Systemen. Beide Modelle können in einer Applikation kombiniert werden.

     • Direkte Verbindungen (direct connections)
       Direkte Verbindungen werden erzeugt und so lange oen gehalten wie ge-
       wünscht.

     • Verbindungspools (connection pools)
       Aus einem Verbindungspool kann eine Verbindung genommen werden, wenn
       sie gebraucht wird. Diese Verbindung sollte so schnell wie möglich wieder
       in den Pool zurückgelegt werden, falls andere sie benötigen sollten.



52
                                                4.1. SAP Java Connector (JCo)

  Der Aufbau einer Verbindung zum SAP-System erzeugt einen gewissen Over-
head, der vor allem durch das Einloggen entsteht. Deshalb sollte häuges Schlie-
ÿen und häuger Neuaufbau bei der Verwendung direkter Verbindungen vermie-
den werden. Verbindungspools können z. B. in Webserver-Applikationen einge-
setzt werden, um eine bessere Ausnutzung der Verbindungen zu erreichen.

Direkte Verbindungen
Um eine direkte Verbindung über den JCo zum SAP-System herzustellen, werden
drei wichtige Klassen des JCo benötigt:

JCO ist die Hauptklasse des SAP Java Connector. Sie bietet zahlreiche statische
     Methoden an.

JCO.Client repräsentiert eine Verbindung zum SAP-System.
JCO.Attributes enthält Verbindungsattribute wie z. B. die Version des SAP-
     Systems.

  Detaillierte Informationen zu den einzelnen Klassen können in der Java-
Dokumentation (Javadoc) des JCo nachgelesen werden. Diese wird mit dem JCo
mitgeliefert.
  Jedes Programm, welches den JCo verwendet, sollte die entsprechenden Java-
Bibliotheken über die import-Anweisung einbinden:
import com.sap.mw.jco.∗;
Ohne diese Anweisung muss der komplette Name jeder Klasse angegeben werden,
was unüblich und umständlich erscheint.
  Die Verbindungsvariable des Client zum SAP-System kann folgendermaÿen
deniert werden:
JCO.Client client;
  Das Client-Objekt wird über die createClient-Methode der Klasse JCO er-
zeugt. Es existieren mehrere überladene Versionen dieser Methode, die in der
Java-Dokumentation des JCo beschrieben werden.
  Ein Beispiel für die Erzeugung eines Verbindungsobjekts könnte wie folgt aus-
sehen:
client = JCO.createClient(
  "001",         // SAP Client
  "user",        // Benutzer
  "password",    // Passwort
  "DE",          // Sprache
  "servername", // Servername
  "00" );        // Systemnummer



                                                                             53
4. Zugri auf SAP R/3 über die Programmiersprache Java

  Die Erzeugung des JCO.Client-Objekts stellt allerdings noch keine Verbindung
zum SAP-System her. Dies geschieht erst über die connect-Methode:
try {
     client .connect();
}
catch( Exception e ) {
    System.out.println( "Exception gefangen: \n" + e );
    System.exit ( 1 );
}
   Nach dem Herstellen der Verbindung können Funktionen in SAP aufgerufen
werden. Die Ausgabe der Verbindungsattribute kann über die folgende Anweisung
erfolgen:
System.out.println( client .getAttributes () );
     Das Schliessen der Verbindung übernimmt die disconnect-Methode:
client .disconnect ();


Verbindungspools
In Server-Applikationen wie einem Webserver erscheint die Verwendung von Ver-
bindungspools sinnvoll, da eine bessere Ausnutzung der Verbindungen möglich
ist.
   Ein Verbindungspool des JCo wird durch einen global denierten Namen iden-
tiziert, der in der Java Virtual Machine (JVM) eindeutig ist. Alle Verbindungen
in einem Pool verwenden die gleichen System-, Benutzer- und Clientinformatio-
nen. Es können so viele Pools wie benötigt existieren.
   Folgende zusätzliche Klassen werden in Zusammenhang mit Verbindungspools
benötigt:

    JCO.Pool repräsentiert ein Verbindungspool.
    JCO.PoolManager verwaltet alle Verbindungspools innerhalb einer Java Virtual
        Machine (JVM).

     Die Erzeugung eines Verbindungspools kann wie folgt aussehen:
JCO.addClientPool(
  "Beispielpool", //      Name des Verbindungspools
  10,              //     max. Anzahl Verbindungen
  "800",           //     SAP Client
  "user",          //     Benutzer
  "password",      //     Passwort
  "DE",            //     Sprache



54
                                              4.1. SAP Java Connector (JCo)

 "servername",     // Servername
 "00" );           // Systemnummer
  Wenn eine neue Verbindung aus dem Pool benötigt wird, kann eine entspre-
chende Anfrage gestellt werden:
client = JCO.getClient( "Beispielpool" );
  Die getClient-Methode liefert entweder eine bestehende oene Verbindung
zurück oder önet eine neue, wenn die Anzahl maximaler Verbindungen noch
nicht erreicht wurde.
  Durch die releaseClient-Methode sollte die Verbindung wieder in den Ver-
bindungspool zurückgeführt werden, wenn sie nicht mehr benötigt wird.
  Details zur Programmierung von Verbindungspools können in dem beiliegenden
Programmierleitfaden des JCo [Sch02] nachgelesen werden. Dort werden auch
mögliche Fehlerquellen und die Behandlung von Exceptions erläutert.

4.1.2. BAPIs und andere RFMs
ABAP Funktionsbausteine können nur von externen Clients aufgerufen werden,
wenn sie RFC-fähig sind. SAP R/3 bietet zahlreiche RFC-fähige Funktionsbau-
steine (RFMs). Unter ihnen sind die BAPIs, die als Objekttypen im Business
Object Repository (BOR) deniert sind. Über den JCo können RFMs aufge-
rufen werden, wobei es keine Rolle spielt, ob es sich dabei um BAPIs handelt
oder nicht. Die Transaktionscodes BAPI und SE37 können verwendet werden,
um Metainformationen über die BAPIs oder andere RFMs in SAP zu erhalten.
  RFMs können drei Arten von Parametern besitzen:

 import: Der Client sendet diesen Parameter zum RFM.
 export: Das RFM sendet diesen Parameter zurück zum Client.
 tables: Dieser Parameter kann in beide Richtungen übertragen werden.

  Import- und Exportparameter sind in der Regel einfache Felder oder Struktu-
ren, während der Tabellenparameter (tables) mehrere Zeilen und Spalten bein-
halten kann.

4.1.3. JCo Repository
Die Metainformationen aller RFMs, die über den JCo aufgerufen werden sollen,
müssen bekannt sein. Dies kann über das JCO.Repository-Objekt erfolgen. Die
Metainformationen der RFMs können im Repository-Objekt fest kodiert oder
dynamisch vom SAP-System zur Laufzeit abgerufen werden.
  Folgende neue Klassen werden in Verbindung mit dem JCo Repository einge-
führt:



                                                                          55
4. Zugri auf SAP R/3 über die Programmiersprache Java

 JCO.Repository enthält die Metainformationen der RFMs.

 IFunctionTemplate enthält die Metainformationen für ein RFM.

 JCO.Function repräsentiert ein RFM mit Parametern.

 JCO.ParameterList enthält die import-, export- und table-Parameter einer
     JCO.Function.

 JCO.Structure enthält eine Datenstruktur.

 JCO.Table enthält eine Tabelle.

  Die Erzeugung einer JCO.Repository-Instanz erfolgt über zwei Parameter.
Der erste gibt einen frei wählbaren Namen des Repository an, während der zwei-
te Parameter den Namen eines Verbindungspools oder ein JCO.Client-Objekt
enthält. Direkte Verbindungen und Verbindungspools werden also unterstützt.
Die Erzeugung eines Repository könnte wie folgt aussehen:
JCO.Repository repository = new JCO.Repository( "Beispielrepository", client );


Erzeugung eines Function-Objekts
Die Erzeugung eines JCO.Function-Objekts geschieht über zwei Schritte. Als
erstes wird ein IFunctionTemplate-Objekt erzeugt, welches alle Metainforma-
tionen für ein RFM enthält. Der JCo erhält diese Informationen lediglich einmal
und cacht sie aus Geschwindigkeitsgründen. Die getFunctionTemplate-Methode
des Interfaces IFunctionTemplate erzeugt die Funktionsvorlage, aus der über
die getFunction-Methode ein JCO.Function-Objekt erzeugt werden kann. Die-
ses Objekt enthält nicht nur Metainformationen, sondern auch die benötigten
Parameter für den Aufruf des RFM.

Ausführung von Funktionen
Als kleines Beispiel soll das BAPI CompanyCode.GetList aufgerufen werden. Der
zugrundeliegende RFM nennt sich BAPI_COMPANYCODE_GETLIST. Das BAPI benö-
tigt keine import-Parameter. Das Funktions-Objekt wird, wie im Abschnitt zu-
vor beschrieben, erzeugt und über die execute-Methode des JCO.Client-Objekts
aufgerufen:
IFunctionTemplate ftemplate =
  repository .getFunctionTemplate( "BAPI_COMPANYCODE_GETLIST" );
JCO.Function function = ftemplate.getFunction();
client .execute( function );



56
                                               4.1. SAP Java Connector (JCo)

 ABAP-Typ     Beschreibung                 Java Datentyp JCo Typ-Konstante
 b            1-Byte Integer               int            JCO.TYPE_INT1
 s            2-Byte Integer               int            JCO.TYPE_INT2
 l            4-Byte Integer               int            JCO.TYPE_INT
 C            Zeichen                      String         JCO.TYPE_CHAR
 N            Numerisches Zeichen          String         JCO.TYPE_NUM
 P            BCD (Binary Coded Decimal) BigDecimal       JCO.TYPE_BCD
 D            Datum                        Date           JCO.TYPE_DATE
 T            Zeit                         Date           JCO.TYPE_TIME
 F            Flieÿkommazahl               double         JCO.TYPE_FLOAT
 X            Raw Data                     byte[]         JCO.TYPE_BYTE
 g            String (variable Länge)      String         JCO.TYPE_STRING
 y            Raw Data (variable Länge)    byte[]         JCO.TYPE_XSTRING
    Tabelle   4.1.: Mapping von ABAP-Datentypen in Java-Datentypen


   Auf alle Parameter des JCO.Function-Objekts kann über die Me-
thoden       getImportParameterList,         getExportParameterList        und
getTableParameterList zugegrien werden. Innerhalb der zurückgeliefer-
ten Parameterlisten können die einzelnen Parameter über ihren Typ und
Namen erreicht werden. Die Methode getStructure erlaubt den Zugri auf alle
Struktur-Parameter in einer Import- oder Export-Parameterliste.
   Eine Struktur besteht aus Feldern, die jeweils einen bestimmten Datentyp be-
sitzen. ABAP verwendet andere Datentypen als Java, wodurch ein Mapping der
Datentypen notwendig wird. Die Tabelle 4.1 zeigt die unterschiedlichen Datenty-
pen und das erforderliche Mapping basierend auf der JCo-Dokumentation [Sch02]:
   Die Klasse JCO.Structure enthält typspezische get-Methoden wie getString
für Strings. Genaue Informationen dazu können der Java-Dokumentation des JCo
und der JCo-Dokumentation [Sch02] entnommen werden.

Zugri auf Tabellen
Nachdem der BAPI-Aufruf erfolgreich verlaufen ist, kann die Tabelle mit den Da-
ten aller Company Codes ausgegeben werden. Als erstes kann die Liste der Ta-
bellenparameter über die getTableParameterList-Methode abgerufen werden,
in der dann über die getTable-Methode auf eine konkrete Tabelle zugegrien
werden kann. Das folgende Beispiel zeigt, wie die Tabellendaten ausgelesen und
ausgegeben werden können:
JCO.Table codes =
  function.getTableParameterList().getTable( "COMPANYCODE_LIST" );

for ( int i = 0; i < codes.getNumRows(); i++, codes.nextRow() ) {
  System.out.println(



                                                                            57
4. Zugri auf SAP R/3 über die Programmiersprache Java

     codes.getString ( "COMP_CODE" ) + '\t' +
     codes.getString ( "COMP_NAME" ) );
}
  Möglichkeiten der Manipulation von Tabellen können der JCo-Dokumentation
[Sch02] entnommen werden.

Setzen von Importparametern
Importparameter sind in der Regel skalare Parameter (Felder) und werden benö-
tigt, wenn dem aufzurufenden BAPI Parameter übergeben werden müssen. Wäh-
rend über die getImportParameterList-Methode auf die Importparameterliste
zugegrien werden kann, können die Parameter über die setValue-Methode ge-
setzt werden. Um beispielsweise den Parameter MAXROWS für die maximale Anzahl
von Zeilen auf 100 zu setzen, kann folgende Zeile verwendet werden:
function.getImportParameterList().setValue( "100", "MAXROWS" );



4.2. Ressourcenadapter
Neben dem SAP Resource Adapter (SAP-RA) existieren zahlreiche Ressour-
cenadapter im Sinne der J2EE Connector-Spezikation, die von Fremdher-
stellern für den Zugri auf SAP-Systeme realisiert wurden. Eine aktuelle Li-
ste von Produkten ist auf der Sun-Homepage im Connector-Bereich unter
http://java.sun.com/j2ee/connector/products.html zu nden. Der SAP
Resource Adapter soll an dieser Stelle exemplarisch beschrieben werden. Kapitel 6
und 7 werden die Entwicklung und den Einsatz eines solchen Ressourcenadapters
für den Zugri auf ein SAP R/3-System im Detail behandeln.


4.2.1. SAP Resource Adapter
Der SAP-RA wurde von einer Tochtergesellschaft der SAP AG, der In-Q-My
Technologies GmbH, entwickelt. Die von In-Q-My angebotene Software ist neu-
erdings komplett in die mySAP Technology Lösung integriert.
  mySAP Technology bietet nach Angaben von SAP eine Web-Infrastruktur, die
auf oenen Standards basiert. Als Ergebnis daraus resultiert die Unterstützung
heterogener Umgebungen und die Möglichkeit der Integration beliebiger Appli-
kationen von beliebigen Anbietern, die auf diesen Technologien basieren. [INQ]
  Die zertizierte J2EE-Software von In-Q-My wurde mit dem SAP Web Appli-
cation Server vereinigt, der Teil der mySAP Technology Lösung ist.
  Da diese Informationen erst gegen Ende der Erstellung dieser Diplomarbeit
bekannt wurden, basiert die folgende Beschreibung auf der von In-Q-My zur
Verfügung gestellten Dokumentation The SAP Resource Adapter [SAP01].



58
                                                                4.2. Ressourcenadapter


                   J2EE Server inklusive eingebundener Komponenten

                 J2EE                                        Applikation
           Applikationsserver
                                                         (z. B. EJB oder JSP)




                                        Function Proxy



                                                                   CCI


                                    Systemkontrakte         SAP Resource
                                                               Adapter




                                                                 JCO




                                                                     RFC über TCP/IP




                                                             SAP System



                     Abbildung 4.1.: SAP Resource Adapter


  Der SAP-RA verwendet den zuvor behandelten SAP Java Connector (JCo) für
den Zugri auf SAP-Systeme. Der Aufbau und Einsatz des SAP-RA wird durch
Abbildung 4.1 verdeutlicht, die auf der Dokumentation zum SAP-RA basiert. Der
JCo bendet sich zwischen dem eigentlichen Ressourcenadapter und dem SAP-
System. Die gezeigte Architektur ist aus Kapitel 2 zur Connector-Architektur
bekannt. Der SAP-RA kann von Applikationskomponenten wie EJBs über das
Common Client Interface (CCI) angesprochen werden.
   Auällig ist der Function Proxy, welcher Datenstrukturen für Funktionsaufru-
fe mit den entsprechenden Parametern generieren soll, die für den Aufruf von
Funktionen genutzt werden können. Da jeder Parameter des CCI des SAP-RA
ein Typ der Klasse Object ist, soll der Function Proxy Funktionsaufrufe verein-



                                                                                       59
4. Zugri auf SAP R/3 über die Programmiersprache Java

fachen und typsicher machen. Dieser Function Proxy bendet sich nach Angaben
der verfügbaren Dokumentation noch in der Entwicklung.
  Im Folgenden möchte ich einige verfügbare und nicht verfügbare Eigenschaften
des SAP-RA aufzeigen, die in Bezug auf die Connector-Architektur von Bedeu-
tung sind.


     • Unterstützung von Verbindungspools und des Verbindungs-Sharing

     • keine Unterstützung der Reauthentisierung aufgrund der Beschränkungen
       durch das SAP-System

     • Da das SAP-System kein 2-Phasen-Commit-Protokoll unterstützt, werden
       nur lokale Transaktionen ermöglicht. XA-basierte Transaktionen sind nicht
       verfügbar.

     • Unterstützung des CCI (bis auf den Java-Datentyp IndexedRecord)

     • Authentisierung durch den JAAS ist derzeit             nur    über   eine
       Benutzername/Passwort-Kombination möglich.




4.3. Java RFC Class Library
Das Java RFC Client und Server Paket gibt eine einfache objektorientierte Sicht
auf die RFC API von SAP. Java-Entwickler können damit reine Java-Programme
schreiben, die mit einem R/3-System kommunizieren. Es sind keine Kenntnisse
über die C- oder C++- Aufrufe der zugrundeliegenden RFC API notwendig. Viele
Details werden durch das Paket verborgen, so dass eine starke Komplexitätsre-
duzierung bei der RFC-Programmierung in Java zu verzeichnen ist.
   Die Client-Pakete erzeugen Proxy-Objekte der Objekte auf dem Server. Die
Proxy-Objekte arbeiten im Namen des wirklichen Objekts transparent gegen-
über dem Client. Die Kommunikation zwischen Client und Server erfolgt über
Schnittstellen der Common Object Request Broker Architecture (CORBA) oder
das Java Native Interface (JNI). Die verwendeten ORBs (Object Request Broker)
in Verbindung mit CORBA sind Orbix und OrbixWeb von IONA Technologies.
   Abbildung 4.2 stellt das Zusammenspiel der Komponenten in Verbindung mit
der Java RFC Class Library dar.
   Als Informationsquelle diente vor allem der Abschnitt Java RFC Architecture
der SAP-Bibliothek [SAP].



60
                                             4.3. Java RFC Class Library




        Externe(r) Computer

               Eigene Java
           Client− oder Server−
               Applikation



              Java RFC
             Class Library
              Interface
                                                R/3 System

              Java RFC
             Middleware
            (JNI, CORBA)



               RFC C++
             Class Library


                                  RFC
              RFC Library



Abbildung 4.2.: Zusammenspiel der Komponenten in Verbindung mit der Java
                RFC Class Library




                                                                      61
4. Zugri auf SAP R/3 über die Programmiersprache Java




       R/3      FB−Aufruf                                                           externes
               BAPI−Aufruf                    XML                         XML
     System       IDoc                      Nachricht                   Nachricht
                                                                                    System
                             SAP Business               ...   WWW ...
                              Connector




                   Abbildung 4.3.: SAP Business Connector


4.4. SAP Business Connector (BC)
Der SAP Business Connector (BC) erlaubt die Erweiterung von Geschäftsprozes-
sen über das Internet. Eine Integration von Nicht-SAP-Produkten ist über eine
oene und nicht-proprietäre Technologie möglich.
   Der SAP BC erzeugt aus einem BAPI-Aufruf ein XML-Dokument oder wan-
delt ein eingehendes XML-Dokument in einen BAPI-Aufruf um. Dadurch wird
es möglich, BAPI-Aufrufe als XML-Dokumente zu versenden und eine Kommu-
nikation über das Internet zu gewährleisten.
   Mit dem SAP BC bietet SAP eine XML-Schnittstelle zum R/3-System an.
Diese Schnittstelle wurde jedoch nicht komplett neu entwickelt. Der SAP BC setzt
auf bereits vorhandenen Schnittstellen auf und ist als eigenständige Komponente
auÿerhalb des R/3-Systems realisiert.
   Der SAP BC vereinigt einen RFC-Server und einen RFC-Client. Er unterstützt
bidirektionale Kommunikation mit einem SAP-System in Echtzeit. Aus Sicht ei-
ner SAP-Anwendung besteht zwischen dem Aufruf des SAP BC und dem Aufruf
eines anderen RFC-Servers kein Unterschied. Das RFC-Format wird in XML
oder HTML konvertiert, so dass auf der anderen Seite der Kommunikation keine
SAP-Software benötigt wird.
   Abbildung 4.3 verdeutlicht die Zusammenhänge zwischen einem externen Sy-
stem, dem Business Connector und einem SAP R/3-System.
   Der SAP Business Connector unterstützt synchrone (sRFC) und asynchrone
(aRFC) Aufrufe von SAP-Systemen transparent. Somit werden auch BAPIs und
ALE-Szenarien unterstützt.
   Der SAP BC wurde komplett in Java geschrieben und läuft auf jeder Maschine,
auf der eine Java Virtual Machine (JVM) der Version 1.1.6 oder höher verfügbar
ist. Für die Verbindung zu SAP-Systemen wird zusätzlich die C-Bibliothek librfc
von SAP in der shared-Version benötigt. Der SAP BC ist kompatibel mit SAP-
Software ab Release 3.1G oder höher.



62
                                            4.4. SAP Business Connector (BC)

4.4.1. Funktionalität
Folgende Funktionalitäten werden durch den SAP BC zur Verfügung gestellt
[SAP00a]:

   • Ausführung von BAPIs
     XML-basierte SAP BC-Dienste können eingerichtet werden, um BAPIs in-
     nerhalb eines Unternehmens auf einem SAP-Server auszuführen. Genau-
     so können Geschäftspartner Anfragen über das Internet stellen, um einen
     Dienst aufzurufen, der eine BAPI ausführt.

   • Ausführung von RFCs
     Die gesamte SAP-Funktionalität, die über RFC zur Verfügung steht, kann
     vom SAP BC-Server erreicht werden. Externe Applikationen benötigen kei-
     ne Kenntnisse der SAP Datentypen, ABAP Strukturen oder des RFC-
     Protokolls, um mit einem SAP-System zu kommunizieren.

   • Aufruf von SAP BC-Diensten von SAP-Systemen
     SAP BC-Dienste können von einem SAP-System aufgerufen werden. Das
     erlaubt dem SAP Benutzer, Informationen abzufragen, die über den SAP
     BC-Server erreichbar sind. Der SAP BC-Server erlaubt B2B-Integration
     zwischen Geschäftspartnern, welche die Reichweite der SAP-Infrastruktur
     zu den Kunden, Partnern und Lieferanten erweitern kann.

   • Routen von SAP Geschäftsdokumenten (IDocs)
     SAP Geschäftsdokumente (IDocs) können entsprechend spezizierter Kri-
     terien geroutet werden. Der SAP BC-Server stellt zahlreiche Routing-
     Einstellungen für IDocs zur Verfügung. Es existieren zahlreiche unterschied-
     liche Transportarten inklusive dem Routen von IDOCs zu anderen SAP-
     Systemen, zu einem mySAP.com Marktplatz oder zu einer URL im XML-
     Format.

   Obwohl der SAP BC komplett in Java implementiert wurde, ist er nicht für
den Einsatz aus der Programmiersprache Java heraus beschränkt. Da er auf dem
Austausch von XML-Dokumenten basiert, kann er über beliebige Programmier-
sprachen genutzt werden, die XML-Dokumente verarbeiten können.
   Als wichtige Quellen dieses Abschnitts dienten der SAP Business Connec-
tor Integration Guide [SAP00a], das White Paper SAP Middleware Technolo-
gies [SAP00b] und die Ausarbeitung Unterstützung von Kopplungsarchitektu-
ren durch SAP R/3 [MS01]. Genauere Informationen zum BC können diesen
Quellen entnommen werden.



                                                                              63
4. Zugri auf SAP R/3 über die Programmiersprache Java


                          SAP         WEB




       R/3               Internet Transaction     ISAPI
                SAPgui          Server            NSAPI                      Webbrowser
     System      RFC                                                  HTTP
                                                   CGI    Webserver
                                 TCP/IP
                         AGate            WGate




                  Abbildung 4.4.: Internet Transaction Server


4.5. Internet Transaction Server (ITS)
Für den Zugri auf ein SAP-System über einen Webbrowser ist ein Vermittler
notwendig, der die Verbindung zwischen SAP-Technologie und Web-Technologie
herstellt. Der SAP Internet Transaction Server (ITS) stellt einen solchen Ver-
mittler dar.
  Auf der einen Seite bietet er den Service eines Webservers, über den Funktio-
nalitäten aufgerufen werden können. Die gesamten Geschäftsprozesse werden an
das SAP-System weitergereicht, mit dem er wie ein normales SAPgui interagiert.



4.5.1. Aufbau
Der ITS ist das Bindeglied zwischen dem Web und SAP. Er besteht aus den
zwei getrennten Programmen WGate (Web Gateway) und AGate (Application
Gateway). Abbildung 4.4 verdeutlicht die Zusammenhänge.
   Eine Web-Anwendung mit ITS wird als eine SAP Internet Application Compo-
nent (IAC) bezeichnet. Ein IAC besteht aus verschiedenen Komponenten. Einige
davon benden sich auf dem ITS-Server, andere im SAP-System. Über einen
Webbrowser kann auf die SAP IACs zugegrien werden, die im SAP-System ver-
arbeitet werden.
   Der Webserver bildet die Schnittstelle zwischen Internet/Intranet und dem
ITS. Er nimmt HTTP-Anfragen von Clients (Browsern) entgegen und leitet diese,
falls erforderlich, über eine der unterstützten Schnittstellen an das WGate weiter.
Sowohl statische als auch dynamisch generierte HTML-Seiten können dem Client
zurückgeliefert werden.



64
                                         4.5. Internet Transaction Server (ITS)

Web Gateway (WGate)
Durch das WGate wird der ITS mit dem Webserver verbunden. Die folgenden
Standardschnittstellen von Webservern werden unterstützt:

   • Microsofts Information Server API (ISAPI)

   • Netscape Server API (NSAPI)

   • Common Gateway Interface (CGI)

   Das WGate erhält Anfragen vom Webserver und leitet diese an das AGate
weiter. Es verarbeitet keine Daten, kann im Bedarfsfall jedoch Fehlermeldungen
bei Kommunikationsproblemen erzeugen. Das WGate kommuniziert mit genau
einem AGate und besitzt einen Namen, der dem Namen des zugehörigen AGate
entspricht.

Application Gateway (AGate)
Das AGate läuft unter Windows NT 4.0 für Intel-Prozessoren und ist somit als
Windows NT Service implementiert. Es ist für die Kommunikation mit SAP zu-
ständig. Dies beinhaltet folgende Dienste:

   • Aufbau der Verbindung über SAPgui- oder RFC-Protokolle

   • Generierung der HTML-Dokumente für die SAP-Anwendungen

   • Verwaltung der Benutzer-Anmeldedaten

   • Verwaltung des Modus-Kontext und der Timeouts

   • Konvertierung der Code-Pages und Unterstützung der Landessprachen

  Auf einem Computer können mehrere AGate-Instanzen installiert sein. Jede
Instanz besitzt einen eindeutigen Namen.
  Der ITS enthält ein Verwaltungswerkzeug auf HTML-Basis, mit dem ITS-
Instanzen konguriert, gesteuert und überwacht werden können.

4.5.2. Funktionalität
Folgende Funktionalität wird durch den ITS bereitgestellt:

   • Skalierbarkeit

   • Handhabung der Anmeldung und der Benutzermodi im SAP-System

   • Transaktionale Konsistenz für Web-Anwendungen



                                                                            65
4. Zugri auf SAP R/3 über die Programmiersprache Java

     • Mehrsprachigkeit

     • Code Page Konvertierung

     • Volle Integration mit der ABAP Workbench

     • Änderungs- und Transportsystem

     • Benutzerverwaltung und Berechtigungskonzept

     • Viele von SAP mitgelieferte, direkt verwendbare IACs

     • Drei unterschiedliche Programmiermodelle: WebTransactions, WebRFC
       und WebReporting

  Details können der SAP-Bibliothek [SAP] entnommen werden, auf der die-
ser Abschnitt basiert. Als zusätzliche Informationsquelle diente die Ausarbeitung
Unterstützung von Kopplungsarchitekturen durch SAP R/3 [MS01].


4.6. SAP DCOM Connector
Das bereits in Abschnitt 3.5.2 vorgestellte Distributed Component Object Model
(DCOM) kann durch den SAP DCOM Connector genutzt werden. Der DCOM
Connector stellt eine von SAP entwickelte C++ Template Library zur Verfügung,
mit der COM-Objekte aus Business-Objekten des R/3-Systems erstellt und ver-
waltet werden können.
   R/3-Komponenten wie BAPIs oder entfernte Funktionsbausteine treten als
COM-Objekte in Erscheinung und nutzen die Laufzeitumgebung des Microsoft
Transaction Servers (MTS).
   Dieser Abschnitt basiert auf der Beschreibung DCOM Connector im Über-
blick der SAP-Bibliothek [SAP]. Eine aktuelle Dokumentation steht mit der
Installation des DCOM Connectors zur Verfügung.

4.6.1. Einsatzmöglichkeiten
Die folgenden beiden Beispiele zeigen unterschiedliche Einsatzmöglichkeiten des
DCOM Connectors:

     • PC Client-Applikationen
       Client-Applikationen können DCOM nutzen, um auf COM-Objekte zuzu-
       greifen, die auf einem oder mehreren MTS installiert sind. Der Zugri auf
       Komponenten des MTS erfolgt entfernt (remote). Die Client-Software kann
       ohne zusätzliche SAP-Software auf unterschiedlichen PCs installiert wer-
       den.



66
                                                 4.6. SAP DCOM Connector

  • Web-Szenario
    Active Server Pages (ASPs) können neben HTML auch ausführbare Skripts
    enthalten. Sie stellen Webseiten dar, die über DCOM auf die Komponenten
    eines MTS zugreifen können.


4.6.2. Merkmale
Folgende Merkmale kommen in Verbindung mit dem DCOM Connector zum
Vorschein:

  • Ermöglichung der Konzentration auf die Programmierung der Client-
    Applikation ohne Kenntnisse des RFC Protokolls

  • Verwendung komfortabler Entwicklungsumgebungen (z. B. Visual Basic
    5/6) für die Client-Entwicklung

  • Höhere Performance durch das Pooling von Ressourcen

  • Vereinfachung der Behandlung von Tabellen und Strukturen durch Micro-
    soft ActiveX Data Objects (ADO) unter Einsatz von Standard-Tools (z.B.
    Data Bound Control)

  • Abbildung von ABAP-Datentypen in entsprechende OLE-Datentypen und
    umgekehrt erfolgt automatisch

  • Sicherheitsdienste des MTS werden in Anspruch genommen, um Zugrissi-
    cherheit zu garantieren

  • Intranet-Anwendungen können verteilt werden, ohne die SAP DLL und die
    entsprechenden ActiveX Controls liefern zu müssen. Die netzweite Pege
    von Kongurationsdateien entfällt.

  • Es entsteht keine BOR-Laufzeit, da der Aufruf von BAPIs direkt über des-
    sen Funktionsbausteine erfolgt.

  • BOR-Namen für Methoden, Schlüsselfelder und Parameter werden vollstän-
    dig und case-sensitiv übernommen.

  • Die Generierung von DCOM-Proxies und deren Installation im MTS erfolgt
    komfortabel über die Benutzungsschnittstelle des DCOM Object Builder.

  • Der Object Builder erlaubt die Generierung und Installation eines Session-
    Objekts.



                                                                           67
4. Zugri auf SAP R/3 über die Programmiersprache Java

     • Eine binäre Beschreibung der Schnittstellen von R/3-Komponenten wer-
       den in einer Type Library abgelegt. Sie ist Bestandteil der Proxy-Objekte,
       so dass Metainformationen zur Design- und Laufzeit des Clients verfügbar
       sind. In der Entwicklungsumgebung sind somit Schnittstellendenitionen
       sichtbar. Zur Laufzeit sind keine Rückverbindungen zum SAP-System not-
       wendig, wodurch ein Performance-Gewinn erzielt werden kann.

4.6.3. Entwicklungsumgebungen
Die generierten Objekte sind generell von allen Programmiersprachen aus ver-
wendbar, die COM unterstützen.
  Folgende Umgebungen wurden von SAP für die Entwicklung von Client-
Applikationen getestet:

     • Visual C++

     • Visual Basic und VBA

     • Java (Microsoft Virtual Machine)

     • Active Server Pages (ASP)

     • Java Script

     • VB Script




68
5. Beispielszenario
   Materialverwaltung

Die Zielsetzung dieser Diplomarbeit beinhaltet neben der Untersuchung der
Connector-Architektur und Zugrismöglichkeiten auf das SAP R/3-System auch
die praktische Umsetzung eines Beispielszenarios. Für den Entwurf dieses Szena-
rios sind Entscheidungen bezüglich der zu verwendenden Technologien zu treen.
Die Grundlage für diese Entscheidungsndung bilden die vorangegangenen Ka-
pitel. Der Weg zur Gesamtarchitektur des Beispielszenarios wird durch dieses
Kapitel beschrieben.


5.1. Der Weg zur Idee
Das zu entwickelnde Beispielszenario soll einen Weg aufzeigen, über den ein Cli-
ent durch die Benutzung der Connector-Architektur auf ein SAP R/3-System
zugreifen kann.
   Der Client muss so gestaltet sein, dass er die Möglichkeiten und das Zusam-
menspiel der zugrundeliegenden Technologien aufzeigt. Seine Funktionalität spielt
eine untergeordnete Rolle.
   Als Favorit für das Beispielszenario stellte sich der Bereich Materialwirtschaft
heraus. Der einfache Grund dafür war die Bereitschaft einer Mitarbeiterin eines
Oldenburger Unternehmens, Einblicke in diesen Teilbereich des SAP R/3-Systems
zu vermitteln. Auch wenn sich diese Einblicke auf das SAPgui beschränkten und
nicht bis auf die Ebene der ABAP-Programmiersprache oder BAPI-Funktionen
reichten, so waren sie doch hilfreich, die später verwendeten Materialdaten wie-
derzunden und bearbeiten zu können.
   Somit entstand die Idee eines Clients zur Materialverwaltung. Dieser sollte
es erlauben, Materialien im SAP R/3-System zu suchen und anzuzeigen. Das
Anlegen, Verändern und Löschen eines Materials war ebenfalls erwünscht, führte
jedoch zu Problemen, deren Gründe im Kapitel zur Implementierung des Clients
beschrieben werden.
   Auch andere Teilbereiche des SAP R/3-Systems wie beispielsweise das Con-
trolling oder Finanzwesen hätten als Grundlage eines Beispielszenarios dienen
können, solange sie den Zugri von aussen (z. B. per Remote Function Call) er-



                                                                                69
5. Beispielszenario Materialverwaltung



                                  Material anlegen



          Sachbearbeiter                       Materialsuche


                                                            >>benutzt<<


                                                       Materialdetails



                             Material ändern/löschen




        Abbildung 5.1.: Anwendungsfalldiagramm zur Materialverwaltung

möglichen. Das Patientendaten-Management-Modul IS-H stand leider nicht zur
Verfügung. Es wäre insbesondere in Bezug auf das EKKIS-Projekt für die Ver-
wendung innerhalb eines Beispielszenarios prädestiniert gewesen. Der prinzipielle
Zugri auf die unterschiedlichen SAP-Module ähnelt sich jedoch sehr, so dass die
Erkenntnisse auch auf das IS-H-Modul übertragen werden können.


5.2. Entwurf
Abbildung 5.1 verdeutlicht die einfach gehaltenen Anwendungsfälle innerhalb der
Materialverwaltung in Form eines Anwendungsfalldiagramms. Der Sachbearbei-
ter ist für die Bearbeitung der Materialdaten zuständig. Änderungsaufträge kann
er durch andere Personen erhalten. Für unser Beispiel ist dieser Vorgang nicht
wesentlich und soll deshalb nicht weiter verfolgt werden. Die Anwendungsfälle
sind die folgenden:

     • Material anlegen
      Das Anlegen von neuen Materialien wird z. B. erforderlich, wenn bisher
      nicht vorhandene Materialien in ein Lager aufgenommen werden. Die Ma-
      terialnummer, Materialbezeichnung und weitere materialspezische Daten
      werden erfasst.

     • Materialsuche
      Über die Materialsuche kann nach Materialien anhand der Bezeichnung
      eines Materials gesucht werden. Die Suchergebnisse werden in Form einer



70
                                                                              5.3. Architektur


                                                                              Ressourcenadapter
                                Webserver          Applikationsserver
                        HTTP (JSP, Servlet, RMI−                        JCA
   Webbrowser                                          Enterprise
                              HTML usw...) IIOP          Bean                         SAP R/3

                               RMI−IIOP                Enterprise
 Applikationsclient
                                                         Bean




                      Abbildung 5.2.: Architektur zum Beispielszenario

       Liste ausgegeben. Durch die Auswahl eines der Materialien dieser Liste
       werden dessen Materialdetails angezeigt.

   • Materialdetails
       Materialdetails beinhalten genauere Informationen über ein Material. Ne-
       ben der zu verwendenden Einheit kann z. B. auch der Lagerort angegeben
       werden. In die Anzeige der Materialdetails gelangt man über die Anwahl
       eines Materials aus der Materialsuche oder durch die direkte Angabe einer
       Materialnummer.

   • Material ändern/löschen
       Die Veränderung und das Löschen von Materialdaten kann bei Verände-
       rungen des Materialbestands oder bei Fehleingaben notwendig werden. Ge-
       ändert werden können alle Materialdaten, die auch in den Materialdetails
       sichtbar werden.



5.3. Architektur
Die in Abbildung 5.2 gezeigte Architektur stellt eine mögliche Verbindung zwi-
schen Clients und einem SAP R/3-System dar.
   Ein Webbrowser und eine Java-Applikation kommen als Clients in Frage, über
die der zuvor erwähnte Sachbearbeiter die Materialdaten bearbeiten kann. Die ei-
gentliche Funktionalität der zu entwickelnden Anwendung steckt in den Enterpri-
se Beans, während die Clients lediglich eine Benutzungsoberäche zur Verfügung
stellen. Die Enterprise Beans laufen innerhalb eines J2EE-Applikationsservers ab
und greifen über den Ressourcenadapter auf das SAP R/3-System zu.
   Der Zugri auf den J2EE-Applikationsserver erfolgt über RMI-IIOP. So wird
es in der EJB-Spezikation 2.0 [LGD01] vorgeschrieben. Das betrit sowohl den



                                                                                             71
5. Beispielszenario Materialverwaltung

Webserver als auch den echten Applikations-Client. Der Webserver kann die An-
wendungsdienste der Enterprise Beans innerhalb des Applikationsservers nutzen,
so dass auch ein Webbrowser in Form eines Clients darauf zugreifen kann.
  Die Verbindung des J2EE-Applikationsservers zum SAP R/3-Modul erfolgt
über die Java Connector-Architektur (JCA), die bereits in Kapitel 2 ausführlich
behandelt wurde. Das Enterprise Information System (EIS) wird als Ressource
betrachtet, auf die ein Applikationsserver zugreifen kann. In diesem Fall handelt
es sich bei dem EIS um ein SAP R/3-System.
  Die Connector-Spezikation legt Teile der Schnittstellen des standardisierten
Adapters fest. So können J2EE-Applikationsserver über den Adapter auf das EIS
zugreifen, falls sie den Ressourcenadapter als Plug-in integrieren können.


5.4. Vorgehensweise
Für die Umsetzung des Beispielszenarios ist bereits jetzt absehbar, dass der Res-
sourcenadapter unabhängig vom Beispielclient entwickelt und implementiert wer-
den kann. Lediglich die von den Enterprise Beans gewünschte Schnittstelle für den
Zugri auf den Ressourcenadapter könnte einen Einuÿ bewirken. Ein Ressour-
cenadapter sollte jedoch nicht zu stark aus der Sicht einer bestimmten Enterprise
Bean betrachtet werden. Vielmehr sollte eine Betrachtung aus einer Sichtweise er-
folgen, die den Einsatz des Ressourcenadapters in unterschiedlichsten Szenarien
ermöglicht. Diese Betrachtungsweise hat einen wiederverwendbaren Ressource-
nadapter zur Folge, der Mehrfachentwicklungen unnötig macht. Diese Idee ist
ein wichtiger Bestandteil der Connector-Architektur und der damit verbundenen
Standardisierung von Schnittstellen.
   Aus diesem Grunde wird die Entwicklung des Ressourcenadapters in den fol-
genden Kapiteln von der Entwicklung der Beispielanwendung abgegrenzt. Die
Entwicklung des Ressourcenadapters steht dabei an erster Stelle, um der Bei-
spielanwendung bereits in der Implementierungsphase einen Zugri auf das SAP
R/3-System zu ermöglichen.


5.5. Entwicklungsumgebung
Als Entwicklungsplattform diente ein Rechner mit dem Betriebssystem Windows
2000 von Microsoft. Die folgenden Anforderungen stellten sich an diese Umge-
bung:

     • Verfügbarkeit der Java 2 SDK Enterprise Edition und Standard Edition
     • Verfügbarkeit eines J2EE-Applikationsservers,      der   die   Connector-
       Architektur unterstützt.

     • Verfügbarkeit eines SAP Frontends



72
                                                     5.5. Entwicklungsumgebung

  Jede weitere Plattform, die diese Anforderungen erfüllt, hätte die Entwicklung
ebenso ermöglicht.
  Es existieren zahlreiche Applikationsserver unterschiedlicher Hersteller für die
J2EE-Plattform. Als Beispiel sollen der BEA WebLogic und der Borland Enter-
prise Server genannt sein. Nicht alle Applikationsserver unterstützten zu Beginn
dieser Diplomarbeit die Connector-Architektur, so dass ich mich für das Origi-
nal, den J2EE-Applikationsserver von Sun, entschied. Dieser ist in der Enterprise
Edition 1.3.1 des Java 2 SDK enthalten, die mit der Standard Edition 1.3.1 die
Grundlage der Java-Entwicklung bildeten.
  Als SAP Frontend diente das SAPgui. Das SAP-System, welches für den
Test des Ressourcenadapters und die Beispielapplikation benötigt wurde, stellte
das Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge
und -Systeme (OFFIS) zur Verfügung. Es handelte sich um ein SAP R/3-System
der Release 4.6B.




                                                                               73
5. Beispielszenario Materialverwaltung




74
6. Entwicklung des
   Ressourcenadapters

Der Zugri auf ein SAP R/3-System über die J2EE Connector-Architektur erfor-
dert die Verwendung eines geeigneten Ressourcenadapters. Es stellen sich die Al-
ternativen der Neuimplementierung und der Verwendung eines bereits bestehen-
den Adapters. Da ein Ziel dieser Diplomarbeit die Untersuchung der Connector-
Architektur darstellt, soll auch die Entwicklung eines eigenen Ressourcenadapters
für den Zugri auf ein SAP R/3-System betrachtet werden. Ein solcher Entwick-
lungsprozess wird in diesem Kapitel beschrieben.


6.1. Entwurf
Die Schnittstellen des Ressourcenadapters werden durch die Connector-
Spezikation [Sha01b] weitgehend vorgegeben. Der Entwurf und die Implementie-
rung wird dadurch bereits stark beeinusst und in vorgegebene Bahnen gelenkt.
Ein Entwurf im eigentlichen Sinne ndet nicht mehr statt, da er bereits durch die
Connector-Spezikation vorgegeben wird. Es bleiben lediglich folgende Fragen zu
klären, die einen wichtigen Einuss auf die Entwicklung des Ressourcenadapters
bewirken:

   • Welche Schnittstellen der Connector-Architektur sollen bzw. können unter-
     stützt werden?
     Dazu ist beispielsweise zu klären, ob lokale und/oder XA-Transaktionen
     unterstützt werden sollen bzw. können.

   • Über welche Schnittstelle sollen Applikationskomponenten wie EJBs auf
     den Ressourcenadapter zugreifen?
     Das Common Client Interface (CCI) kommt beispielsweise in Frage. Es kann
     aber auch eine EIS-spezische Schnittstelle eingesetzt werden.

   • Welche Zugrismethode auf das EIS soll verwendet werden?
     Im Falle des zu entwickelnden Ressourcenadapters für den Zugri auf ein
     R/3-System kommen die in Kapitel 4 beschriebenen Zugristechnologien



                                                                              75
6. Entwicklung des Ressourcenadapters

       wie der SAP Java Connector (JCo) oder der SAP Business Connector für
       die Verwendung innerhalb des Ressourcenadapters in Frage.

  Im Folgenden möchte ich Antworten auf die genannten Fragen liefern, die sich
auf den zu entwickelnden Ressourcenadapter beziehen.


6.1.1. Unterstützte Schnittstellen
Der Ressourcenadapter kann selbstverständlich nur Schnittstellen unterstützen,
deren Funktionalität vom EIS umgesetzt werden kann. Es stellt sich zusätzlich
die Frage, welche Schnittstellen überhaupt benötigt werden und somit vom Ent-
wickler umgesetzt werden sollen.
   Im Fall des SAP R/3-Systems ist die Implementierung der XA-Schnittstellen
für verteilte Transaktionen nicht möglich, da das R/3-System das 2-Phasen-
Commit-Protokoll nicht unterstützt und derartige Transaktionen somit nicht zu-
lässt. Lediglich die Schnittstelle für lokale Transaktionen kann unterstützt wer-
den.
   Reauthentisierung ist ebenfalls aufgrund der Beschränkungen des SAP-Systems
nicht möglich.
   Die restlichen Schnittstellen der Connector-Spezkation sollen in dem zu ent-
wickelnden Ressourcenadapter nach Möglichkeit umgesetzt werden.


6.1.2. Schnittstelle für Applikationskomponenten
Als Schnittstelle für Applikationskomponenten wie beispielsweise EJBs kommt
das Common Client Interface (CCI) in Betracht. Dieses soll in dem zu entwickeln-
den Ressourcenadapter weitgehend umgesetzt werden. Da diese Schnittstelle von
der Connector-Spezikation nicht vorgeschrieben wird, kann an geeigneten Stellen
davon abgewichen werden, wenn dies sinnvoll erscheint.


6.1.3. Wahl der Zugrismethode
In Kapitel 4 wurden unterschiedliche Möglichkeiten für den Zugri auf das SAP
R/3-System über die Programmiersprache Java beleuchtet. Es soll der Entschei-
dungsndung einer Zugristechnologie auf das R/3-System dienen. Zahlreiche Ar-
gumente sprechen für den JCo (SAP Java Connector) als die bevorzugte Zugris-
methode des zu implementierenden Ressourcenadapters. Im Folgenden möchte
ich die wichtigsten Argumente aufzeigen, die meine Entscheidung für den JCo
festigten:

     • Der JCo ermöglicht den Zugri auf entsprechend freigegebene Funktions-
       bausteine eines SAP-Systems. Der Zugri auf BAPI-Funktionalität ist da-
       durch ebenfalls gegeben.



76
                                                                    6.1. Entwurf

   • Der JCo ist für unterschiedlichste Plattformen verfügbar und benötigt im
     Gegensatz zu anderen Zugristechnologien wie beispielsweise dem Inter-
     net Transaction Server oder dem SAP Business Connector keinen weiteren
     Server.

   • SAP empehlt den JCo für den Zugri auf R/3-Systeme über die Program-
     miersprache Java und verwendet diesen ebenfalls innerhalb des eigenen Res-
     sourcenadapters.

   Für die Neuentwicklung eines Ressourcenadapters scheint der JCo eine geeig-
nete Zugrismethode auf ein SAP-System zu sein. Falls jedoch eine Integration
von Anwendungen in einem bestehenden Umfeld erfolgen soll, in dem beispiels-
weise der SAP Business Connector erfolgreich eingesetzt wird, so kann es sinnvoll
sein, andere Zugristechnologien in den Ressourcenadapter einzubetten. Auf die-
sem Wege können bereits existierende Lösungen integriert und beispielsweise ein
existierender SAP Business Connector oder auch Internet Transaction Server an-
gesprochen und genutzt werden.


6.1.4. Architektur
Die Architektur des zu implementierenden Ressourcenadapters ergibt sich durch
die Kombination der Connector-Architektur in einer verwalteten Umgebung (Ab-
bildung 2.5 auf Seite 16) mit den in den letzten Abschnitten beantworteten Fra-
gestellungen. Abbildung 6.1 stellt das daraus resultierende Ergebnis dar.
   Folgende zentrale Klassen sind somit auf jeden Fall zu implementieren:

   • Die Klasse SAPConnectionFactory implementiert die Schnittstelle
     ConnectionFactory des CCI-Standards.

   • Die Klasse SAPConnection implementiert die Schnittstelle Connection des
     CCI-Standards.

   • Die Klasse SAPManagedConnectionFactory implementiert die Schnittstelle
     ManagedConnectionFactory.

   • Die Klasse SAPManagedConnection implementiert die Schnittstelle
     ManagedConnection.

   • Die Klasse SAPLocalTransactionSPI implementiert die Schnittstelle
     LocalTransaction des Transaktionskontraktes.
     Achtung: Es existiert ebenfalls eine Schnittstelle LocalTransaction des
     CCI-Standards, welche jedoch durch die Klasse SAPLocalTransactionCCI
     implementiert wird!



                                                                              77
6. Entwicklung des Ressourcenadapters


     Kontrakt der Connector−Architektur              Applikationskomponente
     implementierungsspezifisch



         Applikationsserver                             Ressourcenadapter

                 ConnectionManager            SAPConnectionFactory        SAPConnection




     Sicherheitsmanager

                                          SAPManagedConnectionFactory
            Verbindungsmanager
                                                                        SAPManagedConnection



                                          SAPLocalTransactionSPI



          ConnectionEventListener




                                                                   SAP Java Connector (JCo)


                                                              SAP R/3


Abbildung 6.1.: Entwurf des Ressourcenadapters in einer verwalteten Umgebung


  Eine Implementierung der Schnittstelle XAResource aus Abbildung 2.5 wird
nicht benötigt, da diese Art von Transaktionen, wie bereits erwähnt, nicht voll-
ständig umgesetzt werden kann.
  Die Schnittstellen ConnectionManager und ConnectionEventListener wer-
den in einer verwalteten Umgebung vom Applikationsserver implementiert.
  Weitere implementierte Klassen sollen an dieser Stelle nicht aufgezählt werden.
Sie werden in den folgenden Abschnitten erläutert.


6.2. Entwicklungsumgebung
Die bereits in Abschnitt 5.5 genannten Anforderungen an die Entwicklungsum-
gebung des Beispielszenarios werden für die Ermöglichung der Implementierung
des Ressourcenadapters um die Verfügbarkeit des SAP Java Connectors (JCo)
ergänzt. Der JCo lag in der Version 1.1.03 vor und ist auf der Windows 2000-



78
                                                6.3. Packaging und Deployment

Plattform lauähig.
   Als Quelltexteditor für die Java-Entwicklung kam der Crimson Editor in der
Version 3.40 zum Einsatz. Die Verwendung einer komplexen Entwicklungsumge-
bung erschien mir aufgrund der Gröÿe des Projekts nicht angebracht. Zudem lag
die Schwierigkeit der Entwicklung des Ressourcenadapters in dem Verstehen der
komplexen Zusammenhänge, bei der eine Entwicklungsumgebung nicht wesent-
lich zu helfen vermag.


6.3. Packaging und Deployment
Unter Packaging wird das Erzeugen eines Packets (einer Datei) verstanden, welche
den Ressourcenadapter beinhaltet bzw. repräsentiert.
   Nach dem Packaging kann ein Deployer den Ressourcenadapter anpassen und
in einen Applikationsserver einbinden. Dieser Vorgang wird auch als Deployment
bezeichnet.
   Während im Folgenden die Grundlagen des Packaging und Deployment be-
trachtet werden, liefert Anhang A zusätzliche praktische Hinweise.

6.3.1. Packaging
Ein Ressourcenadapter besteht vor allem aus implementierten Java-
Schnittstellen, welche die durch die Connector-Architektur spezizierten
Kontrakte und EIS-spezische Funktionalität umsetzen. Im Falle des zu ent-
wickelnden Ressourcenadapters für den Zugri auf ein R/3-System über den JCo
werden ebenfalls Bibliotheken verwendet, die nicht in Java implementiert wurden.
Auch diese können als sogenannte Native Libraries in den Ressourcenadapter
eingebunden werden.
   Folgende Elemente kann ein Ressourcenadapter enthalten [Sha01b]:
   • Java-Klassen und -Schnittstellen für die Implementierung der Kontrakte
     und der Funktionalität des Ressourcenadapters
   • Hilfsklassen für den Ressourcenadapter
   • vom Ressourcenadapter benötigte plattformabhängige Native Libraries
   • Hilfedateien und Dokumentation
   • beschreibende Metainformationen, welche die oben genannten Elemente zu-
     sammenfügen
  Der Ressourcenadapter wird ausgehend vom Java Archive (JAR) Format in
das Dateiformat Resource Adapter Archive (RAR) überführt. Der in dieser Di-
plomarbeit entwickelte Ressourcenadapter erhält beispielsweise den Dateinamen
SAPAdapter.rar.



                                                                             79
6. Entwicklung des Ressourcenadapters

  Die RAR-Datei muss einen Deployment Descriptor mit dem Namen
META-INF/ra.xml enthalten. In Anhang A.2.1 kann der Deployment Descriptor
des entwickelten Ressourcenadapters SAPAdapter als Beispiel betrachtet werden.
Eine genauere Beschreibung folgt.

6.3.2. Deployment
Der sogenannte Deployer, der den Ressourcenadapter anpasst und in den Ap-
plikationsserver einbindet, muss sicherstellen, dass alle JAR-Dateien des Res-
sourcenadapters in die Umgebung eingebunden werden. Zudem muss er alle Ab-
hängigkeiten mit plattformabhängigen Native Libraries beachten und für deren
Einhaltung sorgen. Die Konguration der Native Libraries liegt ausserhalb der
Connector-Spezikation.
   Der JCo 1.1.03 enthält beispielsweise die Datei librfc32.dll, welche unter
einem Windows-Betriebssystem in das System-Verzeichnis kopiert werden muss.
Dies wird dem Deployer durch die Connector-Architektur nicht abgenommen.

Deployment Descriptor
Der Deployment Descriptor enthält deklarative Beschreibungen, die der Deployer
für die Einbettung in die Zielumgebung verwenden kann. Folgende Informationen
muss der Entwickler des Ressourcenadapters über den Deployment Descriptor
spezizieren:
     • generelle Informationen wie den Namen und eine Beschreibung des Res-
       sourcenadapters, den Typ des unterstützten EIS, Versionsnummern usw.
     • den Namen der Java-Klasse, welche die ManagedConnectionFactory-
       Schnittstelle implementiert
     • die Schnittstelle und den Namen der Java-Klasse für die Connection Factory
     • die Schnittstelle und den Namen der Java-Klasse für die Connection
     • unterstützte Transaktionen
     • kongurierbare Eigenschaften der ManagedConnectionFactory-Instanz
       Der Servername und die Systemnummer werden über diesen Mechanismus
       im implementierten SAPAdapter gesetzt.
     • unterstützte Mechanismen für die Authentisierung
     • Wird Reauthentisierung unterstützt?
     • Sicherheitseigenschaften
   Eine detailliertere Beschreibung des Deployment Descriptor-Mechanismus ist
in der Connector-Spezikation [Sha01b] zu nden.



80
                                                             6.4. Implementierung

6.4. Implementierung
Vor der Implementierung eines eigenen Ressourcenadapters sind grundlegende
Kenntnisse der Connector-Architektur erforderlich. Diese wurden grob in Kapitel
2 behandelt, wobei Details in der Connector-Spezikation [Sha01b] nachgelesen
werden können. Kenntnisse über die Schnittstellen scheinen unumgänglich, um
die Connector-Architektur in ihrem Gesamtzusammenhang erfassen zu können.
   Als problematisch bei der Implementierung des Ressourcenadapters stellte sich
die Frage nach der Vorgehensweise heraus. Diese wird innerhalb der Connector-
Spezikation nicht beschrieben. Zu Beginn der Implementierung des Ressource-
nadapters waren deshalb keine gebräuchlichen Informationen verfügbar, die An-
haltspunkte oder Hilfestellung liefern konnten.
   Erst im Laufe dieser Diplomarbeit wurde das Buch J2EE Connector Archi-
tecture and Enterprise Application Integration [RS01] verfügbar, an dem auch
Rahul Sharma, der Entwicklungsleiter der Connector-Spezikation, mitwirkte. Es
lieferte weitere Anhaltspunkte für die Implementierung, ähnelte in groÿen Teilen
seiner Struktur und seines Inhalts jedoch stark der Connector-Spezikation.
   Als wirklich hilfreich stellten sich die Quelltexte zu Beispielressourcenadaptern
heraus, die auf der Sun-Homepage zum Download bereitgestellt werden. Auch
wenn sie für den Zugri auf relationale DBMS entwickelt wurden, ermöglich-
ten sie einen Einblick in praktisch umgesetze Zusammenhänge der Connector-
Spezikation. Leider waren diese Quelltexte erst verfügbar, als bereits groÿe Tei-
le der Implementierung des Ressourcenadapters fertiggestellt waren. Durch den
Vergleich der Beispielquelltexte mit der eigenen Implementierung wurde die Kor-
rektheit des eigenen Ressourcenadapters bestätigt. Verbesserungsmöglichkeiten
bzw. neue Ansätze wurden ersichtlich.
   Die Internetseiten zur Connector-Architektur und die Connector-
Mailingliste,    welche      auf      der    Sun-Homepage       unter    der   URL
http://java.sun.com/j2ee/connector/ zu nden sind, bieten zudem ak-
tuelle Informationen über die Connector-Spezikation. Auch Rahul Sharma
liefert als Mitglied dieser Mailingliste Informationen über den aktuellen Stand
der Connector-Architektur.


6.4.1. Nicht verwaltete Umgebung
Der Kontrakt des Verbindungsmanagements ermöglicht die Verwendung des Res-
sourcenadapters innerhalb einer 2-Schichten-Applikation (two-tier) direkt von ei-
nem Applikationsclient aus. Die Verwendung eines Applikationsservers ist in die-
sem Fall nicht erforderlich, so dass sich eine einfache Architektur ergibt.
   Für diese Diplomarbeit scheint der Ansatz der nicht verwalteten Umgebung
uninteressant, weil der Ressourcenadapter vor allem in Verbindung mit dem Ap-
plikationsserver zum Einsatz kommen soll. Die Connector-Spezikation erfordert
jedoch die Verwendbarkeit des Ressourcenadapters in einer nicht verwalteten Um-



                                                                                 81
6. Entwicklung des Ressourcenadapters

gebung. Bereits wesentliche Bestandteile des Adapters müssen dafür funktionie-
ren.
   Aus dieser Gegebenheit wird ein Vorteil der nicht verwalteten Umgebung er-
sichtlich. Die Entwicklung des Ressourcenadapters gestaltet sich als einfacher und
eektiver als in Verbindung mit dem Applikationsserver. Die Funktionsweise des
auf den Ressourcenadapter zugreifenden Applikations-Client wird innerhalb der
Connector-Spezikation weitgehend vorgegeben. Dadurch stellt die nicht verwal-
tete Umgebung einen geeigneten Einstiegspunkt für die Implementierung dar.

Applikationsclient
Die in diesem Abschnitt folgenden Auszüge aus dem Quelltext des Beispielclients
NonManagedClient.java für die nicht verwaltete Umgebung zeigen auf, wie der
Zugri des Applikationsclients auf den Ressourcenadapter erfolgt. Der Beispielcli-
ent basiert auf der Vorgabe der Connector-Spezikation [Sha01b], ergänzt diese
jedoch um nicht notwendige, aber doch sinnvolle Bestandteile wie das Logging
und das Ausführen von Funktionen auf dem EIS. Die Verfolgung der einzelnen
Schritte in der dieser Diplomarbeit beiliegenden Java-Dokumentation zum Res-
sourcenadapter oder dessen Quelltexten kann dem Verständnis zuträglich sein.
  An erster Stelle steht die Erzeugung einer ManagedConnectionFactory-
Instanz. Sie wird für die Erzeugung von ManagedConnection- und
ConnectionFactory-Instanzen benötigt.
SAPManagedConnectionFactory mcf = new SAPManagedConnectionFactory();
  Die Eigenschaften der ManagedConnectionFactory-Instanz müssen gesetzt
werden, so dass alle benötigten Informationen für die Erzeugung einer physi-
kalischen Verbindung zum EIS vorhanden sind. Für den SAP-Zugri sind dies
der Servername und die Systemnummer. Client-spezische Informationen wer-
den erst später übergeben. Die Methoden sollten der Java Beans Design Pat-
tern [Ham97] entsprechen, um das Setzen der Eigenschaften in einer verwalteten
Umgebung über Deployment-Tools zu ermöglichen.
mcf.setServerName ( ... );
mcf.setSystemNumber( ... );
  Das Logging kann während der Implementierungsphase des Ressourcenadap-
ters beispielsweise auf die Standardausgabe geleitet werden. Es können wichtige
Meldungen aller Art ausgegeben werden.
mcf.setLogWriter ( ... );
   Die ConnectionFactory-Instanz muss erzeugt werden, um später an ein
Verbindungs-Handle und somit an eine Verbindung zu gelangen. Die Connection
Factory wird mit dem Standard-Connection Manager des Ressourcenadapters in-
itialisiert, wenn keine ConnectionManager-Instanz explizit übergeben wird, wie
es hier der Fall ist.



82
                                                            6.4. Implementierung

ConnectionFactory cf = (ConnectionFactory)mcf.createConnectionFactory();

  Client-spezische Verbindungsparameter, die für die Verbindung zum SAP-
System benötigt werden, können über die ConnectionSpec-Schnittstelle überge-
ben werden. Im Falle des in dieser Diplomarbeit entwickelten Ressourcenadapters
für den Zugri auf SAP R/3 ist das eine SAPConnectionSpec-Instanz, welche die
Clientnummer, die Sprache, den Benutzernamen und das Passwort beinhaltet.
ConnectionSpec cspec = new SAPConnectionSpec( ... );

   Die getConnection-Methode der ConnectionFactory-Instanz liefert
das Verbindungs-Handle auf Applikationsebene zurück. Dabei müssen die
Client-spezischen Verbindungsinformationen für die Erstellung der Verbin-
dung übergeben werden. Innerhalb der getConnection-Methode wird die
allocateConnection-Methode des Connection Manager aufgerufen, der die
Erzeugung der physikalischen Verbindung einleitet und eine Connection-Instanz
als Verbindungs-Handle zurückliefert.
Connection c = cf.getConnection( cspec );

  Über eine Interaction-Instanz, die von der createInteraction-Methode des
Verbindungs-Handles zurückgeliefert wird, können dann Funktionen auf dem EIS
ausgeführt werden. Nach der Ausführung der gewünschten Funktionen wird die
Interaction wieder geschlossen.
SAPInteraction i = (SAPInteraction)c.createInteraction();
i .execute ( ... );
 ...
i . close ();

  Wenn die Verbindung zum EIS nicht mehr benötigt wird, muss diese geschlos-
sen werden. Die close-Methode des Verbindungs-Handles schlieÿt allerdings nur
die Verbindung auf Applikatonsebene und nicht direkt die physikalische Verbin-
dung.
c. close ();

  Die Reihenfolge bei der Implementierung der Schnittstellen des Ressourcena-
dapters kann sich an dessen Aufrufreihenfolge im Beispielclient anlehnen. Es
taucht jedoch ein Problem auf, dessen Lösung aus der Connector-Spezikation
nur schwer ersichtlich wird.
  Es fällt auf, dass die physikalische Verbindung nicht explizit vom Client been-
det wird. Nach dem Aufruf der close-Methode des Verbindungs-Handles muss
innerhalb des Ressourcenadapters also ein Mechanismus ablaufen, der für die Be-
endigung der physikalischen Verbindung sorgt, wenn diese von keinem weiteren
Verbindungs-Handle mehr beansprucht wird.



                                                                              83
6. Entwicklung des Ressourcenadapters

Applikationsclient       SAPConnection     SAPManagedConnection        SAPConnectionEventListener

                 close
                                closeConnection(this)
                                                        connectionClosed(ConnectionEvent)




                                                                    destroy




Abbildung 6.2.: Beendigung der physikalischen Verbindung in einer nicht verwal-
                teten Umgebung

6.4.2. Interaktion interner Objekte
Die Connector-Spezikation gibt an, dass ein Ressourcenadapter Interaktionen
zwischen seinen internen Objekten in einer implementierungsspezischen Art und
Weise unterstützt.

Der Ereignismechanismus
Der Ressourcenadapter kann für die genannten Interaktionen den Mechanismus
für die Verarbeitung von Verbindungsereignissen verwenden. Dieser ist ein Teil
der ManagedConnection-Implementierung. Seine Verwendung wird jedoch nicht
gefordert.
  Die Umsetzung des Ereignismechanismus erfordert die Implementierung der
ConnectionEventListener-Schnittstelle. Der in dieser Diplomarbeit entwickel-
te Ressourcenadapter SAPAdapter implementiert das Schlieÿen von Verbindun-
gen auf die im Folgenden beschriebene Art und Weise. Bei dem gezeigten Auf-
ruf der close-Methode der Connection-Instanz wird die nicht in der Spezi-
kation festgelegte interne Methode closeConnection der ManagedConnection-
Instanz aufgerufen, welche die Verknüpfung zur Connection-Instanz löscht. Zu-
sätzlich wird ein Verbindungsereignis (Klasse ConnectionEvent) an alle mit der
ManagedConnection-Instanz verbundenen Connection Event Listener gesendet.
Erst der Connection Event Listener sorgt dann durch den Aufruf der destroy-
Methode der ManagedConnection-Instanz für die Beendigung der physikalischen
Verbindung. Dieser Ablauf wird durch Abbildung 6.2 verdeutlicht.

Implementierungsfreiraum
Spätestens zum jetzigen Zeitpunkt der Implementierung wird klar, dass die
Connector-Spezikation Freiraum für unterschiedliche Implementierungsansätze



84
                                                           6.4. Implementierung

bietet. Die Implementierung der vorgegebenen Schnittstellen reicht nicht aus, um
einen lauähigen Ressourcenadapter zu erhalten. Vielmehr müssen geeignete Me-
thoden hinzugefügt werden, welche die benötigte Kommunikation innerhalb des
Ressourcenadapters übernehmen.
   Der genannte Freiraum bietet den Vorteil, dass der Programmierer individuell
bevorzugte Mechanismen implementieren kann. Ein Problem besteht jedoch dar-
in, dass sich während der Implementierung des ersten Ressourcenadapters oft die
Frage stellt, ob dieser Mechanismus nicht doch von der Spezikation abgedeckt
wird und ob somit wirklich eine eigene Lösung notwendig ist. Die Beantwortung
dieser Frage bedarf ein häuges Nachlesen der Connector-Spezikation und kann
für ein leichtes Unsicherheitsgefühl sorgen. Dies wird durch die komplexen Zusam-
menhänge der Schnittstellen nochmals verstärkt. Gerade in der nicht verwalteten
Umgebung kann die Komplexität der Schnittstellen übertrieben und unnatürlich
wirken. Das gilt insbesondere, wenn nur ein einfacher Zugri auf ein EIS erfolgen
soll. Erst in der verwalteten Umgebung in Verbindung mit einem Applikations-
server erscheint diese Komplexität notwendig und sinnvoll.


6.4.3. Ausführung von EIS-Funktionen
Die Schnittstelle Connection des Common Client Interfaces (CCI) bietet die
Methode createInteraction an, welche eine Interaction-Instanz zurücklie-
fert. Über diese Instanz können Funktionen auf dem verbundenen EIS aufgerufen
werden.
   An dieser Stelle weicht die Implementierung des entwickelten Ressourcenadap-
ters SAPAdapter erstmals vom CCI ab und verwendet zudem Datentypen des
SAP Java Connector (JCo). Durch die Abweichungen wird die Implementierung
des Ressourcenadapters vereinfacht. Zusätzlich werden Funktionalitäten des JCo
gewährleistet, die vom CCI in dieser Form nicht unterstützt werden.
   Die in diesem Abschnitt vorkommenden JCo-Klassen wurden bereits in Kapitel
4.1 behandelt und können bei Bedarf nachgeschlagen werden.


Die Methode getFunction
Die Methode getFunction erzeugt aus dem Namen einer Funktion eines SAP
R/3-Funktionsbausteins eine Instanz vom Typ JCO.Function. Dabei handelt
es sich um eine Datenstruktur, die für den Aufruf der entsprechenden Funkti-
on über die Methode execute( JCO.Function ) benötigt wird. Eine Funkti-
on wie getFunction ist innerhalb der Interaction-Schnittstelle im Sinne des
CCI-Standards nicht vorgesehen. Die entsprechende execute-Methode existiert
ebenfalls nicht in Verbindung mit dem JCO.Function-Parameter.
  Die Methode getFunction kann zudem nicht direkt dem CCI-Standard
angepasst werden. Für die Erstellung von Datenstrukturen ist die Methode



                                                                              85
6. Entwicklung des Ressourcenadapters

getRecordFactory der Schnittstelle ConnectionFactory vorgesehen. Die Im-
plementierung innerhalb dieser Schnittstelle ergibt jedoch ein Problem. Der JCo
bezieht die Informationen für die zu erzeugenden Datenstrukturen für den Aufruf
von Funktionen üblicherweise direkt vom SAP R/3-System. Dazu wird die Klasse
JCO.Repository verwendet, die eine Verbindung zum R/3-System voraussetzt.
Wenn noch keine physikalische Verbindung besteht, kann dies zu Fehlern füh-
ren, da Informationen zur Erzeugung der benötigten Datenstruktur nicht vom
R/3-System abgerufen werden können. Der Connection-Instanz liegt auf jeden
Fall eine physikalische Verbindung zu Grunde, so dass die Position der Metho-
de für die Erzeugung von Datenstrukturen innerhalb der Interaction-Instanz
als geeignet erscheint. Dies ist der Grund für die Implementierung der Methode
getFunction innerhalb der Interaction-Schnittstelle.
   Bereits in Abschnitt 4.2 zum SAP Resource Adapter wurde ein Function Proxy
vorgestellt, der eine ähnliche Funktion wie die Methode getFunction in Verbin-
dung mit dem vom SAP-RA unterstützten CCI übernehmen soll. Die Lösung
innerhalb des in dieser Diplomarbeit entwickelten Ressourcenadapters stellt eine
vereinfachte Umsetzung des Function Proxy dar.
   Es ist möglich, Funktionsbausteine auch ohne eine von der getFunction-
Methode erzeugte Datenstruktur über die execute-Methode aufzurufen. Dies er-
fordert jedoch die Erstellung der Datenstruktur per Hand, welches eine nicht
befriedigende Lösung darstellt. Der daraus resultierende Nachteil der fehlenden
Typsicherheit wurde bereits in Verbindung mit dem Function Proxy des SAP-RA
genannt.

Die execute-Methoden
Zwei der execute-Methoden zur Ausführung von Funktionen auf dem EIS
verwenden Datentypen des JCo und entsprechen somit nicht mehr dem CCI-
Standard.
  Die Implementierung der execute-Methoden des CCI-Standards würden eine
Konvertierung der JCO-Datentypen in die vom CCI vorgeschriebenen Datenty-
pen erfordern. Aus Gründen der Vereinfachung wurde diese Konvertierung nicht
umgesetzt. Sie wird jedoch in einem späteren Abschnitt beschrieben.
  Die Implementierung der execute-Methoden wirft die Frage auf, an welcher
Stelle der Aufruf der entsprechenden Funktionen auf dem EIS durchgeführt wird.
Da der Ressourcenadapter den JCo als Verbindung zum R/3-System verwen-
det, werden die execute-Methoden einer JCO.Client-Instanz für das Ausfüh-
ren der Funktionen auf dem EIS verwendet. Für die Ausführung der execute-
Methoden der JCO.Client-Instanz durch einen Aufruf der execute-Methoden
der Interaction-Instanz existieren zwei prinzipiell unterschiedliche Ansätze:

     1. Die JCO.Client-Instanz wird von der ManagedConnection-Instanz zur
        Connection-Instanz und dann zur Interaction-Instanz weitergereicht.



86
                                                          6.4. Implementierung

     Dort wird dann die execute-Methode auf der JCO.Client-Instanz aufge-
     rufen.

  2. Die Ausführung der execute-Methode auf der Interaction-Instanz wird
     an die zugehörige Connection-Instanz weitergereicht, die diesen Aufruf wie-
     derum an die ManagedConnection-Instanz weiterreicht. Dort wird dann die
     execute-Methode auf der JCO.Client-Instanz ausgeführt.
  Für den Benutzer des Ressourcenadapters spielt die Wahl der beiden genann-
ten Alternativen keine Rolle, solange die Funktion wie gewünscht auf dem EIS
ausgeführt wird. Die Connector-Spezikation gibt zudem keine eindeutige Lö-
sung für die beste Implementierungsvariante an. Der zweite Ansatz erscheint
jedoch sinnvoll, da die Ausführung von Methoden auf dem EIS nur inner-
halb der ManagedConnection-Instanz erfolgen sollte, weil diese laut Connector-
Spezikation die physikalische Verbindung zum EIS repräsentiert.
  Die dargestellte Problematik zeigt erneut, dass die Implementierung eines Res-
sourcenadapters zusätzlicher Methoden bedarf, die nicht Teil der Connector-
Spezikation sind und wiederum für die Interaktion interner Objekte benötigt
werden.
  Abbildung 6.3 zeigt die Lösung des Problems innerhalb des Ressourcena-
dapters SAPAdapter. Die Applikationskomponente lässt sich zuerst eine Da-
tenstruktur für den Aufruf der gewünschten EIS-Funktion erzeugen. Das ge-
schieht über die Methode getFunction der SAPInteraction-Instanz. Die zu-
rückgelieferte Datenstruktur JCO.Function wird durch die Applikationskom-
ponente mit den für den Aufruf der gewünschten Funktion erforderlichen
Daten gefüllt. Dann wird die Methode execute auf der SAPInteraction-
Instanz mit der JCO.Function-Datenstruktur ausgeführt. Die SAPInteraction-
Instanz fragt die verbundene Connection-Instanz nach der zugrundeliegen-
den ManagedConnection-Instanz und liefert diese zurück. Daraufhin wird die
execute-Methode auf der SAPManagedConnection-Instanz mit dem entsprechen-
den Parameter JCO.Function ausgeführt. Erst diese Methode führt die EIS-
Funktion auf physikalischer Ebene aus.

Anpassung an den CCI-Standard
Die Probleme mit dem CCI-Standard, die durch die execute-Methoden der
Interaction-Schnittstelle aufgeworfen werden, können durch geeignete Konver-
tierung von Datenstrukturen umgangen werden. Ein Lösungsansatz soll im Fol-
genden vorgestellt werden.
   Die genannten execute-Methoden des CCI-Standards erwarten Instanzen der
Schnittstelle Record als Parameter, welche Ein- und Ausgabewerte der aufzuru-
fenden EIS-Funktion darstellen.
   Die MappedRecord-Schnittstelle erweitert die Record-Schnittstelle und ist für
die Speicherung von Elementen mit einer Zuordnung von Schlüsseln gedacht.



                                                                             87
6. Entwicklung des Ressourcenadapters

Applikationkomponente         SAPInteraction             SAPConnection          SAPManagedConnection

              getFunction()

           return JCO.Function

         execute(JCO.Function)

                                          getManagedConnection()

                                       return SAPManagedConnection

                                                      execute( JCO.Function )




                   Abbildung 6.3.: Ausführung von EIS-Funktionen

So könnte die MappedRecord-Instanz einen import-, export- und tables-Eintrag
beinhalten, der für den Aufruf von SAP R/3-Funktionsbausteinen über das JCo
benötigt wird. Die einzelnen Einträge könnten wiederum aus einer ResultSet-
Datenstruktur bestehen, welche einen tabellarischen Datensatz darstellt.
   Entsprechende Methoden zur Bearbeitung der Datentypen müssten ebenfalls
implementiert werden.
   In dem oben beschriebenen Ansatz würden die Schnittstellen MappedRecord
und ResultSet implementiert werden. Eine Konvertierung der Datentypen in
die JCo-Datentypen JCO.ParameterList, JCO.Structure und JCO.Table wäre
erforderlich. Die Konvertierung in anderer Richtung müsste ebenfalls implemen-
tiert werden, um die Rückgabeparameter von den JCo-Datentypen in die ent-
sprechenden Record-Datentypen zu konvertieren. Die Konvertierung der Daten
könnte anhand von Tabelle 4.1 in die Standard-Java-Datentypen erfolgen.
   Eine solche Konvertierung würde dann der Vollständigkeit halber auch in der
bereits vorgestellten getFunction-Methode enthalten sein, so dass von aussen
nicht mehr mit den JCo-Datentypen gearbeitet werden müsste. Mit dieser Me-
thode verlassen wir jedoch wieder den CCI-Standard.


6.4.4. Transaktionen
Das Transaktionsmodell für die BAPI-Entwicklung wurde bereits in Abschnitt
3.3.7 behandelt. Der Client kann die Transaktionskontrolle durch Service-BAPIs
übernehmen. Dies gilt allerdings nur, solange das BAPI selbst kein COMMIT WORK-
Kommando ausführt.
  Eine BAPI-Transaktion wird durch den Aufruf der BAPI BapiSer-



88
                                                          6.4. Implementierung

vice.TransactionCommit() oder BapiService.TransactionRollback() been-
det. Dadurch wird die Transaktion entweder ausgeführt oder rückgängig gemacht.
Die transaktionssteuernden BAPIs stehen erst ab Release 4.5 zur Verfügung.
Stattdessen können auch die Funktionsbausteine BAPI_TRANSACTION_COMMIT und
BAPI_TRANSACTION_ROLLBACK verwendet werden, die bereits ab Release 4.0 ver-
fügbar waren. Diese Funktionsbausteine kommen in dem hier vorgestellten Res-
sourcenadapter zum Einsatz.
   Die vorgestellten Funktionsbausteine zur Steuerung von Transaktionen bezie-
hen sich lediglich auf lokale Transaktionen innerhalb des R/3-Systems. Da das
SAP R/3-System wie bereits erwähnt kein 2-Phasen-Commit-Protokoll unter-
stützt, können keine XAResource-basierten Transaktionen ausgeführt werden.
   Problematisch bei der Ausführung von Client-gesteuerten lokalen Transaktio-
nen ist die Tatsache, dass einige Funktionsbausteine nach ihrem Aufruf über RFC
im direkten Anschluss ein Update der Datenbank zur Folge haben, wodurch keine
Transaktionssteuerung mehr möglich ist. Andere Funktionsbausteine wiederum
ermöglichen eine Transaktionssteuerung, da sie erst nach dem oben genannten Be-
fehl zur Ausführung der Transaktion auf die Datenbank geschrieben werden. Da
die Funktionsbausteine dies unterschiedlich handhaben, ist die Programmierung
von Transaktionen mit äuÿerster Vorsicht zu genieÿen. Für jeden aufzurufenden
Funktionsbaustein muss somit geklärt werden, ob er die Transaktionssteuerung
zulässt (siehe auch Abschnitt 3.3.7).
   Ein Ressourcenadapter implementiert die Schnittstelle javax.re-
source.spi.LocalTransaction, um dem Applikationsserver zu erlauben,
lokale Transaktionen zu steuern. Die Schnittstelle javax.resource.cci.Local-
Transaction gehört dagegen zum CCI und kann von einer Applikationskom-
ponente zur Steuerung von lokalen Transaktionen verwendet werden. Beide
Schnittstellen besitzen die Methoden begin, commit und rollback, die von der
implementierenden Klasse unterstützt werden müssen.
   Da im R/3-System kein Befehl für den Beginn einer Transaktion exi-
stiert, werden nur die Methoden commit und rollback so implementiert,
dass sie die entsprechenden Funktionsbausteine BAPI_TRANSACTION_COMMIT und
BAPI_TRANSACTION_ROLLBACK aufrufen. Die Methode begin besitzt keine Funk-
tionalität, muss jedoch implementiert werden.

6.4.5. Verwaltete Umgebung
Die Verwendung des Ressourcenadapters in einer verwalteten Umgebung setzt
Kenntnisse über den Applikationsserver voraus. Über ein sogenanntes Deploytool
wird der Ressourcenadapter in den Applikationsserver eingebunden und kongu-
riert. Während der Implementierung wird dies häug erforderlich, um den Res-
sourcenadapter testen zu können.
   Zum Testen wird ein Client verwendet, der auf den Ressourcenadapter zugreift,
um dessen Funktionalität zu überprüfen. Eine Enterprise Java Bean (EJB) in



                                                                             89
6. Entwicklung des Ressourcenadapters

Form einer Session Bean in Verbindung mit einem Applikationsclient erscheint
geeignet, um diese Tests zu ermöglichen. Auch ein Browser ist durch die Ver-
wendung einer Java Server Page (JSP) in Verbindung mit einem Webserver als
Testclient denkbar.
  Die Verwendung des Ressourcenadapters innerhalb der Session Bean entspricht
prinzipiell der Vorgehensweise in einem Applikationsclient der nicht verwalteten
Umgebung.


Methoden zur Verwaltung des Verbindungspools
Um das Zusammenspiel des Ressourcenadapters in Verbindung mit dem Appli-
kationsserver zu gewährleisten, wird die Implementierung weiterer Schnittstellen
des Ressourcenadapters erforderlich, die zuvor nicht unbedingt benötigt wurden.
   Es handelt sich dabei vor allem um die Methoden cleanup und
associateConnection der ManagedConnection-Schnittstelle und die Methode
matchManagedConnections der ManagedConnectionFactory-Schnittstelle. Die-
se Methoden werden für die Verwaltung des Verbindungspools durch den Verbin-
dungsmanager des Applikationsservers verwendet. Da in der zuvor beschriebenen
nicht verwalteten Umgebung der einfache Verbindungsmanager des Ressourcena-
dapters zum Einsatz kam, wurden diese Methoden nicht genutzt.
   Es folgt eine Beschreibung der genannten Schnittstellen für die Verwaltung des
Verbindungspools durch den Applikationsserver:


     • ManagedConnection.cleanup
      Die Methode cleanup initialisiert die ManagedConnection-Instanz neu und
      löscht alle Client-spezischen Informationen. Alle zu der Instanz gehören-
      den Connection-Handles werden ungültig. Die Methode wird vom Applika-
      tionsserver aufgerufen. Nach dem Aufruf von cleanup kann die Verbindung
      wieder in den Verbindungspool des Applikationsservers aufgenommen wer-
      den. Die physikalische Verbindung wird durch diese Methode nicht beendet.

     • ManagedConnection.associateConnection
      Die Methode associateConnection wird vom Container verwendet, um ei-
      ne Verknüpfung eines Verbindungs-Handles auf Applikationsebene mit einer
      ManagedConnection-Instanz zu ändern. Der Container sollte die richtige
      ManagedConnection-Instanz nden und associateConnection aufrufen.
      Diese Methode sollte das übergebene Verbindungshandle von der verknüpf-
      ten ManagedConnection-Instanz lösen und es mit der ManagedConnection-
      Instanz verbinden, dessen associateConnection-Methode aufgerufen wur-
      de.



90
                                                                       6.5. Test

   • ManagedConnectionFactory.matchManagedConnections
     Die Methode matchManagedConnections liefert eine passende Verbindung
     von den Kandidaten der Verbindungen zurück, die vom Applikationsserver
     zusammengestellt wurden und an diese Methode übergeben wurden.
     Die  Sicherheitsinformationen, die als Subject und Connection-
     RequestInfo übergeben wurden, werden für das Heraussuchen einer
     passenden Verbindung genutzt.
     Diese Methode liefert die ManagedConnection-Instanz zurück, die den An-
     forderungen der Anfrage am besten entspricht. Falls eine soche Instanz nicht
     existiert wird null zurückgeliefert.

  Implementierungsdetails können jederzeit den Quelltexten entnommen werden,
die dieser Diplomarbeit beiliegen. Ich habe mich um eine gute Dokumentation
der Quelltexte bemüht, so dass Zusammenhänge schnell klar werden sollten.


6.5. Test
Der Ressourcenadapter wurde während der Implementierungsphase und nach sei-
ner Fertigstellung getestet, um seine Korrektheit zu überprüfen. Es kamen zwei
Testanwendungen zum Einsatz.


6.5.1. Nicht verwaltete Umgebung
Ein Applikationsclient für die nicht verwaltete Umgebung wurde bereits vorge-
stellt. Dieser Client kann auch zu Testzwecken während und nach der Imple-
mentierungsphase verwendet werden und stellt eine einfache Möglichkeit dar, die
grundlegende Funktionsweise des Ressourcenadapters zu überprüfen.


6.5.2. Verwaltete Umgebung
Eine Testanwendung für die verwaltete Umgebung erscheint dagegen komplizier-
ter. Eine Session Bean in Verbindung mit einem Applikationsclient kamen dabei
zum Einsatz. Die Implementierung der Session Bean besteht aus folgenden Da-
teien:

   • Session Bean Klasse (SAPTestBean.java)

   • Home Interface (SAPTestHome.java)

   • Remote Interface (SAPTest.java)



                                                                              91
6. Entwicklung des Ressourcenadapters

   Der Client (SAPTestClient.java) greift auf die Session Bean zu, welche den
Ressourcenadapter für den Zugri auf das R/3-System verwendet. Die Testan-
wendung SAPTest soll als Beispiel dienen und bendet sich auf der beiliegenden
CD (siehe Anhang B). Sie führt grundlegende Funktionen des Ressourcenadap-
ters aus, um seine Funktionalität zu testen. Praktische Hinweise zum Packaging
und Deployment der Testanwendung benden sich in Anhang A.
   Ausgaben auf die Standardausgabe innerhalb des Ressourcenadapters waren
hilfreich, um übergebene Parameter überprüfen zu können. Teile dieser Testaus-
gaben benden sich noch als Kommentar im Quelltext des Ressourcenadapters
und können bei Bedarf auskommentiert werden.

6.5.3. Testgrenzen
Es soll darauf hingewiesen werden, dass der entwickelte Ressourcenadapter in re-
lativ einfachen Umgebungen getestet wurde, wobei immer ein Zugri auf ein SAP
R/3-System der Release 4.6B erfolgte. Zudem kam der J2EE-Applikationsserver
von Sun zum Einsatz. Daher kann keine Aussage über die korrekte Funktionsweise
des Ressourcenadapters in beliebigen weiteren Umgebungen getroen werden.




92
7. Entwicklung der
   Beispielanwendung

Die Umsetzung der Beispielanwendung zeigt auf, wie der zuvor entwickelte Res-
sourcenadapter SAPAdapter für den Zugri auf ein SAP R/3-System zum Einsatz
kommen kann. Der Entwurf des Beispielszenarios wurde bereits in Kapitel 5 vor-
gestellt. Dieses Kapitel beschreibt die Umsetzung der Beispielanwendung unter
Verwendung eines Webclients.


7.1. Vorgehensweise
Die Erstellung der Beispielanwendung besteht aus zwei Teilbereichen:

  1. An erster Stelle steht die Suche nach geeigneten BAPIs bzw. Funktionsbau-
     steinen innerhalb des SAP-Systems, die Funktionalitäten zu den Materia-
     lien entsprechend der Anwendungsfälle des Beispielszenarios aus Kapitel 5
     bereitstellen.

  2. An zweiter Stelle steht der Entwurf und die Implementierung der benötig-
     ten Enterprise Java Beans (EJBs) für die Umsetzung der Anwendungsfälle.
     Zusätzlich wird der Client implementiert.


7.2. BAPIs und Funktionsbausteine
Für die Umsetzung der Anwendungsfälle werden entsprechende BAPIs bzw. de-
ren zugrundeliegenden Funktionsbausteine benötigt, über die Funktionen auf dem
SAP R/3-System ausgeführt werden können. Zu den in Kapitel 5 genannten An-
wendungsfällen sollen jetzt entsprechende Funktionsbausteine herausgesucht wer-
den:


7.2.1. Anwendungsfall Material anlegen
Für    das     Anlegen         Materials
                           eines           existiert die  Funktion
BAPI_STANDARDMATERIAL_CREATE. Der JCo, über den der SAPAdapter auf



                                                                            93
7. Entwicklung der Beispielanwendung

das SAP R/3-System zugreift, lieferte jedoch die Fehlermeldung Dynproausgabe
ohne Verbindung zum Benutzer beim Aufruf der besagten Funktion.
   Informationen zu dieser Fehlermeldung waren weder in der Dokumentation zum
JCo, noch auf der SAP-Homepage zu nden. Der Versuch, in einem Forum unter
http://www.sapfans.com an Antworten zu gelangen, schlug anfangs ebenfalls
fehl. Der Produktmanager des SAP JCo antwortete auf meine Bitte nach weite-
ren Informationsquellen zum JCo und der Fehlermeldung mit dem Verweis auf
einen von SAP angebotenen 5-Tages-Kurs. Als Alternative wurde eine Supportan-
frage angegeben, die dann letztlich zur Aufklärung der genannten Fehlermeldung
führte:

        Das Problem beim BAPI_STANDARDMATERIAL_CREATE
     besteht darin, daÿ es sich um einen Dialog-Funktionsbaustein han-
     delt, der ein CALL TRANSACTION auf die 'MM01' macht und ein
     Dynpro sendet. Diesen können Sie nur aus dem Dialog rufen, nicht
     über JCO.
        Das gilt allgemein (siehe Hinweis 49730):
        Bei RFC-Kommunikation zwischen einem R/3-System und einem
     externen Programm (z. B. C- oder Visual-Basic- oder andere externe
     Programme) führt die Ausgabe von Bildern (Dynpros oder Listen)
     immer zum Kommunikationsabbruch, unabhängig von dem verwen-
     deten Benutzertyp, es sei denn, das externe Programm verfügt über
     einen SAPGUI (RFC mit SAPGUI).

   Mit Verzögerung erhielt ich zusätzlich noch Informationen aus dem bereits oben
erwähnten Forum. Angeblich existiert eine Funktion MATERIAL_MAINTAIN_DARK,
über die Material erzeugt werden kann. Diese Funktion müsse allerdings erst für
den Remote-Zugri freigeschaltet werden. Sie besitzt angeblich die Einschrän-
kung, dass einem Material keine Klasse zugewiesen werden kann. Unter der ver-
fügbaren SAP-Version der Release 4.6B war diese Funktion über den Function
Builders jedoch nicht aundbar.
   Oensichtlich existieren keine Funktionsbausteine, die über den JCo für die
Erzeugung von Materialien aufgerufen werden könnten. Dies gilt zumindest für
das zum Test herangezogene SAP R/3-System der Release 4.6B.
   Die Implementierung eines Funktionsbausteins für die Erzeugung eines Mate-
rials sprengt den Rahmen dieser Diplomarbeit. Zudem wären detaillierte Kennt-
nisse der ABAP-Programmiersprache und interner Zusammenhänge des SAP-
Systems notwendig. Ein derartiger Aufwand scheint nicht angebracht, da der
prinzipielle Zugri auf das SAP R/3-System auch durch die anderen Anwen-
dungsfälle gezeigt werden kann.
   Aus den genannten Gründen wird der Anwendungsfall für die Erzeugung von
Materialien nicht umgesetzt.



94
                                             7.3. Entwurf und Implementierung

7.2.2. Anwendungsfall Materialsuche
Der zugrundeliegende Funktionsbaustein der BAPI für die Suche nach Materialien
heisst BAPI_MATERIAL_GETLIST. Über den Function Builder des SAPgui können
Informationen über diesen Funktionsbaustein abgerufen werden. Die Suche er-
folgt nach angegebenen Selektionsparametern. Uns soll an dieser Stelle vor allem
die Tabelle MATERIALSHORTDESCSEL interessieren, in der Suchoptionen zur Kurz-
beschreibung der Materialien übergeben werden können. Die Parameter werden
dabei entsprechend der Dokumentation des Funktionsbausteins so gewählt, dass
ein Vergleich der Kurzbeschreibung mit einem eingegebenen Suchstring erfolgt.


7.2.3. Anwendungsfall Materialdetails
Über die Funktion BAPI_MATERIAL_GET_DETAIL können Details zu einem Mate-
rial abgerufen werden. Als Parameter muss lediglich eine Materialnummer über-
geben werden. Wiederum können Details über den Function Builder des SAPgui
angezeigt werden.


7.2.4. Anwendungsfall Material ändern/löschen
Für den Anwendungsfall Material ändern/löschen trit die gleiche Problematik
zu, die bereits beim Anlegen eines Materials aufgetreten ist. Es sind lediglich
dialogorientierte Funktionsbausteine für das Ändern und Löschen von Materialien
vorhanden. Die Funktionen BAPI_MATERIAL_DELETE und BAPI_MATERIAL_EDIT
verursachen ebenfalls die Fehlermeldung Dynproausgabe ohne Verbindung zum
Benutzer. Somit wird auch dieser Anwendungsfall innerhalb dieser Diplomarbeit
nicht umgesetzt.


7.3. Entwurf und Implementierung
Die zu entwickelnde Beispielanwendung besteht aus Enterprise Java Beans (EJBs)
und einem Client (vgl. Abbildung 5.2). Der Entwurf und die Implementierung der
Beispielanwendung kann somit in zwei Teile unterteilt werden:

   • Entwicklung der Enterprise Java Beans (EJBs)

   • Entwicklung des Clients

7.3.1. Entwicklung der Enterprise Java Beans (EJBs)
Die zu entwickelnde Beispielanwendung enthält eine EJB in Form einer Session
Bean, in der ein Zugri auf den Ressourcenadapter und somit auf das SAP R/3-
System erfolgt. In dieser wird die eigentliche Funktionalität der Beispielanwen-



                                                                             95
7. Entwicklung der Beispielanwendung

dung implementiert. Es werden lediglich zwei Methoden für die umzusetzenden
Anwendungsfälle Materialsuche und Materialdetails benötigt:

     • eine Methode zur Rückgabe einer Materialliste anhand übergebener Such-
       parameter

     • eine Methode, die Materialdetails zu einem Material anhand der Material-
       nummer zurückliefert

  Die Implementierung der Session Bean besteht aus folgenden dieser Diplomar-
beit beiliegenden Dateien:

     • Session Bean Klasse (SAPBeispielBean.java)

     • Home Interface (SAPBeispielHome.java)

     • Remote Interface (SAPBeispiel.java)

   Als Grundlage der Implementierung diente das Kapitel A Session Bean Ex-
ample aus dem J2EE Tutorial [SB02]. Grundlegende Informationen zur Funk-
tionsweise von EJBs und speziell der Session Bean können dort nachgeschlagen
werden.

Anwendungsfall Materialsuche
Für die Suche nach Materialien kommen die bereits vorgestellten Funktionsbau-
steine BAPI_MATERIAL_GETLIST und MATERIALSHORTDESCSEL zum Einsatz.
  Die für diese Funktionalität implementierte Methode innerhalb der Session
Bean heisst getMaterialList. Sie liefert eine Liste der Materialien zurück, die
den übergebenen Suchparametern entsprechen.
  Innerhalb dieser Methode wird eine Verbindung zur Connection Factory des
Ressourcenadapters SAPAdapter hergestellt. Dies geschieht über das Java Na-
ming and Directory Interface (JNDI):
InitialContext ic = new InitialContext();
ConnectionFactory cf =
  (ConnectionFactory)ic.lookup( "java:comp/env/eis/SAPAdapter" );
  Die Erzeugung eines Verbindungs-Handles auf Applikationsebene zum
SAP R/3-System erfolgt über Verbindungsparameter, die über eine
SAPConnectionSpec-Instanz übergeben werden:
ConnectionSpec cspec = new SAPConnectionSpec( "800", "DE", "user", "password" );
Connection c = cf.getConnection( cspec );
  Anschlieÿend wird eine SAPInteraction-Instanz erzeugt, über die Funktionen
auf dem SAP R/3-System ausgeführt werden können:



96
                                             7.3. Entwurf und Implementierung

SAPInteraction i = (SAPInteraction)c.createInteraction();
   Die Erzeugung einer JCo-Datenstruktur, welche die Parameter für den spä-
teren Aufruf der Funktion BAPI_MATERIAL_GETLIST enthält, erfolgt duch den
folgenden Befehl, wobei i die zuvor erzeugte Interaction-Instanz der verwendeten
Verbindung darstellt:
JCO.Function function = i.getFunction( "BAPI_MATERIAL_GETLIST" );
  Die Suchparameter werden dann, entsprechend der Beschreibung der Funkti-
on BAPI_MATERIAL_GETLIST durch den Function Builder, gesetzt. Die Variable
descr_low enthält dabei den übergebenen Suchparameter für die Beschreibung
des Materials:
JCO.Table codes =
  function.getTableParameterList().getTable( "MATERIALSHORTDESCSEL" );
codes.appendRow();
codes.setValue( ' I ' , "SIGN" );
codes.setValue( "CP", "OPTION" );
codes.setValue( descr_low, "DESCR_LOW" );
codes.setValue( ' ' , "DESCR_HIGH" );
 Die Ausführung des Funktionsbausteins erfolgt schlieÿlich über den Aufruf der
Methode execute der Interaction-Instanz:
i .execute( function );
  Die Interaction-Instanz sollte wieder geschlossen werden, wenn keine Funktio-
nen mehr über sie ausgeführt werden:
i . close ();
  Abschlieÿend wird die Verbindung zum R/3-System wieder geschlossen:
c. close ();
   Wir erinnern uns, dass das Schlieÿen dieses Applikationshandles nicht unbe-
dingt die Beendigung der physikalischen Verbindung zum SAP R/3-System zur
Folge hat. Möglicherweise wird die zugrundeliegende physikalische Verbindung
wieder in den Verbindungspool des Applikationsservers zurückgeführt. Die Vor-
gehensweise liegt im Ermessen des Applikationsservers.
   Die von dem aufgerufenen Funktionsbaustein zurückgelieferte Materialliste
wird nun verarbeitet und von der Methode getMaterialList der Session Bean
als Liste in Form einer Java-Klasse an den Aufrufer zurückgeliefert. Implemen-
tierungsdetails dazu können den Quelltexten entnommen werden.

Anwendungsfall Materialdetails
Der Aufruf des Funktionsbausteins BAPI_MATERIAL_GET_DETAIL lehnt sich prin-
zipiell an den Aufruf im zuvor beschriebenen Anwendungsfall Materialsuche an.
Daher werden im Folgenden lediglich wichtige Unterschiede beschrieben.



                                                                             97
7. Entwicklung der Beispielanwendung

     Die   Anzeige   von Materialdetails wird über den Funktionsbaustein
BAPI_MATERIAL_GET_DETAIL ermöglicht. Der Parameter MATERIAL muss
gesetzt werden und steht für die Materialnummer des Materials, dessen Details
zurückgegeben werden sollen. Die Methode innerhalb der Session Bean erhält
den Namen getMaterialDetail.
   Die Erzeugung einer Datenstruktur für den Aufruf des entsprechenden Funk-
tionsbausteins sieht wie folgt aus:
JCO.Function function = i.getFunction( "BAPI_MATERIAL_GET_DETAIL" );
     Die Materialnummer des gewünschten Materials muss gesetzt werden:
function.getImportParameterList().setValue( material, "MATERIAL" );
  Die Materialdetails werden nun von der getMaterialDetail-Methode verar-
beitet und in Form einer Liste als Java-Klasse zurückgeliefert.


7.3.2. Entwicklung des Clients
Ein Web-Client soll als Benutzungsoberäche für die Materialverwaltung dienen.
Die vom Webserver generierten dynamischen Seiten werden in diesem Fall von
einem Browser dargestellt.

JSPs und Servlets
Die Generierung der Seiten auf dem Webserver kann durch unterschiedliche Tech-
nologien erfolgen. Unter Einsatz von Java bietet sich die Verwendung von Java
Server Pages (JSPs) oder Servlets an. JSPs und Servlets werden serverseitig aus-
geführt, indem sie ähnlich einer HTML-Seite aufgerufen werden. Zusätzlich kön-
nen Parameter übergeben werden, die beispielsweise aus einem zuvor ausgefüll-
ten HTML-Formular stammen können. Die aus diesen Informationen generierte
HTML-Seite wird vom Server an den Browser zurückgeliefert.
  Der Vorteil von JSPs gegenüber Servlets liegt darin, dass sie einfacher zu bear-
beiten sind, weil sie HTML und Java in einer Datei vereinen. Aus diesem Grund
wurde die JSP-Technologie für die Implementierung des Webclients innerhalb
dieser Diplomarbeit gewählt. Eine Einführung in diese Technologie kann durch
das J2EE Tutorial [SB02] erfolgen.

Der Web-Client
Abbildung 7.1 zeigt den Web-Client für die Materialauskunft innerhalb des Mi-
crosoft Internet Explorer. Er besteht aus einer JSP, welche mehrere Eingabefelder
enthält. Die Felder Suchstring und Max. Suchergebnisse werden für die Ma-
terialsuche benötigt, während das Feld Materialnummer für die Anzeige der
Materialdetails verwendet wird.



98
                                           7.3. Entwurf und Implementierung




                 Abbildung 7.1.: Screenshot Materialauskunft

   In dem gezeigten Screenshot wurde *dichtung* als Suchstring eingetragen und
100 als die maximale Anzahl von Suchergebnissen angegeben. Die Materialsuche
wurde dann durch den Klick auf den Button Material suchen! ausgeführt. Die
eingegebenen Daten aus den Formularfeldern wurden daraufhin an die neu auf-
gebaute JSP übergeben. Diese Übergabeparameter sind in der Adresszeile des
Browserfensters wiederzunden. In dem gezeigten Fall führte die Auswertung der
übergebenen Daten zur Ausführung der Methode getMaterialList der Session
Bean. Diese wurde unter anderem mit dem eingegebenen Suchstring *dichtung*
aufgerufen. Die zurückgelieferte Liste der Suchergebnisse wurde dann als HTML-
Tabelle ausgegeben.

Implementierung der JSP
Die implementierte JSP enthält neben HTML-Tags wie beispielsweise <head>,
<body> oder <form> JSP-spezische Konstrukte der folgenden Form:

   • Direktiven (<%@ page ... %>) importieren Klassen

   • Scriptlets (<% ... %>) führen Java-Befehle aus. Sie verwerten Übergabe-



                                                                           99
7. Entwicklung der Beispielanwendung

          parameter, führen Schleifen aus und können HTML in Abhängigkeit von
          Bedingungen einfügen.

     • Ausdrücke (<%= ... %>) fügen Werte lokaler Variablen ein.

     • Deklarationen (<%! ... %>) deklarieren Variablen und Methoden.

  Über die folgenden Zeilen werden notwendige Klassen und Packete eingebun-
den:
<%@ page import="SAPBeispiel,SAPBeispielHome,javax.ejb.∗,javax.naming.∗,
javax.rmi.PortableRemoteObject,java.rmi.RemoteException,java.util.∗" %>
  Darunter benden sich auch die Klassen, die für den Zugri auf die zuvor
entwickelte Session Bean benötigt werden.
  Der folgende Bereich erstellt die Verbindung zu der Session Bean, welche
die beiden Methoden getMaterialList und getMaterialDetail zur Verfügung
stellt:
<%!
 private SAPBeispiel sapbeispiel = null;
 public void jspInit()
 {
      try
      {
          InitialContext ic = new InitialContext();
          Object objRef = ic.lookup("java:comp/env/ejb/SAPBeispielEJB");
          SAPBeispielHome home =
            (SAPBeispielHome)PortableRemoteObject.narrow(
              objRef,
              SAPBeispielHome.class );
          sapbeispiel = home.create();
      }
      .
      .
      .
 }
%>
  Es folgt HTML-Quelltext kombiniert mit Befehlen für die Umsetzung der An-
wendungsfälle Materialsuche und Materialdetails.
  Der für den Anwendungsfall Materialdetails zuständige Bereich der JSP be-
ginnt beispielsweise wie folgt:
<%
 String material = request.getParameter( "MATERIAL" );




100
                                             7.3. Entwurf und Implementierung

  if ( material != null )
 {
     Vector materialdetail = sapbeispiel .getMaterialDetail( material );

     if ( materialdetail != null )
     {
%>
.
.
.
   Zu Beginn wird der Übergabeparameter MATERIAL ausgewertet, der die Mate-
rialnummer enthält. Wenn dieser Parameter korrekt übergeben wurde und nicht
gleich null ist, wird die Methode getMaterialDetail aufgerufen usw. Weitere
Implementierungsdetails können der JSP-Datei index.jsp entnommen werden,
die sich auf der beiliegenden CD bendet.




                                                                           101
7. Entwicklung der Beispielanwendung




102
8. Zusammenfassung und
   Ausblick

Die Integration heterogener Enterprise Information Systems (EISs) in die Platt-
form der Java 2 Enterprise Edition (J2EE) wird über die Connector-Architektur
auf eine standardisierte Art und Weise ermöglicht. Das Ziel der Enterprise Appli-
cation Integration (EAI), Unternehmensanwendungen zu integrieren, kann somit
in Verbindung mit den vorhandenen Technologien des J2EE weitgehend umge-
setzt werden.
   Die Connector-Spezikation wirkt durchdacht und präzise ausgearbeitet. Le-
diglich aus Entwicklersicht scheint es schwierig, die Spezikation in eine entspre-
chende Implementierung umzusetzen. Der Grund dafür ist in der noch fehlenden
Literaturvielfalt zu diesem Thema zu suchen.
   Im Gegensatz zur Connector-Architektur besteht das komplex erscheinende
SAP R/3-System bereits seit längerer Zeit. Unterschiedliche Zugrismöglichkei-
ten existieren unter Verwendung verschiedener Technologien. Durch die nur un-
zureichend verfügbare Dokumentation wird das Aunden der für den Bedarfsfall
richtigen Zugrismethode erschwert. Ein Ausschnitt aus dem Buch B2B App-
lication Integration [Lin00] gibt diese Problematik treend wieder:

     The upside is that unlike many packaged applications, SAP has well-
     dened and well-tested built-in interfaces that adequately provide for
     the sharing of data and processes with the outside world. The down-
     side is that these same interfaces are complex, their architecture is
     confusing, information is lacking about how best to leverage them,
     and various other technical issues still require resolution.

  Unter Verwendung der J2EE Connector-Architektur beschränkt sich die Wahl
der Zugrismethode auf die Wahl eines geeigneten Ressourcenadapters. Im ein-
fachsten Fall kann so über eine standardisierte Schnittstelle auf das EIS zugegrif-
fen werden. Nur im Falle der Neuimplementierung eines solchen Adapters besteht
die Notwendigkeit, sich mit den Details des anzusprechenden Systems auseinan-
derzusetzen.
  Die Version 2.0 der Connector-Architektur verspricht weitere Verbesserungen
wie beispielsweise die Unterstützung asynchroner Ressourcenadapter und XML-



                                                                               103
8. Zusammenfassung und Ausblick

Support, durch die weitere Möglichkeiten der Integration von Unternehmensan-
wendungen entstehen. Die J2EE-Plattform könnte sich somit zu einem Standard
der EAI entwickeln.




104
A. Packaging und Deployment

Es folgen einige praktische Hinweise für das Packaging und Deployment von
J2EE-Komponenten in Verbindung mit dem von Sun angebotenen J2EE-
Applikationsserver.


A.1. Application Deployment Tool
Das Application Deployment Tool des J2EE erleichtert das Deployment. Vor der
Benutzung sollte der J2EE-Applikationsserver gestartet werden. Dies kann z. B.
durch folgende Befehle aus der Kommandozeile heraus geschehen:

  1. Starten des Applikationsservers: j2ee -verbose

  2. Starten des Application Deployment Tools: deploytool

  Das Deployment Tool bietet über sogenannte Wizards auch Hilfestellung beim
Packaging. Benötigte Dateiformate wie EAR oder RAR können so erzeugt wer-
den.
  Es ist darauf zu achten, dass die EJBs den Ressourcenadapter und die Clients
die EJBs ansprechen können. Dies geschieht durch die Verwendung geeigneter
Reference Names. Der Ressourcenadapter kann beispielsweise den Reference
Name eis/SAPAdapter erhalten, wodurch ihn eine EJB beispielsweise über die
lookup-Methode unter java:comp/env/eis/SAPAdapter ansprechen könnte. Die
verwendeten Reference Names müssen mit den in den Quelltexten verwendeten
Namen übereinstimmen.
  Die Verwendung des Deployment Tools wird im J2EE Tutorial [SB02] genau-
er beschrieben. Hinweise zum Packaging und Deploying des Ressourcenadapters
werden im Folgenden gegeben.


A.2. Ressourcenadapter
Die Erzeugung der für den Ressourcenadapter vorgeschriebenen RAR-Datei kann
über den Wizard des Deployment Tools geschehen. Der darin enthaltene Deploy-
ment Descriptor wird durch den Wizard generiert.



                                                                          105
A. Packaging und Deployment

  Das Deploying und Undeploying des Ressourcenadapters kann innerhalb der
graschen Benutzungsoberäche des Deployment Tool erfolgen. Die Verwendung
der Kommandozeile ist ebenfalls möglich:

    • Deploying:
      z. B. deploytool -deployConnector SAPAdapter.rar localhost

    • Undeploying:
      z. B. deploytool -undeployConnector SAPAdapter.rar localhost

  Die Rechte (Permissions) im Applikationsserver müssen so gesetzt sein, dass der
Ressourcenadapter Native Libraries verwenden kann, falls diese benötigt werden.
Im Falle des SAPAdapter greift der Ressourcenadapter auf die DLL-Dateien des
JCo zu und benötigt diese Rechte. Das Setzen der Rechte kann beim J2EE-
Applikationsserver von Sun in der Datei server.policy erfolgen.

A.2.1. Deployment Descriptor
Der folgende Deployment Descriptor ist Teil des entwickelten Ressourcenadapters
SAPAdapter.
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE connector PUBLIC '-//Sun Microsystems, Inc.//DTD Connector 1.0//EN'
'http://java.sun.com/dtd/connector_1_0.dtd'>

<connector>
  <display-name>SAPAdapter</display-name>
  <description>Ressourcenadapter fuer den Zugriff auf SAP R/3</description>
  <vendor-name>Ludger Bischofs</vendor-name>
  <spec-version>1.0</spec-version>
  <eis-type>SAP R/3</eis-type>
  <version>1.0</version>
  <resourceadapter>
    <managedconnectionfactory-class>SAPManagedConnectionFactory</managedconnectionfactory-class>
    <connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface>
    <connectionfactory-impl-class>SAPConnectionFactory</connectionfactory-impl-class>
    <connection-interface>javax.resource.cci.Connection</connection-interface>
    <connection-impl-class>SAPConnection</connection-impl-class>
    <transaction-support>LocalTransaction</transaction-support>
    <config-property>
      <config-property-name>ServerName</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
    </config-property>
    <config-property>
      <config-property-name>SystemNumber</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
    </config-property>
    <authentication-mechanism>
      <authentication-mechanism-type>BasicPassword</authentication-mechanism-type>
      <credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface>
    </authentication-mechanism>
    <reauthentication-support>false</reauthentication-support>
  </resourceadapter>
</connector>




106
B. CD

Im Hauptverzeichnis der dieser Diplomarbeit beiliegenden CD bendet sich die
HTML-Datei index.html. Sie kann über einen Browser geönet werden und ver-
mittelt einen Überblick über den Inhalt der CD.
  Das Hauptverzeichnis der CD besteht aus vier Verzeichnissen mit folgendem
Inhalt:

   • Das Verzeichnis Diplomarbeit beinhaltet diese Dokumentation im PDF-
     Format (Adobe Acrobat).

   • Das Verzeichnis Quelltexte enthält die in dieser Diplomarbeit vorgestell-
     ten und ausgearbeiteten Quelltexte des Ressourcenadapters, der EJBs, der
     JSP und der Applikationsclients. Zusätzlich benden sich darin die aus den
     Quelltexten generierten Java-Dokumentationen.

   • Das Verzeichnis SAP Java Connector 1.1.03 enthält den SAP Java
     Connector (JCo) in der Version 1.1.03.

   • Das Verzeichnis Quellen beinhaltet einige innerhalb dieser Ausarbeitung
     verwendete Literaturquellen in digitaler Form.




                                                                           107
B. CD




108
Abbildungsverzeichnis

 2.1.   m mal n-Integrationsproblem . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   11
 2.2.   m + n-Integrationsproblem . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   12
 2.3.   Überblick über die Connector-Architektur . . . .       .   .   .   .   .   .   .   .   .   13
 2.4.   Architektur in einer nicht verwalteten Umgebung        .   .   .   .   .   .   .   .   .   15
 2.5.   Architektur in einer verwalteten Umgebung . . .        .   .   .   .   .   .   .   .   .   16
 2.6.   Lokale Transaktion . . . . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   18
 2.7.   XAResource-basierte Transaktion . . . . . . . . .      .   .   .   .   .   .   .   .   .   19

 3.1. Schichten eines Business-Objekts . . . . . . . . . . . . . . . . . .                         30

 4.1. SAP Resource Adapter . . . . . . . .      . . . . . . . . . .        . . . . . .             59
 4.2. Zusammenspiel der Komponenten in           Verbindung mit            der Java
      RFC Class Library . . . . . . . . . .     . . . . . . . . . .        . . . . . .             61
 4.3. SAP Business Connector . . . . . . .      . . . . . . . . . .        . . . . . .             62
 4.4. Internet Transaction Server . . . . .     . . . . . . . . . .        . . . . . .             64

 5.1. Anwendungsfalldiagramm zur Materialverwaltung . . . . . . . . .                              70
 5.2. Architektur zum Beispielszenario . . . . . . . . . . . . . . . . . .                         71

 6.1. Entwurf des Ressourcenadapters in einer verwalteten Umgebung .                               78
 6.2. Beendigung der physikalischen Verbindung in einer nicht verwal-
      teten Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . .                         84
 6.3. Ausführung von EIS-Funktionen . . . . . . . . . . . . . . . . . . .                          88

 7.1. Screenshot Materialauskunft . . . . . . . . . . . . . . . . . . . . .                        99




                                                                                                   109
Abbildungsverzeichnis




110
Tabellenverzeichnis

 4.1. Mapping von ABAP-Datentypen in Java-Datentypen . . . . . . .   57




                                                                     111
Tabellenverzeichnis




112
Abkürzungsverzeichnis

ABAP Advanced Business Application Programming
ADO ActiveX Data Object
AGate Application Gateway
ALE Application Link Enabling
ASP Active Server Page
BAPI Business Application Programming Interface
BC Business Connector
BOR Business Object Repository
CCI Common Client Interface
COM Component Object Model
CORBA Common Object Request Broker Architecture
CPI-C Common Programming Interface-Communication
DBMS Database Management System
DCOM Distributed Component Object Model
DLL Dynamic Link Library
EAI Enterprise Application Integration
EAR Enterprise Archive
EDI Electronic Data Interchange
EIS Enterprise Information System
EJB Enterprise Java Bean


                                                   113
Abkürzungsverzeichnis

EKKIS Enge Kopplung klinischer Informationssysteme
ERP Enterprise Resource Planning
HTML Hypertext Markup Language
HTTP Hypertext Transport Protocol
IAC Internet Application Component
IDoc Intermediate Document
IS-H Informationssystem Health
ITS Internet Transaction Server
J2EE Java 2 Enterprise Edition
JAAS Java Authentication and Authorization Service
JAR Java Archive
JCo Java Connector
JNDI Java Naming and Directory Interface
JNI Java Native Interface
JRFC Java Remote Function Call
JVM Java Virtual Machine
LUW Logical Unit of Work
MTS Microsoft Transaction Server
OFFIS Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-
      Werkzeuge und -Systeme

OLE Object Linking and Embedding
RAR Resource Adapter Archive
RFC Remote Function Call
RFM Remote Function Module
RMI-IIOP Remote Method Invocation over Internet Inter-Orb Protocol
RPC Remote Procedure Call


114
SAP-RA SAP Resource Adapter
TP-System Transaction Processing System
URL Universal/Uniform Resource Location
WGate Web Gateway
XML Extensible Markup Language




                                          115
Abkürzungsverzeichnis




116
Literaturverzeichnis

[DCO]     Microsoft Corporation: Distributed Component Object Model (DCOM).
          http://www.microsoft.com/com/tech/DCOM.asp.           besucht am
          23.04.2002

[Ham97] Hamilton, Graham: JavaBeans Specication. 1.01. Sun microsy-
        stems, Juli 1997

[Has00]   Hasselbring, Wilhelm: Information System Integration. In: Com-
          munications of the ACM 43 (2000), Juni, S. 3338

[INQ]     SAP AG: SAP In-Q-My. http://www.sap.com/solutions/technology/inqmy.asp.
           besucht am 18.05.2002

[JCO]     SAP      AG:           SAP     Java     Connector    Intro     Page.
          http://service.sap.com/connectors.  besucht am 05.03.2002

[JZ00]    Jürgen Zimmermann, Gerd B.: Verteilte Komponenten und Daten-
          bankanbindung. Addison Wesley, 2000

[LGD01] Linda G. DeMichiel, Sanjeev K.: Enterprise JavaBeans Specicati-
        on. 2.0. Sun microsystems, August 2001

[Lin00]   Linthicum, D. S.: B2B Application Integration - e-Business-Enable
          Your Enterprise. Addison Wesley, 2000

[MS01]    Martin Schissler, Otto K. Ferstl Elmar J. S.: Unterstützung von
          Kopplungsarchitekturen durch SAP R/3 / Universität Bamberg. Feld-
          kirchenstraÿe 21, 96045 Bamberg, 2001 ( FWN-2001-008).  For-
          schungsbericht

[Nie01]   Niemann, Heiko: EKKIS-02: Projektziel. OFFIS, März 2001

[Rod01]   Rodoni, Jennifer: The Java 2, Enterprise Edition (J2EE) Connector
          Architecture's Resource Adapter. Sun microsystems, Dezember 2001

[RS01]    Rahul Sharma, Tony N.: J2EE Connector Architecture and Enter-
          prise Application Integration. Addison Wesley, Dezember 2001



                                                                          117
Literaturverzeichnis

[SAP]     SAP AG: SAP Bibliothek. http://help.sap.com.  insbesondere SAP
          R/3 Release 4.6B und 4.6C

[SAP00a] SAP AG: SAP Business Connector Integration Guide. 2000

[SAP00b] SAP AG: White Paper - SAP Middleware Technologies. 2000

[SAP01]   In-Q-My Technologies GmbH: The SAP Resource Adapter. Juni 2001

[SB02]    Stephanie Bodoff, Kim Haase Eric Jendrock Monica Pawlan Be-
          ath S.: The J2EE Tutorial. Sun microsystems, Januar 2002

[Sch02]   Schuessler, Thomas G.: Developing Applications with the SAP Java
          Connector (JCo). ARAsoft GmbH, 2002

[Sha01a] Shannon, Bill: Java 2 Platform Enterprise Edition Specication. 1.3.
         Sun microsystems, Juli 2001

[Sha01b] Sharma, Rahul: J2EE Connector Architecture Specication. 1.0. Sun
         microsystems, August 2001

[XOp]     X/Open CAE Specication - Distributed Transaction Processing: the
          XA specication.  X/Open document




118
Erklärung:
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.

   Oldenburg, den 05.06.2002




..................................................................
    Ludger Bischofs




                                                                         119

								
To top