System Zarządzania Forte Replikacja. Dokumentacja wdrożeniowa Wersja 2012

Transkrypt

1 System Zarządzania Forte Replikacja Dokumentacja wdrożeniowa Wersja 2012

2 System Zarządzania Forte - Replikacja Strona 2 z 39 SPIS TREŚCI 1 Wstęp PRZEZNACZENIE DOKUMENTU STAN WYJŚCIOWY STAN DOCELOWY WERYFIKACJA System Zarządzania Forte z Common Data SŁOWNIK POJĘĆ OPIS ROZWIĄZANIA PRZEJŚCIE NA ARCHITEKTURĘ COMMON DATA PRACA Z APLIKACJAMI FORTE W MODELU COMMON DATA Rozpoczęcie pracy w modelu Common Data NARZĘDZIA UTWORZENIE BAZY COMMON DATA UZGODNIENIE GUID ÓW ZASILENIE BAZY COMMON DATA DANYMI POWIĄZANIE BAZ MIRROR Z COMMON DATA INSTALACJA LUB URUCHOMIENIE USŁUGI HR2CD INSTALACJA I URUCHOMIENIE USŁUGI REPLIKACJI W TLE KONFIGURACJA USTAWIEŃ WSPÓŁPRACY Z FK W MODUŁACH BIZNESOWYCH SYSTEMU FORTE Dołączenie kolejnej bazy aplikacyjnej do już pracującego systemu DOŁĄCZENIE NOWOUTWORZONEJ BAZY APLIKACYJNEJ DOŁĄCZENIE SKONWERTOWANEJ BAZY APLIKACYJNEJ Szczegółowe informacje o serwisie HR2CD DANE KDF A DANE COMMON DATA SERWIS HR2CD URUCHAMIANIE SERWISU W MODULE KDF URUCHAMIANIE USŁUGI HR2CD DEINSTALACJA USŁUGI HR2CD URUCHOMIENIE SERWISU PRZED UZGADNIANIEM GUID ÓW ŚLEDZENIE WYNIKU EKSPORTU DANYCH KADROWYCH PRACOWNIKÓW SPIS DANYCH KADROWYCH EKSPORTOWANYCH DO DANYCH WSPÓLNYCH Szczegółowe informacje o aplikacji Guider WYBÓR BAZ DANYCH POTWIERDZENIE KONTYNUACJI PROCESU UZGADNIANIA GUID ÓW... 32

3 System Zarządzania Forte - Replikacja Strona 3 z ZARZĄDZANIE KRYTERIAMI PROCES WYSZUKIWANIA GUID ÓW OPERACJA NADPISYWANIA GUID ÓW Czynności serwisowe KONWERSJA BAZ W REPLIKACJI CZYNNOŚCI DO WYKONANIA W CELU DOSTOSOWANIA SYSTEMU Z COMMON DATA PO ZMIANIE HASEŁ UŻYTKOWNIKOM SQL WYKONYWANIE I ODTWARZANIE KOPII BEZPIECZEŃSTWA BAZ COMMON DATA I MIRROR CZYNNOŚCI DO WYKONANIA W CELU USUWANIA KONTRAHENTÓW, PRACOWNIKÓW, OSÓB, SŁOWNIKÓW I ICH ELEMENTÓW... 39

4 System Zarządzania Forte - Replikacja Strona 4 z 39 1 Wstęp 1.1 Przeznaczenie dokumentu Dokument jest przeznaczony dla osób administrujących Systemem Forte w przedsiębiorstwie i osób implementujących system, mających zaawansowaną wiedzę zarówno z zakresu działania przedsiębiorstwa, procesów w nim zachodzących jak i administracji systemami z rodziny MS Windows oraz MS SQL Server 2005/2008. Dokument jest instrukcją wdrożeniową opisującą przejście z trybu pracy, w którym System Zarządzania Forte pracuje na osobnych bazach (czyli de facto na osobnych kartotekach i słownikach) do trybu, w którym system do uwspólnienia kartotek wykorzystuje bazę Common Data. W rozdziale Czynności serwisowe przedstawiony został zakres działań umożliwiający przeprowadzenie poprawnej konwersji baz w replikacji do wersji 2012 Systemu Forte. 1.2 Stan wyjściowy Bazy Systemu Forte: Finanse i Księgowość Forte 2012, Handel Forte 2012, Kadry i Płace Forte 2012, Środki Trwałe Forte 2012, zawierające tożsame kartoteki kontrahentów, pracowników, osób oraz słowniki i ich elementy. Bazy powinny być zsynchronizowane po konwersji do wersji Uruchomiona usługa Serwera Globalnej Konfiguracji: Forte.GlobalServer. 1.3 Stan docelowy Cztery bazy Forte 2012 ze wspólnymi kontrahentami, pracownikami, osobami, słownikami i elementami słowników oraz baza Common Data przechowująca aktualną i obowiązującą wersję obiektów wspólnych. 1.4 Weryfikacja Rezultat każdego z etapów powinien być weryfikowany pod względem poprawności wykonanych procesów oraz stanu baz danych, a także kompletności kartotek, słowników oraz ich elementów biorących udział w procesie wdrożenia. Należy zwracać szczególną uwagę na wszelkie komunikaty informujące o niepowodzeniach, błędnych danych lub konfliktach zaistniałych np. podczas replikacji poszczególnych obiektów. W każdym z rozdziałów opisującym poszczególne etapy procesu zawarta jest dodatkowa informacja o sposobie zweryfikowania czy etap przebiegł i zakończył się bez błędów. UWAGA! W wielu miejscach tego dokumentu pojawiają się przykłady lub odwołania do elementów zawierających w nazwie numer wersji Forte Common. Została zatem zastosowana notacja literowa A.B.C.D lub A_B z kolorystycznym podkreśleniem, a użytkownik dokumentacji i systemu powinien w miejsce liter zastosować odpowiednie cyfry posiadanej wersji Forte Common.

5 System Zarządzania Forte - Replikacja Strona 5 z 39 2 System Zarządzania Forte z Common Data 2.1 Słownik pojęć Common Data Mirror Dane wspólne GUID Baza danych przechowująca obowiązującą i aktualną wersję danych wspólnych Baza danych aplikacji Forte, zawierająca kopię danych Common Data do wykorzystania lokalnie przez rozwiązania aplikacji Kontrahenci, pracownicy, osoby, słowniki, elementy słowników Global Unique IDentifier, globalnie unikalny identyfikator instancji danych obiektu Konfiguracja globalna Miejsce przechowywania ustawień modułów Forte 2012 Replikacja Proces przenoszenia obiektów między modułami Forte Opis rozwiązania System Forte w wersji 2012 zapewnia automatyczny proces replikacji danych wspólnych. Proces: jest transparentny dla użytkownika modułów Forte, działa w tle, niezależnie od działania instancji modułów Forte, podlega zarządzaniu w zakresie uruchomienia/zatrzymania, nie jest konfigurowalny pod kątem wrażliwości na dane replikowane. Automatyzacja procesu wymaga: istnienia bazy Common Data, zainstalowania i uruchomienia jednej instancji usługi Forte.GlobalServer, skojarzenia baz danych Mirror z dokładnie jedną bazą Common Data. Common Data pełni rolę wspólnej bazy w zakresie elementów wspólnych dla baz aplikacyjnych Systemu Forte. Oznacza to, że w zakresie danych tylko i wyłącznie w bazie Common Data istnieją aktualne i obowiązujące informacje w danej instalacji Systemu Forte W bazach aplikacyjnych Mirrory dane wspólne są jedynie aktualizowane. UWAGA: Mechanizmy replikacji Systemu Forte 2012 zaprojektowane zostały do pracy z bazami różnych modułów, tzn. że niezalecana jest replikacja dwóch baz, w których uruchomiono ten sam moduł biznesowy.

6 System Zarządzania Forte - Replikacja Strona 6 z 39 FKF Mirror 2. Zapis do klienta gdy powiodło się 1. Modyfikacja danych wspólnych z klienta FKF KDF Mirror Automatyczna replikacja w tle z COMMON DATA do FKF 1. Zapis do Common Data COMMON DATA Automatyczna replikacja w tle z COMMON DATA do KDF HMF Automatyczna replikacja w tle z COMMON DATA do HMF Automatyczna replikacja w tle z COMMON DATA do STF STF Mirror Mirror Techniczne: Wszelkie zmiany danych wspólnych zachodzą NAJPIERW w bazie Common Data i jeśli się powiodą, stają się obowiązujące w systemie i jako takie są BEZWARUNKOWO propagowane do baz Mirror. Każda baza Mirror jest jednoznacznie powiązana z jej właściwą bazą Common Data. W systemie Forte może być wiele baz Common Data. Jedna baza Mirror może być skojarzona TYLKO z jedną bazą Common Data. Baza nie może jednocześnie być bazą Mirror i bazą Common Data. W globalnej konfiguracji systemu Forte przechowywane są wskazania na wszystkie zarejestrowane bazy, które zostały wskazane jako Common Data. Aplikacje korzystające z baz powiązanych z Common Data nie mogą pracować jeśli nie będzie zapewniony dostęp do bazy Common Data. Replikacja dla jednej bazy Common Data odbywa się sekwencyjnie dla kolejnych baz Mirror i odbywa się w tle. Poszczególne bazy Mirror można odłączać od bazy Common Data w celu wykonania czynności serwisowych (kopie zapasowe/odtwarzanie). Techniczne: Rozwiązanie zapewnia obsługę sytuacji odtworzenia z backupu bazy Mirror (czyli sytuacja gdy pojawia się baza Mirror, która ma dane STARSZE niż baza Common Data). Rozwiązanie zapewnia również obsługę sytuacji gdy z backupu odtwarzana jest baza Common Data (czyli sytuacja gdy okazuje się, że baza Common Data zawiera dane starsze niż bazy Mirror) i jako proces PRZECIWNY do założeń architektury jest to proces nietrywialny, serwisowy.

