Funkcjonowanie XTEND 

Słownik

Słownik zawierający definicje wszystkich rekordów ustawień XTEND.

Ma on formę plików XML (otwieranych przez funkcje XTEND) zapisanych na serwerze rozwiązań X3 w katalogu:
X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_GEN/SITE.

Zatwierdzenie

W momencie zatwierdzenia rekordu przez programistę uruchomiony zostaje proces generujący słownik w celu utworzenia pliku xml.

Zatwierdzenie generuje nowy katalog XML z ustawieniami XTEND.

Nowy słownik zostaje automatycznie uwzględniony przy odświeżeniu/wciśnięciu F5 strony HTML w przeglądarce, jeżeli zaznaczona została opcja rekordu ustawień witryny, function Websites (GESAYS)„Technique\Check updates\Web dictionary” .

W przeciwnym wypadku ponowne załadowanie słownika musi zostać wymuszone przez poniższy adres url:
„http://hostname:port/xtend/svc/X3Solution/X3Folder/XtendSite/admin/reposit/reload”

Po modyfikacji ustawień X3:

Zaleca się zatwierdzanie witryny w całości w celu wygenerowania słownika serwera XTEND poprzez funkcję Zatwierdzenie witryny internetowej (AYTFCYGEN).

Zweryfikuj, czy witryna XTEND została opublikowana, tzn. czy zostało zaznaczone pole „Publish the site” (Publikuj witrynę) rekordu „Web site” (Witryna).

Dostęp do plików X3

Serwer XTEND ma dostęp do plików X3 poprzez serwer HTTP (Apache), zainstalowany domyślnie na stacji roboczej, na której mieści się główny serwer X3.

Katalogiem głównym jest katalog X3_PUB rozwiązania.

Aktualizacje wykrywane są podczas odczytu „TimeStamp” (daty ostatniej modyfikacji) pliku.

Serwer XTEND odczytuje pliki XML i buduje w pamięci bazę danych, aby zoptymalizować dostęp do ustawień.

Podczas ładowania XTEND kontroluje spójność słownika i generuje wyjątki w przypadku odnalezienia błędu.

W przypadku błędu odczytu słownika
  • Sprawdź, czy do katalogu X3_PUB mają dostęp niezarejestrowani użytkownicy
    Adres URL http://hostX3/Adonix_X3SOL/X3FOLDER/X_TEND/X_GEN/XTENDSITE/musi zwracać listę plików xml.
  • Zweryfikuj uprawnienia dostępu użytkowników w UNIX
Optymalizacja

Domyślnie zarówno słownik, jak i lokalne menu zapisywane są na serwerze X3.

Ustawienia konsoli xtend.server.reposit.local=off oraz xtend.server.menux3.local=off są wykorzystywane do określania miejscowej lokalizacji plików na serwerze X3WEB (optymalizacji).

W takim przypadku konieczne jest skopiowanie katalogów słownika i/lub lokalnego menu do \WebData\LOCAL\X3SOLUTION\X3_PUB\.

WebData reprezentuje katalog „Data” zdefiniowany w momencie instalacji serwera X3WEB.

Przetwarzanie HTML

Odczyt

Domyślnie strony i wszystkie zasoby projektu HTML przechowywane są na serwerze X3 w katalogu
/X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_HTML/ASAMPLE/LANG/ (LANG określa język kodowy witryny).

Programista musi pamiętać o przesłaniu stron HTML na serwer przed sprawdzeniem ich w przeglądarce.

W systemie unix konieczne jest sprawdzenie, czy wszystkie pliki katalogu HTML posiadają minimalne ustawienia dla „read” wszystkich użytkowników.

Proces wykrycia odczytu i modyfikacji strony jest taki sam jak w przypadku słownika.

Konfiguracja witryny XTEND umożliwia aktywowanie/deaktywowanie sprawdzeń aktualizacji.

Jeżeli sprawdzanie zostało deaktywowane, konieczne jest przeładowanie słownika za pomocą adresu url, aby wymusić uwzględnienie przez serwer XTEND modyfikacji strony.

Parsowanie

Strona internetowa jest tekstem zawierającym znaczniki HTML, do których programista dodaje tokeny XTEND.

