Implementierungstyp HTTP

Analyse der ISPC-Angaben

Bei der Ausführung eines TAA-Bausteins mit dem Implementierungstyp (ityp) http wird vom Proxy zunächst die Implementierungsspezifikation (ispc) analysiert. Die ispc besteht aus bis zu 7 Angaben, die mit Semikolons voneinander getrennt sind. Die Angaben beschreiben

  1. Die Basis-URL und ggf. Portnummer, bspw. www.teamwise.de oder wfngen.bkend.com:4366.
  2. Das zu adressierende Dokument auf dem Zielserver, z.B. /wflow/testdok.cpi. In dieser Angabe können Kürzel für zur Laufzeit zu ersetzende Angaben benutzt werden.
  3. reserviert
  4. reserviert
  5. Sogenannte Flags, die spezielle Behandlungen für die Ausführung beinhalten.
  6. Die Benutzerkennung, die für die Kommunikation mit diesem Baustein gelten soll.
  7. Das Kennwort, das zu der jeweiligen Benutzerkennung gelten soll. Das Kennwort ist nach TAA-Verfahren verschlüsselt.

Kürzel

Folgende Kürzel in der Angabe des zu adressierenden Dokuments auf dem Zielserver werden erkannt und ersetzt:

  • %a: Anwendung des zu rufenden Bausteins
  • %n: Name des zu rufenden Bausteins
  • %e: das auszulösende Ereignis
  • %v: Anwendungsversion des zu rufenden Bausteins

So wird die Eintragung /wfltest/%a/%n_%e.cpi bei Aufruf des Bausteins MODL in der Anwendung APPL mit dem Ereignis EVNT umgesetzt in /wfltest/APPL/MODL_EVNT.cpi.

Flags

Zur Zeit werden folgende Angaben unterstützt:

  • S: benutze immer SSL für die Kommunikation mit diesem Baustein, auch wenn der Proxy dies nicht für notwendig halten sollte.
  • B: benutze nie SSL für die Kommunikation mit diesem Baustein, auch wenn der Proxy dies für notwendig halten sollte.
  • C: komprimiere die zu sendenden Daten. Man beachte, dass dieser Flag derzeit immer als gesetzt betrachtet wird. Die Daten bei Nutzung von http werden immer komprimiert.

Wenn die Schnittstelle des Bausteins keine Objekte beinhaltet, die durch den Aufruf verändert werden, erfolgt die Ausführung asynchron ohne Response. Allerdings lässt sich dieses Verhalten durch folgende Flags beeinflussen:

  • A: erwarte keine Rückkehrdaten, auch wenn einzelne Schnittstellenobjekte die Rolle MOD oder CRE besitzen. Ein Aufruf dieses Bausteins wird hiermit grundsätzlich asynchron.
  • W: warte auf Rückkehrdaten (Zustand), auch wenn kein Schnittstellenobjekt verändert wird. Ein Aufruf des Bausteins wird hiermit grundsätzlich synchron.

Man beachte, dass diese Asynchronität nichts mit der Funktionalität des Spawn/WaitFor-Verfahrens zu tun hat.

Normalerweise wird Schriftgut ignoriert. Für ityp http gibt es aber die Möglichkeit, auch Schriftgut zu transferieren1). Hierzu muss der folgende Flag verwendet werden:

  • R: gibt an, dass Schriftgut, welches auf dem Server erstellt wird, zurückübertragen und an die CTV Engine hinzugefügt werden soll.

Beispiel

wfngen.teamwise.de:3655;/wwwflow/%a/%n/%e.cpi;;;B;wfuser;a86e3c728a26c02b

Hier wird die Kommunikation mit dem Server wfngen.teamwise.de über den HTTP-Port 3655 aufgebaut. Obwohl eine Benutzerkennung und ein Passwort angegeben ist, wird die Verbindung nicht über SSL, sondern unverschlüsselt aufgebaut, weil dies in der ISPC explizit verlangt wurde. Der Proxy ersetzt die Kürzel für das Zieldokument, wendet kein Stylesheet auf den TAA-formatierten XML an, und versucht das kreierte Dokument mit der Benutzerkennung wfuser und dem Kennwort ??? (entschlüsselter a86e3c728a26c02b) anzusprechen. Die Rückantwort des Servers wird genommen, wie sie ist, da auch für das Ergebnisdokument kein Stylesheet angegeben wurde.

