Funcionamento de XTEND 

O dicionário

O dicionário contém a definição de todas as fichas de parametrização XTEND.

Está constituido de um conjunto de ficheiros XML (um por função XTEND) que estão guardados sobre o servidor da solução X3 no directório:
X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_GEN/SITE

Validação

Quando o programador valida uma ficha, um tratamento de geração do dicionário está ativada para produzir o ficheiro xml.

A validação gera um novo dicionário XML dos parâmetros XTEND.

O novo dicionário só está tomado em conta automaticamente sobre reload/F5 da página HTML no navegador que se a opção da ficha de parametrização do estabelecimento, função Estabelecimentos Web (GESAYS)"Técnica\Verificar atualizações\Dicionário web" está assinalada.

Senão falta forçar o recarregamento do dicionário com URL :
http://hostname:port/xtend/svc/SolutionX3/DossierX3/SiteXtend/admin/reposit/reload

Após modificação dos parâmetros X3 :

É aconselhado de validar a integralidade do estabelecimeto via a função afim de reconstruir o dicionário do servidor XTEND via a funçãoValidação estabelecimento Web(AYTFCYGEN).

Bem verificar que o estabelecimento está publicado, quer dizer o campo "Publicado" o estabelecimento da ficha"Estabelecimento web" está assinalada.

Acesso aos ficheiros X3

Tecnicamente o servidor XTEND acede aos ficheiros X3 via o servidor HTTP (Apache) que é instalado por defeito sobre a máquina que alberga o servidor X3 principal.

O directório raíz é o diretório X3_PUB da solução.

A deteção das atualização se faz sobre leitura do "TimeStamp" (data de útima modificação) do ficheiro.

O servidor XTEND lê os ficheiros XML e constitui uma base de dados em memória para optimizar o acesso aos parâmetros.

No momento do carregamento, XTEND controla a coerência do dicionário e gera uma exceção em caso de erro.

Em caso de erro de leitura do dicionário
  • Verificar que os utilizadores anónimos podem aceder ao directório X3_PUB
    A URL http://hostX3/Adonix_X3SOL/X3FOLDER/X_TEND/X_GEN/XTENDSITE/deve reenviar a lista dos ficheiros xml
  • Sob UNIX verifique os direitos de acesso de utilizador
Otimização

Por defeito o dicionário e os menus locais são guardados sobre o servidor X3

Os parâmetros consola xtend.server.reposit.local=off e xtend.server.menux3.local=off permitem de definir uma localização dos ficheiros em local do servidor X3WEB (optimização).

Neste caso falta copiar os diretórios dicion+ario e/ou menus locais sob \WebData\LOCAL\X3SOLUTION\X3_PUB\.

WebData é o directório "Data" definido no momento de instalação do servidor X3WEB.

Tratamento do HTML

Leitura

Por defeito as páginas e todos os recursos do projeto HTML são guardados sobre o servidor X no directório :
/X3SOL/dossiers/X3_PUB/X3FOLDER/X_TEND/X_HTML/ASAMPLE/LANG/ (LANG sendo o código do estabelecimento).

O programador deve pensar a "uploader" as páginas HTML sobre o servidor X3 antes de testar no seu navegador.

Sob unix falta bem de verificar que todos os ficheiros do directório HTML têm os direitos mínimo em "leitura" para todos os utilizadores.

O processo de leitura das páginas e de deteção das modificações está idêntico àquele do dicionário.

Um parâmetro do estabelecimento XTEND permite ativar/desativar as verificações das atualizações.

Se a verificação está desactivada falta utilizar o url de recarregamento do dicionário para forçar o servidor XTEND a tomar em conta as modificações das páginas.

Análise

Uma página web é um ficheiro texto que contém as balisas HTML nos quais o programador acrescentou os tokens XTEND.

Após carregamento da página, o servidor XTEND lê o conteúdo e interprete o HTML e os tokens (análise) para constituir uma representação em memória da página sob a forma de arborescência de objetos (DOM).

Cada objeto representa um token e implementa um método de cálculo de HTML (computeHtml).

