Polecenie "migrate"

Pozwala na migrację konfiguracji lokalnych serwisów. Migracja oznacza wyznaczenie dla każdego serwisu szablonu konfiguracyjnego oraz detekcję różnic między bieżącą konfiguracją a szablonem konfiguracyjnym.

Dostępne są migracje konfiguracji:

• sowas - migracja konfiguracji dostępnych serwisów (przejęcie kontroli nad konfiguracją sowas.cfg)
• sowa2 - migracja konfiguracji zainstalowanych serwisów typu SOWA2 (przejęcie kontroli nad plikiem .inf, katalog.ini oraz index.py)
• sowasql - migracja konfiguracji zainstalowanych serwisów typu SOWASQL (przejęcie kontroli nad całym katalogiem etc/)

Składnia

sowizor migrate sowas [check|start] [--force]
sowizor migrate sowa2|sowasql
sowizor migrate <sid> [--force] [--nodelete] [--ignore-params|--generate-params] [--generate-services] [--use-schema=<hid>] [--override-records]

Migracja konfiguracji sowas

W systemach Linux instalowany jest moduł o nazwie "sowas". Konfiguracja katalogów SOWY przechowywana jest w pliku sowas.cfg. Podczas migracji sowizor przejmuje kontrolę nad tym plikiem - od momentu migracji jest on automatycznie generowany podczas wszelkich operacji na serwisach dokonywanych przy pomocy sowizora.

Migracja konfiguracji sowas jest obligatoryjna i należy ją przeprowadzić zaraz po instalacji sowizora.

Wywołanie polecenia z parametrem sowas lub sowas check - weryfikuje możliwość migracji ustawień (zwykle nie ma z tym problemu).

Wywołanie polecenia z parametrem sowas start - przeprowadza migrację konfiguracji. Od tego momentu serwisy są już pod kontrolą sowizora (nie ma potrzeby uruchamiania polecenia "scan").

Operację tę należy wykonać tylko raz. Jeśli z jakiegoś powodu zaistnieje konieczność jej powtórzenia, konieczne będzie podanie opcjonalnego atrybutu --force. Wymusi to ponowną migrację konfiguracji z pliku sowas.cfg.

Migracja konfiguracji serwisów SOWA2 i SOWASQL

Wydając polecenie z parametrem sowa2 lub sowasql można wyświetlić listę serwisów, potencjalnie nadających się do migracji.

Podając jako parametr identyfikator <sid> uruchamia się migrację serwisu (o ile jest to serwis SOWA2 lub SOWASQL).

Jest to zaawansowany, skomplikowany proces, który wymaga szczegółowej wiedzy na temat architektury systemu i sposobu jego konfiguracji. Z tego powodu wskazane jest przeprowadzanie tej operacji pod nadzorem pracowników firmy SOKRATES-software.

Proces ten dzieli się na fazę check (detekcja ustawień) i start (wykonanie migracji).

Etapy w fazie check

• detekcja schematu (schemat określa przeznaczenie serwisu, układ katalogu, dostępne rekordy i bazy aplikacji)
• detekcja używanych typów rekordów
• wykrycie różnic w konfiguracji pól logicznych rekordów SOWY2
• sprawdzenie poprawności parametrów systemu
• wykrycie używanych usług katalogu SOWY2 (detekcja m.in. formatów, zestawień, programów, indeksów, kryteriów itd.)
• sprawdzenie dostępności i poprawności struktur plików DBF (nie dotyczy wersji SQL)

Po zakończeniu fazy check, program dla każdego migrowanego serwisu wyświetli podsumowanie i możliwe dalsze kroki migracji. Możliwe są następujące statusy:

• Migracja już wykonana - oznacza to, że serwis został już wcześniej zmigrowany i nie ma potrzeby robić tego ponownie. Można to jednak wymusić podając opcjonalny argument --force.
• Migracja możliwa: katalog gotowy do automatycznej migracji
• Migracja możliwa: zalecana weryfikacja przez specjalistę - ten status wystąpi w przypadku stwierdzenia istotnych różnic np. w konfiguracji struktur pól logicznych rekordów SOWA2. Wymagana jest świadoma decyzja o aktualizacji tych struktur do wykrytego (lub zadeklarowanego) schematu konfiguracyjnego.
• Migracja niemożliwe: wymagana aktualizacja ręczna - ten status wystąpi w przypadku, gdy proces automatycznej detekcji ustawień napotkał na problemy wymagające ręcznej ingerencji. Jeśli operator programu nie wykona odpowiednich modyfikacji, wówczas migracja automatyczna nie będzie możliwa.
• Konieczność kontaktu z firmą SOKRATES-software - ten status oznacza, że napotkano serwis o konfiguracji wyjątkowo niestandardowej (której nie opisuje żaden dostępny szablon konfiguracyjny)

Rozwiązywanie problemów

W trakcie detekcji ustawień program może napotkać problemy wymagające podjęcia dodatkowych kroków lub decyzji przez operatora. Zwykle w tym momencie proces analizy jest przerywany i wyświetlana jest sugestia na temat możliwych sposobów rozwiązania problemów. Rozwiązać je można albo poprzez poprawienie bieżącej konfiguracji (i w ten sposób wyeliminowanie problemu) lub użycie sugerowanych opcji dodatkowych wywołania polecenia.

