Replikacja repozytorium - jak to zrobić?

W poprzednim artykule o replikacji repozytorium wskazałem, kiedy warto zdecydować się na replikację repozytorium EAP. Podałem wady i zalety takiego rozwiązania oraz opisałem proponowany proces, który powinien moim zdaniem towarzyszyć tego typu pracy grupowej.

W tym miejscu opisuję temat replikacji od strony technicznej.


Proces replikacji wygląda tak, jak to przedstawia poniższy diagram.

Do replikacji repozytorium wykorzystywane są mechanizmy bazodanowe MS Jet. Każda replika posiada szereg dodatkowych pól, które są wykorzystywane do zarządzania replikacją. W tabelach dodawane są np. kolumny:

• s_GUID - dodatkowy GUID wykorzystywany przy synchronizacji,
• s_Generation - licznik zmian przyrostowych,
• s_Lineage - zawiera informacje identyfikatorze repliki i wersji rekordu.

Oznaczenie modelu jako Design Master

Pierwszym krokiem jest oznaczenie modelu jako Master. Aby to wykonać należy wybrać z menu Tools -> Data Management -> Manage .EAP file -> Make Design Master

Spowoduje to wprowadzenie zmian w strukturze pliku EAP.
Warto nadać taką nazwę temu plikowi EAP, aby móc go później łatwo rozróżnić od replik, jak również od innych wersji repozytorium. Można dodać np. przyrostek master oraz numer wersji.

Generowanie replik dla konkretnych użytkowników

Następnie z głównego pliku generujemy tyle replik, ilu użytkowników będzie brało udział w edycji modelu w danej iteracji. Aby to zrobić należy wybrać z menu Tools -> Data Management -> Manage .EAP file ->  Create New Replica...

Spowoduje to zapisanie na dysku nowego pliku EAP.
Warto nadać taką nazwę plikowi EAP, aby móc go później łatwo zidentyfikować. Można dodać np. przyrostek z inicjałami właściciela.

Synchronizacja replik

Po zakończeniu edycji przez użytkowników i po odesłaniu ich do administratora modelu następnym krokiem jest synchronizacja replik. Aby to zrobić należy wybrać z menu Tools -> Data Management -> Manage .EAP file ->  Synchronize Replicas...

Operacja ta powoduje jednoczesne naniesienie zmian w modelu głównym (Design Master), jak również w synchronizowanej replice.

Po zakończeniu synchronizacji EA wyświetla odpowiedni komunikat.

Jeśli podczas synchronizacji wykryto jakieś konflikty, wówczas wyświetlany jest komunikat o treści:

There are synchronization conflicts with replica <sciezka i nazwa pliku repliki>.

Open <sciezka i nazwa pliku repliki> to resolve these conflicts.

Co tak naprawdę dzieje się podczas synchronizacji?

Zmiany w modelu się kumulują. To znaczy, że jeśli na przykład w pierwszej replice dodano 5 klas, a w drugiej replice dodano również 5 klas, to po synchronizacji model będzie miał łącznie 10 nowych klas.
Obsługiwane są (bez konfliktów) zmiany tego samego elementu w dwóch replikach - przynajmniej w większości przypadków. Jeśli na przykład w replice 1. zostanie zmieniony opis klasy (pole Notes), a w replice 2. również zostanie zmieniony opis tej samej klasy, wówczas po synchronizacji obu replik opis klasy będzie taki, jaki był w replice synchronizowanej jako ostatniej (o ile zmieniła się w niej wartość opisu). Jeśli jako pierwszą synchronizowano replikę 1, a potem replikę 2, wówczas w modelu głównym wartość opisu będzie taka, jak w replice 2.
Usuwanie ma pierwszeństwo nad modyfikacją. Jeśli ten sam element był modyfikowany w jednej replice, a usunięty w drugiej, to zniknie z modelu głównego bez względu na kolejność synchronizacji replik.
Warto mieć również na uwadze, że synchronizacja repliki skutkuje naniesieniem zmian zarówno w modelu głównym, jak i w replice. Zatem warto na wszelki wypadek pozostawić sobie kopie replik w stanie sprzed synchronizacji.

Rozwiązywanie konfliktów synchronizacji

Myślę, że nie da się zupełnie wykluczyć ryzyka powstawania konfliktów synchronizacji, jednak można to znacząco ograniczyć poprzez odpowiednią organizację pracy.
Po otwarciu repozytorium EAP repliki - zgodnie ze wskazówką z poprzedniego komunikatu - wybieramy z menu Tools -> Data Management -> Manage .EAP file ->  Resolve Replication Conflicts...

Po wywołaniu tej opcji zostanie wyświetlone następujące okno.

Informacje wyświetlone w tym oknie niestety nie są szczególnie czytelne. Podane jest:

• wskazanie na tabelę repozytorium - w tym przykładzie jest to tabela t_diagram, zawierająca dane diagramów,
• wskazanie na wiersz w tej tabeli (Conflicting Records),
• wskazanie na kolumny w tym wierszu, których wartości nie udało się automatycznie zsynchronizować (Conflict Details).

Z przyczyn technicznych nie jest niestety możliwe wyświetlenie różnic w takiej postaci, jak w oknie Model Compare (Show Differencies). Dobrze chociaż, że po kliknięciu prawym przyciskiem na wiersz w sekcji Conflicting Records możliwe jest automatyczne wyszukanie takiego elementu, pakietu czy diagramu w oknie Project Browser. 

Jak administrator modelu ma rozwiązywać takie konflikty?

Jeśli już dojdzie do sytuacji, w której dwóch różnych użytkowników w dwóch replikach zmodyfikowało ten sam obiekt, wówczas może być potrzebna konsultacja z tymi użytkownikami, aby móc zdecydować czyje zmiany powinny znaleźć się w modelu głównym.

Gdyby w wyniku synchronizacji utracone zostałyby małe ilości danych, np. fragment opisu elementu, położenie elementu na diagramie itp - wówczas wskazanym rozwiązaniem jest ponowne uwzględnienie tych zmian w modelu głównym poprzez ręczną edycję. 

Gdyby w wyniku synchronizacji utracone zostałyby duże ilości danych, wówczas w ostateczności można dokonać eksportu zawartości pakietu z repliki do pliku XMI oraz import takiego pliku do modelu głównego.

Warto jednak mieć na uwadze, że większości problemów z synchronizacją można uniknąć poprzez odpowiednią organizację pracy administratora modelu oraz całego zespołu.

Kolejna iteracja

Aby rozpocząć nową iterację teoretycznie możliwe jest odesłanie tych samych plików EAP (zawierających repliki), które zostały zsynchronizowane, gdyż mogą zawierać zmiany dokonane przez pozostałych użytkowników. Jednak, aby mieć pewność, że zawartość replik jest prawidłowa i taka sama należy wygenerować nowe repliki i odesłać je użytkownikom.