7 System Zarządzania Forte - Replikacja Strona 7 z Synchronizacja czasu Architektura środowiska pracy z Common Data wymaga synchronizacji czasu w sieci lokalnej użytkownika. Nawet zwykła praca wielu użytkowników tej samej aplikacji na jednej bazie niesie za sobą konieczność użycia zsynchronizowanego czasu do oznaczania daty i czasu wykonania poszczególnych funkcjonalności biznesowych. Końcówki używające Forte Common i serwisu synchronizacji czasu wykonują synchronizację czasu wg tzw. strategii. Domyślna strategia synchronizacji jest ustalana przy uruchamianiu instancji Forte Common. Polega na ustaleniu, które źródła synchronizacji są osiągalne poprzez sprawdzenie możliwości synchronizacji z tym źródłem. Strategia synchronizacji czasu dla klienta Forte Common niepełniącego roli Serwera Konfiguracji Globalnej: A. Tryb pracy w scenariuszu z Common Data: a. Serwis Konfiguracji Globalnej (zaufany o ile zsynchronizowany)* b. Inne końcówki w sieci przez rozgłoszenie sieciowe (Broadcast) (zaufane o ile zsynchronizowane)* c. Internetowe Serwery NTP (zaufany) d. Domenowy serwer czasu (zaufany)** e. Zewnętrzne źródła czasu (np. SQL Server) f. Lokalny zegar komputera (czyli bez synchronizacji) (NIEZAUFANY)*** B. Tryb pracy w scenariuszu bez Common Data: a. Serwis Konfiguracji Globalnej (zaufany o ile zsynchronizowany)* b. Internetowe Serwery NTP (zaufany) c. Inne końcówki w sieci przez rozgłoszenie sieciowe (Broadcast) (zaufane o ile zsynchronizowane)* d. Zewnętrzne źródła czasu (np. SQL Server) e. Domenowy serwer czasu (zaufany)** f. Lokalny zegar komputera (czyli bez synchronizacji) (NIEZAUFANY)*** Strategia synchronizacji czasu dla maszyny pełniącej rolę Serwera Konfiguracji Globalnej: a. Internetowe Serwery NTP (zaufany) b. Lokalny zegar komputera (czyli bez synchronizacji) (NIEZAUFANY)*** Legenda: * - jeżeli instancja nie jest zsynchronizowana, nie powinna brać udziału w dalszej propagacji czasu ** - zaufany tylko wtedy, gdy nie ma innych wcześniejszych źródeł czasu, a pracujemy w domenie *** - lokalny czas jest domyślnie NIEZAUFANY Ustalone scenariusze są zapamiętywane i używane podczas kolejnych synchronizacji odbywających się automatycznie w tle. Jeżeli podczas synchronizacji wybrany scenariusz nie powiedzie się, serwis czasu przejdzie do następnego scenariusza w kolejce aż do momentu wyczerpania listy. Wtedy synchronizacja czasu nie ma miejsca w bieżącym podejściu. Będzie możliwa dopiero przy kolejnej próbie). 2.3 Przejście na architekturę Common Data Przejście na architekturę Common Data jest procesem składającym się z TRZECH ETAPÓW: 1. Konwersja do wersji 2012 i uzgodnienie danych wspólnych przy pomocy istniejących mechanizmów: a. Jest to krytyczna część procesu z punktu widzenia powodzenia całości przedsięwzięcia. Dobrze wykonana pozwoli na łatwą realizację następnych etapów, źle wykonana może następne etapy uczynić niemożliwymi do realizacji.

8 System Zarządzania Forte - Replikacja Strona 8 z 39 b. Konwersję baz aplikacji wykonuje moduł administracyjny poprzez dołączenie i otwarcie firmy. c. Proces uzgadniania danych obiektów wspólnych należy wykonać poprzez pełną synchronizację (ze zmianą ujednolicającą wszystkie dane), przy użyciu istniejących mechanizmów synchronizacji. Bezwzględnie w module HMF należy wykonać synchronizację pracowników, aby uzupełnić numery NIP, PESEL. Należy zwrócić uwagę na takich pracowników, którzy mają w module KDF dwa imiona. Przed przystąpieniem do łączenia baz należy poprawić dane pracowników, tak by w polu Imię było tylko pierwsze imię oraz należy zwrócić uwagę na takich pracowników, którzy w module KDF mają dwuczłonowe nazwiska, a pozostałych tylko pierwszy człon nazwiska. Tacy pracownicy zostaną uznani przez system jako różni. Dlatego należy ujednolicić ich dane we wszystkich modułach. 2. Uzgodnienie globalnych identyfikatorów dla tożsamych instancji obiektów i replikacja danych do Common Data: a. Proces uzgadniania wykonuje się przy użyciu aplikacji Guider.exe. b. Proces uzgodnienia danych wspólnych pomiędzy więcej niż dwiema bazami systemu Forte należy przeprowadzać dla par baz w kolejności uzasadnionej preferencjami klienta co do istotności instancji danych wspólnych w poszczególnych bazach systemu Forte. c. Proces uzgadniania danych wspólnych dotyczy zawsze dwóch baz, jedna jest wyróżniona jako nadrzędna (powinna to być baza pełniąca rolę Common Data), co oznacza że w niej GUID y nie będą zmieniane, druga jest oznaczona jako podrzędna (baza Mirror), co oznacza, że to w niej będą zmieniane GUID y tych instancji obiektów, które zostaną uznane za tożsame z istniejącymi instancjami w bazie nadrzędnej. i. Należy ustalić najliczniejszy zasób danych wspólnych uzgadnianych ii. Wybrać bazę systemu Forte gdzie ten zasób jest najliczniej i/lub najlepiej reprezentowany z punktu widzenia klienta iii. Utworzyć bazę Common Data: 1. Z backupu wybranej bazy lub 2. Utworzyć nową Common Datę, a następnie wykonać replikację z bazy wybranej w punkcie ii. w celu napełnienia Common Data danymi iv. Wykonać proces uzgadniania GUID ów następnej bazy Mirror z bazą Common Data a następnie wykonać replikację z uzgodnionej bazy Mirror do bazy Common Data, v. Punkt iv. powtórzyć dla kolejnych baz Mirror. d. Przed przystąpieniem do uzgadniania należy bezwzględnie wykonać poprawne pełne kopie zapasowe obu baz danych Techniczne: uzgodnienie polega na sporządzeniu w bazie podrzędnej listy par GUID ów obiektów w postaci <GUID_istniejacy, GUID_uzgodniony>. Zastosowanie uzgodnień polega na zmianie wszystkich wartości GUID_istniejący na sparowane z nimi GUID_uzgodniony. Zarówno proces uzgadniania, jak i proces zastosowania uzgodnień, to procesy długotrwałe porównywalne z konwersją. Wykonują znaczące zmiany na bazie danych, dlatego warto wykonać kopię zapasową PO etapie uzgodnienia, aby w przypadku awarii nie powtarzać całego procesu a tylko część zastosowania uzgodnień (zmian GUID ów). 3. Konfiguracja i uruchomienie replikacji w tle (z bazy Common Data do baz Mirror): a. Połączenie baz Mirror z bazą Common Data b. Uruchomienie usługi replikacji

9 System Zarządzania Forte - Replikacja Strona 9 z Praca z aplikacjami Forte w modelu Common Data Aplikacja Forte pracująca na bazie Mirror do działania wymaga istnienia i dostępności bazy Common Data. W przypadku, gdy Common Data z jakiegoś powodu nie będzie dostępna, aplikacja nie rozpocznie pracy na bazie Mirror, informując użytkownika odpowiednim komunikatem. Gdy pomiędzy Common Data a Mirrorem będą trwały procesy/replikacje serwisowe (np. po odtworzeniu z backupu Mirrora lub Common Data), zaleca się niekorzystanie z aplikacji biznesowych Systemu Forte. Aplikacje Forte (FKF, HMF, KDF, STF) na czas wdrożenia powinny być zamknięte na wszystkich stacjach klienckich.

10 System Zarządzania Forte - Replikacja Strona 10 z 39 3 Rozpoczęcie pracy w modelu Common Data Aby ze stanu wyjściowego osiągnąć stan, w którym cztery aplikacje mogą pracować na wspólnych obiektach, należy przeprowadzić szereg czynności pozwalających na uzgodnienie danych, replikację tych danych do bazy Common Data oraz powiązanie baz aplikacyjnych z bazą Common Data. 3.1 Narzędzia Narzędzia niezbędne do wdrożenia replikacji dostępne są po zainstalowaniu Forte.Replication.msi. W katalogu: %COMMONPROGRAMFILES%\Sage\Forte\Forte.Common_A.B.C.D\ lub dla systemów 64-bitowych: %COMMONPROGRAMFILES(x86)%\Sage\Forte\Forte.Common_A.B.C.D\ znajdziemy: 1. Guider aplikacja okienkowa przeznaczona do uzgadniania GUID ów obiektów w bazie Mirror z tożsamymi obiektami w bazie Common Data. 2. Cdconf aplikacja uruchamiana z linii poleceń systemu operacyjnego pozwalająca na zarządzanie bazami pracującymi w modelu z bazą Common Data. 3. Replicator aplikacja uruchamiana z linii poleceń systemu operacyjnego służąca do napełnienia bazy Common Data danymi z baz Mirror. 4. ForteSrv aplikacja instalująca usługę replikacji w tle oraz usługę HR2CD. 5. HR2CD usługa umożliwiająca eksportowanie danych kadrowych z tabel programu Kadry i Płace do danych wspólnych (Common Data). 6. ForteRepl usługa wykonująca replikację danych wspólnych systemu Forte 2012 z bazy Common Data do baz Mirror. 3.2 Utworzenie bazy Common Data Bazę Common Data można utworzyć na dwa sposoby: Pierwszy polega na wykonaniu backup u jednej z baz aplikacyjnych i odtworzeniu go na serwerze jako nowej bazy przeznaczonej na bazę Common Data. Tak sporządzoną bazę należy oznaczyć jako Common Data przy pomocy narzędzia CDCONF i akcji PCD. Zaletą rozwiązania jest to, że tak utworzona baza Common Data posiada już dane wspólne z jednej z baz i nie trzeba ich przenosić do bazy wspólnej. Wystarczy replikacja z pozostałych baz aplikacyjnych do bazy Common Daty. Wadą tego rozwiązania jest fakt, że w bazie znajdują się tabele utworzone przez aplikacje biznesowe Forte, a nieużywane przez mechanizmy Forte Common, niepotrzebnie zwiększając rozmiar bazy. Drugi sposób polega na utworzeniu nowej bazy Common Data za pomocą narzędzia CDCONF i akcji PCD. Zaletą takiego rozwiązania jest to, że utworzona baza posiada tylko niezbędne do jej użycia dane.

