Capitolo 4 Java CAPS ed eBAM Studio
Questo capitolo tratta della fase 2 del macropiano delle attività relativa all’analisi della piattaforma JCAPS in uso presso Lottomatica e del tool eBAM Studio integrato nella piattaforma stessa (Error! Reference source not found.).
In particolare esso tratta:
dell’architettura dei componenti e delle funzionalità della piattaforma “Sun SeeBeyond eGate Integrator”;
del componente “eInsight Business Process Manager” e delle modalità in cui esso interagisce con gli altri componenti di Java CAPS;
delle caratteristiche delle applicazioni di Business Activity Monitoring (BAM) e del tool “eBAM Studio” integrato in JCAPS che fornisce funzionalità di tipo BAM attraverso collezione, aggregazione e presentazione dei dati delle attività di business in accordo con i Key Performance Indicators (KPI) di interesse.
4.1.
Introduzione
Nell’attuale ambiente economico, così altamente competitivo, si rende necessaria l’ottimizzazione delle operazioni di business attraverso un miglior utilizzo dei sistemi già in uso, connettendoli con partner, fornitori e clienti. Allo stesso tempo le aziende devono gestire in maniera efficace ed efficiente un enorme volume di transazioni.
Sun Java Composite Application Platform Suite (JCAPS) è una suite proposta da Sun Microsystem® che viene incontro a tutte queste esigenze, permettendo alle organizzazioni di assemblare applicazioni complesse costruite su sistemi ed infrastrutture eterogenee. La piattaforma consente la connettività tra persone, sistemi e device sia della stessa organizzazione che tra organizzazioni diverse, attraverso Business Service su Architettura
Orientata ai Servizi (SOA).
In particolare, attraverso l’utilizzo di Java CAPS un’organizzazione può:
connettersi con partner, fornitori e clienti in maniera rapida e sicura per permettere lo scambio di informazioni di business;
stabilire velocemente relazioni tra i partner e gestirle in maniera dinamica;
integrare dati di business, sistemi e altre applicazioni indipendenti in una piattaforma comune per lo scambio di informazioni in tempo reale tra i partner;
ottimizzare i processi di business, sia interni che esterni, al fine di creare un’organizzazione agile che sia abile nel reagire velocemente al cambiare delle condizioni di business.
Java CAPS rappresenta dunque una completa e unificata infrastruttura di eBusiness, disponibile per le aziende che intendono migliorare le proprie operazioni di business ed ottenere un rapido ritorno sugli investimenti. JCAPS fornisce integrazione fra diverse applicazioni, connettività business-to-business dinamica ed un robusto insieme di funzionalità per la gestione delle operazioni tra clienti, fornitori e partner.
4.2.
Architettura del Sistema
Come mostrato in Figura 1, Sun JCAPS è realizzato attraverso un’architettura stratificata composta dai seguenti livelli:
eGate Integrator – assicura le funzionalità fondamentali per la messa in esecuzione delle applicazioni sviluppate e per lo scambio e il trasporto affidabile di messaggi tra esse;
Service Integration – consente l’integrazione tra applicazioni eterogenee su piattaforme hardware differenti e l’interfacciamento verso sistemi di terze parti quali SAP e DBMS;
Service Orchestration – abilita la service orchestration per lo sviluppo di applicazioni composite;
composite;
Service Access – permette di definire politiche di controllo e gestione degli accessi per le applicazioni sviluppate.
Figura 1- Componenti di Sun JCAPS
Nel prosieguo di questo capitolo saranno approfonditi alcuni dei componenti più importanti dell’architettura mostrata in Figura 1, tra cui:
Enterprise Designer – fornisce un ambiente di sviluppo integrato per l’integrazione di sistemi e lo sviluppo di Composite Application che utilizzano Web Service;
Enterprise Manager – fornisce un framework web-based per la gestione di tutti gli aspetti relativi all’ambiente di run-time;
eWay Adapters – consente l’interfacciamento tra JCAPS e altri sistemi esterni, quali ad esempio SAP e DBMS;
eInsigth Business Process Manager – consente il disegno, gestione e deployment delle applicazioni composite sviluppate;
eBAM Studio – consente la costruzione integrata in JCAPS di dashboard e altri strumenti per il monitoraggio di opportuni KPI.
4.2.1
eGate Integrator
L’intera suite JCAPS poggia sul componente Sun SeeBeyond eGate Integrator: una piattaforma di Enterprise Application Integration (EAI), che risolve velocemente i complessi problemi di connettività e che permette la trasmissione dinamica di informazioni tra le diverse applicazioni e sistemi di partner e clienti con ottime performance e flessibilità.
eGate Integrator è una piattaforma di integrazione, certificata J2EE e basata sulla tecnologia dei Web Service. Esso fornisce le funzionalità per la connettività e l’integrazione di sistemi eterogenei, insieme al delivery sicuro dei messaggi scambiati tra le applicazioni e funzionalità di elaborazione integrata di dati e informazioni. Inoltre esso fornisce un ambiente integrato per lo sviluppo, il deployment, il monitoring e il management delle applicazioni. Come mostrato in Figura 2, il cuore dell’eGate Integrator è il Repository, ovvero un contenitore di informazioni comune all’intera suite JCAPS. Un separato registro UDDI consente invece la pubblicazione e il discovery dei Web Service.
Il sistema permette inoltre di effettuare il deploy di applicazioni su un ambiente di esecuzione Sun e su Application Server di terze parti (ad esempio JBOSS) all’interno di una rete distribuita e eterogenea di piattaforme hardware.
eGate Integrator può quindi comunicare e connettersi attraverso eWay Adapters con diverse applicazioni e database che girano su diversi sistemi operativi ed è in grado di operare su diverse tipologie di hardware e protocolli di comunicazione sia in modalità real-time che batch.
4.2.1.1
Componenti dello strato di eGate Integrator
eGate Integrator impiega un’architettura versatile che si adatta perfettamente ad ambienti di elaborazione distribuiti. Infatti i diversi componenti dell’eGate Integrator possono risiedere nella stessa piattaforma hardware (assumendo che siano disponibili adeguate risorse), oppure essere distribuiti lungo diverse piattaforme hardware all’interno della rete aziendale.
La Figura 3 mostra un esempio di implementazione di un sistema distribuito che comprende sei separati server di run-time, oltre al Repository server e, opzionalmente, un Enterprise Manager Server. Ciascun server di run-time può ospitare diversi Domain, ognuno dei quali consiste in una coppia di <Application Server, Message Server>.
Figura 3 - Sistema eGate Integrator distribuito
In particolare, come mostrato in Figura 1, lo strato eGate Integrator è composto da tre componenti fondamentali:
Repository;
Java System Application Server;
Java Messaging Server.
4.2.1.1.1
Repository
Il setup, i componenti e le informazioni di configurazione per gli elementi di un Project JCAPS sono immagazzinati all’interno del Repository. Tipicamente un singolo Repository è utilizzato dall’intera organizzazione così come mostrato in Figura 3. Tale Repository comune è quindi utilizzato sia per scopi di sviluppo, che di testing e produzione. La comunicazione tra il Repository e gli altri componenti di JCAPS può avvenire tramite HTTP o HTTPS, mentre i diversi client di Enterprise Designer e di Enterprise Manager
possono comunicare attraverso un firewall in modo controllato col Repository.
4.2.1.1.2
Java System Application Server
Un Environment JCAPS rappresenta il sistema completo necessario per poter porre in esecuzione un Project. L’Environment può avere al suo interno uno o più Java System Application Server che possono essere:
Logical host – composti a loro volta da uno o più Application Server (i motori che fanno girare le applicazioni deployate) come ad esempio Sun SeeBeyond Integration Server, e uno o più Message Server, che gestiscono JMS topics per la messaggistica di tipo publish-and-subscrive, e code, per la messaggistica point-to-point, come ad esempio Sun SeeBeyond JMS IQ Manager;
External System – è la rappresentazione di un sistema fisico reale che esiste all’interno di uno specifico Environment, insieme alle proprietà di configurazione per la sua localizzazione e il suo accesso. Esempi di risorse di tipo External System sono: file, Web Service e DB.
4.2.1.1.3
Java Messaging Server
Un Java Messaging Server (JMS) consente la scrittura dei flussi di “orchestrazione” dei servizi e le regole di routing intelligente dei messaggi in due modalità:
Collaboration Java o XSLT – si tratta di scenari di interazione tra i vari sistemi, disegnati per mezzo di semplici editor visuali (Figura 4). Le Collaboration (Java o XSLT) interne a Java CAPS permettono di implementare rapidamente complesse logiche di trasformazione dei messaggi, integrare sistemi multipli con logica transazionale e possono essere invocate in modo sincrono (Web Service) o asincrono (JMS);
Figura 4 - Esempio di Editor di Collaboration Java
Business Process – lo strumento di sviluppo Enterprise Designer consente anche il disegno dei processi, in modalità compatibile con gli standard di mercato più diffusi:
o BPMN (Business Process Modeling Notation) per la notazione grafica relativa ai costrutti interni al processo (attività, nodi decisionali, eventi, …); o BPEL (Business Process Execution Language) per il formalismo, basato su
XML, relativo alla memorizzazione ed esecuzione del processo.
All'interno di ciascun processo di business è possibile realizzare Business Rule, ossia regole di trasformazione, inoltro ed indirizzamento dei messaggi attraverso editor visuali denominati Business Rule Designer (Figura 5).
Figura 5 - Business Rule Designer
4.2.1.1.3.1
Paradigmi di comunicazione
Esistono in JMS due diverse tipologie di paradigmi di comunicazione supportati:
Comunicazione sincrona;
Comunicazione asincrona.
La comunicazione sincrona di tipo request/response verso un sistema esterno può essere realizzata in due modi alternativi:
mediante adapter eWay specifici per il sistema invocato, usando il protocollo ed il formato nativo di quest'ultimo (ad es. DBMS, SAP, CICS, ...);
mediante interfaccia di tipo Web Service SOAP/HTTP.
Eventuali regole di bridging tra i due paradigmi possono essere implementati attraverso opportune Collaboration che gestiscano il relativo wrapping.
La comunicazione asincrona è realizzata secondo due paradigmi:
point-to-point (JMS queue);
publish-and-subscribe (JMS topic).
I server di messaggistica possono essere liberamente distribuiti, senza alcuna limitazione, all’interno di un ambiente di deployment. Sono supportati sia server JMS “tradizionali”,
ad esempio Sun Java System Message Queue o Sun SeeBeyond IQ Manager, che server di messaggistica di terze parti, ad esempio Websphere MQ JMS o BEA WebLogic JMS. E’ possibile configurare la modalità di delivery dei messaggi in corrispondenza dell’invio di messaggi su code o topic attraverso la proprietà “Delivery Mode”. Le modalità possibili sono:
non persistente, per ottenere massime performance dato che i messaggi restano in memoria all’interno dei Message Server;
persistente, che effettua salvataggio dei messaggi su supporto fisico. In caso di recovery del sistema è dunque sufficiente trasferire i suddetti file verso il server su cui si intende riattivare il sistema di messaggistica.
4.2.1.1.3.2
Trasformazione dei dati e mediazione dei servizi
Come specificato al paragrafo 4.2.1.1.3 , le regole di trasformazione dinamica dei messaggi sono implementate all'interno di Collaborations Java o XSLT realizzate in modo visuale, oppure direttamente all'interno dei processi di business che implementano i flussi di integrazione.
Inoltre, le suddette trasformazioni o regole di business non richiedono necessariamente la preventiva convergenza verso XML di tutti i formati di messaggi oggetto di trasformazione. Gli Object Type Definition (OTD), che definiscono i messaggi in ingresso/uscita, infatti, incapsulano internamente la struttura nativa dei messaggi stessi, permettendo a tempo di esecuzione un mapping diretto da e verso i vari formati, così come mostrato in Figura 6.
Ciascun adapter (eWay) verso le varie applicazioni integrabili include wizard grafici che permettono di definire graficamente tali OTD, partendo dai metadati relativi alle suddette applicazioni (ad esempio BAPI su SAP, tabelle su DB, transazioni CICS, EJB su Application Server, ecc.).
L'implementazione di formati custom è semplificata dalla presenza di un OTD Editor visuale, che permette di definire rapidamente le regole di marshal/unmarshal dei messaggi (Figura 7). Sono inoltre presenti strumenti di test/debug per verificare la correttezza delle operazioni di lettura/scrittura del formato disegnato.
Figura 7 - OTD Editor
4.2.2
Enterprise Designer
Enterprise Designer è un editor grafico che consente di creare e configurare i componenti logici e le risorse fisiche di un Project JCAPS. Attraverso tale editor, mostrato in Figura 8, è possibile sviluppare Project contenenti Business Process, che processano e indirizzano dati tra applicazioni o sistemi esterni.
Figura 8 - Enterprise Designer
Le principali funzionalità e risorse disponibili all’Enterprise Designer sono rappresentate dal Project Explorer sulla sinistra e da un editor panel sulla destra che inizialmente è vuoto.
Il Project Explorer mostra una struttura ad albero per la rappresentazione della gerarchia dei processi creati nel repository.
L’editor panel invece può mostrare diversi editor grafici a seconda del componente selezionato nel Project Explorer. Ad esempio in Figura 8 è mostrato il Connectivity Map Editor, che consente di definire la Connectivity Map di un Project, ovvero le modalità di connessione tra i sistemi interni ed esterni utilizzati nel Project stesso.
In sostanza l’eGate Integrator utilizza le Connectivity Map per configurare automaticamente il flusso di messaggi end-to-end all’interno di uno scenario. Attraverso il drag e drop dei componenti nel pannello del Connectivity Map Editor è possibile inserire e collegare assieme i diversi sistemi utilizzati nel Project.
In Figura 9 è invece mostrato un ulteriore editor disponibile nell’editor panel dell’Enterprise Designer: il Business Process Designer, che consente il disegno grafico dei Business Process secondo lo standard BPMN.
Figura 9 - eInsight Business Process Designer
4.2.3
Enterprise Manager
L’Enterprise Manager è un’interfaccia web-based attraverso la quale è possibile gestire le applicazioni JCAPS implementate.
In Figura 10 è mostrata la home page dell’Enterprise Manager.
Figura 10 - Enterprise Manager
4.2.4
eInsight Business Process Manager
Per la funzionalità di Business Process Management, Sun propone eInsight Business Process Manager, una soluzione BPM totalmente aperta costruita su un’architettura SOA per consentire la creazione e l’orchestrazione dei processi di business per la realizzazione di applicazioni composite.
eInsight comprende anche un Task List Manager per l’esecuzione di attività che richiedono l’intervento umano (User Activity), in modo da gestire scenari di integrazione di tipo workflow-oriented.
Attraverso eInsigth è quindi possibile:
massimizzare l’efficienza dei Business Process attraverso la loro modellazione, monitoraggio, gestione, analisi e ottimizzazione grazie all’utilizzo di una graphical user interface intuitiva;
gestire i Business Process permettendo la compensazione in caso di fallimento di attività al loro interno;
astrarre la complessità riguardante l’integrazione tecnica, utilizzando notazioni standard per la modellazione dei Business Process;
inserire la business logic all’interno del processo stesso per assicurare flessibilità nell’implementazione delle applicazioni;
automatizzare l’orchestrazione dei Web Service implementando BPEL4WS per assemblare i Web Service in una più ampia applicazione composita;
fornire automaticamente tutti i benefici riguardanti l’interoperabilità dei Web Service senza richiedere agli sviluppatori una profonda conoscenza di SOAP, WSDL, UDDI e BPEL;
garantire l’integrità dei processi assicurando funzionalità di Exception Handling;
accelerare il decision making attraverso un robusto supporto al workflow, includendo supporto per l’assegnazione di task, ruoli utente e gerarchia organizzativa.
4.2.4.1
eInsight e Java CAPS
eInsight si appoggia all'Enterprise Service Bus eGate Integrator per tutte le operazioni relative all'invio di messaggi, invocazione di servizi ed applicazioni e adapter verso protocolli ed applicazioni esterne.
interfacce di front-end di eInsigth, generalmente destinate a due diverse categorie di utenti:
Enterprise Designer – utilizzato dagli sviluppatori per la progettazione e configurazione di Project e per l’integrazione delle diverse applicazioni enterprise utilizzando eGate Integrator ed altri componenti di Java CAPS;
Enterprise Manager – basato su web browser e utilizzato dagli amministratori di sistema per il deploy e l’undeploy delle applicazioni e il monitoraggio dei Business Process deployati.
Lo strumento unico di sviluppo Enterprise Designer consente il disegno dei processi, in modalità compatibile con gli standard di mercato più diffusi, come BPMN e BPEL.
In particolare, attraverso l’Enterprise Designer è possibile definire i processi sia in modo top-down, partendo da una descrizione generica del processo basata su orchestrazione di servizi astratti, che in modalità bottom-up, partendo dai servizi messi a disposizione dalla piattaforma eGate ed assemblandoli in modo grafico.
Attraverso l’Enterprise Designer, eInsight fornisce una chiara visione dei processi interni ed esterni di un’organizzazione e velocizza la progettazione ed il deploy di Business Process. Infatti la progettazione di Business Process avviene in eInsigth tramite un semplice drag e drop di componenti all’interno del Process Model editor. Il disegno del processo va poi completato attraverso l’inserzione di altre informazioni per il controllo di flusso (costrutti if then…else…, while, ecc…) e Business Rule che permettono la manipolazione di dati all’interno del processo stesso.
eInsight supporta inoltre l’import e l’export di BPEL per l’orchestrazione dei Web Service per condividere i processi modellati con tool di terze parti.
Attraverso l’Enterprise Manager eInsigth offre strumenti sofisticati di monitoraggio ed amministrazione del motore di BPM, in modalità integrata con l’intera interfaccia web-based di amministrazione.
esso è “ospitato” all’interno di eGate, utilizzandone direttamente i componenti di integrazione (code, eWays, trasformazioni, …) e i relativi servizi, tra cui:
Resource Management – abilita i componenti ad accedere alle risorse di sistema (memoria e processore) secondo le loro necessità e comunque in relazione alle esigenze degli altri componenti della piattaforma;
Sicurezza – fornisce funzionalità per l’autenticazione e l’autorizzazione all’accesso alle funzioni di eInsight;
Accesso e Immagazzinamento di dati – consente la memorizzazione delle componenti e delle informazioni di configurazione di un Project (inclusi i Business Process) all’interno del Repository;
Deploy – consente di creare Deployment Profile contenenti tutte le informazioni necessarie all’attivazione dei Business Process di eInsight e dei componenti associati. Quando un Deployment Profile è attivato, i Business Process attivi possono essere resi disponibili all’esterno come Web Service;
Monitoring – permette di osservare il flusso delle attività di un Business Process in esecuzione;
Connectivity mapping – attraverso la Connectivity Map è possibile descrivere le relazioni per il routing dei messaggi scambiati tra i componenti di eInsight e altri sistemi esterni. La Connectivity Map specifica inoltre la topologia dei servizi che verranno invocati e quindi in particolare:
o identifica la natura dei servizi da invocare;
o mostra le relazioni tra i componenti, includendo le informazioni di publish/subscribe per il data routing;
o definisce le relazioni tra i componenti che invocano i servizi;
Version Control – permette di mantenere la storia delle versioni dei Project attraverso un meccanismo di check in/check out;
Impact Analysis – consente di analizzare come i cambiamenti su un componente o Business Process impatteranno sugli altri componenti di un Project nel Repository;
esportare Business Process Model dal repository per consentire il riuso dei processi su altri sistemi.
4.2.4.2
Business Process Management in eInsigth
Sono presenti due fasi nel Business Process Management definito da eInsigth. La prima fase, detta di design, inizia prima che si cominci ad utilizzare eInsight e finisce a seguito del deploy del Business Process.
La seconda fase è chiamata runtime e si riferisce ai task che vengono eseguiti dopo aver deployato il Business Process.
4.2.4.2.1
La fase di design
L’interfaccia utente per lo sviluppo di Project in eInsight è esposta dall’Enterprise Designer. Essa permette di modellare i Business Process dell’organizzazione e di caratterizzare le varie attività che compongono l’intero processo modellato.
Lo sviluppatore può quindi implementare i Business Process attraverso il Business Process Designer. E’ data inoltre la possibilità di inserire della logica all’interno del Business Process attraverso l’uso di Collaboration.
4.2.4.2.1.1
Sviluppo di Business Process
JCAPS permette l’integrazione di applicazioni tramite la realizzazione di un Integration Project, contenente i Business Process dell’applicazione. Il Project conterrà i diversi componenti logici e le informazioni di supporto richieste per la realizzazione di routing, processing e caching di messaggi contenenti dati rilevanti che viaggiano da un’applicazione all’altra. Tutti i Project sono contenuti all’interno del repository.
I Project sono realizzati utilizzando tool contenuti all’interno dell’Enterprise Designer e, una volta effettuato il deploy, possono essere messi in esecuzione all’interno di Logical Host o altri External System definiti all’interno di un Environment.
L’Environment rappresenta l’insieme di risorse fisiche richieste per implementare il Project e metterlo in esecuzione.
I Project sono mappati all’interno dei singoli Environment attraverso i Deployment Profile, definiti all’interno dell’Enterprise Designer e che fanno essi stessi parte del Project. Attivando il Deployment Profile viene effettuato il deploy del Project all’interno dell’Environment associato.
Questa struttura di Project, Environment e Deployment Profile isola ogni implementazione in realm logici e fisici. Ciò permette grande flessibilità ed efficienza nell’implementazione ed integrazione dei Project.
In tal modo il Project, una volta sviluppato, potrà essere eseguito nell’Environment di produzione, mentre Environment separati potrebbero essere creati per lo sviluppo e testing di altre applicazioni. In Figura 11 si mostra un modello di implementazione dell’eGate Integrator che utilizza diversi Environment.
Figura 11 - Esempio di Modello di Implementazione dell'eGate Integrator
Ciascuno dei Project mostrati in Figura 11 possono essere deployati su uno qualsiasi degli Environment attraverso il mapping definito nei Deployment Profile. In particolare l’esempio in Figura 11 mostra che il Project “Patient Admittance” è già in fase di produzione e quindi deployato utilizzando il Deployment Profile relativo alla produzione. Il Project “Patient records” è in fase di staging e pertanto risulta deployato utilizzando il Deployment Profile relativo allo staging. Il Project “Insurance Billings”, poiché ancora non sviluppato e testato, è deployato negli Environment di sviluppo e testing attraverso i relativi Deployment Profile.
Tipicamente, un particolare Project esisterà in differenti versioni: una matura che è in esecuzione nell’Environment di produzione ed una migliorativa in fase di sviluppo che
invece è in esecuzione nell’Environment di sviluppo e testing.
In ogni caso il Repository manterrà al suo interno versioni diverse ed isolate dello stesso Project, ognuna relativa ad uno specifico Environment (produzione, staging, sviluppo e testing).
I passi fondamentali da eseguire per progettare ed implementare un Project in eInsigth sono i seguenti:
pianificare e progettare un modello che rappresenta un Business Process reale della propria organizzazione;
settare i componenti necessari per la modellazione del Business Process all’interno di un Project;
creare un nuovo Business Process tramite il Business Process Designer, utilizzando blocchi attività, collegamenti e blocchi decisione. Occorre dopo di ciò completare il disegno del Business Process attraverso l’inserzione della logica di gestione delle eccezioni e di qualsiasi altro elemento che caratterizza il processo da modellare;
validare, generare e salvare il Business Process all’interno del JCAPS Repository Server, dove vengono immagazzinate tutte le informazioni riguardanti la configurazione e il deploy del Business Process;
creare una o più Connectivity Map per configurare la relazione tra i componenti JCAPS coinvolti nel processo;
selezionare o creare un nuovo Environment all’interno del quale eseguire il Business Process;
selezionare o creare un Deployment Profile correlato all’Environment e alle Connectivity Map create in precedenza;
eseguire il build del Project;
eseguire lo start del Logical Host;
deployare l’applicazione sul Logical Host attraverso l’autodeply disponibile dal Deployment Profile creato precedentemente.
4.2.4.2.2
La fase di Runtime
Dopo aver completato la fase di design l’applicazione risulterà in esecuzione e quindi sarà possibile monitorare e gestire le attività del Business Process e di tutto il Project attraverso l’Enterprise Manager.
Come già anticipato in precedenza, l’Enterprise Manager offre un’interfaccia web-based che permette agli amministratori del processo di avere visibilità dello stato di ogni attività del Business Process. Ciò consente alle organizzazioni di monitorare e gestire tutti gli aspetti del Business Process attraverso un unico tool integrato. La Figura 12 mostra la finestra dell’Enterprise Manager che consente il monitoraggio di un Business Process deployato e posto in esecuzione sul relativo Logical Host.
Figura 12 - Business Process Monitor
Le azioni che possono essere svolte su un Business Process tramite l’Enterprise Manager sono chiamate Business Process Management Task. Un esempio di Business Process Management Task è rappresentato dalla possibilità di identificare errori originati da dati scorretti all’interno dei messaggi scambiati attraverso l’eGate Integrator. Attraverso questo potente strumento di controllo è dunque possibile assicurarsi che i processi continuino a girare e funzionare in modo corretto.
4.2.5
Business Activity Monitoring e eBAM Studio
un’applicazione di Business Activity Monitoring e del loro contributo e supporto all’attività di analisi e monitoraggio dei processi di business.
Infine sarà descritto in dettaglio il tool eBAM Studio presente nella suite Sun CAPS e le fasi che consentono lo sviluppo di un’applicazione BAM attraverso tale tool.
4.2.5.1
Introduzione al Business Activity Monitoring
Per mantenere la competitività nell'attuale ambiente di business, i dirigenti e i manager devono assicurare l'allineamento tra strategia e operazioni nell'intera organizzazione. Le aziende devono avere la certezza che le attività operative siano allineate agli obiettivi strategici e che i singoli dipendenti responsabili di tali attività siano costantemente in grado di tenere traccia delle prestazioni rispetto agli obiettivi prefissati.
Si tratta in sostanza di conoscere la situazione e focalizzarsi rapidamente sulle aree che richiedono attenzione.
Nel rispondere a queste sfide, una soluzione di Business Activity Monitoring (BAM) può contribuire a risolvere i problemi legati all'allineamento tra attività operative e strategia aziendale, rendendo più semplice identificare, monitorare e rispondere in modo rapido ed efficiente ai problemi urgenti. Eliminando gli ostacoli all'ottimizzazione delle attività di business e offrendo al personale operativo strumenti per tenere traccia in modo costante delle prestazioni rispetto agli obiettivi, un'organizzazione può diventare più reattiva e competitiva.
Occorre quindi raccogliere in modo efficace i dati BAM, inserirli in un contesto di business che supporta l'allineamento tra strategia e operazioni e consentire ai dipendenti di registrare e monitorare le prestazioni, confrontandole con gli obiettivi prefissati.
Ora che sempre più aziende guardano all'obiettivo dell'operatività in tempo reale, i sistemi BAM si sono imposti come nuova soluzione per la cosiddetta “Business Intelligence operativa”. Questa metodologia aggiunge funzionalità in tempo reale alle caratteristiche di analisi offerte dai sistemi di Business Intelligence e al contesto dei sistemi BPM (Business
Process Management), aumentando l'affidabilità e il valore delle informazioni. L'obiettivo di questo approccio è rendere più rapide e informate le decisioni di business, sfruttando una combinazione di informazioni storiche e in tempo reale, sia strutturate che non strutturate. Come ha dichiarato lo scrittore e consulente IT Ian Hayes:
“Una soluzione BAM monitora i processi di business e analizza le immense quantità di metriche e dati generati da tali processi, in modo da tenere traccia delle tendenze più importanti e individuare le anomalie. Il sistema applica un contesto alle metriche, convertendo i dati non elaborati in informazioni traducibili in azione […] La soluzione BAM avverte quindi tempestivamente il personale, fornendo le informazioni necessarie per decidere come intervenire. Lo scopo delle soluzioni BAM è fornire un accesso in tempo reale ai principali indicatori delle prestazioni di business, per migliorare la rapidità e l'efficacia delle operazioni”.
Monitorando gli indicatori di prestazioni chiave per rilevare problemi e opportunità, la soluzione BAM segnala al personale interessato il verificarsi di eventi significativi. Gli avvisi vengono inviati agli utenti tramite un sistema di messaggistica integrato, insieme alle necessarie informazioni di contesto che specificano la portata e le implicazioni del problema. Il sistema può includere un dashboard o una console che fornisce indicazioni su come e quando rispondere al problema, sfruttando una combinazione di dati in tempo reale, informazioni storiche, funzionalità analitiche e controlli dei processi.
Molti vendor di sistemi per il SCM (Supply Chain Management), CRM (Customer Relationship Management), ERP (Enterprise Resource Planning) e BPM, stanno cercando di affiancare alle tradizionali funzionalità delle suite di Business Intelligence, cruscotti elettronici personalizzabili per il monitoraggio in real-time di opportuni KPI.
4.2.5.2
eBAM Studio
Sun SeeBeyond eBAM Studio permette di creare applicazioni di Business Activity Monitoring in grado di intercettare il flusso di dati che attraversano i diversi componenti di JCAPS. Elaborando tali dati eBAM produce una rappresentazione visuale dell’analisi dei
dati basata su Key Performance indicator (KPI) e Alert.
In tal modo, eBAM permette di dare una panoramica di alto livello agli utenti di business permettendo l'implementazione di KPI personalizzati per misurare e monitorare lo stato delle attività di business.
In particolare, eBAM permette la realizzazione di applicazioni sofisticate di BAM per il monitoring operativo delle informazioni circolanti all’interno degli scenari di integrazione Java CAPS, rilevanti a livello strategico.
Figura 13 - Esempio di Chart in eBAM Studio
L’ambiente di sviluppo eBAM Studio, interno all’Enterprise Designer, consente:
l’accesso alle informazioni interne e alle istanze dei processi di business di eInsight, da cui è possibile “pubblicare” eventi rilevanti verso il motore eBAM;
la definizione di Key Performance Indicators ottenuti attraverso l’integrazione dei dati di base;
la definizione di condizioni di business e valori di soglia per i suddetti KPI, in modo da generare eventi di trigger e notifiche (alert);
interfacce di presentazione di tipo dashboard, con utilizzo di grafici personalizzabili (Figura 13) di vario tipo (a barre, a torta, istogrammi, semafori, ecc.).
L’integrazione di eBAM con il resto della piattaforma è nativo, in quanto è in esecuzione all’interno dell’ambiente J2EE ospitante ed utilizza direttamente i paradigmi eGate ed eInsight (OTD, regole di business, attività) per l’esecuzione delle applicazioni BAM.
Ogni applicazione eBAM è costituita da una o più Data Definition (DDN), in cui definire la natura degli eventi da monitorare, un numero variabile di grafici (Chart) per la visualizzazione dei dati in modo visuale agli utenti di business, compresa la natura dei valori (KPI) da mostrare e la modalità di calcolo degli stessi, ed un numero variabile di alert, finalizzati ad informare gli utenti di business del raggiungimento di condizioni specifiche su tali KPI, o per notificare, mediante eventi asincroni, l’esecuzione di altri processi di business che effettuino operazioni personalizzabili.
Tali operazioni sono supportate da wizard grafici all’interno dell’Enterprise Designer che permettono una semplice definizione delle regole di raccolta delle informazioni, aggregazione delle stesse mediante KPI, logica di generazione di eventi di notifica e/o alert.
In particolare, le applicazioni BAM possono essere orientate ad un output di tipo standalone, oppure possono essere integrate in modo uniforme insieme ad altre applicazioni di front-end di tipo composito all’interno di Portal Server.
In ogni caso, un’applicazione eBAM necessita dell’accesso a runtime ad un certo numero di risorse. Da tali risorse essa riceve i dati che poi processa ed elabora per trasformarli in informazioni utili per il calcolo dei KPI da monitorare.
In particolare un’applicazione eBAM necessita di:
dati provenienti a runtime dai processi, code o topic JMS o WS;
Data Definition per la costruzione delle strutture atte a contenere i dati e sulle quali verranno poi calcolati i valori dei KPI;
dashboard visuali che rappresentano i KPI sottoforma di chart a torta, a barre, meter, semafori, ecc...;
un insieme di eventi da scatenare quando il valore di un KPI raggiunge una certa soglia;
un insieme di valori per indicare la frequenza di aggiornamento dei dati da processare.
4.2.5.2.1
Componenti di un’applicazione eBAM
Un’applicazione eBAM fornisce un meccanismo per recuperare i dati scambiati tra le applicazioni attraverso eGate integrator e memorizzarli in maniera tale da permettere alle query di aggiornare e comunicare i loro risultati ai chart che poggiano su di esse.
Figura 14 – eBAM Studio Query Editor
I componenti di un’applicazione eBAM sono (Figura 15):
Data Definition – che specifica:
o un’etichetta identificante un campo della struttura DDN e il relativo datatype (string, integer, float, ecc…);
o un retention interval che specifica la durata della validità dei dati da analizzare prima di rimuoverli dal DDN;
Query – che permettono di combinare e manipolare i dati in ingresso all’applicazione eBAM attraverso costrutti SQL-LIKE. Ogni condizione di una query è una clausola WHERE all’interno di uno statement SELECT. eBAM Studio Query Editor (Figura 14) è il tool che consente la costruzione di query in modo visuale e in particolare fornisce:
o un tool visuale per filtrare e manipolare dati tramite istruzioni SQL; o la possibilità di effettuare join tra diversi Data Definition;
run time;
Chart – rappresentano l’output più significativo di un’applicazione eBAM. Ogni chart si alimenta dei risultati dell’esecuzione di una ed una sola query. Essi forniscono una rappresentazione visuale dei KPI e si aggiornano continuamente inseguendo il flusso dei dati catturati dal Business Process monitorato;
Alert – rappresentano l’altro importante output delle applicazioni eBAM. Come per i chart anche un alert si alimenta dei risultati dell’esecuzione di una ed una sola query. Attraverso gli alert è possibile inviare una e-mail con uno specifico messaggio di allarme non appena il risultato della query associata verifica una specifica condizione. Inoltre è possibile utilizzare il Web Service Notify reso disponibile da un Alert per costruire un Business Process che comunichi all’esterno le informazioni che hanno scatenato l’alert, ad esempio scrivendole su un file di OUT.
Figura 15 - Componenti di un'eBAM Application
4.2.5.2.2
Flusso di dati in un’applicazione eBAM
Per permettere la differenziazione dei task, la loro scalabilità, manutenibilità e robustezza, il flusso dei dati in eBAM segue una struttura stratificata in tre differenti layer (Figura 16):
Presentation layer – fornisce un’interfaccia grafica di front-end che permette agli analisti di business di monitorare ciò che è di loro interesse, utilizzando gli indicatori che ritengono più utili, presentati nella maniera a loro più congeniale;
Tracking layer – colleziona, aggrega e filtra i dati, effettuando aggiornamenti periodici delle informazioni di interesse nel DDN;
Messaging layer – raccoglie le informazioni di interesse dai messaggi scambiati tra i sistemi interni ed esterni coinvolti in uno o più Business Process attraverso il BUS
eGate Integrator.
Figura 16 - Architettura a livelli di un'applicazione eBAM
I tre layer sono strettamente legati ai tre componenti fondamentali di un eBAM Application mostrati in Figura 15.
La Figura 17 mostra infatti come il livello presentazione sia in realtà associato direttamente agli output dell’eBAM Application (chart e alert), il livello di tracking sia direttamente relazionato all’insieme di query che alimentano i chart e gli alert dell’applicazione e infine lo strato di Messaging BUS non è altro che l’insieme di regole che catturano e popolano i DDN dell’applicazione.