Po załadowaniu strony, serwer XTEND odczytuje zawartość i interpretuje HTML oraz tokeny (parsowanie), aby wygenerować reprezentację strony w pamięci w formie obiektu o strukturze drzewa (DOM).

Każdy obiekt reprezentuje token i stosuje metodę obliczenia HTML (computeHtml).

Struktura drzewa tokenów widoczna jest w logu XTEND:
++ odnosi się do poziomu - CXtdHtmBuild* jest klasą obiektu

+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
...

Parser HTML serwera XTEND jest kompatybilny z wersją HTML 4.01 (DTD HTML 4.01 Transitional).

Jedynym ograniczeniem projektowania HTML narzuconym przez XTEND jest możliwość wykorzystania wyłącznie formy HTML obejmującej całą część body strony HTML.
<body><form> Body content </form></body>

Generowanie

W celu obliczenia, w sposób dynamiczny, zawartości strony HTML, serwer XTEND wykonuje następujące operacje:

1. Inicjuje bloki

Dla interfejsów dostępu do danych typów:

  • Tworzy zapytanie (wybór) zgodnie z ustawieniami
  • Wywołuje usługę sieciową poprzez interfejs powiązany z jednostką bloku
  • Tworzy w pamięci jednostkę „Data access”

Dla interfejsów czynności typów:

  • Odczytuje jednostki już istniejące w pamięci
2. Przechodzi, w sposób rekursywny, przez obiekty struktury drzewa (DOM) i wywołuje metodę computeHtml

Jeżeli token jest polem:

  • Metoda oblicza wartość pola

Jeżeli token jest łączem dynamicznym:

  • Metoda oblicza adres url (tag <a></a>) lub JavaScript (tag <imput type='button')

Jeżeli token jest blokiem:

  • Metoda przeprowadza iterację wszystkich jednostek i wywołuje jednostkę obliczenia tokenów podrzędnych

Jeżeli token jest blokiem warunkowym:

  • Metoda ocenia wyrażenie logiczne (kryteria) i może wywołać metodę kalkulacji tokenów podrzędnych
3. Wynikiem globalnym jest suma HTML wygenerowanych przez wszystkie tokeny.

Metoda obliczenia HTML zależy od rodzaju tokena i znacznika HTML, w jakim został on umieszczony.

Generowanie HTML

Obliczony HTML zależy od rodzaju tokena i znacznika HTML, w jakim został on umieszczony.

Pole tokenu w znacznikach <td>,<div>, <span>, <p>...

Zastępuje zawartość znacznika wartością pola

<td adx='myField'></td> ---> <td>Value</td>

Pole tokenu w znaczniku <select>

Wybiera opcję odpowiadającą wartości pola poprzez wygenerowanie wybranego atrybutu

Przykład: jeżeli wartością pola myField jest FR, a wartość opcji=FR i została ona wybrana (wybierz atrybut)

<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>

Pole tokenu w znaczniku <img>

Generuje adres URL umożliwiający przeglądarce odczyt obrazu

<img adx='COUNTRYFLAG'>
<!--GENERE-->
<img src="'/xtend/data/exp(expires,index)/remote/SOL/FLDR/X_TEND/X_HTML/SITE/FRA/FLAGS/BE.gif'/></FONT">

Token łącza dynamicznego w znaczniku <a>

Jeżeli do tokenu nie została przypisana żadna czynność (metoda GET), obliczany jest atrybut href znacznika
W przeciwnym wypadku (metoda POST) znacznik traktowany jest jako przycisk (patrz niżej)

<a adx='MyDynLink'>Logout</a>
<!--GENERE d'URL'-->
<a href='http://host:port/xtend/page?DLK=MyDynLink&SOL=SOL...'>Logout</a>

Token łącza dynamicznego w znaczniku <input type='button'>

Oblicza funkcję xtdDoDlk JavaScript i umieszcza ją w atrybucie „onClick”

Są to ustawienia kontekstowe, zarządzane przez bibliotekę XTEND

<input type='button' adx='MyDLK' value='Créer'>
<!--GENERE L'ATTRIBUT ONCLICK'-->
<input type='button'
onclick='xtdDoDlk(this,'MyDLK',null,null,null,0,null,event,true,'',false,null,true);'
value='Créer'/>

