Alfresco Day Roma 2015: Big Repository Implementation, Francesco Fornasari, Alfresco Engineer, TAI Software Solutions

1. Big Repository Implementation
Le sfide, le criticità e soprattutto i vantaggi/benefici

2. Francesco Fornasari
Alfresco Engineer - Alfresco Administrator

3. Lo Scenario

4. Caso d’uso
• Content Repository a supporto delle applicazioni di business
• Documenti gestiti di tipo fattura, protocollo e altri documenti aziendali
• Integrazione con sistemi terzi
• Ricerche sui contenuti
• Volumi documentali significativi
• Migrazione da ECM legacy
BigRepository

5. Volumi documentali
• Target: +500 milioni di documenti presenti nel sistema legacy
• Crescita: 120 milioni di documenti/anno
• Documenti migrati in Alfresco: 10 milioni
• L’architettura deve essere dimensionata di conseguenza a tutti i livelli per
affrontare al meglio il carico e la crescita del repository
BigRepository

6. Integrazione sistemi terzi
Applicazioni esistenti in essere dal cliente che necessitano dei servizi
documentali
• SAP
• EMC2 Centera o Atmos
• Hitachi HCP Content Platform
• Applicazioni custom
BigRepository

7. Migrazione da ECM legacy
• Analisi congiunta con il cliente
finale dello scenario dell’ECM da
dismettere
• Verifica e stima del numero dei
documenti da migrare
• Preparazione di un modello dati
specifico per Alfresco
• Preparazione e modellazione del
repository
• Integrazione con altre applicazioni
• Dimensionamento dell’architettura
finale
• Creazione/utilizzo di un tool
guidato di migrazione
• Analisi dei log e del
comportamento del sistema
durante la migrazione
• Verifica analitica dei contenuti
migrati
• Avvio in Produzione
BigRepository

8. Ricerche
• Possono rappresentare uno dei problemi più impegnativi da risolvere
• Il cliente deve capire le capacità/limiti del sistema di indicizzazione basato
su SOLR 1.4
• Va stabilita la soglia di soddisfazione nel tempo di retrieval
• Va stabilito cosa ha senso indicizzare sia per i metadati che per i
contenuti
BigRepository

9. Criticità

10. Criticità
• Non sempre i contenuti nell’ECM da dismettere sono validi
• Il cliente non ha inizialmente sufficiente know-how per dare indicazioni su
quali tipologie di formati e metadati migrare
• Potrebbe essere necessario ristrutturare il modello dati iniziale
• Il cliente deve avere chiara percezione di eventuali utilizzi massivi delle
modalità di ricerca full-text
• L’integrazione con altre applicazioni o sistemi deve essere valutata
attentamente
• Raccogliere sufficienti informazioni per dimensionare e strutturare query di
ricerca può essere veramente difficile
• I tempi di risposta si devono mantenere nei limiti di accettazione per il cliente
finale
BigRepository

11. Soluzione

12. Architettura e configurazione minimale
• Alfresco Repository: 2 nodi in cluster
• Index Server SOLR: 2 nodi + 2 Alfresco Repository read-only mode
• Alfresco Repository Injection: 1 nodo
• DBMS ad alte prestazioni (i.e: Oracle Exadata) che supporta tecniche di
partizionamento dei dati
BigRepository
Web
Services
• Ottimizzazione parametri JVM Alfresco e
SOLR
• Disabilitare servizi non necessari
• Disabilitare estrazione automatica
metadati non necessari (i.e: Exif,
RFC822)

13. Strutturare il processo di migrazione
• Il processo di migrazione deve avvalersi di tool o strumenti adatti a
mappare dinamicamente dalla sorgente alla destinazione contenuti e
metadati associati
• Creare lotti a batch temporali
• Esecuzione parallela dei batch definiti per minimizzare i tempi di
migrazione
• Definire logiche di controllo durante le fasi di migrazione al fine di
generare reportistica oppure fermare il processo di migrazione
• Soluzione TAI: Enterprise Content Mapper
– http://www.tai.it/progetti/migrazione-documentale/
BigRepository

