ACG Enterprise Implementazione Exit - TeamSystem

© Copyright Teamsystem Spa 2018. Tutti i diritti riservati. Pagina 1 di 12

ACG Enterprise

Implementazione Exit


Aggiornamenti

Data Id PTF Descrizione aggiornamenti

05/01/2018 Prima versione


Indice Indice ............................................................................................................................... 3

1. Introduzione ............................................................................................................ 4

2. Exit automatiche ..................................................................................................... 5

3. Exit non automatiche ............................................................................................ 11

4. Exit predefinite ...................................................................................................... 12


1. Introduzione

Il documento descrive i diversi tipi di exit applicative presenti nelle funzioni basate su tecnologia Java dei prodotti ACG Enterprise al fine di consentirne la personalizzazione e l’integrazione applicativa di terze parti.

La personalizzabilità delle funzioni Java presenti in ACG Enterprise si realizza attraver-so l’uso di exit, punti di uscita dal codice standard, dai quali è possibile invocare - auto-maticamente o su richiesta dell’utente - codice personalizzato, per realizzare estensioni delle funzionalità standard e/o implementare comportamenti ad hoc.

ll codice di personalizzazione che può essere invocato deve essere scritto secondo il programming model di ACG Enterprise Hub, dovendo rispettare convenzioni e specifi-che proprie dell’architettura.

L’infrastruttura di ACG Enterprise permette inoltre la definizione/configurazione di exit points personalizzati in aggiunta a quelli predefiniti nel prodotto.

ACG Enterprise prevede le seguenti tipologie di exit che possono essere attivate nell’ambito della interazione utente-UI (user interface) o nell’ambito del codice java ser-vente di una funzionalità:

• exit automatiche di tipo PRE o POST

• exit non automatiche, richiamabili da finestra a seguito della pressione di un tasto funzionale;

• exit predefinite, inserite nel codice standard di gestione della User Interface ACG;

Nel seguito vengono dettagliate le tre tipologie di exit.


2. Exit automatiche

Il meccanismo delle exit automatiche si basa sulla possibilità di invocare un metodo specifico di una classe di personalizzazione ogni qualvolta viene invocato un metodo di un’azione Struts in ACG Enterprise. La Exit può essere richiamata in modalità POST o in modalità PRE rispetto all’esecuzione dell’azione Struts ACG; nel primo caso sarà eseguita dopo l’invocazione del metodo dell’azione Struts, nel secondo caso prima dell’invocazione.

L’associazione tra le exit da invocare ed i metodi o le azioni su cui si intende attivare il meccanismo delle exit stesso è realizzata attraverso la funzione “Associazione opera-zioni-exit” inclusa nel menu “Operazioni ed autorizzazioni” di ACG Enterprise Hub. E’ necessario il ruolo di amministratore di sistema (SYSTEM_ADM) per accedere a tale funzione. La tabella SQL contenente le associazioni operazioni-exit è KOPEX00Fnella libreria ACGGAA.

La funzione succitata consente di creare, modificare, cancellare un record che definisce il legame tra un’operazione (o una action) e la sua exit (metodo utente).

Nel caso in cui si debba creare un’associazione tra un metodo specifico di un’action ed un’operazione di exit, il codice dell’operazione (Id operazione, corrispondente al campo KOPID della tabella KOPEX00F) associato al metodo dell’azione Struts deve corrispon-dere alla concatenazione dei seguenti elementi:

1. action id dell’azione Struts da invocare, così come definito nel file di configura-zione struts (struts-xxx.xml) in cui è dichiarata l’azione stessa

2. carattere underscore (trattino basso)


3. metodo da invocare

L’id dell’operazione associato al metodo dell’operazione Struts può facilmente essere rilevato andando a rilevare nella finestra di debug javascript il campo “xoperationid” pre-sente nella risposta XML.

Nel caso in cui si voglia associare un’operazione di exit ad un’action Struts, bisognerà specificare nel campo “Operazione” l’action id associato all’azione Struts. La exit sarà caricata e gestita dall’applicazione, qualunque sia il metodo dell’azione Struts che viene invocato. Tipicamente questo tipo di associazione deve essere previsto per le exit di ti-po “non automatico” (si veda paragrafo successivo) mentre per le exit di tipo automatico ha senso definire un’associazione tra la exit e l’operazione associata al metodo specifi-co dell’azione Struts.