Funkcja xtdDoDlk

Funkcja ta generowana jest przez XTEND w atrybucie onClick dla łączy dynamicznych, do których przypisana jest jakaś czynność lub wybór.

Uruchamia ona proces JavaScript XTEND, który przetwarza czynności użytkownika.

Służy ona również do odnajdywania kontekstu danych (aCtxTag,aLineIdx) łącza dynamicznego, zwłaszcza dla tokenów generowanych w wierszach bloków.

function xtdDoDlk(aElmt,aDlk,aProtocol,aBlkId,aCtxTag,aLineIdx,aUrlAdd,aEvent,aSubmit,
aAutoId,aForceAcceptReload,aForceSelBlock,aCheckWebFields)
{/*
aElmt: Obiekt JavaScript kliknięty przez użytkownika
aDlk: Kod klikniętego łącza dynamicznego
aProtocol: Jeżeli !=null wymusza protokół (https,http) dla danego łącza
aBlkId: Kod bloku referencyjnego, jeżeli adx=„MyBlocRefence.MyLink”
aCtxTag: Identyfikator kontekstu danych (jeżeli czynność dotyczy ustawień pól XTEND typów)
aLineIdx: Indeks wiersza, jeżeli token jest umieszczony w bloku {{multi}}
aUrlAdd: Zawiera wartość ustawień HTML xanchor adx='MyLink:xanchor=#section'
aEvent: Zawiera obiekt zdarzenia JavaScript
aSubmit: Prawda dla przedstawienia formularza
aAutoId: Id generowane przez XTEND, jeżeli adx=„MyLink:xautoid”
aForceAcceptReload:Prawda dla zatwierdzenia przeładowania (F5)
aForceSelBlock:Id bloku przetwarzającego zapytanie, jeżeli != AMAIN
aCheckWebFields:Prawda dla kontroli pól sieciowych
*/
}

Kontekst danych strony zapisany jest na niej samej w ukrytym znaczniku rozpiętości.
Zawiera on wszystkie wartości pól (typu „Pole tokenu”) wykorzystywane jako ustawienia czynności dla łączy dynamicznych danej strony.
Metoda ta umożliwia łatwe zarządzanie opcją powrotu poprzez funkcję „Back” (powrót) przeglądarki.

<span id='xtdctx' style='display: none; clear: both;'>
XML zawierający kontekst strony
</span>

Kontekst danych serwera

Aby w pełni zrozumieć zasadę działania XTEND, konieczne jest szczegółowe wyjaśnienie procesu określania wartości pola przez serwer XTEND.

Serwer XTEND zachowuje kontekst danych, którym zarządza w stosach bloków danych (jednostkach).

Kontekst danych składa się z:

  • Części stałej, niezależnej od strony
      • Składającej się z danych sesji, to jest z jednostek typu „session” oraz „action”.
  • Części dynamicznej, zależnej od tokenów blokowych umieszczonych na stronie
      • Składającej się z jednostek typu „data access” utworzonych podczas przetwarzania tokenów blokowych.
Zarządzanie kontekstem

Stan początkowy

W momencie rozpoczęcia budowy strony kontekst danych zawiera wyłącznie dane sesji.

Przetwarzanie bloków

Podczas przetwarzania bloku serwer XTEND dokonuje iteracji wszystkich wybranych jednostek.
Każda jednostka jest przetwarzana w następujący sposób:

1. Gromadzenie danych (jednostka) w kontekście danych.
-->Jednostka jest spozycjonowana na szczycie stosu i przetwarzana jest jako pierwsza w momencie zdefiniowania wartości pola.

2. Wywołanie metody generowania HTML dla tokenów podrzędnych
-->Jest to mechanizm rekursywny, umożliwiający gromadzenie bloków

3. Rozładowywanie stosu jednostki
-->Po przetworzeniu na serwerze tokenów podrzędnych, stos jednostki jest rozładowywany przed przejściem do następnej jednostki.

Jednostka zajmuje miejsce na szczycie stosu i zostaje powiązana z blokiem ACURRENT .
Na przykład, kryterium wyboru „CODE=ACURRENT.CODE” w łączu dynamicznym wskazuje na konieczność wyboru elementu bieżącego wiersza