A arborescência dos tokens está visível no rasto XTEND:
++ corresponde ao nível - CXtdHtmBuild* é a classe de objecto

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

A analisar HTML do servidor XTEND está compatível com a versão HTML 4.01 (DTD HTML 4.01 Transitional).

O único constrangimento que impõe XTEND para o design HTML é de não utilizar que um único formulário HTML que encapsula todo o corpo (body) da página HTML.
<body><form> Conteúdo do body </form></body>

Construção

Para calcular dinamicamente o conteúdo da página HTML, o servidor XTEND efetua as operações seguintes :

1. Inicializa os blocos

Para os interfaces de tipo Acesso dados:

  • Constitui o pedido (seleção) em função dos parâmetros
  • Chama o web service via a interface assoicada à entidade do bloco
  • Criado as entidades "Acesso dados" em memória

Para os interfaces de tipo Ação:

  • Lê as entidades já apresentadas em memória
2. Percorre recursivamete todos os objetos da arborescência (DOM) e chamam o método computeHtml

Se o token é um campo

  • O método calcula o valor do campo

Se o token é uma ligação dinâmica :

  • O método calcula a URL (tag <a></a>) ou o JavaScript (tag <imput type="botão")

Se o token é um bloco:

  • O método efectua uma iteração sobre todas as entidades e chama o método de cálculo dos tokens filhos

Se o token é um bloco condicionado:

  • O método avalia a expressão boleana (critérios) e chamada ou não o método de cálculo dos tokens filhos.
3. O resultado global é a soma do HTML produto por todos os tokens

O método de cálculo do HTML depende do tipo de token e do tag HTML no qual está inserido.

Geração do html

o HTML calculado é função do tipo de token e do tag HTML no qual está inserido.

Token campo nos tags <td>,<div>, <span>, <p>...

Preenche o conteudo do tag por valor do campo

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

Token campo num tag <select>

Seleciona a opção que corresponde ao valor do campo em gerando o atributo selecionado.

Exemplo se o valor de myField é FR a opção valor ="FR" e seleccionada (atributo selecionado)

<select adx="myField">
    <option value="AT">Austria</option>      
    <option value="FR">França</option>
</select>
<!--GENERE-->
<select adx="myField">
    <option value="AT">Austria</option>        
    <option selected value="FR">França</option>
</select>

Token campo num tag <img>

Gera URL que permite ao navegador de ler a imagem

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

Token ligação dinâmica num tag <a>

Se o token não está associado (método GET) calcula o atributo href do tag
Senão (método POST) trata o tag como um botão (a seguir).

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

Token ligação dinâmica num tag <input type="button">

Calcula a função JavaScript xtdDoDlk e insere no atributo "onClick"

Os parâmetros são contextuais e são tratados pela livraria XTEND

<input type="botão" adx="MyDLK" value="Criar">
<!--GENERE L'ATTRIBUT ONCLICK'-->
<input type="botão"
   onclick="xtdDoDlk(this,'MyDLK',null,null,null,0,null,event,true,'',false,null,true);"
   value="Criar"/> 

Função xtdDoDlk

Esta função está gerada por XTEND no atributo onClick para as ligações dinâmicas que têm uma ação ou uma seleção associada.

Ela desencadeia o processo JavaScript XTEND de tratamento das ações utilizador.

Ela permite também reencontrar o contexto de dados (aCtxTag,aLineIdx) da ligação dinâmica em particular para os tokens gerados nas linhas dos blocos.

