Funktionsweise von XTEND 

Dictionary

Das Dictionary umfasst die Definition sämtlicher XTEND-Parameterdateien.

Es setzt sich aus einer Reihe von XML-Dateien zusammen (einer pro XTEND-Funktion), die auf dem Server der X3-Lösung in folgendem Verzeichnis gespeichert sind:
X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_GEN/SITEFreigabe

Gibt der Entwickler

ein Datenblatt frei , wird für die Generierung der XML-Datei eine Generierungsverarbeitung aus dem Dictionary angestoßen.

Bei Freigabe wird ein neues XML-Dictionary der XTEND-Parameter angelegt.

Nur, wenn die Option 'Technik\Aktualisierung\ Prüfen\Web-Dictionary'derWebsite , Funktion Websites (GESAYS), aktiviert ist, wird das neue Dictionary bei Aktualisierung / F5 der HTML-Seite im Browser automatisch berücksichtigt.

Sonst muss die Dictionary-Aktualisierung mithilfe folgender URL erzwungen werden:
'http://hostname:port/xtend/svc/SolutionX3/DossierX3/SiteXtend/admin/reposit/reload'

Nach der Änderung der X3-Paramter:

wird empfohlen, die gesamte Website über die Funktion freizugeben, damit das Dictionary des XTEND-Servers über die Funktion Freigabe Website (AYTFCYGEN)neu aufgebaut wird.

Es ist zu prüfen, ob die XTEND-Website veröffentlicht wurde, also ob das Feld 'Website veröffentlicht' auf dem Datenblatt 'Website' aktiviert ist.

Zugriff auf X3-Dateien

Technisch greift der XTEND-Server über den per Default auf der Maschine des Haupt-X3-Servers installierten HTTP-Server (Apache) auf die X3-Dateien zu.

Das Wurzelverzeichnis ist das Verzeichnis X3_PUB der Lösung.

Die Aktualisierungen werden per Lesen des 'TimeStamp' (letztes Änderungsdatum) der Datei ermittelt.

Der XTEND-Server liest die XML-Dateien und baut im Speicher für die Optimierung des Parameterzugriffs eine Datenbank auf.

Beim Laden prüft XTEND die Dictionary-Kohärenz und generiert im Fehlerfall eine Ausnahme.

Fall eines Fehlers beim Lesen des Dictionarys
  • Es ist zu prüfen, ob anonyme Benutzer Zugriff auf das Verzeichnis X3_PUB besitzen.
    Die URL http://hostX3/Adonix_X3SOL/X3FOLDER/X_TEND/X_GEN/XTENDSITE/muss die Liste der XML-Dateien zurückgeben.
  • Unter UNIX prüfen Sie die Zugriffsrechte des Benutzers
Optimierung

Standardmäßig werden Dictionary und Lokale Menüs auf dem X3-Server gespeichert.

Mit den Konsolenparametern xtend.server.reposit.local=off und xtend.server.menux3.local=off kann lokal eine Lokalisierung der X3WEB-Serverdateien definiert werden (Optimierung).

In diesem Fall muss das Dictionary-Verzeichnis und / oder das Verzeichnis der Lokalen Menüs in \WebData\LOCAL\X3SOLUTION\X3_PUB\kopiert werden.

WebData ist das bei Installation des X3WEB-Servers definierte 'Data-Verzeichnis'.

HTML-Verarbeitung

Lesen

Standardmäßig werden die Seiten und sämtliche Ressourcen des HTML-Projekts auf dem X3-Server im Verzeichnis
/X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_HTML/ASAMPLE/LANG/ gespeichert (LANG = Sprachcode der Website).

Der Entwickler muss daran denken, die HTML-Seiten vor dem Test in seinem Browser auf den X3-Server hochzuladen.

Unter UNIX muss geprüft werden, ob für sämtliche Dateien im HTML-Verzeichnis mindestens Leserechte für alle Benutzer vorhanden sind.

Der Prozess beim Lesen der Seiten und beim Ermitteln der Änderungen ist analog zum Dictionary.

Die Prüfung auf Aktualisierungen kann mit einem Parameter der XTEND-Websiteaktiviert oder deaktiviert werden. Ist die Prüfung deaktiviert, so muss für die Berücksichtigung der Seitenänderungen durch den XTEND-Server die URL für das erneute Laden des Dictionarys verwendet werden. Eine Webseite entspricht einer Textdatei mit HTML-Text, auf der vom Entwickler XTEND-Token hinzugefügt wurden.

Nach dem Laden der Seite liest der XTEND-Server den Inhalt und interpretiert den HTML-Code und die Token (Parsing), um die Seite im Speicher in Form einer Objekthierarchie (DOM) darzustellen zu können.

