Fra Documentum til SharePoint

Microsofts egne migreringsværktøjer kender ikke Documentum. SharePoint Migration Tool tager SharePoint Server og fildrev, Migration Manager tager fildrev, Box, Dropbox, Google Drive og Egnyte (Microsoft). En migrering fra Documentum går gennem et værktøj fra en tredjepart eller eget udtræk, og det lægger indholdet i SharePoint gennem Migration API. Den kan tage flere versioner af en fil med, både major og minor, og bevarer indholdstypens id og elementernes id’er (Microsoft).

Værktøjet er ikke det svære. Det svære er, at Documentum kan ting, SharePoint ikke kan, og hver af dem kræver en beslutning. Citaterne fra Documentum herunder er fra EMC’s manualer til Content Server 6.7 og 5.3 (Fundamentals Guide 6.7, Object Reference 5.3). Begreberne er de samme i OpenTexts senere udgaver, men OpenTexts egen dokumentation kræver login, og den har jeg ikke læst.

Oversigt#

Typer og attributter#

Documentum har objekttyper i et hierarki: dm_document er en undertype af dm_sysobject, og en virksomheds egne typer er undertyper med egne attributter. Det svarer til indholdstyper, der arver.

En attribut kan være gentagen: den har en indekseret liste af værdier, fx keywords[2]. I SharePoint svarer det til en kolonne med flere værdier: valg, person eller managed metadata. En kolonne med flere valg har ingen rækkefølge. Betyder rækkefølgen noget, fx første forfatter, skal den gemmes på en anden måde.

Versioner#

Hver version i Documentum er sit eget objekt. Versionerne hænger sammen gennem i_chronicle_id, der peger på den første version, og står i et versionstræ. Numrene går 1.0, 1.1, 1.2, og tjekkes en ældre version ud og ind igen, opstår der en gren: fra 1.3 kan der komme 1.3.1.0 og 1.3.2.0. Oven i numrene kan en version have symbolske etiketter. CURRENT er den eneste, serveren sætter selv.

SharePoint har major og minor versioner på en lige linje (5.0, 5.1) og op til 50.000 major og 511 minor pr. major (Microsoft). Der er ingen grene. Derfor skal det besluttes, om kun hovedlinjen skal med, om grenene skal lægges ind i rækkefølge efter dato, eller om kun den version, der har CURRENT, skal med, og resten blive i et arkiv. Versionsnumrene bliver ikke de samme, og de symbolske etiketter har ingen plads, medmindre de gemmes i en kolonne.

Mapper#

Et dokument i Documentum kan ligge i flere mapper på én gang. i_folder_id er en gentagen attribut med alle de mapper, objektet er linket til. En fil i SharePoint har én adresse. Ved migreringen skal hvert dokument have ét hjem, og de andre placeringer bliver til links eller til en kolonne. Findes der dokumenter med flere mapper, er det værd at tælle dem med en DQL-forespørgsel, før kortlægningen, for de er en beslutning hver.

Renditioner og virtuelle dokumenter#

En rendition er det samme dokument i et andet format, typisk en PDF ved siden af Word-filen. Et dokument kan have flere. SharePoint har intet tilsvarende. Renditionen kan komme med som sin egen fil, ved siden af originalen eller i et arkivbibliotek, eller blive lavet igen fra originalen. I en reguleret virksomhed kan det være PDF’en, der er den godkendte udgave, og så er det den, der skal med.

Et virtuelt dokument er et dokument sat sammen af andre dokumenter i et hierarki, og det samme dokument kan indgå i flere. Heller ikke det findes i SharePoint. Delene flyttes som filer, og sammenhængen gemmes som links, en kolonne eller en samlet PDF af det godkendte hele.

Rettigheder#

Documentum styrer adgang med ACL’er. Grundniveauerne er syv og bygger på hinanden: None, Browse, Read, Relate, Version, Write, Delete. Oven i dem er der udvidede rettigheder, der tildeles hver for sig, fx Change Location, Change Permission og Change State. Et objekt har også rettigheder til ejer, gruppe og world, alle andre.

Med Trusted Content Services kan en ACL desuden begrænse: en AccessRestriction holder en bruger eller gruppe nede på et niveau, selv om en anden post giver mere, og en RequiredGroup kræver medlemskab af en gruppe for overhovedet at få adgang. Begge virker som afvisninger. SharePoints rettighedsniveauer er samlinger af tilladelser, der gives (Microsoft), og der er ingen post, der tager adgang fra nogen. Det er samme problem som med Deny på et fildrev, og løsningen er den samme: grænserne lægges på websteder og biblioteker, og det, der var begrænset, får sit eget sted. Mere i Rettigheder flyttes ikke, de oversættes.

Livscyklusser, workflows og revisionsspor#

En livscyklus (dm_policy) er en række tilstande, et dokument flyttes igennem, og et workflow er en forretningsproces. Ingen af dem kan flyttes. Tilstanden kan gemmes i en kolonne, og processen bygges igen i SharePoint eller Power Automate, hvis den stadig skal bruges.

Revisionssporet i Documentum er egne objekter (dm_audittrail og beslægtede), ikke en del af dokumentet. Det kommer ikke med af sig selv, og SharePoints egen historik begynder den dag, filen lægges ind. Skal sporet gemmes, fx fordi det er dokumentation for et GxP-system, skal det eksporteres og arkiveres for sig, og det skal besluttes, før Documentum lukkes. Det gælder også opbevaringspolitikker fra Retention Policy Services: de skal genopstå som opbevaring i Purview, de flytter ikke med. Hvordan det vises, at indholdet ikke blev ændret undervejs, står i At bevise, at intet blev ændret under en migrering.

Det der driller#

• Signerede dokumenter. EMC’s manual advarer om, at signaturer ikke er gyldige efter dump og load til et andet repository. Det samme må forventes ved en migrering til SharePoint, men det har jeg ikke efterprøvet. Et signeret dokuments status skal bevises på anden vis.
• Lange stier. Dybe mappestrukturer i Documentum kan give adresser over SharePoints grænse på 400 tegn for hele stien.
• Brugere, der er væk. Ejere og forfattere, der ikke længere findes i Entra ID, skal mappes til noget, ellers bliver Oprettet af forkert.