ACG Vision4 Service Bus Guida Tecnica Overview Architetturale

Transcript

1 ACG Vision4 Service Bus Guida Tecnica Overview Architetturale Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 1 di 108

2 Quinta Edizione (Aprile 2012) Questa edizione si riferisce alla Versione 1 Rilascio 4 livello di modifica 0 di ACG Vision4 Service Bus (5733-F13) e a tutti i successivi rilasci e modifiche, se non altrimenti indicati in nuove edizioni o lettere di accompagnamento. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 2 di 108

3 Note e Trademarks Copyright ACG S.r.l Tutti i diritti riservati. ACG e ACG Vision4 sono marchi di ACG S.r.l., con socio unico e soggetta all attività di direzione e coordinamento di TeamSystem S.p.A., sede legale in in via Yuri Gagarin, Pesaro (PU), Cap. Soc i.v., codice fiscale e iscrizione al Registro delle Imprese di Milano n (di seguito ACG ) - Tutti i diritti riservati. I marchi e loghi riportati nel presente documento diversi da ACG e ACG Vision4 (ivi inclusi, a mero titolo esemplificativo e non esaustivo, IBM, il logo IBM, Adobe, il logo Adobe, PostScript, il logo PostScript, Intel, il logo Intel, Intel Inside, il logo Intel Inside, Intel Centrino, il logo Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium e Pentium, Linux, Microsoft, Windows, Windows NT e il logo di Windows, UNIX, Java, Novell, il logo Novell, opensuse e il logo opensuse, AS/400, BladeCenter, Cognos, DB2, DB2 Universal Database, eserver, i5/os, iseries, OpenPower, OS/400, POWER, Power Systems, pseries, Rational, System i, System i5, System p, System p5, System Storage, System x, WebSphere, etc.) sono di titolarità di soggetti terzi. ACG rispetta i diritti di proprietà intellettuale di terzi. Tutti i contenuti del presente documento e i diritti ad essi correlati sono riservati. Tali contenuti pertanto possono essere consultati esclusivamente per finalità d informazione personale, essendo espressamente vietato ogni diverso utilizzo senza il preventivo consenso scritto di ACG. Sebbene sia stata usata ogni ragionevole cura nel raccogliere e presentare le informazioni contenute nel presente documento, nessuna garanzia è prestata in ordine alla loro esattezza, completezza, utilità, né ai loro possibili impieghi da parte degli utenti; è pertanto esclusa ogni responsabilità di ACG per errori, inesattezze od omissioni relative a dette informazioni. I contenuti del presente documento sono soggetti a continuo aggiornamento e sono da ritenersi puramente indicativi e suscettibili di eventuali errori e/o imprecisioni. ACG può introdurre miglioramenti e/o variazioni ai prodotti e/o programmi descritti nel presente documento in qualsiasi momento e senza preavviso. Il presente documento può contenere informazioni che riguardano programmi e propositi futuri, che vengono descritti di volta in volta mediante l utilizzo di termini come "attendersi", "stimare", "prevedere", "prospettare" e "programmare". Tali dichiarazioni per loro natura non comportano alcun impegno a carico di ACG, che pertanto non assume in relazione ad essi alcuna responsabilità di realizzazione. Qualunque riferimento a siti web diversi da è fornito a solo titolo esemplificativo e non costituisce invito all utilizzo e/o navigazione. I contenuti dei siti web referenziati non sono parte dei prodotti ACG e il loro eventuale utilizzo da parte dell utente è effettuato a suo esclusivo rischio. Le informazioni relative a prodotti non ACG contenute nel presente documento sono fornite dai rispettivi fornitori, dagli annunci pubblicitari e da informazioni liberamente disponibili. ACG non ha collaudato tali prodotti e non può confermarne l accuratezza delle prestazioni, la compatibilità con i prodotti ACG o qualunque altra caratteristica. Qualunque richiesta sulle Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 3 di 108

4 caratteristiche operative dei prodotti non ACG deve essere rivolta direttamente ai rispettivi fornitori. Fatti salvi i danni causati da dolo o colpa grave, ACG non assume nessuna responsabilità circa i contenuti del presente documento. In particolare, tali contenuti non rappresentano una promessa o garanzia relativa all idoneità a determinati scopi dei prodotti ACG oppure alla non violazione, da parte dei prodotti ACG stessi, di leggi di qualsivoglia natura. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 4 di 108

5 INDICE NOTE E TRADEMARKS... 3 TABELLA DEGLI AGGIORNAMENTI... 7 OVERVIEW ARCHITETTURALE LA STRATEGIA ACG VISION ACG SERVICE BUS ARCHITETTURA DI RIFERIMENTO DELLE APPLICAZIONI Implementazione MVC in ACG Service Bus INFRASTRUTTURA LOGON AL SISTEMA Connessione JDBC CONFIGURAZIONE WORKMANAGER OPERAZIONI, WORKFLOW ED AUTORIZZAZIONI Ruolo Operazioni Autorizzazioni Authorization Manager Autorizzazione a livello di campo GESTIONE DEI CONFLITTI IN ACG SERVICE BUS ACG Risorse Virtuali e parametri delle risorse Il parametro KEY per implementare il Logical Lock Associazione operazione- risorsa virtuale e tipo di accesso Impostazioni per la gestione conflitti WORKFLOW Concetti di Base Workflow in ACG Service Bus Lista definizione processi Motore di gestione delle regole di business MESSAGGISTICA Utilizzo delle funzionalità presenti in Websphere Application Server 6.0.X Componenti JMS Destinazioni utilizzate da ACG Service Bus Formato e proprietà messaggi per Ruolo Utente MONITORING SCHEDULING IN ACG VISION GENERATORE DI CODICE PER ACG VISION Autorizzazione campi Generazione di codice per BO che implementano il pattern parent-child LISTA STAMPE SALVATAGGIO STAMPE IN ACG VISION GESTIONE MENU CONTROLLO SUL NUMERO UTENTI COLLEGATI AD ACG VISION PUNTI DI ESTENSIONE Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 5 di 108

6 3.1 GESTIONE EXIT Exit automatiche Exit non automatiche Exit predefinite Exit lato server LANCIO OPERAZIONI RICHIAMO CLASSI CUSTOM ALLO STARTUP DELL APPLICAZIONE GESTIONE DATI TABELLARI UTENTE EXIT MOTORE DI GESTIONE DELL INTERFACCIA UTENTE (UIENGINE) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 6 di 108

7 Tabella degli aggiornamenti Data PTF id Descrizione 07/06/2011 SVB140029D Introdotto il paragrafo "3.4 Gestione dati tabellari utente" che descrive la procedura per creare una nuova area applicativa nell'ambito della gestione delle tabelle ACG, definire le tabelle appartenenti all'area applicativa creata, visualizzare la lista delle tabelle dell'area applicativa e richiamare la funzione di gestione delle tabelle. In particolare, nel caso di tabelle di tipo descrittivo, è previsto il richiamo di una funzione standard del Service Bus che consente la gestione degli elementi tabellari, Aggiornato il paragrafo "3.1 Gestione delle exit" per descrivere l'introduzione e l'utilizzo del parametro "extf" tramite il quale è possibile condizionare l'esecuzione di una exit all'abilitazione o meno di un elemento della tabella EXTF (Personalizzazione funzioni) in un sistema informativo ACG. 12/06/2011 SVB140030D 27/04/2012 SVB140072D Aggiornato il paragrafo "3.1 Gestione delle exit" per descrivere la possibilità di creare un associazione exit-action id in aggiunta all associazione exit-operazione collegata ad un metodo di un azione Struts Aggiornato il paragrafo per le exit di tipo automatico che implementano il pattern Chain of Responsibility (COR) Aggiunto paragrafo 3.5 Exit motore di gestione dell interfaccia utente (UIEngine) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 7 di 108

8 Overview architetturale 1.1 La strategia ACG Vision4 La strategia ACG Vision4 rappresenta l evoluzione delle attuali famiglie di prodotti ACG verso una piattaforma applicativa innovativa, SOA-enabled, nella quale sono destinate a confluire tutte le linee attuali di prodotto. Le caratteristiche peculiari della nuova famiglia di prodotti possono essere così sintetizzate: o Nuovo disegno funzionale per processi/servizi o Abilitazione all integrazione intra/inter aziendale tramite SOA e web services o Client di tipo Web innovativo o Infrastruttura/servizi di supporto delle applicazioni o Aderenza a open standard, utilizzo di open source o Coesistenza con attuali famiglie di prodotti ACG o Portabilità su piattaforme hardware diverse tramite utilizzo del linguaggio Java o Flessibilità e facilità di personalizzazione o Integrazione con strumenti Office Automation Il modello di riferimento delle ACG Vision4 è la specificazione del modello di riferimento concettuale IBM per l architettura SOA (Service Oriented Architecture) ed è sotto riportato. D D e v e l o p m e n t s T o o l s Multi-channel Client (Browser, Portal, ) Customers/Suppliers Integration (B2B) Controls Services Workflow ACG Service Bus Business Logic I/O via Xml Connectors for legacy applications M a n a g e m e n t S e r v i c e s Infrastructure Services Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 8 di 108

9 1.2 ACG Service Bus Il prodotto ACG Service Bus è l elemento fondante della strategia ACG Vision4, che possiamo definire come il componente architetturale che fornisce servizi di supporto e di integrazione per le applicazioni, costituendo il canale di comunicazione tra applicazioni/componenti/servizi. I componenti di ACG Service Bus utilizzano laddove conveniente componenti e framework open source come mostra la figura seguente: Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 9 di 108

10 1.3 Architettura di riferimento delle applicazioni L implementazione del modello di riferimento delle applicazioni nel contesto di ACG Service Bus è realizzato dalla architettura seguente: L architettura implementa il pattern MVC (Model View Controller) che consente di tenere separati e indipendenti i livelli di cui si compone un applicazione. Per Model si intende la rappresentazione dei dati di business dell applicazione e le regole con cui tali dati vengono interrogati o manipolati. Per View si intende la componente responsabile della visualizzazione dei dati del Model: i dati del Model possono essere visualizzati utilizzando viste diverse. Per Controller si intende la componente responsabile dell interazione tra View e Model: esso interpreta le richieste della View, che non sono altro che le richieste dell utente dell applicazione, inducendo azioni corrispondenti nella parte Model, selezionando la nuova View da visualizzare o se del caso aggiorna la View stessa da cui è partita la richiesta. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 10 di 108

11 1.3.1 Implementazione MVC in ACG Service Bus Il paradigma Model-View-Control è stato cosi implementato: Model: Java Business Object che incapsulano la logica applicativa ed accedono ai dati dell applicazione utilizzando come framework di persistenza Hibernate oppure Java Object Wrappers che utilizzano programmi ACG esistenti tramite i bean java generati dal generatore di codice Legacy Controller: Action ( classi java ) scritte utilizzando il framework Struts View: è costituita dal motore di gestione delle form (ACG Form Handler) che si occupa di gestire gli aspetti di rendering utilizzando DHTML (codice HTML dinamico) e di interattività utilizzando Ajax per la comunicazione asincrona con il server web: la View è costruita sulla base delle informazioni contenute nel Dizionario (Data Dictionary) La logica di interazione tra le componenti costituenti l applicazione è la seguente: dal nuovo desktop ACG Service Bus, desktop delle applicazioni della strategia ACG Vision4, viene richiesta l esecuzione di un operazione ( il cui risultato è la visualizzazione di una finestra con i dati relativi) il Form Handler legge dal dizionario la definizione della finestra e richiama l URL ad essa associato ( richiamo del metodo di una Action di Struts) viene verificato dal componente di Autorizzazione che l utente sia abilitato all esecuzione dell operazione: in caso negativo viene restituito XML di errore al Form Handler viene eseguito il metodo della Action di Struts che richiama la Business Logic e ritorna XML di risposta contenente i dati del Model da visualizzare ed eventuali errori Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 11 di 108

12 2. Infrastruttura 2.1 Logon al sistema In ACG Service Bus l accesso al sistema, qualunque esso sia (sistema iseries su cui siano già presenti ACG WE o ACG for Java oppure sistema Window/Linux su cui siano stati installati i prodotti ACG Express), l accesso al sistema avviene attraverso un unica classe denominata ACGLogon nel package com.ibm.acgv4.base, presente nella libreria java acg_base.jar. La libreria java acg_base.jar (che tra l altro include le componenti serventi di autorizzazione, accesso al database e logging) richiede le seguenti librerie: - Log4j per il logging (nello specifico log4j jar) - Java ToolBox per iseries nel caso di accesso al sistema iseries con ACG WE e ACG For Java (jt400.jar) - Runtime Caravel nel caso di accesso ad un sistema su cui siano installate le ACG Express (caravel.fw.jar e caravel.addon.jar) - Runtime core Hibernate per utilizzare la classe di ACG Service Bus di creazione della configurazione e delle sessioni Hibernate (hibernate3.jar) La classe ACGLogon richiede, per l effettuazione del collegamento al sistema, i seguenti parametri da passare al metodo login(): - tipo sistema (valori ammissibili sono AS400, CARAVEL e CARAVEL_I5 e possono essere recuperati dalle variabili statiche omonime dichiarate nella classe com.ibm.acgv4.utils.utils) - indirizzo IP del sistema - utente di collegamento - password di collegamento - nome del sistema informativo di collegamento (opzionale; se impostato a null si assume un collegamento con il sistema informativo di default) - flag complete: se impostato al valore true, recupera la lista di tutti i Sistemi informativi a cui è abilitato l utente. La classe ACGLogon contiene il riferimento alla classe rappresentativa del server cui si collega (com.ibm.acgv4.base.server) e all istanza della classe rappresentativa del profilo utente di collegamento (com.ibm.acgv4.base.profile). Attraverso la classe ACGLogon è possibile reperire in qualsiasi porzione di codice Java: - le informazioni di collegamento al sistema (utenza, password, indirizzo sistema, tipo sistema) - il sistema informativo e l azienda cui si è collegati - i ruoli ai quali è abilitato l utente nel sistema informativo - la lista dei sistemi informativi ai quali l utente è abilitato - l immagine della KPJBA che viene fornita dal Modulo Base all atto dell accesso al sistema - la libreria in cui si trovano uno (metodi search) o fino a dieci oggetti (metodo touch) nel sistema informativo - la lingua dell utente sotto forma di locale Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 12 di 108

13 La classe ACGLogon consente, come detto, di accedere alla classe rappresentativa del Server, che sarà un istanza di una delle seguenti classi: - AS400Server - CaravelServer - CaravelI5Server a seconda dei casi, ciascuna delle quali implementa l interfaccia com.ibm.acgv4.base.server precedentemente menzionata. Tramite tali classi è possibile effettuare il lancio di programmi secondo le modalità tipiche di ciascun ambiente. Nell ambito dell applicazione web, la classe ACGLogon può essere recuperata mediante la classe wrapper com.ibm.acgv4.guiweb.acgbaseconnector, mediante il richiamo del metodo getlogon(httpservletrequest req, HttpServletResponse resp, ServletContext context). Si tenga presente che nell applicazione web l indirizzo di sistema ed il tipo sistema sono parametri di contesto configurabili all atto dell installazione, come descritto nella Guida di installazione. Per quanto riguarda l indirizzo IP del server a cui far puntare l applicazione occorre configurare una risorsa di tipo URL come descritto nel paragrafo Configurazione provider URL. Un metodo analogo al metodo getlogon( ) di ACGBaseConnector è stato inserito nella classe ACGDispatchAction per il recupero dell istanza di ACGLogon in una Action di Struts in architettura ACG Service Bus (si veda quanto riportato nel paragrafo relativo nel capitolo Componente Controller ). All atto del collegamento l applicazione visualizza una schermata in cui l utente, a regime, vedrà preimpostati i nome dell utente e del sistema informativo con i quale si è collegato l ultima volta, così come mostrato nell immagine sottostante. Il campo Sistema Informativo consente di selezionare uno tra i sistemi informativi ai quali l utente è abilitato. All atto del primo collegamento in assoluto (o nel caso in cui siano stati eliminati i cookie salvati dal browser sulla macchina client) il campo Utente sarà impostato a spazio vuoto, mentre il campo Sistema Informativo non sarà visualizzato affatto. Il recupero dell indirizzo IP del server iseries o Linux cui punta l applicazione web acgv4 richiede la creazione di un URL il cui nome JNDI sia url/acgv4. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 13 di 108