11 System Zarządzania Forte - Replikacja Strona 11 z 39 Utworzona za pomocą tego polecenia baza w konfiguracji globalnej oznaczona jest jako baza Common Data. Tworzenie nowej bazy Common Data: Należy uruchomić aplikację CDCONF z katalogu: %COMMONPROGRAMFILES%\Sage\Forte\Forte.Common_A.B.C.D\ lub dla systemów 64-bitowych: %COMMONPROGRAMFILES(x86)%\Sage\Forte\Forte.Common_A.B.C.D\ z następującymi parametrami: CDCONF -a:pcd -s:serwer -b:baza [-alias:alias] [/u] [-Alogin:login] [-Apwd:pwd] [-Ulogin:login] [-Upwd:pwd] [ [-appulogin:login] [-appupwd:pwd] ] [/i] Przełączniki dla akcji PCD: -s: nazwa serwera (wymagane) -b: nazwa bazy (wymagane) -alias: określenie aliasu jaki nabędzie baza w konfiguracji globalnej -Alogin: login użytkownika SSDBAdmin na serwerze -Apwd: hasło użytkownika SSDBAdmin na serwerze -Ulogin: login użytkownika SSDBUser na serwerze -Upwd: hasło użytkownika SSDBUser na serwerze -appulogin: login administratora praw w aplikacji (ignorowany jeśli /i) -appupwd: hasło administratora praw w aplikacji (ignorowany jeśli /i) /i zintegrowane logowanie istniejącego admina praw w aplikacji /u zezwala na konwersje wskazanej bazy do aktualnej wersji Parametry logowania SSDBAdmina, SSDBUsera oraz administratora praw mogą być pominięte. Wówczas nastąpi próba dostępu i zalogowania na danych domyślnych. Jeśli tworzymy nową bazę parametry: -appulogin i appupwd należy pominąć. Szczegółowe informacje na temat wszystkich funkcji narzędzia CDCONF uzyskamy przy pomocy polecenia: CDCONF bez parametrów, lub CDCONF /? (dla większej ilości szczegółów) Weryfikacja Stan oczekiwany: Na serwerze SQL powinna zostać utworzona baza o nazwie zdefiniowanej przez użytkownika. Informacja o tej bazie powinna znaleźć się w konfiguracji globalnej.

12 System Zarządzania Forte - Replikacja Strona 12 z 39 Sposób sprawdzenia: Weryfikacja czy na wskazanym serwerze SQL istnieje tworzona baza oraz czy zawiera tabele Forte.Common. Aby sprawdzić, czy informacja o bazie Common Data została zapisana w konfiguracji globalnej, należy użyć CDCONF a z parametrem a:lcd: CDCONF -a:lcd W rezultacie użytkownik powinien uzyskać informację w postaci: cdconf -a:lcd Otwieranie sesji... OK Entering instance... OK Odczyt lusterek DETACHED dla bazy VPC2009.cdata Otwieranie sesji... OK Entering instance... OK Wykrywanie S.Common... Wykryto. OK Wejście do firmy... OK Exiting instance... OK Zamykanie sesji... OK Lista baz CommonData w systemie: Lp. Serwer Baza Alias VPC2009 cdata VPC2009.cdata Lista baz aplikacyjnych w systemie i ich baz Common: Lp. Serwer Baza Alias bazy Common Detached? Exiting instance... OK Zamykanie sesji... OK Program pomyślnie zakończył działanie. 3.3 Uzgodnienie GUID ów Cel: jednoznaczna identyfikacja tożsamych kontrahentów, pracowników i osób przed replikacją kolejnych obiektów do bazy Common Data. Uwaga: Niepoprawna identyfikacja tożsamych elementów kartotek może prowadzić do problemów przy replikacjach z baz Mirror do bazy Common Data. Do uzgadniania globalnych identyfikatorów służy aplikacja o nazwie Guider. Proces uzgadniania powinien być przeprowadzony pomiędzy dwiema bazami, gdzie bazą nadrzędną powinna być Common Data a bazą podrzędną baza Mirror. Uzgadnianie GUID ów odbywa się przy wykorzystaniu definiowalnych reguł porównujących dane kartotek. Sage sp z o.o. dostarcza plik z domyślnymi regułami, jednak reguły te mogą okazać się zbyt ogólne. Dlatego zaleca się dostosowanie ich do specyfiki grupy baz danych oraz indywidualnych potrzeb klienta.

13 System Zarządzania Forte - Replikacja Strona 13 z 39 Uwaga: Jeśli jedną z baz Mirror jest baza programu Kadry i Płace Forte, przed przystąpieniem do procesu uzgadniania GUID ów zaleca się uruchomienie usługi HR2CD Uzgadnianie kontrahentów Domyślnie kontrahent z bazy podrzędnej uznany zostanie za tożsamy z kontrahentem z bazy nadrzędnej jeśli spełnią następujące warunki: lub: Mają takie same, ale niepuste numery NIP Mają takie same Nazwy Mają takie same Skróty Mają takie same Miejscowości adresu Mają puste numery NIP Mają takie same, ale niepuste numery REGON Mają takie same Nazwy Mają takie same Skróty Mają takie same Miejscowości adresu Natomiast kontrahent z bazy podrzędnej z kontrahentem z bazy nadrzędnej zostanie skierowany do rozstrzygnięcia tożsamości przez użytkownika jeśli spełnione zostaną następujące warunki: lub Mają takie same Nazwy Mają takie same Skróty Kontrahenci, którzy nie spełnią żadnego z powyższych kryteriów, zostaną uznani za różnych. Uwaga: Jeśli kontrahent z bazy podrzędnej zostanie uznany za tożsamy z kontrahentem z bazy nadrzędnej i obaj mają osoby kontaktowe, to jeśli te osoby kontaktowe mają takie same Imię i Nazwisko to także zostaną uzgodnione Uzgadnianie pracowników Domyślnie pracownik z bazy podrzędnej uznany zostanie za tożsamy z pracownikiem z bazy nadrzędnej jeśli spełnią następujące warunki: lub: Mają takie samo Imię i Nazwisko Mają takie same, ale niepuste numery NIP Mają takie same Miejscowości adresu osoby Mają takie samo Imię i Nazwisko Mają pusty numer NIP Mają takie same, ale niepuste numery PESEL Mają takie same Miejscowości adresu osoby Natomiast pracownik z bazy podrzędnej z pracownikiem z bazy nadrzędnej zostanie skierowany do rozstrzygnięcia tożsamości przez użytkownika jeśli spełnione zostaną następujące warunki: Mają takie samo Imię i Nazwisko lub Mają takie same Identyfikatory unikalne Pracownicy którzy nie spełnią żadnego z powyższych kryteriów zostaną uznani za różnych.

14 System Zarządzania Forte - Replikacja Strona 14 z 39 Uwaga: Istnienie w bazie danych pracownika determinuje istnienie osoby w roli Pracownik. Jeśli pracownik z bazy podrzędnej zostanie uznany za tożsamego z pracownikiem z bazy nadrzędnej, to również osoby powiązane z tymi pracownikami automatycznie zostaną uznane za tożsame Uzgadnianie osób Aby przejść do uzgadniania osób, należy najpierw rozstrzygnąć tożsamość kontrahentów i pracowników. Domyślnie osoba z bazy podrzędnej uznana zostanie za tożsamą z osobą z bazy nadrzędnej jeśli spełnią następujące warunki: i Mają takie samo Imię i Nazwisko i. Mają równy atrybut Jest osobą kontaktową i ii. mają równy atrybut Jest pracownikiem i iii. mają równy atrybut Jest użytkownikiem Natomiast osoba z bazy podrzędnej z osobą z bazy nadrzędnej zostanie skierowana do rozstrzygnięcia tożsamości przez użytkownika jeśli spełnione zostaną następujące warunki: i Mają takie samo Nazwisko i. Mają równy atrybut Jest osobą kontaktową lub ii. mają równy atrybut Jest pracownikiem lub iii. mają równy atrybut Jest użytkownikiem Osoby które nie spełnią żadnego z powyższych kryteriów zostaną uznane za różne. Uwaga: Jeśli zajdzie potrzeba uznania osób z bazy STF (pełniących w aplikacji rolę osób odpowiedzialnych) za tożsame z osobami z bazy Common Data z atrybutem Jest pracownikiem, to kryteria rozstrzygnięć powinny być do tego celu odpowiednio dostosowane. Uruchomienie aplikacji: Należy uruchomić aplikację Guider.exe z katalogu: %COMMONPROGRAMFILES%\Sage\Forte\Forte.Common_A.B.C.D\ lub dla systemów 64-bitowych: %COMMONPROGRAMFILES(x86)%\Sage\Forte\Forte.Common_A.B.C.D\ Po wyszukaniu tożsamych obiektów i uzgodnieniu GUID ów na parze baz, można przystąpić do replikacji elementów z bazy Mirror do bazy Common Data Weryfikacja a) Weryfikacja par elementów uznanych za tożsame: Lista par elementów uznanych za tożsame zapisana jest w tabeli STAgreedGUIDsPairs w bazie podrzędnej, gdzie kolumna Master to GUID y obiektu z bazy nadrzędnej, Local to GUID y obiektu z bazy podrzędnej (lokalnej), Folder to rodzaj obiektu, State to stan rozstrzygnięcia (gdzie 0

15 System Zarządzania Forte - Replikacja Strona 15 z 39 nierozstrzygnięte, 1 różne, 2 tożsame, 3 numery GUID obiektu zostały już nadpisane), oraz data modyfikacji w kolumnie ST_last_modified. b) Weryfikacja po uzgodnieniu globalnych identyfikatorów: Globalne identyfikatory (GUID) tożsamych obiektów powinny być identyczne na poziomie elementów kartotek oraz elementów słowników. Sposób sprawdzenia: Sprawdzićczy GUID y tożsamych obiektów w tabelach STContractors, STEmployees, STPersons, STElements są takie same. Więcej informacji o aplikacji GUIDER można znaleźć w rozdziale 6. Uwaga: Jeśli jedną z baz Mirror jest baza programu Kadry i Płace Forte, przed przystąpieniem do procesu uzgadniania GUID ów zaleca się uruchomienie usługi HR2CD usługi HR2CD Jeśli jedną z baz Mirror jest baza programu Kadry i Płace Forte przed przystąpieniem do procesu uzgadniania GUID ów zaleca się uruchomienie usługi HR2CD, ponieważ program Kadry i Płace przechowuje w bazie dane kadrowe pracowników w okresie od daty do daty, natomiast baza Common Data posiada dane na dzień bieżący. Potrzebny jest serwis biznesowy pozwalający na wyeksportowanie danych kadrowych z tabel programu Kadry i Płace do danych wspólnych (do bazy Common Data) obowiązujących w danym dniu, ale tylko tych, które uległy zmianie od ostatniego eksportu. Eksport danych powinien odbywać się każdego dnia o określonej porze (im wcześniej tym lepiej, np. o godzinie 00:00:00) dla wszystkich pracowników, aż do wyeksportowania wszystkich zmienionych danych. Przed przystąpieniem do uruchomienia usługi HR2CD należy wykonać polecenie: cdconf.exe a:pmr sapp:serwer bapp:baza appulogin:login administratora praw appupwd:hasło administratora które przygotuje bazę KDF do współpracy z usługą HR2CD. Zakłada użytkownika synchronizacyjnego oraz zapisuje informacje w konfiguracji bazy oraz w konfiguracji globalnej. 1 Następnie należy uruchomić usługę HR2CD na komputerze, na którym działa usługa serwera globalnej konfiguracji ForteSrv. Instalowanie serwisu: Serwis MS Windows instaluje się narzędziem z wiersza poleceń: %COMMONPROGRAMFILES%\Sage\Forte\Forte.Common_A.B.C.D\ lub dla systemów 64-bitowych: %COMMONPROGRAMFILES(x86)%\Sage\Forte\Forte.Common_A.B.C.D\ ForteSrv.exe ihr2cd serwer.baza czas gdzie: serwer adres serwera SQL z bazą KDF baza nazwa bazy danych KDF na serwerze 1 Więcej o aplikacji cdconf.exe w punkcie 3.2, 3.5 oraz w helpie do cdconf.exe wywoływanym z linii poleceń.

