Download pdf - The EMC Documentum xCelerated Composition Platform · Documentum xCelerated Composition Platform (xCP) è una piattaforma di sviluppo rapida che consente a partner e clienti di creare

White Paper

Abstract

In questo white paper viene fornita un’introduzione ai principi, all’approccio concettuale e ai modelli di progettazione di EMC® Documentum® xCP. L’approccio viene illustrato con un esempio concreto nell’area del Case Management, quindi il documento si conclude con un esempio dei vantaggi che è possibile ottenere. Per le applicazioni che richiedono il coordinamento di personale, processi e dati, Documentum xCP semplifica radicalmente lo sviluppo di soluzioni aziendali complesse, con i concomitanti vantaggi di costi più bassi e rischio tecnico minimo, offrendo una maggiore agilità della soluzione e un time-to-market ridotto. Ottobre 2010

EMC DOCUMENTUM xCELERATED COMPOSITION PLATFORM Analisi dettagliata

2 EMC Documentum xCelerated Composition Platform Analisi dettagliata

Copyright © 2009, 2010 EMC Corporation. Tutti i diritti riservati. EMC ritiene che le informazioni contenute in questo documento siano esatte al momento della sua data di pubblicazione. Le informazioni sono soggette a modifiche senza preavviso. Le informazioni contenute nella presente pubblicazione vengono fornite “così come sono”. EMC Corporation non riconosce garanzie di alcun genere inerenti le informazioni riportate nella presente pubblicazione, tra cui garanzie implicite di commerciabilità o idoneità ad un determinato scopo. L’uso, la copia e la distribuzione di qualsiasi software EMC descritto in questa pubblicazione richiede una licenza software applicabile. Per un elenco aggiornato dei nomi di prodotti di EMC, vedere i marchi di EMC Corporation sul sito web di EMC. Tutti gli altri marchi citati nel presente documento appartengono ai rispettivi proprietari. Part Number h4723.1


Sommario

Executive Summary ······································································································ 4

Introduzione ················································································································ 4

Destinatari ···························································································································· 4

Che cos’è EMC Documentum xCelerated Composition Platform? ······································· 5

Vantaggi ······························································································································· 5

Obiettivi e principi ········································································································ 6

Obiettivi ································································································································ 6

Principi di progettazione ········································································································· 7

Approccio concettuale ·································································································· 8

Modelli di progettazione ····························································································· 10

Modelli di progettazione dei processi ···················································································· 10

Avvio del processo ··········································································································· 10

Mapping dei dati di processo ···························································································· 10

Richiamo di processi ············································································································ 12

Modelli di interfaccia utente ································································································· 12

Task View ························································································································ 13

Azioni configurabili ·········································································································· 14

Modelli di generazione di report ···························································································· 15

BAM Control Process ········································································································ 15

Generatore di origini dati ·································································································· 16

Generatore di report ········································································································· 17

Esempio di Case Management ····················································································· 18

Persone coinvolte ················································································································ 18

Riepilogo del caso ················································································································ 18

Componenti riutilizzabili ······································································································ 18

Processi ······························································································································ 19

Anatomia di un processo ······································································································ 20

Il “motore a quattro fasi” ······································································································ 23

Conclusione ·············································································································· 23

Riduzione dei costi ··············································································································· 23

Eliminazione del rischio ······································································································· 24

Time-To-Market ridotto ········································································································· 24

Facilità di espansione ·········································································································· 24


Executive Summary Negli ultimi anni le tecnologie ECM (Enterprise Content Management) e BPM (Business Process Management) sono state progressivamente integrate fino ad esercitare un impatto coordinato sui problemi aziendali. Un processo aziendale crea e consuma documenti, gestendo inoltre il flusso di informazioni durante l’intero ciclo di vita. Esistono, tuttavia, problemi aziendali di notevole rilevanza che richiedono il coordinamento di più processi aziendali così come di più documenti e dati. Questi elementi devono essere gestiti come una singola unità strutturale. Sebbene la creazione di applicazioni finalizzate a questo scopo ponga sfide tecniche significative, promette al contempo di offrire enormi vantaggi. Un primo esempio è il Case Management, in cui il caso utilizza più processi e dati per raggiungere i propri obiettivi. In questo white paper viene descritta una piattaforma che consente di semplificare e accelerare lo sviluppo di tali applicazioni.

Introduzione Tradizionalmente, lo sviluppo di applicazioni della linea di business affidabili comportava investimenti ingenti nella codifica personalizzata, in quanto richiedeva l’assunzione di costoso personale per la programmazione, con un processo impegnativo sia in termini di manodopera che di tempo. Inoltre, apportare modifiche a queste applicazioni era un processo rischioso e quanto mai labile. Le soluzioni risultanti erano in genere altamente specifiche, pertanto non erano facilmente riutilizzabili tra i clienti.