14 2.1.1 Connessione JDBC Attraverso un istanza valida di ACGLogon (tramite la quale sia stato effettuato un login) è possibile richiedere una connessione JDBC al database, mediante l invocazione del metodo getconnection(). Tale metodo restituisce un istanza della classe java.sql.connection, rappresentativa di una connessione SQL al database, recuperandola tramite una classe del package base denominata ACGConnectionManager. Tale classe è in grado di creare una connessione JDBC richiedendola al driver JDBC opportunamente creato, nel caso di utilizzo in un applicazione java stand-alone, mentre richiede la stessa ad un pool di connessione opportunamente configurato in Websphere. 2.2 Configurazione WorkManager In ACG Service Bus si utilizza il WorkManager di default per l esecuzione di lavori asincroni sull application server: esso è già configurato all atto dell installazione di Websphere con il parametro di numero massimo di lavori asincroni contemporanei impostato a 5: esso può essere assimilato alla coda lavori KSDIFFE del Modulo Base ACG NOTA BENE L applicazione web ACG Vision4porta come riferimento JNDI preimpostato il valore wm/default. La gestione batch fornita da ACG Service Bus prevede la definizione di un WorkManager aggiuntivo, ACGV4_DIFFE_WorkManager, per gestire un WorkManager con il parametro di numero massimo di lavori asincroni contemporanei impostato ad 1; esso può essere assimilato alla coda lavori KSDIFFE del Modulo Base ACG. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 14 di 108

15 2.3 Operazioni, workflow ed autorizzazioni Il modello di riferimento di ACG Service Bus relativo ai servizi di sicurezza è il seguente: Utenti Sistemi informativi Ruoli Operazioni Associazione utenti-ruoli per Sistema informativo Associazione ruolioperazioni Authorization Component Le novità più rilevanti rispetto al modello dell attuale famiglia di prodotti ACG sono: l introduzione del concetto di Ruolo l introduzione del concetto di Operazione in luogo dell Azione Ruolo Il ruolo rappresenta la funzione aziendale di un utente; esso è associato tipicamente alle mansioni svolte ed alle responsabilità che competono ad un utente nel sistema informativo in cui può operare. Ruoli aziendali tipici sono, ad esempio quello del Contabile, che può accedere alle funzioni di gestione della Contabilità Generale, Clienti e Fornitori, avendo la possibilità di visualizzare il Piano dei Conti, senza tuttavia poterlo modificare, oppure quello del Responsabile amministrativo, che, oltre ad avere accesso alle funzioni di Contabilità Generale, avrà la facoltà di creare/modificare il piano dei conti, utilizzare le funzioni di redazione dei Bilanci (di verifica, civilistico-fiscale, consolidato, etc.) e via discorrendo. Il concetto di Ruolo è legato a quello del Sistema Informativo dell attuale famiglia di prodotti ACG, in modo che sia possibile per un utente assumere un ruolo, ad esempio Contabile in un sistema informativo ed in un altro NON assumere tale ruolo. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 15 di 108

16 Le informazioni relative ai Ruoli, sono contenute nella tabella KROLE00F nella libreria ACGGAA di cui si riporta il tracciato* : Campo Tipo Lunghezza Decimali Descrizione KRLID CHARACTER 10 Role id KRLDS CHARACTER 50 Description * sono stati omessi i campi standard Utente di creazione e modifica, Stato, Data creazione e modifica Esempio: KRLID CONTABILE RESP_AMM KRLDS Contabile Responsabile amministrativo Nella tabella KROLE00F in ACGGAA sono stati precaricati i ruoli: - SYSTEM_ADM (Amministratore di sistema) che è stato associato al profilo ACGMASTER su tutti i Sistemi Informativi (si veda quanto riportato di seguito nel paragrafo Autorizzazioni a proposito delle relazioni utenti-ruoli salvate nella tabella KUSRL00F) - CONTABILE per il ruolo contabile (si veda il sample delle banche) - RESP_AMM per il ruolo di responsabile amministrativo Operazioni In ACG Service Bus un operazione rappresenta una porzione di codice eseguibile per il quale si possono gestire i vari aspetti di sicurezza: autorizzazione all esecuzione monitoring e traccia della sua esecuzione conflitti con altre operazioni L operazione può dunque rappresentare l esecuzione di un metodo di una classe java, di un programma legacy o di un servizio. Le informazioni relative alle Operazioni sono contenute nella tabella KOPER00F nella libreria ACGGAA di cui si riporta un estratto del tracciato* Campo Tipo Lunghezza Descrizione KOPID CHAR 30 Operation id (Campo CHIAVE) KOPDS CHAR 50 Description KOPAC CHAR 1 ACG operation (Y/N) KOPTP CHAR 4 Type Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 16 di 108

17 KOPUR CHAR 100 URL KOPEN CHAR 30 Referenced entity KOPEA CHAR 10 Referenced entity auth. KOPUM CHAR 1 Use in menu (Y/N) KOPUP CHAR 1 Use in persistent filters (Y/N) KOPAA CHAR 4 Application area KOPGR CHAR 10 Group of operations KOPRP CHAR 1 Requires parameters (Y/N) KOPAZ CHAR 4 Action code old style Note: - KOPAC = Y se l operazione appartiene alla famiglia dei prodotti ACG, N altrimenti - KOPTP = PROC se l operazione rappresenta un Processo di business, vedi workflow - KOPUR rappresenta in forma di URL (Unified Resource Locator) la chiamata all esecuzione dell operazione - KOPUM = Y se l operazione può essere inclusa in un menu, N altrimenti - KOPUP = Y se l operazione può essere richiamata dalle funzionalità dei Persistent Filters, N altrimenti - KOPAA rappresenta l area applicativa (prodotto a cui l operazione si riferisce; ad esempio FT4 Fatturazione, CA4 Contabilità generale) - KOPRP = Y se l operazione per essere richiamata richiede in input parametri, N altrimenti - KOPGR permette di raggruppare le operazioni in gruppi logici, per associare ad un ruolo l autorizzazione all esecuzione di più operazioni (vedi innanzi) - KOPAZ permette di definire un operazione la cui esecuzione comporti l esecuzione di un azione del modulo base ACG Esempio: KOPID KOPDS KO PC KO PT P KOPUR KOP EN KOP EA KOP UM KOP UP KOP AA KOP GR KOP RP RDP_c reate Immissio ne RDP Y./RdPAction.do?xm ethod=create RD P Inse rt Y Y FT4 N RDP_ update Modifica Richiesta di Y./RdPAction.do?xm ethod=update RD P Wri te N Y FT4 Y Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 17 di 108

18 Preventivo Autorizzazioni Data un operazione, è possibile indicare i ruoli abilitati all esecuzione dell operazione. Dato un utente di un Sistema Informativo, è possibile specificare il ruolo od i ruoli che esso assume, da cui indirettamente discende l autorizzazione o meno all esecuzione delle operazioni. Un utente, quindi, richiedendo l accesso ad un Sistema Informativo, viene caratterizzato dai ruoli ad esso associati per quel Sistema Informativo: questa caratterizzazione viene effettuata dal componente di autenticazione e di accesso al Sistema Informativo (detto di Logon). Quando un utente richiede l esecuzione di un operazione, il componente di gestione delle autorizzazioni, Authorization Component, verificherà se l utente è abilitato ad eseguire l operazione in base alle sue credenziali di accesso (ruoli da esso assunti in quel sistema Informativo) e ruoli abilitati all esecuzione dell operazione Le informazioni relative all associazione Ruoli-Operazioni, sono contenute nella tabella KOPRL00F nella libreria ACGGAA di cui si riporta il tracciato*: Campo Tipo Lunghezza Descrizione KOPER CHARACTER 30 Operation (Campo CHIAVE) KROLE CHARACTER 10 Role (Campo CHIAVE) KFLGR CHARACTER 1 Flag group of oper (Y/N) Il campo KFLGR, se impostato a Y, indica che KOPER contiene il riferimento al gruppo di operazioni (KOPGR di KOPER00F) cui il ruolo KROLE si vuole associare, altrimenti N KOPER è un codice operazione (KOPID) presente nella tabella KOPER00F. Ad esempio: KOPER KROLE KFLGR RDP_create CONTABILE N RDP_update DIR_AMM N Le informazioni relative all associazione Utenti-Ruoli-Sistema Informativo, sono contenute nella tabella KUSRL00F nella libreria ACGGAA di cui si riporta il tracciato* Campo Tipo Lunghezza Descrizione KUSER CHARACTER 10 User (Campo CHIAVE) KROLE CHARACTER 10 Role (Campo CHIAVE) KSYS CHARACTER 10 Information System (Campo CHIAVE) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 18 di 108

19 Il campo KSYS ammette il valore *ALL per rendere l associazione Ruolo-Utente valida per tutti i Sistemi Informativi gestiti Esempio KUSER KROLE KISYS ACG3USER CONTABILE *ALL DISP RESP_AMM SIS1 La creazione di un operazione e l indicazione dei ruoli abilitati all esecuzione della stessa viene realizzata attraverso la funzione di gestione accessibile dal menu Operazioni ed autorizzazioni in ACG Vision4. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 19 di 108

20 2.3.4 Authorization Manager ACG Service Bus fornisce nella libreria java denominata acg_base.jar la classe com.ibm.acgv4.base.authorizationmanager come interfaccia alle autorizzazioni di esecuzione di operazioni. In particolare la classe mette a disposizione i seguenti metodi: public static boolean check(acglogon logon, String operationid, String informationsystem) throws BaseException per verificare se l utente connesso ad ACG Service Bus (istanza di ACGLogon) è autorizzato all operazione operationid sul sistema informativo informationsystem (o su quello a cui è connesso se informationsystem è non impostato) public static List getautohorizedroles(acglogon logon, String operationid) throws BaseException per ottenere la lista dei ruoli autorizzati ad eseguire l operazione operationid sul sistema informativo a cui è l utente è connesso Si noti che i metodi della componente Controller (Action di Struts) delle funzioni sviluppate nel contesto di ACG Service Bus eseguono automaticamente il controllo di autorizzazione tramite personalizzazione del pattern COR (Chain Of Responsibility) implementato nella framework Struts (si veda quanto riportato nella paragrafo che descrive in dettaglio tale componente). Quindi il programmatore di solito ignora nella scrittura del codice controller tali controlli in ottica AOP (Aspect Oriented Programming) Autorizzazione a livello di campo In ACG Vision4è prevista la possibilità di specificare le autorizzazioni a livello di campo di database, sulla base di un interfaccia che permatte di specificare i diritti che un ruolo utente ha su una colonna di database. Per maggiori dettagli consultare il paragrafo 2.5.1, che è logicamente collegato alla problematica di generazione del codice in ACG Vision4. La definizione dell autorizzazioe su un campo comporta la scrittura di un record nel file KAUT400F, presente nella libreria ACGGAA nel rilascio corrente. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 20 di 108

21 2.4 Gestione dei conflitti in ACG Service Bus ACG Per conflitto si intende la contesa tra due oggetti (di solito programmi) di una o più risorse esterne agli oggetti stessi. In particolare l obbiettivo è quello di garantire l integrità dei dati ad un livello più alto di quello garantito a livello di transazione dai DBMS. Il conflitto in ACG Service Bus è strettamente collegato all esecuzione delle operazioni. Il requisito multipiattaforma impone ad ACG Service Bus di prescindere dal lock effettivo delle risorse fisiche, introducendo il concetto di risorsa virtuale. All atto dell esecuzione di una operazione ACG Service Bus verifica ed impone, mediante apposito servizio, i vincoli sulle risorse virtuali richiesti dall operazione oppure segnala l impossibilità di eseguire l operazione a causa di un conflitto con una o più operazioni in corso di esecuzione. Al termine dell operazione i vincoli sono terminazione normale. rimossi sia in caso di errore che in caso di Risorse Virtuali e parametri delle risorse Come accennato nell introduzione, la gestione dei conflitti si basa sul concetto di Risorsa virtuale. La risorsa virtuale e una astrazione (nome logico) di una risorsa su cui un operazione all atto dell esecuzione vuole porre un vincolo: occorre verificare che tra le operazioni in esecuzione non ve ne sia una che abbia già vincolato la risorsa in maniera incompatibile con il vincolo richiesto. Il caso più frequente e quello in cui la risorsa rappresenta logicamente una tabella su cui un operazione vuole apporre un vincolo per effettuare modifiche che richiedono un uno esclusivo della tabella. Inoltre per poter dettagliare meglio i vincoli sulle risorse e possibile specificare dei parametri associati alla risorsa, costituiti da un nome ed un valore ad essi associato. Un esempio di parametro può essere l azienda su cui si opera, la chiave del record di una tabella che si vuole riservare. Il Service Bus ha previsto la possibilità di associare ad una risorsa dei parametri, detti di sistema, che assumono un particolare significato nel contesto Vision4; essi sono: 1. KCOMP, il cui valore rappresenta l azienda a cui e collegato l utente ed in cui si sta eseguendo l operazione (credenziali di accesso) 2. KSYSI, il cui valore rappresenta il sistema informativo a cui e collegato l utente ed in cui si sta eseguendo l operazione (credenziali di accesso) 3. KUSER, il cui valore rappresenta il nome dell utente che sta tentando di eseguire l operazione (credenziali di accesso) Il Service Bus e in grado di avvalorare automaticamente questi parametri. Per i parametri KCOMP e KSYSI e possibile specificare valori diversi rispetto a quelli delle credenziali di accesso: in tal caso viene controllato che l utente abbia l autorizzazione ad operare sui valori impostati (azienda o sistema informativo diversi da quelli a cui e collegato). Invece il parametro KUSER e sempre avvalorato al nome dell utente che sta eseguendo l operazione. I parametri (nomi) sono delle variabili da avvalorare a tempo di esecuzione dell operazione che consentono di porre dei vincoli più granulari sulle risorse. In particolare un operazione che richiede un vincolo su una risorsa risulta in conflitto con un altra operazione in esecuzione solo se quest ultima ha posto un vincolo sulla stessa risorsa con gli stessi valori dei parametri. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 21 di 108

22 2.4.2 Il parametro KEY per implementare il Logical Lock Particolare significato assume nel Service Bus il parametro KEY: esso sta a rappresentare logicamente i nomi dei campi chiave di una tabella (Risorsa virtuale) separati dal carattere (barra verticale): in presenza di un parametro di questo tipo il Service Bus all atto del richiamo di un action cerca di avvaloralo automaticamente cercando nella request i nomi indicati nel valore del parametro ( Si veda più avanti il paragrafo Richiamo automatico del servizio conflitti a cura di ACG Service Bus ) se per l operazione corrispondente all Action richiesta il campo KOPEN e avvalorato al nome della Risorsa virtuale. Ad esempio supponiamo di associare all operazione Agent_update, che corrisponde al metodo update() dell action AgentAction, la risorsa virtuale AAGE200F (che rappresenta la tabella Agenti) con accesso di tipo WRITE a cui sono stati associati il parametro Azienda (KCOMP) e il parametro KEY con valore CODAG: nel campo KOPEN dell operazione Agent_update deve essere impostato il valore AAGE200F. Al richiamo del metodo dell action in questione (ad esempio con la voce di menu pop up di modifica dalla Lista Agenti) il Service Bus tenterà automaticamente di apporre il vincolo sulla risorsa AAGE200F avvalorando il parametro KCOMP all azienda cui si è collegati ed il parametro KEY al valore del parametro della request CODAG; ma quest ultimo non è altro che la chiave del record della tabella AAGE200F che si vuole modificare, quindi i questo modo si e realizzato il meccanismo di Logical lock. Infatti se un altro utente tenta di eseguire lo stesso metodo ( cioè di modificare lo stesso record) ha un errore di conflitto. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 22 di 108

23 2.4.3 Associazione operazione- risorsa virtuale e tipo di accesso Per specificare i vincoli che una operazione deve apporre sulle risorse virtuali e possibile in ACG Service Bus associare ad un operazione una o più Risorse virtuali da allocare all atto della esecuzione e il tipo di accesso alla risorsa virtuale stessa richiesto dall operazione. I tipi di accesso gestiti sono i seguenti: NO_LOCK READ WRITE EXCLUSIVE All atto dell esecuzione di un operazione il Service Bus: 1. per ogni risorsa verifica se esistono vincoli imposti da operazioni in esecuzione 2. se i parametri di esecuzione dell operazione DIFFERISCONO da quelli dei vincoli imposti dalle operazioni in esecuzione per la risorsa considerata impone il vincolo richiesto 3. se i parametri di esecuzione dell operazione SONO IDENTICI a quelli dei vincoli imposti dalle operazioni in esecuzione per la risorsa considerata, verifica la compatibilità del tipo accesso richiesto rispetto a quello esistente secondo le regole esemplificate nella tabella che segue: Tipo Accesso richiesto Tipo Accesso in essere NO_LOCK READ WRITE EXCLUSIVE NO_LOCK READ WRITE EXCLUSIVE Legenda: 1 sta per accesso compatibile; 0 sta per accesso incompatibile(conflitto) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 23 di 108