Dabei entspricht jedes Objekt einem Token, in dem eine Berechnungsmethode für die HTML-Implementierung enthalten ist (computeHtml).

Die Token-Hierarchie wird aus dem XTEND-Protokoll ersichtlich:

++ entspricht der Ebene - CXtdHtmBuild* ist die Objektklasse

+CXtdHtmBuildDom - XTEND

++CXtdHtmBuildNodeHtml - HTML
++CXtdHtmBuildTagHead - <HEAD

+++CXtdHtmBuildTagBase - <BASE
++CXtdHtmBuildAdxScriptLibrary - ALIBJS
++CXtdHtmBuildTagHeadEnd - </HEAD
++CXtdHtmBuildTagBody - <BODY
++CXtdHtmBuildTagForm - <FORM
++CXtdHtmBuildAdxTagAnchor - AHOME
++CXtdHtmBuildAdxTagAnchor - AABOUT
++CXtdHtmBuildAdxCND - ADISPUSERLOGGEDIN
+++CXtdHtmBuildAdxTagAnchor - AUSERACCOUNT
+++CXtdHtmBuildAdxTagAnchor - ADLKLOGOUT
++CXtdHtmBuildAdxCND - ADISPUSERLOGGEDIN
+++CXtdHtmBuildAdxTagAnchor - ALOGIN
...
Der HTML-Parser des XTEND-Servers ist mit der Version
HTML 4.01 (DTD HTML 4.01 Transitional)
kompatibel.

Die einzige Einschränkung, die durch XTEND beim HTML-Design auftritt, liegt darin, dass nur ein einziges HTML-Formular

verwendet werden kann, in dem der gesamte Body der HTML-Seite gekapselt sein muss. <body><form> Inhalt </form></body> Aufbau
Bei der dynamischen Berechnung des Inhalts einer HTML-Seite führt der XTEND-Server folgende Schritte aus:

1. Initialisierung der Blöcke

Schnittstellen vom Typ Datenzugriff:

Aufbau der Abfrage (Selektion) je nach Parametern

Aufruf der Website über die Schnittstelle zur Blockentität

  • Anlage der 'Datenzugriffsentitäten' im Speicher
  • Schnittstellen vom Typ Aktion:
  • Lesen der bereits im Speicher vorhandenen Entitäten

2. Rekursiver Durchlauf sämtlicher Hierarchieobjekte (DOM) und Aufruf der Methode

  • computeHtml
. Das Token ist ein Feld:

Berechnung des Feldwertes

  • Das Token ist ein dynamischer Link:

Berechnung der URL (tag <a></a>) oder des JavaScripts (tag <imput type="button")

  • Das Token ist ein Block:

Iteration über alle Entitäten und Aufruf der Berechnungsmethode für die abgeleiteten Token 

  • Das Token ist ein bedingter Block:

Auswertung des Booleschen Ausdrucks (Kriterien) und ggf. Aufruf der Berechnungsmethode für die abgeleiteten Token

  • 3. Das Gesamtergebnis ist die Summe des von allen Token erstellten HTML.
Die Berechnungsmethode des HTML richtet sich nach der Art des Tokens und nach dem HTML-Tag, in das das Token eingefügt wird.

HTML-Generierung

Das berechnete HTML richtet sich nach der Art des Tokens und nach dem HTML-Tag, in das das Token eingefügt wird.

<field>-Token in den Tags <td>, <div>, <span>, <p> etc.

Ersetzt den Tag-Inhalt durch den Feldwert

<td adx="myField"></td> ---> <td>Valeur</td>

<field>-Token in einem <select>-Tag

Wählt per Generierung des selektierten Attributs die Option, die dem Feldwert entspricht.

Beispiel: myField = FR, Option = "FR" (attribute selected)

<select adx="myField">

    <option value="AT">Austria</option>      
    <option value="FR">France</option>
</select>
<!--GENERE-->
<select adx="myField">
    <option value="AT">Austria</option>        
    <option selected value="FR">France</option>
</select>
<field>-Token in einem <img>-Tag

Generiert die URL, mit der der Browser das Bild lesen kann

<img adx="COUNTRYFLAG">

<!--GEN-->
<img src="/xtend/data/exp(expires,index)/remote/SOL/FLDR/X_TEND/X_HTML/SITE/FRA/FLAGS/BE.gif"/>
Dynamischer Link in einem <a>-Tag

Wenn dem Token keine Aktion zugeordnet ist (GET-Methode), wird das Attribut href des Tags berechnet

Sonst wird der Tag wie ein Button behandelt (POST-Methode, siehe unten)
<a adx="MyDynLink">Logout</a>