14. Strutturare l’integrazione applicativa e di sistema
• Creare se possibile uno strato di servizi unificato per l’accesso ai servizi
documentali (astrazione)
– Soluzione TAI:
• Layer servizi in standard SOAP + MTOM + WS-Security
• Implementazione specifica per un uso ottimale di Alfresco
• Non è necessario conoscere nativamente Alfresco
• Guidare gli sviluppatori all’utilizzo ottimale dei servizi documentali CMIS o
Alfresco REST
• Utilizzare connettori specifici e certificati Alfresco per sistemi come EMC2
Centera e SAP (Connexas-connector)
BigRepository

15. Punti di attenzione 1/3
• Modellare solo i metadati minimali e necessari
• Modellare tipi significativi
• Strutturare il repository in modo da non avere troppi figli diretti di uno
stesso nodo cm:folder
• Attenti a non esagerare con le ACL e preferire un approccio di
configurazione sui Gruppi
• Categorizzare se possibile i nodi documentali attraverso l’aspect
cm:classifiable
BigRepository

16. Punti di attenzione 2/3
• Indicizzare solo i metadati che verranno effettivamente utilizzati nelle
ricerche
• Guidare le ricerche applicative in modo che utilizzino il più possibile il
Metadata Search Engine (utilizzare linguaggi come AFTS o CMIS ed
evitare l’utilizzo dell’operatore OR, PATH, NOT e @)
• Utilizzare in corso d’opera l’aspect cm:indexControl
• Abilitare il full-text per un sotto-insieme di tipi documentali
• Ricerche con result-set elevati possono portare il processo java
dell’istanza Alfresco Repository in out-of-memory
• Avere gli indici su dischi locali e comunque performanti
• Avere circa la metà di spazio disco degli indici sempre libero
BigRepository

17. Punti di attenzione 3/3
• Evitare query troppo generiche e restringere il più possibile i campi di
ricerca su metadati significativi
• Interrogare direttamente il DB nel caso in cui:
– Il result-set abbia una cardinalità troppo elevata (>~20.000 elementi)
– Sia necessario conoscere il numero di elementi di un certo tipo o eseguire
aggregazioni particolari
BigRepository
SELECT names.local_name as node_type, count(*) as occurrencies
FROM alf_node nodes, alf_qname names
WHERE nodes.type_qname_id=names.id
AND
(
names.local_name='PRAI_AP01' OR
names.local_name='PRAI_COIMA' OR
….
)
GROUP BY nodes.type_qname_id, names.local_name
ORDER BY occurrencies desc;

18. Punti di attenzione DBMS 1/2
• Nel disegno e dimensionamento architetturale confrontarsi con un DBA
• Monitorare le tabelle più critiche dello schema dati alfresco e nel caso attivare
tecniche di partizionamento:
– ALF_NODE: riferimenti ai nodi del repository
– ALF_NODE_PROPERTIES: proprietà definite nei modelli dati per ogni tipo o aspetto
– ALF_CONTENT_URL: contiene il riferimenti fisico al contenuto
– ALF_CHILD_ASSOC: relazioni padre-figlio tra nodi del repository
• Fattori di crescita indicativi ~ (per ogni nuovo inserimento di cm:content o
cm:folder):
– ALF_NODE: +3
– ALF_NODE_PROPERTIES: +4
– ALF_NODE_PROPERTIES (versioning attivo): +25
– ALF_CONTENT_URL: +1
BigRepository

19. Punti di attenzione DBMS 2/2
• ALF_NODE_PROPERTIES crescerà a seconda della complessità del
modello dati
• I.E: ~10M documenti potrebbero produrre ~200M di righe su
ALF_NODE_PROPERTIES
• Tecniche di partizionamento basate su HASH sui campi univoci
identificativi
• Evitare quindi in fase di analisi del modello:
– Modellare metadati di cui non si è SICURI dell’effettivo utilizzo
– Abilitare estrattori su meta-type conosciuti non necessari
– Riportare stessi metadati su tipi differenti, utilizzare in questi casi gli aspect
BigRepository

20. Vantaggi/Benefici

21. Vantaggi/Benefici
• Riduzione dei costi a lungo termine
• Scalabilità del sistema
• Performance
• Strutturazione evolutiva dei servizi documentali
• Organizzazione delle informazioni (i dati parlano di sé stessi)
BigRepository

22. TAI Enterprise Content Mapper
DEMO
http://www.tai.it/soluzioni-software/enterprise-content-mapper/

23. Grazie!
Per informazioni alfresco-training@tai.it
Condividi su
#AlfrescoDayRoma