Zum Hauptinhalt springen

Web-Schnittstelle - c16_web.cfg

Web-Schnittstelle - c16_web.cfg Inhalt der Datei c16_web.cfg

In der Datei steht am Anfang ein allgemeiner Bereich, in dem Informationen für den gesamten Client abgelegt werden. Für jede Applikation wird danach ein eigener Bereich eingetragen. Einträge die mit einem * markiert sind, müssen in der Datei vorhanden sein. Eine mögliche Konfiguration befindet sich in der Beispiel-Datei .

Einträge im allgemeinen Bereich

Einträge im Applikationsbereich

Einträge im allgemeinen Bereich

web_max_connections *

Die maximale Anzahl aller Web-Benutzer des Clients können in diesem Eintrag angegeben werden. Will sich ein weiterer Benutzer anmelden, wird zunächst versucht, einen vorhandenen Web-Benutzer abzumelden, der über einen längeren Zeitraum keine Anfragen an den Client gestellt hat. Welcher Benutzer entfernt wird, ist beim Eintrag web_min_timeout_s beschrieben. Kann kein Web-Benutzer entfernt werden, wird ein entsprechender Fehler an den Browser zurückgeliefert. Dieses Limit ist nicht applikationsspezifisch und dient der Beschränkung des Verbrauchs an Systemressourcen durch den Client.

In dieser Einstellung können Werte von 5 bis 100000 angegeben werden.

web_max_sessions *

In diesem Eintrag wird festgelegt, wie viele Sessions von einer einzelnen Browser-IP-Adresse aus gleichzeitig möglich sind. Auf diese Weise kann nur eine beschränkte Anzahl von Browser-Sessions von einem Rechner aus auf den Client zugreifen.

Diese Beschränkung besteht ebenfalls, wenn über einen Proxy-Server auf den Client zugegriffen wird. Alle Anwender aus dem Netz, das durch den Proxy vertreten wird, melden sich mit der gleichen IP-Adresse (die des Proxy) beim Client an. Damit wird dann die Anzahl der Sessions aus einem Netz beschränkt.

Wird web_max_sessions mit 0 angegeben, findet keine Beschränkung der Sessions statt. Es können maximal 10000 Sessions zugelassen werden. Eine Einschränkung ist sinnvoll, um Denial-of-service-Attacken mittels Session-Overflow zu verhindern. Ein empfohlener Wert ist 20.

web_max_timeout_s *

Ein Web-Benutzer wird vom Client entfernt, wenn er nach der hier eingestellten Anzahl von Sekunden keine Anfrage mehr gestellt hat. Ist web_max_timeout_s auf 900 Sekunden gesetzt, wird ein Web-Benutzer, der 15 Minuten keine Anfrage mehr gestellt hat, vom Client abgemeldet. Die ID des Web-Benutzers ist danach nicht mehr gültig.

Die Einstellung kann zwischen 120 und 10800 Sekunden (oder zwischen 2 Minuten und 3 Stunden) gewählt werden. Der Wert sollte kleiner sein als der Wert, der in der Einstellung c16_timeout_s angegeben ist.

info

Bei der Angabe von Zeiten können entweder die Anzahl der Sekunden angegeben werden oder eine Zeitangabe in der Form [hh.]mm.ss.

web_min_timeout_s *

Hier wird eingestellt, wie viele Sekunden ein Web-Benutzer mindestens keine Anfrage mehr an den Client gestellt hat, um bei Bedarf entfernt werden zu können. Diese Einstellung wird erst dann benötigt, wenn die in web_max_connections eingestellte Anzahl von Web-Benutzern erreicht ist und sich ein weiterer Web-Benutzer anmelden möchte.

Zu diesem Zeitpunkt wird ein Web-Benutzer gesucht, der über einen Zeitraum von mehr als den hier eingestellten Sekunden keine Anfrage mehr gestellt hat. Werden mehrere Web-Benutzer gefunden, die diese Bedingung erfüllen, wird der Web-Benutzer entfernt, der am längsten keine Anfrage mehr gestellt hat.