Ad esempio, se si vuol attivare una exit ogni volta che viene richiamato il metodo crea-te() di una certa gestione, basata sull’azione Struts con l’action id “Azione”, occorre specificare il codice operazione Azione_create. Per individuare la action id e il nome della operazione è utile attivare la window di debug JavaScript (Strumenti->Debug->Raccolta informazioni->Stampa log e successivamente lanciare l’applicazione/funzione da personalizzare in modo da reperire il nome dell’azione Struts e il nome del metodo invocato).

La exit (Id exit corrispondente al campo KOPEX della tabella KOPEX00F) da associare è a sua volta un’operazione identificata da un codice di fantasia, definito dall’autore del-la exit; nell’esempio, il codice dell’operazione associata alla exit è Azione_exit_1.

I valori ammissibili per il campo “Nr exit” sono:

• 0 per contrassegnare le exit automatiche di tipo POST. La exit automatica di tipo POST verrà eseguita dopo l’esecuzione dell’azione Struts alla quale è associata.

• -1 per contrassegnare le exit automatiche di tipo PRE. La exit automatica di tipo PRE verrà eseguita prima dell’esecuzione dell’azione Struts alla quale è asso-ciata.

• > 0 per identificare le exit richiamabili da finestra (exit non automatiche).

L’operazione Azione_exit_1 deve essere codificata nell’anagrafico delle operazioni KO-PER00F specificando nel campo “URL” i nomi della classe di exit e del relativo metodo da invocare secondo la seguente codifica:

class=nome_classe_exit;method=metodo_exit_da_richiamare

oppure

class=nome_classe_exit;method=metodo_exit_da_richiamare;extf=id_tabella_logica_ASTB300F

essendo

nome_classe_exit = il nome qualificato (incluso il package) della classe di exit da ri-chiamare

metodo_exit_da_richiamare = il nome del metodo della classe di exit da richiamare


extf = se presente, viene impostato con un codice alla tabella estesa EXTF (Persona-lizzazione funzioni) di ASTB300F. Tale codice permette di attivare o meno la exit in dipendenza di un determinato sistema informativo. Il campo “funzione” della exit con-sente di modificare il nome del metodo della exit in dipendenza del sistema informativo.

Ad esempio, se la exit Azione_exit_1 deve richiamare il metodo afterCreate() della clas-se com.acg.exit.bp.CustomExit, si deve impostare l’URL dell’operazione Azione_exit_1 come segue:

class=com.acg.exit.CustomExit;method=afterCreate


La classe di personalizzazione deve implementare un metodo la cui signature deve es-sere:

methodName(ACGLogon logon, ActionForm form, HttpServletRequest

request, String context)

essendo previsto che riceva:

• l’istanza di ACGLogon correntemente attiva

• il form bean dell’azione Struts sulla quale si è attivata la exit

• la request http

• il parametro context dell’azione Struts sulla quale si è attivata la exit

Nell’esempio il metodo della classe com.acg.exit.CustomExit è:

afterCreate(ACGLogon logon, ActionForm form, HttpServletRequest

request, String context)

Si fa presente che, se sull’operazione della exit non viene impostato il campo Url, la exit non viene eseguita. ACG precarica alcune associazioni operazioni-exit e le relative ope-razioni di exit, le quali hanno il campo Url non impostato. Il cliente/Business Partner che intenda attivare la exit dovrà semplicemente impostare il campo Url come specificato precedentemente.

Nel caso sia stato associato un codice della tabella estesa Personalizzazione funzioni (tabella EXTF), la exit verrà eseguita se il codice indicato nel parametro extf dell’URL è presente nella tabella estesa nel sistema informativo collegato e risulta attivo ed abilita-to.

Ad esempio è possibile condizionare l’esecuzione della exit Azione_exit_1 al codice EXITCUST della tabella EXTF.


All'atto dell'invocazione di una exit automatica, sia essa di tipo PRE o di tipo POST, è stato previsto il passaggio dell'istanza della variabile org.apache.struts.config.ActionConfig associata all'azione Struts dalla quale è scaturita l'invocazione della exit automatica. Il passaggio del parametro viene realizzato aggiun-gendolo ai dati del thread; la exit automatica invocata può recuperare il nuovo parame-tro come segue:

ActionConfig actionConfig = (ActionConfig) InfoConnessione

.getInfoConnessione().getData().getFromData("actionConfig");

Data la variabile actionConfig è possibile, ad esempio, ricavare l'operazione da cui è partita la exit come segue:

String actionId = actionConfig.getProperty("actionId");