16 System Zarządzania Forte - Replikacja Strona 16 z 39 Parametr czas to czas rozpoczęcia eksportu każdego dnia. Należy go podawać w formacie gg:mm:ss Czas rozpoczęcia eksportu jest opcjonalny. Domyślny czas: 00:15:00. Pozostałe parametry (nazwa użytkownika i hasło Serwera SQL, nazwa użytkownika i hasło aplikacji) pobierane są z konfiguracji globalnej lub lokalnej w przypadku braku tej pierwszej. Uwaga: Po zakończeniu eksportu pracowników należy zatrzymać lub odinstalować usługę HR2CD. Odinstalowanie usługi: ForteSrv.exe uhr2cd serwer.baza gdzie: serwer adres serwera SQL z bazą KDF baza nazwa bazy danych KDF na serwerze Weryfikacja Stan oczekiwany: Dane kadrowe pracownika zapisane w tabelach SSCommon, uaktualniane wraz ze zmianami w module kadrowo-płacowym. Sposób sprawdzenia: a) W dzienniku zdarzeń systemowych (Event Viewer) w katalogu Application zapisują się informacje o błędach działania i akcjach wykonywanych przez serwis HR2CD, np.: Serwis pozostanie uśpiony przez 11:55: do czasu :15:00., Baza:serwer.baza_kdf, czas globalny: ' :19:26' Zakończono eksport danych pracowników, porównanych: 44, wyeksportowanych: 0, Baza:serwer.baza_kdf, czas globalny: ' :19:26' Rozpoczęto eksport danych pracowników, Baza:serwer.baza_kdf, czas globalny: ' :19:22' Serwis został uruchomiony poprawnie, Baza:serwer.baza_kdf, czas globalny: ' :19:22' Więcej informacji o serwisie HR2CD można znaleźć w rozdziale Zasilenie bazy Common Data danymi Baza Common Data została utworzona ale nie zawiera żadnych danych wspólnych. Dane te należy do niej dodać z baz, które docelowo mają pełnić rolę baz Mirror. Jeśli w bazie Common Data są już obiekty zreplikowane z pierwszej bazy Mirror lub została ona utworzona na podstawie istniejącej bazy, przed przystąpieniem do replikowania obiektów do Common Daty należy uzgodnić GUID y (pkt. 3.3). Aby wykonać replikację obiektów z bazy Mirror do bazy Common Data należy użyć aplikacji replicator.exe.