Beispiel:

Im Client sind 200 Web-Benutzer registriert, was genau der Eintragung in web_max_connections entspricht. 198 dieser Benutzer stellen in kurzen Zeitabständen (weniger als web_min_timeout_s Sekunden) Anforderungen an die Datenbank. Der Web-Benutzer A hat seit 600 Sekunden, der Web-Benutzer B seit 450 Sekunden keine Anforderung gestellt. Soll jetzt ein weiterer Web-Benutzer angemeldet werden, wird der Web-Benutzer A entfernt, sofern web_min_timeout_s kleiner als 600 Sekunden ist.

Die Einstellung kann zwischen 120 und 1800 Sekunden (oder zwischen 2.00 und 30.00) gewählt werden.

web_req_timeout_s

Es wird immer nur ein Request eines Web-Benutzers auf einmal verarbeitet. Da der Browser asynchron zum Web-Server arbeitet, können von einem Browser mehrere Requests an den Server gesendet werden, bevor die Antwort auf den ersten Request zurückgeliefert worden ist. Beispielsweise kann während der Bearbeitung eines Requests der Benutzer in seinem Browser einen weiteren Link anklicken. Dieser zusätzliche Request wird im Client in einen Wartezustand versetzt und erst dann verarbeitet, wenn der erste Request beendet wurde. Jeder weitere Request ersetzt den Request im Wartezustand. Es steht also höchstens ein weiterer Request in der Warteschlange. Der Request wird aus der Warteschlange entfernt, wenn er innerhalb der angegebenen Zeit (in Sekunden) nicht bearbeitet werden kann.

Es kann eine Wartezeit von 5 bis 600 Sekunden eingestellt werden. Befindet sich kein Eintrag in der Konfigurationsdatei, werden 10 Sekunden angenommen.

Einträge im Applikationsbereich

info

Ein Applikationsbereich wird in der Konfigurationsdatei mit dem Namen der Applikation in eckigen Klammern ([...]) eingeleitet.

web_root_path *

Hier wird ein Verzeichnis auf der Festplatte des Web-Servers angegeben. Das Verzeichnis kann über den Prozedurbefehl WseInfo(_WseInfoRootPath) ermittelt werden. Alle Angaben in der Applikation mit Bezug auf eine externe Datei können relativ zu diesem Eintrag definiert werden. Durch dieses Vorgehen kann eine leichtere Übertragbarkeit auf andere Serverrechner erreicht werden. Es können bis zu 127 Zeichen angegeben werden.

web_root_path = c:\inetpub\wwwroot

web_error_path *

Tritt ein Fehler auf, der nicht von der Request-Funktion verarbeitet werden kann, wird eine HTML-Seite aus dem hier angegebenen Verzeichnis angezeigt. Das Verzeichnis kann bis zu 127 Zeichen lang sein.

web_error_path = c:\inetpub\wwwroot\error

Der Aufruf von Fehlerseiten ist im Abschnitt Rückgabe von Fehlerseiten beschrieben.

web_log_path

In der Log-Datei werden Ereignisse der Applikation protokolliert. Die Datei wird in dem hier angegebenen Verzeichnis angelegt. Es können maximal 127 Zeichen angegeben werden. Für jeden Tag wird eine eigene Datei generiert. Ist diese Eigenschaft nicht gesetzt, wird im Verzeichnis, in dem auch die Datei c16_web.DLL abgelegt ist, eine Datei mit dem Namen <Applikation>.<Datum>.LOG angelegt. Der Applikationsname ist in eckigen Klammern ([...]) in der Konfigurationsdatei angegeben. Das Datum wird dabei im Format JJJJMMTT angegeben.

web_log_path = c:\c16\web

web_module_path *

In diesem Eintrag werden das Verzeichnis und der Name des Clients angegeben. Die Angabe ist relativ zu web_root_path . Das Verzeichnis kann über den Prozedurbefehl WseInfo(_WseInfoModulePath) ermittelt und zusammen mit der Eintragung in web_root_path zur Generierung von URL’s verwendet werden.

