topic Re: Best practices per personalizzazione/sviluppo in Alfresco Archive

Best practices per personalizzazione/sviluppo

nidroide — Mon, 17 Nov 2014 10:31:13 GMT

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 funzio

Re: Best practices per personalizzazione/sviluppo

openpj — Mon, 17 Nov 2014 10:38:56 GMT

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.

Re: Best practices per personalizzazione/sviluppo

nidroide — Tue, 18 Nov 2014 09:57:59 GMT

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

Re: Best practices per personalizzazione/sviluppo

openpj — Tue, 18 Nov 2014 16:08:56 GMT

<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.