function xtdDoDlk(aElmt,aDlk,aProtocol,aBlkId,aCtxTag,aLineIdx,aUrlAdd,aEvent,aSubmit,
                  aAutoId,aForceAcceptReload,aForceSelBlock,aCheckWebFields)
{/*
 aElmt: Objeto JavaScript sobre o qual o utilizador clicou
aDlk: Código da ligação dinâmica clicado
aProtocol: Se "!=null" força o protocolol (https,http) para esta ligação
aBlkId: Código de bloco de referência se adx='MyBlocRefence.MyLink'
 aCtxTag: Identificador do contecto de dados (se ação com parâmetros de tipo campos XTEND)
aLineIdx: Índice da linha se token está colocado num bloco {{multi}}
 aUrlAdd: Contém o valor dos parâmetros HTML xanchor adx="MyLink:xanchor=#section"
 aEvent: Contém o objeto evento JavaScript
aSubmit: Verdade para submeter o formulário
aAutoId: Id gerado por XTEND se adx="MyLink:xautoid"
aForceAcceptReload:Verdade para aceitar o reload (F5)
aForceSelBlock:Id do bloco que trata o pedido se "!= AMAIN"
 aCheckWebFields:Verdade para controlar os campos web
*/
}  

O contexto de dados da página está guardada na página de uma mesma tag span mascarada.
Contém todos os valores dos campos (tipo "Token champ") utilizados em parâmetro das ações das ligações dinâmicas da página.
Este método permite gerar muito eficazmente o retorno atrás via a função "Back" do navegador.

<span id="xtdctx" style="display: none; clear: both;>
XML que contém o contexto da página
</span>

O contexto de dados servidor

Para bem compreender o funcionamento XTEND é necessário de detalhar o mecanismo de resolução do valor de um campo pelo servidor XTEND.

O servidor XTEND mantém um contexto de dados que está gerado numa pilha (ou stack) de blocos de dados (entidades).

Este contexto de dados está constituido:

  • De uma parte estática, independentemente da página
      • Constituido dos dados a sessão utilizador quer dizer as entidades de tipo "sessão" e das entidades de tipo "ação"
  • De uma parte dinâmica, dependente dos tokens blocos inseridos na página
      • Constituida das entidades de tipo "acesso de dados" criados no momento do tratameto dos tokens blocos.
Gestão do contexto

Lista inicial

Quando a construção da página arranca, o contexto de dados não contém que os dados da sessão.

Tratamentos dos blocos

Quando o servidor XTEND trata um bloco, efetua uma iteração sobre todas as entidades selecionadas.
Para cada entidade efetua o tratamento seguinte:

1. Empilha (empurra) o dado (entidade) no contexto de dados
--> A entidade está posicionada ao extremo da pilha (top) e será tratado em primeiro no momento da resolução do valor de um campo.

2. Chama o método de construção do HTML dos tokens filhos
--> Este mecanismo está recursivo e permite de emplihar os blocos

3. Depila a entidade
-->Após ter tratado todos os tokens filhos o servidor depila antes de tratar a seguinte

A entidade que está no extremo da pilha está endereçada pelo bloco ACURRENT.
Por exemplo um critério de seleção "CODE=ACURRENT.CODE" numa ligação dinâmica indica que falta selecionar o elemento da linha corrente.

Resolução

O princípio de resolução do valor de um campo consiste a :

1. percorrer a pilha das entidades do alto (topo) versus o baixo (fundo)

2. se parar quando a entidade lida contém um campo de mesmo nome

Se um campo foi encontrado XTEND reenviará o valor deste campo senão reenviará um valor vazio.

O exemplo a seguir mostra a lista da pilha com um bloco de "fundo" mono-registo (BLOCMONO) dois blocos multi-registos imbricados (BLOCMULTI1, BLOCMULTI2).

O primeiro bloco multi está posicionado sobre a 2ª linha e o segundo bloco (BLOC2) está posicionado sobre a 3ª linha

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

Pilha

Ordem

 ASESSION

3 - Fundo

ENTITE_BLOCMONO

2

ENTITE_BLOCMULTI1_LIGNE2

1

ENTITE_BLOCMULTI2_LIGNE3

0 - Top

Para resolver o valor do campo MyField o servidor XTEND vai verificar a presença do campo MyField nas entidades seguindo a ordem a seguir-

1. ENTITE_BLOCMULTI2_LIGNE3

2. ENTITE_BLOCMULTI1_LIGNE2

3. ENTITE_BLOCMONO

4. ASESSION