web_module_path = /scripts/c16_web.dll

web_url_id *

In diesem Eintrag wird ein Hostname angegeben, mit dem diese Applikation identifiziert werden kann. Hier muss der Hostname der Site angegeben werden, unter dem die Applikation erreichbar ist. Der Hostname wird im Header jedes Browser-Request übergeben. Dabei kann es sich um einen Namen oder eine IP-Adresse handeln. Mehrere Namen können durch ; voneinander getrennt angegeben werden, damit kann die Applikation dann durch verschiedene Hostnamen angesprochen werden. Es können maximal 255 Zeichen angegeben werden.

Ist beim Web-Server ein anderer Port als der Standardport (80) angegeben, kann im ersten Eintrag die Portnummer mit angegeben werden.

web_url_id = shop.vectorsoft.de:8080;appl;62.132.119.100

web_app_id

Sind mehrere Applikationen unter demselben Hostnamen erreichbar, wird über diese Applikations-ID die Applikation identifiziert. Die ID kann bis zu 30 Zeichen lang sein. Der hier eingetragene Wert muss im Query-String als Argument übergeben werden:

http://www.vectorsoft.de/scripts/c16_web.dll?C16APP=kunden

Der Name des Rechners wird der Einstellung web_url_id , der Pfad des Clients wird dem Eintrag web_module_path entnommen.

Erhält der Client eine URL in dieser Form, wird aufgrund von C16APP die Applikation identifiziert und deren Request-Funktion ( c16_proc_request ) aufgerufen. Beim ersten Aufruf können bereits weitere Argumente übergeben werden, die von der Request-Funktion ausgewertet werden können. Die Angabe von C16APP ist nur dann erforderlich, wenn noch keine Benutzer-ID verfügbar ist.

web_uid_mode

Die Benutzer-ID des Web-Benutzers wird grundsätzlich in der URL mit angegeben (Cookies werden nicht verwendet). Dabei wird die ID normalerweise in den Pfad integriert:

http://www.vectorsoft.de/scripts/c16_web.dll/C16UID....?...

Mit der Angabe von web_uid_mode = query wird die ID dagegen in den Query-String übernommen:

http://www.vectorsoft.de/scripts/c16_web.dll?C16UID=...&...

Die Angabe von web_uid_mode = path entspricht der Standardeinstellung. Die Pfadmethode ist vorzuziehen, da sonst die Benutzer-ID immer ein Argument des Query-Strings darstellt und dies bei Argumentabfragen mittels WseArg() berücksichtigt werden muss.

info

Die Angabe der Web-Benutzer-ID im Pfad ist nur ab IIS Version 4.0 möglich. Bei der Verwendung des IIS Version 3.0 muss web_uid_mode auf query gesetzt werden.

c16_server *

In diesem Eintrag werden das Protokoll und der Name des Servers angegeben, auf dem die Anwendungs-Datenbank geöffnet werden soll. Die Angabe erfolgt nach dem Schema TCP:<Name des Servers>. "TCP" steht dabei für das unterstützte Protokoll TCP/IP.

Als Name des Servers kann entweder die IP-Adresse des Rechners, auf dem der CONZEPT 16-Server läuft, oder dessen Name, angegeben werden. Bei der Verwendung des Namens muss ein Domain Name Service im System installiert und der entsprechende Name dort eingetragen sein. Wird die Datenbank im Hot-Standby betrieben, werden die IP-Adressen der beiden Server durch "+" getrennt angegeben.

c16_server = TCP:10.0.0.1+10.0.0.2

Es können maximal 60 Zeichen angegeben werden.

c16_database *

Die zu öffnende Datenbank wird in diesem Eintrag angegeben. Die Datenbank muss so angegeben werden, wie sie beim Server definiert ist, d. h. ein entsprechender Eintrag muss in der Datenraumtabelle des Servers vorhanden sein. In diesem Eintrag können bis zu 127 Zeichen angegeben werden.

c16_database = ecm

C16_user * und C16_password *