<!--GEN URL'-->
<a href="
http://host:port/xtend/page?DLK=MyDynLink&SOL=SOL...">Logout</a>Dynamischer Link in einem <input type="button">-Tag

Berechnet die JavaScript-Funktion xtdDoDlk und fügt das Attribut 'onClick' ein

Die Parameter richten sich nach dem Kontext und werden von der XTEND-Bibliothek behandelt

<input type="button" adx="MyDLK" value="Anlegen">

<!--GENERIERT DAS ATTRIBUT ONCLICK'-->
<input type="button"
   onclick="xtdDoDlk(this,'MyDLK',null,null,null,0,null,event,true,'',false,null,true);"
   value="Anlegen"/>
 Funktion xtdDoDlk

Diese Funktion wird von XTEND im Attribut onClick für dynamische Links generiert, die über eine zugeordnete Aktion oder Selektion verfügen.

Sie stößt den JavaScript-Prozess XTEND für die Verarbeitung von Benutzeraktionen an.

Mit der Funktion kann auch der Datenkontext (aCtxTag, aLineIdx) der dynamischen Links wiedergefunden werden, insbesondere für die in den Blockzeilen generierten Token.

function xtdDoDlk(aElmt, aDlk, aProtocol, aBlkId, aCtxTag, aLineIdx, aUrlAdd, aEvent, aSubmit,

                  aAutoId, aForceAcceptReload, aForceSelBlock, aCheckWebFields)
{/*
 aElmt: Vom Benutzer angeklicktes JavaScript-Objekt
 aDlk: Angeklickter dynamischer Link
 aProtocol: !=null erzwingt das Protokoll (https, http) für diesen Link
 aBlkId: Code des Referenzblocks, wenn adx='MyBlocRefence.MyLink'
 aCtxTag: Id des Datenkontexts (wenn Aktion mit Parametern vom Typ XTEND-Feld)
 aLineIdx: Zeilenindex, wenn das Token in einen {{multi}}-Block gesetzt wurde
 aUrlAdd: Enthält den Wert des HTML-Parameters xanchor adx="MyLink:xanchor=#section"
 aEvent: Enthält das JavaScript-Ereignisobjekt
 aSubmit: True zur Formularvorlage
 aAutoId: Von XTEND generierte Id, wenn adx="MyLink:xautoid"
 aForceAcceptReload:True, um die Aktualisierung (F5) zu akzeptieren
 aForceSelBlock:Id des Blocks, der die Abfrage verarbeitet, sofern != AMAIN
 aCheckWebFields: True für die Prüfung der Webfelder
*/
}
  Der Datenkontext der Seite wird in der Seite selbst in einem maskierten <span>-Tag gespeichert.