24 2.4.4 Impostazioni per la gestione conflitti I passi logici da compiere per poter imporre uno o più vincoli su risorse virtuali richiesti all atto dell esecuzione di un operazione sono i seguenti: - Definizione delle risorse utilizzate dall operazione - Creazione del legame operazione-risorsa virtuale - Richiamo del servizio di ACG Service Bus Definizione delle risorse utilizzate dall operazione Tramite la voce di menu Crea Risorsa Virtuale, presente nel menu ACG Vision4Service busconflitti e possibile definire una nuova Risorsa Virtuale In essa è possibile indicare: - Il nome della Risorsa virtuale (Obbligatorio) - La descrizione ad essa associata - se l accesso alla risorsa può essere parametrizzato con i parametri di sistema Azienda, Sistema Informativo, Utente (checkbox corrispondenti selezionati) All atto del salvataggio dell operazione, alla risorsa creata viene associato un identificativo numerico univoco (Id. risorsa) che ne costituisce la chiave di accesso: viene controllato che il nome impostato per la Risorsa non sia già stato utilizzato. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 24 di 108

25 Una volta salvata l operazione è possibile associare ad essa uno o più parametri specifici, utilizzando l apposito pannello sottostante ed opzionalmente un valore per il parametro stesso. Nell esempio è stata definita la risorsa virtuale ANCL200F, a cui sono stati associati due parametri: il parametro di sistema Azienda ed il parametro PARAMETRO1. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 25 di 108

26 Creazione del legame operazione-risorsa virtuale Per associare ad un operazione le risorse virtuali che essa deve allocare all atto della sua esecuzione, occorre andare in modifica dell operazione e fare click sulla linguetta Risorse Virtuali. Tramite il pannello Crea associazione operazione risorsa e possibile indicare: la risorsa richiesta dall operazione, tramite la sua chiave numerica univoca, Id. risorsa oppure tramite il suo nome logico (Nome) il tipo di accesso richiesto (NO_LOCK, READ, WRITE, EXCLUSIVE) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 26 di 108

27 Nell esempio si e associata all operazione Operation01, la Risorsa Virtuale di nome ANCL200F con Tipo Accesso Write. Questo vuol dire che si vuole che all atto dell esecuzione della operazione si vuole imporre il vincolo sulla risorsa suddetta altrimenti deve essere segnalata l impossibilità dell esecuzione dell operazione per conflitto con una o più operazioni Richiamo del servizio di ACG Service Bus a codice All atto dell esecuzione di una operazione occorre richiamare il metodo public Object checkconflictsoperation(acglogon logon, Map userparametersmap,string operationid, boolean lock) throws Exception {throws Exception della classe com.ibm.acgv4.model.kopreshome. Il metodo richiede in input: 1. una istanza di ACGLogon 2. una collection di tipo Map contenente la lista dei parametri di specializzazione per ogni risorsa virtuale utilizzata dall operazione 3. il codice dell operazione da eseguire 4. il parametro lock di tipo boolean, che indica se si devono allocare le risorse (true) oppure (false) se si vuole solo controllare se potenzialmente l operazione può partire oppure no Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 27 di 108

28 Il metodo ritorna: se lock e passato a true, un array di interi contenenti gli id dei vincoli imposti oppure genera una BaseException contenente le ragioni per le quali non si e potuto vincolare le risorse richieste (collection di BaseException se lock e passato a false, la Map dei parametri richiesti per ogni risorsa avvalorata ( per i parametri di sistema e per quelli con un default sull archivio delle risorse virtuali) oppure genera una BaseException contenente le ragioni per le quali non si e potuto vincolare le risorse richieste (collection di BaseException) Dato che un operazione può imporre vincoli su più di una Risorsa virtuale, il nome del parametro deve essere preceduto dal prefisso NOME_RISORSA_VIRTUALE_ : ad esempio ANCL200F_PARAM1 Per quanto riguarda i valori dei parametri di sistema KSYSI (Sistema Informativo), KCOMP (Azienda) associati ad una risorsa virtuale, essi sono automaticamente avvalorati dal metodo sopraccitato, utilizzando le credenziali di accesso solo se ad essi e associato nella collection il valore blank o null, altrimenti viene controllata l autorizzazione ad operare sull azienda o sistema informativo specificati nella collection; il parametro KUSER (Utente) viene sempre avvalorato utilizzando le credenziali di accesso. Ad esempio se l operazione richiede un vincolo sulla risorsa ANCL200F con parametro di sistema azienda: se nella collection è presente il parametro ANCL200F_KCOMP con associato il valore blank o null, il metodo avvalorerà automaticamente tale parametro all azienda a cui si e collegati se nella collection è presente il parametro ANCL200F_KCOMP con associato il valore AZIENDA1, il metodo controllerà la autorizzazione ad operare sulla azienda AZIENDA1 Per quanto riguarda i parametri specifici, se nella collection ad esso è associato il valore blank o null, il metodo avvalorerà automaticamente tale parametro con il valore di default associato a livello di anagrafico Risorse. Il metodo ritornerà: un array contenente le chiavi dei vincoli imposti, necessario per poter cancellare al termine dell operazione i vincoli imposti dall operazione oppure genererà (throw) una BaseException contenente i conflitti a causa dei quali non e stato possibile vincolare le risorse richieste con il tipo di accesso specificato Richiamo del servizio di cancellazione dei vincoli Nel caso in cui un operazione apponga dei vincoli al termine di essa deve liberare le risorse virtuali allocate mediante la cancellazione di questi vincoli. Per fare cio occorre richiamare il metodo public synchronized void releaseresources(int[] runtimeidlist) throws Exception della classe om.ibm.acgv4.model.kopreshome. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 28 di 108

29 Il metodo richiede in input l array di interi che rappresentano le chiavi dei vincoli apposti sulle risorse dall operazione ritornato dal metodo checkconflictsoperation sopraccitato Richiamo automatico del servizio conflitti per le Action di Struts E stata modificata la chain of responsibility di struts per aggiungere l aspetto di richiamo automatico del servizio dei conflitti per un operazione all atto del richiamo di un metodo di un action di struts a cui e associata un operazione. Sono previsti due comportamenti: 1. Se l operazione richiede vincoli su risorse che non hanno parametri oppure hanno parametri di sistema che il Service Bus e in grado di avvalorare automaticamente oppure ha il parametro KEY ed i nome dei campi in esso contenuti sono presenti nella ActionForm e l operazione corrispondente ha il campo KOPEN impostato al nome della Risorsa virtuale da considerare per il parametro KEY allora il Service Bus tenta di vincolare le risorse richieste e se del caso da errore di conflitto. 2. Se non si rientra nel caso precedente, allora il Service Bus prepara la Map dei parametri richiesti per ogni risorsa dall operazione, avvalorando i parametri che può avvalorare( di sistema, parametro KEY, parametri che hanno un valore di default nell archivio delle risorse virtuali) e la mette come attributo della request con chiave ACGDispatchAction.ATTRIBUTE_PARAMETER_MAP. In questo caso il programmatore nel metodo dell action in questione prevederà al completamento della collection di tipo Map dei parametri ed al richiamo del servizio di lock come di seguito indicato: ::::::::::::::::::::::::::::::::::::::: // all interno del metodo dell action cui corrisponde l operazione if (!isoperationlocked(request)) { System.out.println("programmer locking!!"); operationlock(logon, request, hibsession); } ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: private void operationlock(acglogon logon, HttpServletRequest request, Session hibsession) throws Exception { String myfield = (String) request.getparameter(myfield); Map requestparametersmap = (Map) request.getattribute(attribute_parameter_map); if (requestparametersmap ==null) requestparametersmap=new HashMap(); requestparametersmap.put("resource1_myfield", myfield); int[] conflicts = null; try { KopresHome home = new KopresHome(); Transaction tx = hibsession.gettransaction(); conflicts = (int[])home.checkconflictsoperation(logon, requestparametersmap, (String) request.getattribute( OperationsConflictsMgmtCmd.ATTRIBUTE_OPERATION_ID),true); } catch (BaseException e) { e.printstacktrace(); throw e; Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 29 di 108

30 } putobjinsession(request,conflicts, ATTRIBUTE_OPERATION_LOCKS); } Nel primo caso alla chiusura della finestra il Service Bus provvederà a cancellare automaticamente i vincoli richiesti; anche nel secondo caso, se il programmatore ha salvato l array dei vincoli apposti nella Sessione http tramite il metodo putobjinsession con suffisso ATTRIBUTE_OPERATION_LOCKS, il Service Bus provvederà a cancellare automaticamente i vincoli richiesti altrimenti deve provvedere egli stesso. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 30 di 108

31 Richiamo automatico del servizio conflitti per i batch Per ogni operazione batch che deve essere eseguita, per far eseguire al Service Bus le stesse operazioni eseguite per le action di struts, occorre passare come parametro del JOB con chiave ACGV4GlobalJobListener.DO_OPR_CONFLICTS una variabile di tipo boolean impostata a true. In questo caso il Service Bus: Se l operazione richiede vincoli su risorse che non hanno parametri oppure hanno parametri di sistema che il Service Bus e in grado di avvalorare automaticamente oppure ha il parametro KEY ed i nome dei campi in esso contenuti sono presenti tra i parametri del JOB, allora il Service Bus tenta di vincolare le risorse richieste altrimenti da errore di conflitto e NON fa partire il JOB. Se il job parte alla sua terminazione il Service Bus rilascerà i vincoli sulle risorse Se non si rientra nel caso precedente, allora il Service Bus prepara la Map dei parametri richiesti per ogni risorsa dall operazione, avvalorando i parametri che può avvalorare( di sistema, parametro KEY, parametri che hanno un valore di default nell archivio delle risorse virtuali) e la mette come attributo del JOB con chiave ACGV4GlobalJobListener.ATTRIBUTE_PARAMETER_MAP. In questo caso il programmatore nel metodo dell action in questione prevederà al completamento della collection di tipo Map dei parametri ed al richiamo del servizio di lock come di seguito indicato; Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 31 di 108

32 Visualizzazione vincoli esistenti sulle risorse Tramite la voce di menu Vincoli su Risorse Virtuali, presente nel menu ACG Vision4Service busconflitti, l amministratore del sistema può visualizzare i vincoli sulle risorse esistenti. La parte superiore della finestra consente di impostare dei parametri di filtro sui vincoli delle risorse virtuali da visualizzare. All atto dell apertura la finestra non mostra I vincoli esistenti (lazy loading): premendo il bottone di ricerca in alto a sinistra viene effettuata la ricerca con I parametri impostati ( se non imposto I parametri vengono visualizzati tutti i vincoli presenti). Il doppio click su un vincolo della lista mostra il dettaglio del vincolo nel pannello sottostante. Selezionando un vincolo e possibile rimuoverlo dal sistema tramite il bottone standard di cancellazione. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 32 di 108

33 2.5 Workflow Concetti di Base Il workflow è l automazione parziale o totale di un processo di business e si compone generalmente di un insieme di attività, durante l esecuzione delle quali informazioni e/o attività passano da un partecipante al processo all altro, seguendo un insieme di regole predefinite. Le attività possono consistere in passi o interventi manuali richiesti all utente od essere completamente automatizzate. Un altro obiettivo del workflow è quello di tracciare e misurare l esecuzione delle attività di cui si compone il processo. Nella descrizione del workflow di un processo si possono distinguere i seguenti elementi ricorrenti: Attività (o task): i processi sono composti da attività da eseguire, che possono essere elementari, e quindi avere una definizione precisa e immediata di specifici compiti, o essere a loro volta costituite da un insieme di attività da svolgere; si parla in quest ultimo caso di descrizione a più livelli o gerarchica dei processi, e i processi si definiscono come costituiti da sottoprocessi Dati/oggetti manipolati: le attività di un processo sono basate su operazioni svolte su oggetti; tali oggetti possono essere di natura diversa, oggetti fisici o documentali. Agenti/ruoli: ad ogni attività è possibile identificare direttamente l agente o meglio il ruolo aziendale che è responsabile dell esecuzione di una singola attività. È importante che l assegnamento delle attività agli agenti possa essere effettuato in modo flessibile e in modo da minimizzare i cambiamenti necessari a fronte di modifiche nella struttura del processo o dell organizzazione Punti di decisione: i punti di decisione sono importanti all interno dei processi, perché solitamente comportano strade alternative nell esecuzione dei passi successivi del processo e possono portare a diverse fasi di negoziazione prima di raggiungere il risultato. Stato: identifica la fase in cui si trova un processo Transizioni: rappresentano lo spostamento del processo da uno stato ad un altro attraverso l'applicazione di una predeterminata azione Workflow in ACG Service Bus Nel contesto di ACG Service Bus l analisi applicativa è condotta tramite tecniche di identificazione dei processi di business e scomposizione degli stessi in attività: ciò permette di evidenziare e dettagliare nel flusso applicativo una sequenza di attività che da un lato rende più flessibile la gestione del processo, dall altra di poter stabilire ruoli diversi per l esecuzione delle singole attività. Nei processi di gestione delle entità di business significative (Richiesta di Preventivo, Ordine, Evasione, etc.) può essere prevista nel processo una fase particolare di approvazione dell entità. Si rimarca che l attivazione del workflow è opzionale e dipendente dal Sistema Informativo. ACG Service Bus fornisce supporto all implementazione di workflow consistente in esecuzione di attività (fasi) in maniera sequenziale nella seguente accezione: per garantire la tracciabilità delle attività esse sono ricondotte ad operazioni di ACG Service Bus; il processo è esso stesso una operazione con tipo operazione PROC Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 33 di 108

34 per garantire l assegnazione diversificata ed esclusiva delle attività agli esecutori occorre associare i ruoli abilitati ad eseguire le operazioni l interfaccia grafica relativa ad un processo cambierà a seconda della fase (stato) in cui è il processo sia in termini di operazioni eseguibili sia in termini di informazioni imputabili e/o visualizzabili relative all entità applicativa corrispondente Al fine di rappresentare un processo di business secondo le tecniche del workflow è stata introdotta nella libreria ACGGAA la tabella KPROC00F di cui si riporta il tracciato* Campo Tipo Lunghezza Descrizione KPRID CHARACTER 30 Process id (Campo CHIAVE) KPROP CHARACTER 30 Operation id (Campo CHIAVE) KSYSI CHARACTER 10 Information System (Campo CHIAVE) KPRSN NUMERIC 3 Sequence number (Campo CHIAVE) KPRIS CHARACTER 2 Input state KPROS CHARACTER 2 Output state Note: - KPRIS rappresenta lo stato di ingresso (prerequisito) per eseguire l operazione KPROP del processo KPRID - KPROS rappresenta lo stato di uscita all esecuzione dell operazione KPROP del processo KPRID Inoltre è stata introdotta la tabella KPRSI00F di cui si riporta il tracciato* Campo Tipo Lunghezza Descrizione KPRID CHAR 30 Process id (Campo CHIAVE) KSYSI CHAR 10 Information System (Campo CHIAVE) Esempio: Si supponga di voler modellizzare il processo di immissione di una Banca, che identifichiamo come BNK_insert, costituito da tre attività sequenziali: 1. Immissione dati generali, che identifichiamo con BNK_insert_basic_data, di responsabilità del ruolo di responsabile amministrativo che codifichiamo come RESP_AMM 2. Immissione dati contabili, che identifichiamo con BNK_insert_accounting_data, di responsabilità del ruolo contabile che codifichiamo come CONTABILE 3. Approvazione finale dell immissione della Banca, che identifichiamo con BNK_approve, di responsabilità del ruolo di responsabile amministrativo Nel file KOPER00F saranno inserite le seguenti informazioni: Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 34 di 108

