Migrazione di Docuware

Migrazione di Docuware

Scritto da Josep Llort il 4 gennaio 2019 

In questo articolo descriveremo la migrazione tra Docuware e OpenKM. In una precedente pubblicazione, ho già descritto un processo di migrazione; in tal caso tra Knowledgetree e OpenKM.

Docuware è un sistema di gestione dei documenti, che, tra molte altre differenze rispetto a OpenKM, non ha una versione open source; cioè, è un'applicazione che viene offerta solo con una licenza commerciale. Docuware Gmbh., È il produttore tedesco di questa soluzione di gestione dei documenti.

Successivamente, esaminerò brevemente le funzionalità principali del software di gestione dei documenti Docuware e li confronterò con la soluzione di gestione dei contenuti aziendali offerta da OpenKM.

Innanzitutto, vorrei sottolineare che Docuware è una soluzione che viene installata solo in un sistema operativo Microsoft Windows; cioè, a causa della sua architettura è una soluzione nativa dell'ecosistema Microsoft. A differenza del gestore documenti OpenKM, la cui architettura è basata su JAVA, quindi è un ambiente multipiattaforma.

In OpenKM, e penso che possiamo estenderlo alla maggior parte dei produttori di soluzioni di gestione dei documenti, gestione dei record e gestione dei contenuti aziendali, consigliamo ai nostri clienti che, quando possibile, Linux venga utilizzato come il sistema operativo nelle sue diverse distribuzioni. Raccomandiamo Ubuntu, Debian, Centos e Red Hat. La ragione è semplice; con lo stesso hardware, Linux ci fornirà sempre prestazioni più elevate, perché il sistema di input (I / O) è più efficiente. Inoltre, notiamo che un server con Windows ha una naturale tendenza a consumare un minimo di 2GB di memoria, mentre Linux consumo di risorse da parte del sistema operativo predefinito è molto più basso.

In breve, se siamo in uno scenario in cui la "performance" è un fattore critico, dovremmo sempre considerare la possibilità di installare Linux anziché Windows. Con questo non stiamo negando la possibilità di creare ambienti ad alte prestazioni sotto Windows. Vogliamo semplicemente rivelare un dato oggettivo; a parità di condizioni, con Linux avremo prestazioni extra.

Un'altra differenza, come ho detto all'inizio, è il tipo di licenza. Mentre il sistema di gestione di OpenKM ha una doppia licenza ("commerciale" e "open source"), Docuware viene offerto solo con un unico modello ("commerciale").

Per quanto riguarda i database, possiamo verificare che sia la soluzione di gestione documentale Docuware che OpenKM possono essere configurati per funzionare con Microsoft SQL Server, Oracle e MySQL Server. Nel caso di OpenKM, è possibile utilizzare anche PostgreSQL. Per quanto riguarda i database, possiamo vedere che sia OpenKM che Docuware o la maggior parte dei produttori di soluzioni di content management scelgono uno di questi 4 database relazionali.

In generale, troveremo gli utenti che vogliono utilizzare il database del server Microsoft SQL, fondamentalmente in ambienti Windows Server; mentre i database PostgreSQL, Oracle, MySQL Server e MariaDB, li troveremo in ambienti basati su Linux.

Segmentiamo i repository della gestione documentale in due grandi gruppi: quelli come OpenKM, che usano una tassonomia e quelli che non usano questo paradigma. La parola tassonomia ha origine nella scienza, in particolare nella biologia, dove è necessario un meccanismo per gerarchizzare e sistematizzare i gruppi di animali e piante. Chiameremo tassonomia, un sistema che ci consente di classificare o ordinare in gruppi, di cose che hanno caratteristiche comuni.

Le applicazioni di gestione dei documenti come OpenKM, Nuxeo o Alfresco utilizzano il concetto di tassonomia per classificare le informazioni. In breve, la tassonomia nel linguaggio popolare è una gerarchia di cartelle che ci consente di ordinare e classificare i documenti.

Altri sistemi di gestione documentale come Documentum (ora ECM2), OnBase, incluso Docuware, utilizzano la catalogazione basata sul concetto di "scatole". Nel caso di Docuware, il nome corretto sarebbe "Cabinets". Un armadio o un cassetto nel mondo reale, in cui è archiviato un solo tipo di documento (una serie di singoli documentari). Nel caso di questi sistemi di gestione documentale, troveremo che per ogni tipo di documento hanno una "scatola" separata ("Cabinet"); con i metadati corrispondenti per il tipo di documentario assegnato a ciascuna casella.

Facciamo un esempio: un'azienda che memorizza fatture e contratti. Nel caso di una soluzione di gestione dei documenti come OpenKM, potremmo navigare attraverso un albero di directory per localizzare le informazioni:

• / okm: root / Gestione del personale / Contratti / 2019
• / okm: root / Gestione del personale / Contratti / 2018
• / okm: root / Gestione del personale / Fatture / 2019
• / okm: root / Gestione del personale / Fatture / 2018

Nel caso di Docuware, Documentum o Onbase, dobbiamo prima selezionare il tipo di documento per accedere a una schermata di elenco che ci consente di affinare la ricerca. Non esiste una navigazione in sé, ma l'accesso alla documentazione è a conoscenza del tipo di documento a cui vogliamo accedere.

Le prime soluzioni di gestione dei documenti, come Documentum e OnBase, sono apparse sotto questo paradigma; probabilmente influenzato spostando il problema del mondo reale in modo esatto, alle soluzioni informatiche. Nel mondo reale, le informazioni sono archiviate sugli scaffali e su ogni scaffale dal tipo di documentazione. Ispirati da questa soluzione, le prime applicazioni offrivano lo stesso formato concettuale in un ambiente digitale.

Successivamente, le più moderne applicazioni di gestione dei documenti, gestione dei contenuti e gestione dei contenuti aziendali hanno optato per un modello basato sulla classificazione delle informazioni all'interno di una tassonomia.

Entrambi i modelli, a mio parere, hanno vantaggi e alcuni svantaggi. Per le soluzioni basate sulla tassonomia, oltre i vantaggi dell'usabilità, il punto più significativo è quello di rompere l'isolamento delle informazioni imposta dai cabinents. Questo è; quando ci troviamo di fronte non solo un problema di gestione dei documenti, ma un problema di gestione dei record (record management, o business case) in cui diversi tipi di documenti hanno una serie di vita correlati, l'approccio basato sulla "armadi" è una soluzione problematica.

In uno scenario in cui il gestore documenti non è un semplice contenitore di prove della società, ma governa i flussi di lavoro che controllano il ciclo di vita dei documenti; e allo stesso tempo ci sono file in corso, in cui sono coinvolti diversi documenti (business case) la soluzione basata su "Cabinets", dal mio punto di vista non è la più ottimale.

In generale, le aziende vanno sempre più oltre ad avere un semplice contenitore di documenti e desiderano controllare le informazioni più attivamente. È qui che vengono visualizzati sia i flussi di lavoro che il piano file (piano file e disposizione). Il problema non è più solo la memorizzazione, ma piuttosto il controllo sulla validità, i cambiamenti, nonché la distribuzione e l'accesso alle informazioni quando è richiesto. E tutto questo attivamente integrato nell'attività dell'azienda (qui troviamo casi tipici di integrazioni con CRM, ERP, tra gli altri). Le applicazioni di gestione dei documenti passano dall'essere un semplice contenitore, all'essere parte attiva dell'ecosistema software con cui l'azienda opera.

Possiamo trovare ulteriori informazioni nel Centro informazioni di Docuware .

Nel caso di Docuware, che è quello di cui ora ci occupiamo; da OpenKM abbiamo fatto diverse migrazioni. In particolare, nel momento in cui sto scrivendo questo articolo, abbiamo effettuato migrazioni sia della versione 6.x sia della versione 7.x.

Come sempre, non abbiamo trovato alcuna informazione dal produttore, in modo che il cliente possa estrarre i dati dal proprio repository. Il punto di partenza viene rinnovato, e come nel caso delle migrazioni effettuate con altre soluzioni di gestione dei documenti, il cliente è imprigionato nella soluzione del computer.

Ecco perché da qui voglio riprendere l'articolo che ho scritto sulla migrazione da Knowledgetree a OpenKM. Dal mio punto di vista, nei processi di acquisizione di un software di gestione documentale, i futuri utenti di questi strumenti, concentrano tutti i loro sforzi sulle funzionalità degli strumenti; La tecnologia su cui si basano, oltre ai costi. Tralasciando la valutazione di un argomento che considererei fondamentale; come ottenere i nostri dati da questo sistema, in futuro.

Il caso di Docuware è molto simile, almeno concettualmente a quello di OnBase. Per ciascun "Cabinet", cioè per ogni tipo di documento, viene creato un set di tabelle specifiche, in cui le informazioni verranno memorizzate separatamente. Questo è; Se disponiamo di 50 tipi di documenti, l'applicazione creerà almeno 50 tabelle, ognuna delle quali conterrà le informazioni e i metadati di ciascun tipo di documento.

