Per la gestione e l’utilizzo dei contenuti (file, immagini, documenti) all’interno di un’organizzazione, le Content Services Platform sono componenti fondamentali.
Queste piattaforme consentono ai dipendenti di accedere e lavorare con i contenuti in modo moderno su diversi dispositivi, e sono quindi un elemento chiave della strategia per il posto di lavoro digitale di qualsiasi organizzazione.
Tra le piattaforme che consentono di creare e gestire esperienze utente personalizzate su siti web o applicazioni c’è anche Adobe Experience Manager (AEM). AEM può essere considerata anche una valida piattaforma di Enterprise Content Management?
Cosa sono le content service platform
Gartner, società che fornisce analisi indipendenti dei prodotti e del mercato, non usa più il termine Enterprise Content Management, ma invece utilizza il termine CSP, ossia, appunto, Content Services Platform.
Adobe AEM, tuttavia, non è considerato un leader nel mondo CSP, ma è un leader riconosciuto, proprio da Gartner, nel “Component Content Management System” (CCMS). I CCMS gestiscono i contenuti a livello di singoli componenti, come testo e immagini, anziché intere pagine o documenti HTML. Un CCMS offre un maggiore controllo sui singoli componenti dei contenuti rispetto a un CSP, che gestisce il contenuto a livello di documento intero. In questo articolo viene descritto un progetto di migrazione da una piattaforma di gestione dei contenuti basato su Opentext Documentum verso una nuova applicazione realizzata a partire da Apache Sling, il framework open source alla base di Adobe AEM. Questo non è un confronto tra la piattaforme Documentum e Apache Sling, quanto una descrizione di come Apache Sling siano stati utilizzati per soddisfare le esigenze specifiche di questo progetto.
Apache Sling come Content Service Platform
Il cliente per il quale è stato completato questo progetto è un’azienda che progetta, sviluppa, produce e integra lanciatori spaziali con sede in provincia di Roma. L’azienda offre soluzioni competitive per il lancio di carichi utili governativi e commerciali, nell’orbita terrestre. Come esperto di content management ho collaborato nella realizzazione e gestione di due applicazioni basate sulla piattaforma Documentum: una utilizzata per la gestione della documentazione tecnica e un’altra per la gestione del protocollo informatico.
Il cliente ha recentemente deciso di cambiare la propria architettura applicativa e di abbandonare la piattaforma Opentext Documentum ritenuta non più strategica. L’applicazione per la gestione del protocollo informatico è utilizzata da circa 150 utenti per gestire cinquantamila documenti, tutti con lo stesso set di metadati. L’obiettivo è quello di sviluppare una nuova applicazione basata su prodotti open-source e standard, come Apache Felix, Apache Jackrabbit OAK e Apache Sling, che sia facile da installare e gestire, offra le stesse funzionalità del repository Opentext Documentum e possa essere integrata con Active Directory. Inoltre, la soluzione deve essere in grado di proteggere i documenti del repository con regole di sicurezza granulari, come quelle offerte da Documentum. Ho perciò proposto l’utilizzo di Apache Sling come Content Service Platform come base per la nuova applicazione.
L’architettura del sistema è composta da un’unica istanza di Apache Sling 12 installata su un server virtuale. L’installazione di un’istanza Apache Sling è molto semplice e richiede solo pochi minuti: è sufficiente un Java Developer Kit supportato e lanciare l’esecuzione di un Jar file. In confronto, l’installazione di un’istanza di Opentext Documentum o Microsoft SharePoint può essere più complessa e richiedere diverse ore o addirittura giorni. Apache Sling offre tutte le funzionalità principali offerte da un’installazione di base di Documentum, come l’autenticazione, l’autorizzazione, la gestione dei metadati, l’indicizzazione full-text, le transazioni, il versioning. Inoltre, rispetto a Documentum, Apache Sling richiede meno risorse (meno Ram, meno Cpu). Per questi motivi, il TCO di un’istanza Adobe AEM o Apache Sling è molto inferiore rispetto a un sistema basato su Documentum. ù
Il database di oggetti Apache Jackrabbit OAK
Adobe Experience Manager (AEM) e Apache Sling utilizzano il database di oggetti Apache Jackrabbit OAK. Ogni dato in questo database è modellato come un oggetto o nodo nella terminologia di Jackrabbit. Gli oggetti sono istanze di classi e sono organizzati in un albero a partire da un nodo radice “/”. E’ possibile estendere il modello dati creando delle classi personalizzate. Adobe ha, per esempio, esteso il modello di dati di Apache Jackrabbit per utilizzarlo in AEM, aggiungendo nuove classi come cq:Page e cq:PageContent per modellare le pagine di un sito web.
Una caratteristica interessante è che Apache Jackrabbit è un database schema-full ma espone alcune classi, che possono essere schema-less. Ad esmpio, per la classe nt:unstructured, gli sviluppatori possono aggiungere informazioni in nuovi attributi non definiti in precedenza. Gli architetti o gli sviluppatori di Adobe AEM di solito non estendono il modello di dati, poiché spesso non ne hanno bisogno.
Per l’applicazione Protocollo Informatico abbiamo definito solo due nuovi tipi di nodo:
- pi:sequence, per definire il contatore e i parametri di ogni registro di protocollo;
- pi:registration, per memorizzare tutte le registrazioni di protocollo e catturare le informazioni più importanti di ogni documento ricevuto o inviato dal cliente
Entrambe le classi personalizzate sono sotto-classi della classe nt:unstructured, quindi lo sviluppatore può aggiungere tutti gli attributi di cui ha bisogno, senza chiedere a un architetto di dati di definire, modificare, ottimizzare il modello di dati personalizzato. Quando necessario, lo sviluppatore può memorizzare nuovi dati in nuovi attributi di pi:sequence o pi:registration, in modo molto simile a quanto fa uno sviluppatore Java quando aggiunge, rimuove o modifica gli attributi di una classe. Certamente, la libertà di lavorare con classi senza schema può generare problemi: la governance è sempre necessaria per evitare il caos, ma per esperienza uno sviluppatore esperto può gestire molto bene questa potente funzionalità.
Apache Jackrabbit OAK e Adobe AEM offrono due opzioni principali per il livello di persistenza dei dati: TarMK e MongoMK. TarMK è il metodo di persistenza standard ed è progettato per garantire un alto throughput sia in lettura che in scrittura senza dipendenze esterne. MongoMK, invece, utilizza il database MongoDB e viene utilizzato per implementare un’alta disponibilità dell’applicazione in modalità High Availability Active/Active o per gestire repository molto grandi sfruttando la scalabilità orizzontale tipica di MongoDB. Per il nostro cliente abbiamo scelto l’opzione TarMK: quest’opzione è interessante poiché sia i metadati che i file sono memorizzati in uno stesso archivio a basso livello e sono quindi sempre coerenti. Il backup e il ripristino con TarMK sono facili da gestire con qualsiasi strumento di backup basato su file senza la necessità di procedure o strumenti speciali, a differenza di quanto accade con Documentum, dove i metadati e i file sono gestiti da due componenti separati. Inoltre il backup a caldo non richiede particolari modalità: è sufficiente archiviare i file in uso, senza la necessità di procedure o attenzioni particolari. Anche quest’opzione concorre nella riduzione del TCO della soluzione proposta.
L’applicazione front-end
L’applicazione front-end del nuovo protocollo informatico è sviluppata con Angular 12, Angular Material e Bootstrap ed è una moderna single page application reattiva e facile da usare. I costi di implementazione del front-end sono gli stessi indipendentemente dall’implementazione del repository scelto, sia che si tratti di Opentext Documentum o di Adobe AEM/Apache Sling. Nel nostro caso, l’applicazione personalizzata utilizza i servizi esposti tramite i servlet GET e POST standard di Apache Sling e i servizi Rest personalizzati.
Il business logic layer del nuovo protocollo informatico è stato implementato come un unico bundle OSGI con servlet Sling e servizi Rest personalizzati. Un vantaggio importante è che non c’è alcun vendor lock-in, poiché tutte le competenze richieste provengono da progetti open source o framework open source come Apache Sling, Apache Jackrabbit OAK e Apache Felix. Ci sono migliaia di sviluppatori nel mondo, sicuramente qualche migliaio in Italia, in grado di lavorare con queste tecnologie, a differenza di Documentum, che non è basato su standard e per il quale può essere molto più difficile trovare sviluppatori o system integrator con le competenze appropriate per lavorare con questa piattaforma.
Apache Sling e Adobe AEM sono basati su OSGI, uno standard che permette di apportare modifiche anche sostanziali alla logica di back-end senza richiedere il riavvio dell’applicazione. Ciò spesso non è possibile per applicazioni Documentum, dove alcune modifiche di configurazione, come la modifica anche di una semplice etichetta di un’applicazione web, possono richiedere il riavvio dell’application server.
L’applicazione che abbiamo rilasciato è accessibile solo agli utenti autenticati e utilizza l’autenticazione standard di Apache Jackrabbit: questa permette di integrarsi facilmente con l’Active Directory aziendale. Il controllo delle autorizzazioni, ovvero la gestione di chi può leggere e modificare le informazioni, è stato demandato interamente a Apache Jackrabbit. Abbiamo aggiunto regole di sicurezza e le abbiamo applicate ai nodi più importanti del database. Documentum e Apache Jackrabbit sono molto simili per quanto riguarda il controllo delle autorizzazioni, entrambi possono essere molto granulari e definire regole specifiche per proteggere singoli oggetti. Tuttavia, Apache Jackrabbit rende la vita dell’amministratore del repository più semplice, poiché è sufficiente applicare una regola di protezione a un oggetto per proteggere, implicitamente, tutti gli oggetti che hanno quel nodo, direttamente o indirettamente, come genitore nella gerarchia: questo ha permesso di creare poche regole di sicurezza, applicate a pochissimi nodi e fare in modo che gli utenti dell’applicazione possono consultare e modificare i soli registri di protocollo sui quali sono abilitati.
La migrazione dei dati
La migrazione dei dati è una parte cruciale di qualsiasi progetto di rinnovamento tecnologico. Nel nostro caso questa operazione, seppure delicata, è stata relativamente semplice. Apache Sling espone infatti servizi REST per gestire gli oggetti del database, gli utenti, i gruppi e le autorizzazioni. Abbiamo quindi installato Documentum REST Services, un insieme di interfacce di servizi Web RESTful che interagiscono con la piattaforma Documentum. Con questi strumenti, siamo stati in grado di interagire con il repository Documentum e il Java Content Repository tramite i servizi REST, rendendo facile e veloce il trasferimento dei dati. Abbiamo creato cinque piccole applicazioni Python per spostare tutte le informazioni e le configurazioni necessarie, e Python e le sue numerose librerie hanno reso tutto molto semplice. Per rendere il codice Python più leggibile e facile da mantenere in futuro, abbiamo creato due servizi Apache Sling. Uno di questi servizi restituisce in formato Json tutti i percorsi dei nodi che soddisfano una specifica query SQL-2, il linguaggio di interrogazione di Apache Jackrabbit, mentre l’altro restituisce semplicemente il conteggio dei risultati di una query SQL-2, il che è importante per fare molte verifiche numeriche per confermare che il trasferimento dei dati sia stato eseguito correttamente. Il codice sorgente di entrambi i servizi è disponibile su GitHub nel repository pubblico artika4biz/sling-utils.
Dopo aver verificato che l’applicazione e i dati fossero corretti, il nostro cliente ha disattivato la vecchia applicazione di protocollo informatico. La nuova applicazione è molto più veloce della precedente, grazie a una struttura di front-end più moderna e aggiornata, pur rimanendo molto simile alla precedente applicazione. La resistenza al cambiamento degli utenti è stata facilmente vinta poiché l’applicazione è più efficiente ma senza grandi modifiche funzionali.
Abbiamo progettato la nuova applicazione di protocollo informatico in modo che possa essere facilmente importata in Adobe Experience Manager (AEM) in futuro, senza alcun costo aggiuntivo. AEM è basato su Apache Sling e offre una serie di potenti e complesse funzionalità, come AEM Sites, AEM Forms, AEM Assets, con un’interfaccia utente semplice da usare per gli autori di siti web o per gli utenti che gestiscono asset digitali.
A diversi mesi dal rilascio in produzione dell’applicazione, possiamo considerare una vittoria la scelta di utilizzare Apache Sling come un’alternativa a costose soluzioni di content management. Oggi proponiamo questa piattaforma open source per ogni nuova richiesta di gestione dei contenuti o migrazione dei dati da piattaforme di content management legacy. In questi giorni stiamo rilasciando una nuova applicazione completamente basata su Apache Sling 12 e che verrà utilizzata negli ospedali da medici e infermieri per catturare le informazioni strutturare e non strutturate e che emergono durante visite e controlli medici specialistici.
Utilizzare Apache Sling o Adobe Experience Manager (AEM) per implementare le applicazioni di gestione dei contenuti presenta molti vantaggi. Per i clienti già utilizzatori di AEM, disattivare le vecchie applicazioni e sostituirle con AEM può rappresentare un modo per modernizzare le loro applicazioni, ridurre i costi totali di proprietà (TCO) e le licenze. Infatti, i clienti AEM possono sfruttare gli investimenti fatti in AEM distribuendo i costi delle licenze su più applicazioni, utilizzando budget di aree funzionali diverse dal marketing, l’area che solitamente fornisce il budget per le implementazioni di experience management. Adobe AEM può quindi essere utilizzato per applicazioni interne, come il Protocollo Informatico, o per altre applicazioni richieste dalle risorse umane, dalla produzione e da altri dipartimenti azienadali.
Per gli integratori di sistema che propongono Apache Sling ai clienti che ancora non utilizzano AEM, offrire una tecnologia open source matura e potente rappresenta una buona opportunità di consulenza, ma c’è anche la possibilità di generare ulteriori entrate vendendo licenze AEM in seguito. Apache Sling può diventare un modo per i system integrator per proporre ai propri clienti l’acquisto di licenze AEM, poiché questi potrebbero essere interessati a ottenere il supporto enterprise di Apache Sling, essendo questo parte di AEM o per utilizzare le funzionalità extra offerte da AEM rispetto ad Apache Sling, come la gestione dei workflow, AEM Sites, AEM Forms.
Il progetto open source Apache Sling non sempre è facile da gestire a causa della quantità di codice e delle diverse versioni disponibili. Nella versione 12 di Apache Sling, non è fornito un file JAR che includa tutti i file binari per i bundle OSGI definiti all’interno del progetto. Nonostante questo aspetto modulare sia il punto di forza del progetto OSGI, può essere difficile districarsi tra i diversi bundle rilasciati. A un livello più basso, Apache Jackrabbit svolge un ottimo lavoro, ma non si può dire che sia un prodotto innovativo. Anche il fork Apache Jackrabbit OAK, che mira, riuscendoci, a fornire prestazioni ottimali, offre essenzialmente le stesse funzionalità di più di dieci anni fa. Apache Jackrabbit è l’implementazione di riferimento per gli standard Java JSR 170 e JSR 283: aderire a questi standard a volte significa dover rimanere sempre uguali a sé stessi. La visualizzazione gerarchica e ad albero della gestione dei contenuti è ormai superata e per la gestione delle informazioni è sempre più necessario utilizzare una visualizzazione basata su grafi. I graph database stanno guadagnando sempre più popolarità e sono convinto che un giorno tutti i sistemi di gestione dei contenuti più innovativi utilizzeranno questo tipo di database.
Il futuro di Adobe AEM come Content Services Platform
Adobe AEM è stato considerato come un leader nel campo dei Content Services Platform. Nel 2006, Gartner lo ha classificato come Visionary / Leader nella sua classifica Magic Quadrant. Tuttavia, nel 2012 Gartner lo ha rimosso dal Magic Quadrangt perché, come riportato da questa società, “Adobe ha spostato la sua attenzione sul Web Content Management. Non abbiamo visto Adobe sviluppare, promuovere o vendere in modo attivo una quantità sufficiente di altri componenti dell’ECM da giustificare la considerazione in questo Magic Quadrant”.
Anche se è vero che Adobe si è concentrata principalmente sulla crescente e redditizia area del marketing digitale, ciò non significa che AEM non possa essere considerato una valida CSP. Inoltre, Adobe ha a disposizione prodotti complementari come Adobe PDF Services, Adobe Sign, Adobe Document Cloud e Adobe Workfront, che aggiungono ulteriori funzionalità alla piattaforma AEM. In aggiunta, altri prodotti e servizi Adobe potrebbero aggiungere nuovo valore alle applicazioni basate su CSP: pensiamo ad Adobe Analytics; questa tecnologia può essere utilizzata non solo per comprendere meglio i comportamenti dei clienti quando acquistano un prodotto o un servizio in un sito web, ma anche per comprendere meglio i comportamenti dei dipendenti, perché anche i dipendenti meritano applicazioni migliori e servizi costantemente migliorate!
AEM è una CSP perfetta? No, non lo è. Adobe AEM avrebbe bisogno di uno strumento più moderno per gestire i tipi di nodo o avrebbe bisogno di alcune funzionalità che altri CSP offrono, come ad esempio il Document Lifecycle, una funzionalità storica e particolarmente utile offerta da Opentext Documentum. Se Adobe mirasse anche a vendere AEM come una Content Services Platform, guadagnerebbe una nuova e fiorente fonte di entrate, considerando che molti clienti stanno rivalutando gli investimenti effettuati sui CSP legacy. Chissà forse un giorno ci sarà una nuova applicazione, la chiamerei AEM Documents, in aggiunta alle attuali AEM Sites, AEM Forms e AEM Assets.
In conclusione, Adobe può svolgere un ruolo unico nello spazio dei CSP.
