Best practices per personalizzazione/sviluppo

[nidroide]

Salve a tutti,

dopo aver utilizzato alfresco per quasi un anno nella sua forma "base" per la gestione documentale (con l'aggiunta di tipi ed aspetti custom) vorremo iniziare a personalizzarlo e strutturarlo in modo da semplificarne l'utilizzo. Attualmente gli utenti operano direttamente con le funzionalità esposte da share, quindi creano cartelle, caricano files, ne cambiano il tipo, aggiungono gli aspetti, modificano le proprietà etc.
Quello che vorremmo ottenere è un'insieme di pagine/form personalizzate e strutturate in un menu in modo da simulare una classica web app (inserisci documento di tipo xxx, ricerca documento di tipo xxx, etc.), le form customizzate e le relative action dovrebbero curare in automatico il change type e l'aggiunta di aspetti, l'avvio di workflow, la gestione di campi che derivano dalla profilatura dell'utente (ad esempio combobox che fa scegliere un'ufficio tra quelli presenti in organigramma di pertinenza dell'utente, combobox per la scelta del responsabile etc.). All'utente, inoltre, bisognerebbe nascondere/inibire gli strumenti di share per poter manipolare la base documentale senza controllo.

Allo stesso tempo vorremmo poter gestire in futuro altri aspetti applicativi più o meno legati al documento in se, ad esempio l'assegnazione di un progressivo numerico automatico (a mo' di protocollo), gestire tabelle di database ai cui record sono allacciati documenti e cartelle, produrre report, effettuare calcoli di varia natura sui metadati, etc.

Mi sapete dunque dare qualche consiglio su come procedere possibilmente usando strumenti di alto livello (evitando di sviluppare in java)? per il momento stiamo sperimentando i web script per la generazione di form e l'upload di documenti, ma la presentazione non è integrata con share, come procedere?

Approfitto con l'occasione anche per affrontare un tema a carattere più generale, ho notato che un diverso approccio per lo sviluppo di applicazioni, ove la gestione del documento è più o meno centrale, consiste nell'utilizzare alfresco (o un qualsiasi altro documentale) solo come "contenitore puro" e sviluppare applicativi esterni indipendenti (che interrogano il documentale via cmis) per la gestione dei metadati (in un proprio db) e per l'implementazione della logica applicativa. Questo approccio evidenzia pro e contro di varia natura (evitando tra l'altro di customizzare un sistema già di per se molto complesso) ma di sicuro tende a frammentare la gestione dei metadati, complicando l'integrazione in uno scenario dove più applicazioni collaborano per la gestione di processi di una certa complessità.
Una possibile soluzione potrebbe consistere nel gestire i metadati di carattere generale nel documentale e quelli di pertinenza specifica negli applicativi esterni ma non risolve del tutto il problema.

In base alla vostra esperienza quale è il modo migliore di procedere?

grazie

   Nico

[openpj]

Se devi creare una gestione di contenuti diversa da Alfresco Share ti suggerisco di utilizzare Alfresco come un ECM puro e di crearti una webapp esterna custom che effettui chiamate ai WebScript di Alfresco relativi al tuo dominio di interesse. In realtà è tipicamente questo l'utilizzo di un repository come Alfresco

I Web Script che dovrai sviluppare sono Data Web Scripts ovvero metodi REST che ritornano un formato di output di tipo JSON, XML, CSV o altri.
La risposta dei Web Script dovrà essere poi processata dalla tua webapp custom che poi presenterà i contenuti agli utenti.

Utilizzando Web Script puoi incapsulare atomicamente diverse operazioni di Alfresco in un unica chiamata HTTP.

Se invece non hai problemi di atomicità delle operazioni potresti pensare di utilizzare il protocollo CMIS per interfacciarti ad Alfresco, oramai ci sono diverse implementazioni di CMIS (Java, PHP, .NET, Objective C, Python e JavaScript).

Sia utilizzando Web Scripts che CMIS puoi sviluppare la tua webapp con qualsiasi tecnologia da PHP a .NET

Spero ti sia utile.

[nidroide]

Ciao Pierluigi e grazie per la pronta risposta. Il problema me lo sono posto quando un nostro partner ci ha proposto una soluzione di gestione "pratiche" ove i documenti risiedono in alfresco, i metadati sono in Oracle ed il tutto è gestito da un'applicazione esterna. Quando ho chiesto come poter "pubblicare" sul sito aziendale alcuni documenti in modo contestualizzato e filtrato mi è stato detto che dovevo interfacciarmi sia con alfresco che con Oracle.

Questa "prassi" mi ha lasciato un pò perplesso in quanto in futuro potrei avere N altre applicazioni che potrebbero dover interagire con questi documenti e mi ritroverei a dover ereditare sempre la doppia interrogazione, aumentando enormemente, tra l'altro, la complessità della manutenzione. Se il partner, infatti, modificasse lo schema dei metadati sarei costretto a riaggiornare tutte le N applicazioni.

Personalmente, invece, mi ero convinto (più o meno in accordo con la tua risposta) che i metadati che hanno la loro connotazione naturale assieme al documento dovessero risiedere in alfresco, mentre quelli specifici dell'elaborazione nell'applicazione esterna.

