Migracja prawniczej bazy wiedzy

Problem

Prawnicza baza wiedzy znajdowała się w systemie helpdeskowym ManageEngine ServiceDesk Plus, z którego firma odchodziła. Każdy artykuł miał załączniki PDF, obrazy osadzone w treści, linki do innych artykułów, miejsce w drzewie tematów, informację o autorze i datach oraz grupy, które mogą go czytać. Wszystko to musiało trafić do SharePointa w nienaruszonym stanie. Alternatywą były tygodnie kopiowania i wklejania, z błędnymi uprawnieniami gdzieś po drodze.

Co zrobiłem

Zaprojektowałem i zbudowałem trzynastoetapowy proces w Pythonie korzystający z Microsoft Graph i API SharePointa. Dzieli się na granicy sieci: pierwsze etapy pobierają wszystko przez API helpdesku do lokalnego archiwum, a kolejne wysyłają dane z tego archiwum do SharePointa. Ekstrakcję można powtórzyć bez dotykania celu, a import bez dotykania źródła. Każdy etap jest osobno idempotentny, a każde masowe uruchomienie dopisuje się do dziennika per rekord, więc ustalenie, co stało się z jednym artykułem w jednym przebiegu, to kwestia wyszukania, a nie śledztwa.

Wszystkie 1029 artykułów zaimportowano w jednym masowym przebiegu: 82 osadzone obrazy przeniesiono i podlinkowano na nowo, przepisano odnośniki między artykułami i nadano 901 zakresów uprawnień. Rozwiązanie działa produkcyjnie, a ograniczony ponowny import czeka na przegląd po stronie działu. Od tego czasu doszła warstwa Power Platform: przepływy i aplikacje Power Apps, dzięki którym zespół prawny sam tworzy nową sekcję, stronę, bibliotekę i uprawnienia, bez programisty.

Załączniki nie trafiły do jednej wspólnej biblioteki. Każdy artykuł ma własny folder nazwany jego identyfikatorem z systemu źródłowego, strona trzyma ten identyfikator w kolumnie, a import wstawia na stronę web part biblioteki dokumentów wskazujący właśnie ten folder, więc pliki widać przy artykule, do którego należą, a plik dorzucony później pojawia się na stronie bez jej edycji. Uprawnienia nadaje się potem dwa razy, stronie i jej folderowi, w tym samym zestawie: artykuł z ograniczonym dostępem, którego folder z załącznikami dalej dziedziczy uprawnienia witryny, ujawnia dokładnie te dokumenty, które to ograniczenie miało chronić. Łącznie 2972 pliki w 846 folderach.

Każda strona potrzebowała bloku z autorem i datą ostatniej aktualizacji. Zapisany w treści strony przetrwał import, a potem znikał, bo SharePoint oczyszcza tę treść przy każdym zapisie w edytorze. Przeniosłem te dane z treści strony do kolumn biblioteki, które wyświetla wbudowany web part. Edycja strony nie może już naruszyć metadanych, bo metadanych nie ma w stronie.

Decyzja i jej koszt

Skrypty logują się jako osoba, a nie jako aplikacja. Każde uruchomienie musi zacząć człowiek, więc nie da się go zaplanować bez nadzoru. W zamian nie ma sekretu do przechowywania ani rotowania, proces może zrobić dokładnie to, co jego operator mógłby zrobić ręcznie, a każdą operację da się przypisać konkretnej osobie. Przy migracji wrażliwych treści prawnych to właściwa strona tego kompromisu.

Kolejność miała znaczenie zarówno dla poprawności, jak i bezpieczeństwa. Uprawnienia do poszczególnych elementów trzeba nadać przed uprawnieniem na poziomie witryny; w odwrotnej kolejności cała baza wiedzy byłaby przez czas trwania przebiegu dostępna dla całej firmy. Tego ograniczenia nie da się wyczytać z kodu, dlatego jest zapisane pogrubioną czcionką na początku instrukcji uruchomienia.

Co zrobiłbym inaczej

Wprowadziłem jeden błąd, który wychwycił dział: indeks tematów był budowany na podstawie artykułów, przez co po cichu znikło 96 tematów, które nie zawierały żadnego artykułu, ale zostały utworzone celowo. Poprawka odczytuje teraz pełną taksonomię. Wniosek, który zachowałem: najdroższe błędy w tym projekcie wynikały z zachowania platformy, a nie z logiki, dlatego weryfikowałem wyniki przez API.