Qualcosa di significativo anche nel caso di Docuware è il modo in cui i dati vengono archiviati nel file system. Esiste la possibilità che ogni tipo di documento sia memorizzato in una destinazione diversa, vale a dire che i documenti binari a seconda del tipo possono essere memorizzati in unità diverse. Questa flessibilità nella configurazione può complicare la nostra vita nel processo di migrazione, perché, a seconda del tipo di documento, dobbiamo tenere conto di dove si trovano fisicamente le informazioni sul disco.

Un'altra curiosità di Docuware è il modo in cui i file vengono archiviati nel file system. Ad esempio, un file PDF di 32 pagine sarà trovato separatamente in 32 file di una pagina ciascuno, cioè; quando carichiamo un file PDF (a seconda della configurazione di Docuware) esso verrà elaborato e memorizzato sotto forma di 32 documenti con una pagina in ciascuno di essi. Per quanto riguarda la modalità di archiviazione dei documenti, abbiamo trovato variazioni a seconda che la versione fosse 6.x o 7.x e anche in base al tipo di documento PDF o TIFF multipagina.

Un altro problema che si pone è il modo in cui sono memorizzati i metadati, in particolare quelli del tipo "data". Questo è un problema classico, che abbiamo trovato praticamente in tutti i processi di migrazione di altre applicazioni di gestione dei documenti e che richiede un'attenzione speciale, per acquisire il valore della data nel formato corrispondente e quindi memorizzarlo in OpenKM in un formato ISO8601.
Infine, l'ultima curiosità di Docuware è che il repository del disco contiene un file per ogni documento, con tutte le informazioni nel documento. Questo è; tutto sembra indicare che il repository Docuware locale funziona come esportazione live del repository con i suoi metadati. Ovviamente, ciò implica che qualsiasi modifica che faremo dall'applicazione in un documento avrà i suoi effetti sia a livello di database che a questi file locali. Questo ha il vantaggio che nel repository abbiamo già un backup (esportazione a caldo); ma allo stesso tempo, stiamo duplicando tutti i dati (database e file system) con il consumo hardware corrispondente che tutto ciò implica. Ciò implica anche una logica complessa sul lato dell'applicazione,

Nel momento in cui il reparto RK di Ricerca e Sviluppo di OpenKM ha eseguito l'analisi di reverse engineering per eseguire la migrazione dei dati, abbiamo ritenuto che fosse molto più conveniente affrontare il processo di migrazione attraverso uno script JAVA, che ha funzionato in combinazione con la base di dati e il file system, collegandolo con OpenKM attraverso l'SDK JAVA. Scartiamo input, elaboriamo i file di testo contenenti la struttura dei metadati di Docuware, perché il formato in cui sono archiviate queste informazioni non era ovvio, a differenza di OpenKM; che quando esportiamo la struttura dei metadati nei file, lo facciamo con i file in formato JSON, il che facilita enormemente la sua successiva elaborazione.

Dal reparto R&D, inoltre, analizziamo il supporto di CMIS in Docuware. Sebbene non ci dichiariamo fan del CMIS, è un'opzione da considerare e al momento della stesura di questo articolo non è disponibile. Abbiamo trovato alcuni esempi di connessione tramite .NET con l'API Docuware, come possiamo vedere in questo esempio di API Docuware.

E' un path dell'ambiente di sviluppo Microsoft che è necessario montare, come un'opzione da considerare per chi vuole migrare il repository. Sembra che il pacchetto DocuWarePlatformApi, un set di librerie simile a quello che abbiamo in OpenKM sotto il nome di SDK per Java, .NET e PHP, fornisce l'accesso in un modo molto semplice a tutte le funzioni del repository, tramite i servizi Web in REST.

In generale, quando possibile e disponiamo di un'API da cui attingere un repository, è consigliabile utilizzarlo come primo approccio per risolvere il problema.

Manca un servizio REST ben documentato; non siamo stati in grado di localizzare la documentazione online. In OpenKM, come altri produttori, abbiamo optato per l'opzione che la documentazione del servizio REST sia disponibile tramite Swagger.io; dalla documentazione stessa come indicato in questa sezione: spavalderia

Spero che questo articolo può servire come introduzione per quegli utenti che vogliono eseguire la migrazione dei dati da Docuware. Sperco che l'esperienza che qui cerchiamo di condividere in qualche modo facilitare la soluzione del problema. I processi di migrazione di repository Docuware sono molto simili, ma non esattamente gli stessi, quindi non in grado di fornire una ricetta magica che è utile in tutti i casi. In questo articolo ho cercato di condividere una conoscenza "comune" che considero riutilizzabile in tutti gli scenari in cui ci siamo trovati.

Alcuni URL di interesse:

• API .NET della piattaforma Docuware
• Esempi di codice
• Piattaforma come servizio REST