Capitolo 3
Sviluppo ed implementazione
3.1 Tool Visualizer, visione generale
Tutte le informazioni ottenute per il Visualizer vengono prelevate dai database a disposizione G&E e da diversi sistemi informatici già presenti in business management. Si fa riferimento a sistemi come Artemis che contiene la catalogazione degli fse e delle assegnazioni ; mentre il sistema di FSCC contiene le informazioni per skills aggiornate, competenze ed aggiornamento dei cantieri per nuove aperture e chiusure.
L'inserimento dei dati nei sistemi informativi in sede G&E avviene in tempo reale, quindi lo scopo del Visualizer è mantenere tale aggiornamento dei propri dati, il più vicino possibile alle modifiche in Database Oracle.
Per far si che sia possibile mantenere tali informazioni pronte all'uso in fase di caricamento dell' FSEVisualizer, è necessario effettuare un MashUp dei dati da inserire in nuove tabelle DB dedicate.
Una funzione di JOB all'avvio dell'Applicativo si occuperà del popolamento delle seguenti tabelle create ad hoc :
• Assignment • Region • Pofile FSCC • Programs
delle informazioni richieste in mappa da FseVisualizer.
Grazie alla schedulazione della funzione di JOB, si ha l'aggiornamento dei dati ogni 4 ore.
Il mash-up in campo ICT, rappresenta una combinazione di dati provenienti da sitemi diversi, rappresentati come in un singolo sistema integrato.
Tali dati vengono rielaborati insieme , ed associati per : ➢ Region
Country
Assignment
• FSE
L'utilizzo dell'applicativo è permesso solo agli addetti G&E ,e solo tramite rete Intranet G&E, controllando l'accesso utente con credenziali assegnate ad ogni lavoratore del gruppo Americano in SSO e Password.
Il login quindi è indirizzato , tramite una regola Proxy , al sistema di riconoscimento utenti di G&E già in uso anche per altri Sistemi Informativi da loro utilizzati, denominato SiteMinder.
L'accesso è consentito anche tramite dispositivi mobili al di fuori della rete Intranet – VPN G&E. Questo per far sì che anche i Manager in cantiere possano controllarne i dati e le dislocazioni.
L' applicativo in esecuzione sul dispositivo mobile avvierà una richiesta di tipo Rest attraverso l'uso del web services e riceverà una risposta in formato xml/json tramite protocollo Http/Https.
Il Site Minder è una web application che si differenzia dalla classica autenticazione utente. La parte client non è un browser quindi non reindirizza la richiesta a nessuna pagina di Login, ma elabora direttamente l'informazione dalla sua screen view.
Si preleva l'SSO dall' Header della Request e se ne controlla l'autorizzazione tramite il Sistema IDSS, il quale definisce i ruoli e gli utenti ad essi associati in un DB interno, invocando chiamate in WS-Security come mostra la figura seguente. Gli Url di riferimento, nei vari ambienti di sviluppo, per effetture un test di controllo SSO saranno del tipo:
✔ DEV: https://webtest02.np.ge.com/service/idsswebservice
✔ QA: https://webstage12.np.ge.com/service/idsswebservice
✔ Username: test
✔ Password: test
Solo dopo aver superato tale controllo sarà possibile ottenere l'accesso di visualizzazione del Visualizer.
46
3.2 Implementazione del Codice - FSEWS
FseVisualizer si compone di 3 parti, ogni parte è un web service a se, l'unione delle parti rende la visualizzazione dei dati in scremata omogenea, reale, e aggiornata periodicamente.
➢ FSCC ➢ FSEWS ➢ FSEDEV
L'ambiente di sviluppo usato per la produzione dei 3 moduli è Eclipse Juno, che permette la visualizzazione in layout JAVA del codice, con la possibilità di sviluppare usando JAVA2EE per i due moduli di FSEWS ed FSEDEV.
Il primo modulo è FseWS application, un web services resources oriented , il quale permette il prelevamento delle grandi basi dati contenute in Artemis, FSCC, HR.
Tali dati vengono richiamati con servizi Rest, con protocollo internet HTTP, in cui se ne specifica l'indirizzo fisico della risorsa richiesta.
Il dato prelevato viene elaborato per filtraggi e per direttive di scrematura dello stesso.
Dalla base dati ottenuta faranno riferimento tutte le successive chiamate a run-time, per le singole richieste di dettagli di visualizzazione, accessi ed assegnazione di ris
orse.
Questa sezione rappresenta il back-end dell'applicativo, dove se ne manipolano i dati, se ne elaborano i servizi esposti, e se ne controllano le chiamate da effettuare agli altri sistemi informativi di appoggio.
Contiene i modelli di visualizzazione degli oggetti, i file di scripting per la creazione e controllo della Mappa Geografica e dell’albero a 3 livelli.
È caratterizzato da un Collettore di Servizi esposti.
La chiamata al DataBase sarà dunque caratterizzata dall’invio di una richiesta di connessione per singolo URL indicato. Tale URL conterrà un Host/context/{dichiarazione del servizio di riferimento esposto dal collettore}. Il lavoro di Popolamento delle Tabelle in memoria viene effettuato da un servizio di sheduling , descritto nella classe JOB, temporizzato a 4ore, che effettuando 4 chiamate asincrone a DB, mantiene l’inserimento in tabelle di memoria. In ogni caso i dati caricati dalle singole richieste di servizio, sono ugualmente mantenute in una struttura di caching utilizzando il modulo applicativo java , JCSCacheManager .
Cache che viene aggiornata ogni 6 ore e che contiene le singole rappresentazioni dei modelli degli oggetti riferiti.
Gli oggetti di riferimento elaborati in java per la mappatura degli attributi sono i seguenti: ProgramsCollection, Program, AssignmentsCollection, Assignment, Country, FseCollections, AssignmentsHistory,
Custmers.
Il collettore si appoggia ad una classe FseService.java che definisce tutti metodi per la restituzione delle informazioni richieste nei servizi
collettore associati.
A sua volta la Service richiamerà le classi java per la gestione del dato proveniente dal DataBase.
Le classi in questione sono le DAO e DAOImplementation, interfaccia e relativa implementazione per il modello del dato richiesto.
Le proprietà dei modelli sono descritte nei file di tipo xml dei package rispettivi delle DAO interfacce. Ed è lì che risiede anche l’estrazione da DB, tramite query. La gestione dei filtraggi in query sono gestiti “applicativamente”, senza pesare sul DB. Tale scelta implementativa è stata prevista per mantenere la query su DB con estrazione generale. Questo poiché il DB è condiviso con altri applicativi G&E che ve ne fanno accesso.
È presente anche un Global Search sui dati, appoggiato alle chiamate effettuate su DB.
Il modulo crea delle tabelle in Memory di supporto mappate in Java e legate ad un 'area DB Oracle concessa da G&.
La funzione che si occupa della gestione di caricamento e svuotamento delle Memory table è il JOB.
Una classe java che ne avvia lo scheduling e la connessione al DB Artemis, la creazione delle tabelle in Memory e ne controlla il corretto caricamento in mappa.
Al Primo avvio dell'applicazione si popola l'albero a destra dei Country e Site, le installazioni dei cantieri in mappa, ed i contatori globali per site, fse e country in alto a destra.
Le chiamate per la raccolta e la scrematura dei dati non avviene solo da
Ogni chiamata ad entrambi i sistemi avviene singolarmente per singolo SSO, ed indipendentemente l'uno dall'altro.
Se una chiamata non va a buon fine, per il popolamento delle tabelle da FSCC, non se ne compromette il caricamento delle altre. Questo per far sì che l'applicativo abbia sempre dei dati a disposizione; la tabella in questione non verrà aggiornata e non verrà svuotata, mentre le altre proseguiranno con l'aggiornamento.
Il JOB non si limita al prelevamento dei dati dai due sistemi puri, ma questi vengono associati e rielaborati in base al supporto richiesto dalle funzionalità FSEVisualizer.
Quindi ritroviamo le tabelle di :
● RegionRegionRegionRegion per la classificazione delle mega aree geografiche G&E;
● InventoryInventoryInventoryInventory per il filtraggio degli assegnamenti di risorse per un periodo temporale prestabilito di 16 settimane; di cui 12 in avanti dalla corrente e 4 indietro;
● Assignemnts Assignemnts Assignemnts Assignemnts per il filtraggio delle risorse umane attive alla data odierna in cantiere e non;
● ProgramsProgramsProgramsPrograms per l'identificazione dei programmi di attivazione cantiere nelle singole country del wild world;
● CustomersCustomersCustomersCustomers per i clienti associati ai cantieri attivi; ● CountryCountryCountryCountry per idividuare i singoli Paesi di riferimento;
● skill & technologyskill & technologyskill & technologyskill & technology per le informazioni di dettaglio dei singoli Fse; ● SalesSalesSalesSales per le assegnazioni di risorse in inventory;
● User User User User per la gestione degli SSO di amministrazione ed i ruoli di accesso per le aree di VisualizerMap- Inventory- Sales.
3.2.1 Implementazione del Collettore dei servizi
Rest
La classe java di maggior importanza per questa sezione di codice è sicuramente il RestCollector.
Da quì si evidenziano tutte le chiamate HTTP (HyperText Transfer Protocol) da effettuare con l'inserimento dei parametri da inviare per singolo servizio, richiamando a sua volta la classe java dei Services.
La Classe si compone, dunque, di una parte iniziale per l'Import delle librerie necessarie all'esecuzione dei metodi.
Nell'esempio di seguito riportato, possiamo sottolineare le librerie
org.apache.poi per la creazione dei file excel nei servizi di creazione dei report
per la sezione Inventory, e per la relazione settimanale delle assegnazioni effettuate.
Sono riportati tutti i package di source project di riferimento:
Vengono impostate anche delle costanti per la visualizzazione di file di Log, utili in fase di testing e debug, e le costanti della Java Cache Manager che verranno popolate al momento dell'avvio del JOB
.
Il primo esempio di metodo Rest per effettuare la richiesta di recupero dati degli FSE è il seguente getAllFse(“...”);
Come mostrato di seguito , nella dichiarazione del metodo sono inseriti i parametri per effettuare la query di estrazione del dato e se ne definisce il percorso della richiesta, e la tipologia di dati da restituire:
Si inseriscono Query parameters quali:
● dateStart, e dateEnd per delineare il range temporale di riferimento dell'FSE attivo in cantiere.
● Start e Limit per delimitare la quantità di dati, in formato Json, che ne verrebbero visualizzati in schermata video dalla semplice risposta Rest
Il metodo richiama a sua volta la getAllFse() dalla classe fseServices, la quale definisce il vero e proprio recupero dei dati tramite mash-up.
Il metodo è inserito dentro l'elaborazione della java cache, in cui il jcsManager
viene precedentemente istanziato.
Volendo visualizzare i dati di questo servizio , si può testare la chiamata in un Client Rest , come per esempio Chrome Rest Client.
Inserendo l'URL del metodo se ne ottiene la visualizzazione dei dati a video, come se fossero una raccolta di informazioni “ linkabili”.
Il metodo per la chiamata al servizio Programs, direttamente accedendo dalla tabella pre-popolata in Memory.
Anche il metodo per la ricerca degli History ,effettua richieste ad FSCC web service. Gli history rappresentano le attività svolte nell'arco dell'intera carriera dei singoli fse, i countries ed i customers ad essi associati, aggiornati alla data corrente.
56 Immagine 3.7 . Informazioni JSON sui Programs restituita da Rest Client Browser
Di seguito il metodo per la gestione dei ruoli da inviare ad IDSS per l'autenticazione degli SSO.
La classe dell'implementazione dei Servizi, con i richiami dei metodi in DAO Interface per il recupero effettivo del dato in DB.
Vengono istanziate le variabili per l'associazione in corretta mappatura tra gli oggetti bean java e le property associate alle entità data base.
In tal modo gli entity bean definiti come Costanti DAO possono essere richiamati per l'accesso alle informazioni , come nel seguente metodo di
getProgram():
E di getFse():
Il metodo ritorna una collezione di Fse, definendone il settaggio delle date di estrapolazione da DB, in start-Date ed end-Date; ed i links di navigazione tra la medesima collezione.
Il Metodo di retrieveProgram() è necessario per il settaggio effettivo degli attributi della classe che li rappresenta, come mostrato nella sezione di codice seguente:
In seguito alla chiamata di tipo HttpURLConnection è possibile inserire in un buffer di lettura, un oggetto di tipo JSON che ne racchiude l'identificazione delle proprietà:
3.2.2 Implementazione del servizio Rest
Si descrive, in questo paragrafo, il flusso di lavoro per l'implementazione di un servizio Rest partendo dall'esposizione del servizio nel Collettore fino all'accesso in data base.
Si seleziona il package:
com.oilandgas.fse.db.statements – assignment.xml
In questo file vanno dichiarati i parametri restituiti dal servizio preso in modifica/aggiunta.
Si aggiungono i parametri alla resulMap e si crea la select/query associata,
specificando : id(numero in ordine crescente), parameterType, resultMap(assegnato).
La definizione della query di selezione avviene mappando le property nel modo seguente:
Ovviamente il numero dei parametri deve corrispondere al numero di parametri che saranno esposti nella classe collettore.
Per ogni oggetto java ci sarà un file xml di riferimento, quindi uno per gli Assignment, uno per i Program, uno per i Site, Fse e così via.
Si procede selezionando adesso il package dei modelli riferiti alle tabelle in DB Artemis. L'oggetto di riferimento deve essere ovviamente creato anche nella sezione java class; con tutti suoi attributi dichiarati, e con i metodi di Getting e Setting impostati.
Definito l'oggetto in model, e le property per la query in package
db->statment, si può proseguire con la creazione delle interfacce DAO associate.
Nel package com.oilandgas.fse.db.dao , si crea o si aggiunge se già esistente, il metodo nell'interfaccia di riferimento.
E si crea lo sviluppo di tale metodo in AssignmentDAOImpl:
all’assignment_id indicato nel file assignment.xml visto inizialmente.
Adesso se ne richiama il metodo select(“...”) visto in DAO Implementato, nella classe di creazione dei servizi.
In package com.oilandgas.fse.services.impl - > FseServices.java
va sviluppato il metodo di visualizzazione del risultato ottenuto dal lancio del servizio richiesto. Se il metodo esiste già va modificato aggiungendo i nuovi
In fine si crea in package :
com.oilandgas.fse.services.collectors -> RestCollector.java
il metodo associato al servizio appena ultimato. Se ne definisce il Path per il collegamento all'identificazione del servizio esposto tramite URL.
3. 2.3 Servizio di JOB per il popolamento delle Tabelle
in Memoria .
Come possiamo vedere dalla panoramica generale dei package in FSEWS web service, oltre alla DAO per l'accesso in DB G&E, vi è un package per l'accesso alle tabelle di supporto create, definito come : hsql -> dao e statements.
L'implementazione dell'oggetto Assignment in sql DAO, sarà del seguente tipo:
anche in questo caso gli attributi dell'oggetto devono rispecchiare gli le colonne presenti in tabella.
La classe che ha il compito di creare le tabelle in memoria è la FSEPreparation, che come si può notare crea la connessione al DB di riferimento e ne crea gli statements per la realizzazione della tabella vera e propria.
In questo caso si crea la tabella Country con le sue relative colonne.
A questo punto non resta che visionare la classe JOB, la quale a sua volta crea il connettore DB alle tabelle in memoria:
Si preleva il bean dal DAOContest associato alla tabella dei Country,
successivamente si inserisce in un array tutti i dai ottenuti dal metodo di tipo retrieveCountry presente nel Collettore, per poi inserirli nella tabella appena creata.
Il job inizia con il caricamento dei Country per poi proseguire con Customers, Programs, Assignemnts e così via.
3.2.4 Settaggio dei file di property
Per far si che si mantenga la persistenza dei dati in accesso in tabelle in memoria, si fa uso del framework open source Mybatis.
Tramite la configurazione del file mybatis-config.xml è possibile: ● creare la connessione tramite driver JDBC adatto;
● identificare un pool di connessioni per garantire l'accesso concorrenziale al DB senza saturarne la connessione.
● identificare il mapping per elaborare i file xml di programs, country, customer, assignments , discussi nel precedente paragrafo. File xml che conterranno la definizione delle tabelle e le query da effetture.
Quindi si stabilisce un pool massimo di connessioni al DB paria 100, di cui un massimo di 28 connessioni attive, ovvero connessioni in modifica dei dati in tabella.
Nei mappers sono presenti i path di cammino dei package contenenti i file con le SQL Query.
Importanti sono anche i file di configurazione delle Librerie Spring e Jersey nel file web.xml
La libreria Jersey mette a disposizione le funzioni di controllo per il Container, e quindi per lo smistamento delle richieste di esecuzione dei servizi:
in Jersey sé possibile settare anche l' url pattern da associare a tutte le chiamate tramite URL dei singoli servizi presenti nel Collettore Rest.
Le librerie Spring oltre al Context Loader Listner, per il caricamento dei servizi esposti, effettua anche il controllo del dispatcher delle Servelt:
3.3 Modulo FSCC
Il terzo modulo, FSCCWS application, è un web server che preleva dati direttamente dallo schema DB FSCC di G&E.
I dati di questo modulo, sono di dettaglio per le innumerevoli informazioni dei singoli Fse risorse:
● immagini di profilo,
● histoy, ● skills,
● competenze , ● etc..
Da questo web server vengono effettuate le chiamate dal primo modulo FseWs in back-end, ottenendo così un'ulteriore catalogazione e scrematura delle informazioni utili.
3. 4 FSE DEV – FrontEnd
Il modulo dedicato alla visualizzazione dei contenuti, all'interazione con il web service che ne viene richiamato, ed all'aggiornamento in tempo reale delle mappe geo-localizzate dei cantieri , è FSE-Dev.
dettaglio, la colorazione dei reports, la creazioni di grafici da esportare, la creazione dell'albero dei country.
La cartella che contiene la gestione dei file javascript per la visualizzazione dei dati , è composta come segue:
Il file maps.js è la struttura portante della sezione Visualizer, poiché ne costruisce l'albero dei Country -> Site -> Fse, e ne distribuisce i Programs in Mappa Tramite le Google API.
Dopo aver settato delle variabili in javascript, si creano delle chiamate ajax per effettuare la richiesta di servizio tramite gli URL dei servizi offerti dal backend, come possiamo ben vedere dalla precedente figura l'URL richiama l'
applicationProgram service, e invia come parametro solo il countryName. La funzione di tipo Ajax non è altro che una chiamata url al servizio desiderato , che ne permette l'inserimento dei dati in variabile di tipo array programApp. A sua volta tale variabile sarà utilizzata dalla funzione javascript putSiteOnMap, che ne visualizza in Mappa geografica grazie alle coordinate di latitudine e longitudine, identificate da attributi che caratterizzano ogni site.
Nell'albero a destra della schermata principale, si espongono i Site, Programs ed Fse associati.
Per ogni informazione di ogni nodo dell'albero, si effettua una chiamata url al servizio dedicato. Come mostrato successivamente per ogni nodo un elenco di informazioni suddivise per country, program, fse attivi.
74
URL corrisponderà al path identificato in back-end nella classe Collettore, e si assegneranno i dati in front-end associandoli a variabili identificative definite nel file html di visualizzazione corrispondente.
Tale file è index.html per l'intero front-end, in cui sono presenti tutti i tag html di presentazione delle informazioni in :
➢ Mappa, ➢ Albero, ➢ Inventory,
Nello stesso file è presente anche uno script di resize, ovvero di organizzazione delle misure espositive dei dati in fronte-end in base al tipo di browser in esecuzione, o in base al tipo di dispositivo mobile in cui è in azione l'applicativo.
Questo è possibile grazie all'inserimento di variabili UserAgent, che sono predefinite in javascript ed identificate dai relativi nomi associativi come mostrato nel ritaglio di codice seguente.
La visualizzazione delle informazione viene corretta per i layout di sistemi operativi di tipo Andorid, Iphone, e per il browser di Internet Explorer 8.
Si effettua il resize anche per l'albero dei Site:
La funzione che permetta l'esposizione dei dettagli per Fse in finestra modale è caratterizzata dall'avvio della openWindowBt Tree alla quale viene passato Id
3.4.1 Settaggio dei file di configurazione per front-end
Nel modulo FSEDEV essendo definito come progetto Java Web, si presentano anche i file di configurazione xml quali:
➢ web.xml ➢ mybatis-config.xml ➢ application-context.xml ➢ quartz.xml e files di properties: ➢ quartz.properties ➢ keys.properties.
Il web file è uguale al web file del modulo FSEWS di back-end, si richiamano le medesime librerie Spring e Jersey per la funzione di Controller dell'intera applicazione.
L' application context richiamerà la classe di avvio dei Bean per il prelievo dei dati da back-end:
Il file dal package com.ge.oilandgas.fse.beans.PropertiesBean , avvia i bean riferendosi al file di keys.properties contente i path settati per il contesto url dei servizi di accesso alle tabelle in memoria:
Le keys dei path url delle chiamate sono impostate su localhost per il debug e
testing dell'applicativo, ma vengono modificate in ambiente di sviluppo Quality e Produzione, inviando le corrette Guide di Configurazione (Configuration Guide) dei parametri alle sezioni IT di dovere.
La parte front-end accede ai dati solo contenuti nelle Memory table create e popolate dal back-end in FSEWS, quindi anche questo modulo viene visto come un' Applicazione Web Services a se con tutte le definizioni delle classi oggetto, DAO, Service previste per il corretto funzionamento.
Si ha , dunque, un file di FSE Preparation per la creazione dei DAO associati alle tabelle in memoria:
Questo meccanismo viene ben gestito dalla configurazione del file di myBatis, che è il framework che ne permette l'accesso in DB e la gestione delle esecuzioni delle query.
Le query sono esplicitate nei file xml dei path indicati nel resourse mapping di myBatis.
Il file di JOB del front-end avvia il caricamento delle suddette tabelle:
I servizi che si avviano dal collettore di fronte-end sono tutti quelli di popolamento , e di creazione dei reports da front-end, come il report per l'Inventory ed il report per gli assegnamenti globali per singolo site selezionato dall'albero.
Tra questi , anche il servizio di autenticazione fse tramite il Site Minder di iidss G&E.
e ruolo. Il servizio viene poi ultimato dalla struttura IIDSS:
L'avvio dell'aggiornamento delle tabelle di supporto avviene grazie alla schedulazione del job front-end, definita dal framework di sheduling Quatrz, settato in quartz.xml:
Ed in file di properties di quartz:
3.5 Sezione Inventory
Il modulo di Inventory si aggiunge ad FSEVisualizer per dare la possibilità agli addetti di management delle risorse, di poter verificare le assegnazioni di settimana corrente e delle successive 12 settimane in avanti , in Program e Site. Si inserisce un tab in barra orizzontale del modulo front-end, e si presenta ugualmente con una mappa globale terrestre ed un albero di selezione a destra. Gli elementi dell'albero , adesso, si differenziano dal raggruppamento per Site analizzato nei paragrafi precedenti.
La gerarchia dei nodi è dettata dalla Gerarchia degli elementi in albero: ● Global Region
REGION
Country
Fse Team
Recuperando Region e countryName dal modulo FSCC per associarli. L'albero sarà composto dalle macro aeree di:
➢ Asia ➢ America ➢ Europe ➢ Global ➢ Site Manager ➢ Resident ➢ Etc..
L'assegnazione in Inventory è caratterizzata dagli stati occupazionali in cui una risorsa può trovarsi, identificata da colori standard definiti e già in uso nella pianificazione :
● Inventory , non assegnato quindi libero – in giallo; ● Mob/DeMob , in mobilità - in blue;
● Training , in addestramento – in viola;
● Rest, in fase di riposo tra una mobilità ed assegnazione – in grigio; ● Wait, in attesa di assegnazione – in verde;
● Leave, in fase di conclusione dell'assegnazione – in azzurro ;
Si crea la visualizzazione di una tabella con tutte le risorse presenti non solo nei cantieri ma anche nelle varie sedi mondiali di G&E, filtrate per le date della settimana corrente.
Il servizio Rest che si occupa di tale elaborazione dei dati, prende in ingresso due date di input, la startDate e la endDate della settimana corrente, che vanno dal lunedì alla domenica , ed un campo che identifica la Region aerea di riferimento. In tal modo ne seleziona tutto il personale associato in site e programs attivi e non solo.
La tabella presenta 12 settimane fiscali in avanti rispetto alla corrente e 4 settimane in dietro. Questo tipo di selezione permette una maggiore pianificazione ed allocamento del personale.
86
Da questa tabella è anche possibile esportarne i dati su reports di file tipo excel. L'algoritmo , inoltre, considera per ogni risorsa le proprie date di assegnazione, confrontandole tra i 10 giorni indietro ed i 10 giorni in avanti previsti per la singola pianificazione di assegnazione.
In corrispondenza dei giorni a -10 e a +10 dall'assegnazione di lavoro (job) , deve essere in Mobilità. E ad ogni 30 giorni dalla mobilità deve essere in fase di Rest.
Le date di assegnazione possono essere anche revisionate e modificate rispetto ad una pianificazione di 4 settimane in dietro.
Ogni stato di attività ha un peso associato sia per indicarne una priorità di assegnazione sia per determinare una priorità maggiore in caso di date revisionate.
Nella classe di gestione dei Servizi esposti su FSEVisualizer, si aggiunge un controllo per la creazione delle settimane fiscali da elaborare per l'esecuzione del servizio di Inventory.
Si crea un HashMap per il prelievo dei dati dalle tabelle in Memory, delle singole fiscalweek identificate a partire dalla data corrente.
Si definiscono gli stati possibili di assegnazione in tabella:
La visualizzazione finale è mostrata in figura sottostante, la tabella visualizza 5 settimane per volta, quindi è possibile visualizzare le successive pagine della finestra modale tramite la barra apposita di scorrimento.
90
L'estrazione dei dati ottenuti dalla tabella, avviene in formato excel, con la numerazione delle settimane fiscali corrispondenti nell'anno in corso e il raggruppamento per singole Region. I dati estraibili sono sulla misura del migliaio per singola macro area.