Il presente white paper propone un’alternativa alla codifica personalizzata, ossia una piattaforma integrata per lo sviluppo delle applicazioni, che offre un ambiente operativo, strumenti, componenti predefiniti e configurabili oltre a modelli di progettazione per l’assemblaggio di tali componenti all’interno delle applicazioni. Include inoltre un’architettura di riferimento, best practice, materiale formativo e software collaterale. L’obiettivo è semplificare lo sviluppo delle applicazioni sostituendo la codifica personalizzata con la configurazione.

Nel resto di questo white paper viene descritta l’implementazione EMC di questo approccio: EMC® Documentum® xCelerated Composition Platform (xCP). Documentum xCP offre un nuovo standard per lo sviluppo delle applicazioni su una singola piattaforma di composizione che combina un insieme di tecnologie perfettamente integrate con strumenti di distribuzione e sviluppo, best practice e un approccio che privilegia la configurazione rispetto alla codifica. Tale piattaforma consente ai partner e ai clienti di creare e implementare rapidamente applicazioni aziendali basate sui casi con un minor numero di risorse e costi complessivi di gestione (TCO) più bassi.

Destinatari

Questo white paper è destinato a CIO, CTO, professionisti dell’IT, analisti aziendali e sviluppatori. Può inoltre essere interessante per qualsiasi persona che operi nel settore aziendale e che desideri meglio comprendere come le soluzioni e le


applicazioni aziendali basate sui casi possano ridurre i costi, aumentare l’efficienza e la produttività oltre che migliorare la customer experience.

Che cos’è EMC Documentum xCelerated Composition Platform? Documentum xCelerated Composition Platform (xCP) è una piattaforma di sviluppo rapida che consente a partner e clienti di creare più velocemente soluzioni e applicazioni dinamiche basate sui casi, con un numero inferiore di risorse e costi più bassi, producendo applicazioni agili e flessibili che riducono i costi complessivi di gestione. Figura 1 offre una panoramica dei componenti di Documentum xCP Platform.

Figura 1. Panoramica di Documentum xCP

Documentum xCP offre:

• Strumenti integrati, un ambiente operativo, un repository e servizi

• Un insieme di componenti predefiniti, facilmente configurabili

• Modelli di progettazione documentati e strumenti di sviluppo per l’assemblaggio dei componenti all’interno delle applicazioni

Il principale vantaggio di xCP è la riduzione o persino l’eliminazione della necessità di codice personalizzato, in quanto quest’ultimo viene sostituito dalla configurazione.

Avvalendosi dei principi dell’architettura orientata ai servizi (SOA, Service Oriented Architecture), xCP crea e gestisce processi, documenti e dati strutturati e ad hoc, consentendo l’integrazione con servizi interni ed esterni.

Vantaggi

L’utilizzo della piattaforma xCP offrirà numerosi importanti vantaggi alle aziende e agli istituti governativi, tra cui:

• Riduzione dei costi di sviluppo mediante l’impiego di un numero inferiore di risorse


• Riduzione del rischio grazie allo sfruttamento di sperimentati modelli di progettazione e configurazione

• Time-to-market inferiore, in quanto verrà dedicato minor tempo allo sviluppo del software e ai cicli di test

• Adattabilità ed espandibilità della soluzione grazie ad una metodologia modulare basata su componenti

Obiettivi e principi

Obiettivi • Consentire ai partecipanti di un’applicazione aziendale di aggiungere valore in

base alla propria esperienza e di esercitare la propria capacità di giudizio

• Consentire di supportare queste decisioni con processi automatici rigorosi e prevedibili

• Fornire un punto di visibilità e di controllo centrale, per tenere traccia, monitorare e verificare tutti gli aspetti dell’applicazione

Il primo obiettivo si distacca dai tradizionali workflow deterministici e consente la collaborazione e decisioni ad hoc. Come sottolineato dall’analista di Gartner, Marc Kerremans,

“Il Case Management si discosta dalla tradizionale visione di processi predefiniti strutturati e sequenziali, proponendo al contrario, workflow non deterministici, contenenti uno o più punti dove sono possibili diverse alternative di continuazione. Sono più influenzati dalla decisione umana e dallo stato del contenuto invece che da altri fattori.1

Il primo obiettivo è fornire ai partecipanti un ambiente di lavoro flessibile e collaborativo, che consenta loro di esercitare la propria capacità di giudizio ad hoc, in modo più strutturato e sistematico.

”

Il secondo obiettivo riflette l’importanza dei “processi di utilità”. Questi processi automatici svolgono funzioni di routine in background, eliminando la necessità di eseguire noiose funzioni manuali che non richiedono l’intervento umano. Tuttavia, la cosa più importante è che questi processi assicurano la conformità alle normative garantendo la coerenza e l’accuratezza della gestione delle informazioni.

