DB2 Web Query ist eine Web-basierte Anwendung. Der aktuelle Artikel beschäftigt sich mit den verschiedenen Server-Programmen und gibt einen Überblick über die Architektur von DB2 Web Query.

Neben den bereits im letzten Artikel erwähnten Objekten wie Bi­bliothek, Verzeichnisse im IFS und verschiedene Benutzerprofile wurden auch zahlreiche Server-Programme erzeugt. Diese werden benötigt, um die Verbindung zu i5/OS über SQL CLI (Call Level Interface) herzustellen. Das CLI ist eine in i5/OS verfügbare Schnittstelle, die aus verschiedenen APIs besteht. Diese ist eine Untermenge von ODBC. Der zugehörige Systemjob, der CLI ausführt, ist QSQSRVR im Subsystem QSYSWRK.

Nach dem Starten von DB2 Web Query (STRWEBQRY) werden die folgenden Jobs auf dem System i ausgeführt:

  • EDAPTH ist für die Erstellung und Verwaltung des Arbeitsbereiches zuständig. Aktueller Benutzer: QSECOFR
  • EDAPLOG enthält die Start-Informationen. Aktueller Benutzer: QSECOFR
  • EDAPGWY: Davon gibt es drei Jobs, die als Listener Job dienen: einer für ­HTTP, einer für TCP und einer für Java. Diese empfangen Anforderungen, die sie an die TSCOM3 Jobs weiterleiten. Aktueller Benutzer: QSECOFR
  • TSCOM3: Standardmäßig werden vier Jobs TSCOM3 gestartet. Diese empfangen Anfragen vom EDAPGWY-Job und setzen diese in SQL um.
  • JSCOM3 führt Java-Prozesse aus. Aktueller Benutzer: QWEBQRYADM
  • HLISNK: Interner Server-Prozess. Aktueller Benutzer: QWEBQRYADM

Alle diese Jobs laufen im Subsystem QSYSWRK (vgl. Abb. 1).

                       Aktueller                                      
Subsystem/Job  Benutzer    Art   CPU %  Funktion        Status
QSYSWRK        QSYS        SBS     0,0                   DEQW 
  EDAPGWY      QSECOFR     BCI     0,0  PGM-EDAPGWY      SELW 
  EDAPGWY      QSECOFR     BCI     0,0  PGM-EDAPGWY      SELW 
  EDAPGWY      QSECOFR     BCI     0,0  PGM-EDAPGWY      SELW 
  EDAPLOG      QSECOFR     BCI     0,0  PGM-EDAPLOG      TIMW 
  EDAPTH       QSECOFR     BCI     0,0  PGM-EDAPTH       CNDW 
  HLISNK       QWEBQRYADM  BCI     0,0  PGM-HLISNK       SELW 
  JSCOM3C      QWEBQRYADM  BCI     0,0  PGM-JSCOM3C      TIMW
  QSQSRVR      QDIRSRV     PJ      0,0                   CNDW
  QSQSRVR      QDIRSRV     PJ      0,0                   CNDW
  TSCOM3       QSECOFR     BCI     0,0  PGM-TSCOM3       SELW 
  TSCOM3       QSECOFR     BCI     0,0  PGM-TSCOM3       SELW 
  TSCOM3       QSECOFR     BCI     0,0  PGM-TSCOM3       SELW 
  TSCOM3       QSECOFR     BCI     0,0  PGM-TSCOM3       SELW 

Abb. 1

  • QP0ZSPWP bzw. WQLWI7: Dieser Job ist der DB2 Web Query JVM (Java Virtual Machine) Thread. Aktueller Benutzer: QWEBQRYADM
  • WQLWI7: Diese dreifach gestarteten Jobs sind für die Integration des Anwendungsservers verantwortlich. Aktueller Benutzer: QTMHHTTP

Alle diese Jobs laufen im Subsystem QHTTPSVR (vgl. Abb. 2).

               Aktueller                                     
Subsystem/Job  Benutzer    Art   CPU %  Funktion        Status
QHTTPSVR       QSYS        SBS     0,0                   DEQW
WQLWI7         QTMHHTTP    BCH     0,0  PGM-QZHBMAIN     SIGW
WQLWI7         QTMHHTTP    BCI     0,0  PGM-QZSRLOG      SIGW
WQLWI7         QTMHHTTP    BCI     0,0  PGM-QZSRHTTP     SIGW
WQLWI7         QWEBQRYADM  BCI     0,0  JVM-com.ibm.lw   THDW

Abb. 2

Weitere Informationen übe die Laufzeitumgebung finden Sie im IFS unter:
/QIBM/UserData/webquery/ibi/srv76/wfs/edaprint.log

Die Architektur von DB2 Web Query

DB2 Web Query läuft native auf dem System i. Es besteht aus mehreren Schichten und Komponenten:

  • Web-Teil mit einem HTTP-Server und einem Anwendungsserver
  • HTTP-Clients
  • Berichts-Server
  • Daten-Adapter
  • Daten des Relationalen Datenbank Management Systems (RDBMS)