17 System Zarządzania Forte - Replikacja Strona 17 z Składnia aplikacji repliacator.exe Składnia poleceń dla narzędzia replikacji jest następująca: Replicator.exe [-p[:plik_konfiguracji]] [-replicatethis -masterserver:serwer -masterdatabase:baza[:cd] [-masterappuser:masteruser] [-masterpassword:mpasword] [mdbadminlogin:adminlogin] [mdbadminpass:adminpassword] [mdbuserlogin:userlogin] [mdbuserpass:userpassword] -slaveserver:serwer -slavedatabase:baza[:cd] [-slaveappuser:slaveuser] [-slavepassword:spasword] [sdbadminlogin:adminlogin] [sdbadminpass:adminpassword] [sdbuserlogin:userlogin] [sdbuserpass:userpassword] [-direction:replicationdirection] [-deletepolicy:replicationdeletepolicy] [-updatepolicy:replicationupdatepolicy] ] [-crs -server:serwer -database:baza[:cd] [-appuser:login -password:pwd]? (help) - Opis parametrów p (replication) - Wykonanie replikacji. Jeżeli nie zostanie podany drugi parametr określający nazwę pliku konfiguracyjnego zawierającego parametry, zostaną użyte parametry zapisane w konfiguracji replikatora. replicator -p replicator -replication replicator -p:myconf.xml replicatethis - Wykonanie replikacji wg parametrów podanych w całości z wiersza poleceń, bez wykorzystania pliku konfiguracyjnego xml, np. Baza źródłowa (master) i docelowa (slave) nie mogą być fizycznie tymi samymi bazami. -masterserver:serwer -masterdatabase:baza -masterappuser:masteruser -masterpassword:mpasword -masterdatabase:cd wskazanie serwera bazy master wskazanie bazy master login użytkownika aplikacyjnego bazy master hasło użytkownika aplikacyjnego bazy master użytkownik master z bazy Common Data Jeżeli baza master jest bazą Common Data i nie jest znana nazwa użytkownika, na którego można się do niej zalogować, to użycie tego parametru spowoduje, że replikator odczyta z konfiguracji globalnej użytkownika i hasło do zalogowania się do bazy Common Data. Nie należy używać tego parametru jednocześnie z parametrem masterappuser. Parametr -masterpassword będzie natomiast ignorowany [mdbadminlogin:adminlogin] [mdbadminpass:adminpassword] [mdbuserlogin:userlogin] [mdbuserpass:userpassword] [mdbadminlogin:] [mdbadminpass:] [mdbuserlogin:] [mdbuserpass:] sql login dla połączenia administracyjnego - master sql hasło dla połączenia administracyjnego - master sql login dla połączenia zwykłego - master sql hasło dla połączenia zwykłego - master dla zintegrowanego połączenia administracyjnego - master dla zintegrowanego połączenia administracyjnego - master dla zintegrowanego połączenia zwykłego - master dla zintegrowanego połączenia zwykłego - master -slaveserver:serwer -slavedatabase:baza -slaveappuser:masteruser -slavepassword:mpasword -slavedatabase:cd wskazanie serwera bazy slave wskazanie bazy slave login użytkownika aplikacyjnego bazy slave hasło użytkownika aplikacyjnego bazy slave użytkownik slave z bazy Common Data Jeżeli baza slave jest bazą Common Data i nie jest znana nazwa użytkownika, na którego można się do niej zalogować, to użycie tego parametru spowoduje, że replikator odczyta z konfiguracji globalnej użytkownika i hasło do zalogowania się do bazy Common Data. [sdbadminlogin:adminlogin] [sdbadminpass:adminpassword] [sdbuserlogin:userlogin] sql login dla połączenia administracyjnego - slave sql hasło dla połączenia administracyjnego - slave sql login dla połączenia zwykłego - slave

18 System Zarządzania Forte - Replikacja Strona 18 z 39 [sdbuserpass:userpassword] [sdbadminlogin:] [sdbadminpass:] [sdbuserlogin:] [sdbuserpass:] sql hasło dla połączenia zwykłego - slave dla zintegrowanego połączenia administracyjnego - slave dla zintegrowanego połączenia administracyjnego - slave dla zintegrowanego połączenia zwykłego - slave dla zintegrowanego połączenia zwykłego - slave Nie należy używać tego parametru jednocześnie z parametrem slaveappuser. Parametr -slavepassword będzie natomiast ignorowany. -direction:repldirection kierunek replikacji domyślnie: Both możliwe wartości: -Both replikacja w obie strony -Master tylko do master -Slave tylko do slave -deletepolicy:replicationdeletepolicy sposób traktowania zmian polegających na usunięciu obiektu domyślnie: DeletedAsChanged możliwe wartości: -DeletedAsChanged usuwanie obiektów replikuje się -DeletedAsNotExist usuwanie obiektów nie podlega replikacji -updatepolicy:replicationupdatepolicy replikacja wykryła zmiany tego samego obiektu np. możliwe wartości: domyślnie: NewerWins -NewerWins -MasterWins -SlaveWins sposób rozstrzygania konfliktu gdy w bazie master i w bazie slave - replikuje się nowsza zmiana - replikuje się zmiana z bazy master do slave - replikuje się zmiana z bazy slave do master REPLIKACJA Z BAZY APLIKACJI DO BAZY COMMON DATA -replicatethis -masterserver:serwera -masterdatabase:bazaa -masterappuser:uzytkownika - masterpassword:haslouzytkownikaa -slaveserver:serwercd -slavedatabase:bazacd:cd -deletepolicy:deletedaschanged - direction:slave -updatepolicy:masterwins - exec:replikacja_kontrahentow:symfonia.common.subjects,version=a.b.c.d,culture=neutral,publickeytoken=94f0c0fc2739d e1f:fcontractors.replicateex - exec:replikacja_pracowników:symfonia.common.subjects,version=a.b.c.d,culture=neutral,publickeytoken=94f0c0fc2739de 1f:FEmployees.ReplicateEx - exec:replikacja_osób:symfonia.common.subjects,version=a.b.c.d,culture=neutral,publickeytoken=94f0c0fc2739de1f:fper sons.replicateex - exec:replikacja_słowników:symfonia.common.dictionaries,version=a.b.c.d,culture=neutral,publickeytoken=94f0c0fc2739d e1f:fdicts.replicateex - exec:replikacja_elementów:symfonia.common.structtree,version=a.b.c.d,culture=neutral,publickeytoken=94f0c0fc2739de 1f:FElements.ReplicateEx REPLIKACJA MIEDZY ZWYKŁYMI (NIE COMMON DATA) BAZAMI -replicatethis -masterserver:serwera -masterdatabase:bazaa -masterappuser:uzytkownika - masterpassword:haslouzytkownikaa -slaveserver:serwerb -slavedatabase:bazab -slaveappuser:uzytkownikb - slavepassword:haslouzytkownikab -deletepolicy:deletedaschanged -direction:both -updatepolicy:masterwins -exec: wskazanie, które obiekty mają być replikowane

19 System Zarządzania Forte - Replikacja Strona 19 z 39 DLA ZINTEGROWANEGO UŻYTKOWNIKA APLIKACYJNEGO NP. BAZY MASTER -replicatethis -masterserver:serwera -masterdatabase:bazaa -masterappuser: -masterpassword: -slaveserver:serwerb - slavedatabase:bazab -slaveappuser:uzytkownikb -slavepassword:haslouzytkownikab -deletepolicy:deletedaschanged - direction:both -updatepolicy:masterwins -exec: wskazanie, które obiekty mają być replikowane DLA ZINTEGROWANEGO POŁĄCZENIA ADMINISTRACYJNEGO I ZINTEGROWANEGO POŁĄCZENIA ZWYKŁEGO NP. BAZY MASTER -replicatethis -masterserver:serwera -masterdatabase:bazaa -masterappuser:uzytkownika - masterpassword:haslouzytkownikaa -mdbadminlogin: -mdbadminpass: -mdbuserlogin: -mdbuserpass: -slaveserver:serwerb - slavedatabase:bazab -slaveappuser:uzytkownikb -slavepassword:haslouzytkownikab -deletepolicy:deletedaschanged - direction:both -updatepolicy:masterwins -exec: wskazanie, które obiekty mają być replikowane crs (compact replication stats) - Kompaktuje dane o wykonanych replikacjach w tle poprzez usługę replikacji w konfiguracjach Common Data - Mirror. Powoduje to zmniejszenie miejsca zajmowanego przez te dane na serwerze i przyspieszenie jego pracy. replicator -crs -server:serwer -database:baza -appuser:login -password:pwd [dbadminlogin:adminlogin] sql login dla połączenia administracyjnego [dbadminpass:adminpassword] sql hasło dla połączenia administracyjnego [dbuserlogin:userlogin] sql login dla połączenia zwykłego [dbuserpass:userpassword] sql hasło dla połączenia zwykłego Uwaga: Aby zapewnić poprawność przeprowadzanej replikacji, należy wykonać replikację do bazy Common Data bezwzględnie określając jej kierunek (direction): master lub slave, wykluczając w ten sposób użycie domyślnego parametru both Replikacja danych do bazy Common Data Replikację obiektów z bazy Mirror do Common Data można wykonać wskazując w wierszu poleceń bazy oraz inne parametry replikacji lub można użyć aplikacji replicator.exe ze wskazaniem pliku z konfiguracją replikacji. Uruchomienie replikacji z plikiem z parametrami replikacji: Replikację uruchamiamy za pomocą polecenia: replicator.exe p:input.xml gdzie input.xml to plik w formacie xml zawierający parametry, z jakimi replikacja ma zostać uruchomiona. Format pliku: <?xml version="1.0" encoding="utf-8"?> <!-- tekst zawarty w tej linijce to komentarz. nie ma wpływu na proces replikacji. --> <!-- służy do oznaczenia uwag i notatek. --> <replicator version = "A.B.C.D"> <!-- ustawienia globalne - są wspólne dla wszystkich zdefiniowanych procesów replikacji --> <!-- podsekcje z tej sekcji są używane w przypadku braku odpowiednich sekcji w konkretnych --> <!-- replikacjach, natomiast w przypadku ich istnienia są ignorowane --> <global>

20 System Zarządzania Forte - Replikacja Strona 20 z 39 <!-- kierunek replikacji: "Master" - replikacja tylko do z bazy slave do bazy master "Slave" - replikacja tylko do z bazy master do bazy slave "Both" - replikacja w obie strony (domyślnie) --> <direction>slave</direction> <!-- sposób traktowania elementów powtarzających się w bazie 'master' i 'slave'. Możliwe wartości: "NewerWins" - Nowszy zostaje, skasowany traktowany jak zmieniony (domyślnie) "MasterWins" - Dane z master'a ważniejsze "SlaveWins" - Dane ze slave'a ważniejsze --> <updatepolicy>slavewins</updatepolicy> <!-- sposób traktowania elementów skasowanych miedzy bazami master-slave: "DeletedAsChanged" - propagacja (elementy traktowane jako zmienione) (domyślnie) "DeletedAsNotExist" - elementy skasowane traktowane jak nieistniejące --> <deletepolicy>deletedasnotexist</deletepolicy> <!-- dane do replikacji nie są zbierane na podstawie historii, replikują sie wszystkie obiekty, warto używać dla optymalizacji przy pierwszej replikacji do bazy Common Data z jej przyszłej bazy Mirror domyślnie: <usehistory>false</usehistory> --> <usehistory>false</usehistory> <!-- podczas modyfikacji obiektów w replikacji nie są usuwane referencje aplikacji, są tylko dodawane jeśli trzeba należy użyć tego przełącznika przy pierwszej replikacji do bazy Common Data z jej przyszłej bazy Mirror domyślnie: <allowremoverefs>true</allowremoverefs> --> <allowremoverefs>false</allowremoverefs> </global> <!-- pierwszy proces replikacji, parametry 'name', 'timeout' sa opcjonalne (tutaj, dla przykładu) --> <replication name = "Replikacja bazy A -> B" timeout = "-1" > <!-- konfiguracja bazy master w tej replikacji --> <master> <server>nazwa_serwera</server> <database>nazwa_bazy</database> <appuser name = "login" password = "hasło" /> <!-- Jeżeli login użytkowników i/lub ich hasła dla użytkownika adminowego i zwykłego różnią się od wartości domyślnych (które są zalecanie do zmiany) powinno się użyć następujących tagów do ustalenia loginu i nazwy użytkowników SQL na których proces replikacji będzie się logował do serwera SQL: <dbadmin name="loginuseraadminowego" password = "!HasloUzytkownika!"/> <dbuser name="loginuserazwyklego" password ="!HasloUzytkownika!"/> Jeżeli użytkownicy dbadmin, dbuser lub appuser to użytkownicy zintegrowani należy wartości name i password pozostawić puste tzn: <dbadmin name="" password = ""/>

21 System Zarządzania Forte - Replikacja Strona 21 z 39 <dbuser name="" password =""/> <appuser name = "" password = "" /> --> </master> <!-- konfiguracja bazy slave w tej replikacji. parametry analogicznie jak w bazie 'master' powyzej --> <slave> <server>nazwa_serwera</server> <database>nazwa_bazy</database> <cd /> <!-- jeżeli baza slave jest bazą Common Data i nie jest znana nazwa użytkownika, na którego można się do niej zalogować, to zamiast sekcji <appuser... /> można użyć wpisu <CD />, spowoduje on, że replikator odczyta z konfiguracji globalnej użytkownika i hasło do zalogowania się do bazy Common Data --> <!-- Jeżeli login użytkowników i/lub ich hasła dla użytkownika adminowego i zwykłego różnią się od wartości domyślnych (które są zalecanie do zmiany) powinno się użyć następujących tagów do ustalenia loginu i nazwy użytkowników SQL na których proces replikacji będzie się logował do serwera SQL: <dbadmin name="loginuseraadminowego" password = "!HasloUzytkownika!"/> <dbuser name="loginuserazwyklego" password ="!HasloUzytkownika!"/> Jeżeli użytkownicy dbadmin, dbuser lub appuser to użytkownicy zintegrowani należy wartości name i password pozostawić puste tzn: <dbadmin name="" password = ""/> <dbuser name="" password =""/> <appuser name = "" password = "" /> --> </slave> <!-- teraz następują poszczególne replikacje obiektów wspólnych --> <exec name = "Replikacja kontrahentów" codebase = "Symfonia.Common.Subjects, Version=A.B.C.D, Culture=neutral, PublicKeyToken=94f0c0fc2739de1f" handler = "FContractors.ReplicateEx" /> <exec name = "Replikacja pracowników" codebase = "Symfonia.Common.Subjects, Version=A.B.C.D, Culture=neutral, PublicKeyToken=94f0c0fc2739de1f" handler = "FEmployees.ReplicateEx" /> <exec name = "Replikacja osób" codebase = "Symfonia.Common.Subjects, Version= A.B.C.D, Culture=neutral, PublicKeyToken=94f0c0fc2739de1f" handler = "FPersons.ReplicateEx" /> <exec name = "Replikacja słownikow" codebase = "Symfonia.Common.Dictionaries, Version= A.B.C.D, Culture=neutral, PublicKeyToken=94f0c0fc2739de1f" handler = "FDicts.ReplicateEx" /> <exec name = "Replikacja elementów" codebase = "Symfonia.Common.StructTree, Version= A.B.C.D, Culture=neutral, PublicKeyToken=94f0c0fc2739de1f" handler = "FElements.ReplicateEx" /> <!-- koniec pojedynczego procesu replikacji --> </replication> <!-- ewentualne kolejne procesy replikacji... --> <!-- koniec wszystkich procesów replikacji --> </replicator> Omówienie poszczególnych sekcji pliku xml: W sekcjach <master> oraz <slave> wskazujemy parametry dostępu do baz, między którymi zostanie wykonana replikacja. Dla naszych celów (pierwsza replikacja z przyszłego Mirrora do Common Data) baza Common Data musi być podana w sekcji <slave>, <CD /> jeżeli jedną z replikowanych baz jest baza Common Data, do której nie znamy nazwy użytkownika ani hasła, możemy zamiast jawnego wpisu <appuser name =

22 System Zarządzania Forte - Replikacja Strona 22 z 39 "nazwauzytkownika" password = "haslo" /> użyć wpisu <CD />. Replicator odczyta wtedy nazwę użytkownika i hasło z konfiguracji globalnej i będzie w stanie zalogować się do bazy Common Data, <deletepolicy>deletedasnotexists</deletepolicy> Podczas replikacji z przyszłego Mirrora do bazy Common Data zalecane jest omijanie usuniętych obiektów ponieważ zależy nam na przeniesieniu tylko istniejących obiektów do bazy Common Data, <usehistory>false</usehistory> Parametr usehistory decyduje o tym, czy dane do replikacji są zbierane na podstawie historii. Jeśli parametr ma wartość false replikują sie wszystkie obiekty. Tego parametru warto używać dla optymalizacji przy pierwszej replikacji do bazy Common Data z jej przyszłego Mirrora. <allowremoverefs>false</allowremoverefs> Parametr ten powoduje, że podczas modyfikacji obiektów w replikacji nie są usuwane referencje aplikacji. Są tylko dodawane jeśli jest taka potrzeba. Należy użyć tego przełącznika przy pierwszej replikacji do bazy Common Data z jej przyszłego Mirrora. <direction>slave</direction> Aby zapewnić poprawność przeprowadzanej replikacji należy wykonać replikację do bazy Common Data bezwzględnie określając jej kierunek (direction): master lub slave, wykluczając w ten sposób użycie domyślnego parametru both. Replikujemy wszystkie dane podlegające replikacji w tle, czyli takie które mogą być wspólne: kontrahenci, pracownicy, osoby, słowniki i elementy. Przy czym istotna jest kolejność, czyli replikację należy wywołać w taki sposób, aby najpierw replikować kartoteki kontrahentów, pracowników i osób, a następnie słowniki i elementy słowników. Wpis nakazujący replicator owi replikację kontrahentów przy użyciu odpowiedniej metody serwisu kontrahentów z assembly o odpowiedniej wersji ma, tak jak w opisywanym pliku, postać: <exec name = "Replikacja kontrahentów" codebase = "Symfonia.Common.Subjects, Version= A.B.C.D, Culture=neutral, PublicKeyToken=94f0c0fc2739de1f" handler = "FContractors.ReplicateEx" /> Po poprawnym wykonaniu tych poleceń baza Common Data jest wypełniona wszystkimi danymi wspólnymi z bazy Mirror. Przed wykonaniem replikacji z kolejnej bazy Mirror do bazy Common Data należy powtórzyć procedurę uzgodnienia GUID ów z pkt Weryfikacja Stan oczekiwany: Proces napełnienia bazy Common Data przeprowadzony bez błędów. W skonfigurowanej bazie Common Data, biorącej udział w replikacji, znajdują się zreplikowane dane. Sposób sprawdzenia: Wynik replikacji zapisywany jest w logu o nazwie replicator_data_godzina_id.log, w katalogu, w którym znajdował się replicator.exe, lub innym folderze roboczym, o ile taki został ustawiony. Dla każdego replikowanego obiektu załączona jest informacja o tym, czy replikacja została zakończona powodzeniem. Np.: :40:57 [i]: Employees - obiekt Replicated - LUID: 1; GUID: b1d430cb-efd7-4c3a-9f70- d86b7ff0f9e4. OK. "[i]" na początku oznacza informację "[w]" na początku oznacza ostrzeżenie "[x]" na początki oznacza błąd

23 System Zarządzania Forte - Replikacja Strona 23 z 39 Informacja o przeprowadzonych replikacjach oraz o tym, czy dana procedura replikacji zakończyła się sukcesem (możliwe są pojedyncze błędy), znajduje się w obu bazach w tabeli STReplicationInfo. Jeśli parametr FinishResult ma wartość True (lub 1 ) oznacza to, że proces replikacji został przeprowadzony na parze baz Master Slave z sukcesem. Wartość False (lub 0 ) mówi o tym, że albo replikacja trwa, albo nie wykonała się poprawnie. Znacząca tu jest kolumna EndDate: jeśli ma wartość :00:00 replikacja trwa, jeśli nie - oznacza to, że proces nie wykonał się poprawnie. Dodatkowo w tabeli STReplicationDetails można znaleźć takie same informacje, ale dotyczące replikacji rodzajów obiektów. UWAGA: Podczas przygotowywania środowiska z bazą Common Data, po wykonaniu replikacji z bazy Mirror do bazy Common Data, zabrania się wykonywania jakichkolwiek zmian na bazie Mirror, zanim baza ta nie zostanie połączona z bazą Common Data oraz replikacja w tle nie wyrówna stanów obiektów we wszystkich bazach Mirror. Nie zastosowanie się do powyższego wymagania skutkować będzie błędami w dalszych etapach wdrożenia. 3.5 Powiązanie baz Mirror z Common Data Po przeniesieniu obiektów ze wszystkich baz Mirror do bazy Common Data, należy zapisać w konfiguracji globalnej powiązanie baz z Common Datą oraz w każdym Mirrorze zapisać wskazanie na jego bazę Common Data. Dla każdego Mirrora należy wykonać polecenie: CDCONF -a:scd -sapp:serwer -bapp:baza -alias:alias [-s:serwer -b:baza] [-Alogin:login] [-Apwd:pwd][-Ulogin:login][-Upwd:pwd] [ [-appulogin:login] [-appupwd:pwd] ] [/i] gdzie: Przełączniki dla akcji SCD: -s: serwer bazy CommonData (wymagane, chyba że jest -alias) -b: nazwa bazy CommonData (wymagane, chyba że jest -alias) -alias: określenie bazy CommonData poprzez alias z konfiguracji globalnej -sapp: serwer bazy aplikacyjnej (domyślnie ten sam co w -s:) -bapp: nazwa bazy aplikacyjnej (wymagane) -Alogin: login użytkownika SSDBAdmin na serwerze bazy aplikacyjnej -Apwd: hasło użytkownika SSDBAdmin na serwerze bazy aplikacyjnej -Ulogin: login użytkownika SSDBUser na serwerze bazy aplikacyjnej -Upwd: hasło użytkownika SSDBUser na serwerze bazy aplikacyjnej -appulogin: login administratora praw w aplikacji (ignorowany jeśli /i) -appupwd: hasło administratora praw w aplikacji (ignorowany jeśli /i) /i zintegrowane logowanie istniejącego admina praw w aplikacji Parametry logowania SSDBAdmina, SSDBUsera oraz administratora praw mogą być pominięte. Wówczas nastąpi próba dostępu i zalogowania na danych domyślnych. Uwaga: Kolejność dołączania baz do Common Daty będzie decydować o kolejności późniejszej replikacji uruchomionej z usługi.

24 System Zarządzania Forte - Replikacja Strona 24 z Weryfikacja Stan oczekiwany: Baza (lub bazy) Mirror przypisane do bazy Common Data. Informacja o przypisaniach zapisana w globalnej konfiguracji. Sposób sprawdzenia: Po wykonaniu poleceń ustawiających bazę Common Data dla Mirrorów, stan konfiguracji można zweryfikować poleceniem: CDCONF -a:lcd W efekcie powinniśmy uzyskać listę baz Common Data w systemie oraz listę baz aplikacyjnych i ich baz Common Data. Aby zobaczyć jaka baza Common Data jest ustawiona dla konkretnego Mirrora, należy wykonać polecenie: CDCONF -a:gcd -sapp:serwer -bapp:baza [-Alogin:login] [-Apwd:pwd] [-Ulogin:login] [-Upwd:pwd] Gdzie: -sapp: serwer bazy aplikacyjnej (wymagane) -bapp: nazwa bazy aplikacyjnej (wymagane) -Alogin: login użytkownika SSDBAdmin na serwerze bazy aplikacyjnej -Apwd: hasło użytkownika SSDBAdmin na serwerze bazy aplikacyjnej -Ulogin: login użytkownika SSDBUser na serwerze bazy aplikacyjnej -Upwd: hasło użytkownika SSDBUser na serwerze bazy aplikacyjnej Parametry logowania SSDBAdmina i SSDBUsera mogą być pominięte. Wówczas nastąpi próba dostępu na danych domyślnych. Szczegółowe informacje na temat wszystkich funkcji narzędzia CDCONF uzyskamy przy pomocy polecenia: CDCONF bez parametrów, lub CDCONF /? (dla większej ilości szczegółów). 3.6 Instalacja lub uruchomienie usługi HR2CD Jeśli jedną z baz Mirror jest baza programu Kadry i Płace Forte, należy zainstalować (jeśli wcześniej usługa została odinstalowana) lub uruchomić usługę HR2CD dla danej bazy KDF. Szczegółowa instrukcja znajduje się w rozdziale Instalacja i uruchomienie usługi replikacji w tle UWAGA: Podczas przygotowywania środowiska z bazą Common Data, po wykonaniu replikacji z bazy Mirror do bazy Common Data zabrania się wykonywania jakichkolwiek zmian na bazie Mirror zanim baza ta nie zostanie połączona z bazą Common Data oraz replikacja w tle nie wyrówna stanów obiektów we wszystkich bazach Mirror. Nie zastosowanie się do powyższego wymagania skutkować będzie błędami w dalszych etapach wdrożenia. Gdy wszystkie bazy Mirror mają ustawioną Common Datę, należy uruchomić usługę replikacji. Aby to zrobić, należy z linii poleceń wykonać komendę:

25 System Zarządzania Forte - Replikacja Strona 25 z 39 ForteSrv.exe ifr serwer.nazwa_bazy_commondata Po uruchomieniu usługi, obiekty które są w bazie Common Data, ale nie ma ich w którejkolwiek z baz Mirror (bo nigdy ich tam nie było, a do bazy Common Data trafiły z innej bazy Mirror), zostaną przeniesione do danej bazy Mirror. Kolejność replikacji jakie wykonuje usługa jest zgodna z kolejnością dołączania baz do bazy Common Data. Po zakończeniu tych pierwszych replikacji układ baz jest już w pełni skonfigurowany, a dane wprowadzane do jednego z Mirrorów będą replikowane przez serwis replikacji do pozostałych Weryfikacja Stan oczekiwany: Aplikacje Forte korzystające z bazy Common Data, a co za tym idzie, pracujące na wspólnych kartotekach kontrahentów, pracowników, osób oraz słownikach i elementach słowników. Poszczególne obiekty zostają rozpropagowane do baz Mirror. Nowododane obiekty zapisują się do Mirrora (bazy aplikacyjnej) i bazy Common Data, a następnie są propagowane do innych Mirrorów (powinny być widoczne w innych aplikacjach). Sposób sprawdzenia: a) W usługach systemowych maszyny, na której uruchomiona została usługa replikacji powinna działać usługa: Symfonia ForteRepl serwer.commondata ver. A.B.C.D b) W bazie pełniącej rolę Common Data powinna powstać tabela: STReplicationStats, w której możemy obserwować czy kolejne replikacje wykonywane są na wszystkich podłączonych bazach (kolumna SlaveDatasource). c) Analogicznie, jak w punkcie 3.3.4, przebieg replikacji można obserwować w tabelach STReplicationInfo i STReplicationDetails. d) Niezależnie od sprawdzenia działania usługi replikacji oraz zawartości tabel SCommon należy upewnić się, czy w każdej z aplikacji widoczne są te same obiekty (kartoteki oraz słowniki i ich elementy), oraz czy nowododane obiekty są propagowane do baz Mirror innych aplikacji i czy widoczne są w aplikacjach Deinstalacja usługi ForteRepl Jeśli zajdzie potrzeba odinstalowania usługi replikacji w tle należy wykonać następujące polecenie: ForteSrv.exe ufr serwer.baza