Il terzo obiettivo consente la gestione dell’applicazione e richiede una profonda comprensione della situazione attuale oltre che visibilità sui traguardi raggiunti, offrendo parametri su come le persone coinvolte assolvono le proprie responsabilità. Senza questo livello di controllo, tali applicazioni potrebbero diventare ingombranti, lente e imprevedibili.

1 Marc Kerremans, “Case Management is a Challenging BPMS Use Case,” dicembre 2008.


Principi di progettazione

Se gli obiettivi consentono di identificare i traguardi da raggiungere, i principi si focalizzano sul mood in cui è possibile raggiungerli. xCP si basa su tre principi di progettazione di base.

1. Fornire un ricco insieme di componenti e modelli predefiniti che è possibile ampliare e utilizzare come fondamenta di un’applicazione.

Esempio 1: xCP include una vasta gamma di modelli di attività. Ciascun modello di attività rappresenta un servizio o un’azione che viene eseguita automaticamente dal sistema. Combinando questi modelli in un processo, il progettista dei processi crea servizi aziendali composti di livello più elevato. Il progettista trascina il modello sul diagramma del processo, quindi configura le proprietà del modello. Un esempio è rappresentato dal modello di attività che crea un nuovo caso direttamente dal modello di una cartella.

Esempio 2: i modelli vengono forniti per creare l’interfaccia utente dell’applicazione. Un’interfaccia utente TaskSpace è composta da moduli che sono basati su modelli di moduli. Questo assicura rapidità di sviluppo e agilità, in quanto una progettazione UI può essere modificata nel giro di secondi, trascinando i controlli dei moduli e le proprietà del layout delle impostazioni. Ad esempio, per scambiare un campo del cognome con un campo del nome e viceversa, il progettista accede al modulo sottostante, esegue il trascinamento e la modifica viene compilata immediatamente.

Esempio 3: in EMC Business Activity Monitor è possibile creare report di monitoraggio trascinando le entità dei processi e dei dati, senza necessità di conoscenze di programmazione o di database. La creazione di un grafico a barre che fornisce un riepilogo dei dati delle prestazioni in base allo stato, può essere eseguita in pochi minuti. I report vengono quindi trascinati sui dashboard nel giro di secondi.

2. Creare applicazioni tramite un processo di sviluppo, ossia configurando, quindi assemblando i componenti anziché tramite la programmazione personalizzata.

Tutte le funzioni e i processi vengono esposti come servizi, consentendo la composizione efficace nell’applicazione. Questo significa che il cliente o il partner può scegliere di creare un’interfaccia utente personalizzata e comunque eseguire un processo aziendale xCP. Dal momento che tutti i componenti sono un servizio, è possibile richiamare questi servizi dal client preferito.

3. Definire modelli di progettazione espliciti per l’assemblaggio dei componenti nelle soluzioni.

La definizione tradizionale dei modelli è stata fornita da Christopher Alexander:

“Ciascun modello descrive un problema che si verifica ripetutamente nel nostro ambiente, in modo che sia possibile utilizzare questa soluzione un numero infinito di volte, senza mai implementarla nello stesso modo.2

2 Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, 1994

”


I modelli di progettazione definiscono le tecniche per combinare i componenti nelle applicazioni. La sezione “Modelli di progettazione” a pagina 10 fornisce una descrizione di diversi importanti modelli di progettazione xCP.

Approccio concettuale In questa sezione viene fornita una panoramica di alto livello delle principali idee e dell’approccio concettuale alla base di xCP, fornendo gli elementi necessari per la discussione sull’applicazione di esempio Grants Management.

Il concetto principale alla base di xCP è che le soluzioni complesse sono composte dall’interazione di oggetti Documentum con i processi aziendali. Gli oggetti forniscono un modo statico e persistente di acquisire le informazioni. I processi sono transitori ma rappresentano un modo dinamico per creare, trasformare e spostare le informazioni. Gli oggetti e i processi Documentum si scambiano i dati dei processi. Ad alto livello, l’interazione tra oggetti, processi e dati può essere rappresentata come mostrato nella Figura 2.

Figura 2. Interazione tra oggetti, processi e dati

Gli oggetti Documentum includono elementi quali cartelle, moduli e documenti. Ciascun oggetto contiene metadati persistenti. Gli oggetti possono inoltre contenere o essere collegati ad altri oggetti, ad esempio cartelle che includono documenti.

Un processo è composto da una serie di attività, che possono essere puramente automatiche o presentare un’interfaccia per un utente che deve eseguirle. Un’attività può consentire di gestire oggetti o richiamare istanze dei processi. I dati dei processi vengono gestiti dal processo sotto forma di variabili di processo, che possono essere di tipo semplice o complesso. Le variabili di processo vengono gestite e utilizzate per tutta la durata del processo e scadono quando il processo viene completato.


