TAA IsApi Extension

Die TAA ISAPI-Extension wird gebildet durch die DLL t2isa608.dll. Neuere Versionen der Infrastruktur werden einen neuen Namen erhalten. Für Abwärtskompatibilität wird eine sog. forwarding DLL ausgeliefert werden. Wahlweise kann man beim Betreiben des Web-Servers die bisherige Version der Infrastruktur beibehalten, oder eine neuere Version einrichten, bei der Anfragen für die ältere Infrastruktur auf die neuere DLL umgeleitet werden. Man beachte allerdings, dass die Nutzung von forwarding DLLs betriebssystembedingt dazu führt, dass es nicht reicht, den Dienst w3svc zu beenden um die TAA Infrastrukturkomponenten freizugeben, sondern dass in einem solchen Fall der iisadmin Dienst vollständig beendet werden muss.

Einrichten

Allgemein

Die ISAPI-Extension wird auf einen Web-Server mit Microsoft Internet Information Server (IIS) ab Release 4.0 installiert. Zunächst wird in IIS eine Web-Site eingerichtet, bspw. mittels des Microsoft Management Consoles (MMC):

Die neue Web-Site muss dabei Ausführungsberechtigung besitzen:

Falls sämtliche ISAPI Anfragen über Pfaderweiterungen als Skript-Anfrage simuliert werden (siehe weiter unten), reicht die Berechtigung für einfache Skript-Ausführung. In einem Unterverzeichnis für die Web-Site werden folgende Komponenten der TAA-Infrastruktur abgelegt:

  • TeamWiSE.IsapiExtension.dll
  • TeamWiSE.Runtimecore.dll (Redist-Fassung)
  • t2ctv60.dll
  • t2srv70.dll
  • t2srv.exe
  • psapi.dll

Falls die ISAPI Extension ausschließlich über Pfaderweiterungen von virtuellen Skripts angestoßen werden soll (empfohlen), kann die Extension in einem beliebigen Verzeichnis abgelegt werden, und braucht nicht in einem (Unter)Verzeichnis der tatsächlichen Web-Site aufzufinden zu sein. Sollte die Extension in einem Unterverzeichnis der Web-Site abgelegt werden, kann man dieses Verzeichnis für Zugriffe von außen sperren. Es besteht dann auch nicht die Möglichkeit, einen Download der vorher aufgelisteten Komponenten auszuführen, was in den meisten Fällen auch nicht zugelassen werden sollte.

Je nach Umgebungsbedingungen können weitere DLLs notwendig sein; dies wäre mit dem TAA Administrator zu klären. Man beachte bei der Konfiguration, dass normalerweise der IIS nicht auf Netzwerkressourcen zugreifen kann, noch sollte. Die Komponenten t2ctv60.dll und t2srv60.dll müssen auf dem Web-Server registriert werden (bspw. mittels regsvr32).

Sorgen Sie dafür, dass die Website so konfiguriert ist, dass ISAPI Anwendungen zwischengespeichert werden. Falls die ISAPI-Extension über Pfaderweiterungen als Skript-Anfrage angesteuert werden soll (empfohlen) müssen folgende Extensions als Skript-Extension hinzugefügt und mit der ISAPI DLL verbunden werden:

  • .trf (GET, POST) - Für Schlüsseltabellen in XML-Format
  • .dst (GET) - Für Datenstrukturen (BLOB)
  • .ost (GET) - Für Datenstrukturen zu einem Objekttyp (BLOB)
  • .stb (GET) - Für Datenstrukturen zu einer Schlüsseltabelle (BLOB)
  • .jcl (GET, POST) - Für Bausteinaufrufe (BLOB).
  • .trb (GET, POST) - Für Schlüsseltabellen (BLOB).
  • .cnd (GET) - Für Meldungstexte zu Conditions (BLOB). (ab 7.00)
  • .ntr (GET) - Für Modulschnittstellenbeschreibung zu taaEnter (BLOB). (ab 7.00)
  • …. - weitere können folgen

Man beachte, dass 1) grundsätzlich auch das HTTP-Verb HEAD zugelassen werden kann, und für die Wf-XML Nutzung zugelassen werden sollte.

Abb. 1: Beispiel Eintragungen für Skript Extensions (IIS 5.0)

Die notwendigen Ressourcen-DLLs werden vorzugsweise in einem getrennten Unterverzeichnis abgelegt. Mindestens die Ressourcen-DLL twzz608.dlx muss hier abgelegt sein. Auch hier muss der TAA Administrator Hilfestellung leisten, um weitere Ressourcen-DLLs, sowie Anwendungskomponenten zu identifizieren, die hier abgelegt werden müssen. Ggf. bietet es sich auch an, pro Anwendung getrennte Unterverzeichnisse zu erstellen. Man beachte, dass die Pfade für die Ressourcen-DLLs und Anwendungskomponenten mittels der Registry-Einstellung ComponentPath in den jeweiligen Abschnitten der TAA Registry vorgenommen werden müssen.