26 System Zarządzania Forte - Replikacja Strona 26 z Konfiguracja ustawień współpracy z FK w modułach biznesowych Systemu Forte Współpraca baz w modelu z replikacją wymaga wprowadzenia zmian w ustawieniach współpracy z FK modułów biznesowych Systemu Forte. Funkcjonowanie któregokolwiek z modułów: Forte Handel, Forte Kadry i Płace, Forte Środki Trwałe z modułem Forte Finanse i Księgowość, działających w replikacji, bezwzględnie wymusza zdefiniowanie parametru współpracy Osobnych baz z replikacją (Rys. 1). Rys. 1 Konfiguracja współpracy z FK Uwaga: Należy pamiętać, aby w modułach biznesowych Systemu Forte w ustawieniach dla współpracy z FK wybrać działanie w trybie Osobnych baz z replikacją.

27 System Zarządzania Forte - Replikacja Strona 27 z 39 4 Dołączenie kolejnej bazy aplikacyjnej do już pracującego systemu 4.1 Dołączenie nowoutworzonej bazy aplikacyjnej Aby dołączyć nowoutworzoną bazę do systemu pracującego w modelu Common Data, należy wykonać następujące czynności: i. Zatrzymanie usługi HR2CD (jeśli jest uruchomiona) oraz ForteRepl. ii. Replikacja obiektów z Common Data do nowoutworzonej bazy narzędziem Replicator.exe. iii. Podłączenie do Common Data nowoutworzonej bazy aplikacyjnej narzędziem cdconf.exe. iv. Uruchomienie usług ForteRepl oraz HR2CD. 4.2 Dołączenie skonwertowanej bazy aplikacyjnej Aby dołączyć nowoskonwertowaną bazę do systemu pracującego w modelu Common Data, należy wykonać następujące czynności: i. Zatrzymanie usługi HR2CD (jeśli jest uruchomiona) oraz ForteRepl. ii. (punkt opcjonalny) Jeśli dołączaną bazą jest baza KDF, należy uruchomić usługę HR2CD dla tej bazy w celu przeniesienia danych pracowników do tabel SSCommon. Po wykonaniu eksportu usługę należy zatrzymać lub odinstalować. iii. Uzgodnienie kontrahentom, pracownikom, osobom globalnych identyfikatorów (GUID ów) z bazą Common Data narzędziem Guider.exe. iv. Replikacja obiektów z nowoskonwerotwanej bazy do bazy Common Data narzędziem Replicator.exe. v. Podłączenie nowoskonwerotwanej bazy aplikacyjnej do Common Data narzędziem cdconf.exe. vi. Uruchomienie usług ForteRepl oraz HR2CD.

