[z/OS]

Native APIs für optimierte lokale Adapter für den Aufruf einer EJB-Anwendung über einen externen Adressraum verwenden

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_connectejbapi
Dateiname:tdat_connectejbapi.html