Die Anmeldung in der Datenbank erfolgt über den hier angegebenen Benutzer. Alle Web-Benutzer der Applikation melden sich in die angegebene Datenbank unter diesem Benutzernamen an. Ist zur Anmeldung ein Kennwort erforderlich, wird dieses im Eintrag c16_password angegeben.

c16_user     = webuser
c16_password = mausi

Die Angabe des leeren Kennwortes erfolgt mit "". Benutzer und Kennwort können mit je maximal 20 Zeichen angegeben werden.

c16_proc_request *

Die Kommunikation zwischen Web-Browser und Web-Server erfolgt über Anforderungen (Requests) des Browsers. Alle Requests an die Applikation werden von der hier angegebenen Prozedur bzw. Funktion verarbeitet. Die Angabe erfolgt über <Prozedur>:<Funktion>. Wird kein Funktionsname angegeben, wird die Main-Funktion der Prozedur aufgerufen. Der Eintrag darf 61 Zeichen nicht überschreiten. Wird kein Funktionsname angegeben, darf der Name nicht länger als 20 Zeichen sein.

c16_proc_cache_kb

In dem eingestellten Cache werden Prozeduren zwischengespeichert. Der Cache wird für jede Datenbankverbindung eingerichtet. Der Prozedurcache sollte mindestens so groß wie die Request-Funktion ausfallen, da diese bei jeder Browser-Anfrage aufgerufen wird. Der Prozedurcache kann zwischen 32 und 65536 KB (64 MB) eingestellt werden. Ist dieser Eintrag nicht in der Konfigurationsdatei enthalten, wird ein Prozedurcache von 256 KB eingerichtet.

c16_proc_test

Der Prozedurcache einer Datenbankverbindung bleibt bis zum Beenden der Verbindung erhalten. Dies führt während der Entwicklungsphase dazu, dass Prozeduränderungen sich nicht auswirken, da sich die vorhergehende Version des Prozedurcodes noch im Cache befindet. Mit der Einstellung c16_proc_test = Y wird der Prozedurcache nach jedem verarbeiteten Request geleert, ohne dass die Datei c16_web.DLL entladen werden muss. Diese Einstellung sollte im Echtbetrieb nicht aktiviert sein, da sie die Verarbeitung deutlich verlangsamt.

c16_max_connections *

In dieser Eigenschaft wird die maximale Anzahl von Verbindungen zur Datenbank angegeben.

Die Einstellung unterscheidet sich von web_max_connections , in der die maximale Anzahl aller Web-Benutzer des Clients angegeben wird, während hier die maximale Anzahl der Verbindungen (Datenbankbenutzer) zur Datenbank für eine Applikation angegeben wird. Eine Verbindung wird nur solange genutzt, bis ein Request abgearbeitet wurde und steht danach einem anderen Web-Benutzer zur Verfügung. Der Eintrag kann zwischen 1 und 1000 gewählt werden.

In diesem Eintrag dürfen nicht mehr Benutzer zugelassen werden, als der CONZEPT 16-Server ermöglicht. Der hier eingetragene Wert entspricht der Anzahl von Requests, die gleichzeitig bearbeitet werden können. Wird die Datenbank sowohl vom Web, als auch von eigenen Mitarbeitern genutzt, sollte die Anzahl der Verbindungen so eingestellt werden, dass auf jeden Fall alle Mitarbeiter arbeiten können.

c16_min_delay_ms *

Wird ein Request an den Client gestellt und alle verfügbaren Datenbankverbindungen der Applikation sind bereits mit der Bearbeitung eines Requests beschäftigt, wird nach Ablauf der hier eingetragenen Millisekunden eine neue Datenbankverbindung aufgebaut. Wird in diesem Zeitraum eine Datenbankverbindung frei, wird diese zur Bearbeitung des Requests verwendet.

Hier können Werte von 0 bis 3000 eingetragen werden. Bei 0 wird sofort eine neue Verbindung eingerichtet.

c16_max_delay_ms *