Definiowanie wartości pola

Zasada definiowania wartości pola polega na:

1. przejściu przez cały stos jednostek od jego szczytu do spodu

2. zatrzymaniu się, gdy jednostka odczytu zawiera pole o takiej samej nazwie

Jeżeli pole może zostać odnalezione, XTEND wysyła wartość tego pola, w przeciwnym wypadku wysłana zostaje pusta wartość.

Poniższy przykład pokazuje przypadek stosu z blokiem tła zapisu mono (BLOCKMONO) i dwoma zagnieżdżonymi blokami zapisu wielokrotnego (BLOCMULTI1, BLOCMULTI2).

Pierwszy blok zapisu wielokrotnego spozycjonowany jest na drugim wierszu, a drugi blok (BLOC2) zajmuje trzeci wiersz.

<!adx='BLOCMONO'>
<!adx='BLOCMULTI1'>
<!adx='BLOCMULTI2'>
<span adx='MyField'>
<!adx='BLOCMULTI2'>
<!adx='BLOCMULTI1'>
<!adx='BLOCMONO'>

Stos

Kolejność

ASESSION

3 - Spód

ENTITE_BLOCMONO

2

ENTITE_BLOCMULTI1_LIGNE2

1

ENTITE_BLOCMULTI2_LIGNE3

0 - Szczyt

W celu określenia wartości pola MyField, serwer XTEND weryfikuje obecność pola MyField w jednostkach zgodnie z poniższą kolejnością:

1. ENTITE_BLOCMULTI2_LIGNE3

2. ENTITE_BLOCMULTI1_LIGNE2

3. ENTITE_BLOCMONO

4. ASESSION

Zasada stosowana do definiowania wartości jest taka sama w przypadku:

  • Pól tokenu
  • Ustawień/kryteriów typów „Pole tokenu” (MyBlock.MyField) użytych w przypadku:
      • Kryteriów wyboru bloków i łączy dynamicznych
      • Ustawień czynności sieciowych
      • Kryteriów formuł bloków warunkowych

Aby obliczyć wartość pola dla danej jednostki, konieczne jest zastosowanie poniższej składni:

  • ASESSION.MyField
      • Odczytuje wartość w kontekście sesji
  • MyBlock.MyField
      • Jeżeli MyBlock jest blokiem zapisu mono, wartość pola dla tego bloku zostaje odczytana.
      • Jeżeli MyBlock jest blokiem zapisu wielokrotnego, wartość pola dla tego bloku zostaje odczytana dla wybranego wiersza
  • MyBlock(i).MyField
      • Odczytuje wartość pola i-tego wiersza bloku (i rozpoczynające się od 1).
Definiowanie w kontekście sesji

Kontekst sesji składa się różnych bloków danych opisanych poniżej.

Wartość pola jest definiowana zgodnie z kolejnością prezentacji bloków na liście.

1. AUSERINF - Informacje dotyczące zalogowanego użytkownika

2. AUSERVAR - Zmienne użytkownika

    • Zawiera pola utworzone poprzez funkcje JavaScript xtdAjaxSetUserVar i xtdSetUserVar
    • Służy do rejestrowania danych klienta na serwerze

3. ASITE - Dokument witryny

    • Dostęp do wartości pól „Free setups” (ustawienia dowolne) rekordu witryny
    • <span adx='ASESSION.MyFreeField'></span> wyświetla wartość ustawień dowolnych kodu MyFreeField

4. AMESS - Komunikaty użytkownika

    • Zawiera komunikaty zwrócone przez X3

5. AUSERCRIT - Kryteria użytkownika

    • Kryteria wyboru są zapisywane i przywracane poprzez ustawienia xcrit HTML
    • <input type='text' adx='MyCriteria:xcrit'>

6. ASYSVAR - Zmienne systemowe

    • Zawiera wyłącznie pole ATODAY

7. ACONST - Pola tokenu stałej typu

Przetwarzanie zapytania HTTP

Zapytania HTTP

W strukturze X3WEB zwierającej serwer XTEND istnieją trzy poziomy aplikacji:

1. główny serwer HTTP Apache przetwarzający zapytania HTTP

2. serwer Apache Tomcat, na którym funkcjonują „Aplikacje sieciowe”

3. aplikacja sieciowa XTEND

Zapytania HTTP do aplikacji sieciowej XTEND są identyfikowane przez adres URL zaczynający się od /xtend/*.

„Ścieżka” aplikacji sieciowej XTEND może zostać ustawiona poprzez konsolę, za pomocą ustawień zaawansowanych:
xtend.server.virtualpath.context=xtend

Aplikacja sieciowa jest w stanie przetwarzać pewną ilość zapytań (serwletów) identyfikowanych poprzez konfigurację znajdującą się na drugim miejscu adresu URL /xtend/servlet/:

  • /xtend/page/* zarządza budową strony HTML
  • /xtend/data/* zarządza dostępem do danych pliku (obrazy, obiekty flash, pliki pdf...) na X3 lub w trybie lokalnym
  • /xtend/admin/* zarządza zapytaniami administratora przydatnymi dla programistów
  • /xtend/svc/* zarządza zapytaniami administratora przydatnymi dla programistów (log, zarządzanie cache, odświeżanie...)
Metoda GET lub POST

Protokół HTTP proponuje różne metody lub polecenia określające typ czynności, jaką wykonuje zapytanie.

Serwer XTEND odpowiada wyłącznie na metody GET i POST, co oznacza:

Łącze dynamiczne wykorzystuje, domyślnie, metodę POST, jeżeli jest do niej przypisany pewien zakres czynności.
Metoda ta zgłasza formularz HTML <form></form> strony poprzez wywołanie funkcji JavaScript xtdDoDlk.
Funkcja ta oblicza ustawienia łącza dynamicznego (xml) i wysyła je do ukrytego pola wejściowego.
Serwer otrzymuje wszystkie informacje, jakich potrzebuje do przetwarzania czynności lub zbioru powiązanego z klikniętym łączem dynamicznym (dane pól formularzy i kontekst obliczony przez klienta).

Link dynamiczny może wykorzystać metodę GET, wyłącznie jeżeli przekierowuje on stronę lub jeżeli nie istnieją ustawienia czynności lub zbiorów, jakie mają zostać obliczone.
Metoda ta nie zgłasza formularza HTML, ale przekierowuje przeglądarkę na adres URL zawierający wyłącznie ustawienia bazowe (łącze, rozwiązanie, katalog, witryna, język).

Tylko metoda GET jest kompatybilna z wyszukiwarkami (crawlerami).

Używanie „odwróconego proxy”

Dla bezpieczeństwa, możliwe jest użycie odwróconego proxy do dostępu do aplikacji z serwerów wewnętrznych.

Użycie odwróconego proxy umożliwia ukrycie rzeczywistego adresu serwera i ułatwia utrzymanie witryny.

W przypadku zatrzymania serwera możliwe jest tymczasowe przekierowanie zapytań na inny serwer bez wiedzy klienta.

Aby zdefiniować „odwrócone proxy” o aliasie proxyxtend w serwerze Apache serwera X3WEB hostproxy „przekierowujące” zapytania XTEND do hostxtendwykorzystywana jest następująca konfiguracja.

File Apache2.2\conf\httpd.conf

Tworzenie „wirtualnego hosta” na porcie 80

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

File 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>

Konfiguracja XTEND

W przypadku gdy serwer Apache hostproxy otrzyma następujący adres url http://hostproxy/proxyxtend/xtend/page/*.
zachowa się jako proxy i wykonuje dla klienta zapytanie http://hostxtend/xtend/page/* do serwera XTEND.

Serwer XTEND, obliczający stronę HTML, jaka ma zostać przesłana do klienta, musi uwzględniać odwrócone proxy, aby wygenerować adresy URL poprawne dla klienta końcowego (przeglądarki).

W naszym przypadku XTEND musi wygenerować adresy URL w/proxyxtend/xtend/*.
Musi on uwzględnić obecność odwróconego proxy w obliczaniu adresu URL.

Metoda, jaką wykorzystuje XTEND, jest następująca:

-1- Deklaracja odwróconych proxy

Deklaracja portów HTTP i HTTPS „odwróconych poxy” poprzez konsolę administracyjną, w której modyfikowane są następujące ustawienia zaawansowane:

# Konfiguracja odwróconych proxy
xtend.server.gensetup.proxies.hosts= hostproxy1 hostproxy2
xtend.server.gensetup.proxies.portshttp= 80 80
xtend.server.gensetup.proxies.portshttps= 443 443

-2- Odczyt „Referera” HTTP

Nagłówek Referera HTTP zawiera adres url używany przez klienta do osiągnięcia serwera.

Serwer XTEND analizuje ten adres URL i wykrywa obecność odwróconego proxy, jeżeli /xtend/ ma wartość jako prefix (na przykład: /proxyxtend/xtend/).

Poprzednia konfiguracja służy do zarządzania zmianami protokołu http->https i odwrotnie. XTEND musi znać porty HTTP i HTTPS odwróconego proxy.

Aby dobrze obsługiwać odwrócone proxy, serwer XTEND musi koniecznie znać „Referera” HTTP oraz porty HTTP i HTTPS (pierwszego) odwróconego proxy.

Ustawienia konfiguracji xtend.server.gensetup.http.askreferer=on/off (domyślnie włączone) służą do aktywowania lub deaktywowania tego mechanizmu.

Nagłówek „HTTP Referer” nie zawsze jest obecny, zwłaszcza przy wprowadzaniu adresu w pasek adresu przeglądarki.

W przypadku braku w zapytaniu nagłówka „Referera” HTTP, serwer XTEND przesyła do przeglądarki pusty formularz z odpowiedzią automatyczną (ukrytą dla użytkownika), która w większości przypadków przesyła „Referera”.

Jeżeli próba taka kończy się niepowodzeniem i „Referer” nie zostaje wysłany, serwer XTEND nie jest w stanie uwzględnić obecności odwróconego proxy.

Sesja

Protokół komunikacji pomiędzy przeglądarką a serwerem HTTP to protokół HTTP przebiegający na zasadzie „bez raportu”.
Serwer HTTP nie przechowuje jakichkolwiek śladów klienta po przetworzeniu zapytania.
Wszystko odbywa się w taki sposób, jakby połączenie pomiędzy klientem a serwerem urywało się po każdym zapytaniu.

Taki tryb funkcjonowania jest radykalnie odmienny od trybu klient/serwer (klient X3), który gwarantuje utrzymanie aktywnego połączenia z serwerem X3 przez cały czas trwania sesji.

Do tworzenia aplikacji sieciowych niezbędne jest połączenie różnych zapytań i powiązanie ich z tym samym klientem.
Połączenie to jest wykonywane z użyciem plików cookie HTTP.

Plik cookie jest tworzony z inicjatywy serwera, gdy ten przesyła klientowi instrukcję „set cookie” (ustaw cookie) do nagłówka HTTP.
Plik cookie jest w takiej sytuacji wysyłany przez klienta do nagłówka HTTP wszystkich zapytań do tego serwera

Instrukcja
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
Ścieżka służąca do filtrowania plików cookie wysyłanych do serwera
W naszym przykładzie, JSESSIONID jest wysyłane do wszystkich zapytań, których adres URL zaczyna się od /xtend/ (http://host:port/xtend/....)

Identyfikacja poprzez pliki cookie (a tym samym również funkcjonowanie aplikacji sieciowej) jest możliwa, wyłącznie jeżeli przeglądarka autoryzuje pliki cookie typu sesja (niezapisane).
Jest to, zazwyczaj, typowe ustawienie w przypadku przeglądarek sieciowych.

Pojęcie „klienta” bywa różne dla różnych przeglądarek i zależy od sposobu zarządzania plikami cookie.

  • W przypadku przeglądarki Firefoxpliki cookie są wspólne dla różnych uruchomień.
    Podczas logowania na tę samą witrynę XTEND, z tej samej stacji roboczej przez dwie przeglądarki Firefox, ta druga nie posiada tej samej sesji XTEND.
    Przeglądarki są widziane jak dla przeglądarek jako ten sam klient.
  • W przypadku przeglądarki IE6, pliki cookie nie są wspólne dla różnych uruchomień.
    Podczas logowania na tę samą witrynę XTEND, z tej samej stacji roboczej przez dwie przeglądarki IE6, ta druga posiada oddzielną sesję.
    Przeglądarki są widziane jak dla przeglądarek jako dwóch różnych klientów.
  • W przypadku jednej przeglądarki zakładki mają te same pliki cookie i są widoczne jako ten sam klient.
Sesja TOMCAT

Sesja użytkownika służąca do powiązania określonego kontekstu danych z każdym z klientów jest zarządzana przez serwer TOMCAT poprzez podejście serwletowe.

Aby zidentyfikować zapytania i przekierować je do prawidłowej sesji użytkownika, TOMCAT używa określone pliki cookie sesji o kodzie JSESSIONID.

Pliki cookie zarządzane przez serwer TOMCAT
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
JSESSIONID jest identyfikatorem sesji TOMCAT

Plik cookie JSESSIONID nie jest plikiem długotrwałym, to znaczy nie jest przechowywany po zamknięciu przeglądarki.
Podczas zamykania przeglądarki sesja, a tym samym kontekst danych, zostają utracone.

Sesja jest przechowywana w pamięci przez okres, który może zostać ustawiony w ustawieniach konfiguracji konsoli.
xtend.server.gensetup.http.session.timeout
Ustawienie to wskazuje czas bezczynności, w minutach, zatwierdzony dla sesji użytkownika przez serwer TOMCAT.
W przypadku niestwierdzenia w tym czasie aktywności (otrzymane zapytanie) sesja zostaje usunięta, a kontekst danych utracony.

Mechanizm ponownego połączenia

Serwer XTEND zarządza swoim własnym identyfikatorem sesji poprzez plik cookie XADXID .
Jest do długotrwały plik cookie, co oznacza że jest on zapisywany przez przeglądarkę (jeżeli został autoryzowany).

Po uruchomieniu przeglądarki przez użytkownika i ponownym połączeniu z serwerem XTEND, plik cookie XASXID jest przesyłany w zapytaniu (jeżeli istnieje), a serwer próbuje odnaleźć sesję (TOMCAT) użytkownika, w celu ponownego połączenia.

Pliki cookie zarządzane przez serwer XTEND
Set-Cookie XADXID=123332746651556912893670; Expires=Sat, 30-Jan-2010 14:57:46 GMT; Path=/xtend

Ustawienia konfiguracji konsoli xtend.server.gensetup.http.cookie.sess.persist=on (domyślnie włączone) służą do aktywowania/deaktywowania zarządzania ponownym połączeniem po zamknięciu przeglądarki.

Strona ponownego połączenia witryny (opcjonalna) służy do informowania o przywróceniu sesji.

Działanie bez plików cookie

XTEND proponuje tryb funkcjonowania bez plików cookie, propagujący identyfikator sesji JSESSIONID w adresie URL.

Tryb ten może zostać aktywowany:

  • Przez użytkownika poprzez czynność sieciową ASESSSWITCHCOOKIES lub poprzez łącze dynamiczne ADLKSWITCHCOOKIES lub
  • W sposób domyślny dla wszystkich sesji - poprzez ustawienia konsoli konfiguracji
    xtend.server.gensetup.http.cookie.disabled=on - domyślnie wyłączone.

Tryb funkcjonowania bez plików cookie zwiększa rozmiar adresu URL poprzez dodanie ustawienia:
http://ecfdalbopro:28980/xtend/page;jsessionid=E04AEF0615702B3C7E52107ED6C17D8A?DLK=DLKTESTMAPPING...

Tryb ten nie umożliwia użycia łącza do innych witryn internetowych, z uwagi na fakt że identyfikator sesji nie jest propagowany, a sesja użytkownika zostaje utracona.

Przetwarzanie serwera

Poniższy akapit opisuje proces przetwarzania zapytań HTTP przez serwer XTEND.

Serwer HTTP Apache

1. Otrzymanie zapytania HTTP

    • Zarządzanie zabezpieczonym protokołem HTTPS

2. Filtrowanie zapytań w zależności od adresu URL

  • XTEND przetwarza wyłącznie adresy URL zaczynające się od „/xtend/*”
    Ustawienia konsolixtend.server.virtualpath.context
  • Jest to httpd.conf zawierające konfigurację serwera Apache
    Plik ten jest generowany podczas konfiguracji serwera X3WEB

3. Przesyłanie zapytania do „Serwera Apache TOMCAT” poprzez mod_jk
mod_jk : „Jakarta module” jest nazwą darmowego projektu informatycznego, którego rezultatem jest projekt TOMCAT

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

Serwer Apache TOMCAT

1. Tworzy zadanie (wątek) dla przetwarzania zapytania

2. Odnajduje (usługę obiektu serwletowego) wskazanego przez adres URL

    • /xtend/page/* dla przetwarzania stron HTML

3. Odnajduje sesję z plikiem cookie JSESSIONID

    • Tworzy nową sesję, jeżeli sesja nie może zostać odnaleziona

4. Wywołuje metodę doPost lub doGet usługi

    • Ustawienia httpRequest zawierają dane zapytania http oraz sesji użytkownika
    • Od tego miejsca rozpoczyna się przetwarzanie aplikacji sieciowej XTEND
Aplikacja sieciowa XTEND

1. Inicjalizacja

1. W przypadku nowej sesji TOMCAT

    • Przetwarzanie ponownego połączenia poprzez plik cookie XADXID
    • Żądanie referera http (uwzględnienie „odwróconych proxy”)

2. W przypadku przekierowania (zmiana protokołu itp.)

    • Przetwarzanie przekierowania adresu URL

3. Odczyt ustawień XTEND

    • Metoda GET: Ustawienia adresu URL
    • Metoda PUT: Ustawienia XML w polu XTDXML formularza HTML
      Ustawienia: kliknięte łącze dynamiczne, żądana strona, ustawienia czynności itp

2. Otwarcie sesji

1. Wstrzymanie sesji użyte przez inne zapytanie

    • Konsola ustawień xtend.session.wait.timeout

2. Pozycjonowanie kontekstu na witrynie XTEND

    • Kod SolutionX3/DossierX3/SiteXtend jest wykorzystywany jako ustawienia dla każdego zapytania
    • Jeżeli nie istnieją ustawienia lub witryna, domyślną witryną jest ta, która została wybrana
    • Konsola ustawień xtend.server.gensetup.defsite.x3sol,x3fldr,xtdSite

3. Weryfikacja uaktualnień słownika XTEND

    • Techniczne ustawienia witryny „Verify updates” (Weryfikuj aktualizacje)

3. Sterowanie

1. Kontrola protokołu

    • Jeżeli wybrany protokół (http lub https) zapytania nie został zdefiniowany dla danej strony
      • Wysyłanie przekierowania do klienta (status Http=302) w celu zmiany protokołu

2. Jeżeli użytkownik jest zalogowany: kontrola czasu bezczynności w ramach sesji XTEND

    • Ustawienia czasu oczekiwania (w min) rekordu witryny

3. Jeżeli strona jest chroniona
Ustawienia „Protected access” (dostęp chroniony) rekordu strony

1. Kontrola praw dostępu użytkownika

    • Kontrola zależna od profilu, jeżeli użytkownik jest zalogowany

2. Jeżeli użytkownik nie posiada właściwych praw dostępu

    • Przekierowanie na stronę logowania zdefiniowaną w rekordzie witryny
    • Zapisanie kontekstu (czynność, strona docelowa) w celu przywrócenia go po zalogowaniu.

4. Przetwarzanie czynności sieciowych jeżeli czynność jest związana z łączem dynamicznym

  • Czynność może zmieniać stronę docelową
  • Na przykład, jeżeli nastąpi błąd, obecna strona wyświetlana jest w dalszym ciągu razem z komunikatem X3

5. Wyświetlanie strony

1. Weryfikacja aktualizacji strony

          • Techniczne ustawienia witryny „Verify updates” (Weryfikuj aktualizacje)

2. Inicjalizacja tokenów bloków (zapytań)

          • Wywołanie usług sieciowych typu „dostęp do danych”

3. Obliczenie HTML

          • Przejście przez strukturę drzewa tokenu
          • Wywoływanie metody computeHtml

6. Wysłanie odpowiedzi do przeglądarki