Uruchomienie nowego kontekstu aplikacji

Transkrypt

1 Uruchomienie nowego kontekstu aplikacji Niniejsza instrukcja (przygotowana dla systemów Debian) dotyczy uruchomienia nowej aplikacji w sytuacji, gdy mamy już jedną działającą. Działanie takie trzeba wykonać jeśli na przykład nastąpi zmiana kodu świadczeniodawcy (nadawanego przez NFZ). Należy wówczas utworzyć kopię istniejącej bazy i aplikacji produkcyjnej, aby z jednej strony mieć możliwość generowania raportów statystycznych i zaimportowania umów NFZ z nowym kodem, a z drugiej zachować możliwość sprawozdawania świadczeń sprzed zmiany kodu. Na potrzeby tej instrukcji zakładamy, że istnieje potrzeba stworzenia aplikacji o nazwie archiwum, zawierającej dane sprzed zmiany kodu, rejestrowane na umowy wystawione na poprzedni kod. Po jej utworzeniu będzie można zmienić kod świadczeniodawcy w aplikacji produkcyjnej, a następnie zaimportować do niej umowy z NFZ i rejestrować w niej świadczenia. UWAGA: instrukcja nie obejmuje operacji zmiany samego kodu świadczeniodawcy. Ponieważ wartość tego kodu jest zapisana w bazie danych i nieedytowalna z poziomu aplikacji, po wykonaniu instrukcji należy zwrócić się do producenta oprogramowania z prośbą o jego zmianę. Należy podać wówczas nazwę bazy, w której ma zostać zmieniony kod świadczeniodawcy, dotychczasową wartość kodu, a także wartość, na jaką ma zostać on zmieniony. Spis treści 1 Kopia bazy produkcyjnej 1.1 Wykonanie kopii bazy danych 1.2 Stworzenie pustej bazy 1.3 Przywrócenie bazy danych 1.4 Vacuum i reindeksacja 2 Działania po przywróceniu bazy danych 2.1 Tworzenie kopii aplikacji 2.2 erejestracja 2.3 Plik build.properties 2.4 Kontekst aplikacji 3 Dodatkowa konfiguracja aplikacji 3.1 Na aplikacji archiwalnej 3.2 Na aplikacji produkcyjnej 3.3 Uwagi

2 Kopia bazy produkcyjnej Ta część instrukcji obejmuje wykonanie kopii istniejącej bazy produkcyjnej, utworzenie nowej, pustej bazy a następnie wczytanie stworzonej kopii do pustej bazy. poniżej omówiono szczegółowo procedurę postępowania. Wykonanie kopii bazy danych W pierwszej kolejności należy wykonać kopię istniejącej bazy danych czyli stworzyć tzw. plik dump, zawierający wszystkie dane z bazy. W tym celu należy zalogować się na serwer (jako użytkownik posiadający odpowiednie uprawnienia najlepiej jako root) i wydać polecenie: pg_dump -Fc -f [sciezka]/[nazwa_pliku] [nazwa_bazy] gdzie sciezka oznacza katalog, w którym zostanie zapisany plik dump, [nazwa_pliku] oznacza nazwę tego pliku, a [nazwa_bazy] to nazwa istniejącej już w systemie bazy danych. Przykładowo polecenie może to wyglądać tak jak poniżej: pg_dump -Fc -f /root/dump sql aplikacja Wynikiem działania tego polecenia będzie utworzenie w katalogu /root pliku o nazwie dump sql, zawierającego dane z bazy o nazwie aplikacja. Stworzenie pustej bazy Plik dumpa bazy danych należy następnie wczytać do nowej, pustej bazy. W tym celu wydajemy polecenie: createdb --encoding=latin2 [nazwa_bazy_danych]; Gdzie nazwa_bazy_danych oznacza nazwę nowej, pustej bazy danych którą chcemy utworzyć. Czyli na przykład polecenie: createdb --encoding=latin2 archiwum; stworzy pustą bazę danych o nazwie archiwum. Przywrócenie bazy danych Następnie należy wczytać plik dump do nowej, pustej bazy danych. W tym celu należy wydać polecenie: pg_restore -Fc -d [nazwa_bazy] [sciezka]/[nazwa_pliku]

3 Gdzie [nazwa_bazy] to nazwa naszej nowej, pustej bazy, [sciezka] to ścieżka dostepu do stworzonego wcześniej pliku z dumpem, a [nazwa_pliku] to nazwa tego pliku. Przykładowo polecenie takie może mieć postać: pg_restore -Fc -d archiwum /root/dump sql Po wykonaniu tego polecenia baza archiwum rozpocznie się proces przywracania bazy danych. Proces ten może potrwać długo w zależności od rozmiaru przywracanej bazy. W wyniku działania tego polecenia baza archiwum otrzyma identyczną postać jaki miała baza produkcyjna w momencie gdy tworzony był plik dump. Vacuum i reindeksacja Nowoutworzoną bazę należy poddać operacji vacuum i reindeksacji. Jeśli nie wykonamy tej operacji będzie ona działać wolno. Wydajemy zatem kolejno polecenia: psql [nazwa_bazy] -c "vacuum analyze" psql [nazwa_bazy] -c "reindex database nazwa_bazy" Gdzie [nazwa_bazy] określa nazwę bazy, dla której ta operacja ma być przeprowadzona. W naszym przypadku polecenia te będą wyglądać następująco: psql archiwum -c "vacuum analyze" psql archiwum -c "reindex database nazwa_bazy" Po wykonaniu tych komend na bazie archiwum zostaną przeprowadzone operacje vacuum i reindeksacji.