String operationId = actionId + "_" + request.getParameter("xmethod");

La soluzione adottata si basa sull’utilizzo del pattern COR (Chain of Responsability) che permette di richiamare in successione più classi java nell’ambito di una stessa request, passando parametri ed oggetti da una classe all’altra nell’ambito della catena.


3. Exit non automatiche

Sono richiamabili da una finestra che viene emessa al clic sul tasto “Exit” inserito in una finestra ACG Enterprise Hub sulla quale ne sia stata predisposta la gestione.

L’Url delle exit eseguibili può essere di due tipi:

• può contenere un comando javascript (tipicamente si prevede il richiamo di funzioni standard dell’UI engine di Enterprise Hub); la sintassi è:

js:comando_javascript

Ad esempio js:xcrtWIN(‘…’) oppure js:xrun(‘…’). Se nel comando javascript è presente la parola chiave parentWin, questa viene so-stituita a run-time con l’identificativo della finestra che contiene il tasto Exit.

Ad Esempio:

js:window.open('../pages/exit.jsp?parm1=parentWin&parm2=AgentForm')

• può contenere il riferimento ad Action forward per il richiamo di un’azione Struts.

Ad esempio è possibile definire nell’operazione l’Url AgentExitAction avendo previsto di configurare il mapping dell’azione di gestione delle Exit (definito nel file struts-exit.xml) come segue:

<action path="/ExitManager"

type="com.ibm.acgv4.action.ExitManagerAction"

name="ExitManagerForm" scope="request" validate="false"

input="/pages/output.vm" parameter="xmethod">

<set-property key="actionId" value="Exit" />

<forward name="AgentExitAction"

path="/AgentExitAction.do?xmethod=create"/>

</action>

Come per quelle automatiche, l’URL della exit non automatica può contenere il parame-tro extf tramite il quale è possibile attivare o meno la exit in funzione del sistema infor-mativo. Pertanto, se ad esempio si vuole abilitare/disabilitare la exit Azione_exit_1 su un sistema informativo in funzione dell’elemento 0001 della tabella EXTF, si può impo-stare l’url come segue:

js:window.open('../pages/exit.jsp?parm1=parentWin&parm2=AgentForm');ex

tf=0001

Se il codice 0001 è presente ed è attivo nella tabella estesa EXTF di un dato sistema informativo, la exit verrà presentata nella lista delle exit eseguibili, altrimenti verrà esclusa.


4. Exit predefinite

Sono punti di exit inseriti in punti prestabiliti del codice java standard per consentire l’invocazione di codice “custom”. L’unica cosa che è necessario fare è definire l’operazione nel KOPER00F.

Il codice utente invocabile è rappresentato da un metodo dichiarato in una classe defini-ta dal personalizzatore.

Sono state identificate due tipologie di signature:

1. void nome_metodo(ActionMapping mapping, ActionForm form, HttpSer-vletRequest request, HttpServletResponse response, Session

hibSession, Object parentBo) throws Exception

2. void nome_metodo(Map hashMap) throws Exception

Il metodo (1) riceve:

• l’action mapping dell’azione Struts dalla quale è stato invocato

• il form bean dell’azione Struts dalla quale è stato invocato

• la request e la response http

• la sessione Hibernate utilizzata nel metodo chiamante dell’azione Struts

• il BO utilizzato nel metodo chiamante dell’azione Struts

Il metodo(2) ha un unico parametro da utilizzare sia per l’input sia per l’eventuale out-put (una hashmap di coppie chieve-valore).

Il nome della classe ed il nome del metodo devono essere definiti nell’url dell’operazione di Exit il cui codice è predefinito nel metodo dell’azione in cui si è inseri-ta la exit, seguendo la convenzione:

class=nome_classe_exit;method=metodo_exit_da_richiamare

oppure

class=nome_classe_exit;method=metodo_exit_da_richiamare;extf=id_record

_EXTF

Il parametro opzionale extf rappresenta il codice di un record della tabella estesa EXTF “Personalizzazione funzioni”; si veda quanto riportato nel paragrafo relativo alle exit au-tomatiche relativamente al significato di tale parametro.

Le operazioni associate alle exit predefinite vengono precaricate con url non impostato e pertanto non vengono eseguite; esse saranno attivate solo nel momento in cui l’url viene impostato opportunamente dal personalizzatore.

FINE DOCUMENTO

ACG Enterprise Implementazione Exit - TeamSystem

Documents

Transcript of ACG Enterprise Implementazione Exit - TeamSystem