O princípio de resolução do valor é o mesmo para :

  • Os tokens campos
  • Os parâmetros/critérios de tipo "Token campo" (MonBloc.MonChamp) utilizados em :
      • Os critérios de seleção dos blocos e ligações dinâmicas
      • Os parâmetros das ações web
      • Os critérios das fórmulas dos blocos condicionados

Para calcular o valor de um campo por uma entidade dada falta utilizar as sintaxes seguintes:

  • ASESSION.MyField
      • Lê o valor no contexto da sessão
  • MyBlock.MyField
      • Se MyBlock está um bloco mono-registo lê o valor do campo para este bloco.
      • Se MyBlock está um bloco mono-registo lê o valor do campo para a linha selecionada
  • MyBlock(i).MyField
      • Lê o valor do campo para a í-ésima linha do bloco (i começa a 1)
Resolução no contexto sessão

O contexto sessão está constituida dos diferentes blocos de dados a seguir

A resolução do valor de um campo está efectuado seguinte a ordem de apresentação dos blocos na lista.

1. AUSERINF - Informações utilizador assinado

2. AUSERVAR - Variáveis utilizador

    • Contém os campos criados via as funções JavaScript xtdAjaxSetUserVar et xtdSetUserVar
    • Utilizado para salvaguardar os dados cliente sobre o servidor

3. ASITE - Documento estabelecimento

    • Acesso aos valores dos campos "Parâmetros livre" da ficha do estabelecimento
    • <span adx="ASESSION.MyFreeField"></span> afixa o valor do parâmetro livre de código MyFreeField

4. AMESS - Mensagens utilizador

    • Contém as mensagens reenviadas por X3

5. AUSERCRIT - Critérios utilizador

    • Os critérios de seleções são salvaguardados e restauradas via o parâmetro HTML xcrit
    • <input type="text" adx="MyCriteria:xcrit">

6. ASYSVAR - Variáveis sistemas

    • Contém unicamente o campo ATODAY

7. ACONST - Tokens campo de tipo constantes

O tratamento de um requerimento HTTP

Os pedidos http

Na arquitetura X3WEB que alberga o servidor XTEND nós temos 3 camadas aplicativas:

1. o servidor frontal Apache HTTP que trata os pedidos HTTP

2. o servidor Apache Tomcat que alberga as "aplicações web"

3. a aplicação web XTEND

