Migrator aplikacji

Podsumowanie:
Migrator aplikacji umożliwia przenoszenie aplikacji między środowiskami nAxiom. Obejmuje to zarówno import nowej aplikacji do środowiska docelowego, jak i aktualizację aplikacji w środowisku docelowym. Niezbędne wymagania dla pomyślnego zmigrowania aplikacji do innego środowiska to:
- takie same wersje nAxiom w obu środowiskach; a dokładniej takie same wersje bazy danych, patrz Import aplikacji,
- takie same schematy obiektów bazy danych w obu środowiskach.

W ogólności migracja polega na przeniesieniu danych definiujących aplikację z bazy danych środowiska źródłowego do bazy w środowisku docelowym. Jednak szczegóły tej operacji zależą od rodzaju obiektów.

☛ AdminSPA > ADMINISTRACJA > Migrator aplikacji

W tym temacie

Wstęp

Budowanie aplikacji pod kątem migracji

Czynności do wykonania przed eksportem aplikacji

Konfiguracje eksportu

Porównywanie konfiguracji eksportu

Podgląd danych w paczce

Import aplikacji

Czynności wykonywane po imporcie

Szczególne przypadki aktualizacji aplikacji

Wstęp

Migracja to proces, który odbywa sie w dwóch krokach:

w środowisku źródłowym: wybór jednej lub kilku aplikacji i wyeksportowanie definicji obiektów przypisanych do tych aplikacji do pliku .nax.
w środowisku docelowym wczytanie pliku .nax i zaimportowanie obiektów aplikacji do bazy danych.

Jeśli w danej aplikacji używane są obiekty przypisane do innej aplikacji, w definicji migrowanej aplikacji należy wskazać moduły macierzyste tych obiektów jako moduły powiązane (AdminSPA > Lista aplikacji > Edytuj > Moduły > Dodaj powiązany moduł).

Jeśli aplikacja BaseApp nie zawiera obiektów utworzonych przez użytkownika, jej migracja nie jest konieczna. Ta aplikacja zawsze istnieje w środowisku docelowym migracji.

Obiekty składające się na aplikację to:

model danych (tabela): powiązanie z aplikacją następuje podczas generowania elementów aplikacji; możliwe jest także dowolne powiązanie innych tabel z modułem aplikacji na karcie Moduły w Kreatorze modeli danych.

Migrator przenosi tylko definicję tabel użytkownika; dane nie są migrowane. Patrz także Szczególne przypadki aktualizacji aplikacji
generowane automatycznie elementy aplikacji:
- definicja dokumentu biznesowego, w tym typy dokumentów biznesowych, schemat autonumeracji, definicje statusów i diagram procesu
- formularz
- widok listy
kategorie załączników
definicje akcji, w tym zarówno globalne, jak i powiązane z formularzami
definicje źródeł danych i słowników
widżety, kontrolki, sekcje i podsekcje menu, szablony (Word, Excel, raporty, e-mail)
monitory e-mail, zadania cykliczne
tłumaczenia
role biznesowe

W przypadku kategorii załączników, jeśli importowana kategoria ma przypisane jedno z repozytoriów systemowych, to przypisanie zawsze nadpisze przypisanie w aplikacji docelowej. Jeśli natomiast importowana kategoria ma przypisane repozytorium niestandardowe, przypisanie w aplikacji docelowej nie zmieni się. W przypadku importu nowej kategorii z repozytorium niestandardowym zostanie utworzona kategoria z przypisanym domyślnym repozytorium załączników.

Migracja nie obejmuje stylów ani zestawów rozpoznawanych danych i szablonów OCR. Ponadto nie są migrowane repozytoria załączników.

Ponadto migrator przenosi powiązane z tabelami danych biznesowych obiekty bazodanowe wymagane do poprawnego działania aplikacji w nowym środowisku:

Constraints — w nAxiom definiowane na karcie Relacje dla wybranej tabeli w kreatorze modeli danych,
Indexes — definiowane w bazie danych, niedostępne w nAxiom,
Triggers — definiowane w nAxiom podczas definiowania audytów na poszczególnych kolumnach,
Views — funkcje tabelaryczne tworzone zarówno w nAxiom jak i w bazie danych.