35 KOPID KOPDS KO PAC KOP TP KOPUR KOP UM KO PUP KO PAA KO PGR KO PRP BNK_insert BNK_insert_bas ic_data BNK_insert_acc ounting_data BNK_approve Inserimento dati bancari Inserimento dati di base Inserimento dati contab. Approv. dati banca Y PROC N N GA4 N Y Y Y./BankAction.d o?xmethod=init./bankaction.d o?xmethod=init./bankaction.d o?xmethod=init Y Y GA4 Y N Y GA4 N N Y GA4 Y Nel file KOPRL00F verranno inserite le seguenti informazioni per associare i ruoli alle operazioni: KOPER KROLE KFLGR BNK_insert_basic_data RESP_AMM N BNK_insert_accounting_data CONTABILE N BNK_approve RESP_AMM N Nel file KPROC00F verranno inserite le seguenti informazioni per descrivere la sequenza di attività di cui si compone il processo KPRID KPROP KSYSI KPRSN KPRIS KPROS BNK_insert BNK_insert_basic_data *ALL 1 D G BNK_insert BNK_insert_accounting_data *ALL 2 G C BNK_insert BNK_approve *ALL 3 C Nel file KPRSI00F verranno inserite le seguenti informazioni per attivare il processo di workflow su un particolare Sistema Informativo, codificato come S1. KPRID BNK_insert KPRSI S1 Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 35 di 108

36 2.5.3 Lista definizione processi Scegliendo dal menu ACG Vision4 la voce Servizi di baseworkflowlista definizioni processi è possibile visualizzare i processi di workflow esistenti e le operazioni (step) di cui si compongono; in pratica viene visualizzato il contenuto della tabella KPROC00F presente in ACGGAA. Tramite il menu pop-up è possibile: 1. creare un nuovo step di processo 2. creare uno step successivo 3. modificare uno step di processo a quello selezionato sulla lista 4. cancellare uno step di processo Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 36 di 108