Er umfasst sämtliche Werte der Felder (Typ '<field>-Token', die als Aktionsparameter der dynamischen Links der Seite verwendet werden.
Mit dieser Methode kann die Rückkehr über die Funktion 'Zurück' des Browsers sehr effizient verwaltet werden.
<span id="xtdctx" style="display: none; clear: both;">

    XML, das den Seitenkontext enthält
</span>
Serverdatenkontext

Um ein gutes Verständnis für die Funktionsweise von XTEND entwickeln zu können, muss die Vorgehensweise bei der Auflösung von Feldwerten durch den XTEND-Server beschrieben werden.

Der XTEND-Server pflegt einen Datenkontext, der in einem Datenblockstapel (Stack) verwaltet wird.

Dieser Datenkontext ist wie folgt aufgebaut:

Statischer, von der Seite unabhängiger Teil

  • Dieser setzt sich aus den Daten der Benutzersitzung zusammen, also aus Entitäten vom Typ 'Sitzung' und aus Entitäten vom Typ 'Aktion'.
      • Dynamischer, von den in die Seite eingefügten <block>-Token abhängiger Teil
  • Dieser setzt sich aus Entitäten vom Typ 'Datenzugriff' zusammen, die bei der Verarbeitung der <block>-Token angelegt wurden.
      • Kontextverwaltung
Ausgangszustand

Zu Beginn des Seitenaufbaus umfasst der Datenkontext lediglich die Sitzungsdaten.

Blockverarbeitung

Wenn der XTEND-Server einen Block verarbeitet, führt er eine Iteration über sämtliche selektierten Entitäten durch.

Für jede Entität wird folgende Verarbeitung ausgeführt:
1. Die Daten (Entität) werden im Datenkontext auf den Stapel gelegt (push)

--> Die Entität wird oben auf den Stapel (top) gelegt und bei Auflösung des Feldwertes zuerst bearbeitet
2. Aufruf der Aufbaumethode für das HTML der abgeleiteten Token

--> rekursiver Mechanismus, mit dem Blöcke gestapelt werden können
3. Entität erweitern

--> Nach der Verarbeitung sämtlicher abgeleiteter Token erweitert der Server die Entität, bevor er mit der Verarbeitung der nächsten Entität fortfährt
Die oben auf dem Stapel liegende Entität wird über den Block

ACURRENT adressiert.Das Auswahlkriterium 'CODE=ACURRENT.CODE' in einem dynamischen Link gibt an, dass das Element der aktuellen Zeile selektiert werden soll.
Auflösung

Das Prinzip der Feldwertauflösung besteht aus:

1. Durchlauf des Entitätenstapels von oben (top) nach unten (bottom)

2. Stopp, wenn die gelesene Entität ein Feld desselben Namens enthält

Wenn ein Feld gefunden wurde, gibt XTEND den Feldwert zurück. Sonst wird ein leerer Wert zurückgegeben.

Das nachstehende Beispiel zeigt den Status des Stapels mit einem 'Basisblock' Single-Datensatz (BLOCMONO) und zwei Blöcken für mehrere verschachtelte Datensätze (BLOCMULTI1, BLOCMULTI2).

Der erste Multiblock ist auf der zweiten Zeile und der zweite Block (BLOC2) auf der dritten Zeile.

<!adx="BLOCMONO">

    <!adx="BLOCMULTI1">
        <!adx="BLOCMULTI2">
            <span adx="MyField">
        <!adx="BLOCMULTI2">
    <!adx="BLOCMULTI1">
<!adx="BLOCMONO">
Stapel

Reihenfolge

 ASESSION

3 - Bottom

ENTITE_BLOCMONO

2

ENTITE_BLOCMULTI1_LIGNE2

1

ENTITE_BLOCMULTI2_LIGNE3

0 - Top

Um den Feldwert von MyField aufzulösen, prüft der XTEND-Server, ob das Feld MyField in den Entitäten vorhanden ist. Dabei wird folgende Reihenfolge beachtet:

1. ENTITE_BLOCMULTI2_LIGNE3

2. ENTITE_BLOCMULTI1_LIGNE2

3. ENTITE_BLOCMONO

4. ASESSION

Das Prinzip der Wertauflösung ist dasselbe für:

<field>-Token

  • Parameter / Kriterien vom Typ '<field>-Token' (MeinBlock.MeinFeld) mit folgender Verwendung:
  • Auswahlkriterien für Blöcke und dynamische Links
      • Parameter der Webaktionen
      • Formelkriterien für bedingte Blöcke
      • Bei der Berechnung eines Feldwertes einer gegebenen Entität wird die folgende Syntax verwendet:

ASESSION.MyField

  • Lesen des Wertes im Sitzungskontext
      • MyBlock.MyField
  • Wenn MyBlock ein Single-Datensatzblock ist, wird der Feldwert dieses Blocks gelesen
      • Wenn MyBlock ein Multi-Datensatzblock ist, wird der Feldwert der
      • selektierten Zeile gelesen
  • MyBlock(i).MyField
      • Lesen des Feldwertes der i-ten Blockzeile (i ab 1)
Auflösung im Sitzungskontext

Der Sitzungskontext setzt sich aus den nachstehend aufgeführten Datenblöcken zusammen.

Die Auflösung des Feldwertes richtet sich nach der Darstellungsreihenfolge der Blöcke in der Liste.

1. AUSERINF - signierte Benutzerdaten

2. AUSERVAR - Benutzervariablen

    • Umfasst die mit den JavaScript-Funktionen xtdAjaxSetUserVar und xtdSetUserVar angelegten Felder
    • Verwendung für Sicherung der Client-Daten auf dem Server

3. ASITE - Document Site

    • Zugriff auf die Werte der freien Parameterfelder im Website-Datenblatt
    • <span adx="ASESSION.MyFreeField"></span> zeigt den Wert des freien Codeparameters MyFreeField an

4. AMESS - Benutzermeldungen

    • Enthält die von X3 zurückgegebenen Meldungen

5. AUSERCRIT - Benutzerkriterien

    • Die Auswahlkriterien werden mit dem HTML-Parameter xcrit gesichert und wiederhergestellt
    • <input type="text" adx="MyCriteria:xcrit">

6. ASYSVAR - Systemvariablen

    • Enthält lediglich das Feld ATODAY

7. ACONST - <fielt>-Token vom Typ Konstante

Verarbeitung von HTTP-Abfragen

HTTP-Abfragen

In der X3WEB-Architektur auf dem XTEND-Server gibt es drei Anwendungsschichten:

1. Apache-HTTP (Front-End) für die Verarbeitung von HTTP-Abfragen

2. Apache-Tomcat für die Webanwendungen

3. XTEND-Webanwendung

Die http-Abfragen an die XTEND-Webanwendung sind über die mit /xtend/*beginnende URL identifiziert.

Der Pfad der XTEND-Webanwendung ist auf der Konsole über folgenden erweiterten Parameter parametrierbar:
xtend.server.virtualpath.context=xtend

Die Webanwendung kann eine bestimmte Anzahl von Abfragen (Servlets) verarbeiten, die durch den 2. Parameter der URL /xtend/servlet/ identifiziert sind:

  • /xtend/page/* verwaltet den Aufbau der HTML-Seite
  • /xtend/data/* verwalteten Zugriff auf die Datenblattdaten (Bilder, fklash, PDF-Dateien etc.) in X3 oder lokal
  • /xtend/admin/* verwaltet die für den Entwickler nützlichen Verwaltungsabfragen
  • /xtend/svc/* verwaltet die für den Entwickler nützlichen Verwaltungsabfragen (Protokoll, Cache-Verwaltung, Aktualisierung etc.)
Methoden POST und GET

Das HTTP-Protokoll bietet verschiedene Methoden und Kommandos, mit denen der von der Abfrage auszuführende Aktionstyp spezifiziert werden kann.

Der XTEND-Server antwortet nur den Methoden GET und POST. Diese haben folgende Bedeutung:

Dynamische Links verwenden standardmäßig die POST-Methode, wenn ihnen eine Selektion oder eine Aktion zugeordnet ist.
Diese Methode legt das HTML-Formular <form></form> der Seite per Aufruf der JavaScript-Funktion xtdDoDlk vor (submit).
In dieser Funktion werden die Parameter des dynamischen Links (XML) berechnet und an ein verborgenes Eingabefeld gesendet.
Der Server empfängt alle Daten, die er für die Verarbeitung der dem angeklickten dynamischen Link zugeordneten Aktion oder Selektion benötigt (Felddaten des Formulars sowie vom Client berechneter Kontext).

Dynamische Links können die GET-Methode verwenden, wenn lediglich eine Verzweigung zu einer Seite ausgeführt wird oder wenn kein Aktions- oder Selektionsparameter zu berechnen ist.
Diese Methode wickelt nicht die Vorlage des HTML-Formulars ab, sondern verzweigt zu einer URL, die lediglich die Datenbankparameter enthält (Link, Lösung, Ordner, Website, Sprache).

Nur die GET-Methode ist zu den Suchmaschinen (Webcrawlern) kompatibel.

Verwendung von 'Reverse Proxys'

Aus Sicherheitsgründen können die Internetbenutzer für den Zugriff auf interne Serveranwendungen einen Reverse Proxy verwenden.

Darüber hinaus lässt sich mit Reverse Proxys die echte Serveradresse eines Benutzers maskieren. Ein weiterer Vorteil ist die Vereinfachung bei der Wartung von Websites.

Ist ein Server down, können die Abfragen auf eine für den Client transparente Art vorübergehend an einen anderen Server umgeleitet werden.

Um einen proxyxtend -Alias für einen 'Reverse Proxy' auf dem Apache-Server des für die Umleitung der XTEND-Abfragen an hostxtend zuständigen X3WEB-Servers hostproxy zu definieren, wird folgende Konfiguration verwendet:

Datei Apache2.2\conf\httpd.conf

Anlage eines 'virtual Hosts' auf Port 80

<VirtualHost _default_:80>
    <Location "/proxyxtend/">
         ProxyPass                                "http://hostxtend:28980/"
         ProxyPassReverse                     "http://hostxtend:28980/"
         ProxyPassReverseCookieDomain "hostxtend"   "hostproxy"
         ProxyPassReverseCookiePath       "/xtend"       "/proxyxtend/xtend"
    </Location>
</VirtualHost>

Datei Apache2.2\conf\extra\httpd-ssl.conf

<VirtualHost _default_:443>
...
    ProxyRequests Off
    SSLProxyEngine on
    ProxyPreserveHost On
    <Location "/proxyxtend/">
         ProxyPass                                "https://hostxtend:28943/"
         ProxyPassReverse                     "https://hostxtend:28943/"
         ProxyPassReverseCookieDomain "hostxtend"   "hostproxy"
         ProxyPassReverseCookiePath       "/xtend"      "/proxyxtend/xtend"
         SSLRequireSSL
    </Location>
...
</VirtualHost>  

XTEND-Konfiguration

Wenn der Apache-Server hostproxy die URL http://hostproxy/proxyxtend/xtend/page/*.
Il erhält, verhält er sich wie ein Mandant und führt für den Client die Abfrage http://hostxtend/xtend/page/* an den XTEND-Server aus.

Der XTEND-Server, der die an den Client zurückzusendende HTML-Seite berechnet, muss den Reverse Proxy berücksichtigen, um für den End-Client (den Browser) korrekte URLs zu generieren.

In unserem Fall muss XTEND URLs in /proxyxtend/xtend/* generieren.
Bei der Berechnung der URL muss also zwingend der Reverse Proxy berücksichtigt werden.

Hierbei verwendet XTEND folgende Formel:

-1- Deklaration der Reverse Proxys:

Deklaration der HTTP- und HTTPS-Ports der 'Reverse Proxys' auf der Verwaltungskonsole per Änderung folgender erweiterter Parameter:

# Konfiguration Reverse Proxys
xtend.server.gensetup.proxies.hosts=      hostproxy1   hostproxy2
xtend.server.gensetup.proxies.portshttp=  80           80
xtend.server.gensetup.proxies.portshttps= 443          443

-2- Lesen des HTTP-'Referers'

Der Header HTTP-Referer enthält die vom Client für die Verbindung an den Server verwendete URL.

Der XTEND-Server analysiert diese URL und leitet daraus die Existenz eines Reverse Proxys ab, wenn /xtend/ einen Wert als Präfix aufweist (z. B. /proxyxtend/xtend/).

Mit oben beschriebener Konfiguration kann das HTTP-Protokoll in einem HTTPS-Protokoll umgewandelt werden oder umgekehrt. Dem XTEND-Server müssen sowohl der HTTP-Port als auch der HTTPS-Port des Reverse Proxy bekannt sein.

Um korrekt mit einem Reserve Proxy zusammenarbeiten zu können, muss der XTEND-Server also den 'HTTP-Referer', HTTP-Port und den HTTPS-Port des (ersten) Reverse Proxy kennen.

Mit dem Konfigurationsparameter xtend.server.gensetup.http.askreferer=on/off (per Default aktiviert) kann dieser Mechanismus aktiviert oder deaktiviert werden.

Der HTTP-Header 'Referer' ist nicht immer vorhanden. Dies gilt insbesondere, wenn die Adresse in der Adresszeile des Browsers erfasst wird.

Wenn der HTTP-Header 'Referer' nicht in der Abfrage vorhanden ist, sendet der XTEND-Server ein leeres Formular mit automatischer Antwort (für den Benutzer transparent) an den Browser, der in den meisten Fällen den 'Referer' zurückgesendet.

Scheitert dieser Versuch und wird kein Referer zurückgesendet, kann die Existenz eines Reverse Proxy also nicht vom XTEND-Server berücksichtigt werden.

Sitzung

Das Kommunikationsprotokoll zwischen Browser und HTTP-Server ist das HTTP-Protokoll, das "keinen Status"hat.
Der HTTP-Server behält nach der Verarbeitung der Abfrage keine Protokolldatei des Client.
Es wird so verfahren, als würde die Verbindung zwischen Client und Server nach jeder Abfrage beendet.

Diese Funktionsweise ist völlig verschieden vom Client-Server-Modus (X3-Client), bei dem während der gesamten Sitzung eine aktive Verbindung mit dem X3-Server unterhalten wird.

Bei der Entwicklung von Webanwendungen muss eine Verbindung zwischen den verschiedenen Abfragen hergestellt werden können, um diese einem bestimmten Client zuordnen zu können.
Diese Verbindung wird mit HTTP-Cookiesgeschaffen.

Ein Cookie wird auf Initiative des Servers angelegt, wenn dieser im HTTP-Header eine 'Set-Cookie'-Anweisung an den Client sendet.
Die Kopie wird anschließend vom Client im HTTP-Header sämtlicher Abfragen an diesen Server zurückgesendet.

Anweisung acht
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
Mit Path können die Cookies an den Server gefiltert werden
In unserem Fall wird JSESSIONID in allen Abfragen zurückgesendet, deren URL folgendermaßen beginnt: /xtend/ (http://host:port/xtend/....)

Die Identifizierung über Cookies (und damit die Funktionsweise der Webanwendung) ist nur gewährleistet, wenn der Browser Cookies vom Typ Sitzung (ungesicherte) akzeptiert.
Dies ist bei Browsern zumeist die Standardeinstellung

Das Konzept des 'Clients' ist von Browser zu Browser verschieden und hängt von der Art der Cookie-Verwaltung ab.

  • Bei Firefox werden die Cookies zwischen den Browserinstanzen aufgeteilt.
    Verbindet sich der Benutzer am selben Arbeitsplatz mit zwei verschiedenen Firefox-Instanzen mit dem XTEND-Server, teilen sich diese beiden Browserinstanzen dieselbe XTEND-Sitzung.
    Die Browser werden auf der Serverseite wie ein einziger Client angesehen.
  • Bei IE6 werden die Cookies zwischen den Browserinstanzen nicht aufgeteilt.
    Verbindet sich der Benutzer am selben Arbeitsplatz mit zwei verschiedenen IE6-Instanzen mit dem XTEND-Server, hält jede Instanz eine eigene Sitzung.
    Die Browser werden auf der Serverseite wie zwei verschiedene Clients angesehen.
  • Die Register desselben Browsers hingegen teilen sich dieselben Cookies und werden als ein einziger Client betrachtet.
TOMCAT-Sitzung

Die Benutzersitzung, mit der jedem Client ein eigener Datenkontext zugeordnet werden kann, wird vom TOMCAT-Server mit so genannten Servlets verwaltet.

Um die Abfragen zu identifizieren und zur richtigen Benutzersitzung umzuleiten, verwaltet der TOMCAT-Server eine spezielle Cookie-Sitzung mit dem Code JSESSIONID.

Vom TOMCAT-Server verwaltetes Cookie
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
JSESSIONID ist die Id der TOMCAT-Sitzung

Das Cookie JSESSIONID ist nicht persistent, d. h. nach dem Verlassen des Browsers wird es nicht aufbewahrt.
Wenn der Benutzer seinen Browser schließt, verliert er also seine Sitzung und damit seinen Datenkontext.

Die Sitzung wird lediglich für eine über folgenden Konsolenkonfigurationsparameter parametrierbare Dauer im Speicher gehalten:
xtend.server.gensetup.http.session.timeout
Dieser Parameter gibt die vom TOMCAT-Server tolerierte Sitzungsinaktivitätszeit in Minuten an.
Wird innerhalb dieser Dauer keine Aktivität (erhaltene Abfrage) ermittelt, wird die Sitzung unterbrochen, und der Datenkontext geht verloren.

Funktionsweise bei der erneuten Verbindung

Der Xtend-Server verwaltet über das Cookie XADXIDseine eigene Sitzungs-Id.
Dieses Cookie ist persistent, wird also vom Browser gesichert, sofern hierfür eine Berechtigung vorliegt.

Wenn der Benutzer seinen Browser öffnet und sich mit dem XTEND-Server verbindet, wird das Cookie XADXID in der Abfrage (sofern vorhanden) versendet, und der Server versucht, die Benutzersitzung (TOMCAT) für die erneute Verbindung wiederzufinden.

Vom XTEND-Server verwaltete Cookies
Set-Cookie XADXID=123332746651556912893670; Expires=Sat, 30-Jan-2010 14:57:46 GMT; Path=/xtend

Mit dem Konsolenkonfigurationsparameter xtend.server.gensetup.http.cookie.sess.persist=on (per Default aktiviert) kann die Verwaltung der erneuten Verbindung nach Verlassen des Browsers aktiviert bzw. deaktiviert werden.

Auf der Wiederverbindungsseite der Website (fakultativ) kann der Benutzer darüber informiert werden, dass seine Sitzung wiederhergestellt wurde.

Funktionsweise ohne Cookies

XTEND bietet eine Funktionsweise ohne Cookies, bei der die Sitzungs-Id JSESSIONID in der URL weitergegeben wird.

Dieser Modus kann auf folgende Arten aktiviert werden:

  • vom Benutzer über die Webaktion ASESSSWITCHCOOKIES oder den dynamischen Link ADLKSWITCHCOOKIES
  • standardmäßig in allen Sitzungen über den Konsolen Konfigurationsparameter
    xtend.server.gensetup.http.cookie.disabled=on - per Default = off

Im Modus ohne Cookies müssen die URLs um einen zusätzlichen Parameter erweitert werden:
http://ecfdalbopro:28980/xtend/page;jsessionid=E04AEF0615702B3C7E52107ED6C17D8A?DLK=DLKTESTMAPPING...

In diesem Modus können Links zu anderen Webseiten nicht verwendet werden, da die Sitzungs-Id nicht weitergegeben wird und die Benutzersitzung verloren geht.

Verarbeitung auf dem Server

In diesem Absatz wird beschrieben, wie die HTTP-Abfragen vom XTEND-Server verarbeitet werden.

Apache-HTTP-Server

1. Eingang der HTTP-Abfrage

    • Generierung des abgesicherten HTTPS-Protokolls

2. Filterung der Abfrage gemäß URL

  • Nur mit '/xtend/*' beginnende URLs werden von XTEND verarbeitet.
    Konsolenparameter xtend.server.virtualpath.context
  • httpd.conf-Datei, die die Konfiguration des Apache-Servers enthält
    Diese Datei wird bei der Konfiguration des X3WEB-Servers generiert

3. Übertragung der Abfrage an den 'Apache-TOMCAT-Server' über mod_jk
mod_jk: 'Modul Jakarta' ist der Name des Open-Source-Projekts, aus dem TOMCAT entstand

JkMount xtend/portal* ajp13
JkMount xtend/page* ajp13
JkMount xtend/err/* ajp13
JkMount xtend/ajax/* ajp13
JkMount xtend/x3rsrc/* ajp13
JkMount xtend/htmrsrc/* ajp13
JkMount xtend/x_protect/* ajp13
JkMount xtend/data/* ajp13
JkMount xtend/svc/* ajp13
JkMount xtend/*.jsp ajp13

Apache-TOMCAT-Server

1. Anlage eines Tasks (Thread) für die Abfrageverwaltung

2. Suche nach dem Service (Servlet-Objekt) für die Verarbeitung von HTML-Seiten,

    • charakterisiert durch die URL /xtend/page/*

3. Suche nach der Sitzung mit dem JSESSIONID-Cookie

    • Anlage einer neuen Sitzung, falls nicht gefunden

4. Aufruf der Methode doPost oder doGet des Service

    • HTTP-Abfragedaten und Benutzersitzung sind im Parameter httpRequest enthalten
    • Hier beginnt die Verarbeitung der XTEND-Webanwendung
XTEND-Webanwendung

1. Initialisierung

1. Falls neue TOMCAT-Sitzung

    • Erneute Verbindung über das XADXID-Cookie
    • Anforderung des HTTP-Referers (unter Berücksichtigung von 'Reverse Proxys')

2. Bei Umleitung (Protokolländerung etc.)

    • Verarbeitung der URL-Umleitung

3. Lesen der XTEND-Parameter

    • GET-Methode: URL-Parameter
    • PUT-Methode: XML-Parameter im Feld XTDXML des HTML-Formulars
      Parameter: angeklickter dynamischer Link, angeforderte Seite, Aktionsparameter etc.

2. Neue Sitzung

1. Warteschlange, falls der Benutzer eine von einer anderen Abfrage gestartete Sitzung hält

    • Konsolenparameter xtend.session.wait.timeout 

2. Positionierung des Kontextes auf der XTEND-Website

    • Der Code SolutionX3/DossierX3/SiteXtend wird bei jeder Abfrage als Parameter übergeben
    • Ist der Parameter oder die Website nicht vorhanden, wenn mit der Standardwebsite gearbeitet
    • Konsolenparameter xtend.server.gensetup.defsite.x3sol,x3fldr,xtdSite 

3. Prüfung der Aktualisierung des XTEND-Dictionarys

    • Technische Parameter der Website 'Aktualisierung prüfen'

3. Prüfungen

1. Protokollprüfung

    • Das HTTP- oder HTTPS-Protokoll der Abfrage ist nicht das für die Seite definierte
      • Umleitung zum Client (HTTP-Status = 302), um das Protokoll zu wechseln 

2. Signierter Benutzer: Prüfung der Inaktivitätsdauer der XTEND-Sitzung

    • Parameter 'Timeout session(mn)' des Websitedatenblatts

3. Bei Weiterleitung der Seite
Parameter 'Geschützter Zugriff' des Websitedatenblatts 

1. Prüfung der Zugriffsrechte des Benutzers

    • Bei signierten Benutzern Prüfung gemäß Profil

2. Der Benutzer verfügt nicht über die benötigten Zugriffsrechte

    • Umleitung zur im Websitedatenblatt definierten Anmeldungsseite
    • Kontextsicherung (Zielseite, Aktion) für die Wiederherstellung nach der Anmeldung

4. Verarbeitung der Webaktion , wenn dem dynamischen Link eine Aktion zugeordnet ist

  • Die Aktion kann die Zielseite ändern
  • Tritt beispielsweise ein Fehler auf, wird die aktuelle Seite nicht verlassen und eine X3-Fehlermeldung angezeigt

5. Anzeige der Seite

1. Prüfung der Seitenaktualisierungen

          • Technische Parameter der Website 'Aktualisierung prüfen'

2. Initialisierung der <block>-Token (Abfragen)

          • Aufruf Webservice vom Typ Datenzugriff

3. HTML-Berechnung

          • Durchlauf der Tokenhierarchie
          • Aufruf der Methode computeHtml

6. Antwortversand an den Browser