An Stelle der DB2 UDB i5/OS können auch andere Datenbanken eingesetzt werden. Die Firma Informations Builders stellt dazu zahlreiche Adapter zur Verfügung (vgl. Abb. 3).

Abb. 3: Datenbank-Adapter

Zum besseren Verständnis schauen wir uns den Ablauf einer Berichts-Anforderung an:

  • ein Benutzer fordert die Ausführung eines Berichtes über einen Web-Browser an
  • der Web-Server empfängt die Anforderung, bearbeitet die entsprechenden Parameter und leitet das Ergebnis über das DB2 Web Query Servlet an den Berichts-Server weiter
  • der Berichts-Server führt die Anforderung aus und leitet diese an den zugeordneten Daten-Adapter weiter
  • der Daten-Adapter generiert die entsprechende Datenbank-Anforderung und schickt diese an die DB2 Datenbank-Engine
  • der Berichts-Server empfängt die Ergebnismenge von der Datenbank, bereitet diese auf und schickt den formatierten Bericht an den Web-Server über das DB2 Web Query Servlet
  • der Web-Server schickt den Bericht an den Web-Browser zum Anzeigen

Wie bereits erwähnt, verwenden sowohl die Entwickler als auch die Anwender von DB2 Web Query einen Browser. Dieser kommuniziert über HTTP mit einem Anwendungsserver.

Die folgenden Browser werden unterstützt:

  • Internet Explorer ab Version 6.0
  • Mozilla Firefox a Version 1.5

Der HTTP-Server WQLWI7 ist verantwortlich für die Steuerung von ­HTML, CGI, GIF und anderen statischen Web Objekten. Die einzelnen Schichten des Servers sind im IFS im Unterverzeichnis /qibm/proddata/webquery/ibi/webfocus76 hinterlegt.

HotBackup Off
HostNameLookups Off        
UseCanonicalName On
KeepAlive Off
DocumentRoot /qibm/userdata/webquery/ibi/webfocus76/WQLWI7/htdocs
AddLanguage en .en
LogMaint logs/error_log 7 0
Listen *:11331   
<Location />
  order allow,deny
  allow from all
</Location>
LoadModule mod_ibm_lwi /QSYS.LIB/QHTTPSVR.LIB/QLWIIHSMOD.SRVPGM
LwiPluginConfig /qibm/userdata/webquery/ibi/webfocus76/WQLWI7/conf/lwi-plugin-cfg.xml
<LwiProfile WQLWI7>
  LwiAssignUserID QWEBQRYADM
  LwiAutostartOption StartEnd
  LwiStartJobQueue QHTTPSVR/QZHBHTTP HTTPWWW
</LwiProfile>

Abb. 4: Konfiguration HTTP-Server WQLWI7

Der Anwendungsserver mit demselben Namen WQLWI7 wie der HTTP-Server bildet den Mittelteil der Server-basierten Architektur. Er führt die Anforderungen der Web-Clients aus, die Java erfordern.

Der DB2 Web Query Anwendungsserver ist J2EE-kompatibel und unterstützt Servlets.

Der DB2 Web Query Berichts-Server ist eine in der Sprache C geschriebene Anwendung, die auf dem System i ausgeführt wird. Der Server steuert den Dateizugriff, führt die Geschäftslogik aus und erzeugt die aufbereitete Ausgabe. Er besteht aus der Berichts-Engine, dem Datenadapter Repository und dem Repository für Metadaten und Synonyme.

Ein Daten-Adapter ist ein Programm, welches DB2 Web Query den Zugriff auf die Datenquelle ermöglicht. Zur Erzeugung einer entsprechenden Anforderung an die Datenbank-Engine ist ein Daten-Adapter erforderlich.

Die Basisversion von DB2 Web Query enthält drei Daten-Adapter (siehe Abb. 5).

Adapter

Verwendeter Datentyp

System i Befehl

DB2 CLI

Dateien mit einer Teildatei, Alias, Stored Procedure oder MQT (Materialzed Query Tables)

CLI  API

DB2 Heritage File

Dateien, die aus mehreren Teildateien oder Satzformaten bestehen

OPNQRYF

Query/400

Objekte der Art  *QRYDFN, d.h. Abfragen von Query/400

RUNQRY

Abb. 5

Der erste Adapter DB2 CLI generiert entsprechende SQL-Anweisungen, die an die DB2 Datenbank-Engine geschickt werden. Diese SQL-Anweisungen verwenden die Möglichkeiten der Optimierung und die aktuellen Erweiterungen der SQL Query Engine (SQE).

Der Adapter DB2 Heritage File verwendet dagegen die alte Classic Query Engine.

Der Query/400-Adapter wird verwendet, um bestehende Query/400-Abfragen nach DB2 Web Query zu übernehmen.

Weitere Adapter können über Information Builders bezogen werden:
www.informationbuilders.com/products/webfocus/data_access.html

Vorschau für die nächste Folge

In der nächsten Folge werden wir die ersten Berichte mit DB2 Web Query erstellen. Erstaunlich ist dabei der Vergleich mit bereits bestehenden Query-Abfragen und deren Darstellung nach der Umsetzung nach DB2 Web Query.