Abb. 2: Beispiel Verzeichnisstruktur Web-Server (Rel. 6.05)

Installieren Sie die TAA Dienste mittels dem Befehl t2srvc /install. Sorgen Sie dafür, dass die Dienste (mindestens t2base, ggf. t2ibc, t2trace und/oder t2req) entweder manuell gestartet werden, bevor die ersten Anforderungen an die Web-Site gestellt werden, oder konfigurieren Sie den Dienst t2base für automatischen Start.

Zum Schluss müssen noch einige Basis-Einstellungen in der Registry vorgenommen werden; auch hier soll ein TAA Administrator eingebunden werden. Man beachte dabei, dass der Web-Server, mangels authentifizierter Benutzeranmeldung, keinen HKEY_CURRENT_USER referenzieren kann, sondern auf die HKEY_LOCAL_MACHINE angewiesen ist. Besondere Beachtung sollte auch dem Eintrag ActAsService im Config Abschnitt gewidmet werden. Dieser Eintrag soll auf einem Web-Server den Wert „1“ (eins) aufweisen.

Spezifische Registry-Einstellungen für die TAA IsApi Extension

Einige Einstellungen können spezifisch für die TAA ISAPI Extension in der Registry vorgenommen werden. Diese Einstellungen werden benötigt, bevor die ISAPI-Extension die TAA Infrastruktur instanziert, und werden deswegen nicht mittels der üblichen Suchwege aus unterschiedlichen Registry Bäumen zusammengestellt. Einige Einträge können aus Bootstrap-Gründen nur umgebungsübergreifend im Config Abschnitt der TAA Registry vorgenommen werden, d.h. unter HKEY_LOCAL_MACHINE\Software\TAA\Config. Solche Einträge sind nachfolgend mit „(nur Config)“ vermerkt.

isaEnterOptionsDispatcher (string)
isaEnterOptionsWorker (string)
isaEnterOptionsDstr (string)
isaEnterOptionsJcal (string)
isaEnterOptionsWfXML_Cpi (string)
isaEnterOptionsModl (string)
SSLOnly_<cmd> (boolean)
SpecificResponseOnError (boolean)
HttpHeader_SessionID (string - in Company, nicht in Config)

Diese Einstellungen müssen noch näher dokumentiert werden. Bis dahin können Rückfragen direkt an die Entwickler gerichtet werden.

ContextXSLPathIn (string)
ContextXSLPathOut (string)

Default für beide = „“

Wenn Anfragen über Wf-XML 1.0 eintreffen, wird mit dem hier angegebenen Basispfad versucht, ein XSL-Stylesheet oder XSL-Transformationsskript zu finden, um die eingehenden Daten (ContextData) und/oder ausgehenden Daten (ResultData) zu transformieren. Ist der entsprechenden Registry Eintrag leer oder nicht gesetzt, so wird (kommentarlos) nicht versucht, die Daten zu konvertieren.

Für eine CreateProcessInstance Anfrage wird ein Pfad für das XSL wie folgt erstellt:

  • ContextData: <ContextXSLPathIn><Anwendung>/<Baustein>/<Ereignis>-i.xsl
  • ResultData: <ContextXSLPathOut><Anwendung>/<Baustein>/<Ereignis>-o.xsl

Man beachte, dass die Anwendung direkt am jeweiligen Registry Eintrag angehängt wird. Somit kann durch das Anhängen oder Weglassen des Schrägstriches in der Registry weiteren Einfluss auf die Gestaltung des Pfades genommen werden.

IsaDebug (binary)
Default = False

Der Wert dieser Einstellung bestimmt, ob die ISAPI-Extension eine Auskunftsmitteilung (Auftrag ?info&…) oder eine Fehlernachricht mit zusätzlichen Verbindungsinformation versorgen soll.

PoolThreads (dword) (nur Config)
Default = 10

Die eingehenden Aufträge werden von der ISAPI-Extension in einer Auftragsschlange eingestellt. Aus dieser Auftragsschlange laden die tatsächlichen Worker Threads jeweils einen Auftrag, und führen diesen aus. Der Eintrag PoolThreads bestimmt, wie viele solche Worker Threads vorzusehen sind, und somit auf dem Web-Server gleichzeitig aktiv sein dürfen. Wenn dieser Eintrag den Wert 0 besitzt, wird stattdessen der Defaultwert (10) benutzt.

Man beachte, dass bei Ausführung bestimmter Aufgaben vom Worker Thread aus Sicherheitsgründen ein weiterer Thread gestartet werden kann. Das erhöht zwar die Anzahl Threads, nicht jedoch die Anzahl gleichzeitig aktiver Threads, da der Worker Thread in diesem Fall deaktiviert wird, und auf Fertigstellung des Auftrages in dem separat gestarteten Thread wartet.