Os pedidos http com destino de aplicação web XTEND seja identificado por URL que começa por /xtend/*.

O "path" da aplicação web XTEND está parametrizada via a consola via o parâmetro avançado:
xtend.server.virtualpath.context=xtend

A aplicação web sabe tratar um certo número de pedidos (servlets) identificados pelo 2º parâmetro de URL /xtend/servlet/ :

  • /xtend/page/* gera a construção da página HTML
  • /xtend/data/* gera o acesso aos dados ficheiros (imagens, fklash, ficheiro pdf...) sobre X3 ou en local
  • /xtend/admin/* gera os pedidos de administração úteis para o programador
  • /xtend/svc/* gera os pedidos de administração úteis para o programador (rasto, gestão escondida, reload...)
Método GET ou POST

O protocolo HTTP propõe diferentes métodos ou encomendas que especificam o tipo de ação que efetua o pedido.

O servidor XTEND não responde que aos métodos GET e POST que têm o significado seguinte:

Uma ligação dinâmica utiliza por defeito o método POST se uma seleção ou uma ação lhe está associada.
Este método submete (submit) o formulário HTML <form></form> da página via a chamada da função JavaScript xtdDoDlk.
Esta função calcula os parâmetros da ligação dinâmica (xml) e os envia num campo input hidden.
O servidor recebe todas as informações cuja tem necessidade para tratar a ação ou a seleção associada à ligação dinâmica sobre a qual clicou (dados dos campos do formulário e contexto calculado para o cliente).

Uma ligação dinâmica pode utilizar o método GET se efectua apenas um desligar versus uma página ou se não tem parãmetro de ação ou de seleção a calcular.
Este método não submete um formulário HTML mas desliga o navegador versus um URL que não contém que os parâmetros de base (ligação, solução, dossier, estabelecimento, língua).

Apenas o método GET está compatível com os motores de pesquisa (web crawlers).

Utilização de um "reverse proxy"

Por razões de segurança, o utilizador do web pode passar pelo intermédio de um "reverse proxy" para aceder às aplicações de servidores internos.

A utilização de um "reverse proxy" permite mascarar aos utilizadores o endereço real de um servidor e facilita a manutenção de um estabeleciemento.

Em caso de paragem de um servidor poder-se-á redirigir temporáriamnte os pedidos versus um outro servidor de maneira transparente para o cliente.

Para definir um "reverse proxy" de alias proxyxtend no servidor Apache do servidor X3WEB hostproxy que "redirige" os pedidos XTEND versus hostxtend utiliza-se a configuração seguinte.

Ficheiro Apache 2.2\conf\httpd.conf

Criar um "virtual host" sobre a porta 80

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

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

Configuração XTEND

Quando o servidor Apache "hostproxy" recebe url http://hostproxy/proxyxtend/xtend/page/*.
Il vai se comportar como um mandatário e efectuar para o cliente http://hostxtend/xtend/page/* versus o servidor XTEND.

O servidor XTEND que vai calcular a página HTNL a reenviar versus o cliente deve tomar em conta o "reverse proxy" para gerar as URLs que sejam correctas para o cliente final (o navegador).

No nosso caso, XTEND deve gerar os URLs em /proxyxtend/xtend/*.
deve então imperativamente ter em conta da presença do "reverse proxy" para calcular o URL.

O método utilizado por XTEND é o seguinte :

-1- Declaração dos "reverse proxies"

Declaração dos ports http e htttps dos "reverse proxies" via a consola de aministração em modificando os parãmetros avançados seguintes :

# Configuração "reverse proxies"
xtend.server.gensetup.proxies.hosts=      hostproxy1   hostproxy2
xtend.server.gensetup.proxies.portshttp=  80           80
xtend.server.gensetup.proxies.portshttps= 443          443

-2- Leitura do "Referer" HTTP

O header HTTP Referer contém a url que deve ser utilizado pelo cliente para juntar o servidor

O servidor XTEND analisa esta URL e deduz a presença de um "reverse proxy" se /xtend/ está prefoixado por um valor (exemplo /proxyxtend/xtend/).

A configuração precedente permite gerar a alteração de protocolo http->https ou inverso O servidor XTEND deve obrigatóriamente conhecer as portas http e https do "reverse proxy"

Para funcionar correctamnte com um "reverse proxy" o servidor XTEND deve então obrigatoriamente conhecer a "Referir" http e as portas http e https do (primeiro) "reverse proxy".

O parãmetro de configuração xtend.server.gensetup.http.askreferer=on/off ("on" por defeito) permite ativar ou desativar este mecanismo.

O cabeçalho http "Referir" não está sempre presente, em particular quando se regista o endereço na barra do navegador

Se o header http "Referir" não está presente no pedido, o servidor XTEND envia versus o navegador um formulário vazio com resposta automática (transparente para o utilizador) que na maior dos casos reenvia o "Referir"

Se a tentativa encalha e que o "Referer" não está reenviado, o servidor XTEND não poderá tomar em conta a presença de um "reverse proxy"

A sessão

O protocolo de comunicação entre o navegador web e o servidor HTTP está o protocolo HTTP que está "sem lista".
O servidor HTTP n~sao conserva nenhum rasto do cliente após o tratamento do pedido.
Tudo se passa como de a conexão entre o cliente e o servidor está cortado após cada pedido.

O modo de funcionamento está completamente diferente do modo cliente/servidor (cliente X3) que mantém uma conexão ativa com o servidor X3 durante toda a duração da sessão

Para desenvolver as aplicações web nós temos necessidade de fazer a ligação entre diferentes pedidos para as associar a um mesmo cliente.
Esta ligação está efectuada via a utilização dos cookies HTTP.

Um cookie está criado à iniciativa do servidor qundo este envia ao cliente uma instrução "set cookie" no cabeçalho HTTP.
O cookie está em seguida reenviado pelo cliente no cabeçalho HTTP de todos os pedidos com destino a este servidor.

Instrução
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
Path permite filtrar os cookies com destino do servidor
No nosso caso JSESSIONID será reenviado em todos os pedidos cujo URL começa /xtend/ (http://host:port/xtend/....)

A identificação por cookie (e logo o funcionamento de aplicaçao web) não funciona que se o navegador autoriza os cookies de tipo sessão (não salvagurdados).
É geralmente a regularização por defeito dos navegadores web.

A noção de "cliente" difere seguinte os navegadores e depende da maneira cujo geram os cookies.

  • Para FireFox os cookies são partilhados entre as instâncias dos navegadores.
    Se se coneta a um mesmo estabelecimento XTEND sobre o mesmo posto com dois nacegadores FireFox partilharão a mesma sessão XTEND.
    Os navegadores são vistos de lado como um limite cliente.
  • Para IE6 os cookies são partilhados entre as instâncias dos navegadores.
    Se se coneta a um mesmo estabelecimento XTEND sobre o mesmo posto com dois navegadores IE6 terão cada um a mesma sessão.
    Os navegadores são vistos de lado como dois clientes diferentes.
  • Os separadores ao seio de um mesmo navegador partilham os mesmos cookies e são vistos como um único cliente.
Sessão TOMCAT

A sessão utilizador que permite associar um contexto de dados específicos a cada cliente está gerado pelo servidor TOMCAT via a noção de servlet.

Para identificar os pedidos e os redirigir versus a boa sessão uilizador o servidor TOMCAT gera um cookie sessão específico de código JSESSIONID.

Cookie gerado pelo servidor TOMCAT
Set-Cookie: JSESSIONID=3C9B3EF39FB53069ACB02B6ADA5551A1; Path=/xtend
JSESSIONID é o identificador de sessção TOMCAT

O cookie JSESSIONID não é persistente, quer dizer que não foram conservados quando se fecha o navegador.
O utilizador perde então sessão e logo o seu contexto de dados se fecha o ser navegador.

A sessão está conservada em memória durante uma duraação parametrizável via o parâmetro de configuração consola :
xtend.server.gensetup.http.session.timeout
Este parâmetro indica a duração de inatividade, em minutos, tolerado pelo servidor TOMCAT para uma sessão utilizador.
Se nenhuma atividade (requerimento recebido) não está detetado durante este período, a sessão está suprimida e o contexto de dados está perdido.

Mecanismo de reconexão

O servidor XTEND gera o seu próprio identificador de sessão via o cookie XADXID.
Este cookie é persistente, quer dizer que está salvaguardado pelo navegador (se autorizado).

Quando o utilizador abre o seu navegador e se conecta ao servidor XTEND, o cookie XASXID está enviada no pedido (se existe) e o servidor ensaia de reencontrar a sessão (TOMCAT) de utilizador para o reconectar.

Cookies gerados pelo servidor XTEND
Set-Cookie XADXID=123332746651556912893670; Expires=Sat, 30-Jan-2010 14:57:46 GMT; Path=/xtend

O parâmetro de configuração consola xtend.server.gensetup.http.cookie.sess.persist=on ("on" por defeito) permite de ativar/desactivar a gestão da reconexão seguinte ao fecho do navegador.

A página de reconexão do estabelecimento (facultativo) permite informar o utilizador que a sua sessão está retaurada.

Funcionamento sem os cookies

XTEND propõe um modo de funcionamento sem cookies que propaga o identificador de sessão JSESSIONID em URL.

Este modo pode ser seja ativado:

  • Pelo utilizador via a ação web ASESSSWITCHCOOKIES ou a ligação dinâmica ADLKSWITCHCOOKIES
  • Por defeito para todas as sessões via o parâmetro de configuração consola
    xtend.server.gensetup.http.cookie.disabled=on - "off" por defeito

O modo sem cookies aumenta o tamanho das URLs em acrescando um parâmetro suplementar:
http://ecfdalbopro:28980/xtend/page;jsessionid=E04AEF0615702B3C7E52107ED6C17D8A?DLK=DLKTESTMAPPING...

Este modo não permite a utilização de ligações versus outros estabelecimentos web porque o id da sessão não está propagado e a sessão utilizador está perdido.

Tratamento servidor

Este parágrafo descreve o porcesso de tratamento dos pedidos HTTP pelo servidor XTEND.

Apache HTTP Server

1. Receção do pedido HTTP

    • Gera o protocolo segurança HTTPS

2. Filtra o pedido em função de URL

  • Apenas asURLs que começam por '/xtend/*' são tratados por XTEND
    Parâmetro consola xtend.server.virtualpath.context
  • É o ficheiro "httpd.conf" que contém a configuração do servidor Apache
    Este ficheiro está gerado no momento da configuração do servidor X3WEB

3. Transferência do pedido versus "Apache TOMCAT servidor" via o "mod_jk
mod_jk" : "módulo Jakarta" que é o nome do projecto de softwares livres dos quais está emitido o projeto 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

Apache TOMCAT server

1. Cria uma tarefa (thread) para o tratamento do pedido

2. Reencontra o serviço (objet servlet) identificado por URL

    • /xtend/page/* para o tratamento das páginas HTML

3. Reencontra a sessão com o cookie JSESSIONID

    • Cria uma nova sessão se não encontrada

4. Chama o método doPost ou doGet do serviço

    • Um paâmetro httpRequest contém os dados do pedido http e a sessão utilizador
    • O tratamento da "web application" XTEND começa aqui
"Web application" XTEND

1. Inicialização

1. Se nova sessão TOMCAT

    • Tratamento reconeção via o cookie XADXID
    • Pedido http referir (tomada em conta dos "reverses proxies")

2. Se redireção (alteração de protocolo...)

    • Tratamento da redireção de URL

3. Leituras dos parâmetros XTEND

    • Método GET : Parâmetros de URL
    • Método PUT : Parâmetros XML no campo XTDXML do formuilário HTML
      Parâmetros : ligação dinâmica clicada, página pedida, parãemtros de ação...

2. Abertura sessão

1. Colocação em espera se sessão em curso de utilização por um outro pedido.

    • Parâmetro console xtend.session.wait.timeout 

2. Posicionamento do contexto sobre o estabelecimeto XTEND

    • O código SolutionX3/DossierX3/SiteXtend está passado em parãmetro de cada pedido.
    • Se sem parãmetro ou estabelecimento inexistente, é o estabelecimento por defeito que é escolhido.
    • Parâmetros consola xtend.server.gensetup.defsite.x3sol,x3fldr,xtdSite 

3. Verificação das utilizações do dicionário XTEND

    • Parâmetros técnicos do estabelecimento "Verificar a atualização"

3. Controlos

1. Controlo do protocolo

    • Se o protocolo (http ou https) do pedido não está definido para a página
      • Envia de uma redireção ao cliente (Http status=302) para mudar de protocolo

2. Se o utilizador assinado : controlo duração de inactividade da sessão XTEND

    • Parâmetro 'Timeout session(mn)' da ficha estabelecimento

3. Se a página está protegida
Parâmetro "Acesso protegido" da ficha página 

1. Controlo dos direitos de acesso do utilizador

    • Controlo em função do perfil se utilizador assinado

2. Se utilizador não tem os direitos de acesso

    • Redireção versus a página de login definida na ficha estabelecimento
    • Salvaguarda do contexto (página destino, ação) para restauração após login

4. Tratamento de ação web se uma ação está associada à ligação dinâmica.

  • A ação pode modificar a página de destino
  • Por exemplo se um erro se produz resta sobre a página corrente e se afixa a mensagem X3

5. Afixação da página

1. Verificação das atualizações da página

          • Parâmetros técnicos do estabelecimento "Verificar a atualização"

2. Inicialização dos tokens bloco (pedidos)

          • Chamada dos web service tipo Acesso dado

3. Cálculo do HTML

          • Percurso da arborescência dos tokens
          • Chama o método compute-HTML

6. Envio da resposta ao navegador