Gli eventi che interessano oggetti Documentum possono avviare i processi. È possibile configurare questa operazione affinché venga eseguita in numerosi modi.

• Esempio 1: quando un fax viene ricevuto e inserito in una cartella, viene avviata una nuova istanza del processo.

• Esempio 2: quando viene ricevuta un’email, viene avviata una nuova istanza del processo.

• Esempio 3: quando i dati vengono inseriti in un database, viene avviata una nuova istanza del processo.

Un processo è composto da una serie di attività, ciascuna delle quali può essere manuale, ossia eseguita da una persona, o puramente automatica. Le attività possono creare e gestire nuovi oggetti Documentum o richiamare istanze di altri processi.

Quando gli utenti eseguono un’attività inclusa in un processo, l’interfaccia utente, TaskSpace, presenta i dati all’interno di moduli che l’utente può leggere e aggiornare. I moduli possono inoltre contenere pulsanti d’azione, che è possibile configurare per eseguire tipi di azioni differenti. Un importante tipo di azione è l’attivazione di un processo aziendale per eseguire un servizio aziendale composito o per rendere automatico un workflow eseguito da persone. Può essere visualizzata una gamma di pulsanti azione. A seconda del pulsante selezionato dall’utente, vengono attivati processi differenti.

Figura 3 rappresenta un’elaborazione della figura precedente ed evidenzia il ruolo dei moduli nel mediare l’interazione tra oggetti, processi e dati.

Figura 3. Interazione dei moduli con oggetti, processi e dati


Modelli di progettazione In questa sezione vengono descritti alcuni importanti modelli di progettazione per le applicazioni xCP. In realtà questi modelli specificano come risolvere problemi ricorrenti utilizzando componenti e modelli standard. Vengono descritti tre tipi di modelli: modelli di progettazione dei processi, modelli dell’interfaccia utente e modelli di generazione di report (necessari per Business Activity Monitoring).

Modelli di progettazione dei processi

Avvio del processo

Un’istanza di processo viene avviata tramite un’attività di avvio, che può essere manuale o automatica. In un avvio manuale, l’utente avvia l’istanza di processo mediante l’invio di un modulo. Il modulo contiene campi di dati e probabilmente anche oggetti allegati. In un avvio automatico, il processo viene attivato da un evento, ad esempio la ricezione di un’email in arrivo. Un listener rileva l’evento e avvia la nuova istanza di processo.

Un processo può includere più attività di avvio, ciascuna delle quali avvierà un’istanza di processo. Come sarà possibile osservare nel caso Grants Management a pagina 18, il processo Grants Request può essere avviato utilizzando uno dei seguenti elementi:

• HTTP POST

• Ricezione di un’email

• FTP in entrata

• Richiesta di un servizio web

Per le attività di avvio automatico, il progettista del processo utilizzerà lo strumento di mappatura dei dati del processo (vedere di seguito) per specificare le regole per la copia dei dati provenienti da messaggi in arrivo nei dati del processo3

Mapping dei dati di processo

. Per le attività di avvio manuale, il progettista del processo creerà un modello di modulo, che è associato ai dati del processo. Gli utenti finali avvieranno le istanze del processo inviando questo modulo.

I processi consentono lo scambio e l’integrazione delle informazioni tra sistemi e origini dati differenti.

• Esempio 1: un processo può eseguire la query su un database, quindi effettuare il mapping dei gruppi di risultati per l’elaborazione dei dati affinché possano essere utilizzati per prendere decisioni di routing.

• Esempio 2: un processo può eseguire il mapping delle variabili di processo sui metadati del contenuto, per renderli persistenti nel repository di Documentum.

• Esempio 3: un processo può richiamare un servizio web. Questo comporta il mapping in due direzioni: per prima cosa verrà eseguito il mapping dati del

3 Dati di processo è un’espressione generica che si riferisce sia alle variabili di processo che ai metadati del contenuto. Questo ultimo tipo nel processo è denominato “pacchetti”.


processo sui parametri di input del servizio web, quindi verrà eseguito il mapping dell’output del servizio web sui dati del processo.

Il mapping dei campi di dati richiede chiaramente un mezzo. Al contrario, è necessario eseguire il mapping dei dati del processo su un database o su altri sistemi. Process Data Mapper è uno strumento che semplifica lo scambio dei dati di processo. Poiché il mapping viene eseguito in modo grafico, utilizzando il trascinamento semplice, non è richiesta alcuna codifica.

Nell’esempio riportato nella Figura 4, il campo “start_date” nell’oggetto Execution Data viene copiato quindi mappato su “DateReceived” in Variables.

Figura 4. Process Data Mapper