37 2.5.4 Motore di gestione delle regole di business Nella esecuzione di un processo non è infrequente voler condizionare il passaggio di un oggetto di business da uno stato piuttosto che ad un altro in base a regole di business, che operino sui dati di business dell oggetto. Si pensi ad esempio al caso del processo di workflow dell immissione di una banca in cui si voglia che l attività di approvazione sia richiesta solo se l importo del fido immesso per la banca superi un certo valore: questo valore deve essere suscettibile di cambiamento senza dover intervenire nel programma che gestisce l immissione. ACG service bus fornisce componenti atti a: caricare dinamicamente regole scritte in formato xml, in un formato quindi comprensibile e modificabile dall utente finale; le regole possono utilizzare operatori matematici, logici, espressioni, possono invocare metodi su oggetti java passare i dati di business (come java bean) che le regole valutano e/o modificano eseguire le regole e ricevere quindi l output di esse I passi da seguire per poter eseguire una regola sono i seguenti: Definire in formato xml la regola di business, i dati su cui essa opera: ad esempio la regola che segue valuta l importo del fido contenuto nell oggetto bank: se esso è inferiore a 1000, pone lo stato dell oggetto bank( invocazione del metodo setata03 con parametro <?xml version="1.0" encoding="utf-8"?> <ruleset name="bankrulesapprove" xsi:nonamespaceschemalocation="./rules.xsd" xmlns:xsi=" <!-- Name of the rule to execute, and whether it should be automatically run, when rule set is executed --> <rule name="calculatestatus" auto="true"> <if> <!-- IF: properties.isautosetstatus() == true --> <condition> <booleanexpression conditionaloperator="lessthan"> <get objectid="bank" type="integer" method="impfi" /> <value type="integer">1000</value> </booleanexpression> </condition> <then> <!-- SET: bank.setata03('a') --> <invoke objectid="bank" method="setata03"> <value type="character"> </value> </invoke> </then> </if> </rule> </ruleset> Inserire opportunamente nel codice java della parte controller o nelle classi di business il caricamento e l esecuzione della regola, passando i dati di cui necessita sotto forma di java bean e gestire il risultato 8output) dell esecuzione della regole protected char getnextstatus(char status, HttpServletRequest request,httpservletresponse response) throws Exception{ System.out.println("in getnextstatus "+status); try { if (status=='g') { // cerco file di condizione sullo stato String path="/rules/ga4rules.xml"; System.out.println("path xml rules "+path); RuleManager rulem = (RuleManager) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 37 di 108

38 getobjfromsession(request, "RuleManager"); RuleSet ruleset =null; if (rulem==null) { rulem=new RuleManager(); rulem.loadruleset("ga4rules",path); } ruleset = rulem.getruleset("ga4rules","bankrulesapprove"); RuleSet ruleset2 = rulem.getruleset("pipor ","BankRulesApprove"); putobjinsession(request, rulem, "RuleManager"); if (ruleset!=null){ System.out.println("ruleSet trovata "+ruleset); Rule rule = ruleset.getrule("calculatestatus"); System.out.println("rule"+rule); // Instantiate the rule manager, and create a session object (container for rules engine) RuleSession session = rulem.createsession(); // Set the objects that will be processed by the rule Anba200f element = (Anba200f) getobjfromsession(request, ANBA200F_SUFFIX); session.put("bank", element); // execute the rule rule.execute(session); session.clear(); System.out.println("Status from rule mgr "+element.getata03()); if(element.getata03()!=status) return element.getata03(); } } } catch (ExecutionException e) { // TODO Auto-generated catch block e.printstacktrace(); } catch (RuleException e) { // TODO Auto-generated catch block e.printstacktrace(); } Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 38 di 108

39 2.6 Messaggistica Uno degli obiettivi di ACG Service Bus è quello di fornire un componente infrastrutturale, atto ad implementare un canale di comunicazione tra i propri servizi/componenti e servizi/componenti di terze parti. ACG Service bus, quindi, deve fornire l infrastruttura atta a centralizzare e supportare le funzionalità tipiche richieste per utilizzare un canale di comunicazione, quali supporto all invio/ricezione di messaggi in modalità sincrona ed asincrona, routing e/o trasformazione degli stessi Utilizzo delle funzionalità presenti in Websphere Application Server 6.0.X Scopo di ACG Service Bus è quello di implementare una architettura distribuita aderente alla architettura SOA a bus condiviso in maniera tale che le applicazioni siano integrate ed operino come servizi. A tale scopo ACG service Bus utilizza quanto offerto da Websphere Application Server 6.0.X: infatti esso fornisce l infrastruttura di base per implementare l architettura sopracitata, fornendo un motore per il messaging, Websphere V6 Messaging Resources, noto come SiBus, i cui componenti principali sono i seguenti: Il Bus che implementa il canale di comunicazione a cui spedire o da cui ricevere messaggi le destinazioni, o meglio la lista di destinazioni definite per il bus atte a ricevere i messaggi, che rappresentano logicamente code di messaggi o topic in uno scenario di tipo publish and subscribe I mediatori, che sono associati alle destinazioni e permettono di operare o trasformazioni sui messaggi ricevuti dal bus prima che siano inviati alle destinazioni o implementare decisioni di routing (la logica con la quale stabilire a quali destinazioni spedire i messaggi) Websphere V6 Messaging Resources supporta direttamente lo scenario in cui la sorgente di un messaggio e la destinazione di esso sono Web services, tramite protocolli di trasporto SOAP sia tramite HTTP che JMS. Websphere V6 Messaging Resources è il JMS provider integrato nell application server. Java Message Service (JMS) è un'insieme di API Java che permette di creare, spedire, ricevere e leggere messaggi. JMS definisce un'interfaccia comune indipendente dalla specifica implementazione del sistema di messaging in modo analogo a quanto avviene con JDBC e JNDI. L'applicazione Java che utilizza JMS risulta così essere indipendente, oltre che dal sistema operativo, anche dalla specifica implementazione del sistema di messaging. L API standard JMS supporta due modelli diversi per lo scambio di messaggi: Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 39 di 108

40 il modello Point-To-Point è caratterizzato dal fatto che più produttori e più consumatori possono condividere la stessa destinazione (Queue) e ogni messaggio ha un solo consumatore; questo permette di fatto una comunicazione uno a uno. Non ci sono dipendenze temporali tra sender e receiver del messaggio e quindi il receiver può ricevere il messaggio anche se non era in ascolto sulla coda al momento dell'invio. Il messaggio viene tolto dalla coda una volta che il ricevitore l'ha prelevato confermando (acknowledge) la ricezione al produttore. L'utilizzo del messaging PTP è da utilizzare nel caso si abbia l'esigenza che ogni messaggio spedito sia ricevuto (e confermato) da un solo consumatore il modello Publish/Subscribe permette una comunicazione uno a molti dal momento che ogni messaggio inserito nella destinazione (topic) può essere inoltrato a tutti i destinatari che si sono dichiarati (subscription) interessati. Il provider JMS si prende carico di distribuire i messaggi inviati ("pubblicati") da più publishers i quali sono automaticamente ricevuti da tutti i client sottoscritti ("subscribed"), cioè che si sono dichiarati interessati alla ricezione. I client possono essere dinamicamente o publisher o subscriber o entrambi. Esiste una dipendenza temporale tra publisher e subscriber visto che il receiver può consumare il messaggio solo dopo essersi "sottoscritto" (subscription) al topic d'interesse dopo che il client ha effettivamente inviato il messaggio. Inoltre il receiver deve rimanere attivo se vuole continuare a ricevere. Il messaggio una volta consumato da tutti i subscriber interessati viene tolto dal Topic. Le API JMS rilassano i vincoli temporali mediante il concetto di Durable Subscriptions. Le Durable subscriptions permettono di ricevere i messaggi anche se i subscribers non erano in ascolto poichè i messaggi vengono resi persistenti, ad esempio mediante memorizzazione su database. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 40 di 108

41 2.6.2 Componenti JMS Le componenti JMS coinvolte nella spedizione/ricezione di messaggi sono le seguenti: Connection Factory È la interfaccia utilizzata dal client per ottenere una connessione con il message server. Si utilizza l'interfaccia ConnectionFactory : Context ctx = new InitialContext(); ConnectionFactory theconnectionfactory= (ConnectionFactory)ctx.lookup("TheConnectionFactory"); Destination Rappresenta l'astrazione di una particolare destinazione. Anche in questo caso il client identifica la destinazione mediante l'utilizzo delle API JNDI. Destination q = (Destination) ctx.lookup( mydestination ); Connection Rappresenta l'astrazione di una connessione attiva con un particolare JMS provider e si ottiene dall'oggetto Connection Factory. Connection connection = theconnectionfactory.createconnection(); Session L'interfaccia Session si ottiene dall'oggetto Connection e rappresenta il canale di comunicazione con una destinazione e permette la creazione sia di produttori che di consumatori di messaggi. La creazione della sessione permette di specificare il controllo della transazione e la modalità di acknowledge Session session = conn.createsession(false, Session.AUTO_ACKNOWLEDGE); Messages I messaggi JMS sono costituiti da tre parti: - un'intestazione (message header) - una serie di campi contenti proprietà (property fields) - il corpo (message body). Il message header è costituito esattamente da 10 campi che devono essere obbligatoriamente presenti. Tali campi sono usati sia dai client che dai provider al fine di identificare ed inoltrare il messaggio. Tra questi è presente l'identificatore univoco del pacchetto (JMSMessageID), il nome della Queue o Topic a cui il pacchetto è destinato(jmsdestination), la priorità (JMSPriority), il Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 41 di 108

42 timestamp del tempo d'inoltro (JMSTimestamp), l'id per collegare i messaggi JMS tra di loro (JMSCorrelationID). I property fields sono coppie di nome e valore e sono utili per costruire "filtri" livello applicativo. La caratteristica di questi campi è che possono essere esaminati mediante i message selectors. Quando un consumatore si connette al server può definire un message selector il quale esamina l'header e i property fields (non il body message) del pacchetto JMS di una specifica destinazione sia essa una Queue o un Topic. Questo permette alle applicazioni JMS di utilizzare i message selector per specificare quali messaggi è interessata a ricevere utilizzando una sintassi condizionale sottoinsieme del linguaggio SQL-92. Il filtraggio avviene a livello di server e permette di inoltrare ai client lungo la rete i messaggi strettamente necessari o utili risparmiando così la banda del canale. Un message selector non è altro che un oggetto di classe String che può contenere boolean literals (TRUE, true, FALSE and false), operatori logici(not, AND, OR),aritmetici(+,-,*,/), di comparazione(=, >, >=, <, <=, <> ), di ricerca (IS,LIKE,IN,NOT IN) ecc.. Esempi di message selector : "ROLE = CONTABILÈ "ROLE <> CONTABILÈ "NRIMO NOT BETWEEN 10 and 20" "ROLE = CONTABILÈ AND SI = SISTEMA_INFORMATIVO AND IMPORTO >= 100" I property field sono valorizzabili mediante i metodi setobjectproperty e getobjectproperty. Il metodo setobjectproperty accetta in ingresso valori di classe Boolean, Byte, Short, Integer, Long, Float, Double e String e se si cerca di utilizzare qualsiasi altra classe viene generata l'eccezione JMSException. Le proprietà possono essere lette mediante i metodi get<class>property; nel caso di proprietà inesistente i metodi getstringproperty e getobjectproperty ritornano null, per le altre classi viene sollevata una NullPointerException. Infine le proprietà possono essere cancellate mediante il metodo clearproperties, lasciando il messaggio JMS con il campo PropertyFields vuoto. Body Message I messaggi JMS possono essere di vari tipi, ognuno dei quali mette a disposizione gli appositi metodi get() e set() - TextMessage (messaggi di tipo Stringa) - ObjectMessage (messaggi che contengono oggetti Serializzabili) - MapMessage (contengono coppie costituite da chiave/valore) - ByteMessage (contengono strema di bytes) - StreamMessage ( contengono strema di primitivi java con lettura/scrittura sequenziale) JMS non supporta uno specifico body per messaggi XML; in questi casi è utilizzabile il text message. I messaggi vengono creati mediante i metodi dell'interfaccia Session. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 42 di 108

43 L'interfaccia mette a disposizione i metodi create relativi ad ogni tipologia di message: createtextmessage, createobjectmessage, createmapmessage, createbytesmessage e createstreammessage prevedendo per ognuno di loro la versione overloaded che prevede come parametro in ingresso un oggetto di inizializzazione. TextMessage txtmsg; txtmsg = session.createtextmessage(); txtmsg.settext("esempio messaggio di testo"); ObjectMessage objmsg = session.createobjectmessage(); MessageProducer Il MessageProducer è l'oggetto che permette l'invio dei messaggi verso una particolare destinazione.utilizzando gli oggetti Session e Destination creati, si possono inizializzare uno o più message producer. MessageProducer queuesender = session.createproducer(q); Una volta creato il produttore, basta invocare il metodo send sull'oggetto queuesender.send(message); MessageConsumer Il MessageConsumer rappresenta un oggetto in grado di ricevere messaggi. Analogamente a quanto avviene per il Message Producer bisogna indicare l'oggetto Session e la Destination d'interesse per inizializzare correttamente l'oggetto Message Consumer. MessageConsumer queuereceiver = session.createconsumer(d); Nel caso Publish/Subscribe è inoltre possibile creare le DurableSubscriber mediante il metodo createdurablesubscriber sull'oggetto Session. Nella ricezione in modo asincrono il client definisce un message listener (una classe che implementa l'interfaccia javax.jms.messagelistener) e ogni qualvolta un messaggio arriva alla destinazione d'interesse, il JMS provvede ad invocare il metodo di callback onmessage. Si deve creare come primo passo un listener MessageListener topiclistener = new MyMessageListener(); e passarlo come argomento al metodi setmessagelistener dell'oggetto MessageConsumer consumer.setmessagelistener(topiclistener); Connesso il listener ci si pone in ascolto di ricevere e processare i messaggi invocando il metodo start sull'oggetto Connection: connection.start(); La classe MyMessageListener è una normale classe Java che implementa l'interfaccia MessageListener ridefinendo perciò il metodo onmessage. In tale metodo si mette la logica applicativa per gestire il contenuto del messaggio ricevuto; si effettua il controllo del tipo del messaggio ricevuto e se è del tipo corretto se ne processa il contenuto. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 43 di 108

44 public class MyMessageListener implements MessageListener { public void onmessage(message message) { try { if (message instanceof TextMessage) { TextMessage txtmsg = (TextMessage) message; System.out.println("Ricevuto : " + txtmsg.gettext());... if (message instanceof ObjectMessage) { objmsg = (ObjectMessage) message; MyMsgClass msg = (MyMsgClass)obj.getObject(); // MyMsgClass è una classe proprietaria serializzabile }... } } I prodotti di Messaging sono intrinsecamente asincroni in quanto produttore e consumatore del messaggio risultano disaccoppiati, nonostante questo è bene specificare che un MessageConsumer può ricevere i messaggi anche in modo sincrono. Nella ricezione dei messaggi in modo sincrono il consumatore richiede esplicitamente alla destinazione di prelevare il messaggio (fetch) invocando il metodo receive. Il metodo receive appartiene all'interaccia javax.jms.messageconsumer ed è sospensivo, cioè rimane bloccato fino alla ricezione del messaggio, a meno che non si espliciti un timeout finito il quale il metodo termina o si usa il metodo di ricezione senza attesa: public Message receive() throws JMSException public Message receive(long timeout) throws JMSException public Message receivenowait() throws JMSException Esempio di ricezione sincrona : while(<condition>) { Message m = queuereceiver.receive(100); if( (m!=null)&&(m instanceof TextMessage) { message = (TextMessage) m; System.out.println("Rx :" + message.gettext()); } } Finite le operazione di gestione del messaggio ricevuto, si effettua il cosiddetto codice di "pulizia" chiudendo la connessione JMS mediante il metodo close. connection.close(); Destinazioni utilizzate da ACG Service Bus Nel modello di sviluppo di ACG Service Bus si utilizzano: Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 44 di 108

45 una destinazione, ACGJMSRolesDest, di ACG Service Bus, associata ad una coda JMS atta a contenere i messaggi indirizzati a ruoli utente ( esempio richiesta di valorizzazione preventivo cliente per il ruolo Valorizzatore preventivi) una destinazione di ACG Service Bus, associate a Topic JMS, atte a contenere messaggi che rappresentano eventi applicativamente rilevanti che altre componenti ACG o di terze parti possono essere interessate a processare ( ad esempio messaggio di immissione preventivo cliente) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 45 di 108

46 2.6.4 Formato e proprietà messaggi per Ruolo Utente Quando un partecipante al workflow di processo completa la sua attività, induce un cambio di stato del un processo: per avvertire gli utenti responsabili dell esecuzione dell attività successiva occorre spedire un messaggio destinato al ruolo responsabile di quell attività. Per far gestire il messaggio al componente visuale Lista Messaggi per ruolo utente occorre impostare in maniera opportuna alcune proprietà del messaggio; Nome Obbligatorio Descrizione Proprietà ROLE SI Ruolo utente destinatario del messaggio WIN SI Identificativo WIN del dizionario per gestire il messaggio URL NO Metodo dell action da invocare all atto della visualizzazione della WIN KEY NO Parametri da passare alla WIN separati dal carattere SI SI Sistema Informativo a cui afferisce il messaggio CATALOG NO Nome completo di package del catalogo dei messaggi da cui reperire il testo Messaggio: se avvalorato, nel testo del messaggio occorre specificare la chiave del messaggio ACGServiceBus: Console di Websphere - Integrazione Servizi-Bus - click su ACGServiceBus Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 46 di 108

47 Console di Websphere- Integrazione Servizi-Bus- click su ACGServiceBus - click su Destinazioni Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 47 di 108

48 Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 48 di 108

49 2.7 Monitoring Contenuti applicativi Tutte le operazioni codificate in ambiente ACGVision4 possono essere monitorate in modo da tracciare le informazioni fondamentali quali: Data/ora di inizio attività Utente Sistema Informativo Numero Sessione Identificativo della window Indirizzo IP del client Codice Operazione Descrizione Operazione I criteri di selezione sono Sistema Informativo, Identificativo Sessione e Identificativo Operazione. In realtà, se non si fanno esclusioni, sono monitorati tutti i metodi referenziati nelle Action Struts, anche se questi non hanno corrispondenza con un Operazione codificata in KOPER00F. Se nell ambito di una sessione, ad esempio, si crea una richiesta di preventivo con una riga, la lista delle operazioni attive sarà di questo tipo: Le informazioni sono memorizzate sul file KFLOG00F nella libreria ACGGAA del database nativo su iseries e nello schema ACGGAA del DB2 su Win/Linux. Per memorizzare alcuni dati si utilizza la parte relativa alla KPJBU : Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 49 di 108

50 Identificativo Sessione: 5 caratteri da posizione 247 del campo KDJBA Identificativo Window: 60 caratteri da posizione 252 del campo KDJBA IP del client: 15 caratteri da posizione 312 del campo KDJBA Identificativo operazione : 30 caratteri da posizione 327 del campo KDJBA Descrizione operazione : 50 caratteri da posizione 357 del campo KDJBA Dati della form: 80 caratteri da posizione 407 del campo KDJBA La chiave di accesso è Id Sessione + Id Window + Id Operazione: quando si chiude la window, si dichiarano chiuse tutte le operazioni gestite in quell ambito. Riferendosi all esempio delle richieste di preventivo, quando si chiude la finestra principale tutte le operazioni (RDP_init, RDP_loadRows, RDP_save..) verranno aggiornate come terminate (KFLLG = F su KFLOG00F). Il monitoring delle operazioni avviene secondo il pattern Chain Of Responsability descritto nel paragrafo 4.5 ovvero eseguendo il Monitor Command dichiarato in acgv4-chain-config.xml. La chiave di accesso è Id Sessione + Id Window + Id Operazione: quando si chiude la window principale, si dichiarano chiuse tutte le operazioni gestite nell ambito della stessa sessione e quindi tutte le window relative. Riferendosi all esempio delle richieste di preventivo, quando si chiude la finestra principale, tutte le operazioni (RDP_init, RDP_loadRows, RDP_save..) verranno aggiornate come terminate (KFLLG = F su KFLOG00F) Parte Controller L Action di Struts che gestisce la lista delle operazioni attive parametrizzata per Sistema Informativo, identificativo sessione e identificativo operazione è SessionAction che semplicemente propone a video il sistema informativo di default. Con l action Find si esegue una query su KFLOG00F a partire dalle selezioni immesse. Parte View Questa la parte del dizionario relativa alle specifiche dei pannelli e window: //PANELS diz["pnl_parametricolistasessioni"]='{"id":"parametricolistasessioni", "type":"grid","formid":"formparsessioni","rows":"19","cols":"2","collapsed": "false","init":"true","url":"act_sns_init","label":"parametrico Lista Sessioni","fields":[' +$d2("fld_sisid","row:3,col:0,span:2") +','+$d2("fld_sessn","row:5,col:0,span:2")+','+$d2("fld_opeid","row:7,col:0, span:2")+'],"actions":['+$d2("act_findsessions","row:18,col:0")+']}'; diz["pnl_sessionslist"]='{ "id":"sessionslist", ' +' "style":"height:100%;width:100%;" ' +', ' + ' "url":"url_sessionslist" ' + ', ' + ' "click":"act_clicksessionslist" ' + ', ' + ' "dblclick":"act_dblclicksessionslist" ' Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 50 di 108

51 + ' } '; diz["pnl_session"]='{"id":"session", "formid":"formsession","rows":"19","cols":"2","collapsed":"false","label":"d ettaglio Sessione","url":"URL_Session","fields":['+$d2("FLD_SESSION","row:2,col:0")+','+$d2("FLD_WINDOW","row:4,col:0")+']}'; // URL diz["url_parms_sessionslist"]=' [ "ParametricoListaSessioni_formParSessioni_SISID", "ParametricoListaSessioni_formParSessioni_SESSN", "ParametricoListaSessioni_formParSessioni_OPEID" ] '; diz["url_sessionslist"]=''+xpfcontext+'/pf/xgenerictable.jsp?querydefinition FileName=com/ibm/acg/xml/KFLOG00F.xml' + USER_AND_PASSWORD + '&' + '&'+ '&'; diz["url_parms_session"]='[ "Session_formSession_SESSION","Session_formSession_WINDOW"]'; // WINDOWS diz["win_sessione"]= '{"window":{ "id":"sessione", "width":600, "height":200, "url":"../sessionsaction.do", ' + ' "panels":[ ' + diz["pnl_session"] +' ] ' +' },"parms":[ "Session_formSession_SESSION","Session_formSession_WINDOW"]}'; diz["win_paramsessions"]='{"window":{"id":"paramwindowsessions", "width":"500", "height":"500", "url":"../sessionsaction.do", ' + ' "panels":[' + diz["pnl_parametricolistasessioni"]+','+diz["pnl_sessionslist"] + ']},"parms": [ "ParametricoListaSessioni_formParSessioni_SISID","ParametricoListaSessioni_formParSessioni_SESSN","ParametricoListaSessioni_formParSessioni_OPEID"] }'; Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 51 di 108

52 2.8 Scheduling in ACG Vision4 In ACG Service Bus sono state create una serie di funzionalità che consentono di eseguire un operazione in maniera asincrona ad una specifica data ed ora oppure ad intervalli regolari. Tipici esempi sono la generazione di statistiche o la esecuzioni di operazioni massive che coinvolgono una gran mole di dati: di solito tali operazioni quindi sono pesanti in termini di carico indotto sul sistema ed è bene che siano eseguite in certi giorni od orari in modo da non penalizzare le performance dell applicazione. Utilizzo di Quartz Quartz è un framework open source che offre molte funzionalità di schedulazione e rappresenta uno standard de facto per schedulare delle attività in ambiente java. Quartz è un open source che consente agli sviluppatori meccanismi semplici ma potenti per la schedulazione dei lavori Le caratteristiche più importanti di Quartz sono le seguenti: semplicità di configurazione potenti e flessibili meccanismi di schedulazione o ad un certa data ed ora o o o in determinati giorni della settimana in certi giorni del mese in certi giorni dell anno o. Qualsiasi classe java può diventare un lavoro schedulabile implementando una semplice interfaccia Possibilità di salvare su database i lavori schedulati Possibilità di monitorare tutti gli aspetti della schedulazione e di tenere traccia dell'esito dei ogni job Si noti che Websphere fornisce uno schedulatore avanzato (Scheduler Service) solo per Enterprise Java Bean di tipo Session. Integrazione di Quartz con Websphere Quartz utilizza per l esecuzione dei lavori i Thread: nel programming model J2EE vi sono molte restrizioni al multi-threading; per esempio in J2EE 1.4 è sconsigliato creare a programma un thread in un container J2EE, in quanto il container non ha conoscenza nè tanto meno controllo di tali thread, che possono portare a peggiorare le performance del server web sino a portarlo in alcuni casi alla caduta del server. Per risolvere questo problema, ACG Service Bus fornisce i componenti per l integrazione dei servizi di schedulazione avanzati offerti da Quartz con il servizio di schedulazione asincrona fornito da Websphere. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 52 di 108

53 In questo modo è possibile: Schedulare una qualsiasi classe java che implementi una semplice interfaccia Demandare l esecuzione controllata a Websphere, e precisamente ad un WorkManager che implementa il concetto di Thread Pool, configurabile dall amministratore del sistema. Configurazione ACG Vision4Scheduling WorkManager ACG Service Bus dichiara nel descrittore di distribuzione l utilizzo di due WorkManager in analogia al Modulo Base ACG : 1.DefaultWorkManager, mappato per default sul WorkManager di default preimpostato all atto dell installazione di Websphere come Thread Pool con numero massimo di lavori contemporanei posto a 5 2.ACGV4_DIFFE_WorkManager, che l amministatore del sistema può creare per definire un Thread Pool con numero massimo di lavori contemporanei posto a 1 Si veda il paragrafo Configurazione WorkManager Persistenza Le tabelle necessarie per salvare i lavori schedulati sono create all atto dell installazione del Service Bus nella libreria ACGGAA. È necessario impostare nei files quartz.properties e quartz2.properties, situati in../web- INF/classes, la proprietà org.quartz.datasource.qzds.password alla password di accesso dell utente QPGMR (proprietà org.quartz.datasource.qzds.user) Lista Lavori schedulati Nel menu ACG Vision4Servizi di base Lavori schedulati è presente al voce di menu Lista Lavori è possibile visualizzare la lista dei lavori schedulati. Tramite pop up menu è possibile cancellare una schedulazione o visualizzarne i dettagli. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 53 di 108

54 Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 54 di 108

55 2.9 Generatore di codice per ACG Vision4 In ACG Service Bus sono state create una serie di funzionalità che consentono di generare il codice necessario ad implementare la gestione di un oggetto di business che si mappi su una tabella di database. Questa funzionalità, allo stato attuale dell arte, consente la generazione degli elementi software (file java, xml e javascript) necessari a realizzare le funzionalità cosiddette CRUD (create, read, update e delete) conformi al programming model di ACG Vision4. Il generatore di codice consente, attraverso le funzionalità presenti nel menu Strumenti in ACG Vision4, di alimentare automaticamente un dizionario di informazioni descrittive degli oggetti di business (nel seguito referenziati con l acronimo BO) attraverso la lettura della struttura dei file di database su cui sono mappati i BO. Un oggetto di business può essere un cliente, un fornitore, un magazzino, un ordine, etc. e rappresenta tipicamente un entità tipicamente descritta in un modello d analisi ad oggetti. Nello specifico vengono creati due set di informazioni descrittivi del BO e della tabella (oggetti di dizionario primari e secondari), in due archivi denominati KDIZ400F e KDIZ410F, che vengono installati nella libreria di gruppo del Sistema informativo di collegamento. Il programmatore può integrare le informazioni prodotte con informazioni non desumibili dalla lettura del DB (quali l obbligatorietà del campo nella funzione di gestione del BO, il tipo di componente visuale da utilizzare per la sua presentazione a video, etc.), utilizzando le specifiche funzioni di gestione degli elementi primari e secondari. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 55 di 108

56 Il primo passo che deve eseguire il programmatore richiede il lancio della funzione di lista degli elementi primari, da cui è possibile lanciare la funzione di creazione di un oggetto primario, utilizzando il menu contestuale che si apre su qualsiasi riga dopo aver cliccato il tasto sinistro del mouse. Viene così aperta la seguente finestra in cui si dovranno immettere: nome del BO (ad es. Cliente) una descrizione da associare al BO il nome del file di database su cui si mappa il BO (nell esempio ANCL200F) il flag Include dati comuni, da impostare con il segno di spunta se l oggetto di business include le informazioni tipiche delle anagrafiche ACG (flag di stato, date di creazione e ultima modifica, utenti di creazione e ultima modifica) Alla pressione del tasto di salvataggio, vengono alimentati i due file di dizionario creando i seguenti record: File KDIZ400F (Dizionario elementi primari) o Un record di tipo BUS_OBJ con identificativo il nome assegnato al BO, cui è associata la tabella di riferimento indicata o Un record di tipo TABLE con identificativo il nome della tabella di database Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 56 di 108

57 o Un insieme di record di tipo PROPERTY, il cui identificativo è dato dalla concatenazione del nome del BO e di campi della tabella di database; tali campi hanno come colonna di riferimento il nome della tabella di database ed il nome corrispondente della colonna nella tabella (nell esempio, Customer_CDCLI con colonna referenziata ANCL200F/CDCLI, Customer_RASCL con colonna referenziata ANCL200F/RASCL, etc.) File KDIZ410F (Dizionario elementi secondari) o Un insieme di record di tipo COLUMN, il cui identificativo è dato dalla concatenazione della tabella nome del BO e di campi della tabella di database; tali campi hanno un insieme di informazioni quali il tipo di dati, la lunghezza, il numero di cifre decimali nel caso di valori numerici, tipo di visualizzazione richiesta (testo, data, numeri, etc.) ed altre informazioni che possono essere aggiunte dall utente. Nell esempio vengono creati record il cui identificativo è ANCL200F_CDCLI, ANCL200F_RASCL, etc. Il programmatore può modificare od integrare le informazioni ottenute automaticamente relativamente agli elementi secondari, impostando un tipo di visualizzazione differente, specificando se il campo è di immissione obbligatoria ed impostando il campo Ordine nelle chiavi. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 57 di 108

58 Se quest ultimo campo è impostato a 0, si assume che il campo non è chiave, mentre un valore maggiore di 0 indica un campo chiave. Se la tabella di database ha solo un campo chiave (come nel caso di ANCL200F il cui campo chiave è CDCLI), basterà indicare il valore 1 su tale campo. Nel caso di una tabella con più campi chiave occorrerà numerare in sequenza i campi chiave (ad esempio nel caso di ANMG200F, su cui si mappano gli articoli a magazzino, occorrerà indicare il valore 1 per CDPAR ed il valore 2 per CDMAG) Nel caso di file di tipo testo è possibile specificare l insieme dei valori che può assumere con l indicazione delle relative decodifiche; il campo in questo caso viene rappresentato a video con un componente di tipo combo-box con la possibilità di scelta dei soli valori ammissibili per il campo. Terminata la fase di integrazione delle informazioni, l utente può lanciare la generazione del codice dalla finestra di gestione dell elemento di business, selezionabile dalla lista degli elementi primari, ciccando sul tasto Genera. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 58 di 108

59 In fase di generazione del codice è data la possibilità di specificare il nome di un file di configurazione da utilizzare per l elaborazione; viene proposto il valore di default CodeGenerator2 da utilizzare nel caso di generazione di un business object singolo. Il file viene ricercato nel percorso WEB-INF\classes\conf dell applicazione installata e contiene le seguenti voci (si riporta qui di seguito il contenuto del file CodeGenerator2.properties): #Config file for CodeGenerator2 #templates template_diz_label=diz_label2.vm template_diz_other=diz2.vm template_diz_menu=diz_menu2.vm template_hibernate_mapping_xml=table_name.vm template_hibernate_mapping_java=table_name_java.vm template_hibernate_mapping_home=table_name_home.vm template_hibernate_mapping_id=table_name_id.vm template_struts_config=strutsconfig.vm template_struts_action=strutsaction2.vm template_validation_xml=validation.vm #output dir output=output #generation language language=it #package package_hibernate=com.ibm.acgv4.model Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 59 di 108

60 package_action=com.ibm.acgv4.action avendo la possibilità di specificare: - i template di velocity da utilizzare per generare i tre file del dizionario visuale, - i template di velocity da utilizzare per generare le classi java ed il file XML di mappatura di hibernate - i template di velocity da utilizzare per generare la classe Action di Struts ed i file XML di mappatura e validation che devono integrare if file d configurazione e di validation del modulo di riferimento - il nome della directory in cui viene generato l output (nell esempio il percorso di destinazione è rappresentato dal path <context_root>\web-inf\classes\output) - la lingua con la quale sono generati eventuali commenti (se diversa da IT, i commenti saranno generati in lingua inglese) - i nomi dei package usati per generare il codice java Nell applicazione sono precaricati i file di properties CodeGenerator e CodeGenerator2 che generano il codice secondo due modalità differenti; si raccomanda di utilizzare il file CodeGenerator2.properties per sfruttare al meglio i controlli di autorizzazione sulle operazioni e sui campi. Nel caso di business object che implementano il pattern parent-child (Padre-figlio o testata-righe) si utilizzi il file HeaderRows secondo quanto specificato nel paragrafo Al termine dell elaborazione vengono prodotti nella cartella WEB-INF\classes\output nella cartella di installazione della web application acgv4 i seguenti file (avendo indicato con BOName il nome del business object e con NomeUtente il nome dell utente di generazione): diz_boname_nomeutente.js (ad esempio diz_customer_acgv4.js) contenente la descrizione della GUI in formato javascript; il file può essere importato direttamente nella cartella addon\diz nel percorso di installazione dell applicazione diz_boname_it_nomeutente.js (ad esempio diz_customer_it_acgv4.js) contenente le etichette (labels) associate agli elementi grafici definiti nel dizionario diz_boname.js diz_menu_boname_nomeutente.js (ad esempio diz_menu_customer_acgv4.js) contenente le voci da aggiungere al file dizmenu.js in addon\diz per includere le voci di menu che consentono il richiamo delle funzione di lista e di creazione del BO il file BOnameAction.java (ad es. CustomerAction.java) che rappresenta lo scheletro della classe Action di Struts il file BOnameStrutsConfig.xml che rappresenta la porzione di mapping di struts da aggiungere opportunamente nel file di configurazione del modulo struts di riferimento (mapping delle form e mapping dell action) le classi BOname.java, BOnameHome.java ed opzionalmente BOnameId.java (nel caso di BO con chiavi multiple) usate per gestire la mappatura di Struts il file BOname.hbm.xml usato per il mapping in Struts Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 60 di 108

61 I file generati possono essere manipolati opportunamente mediante i tool presenti in RAD o in Eclipse, qualora la web application sia stata importata come progetto web dinamico nell IDE. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 61 di 108

62 2.9.1 Autorizzazione campi Le informazioni di dizionario sono utilizzabili a runtime per effettuare un controllo di autorizzazione a livello di campo nelle funzionalità che referenziano gli stessi. un autorizzazione di campo. Attraverso la funzione Lista autorizzazioni è possibile creare o modificare un autorizzazione di campo che richiede: l indicazione di un ruolo su cui si intende applicare la restrizione i nomi della tabella e della colonna identificativi del campo di database il diritto che il ruolo ha sul capo; i valori possibili sono: a) nessuno: il campo a video associato a quello di database non viene visualizzato b) lettura: il campo a video associato a quello di database viene visualizzato come campo protetto (sola lettura) c) scrittura: il campo a video associato a quello di database viene visualizzato come campo di I/O (sola lettura) Viene mostrata qui di seguito la UI di immissione di Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 62 di 108

63 Nel caso in cui si indichi il valore *QUERY nel campo proprietà, il controllo di autorizzazione verrà effettuato sull intera tabella nell esecuzione delle query tramite persistent filters. Pertanto, se un ruolo ha diritto Nessuno su una tabella X, avendo specificato come detto la proprietà *QUERY, all atto dell esecuzione della query verrà emesso un messaggio di avvertimento come in figura: Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 63 di 108

64 2.9.2 Generazione di codice per BO che implementano il pattern parent-child Il code generator supporta la generazione di codice per due oggetti di business legati da una relazione parent child, vale a dire due oggetti di business per i quali l uno (il parent) possegga una collezione (0, 1 oppure n) oggetti dipendenti (figli). Tipicamente questa relazione prevede una mappatura su database su due tabelle SQL per le quali il parent ha n campi chiave ed il figlio un numero di campi chiave m > n, di cui i primi n siano coincidenti con quelli del padre. Le operazione da seguire per la generazione sono: 1. creare l elemento primario associato al padre 2. creare l elemento primario associato al figlio 3. modificare le property secondarie dell oggetto padre per definire l ordine delle chiavi ed impostare attributi di presentazione diversi da quelli di default (tipo visualizzazione, obbligatorietà, valori ammissibili) 4. modificare le property secondarie dell oggetto figlio per definire l ordine delle chiavi ed impostare attributi di presentazione diversi da quelli di default (tipo visualizzazione, obbligatorietà, valori ammissibili). L ordine delle chiavi deve essere tale per cui ci sia coincidenza nel campo Ordine delle chiavi tra le property chiave del padre e quelle del figlio 5. entrare in modifica dell elemento BUS_OBJ del business object padre e specificare nel campo Property File il valore HeaderRow e nel campo Oggetto figlio il nome del business object figlio e premere il pulsante Genera. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 64 di 108

65 2.10 Lista Stampe Scegliendo la voce di menu ACGVision4ReportingLista Stampe è possibile visualizzare le stampe prodotte e salvate in ACG Service Bus. Con il doppio click su un elemento si possono vedere le informazioni riguardanti la stampa, quali Nome Stampa, Tipo Stampa etc Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 65 di 108

66 Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 66 di 108

67 Se dal menu pop-up si sceglie la voce Apri è possibile visualizzare o salvare la Stampa Gestione stampanti ACG Vision4 Nella versione di ACG Service Bus e stata realizzata una funzione di gestione delle stampanti da associare all applicazione ACG Vision4; anche in questo caso è possibile definire un set di stampanti per installation id (vedi paragrafo 2.13 per informazioni sull installation id). I dati sono registrati sulla tabella PRTP400F avente per chiave un id numerico generato automaticamente; sulla tabella è definito un indice univoco sulle colonne Id Installazione e Printer name. Il file viene alimentato automaticamente all atto del setup. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 67 di 108

68 La funzione di modifica stampante consente di attivare/disattivare la stampante e di definirla come stampante predefinita. La funzione di aggiunta stampante permette di aggiungere una stampante selezionandola da una combobox che mostra tutte le stampanti visibili dall application server (ovvero la lista delle stampanti restituite da com.ibm.acgv4.ise.print.printerutils.retrieveprinternames(logon). Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 68 di 108

69 La funzione di gestione delle Stampe recupera le stampanti dal file PRTP400F attraverso la classe com.ibm.acgv4.base.svbprintermanager che effettua un caching delle stampanti attive al fine di minimizzare gli accessi al DB (la cache viene svuotata ogni volta che c è un aggiornamento del file PRTP400F ad opera della funzione di gestione delle stampanti) Salvataggio stampe in ACG Vision4 ACG Vision4 mette a disposizione un componente per salvare le stampe prodotte dalle applicazioni su tabelle del database, in particolare associate alla libreria ACGGAA. La classe che gestisce le stampe è com.ibm.acgv4.model.prtd400fhome Tale classe, che utilizza Hibernate per l accesso al database, contiene il metodo: public String saveprint(acglogon logon, InputStream in, String title, String description, String status, String userdata, String extension) throws Exception { Esso deve essere richiamato all interno di una Session di Hibernate valida (in stato open). Il significato dei parametri è il seguente: logon è l istanza di ACGLogon da cui vengono reperite le informazioni di collegamento dell utente ( Nome utente, Sistema informativo, etc.) in è la stampa che si vuole salvare come oggetto di tipo InputStream title è il nome della stampa che comparirà nella Lista stampe: dimensione massima 30 caratteri description è la descrizione della stampa che comparirà nella Lista stampe: dimensione massima 100 caratteri status è lo stato della stampa dimensione massima 2 caratteri userdata sono eventuali dati che si vogliono salvare con la stampa dimensione massima 100 caratteri extension è il tipo di stampa (MIME) che si sta salvando dimensione massima 3 caratteri (ad esempio pdf, xml, xls, doc etc) La chiamata a tale metodo permette di salvare i dati descrittivi della stampa nella tabella PRTD400F mentre il file di stampa viene salvato in una o più righe della tabella PRTC400F: in particolare se il file di stampa ha dimensione maggiore di 1GB viene spezzato in tante righe di dimensione massima di 1GB. La chiave della tabella PRTD400F è la colonna KPRID: essa è un numero progressivo NUMERIC(10). Se si vuole prendere il contenuto di una stampa occorre utilizzare il metodo: public void writeprintonstream(acglogon logon, Prtd400f stampa, OutputStream out, int buffersize) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 69 di 108

70 Esso scrive nell istanza out di tipo OutputStream il contenuto della stampa, istanza stampa di tipo Prtd400f; il parametro buffersize rappresenta la dimensione dei pezzi (chunck) di stampa da leggere dal database e trasferire in out: impostare il valore L istanza di stampa va reperita facendo una query ricercandola per chiave secondo il programming model di Hibernate. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 70 di 108

71 2.12 Gestione menu In ACG Vision4è prevista la possibilità di creare il menu ad albero recuperando le informazioni da tre tabelle di database: KMNOP00F: è la tabella che contiene le informazioni di struttura del menu ad albero KDES400F: è la tabella che contiene le descrizioni in lingua dei nodi dell albero KOPER00F: è la tabella delle operazioni che contiene le informazioni relative agli URL da invocare nel caso in cui si effettui un clic su un nodo terminale del menu ad albero La funzione di gestione del menu ad albero, per default, è accessibile agli utenti che hanno ruolo SYSTEM_ADM, ma può essere estesa ad altri ruoli andando a modificare l operazione il cui codice è 4TreeMenu. Si ricorda che il ruolo SYSTEM_ADM viene associato all atto del setup dei dati al profilo ACGMASTER. La finestra di gestione dei menu ad albero, all apertura, presenta una tipica struttura ad albero come in figura. Il nodo TOP rappresenta la radice dell albero e non deve essere modificato nè cancellato; al di sotto di tale nodo sono presenti più nodi di tipo Menu che corrispondono ai Menu visibili sulla Top Bar del desktop. Al di sotto di ciascun menu della top bar sono presenti ulteriori nodi di tipo Menu, che rappresentano dei sottomenu, oppure voci di tipo Operazione, che rappresentano le voci di menu che consentono l esecuzione delle diverse funzionalità. Le voci di tipo Operazione sono associate ad operazioni del Service Bus, dalle quali viene recuperato l URL come comando da eseguire. L URL di un operazione si presenta tipicamente nella forma: Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 71 di 108

72 js: comando javascript interpretabile dal componente UI engine (ad es. js:xcrtwin("f0","win_virtualresourcelist") per invocare la finestra di lista delle risorse virtuali) js: comando javascript standard (js:window.open("../products/ise/acgoise.zip") per aprire una finestra per effettuare il download del file acgoise.zip ) WIN: documento da richiamare (ad es: WIN:../wizard/doc/ACGV4Wizard.pdf per richiamare l apertura la guida in formato pdf del wizard visuale) {"id":"codice_azione_modulo_base", "type":"acgv3"} (ad esempio {"id":"aac0", "type":"acgv3"} per richiamare l azioneaac0 del Modulo Base ACG di gestione dell anagrafico clienti) Si noti che nella lista dei parametri specificati nell URL si è convenuto di utilizzare le virgolette ( ) in luogo del singolo apice ( ). Posizionandosi su un nodo di tipo Menu è possibile aprire il menu contestuale che prevede le seguenti operazioni: Crea menu Aggiungi operazione Cancella riga La voce Crea menu visualizza la seguente finestra, nella quale vengono preimpostati l identificati-vo e l acronimo del nodo genitore, l indicazione dell utente e del sistema informativo di riferimento al valore *ALL (nella attuale versione non è prevista la possibilità di creare menu per utente e/o sistemi informativi specifici). L utente deve indicare l identificativo del menu e la relativa descrizione, nonché modificare l acronimo; al salvataggio verranno creati un record in KMNOP00F con i dati di struttura dell albero ed un record in KDES400F con la descrizione in lingua della voce di menu. La voce Aggiungi operazione visualizza la seguente finestra, nella quale vengono preimpostati l acronimo e l identificativo del nodo genitore, l indicazione dell utente e del sistema informativo di rife-rimento al valore *ALL, come nel caso precedente. In questo caso l utente deve specificare un codice operazione esistente in anagrafica. Di default viene proposta la descrizione recuperata dal file delle operazioni KOPER00F ma può essere modificata dall utente. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 72 di 108

73 L acronimo può essere modificato. La voce Cancellazione riga elimina fisicamente la riga selezionata con tutti i nodi sottostanti, nel caso di nodo di tipo Menu. All atto del collegamento, l applicazione controlla che nella cartella customized nel percorso di installazione dell applicazione stessa sia presente il file denominato menu_utente_sistemainformativo.js (ad esempio menu_acg3user_acg3si.js nel caso di collegamento dell utente ACG3USER al sistema informativo ACG3I). Se non presente, viene creato tale file con le voci di navigazione recuperate dagli archivi che contengono le informazioni di struttura del menu ad albero, opportunamente filtrate sui ruoli utente e sui prodotti installati nel sistema informativo. Tale file riporta infatti le voci di navigazione nella seguente forma: diz["nav_top"]='acg USR LAST TOOLS HELP '; diz["lbl_it_top"]='top menu'; diz["nav_acg"]='4acgv4 '; diz["lbl_it_acg"]='applicazioni ACG'; diz["nav_usr"]='4changesisinfo RELOADMENU RESTOREMENU '; diz["lbl_it_usr"]='preferiti'; diz["nav_last"]='dellast '; diz["lbl_it_last"]='cronologia'; diz["nav_tools"]='debug SETTINGS '; diz["lbl_it_tools"]='strumenti'; diz["nav_help"]='4wizardhelp '; diz["lbl_it_help"]='aiuto'; diz["nav_4acgv4"]='4acgv4base '; diz["lbl_it_4acgv4"]='acg Vision4'; diz["lbl_it_4changesisinfo"]='cambio Sistema Informativo'; diz["cmd_4changesisinfo"]='js:xcrtwin("f0", "WIN_xCHANGESISINFO")'; in cui le voci di tipo NAV rappresentano i nodi di ipo Menu, quelle di tipo CMD i comandi associati ai nodi di tipo Operazione e quelle di tipo LBL le descrizioni dei diversi nodi. Come detto precedentemente, all atto della costruzione del file menu_utente_sistemainformativo.js vengono rimossi i nodi di tipo Operazione che sono associati ad operazioni di ACG Service Bus per le quali l utente non è autorizzato (vedasi associazioni utenti-ruoli e operazioni-ruoli). Inoltre, sulla base dell acronimo associato alle operazioni, vengono filtrate le operazioni relative a moduli che non sono stati installati nel Sistema Informativo, potendo recuperare le informazioni di installazione dei moduli dal file di controllo ACGGAA/KINST10F. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 73 di 108

74 Nel menu Preferiti sono presenti le seguenti voci: Ricarica albero dei menu: il file menu_utente_sistema-informativo.js viene ridenominato come menu_utente_sistema-informativo.bak e ricreato Ripristina albero dei menu: se esiste, il file menu_utente_sistema-informativo.bak viene ridenominato come menu_utente_sistema-informativo.js. Se il file con estensione.bak non è presente, viene emesso un messaggio del tipo File di backup non trovato. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 74 di 108

75 2.13 Controllo sul numero utenti collegati ad ACG Vision4 Nel presente paragrafo vengono elencati i punti fondamentali che descrivono la soluzione implementata per il controllo del numero di utenti collegati in ACG Vision4. a) Il controllo del numero degli utenti che accedono alle funzioni ACG Vision4 è basato sul numero di utenti specificato in fase di immissione delle password per il modulo di appartenenza (ad esempio nel caso in cui venga invocata una funzione di Finance, viene controllato il numero di utenti per il prodotto 5733-R01 Amministrazione) b) Il controllo del numero utenti è a livello di Application Server, dato che la password per i prodotti è correlata all ID d installazione del WAS su cui risiedono le applicazioni ACG Vision4. Non è possibile pertanto installare ACG Vision4 su due application server distinti, in quanto il controllo password fallirebbe per una delle due installazioni (quella con installation id diverso da quello specificato all atto dell immissione delle password di prodotto) c) Il controllo del numero utenti è multi-applicazione, vale a dire che tiene conto del fatto che è possibile installare più web-app ACG Vision4 sullo stesso WAS. Il conteggio degli utenti effettuato per tutte le applicazioni installate determina il numero totale degli utenti che utilizzano funzioni Vision4 d) Un utente può aprire più browser dalla stessa macchina client e collegarsi alle applicazioni ACG Vision4 da ciascun browser, venendo contato una sola volta. E stato limitato a 3 il numero dei browser che possono essere contemporaneamente aperti e collegati alla Vision4 per ciascuna macchina client e) In un browser che visualizza il desktop Vision4, l invocazione di più funzioni appartenenti allo stesso modulo o gruppo di moduli (si veda quanto specificato successivamente nel punto g per il gruppo di moduli) aperte in successione, fa sì che il contatore associato al modulo venga incrementato una sola volta. Infatti il meccanismo di conteggio è tale per cui, dallo stesso client, se ad esempio viene invocata una funzione di SCM e poi una di Finance, il contatore delle funzioni Vision4 viene incrementato di 1 e non di 2. Se viene invocata per prima la funzione di SCM, la verifica sulla possibilità che è possibile eseguire la funzione per mancato raggiungimento del numero massimo di utenti ammessi viene effettuata sulla base del numero massimo di utenti specificato all'atto dell'immissione della password di SCM. Quando successivamente viene invocata la funzione di Finance, dato che l'utente è stato già conteggiato, non viene effettuato alcun controllo (in altri termini viene automaticamente autorizzato all'esecuzione) f) Il controllo utente non viene attivato né al logon né al richiamo di funzioni generalizzate (quali i Persistent Filter) ma solo all invocazione delle funzioni di gestione applicativa, che possono essere associate a moduli ben precisi. Pertanto un utente può sempre collegarsi, richiedere una lista, ma sarà soggetto a controllo nel momento in cui verrà lanciata una funzione di gestione (es. modifica o visualizzazione) di un record presente in lista. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 75 di 108