4 Działania po przywróceniu bazy danych Tworzenie kopii aplikacji Po przywróceniu bazy danych należy jeszcze dodatkowo przygotować ją do pracy. W tym celu należy przede wszystkim utworzyć kopię aplikacji produkcyjnej w nowym katalogu. Załóżmy, że aplikacja produkcyjna działa w katalogu /home/aplikacja, a jej kopia powinna działać w katalogu /home/archiwum. Powinniśmy zatem kolejno wydać na serwerze polecenia: utworzenia nowego katalogu /home/archiwum UWAGA: Uprawnienia dostępu do tego katalogu, jak również jego właściciel i grupa powinny być dokładnie takie same jak katalogu aplikacji produkcyjnej! skopiowania całej zawartości katalogu /home/aplikacja do katalogu /home/archiwum erejestracja niniejsza instrukcja zakłada sytuację w której tworzymy bazę danych oraz aplikację zawierającą dane archiwalne a aplikacja dotychczas używana będzie służyć do rejestracji danych bieżących. Jeśli wykonywalibyśmy operację odwrotną, tzn nowo utworzona baza i aplikacja miałaby służyć do rejestracji danych bieżących, wówczas bylibyśmy zobligowani do wprowadzenia zmian na serwerze erejestracji (w pliku build.properties oraz w pliku kontekstu na tym serwerze). Erejestracja zawsze musi odwoływać się do aplikacji w której rejestrowane są bieżące dane. Plik build.properties Kolejnym krokiem będzie modyfikacja pliku build.properties, który znajduje się w katalogu głównym utworzonej kopii aplikacji (czyli w naszym przypadku w katalogu /home/archiwum). Plik ten zawiera parametry konfiguracyjne aby nowa aplikacja działała prawidłowo należy w nim dostosować następujące wartości: app.home parametr powinien wskazywać na katalog nadrzędny dla aplikacji. W naszym przypadku (aplikacja znajduj się w katalogu /home/archiwum) parametr powinien mieć wartość /home app.name parametr przechowuje nazwę aplikacji. Należy go zmienić na inną wartość. app.path przechowuje ścieżkę, od katalogu wskazanego w parametrze app.home do katalogu aplikacji. W naszym przypadku będzie to wartość app.path=/archiwum. psql.dbname nazwa bazy. Powinniśmy wpisać tu nazwę bazy danych tworzonej aplikacji, czyli w naszym przypadku archiwum. app.import wskazuje podkatalog import w tworzonej aplikacji. Powinien mieć wartość app.import=/home/archiwum/import.

5 UWAGA: edytując plik build.properties dla tworzonej aplikacji należy zwrócić uwagę na kilka dodatkowych rzeczy: parametr check.ewus sprawdzanie ewuś powinno być włączone tylko w jednej aplikacji. Wartość true (check.ewus=true) ma być ustawiona tylko w aplikacji służącej do rejestracji bieżących danych. Dodatkowo w aplikacjach testowych lub zawierających dane historyczne (czyli takich, które nie służą do rejestrowania danych bieżących) należy usunąć z pliku jobs.xml (katalog /home/[nazwa aplikacji]/web/ oraz /home/[nazwa aplikacji]/build/) konfigurację automatycznego sprawdzenia ewuś. parametr start.hl7 konfiguracja serwisów HL7 powinna działać wyłącznie w jednej aplikacji. Wartość true (start.hl7=true) ma być ustawiona tylko w aplikacji służącej do rejestracji bieżących danych. Dodatkowo w aplikacjach testowych lub zawierających dane historyczne (czyli takich, które nie służą do rejestrowania danych bieżących) należy wyłączyć wszystkie serwisy HL7 (zakładka Ustawienia Serwisy HL7). parametr pobierz.send.log w aplikacjach testowych lub zawierających dane historyczne (czyli takich, które nie służą do rejestrowania danych bieżących) należy ustawić na wartość false (pobierz.send.log=false). Opcja odpowiada za wysyłanie logów instalacji nowej wersji. Kontekst aplikacji Konteksty aplikacji definiują pliki XML, znajdujące się w katalogu /etc/tomcat[numer]/catalina/localhost/ Przy czym wartość [numer] może być różna, w zależności od zainstalowanej wersji Tomcata. Jeśli na serwerze działa aktualnie aplikacja, to w tym katalogu powinien znajdować się plik XML z jej kontekstem o takiej samej nazwie jak nazwa aplikacji. Na przykładzie: jeśli adres działającej aplikacji to to w katalogu kontekstów musi znajdować się plik APLIKACJA.xml zawierający dane kontekstu. Aby stworzyć kontekst dla nowej aplikacji należy utworzyć w tym katalogu kopię istniejącego pliku z kontekstem aplikacji produkcyjnej (nowemu plikowi musimy nadać taką nazwę, jaką ustawiliśmy w zmiennej app.name w pliku build.properties czyli plik build.properties zawiera wartość app.name=archiwum, to nowy plik powinien nazywać się archiwum.xml). W naszym przypadku należy zatem wydać polecenie: cp /etc/tomcat6/catalina/localhost/aplikacja.xml /etc/tomcat6/catalina/localhost/archiwum.xml UWAGA: Proszę zwrócić uwagę, że na powyższym przykładzie na serwerze działa Tomcat w wersji 6 stąd katalog /etc/tomcat6. Dla innych wersji może to być na przykład katalog /etc/tomcat5.5 czy /etc/tomcat7. Skopiowany plik edytujemy i zmieniamy w nim następujące dane: <Context docbase="[ścieżka1]" path="[ścieżka2]" (...) wartość [ścieżka1] musi wskazywać na podkatalog build katalogu nowej aplikacji, czyli w naszym przypadku będzie miała wartość /home/archiwum/build