Utilizzando l’editor di funzioni (il menu a discesa denominato Select Function), Process Data Mapper consente di eseguire trasformazioni dei dati complesse così come semplici operazioni di copia, ad esempio il mapping di una data su una variabile stringa (con la funzione date-to-string). È inoltre possibile eseguire il mapping di una variabile su più variabili, come mostrato nella figura 5.

Figura 5. Trasformazioni complesse dei dati


Richiamo di processi

Un modello di progettazione comune è un processo in grado di delegare il lavoro. Un’attività all’interno di un processo può richiamare un servizio o un altro processo come servizio composito. Utilizzando un modello di attività Invoke Process un processo richiama un processo child. Avendo richiamato un processo child, il processo parent può continuare ad essere eseguito oppure attendere la ricezione di un segnale da parte del processo child. Utilizzando un modello di attività Post Event to Parent, il processo child segnala al processo parent l’avvenuto completamento. Quando il processo parent riceve il segnale, viene eseguita un’attività di attesa e il processo continua.

Figura 6. Richiamo di processi

Questo comporta il quesito su come il servizio web o il processo richiamato risponderà alla specifica istanza di processo che lo ha richiamato, in quanto potrebbero essere contemporaneamente in esecuzione più istanze di processo. La correlazione consente di risolvere questo problema. Per far sì che il processo risponda all’istanza corretta, il messaggio di richiesta (da parent a child) includerà un identificatore di correlazione che identifica in modo univoco l’istanza di processo. Il messaggio di risposta (da child a parent) conterrà lo stesso identificatore di correlazione. Quando Process Integrator4

Modelli di interfaccia utente

riceve il messaggio di risposta, utilizzerà l’identificatore di correlazione per instradare il messaggio all’istanza di processo corrispondente.

TaskSpace è un’interfaccia utente altamente configurabile che combina processi, contenuto e monitoraggio in un’unica esperienza utente, espressamente progettata per applicazioni aziendali incentrate sulle transazioni. TaskSpace consente di creare e implementare applicazioni intuitive realizzate su misura per ruoli differenti. Consente di configurare le applicazioni per gli utenti che ricevono ed eseguono il lavoro, per i responsabili che distribuiscono e tengono traccia delle attività all’interno dei team e per i responsabili dei processi che hanno esigenza di

4 Process Integrator è il componente server responsabile della gestione dell’integrazione: avvia processi, gestisce la messaggistica peer-to-peer e broadcast, richiama i servizi e gestisce le nuove chiamate.


monitorare in tempo reale le prestazioni operative. TaskSpace include una serie di schede, ciascuna delle quali offre una vista differente. Una di queste schede include la Task View.

Task View

La Task View mostra il lavoro effettivo che l’utente addetto dovrà eseguire, pertanto è quella più importante e utilizzata in TaskSpace. Richiama l’attenzione dell’utente sulle informazioni necessarie ad eseguire l’attività nel modo più efficiente possibile. Nella Figura 7 Task View è visualizzata nella scheda Open Items.

Figura 7. EMC Documentum TaskSpace

Questo esempio mette in evidenza alcuni componenti importanti:

• Mostra come una vista delle cartelle può essere incorporata all’interno di una Task View

• Nella parte superiore sinistra sono visualizzati i metadati, con informazioni sull’attività

• Nell’area sottostante è collocata la vista del contenuto della cartella, in cui è incluso un gruppo di documenti

• Nella parte destra è visualizzato il riquadro di anteprima del documento, che mostra il documento selezionato

• Nella parte inferiore sinistra sono disponibili diversi pulsanti azione


L’utente che esegue l’attività ispeziona i dati, inserisce eventuali valori richiesti, aggiorna i campi di dati e preme i pulsanti azione appropriati.

La creazione di una Task View è un’operazione di configurazione. Il progettista seleziona il processo e l’attività, quindi trascina i controlli UI predefiniti e li associa ai dati del processo. Il modulo dell’attività in cui viene eseguita questa operazione è mostrato nella Figura 8.

Figura 8. Configurazione di TaskSpace

Una volta compilato il modulo, il progettista può impostare diversi parametri di visualizzazione in TaskSpace, inoltre, configurando componenti predefiniti, può creare e modificare l’interfaccia utente con la massima facilità. Non è necessaria alcuna codifica.

Azioni configurabili

Si è visto come in TaskSpace siano disponibili diversi pulsanti azione. I progettisti possono creare pulsanti azione per eseguire numerosi tipi di azione, ad esempio creare documenti, moduli o processi. Nell’esempio riportato sopra, sono visualizzati i seguenti pulsanti:

Figura 9. Azioni configurabili in TaskSpace

Ciascuno di questi pulsanti viene utilizzato per avviare un processo. Per la creazione di un’azione che avvii un processo, verrà utilizzata la procedura guidata di TaskSpace, la quale assisterà l’utente durante il processo di configurazione. Il progettista specifica il modo in cui desidera avviare il processo, seleziona il processo specifico e infine lo associa ad un pulsante.