28 System Zarządzania Forte - Replikacja Strona 28 z 39 5 Szczegółowe informacje o serwisie HR2CD 5.1 Dane KDF a dane Common Data Dane w bazie Common Data to dane wspólne dla kilku programów Systemu Forte. Dane pracowników wprowadzone w module KDF widoczne są w innych aplikacjach, tzn: FKF, HMF oraz STF (osoby). Program Forte Kadry i Płace przechowuje w bazie danych dane kadrowe pracowników obowiązujące od daty do daty, natomiast dane wspólne posiadają dane na konkretny dzień. Dlatego został stworzony serwis pozwalający na wyeksportowanie danych kadrowych pracowników takich jak imię nazwisko, adresy, telefony, konta bankowe itd. z programu KDF do danych wspólnych (bazy Common Data) obowiązujących w danym dniu, ale tylko tych, które uległy zmianie od ostatniego eksportu. Eksport danych powinien odbywać się każdego dnia o określonej porze (im wcześniej tym lepiej, np. o godzinie 00:15) dla wszystkich pracowników, aż do wyeksportowania wszystkich zmienionych danych. 5.2 Serwis HR2CD Serwis HR2CD zajmuje się eksportem danych pracowników (takich jak imię nazwisko, data urodzenia, adresy, telefony, konta bankowe itd.) z danych kadrowych programu KDF do danych wspólnych (Common Data). Serwis HR2CD odczytuje dane kadrowe pracownika obowiązujące w danym dniu, porównuje je z danymi zapisanymi w danych wspólnych i jeżeli wykryje różnice to wykonuje zapis do danych wspólnych. W przypadku gdy baza KDF została skonfigurowana do pracy z danymi wspólnymi (posiada konfigurację globalną zapisaną programem cdconf.exe) zapis danych odbywa się najpierw do bazy Common Data a następnie do bazy Mirror (KDF). 5.3 Uruchamianie serwisu w module KDF Serwis HR2CD uruchamiany jest automatycznie w module KDF dla konkretnych pracowników podczas zapisywania danych kadrowych podlegających eksportowi do Common Data. Dla użytkownika KDF jest to permanentne i nie musi nic w tym celu robić. 5.4 Uruchamianie usługi HR2CD Dane kadrowe KDF mogą zawierać dane obowiązujące w przyszłości (stają się obowiązujące z początkiem danego dnia), w związku z czym dane pracownika w danych wspólnych stają się nieaktualne, dlatego dostępna jest funkcjonalność serwisu HR2CD w postaci usługi Windows. Usługa HR2CD w postaci Windows Service jest procesem rezydentnym systemu Windows. Po wystartowaniu (ręcznym lub automatycznym) wykonuje powierzone mu zadanie po czym przechodzi w stan uśpienia do następnego dnia. Usługa HR2CD umożliwia eksport danych kadrowych pracowników programu KDF obowiązujących w bieżącym dniu do danych pracownika w danych wspólnych (Common Data). Usługa HR2CD wymaga konfiguracji parametrów takich jak: nazwa serwera SQL i bazy danych KDF oraz godzina, o której każdego dnia ma się odbywać eksport danych kadrowych.

29 System Zarządzania Forte - Replikacja Strona 29 z 39 Instalowanie usługi HR2CD odbywa się poprzez narzędzie ForteSrv.exe (instalowane z Forte.Common) z wiersza poleceń: ForteSrv.exe ihr2cd serwer.baza czas serwer baza serwer SQL nazwa bazy danych KDF na serwerze Parametr czas to czas rozpoczęcia eksportu każdego dnia; należy go podawać w formacie gg:mm:ss. Czas rozpoczęcia eksportu jest opcjonalny. Domyślny czas: 00:15:00. Po zainstalowaniu usługa jest automatycznie startowana. Zatrzymanie usługi z poziomu listy usług Windows i ponowne wystartowanie spowoduje ponowne wykonanie procedury eksportującej dane pracowników. Uwaga: Polecenie ForteSrv.exe ihr2cd wyświetla tylko informacje o powodzeniu zainstalowania usługi Windows, nie wyświetla informacji o działaniu samej usługi, np. o niepoprawnej nazwie serwera. Działanie usługi HR2CD można obserwować w dzienniku zdarzeń systemowych (Event Viewer) w katalogu Application. Uwaga: Serwis HR2CD pracując jako usługa Windows podłącza się do bazy danych używając parametrów z konfiguracji globalnej utworzonej programem cdconf.exe, takich jak: loginy do bazy danych wraz z hasłami, użytkownik aplikacji i jego hasło. W przypadku braku konfiguracji globalnej używane są parametry domyślne (SSDBAdmin, SSDBUser, bez logowania użytkownika aplikacji). Informacja ta dołączana jest do logu Windows. Uwaga: Serwis HR2CD jest uruchamiany zgodnie z czasem globalnym (synchronizowanym z serwerem czasu), a nie lokalnym (czas komputera), zazwyczaj widoczne są różnice kilkudziesięciu sekund. Przykłady: ForteSrv.exe ihr2cd k2137\sql2005.kd_demo :15:00 Powyższe polecenie spowoduje zainstalowanie i uruchomienie usługi widocznej na liście usług Windows pod nazwą: Symfonia HR2CD k2137sql2005.kd_demo2009 ver. A.B.C.D skonfigurowanej do eksportu danych z bazy KD_DEMO2009 z serwera k2137\sql2005, przy czym eksport będzie się rozpoczynał każdego dnia o godzinie 01:15:00. Jeśli nie zostanie podana godzina eksportu wtedy ustawiona zostanie domyślna godzina: 00:15: Deinstalacja usługi HR2CD Jeśli zajdzie potrzeba odinstalowania usługi replikacji w tle, należy wykonać następujące polecenie: ForteSrv.exe uhr2cd serwer.baza Np.: ForteSrv.exe uhr2cd k2137\sql2005.kd_demo2009

30 System Zarządzania Forte - Replikacja Strona 30 z Uruchomienie serwisu przed uzgadnianiem GUID ów Uruchomienie serwisu HR2CD przed uzgadnianiem GUID ów programem Guider pozwala na wyeksportowanie danych kadrowych pracowników do danych wspólnych w bazie KDF (czyli z tabel danych kadrowych, których Guider nie bierze pod uwagę przy wyszukiwaniu obiektów, do tabel dostępnych dla Forte.Common). Dzięki temu Guider będzie mógł porównać pełniejsze dane pracownika KDF (dostępne będą również te dane, które wyeksportuje HR2CD) z pracownikiem z innej bazy. Przed uruchomieniem serwisu HR2CD należy wykonać odpowiednią akcję programem cdconf dla bazy danych KDF, która zakłada użytkownika synchronizacyjnego oraz zapisuje informacje w konfiguracji bazy oraz w konfiguracji globalnej. Cdconf.exe a:pmr sapp:k2137\sql2005 bapp:kd_demo2009 Uwaga: Polecenie to nie konfiguruje bazy KDF do pracy z bazą CD, tylko przygotowuje ją do współpracy z HR2CD. Następnie uruchomić usługę Windows HR2CD, np.: ForteSrv.exe ihr2cd k2137\sql2005.kd_demo :15:00 Po zakończeniu eksportu i uśpieniu serwisu HR2CD (informacja w dzienniku zdarzeń systemowych w katalogu Application i źródle HR2CD) należy zatrzymać usługę Windows (Stop na liście usług Windows), wykonać uzgadnianie GUID ów programem Guider, skonfigurować bazę KDF do pracy z bazą wspólną (programem cdconf.exe) i ponownie uruchomić usługę HR2CD. 5.7 Śledzenie wyniku eksportu danych kadrowych pracowników W dzienniku zdarzeń systemowych (Event Viewer) w katalogu Application zapisują się informacje o błędach działania i akcjach wykonywanych przez serwis HR2CD, np.: Serwis pozostanie uśpiony przez 11:55: do czasu :15:00., Baza:k2137\sql2005.KD_DEMO2009, czas globalny: ' :19:26' Zakończono eksport danych pracowników, porównanych: 44, wyeksportowanych: 0, Baza:k2137\sql2005.KD_DEMO2009, czas globalny: ' :19:26' Rozpoczęto eksport danych pracowników, Baza:k2137\sql2005.KD_DEMO2009, czas globalny: ' :19:22' Serwis został uruchomiony poprawnie, Baza:k2137\sql2005.KD_DEMO2009, czas globalny: ' :19:22' 5.8 Spis danych kadrowych eksportowanych do danych wspólnych Lista eksportowanych elementów kadrowych programu KDF: Dane osobowe: Imię, Drugie Imię, Nazwisko Data urodzenia PESEL NIP Numer ewidencyjny pracownika Konto bankowe Adres zameldowania Adres tymczasowy Adres do korespondencji Telefon prywatny Telefon służbowy Telefon komórkowy pracownika

