## Guida alla integrazione di applicazioni a livello di User Interface

### Tipologie di integrazione

L'integrazione tra applicazioni a livello di user interface è una delle modalità di integrazione tra applicazioni. Un'altra modalità è rappresentata dall'integrazione tramite back end comune SOA, che però non è oggetto di questa guida. L'integrazione tra due applicazioni a livello di user interface si esplicita tramite una operatività che l'utente attua in parte sulla prima applicazione e in parte sulla seconda, talvolta condividendo a livello logico parte del contesto applicativo oppure il contesto di sicurezza.

I tipici scenari in cui entra in gioco questo tipo di integrazione sono:

1. passaggio di controllo tra applicazione principale / applicazione accessoria (esempio: applicazione di workspace di un sistema di BPM - applicazioni che realizzano i task di human interaction del processo)
2. coabitazione di applicazioni in un sistema di single-sign-on

Per ottenere questo tipo di integrazione (specialmente per quanto riguarda lo scenario #1)tipicamente è necessario predisporre opportunamente sia l'applicazione chiamante che quella chiamata. Di seguito sono descritti i passi da compiere utilizzando guigen.

### Predisposizione alla integrazione in entrata (applicazione "chiamata")

Di seguito le attività da svolgere in guigen sull'applicazione chiamata per predisporsi ad essere invocata da un'altra applicazione.

#### Predisposizione alla ricezione di parametri di attivazione e inizializzazione del contesto applicativo

In molti casi l'applicazione chiamata, per poter svolgere correttamente il suo compito, necessita di un contesto applicativo inizializzato all'ingresso nell'applicazione e dipendente dal contesto applicativo presente nell'applicazione chiamante al momento della chiamata. Un tipico esempio di questo è rappresentato dalla mini-app di un processo BPM che deve venire innescata in modo da operare sulla istanza del processo selezionata nell'applicazione chiamante (il workspace). Per fare ciò è necessario che l'applicazione chiamante passi all'applicazione chiamata uno o più parametri che permettano all'applicazione chiamata di inizializzare il contesto.

In guigen il modo in cui è possibile predisporre un'applicazione a ricevere parametri di attivazione è rappresentato dall'ActivatonModel (che si definisce come nodo figlio del nodo GUIModel). L'ActivationModel non è altro che un contenitore di elementi di tipo ActivationParam: ciascun ActivationParam corrisponde ad un parametro di attivazione. Il nome del parametro è libero, mentre il tipo del parametro può solamente essere un SimpleType. Nell'immagine seguente è mostrato un esempio di modello di attivazione.

L'inizializzazione del contesto deve avvenire al momento dell'ingresso nell'applicazione chiamata. Pertanto è necessario modellare la logica corrispondente nella catena di comandi che si definisce al di sotto dell'elemento ApplicationArea e che viene eseguito solo all ingresso nella action HomePage.do. I parametri modellati nell'ActivationModel saranno disponibili in tale logica.

#### Home page dinamica

In alcuni casi l'operatività sull'applicazione chiamata potrebbe dover iniziare da una schermata differente a seconda di alcune condizioni al contorno (dati sul DB, valore di un parametro di attivazione). Per realizzare questo scenario di home page dinamica sull'applicazione chiamante è sufficiente che la catena di comandi di inizializzazione contenga come ultimi comandi un ExecCommand con tanti Outcome quante sono i possibili punti di ingresso. Un esempio è riportato nella figura che segue.

#### URL di ingresso nell'applicazione chiamata

A fronte della definizione (opzionale) di un ActivationModel l'URL con cui è necessario invocare un'applicazione generata da guigen è nel formato: `http://<host>/<context>/?<param_1>=<valore_1>&<param_2>=<valore_2>...`

N.B: è importante non includere la action iniziale `HomePage.do` nell'url di innesco, pena il malfunzionamento del meccanismo degli arricchimenti javascript (in particoalre alcuni eventi sulle combobox non funzioneranno).

### Richiamo di un'applicazione da una applicazione generata da guigen

Per richiamare un'applicazione da un'applicazione generata con guigen è possibile utilizzare un JumpExtCommand. A seconda che l'URL da richiamare contenga o meno dei parametri da calcolare a runtime è necessario impostare l'attributo runtimeUrlProvider facendolo puntare ad un ApplicationData di tipo stringa che conterrà a runtime l'url completo da richiamare (parametri compresi).

### Non interferenza tra sessioni applicative

Le sessioni applicative delle due applicazioni (chiamante e chiamata) sono disgiunte e non hanno punti di contatto. Il meccanismo di session tracking di j2ee prevede l'utilizzo di un cookie di nome JSESSIONID che viene memorizzato nel browser e passato al server ad ogni interazione in modo che questo possa riconoscere a quale sessione fa riferimento. Nel caso in cui vi siano due applicazioni che si alternano nello stesso browser i JSESSIONID in gioco sono due:

1. quello dell'applicazione chiamante
2. quello dell'applicazione chiamata

Per fare in modo che non vi sia una sovrapposizione dei valori dei due cookie è necessario fare in modo che ciascuno dei due sia relativo al contesto dell'applicazione che lo ha generato, ovvero è necessario impostare il cookie-path. Per far ciò si agisce in modo differente a seconda che l'applicazione sia ospitata da u server weblogic oppure un server jboss.

#### cookie path in weblogic

Per impostare il cookie path in weblogic è necessario agire sul file weblogic.xml contenuto nella directory WEB-INF del WAR. In questa versione di generatore l'impostazione è automatica in fase di generazione. Poichè però essa è contenuta in una regione protetta, per gli applicativi generati con versioni precedenti è necessario in alternativa:

- modificare manualmente il file nella regione protetta
- cancellare il file weblogic.xml in modo che possa essere rigenerato pulito (ripristinando poi manualmente eventuali personalizzazioni precedentemente presenti nella regione protetta).

#### cookie path in JBoss

Le installazioni standard di JBoss possiedono automaticamente l'impostazione corretta del cookie path: in questo caso non è necessario fare nulla. Gli ambienti standard CSI potrebbero però avere questa caratteristica inibita: guigen permette di ripristianrla localmente all'applicativo. Per far ciò è necessario impostare a true la property `guigen.sessioncookievalve` nel file dei parametri di build dei vari ambienti. questo permette di impostare la variazione solo sugli ambienti ove questo sia effettivamente necessario. L'effetto di questa impostazione è rappresentata dalla presenza nel file `context.xml` di una direttiva Valve specifica.

N.B: questa impostazione è molto specifica della server farm CSI e di norma non è necessaria su ambienti standard red-hat.

### Integrazione tra applicazioni per convivenza nel sistema di SSO

Se un'applicazione utilizza un meccanismo di autenticazione che prevede un meccanismo di single-sign-on, automaticamente stabilisce la possibilità di una integrazione implicita con le altre applicazioni che partecipano allo stesso dominio di SSO.

In questo scenario gli accorgimenti che tipicamente occorre tener presenti sono:

- Evitare l'interferenza tra le sessioni dei vari applicativi: questo si realizza con il meccanismo del cookie path descritto in precedenza
- Tenedo presente la relae semantica delle operazioni di logout locale e logout da SSO:
  - il local logout di un'applicazione che parteciapa ad un sistema di SSO non chiude la sessione di SSO
  - il logout da SSO effettuato su un'applicazione termina la sessione di SSO anche per le altre applicazioni che partecipano al sistema di SSO

N.B: questa nota non rappresenta una trattazione completa degli scenari possibili, ma solo un richiamo all'attenzione delle implicazioni che la partecipazione ad un sistema di SSO comporta.