76 g) L invocazione di funzioni appartenenti ai seguenti moduli: F13 Service Bus (SVB) R01 Amministrazione (FIN) R07 Supply Chain (SCM) R19 Controlling (CTG) R67 Ritenuta di Acconto (RAC) concorre ad incrementare il contatore dei Moduli Vision4. I seguenti moduli: R37 InContact (INC) R31 CRM (CRM) R43 Cespiti (CSP) hanno contatori propri. L invocazione di funzioni non riconosciute come appartenenti ai moduli sopra menzionati concorre ad incrementare il contatore dei moduli di personalizzazione. h) Le funzioni di personalizzazione vengono controllate, per quanto riguarda il numero di utenti ammessi, andando a recuperare il numero di utenti specificati all atto dell immissione della password per il prodotto 5733-F19 Service Bus Utenti i) Il superamento del numero massimo di utenti collegati per un dato modulo ACG Vision4 comporta l emissione di un messaggio con l indicazione del nome del modulo applicativo per il quale si è raggiunta la soglia massima. Per le funzioni non appartenenti ad ACG Vision4 (personalizzazioni) il superamento della soglia di utenti collegati viene misurato sul numero massimo di utenti ammissibile per il Service Bus Utenti. j) Il controllo sulla numero di utenti tiene conto della data di scadenza della password (viene cioè verificato che il record che contiene i codice di autorizzazione dei moduli abbia la data di scadenza impostato ad un giorno successivo o uguale alla data del sistema) k) Il decremento del contatore avviene alla chiusura della sessione mediante click sul pulsante di log-out del desktop Vision4. Se sono aperti più browser sulla stessa macchina client, il decremento avviene solo al log-out sull ultimo desktop ancora attivo. l) Se il browser viene chiuso impropriamente (vale a dire cliccando sull icona X di chiusura dell Internet Explorer), il decremento del contatore viene attivato nel momento in cui il Session Listener di Websphere rileva che la sessione http associata al browser è scaduta. Ciò comporta un differimento del momento in cui i contatori vengono effettivamente aggiornati Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 76 di 108