Budowanie aplikacji pod kątem migracji

Należy zwrócić uwagę na odwołania do obiektów aplikacji w oparciu o ustalone wartości identyfikatora. W przypadku tabel z kolumną klucza głównego o wartościach generowanych automatycznie (najczęściej kolumna o nazwie Id i typie int), po migracji do innego środowiska wartości w tej kolumnie mogą być inne. Spowoduje, to że wszelkie odwołania do obiektów reprezentowanych przez te rekordy za pomocą konkretnej wartości Id przestaną działać.

Aby zapobiec takim problemom, należy konstruować odwołania np. do kodu danego obiektu lub jego identyfikatora typu uniqueidentifier. W niektórych przypadkach można także użyć funkcjonalności smart numbers opisanej w temacie Smart numbers .

Czynności do wykonania przed eksportem aplikacji

Aby zapewnić powodzenie migracji aplikacji, zaleca się sprawdzenie kilku podstawowych kwestii.

Czy zamiast odwołań do identyfikatorów obiektów (np. statusów, typów biznesowych, słowników) używane są referencje smart numbers lub identyfikatory innego typu. Dotyczy to w szczególności akcji, zależności na listach, konfiguracjach list, zależności kontrolek.
Czy wszystkie tabele, które mają być migrowane, są przypisane do modułów aplikacji (Kreator modeli danych, karta Moduły); dotyczy to przede wszystkim tabel pomocniczych oraz tych tabel modeli standardowych i uproszczonych, których dokumenty biznesowe nie są migrowane.
Czy definicje dokumentów biznesowych, formularze i listy są powiązane z odpowiednimi aplikacjami i modułami. Migrator uwzględni tylko obiekty powiązane z modułami włączonymi do konfiguracji eksportu. W przypadku korzystania z obiektów powiązanych z innymi aplikacjami, należy powiązać moduł macierzysty takiego obiektu z modułem migrowanej aplikacji, zgodnie z opisem powyżej .

Konfiguracje eksportu

Aby wyeksportować aplikacje z bieżącego środowiska nAxiom, wykonaj poniższe kroki:

Wyświetl stronę Migrator aplikacji (AdminSPA > ADMINISTRACJA > Migrator aplikacji).
Kliknij przycisk Eksportuj i w wyświetlonym oknie wpisz nazwę eksportowanej konfiguracji, a następnie zaznacz pola wyboru obok aplikacji, które chcesz eksportować. Podana nazwa zostanie użyta w nazwie pliku konfiguracji. Dla każdej aplikacji można włączyć przełącznik w kolumnie Eksportuj uprawnienia PBA. Spowoduje to, że wraz z rolami przypisanymi do danej aplikacji zostaną wyeksportowane uprawnienia PBA przypisane tej roli we FrontSPA oraz w AdminSPA.
Kliknij przycisk Eksportuj. Zdefiniowana konfiguracja eksportu zostanie wyświetlona na liście.

Dla każdej konfiguracji eksportu w ostatniej kolumnie tabeli są dostępne przyciski akcji:

Importuj do platformy: uruchamia kreatora importu aplikacji z danej konfiguracji; patrz sekcja Import aplikacji
Właściwości: wyświetla listę aplikacji w konfiguracji
Pobierz: pobiera konfigurację w postaci pliku archiwum z rozszerzeniem nax do domyślnego folderu pobierania; nazwa pliku ma postać nAxiom-NazwaKonfiguracji-data-godzina
Usuń: usuwa konfigurację z listy

Porównywanie konfiguracji eksportu

Na stronie Migrator aplikacji dostępne są przyciski umożliwiające porównanie dwóch konfiguracji eksportu oraz porównanie wybranej konfiguracji z bieżącym środowiskiem.