31 System Zarządzania Forte - Replikacja Strona 31 z 39 6 Szczegółowe informacje o aplikacji Guider Aplikacja Guider służy do uzgadniania globalnych identyfikatorów (w skrócie GUID ów). Proces uzgadniania odbywa się pomiędzy dwiema bazami wskazanymi przez użytkownika. Uzgadnianie GUID ów odbywa się przy wykorzystaniu zdefiniowalnych kryteriów porównujących dane kartotek. Uzgadnianie GUID ów ma się wykonać dla kartotek kontrahentów, pracowników, osób, słowników oraz rodzajów i elementów słowników. 6.1 Wybór baz danych Uwaga: Przed przystąpieniem do uzgadniania GUID ów należy wykonać kopie zapasowe baz danych, w których obiekty będą modyfikowane. Rys. 6.1 Okno wyboru baz danych Po uruchomieniu aplikacji Guider należy wskazać firmy, pomiędzy którymi będą uzgadniane numery GUID. Należy wskazać bazę nadrzędną (baza, która będzie źródłem GUID ów zmienianych w bazie podrzędnej) oraz firmę podrzędną (baza, w której GUID y zostaną zmienione). Uwaga: Zaleca się, aby bazą nadrzędną była zawsze baza pełniąca rolę Common Data. Jeśli bazy Common Data nie ma na liście, należy skorzystać z opcji Dołącz bazę Common Data, a następnie w kreatorze wskazać tę bazę. Po wskazaniu odpowiednich baz danych i podaniu parametrów logowania (podanie parametrów logowania do bazy Common Data nie jest konieczne) należy wybrać przycisk Dalej>>, który pozwala na przejście do kolejnego kroku.

32 System Zarządzania Forte - Replikacja Strona 32 z Potwierdzenie kontynuacji procesu uzgadniania GUID ów Rys. 6.2 Okno potwierdzające kontynuację Po przejściu do kolejnego kroku aplikacja ostrzega użytkownika o konsekwencji kontynuowania procesu uzgadniania GUID ów, tzn. zmianach w bazie danych oraz przypomina o potrzebie wykonania kopii bezpieczeństwa baz danych. Wciśnięcie przycisku Dalej>> jest możliwe dopiero po zaznaczeniu checkboxa tak, chcę kontynuować i powoduje przejście do okna definiowania kryteriów. 6.3 Zarządzanie kryteriami Rys. 6.3 Zarządzanie kryteriami Kolejny krok to zarządzanie kryteriami, według których wyszukiwane będą tożsame elementy kartotek, które powinny mieć takie same GUID y. Domyślnie, żadne kryteria nie są załadowane, a użytkownik musi wskazać plik z gotowymi kryteriami (akcja Importuj kryteria) lub je stworzyć (akcja Edytuj kryteria).

33 System Zarządzania Forte - Replikacja Strona 33 z 39 W oknie zarządzania kryteriami prezentowana jest lista kartotek, dla których mogą być zdefiniowane kryteria. W pierwszej kolumnie widnieje nazwa kartoteki. W drugiej podana jest informacja, czy kryteria dla tej kartoteki zostały zdefiniowane. Kolumna trzecia pozwala na ustalenie, czy obiekty wybranej kartoteki mają być uzgadniane. Kolumna czwarta (edycyjna) zawiera numer etapu, w którym dana kartoteka będzie uzgadniana. W podzielonym na etapy procesie uzgadniania w pierwszej kolejności wyszukane i uzgodnione zostaną elementy kartotek kontrahentów, pracowników oraz słowniki (proces oznaczony cyfrą 1). W drugim etapie uzgadniane będą osoby i rodzaje elementów (cyfra 2). Trzeci krok (cyfrą 3) dotyczy elementów słowników. W przypadku łączenia baz do replikacji, zaleca się zaimportowanie pliku kryteria_replikacja.all dostępnego w katalogu aplikacji Guider. Przygotowany zestaw kryteriów zawiera informacje potrzebne do wyszukania tożsamych kontrahentów, pracowników, słowników, osób, rodzajów elementów, elementów. UWAGA: Dostarczone kryteria należy dostosować do specyfiki uzgadnianych baz danych Definiowanie/Edycja kryteriów Rys Kryteria uzgadniania tożsamości Dla elementów, dla których można jednoznacznie określić, iż są to te same elementy, należy zdefiniować kryterium Uznaj za tożsame. Dla przypadków, w których nie istnieje pewność że są to te same elementy, należy zdefiniować kryterium Do rozstrzygnięcia. Obiekty, które nie spełnią reguł Uznaj za tożsame lub Do rozstrzygnięcia, zostaną uznane za obiekty różne. Uwaga: Poszczególne akcje oraz listy akcji można importować lub eksportować. Przy imporcie należy jednak pamiętać, że warunki stworzone dla jednego rodzaju kartoteki nie mogą być importowane dla innego rodzaju kartoteki. Program nie pozwoli na import akcji do rozstrzygnięcia kartoteki np. pracowników, gdy akcje zostały wcześniej stworzone dla kartoteki np. kontrahentów.

34 System Zarządzania Forte - Replikacja Strona 34 z 39 Do edycji reguł służy również program Criteriaeditor.exe znajdujący się w lokalizacji: %COMMONPROGRAMFILES%\Sage\Forte\Forte.Common_A.B.C.D\ lub dla systemów 64-bitowych: %COMMONPROGRAMFILES(x86)\Sage\Forte\Forte.Common_A.B.C.D\ Po zdefiniowaniu odpowiednich kryteriów należy w oknie Zarządzanie kryteriami wybrać przycisk Dalej>>. Aplikacja Guider przystąpi wtedy do wyszukiwania obiektów do uzgodnienia (rozdział 6.4) oraz nadpisania GUID ów w bazie podrzędnej zgodnie z ustalonym w kryteriach podziałem na etapy (rozdział 6.5). W każdym z etapów obiekty zostaną kolejno wyszukane, uzgodnione, a następnie ich GUID y nadpisane. 6.4 Proces wyszukiwania GUID ów Rys. 6.4 Okno z procesem wyszukiwania GUID ów Proces wyszukiwania elementów kartotek do uzgodnienia GUID ów składa się z dwóch części. Pierwsza to wyszukanie obiektów i automatyczne przydzielenie ich do jednej z grup: Uzgodnione, Do rozstrzygnięcia, Różne. Druga to rozstrzygnięcie statusu obiektów podejrzanych o tożsamość, która jest opcjonalna i występuje tylko wtedy gdy zostaną znalezione obiekty do rozstrzygnięcia. Okno z procesem wyszukiwania GUID ów zawiera listę kartotek wraz z liczbą wszystkich obiektów w kartotece, obiektów porównanych podczas tego wyszukiwania, uzgodnionych, do rozstrzygnięcia, różnych oraz obiektów z nadpisanymi GUID ami. Po zakończeniu wyszukiwania zmienia się opis w górnej części okna na: Zakończono wyszukiwanie elementów do uzgodnienia. Jeśli istnieją elementy do rozstrzygnięcia, aktywowany jest przycisk Rozstrzygaj. Przycisk ten otwiera okno służące do rozstrzygania tożsamości elementów, patrz rozdział Uwaga: Przed przystąpieniem do replikacji, wszystkie podmioty podejrzane o tożsamość muszą być rozstrzygnięte. W przeciwnym wypadku może to skutkować konfliktami przy replikacji.

35 System Zarządzania Forte - Replikacja Strona 35 z Rozstrzyganie tożsamości elementów kartotek Rys Rozstrzyganie tożsamości elementów kartotek W kolejnym etapie następuje przejście do rozstrzygania tożsamości elementów kartotek, dla których nie zostało zastosowane automatyczne uzgadnianie tożsamości. Obiekty, dla których zostało spełnione kryterium Do rozstrzygnięcia poddawane są procesowi rozstrzygania. Lista w prawej górnej części okna w każdym wierszu prezentuje dane dwóch elementów (z bazy nadrzędnej i podrzędnej), pomiędzy którymi należy ustalić tożsamość. W kolumnie Tożsame podany jest stan rozstrzygania dla tych dwóch elementów. Możliwe stany to:?, Tak, Nie, gdzie? jest stanem początkowym i oznacza brak rozstrzygnięcia, Tak oznacza, że para elementów uznana została za tożsame, natomiast Nie, że para elementów uznana została za różne. W dolnej części okna pojawiają się detale elementów wybranych w górnej części okna. Detale elementów prezentowane są w postaci dwóch rozwijalnych drzewek. Dodatkowo pola, które wchodziły w skład kryteriów, podświetlone są na czerwono (jeśli ich wartości są różne) lub zielono (jeśli ich wartości są identyczne). Nad listą elementów umieszczone są dwa przyciski: Tożsame i Różne. Wciśnięcie jednego z nich ustala, czy elementy prezentowane z detalami są tożsame, czy są różne.

36 System Zarządzania Forte - Replikacja Strona 36 z 39 Na liście elementów można zaznaczyć dowolną liczbę obiektów, aby ustalić ich tożsamość, bądź oznaczyć je jako różne. Aby zaznaczyć kilka obiektów należy trzymając wciśnięty klawisz Ctrl wskazać wybrane obiekty z listy lub zaznaczyć pierwszy obiekt z listy a następnie trzymając wciśnięty klawisz Shift, wybrać ostatni - zaznaczone zostaną wtedy wszystkie obiekty pomiędzy nimi. Uwaga: W przypadku próby uzgodnienia elementu z jednej bazy z elementem z drugiej bazy, z którym był już uzgodniony inny element, aplikacja pokaże kolejne okno: Konflikt uzgodnień elementów kartoteki nazwa kartoteki, w którym należy podjąć ostateczną decyzję, które uzgadniane elementy są na pewno tożsame. Rys Okno: Konflikt uzgodnień elementów kartoteki Jeśli z listy kartotek wybrane zostaną osoby, a nie zostali jeszcze rozstrzygnięci wszyscy kontrahenci oraz pracownicy, wówczas aplikacja wyświetli stosowny komunikat informujący o tym, że najpierw należy rozstrzygnąć tożsamość kontrahentów i pracowników.

37 System Zarządzania Forte - Replikacja Strona 37 z Operacja nadpisywania GUID ów Zanim użytkownik przystąpi do procesu nadpisywania, zostanie poproszony o potwierdzenie,czy na pewno chce kontynuować, okno Rys Potwierdzenie kontynuowania nadpisywania GUID ów Przed przystąpieniem do procesu nadpisywania GUID ów istnieje możliwość obejrzenia uzgodnionych podmiotów poprzez wybranie przycisku Pokaż uzgodnione podmioty. Jeśli użytkownik potwierdzi chęć nadpisywania GUID ów i wybierze przycisk Dalej>> zostanie uruchomiony proces nadpisywania GUID ów kartotek. Po zakończeniu nadpisywania GUID ów należy przejść do kolejnego etapu. Jeśli uzgodniono wszystkie kartoteki, należy zakończyć pracę z aplikacją i przejść do dalszej części wdrażania mechanizmów replikacji.