Java-Proxy-Objekte (XI 3.0 kompatibel) 

Definition

Alle Java-Objekte, die ausgehend von einem Service-Interface aus dem Enterprise Services Repository (ES Repository) im SAP-System angelegt werden, nennt man Java-Proxy-Objekte. Zu einem Service-Interface werden mehrere Proxy-Objekte im System angelegt (Java-Klassen oder Java-Interfaces). Die Java-Proxy-Generierung im ES Builder legt Java-Proxy-Objekte an, die XI 3.0 kompatibel sind (Interface-Pattern: zustandslos (XI 3.0 kompatibel)).

Service-Interfaces dieses Interface-Pattern verweisen auf genau eine Operation, die Operation verweist auf Message-Typen und die Message-Typen verweisen wiederum auf Datentypen. Alle vom Service-Interface referenzierten Objekte (auch Fault-Message-Typen) nennt man zusammenfassend auch Interface-Objekte. Sie sind das Pendant zu den daraus generierten Proxy-Objekten.

Struktur

Man kann die unterschiedlichen Interface-Objekte in zwei Klassen einteilen: Das Service-Interface selbst und die Parameter und Datentypen dazu.

Auch nach der Generierung lässt sich jedes generierte Proxy-Objekt seinem zugehörigen Interface-Objekt im ES Repository zuordnen.

Interfaces

Interfaces haben eine Kategorie (Outbound, Inbound oder Abstrakt) und einen Modus (synchron oder asynchron), siehe Kommunikationsparameter.

Die Java-Laufzeit für Java-Proxies der Java-Proxy-Generierung des ES Builders stellt kein Queueing für die asynchrone Verarbeitung von Messages zur Verfügung. Tritt beim Versenden einer asynchronen Message ein Fehler auf, wird eine Ausnahme ausgelöst.

Für J2EE-Anwendungen sind nur die Kategorien Outbound und Inbound relevant. Abhängig von der Kategorie werden folgende Proxy-Objekte generiert:

●      Inbound-Service-Interfaces werden gerufen, um einen Service zu starten, der im synchronen Fall ein Ergebnis zurückliefert. Die Proxy-Generierung generiert für ein Inbound-Service-Interface ein Java-Interface. Um den Service bereitzustellen, implementieren Sie dieses Interface mit Hilfe einer Java-Klasse. Für die implementierende Klasse ist folgendes zu beachten: Ist JavaInterface der Name des generierten Java-Interfaces, dann muss die implementierende Klasse JavaInterfaceImpl heißen und im gleichen Paket wie das generierte Java-Interface liegen.

●      Outbound-Service-Interfaces werden gerufen, um eine Message zu senden. Ein Outbound-Service-Interface wird auf eine Java-Klasse abgebildet.

●      Für J2EE-Anwendungen werden zusätzliche Bean-Klassen generiert. In diesem Fall senden und empfangen Sie Messages nicht direkt über die Proxy-Klassen, sondern über die Bean-Klassen. Für Java-Standalone-Anwendungen werden diese Klassen nicht benötigt.

Allgemein sieht die Signatur der generierten Methode zu einem Service-Interface SI aus dem ES Repository folgendermaßen aus (im asynchronen Fall ohne Rückgabeparameter):

●      Im Outbound-Fall:      public <Klasse für Response-Message> SI(<Klasse für Request-Message>)

●      Im Inbound-Fall:         public <Klasse für Response-Message> SI(<Klasse für Request-Message>)

Die Klasse für die Input- beziehungsweise Output-Message entspricht dabei dem Datentyp, auf den der verwendete Message-Typ verweist. Für Message-Typen selbst werden keine öffentliche globale Klassen erzeugt (Ausnahme sind Fault-Message-Typen).

Parameter und Datentypen

Unabhängig von der Kategorie werden folgende Objekte erzeugt:

●      Eine Klasse für jeden komplexen Datentyp erzeugt, die set/get-Methoden für den Zugriff auf die jeweiligen Felder enthält.

●      Für einfache Datentypen werden keine Klassen benötigt. Wird zum Beispiel ein einfacher Datentyp vom Typ xsd:stringverwendet, generiert die Java-Proxy-Generierung keine eigene globale Klasse für den Datentyp, sondern benutzt direkt den korrespondierenden Java-Datentyp java.lang.String.

Für XSD-Elemente, die unbegrenzt oft auftreten können, und Aufzählungen gibt es spezielle Umsetzungen. Weitere Informationen: Tabellen, Enumerations.

Beispiel

Die folgende Grafik gibt ein Beispiel, wie ein Service-Interface aus dem ES Repository auf ein Java-Proxy abgebildet wird:

Die ursprünglichen Namen der Interface-Objekte sind fett hervorgehoben. Der Name des Service-Interface und der Name der Operation stimmt im Fall des Interface-Pattern zustandslos (XI 3.0 kompatibel) immer überein (XI 3.0 Message-Interfaces hatten implizit nur eine Operation).

Man sieht, dass die Java Proxy-Generierung die Namen etwas erweitert (siehe auch: Namensvergabe für Java-Proxy-Objekte). Die Methode bookOut erwartet als Formalparameter om vom Typ Ct_Type. Sie übergeben also direkt den Datentyp – der Message-Typ wird von der Proxy-Laufzeit über die private Klasse Om_Message intern berücksichtigt.