• Napotkano niepoprawne (nieznane) parametry w plikach parametry.inc oraz katalog.ini.
  Wszystkie dopuszczalne parametry są elementem pakietu z szablonami konfiguracyjnymi (serwer-sowa2-cfg). Zdarzają się sytuacje w których w migrowanym serwisie pojawi się parametr, którego definicji nie ma w szablonie. Zwykle jest to wynik błędu użytkownika (użycie niepoprawnej składni polecenia administracyjnego), niekiedy zaś jest to lokalny parametr stosowany tylko i wyłącznie w danej instalacji. W zależności od tego jakiego rodzaju jest ów nieznany parametr, należy użyć jednej z dostępnych opcji:
  --ignore-params - ignoruje nieznane parametry i kontynuuje migrację. Parametry te zostaną usunięte z konfiguracji serwisu.
  --generate-params - generuje lokalne definicje parametrów, a ich bieżącą wartość ustawia jako domyślną. Parametry te zostaną zachowane w konfiguracji serwisu.
• Napotkano niepoprawne (nieznane) serwisy/usługi w pliku .inf
  Wszystkie dopuszczalne w standardowych instalacjach serwisy/usługi są elementem pakietu z szablonami konfiguracyjnymi (serwer-sowa2-cfg). Dość częstym przypadkiem jest jednak definiowanie lokalnych serwisów (np. nietypowe zestawienia, programy, czy formaty wyświetlania lub indeksy). W większości przypadków właściwym rozwiązaniem tego problemu jest użycie opcji --generate-services. Dzięki temu wygenerowane zostaną lokalne definicje nietypowych serwisów i zostaną one zachowane w konfiguracji.
• Nie udało się określić schematu konfiguracyjnego dla cełego serwisu.
  Jest to rzadki przypadek, w którym nie udało się określić schematu dla migrowanego serwisu. W takiej sytuacji można wymusić użycie schematu o podanej nazwie, np.:
  --use-schema=marc21-akc - powoduje użycie schematu dla serwisu katalogu bibliotecznego w formacie MARC21 z akcesją dokumentów zwartych.
• Napotkano konflikt oznaczeń indeksów dla rekordów
  W takim przypadku zwykle konieczna jest fachowa ingerencja pracownika SOKRATES-software. Jednym z możliwych rozwiązań jest użycie opcji --override-records, która spowoduje zignorowanie konfliktu i zastosowanie oznaczeń zdefiniowanych w szablonach konfiguracyjnych. Należy używać tej opcji z dużą ostrożnością.

Etapy w fazie start

Serwis, który przejdzie przez etap check można ostatecznie zmigrować wywołując polecenie z parametrem start.

Migracja wykona następujące czynności:

• w razie konieczności zainstaluje i skonfiguruje moduł SMAILER
• wygeneruje i obejmie nadzorem plik katalog.ini (zlikwiduje to wszystkie dotychczasowe pliku .inc w katalogu bazy danych)
• wygeneruje i obejmie nadzorem plik index.py (stosowany do reindeksacji bazy danych w trybie offline)
• jeśli jest to wymagane - przeprowadzi migrację struktur plików DBF
• jeśli jest to wymagane - wykona reindeksację nowo utworzonych lub zmienionych plików DBF
• przeniesie konfigurację wysyłki poczty do modułu SMAILER
• wygeneruje lokalny wariant schematu służący do automatycznego generowania konfiguracji
• wygeneruje i obejmie nadzorem nowy plik konfiguracyjny .inf

Proces ten archiwizuje dotychczasowe ustawienia, dzięki czemu można w razie potrzeby odzyskać starą konfigurację. Domyślnie jest ona archiwizowana i usuwana. Można to zmienić dzięki opcji --nodelete - podanie jej spowoduje, że dotychczasowa konfiguracja nie zostanie usunięta, lecz tylko zostaną przemianowane pliki na rozszerzenie .old.

Zmiana bazowego schematu serwisu

Polecenie migrate służy także do zmiany bazowego schematu serwisu. W ten sposób można np. rozszerzyć funkcjonalność serwisu - do serwisu obsługującego katalogowanie MARC21 dołożyć typy rekordów i programy dla zasobów czasopism, albo np. do akcesji zbiorów. W szczególności należy jednak pamiętać, że jedyne bezpieczne migracje wykonuje się od schematu węższego do szerszego. "Obcinanie" funkcjonalności (czyli np. usuwanie akcesji) wymaga wcześniejszego zweryfikowania, że dla usuwanych typów rekordów nie ma żadnych danych w bazie.

Operacja zmiany schematu bazowego jest oparta na tych samych mechanizmach, co zwykła migracja. Wymagane jest jedynie użycie parametru --use-schema=<hid>. Listę dostępnych schematów można zobaczyć w dokumentacji polecenia add.

sowizor migrate biblioteka_pub_ks start --use-schema=marc21-zasob