77 m) All atto della ripartenza di un applicazione web è previsto il reset dei contatori per quell applicazione. Questo meccanismo di salvaguardia fa sì che, in caso di erroneo conteggio dei contatori, si possa comunque far ripartire l applicazione da uno situazione di contatori correttamente impostati. n) Il meccanismo di controllo degli accessi si basa sull utilizzo di dati che vengono salvati in forma crittografata in una tabella DB2 creata in ACGGAA. Lo svuotamento o l eventuale manipolazione dei dati bloccherebbe l uso delle funzioni applicative, in quanto è prevista la presenza di determinati record con i dati salvati secondo un formato predefinito. Con la primo versione e stata modificata la funzione di gestione dei codici di autorizzazione all uso dei prodotti ACG Vision4 per consentire l immissione/modifica dei codici di autorizzazione per più application server che puntano alla stesso database ACG. La modifica non ha comportato la modifica del tracciato della tabella ACGGAA.KPRA400F; la chiave virtuale del file è rappresentata dall area (KxxxUSEAUT) e dall installation id. L installation id può essere ricavato invocando il metodo getinstallationid(boolean gui) della classe com.ibm,acgv4.utils.utils. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 77 di 108

78 Visualizzazione lista client collegati E stata aggiunta la funzione che consente di visualizzare la lista dei client collegati all applicazione; i client sono identificati dall indirizzo IP. La funzione mostra per ciascun client il numero di sessioni aperte (ovvero di browser collegati a Vision4 che abbiano invocato una funzione Struts) ed i contatori delle licenze consumate. Vengono inoltre visualizzati i contatori globali delle licenze. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 78 di 108

79 Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 79 di 108

80 3. Punti di estensione 3.1 Gestione Exit ACG Vision4 prevede la possibilità di invocare automaticamente o su richiesta dell utente funzionalità o parti di codice personalizzati, al fine di realizzare estensioni delle funzionalità standard ed implementare comportamenti ad hoc. Il codice personalizzato che può essere invocato deve essere scritto secondo il programming model ACG Vision4, dovendo rispettare convenzioni e specifiche proprie dell architettura V4. Il meccanismo attraverso il quale è stata realizzata l invocazione a funzioni di personalizzazione è rappresentato dall attivazione delle cosiddette exit, vale a dire dall attivazione di punti di uscita del codice standard. Sono state individuate quattro tipologie di exit che possono essere attivate nell ambito di una funzionalità: 1. exit automatiche 2. exit non automatiche, richiamabili da finestra a seguito della pressione di un tasto funzionale 3. exit predefinite, inserite in punti ben precisi del codice standard ACG 4. exit di tipo server Nel seguito vengono dettagliate le quattro tipologie di exit 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 ACG Vision4. La Exit puo essere richiamata in modalità POST o in modalità PRE rispetto all esecuzione dell azione Struts ACG Vision4; nel primo caso sarà eseguita dopo l invocazione del metodo dell azione Struts, nel secondo caso prima. 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 operazioni-exit inclusa nel menu Operazioni ed autorizzazioni di ACG Service Bus; è necessario il ruolo di amministratore di sistema (SYSTEM_ADM) per accedere a tale funzione. La tabella SQL contentente le associazioni è ACGGGA.KOPEX00F. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 80 di 108

81 La funzione succitata consente di creare, modificare, cancellare un record che definisce il legame tra un operazione (o un 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, KOPEX00F.KOPID) associato al metodo dell azione Struts deve corrispondere alla concatenazione dei seguenti elementi: 1. action id dell azione Struts da invocare (la classe java..action di Struts) 2. carattere underscore (trattino basso) 3. metodo da invocare Nel caso in cui si voglia associare un operazione di exit ad un action, 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 tipo 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 specifico dell azione Struts. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 81 di 108

82 Ad esempio, se si vuol attivare una exit ogni volta che viene richiamato il metodo create() della gestione dell anagrafica agenti, basata sull azione Struts con action id Agent, occorre specificare il codice operazione Agent_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, KOPEX00F.KOPEX) da associare è a sua volta un operazione identificata da un codice di fantasia, definito dall autore della exit; nell esempio, il codice dell operazione associata alla exit è Agent_create_exit_0. 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 Strus 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 Strus alla quale è associata. > 0 per identificare le exit richiamabili da finestra (exit non automatiche). L operazione Agent_create_exit_0 deve essere codificata nell anagrafico delle operazioni KOPER00F; l url che contiene i nomi della classe di exit e del relativo metodo da invocare deve seguire 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 richiamare metodo_exit_da_richiamare = il nome del metodo di exit da richiamare extf = se presente, viene impostato con un codice alla tabella estesa EXTF (Personalizzazione funzioni) di ASTB300F. Tale codice permette di attivare o meno la exit in dipendenza di un determinato sistema informativo. Il campo funzione della exit consente di modificare il nome del metodo della exit in dipendenza del sistema informativo. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 82 di 108

83 Ad esempio, se la exit Agent_create_exit_0 deve richiamare il metodo aftercreate() della classe com.ibm.acgv4.exit.bp.agentexit, si deve impostare l URL dell operazione Agent_create_exit_0 come segue: class=com.ibm.acgv4.exit.bp.agentexit;method=aftercreate La classe di personalizzazione deve implementare un metodo la cui signature deve essere: methodname(acglogon logon, ActionForm form, HttpServletRequest request, String context) essendo previsto che riceva: l istanza di ACGLogon correntemente attiva il form dell Action Struts sulla quale si è attivata la exit la request http il parametro context dell Action Struts sulla quale si è attivata la exit Nell esempio il metodo della classe com.ibm.acgv4.exit.bp.agentexit è: oncreate(acglogon logon, ActionForm form, HttpServletRequest request, String context) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 83 di 108