Kann keine weitere Datenbankverbindung eingerichtet werden, wird maximal die hier eingestellte Zeit gewartet. Wird eine Datenbankverbindung in diesem Zeitraum frei, wird diese verwendet. Kann auch nach dieser Zeit keine Verbindung benutzt werden, wird eine Fehlerseite mit dem HTTP-Status 503 bzw. dem Fehlerwert 50026 (siehe Rückgabe von Fehlerseiten ) zurückgegeben.

Hier können Werte zwischen 100 und 10000 eingetragen werden.

c16_timeout_s *

Wird eine Datenbankverbindung länger als die hier eingestellte Zeit nicht benutzt, wird sie automatisch beendet, d. h. der Datenbankbenutzer wird abgemeldet. Es können Werte von 5 bis 14400 Sekunden eingetragen werden.

Der eingestellte Wert sollte größer sein, als die Werte in den Eintragungen web_max_timeout_s und web_min_timeout_s .

Das Zusammenspiel der Einträge c16_max_connections , c16_min_delay_ms , c16_max_delay_ms und c16_timeout_s funktioniert wie folgt. Im Beispiel wird von folgenden Einstellungen ausgegangen:

c16_max_connections =   10
c16_min_delay_ms = 50
c16_max_delay_ms = 2000
c16_timeout_s = 600

Ein Anwender stellt über einen Browser einen Request an den Client. Da der Web-Benutzer der erste ist, besteht noch keine Verbindung zur Datenbank. Der Client öffnet die Datenbank mit dem eingestellten Benutzernamen. Während der Request des ersten Anwenders bearbeitet wird, trifft ein weiterer Request eines zweiten Anwenders ein. Da bereits eine Datenbankverbindung besteht, wird zunächst überprüft, ob die Verbindung noch verwendet wird. Das ist der Fall, da der Request von Anwender #1 noch nicht abgeschlossen ist. Der Client wartet jetzt maximal 50 Millisekunden ( c16_min_delay_ms ). Sollte in dieser Zeit die Datenbankverbindung nicht mehr für den Anwender #1 benötigt werden, wird sie von Anwender #2 verwendet. Anwender #2 ist dann mit der gleichen User-ID in der Datenbank eingeloggt, wie kurz zuvor noch Anwender #1.

Wird die Datenbankverbindung weiter von Anwender #1 benötigt, wird nach insgesamt 50 Millisekunden eine weitere Verbindung zur Datenbank hergestellt. Die Anfragen von Anwender #1 und Anwender #2 werden gleichzeitig verarbeitet.

Nachdem der Request von Anwender #1 abgearbeitet wurde, bleibt die Verbindung zunächst bestehen. Trifft innerhalb der nächsten 600 Sekunden ( c16_timeout_s ) eine weitere Anfrage ein, wird die erste Verbindung erneut verwendet. Nach 600 Sekunden ohne Anfrage wird die Datenbankverbindung beendet.

Sind nun 10 ( c16_max_connections ) Datenbankverbindungen aufgebaut, von denen alle verwendet werden und es trifft ein weiterer Request ein, wird zunächst 50 Millisekunden gewartet. Wenn in dieser Zeit keine der Verbindungen frei wird, versucht der Client eine weitere Datenbankverbindung einzurichten. Dies ist nicht möglich, da die maximale Anzahl an Verbindungen bereits erreicht ist. Der Client versucht dann weitere 2000 Millisekunden ( c16_max_delay_ms ) eine freie Verbindung zu erhalten. Wird keine der Verbindungen frei, wird der Request abgewiesen und der Anwender erhält eine entsprechende Fehlerseite zurück.

Durch diese Form des Verbindungs-Sharings können mehrere Web-Benutzer eine Datenbankverbindung nutzen und belasten damit nicht das Benutzerlimit des Servers. Es ist allerdings darauf zu achten, dass in der Programmierung nicht die User-ID UserInfo(_UserCurrent) der Datenbank über einen Request hinaus verwendet wird, da diese von der Verbindung abgeleitet wird und sich daher für den Web-Benutzer bei jedem Request ändern kann. Stattdessen kann über den Befehl WseInfo(_WseInfoUserNumber) die Nummer des Web-Benutzers ermittelt werden.