Faccio un esempio che magari mi aiuta ad esporre meglio il problema. Supponiamo dunque di dover trattare un'applicazione document-centric, ad esempio per la scrittura, firma digitale, archiviazione e pubblicazione su web di atti amministrativi. In questo caso immagino di creare un custom model e/o aspects per associare al "pdf" dei metadati come l'autore, l'ufficio di competenza, il responsabile, la data di emissione, il progressivo dell'atto e così via.
Un app esterna gestisce la scrittura collaborativa e l'apposizione della firma digitale, l'interrogazione/integrazione con il sistema di gestione contabile, il flusso, etc. quando il documento è "finito" e firmato lo carico in alfresco associandovi i metadati (e qui viene in aiuto il webscript che mi garantisce atomicità, associazione tipo/aspetti, presenza dei metadati minimi, etc.). Ora posso facilmente scrivere un plugin per il mio cms che interroga alfresco (magari tramite un'altro webscript) *senza* dover interfacciarmi con l'applicazione di gestione e/o il database oracle.

Il partner dal canto suo mi spiegava che la loro scelta progettuale nasceva dalla complessità di gestione dei metadati in alfresco. In pratica mi riferivano che modificare una proprietà di un custom model spesso comportava dei grossi problemi. Se ad esempio una proprietà era ad esempio "nome ufficio" e dopo aver caricato i documenti si voleva trasformare la stessa in un'associazione ad un'elenco di nodi "ufficio" bisognava cancellare tutti i documenti e ricominciare daccapo. A prescindere dalla correttezza di quanto affermato, la cosa era vista come molto macchinosa soprattutto in riferimento ad una evoluzione del modello dei dati molto dinamica.

Come orientarsi dunque?

Poichè alfresco consente anche altre funzionalità, quali gestione del workflow, degli utenti, dei permessi, perchè non sfruttarlo anche per questi aspetti? anche qui il partner mi diceva che più "si mette mano" ad alfresco e più il sistema rischia di divenire poco stabile/manutenibile.

Infine, tornando anche al topic principale, vorrei comunque provare a scrivere qualche form/data web script per caricamento/reperimento dei documenti, per allargare l'utilizzo di alfresco anche ad utenti informaticamente poco skillati. Trattandosi di cose semplici, scrivere una webapps apposita mi sembra attualmente esagerato, ho visto che si possono scrivere facilmente dei presentation web script, ma non sono integrati in share. Volendo dunque realizzare la presentazione in share senza utilizzare java come mi consigliate di procedere?

grazie

    Nico

[openpj]

<blockquote>
Ciao Pierluigi e grazie per la pronta risposta. Il problema me lo sono posto quando un nostro partner ci ha proposto una soluzione di gestione "pratiche" ove i documenti risiedono in alfresco, i metadati sono in Oracle ed il tutto è gestito da un'applicazione esterna. Quando ho chiesto come poter "pubblicare" sul sito aziendale alcuni documenti in modo contestualizzato e filtrato mi è stato detto che dovevo interfacciarmi sia con alfresco che con Oracle.
</blockquote>
Mi dispiace dirlo ma credo che questo partner non abbia ben chiaro che cosa sia Alfresco e come si possa utilizzare a 360 gradi. Alfresco tipicamente viene utilizzato proprio per fare in modo di persistere tutte le informazioni necessarie al dominio di interesse. Questo facilita di parecchio le logiche dell'applicazione esterna che tipicamente dovrà semplicemente invocare metodi REST sul repository (Web Scripts o CMIS).

<blockquote>
Il partner dal canto suo mi spiegava che la loro scelta progettuale nasceva dalla complessità di gestione dei metadati in alfresco. In pratica mi riferivano che modificare una proprietà di un custom model spesso comportava dei grossi problemi. Se ad esempio una proprietà era ad esempio "nome ufficio" e dopo aver caricato i documenti si voleva trasformare la stessa in un'associazione ad un'elenco di nodi "ufficio" bisognava cancellare tutti i documenti e ricominciare daccapo.
</blockquote>
Vero, ma è per questo che il modello Alfresco deve essere progettato bene anche per prevedere questi dinamismi.
Evidentemente c'è una carenza di analisi del content model in questo contesto.
La dinamicità del modello la si può dare attraverso la definizione degli aspetti (aspect).
Definendo ogni singola proprietà come un aspetto si può rendere il modello super dinamico senza necessità di dover eliminare i contenuti per poter ripristinare il modello.

<blockquote>
Poichè alfresco consente anche altre funzionalità, quali gestione del workflow, degli utenti, dei permessi, perchè non sfruttarlo anche per questi aspetti? anche qui il partner mi diceva che più "si mette mano" ad alfresco e più il sistema rischia di divenire poco stabile/manutenibile.
</blockquote>
Falso, Alfresco può essere utilizzato pienamente con tutti i suoi componenti in modo ottimale. Certo è che se chi implementa le estensioni, non conosce bene l'API di Alfresco, allora si che può rendere la piattaforma instabile. Dipende dalle competenze e dall'esperienza pregressa che si ha su questo sistema ECM, evidentemente questo partner non ha mai implementato progetti di importante rilevanza.