Modelli di generazione di report

In Business Activity Monitor (BAM) di Documentum, i report vengono eseguiti a fronte dei dati di esecuzione dei processi storici in tempo reale. Questi report vengono creati in uno strumento denominato Process Reporting Services (PRS). I risultati del report vengono visualizzati in un dashboard e integrati in una scheda all’interno di TaskSpace, che offre prospettive visive sul livello di efficienza con cui i processi soddisfano gli indicatori prestazionali. È necessario tenere conto di tre importanti modelli di generazione dei report: il BAM Control Process, il generatore di origini dati e il generatore di dashboard.

A differenza di altri prodotti BAM, il BAM di EMC Documentum è strettamente integrato nell’esecuzione del processo, pertanto i processi di monitoraggio non richiedono una configurazione complessa. Una volta eseguito il processo, i dati BAM sono disponibili e pronti per la generazione del report.

BAM Control Process

BAM è progettato per monitorare le prestazioni dei singoli processi utilizzando le informazioni che esso estrae da Process Engine. BAM può concentrarsi su singole istanze di processo per mostrare esattamente l’avanzamento del processo e l’attività al momento in esecuzione. Tuttavia nelle applicazioni aziendali complesse, in cui numerosi processi possono essere eseguiti in parallelo, è importante fornire un punto di visibilità e di controllo centrale. Questo è l’obiettivo del BAM Control Process, un processo singolo che consente di raccogliere informazioni da altri processi, fornendo una vista consolidata. I responsabili e altri utenti possono vedere le fasi principali e comprendere lo stato dell’applicazione globale. Figura 10 mostra un esempio tipico di BAM Control Process utilizzato in un’applicazione Grants Management:

Figura 10. BAM Control Process

Tutte le attività che il BAM Control Process comprende sono automatiche. Le attività nei singoli processi segnalano queste attività per indicare che sono in corso.

Figura 11. I singoli processi segnalano un BAM Control Process

Naturalmente la comunicazione tra processi deve riportare l’identificatore del caso in una singola istanza di questo BAM Control Process.


Con queste informazioni il sistema BAM può eseguire diversi report e immettere i dati in un dashboard mostrando lo stato dell’applicazione.

Generatore di origini dati

I report sono logicamente suddivisi in due parti: la definizione dell’origine dati e la specifica del formato del report. Le origini dati definiscono la struttura logica dei dati. PRS consente al progettista del report di definire le origini dati senza la necessità di disporre di conoscenze di programmazione o di SQL. Al contrario, l’utente può semplicemente trascinare le entità dei report.

Figura 12 mostra un esempio delle origini dati contenenti un’entità parent e un’entità child.

Figura 12. Origine dati con un’entità parent e un’entità child

L’entità parent, Activity Execution, corrisponde alle istanze delle attività. L’entità child, ERForm, si riferisce ai dati del processo. In questo esempio l’utente compila un Expense Report. Il progettista crea un’origine dati trascinando le entità da una palette contestuale. Ciascun elemento di questo report sarà una coppia ordinata (Activity Instance ID, State), come mostrato nella Figura 13.

Figura 13. Elementi delle origini dati utilizzati nei report


Figura 14. Trasformazione dei dati in un grafico a barre

Questa origine dati può essere facilmente trasformata in un grafico a barre mediante l’impostazione appropriata dei parametri di presentazione del report.

Generatore di report

Una volta definiti, i report possono essere inseriti nei dashboard. Per creare un dashboard, è sufficiente aggiungere una nuova scheda in TaskSpace. Sarà, quindi, possibile configurare il dashboard trascinando i report da una struttura di report nell’area di disegno. Un report può essere trascinato sopra, sotto, a destra o a sinistra di un altro report. Non è necessaria alcuna programmazione. Figura 15 mostra l’esempio di un dashboard, Grants Trends, che include 5 report differenti.

Figura 15. Dashboard Grants Management

La creazione di un dashboard completo può essere eseguita in pochi minuti. È possibile creare più dashboard, per persone dell’organizzazione diverse e ciascun report può essere riutilizzato all’interno di dashboard differenti.


Esempio di Case Management Dopo aver descritto le principali caratteristiche tecniche di xCP, verranno ora analizzati i problemi aziendali che questa piattaforma consente di risolvere. Case Management è una classe di applicazioni di crescente importanza, rilevante per numerosi settori, tra cui quello pubblico, sanitario, assicurativo, legale e dei servizi finanziari. Il caso è il punto di controllo centrale contenente documenti, attività, dati e discussioni. È possibile accedere al caso e aggiornarlo in base ad un insieme di processi aziendali. Nel corso di questi processi, gli addetti al caso aggiornano e aggiungono documenti e immettono informazioni. Queste informazioni consentono agli addetti e ai responsabili del caso di prendere decisioni sulla relativa eliminazione. Il caso persiste anche dopo che il processo ha completato il proprio corso. Questo assicura che i casi possano essere sempre controllati e che i casi futuri possano essere collegati ai casi precedenti.