84 Si fa presente che, se sull operazione della exit non viene impostato il campo Url, la exit non viene eseguita. ACG Vision4 precarica alcune associazioni operazioni-exit e le relative operazioni di exit, le quali hanno il campo Url non impostato. Il cliente/business Partner che intende attivare la exit dovrà semplicemente impostare il campo Url come specificato precedentemente. Nel caso sia stato associato un codice della tabella estesa Personalizzazione funzioni (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 abilitato. Ad esempio è possibile condizionare l esecuzione della exit Agent_create_exit_0 al codice AGENT della tabella EXTF; inoltre è possibile impostare il campo funzione per far sì che nell esecuzione della exit venga invocato il metodo specificato nel campo Funzione del record AGENT di EXTF in luogo del nome del metodo specificato nell url dell operazione di exit. A partire dalla ptf SVB140072D è stata prevista la possibilità di far eseguire più classi java all invocazione di una exit automatica. 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 Implementazione del pattern in Apache Commons Il progetto Apache Commons fornisce un implementazione del pattern basata sui Command (vedi Per implementare il pattern si utilizzano 5 interfacce: Context: rappresenta lo stato dell applicazione (Stateful object) ed è implementato come una collezione con chiave java.util.map Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 84 di 108

85 Command: rappresenta un unità di lavoro. Il Command espone un unico metodo pubblico: public boolean execute(context context). Il Command agisce sul Context ricevuto ma non mantiene lo stato (stateless). Si può costruire una catena (Chain) di Command; ciascun Command esegue un unità di lavoro e può far avanzare la catena (se il metodo execute restituisce false) oppure interromperla (se il metodo execute restituisce false) Chain: implementa l interfaccia Command; in questo modo il programma client può invocare in maniera trasparente la esecuzione di un Command che a runtime può risultare nell esecuzione di un singolo Command o di una Chain; una Chain può richiamare un altra Chain Filter: estensione che permette il rilascio controllato delle risorse allocate da un Command, tramite l aggiunta del metodo postprocess. All atto dell esecuzione di una chain e garantito il richiamo del metodo postprocess di tutti i command partecipanti Catalog: è una collezione di Command (e Chain) ad ognuno dei quali si assegna un nome. Il Client può quindi richiedere l esecuzione di un Command ( e/o Chain) tramite un nome logico, senza conoscere i nomi qualificati delle classi; questo permette di cambiare una catena (aggiungendo/rimuovendo Command) senza dover cambiare il codice Client che invoca l esecuzione della catena Utilizzo Command nel meccanismo delle exit Vision4 Per utilizzare il pattern Chain of Responsibility per richiamare più classi java occorre definire i seguenti oggetti logici ed implementativi: Chain: definire un nome logico che verrà utilizzato per invocarne l esecuzione Catalog: il path del file xml che conterrà la definizione della catena e che a runtime permetterà di risolvere l associazione nome logico-classe Command da eseguire; questo permette di aggiungere /rimouvere personalizzazioni senza dover cambiare la classe Client. Command: uno o più Command che implementino ciascuno una logica di exit, ricevendo in input l oggetto ExitContext Definire come URL dell operazione che implementa la exit (e che verrà associata ad un operazione Vision4) secondo il formato chainname=chain_name;chainurl=catalog_path Ad esempio se si vuole invocare la chain ClientiInitExit descritta nel file conf/corclientexitcatalog.xml occorre impostare l url come segue : chainname=clientiinitexit;chainurl=/conf/corclientiexitcatalog.xml Per maggiori dettagli si faccia riferimento al paragrafo Chiamata di più exit in cascata del documento ACG Vision4 Scenari di personalizzazione Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 85 di 108

86 3.1.2 Exit non automatiche Sono richiamabili da una finestra che viene emessa al clic sul tasto Exit inserito in una finestra Vision4 sulla quale ne sia stata predisposta la gestione. Nell esempio è stato inserito il tasto Exit che viene abilitato dal metodo aftercreate() della classe com.ibm.acgv4.exit.bp.agentexit. Alla pressione del tasto Exit viene emessa la seguente finestra: Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 86 di 108

87 Nella finestra Operazioni di exit eseguibili vengono visualizzate tutte le exit associate al metodo dell action Struts che ha emesso la finestra di gestione degli agenti, leggendo la tabella delle associazioni Operazioni-Exit. La finestra elenca tutti i record associati con numero exit maggiore di 0, visualizzando la descrizione e l url dell operazione di exit da eseguire. Qui di seguito viene mostrato l elenco delle exit associate all operazione Agent_update, relativa all esecuzione del metodo update() sull Action di gestione dell anagrafica Agenti. Le exit visualizzate hanno Nr Exit maggiore di zero e sono incrementali. Eseguendo un doppio clic sulla riga relativa alla Exit nella finestra Operazioni di exit eseguibili verrà eseguita la exit. 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 Vision4); la sintassi è js:comando_javascript (esempio: js:xcrtwin( ) oppure js:xrun( )). Se nel comando javascript è presente la parola chiave parentwin, questa viene sostituita a run-time con l identificativo della finestra. Nell esempio, al doppio clic sulla prima riga js:window.open('../pages/exit.jsp?parm1=parentwin&parm2=agentform') viene trasformato in js:window.open('../pages/exit.jsp?parm1=2_f1_win_salagent&parm2=agentform') essendo 2_F1_WIN_SALAgent l identificativo della finestra di gestione degli agenti dalla quale è stata emessa la finestra di lancio della Exit. Tramite l identificativo della finestra di partenza e nell esempio il parametro 2 è possibile recuperare il form bean dell action di partenza (si veda la pagina pages/exit.jsp) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 87 di 108

88 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 di gestione delle Exit (definito nel file strutsexit.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="/agentexitiaction.do?xmethod=create"/> </action> Come per quelle automatiche, l URL della exit non automatica può contenere il parametro extf tramite il quale è possibile che permette di attivare o meno la exit in dipendenza del sistema informativo. Pertanto, se ad esempio si vuole abilitare/disabilitare la exit Agent_create_create_1 su un sistema informativo in funzione dell elemento 0001 della tabella EXTF, si può impostare l url come segue: js:window.open('../pages/exit.jsp?parm1=parentwin&parm2=agentform');extf=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. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 88 di 108

89 3.1.3 Exit predefinite Sono punti di exit inseriti in punti prestabiliti del codice java Vision 4 standard per consentire l invocazione di codice utente. L unica cosa che e necessario fare e definire l operazione nel Koper00f. Il codice utente invocabile è rappresentato da un metodo dichiarato in una classe definita dal personalizzatore. Al momento sono state identificate due tipologie di signature: 1. nome_metodo(actionmapping mapping, ActionForm form, HttpServletRequest 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 l action form 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 Ad esempio nel metodo save() dell azione di gestione dell Anagrafica Agenti è stato inserito un punto di Exit che permette il richiamo di un metodo utente su una classe definita dall utente. 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 è inserita 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 automatiche relativamente al significato di tale parametro. Il nome dell operazione di Exit da invocare nel caso della gestione anagrafica agenti è Agent_internalSave_exit; è necessario perciò conoscere il nome delle operazioni di exit predefinite per poter innescare l aggancio. 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. Si riporta a titolo d esempio il codice di un metodo di exit invocato a fronte di una exit predefinita, che prevede l aggiornamento di un file di estensione dell anagrafica agenti (BPAGE00F) con l impostazione di due campi (Field1 e Field2) recuperati dal form bean dell action chiamante. public void onsavebeforecommit(actionmapping mapping, Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 89 di 108

90 ActionForm form, HttpServletRequest request, HttpServletResponse response, Session hibsession, Object parentbo) throws BaseException,Exception { log.info("entered method onsavebeforecommit"); DynaValidatorForm actionform = (DynaValidatorForm) form; //Implement validation code String field1 = actionform.getstring(field1).trim(); if(field1.equals("*all")) throw new BaseException(ERROR_MSG_RESOURCE_PATH, "BP0001", null); String codag = actionform.getstring("codag"); Bpage00f bo = null; String context = actionform.getstring(acgdispatchaction.xcontext).trim(); if (context.equals(utils.ctx_insert)) { bo = new Bpage00f(); bo.setcodag(codag); } else { bo = (new Bpage00fHome()).findById(codag); } } bo.setfield1(field1); bo.setfield2(actionform.getstring(field2).trim()); hibsession.saveorupdate(bo); Nell esempio viene anche mostrato come eseguire una semplice validazione a fronte della quale può derivare il lancio di una eccezione di tipo BaseException. Il metodo(2) ha un unico parametro da utilizzare sia per l input sia per l eventuale output. Si riporta qui di seguito un esempio di implementezione: HashMap hm = new HashMap(); hm.put( form, form); hm. put( request, request); hm. put( response, response); Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 90 di 108

91 hm. put( session, session); Hm. put(..,..) gli ulteriori parametri dipendono dalla exit / richieste degli utenti Nella classe Java ACG Vision4 è prevista che venga istanziata la classe com.ibm.acgv4.exit.exitoperation ed eseguito su di essa il metodo run(), passando come parametro la HashMap precedentemente definita. Ad esempio: HashMap hm = new HashMap(); hm. put( form, form); hm. put( request, request); hm. put( response, response); hm. put( session, session); ExitOperation eo = ExitOperation.getExitOperation( CLIENTI_Internal_Init ); if (eo!=null) { eo.run(hm);.. BigDecimal tot_fat = (BigDecimal) hm.get( RET_Totale_Fatturato ); BigDecimal tot_mat = (BigDecimal) hm.get( RET_Totale_Maturato );.. } Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 91 di 108

92 3.1.4 Exit lato server Le exit di questo tipo sono state deprecate a partire dall aggiornamento SVB140027D di ACG Service Bus V1R4M0, potendo utilizzare in sostituzione le exit predefinite che implementano il metodo void nome_metodo(map hashmap) throws Exception. Nella libreria acg_base.jar è presente la classe denominata com.ibm.acgv4.base.serverexit, tramite la quale è possibile effettuare il richiamo di codice java come exit di classi "server" (che implementano cioè la componente model). Tali exit consentono la personalizzazione della logica di business prevedendo la possibilità di richiamare il codice utente al quale vengono passati una serie di parametri e sulla base dei quali può restituire dei valori di ritorno che possono sovrascrivere quelli previsti dalla logica di business standard ACG. La classe da richiamare (vale a dire la classe di personalizzazione) con il relativo metodo deve essere dichiarata nel campo "Url" di un'operazione che deve essere usata come exit della classe model, secondo la convenzione: class=nome_classe;method=nome_metodo (ad es. class=com.ibm.acgv4.exit.exitcalcolofido;method=calcola). Se l'url dell'operazione di exit non è impostato oppure l'operazione ha status diverso da blank, non viene eseguito nulla (la exit viene bypassata). Esempio d'utilizzo Si supponga di voler lanciare la exit associata all'operazione FORNITORI_Exit, che prevede il richiamo del metodo run() della classe com.ibm.acgv4.exitfornitoriexit. Il metodo run() riceve i parametri tramite una HashMap e restituisce come ritorno una HashMap. E' necessario eseguire le seguenti operazioni: 1) codificare l'operazione FORNITORI_Exit con URL class=com.ibm.acgv4.exit.fornitoriexit;method=run 2) Nel codice servente scrivere HashMap params = new HashMap(); params.put("parm1", "Parametro 1"); params.put("parm2", "Parametro 2"); ServerExit se = new ServerExit(logon, null, null, "FORNITORI_Exit"); try { HashMap retexit = (HashMap) se.run(params); System.out.println(retExit); } catch (BaseException e) { e.printstacktrace(); } La classe richiamata deve implementare il metodo run() con segnature Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 92 di 108

93 public Object methodname(acglogon logon, Session session, Connection conn, Object param) throws BaseException { Ad esempio: package com.ibm.acgv4.exit; import java.sql.connection; import java.util.hashmap; import org.hibernate.session; import com.ibm.acgv4.base.acglogon; import com.ibm.acgv4.utils.utils; public class FornitoriExit { public HashMap run(acglogon logon, Session session, Connection conn, HashMap hm) throws BaseException { if (logon == null) throw Utils.createBaseException("BASE0018", null, null); Utils.printHashMap((HashMap) hm, "Input parameters"); hm.put("parm1", "Parametro 1 cambiato"); hm.put("parm3", "Parametro 3 aggiunto"); hm.remove("parm2"); } } return hm; La classe com.ibm.acgv4.exit.serverexit deve essere istanziata passando i seguenti parametri: ACGLogon: obbligatorio (deve essere not null) Session: sessione hibernate (opzionale) se la si vuol far condividere tra le classi chiamante e chiamata Connection: connessione jdbc (opzionale) se la si vuol far condividere tra le classi chiamante e chiamata OperationId: obbligatorio La classe ServerExit implementa il metodo run() che riceve un Object che rappresenta il parametro (può essere una stringa o un oggetto di tipo list, map o bean o altro oggetto java) e restituisce a sua volta un oggetto (ancora una volta stringa, map, list, bean, etc.). La classe richiamata può sollevare eccezioni di tipo com.ibm.acgv4.base.baseexception; altri tipi di eccezione andranno intercettati e rimappati come com.ibm.acgv4.base.baseexception. La classe ServerExit può sollevare le seguenti eccezioni: BASE0018 per logon null BASE0065 per id operazione null BASE0021 per operazione non trovata in KOPER00F BASE0019 per utente non autorizzato all'operazione BASE0068 per errore in invocazione della classe richiamata (classe di exit inesistente, metodo da richiamare con signature sbagliata, etc) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 93 di 108

94 qualsiasi BaseException sollevata dalla classe richiamata (dato che le eccezioni sollevate dalla classe custom vengono catturate e rilanciate) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 94 di 108

95 3.2 Lancio operazioni La funzione Lancio operazione nel menu Strumenti è in grado di eseguire una classe java, che estende la classe com.ibm.acgv4.exit.genericlaunch, associata ad un operazione caricata nella tabella delle operazioni (ACGGAA.KOPER00F). L operazione che si desidera lanciare deve essere codifica impostando l URL secondo il seguente pattern: class=nome_classe_da_invocare;method=metodo_da_incvocare;parms=10_flag_parametri_richiesti essendo: 1010_flag_parametri_richiesti una stringa formata da 10 lettere associate ad altrettanti parametri che possono essere visualizzati a video e passati alla classe da invocare. La prima lettera è associate al primo parametro, la seconda al secondo parametro e così via. I valori consentiti sono: M = parametro obbligatorio O = parametro opzionale N = parametro non richiesto Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 95 di 108

96 Nell esempio in figura, l operazione SVB_V1R3M0_SVB invocherà il metodo execute() della classe com.acgv4.exit.installtable; la classe richiede tre parametri, due dei quali sono obbligatori. Dopo aver lanciato la funzione Lancio Operazione, viene mostrata la seguente finestra nel desktop Vision4; l utente può digitare o scegliere ciccando sul pulsante di lista l operazione da lanciare e premere successivamente il pulsante che risulta abilitato.. Se l operazione scelta è valida (vale a dire, l operazione ha un url conforme allo schema descritto precedentemente), la finestra visualizza: - il codice operazione come campo protetto - i nomi della classe e del metodo da invocare in un campo protetto Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 96 di 108

97 - due campi di immissione obbligatoria - un campo di immissione facoltativa Dopo aver immesso i dati richiesti e premuto il pulsante abilitato, viene invocata la classe passando i parametri richiesti. Viene mostrato qui di seguito un esempio della classe invocata Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 97 di 108

98 In primo luogo la classe d esempio sovrascrive il metodo: HashMap init(acglogon logon) throws Exception che può essere usato per impostare valori ed etichette a video dei parametri di input. Nell esempio in figura sono impostati etichette e valori di default per i parametri 1 e 2 invocando i metodi setvalue() e setlabel(). Il metodo che deve essere invocato deve rispettare la seguente segnature: public String method_name(acglogon logon, HashMap hm) throws Exception Il parametro hm contiene le coppie nome-valore con i parametri di input; I valori di input possono essere recuperati invocando il metodo getvalue() al quale devono essere passati il numero del parametro e l hash-map di input. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 98 di 108

99 Il metodo invocato può sollevare un eccezione in caso d errore (ad esempio per effetto di una validazione fallita) ed una stringa che rappresenta un messaggio da visualizzare. Se la strina gi ritorno è impostata al valore null, viene visualizzato il messaggio standard Operazione terminata con successo.. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 99 di 108

100 3.3 Richiamo classi custom allo startup dell applicazione E stata prevista la possibilità di lanciare una o più classi custom allo startup dell applicazione, senza richiedere la modifica del file web.xml per inserire una servlet che parta automaticamente all avvio della web application ACG Vision. La lista delle classi da invocare deve essere indicata nel file custom.properties da creare nella cartella WEB-INF\classes\conf nel percorso d installazione della web application ACG Vision4. In particolare le classi da invocare devono essere specificate impostando la property STARTUP_SERVLET nel file di property, separandone i nomi con il carattere :. Ad esempio, volendo invocare le classi mypkg.startup1 e mypkg.startup2, si dovrà impostare la property custom.properties STARTUP_SERVLET= mypkg.startup1;mypkg.startup2 Le classi custom che vengono richiamate devono implementare il metodo public void init(servletconfig sc) { analogamente ad una Servlet, essendo sc un istanza di javax.servlet.servletconfig. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 100 di 108

101 3.4 Gestione dati tabellari utente A partire dalla ptf SVB140028D è stata prevista la possibilità di poter immettere e gestire i dati di tabelle di specializzazione (registrate nella tabella ASTA300F residente nello schema/libreria aziendale) o comuni (registrate nella tabella ANTA200F residente nello schema/libreria comune) non appartenenti ai moduli standard ACG. Vengono illustrati qui di seguito i passi necessari per: a) definire una tabella di tipo descrittivo appartenente ad un area applicativa definita dall utente b) creare un operazione che lanci la funzione di gestione della tabella c) agganciare l operazione ad un nodo del menu ad albero ACG d) lanciare ed eseguire le funzioni di gestione degli elementi tabellari La creazione della funzione di gestione dei dati tabellari non appartenenti alle tabelle standard ACG (nel seguito referenziate come tabelle non ACG) prevede: 1. la definizione di un area applicativa ad hoc, cui appartengono logicamente le tabelle non ACG. Occorre lanciare la funzione Tabelle standard del menu Common selezionare la voce Lista in corrispondenza dell elemento DAP (Area Applicativa) Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 101 di 108

102 ed, infine, inserire un codice area applicativa (nell esempio codice ABC), salvando l elemendo aggiunto dopo averlo selezionato con un check come in figura. 2. la creazione di un record della tabella TAB (Tabelle gestite) in ANTA200F che definisce la tabella non ACG con le sue caratteristiche di base (codice identificativo, lunghezza elemento, lunghezza descrizione, etc). Lanciare la funzione di creazione di una nuova definizione di tabella Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 102 di 108

103 ed immettere un nuovo codice tabella, specificando i parametri richiesti (nell esempio si è creato la tabella descrittiva D99 i cui elementi devono essere lunghi 3 e descrizione 35; come detto, l area applicativa di appartenenza sarà ABC). Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 103 di 108

104 3. la definizione di un operazione che richiami la funzione di visualizzazione della lista delle tabelle non ACG appartenenti all area applicativa definita al punto 1. Dopo aver lanciato la lista delle operazioni come in figura, creare un operazione specificando l url js:xcrtwin('f0', 'WIN_TabelleGENList', '[TAB,ABC,ABC,ABC,ABC,ABC]') L operazione può essere soggetta a restrizioni sui ruoli, per consentire la visualizzazione della funzione di gestione delle tabelle dell area applicativa ABC ai soli utenti autorizzati. Il campo Area applicativa dell operazione consente l inclusione dell operazione nel menu ad albero nei soli sistemi informativi nei quali risulta installato il modulo COM (vale a dire il modulo Archivi Comuni del Service Bus); è possibile specificare aree applicative differenti (FIN, SCM o custom) purché siano relative ad un modulo/prodotto installato su un sistema informativo ACG Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 104 di 108

105 4. l aggiunta dell operazione creata ad una voce del menu ad albero ACG tramite la funzione di amministrazione della struttura dei menu. Lanciare la funzione di amministrazione del menu ad albero ACG Esplodere il menu ad albero ed individuare il nodo all interno del quale aggiungere l operazione creata (se desiderato, si può creare un nuovo menu ed aggiungere l operazione creata). Nell esempio l operazione viene inclusa nel menu identificato dal codice 4GBCommon (Common) Dopo aver ciccato sulla voce Aggiungi operazione viene visualizzata una finestra di immissione dei dati; indicare il codice dell operazione creata al punto precedente e premere Salva. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 105 di 108

106 5. Gli utenti, per poter visualizzare la nuova voce di menu, devono eseguire la funzione di ricarica dell albero dei menu come in figura Nel menu verrà visualizzata la nuova operazione Visualizza tabella ABC. Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 106 di 108

107 6. Al click sulla voce del menu contestuale Lista, viene visualizzata la lista delle tabelle dell area applicativa ABC, che riporta i codici tabellari dell area applicativa indicata. Su ciascuna voce è attivo un menu contestuale che visualizzerà la lista degli elementi appartenenti alla tabella selezionata. Nel caso di tabelle descrittive viene richiamata una funzione generalizzata che permette di creare, annullare e riattivare gli elementi della tabella. Nel caso in cui la tabella da invocare fosse stata di tipo Applicativo, la voce di menu Lista avrebbe eseguito il seguente metodo javascript: xcrtwin( F1, WIN_TabellaXXXList ) mentre la voce Nuovo avrebbe eseguito il seguente metodo: js:xcrtwin( F0, WIN_TabellaXXX, [XXX], xmethod=create&onerror=close )"/ essendo XXX il codice della tabella Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 107 di 108