martedì 7 ottobre 2014
sabato 28 aprile 2012
Developing a CMIS portlet for Liferay
Liferay Portal has many powerful tools for content’s authoring. Despite of this tools, it’s difficult to imagine that on the long term the Enterprise Portal
built with Liferay can be the only place where contents are produced
(while probably it will still be the main channel for publication and
fruition of the content itself).
In my company (www.qbreng.it) we are currently working on a content production & delivery architecture that provides our Customers a Collaboration Platform (Alfresco Share) to organize workflows for the digital asset production. The assets produced in the workflow are (generally) very low- coupled to the final delivery channel (web, mobile, disk etc).
To simplify the interaction between the internal Collaboration Platform (Alfresco Share) and the WCM (Liferay), some ECM products provide good portlets that, after a small configuration work, make able Liferay’s users to browse, inspect and download the artifacts produced and stored on the ECM.
But sometimes this portlets are not able to fully address all configuration needs for the final customer, so sometimes we need to abandon this kind of (native ECM supported) approach and proceed to develop our integration solution “from scratch”. Now we have to justify our decision with the classic “buy vs build” pattern. This is the question: “I must use native tools, cheap and configurable but limited in flexibility, or we must develop a new (costly) integration component from scratch that I can totally dominate in functions?”
Costly? No more guys. Thanks to the adoption by many ECM vendors of the CMIS (Content Management Interoperability Services) communication protocol, it is very cheap and affordable today the development of new components with very high integration capabilities.
In this article we demonstrate, with an easy exercize, how simple is to write a good customized integration solution to let Liferay and Alfresco easily communicate with each other. We will realize a small portlet that we can use to browse contents on a remote CMIS Repository (Alfresco). This portlet (evolved) is today part of our document management suite Beefly developed by my company qbreng.it.
This portlet – that we can call a “semifinished” component – can represent the first part of a more complex, CMIS-based, integration platform, very flexible and useful to address the Client’s customization’s needs.
Main features of the portlet
View the full article here
In my company (www.qbreng.it) we are currently working on a content production & delivery architecture that provides our Customers a Collaboration Platform (Alfresco Share) to organize workflows for the digital asset production. The assets produced in the workflow are (generally) very low- coupled to the final delivery channel (web, mobile, disk etc).
To simplify the interaction between the internal Collaboration Platform (Alfresco Share) and the WCM (Liferay), some ECM products provide good portlets that, after a small configuration work, make able Liferay’s users to browse, inspect and download the artifacts produced and stored on the ECM.
But sometimes this portlets are not able to fully address all configuration needs for the final customer, so sometimes we need to abandon this kind of (native ECM supported) approach and proceed to develop our integration solution “from scratch”. Now we have to justify our decision with the classic “buy vs build” pattern. This is the question: “I must use native tools, cheap and configurable but limited in flexibility, or we must develop a new (costly) integration component from scratch that I can totally dominate in functions?”
Costly? No more guys. Thanks to the adoption by many ECM vendors of the CMIS (Content Management Interoperability Services) communication protocol, it is very cheap and affordable today the development of new components with very high integration capabilities.
In this article we demonstrate, with an easy exercize, how simple is to write a good customized integration solution to let Liferay and Alfresco easily communicate with each other. We will realize a small portlet that we can use to browse contents on a remote CMIS Repository (Alfresco). This portlet (evolved) is today part of our document management suite Beefly developed by my company qbreng.it.
This portlet – that we can call a “semifinished” component – can represent the first part of a more complex, CMIS-based, integration platform, very flexible and useful to address the Client’s customization’s needs.
Main features of the portlet
- Browsing a remote repository tree with AJAX
- Setting the portlet’s root folder (from wich you start the browsing actions) with the standard configuration tools of Liferay.
- Download of remote contents trough direct repository connection or with a proxy servlet.
- Support to multi-instance. It’s’ possible to create more instances of this portlet (also on the same page), each one with a different root folder.
View the full article here
venerdì 20 aprile 2012
Beefly Touch – Touch Screen Document Management System developed on Alfresco
BEEFLY is an innovative Document Management system, developed on the Alfresco platform that includes a very intuitive touch screen user interface, called BEEFLY TOUCH.
BEEFLY uses CMIS protocol to communicate with the Alfresco platform. BEEFLY allows users to store digital documents in the Alfresco repository, by simply using a TWAIN compatible scanner. Users can also index, share, version, number and search for different kinds of documents and contents (images, videos, e-mails, faxes, etc…).
Beefly Touch – Gestore Documentale Touch Screen sviluppato su Alfresco
Beefly Touch è un software per la dematerializzazione dei documenti sviluppato sulla piattaforma Open Source Alfresco e dotato di una semplice e intuitiva interfaccia utente Touch.L ‘interfaccia Beefly permette all’utente di effettuare l’archiviazione dei documenti in Alfresco tramite uno scanner o una stampante multi-funzione compatibile con il protocollo Twain. Il prodotto permette un processo di digitalizzazione, protocollazione, classificazione, archiviazione e ricerca dei documenti distribuito.
Dettagli del prodotto
Beefly permette all’utente di velocizzare e automatizzare le attività di dematerializzazione, archiviazione e consultazione documentale, il tutto grazie ad una interfaccia utente Touch semplice e intuitiva.
Beefly è una applicazione web di tipo Rich Internet Application creata per essere utilizzata attraverso un dispositivo Touch acreen. Il prodotto permette all’utente di effttuare la classificazione e indicizzazione dei documenti archiviati in pochi passi. L’interfaccia RIA Touch è stata sviluppata in Flash/Flex ponendo massima attenzione all’usabilità dell’applicativo.
Per la gestione dei tipi di documenti (Custom Type) nel Beefly l’utente amministratore ha a disposizione l’applicativo web based ADAMO(Alfresco DAta MOdel) che consente di creare dei Custom Model ad hoc allo scopo di customizzare le tipologie di documenti del gestore documentale con i relativi metadati che possono essere di tipo testo, data, o multivalore.
Una postazione pc collegata ad uno scanner costituisce una vera e propria postazioni di dematerializzazione distribuita. Differenti persone possono effettuare contemporaneamente le attività di digitalizzazione, classificazione e indicizzazione dei documenti cartacei ed elettronici. La classificazione e l’indicizzazione dei documenti può essere svolta sia in fase di archiviazione del documento elettronico da file system che in fase di scansione.
Il Beefly presenta le seguenti caratteristiche:
- Preview dei documenti integrata per i formati PDF, MS Office, Open Office, immagini, xml e testo.
- Informazioni di dettaglio relative ai documenti, alle pratiche e ai fascicoli selezionati
- Funzione di Remote Scan dei documenti da scanner o multi-funzione compatibile con il protocollo Twain. Scansione multiDocumento attraverso un Barcode Page Separator.
- Upload dei documenti nell’archivio documentale da file system
- Protocollo elettronico dei documenti archiviati, sia in fase di upload che in fase di scansione a norma CNIPA
- Ricerca full-text dei documenti archiviati
- Ricerca avanzata dei documenti per tipologia documentale e per metadati specifici
- Funzionalità di Copia e Sposta di un documento
- Cancellazione di un documento selezionato in fase di archiviazione o di ricerca
- Salvataggio e visualizzazione dell’ultima ricerca eseguita dall’utente
- Tastiera alfanumerica e numerica completamente touch per migliorare la User Experience dell’utente
- Creazione di Pratiche nell’archivio dotati di attributi ad hoc
- Ricerca di Pratiche archiviati attraverso l’inserimento degli attributi cercati
- Configurazione dei parametri di scansione dello scanner (Twain): modalità di scansione Colore/Bianco e Nero, selezione della risoluzione e selezione del formato di output (Tiff, Pdf, Jpeg)
- Rubrica dei contatti (Mittenti/Destinatari) integrata
- Interfaccia utente localizzata in Inglese, Francese e Italiano con la possibilità di aggiungere altre lingue
- OCR dei documenti in fase di scansione
Installazione su macchina virtuale (VIRTUAL BOX)
Gestione dei moduli applicativi con Apache Maven
Vedi l'articolo completo qui
domenica 12 febbraio 2012
Alfresco Share datalist: Paginazione server-side
Durante lo sviluppo del modulo di protocollo a norma CNIPA su Alfresco Share (Beefly Protocol), ci siamo imbattuti in problemi di performance nella visualizzazione della datalist di Alfresco Share utilizzata per implementare il registro di protocollo (fig. seguente).
Tali problemi si presentavano quando il numero degli elementi della datalist raggiungeva il limite di 35-40.000 unità. L’effetto che si aveva era che il tempo di risposta del webscript che si occupa di restituire gli elementi della datalist era superiore al minuto, quindi la connessione client-server si chiudeva per timeout e il client, quindi l’interfaccia utente rimaneva “freezzata”.
Per risolvere questo problema abbiamo effettuato una analisi approfondita relativa alla gestione delle datalist da parte di Alfresco Share. Alfresco memorizza sul repository gli elementi di una datalist gestendoli come nodi contenuti in una folder. La folder rappresenta la datalist stessa, in sostanza è come avere una folder, e tanti figli ognuno rappresentante un elemento della datalist, quindi se sul repository si crea una cartella e in essa si caricano 35-40.000 files l’effetto della navigazione nella cartella dovrebbe essere lo stesso del caricamento della datalist, ma non è così!!! La navigazione, vale a dire il passaggio da una pagina all’altra, tra i figli della cartella sul repository è molto più responsiva e performante.
È bene ricordare che le impostazioni di default di Alfresco fanno si che lucene restituisca soltanto i primi 1000 elementi di ogni query (a meno che non si modifichino i parametri di configurazione), questo vale sia per le datalist che per i files contenuti nelle cartelle del repository.
I due webscript che si occupano di fare la query e restituire i risultati sono: data-post.json.js per la datalist e doclist.get.js per la documentLibrary. Analizzandoli con attenzione abbiamo notato che il tempo per eseguire la query è pressoché identico per entrambi ciò che effettivamente cambia è il numero di risultati restituiti al client. Nel caso della datalist al client vengono inviati tutti i 1000 elementi, ed in particolare per ognuno di questi elementi invocata la funzione Evaluator.run(node, fields) ciò causa notevoli rallentamenti e degrado dei tempi di risposta. In sostanza la paginazione sulle datalist e fatta sul client, la navigazione da una pagina all’altra non è altro che uno shift sull’array degli elementi che sono stati già tutti inviati al client, questo garantisce ottime prestazione nel passaggio da una pagina all’altra (tempo di risposta immediato) ma impedisce il caricamento degli elementi la prima volta che si visualizza la datalist.
Al contrario nella documentLibrary la paginazione è fatta sul server, ossia il passaggio da una pagina all’altra provoca una nuova chiamata al webscript doclist.get.js al quale vengono passati il numero della pagina e il numero degli elementi visualizzati nella pagina. Con queste informazioni lo shift sui risultati della query viene fatto sul server e la funzione Evaluator.run(node, fields) viene chiamata su un numero limitato di elementi (in particolare tanti quanti ne sono visualizzati in una pagina di solito 50) con un notevole miglioramento dei tempi di risposta.
Quindi per rendere le datalist più performanti si è deciso di applicare la stessa logica usata da Alfresco nella documentlibrary. Applicando questa logica si ottengono buoni risultati in termini di risposta al caricamento delle datalist anche con datalist che hanno 75-80.000 elementi.
Le modifiche coinvolgono due webscript. In particolare per il file datagrid.js di share (lato client) sono:
// Register History Manager page update callback
YAHOO.util.History.register("page", bookmarkedPage, function DataGrid_onHistoryManagerPageChanged(newPage)
{
Alfresco.logger.debug("HistoryManager: page changed:" + newPage);
me.widgets.paginator.setPage(parseInt(newPage, 10));
// Update the DataGrid
if (this.currentPage != newPage)
{
this._updateDataGrid.call(this,
{
page: newPage
});
}
else
{
Alfresco.logger.debug("...page changed event ignored.");
}
}, null, this);
In pratica si registra sulla funzione di cambio pagina, la funzione di updateDataGrid che permette di rifare la query. Le altre modifiche allo stesso file riguardano la definizione della tabella:
// DataTable definition
var me = this;
this.widgets.dataTable = new YAHOO.widget.DataTable(this.id + "-grid", columnDefinitions, this.widgets.dataSource,
{
renderLoopSize: this.options.usePagination ? 16 : 32,
initialLoad: false,
dynamicData: true,
"MSG_EMPTY": this.msg("message.empty"),
"MSG_ERROR": this.msg("message.error")
//paginator: this.widgets.paginator
});
// Update totalRecords with value from server
this.widgets.dataTable.handleDataReturnPayload = function DataGrid_handleDataReturnPayload(oRequest, oResponse, oPayload)
{
me.totalRecords = oResponse.meta.totalRecords;
/*oResponse.meta.pagination =
{
rowsPerPage: me.options.pageSize,
recordOffset: (me.currentPage - 1) * me.options.pageSize
}; */
return oResponse.meta;
};
e la formazione della query, in particolare alla funzione _buildSearchParams va aggiunto questa istruzione di if:
// Pagination in use?
if (this.options.usePagination)
{
obj.page = this.widgets.paginator.getCurrentPage() || this.currentPage;
obj.pageSize = this.widgets.paginator.getRowsPerPage();
}
Invece per quanto riguarda il file data.post.json.js che si trova in alfresco (lato server) le modifiche servono a gestire i nuovi parametri page e pageSize settati nel file datagrid-min.js.
Questo codice va aggiunto subito dopo l'esecuzione della query.
var pageSize, pagePos;
if (json.has("size")) {
pageSize = json.get("size");
}
else {
pageSize = allNodes.length;
}
if (json.has("pos")) {
pagePos = json.get("pos");
}
else {
pagePos = "1";
}
var nodes = [],
startIndex = (pagePos - 1) * pageSize;
nodes = allNodes.slice(startIndex, pagePos * pageSize);
for each (node in nodes)
{
try
{
items.push(Evaluator.run(node, fields));
}
catch(e) {}
}
}
Fatte queste modifiche le datalist saranno molto più performanti e veloci!!!
Tali problemi si presentavano quando il numero degli elementi della datalist raggiungeva il limite di 35-40.000 unità. L’effetto che si aveva era che il tempo di risposta del webscript che si occupa di restituire gli elementi della datalist era superiore al minuto, quindi la connessione client-server si chiudeva per timeout e il client, quindi l’interfaccia utente rimaneva “freezzata”.
Per risolvere questo problema abbiamo effettuato una analisi approfondita relativa alla gestione delle datalist da parte di Alfresco Share. Alfresco memorizza sul repository gli elementi di una datalist gestendoli come nodi contenuti in una folder. La folder rappresenta la datalist stessa, in sostanza è come avere una folder, e tanti figli ognuno rappresentante un elemento della datalist, quindi se sul repository si crea una cartella e in essa si caricano 35-40.000 files l’effetto della navigazione nella cartella dovrebbe essere lo stesso del caricamento della datalist, ma non è così!!! La navigazione, vale a dire il passaggio da una pagina all’altra, tra i figli della cartella sul repository è molto più responsiva e performante.
È bene ricordare che le impostazioni di default di Alfresco fanno si che lucene restituisca soltanto i primi 1000 elementi di ogni query (a meno che non si modifichino i parametri di configurazione), questo vale sia per le datalist che per i files contenuti nelle cartelle del repository.
I due webscript che si occupano di fare la query e restituire i risultati sono: data-post.json.js per la datalist e doclist.get.js per la documentLibrary. Analizzandoli con attenzione abbiamo notato che il tempo per eseguire la query è pressoché identico per entrambi ciò che effettivamente cambia è il numero di risultati restituiti al client. Nel caso della datalist al client vengono inviati tutti i 1000 elementi, ed in particolare per ognuno di questi elementi invocata la funzione Evaluator.run(node, fields) ciò causa notevoli rallentamenti e degrado dei tempi di risposta. In sostanza la paginazione sulle datalist e fatta sul client, la navigazione da una pagina all’altra non è altro che uno shift sull’array degli elementi che sono stati già tutti inviati al client, questo garantisce ottime prestazione nel passaggio da una pagina all’altra (tempo di risposta immediato) ma impedisce il caricamento degli elementi la prima volta che si visualizza la datalist.
Al contrario nella documentLibrary la paginazione è fatta sul server, ossia il passaggio da una pagina all’altra provoca una nuova chiamata al webscript doclist.get.js al quale vengono passati il numero della pagina e il numero degli elementi visualizzati nella pagina. Con queste informazioni lo shift sui risultati della query viene fatto sul server e la funzione Evaluator.run(node, fields) viene chiamata su un numero limitato di elementi (in particolare tanti quanti ne sono visualizzati in una pagina di solito 50) con un notevole miglioramento dei tempi di risposta.
Quindi per rendere le datalist più performanti si è deciso di applicare la stessa logica usata da Alfresco nella documentlibrary. Applicando questa logica si ottengono buoni risultati in termini di risposta al caricamento delle datalist anche con datalist che hanno 75-80.000 elementi.
Le modifiche coinvolgono due webscript. In particolare per il file datagrid.js di share (lato client) sono:
// Register History Manager page update callback
YAHOO.util.History.register("page", bookmarkedPage, function DataGrid_onHistoryManagerPageChanged(newPage)
{
Alfresco.logger.debug("HistoryManager: page changed:" + newPage);
me.widgets.paginator.setPage(parseInt(newPage, 10));
// Update the DataGrid
if (this.currentPage != newPage)
{
this._updateDataGrid.call(this,
{
page: newPage
});
}
else
{
Alfresco.logger.debug("...page changed event ignored.");
}
}, null, this);
In pratica si registra sulla funzione di cambio pagina, la funzione di updateDataGrid che permette di rifare la query. Le altre modifiche allo stesso file riguardano la definizione della tabella:
// DataTable definition
var me = this;
this.widgets.dataTable = new YAHOO.widget.DataTable(this.id + "-grid", columnDefinitions, this.widgets.dataSource,
{
renderLoopSize: this.options.usePagination ? 16 : 32,
initialLoad: false,
dynamicData: true,
"MSG_EMPTY": this.msg("message.empty"),
"MSG_ERROR": this.msg("message.error")
//paginator: this.widgets.paginator
});
// Update totalRecords with value from server
this.widgets.dataTable.handleDataReturnPayload = function DataGrid_handleDataReturnPayload(oRequest, oResponse, oPayload)
{
me.totalRecords = oResponse.meta.totalRecords;
/*oResponse.meta.pagination =
{
rowsPerPage: me.options.pageSize,
recordOffset: (me.currentPage - 1) * me.options.pageSize
}; */
return oResponse.meta;
};
e la formazione della query, in particolare alla funzione _buildSearchParams va aggiunto questa istruzione di if:
// Pagination in use?
if (this.options.usePagination)
{
obj.page = this.widgets.paginator.getCurrentPage() || this.currentPage;
obj.pageSize = this.widgets.paginator.getRowsPerPage();
}
Invece per quanto riguarda il file data.post.json.js che si trova in alfresco (lato server) le modifiche servono a gestire i nuovi parametri page e pageSize settati nel file datagrid-min.js.
Questo codice va aggiunto subito dopo l'esecuzione della query.
var pageSize, pagePos;
if (json.has("size")) {
pageSize = json.get("size");
}
else {
pageSize = allNodes.length;
}
if (json.has("pos")) {
pagePos = json.get("pos");
}
else {
pagePos = "1";
}
var nodes = [],
startIndex = (pagePos - 1) * pageSize;
nodes = allNodes.slice(startIndex, pagePos * pageSize);
for each (node in nodes)
{
try
{
items.push(Evaluator.run(node, fields));
}
catch(e) {}
}
}
Fatte queste modifiche le datalist saranno molto più performanti e veloci!!!
Beefly Protocol - il Protocollo Informatico a norma CNIPA per Alfresco
QBR Engineering ha recentemente rilasciato Beefly Protocol, la soluzione per la gestione del Protocollo Informatico basata sulla piattaforma ECM Open Source Alfresco e pienamente integrata nella propria suite di gestione documentale Beefly.
L'obiettivo principale che ci siamo posti all'avvio del progetto è stato quello di realizzare un software per la gestione del Protocollo Informatico che rispondesse ai seguenti requisiti:
Il risultato ottenuto è stata la realizzazione di un nuovo modulo applicativo nella suite Beefly denominato Beefly Protocol. Tale modulo applicativo, una volta installato sulla piattaforma Beefly (o direttamente su Alfresco Share) permette di usufruire di un sistema di gestione del protocollo informatico che risponde pienamente alle disposizioni sul protocollo informatico emanate dal DigitPA per la Pubblica Amministrazione Centrale e Locale.
L'adozione di Beefly Protocol permette all'Ente di usufruire, oltre che delle cosiddette funzionalità minime o "nucleo minimo" per la gestione informatica dei documenti, anche di tutte le funzionalità aggiuntive necessarie alla gestione dei flussi documentali, alla conservazione e all'accessibilità dei documenti archiviati.
Come è evidente dal diagramma precedente, Beefly Protocol, posizionandosi al livello più elevato della piramide documentale, è in grado di usufruire delle funzionalità di gestione documentale e workflow management erogate dalle piattaforme sottostanti.
Il DigitPA infatti classifica le applicazioni di protocollo informatico in tre macro livelli realizzativi (scenari) di complessità crescente:
1. Modalità base del protocollo informatico - Nucleo minimo di protocollo
2. Gestione informatica dei documenti e notifica
3. Flussi documentali - Esecuzione dei workflow
Il software che abbiamo sviluppato permette all'Ente di implementare la gestione del protocollo informatico che soddisfa tutti e tre i livelli necessari per usufruire della piena integrazione delle funzioni di Protocollo con le funzioni ECM necesarie all'erogazione dei servizi documentali.
1. Nucleo minimo di protocollo (rif. Testo unico DPR 445/2000 e s.m.i): Beefly Protocol fornisce le funzionalità di registrazione dei documenti in ingresso, in uscita e interni, oltre che la classificazione, la fascicolazione e l'archiviazione degli stessi all'interno del titolario di classificazione adottato dall'Ente.
2. Gestione Documentale: Beefly Protocol, avvalendosi, oltre che della piattaforma Alfresco anche delle funzionalità aggiuntive fornite dalla piattaforma Beefly, offre una serie di funzionalità aggiuntive fra cui, la dematerializzazione dei documenti cartacei, anche massiva, l'archiviazione delle email provenienti dalle caselle di posta certificata dell'ente, la firma digitale e marcatura temporale dei documenti elettronici, l'integrazione con lo Spooler di stampa etc.
3. Flussi documentali: Beefly Protocol supporta le funzionalità di notifica delle registrazioni di protocollo sulla scrivania di lavoro e sull'email dell'utente. Grazie alla forte integrazione fra il software di protocollo e Beefly (o Alfresco Share) l'utente riceve sulla propria Dashboard o sulla propria email la notifica di nuove assegnazioni di protocollo.
Funzionalità di Beefly Protocol
Beefly Protocol è dotato delle seguenti caratteristiche principali:
Le funzionalità in dettaglio di Beefly Protocol sono riportate qui.
Caratteristiche Tecniche
Beefly Protocol si basa sulla piattaforma Open Source di Alfresco Share di cui eredita le funzionalità di social collaboration, gestione documentale ed esecuzione dei workflow personalizzati, nonché di integrazione con Microsoft Office.
Il modulo espone un insieme di RESTful Web Service API che gli permettono di comunicare con le funzionalità del repository documentale di Alfresco (json) e con eventuali applicazioni esterne. I dati vengono scambiati utilizzando formati standard, quali JSON, Atom/RSS etc. (vedi fig. seguente).
Il modulo di protocollo è costituito da due componenti (vedi fig. seguente):
Scarica la presentazione completa del prodotto Beefly Protocol da questo link.
L'obiettivo principale che ci siamo posti all'avvio del progetto è stato quello di realizzare un software per la gestione del Protocollo Informatico che rispondesse ai seguenti requisiti:
- Completa conformità alla normativa CNIPA (ora DIGITPA)
- Installabile sulla piattaforma documentale Alfresco
- Multi Organizzazione, in modo da consentire, con un'unica installazione del prodotto, la creazione di molteplici sistemi di protocollo all'interno di un Ente della P.A. (ad esempio diversi protocolli per differenti A.O.O.)
- Integrabile con gli altri sistemi informatici adottati dall'Ente (es. sistemi di Enterprise Content Mangement, Business Process Management, Portali Internet etc.)
Il risultato ottenuto è stata la realizzazione di un nuovo modulo applicativo nella suite Beefly denominato Beefly Protocol. Tale modulo applicativo, una volta installato sulla piattaforma Beefly (o direttamente su Alfresco Share) permette di usufruire di un sistema di gestione del protocollo informatico che risponde pienamente alle disposizioni sul protocollo informatico emanate dal DigitPA per la Pubblica Amministrazione Centrale e Locale.
L'adozione di Beefly Protocol permette all'Ente di usufruire, oltre che delle cosiddette funzionalità minime o "nucleo minimo" per la gestione informatica dei documenti, anche di tutte le funzionalità aggiuntive necessarie alla gestione dei flussi documentali, alla conservazione e all'accessibilità dei documenti archiviati.
Come è evidente dal diagramma precedente, Beefly Protocol, posizionandosi al livello più elevato della piramide documentale, è in grado di usufruire delle funzionalità di gestione documentale e workflow management erogate dalle piattaforme sottostanti.
Il DigitPA infatti classifica le applicazioni di protocollo informatico in tre macro livelli realizzativi (scenari) di complessità crescente:
1. Modalità base del protocollo informatico - Nucleo minimo di protocollo
2. Gestione informatica dei documenti e notifica
3. Flussi documentali - Esecuzione dei workflow
Il software che abbiamo sviluppato permette all'Ente di implementare la gestione del protocollo informatico che soddisfa tutti e tre i livelli necessari per usufruire della piena integrazione delle funzioni di Protocollo con le funzioni ECM necesarie all'erogazione dei servizi documentali.
1. Nucleo minimo di protocollo (rif. Testo unico DPR 445/2000 e s.m.i): Beefly Protocol fornisce le funzionalità di registrazione dei documenti in ingresso, in uscita e interni, oltre che la classificazione, la fascicolazione e l'archiviazione degli stessi all'interno del titolario di classificazione adottato dall'Ente.
2. Gestione Documentale: Beefly Protocol, avvalendosi, oltre che della piattaforma Alfresco anche delle funzionalità aggiuntive fornite dalla piattaforma Beefly, offre una serie di funzionalità aggiuntive fra cui, la dematerializzazione dei documenti cartacei, anche massiva, l'archiviazione delle email provenienti dalle caselle di posta certificata dell'ente, la firma digitale e marcatura temporale dei documenti elettronici, l'integrazione con lo Spooler di stampa etc.
3. Flussi documentali: Beefly Protocol supporta le funzionalità di notifica delle registrazioni di protocollo sulla scrivania di lavoro e sull'email dell'utente. Grazie alla forte integrazione fra il software di protocollo e Beefly (o Alfresco Share) l'utente riceve sulla propria Dashboard o sulla propria email la notifica di nuove assegnazioni di protocollo.
Funzionalità di Beefly Protocol
Beefly Protocol è dotato delle seguenti caratteristiche principali:
- Archiviazione e registrazione di protocollo dei documenti rispondente alla normativa CNIPA con la possibilità di registrare un documento, classificarlo all'interno del titolario di classificazione adottato dall'Ente e assegnarlo ad un Ufficio (UOR) o al responsabile del procedimento (RPA).
- Scansione dei documenti da scanner direttamente dall'applicativo (Remote Scanning).
- Gestione del Titolario di classificazione dell'Ente con la possibilità di creare
tipologie di fascicoli elettronici e documenti personalizzati (Fascicoli estesi e Documenti estesi). Possibilità di chiudere un fascicolo relativo ad un procedimento terminato. - Gestione con un sistema di Access Control List (ACL) dei criteri di accesso ad un documento o ad un Fascicolo.
- Gestione del flusso di lavoro con l'assegnazione dei documenti protocollati agli uffici (UOR) o direttamente ai responsabili del procedimento amministrativo (RPA).
- Possibilità di notificare per conoscenza i documenti protocollati ad Uffici e singoli Responsabili.
- Possibilità di creare più sistemi di protocollo in base alle Aree Organizzative Omogenee (AOO) presenti nell'Ente o in base alle funzioni individuate nell'organizzazione aziendale (es. Organigramma, divisioni aziendali, più aziende appartenenti allo stesso gruppo etc.).
- Apposizione da parte dell'utente, tramite la propria SmartCard, della Firma digitale a norma direttamente ai documenti archiviati sul gestore documentale Beefly.
- Archiviazione automatica e protocollazione sul gestore documentale delle email scaricate dagli account email istituzionali, anche da account di Posta Elettronica (PEC).
- Funzionalità di Audit che permette di tracciare tramite log tutte le attività effettuate dagli utenti sul sistema.
- Cloud Compliat. Pieno supporto al modello di distribuzione dell'applicativo in modalità Software as a Service (SaaS).
Le funzionalità in dettaglio di Beefly Protocol sono riportate qui.
Caratteristiche Tecniche
Beefly Protocol si basa sulla piattaforma Open Source di Alfresco Share di cui eredita le funzionalità di social collaboration, gestione documentale ed esecuzione dei workflow personalizzati, nonché di integrazione con Microsoft Office.
Il modulo espone un insieme di RESTful Web Service API che gli permettono di comunicare con le funzionalità del repository documentale di Alfresco (json) e con eventuali applicazioni esterne. I dati vengono scambiati utilizzando formati standard, quali JSON, Atom/RSS etc. (vedi fig. seguente).
Il modulo di protocollo è costituito da due componenti (vedi fig. seguente):
- Cnipa Protocol Share: Presentation layer – E' stato implementato un nuovo tipo di site (custom site) in Alfresco Share.
- Cnipa Protocol Alfresco: Business Layer - Logica di back-end del modulo di protocollo.
Scarica la presentazione completa del prodotto Beefly Protocol da questo link.
giovedì 12 maggio 2011
Hadoop HBase
HBase è un database distribuito column-oriented, scritto in Java, la cui progettazione è stata fortemente influenzata da Google BigTable e che fa uso del filesystem HDFS per la persistenza delle informazioni.
HBase è l'applicazione di Hadoop da utilizzare quando si richiede accesso real-time (read/write) ai dati in modalità random-access per una grande quantità di dati (diversamente da MapReduce che è batch-oriented).
Esso permette di archiviare una grande quantità di dati offrendo un architettura, fault-tolerant, orientata alla scalabilità attraverso l'aggiunta di nodi commodity al cluster e l'integrazione nativa con MapReduce e HDFS. Fornisce anche l'accesso alle risorse attraverso delle semplici API REST e la possibilità di operare in memoria per aumentare le performance.
Per quanto riguarda il data model, le applicazioni che utilizzano HBase, archiviano le informazioni in tabelle composte da righe e colonne, le cui intersezioni (le celle) sono versionate e possono contenere contenuti di vario genere in quanto formalmente sono considerate un array di byte. Di default il numero di versione è un timestamp auto generato da HBase in fase di inserimento della cella. Anche le chiavi (key) delle righe sono un'array di byte e teoricamente possono contenere qualsiasi cosa: da stringhe a dati binari. Le righe nelle tabelle vengono ordinate attraverso la row key e è quest'ultima che permette di accedere alle informazioni contenute nella riga attraverso le opportune query. Le colonne invece vengono raggruppate in column families e possono essere aggiunte a run-time(specificando la column family attraverso un prefisso). Fisicamente tutte le colonne di una column family vengono archiviate insieme nel filesystem.
Oltre al concetto di column, table e row, HBase utilizza anche le region. Infatti, le tabelle in HBase vendono automaticamente partizionate orizzontalmente in regions che vengono distribuite nel cluster. Ogni region comprende un sotto-insieme di righe di una tabella e in questo modo una tabella che è troppo grande per essere contenuta in un server può essere distribuita in diversi server del cluster.
Inoltre in HBase gli aggiornamenti sulle righe sono atomici, indipendentemente dal numero di colonne che costituiscono la riga.
Per quanti riguarda i dettagli implementativi, in HBase esiste un nodo master che gestisce il cluster composto da uno o più regionserver slave (fig. 11). Il nodo master è responsabile di inizializzare il cluster, di assegnare region ai regionserver registrati nel cluster e di sopperire alle failure dei regionserver. Come abbiamo detto i regionserver gestiscono uno o più region e forniscono le funzionalità di read/write. Gestiscono anche i dati (split) inviati dal nodo master contenenti informazioni riguardo i nuovi nodi del cluster.
HBase usa il file system di Hadoop HDFS per la persistenza dei dati anche se si possono usare altre implementazioni quali : local filesystem, Amazon S3, KFS filesystem e altri.
Quando una richiesta di scrittura arriva ad una regionserver (fig. 12), questa viene prima appesa al commit log e poi aggiunta alla cache in memoria. Quando la cache è piena, il suo contenuto viene scritto su filesystem. Il commit log è archiviato su HDFS, in modo da renderlo disponibile anche in presenza di un regionserver crash. In fase di lettura, viene in primo luogo consultata la cache in memoria della region, se viene trovata un'occorrenza questa viene ritornata, altrimenti viene avviata una fase di ricerca nel file archiviato su filesystem alla ricerca del record partendo dai dati che hanno un numero di versionamento più recente.
HBase è l'applicazione di Hadoop da utilizzare quando si richiede accesso real-time (read/write) ai dati in modalità random-access per una grande quantità di dati (diversamente da MapReduce che è batch-oriented).
Esso permette di archiviare una grande quantità di dati offrendo un architettura, fault-tolerant, orientata alla scalabilità attraverso l'aggiunta di nodi commodity al cluster e l'integrazione nativa con MapReduce e HDFS. Fornisce anche l'accesso alle risorse attraverso delle semplici API REST e la possibilità di operare in memoria per aumentare le performance.
Per quanto riguarda il data model, le applicazioni che utilizzano HBase, archiviano le informazioni in tabelle composte da righe e colonne, le cui intersezioni (le celle) sono versionate e possono contenere contenuti di vario genere in quanto formalmente sono considerate un array di byte. Di default il numero di versione è un timestamp auto generato da HBase in fase di inserimento della cella. Anche le chiavi (key) delle righe sono un'array di byte e teoricamente possono contenere qualsiasi cosa: da stringhe a dati binari. Le righe nelle tabelle vengono ordinate attraverso la row key e è quest'ultima che permette di accedere alle informazioni contenute nella riga attraverso le opportune query. Le colonne invece vengono raggruppate in column families e possono essere aggiunte a run-time(specificando la column family attraverso un prefisso). Fisicamente tutte le colonne di una column family vengono archiviate insieme nel filesystem.
Oltre al concetto di column, table e row, HBase utilizza anche le region. Infatti, le tabelle in HBase vendono automaticamente partizionate orizzontalmente in regions che vengono distribuite nel cluster. Ogni region comprende un sotto-insieme di righe di una tabella e in questo modo una tabella che è troppo grande per essere contenuta in un server può essere distribuita in diversi server del cluster.
Inoltre in HBase gli aggiornamenti sulle righe sono atomici, indipendentemente dal numero di colonne che costituiscono la riga.
Per quanti riguarda i dettagli implementativi, in HBase esiste un nodo master che gestisce il cluster composto da uno o più regionserver slave (fig. 11). Il nodo master è responsabile di inizializzare il cluster, di assegnare region ai regionserver registrati nel cluster e di sopperire alle failure dei regionserver. Come abbiamo detto i regionserver gestiscono uno o più region e forniscono le funzionalità di read/write. Gestiscono anche i dati (split) inviati dal nodo master contenenti informazioni riguardo i nuovi nodi del cluster.
HBase usa il file system di Hadoop HDFS per la persistenza dei dati anche se si possono usare altre implementazioni quali : local filesystem, Amazon S3, KFS filesystem e altri.
Quando una richiesta di scrittura arriva ad una regionserver (fig. 12), questa viene prima appesa al commit log e poi aggiunta alla cache in memoria. Quando la cache è piena, il suo contenuto viene scritto su filesystem. Il commit log è archiviato su HDFS, in modo da renderlo disponibile anche in presenza di un regionserver crash. In fase di lettura, viene in primo luogo consultata la cache in memoria della region, se viene trovata un'occorrenza questa viene ritornata, altrimenti viene avviata una fase di ricerca nel file archiviato su filesystem alla ricerca del record partendo dai dati che hanno un numero di versionamento più recente.
Iscriviti a:
Post (Atom)