Falls die ISPC keine Vorgaben zur Nutzung von SSL macht, werden die Proxies immer dann SSL benutzen, wenn sich zur Laufzeit herausstellt, dass ein Kennwort mit dem Zielserver ausgetauscht werden muss. Nur die Übertragung einer Benutzerkennung wird noch nicht als Auslöser für eine SSL-Verbindung betrachtet.

Authentifizierung

Falls eine Authentifizierung benötigt oder explizit verlangt wird, so wird dies vom Proxy erkannt und behandelt, und wird die Verbindung zum Ziel-URL ggf. per SSL aufgebaut. Bei der Analyse der für die Authentifizierung benötigten Angaben geht der Proxy nach den hier unten beschriebenen Schritten vor.

Analyse der GeVo-Eigenschaften

Falls die ISPC keine Angaben zur Benutzerkennung und Kennwort beinhaltet, werden die Proxies die GeVo-Eigenschaften nach einer passenden Benutzerkennung und passendem Kennwort durchsuchen. Dazu wird zunächst versucht, eine Benutzerkennung unter der GeVo-Eigenschaft <Http>/<Server>/UserID zu finden. Für das obige ISPC-Beispiel würde der Proxy also versuchen, eine GeVo-Eigenschaft mit dem Namen Http/wfngen.teamwise.de/UserID zu finden. Falls eine solche GeVo-Eigenschaft gefunden wird, wird auch versucht, das dazu passende Kennwort in der Eigenschaft Http/<Server>/Password zu finden. Dieses Kennwort kann leer sein. Wenn nicht, muss es gemäß der TAA-Verschlüsselung abgelegt worden sein. Wenn das Kennwort nicht leer ist, wird die Kommunikation mit dem Zielserver über SSL erzwungen, es sei denn, die ISPC hat dies explizit unterbunden.

Falls für den konkreten Zielserver keine passende GeVo-Eigenschaft gefunden werden kann, wird vom Proxy versucht, eine GeVo-Eigenschaft <Http>/UserID zu finden, die als Standard für alle Zielserver verwendet werden kann. Wird in dieser GeVo-Eigenschaft eine Benutzerkennung gefunden, wird ein dazugehöriges (verschlüsseltes) Kennwort in <Http>/Password gesucht.

Analyse der früheren Verbindungen und Vorgaben

Falls weder die ISPC, noch die GeVo-Eigenschaften eine Benutzerkennung/Kennwort liefern, wird vom Proxy untersucht, ob eine frühere oder eine vorkonfigurierte Kombination für Benutzerkennung/Kennwort in der Registry abgelegt wurde. Dazu wird zunächst gemäß Standard TAA Konventionen der Abschnitt Http in den TAA-Registry Bäumen nach einem Schlüssel mit dem Namen des Zielservers gesucht. Wenn vorhanden, wird in diesem Schlüssel eine Zeichenfolge UserID gesucht. Falls vorhanden und nicht leer, wird ebenfalls einen Binäreintrag Password gesucht und nach TAA Verfahren entschlüsselt.

Analyse des HTTP-Statuscodes

Falls die Kommunikation mit dem Zielserver Fehler liefert, entweder mit einer konkret ermittelten Benutzerkennung und Kennwort oder mangels einer solchen Kombination, wird analysiert, ob der Fehler mit der Authentifizierung zusammenhängt. Wenn das der Fall ist, wird, falls die GeVo-Einstellungen dies zulassen, seitens des Proxies ein Dialog gezeigt, in dem die Authentifizierungsangeben korrigiert oder vervollständigt werden können.

Dieser Dialog erscheint immer wieder, bis entweder die Authentifizierung erfolgreich war, oder die Kennworteingabe mit Abbrechen verlassen wird. Im Dialog besteht die Möglichkeit, die gemachten Angaben in der TAA Registry abzulegen, damit zu diesem Zielserver in Zukunft diese Angaben versucht werden, bevor ein Dialog hoch kommt. Die in der Registry gespeicherten Angaben (mit verschlüsseltem Kennwort) können auch für Zwecke der Softwareverteilung exportiert und auf anderen Rechnern in die Registry importiert werden.

1)
ab 9.03
faq:allg:http · Zuletzt geändert: 02.09.2021 14:47

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