WorkQueue (dword) (nur Config)
Default = 200

Die eingehenden Aufträge werden von der ISAPI-Extension in einer Auftragsschlange eingestellt. Aus dieser Auftragsschlange laden die tatsächlichen Worker Threads jeweils einen Auftrag, und führen diesen aus. Einen Auftrag bleibt solange in der Schlange, bis ein Worker Thread verfügbar ist, um den Auftrag abzuarbeiten. Die Aufträge werden in Eingangsreihenfolge abgearbeitet. Der Eintrag WorkQueue bestimmt, wie viele Aufträge maximal in der Warteschlange verbleiben dürfen. Wenn die Warteschlange voll ist, und dennoch weitere Aufträge gestellt werden, werden diese Aufträge nicht in der Warteschlange gestellt, sondern auf dem jeweiligen IIS Thread ausgeführt. Wenn dieser Eintrag den Wert 0 besitzt, wird stattdessen der Defaultwert (10) benutzt. Da auch aktive Aufträge bis zur vollständigen Abarbeitung in der Warteschlange verbleiben, muss die WorkQueue Angabe mindestens so groß sein, wie die PoolThreads Angabe. Sollte das nicht der Fall sein, korrigiert die ISAPI-Extension diesen Wert intern.

ThreadAlive (dword) (nur Config)
Default = 60 Sekunden

Ein Worker Thread meldet sich zur Ausführung der Aufträge bei der TAA-Infrastruktur an. Wenn der Auftrag erledigt ist, kann der Worker Thread sich wieder abmelden. Die Abmeldung geschieht allerdings nicht sofort, sondern erst nach einer gewissen Wartezeit, der mittels der Angabe ThreadAlive in Millisekunden festgelegt werden kann. Einen Wert von 0 Millisekunden bedeutet allerdings, dass ein Worker Thread sich nie mehr bei der TAA-Infrastruktur abmelden soll. Wenn innerhalb der Timeout-Periode ein weiterer Auftrag vom Worker Thread aufgegriffen werden kann, erspart sich der Worker Thread eine erneute Anmeldung bei der TAA-Infrastruktur, und setzt die Bearbeitung des neuen Auftrages mit der bisherigen Anmeldung fort.

AsyncMinFileSize (dword)
Default = 1.400

Die ISAPI-Extension liefert die Response im Normalfall nach Fertigstellung der jeweiligen Anfrage asynchron an den Client. Entgegen der expliziten Empfehlung von Microsoft, in der diese Technik als optimal dargestellt wird, scheint es in der Praxis bei kleineren Response-Daten effizienter zu sein, diese Daten synchron als Bestandteil der Ausführung der Anfrage dem Client zu liefern. Mit dieser Einstellung kann der Grenzwert für die Größe der Response gesetzt werden. All Responses, die kleiner als dieser Grenzwert sind, werden synchron, die übrigen asynchron geliefert. Eine Einstellung mit der Angabe 0 bewirkt, dass sämtliche Responses asynchron geliefert werden. Eine Angabe -1 bewirkt, dass sämtliche Responses synchron geliefert werden. MaxAgeDstr (dword)
Default = 720 (12 Stunden)

Wenn Datenstrukturen vom Client geladen werden, werden diese mit einer HTTP-Header-Angabe max-age versehen. Gemäss HTTP-Spezifikationen soll der Client innerhalb dieser Zeit das Ergebnis als gültig betrachten, und nicht versuchen, diese erneut vom Server zu besorgen. Der Wert für diese Einstellung in der Registry wird in Minuten angegeben. Einen Wert 0 in der Registry bewirkt, dass die Datenstrukturen immer neu vom Server besorgt werden. Dies wird bewirkt durch die Ergänzung des HTTP-Headers in der Response um die Angaben

  Pragma: no-cache
  Cache-Control: no-cache must-revalidate

MaxAgeTref (dword)
Default = 720 (12 Stunden)

Wenn Schlüsseltabellen vom Client geladen werden, werden diese mit einer HTTP-Header-Angabe max-age versehen. Gemäss HTTP-Spezifikationen soll der Client innerhalb dieser Zeit das Ergebnis als gültig betrachten, und nicht versuchen, diese erneut vom Server zu besorgen. Der Wert für diese Einstellung in der Registry wird in Minuten angegeben. Einen Wert 0 in der Registry bewirkt, dass die Schlüsseltabellen immer neu vom Server besorgt werden. Dies wird bewirkt durch die Ergänzung des HTTP-Headers in der Response um die Angaben

  Pragma: no-cache
  Cache-Control: no-cache must-revalidate

Man beachte, dass nur im Falle der Benutzung der GET-Methode seitens des Clients diese Einstellung eine Auswirkung hat.