Aby porównać dwie konfiguracje, zaznacz je na liście i kliknij przycisk Porównaj dwie konfiguracje. Zostanie wyświetlona lista z nazwami tabel systemowych, w których zapisywane sa elementy aplikacji, oraz w kolejnych kolumnach liczby nowych wpisów, modyfikacji i usunięć. Każdą tabelę można rozwinąć, aby wyświetlić listę obiektów, które zostały zmienione, a te z kolei można rozwinąć do poziomu atrybutów. Dla szczegółów zmiany wyświetlany jest rodzaj modyfikacji (DELETE, INSERT, UPDATE) oraz dane oryginalne i dane importowane.

Z prawej strony nagłówka listy zmian są dostępne dwa przyciski:

Schowaj różnice/Pokaż różnice: ukrywa/wyświetla listę zmian
Pokaż szczegóły/Ukryj szczegóły: rozwija/zwija wszystkie pozycje na liście zmian

Aby porównać wybraną konfigurację z bieżącym środowiskiem, zaznacz konfigurację na liście i kliknij przycisk Porównaj z obecną konfiguracją. Zostanie wyświetlona lista zmian identyczna z opisaną powyżej. W tym przypadku konfiguracja bieżąca jest traktowana jako pierwotna (bez daty/godziny), a konfiguracja zaznaczona na liście jako nowa konfiguracja.

Porównywanie konfiguracji odbywa się także podczas importu aplikacji, ale możne je wówczas pominąć.

Podgląd danych w paczce

Aby wyświetlić wykaz obiektów w danej konfiguracji, należy ją zaznaczyć na liście i kliknąć przycisk Podgląd danych w paczce. Kliknięcie dowolnej pozycji w kolumnie Nazwa powoduje wyświetlenie listy obiektów danej kategorii i ich atrybutów.

Import aplikacji

Przed importem aplikacji należy wykonać kopię zapasową bazy danych na środowisku docelowym, aby niepowodzenie operacji nie doprowadziło do utraty danych.

Aby zapewnić powodzenie importu, należy wziąć pod uwagę następujące kwestie:

Migrator nie tworzy w docelowej bazie danych schematów bazy danych. Jeśli importowana aplikacja korzysta z niestandardowych schematów bazy danych, przed importem konsultant musi utworzyć je w docelowej bazie danych. W przeciwnym razie import nie powiedzie się.
Środowisko źródłowe importowanej aplikacji musi być zgodne ze środowiskiem docelowym na poziomie bazy danych. Zgodne bazy danych to takie, w których wykonywane są te same migracje Entity Framework, czyli ostatni rekord w tabeli core.__EFMigrationsHistory ma tę samą wartość w kolumnie MigrationId w obu bazach. W szczególnych przypadkach może być możliwe migrowanie aplikacji między różnymi wersjami nAxiom. Odpowiednie informacje są publikowane w Informacjach o wersji.

Podczas importu konfiguracji dokonywanych jest szereg zmian na bazie danych. Zaleca się, aby w tym czasie ze środowiska docelowego nie korzystali inni użytkownicy, ani w aplikacji FrontSPA, ani w aplikacji AdminSPA.

Aby zaimportować konfigurację do bieżącego środowiska, kliknij przycisk Importuj do platformy w wierszu tej konfiguracji na ekranie Migrator aplikacji. Zostanie wyświetlone okno dialogowe z pytaniem o porównanie konfiguracji importowanej aplikacji z konfiguracją aplikacji w docelowej bazie danych.

W przypadku bardziej złożonych aplikacji ta operacja może zajmować dużo czasu, dlatego można ją pominąć, klikając przycisk Rozpocznij bez porównania. Po kliknięciu przycisku Porównaj zostanie wyświetlona lista tabel systemowych, w których w związku z importem zostaną zmienione rekordy. Rozwijając poszczególne pozycje, można szczegółowo analizować zmiany w wyniku importu. Kliknij przycisk Rozpocznij import u dołu. Przycisk Anuluj spowoduje przerwanie procesu.

Operacja importu jest realizowana w trybie asynchronicznym, to jest po rozpoczęciu importu użytkownik może przejść do innych zadań lub wylogować się.

W trakcie operacji importu zainicjowanej z poziomu AdminSPA nie można uruchomić kolejnego importu ani wyeksportować konfiguracji.

Aby odświeżyć status importu, należy kliknąć przycisk odświeżania listy widoczny na ekranie migratora.