Persone coinvolte

Verrà ora esaminato il caso Grants Management, un caso speciale di Case Management. L’approccio e le caratteristiche tecniche di questo caso sono applicabili alle applicazioni di Case Management in generale. L’esempio include tre protagonisti:

• Un richiedente, ossia una persona che opera nel campo della ricerca e che desidera ottenere dei fondi da un’agenzia governativa

• Il Grants Manager, ossia un dipendente dell’agenzia governativa che gestisce la domanda (ossia il “caso”) dall’inizio alla fine

• Un revisore, ossia un esperto che valuta la richiesta di sovvenzione (Grant) in termini di importanza, fattibilità, appropriatezza del finanziamento e così via

Riepilogo del caso

Le persone coinvolte interagiscono nel seguente modo:

1. Una persona presenta un modulo di richiesta di una sovvenzione.

2. Il Grants Manager riceve tale richiesta e ne verifica la validità;

3. può inoltre chiedere al candidato di fornire informazioni aggiuntive.

4. Invia quindi la richiesta ai revisori che fanno dei commenti e inviano la loro valutazione formale.

5. In base alla valutazione, il Grants Manager approva o respinge la richiesta inviando notifica alla persona che ha presentato la domanda.

Componenti riutilizzabili

L’oggetto alla base del caso è la cartella Grant Request, che contiene due sottocartelle:

• Grant Submitted Application, contenente il modulo ricevuto dalla persona che presenta la domanda

• Grant Review History, contenente le informazioni sulle revisioni


La creazione di un nuovo caso è un’operazione semplice, in quanto Process Builder5

Nell’applicazione vengono creati due importanti oggetti Documentum persistenti:

offre un modello di attività predefinito che consente di creare automaticamente nuovi casi basati sul modello del modulo.

• Grants Application Package, che è essenzialmente il modulo compilato dal richiedente

• Grants Request Package, che contiene tutte le informazioni create durante il ciclo di vita della sovvenzione

Processi

Per completare il proprio lavoro l’applicazione Grants Management utilizza numerosi processi, due dei quali richiedono l’intervento dell’utente e la parte rimanente sono processi “basati di utilità”. La relazione logica tra i processi è mostrata nella Figura 16.

Figura 16. Panoramica di alto livello del processo Grants Management

Il risultato del processo Create Grant Request è la creazione di un nuovo oggetto Grant Request. Una volta creato l’oggetto, viene automaticamente avviato un processo Manage Grants Request. Il processo di controllo principale è quello mostrato nella parte centrale, ossia “Manage Grants Request”, il quale include una sola attività manuale “Process Grant Request”, in cui Grants Manager ha la possibilità di scegliere tra alcune azioni, ciascuna delle quali attiva un altro processo: Request Documents, Start Review Process e Send Notification (all’interno della casella rossa). Tutti gli altri processi all’interno del diagramma vengono chiamati dai relativi processi parent, ad esempio Classify and Validate viene richiamato da Create Grant Request.

5 Lo strumento di progettazione di base per l’elaborazione dei servizi e la gestione delle richiamate.


Anatomia di un processo

Verrà ora esaminato in dettaglio uno dei processi dell’applicazione Grants Management, ossia Manage Grants Request.

Figura 17. Processo Manage Grants Request

Il processo inizia con un’attività di avvio automatico, che recupera la richiesta di sovvenzione successiva dal repository di Documentum. La seconda attività è un processo di mapping dei dati, mediante il quale viene eseguito il mapping degli attributi dell’oggetto Grant Request sui dati del processo. La terza attività è manuale, ossia è un’attività che deve essere eseguita da un utente, in cui il responsabile Grants Manager, esegue un’azione sulla richiesta. La Task View, già osservata in precedenza, viene mostrata nella Figura 18.


Figura 18. Interfaccia utente per i Grants Manager

Il Grants Manager può scegliere di fare clic su uno dei seguenti pulsanti azione. Quando fa clic sul pulsante Send To Reviewers, vengono prodotti diversi effetti. Per prima cosa viene recuperato un elenco dei potenziali revisori dal repository di Documentum. Questo viene utilizzato per compilare il modulo mostrato nella Figura 19, in cui Grants Manager seleziona i revisori che si occuperanno effettivamente del caso.


Figura 19. Assegnazione dell’interfaccia dei revisori

Una volta che l’utente fa clic sul pulsante Send, viene avviato il processo Start Review e le informazioni contenute in questo modulo, ossia l’elenco dei revisori, verranno passate al processo.