Beispiel einiger Registry-Einstellungen

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA]
@="Technical Application Architecture - User Settings"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Appl]
@="Application specifics"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Appl\TAA]
@="TAA Komponenten"
"Abbrev"="zz"
"Version"="608"
"ComponentPath"="c:\\taa\\ress"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Appl\TAA\Company]
@="TeamWiSE GmbH"
"Abbrev"="tw"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Appl\Test]
@="Test-Anwendung"
"Abbrev"="st"
"Version"="100"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Appl\Test\Company]
@=""
"Abbrev"="HG"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Appl\VO]
@="Geschäftsvorfall-Verwaltungssystem"
"Abbrev"="VO"
"Version"="007"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Appl\ZENTKO]
@="Zentrale TAA-Komponenten"
"Abbrev"="ZK"
"Version"="012"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Company]
@="Company settings"
"Abbrev"="AL"
"UsePipeComm"=dword:00000001
"DbTsAsChar"=hex:01
"AllowUnconfirmedUser"=hex:00
"CtvSgpvVersandart"="VSAN-ART-K"
"CtvSgpvVersandweg"="VWEG-K"
"iXOSArchive"=hex:00

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Config]
"ComponentPath"="c:\\taa\\ress"
"EditEnv"=hex:00
"DebugAllowed"=hex:00
"SearchOrder"=dword:00000000
"CndGrpVal"="ZZTAAVAL"
"WarnLevel"=dword:00000001
"Server"="c:\\taa\\bin\\TaaSrvc.Exe"
"AddOnApps"="ZENTKO;TAA"
"InfoLevel"=dword:00000000
"ECIDllName"="almwecic.dll"
"ECIEntryName"="_ECICall@8"
"GevesLogFile"="c:\\taa\\log\\taagevs.htm"
"WriteGevesLog"=dword:00000000
"NotImplMsg"=hex:01
"DumpsAllowed"=hex:00
"EndUser"=hex:00
"GevoYieldIsCleanup"=hex:00
"KontextDB"="ctxdb"
"KontextTabelle"="ctx"
"TaaTraceHostName"=""
"EnvSpec"="ALPROD"
"ODBCDataSourceOETab"="altest"
"ODBCTableNameOETab"="TVOSOE"
"ODBCTableNameGeVoStates"="TVOGST"
"ODBCTableNameVorgStates"="TVOVST"
"IgnoreWorkflow"=hex:00
"CtvDB"="ctxdb"
"CtvTabelle"="TCTCTE"
"Profiling"=hex:00
"LogFile"="c:\\taa\\log\\taaoops.htm"
"CtvPrintQueue"=""
"EciTransactionRouting"=""
"DebugFledge"=dword:00000000
"bGevTransactional"="0"
"EciCompress"="1"
"EciDebugSkipTransaction"=""
"TpDialogPath"=""
"EciClientWarningLevel"="0"
"EciServerWarningLevel"="0"
"EciOopsLogFile"="C:\\taa\\log\\EciOops.htm"
"EciTimeLogFile"="C:\\taa\\log\\EciTime.htm"
"MQIDllName"="ALmqi100.dll"
"MQIFreeProc"="MQIMFREE"
"MQISendProc"="MQIC2S"
"MQIRecvProc"="MQIS2C"
"MQIAuftrag"="TAA"
"MQIAuftragstyp"="LEVERT"
"MQIAuftragsmanager"="alamdstu.dll"
"MQIEntryName"="_ALAMDSTU@4"
"MqiClientWarningLevel"="0"
"MqiLogging"="1"
"MQIFehlerklasse"="ERROR"
"MQIFehlername"="TAA-ERROR"
"TimestampOffset"="0000-00-00-00.00.00.000000"
"RefDB"="altest"
"CtvType"="normal"
"bCtxBlobCompressed"="1"
"bEciReentrant"="1"
"CtvViewer"=""
"TonInitDllName*"="t2gev608.dll"
"TonInitEntryName*"="gevInitHook"
"SQLBlob"="-4"
"ActAsService"=hex:01
"IsaDebug"=hex:00
"ThreadAlive"=dword:00124f80
"ContextXSLPathIn"="c:/taa/ctx_xsl/"
"ContextXSLPathOut"="c:/taa/ctx_xsl/"

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Env]

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\Env\ALPROD]

Technische Funktionsweise

An dieser Stelle erscheint in Zukunft eine technische Spezifikation der genauen Abläufe bei der Kommunikation zwischen einem Client und der TAA ISAPI Extension.

1)
ab der Version 7.01
faq:allg:isapi · Zuletzt geändert: 02.09.2021 14:56

Copyright © 1992-2024 TeamWiSE Gesellschaft für Softwaretechnik mbH         Adressen |  Kontakt |  AGB |  Datenschutzerklärung |  Impressum