W przypadku importowania aplikacji przez Public API, można zlecić kilka operacji importu, które zostaną dodane do kolejki.

W razie wystąpienia błędów operacja importu jest przerywana i żadne zmiany nie są dokonywane w bazie danych. Aby zaimportować konfigurację pomimo błędów importu, włącz przełącznik Pomiń błędy importu w ustawieniach środowiska (ADMINISTRACJA > Ustawienia systemu > Ogólne).

W przypadku decyzji o imporcie z pominięciem błędów konieczne jest wyświetlenie dziennika błędów (ADMINISTRACJA > Logi środowiska i bieżącego tenanta) i rozwiązanie wszystkich problemów napotkanych podczas importu.

Czynności wykonywane po imporcie

Po zaimportowaniu pliku .nax do nowego środowiska:

Wyczyścić pamięć podręczną; ADMINISTRACJA > Cache > Wyczyść cały cache.
Ustawić ścieżki w repozytoriach załączników. W przeciwnym razie utracone zostaną informacje o kategoriach załączników, zgodnie z uwagą powyżej; DANE > Repozytoria załączników.
Zmigrować dane biznesowe, których atrybuty uległy zmianie na skutek importu nowej definicji aplikacji; szczegóły opisano ponizej . Ta czynność dotyczy także tabel pomocniczych.

Migrator nie przenosi ustawień e-mail. W celu korzystania z wysyłki poczty może być konieczne skonfigurowanie ustawień e-mail (ADMINISTRACJA > Ustawienia systemu > Email). Następnie należy zrestartować komponent taskservice (Menedżer usług informacyjnych > Pule aplikacji > naxiom.nazwa_witryny.taskservice > Odtwarzanie).

Uprawnienia ról do menu podlegają migracji tylko w obrębie migrowanej aplikacji. Uprawnienia roli do menu z innych aplikacji zostaną zmigrowane tylko wtedy, gdy w witrynie docelowej będą te aplikacje.

Szczególne przypadki aktualizacji aplikacji

Migrator nAxiom obsługuje trzy rodzaje zmian w importowanej aplikacji, które w przypadku aktualizacji aplikacji wpływają na dane biznesowe w środowisku docelowym.

Pierwsza z nich dotyczy zmiany definicji kolumny w tabeli dokumentu biznesowego. Jeśli w środowisku docelowym ta kolumna zawiera dane, migrator zmieni jej nazwę na StaraNazwa_backup<timestamp>, a następnie utworzy nową kolumnę zgodną z nową specyfikacją. Po zakończeniu importu konieczne będzie przeniesienie danych z oryginalnej kolumny do nowej i usunięcie starej kolumny.

Jeśli w ramach aktualizacji aplikacji została usunięta kolumna w tabeli użytkownika, ta kolumna nie zostanie usunięta z aplikacji w środowisku docelowym, bez względu na to czy zawiera dane.

Druga funkcja ma na celu zabezpieczenie danych biznesowych w sytuacji, kiedy w migrowanej aplikacji usunięto status, typ biznesowy lub przejście na diagramie procesów, ale w docelowej bazie danych istnieją dokumenty, które mają ustawione te atrybuty. Na potrzeby obsługi takiego przypadku utworzono specjalną definicję dokumentu biznesowego — Dokument biznesowy usunięty przez migrator, z którą powiązano specjalny status i typ dokumentu biznesowego:

Status biznesowy usunięty przez migrator (kod: ErasedByAppMigration)
Typ biznesowy usunięty przez migrator (kod: ErasedByAppMigration)

Te wartości są używane do zastąpienia usuniętego statusu i/lub typu biznesowego w instancjach dokumentów w środowisku docelowym. Po migracji konsultant musi je zastąpić odpowiednimi wartościami.

Trzecia funkcja obsługuje przypadek usunięcia przejścia na diagramie procesu w importowanej aplikacji. Powoduje ona zastąpienie wszystkich wystąpień identyfikatora tego przejścia w kolumnie Transition w tabeli dokumentu biznesowego wartością NULL.

|← Import pliku licencji |↑ Do góry |→ Budowanie i debugowanie aplikacji nAxiom |