Come mostrato nella Figura 20, il Grants Manager ha a disposizione tre processi, ciascuno dei quali viene attivato da un pulsante azione.

Figura 20. Viene attivato all’interno del processo Grants Request

È inoltre possibile osservare la presenza di un’altra chiamata di processo. Un’attività nel processo Start Review richiamerà il processo Vote on Grants Request durante il quale il revisore compila il modulo e consiglia l’approvazione o il rifiuto della richiesta di sovvenzione.

Le attività rimanenti in Manage Grants Request inviano i dati al processo di monitoraggio (necessario per il dashboard BAM), eseguono il mapping dei


commenti dei revisori sull’oggetto Grant Request, inviano un’email al candidato che ha presentato la domanda informandolo che la richiesta è stata approvata, quindi archiviano la sovvenzione.

Il “motore a quattro fasi”

L’applicazione Grants Management include un modello di soluzione che ricorre continuamente.

1. La persona che esegue l’attività decide di intraprendere un’azione e fa clic su un pulsante azione.

2. Facendo clic su questo pulsante viene avviato un modulo che consente all’utente di immettere dati.

3. Può anche essere richiamato un adattatore di modulo, come nel precedente esempio dove era necessario per compilare l’elenco di revisori.

4. Il pulsante azione attiva quindi un processo aziendale che consuma i dati del processo provenienti dal modulo.

Questo modello di “motore a quattro fasi” può essere richiamato in modo ricorsivo, in quanto il nuovo processo può presentare all’utente un’altra attività con pulsanti azione, quindi richiamare un altro processo. In generale, l’architettura xCP si basa su un approccio frattale in cui le strutture “possono essere suddivise in parti, ciascuna delle quali è [almeno approssimativamente] una copia di dimensione ridotte dell’intero”.

Questo modello consente al Grants Manager la massima libertà per l’utilizzo della propria esperienza e per prendere decisioni, permettendo contemporaneamente di richiamare processi di utilità, che eseguono numerose operazioni automatiche, strutturabili e ripetibili.

Conclusione In questo white paper, è stato illustrato come le applicazioni di Documentum xCP vengano create mediante la configurazione di componenti predefiniti e il relativo assemblaggio in base a modelli di progettazione documentati. Sono stati esaminati diversi componenti e modelli di progettazione nel contesto di un’applicazione basata sui casi. Tale approccio offre i seguenti vantaggi:

Riduzione dei costi

Il costo di sviluppo è della massima importanza per i clienti e gli integratori di sistemi. Con l’approccio xCP, basato su componenti e modelli di progettazione predefiniti, un progetto di sviluppo richiederà un minor numero di risorse, ad esempio un minor numero di programmatori Java esperti. L’effetto consiste nel ridurre considerevolmente i costi di sviluppo, che si tradurrà in margini di profitto più elevati o in una percentuale più alta di transazioni positive per l’integratore di sistemi. Se si considera l’intero ciclo di vita dell’applicazione, incluse le modifiche, la manutenzione e gli upgrade, i costi complessivi di gestione (che tendono a essere molto più elevati dei costi di sviluppo iniziali) risulteranno ridotti.


Eliminazione del rischio

Lo sviluppo personalizzato presenta rischi intrinseci. Le interfacce possono essere complesse e le modifiche apportate ad un’area del codice possono avere effetti imprevisti su altre. Questo comporta la necessità di revisioni della progettazione frequenti e molti livelli di test del software. Un vantaggio derivante dall’utilizzo di modelli di progettazione sperimentati e testati, è la riduzione del rischio tecnico. Seguendo le best practice, è possibile evitare potenziali problemi di prestazioni, utilizzabilità e agilità, eliminando frammentazione e rielaborazione.

Time-To-Market ridotto

In numerosi progetti di integrazione, l’obiettivo più critico è velocizzare il conseguimento dei risultati aziendali. Per un cliente, l’implementazione rapida di una soluzione può fare la differenza tra la sopravvivenza e l’estinzione. Assemblando le soluzioni dai componenti, lo sviluppo può essere sostanzialmente accelerato con una velocità doppia rispetto al tradizionale codice compilato a mano. In alcuni casi il fattore di accelerazione sarà ancora superiore.

Facilità di espansione

Acquisendo esperienza nell’utilizzo dei componenti xCP, l’integratore di sistemi imparerà a risolvere una vasta gamma di problemi. Nuovi modelli di soluzioni emergeranno e l’integratore di sistemi compilerà le librerie di best practice, aumentando, in tal modo, l’efficienza e l’efficacia. Questo consentirà l’ampliamento del framework in una vasta gamma di soluzioni basate sui casi e incentrate sui processi in numerosi ambiti quali il settore pubblico, sanitario, assicurativo, manifatturiero e dei servizi finanziari.