6 wartość [ścieżka2] musi być zgodna z wartością app.path= ustawioną w pliku build.xml w poprzednim kroku. url="jdbc:postgresql:// :5432/[nazwa]?charset=windows-1250" wartość [nazwa] musi być taka jak nazwa bazy danych. W naszym przypadku zatem ta linijka powinna wyglądać tak: url="jdbc:postgresql:// :5432/archiwum?charset=windows 1250" UWAGA: Po wykonaniu powyższych działań należy zrestartować Tomcata.

7 Dodatkowa konfiguracja aplikacji Oprócz powyższych działań należy z poziomu aplikacji wykonać dodatkowe czynności: Na aplikacji archiwalnej należy zmienić daty wszystkich aktualnych umów powinny obowiązywać tylko do dnia, do którego ZOZ funkcjonował pod poprzednim kodem resortowym. Uniemożliwi to omyłkowe rejestrowanie danych. należy ustawić wartość parametru L_SKIN_BC odpowiadającego za kolor tła aplikacji na inny nić na aplikacji produkcyjnej aby personel po zalogowaniu od razu widział na której aplikacji pracuje. Dodatkowo dobrze jest ustawić wartość parametru L_LIST_INFO, aby informował użytkowników, że aplikacja jest aplikacją archiwalną. przekonfigurować parametry L_REP_DIR, L_XSD_DIR, L_EXIM_DIR na wartości poprawne dla tej aplikacji. Na aplikacji produkcyjnej Uwagi należy zmienić daty obowiązywania aktualnych umów komercyjnych na dzień od którego ZOZ funkcjonuje pod nowym kodem świadczeniodawcy (aby nie była możliwa rejestracja danych z wcześniejszych okresów) jeśli mamy w systemie aktualne umowy z NFZ, to do czasu otrzymania umów wystawionych na nowy kod świadczeniodawcy możemy je traktować jako tymczasowe. Po otrzymaniu umów wszystkie wykonania usług w ramach tych umów zarejestrowane po dacie obowiązywania starego kodu świadczeniodawcy należy przepiąć do nowej umowy. Umowy "stare" należy wówczas zmienić w następujący sposób: typ umowy zmieniamy na "cennik". daty obowiązywania zmieniamy na od do wyłączamy pole "aktualna". należy zmienić identyfikator instalacji oraz wprowadzić nowe dane instytucji (zakładka Firmy własna edycja). Po wykonaniu powyższych działań aplikacja będzie już działać, jednak sugerujemy wykonanie jeszcze dodatkowych czynności: należy przenieść nową aplikację i bazę danych na inny serwer, ponieważ działanie jednocześnie dwóch aplikacji na jednym serwerze może powodować problemy z wydajnością. należy zadbać o to, aby obydwie bazy były poddawane vacuum, reindeksacji oraz kopii bezpieczeństwa. jeśli zmienił się kod świadczeniodawcy, to należy wyjaśnić z NFZ jak prawidłowo sprawozdań pobyty na oddziałach, których czas trwania zawiera się w dniu zmiany danych, a także sposób sprawozdawania kolejek (czy ma zostać zachowana ciągłość danych, czy też kolejki mają zostać wycofanie z jednej a wprowadzone w drugiej instytucji) należy powiadomić dział statystyki medycznej, aby zwrócił szczególną uwagę, na to z której aplikacji generują raporty za dany okres.