Verwenden Sie diese Task, wenn Sie die nativen APIs für optimierte lokale Adapter verwenden möchten, um einen
externen Adressraum mit WebSphere Application
Server for z/OS zu verbinden und eine EJB-Anwendung (Enterprise JavaBeans) aufzurufen, die im Anwendungsserver implementiert ist.
Vorbereitende Schritte
Die Dämongruppe von
WebSphere Application Server muss in demselben
z/OS-Image aktiv sein, aus dem auch die Registrierungsanforderung stammt.
Wenn
Sie Customer
Information Control System (CICS) verwenden, muss das taskbezogene
Benutzerexitprogramm (TRUE) aktiviert werden, bevor eine Verbindung zwischen CICS und WebSphere Application Server hergestellt wird.
Wie das taskbezogene Benutzerexit-Programm durch die Transaktionen aktiviert wird, können Sie in den Artikeln
"BBOC-, BBO$- und BBO#-Transaktionen in der Clientumgebung installieren" und "BBOC-, BBO$- und BBO#-Transaktionen von WebSphere Application Server" nachlesen.
Für Programme, die in z/OS-Stapelverarbeitungsumgebungen und UNIX Systems Services (USS) ausgeführt werden, muss das taskbezogene Benutzerexit-Programm nicht aktiviert werden.
Stellen Sie sicher, dass der aktuelle Adressraum durch den Aufruf der API "Registrieren" (BBOA1REG)
bereits registriert und an die Zieldämongruppe von WebSphere Application Server gebunden wurde.
Informationen zu diesem Vorgang
Die Adapter-APIs rufen eine Stateless-Session-Bean über ein externes Programm in nativer Sprache auf und rufen die Antwort ab.
Dies wurde für Nutzer konzipiert, die mehr Benutzer
Flexibilität wünschen und die die maximale Größe des Antwortbereichs nicht im Voraus kennen.
Vorgehensweise
- Die Anwendung für den Clientadressraum, die in einer nativen Sprache wie
Cobol, PL/I, C/C++ oder Assembler geschrieben ist, ruft die API "Verbindung abrufen" (BBOA1CNG) auf und übergibt
den Registrierungsnamen, der für den Registrierungsaufruf verwendet wurde. Es wird eine Verbindungskennung zurückgegeben, die für alle künftige API-Aufrufe verwendet werden muss.
- Die Clientanwendung stellt ihre Parameter zusammen und legt als
Zielservicenamen den Pfadnamen der JNDI-Home-Schnittstelle für die Enterprise-Bean fest,
die sie aufrufen möchte, und ruft die API "Anforderung senden" (BBOA1SRQ) auf. Daraufhin wird eine Verbindung zur Steuerregion von WebSphere Application Server
und anschließend zu einer über WLM (Workload-Manager) abgeleiteten Servant-Region hergestellt, wo
die übergebene JNDI-Home-Schnittstelle ihre Methode "create" ausführt.
Die voreingestellte Methode "execute" wird über die Bytefeldgruppenparameter gesucht und aufgerufen.
Die Steuerung wird sofort an den Caller (Aufrufenden) zurückgegeben, wenn der
Parameter "asynchronous" angegeben und auf 1 gesetzt ist. Wenn der Parameter
""asynchronous" auf 0 (null) gesetzt ist, gibt die API die Länge der Antwort im
Parameter "ResponseLength" sowie den Rückgabewert zurück.
- In der Servant-Region von WebSphere Application Server ruft die Methode "execute" der Ziel-Bean die Geschäftslogik auf. Die Methode "execute" der Ziel-Bean kann jetzt die erforderliche Geschäftslogik aufrufen, bevor sie die Antwortdaten
als serialisierte Bytefeldgruppe an den Caller in der nativen Sprache zurückgibt.
- Ein Rückkehrcode und ein Ursachencode von 0 (null) zeigen an, dass die Client-API
"Anforderung senden" erfolgreich in die Warteschlange eingereiht wurde. Wenn der Parameter ""asynchronous"
auf 0 (null) gesetzt ist, werden die Antwortlänge im Parameter
"ResponseLength" sowie der Rückgabewert bereitgestellt. Wenn der Parameter ""asynchronous"
auf 1 gesetzt, ist die Antwort möglicherweise noch nicht bereit, und ein Aufruf
der API "Antwortlänge empfangen" (BBOA1RCL) ist erforderlich, um festzustellen, ob und in welcher Länge die Antwort angekommen ist.
- Für asynchrone Aufrufe der API "Anforderung senden" ruft die Clientanwendung die API "Antwortlänge empfangen"
(BBOA1RCL) mit "asynchronous 0" oder "asynchronous 1" auf. Der Aufruf "asynchronous 0" zeigt an, dass die Adapter-API den Thread so lange blockieren muss, bis eine Antwort empfangen wird.
Der Aufruf "asynchronous 1" zeigt an, dass die Adapter-API sofort zurückkehrt, unabhängig davon, ob die Antwort angekommen ist oder nicht.
- Ein Rückkehrcode und ein Ursachencode von 0 (null) zeigen an, dass der Aufruf der Client-API "Antwortlänge empfangen" erfolgreich abgeschlossen wurde. Wenn der Parameter "asynchronous" auf 1 gesetzt ist, zeigen ein ResponseLength-Wert und ein Rückgabewert, die nur aus 0xFFs bestehen, an, dass
noch keine Antwort in der übergebenen Verbindung empfangen wurde.
Die gibt der Clientanwendung mehr Kontrolle über die Art und Weise, in der Anforderungen gesendet und Antworten empfangen werden.
Der Client kann Sendeanforderungen gruppieren und nacheinander über eine Gruppe von Verbindungen senden und diese
Verbindungen dann in regelmäßigen Abständen nach Antworten abfragen.
Einer Verbindung, die eine Sendeanforderung mit dem Aufruf "asynchronous 1" verarbeitet, kann so lange keine weitere Sendeanforderung übergeben werden, bis die zugehörigen
Aufrufe der APIs "Antwortlänge empfangen" und "Daten abrufen" verarbeitet wurden.
Wichtig: Wenn diese APIs
asynchron verwendet werden, d. h., wenn der Parameter "asynchronous" auf 1 gesetzt ist,
können Sendeanforderungen nur über Verbindungen, die nicht als transaktionsorientierte Verbindungen konfiguriert sind,
gruppiert und gleichzeitig verarbeitet werden.
Wenn Sie beispielsweise CICS verwenden und eine Arbeitseinheit an einer RRS-Arbeitseinheit mit Wiederherstellung
ausrichten möchten und einen Synchronisationspunkt unter CICS an
WebSphere Application Server weitergeben müssen, kann nur eine einzige Verbindung zu einem bestimmten
WebSphere-Server in der aktuellen CICS-Task verwendet werden. Diese Anforderung empfängt einen
Warnrückkehrcode, der darauf hinweist, dass der Adapter die Festschreibung nicht über mehrere Verbindungen an denselben
Server in derselben CICS-Task weitergibt.
- Clientanwendungen verwenden die Antwortlänge, die von der API "Antwortlänge zurückgeben"
zurückgegeben wird, um sicherzustellen, dass ein Bereich in ausreichender Größe für die Aufnahme der Daten vorhanden ist,
und einen Aufruf der API "Daten abrufen" (BBOA1GET), um die Antwortdaten in ihren Puffer zu kopieren.
- Clientanwendungen können diese Aktion mit derselben Verbindungskennung so oft wiederholen, bis die Verbindung freigegeben werden kann.
Bei der Freigabe der Verbindung wird die API "Verbindung freigeben" (BBOA1CNR) aufgerufen. Verbindungskennungen müssen freigegeben werden, bevor sie
in einem Aufruf der API "Verbindung abrufen" erneut abgerufen und wiederverwendet werden kann.
Ergebnisse
Der Client hat eine Stateless Session-Bean in
WebSphere Application Server über die APIs für optimierte lokale Adapter aufgerufen.