Podręcznik Administratora Systemu GRANIT

Dokumentacja technologiczna
i administracyjna systemu opartego

o platformę GRANIT.
Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 1 z 106

1. Spis treści.
1. SPIS TREŚCI.................................................................................................................... 2
2. BUDOWA LOGICZNA SYSTEMU. ............................................................................. 5
2.1 WARSTWA BAZY DANYCH. .......................................................................................... 5
2.1.1 Baza LOGON. ........................................................................................................ 5
2.1.2 Baza produkcyjna. .................................................................................................. 6
2.1.3 Inne bazy danych. ................................................................................................... 6
2.2 WARSTWA BIZNESOWA. .............................................................................................. 6
2.2.1 Serwer aplikacji COM+. ........................................................................................ 6
2.2.2 Komponent COM+. ................................................................................................ 6
2.3 WARSTWA PREZENTACJI. ............................................................................................ 7
3. BUDOWA FIZYCZNA SYSTEMU. .............................................................................. 9
3.1 SERWER BAZY DANYCH. .............................................................................................. 9
3.2 SERWER APLIKACJI COM+ ........................................................................................ 10
3.2.1 Komponenty. ......................................................................................................... 10
3.2.2 Dodatkowe usługi systemowe . ............................................................................. 10
3.2.3 Autoryzacja użytkowników sieciowych................................................................. 10
3.3 SERWER PLIKÓW SYSTEMU. ....................................................................................... 11
3.3.1 Aplikacje EXE. ..................................................................................................... 11
3.3.2 Formularze. .......................................................................................................... 11
3.3.3 Katalog wymiany .................................................................................................. 11
3.3.4 Inne pliki i katalogi. ............................................................................................. 11
3.4 STACJA KLIENCKA. .................................................................................................... 12
3.4.1 Pliki lokalne.......................................................................................................... 12
3.4.2 Katalog tymczasowy. ............................................................................................ 12
3.5 SIEĆ KOMPUTEROWA. ................................................................................................ 13
4. MINIMALNE WYMAGANIA SYSTEMU. ................................................................ 14
4.1 SERWER BAZY DANYCH. ............................................................................................ 14
4.2 SERWER APLIKACJI COM+. ....................................................................................... 17
4.3 STACJA KLIENCKA. .................................................................................................... 18
4.4 SIEĆ KOMPUTEROWA. ................................................................................................ 19
5. INSTALACJA SYSTEMU GRANIT ........................................................................... 20
5.1 INSTALACJA NA SERWERZE (SERWERACH)................................................................. 20
5.1.1 Instalacja za pomocą kreatora instalacji ............................................................. 20
5.1.2 Instalacja „ręczna” .............................................................................................. 29
5.2 INSTALACJA NA STACJACH ROBOCZYCH (KLIENCKICH) ............................................. 44
6. MONITOROWANIE SYSTEMU. ............................................................................... 46
6.1 SYSTEM OD STRONY BAZY DANYCH. ......................................................................... 46
6.2 SYSTEM OD STRONY SERWERA APLIKACJI COM+. .................................................... 47
7. OPTYMALIZACJA WYDAJNOŚCI SYSTEMU. ..................................................... 49
7.1 SERWER BAZY DANYCH. ............................................................................................ 49
7.1.1 Wersja serwera ..................................................................................................... 49
7.1.2 Dedykowanie serwera na potrzeby bazy danych. ................................................. 50

7.1.3 Rozmieszczenie plików baz danych i systemowego pliku wymiany. ..................... 50
7.1.4 Defragmentacja dysków. ...................................................................................... 51
7.1.5 Aktualizacja statystyk indeksów baz danych ........................................................ 52
7.1.6 Parametry serwera bazy danych. ......................................................................... 53
7.1.7 Dedykowanie serwera na potrzeby systemu GRANIT. ......................................... 53
7.1.8 Priorytet usług ...................................................................................................... 53
7.1.9 Systemy antywirusowe i zapór.............................................................................. 55
7.2 SERWER APLIKACJI COM+ ........................................................................................ 55
7.2.1 Tożsamość aplikacji COM+. Użytkownik interakcyjny lub dedykowany. ........... 55
7.2.2 Systemy antywirusowe i zapór.............................................................................. 58
7.2.3 Dedykowanie serwera aplikacji COM+ na potrzeby systemu GRANIT. ............. 58
7.2.4 Połączenie sieciowe z serwerem bazy danych. ..................................................... 58
7.3 STACJA KLIENCKA. .................................................................................................... 58
7.3.1 Inne oprogramowanie. Systemy antywirusowe i zapór. ....................................... 58
7.3.2 Kompresowanie danych wymienianych z serwerem ............................................ 58
7.3.3 Rozmiar paczki zwracanych w zestawieniu. ......................................................... 59
7.3.4 Buforowanie definicji formularzy na stacji lokalnej ............................................ 60
7.3.5 Rozpoznawanie nazwy serwera aplikacji ............................................................. 60
7.3.6 Dystrybucja uaktualnienia aplikacji na stacjach roboczych ................................ 61
7.3.7 Ogólne uwagi ....................................................................................................... 62
8. BEZPIECZEŃSTWO DANYCH I SYSTEMU ........................................................... 63
8.1 DOSTĘP DO DANYCH .................................................................................................. 63
8.1.1 Baza danych ......................................................................................................... 63
8.1.2 Serwer plików i aplikacji COM+ ......................................................................... 63
8.2 OPROGRAMOWANIE ANTYWIRUSOWE I ZAPÓR........................................................... 63
8.3 POLITYKA KOPII ZAPASOWYCH. ................................................................................. 64
8.3.1 Kopia systemu i bazy danych – narzędzie systemu GRANIT ............................... 64
8.3.2 Kopia bazy danych – narzędzie Microsoft. .......................................................... 68
8.3.3 Kopia systemu GRANIT – narzędzia Windows.. .................................................. 72
8.3.4 Kopia całego serwera........................................................................................... 73
9. NADPISYWANIE BAZY TESTOWEJ BAZĄ PRODUKCYJNĄ. .......................... 75
9.1 NARZĘDZIA SYSTEMU GRANIT ................................................................................ 75
9.2 SQL SERVER AGENT. ................................................................................................ 76
9.2.1 SQL Serwer Agent – zakładka „General” ........................................................... 77
9.2.2 SQL Serwer Agent – zakładka „Steps” ................................................................ 78
9.2.3 Backup bazy produkcyjnej. ................................................................................... 79
9.2.4 Nadpisanie kopii bazą produkcyjną. .................................................................... 80
9.2.5 Usunięcie backpu bazy produkcyjnej. .................................................................. 81
9.2.6 SQL Serwer Agent – zakładka „Schedules” ........................................................ 82
9.2.7 SQL Serwer Agent – zakładka „Notifications” .................................................... 83
9.3 NAPISYWANIE BAZY TESTOWEJ PRODUKCYJNĄ ZA POMOCĄ SKRYPTU....................... 84
9.3.1 Skrypt nadpisujący bazę testową bazą produkcyjną. ........................................... 84
9.3.2 Opis najważniejszych elenentów skryptu nadpisującego bazę testową. .............. 85
10. KONFIGURACJA URZĄDZEŃ WSPÓŁPRACUJĄCYCH Z SYSTEMEM
GRANIT. ................................................................................................................................. 87
10.1 DRUKARKI FISKALNE................................................................................................. 87

10.1.1 Konfiguracja uprawnień dla zdalnej aktywacji składników z wykorzystaniem
uzytkownika nie-domenowego .......................................................................................... 88
10.1.2 Konfiguracja uprawnień dla zdalnej aktywacji składników z wykorzystaniem
uzytkownika domenowego ................................................................................................ 88
 Użytkownik domenowy przygotowany do aktywacji zdalnej składników powinien
mieć uprawnienia administratora i należeć do grupy operatorów DCOM. .................... 89
 Aktywacja pakietu Invoice powinna odbywać się na koncie tego użytkownika oraz
należy zapewnić możliwość zdalnej aktywacji składników tego pakietu (edycja
uprawnień): ...................................................................................................................... 89
10.1.3 Konfiguracja parametrów uruchomieniowych................................................. 89
11. ROZWIĄZANIA NAJCZĘŚCIEJ SPOTYKANYCH PROBLEMÓW. .............. 93
11.1 PROBLEMY ................................................................................................................ 93
11.1.1 System nie daje się uruchomić na stacji klienckiej........................................... 93
11.1.2 System nie daje się uruchomić na wszystkich stacjach klienckich. .................. 93
11.1.3 System nie daje się uruchomić nawet na serwerze aplikacji COM+. .............. 94
11.1.4 System wolno działa na stacji klienckiej. ......................................................... 94
11.1.5 System wolno działa również na serwerze aplikacji COM+. ........................... 95
11.1.6 Aplikacja na stacji klienckiej loguje się bez pytania o hasło. .......................... 95
11.2 ELEMENTARNE OPERACJE ROZWIĄZYWANIA PROBLEMÓW. ....................................... 95
11.2.1 Zdalna praca komponentów COM. .................................................................. 95
11.2.2 Sprawdzenie poprawności autoryzacji użytkownika Windows stacji klienckiej
na serwerze aplikacji COM+. .......................................................................................... 95
11.2.3 Sprawdzenie działania systemu rozpoznawania nazw DNS na stacji klienckiej.
98
11.2.4 Wpisy w plikach HOSTS i LMHOSTS. ............................................................. 98
11.2.5 Sprawdzenie szybkości i jakości połączenia sieciowego. ................................. 99
11.2.6 Sprawdzenie obciążenia serwera bazy danych. ............................................. 100
11.2.7 Sprawdzenie obciążenia serwera aplikacji COM+. Sprawdzenie bieżącego
stanu ogólnego serwera aplikacji COM+ pod kątem wszystkich aplikacji COM+. ...... 100
11.2.8 Włączenie kompresji danych pomiędzy serwerem aplikacji COM+ a stacją
kliencką dla danego użytkownika. .................................................................................. 103
11.2.9 Awaryjne, zamknięcie procesu(ów) aplikacji COM+. ................................... 103
11.2.10 Sprawdzenie w jakiej tożsamości pracują komponenty COM+ na serwerze
aplikacji COM+. ............................................................................................................ 105
12. PRZYGOTOWYWANIE TECHNICZNEGO ZGŁOSZENIA SERWISOWEGO
106

2. Budowa logiczna systemu.
System oparty jest na architekturze trójwarstwowej:
 Warstwę bazy danych oparto na serwerze bazy danych firmy Microsoft®: MS
SQL Server . Minimalną wersją na jakiej system poprawnie działa jest wersja
2005® (tryb kompatybilności z MS SQL Server 2000).
 Warstwę biznesową stanowi technologia COM+ opracowana przez firmę
Microsoft i dołączaną do każdego z systemów operacyjnych MS Windows
Server®: 2000, 2003, 2008, 2008 R2
 Warstwa prezentacji to szereg aplikacji typu EXE dla platformy zgodnej z MS
Windows: 2000 (SP4 oraz zainstalowany gdi+), XP, Vista, 7
Rys. 2-1 Logiczna struktura systemu.
2.1 Warstwa bazy danych.

Warstwa bazy danych obsługuje wszystkie aktywności związane z przechowywaniem
danych systemu, udostępnianiem ich pozostałym elementom systemu oraz zapewnia
im bezpieczeństwo. Fizycznie realizowana jest przez komputer serwera bazy danych
z oprogramowaniem serwera bazy danych. Dane systemu przechowywane są w
poszczególnych bazach danych. Cześć z tych baz pełni rolę pomocniczą dla systemu
a część z nich jest faktycznymi produkcyjnymi bazami klienta.
Do poprawnego działania system wymaga dwóch baz danych. Bazy LOGON i bazy
produkcyjnej.
2.1.1 Baza LOGON.

Pierwsza z nich to tzw. baza definicyjna (logująca) o nazwie kończącej się ciągiem
znaków „_LOGON”. Jej rolą jest zdefiniowanie połączeń pomiędzy komponentem
bazodanowym, a faktycznymi bazami roboczymi. Dodatkowo umieszczone są tutaj
dane systemu, które są niezależne od kontekstu poszczególnych roboczych baz
danych. W systemie występuje tylko jedna logująca baza danych.

2.1.2 Baza produkcyjna.
Druga baza to tzw. baza produkcyjna, czyli baza z rzeczywistymi danymi
przedsiębiorstwa Klienta. W standardowej instalacji baza produkcyjna jest tylko jedna
ale istnią także instalacje, w których baz produkcyjnych jest kilka.
2.1.3 Inne bazy danych.

Bazy testowe – bazy powstałe z bazy produkcyjnej przeznaczone do testowania
procesów na danych rzeczywistych lub danych testowych. Z reguły baza ta
odświeżana jest przez administratora systemu danymi z bazy rzeczywistej w
określonych odstępach czasu. Odświeżenie kopii powoduje nadpisanie i utratę
modyfikacji wprowadzonych do tej bazy przez użytkowników.
Podczas prac wdrożeniowych (jak i rozwojowych po wdrożeniu) mogą powstać także

inne bazy danych, na przykład bazy migracyjne służące do migracji danych z
systemów zewnętrznych do systemu Granit (lub w drugą stronę).
Rys. 2-2 Bazy danych systemu GRANIT. Aplikacja Microsoft SQL Server
Management Studio
2.2 Warstwa biznesowa.

Warstwa ta, zwana również warstwą logiki, zawiera tzw. logikę branżową, związaną z
poszczególnymi funkcjonalnościami modułów branżowych systemu Granit. Tutaj
umieszczane są również wszystkie komponenty systemowe. Fizycznie warstwę
aplikacji realizuje silny komputer (lub ich grupa) na tym komputerze odbywa się
faktyczne przetwarzanie danych systemu.
2.2.1 Serwer aplikacji COM+.

Serwer aplikacji COM+ pod względem logicznym implementuje warstwę biznesową
(warstwę logiki) pośrednią pomiędzy warstwą bazy danych, a warstwą prezentacyjną.
2.2.2 Komponent COM+.

Komponent to fragment binarnego kodu systemu zawierający w sobie obsługę
pewnego wycinka funkcjonalności. W systemie komponentami są „komponenty
aplikacji COM+” zarejestrowane na serwerze komponentów. Fizycznie komponentem
jest plik DLL umieszczony w katalogu na serwerze komponentów.

Komponentowa budowa systemu gwarantuje ważną cechę: modularność.
Komponenty mogą być wymieniane na nowsze czy dodawane bez konieczności
zatrzymywania systemu jako całości. Ewentualne problemy w działaniu jednego z
nich nie powodują zakłócenia pracy innych niezależnych komponentów.
2.2.2.1 Komponenty systemowe.

Komponenty systemowe to grupa komponentów przeznaczona do obsługi
funkcjonalności związanych z samych systemem jako takim, a nie
z funkcjonalnościami branżowymi firmy klienta. Stanowią one część tzw. jądra
systemu GRANIT (inne nazwy to: core (ang.), kernel, część uniwersalna). Aplikacje
COM+ które zawierają komponenty systemowe oznaczone są przedrostkiem „_”
odróżniającym je od innych komponentów (komponentów biznesowych).
W grupie komponentów systemowych wyróżniamy m.in. komponent do komunikacji

z bazą danych oraz komponenty komunikacji z warstwą prezentacyjną (stacją
kliencką).
2.2.2.2 Komponent do komunikacji z bazą danych.

W systemie, w grupie komponentów systemowych, występuje jeden specjalny
komponent przeznaczony do komunikacji z bazą danych. Cała komunikacja
pomiędzy bazą danych, a resztą systemu odbywa się przez ten komponent.
2.2.2.3 Komponenty logiki biznesowej.

Komponenty biznesowe to komponenty w których zaszyta jest właściwa branżowa
logika systemu. Grupa tych komponentów stanowi sedno wdrożenia, jest sercem
funkcjonalności związanych z branżą i specyfiką firmy klienta. Komponenty
pogrupowane są w pakiety skupiające komponenty z danego modułu branżowego.
2.2.2.4 Komponenty komunikacji z warstwą prezentacji.

Komponenty komunikacji z warstwą prezentacyjną to grupa kilku komponentów
należąca do komponentów systemowych. Ich rolą jest pośredniczenie pomiędzy
komputerem użytkownika (aplikacjami systemu na stacji klienckiej) a serwerem
komponentów systemu (systemem jako takim).
2.3 Warstwa prezentacji.

Warstwa prezentacji, zwana również warstwą interfejsu, służy do pokazywania
danych użytkownikowi i obsługuje całość komunikacji serwera z użytkownikiem
(interfejs systemu). System zbudowany jest według zasady „cienkiego klienta –
grubego serwera” („Thin Client – Thick Server”) oznacza to że warstwa prezentacji
jako cienki klient nie wykonuje żadnych przetwarzań danych i w związku z tym ma
minimalne wymagania i może działać na słabych komputerach.
Warstwa ta realizowana jest poprzez aplikację typu EXE.

Rys. 2-3. Aplikacja interfejsu użytkownika.

3. Budowa fizyczna systemu.
Rdzeń systemu oparty jest o jeden lub więcej serwerów otoczonych stacjami
klienckimi użytkowników systemu.
Rys. 3-1. Przykładowa realizacja systemu GRANIT.
3.1 Serwer bazy danych.

Podstawą systemu jest serwer bazy danych oparty o Microsoft SQL Server w wersji
2005 lub nowszej. Może on być zainstalowany jako osobny, pełny produkt (np.
Standard Edition) lub jako darmowy pakiet Microsoft SQL Server Express (w
zależności od przewidywanego przyrostu bazy danych i możliwości finansowych
klienta).
Po standardowej instalacji systemu na serwerze zainstalowane są trzy bazy danych:
produkcyjna, LOGON oraz baza testowa (kopia). Dla niewielkich wdrożeń serwer
bazy danych jest zainstalowany na tym samym komputerze co serwer aplikacji
COM+

3.2 Serwer aplikacji COM+
Serwer ten realizowany jest przez część systemu operacyjnego wbudowaną w
systemy serwerowe Windows.
3.2.1 Komponenty.
Rdzeniem systemu serwera aplikacji są komponenty COM+. Komponenty te są
fizycznie specjalnymi plikami DLL zawartymi w katalogu ..\Components\ lub
..\Components.Net\ zarejestrowanymi w rejestrze komputera pełniącego rolę serwera
aplikacji COM+. Komponenty te charakteryzują się tym, że mogą wykonać operacje
jako element przetwarzania rozproszonego (tu: zdalnie na zlecenie aplikacji
uruchomionej na komputerze stacji roboczej). Mechanizm rozproszonej pracy
aplikacji COM+ opiera się na kilku standardowych usługach systemowych Windows.
3.2.2 Dodatkowe usługi systemowe .

Dodatkowym elementem serwera aplikacji COM+ są klasyczne usługi systemowe
niezbędne do realizacji dodatkowych operacji na systemie (okresowe wykonywanie
zaplanowanych zadań, usuwanie niepoprawnie odłączonych klientów itp.).
Są to usługi:
 DDSystemService,
 DDTaskService
Rys. 3-2. Przykładowa usługa systemowa GRANIT DDSystemService.
3.2.3 Autoryzacja użytkowników sieciowych.

Ze względu na architekturę COM+ warstwy aplikacji istnieje konieczność poprawnej
autoryzacji użytkowników stacji klienckich na serwerze komponentów. Serwer, zanim
pozwoli skorzystać ze swoich zasobów COM+ musi rozpoznać sieciowego
użytkownika. Występują tutaj dwa warianty:
 W pierwszym, oba komputery, zarówno serwer aplikacji COM+ jak i stacja
kliencka, podłączone są do wspólnej domeny. Przy takim rozwiązaniu problem
autoryzacji praktycznie nie istnieje.
 W drugim przypadku jeden lub oba komputery działają w grupie roboczej lub w
różnych domenach. W takim przypadku istnieje konieczność tworzenia na

serwerze COM+ użytkowników będących dokładnymi (pod względem nazwy i
hasła) odpowiednikami użytkowników dla stacji klienckiej i pilnowania zmian
haseł.
3.3 Serwer plików systemu.

Praca sieciowa systemu wymaga, aby któryś z serwerów pełnił role serwera plików
systemu. Praktycznie zawsze rolę tę pełni serwer komponentów, który udostępnia
użytkownikom na stacjach klienckich określone katalogi w określonych prawach
dostępu. Czasami ze względów wydajności sieci rolę serwera plików może pełnić
inny komputer.
Poniżej opisano wszystkie udziały sieciowe serwera plików których katalogi
macierzyste znajdują się w katalogu głównym systemu GRANIT
3.3.1 Aplikacje EXE.

Serwer plików udostępnia sieciowo aplikacje warstwy klienckiej w udziale sieciowym
o nazwie Programs lub ServerApplications. Oprócz plików EXE w jest również tym
katalogu umieszczony skrót instalująco-uruchamiający do systemu. Udział ten
powinien być udostępniony użytkownikom na stacjach roboczych z prawami:
 odczytu.
3.3.2 Formularze.
Innym udziałem jest udział z definicjami formularzy. Udział sieciowy nazwany Forms
powinien być przydzielony wszystkim użytkownikom systemu z prawami
 odczytu.
3.3.3 Katalog wymiany

Podczas pracy z systemem GRANIT istnieje konieczność wymiany wygenerowanych
plików pomiędzy serwerem a stacją roboczą. Służy do tego udział sieciowy na
serwerze plików o nazwie Exports. Udział ten powinien być udostępniony dla
wszystkich użytkowników systemu z prawami:
 Odczytu
 Zapisu
UWAGA:
Katalog ten pełni też często rolę katalogu wymiany danych pomiędzy serwerem
SQL a serwerem aplikacji dlatego też powinien też mieć do niego PEŁNY
dostęp użytkownik na których działa usługa SQL serwera
3.3.4 Inne pliki i katalogi.

Dodatkowo na serwerze plików mogą być udostępnione inne udziały sieciowe do
plików systemu. Głównie na potrzeby administracyjne i wsparcia technicznego.
Jednym z takich udziałów jest udział LOG. Udostępniony jest zazwyczaj tylko dla
administratorów dlatego też często jest on niewidoczny w otoczeniu sieciowym –
udostępniony jako LOG$. W czasie wdrożenia mogą powstawać dodatkowe

katalogi i udziały, których konfiguracja i przeznaczenie jest ustalane w trakcie
prac wdrożeniowych.
UWAGA:
Użytkownik, w którego kontekście chodzą komponenty powinien mieć pełne
prawa do wszystkich udziałów systemu Granit.
3.4 Stacja kliencka.
Rolę stacji klienckiej pełni komputer użytkownika systemu. W specyficznych

przypadkach stacją kliencką może być komputer serwera aplikacji COM+ lub serwera
bazy danych.
3.4.1 Pliki lokalne.

Podczas instalacji i normalnej pracy systemu GRANIT na komputer stacji klienckiej
kopiowane są pliki.
W miarę pracy z systemem i używania dodatkowych programów są one sukcesywnie
kopiowane do określonego katalogu na stacji klienckiej. Katalog ten najczęściej
znajduje się w %appdata%\DomConsult (ścieżka ta może być zmieniona poprzez
odpowiednią modyfikację pliku company.ini, który znajduje się na serwerze
aplikacji w katalogu z aplikacjami).
Rys. 3-3. Pliki lokalne na stacji roboczej.
3.4.2 Katalog tymczasowy.

Drugim rodzajem plików kopiowanych do stacji roboczej są pliki tymczasowe,
wygenerowane dla danego użytkownika. Składowane one są w katalogu
tymczasowym (definiowanym przez zmienna systemową TEMP) w podkatalogu
$ddtemp.

Katalog tymczasowy pełni również rolę bufora definicji formularzy, jeśli opcja
buforowania jest włączona.
Rys. 3-4. Szybki sposób pokazania zawartości katalogu tymczasowego.
3.5 Sieć komputerowa.

Kolejnym elementem sprawnie działającego systemu jest sieć komputerowa. W
zalezności od polityki bezpieczeństwa obowiązującej w u klienta czasami konieczne
jest także skonfigurowanie serwerów i/lub stacji klienckich tak by współpracowały z
oprogramowaniem zapór sieciowych.

4. Minimalne wymagania systemu.
Poniżej omówiono minimalne wymagania, jakie powinny spełniać wszystkie elementy
systemu tak by umożliwiać prawidłową pracę. Poniższe uwagi mają charakter ogólny.
Szczegółowe specyfikacje wymagań systemu zależą w znacznej mierze od ilości
użytkowników, ilości serwerów oraz specyfiki klienta i produktu działającego na bazie
GRANIT, które określane są dla każdego wdrożenia indywidualnie.

 Serwer bazy danych musi posiadać system operacyjny umożliwiający
poprawne działanie oprogramowania bazy danych. Wspieranymi systemami
operacyjnymi są:
o Microsoft Windows 2000 Server (niezalecany),
o Microsoft Windows 2003 Server,
o Microsoft Windows 2008 R2 Server (preferowany)
Wspieranymi nieserwerowymi systemami operacyjnymi są:
o Microsoft Windows 2000 Professional (niezalecany),

o Microsoft Windows XP,
o Microsoft Windows Vista,
o Microsoft Windows 7
 Serwer bazy danych powinien posiadać wystarczającą pojemność dyskową do

przechowania rosnących baz danych.
 Serwer powinien posiadać poprawnie skonfigurowany interfejs sieciowy do
komunikacji z innymi maszynami wchodzącymi w skład systemu.
 Minimalną wersją oprogramowania serwera bazy danych jest wersja
o Microsoft SQL 2005 (od wersji Express)
 podczas instalacji serwera bazy danych należy zwrócić uwagę na kodowanie
języka (collation), aby było ustawione na „Polish_CI_AS” (w późniejszej
fazie, zmiana tego parametru może okazać się problematyczna)

 na serwerze bazy danych powinien być udostępniony tryb autoryzacji:
mix-mode, tzn. Windows Authentication oraz SQL Server Authentication
mode
 na serwerze bazy danych powinna być udostępniona możliwość zdalnego

łączenia się z serwerem

 na serwerze bazy danych powinien być utworzony dedykowany użytkownik
wykorzystywany przez system GRANIT
 dedykowany użytkownik powinien mieć uprawnienia roli:

o „bulkadmin”,
o „dbcreator”,
o „diskadmin”,
o „processadmin” ,
o „public”
lub zamiast tych pięciu - uprawnienia roli „sysadmin” , „public”

UWAGA
Do instalacji baz systemu GRANIT potrzebny jest użytkownik z
uprawnieniami administratora serwera SQL – ‘sysadmin’. Uprawnienia te
po instalacji można ograniczyć do tych wymienionych powyżej.
Należy pamiętać aby raczej nie korzystać z konta domyślnego ‘sa’ i
stworzyć oddzielne konto z takimi uprawnieniami.
 Standardowo proces obsługujący SQL Server działa na użytkowniku

systemowym. W szczególnych przypadkach konfigurację tę można zmienić
jednak należy pamiętać iż do poprawnego działania serwera bazy danych
niezbędne jest nadanie takiemu użytkownikowi specjalnych uprawnień, w tym
odpowiednich uprawnień do katalogów, gdzie zainstalowany jest SQLServer
jak również do katalogów gdzie składowane są pliki baz danych i robione są
kopie bezpieczeństwa. Dokładna konfiguracja takiego użytkownika wykracza
poza zakres tego dokumentu.
4.2 Serwer aplikacji COM+.

 Serwer aplikacji musi posiadać nowy system operacyjny umożliwiający
poprawne działanie mechanizmu COM+. Wspieranymi serwerowymi
systemami operacyjnymi są:
o Microsoft Windows 2008 R2 Server (preferowany).
Wspieranymi nieserwerowymi systemami operacyjnymi są:
o Microsoft Windows 2000 Professional,

o Microsoft Windows XP
 Professional
 Home Edition
o Microsoft Windows 7.

UWAGA: część systemów nieserwerowych może pełnić rolę serwera aplikacji, ale
tylko w prostym systemie bez stacji klienckich (jeden komputer pełni rolę obu
serwerów i jedynej stacji klienckiej; bez możliwości podłączenia się do takiej instalacji
z innego komputera).
 Mechanizm rozproszonej pracy aplikacji COM+ opiera się na kilku usługach

systemowych. Usługi te muszą być włączone. Są to:
o „Distributed Transaction Coordinator”,
o „Menedżer kont zabezpieczeń”
o „Zdalne wywoływanie procedur (RPC)”.
 Dodatkowo dla systemów operacyjnych od MS Windows 2003 Server (w górę)
wymagane jest zainstalowanie roli serwera aplikacji dla obsługi zdalnej
COM+, która nie jest instalowana podczas domyślnej instalacji
 Na serwerze wymagane jest zainstalowanie pakietu Microsoft Data Access
Components (MDAC) o wersji 2.8 lub nowszej – w nowszych systemach
serwerowych pakiet ten jest domyślnie zainstalowany.
 Serwer powinien posiadać poprawnie skonfigurowany interfejs sieciowy do
komunikacji z innymi maszynami wchodzącymi w skład systemu.
 Użytkownicy, na których są zalogowane stacje klienckie(w grupie roboczej
bądź domenie) powinny mieć uprawnienia do zdalnego uruchamiania
komponentów COM+ na serwerze aplikacji COM+.
 W ramach konfiguracji mechanizmu COM+ opcja „Włącz model obiektów
rozproszonych na tym komputerze” musi być włączona.
 Zalecane jest wyłączenie zapory (FIREWALL’a) która może być przyczyną
problemów z komunikacją COM+ w sieci komputerowej (jej włączenie wymaga
przeprowadzenia dodatkowych prac konfiguracyjnych).

 Stacja kliencka powinna posiadać parametry umożliwiające bezproblemowe
uruchamianie aplikacji klienckich. Komputer taki powinien posiadać system
operacyjny umożliwiający poprawne działanie mechanizmu DCOM.
Wspieranymi systemami operacyjnymi są:
o Microsoft Windows 2000 Professional (niezalecany),
o Microsoft Windows XP,
o Microsoft Windows 7.
 Stacja kliencka powinna posiadać poprawnie skonfigurowany interfejs
sieciowy do komunikacji z innymi maszynami wchodzącymi w skład systemu,
ze szczególnym uwzględnieniem serwera aplikacji COM+. Szczególnie istotne
jest szybki i prawidłowe rozpoznawanie po nazwie komputera pełniącego rolę
serwera aplikacji.
 Użytkownik na stacji klienckiej musi być zalogowany do systemu na
określonego użytkownika rozpoznawalnego przez serwer aplikacji COM+.
 Użytkownik na stacji klienckiej musi być mieć uprawnienia do zasobów
udostępnionych na serwerze plików.
 Na stacji roboczej muszą działać następujące usługi:
o „Menedżer kont zabezpieczeń”

o „Zdalne wywoływanie procedur (RPC)”.
 W ramach konfiguracji mechanizmu COM+ opcja „Włącz model obiektów
rozproszonych na tym komputerze” musi być włączona.
 Zalecane jest wyłączenie zapory (FIREWALL’a) która może być przyczyną
problemów z komunikacją COM+ w sieci komputerowej (jej włączenie wymaga
przeprowadzenia dodatkowych prac konfiguracyjnych).
4.4 Sieć komputerowa.

 Wymaganą siecią jest sieć 100 Mb/s lub szybsza.
 Sieć komputerowa powinna być stabilna. Wszelkie wahania w pracy sieci i
nieprawidłowa konfiguracja w znacznym stopniu odbijają się na stabilności
systemie GRANIT.
 Jeżeli u klienta obowiązuje standard 100Mb/s to należy w miarę możliwości
zadbać przynajmniej o to, aby serwery bazy danych i komponentów mogły
komunikować się między sobą w standardzie 1Gb/s.

5. Instalacja systemu GRANIT
System GRANIT można zainstalować na dwa sposoby:
 Korzystając z instalatora systemu, za pomocą kreatora instalacji
 Instalując „ręcznie” system GRANIT na podstawie zarchiwizowanej
kopii systemu
5.1 Instalacja na serwerze (serwerach)

5.1.1 Instalacja za pomocą kreatora instalacji
Instalacja składa się z dwóch odrębnych lecz ściśle powiązanych ze sobą

instalatorów:
 GRANIT install DB – instalacja baz danych

 GRANIT install AS – instalacja aplikacji
5.1.1.1 Serwer bazy danych
Gdy już mamy spełnione wszystkie warunki dla instalacji możemy zainstalować bazy
danych dla systemu GRANIT.
Instalację rozpoczynamy NA SERWERZE BAZY DANYCH z katalogu

instalacyjnego:
 GRANIT_Install_11_02_03_DB_OK
W katalogu DB znajdują się puste backupy bazy danych dla instalacji systemu
GRANIT.
 GRANIT.bak
 GRANIT_LOGON.bak
By rozpocząć instalację serwera bazy danych uruchamiamy Setup.exe, po czym

pojawia się nam okno do wyboru języka instalacji.

Po wybraniu języka pojawia się główne okno instalatora.
Kontynuujemy i pojawia się okno na którym określamy ścieżki do katalogu w którym

instalator umieści pliki bazy danych.
Po wybraniu odpowiednich ścieżek kontynuujemy i pojawia się okno na którym

musimy ustawić połączenie do bazy danych.

 Nazwa instancji – nazwa serwera SQL
 Baza danych: nazwa bazy danych – pole wypełnia się automatycznie
 Baza logon: nazwa bazy logon, baza konfiguracyjna – pole wypełnia się
automatycznie
 Użytkownik: dedykowany użytkownik dla SQL Server’a (patrz rozdział 3.1
Serwer bazy danych.)
 Hasło: hasło dla użytkownika SQL Serwera
Po poprawnym wypełnieniu okna kontynuujemy instalację. Pojawia się okno

rozpoczęcia samej operacji instalacji systemu GRANIT.
Poprawnie zakończona instalacji serwera bazy danych zakończy się komunikatem:

Po zakończeniu instalacji w SQL Server Management Studio powinny pojawić się
bazy danych:
 GRANIT
 GRANIT_TEST
 GRANIT_LOGON
Jeśli użytkownik nie ma uprawnień roli „sysadmin” wówczas dla takiego użytkownika
w zakładce User Mapping powinniśmy wybrać bazy :
o GRANIT,
o GRANIT_TEST,
o GRANIT_LOGON
oraz dla każdej bazy wybrać role:

o „public”,
o „db_owner”
o „db_backupoperator”
5.1.1.2 Serwer aplikacji
Instalację aplikacji GRANIT możemy rozpocząć gdyż już mamy zainstalowany

serwer bazy danych. Instalację rozpoczynamy NA SERWERZE APLIKACJI
z katalogu instalacyjnego:
 GRANIT_Install_11_02_03_AS_OK
By rozpocząć instalację serwera aplikacji uruchamiamy Setup.exe, po czym pojawia

się nam okno do wyboru języka instalacji.

Po wybraniu języka pojawia się główne okno instalatora.
Wybieramy przycisk „Dalej”. Pojawia się okno z możliwością wyboru Instalacji

aplikacji GRANIT lub usunięcia wcześniej zainstalowanego systemu GRANIT.
Wybieramy „Instalacja” i kontynuujemy instalowanie systemu GRANIT.
Pojawia się okno na którym wybieramy miejsce instalacji systemu GRANIT.

Instalację serwera aplikacji systemu GRANIT zalecamy przeprowadzać najlepiej na
innej partycji logicznej dysku niż system WINDOWS. Dobrą praktyką jest instalacja
na oddzielnych dyskach (macierzach dyskowych – patrz rozdział 8.1.3
(Rozmieszczenie plików baz danych i systemowego pliku wymiany)
W następnym oknie instalator pyta nas czy jest to instalacja lokalna czy sieciowa. Dla
instalacji lokalnej z Systemu GRANIT będzie można korzystać tylko z komputera na
którym został zainstalowana aplikacja. Gdy nie wybierzemy instalacji lokalnej,
zostaną utworzone udziały sieciowe i z Systemu GRANIT będzie można korzystać
również z innych komputerów podłączonych do sieci.

Następnym krokiem jest wprowadzenie użytkownika Windows na którym będą
uruchamiane komponenty COM+. Przed kontynuowaniem należy założyć w systemie
Windows dedykowanego użytkownika z uprawnieniami lokalnego administratora.
(patrz rozdział 8.2.2 Tożsamość aplikacji COM+. Użytkownik interakcyjny lub
dedykowany oraz rozdział 4.1.2.2.3 Użytkownik na komponentach)
Gdy już utworzyliśmy użytkownika i uzupełniliśmy w oknie jego nazwę i hasło

możemy przejść do następnego kroku.
Tak samo jak przy instalacji serwera bazy danych SQL również i tutaj musimy podać
parametry wskazujące na połączenie do serwera SQL na którym zainstalowane
zostały wcześniej bazy GRANIT
.
 Nazwa instancji – nazwa serwera SQL

 Baza danych: nazwa bazy danych – pole wypełnia się automatycznie
 Baza logon: nazwa bazy logon, baza konfiguracyjna – pole wypełnia się
automatycznie
 Użytkownik: dedykowany użytkownik dla SQL Server’a (patrz rozdział 3.1
Serwer bazy danych.)
 Hasło: hasło dla użytkownika SQL Serwera
Kontynuujemy instalację i pojawia się okno do utworzenia użytkownika systemu

GRANIT.
Musimy wprowadzić hasło dla użytkownika „Administrator” systemu GRANIT i

przechodzimy do następnego kroku.
Po naciśnięciu przycisku „Start” rozpoczniemy instalację serwera aplikacji systemu

GRANIT.

Po zakończeniu pracy przez instalator pojawia się poniższy komunikat.
Po instalacji system GRANIT można uruchomić z serwera aplikacji spod lokalizacji:
\\nazwaSerweraAplikacji\ServerApplications\GRANIT.lnk
gdzie
NazwaSerwera – nazwa serwera aplikcaji na której instalowaliśmy system GRANIT
5.1.2 Instalacja „ręczna”
5.1.2.1 Serwer bazy danych
Do poprawnego działania systemu wymagana jest prawidłowo działająca

instalacja Microsoft SQL Server oraz odpowiednia konfiguracja baz danych –
patrz - 3. Minimalne wymagania systemu.
W celu łatwego zarządzania bazami danych zalecana jest także instalacja
aplikacji Microsoft SQL Server Management Studio (ilustracje w tej części
dokumentacji bazują właśnie na tej aplikacji).
5.1.2.1.1 Bazy danych
Do prawidłowego funkcjonowania systemu GRANIT niezbędne są dwie bazy:

 GRANIT
 GRANIT_LOGON.

Jeśli chodzi o parametry samej bazy produkcyjnej GRANIT, to należy zwrócić
uwagę na następujące elementy:
 kodowanie języka bazy danych („collation”) powinno być ustawione na
„Polish_CI_AS” i zgodne z kodowaniem języka serwera
 zgodnie z wymogami ustalonymi w danej firmie parametr bazy danych

„Recovery model” może przyjąć wartość:
o „simple”,
o „full”.
o „bulk-logged”
Jeśli wybrana została wartość „full” lub „bulk-logged”
wówczas należy położyć szczególny nacisk na regularne wykonywanie kopii
bazy danych (pełnych, różnicowych, logu transakcjyjnego) oraz zwrócić
uwagę na zarezerwowanie odpowiedniej przestrzeni dyskowej dla pliku
dziennika transakcyjnego bazy danych, który może przyjmować z czasem
duże rozmiary.
UWAGA:
Domyślną opcją dla baz danych systemu GRANIT jest tryb SIMPLE – może
to zostać zmienione w zależności od polityki bezpieczeństwa firmy
 parametr „Compatibility level” powinien przyjąć wartość „SQL Server
2000 (80)”

 do prawidłowego działania systemu należy także zapewnić bazie danych
możliwość swobodnego rozrastania się poprzez odpowiednie ustawienie
parametru „autogrowth” (np. „by 10 percent, unrestricted growth” lub
ustawić górny limit rozmiaru pliku bazy danych i dziennika transakcyjnego
i na bieżąco kontrolować ich rozmiary)
 dla zwiększenia wydajności systemu warto także plik dziennika

transakcyjnego bazy danych (GRANIT_log.ldf) umieścić na innym dysku
(macierzy dyskowej), niż sam plik bazy danych (GRANIT.mdf) – patrz
(6.1.3 Rozmieszczenie plików baz danych i systemowego pliku wymiany)
Z punktu widzenia administratora systemu, warto zwrócić szczególną uwagę na

zawartość czterech tabel w wymienionych bazach danych, które zawierają
krytyczne dla aplikacji parametry, od których zależy poprawna konfiguracja
sytemu GRANIT:

GRANIT_LOGON:
 BazadanychRzeczywista
 SysParams
GRANIT:
 FmFormatkaTyp
 ExportDefinitionML
5.1.2.1.2 Konfiguracja bazy GRANIT_LOGON
Baza danych GRANIT_LOGON odpowiada za połączenie aplikacji z bazami

z danymi użytkownika. Miejsca, na które należy zwrócić uwagę to:
 Tabela BazaDanychRzeczywista – zawiera informacje potrzebne do

połączenia aplikacji GRANIT do baz produkcyjnych. Należy zwrócić
szczególną uwagę na poprawność pola ConnectString tj.:
o nazwę instancji serwera bazy danych,
o użytkownika i hasło do połączenia z MS SQL Serwerem
UWAGA:
(ConnectString jest taki sam jak w pliku SysReg patrz rozdział 4.1.2.2.
Konfiguracja pliku SysReg).
 Tabela SysParams – zawiera ścieżki sieciowe do katalogów sieciowych

zawierających formatki, pliki uruchomieniowe i lokalizację do eksportu plików.
Należy sprawdzić czy podane ścieżki są poprawne.

5.1.2.1.3 Konfiguracja bazy GRANIT
Po poprawnym ustawieniu parametrów i ścieżek w bazie logon, należy uruchomić

procedurę składowaną Sp_afterimport (np. poprzez SQL server Management
Studio -> New Query na konkretnej bazie danych – GRANIT lub GRANIT_TEST).
Powinna ona ustawić poprawne ścieżki w danej bazie. Jeśli z jakiegoś powodu
ścieżki w bazie GRANIT lub GRANIT_TEST nie zaktualizują się na poprawne, należy
zmienić je ręcznie w tabelach:
 FmFormatkaTyp
 ExportDefinitionML
5.1.2.2 Serwer aplikacji
Serwer aplikacji jest odpowiedzialny za funkcjonowanie systemu GRANIT i

połączenie z bazą danych SQL. Na serwerze aplikacji zainstalowane są
komponenty, które są sercem aplikacji GRANIT, biblioteki i pliki uruchomieniowe.
5.1.2.2.1 Zdalny dostęp do komponentów COM+
Jeśli chcemy by GRANIT pracował jako system sieciowy, czyli praca w systemie
GRANIT była możliwa z innych stacji roboczych w sieci, należy doinstalować rolę
w systemie Windows – zdalny dostęp do obiektów COM+.
W systemie MS Windows 2008 Server włączenie zdalnego dostępu do

komponentów odbywa się następująco:
[Panel sterowania -> Narzędzia administracyjne –> Menedżer serwera ->

Role -> Dodaj Role -> Serwer aplikacji->Zaznaczyć: Dostęp sieciowy modelu
COM+]
Po przejściu kreatora możemy sprawdzić czy usługi zostały zainstalowane
[Panel sterowania -> Narzędzia administracyjne –> Menedżer serwera ->

Role -> Dodawanie ról]

5.1.2.2.2 Użytkownik na komponentach COM+
Komponenty to obiekty, które muszą być zarejestrowane na jakiegoś

użytkownika. By system GRANIT działał prawidłowo musi to być użytkownik
z prawami Administratora lokalnego. Rozróżniamy dwa rodzaje użytkowników, na
których działają komponenty systemu GRANIT:
 Użytkownik dedykowany – jest to użytkownik systemu Windows specjalnie

utworzony na potrzeby Systemu GRANIT;
 Użytkownik interakcyjny – komponenty działają na użytkowniku aktualnie

zalogowanym na serwerze, taki użytkownik musi mieć prawa Administratora
lokalnego.
Bardziej wskazanym użytkownikiem, na którym działają komponenty jest

użytkownik dedykowany. By wybrać to rozwiązanie musimy najpierw utworzyć
użytkownika w systemie Windows. Proponujemy nazwać tego użytkownika
Components i dodać go do grupy: lokalni administratorzy.
UWAGA:
Użytkownikiem dedykowanym może być zarówno użytkownik domenowy bądź
lokalny, ważne aby należał do grupy administratorów lokalnych
Podczas tworzenia użytkownika dedykowanego, sugerujemy odznaczyć:
 Użytkownik musi zmienić hasło przy następnym logowaniu;
Natomiast zaznaczyć:

 Użytkownik nie może zmienić hasła;
 Hasło nigdy nie wygasa;
5.1.2.2.3 Zmiana użytkownika na komponentach COM+
Jeśli zdecydujemy się na użytkownika interaktywnego, jako użytkownika na którym

chodzą komponenty, oraz chcemy zmienić teraz na użytkownika dedykowanego,
możemy to wykonać spod lokalizacji:
[Panel sterowania / Narzędzia administracyjne / Usługi składowe ]
Patrz rozdział - (10.2.2 Sprawdzenie poprawności autoryzacji użytkownika Windows
stacji klienckiej na serwerze aplikacji COM+.)
5.1.2.2.4 Model obiektów rozproszonych COM
Do poprawnego działania systemu GRANIT należy włączyć na serwerze

model obiektów rozproszonych COM. Jeśli opcja nie jest włączona GRANIT na
stacjach roboczych nie będzie w stanie komunikować się z serwerem.
Model Obiektów rozproszonych COM włączamy spod lokalizacji:
[Panel sterowania – Narzędzia Administracyjne – Usługi składowe – Mój

komputer –Właściwości]

Wchodzimy w zakładkę Właściwości domyślne.
5.1.2.2.5 Zabezpieczenia COM
By system GRANIT mógł na stacjach roboczych bez problemów łączyć się do

serwera, należy ustawić zabezpieczenia COM.
Uprawnienia COM ustawiamy spod lokalizacji:

komputer – Właściwości]
Wchodzimy w zakładkę Zabezpieczenia COM.

Ustawiamy pełne uprawnienia dostępu do obiektów COM (do uruchamiania i
aktywacji) dla wszystkich użytkowników (w domenie oraz na serwerze aplikacji w
przypadku grupy roboczej).
Dodatkowo sprawdzamy, czy dla wszystkich pakietów wyłączona jest opcja

„Wymuszaj testy dostępu dla tej aplikacji. Zaznaczenie tej opcji może
spowodować nieprawidłowe działanie systemu GRANIT.

5.1.2.2.6 Struktura katalogów serwera aplikacji
Na partycji dysku (przykładowo E:\ ) tworzymy strukturę katalogów na podstawie

katalogów instalatora systemu GRANIT:
GRANIT_Install_11_02_03_AS_OK
[E:\GRANIT]
[E:\GRANIT\Components\]
[E:\GRANIT\Components.NET\]
[E:\GRANIT\DesignTools\]
[E:\GRANIT\Exports\]
[E:\GRANIT\Forms\]
[E:\GRANIT\Lib\]
[E:\GRANIT\Log\]
[E:\GRANIT\Printer\]
[E:\GRANIT\ServerApplications\] – lub Programs w zależności od
wcześniejszej instalacji
[E:\GRANIT\Service\]
[E:\GRANIT\Setup\] – tworzymy pusty katalog
[E:\GRANIT\Snapshot\]
Do której kopiujemy zawartość katalogów z instalatora lub zawartość

katalogów z ostatniego backup’u katalogu GRANIT

5.1.2.2.7 Uprawnienia do katalogów w systemie GRANIT
Udostępnienie konkretnych katalogów w systemie GRANIT jest istotnym

elementem poprawnego działania aplikacji. Należy udostępnić katalogi jako
udziały:
 Exports
 Forms
 Log$
 ServerApplications
Wszystkie katalogi do udostępnienia znajdują się w katalogu GRANIT.
Uprawnienia do katalogów opisane są w rozdziale (2.3 Serwer plików systemu.)
5.1.2.2.8 Konfiguracja pliku SysReg_{63AFD5B1-49BA-11D5-9AA5-

00105A72C191}.ini
Plik SysReg_{63AFD5B1-49BA-11D5-9AA5-00105A72C191}.ini jest plikiem

odpowiedzialnym za połączenia serwera aplikacji z bazą danych.
Plik powinien znaleźć się w lokalizacji:
 %windir%\System32\SysReg_{63AFD5B1-49BA-11D5-9AA5-
00105A72C191}.ini
lub w przypadku systemu 64-bitowego
 %windir%\SysWOW64\SysReg_{63AFD5B1-49BA-11D5-9AA5-
00105A72C191}.ini
Przykładowa Zawartość pliku SysReg_{63AFD5B1-49BA-11D5-9AA5-

00105A72C191}.ini – w zależności od wersji systemu GRANIT może się
nieznacznie różnić (wpisy do konfiguracji pogrubiono):
--------------DBCom Connection----------------
LOGON=Provider=SQLOLEDB;DataSource=GRANITserw\sqlexpress;Initial Catalog=GRANIT_LOGON; User
ID=sa;Password=gra#nit0.1;
SERVICE=Provider=SQLOLEDB;DataSource=GRANITserw\sqlexpress;Initial Catalog=GRANIT_SERVICE;
User ID=sa;Password=gra#nit0.1;
---------------DBCOM Parametry----------------
Initialization=0
Log=1
SleepTime=20
PacketTime=1000
Prior=0
First=0
ConnectionTime=1
LogDirectory=\\ GRANITSERW \Log$
TryCloseTransaction=0
ListLocation=Client
RowCount=1
--------------DBCom Path Bulk-----------------
TempFilePath=\\GRANITSERW\Exports

ErrorLogFile=D:\GRANIT\log\Error.log
--Ciagla Weryfikacja AccessCode przez DBCOM---
AccessCodeVeryfication=1
-----------?????----------------
EnforceWinAuth=0
FilterEnterprise=0
MessagingType=0
SessionTime=2
DisableFormCaching=0
-----------Logowanie Instancji Com------------
LogInstancesInfo=1
-----------?????----------------
LogToolExecuting=0
LogToolError=1
LogToolReport=2
LogCheckRights=0
------Postac Generowanych Paczek XML/VAR------
GeneratorPacketType=VAR
--------------Klucz rejestracyjny-------------
Registration=HbfmjTGY
-----------MAPA----------------
MapDBUSER=QNzqgkEiMA==
MapDBPASSWORD=QNzqgkEiMA==
MapJPGPath=\\Server\Katalog\
--------Systemowy Katalog Tymczasowy----------
TempPath=D:\GRANIT\Log
-------Buforowanie definicji formularzy-------
FormDefinitionCachingAtClient=1
FormDefinitionVersion=10811000
---Truncate Table przy nakladaniu uprawnien---
RightsTruncate=0
---License---
USERLIK=
LogDirectoryForApp=\\GRANITSERW\LOG$
DBComReaderCLASS=DBCReader.DBCom
UseGlobalRights=1
ParserType=3
rlURL=
rlServerId=
rlGroupId=
rlSMTPUser=
rlSMTPPassword=
rlSMTPTo=
rlMailServer=
rlSMTPSender=
LogPingMethod=1
VerifyLicence=999
Data Source= - zawiera informacje o instancji serwera SQL na którym

zainstalowane są bazy danych
User ID= - nazwa użytkownika SQL który jest używany do logowania do baz danych
GRANIT
Password= - hasło użytkownika SQL który jest używany do logowania do baz
danych GRANIT
LogDirectory= - ścieżka sieciowa do katalogu z logami
TempFilePath= - ścieżka do katalogu w którym zapisywane są tymczasowo dane
dla poleceń SQL typy BULK - do tej lokalizacji musi mieć dostęp użytkownik na
którym działa usługa serwera SQL (patrz rozdział 2.3.3)
ErrorLogFile= - ścieżka lokalna dla plików z logiem błędów
TempPath= - ścieżka lokalna dla plików tymczasowych

FormDefinitionVersion= - unikatowy dla danej wersji systemu GRANIT nr
wykorzystywany przez formatki buforowane lokalnie na stacji roboczej (jest to
zazwyczaj nr HotFix + 000)
LogDirectoryForApp= - ścieżka sieciowa do katalogu z logami dla aplikacji
5.1.2.2.9 Dodatkowe usługi systemu GRANIT działające na

serwerze aplikacji
Na serwerze aplikacji muszą być także uruchomione dwie usługi systemu

GRANIT (logowanie w kontekście użytkownika LOCALSYSTEM), które
zawiadują działaniem zadań wsadowych systemu GRANIT:
 DDSystemService
 DDTaskService
Usługi te znajdują się odpowiednio w lokalizacji:

 [xxx:\GRANIT\Service\InfoService.exe]
 [xxx:\GRANIT\Service\DDTaskService.exe]
Instalacja tych usług odbywa się za pomocą z poziomu wiersza poleceń:

[start->uruchom->CMD]
5.1.2.2.10 Instalowanie komponentów COM+
System GRANIT oferuje narzędzie do administrowania komponentami COM+

systemu GRANIT. Narzędzie MTSUtils znajduje się w lokalizacji:
[xxx:\GRANIT\DesignTools\MTSUtils.exe]

Aby można było używać tego narzędzia do rejestracji komponentów COM+ należy
wcześniej zarejestrować bibliotekę z katalogu GRANIT\Lib:
 DDBaseTypeLibrary.tlb tregsvr.exe
Instalacja odbywa się z poziomu wiersza poleceń CMD:
Następnie uruchamiamy narzędzie MTSUtils.exe, w zakładce Import wpisujemy

ścieżkę do katalogu Components i wybieramy Import All Packeges.
Zaznaczona opcja „Set Registry” pozwoli na zarejestrowanie komponentów COM+

w systemie WINDOWS. Opcja „Incremental” spowoduje zarejestrowanie TYLKO
BRAKUJĄCYCH komponentów COM+ z podanego katalogu, które z jakiejś
przyczyny nie zostały wcześniej zarejestrowane.
5.1.2.2.11 Ustawianie użytkownika na komponentach COM+

Aby ustawić w jak sposób będą uruchamiane komponenty COM+ - patrz (6.2.2
Tożsamość aplikacji COM+. Użytkownik interakcyjny lub dedykowany.)

5.1.2.2.12 Czas życia komponentów
Do lepszego działania systemu, warto ustawić czas życia komponentów na 3 min.
Czas życia komponentów ustawiamy spod lokalizacji:

komputer – Aplikacje COM+ ]
By uzyskać wszystkie potrzebne informacji na temat komponentów włączamy

wyświetlanie ich w trybie Szczegóły.
By zmienić czas życia komponentów, zaznaczamy wszystkie komponenty (Ctrl + A).

Z listy zaznaczonych komponentów odznaczamy:
 .NET Utilities
 COM+ Explorer
 COM+ QC Dead Letter Queue Listener
 COM+ Utilities
 MS Software
 System Application
Na pozostałych komponentach klikamy prawym przyciskiem myszy i wchodzimy

we właściwości komponentów, zakładka Zaawansowane. Zaznaczamy checkbox:
Zamknij bezczynny po i wprowadzamy 3 minuty, po których bezczynny komponent
zostanie zamknięty.

5.1.2.2.13 Wgranie kodu aktywacyjnego.
Jeśli po uruchomieniu Systemu GRANIT pojawi się komunikat:
to należy skontaktować się z producentem w sprawie wygenerowania nowego klucza

aktywacyjnego. Klucz aktywacyjny jest generowny na podstawie konfiguracji sprzętu,
na którym zainstalowany jest system GRANIT.
W przypadku gdy sprzęt ten został zmieniony, może zaistnieć potrzeba
wygenerowania nowego klucza.
5.2 Instalacja na stacjach roboczych (klienckich)

Instalacja na stacji klienta polega na uruchomienia systemu z przeznaczonego do
tego celu skrótu sieciowego. Podczas pierwszego uruchomienia pojawi się
komunikat:
Zalecaną opcją jest wybranie ‘Zawsze aktualizuj’. Spowoduje to przy pierwszym

uruchomieniu systemu w nowym dniu system sprawdzi czy na serwerze istnieje
nowsza wersja aplikacji EXE warstwy prezentacyjnej (np. w wyniku aktualizacji
systemu poprzez HotFix) i jeżeli istnieje to zostanie ona automatycznie
zaktualizowana na stacji klienta.
Gdy zostanie wybrana opcja: ‘Aktualizuj’ to przy pierwszym uruchomieniu systemu

w nowym dniu w przypadku, gdy na serwerze wystąpiła aktualizacja aplikacji warstwy
prezentacyjnej, pojawi się ponownie w/w komunikat.
Na stacji klienckiej do katalogu %appdata%\DomConsult kopiowane są pliki

aplikacji warstwy prezentacyjnej, które są potrzebne do uruchomienia aplikacji
GRANIT oraz dodawane odpowiednie wpisy w rejestrze Windows (miejsce
przechowywania plików na stacji klienckiej jak i miejsce zapisywania informacji w
rejestrach może się różnić w zależności od instalacji. Konfiguracja ta znajduje się w
pliku company.ini na serwerze aplikacji w katalogu z innymi aplikacjami systemu
Granit):

- HKEY_CURRENT_USER\Software\DomConsult\
- HKEY_CURRENT_USER\Software\ -

6. Monitorowanie systemu.
Uwaga:
Poniższy opis ma zadanie jedynie pobieżnie poinformować o użytkownika o
możliwości kontroli pracy systemu.
Wszelkie modyfikacje ustawień pracy warstwy bazy danych lub komponentów
za pomocą opisanych poniżej narzędzi powinny być wykonywane przez osobę
przeszkoloną. Nieprawidłowa konfiguracja któregoś z elementów systemu za
pomocą poniżej opisanych narzędzi może spowodować spadek wydajności
systemu, nieprawidłowe działanie lub nawet awarię systemu GRANIT!
6.1 System od strony bazy danych.

Monitorowanie warstwy bazy danych jest równoznaczne monitorowaniem pracy
usługi serwera bazy danych. Proces serwera jest usługą systemową, która jako
proces na liście procesów serwera widoczna jest pod pozycją „sqlservr.exe”.
W niektórych przypadkach możliwe jest uruchomienie kilku instancji serwera bazy
danych (kilka procesów sqlservr.exe), ale z reguły tylko jeden z nich związany jest
z systemem GRANIT.
Rys. 6-1. Proces serwera bazy danych MS SQL Server.

6.2 System od strony serwera aplikacji COM+.
System od strony serwera aplikacji to:
 Usługi systemu operacyjnego. Czyli: Distributed Transaction Coordinator
(proces: msdtc.exe), Menedżer kont zabezpieczeń (lsass.exe), Zdalne
wywoływanie procedur (RPC) (svchost.exe -k rpcss)
 Usługi systemu GRANIT. Główna usługa systemowa GRANIT
DDSystemService (InfoService.exe), Usługa wykonywania zadań
okresowych DDTaskService (DDTaskService.exe). W niektórych
wdrożeniach używane są również inne specjalistyczne usługi.
 Procesy odpowiadające poszczególnym zarejestrowanym aplikacjom COM+.
Procesy te widoczne są w systemie jako procesy dllhost.exe
Rys. 6-2. Menedżer zadań z widocznymi procesami odpowiadającymi

aplikacjom COM+ (dllhost.exe) i usługą systemową DDTaskService.exe.
Do monitorowania usług używana jest konsola Usługi dostępna w Panelu sterowania

w grupie Narzędzia administracyjne.

Do monitorowania procesów COM+ używana jest konsola Usług składowych również
umieszczona w Panelu sterowania w grupie Narzędzia administracyjne.
Za pomocą powyższych konsoli można oglądać pracę poszczególnych usług i

komponentów.
Rys. 6-3. Panel sterowania z konsolą "Usługi" i "Usługi składowe".
Rys. 5-6. Aplikacje COM+. Podgląd działających aplikacji COM+

7. Optymalizacja wydajności systemu.
Kwestia wydajności serwera bazy danych jest bardzo szerokim tematem. Składają
się na niego kwestie sprzętowe (pamięć, procesor, dyski, sieć), parametry pracy
systemu operacyjnego i serwera bazy danych, oraz kwestie strojenia baz danych.
W poniższym opisie skoncentrowano się na pierwszych dwóch elementach.
7.1.1 Wersja serwera

Główną rzeczą z punktu widzenia warstwy bazy danych jest wersja serwera bazy
danych. W momencie pisania tego dokumentu sugerowana wersją dla
Microsoft S SQL Server jest wersja 10.50.4000 – czyli Microsoft SQL 2008 R2
Rys. 7-1. Uruchomienie okna z właściwościami serwera bazy danych.

Rys. 7-2, Okno właściwości serwera bazy danych.
7.1.2 Dedykowanie serwera na potrzeby bazy danych.

Serwer bazy danych jest najważniejszym składnikiem systemu i powinien być
wydajnym komputerem o dużej ilości pamięci operacyjnej, mocnych procesorach i
odpowiedniej konfiguracji dyskowej (macierz RAID). W przypadku mniejszych
wdrożeń komputer, na którym działa serwer bazy danych wykorzystywany jest
również do innych celów (najczęściej jako serwer aplikacji COM+). Dedykowanie
całego komputera na potrzeby serwera bazy danych jest dobrym pomysłem i może
być rozwiązaniem wielu problemów wydajnościowych.
7.1.3 Rozmieszczenie plików baz danych i systemowego pliku

wymiany.
Baza danych jest z punktu widzenia systemu operacyjnego dwoma plikami. Pierwszy
z nich to plik przechowujący faktyczne dane bazy (*.mdf), drugi z nich jest plikiem
pomocniczym wykorzystywanym podczas pracy danej bazy (*.ldf). Dodatkowo
system operacyjny wykorzystuje tzw. plik wymiany (ang. swapfile).
Ponieważ podczas pracy serwera bazy danych intensywnie wykorzystywane są
wszystkie te trzy pliki i z punktu widzenia zwiększenia wydajności optymalnym
rozwiązaniem jest jak największe ich rozdzielenie na niezależne od siebie urządzenia
dyskowe (osobne dyski, kanały, kontrolery RAID).
Zalecaną konfiguracją jest taka konfiguracja gdzie każdy z typów plików (.mdf,
.ldf, swap) będzie umieszony na oddzielny dysku fizycznym a najlepiej na

oddzielnej macierzy dyskowej RAID – z doświadczeń wynika że na pliki .mdf
najlepiej nadaje się RAID 10 , na pliki .ldf Raid 1
Rys. 7-3. Uruchomienie okna właściwości bazy danych.
Rys. 7-4. Lokalizacja plików bazy danych.
7.1.4 Defragmentacja dysków.

Podczas pracy z bazą danych pliki baz danych podlegają zmianom rozmiarów. W
niektórych sytuacjach (np. mała ilość wolnego miejsca) proces fragmentacji tych
plików może znacząco wpłynąć na wydajność serwera bazy danych. To samo
dotyczy dynamicznego pliku wymiany. Stopień defragmentacji plików komputera

bazy danych należy kontrolować i w przypadku znacznej defragmentacji należy
wykonać odpowiednie kroki.
Uwaga
Przed rozpoczęciem defragmentowania należy zatrzymać serwer bazy danych.
W przeciwnym wypadku pliki bazy danych nie zostaną uporządkowane.
Rys. 7-5. Systemowy defragmentator dysków,.
7.1.5 Aktualizacja statystyk indeksów baz danych
Utrzymywanie aktualnych statystyk oraz defragmentacja indeksów na bazach

produkcyjnych GRANIT ma DUŻY WPŁYW na wydajność przeprowadzanych
operacji na danych w bazie. Zalecane jest wykonywanie powyższych operacji
chociażyby raz w tygodniu (najlepiej w weekend w nocy) np. poprzez zdefiniowanie
JOB’a w SQL Agent’cie. Poniższe polecenia uruchomione ręcznie w SQL Server
Management Studio wykonają aktualizację statystyk oraz reindeksację na bazie
danych GRANIT:
USE GRANIT
go
EXEC sp_MSforeachtable " PRINT '?' DBCC DBREINDEX('?','',90)"

go
EXEC sp_MSforeachtable " UPDATE STATISTICS ? WITH FULLSCAN "

Go

7.1.6 Parametry serwera bazy danych.
Aplikacja SQL Server daje możliwość zmiany wielu parametrów, które mogą
zwiększyć wydajność, lecz należy je stosować z wielką rozwagą i rozumieć ich wpływ
na pracę serwera.
Domyślne ustawienia instalacji serwera bazy danych są z reguły wystarczające dla
większości wdrożeń.
UWAGA
Wszelkie modyfikacje muszą być wykonywane przez osoby przeszkolone i w
konsultacji z Działem Technicznym systemu GRANIT. Niewłaściwa konfiguracja
któregoś z parametrów serwera bazy danych może spowodować drastyczny
spadek wydajności systemu w niektórych sytuacjach, nieprawidłowe działanie
lub nawet awarię systemu GRANIT.
Rys. 7-6. Okno parametrów serwera bazy danych.
7.1.7 Dedykowanie serwera na potrzeby systemu GRANIT.

Często się zdarza, że serwery systemu GRANIT są wykorzystywane również do
innych celów. System GRANIT poprawnie współpracuje praktycznie z każdym innych
oprogramowaniem, ale niestety często spotykane są sytuacje, w których serwery
systemu GRANIT wykazują obniżoną wydajność na skutek nadmiernego obłożenia
dodatkowymi zadaniami. W przypadku takich rozwiązań należy kierować się
zdrowym rozsądkiem i sprawować kontrolę nad wydajnością serwera.
7.1.8 Priorytet usług

Ponieważ warstwa bazy danych działa jako usługa, dlatego podstawową rzeczą w
przypadku serwera bazy danych jest ustawienie w „Opcjach wydajności tego

komputera” (Panel Sterowania, System) optymalizacji działania dla usług, a nie dla
aplikacji. Ustawienie tej opcji jest szczególnie ważne dla systemów w których rolę
serwera bazy danych pełni komputer z nie serwerowym systemem operacyjnym (np.
Microsoft Windows XP lub Microsoft Windows 2000 Professional).
Rys. 7-7. Opcje systemu operacyjnego.
Rys. 7-8. Opcje wydajności systemu.

7.1.9 Systemy antywirusowe i zapór
Systemy antywirusowe i zapór ogniowych (ang. firewall) mogą w znacznym stopniu
spowolnić pracę serwera. W przypadku ich instalacji należy poświęcić nieco czasu na
takie ich skonfigurowanie by narzut związany z bezpieczeństwem był akceptowalny.
W przypadku systemów antywirusowych sugerowanym wyjściem jest wyłączenie
katalogu z plikami baz danych ze skanowania monitora antywirusowego (upewnienie
się że pliki baz danych nie będą ciągle monitorowane).
7.2 Serwer aplikacji COM+

Optymalizacja serwera aplikacji jest prostsza i mniej tajemnicza w porównaniu do
serwera bazy danych, ale równie ważna.
Poniżej omówiono aspekty przyśpieszania pracy serwera aplikacji COM+
specyficzne dla jego pracy oraz te które mają kluczową rolę (są częstą przyczyną
problemów wydajnościowych).
7.2.1 Tożsamość aplikacji COM+. Użytkownik interakcyjny lub

dedykowany.
Aplikacje COM+ działające na serwerze mogą działać jako dedykowany użytkownik
albo jako użytkownik właśnie zalogowany na serwerze (tzw. logowanie interakcyjne).
Dedykowany użytkownik POWINIEN mieć uprawnienia administratora lokalnego
serwera.
Oba rozwiązania mają swoje wady i zalety.
W przypadku użytkownika dedykowanego serwer aplikacji działa również, gdy nikt
nie jest zalogowany, ale może przestać działać, gdy np. administrator zmieni hasło
tego użytkownika i zapomni uaktualnić właściwości aplikacji COM+.
W tym drugim przypadku serwer działa jako użytkownik zalogowany, co jest
łatwiejsze do konfiguracji ale uniemożliwia działanie aplikacji COM+ gdy nikt nie jest
na nim zalogowany (na głównym pulpicie, tzw. konsoli). Jest to szczególnie przykre w
sytuacjach w rodzaju przerwy w dostawie prądu, podczas której serwer jest
automatycznie wyłączany, a po włączeniu nikt nie zna hasła administratora.
Poniżej opis jak można ręcznie konfigurować tożsamość aplikacji COM+.
Rys. 7-9. Pierwszym krokiem jest zaznaczenie wszystkich zarejestrowane

aplikacji COM+. (klawisze Ctrl+A w widoku szczegółów).

Rys. 7-10. W kolejnym kroku należy ręcznie usunąć zaznaczenie aplikacji nie
należących do platformy GRANIT. Są to:
- wszystkie zaczynające się od „.NET”,
- wszystkie zaczynające się od „COM+”,
- wszystkie zaczynające się od „IIS ”,
- „System application”,
- inne
Rys. 7-11. Wybrać opcję właściwości.

Rys. 7-12. Na zakładce "Tożsamość" wybrać opcję dedykowanego
użytkownika. Wybrać odpowiedniego użytkownika, wprowadzić jego hasło i
kliknąć OK.
Rys. 7-13. System COM+ po pewnym czasie wprowadzi zmianę do wszystkich

komponentów. Efekt zmiany można zaobserwować w kolumnie „Konto”.

7.2.2 Systemy antywirusowe i zapór
Systemy antywirusowe i zapór ogniowych (ang. firewall) mogą w znacznym stopniu
spowolnić pracę serwera. W przypadku ich instalacji należy poświęcić nieco czasu na
takie ich skonfigurowanie by narzut związany z bezpieczeństwem był akceptowalny.
W przypadku systemów antywirusowych sugerowanym wyjściem jest wyłączenie
katalogu GRANIT\Components ze skanowania monitora antywirusowego
(wyłączenie ciągłego sprawdzania często otwieranych plików wykonywalnych DLL
systemu GRANIT).
7.2.3 Dedykowanie serwera aplikacji COM+ na potrzeby systemu

GRANIT.
Często się zdarza, że serwery systemu GRANIT są wykorzystywane również do
innych celów. System GRANIT poprawnie współpracuje praktycznie z każdym innych
oprogramowaniem, ale niestety często spotykane są sytuacje, w których serwery
systemu GRANIT wykazują obniżoną wydajność na skutek nadmiernego obłożenia
dodatkowymi zadaniami. W przypadku takich rozwiązań należy kierować się
zdrowym rozsądkiem i sprawować kontrolę nad wydajnością serwera.
7.2.4 Połączenie sieciowe z serwerem bazy danych.

Istotna rzeczą z punktu widzenia wydajności systemu GRANIT jest szybkość
połączenia sieciowego pomiędzy serwerem bazy danych i serwerem aplikacji COM+.
Oczywiście dotyczy to instalacji z wydzielonym, dedykowanym serwerem bazy
danych. Sugerowane jest łącze o szybkości 1 Gb/s.

Optymalizacja działania systemu GRANIT na stacji roboczej jest bardzo istotna i ma
zasadniczy subiektywny wpływ na odbiór pracy z systemem GRANIT.
7.3.1 Inne oprogramowanie. Systemy antywirusowe i zapór.

Często spotykane są sytuacje, w których następuje znaczne spowolnienie pracy
systemem na stacji roboczej spowodowane przez oprogramowanie antywirusowe i
zapór internetowych. Główną przyczyną są zbyt restrykcyjne domyślne ustawienia
tego typu oprogramowania. Rozwiązaniem jest najczęściej bardziej precyzyjne jego
skonfigurowanie, np. wyłączenie monitorowania połączenia sieciowego z serwerem
aplikacji COM+.
7.3.2 Kompresowanie danych wymienianych z serwerem

Podczas pracy z systemem GRANIT stacja robocza cały czas wymienia dane z
serwerem. Wymieniane dane wędrują pomiędzy komputerami poprzez sieć
komputerową. Czasami, gdy szybkość sieci jest dość mała (zwłaszcza podczas
łaczenia się zdalnego do sieci poprzez VPN) znaczne przyśpieszenie można uzyskać
poprzez włączenie dla danego użytkownika systemu GRANIT opcji kompresowania
danych wymienianych z serwerem aplikacji COM+.
Należy jednak pamiętać, że włączenie tej opcji powoduje wzrost obciążenia serwera
aplikacji i stacji klienckiek (operacje kompresowania i dekompresowania danych). Dla
stacji roboczej może nie jest to problemem (gdyz pracuje na niej tylko jeden

użytkownik), ale dla maszyny serwera może być już większym, zwłaszcza, gdy
włączy się tą opcję dla wielu użytkowników.
Rys. 7-14. Uruchomienia okna ustawień aplikacji użytkownika.
Rys. 7-15. Włączenie opcji „Kompresowanie danych wymienianych z

serwerem”. Potem należy wybrać „Zapisz” i „OK.”
7.3.3 Rozmiar paczki zwracanych w zestawieniu.

Pewne przyśpieszenie można również uzyskać dzięki zmniejszeniu zwracanej liczby
rekordów w paczkach zestawienia do minimalnej wartości 50. W instalacjach, w

których jednak wystepuje wydajna infrastruktura sieciowa zaleca się ustawianie
wyższych wartości tego parametru.
Poniżej rysunek pokazujący tą opcję.
Rys. 7-16. Opcja "Liczba rekordów w paczce".
7.3.4 Buforowanie definicji formularzy na stacji lokalnej

Za każdym razem gdy użytkownik systemu GRANIT uruchomi formularz to jego
definicja przesyłana jest z serwera do stacji roboczej. W sytuacji gdy użytkownik
często korzysta z ograniczonej ilości tych samych formularzy zauważalne
przyśpieszenie można uzyskać dzięki buforowaniu definicji formularzy na stacji
roboczej.
Buforowanie formularzy w nowszych wersjach jądra systemu GRANIT jest włączone
automatycznie.
7.3.5 Rozpoznawanie nazwy serwera aplikacji

Kluczowe dla szybkości działania stacji roboczej jest szybkość rozwiązywania nazwy
serwera aplikacji (DNS). Stacja kliencka systemu GRANIT podczas pracy zdalnej z
komponentami COM+ zarejestrowanymi na serwerze aplikacji szuka w sieci
komputerowej tego serwera po nazwie. W sytuacji gdy podejrzewamy system DNS o
powodowanie zwolnienia pracy systemu GRANIT należy wypróbować opcję
ominięcia DNS poprzez wprowadzenie wpisu do pliku HOSTS.

Rys. 7-17. Plik tekstowy HOSTS umieszczony jest, w zależności od systemu
operacyjnego stacji klienckiej, w katalogu
C:\WINDOWS\SYSTEM32\DRIVERS\ETC lub
C:\WINNT\SYSTEM32\DRIVERS\ETC. Należy go otworzyć do edycji np. w
notatniku systemowym.
Rys. 7-18. Ominiecie DNS polega na wprowadzeniu pary ADRESU IP

SERWERA oraz NAZWY SERWERA oddzielonej spacjami lub znakiem tabulacji
(tu: przykładowy wpis: 192.168.0.1 serverapp) .
7.3.6 Dystrybucja uaktualnienia aplikacji na stacjach roboczych

System GRANIT jest systemem samo aktualizującym pliki na wszystkich stacjach
roboczych. W sytuacji bardzo wolnego łącza pomiędzy stacją roboczą, a serwerem
plików proces aktualizacji może być dość długi. Rozwiązaniem jest ręczne
nadpisanie plików lokalnych na stacji klienckiej lub przeniesienie serwera aplikacji na
komputer „lepszy” pod względem sieciowym dla danych stacji klienckich.

7.3.7 Ogólne uwagi
Duże znaczenie mają dla wydajności systemu na stacji klienckiej podstawowe
aspekty działania każdego komputera czyli np. wolne miejsce na dyskach, brak
defragmentacji czy ilość wolnych zasobów pamięci i procesora. Generalną zasadą
dla wydajności systemu GRANIT jest utrzymywanie stacji roboczej w dobrej kondycji.

8. Bezpieczeństwo danych i systemu
W poniższym rozdziale pokrótce omówiono podstawowe aspekty zabezpieczenia
działającego systemu GRANIT.
8.1 Dostęp do danych

System GRANIT jest systemem sieciowym i jako taki musi umożliwiać zdalny dostęp.
Rolą administratora jest określenie, monitorowanie i zarządzanie tym dostępem.
8.1.1 Baza danych

Baza danych jest najcenniejszą częścią systemu i jako taka powinna być szczególnie
dobrze chroniona. Przy działającym systemie GRANIT tylko jeden komponent łączy
się z bazami danych i wykonuje wszystkie operacje odczytów i zapisów danych.
Dostęp tego komponentu konfigurowany jest podczas instalacji systemu i
zdefiniowany jest w bazie logującej i na serwerze aplikacji. Przy standardowej
instalacji żaden użytkownik ze stacji klienckiej NIE MA dostępu do serwera bazy
danych.
Kluczową kwestią dla zabezpieczenia danych przed kradzieżą i uszkodzeniem jest

zrozumienie mechanizmu użytkowników i uprawnień aplikacji MS SQL Server.
Sugerujemy przestudiowanie dokumentacji dot. SQL Serwera lub jednej z wielu
publikacji na ten temat.
8.1.2 Serwer plików i aplikacji COM+

Serwer plików i aplikacji COM+ to praktycznie zawsze ten sam komputer. Jako
serwer plików musi udostępniać pliki użytkownikom systemu. Domyślna instalacja
systemu tworzy udziały na głównym katalogu instalacyjnym dla wszystkich
użytkowników. Sugerowane jest, aby administrator systemu po stronie klienta
utworzył jasno zdefiniowaną grupę (lub wiele grup) użytkowników systemu i tylko jej
przydzielił uprawnienia do udziałów sieciowych na serwerze według schematu
pokazanego poniżej.
UWAGA.
Każdą zmianę udziałów sieciowych serwera aplikacji COM+ należy wcześniej
zgłosić i wykonać pod nadzorem producenta systemu GRANIT (dostawcy). Po
zmianie udziałów należy bowiem ponownie skonfigurować system GRANIT.
8.2 Oprogramowanie antywirusowe i zapór

Sugerowane jest aby zarówno serwer(y) jak i stacje klienckie były chronione przez
firmowe systemy antywirusowe i zapór internetowych. Zalecane jest aby ochrona
przed włamaniami (zapora internetowa – firewall) była WYŁĄCZONA na
serwerze i stacjach klienckich a WŁĄCZONA na bramce dostępowej do
Internetu
Pozostawienie systemu otwartego na świat zewnętrzny wcześniej czy później
spowoduje jego zawirusowanie i może prowadzić do kradzieży lub uszkodzenia

danych. Głównie zagrożony jest tutaj serwer aplikacji jako serwer mechanizmów
COM+ oraz serwer aplikacji z jego plikami wykonywalnymi.
Należy pamiętać również o tym, że zainfekowany serwer aplikacji bardzo szybko
może przenieść infekcję na stacje klienckie poprzez pliki EXE.
Ważne jest również to aby pamiętać o wpływie takiego oprogramowania na
wydajność systemu GRANIT (patrz rozdział dot. optymalizacji wydajności systemu).
8.3 Polityka kopii zapasowych.

Tworzenie kopii bezpieczeństwa dla systemu GRANIT można podzielić na dwa
elementy. Kopia katalogu aplikacji GRANIT oraz kopia baz danych.
Najważniejszą rzeczą z punktu widzenia zabezpieczania rozbudowanego sieciowego

systemu trójwarstwowego jakim jest system GRANIT jest zabezpieczenie archiwalnej
kopii bazy danych.
UWAGA:
Utracona baza danych systemu GRANIT jest elementem, który
NIE MOŻE BYĆ JUŻ ODTWORZONY!
Zabezpieczenie bazy danych jest PODSTAWOWYM zadaniem administratora

systemu GRANIT od strony klienta.
Użytkownik oprogramowania (administrator systemu), a nie twórca czy

dostawca, jest odpowiedzialny za zorganizowanie systemu tworzenia kopii
bezpieczeństwa.
Rolą dostawcy jest jedynie sugerowanie określonych rozwiązań i ewentualne
wsparcie.
8.3.1 Kopia systemu i bazy danych – narzędzie systemu GRANIT

UWAGA
Instalator nie tworzy kopii całego katalogu GRANIT lecz jedynie KLUCZOWE
katalogi potrzebne do odworzenia możliwości pracy w systemie - patrz 8.3.3
Kopia systemu GRANIT – narzędzia Windows)
Instalator systemu GRANIT dodaje domyślnie możliwość m.in. ręcznego tworzenia

kopii bezpieczeństawa systemu GRANIT poprzez uruchomienie narzędzia z menu
start systemu WINDOWS na serwerze aplikacji GRANIT:

Zostanie wyświetlony kreator kopii zapasowej:
Rys. 8-1. Wybieramy kopię jakiej bazy chcemy wykonać oraz podajemy nazwę
użytkownika (oraz hasło) z prawami administratora w systemie GRANIT

Rys. 8-2. Wybieramy lokalizację gdzie jest zainstalowany system GRANIT –
ścieżki do katalogów które zostaną backup’owane
Rys. 8-3. Podajemy lokalizację miejsca do którego zostanie wykonana kopia

systemu GRANIT

Rys. 8-4. Podajemy nazwę użytkownika na którym zainstalowane zostały
komponenty COM+ systemu GRANIT
Rys. 8-5. Po kliknięciu przycisku Start zostanie rozpoczęty proces tworzenia

kopii zapasowej systemu GRANIT
Za pomocą powyzszego narzędzie do tworzenia kopii bezpieczeństwa systemu,

w katalogu wskazanym przez nas w kreatorze, zostaną utworzone kluczowe katalogi
potrzebne do odtworzenia systemu:
 Forms,
 Programs (ServerApplications),
 Components
oraz pliki kopii baz danych (BAK):

 GRANIT – jeżeli w kreatorze wybraliśmy kopię bazy GRANIT
 GRANIT_LOGON – plik kopii bazy logującej
UWAGA:
Dodatkowo należy RĘCZNIE z katalogu %windir%\System32 lub w przypadku
systemu 64-bitowego %windir%\SysWOW64 skopiować plik:
 SysReg_{63AFD5B1-49BA-11D5-9AA5-00105A72C191}.ini
zawierający pomocne informacje do odtworzenia systemu GRANIT
8.3.2 Kopia bazy danych – narzędzie Microsoft.

Przy planowaniu systemu tworzenia kopii bezpieczeństwa należy rozważyć
następujące kwestie:
 Jak często tworzyć kopię bazy?
 Gdzie ją przechowywać?
 Na jakim nośniku i jak długo przechowywać archiwalne kopie.
Kopia bazy danych jest fizycznie plikiem zazwyczaj o rozszerzeniu *.BAK, który
generowany jest przez proces SQL Serwera na żądania. Nie należy mylić plików baz
danych z plikiem archiwalnej kopii bazy danych.
Do automatycznego tworzenia kopii bazy danych najlepiej wykorzystać prosty

mechanizm SQL Serwera tzw. planów obsługi (Maintenance Plans).
Poniżej przykład rozwiązania archiwizacji baz danych systemu GRANIT bazującego
na tym mechanizmie do tworzenia PEŁNYCH kopii baz danych.
Rys. 8-6. Tworzenie nowego planu obsługi.

Rys. 8-7. Zmieniamy harmonogram (change)
Rys. 8-8. Tworzymy harmonogram: codziennie o godzinie 02:00 począwszy od

2011-02-04, bez końca.

Rys. 8-9. Wybieramy jakie zadanie chcemy aby zostało wykonane – pełna
kopia baz
Rys. 8-5. Wybór baz danych których ma dotyczyć ten plan. Zaznaczono tylko
bazę logującą (tu: GRANIT_LOGON) oraz bazę produkcyjna (GRANIT). Baza

testowa GRANIT_TEST nie powinna być archiwizowana ponieważ nie jest
używana produkcyjnie, a jedynie do testów i szkolenia.
Rys. 8-6. Wybieramy m.in. gdzie będzie robiona kopia, po ilu dniach pliki mają
zostać nadpisane nowymi
Po przejściu kolejnych okien mamy wygenerowany podstawowy plan obsługi

codziennego tworzenia kopii bazy danych.
Samym wykonywaniem kopii bezpieczeństwa zajmie się specjalizowana usługa SQL

Server Agent będącą częścią pakietu narzędzi MS SQL Server. Kluczową sprawą
jest to, aby ta usługa była cały czas uruchomiona (m.in. startowała
automatycznie podczas startu komputera).

Rys. 8-10. Usługa SQL Server Agent w menedżerze usług systemu.
Po wykonaniu wszystkich powyższych procedur mamy zdefiniowany i uruchomiony
automatyczny proces tworzenia kopii bezpieczeństwa głównych baz danych. Nie jest
to jednak koniec. Proszę zauważyć, że w tym momencie zarówno pliki bazy danych
jak i ich kopie znajdują się na tym samym komputerze, a w tym przykładzie nawet na
jednym fizycznym dysku (D:\GRANIT\BACKUP i D:\GRANIT\DBFiles). W sytuacji
awarii dysku tracimy zarówno bazy jak i ich kopię. Następny krokiem musi być
wymyślenie i zdefiniowanie przez administratora dodatkowego schematu kopiowania
plików kopii na inny, zaufany nośnik. Można wykorzystać mechanizmu systemowe
Windows (np. narzędzie Kopia zapasowa: ntbackup.exe lub bardzo przydatne i
proste narzędzie ROBOCOPY.EXE).
8.3.3 Kopia systemu GRANIT – narzędzia Windows..

W tym przypadku sprawa jest o wiele bardziej prosta. Pliki systemu GRANIT
umieszczone na serwerze plików i aplikacji COM+ zmieniają się tylko podczas
wprowadzania nowej wersji produktu i nie zawierają żadnych danych klienta. W
krytycznej sytuacji całkowitej utraty mogą być, z pomocą producenta, częściowo
odtworzone.
Sugerowanym jednak rozwiązaniem jest okresowe kopiowanie, lub synchronizowanie

z tzw. lustrzaną kopia) katalogów z systemem GRANIT oraz pliku
SysReg_{63AFD5B1-49BA-11D5-9AA5-00105A72C191}.ini (patrz pkt. 6.3.1) za
pomocą narzędzia Kopii zapasowa lub np.ROBOCOPY.EXE – narzędzie Microsoft.
Pomocne tutaj być może skorzystanie z mechanizmu Harmonogramu zadań
systemu WINDOWS w którym możemy np. stworzyć cotygodniowy plan kopii
systemu GRANIT:
 (%SystemRoot%\system32\taskschd.msc /s)
 %SystemRoot%\explorer.exe ::{20D04FE0-3AEA-1069-A2D8-
08002B30309D}\::{21EC2020-3AEA-1069-A2DD-
08002B30309D}\::{D6277990-4C6A-11CF-8D87-00AA0060F5BF}

Rys. 8-11. Opcje programu ROBOCOPY.EXE.
Rys. 8-12. Przykładowy Harmonogram zadań (Zaplanowane zadania) w

systemie WINDOWS
8.3.4 Kopia całego serwera.

Innym rozwiązaniem jest tworzenie kopii całego serwera (systemu operacyjnego i
wszystkich plików). Zaletą takiego rozwiązania jest szybkość odtworzenia serwera w
przypadku całkowitej awarii systemu operacyjnego. Wadą jest to że: wymaga to
większej wiedzy i sprawności od administratora serwera, kłopotliwe jest również
sprawdzenie poprawności wykonanej kopii oraz kłopotliwa wielkość archiwizowanych
danych.
Sugerowanym rozwiązaniem jest wykorzystanie tworzenia kopii całego serwera jako
dodatkowego uzupełniającego zabezpieczenia danych, tworzonego pod kątem
szybkości odtworzenia systemu.

9. Nadpisywanie bazy testowej bazą produkcyjną.
W poniższym rozdziale opisano jak nadpisać bazę testową bazą produkcyjną
poprzez narzędzie systemu GRANIT oraz zadanie zaplanowane serwisu SQL Agent,
które o wskazanej godzinie wykonuje backup bazy produkcyjnej a następnie restore
tej bazy na bazę testową.
9.1 Narzędzia systemu GRANIT
Korzystając z narzędzi systemu GRANIT można wykonać nadpisanie testowej bazy

danych GRANIT_TEST (w przypadku posiadania innych baz należy stosować
narzędzia do wykonywania backup’u i restore bazy danych takie jak SQL Server
Management Studio – (patrz 7.3 Polityka kopii zapasowych.)
Rys. 9-1. Na serwerze aplikacji GRANIT wybieramy: Odświeżenie testowej bazy

danych

Rys. 9-2. Wskazujemy bazę produkcyjną którą nadpisujemy na bazę testową
GRANIT_TEST
Rys. 9-3. Po kliknięciu przycisku Start zostanie rozpoczęty proces

nadpisywania bazy testowej bazą produkcyjną.
9.2 SQL Server Agent.
Automatyczne nadpisywanie bazy testowej bazą produkcyjną ustawiamy

w Microsoft SQL Server Management Studio. Przedstawione akcję ustawione są
dla standardowych baz GRANITowych:
 GRANIT
 GRANIT_KOPIA
Automatyczne nadpisywanie bazy testowej ustawiamy za pomocą SQL Server

Agent. Jest to usługa, która posiada możliwość skonfigurowania zaplanowanych
czynności (Jobów).

Uwaga:
Należy sprawdzić czy usługa SQL Agent jest włączona (powinna być
uruchamiana z systemem Windows).
By ustawić takie zaplanowane czynności, wybieramy nowy JOB.
Pojawia się okno, na którym ustawiamy szczegóły naszego zadania zaplanowanego.
9.2.1 SQL Serwer Agent – zakładka „General”
 Name – nazwa wykonywanej czynności

 Owner – użytkownika na którym czynność będzie wykonywana

 Category – wybieramy (Lokal)
 Description – opis wykonywanej czynności
 CheckBox Enable – musi być zaznaczony
9.2.2 SQL Serwer Agent – zakładka „Steps”
Na zakładce ustawiamy kroki które SQL Serwer Agent ma wykonać.
Aby zdefiniować nowy krok dla zadania zaplanowanego wybieramy przycisk New.
W poniższych punktach opisano trzy kroki które należy zdefiniować by system
automatycznie nadpisywał bazę testową bazą produkcyjną.

9.2.3 Backup bazy produkcyjnej.
 Step name – wpisujemy nazwę dla kroku

 Type – wybieramy skrypt SQL
 Command – wprowadzamy skrypt, który wykona backup bazy produkcyjnej
w określonej lokalizacji
backup database GRANIT to disk = 'd:\GRANIT\backup\bak.bak'
Za pomocą przycisku Next przechodzimy do następnego kroku.

9.2.4 Nadpisanie kopii bazą produkcyjną.

 Type - wybieramy skrypt SQL
 Command – wpisujemy skrypt, który napisze wskazaną bazę bazą
produkcyjną.
RESTORE DATABASE GRANIT_KOPIA
FROM DISK = 'D:\GRANIT\Backup\bak.bak' WITH
MOVE 'ORIGINAL_Log' TO 'D:\GRANIT\DBFiles\GRANIT_KOPIA.ldf',
MOVE 'ORIGINAL_Data' TO 'D:\GRANIT\DBFiles\GRANIT_KOPIA.mdf'
go
use GRANIT_KOPIA
go
sp_afterimport
go
Uwaga:
Należy podać poprawne ścieżki do plików bazy danych którą będziemy
nadpisywać.

9.2.5 Usunięcie backpu bazy produkcyjnej.

 Type – Operating system
 Run as – SQL Agent Service Account
 Command – wpisujemy skrypt, który usunie nam z dysku wcześniej
utworzony backup bazy produkcyjne.
del d:\GRANIT\backup\bak.bak

9.2.6 SQL Serwer Agent – zakładka „Schedules”
Na zakładce ustawiamy w jakim czasie czynności mają się wykonać.
Za pomocą przycisku New uruchamiamy formatkę do określenia parametrów

czasowych.
New Job Schedule.
Ustawiamy czas w jakim czynności mają się wykonać.

 Name - nazwa operacji
 Schedule type – Recurring
 CheckBox Enabled – włączony
 Occurs – wybieramy codziennie
 Recurs every – 1 dzień
 Occurs once at – godzina rozpoczęcia
 Start date – data rozpoczęcia czynności
 End date – data zakończenia wykonywania czynności, jeśli data nie jest
określona zaznaczamy No end date
9.2.7 SQL Serwer Agent – zakładka „Notifications”
Zaznaczamy checkBox: Write to the Windows Application event log. Wybieramy

by zapisywał logi gdy czynności się nie powiodą.

9.3 Napisywanie bazy testowej produkcyjną za pomocą skryptu.
Uruchomienie ręcznego procesu napisania bazy testowej bazą produkcyjną odbywa

się za pomocą skryptu uruchomionego przez SQL Server Management Studio
9.3.1 Skrypt nadpisujący bazę testową bazą produkcyjną.
USE MASTER
if exists (select * from dbo.sysobjects where id =

object_id(N'[dbo].[sp_kill_all_db_connections]') and OBJECTPROPERTY(id,
N'IsProcedure') = 1)
drop procedure [dbo].[sp_kill_all_db_connections]
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_NULLS ON
GO
CREATE procedure sp_kill_all_db_connections

(
@db_name varchar(40)
)
as
if not exists(select dbid from sysdatabases where name = @db_name)

begin
raiserror('Database ''%s'' does not exist in system catalog!', 16, 1,
@db_name)
return(1)
end
declare spid_cur cursor read_only for

select sp.spid from master..sysprocesses sp join master..sysdatabases sdb
on sp.dbid = sdb.dbid
where sdb.name = @db_name
declare @spid smallint, @cmd nvarchar(50)

open spid_cur
fetch next from spid_cur into @spid

while (@@fetch_status <> -1)
begin

if (@@fetch_status <> -2)
begin
set @cmd = N'kill ' + convert(nvarchar(10), @spid)
exec sp_executesql @cmd
end
fetch next from spid_cur into @spid
end
close spid_cur
deallocate spid_cur
return(0)
GO
BACKUP DATABASE GRANIT TO DISK = N'C:\Program Files\Microsoft SQL

Server\MSSQL.1\MSSQL\Backup\PEC_K_PROD.bak' WITH INIT
GO
EXEC sp_kill_all_db_connections 'PEC_K_PROD_TEST'

GO
RESTORE DATABASE PEC_K_PROD_TEST

FROM DISK = N'C:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\Backup\PEC_K_PROD.bak' WITH REPLACE,
MOVE 'ORIGINAL_DATA' TO 'D:\BAZY\PEC_K_PROD_TEST_Data.MDF',
MOVE 'ORIGINAL_LOG' TO 'L:\LOGI\PEC_K_PROD_TEST_log.LDF'
9.3.2 Opis najważniejszych elenentów skryptu nadpisującego bazę

testową.
a) Ustawiamy ścieżkę do miejsca, gdzie ma się zapisać backup bazy

produkcyjnej.
BACKUP DATABASE GRANIT TO DISK = N'C:\Program Files\Microsoft SQL

Server\MSSQL.1\MSSQL\Backup\NAZWA_PLIKU_BACKUP.bak' WITH INIT
*/ Ścieżka do pliku z backupem bazy danych. Serwer SQL musi posiadać

uprawnienia do zapisu do określonego katalogu.
b) Odcięcie wszystkich użytkowników połączonych do bazy produkcyjnej, którą

chcemy nadpisać bazą testową.
EXEC sp_kill_all_db_connections 'TEST_DB'

*/ ‘TEST_DB’ – odpowiednia nazwa bazy testowej, na którą zrestorowana zostanie
baza produkcyjna.
*/ Przed puszczeniem skryptu musimy mieć pewność że nikt nie pracuje na bazie
produkcyjnej.
c) Procedura wykonująca napisanie bazy testowej bazą produkcyjną.
RESTORE DATABASE TEST_DB

FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\
NAZWA_PLIKU_BACKUP.bak' WITH REPLACE,
MOVE 'ORIGINAL_DATA' TO 'D:\BAZY\TEST_DB_Data.MDF',
MOVE 'ORIGINAL_LOG' TO 'L:\LOGI\TEST_DB _log.LDF'
*/ ‘TEST_DB’ – odpowiednia nazwa bazy testowej, na którą zrestorowana zostanie

baza produkcyjna.
*/ 'D:\BAZY\TEST_DB_Data.MDF' – scieżka do pliku pliku bazy danych.
*/ 'L:\LOGI\TEST_DB _log.LDF' – scieżka do pliku logu bazy danych.

10. Konfiguracja urządzeń współpracujących z systemem
GRANIT.
10.1 Drukarki fiskalne
Obsługa mechanizmu połączeniowego drukarek fiskalnych Thermal
realizowana jest za pomocą komponentu tunelującego ReceiptPrinter.Manager.
Zajmuje się on zdalną aktywacja składnika InvoicePrinter.PrinterCore.1
W celu poprawnej aktywacji wszystkich zależnych składników wymagane jest:
STACJA ROBOCZA do której podłączona jest drukarka fiskalna:
 Umiejscowienie biblioteki ThermalServiceLibrary.dll (dostarczanej przez

producenta drukarki wraz z pakietem emulatora) w jednej z lokalizacji
[%windir%\System32\], [%windir%\System\] lub w bieżącym katalogu
użytkownika (zalecana lokalizacja to [%windir%\System32\])
 Zainstalowanie bibliotek z pakietu vcredist_x86.exe
 Umiejscowienie w pakiecie Invoice składnika COM+

InvoicePrinter.PrinterCore.1 na maszynie, która fizycznie połączona jest z
drukarka fiskalną – pakiet może być lokalizowany w dowolnym miejscu na
dysku – należy pakiet zarejestrować w systemie Windows – można to zrobić
metodą drag&drop pliku InvoicePrinter.dll w miejsce gdzie znajdują się
składniki pakietu Invoice. (należy wcześniej dodać pustą aplikację serwera:
Invoice z poziomu usługi składowe->komputery->mój komputer->Aplikacje
COM+:prawym przyciskiem myszy->Nowy: Aplikacja)
 poprawna konfiguracja uprawnień dostępu COM+ (patrz też pkt. 10.1.x).

Należy się upewnić czy we właściwościach pakietu Invoice wyłączone jest
wymuszanie testów dostępu dla tej aplikacji:

SERWER KOMPONENTÓW:
 umiejscowienie w pakiecie Invoice składnika COM+

ReceiptPrinter.Manager, (jeżeli nie został już wcześniej zarejestrowany)
10.1.1 Konfiguracja uprawnień dla zdalnej aktywacji

składników z wykorzystaniem uzytkownika nie-domenowego
 Należy dodać na stacji roboczej użytkownika, na którym pracują komponenty

systemu GRANIT na serwerze aplikacji GRANIT, z takim samym hasłem co
na serwerze aplikacji
 Należy aktywować pakiet Invoice na koncie tego użytkownika oraz zapewnić

możliwość zdalnej aktywacji składników dla tego pakietu
10.1.2 Konfiguracja uprawnień dla zdalnej aktywacji

składników z wykorzystaniem uzytkownika domenowego

 Użytkownik domenowy przygotowany do aktywacji zdalnej składników
powinien mieć uprawnienia administratora i należeć do grupy
operatorów DCOM.
 Aktywacja pakietu Invoice powinna odbywać się na koncie tego

użytkownika oraz należy zapewnić możliwość zdalnej aktywacji
składników tego pakietu (edycja uprawnień):
10.1.3 Konfiguracja parametrów uruchomieniowych

Obecnie konfiguracji mechanizmu dokonuje się przez edycje wpisów w tabeli
ReceiptPrinterConfiguration znajdującej się na bazie produkcyjnej GRANIT
(w kolejnych wersjach planowane jest przygotowanie mechanizmu umożliwiającego
edycję tych parametrów w systemie „GRANIT”).
Znaczenie pól:
 Name – nazwa konfiguracji
 MachineName – nazwa domenowa maszyny fizycznie powiązanej z drukarką
fiskalną
 PortName – port połączenia z drukarką

 BaudRate – ilość bitów przypadająca na 1 sek. Transmisji
 PrinterCode – parametr uwzględniany na wydruku (kod drukarki)
 ApplicationName – nazwa komponentu komunikującego się z drukarka
(składnik pakietu Invoice na maszynie powiązanej z drukarka – określona
przez parametr MachineName)
 LogEnabled – 1- wyłączony 2- włączony – w tabeli printersystemlog
 CodePage – wartość określająca stronę kodową używaną przez drukarkę
1 CSK,
2 Cyfromat,
3 DHN,
4 IBM,
5 ISO,
6 Mazovia,
7 MacIntosh,
8 Microvex,
9 Oficyna,
10 Windows,
11 BezPolskich
Drukarka fiskalna wymaga oprogramowania oznaczeń kodowych stawek VAT
używanych w systemie zintegrowanym „GRANIT” – odpowiednie wpisy w tabeli
rchStawkaVAT w kolumnie Code (które powinny być uzupełnione przy pierwszym
uruchomieniu drukarki)np.:
Aby sprawdzić jakie kody należy przypisać do jakiej stawki VAT, można skorzystać
z logów zapisywanych do tabeli PrinterSystemLog. Aby takie logowanie było
możliwe należy w tabeli ReceiptPrinterConfiguration w kolumnie LogEnabled
ustawić wartość: 2. Sprawdzenie takie zaleca się wykonać na bazie testowej np.
GRANIT_TEST, a następnie po przetestowaniu wydruku na drukarce fiskalnej,
zmienić wpisy w tabeli rchStawkaVAT na bazie GRANIT.
Wydruk na drukarce fiskalnej następuje po zatwierdzeniu faktury sprzedaży, która

musi zawierać:
 pozycje zawierające podatek VAT
 w zakładce „dane podstawiwe” wybrana musi być drukarka fiskalna
 w zakładce „dane podstawiwe” zaznaczona musi być opcja: rozliczenie brutto

Jeżeli włączyliśmy logowanie to w tabeli PrinterSystemLog będziemy mieli m.in.
następujący wpis analogiczny do poniższego
W wierszu gdzie dla kolumny MethodName jest wpisy VAT Script, w polu
Description jest wpis w którym mamy informacje jaki jest przypisany kod do jakiej
stawki VAT np.:
UPDATE receiptpositions
SET vatcode = 'A'
WHERE vatcode = '23.00'
AND receiptid = 3
SET vatcode = 'B'
AND receiptid = 3
SET vatcode = 'C'

AND receiptid = 3
SET vatcode = 'D'
AND receiptid = 3
SET vatcode = 'E'
AND receiptid = 3
SET vatcode = 'F'
AND receiptid = 3
SET vatcode = 'G'
AND receiptid = 3
Przy zatwierdzaniu faktury może pojawić się błąd. Należy po odpowiednim

przypisaniu stawek VAT w tabeli rchStawkaVAT (jeżeli w tabeli jest kilka pozycji
gdzie w kolumnie wartość widnieje np. 0, to każdej z tych pozycji w kolumnie Code
przypisujemy ten sam kod – w powyższym przypadku będzie to C ) i spróbować
zatwierdzić kolejną fakturę i sprawdzić poprawność wydruku na drukarce fiskalnej.

11. Rozwiązania najczęściej spotykanych problemów.
W poniższym rozdziale opisano najczęściej spotykane problemy we wdrożeniach
systemu GRANIT.
W pierwszej części zebrano problemy. Druga część jest zbiorem elementarnych
czynności wykorzystanych w części pierwszej do rozwiązywania problemów.
11.1 Problemy
11.1.1 System nie daje się uruchomić na stacji klienckiej.
 Restartuj stację kliencką i spróbuj ponownie. Jeśli problem nie ustąpił przejdź
dalej.
 Sprawdź, czy system nie działa na tej jednej stacji klienckiej, czy też nie
działa na wszystkich stacjach klienckich.
 Sprawdź, czy system działa na serwerze aplikacji COM+.
 Jeśli system nie działa na serwerze aplikacji COM+, przejdź do problemu:
System nie da się uruchomić nawet na serwerze aplikacji COM+.
 Jeśli system nie działa na wszystkich stacjach klienckich, przejdź do
problemu: System nie daje się uruchomić na wszystkich stacjach klienckich.
 Sprawdź czy sieć działa. (Sprawdzenie szybkości i jakości połączenia

sieciowego). Jeśli to nie pomogło, przejdź dalej.
 Sprawdź, dla nie działającej stacji roboczej, czy są włączone ustawienia
opisane w Zdalna praca komponentów COM. Jeśli to nie pomogło, przejdź
dalej.
 Jeśli po zmianie i ewentualnym restarcie tej stacji klienckiej nadaj problem
występuje to sprawdź poprawność autoryzacji użytkownika na serwerze
COM+. Przyczyną mogłaby to być np. zmiana hasła użytkownika stacji
klienckiej w sytuacji gdy stacja kliencka i serwer aplikacji nie są w tej samej
domenie. Operacja: Sprawdzenie poprawności autoryzacji użytkownika
Windows stacji klienckiej na serwerze aplikacji COM+.
 Jeśli i to nie dało rezultatów, to należy sprawdzić czy serwer jest
rozpoznawany po nazwie w operacji: Sprawdzenie działania systemu
rozpoznawania nazw DNS na stacji klienckiej.
 Jeśli to nie pomogło i problem ma charakter trwały należy zgłosić problem
techniczny i dołączyć do zgłoszenia wszystkie dotychczas zebrane
informacje.
11.1.2 System nie daje się uruchomić na wszystkich stacjach

klienckich.
Jeśli system nie działa na wszystkich stacjach roboczych to najprawdopodobniej jest
to problem z serwerem aplikacji.
 Sprawdź czy system daje się uruchomić bezpośrednio na serwerze aplikacji

COM+. Jeśli nie to przejdź do problemu: System nie daje się uruchomić nawet
na serwerze aplikacji COM+.

 Sprawdź czy ustawiono odpowiednie uprawnienia uruchamiania zdalnego
komponentów COM+ - Zdalna praca komponentów COM.
 Będąc na stacji klienckiej zacznij od sprawdzenia sieci (Sprawdzenie

szybkości i jakości połączenia sieciowego).
 Sprawdź czy jakiś użytkownik jest zalogowany na serwerze aplikacji COM+ i
czy komponenty nie pracują jako użytkownik interaktywny (Sprawdzenie w
jakiej tożsamości pracują komponenty COM+ na serwerze aplikacji COM+).
 Jeśli problem nadal występuje należy sprawdzić na serwerze aplikacji COM+
włącznik zdalnej pracy COM za pomocą operacji: Zdalna praca komponentów
COM.
techniczny i dołączyć do zgłoszenia wszystkie dotychczas zebrane informacje.
11.1.3 System nie daje się uruchomić nawet na serwerze aplikacji COM+.
 Spróbuj zrestartować komponenty COM+ poprzez wykorzystanie narzędzia

MTSUtils.exe (Awaryjne, zamknięcie procesu(ów) aplikacji COM+.)
 Sprawdź w jakiej tożsamości pracują aplikacje na serwerze aplikacji COM+
(Sprawdzenie w jakiej tożsamości pracują komponenty COM+ na serwerze
aplikacji COM+). Jeśli to konieczne zmień konto na jakim pracują (Zmiana
tożsamości aplikacji COM+)
informacje.
11.1.4 System wolno działa na stacji klienckiej.
 Sprawdź, czy system wolno działa również na serwerze aplikacji COM+. Jeśli
tak, to przejdź do problemu System wolno działa również na serwerze
aplikacji COM+.
 Sprawdź jakość połączenia sieciowego z serwerem aplikacji COM+
(Sprawdzenie szybkości i jakości połączenia sieciowego) oraz sprawdź
szybkość pracy DNS (Sprawdzenie działania systemu rozpoznawania nazw
DNS na stacji klienckiej). Jeśli problemem może być wolno działający DNS
spróbuj go pominąć (Wpisy w plikach HOSTS i LMHOSTS)
 Sprawdź, czy stacja lokalna nie jest obciążona innym niż GRANIT
oprogramowaniem. Sprawdź czy ewentualne wyłączenie aplikacji firewall i
antywirusowych na stacji klienckiej nie poprawi sytuacji.
 Włącz kompresję komunikacji z serwerem aplikacji COM+ (Włączenie
kompresji danych pomiędzy serwerem aplikacji COM+ a stacją kliencką dla
danego użytkownika).
informacje.

11.1.5 System wolno działa również na serwerze aplikacji
COM+.
 Sprawdź obciążenie bazy danych na serwerze bazy danych (Sprawdzenie

obciążenia serwera bazy danych). Jeśli problem dotyczy serwera bazy danych
i problem ma charakter trwały należy zgłosić problem techniczny i dołączyć do
zgłoszenia wszystkie dotychczas zebrane informacje.
 Sprawdź obciążenie i ogólny stan serwera aplikacji (Sprawdzenie obciążenia
serwera aplikacji COM+. Sprawdzenie bieżącego stanu ogólnego serwera
aplikacji COM+ pod kątem wszystkich aplikacji COM+). Spróbuj zapamiętać
nazwy aplikacji i komponentów sprawiających problemy. Jeśli problem
zwolnienia działania ma charakter trwały należy zgłosić problem techniczny i
dołączyć do zgłoszenia wszystkie dotychczas zebrane informacje.
11.1.6 Aplikacja na stacji klienckiej loguje się bez pytania o hasło.
 Jeśli nastąpiło to po awaryjnym przerwaniu aplikacji GRANIT należy odczekać

kilka minut po których usługa systemowa automatycznie wyloguje wiszące
sesje użytkownika.
 Jeśli problem nie ustąpi należy ręcznie zamknąć tą sesję za pomocą aplikacji
AccessCodeCleaner.exe dostępnej na serwerze aplikacji COM+ w katalogu
ServerApplications i sprawdzić działanie usługi DDSYSTEMSERVICE na
serwerze aplikacji COM+.
 Jeśli to nie pomogło i problem ma charakter trwały (kilkudniowy) należy zgłosić
problem techniczny i dołączyć do zgłoszenia wszystkie dotychczas zebrane
informacje.
11.2 Elementarne operacje rozwiązywania problemów.
11.2.1 Zdalna praca komponentów COM.

Czasami po instalacji oprogramowania, poprawek systemowych lub po ataku
złośliwego oprogramowanie zostaje wyłączona opcja zdalnej pracy komponentów
COM+ na danym komputerze.
Patrz rozdział 4.1.2.2.5 Zabezpieczenia COM
11.2.2 Sprawdzenie poprawności autoryzacji użytkownika

Windows stacji klienckiej na serwerze aplikacji COM+.
System GRANIT wymaga aby użytkownik systemu Windows na stacji klienckiej był
autoryzowany przez serwera. Poprawność autoryzacji można sprawdzić w poniższy
sposób.

Restartować system na stacji klienckiej i po ponownym uruchomieniu spróbować
otworzyć na stacji klienckiej zawartość dowolnego udziału sieciowego na serwerze
aplikacji COM+.
Rys. 11-1. Zawartość udziału sieciowego na przykładowym serwerze.
System powinien otworzyć to okno bez pytania się o autoryzację użytkownika.

Jeśli nastąpiło pytanie o autoryzację to oznacza, że system operacyjny na serwerze
aplikacji COM+ nie rozpoznał użytkownika.
 W przypadku GRUPY ROBOCZEJ należy upewnić się że użytkownik na stacji
roboczej ma poprawnego odpowiednika na serwerze pod kątem nazwy i
hasła. Najczęstszą przyczyną takiej sytuacji jest zmiana przez użytkownika
stacji klienckiej swojego hasła.
 W przypadku domeny należy sprawdzić uprawnienia dla użytkowników
domeny dla poszczególnych udziałów
Należy ustawić odpowiednie uprawnienia do udziałów sieciowych na serwerze

aplikacji GRANIT – patrz pkt. 2.3 Serwer plików systemu.
Jeśli system pokazał zawartość katalogu bez pytania o autoryzację to albo zalogował
użytkownika jako tzw. Gościa lub poprawnie zautoryzował użytkownika.
Aby to sprawdzić należy pozostawić na stacji klienckiej otwarte okno z zawartością
udziału sieciowego serwera, a następnie udać się na serwer i uruchomić z Panelu
sterowania i Narzędzi administracyjnych konsolę Zarządzanie komputerem.

Rys. 11-2. Panel zarządzania komputerem.
Na konsoli Zarządzanie komputerem należy rozwinąć węzeł Narzędzia systemowe –

Katalogi udostępnione – Sesje.
Na liście sesji powinna być widoczna sesja o użytkowniku takim samym jak
zalogowany na naszej stacji klienckiej (kolumna Komputer z nazwą stacji klienckiej
lub jej adresie IP). W kolumnie Gość powinna być wartość Nie.
Rys. 11-3. Kolumna "Gość".
Jeśli sesja odpowiadająca danemu użytkownikowi jest na liście sesji, a w kolumnie

Gość jest wartość Nie to autoryzacja jest poprawna. W przeciwnym wypadku mamy
do czynienie z brakiem autoryzacji i system GRANIT nie będzie działał. Należy
sprawdzić nazwy i hasła użytkowników na serwerze aplikacji i stacji roboczej.

11.2.3 Sprawdzenie działania systemu rozpoznawania nazw
DNS na stacji klienckiej.
Poprawne rozpoznawanie nazwy serwera aplikacji przez stację kliencką jest
warunkiem sprawnego działania systemu GRANIT. W prosty sposób można
sprawdzić szybkość rozpoznawania nazwy serwera aplikacji przez stację kliencką
wykorzystując poleceni PING.
W pierwszej kolejności należy ponownie uruchomić stację kliencką i na dopiero co
uruchomionej stacji należy uruchomić okno trybu linii poleceń.
W oknie linii poleceń należy wpisać polecenie „ping” i po spacji nazwę serwera
aplikacji COM+. Po naciśnięciu klawisza Enter należy zwrócić uwagę na czas jaki
upłynął POMIĘDZY naciśnięciem klawisza, a pojawieniem się pierwszych
komunikatów. Nie mówimy tutaj o czasie jaki pokazuje polecenie ping, a jedynie
czasie w którym „nic się nie dzieje” w oknie poleceń. Czas ten jest czasem jaki stacja
kliencka potrzebowała na zamianę nazwy serwera aplikacji COM+ na jego adres IP.
W poprawnie skonfigurowanych sieciach czas ten powinien być praktycznie
niezauważalny, a przynajmniej krótszy od 1s.
Rys. 11-4. Uruchomienie linii poleceń.
Rys. 11-5. Przykładowy rezultat polecenia ping.
11.2.4 Wpisy w plikach HOSTS i LMHOSTS.
W niektórych przypadkach należy ominąć system rozpoznawania nazw i ręcznie

powiązać nazwę sieciową określonego komputera z określoną nazwą sieciową.
Wykorzystywany jest do tego plik HOSTS i zlokalizowany w katalogu

%windir%\SYSTEM32\DRIVERS\ETC
W pliku należy wprowadzić linię w której umieszczamy parę adres IP oraz nazwę
komputera oddzielone spacjami.
Linie zaczynające się znakiem # to linie komentarzy.
Rys. 11-6. Plik HOSTS z wpisem o komputerze serverapp.
11.2.5 Sprawdzenie szybkości i jakości połączenia

sieciowego.
Do prostego wykonania sprawdzenie jakości połączenia lub ewentualnego jej braku
wykorzystywane jest polecenie PING. Polecenie to zwraca czasy potrzebne na
przesłanie paczek danych przez sieć z komputera lokalnego, do tego którego
„pingujemy”. Czasy te mogą być wyznacznikiem szybkości działania sieci. W
standardowej sieci lokalnej o szybkości 100 Mb/s czasy powinny się mieścić poniżej
10 ms. Standardowe wywołanie powoduje wykonanie tylko kilku „pingowań”. Jeśli
chcemy by zdalny komputer był pingowany cały czas powinniśmy użyć przełączniki „-
t”. Poniżej przykład ciągłego pingowania serwera PEC_MTS.

Rys. 11-7. Ciągłe "pingowanie" serwera GRANITVERSION.
Przerwanie pingowania można wykonać za pomocą kombinacji Ctrl+C.
11.2.6 Sprawdzenie obciążenia serwera bazy danych.
Najprostszym sposobem sprawdzenia obciążenia serwera bazy danych jest

sprawdzenie procesu serwera za pomocą menedżera zadań.
Rys. 11-8. Serwer bazy danych na liście procesów komputera.
11.2.7 Sprawdzenie obciążenia serwera aplikacji COM+.

Sprawdzenie bieżącego stanu ogólnego serwera aplikacji COM+
pod kątem wszystkich aplikacji COM+.
Ogólne sprawdzenie stanu serwera można wykonać za pomocą systemowego

menedżera procesów. Każdej aplikacji COM+ odpowiada proces SVCHOST.EXE lub
DLLHOST.EXE (w zależności od systemu operacyjnego). Ogólne spojrzenie na
zachowanie się tych procesów daje wstępny obraz sytuacji serwera.

Rys. 11-9. Procesy DLLHOST.EXE serwera aplikacji.
Do ogólnego spojrzenia na wszystkie aplikacje COM+ w systemie może być użyta

aplikacja DDComSpy.exe. Pokazuje ona praktycznie takie same informacje jak
systemowa konsola Usług składowych ale w jej przypadku mamy podgląd na
wszystkie komponenty jednocześnie. Kolumna Status pokazuje przybliżony stan
danego komponentu. Jeśli przez dłuższy czas dla jakiegoś komponentu pokazywana
w tej kolumnie wartość jest inna niż OK (np. Warning) to oznacza problem z danym
składnikiem COM+. Kolumna ProcessId pokazuje PID aplikacji skojarzonej z
komponentem. Kolumna InCall pokazuje ilość instancji danego komponentu
obsługujących w danej chwili wywołanie funkcji. Kolumna Total Instances pokazuje
ilość aktywnych w danej chwili instancji komponentu COM+.
Narzędzie DDComSpy.exe umieszczone jest zazwyczaj w katalogu głównym
aplikacji GRANIT w podkatalogu DesignTools na serwerze aplikacji COM+.

Rys. 11-10. Aplikacja DDComSpy.exe.
Konsola Usług składowych dostępna w Panelu sterowania w Narzędziach

administracyjnych pokazuje analogiczne informacje, ale przydatne bardziej pod
kątem monitorowania pojedynczej aplikacji COM+ a nie systemu jako całości.
Rys. 11-11. Konsola Usług składowych. Monitorowanie pracy komponentu

Actions.ActionManager z aplikacji _Actions.

11.2.8 Włączenie kompresji danych pomiędzy serwerem
aplikacji COM+ a stacją kliencką dla danego użytkownika.
Włączenie kompresji danych wymienianych pomiędzy daną stacją roboczą, a

serwerem aplikacji wykonywane jest dla konkretnego użytkownika systemu GRANIT
w jego opcjach aplikacji. Aby włączyć/wyłączyć kompresowanie danych należy
zaznaczyć lub zdjąć zaznaczenie na opcji Kompresowanie danych wymienianych z
serwerem w opcjach głównej aplikacji GRANIT (menu Opcje-Opcje aplikacji).
Po zmianie opcji należy nacisnąć przycisk Zapisz a potem OK.
Zmiany w kompresji będą widoczne po ponownym zalogowaniu do systemu.
Rys. 11-12. Opcja kompresji danych.
11.2.9 Awaryjne, zamknięcie procesu(ów) aplikacji COM+.

Czasami, w specyficznych sytuacjach, konieczne jest ręczne wpłynięcie na pracę
systemu poprzez wymuszenie zakończenie procesu. Sytuacje takie są sporadyczne i
nie powinny być traktowane jako normalny sposób postępowania.
Awaryjne zamknięcie aplikacji COM+ może być wykonane z trzech różnych miejsc:
 menedżera zadań po wybraniu odpowiedniego procesu aplikacji (należy znać
PID aplikacji COM+)

Rys. 11-13. Ręczne kończenie procesu w Menedżerze zadań.
 konsoli Usług składowych na węźle danej aplikacji.
Rys. 11-14. Opcja zatrzymania aplikacji _Actions.
 Narzędziem MTSUtils.exe znajdującym się w katalogu

[xxx:\GRANIT\DesignTools]
Za pomocą tego narzędzia można dokonać zamknięcia wszystkich procesów

komponentów COM+, bez możliwości wyboru pojedynczych procesów tak jak
było to możliwe w przypadku dwóch powyższych możliwości. Należy na
zakładce „Shut Down” wybrać „Shut Down All Packages”

Rys. 11-15. Opcja zatrzymania wszystkich procesów COM+ systemu GRANIT
11.2.10 Sprawdzenie w jakiej tożsamości pracują komponenty

COM+ na serwerze aplikacji COM+.
Sprawdzenia można szybko dokonać na serwerze aplikacji COM+ za pomocą
konsoli Usług składowych umieszczonych w Panelu sterowania w Narzędziach
administracyjnych. – patrz rozdział 7.2.1 Tożsamość aplikacji COM+. Użytkownik
interakcyjny lub dedykowany.
11.2.10.1 Zmiana tożsamości aplikacji COM+.

Opis jak można ręcznie konfigurować tożsamość aplikacji
COM+ znajduje się w rozdziale 5.2.2

12. Przygotowywanie technicznego zgłoszenia
serwisowego
Informacje znajdują się na stronie
http://www.GRANIT-software.pl/I.Kontakt/Jak%20zglaszac%20bledy/

Podręcznik Administratora Systemu GRANIT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Podręcznik Administratora Systemu GRANIT

Uploaded by

Copyright:

Available Formats

Dokumentacja technologiczna

i administracyjna systemu opartego

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 1 z 106

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 2 z 106

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 3 z 106

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 4 z 106

Rys. 2-1 Logiczna struktura systemu.

2.1 Warstwa bazy danych.

2.1.1 Baza LOGON.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 5 z 106

2.1.3 Inne bazy danych.

Podczas prac wdrożeniowych (jak i rozwojowych po wdrożeniu) mogą powstać także

2.2 Warstwa biznesowa.

2.2.1 Serwer aplikacji COM+.

2.2.2 Komponent COM+.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 6 z 106

2.2.2.1 Komponenty systemowe.

W grupie komponentów systemowych wyróżniamy m.in. komponent do komunikacji

2.2.2.2 Komponent do komunikacji z bazą danych.

2.2.2.3 Komponenty logiki biznesowej.

2.2.2.4 Komponenty komunikacji z warstwą prezentacji.

2.3 Warstwa prezentacji.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 7 z 106

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 8 z 106

Rys. 3-1. Przykładowa realizacja systemu GRANIT.

3.1 Serwer bazy danych.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 9 z 106

3.2.2 Dodatkowe usługi systemowe .

Rys. 3-2. Przykładowa usługa systemowa GRANIT DDSystemService.

3.2.3 Autoryzacja użytkowników sieciowych.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 10 z 106

3.3 Serwer plików systemu.

3.3.1 Aplikacje EXE.

3.3.3 Katalog wymiany

3.3.4 Inne pliki i katalogi.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 11 z 106

3.4 Stacja kliencka.

Rolę stacji klienckiej pełni komputer użytkownika systemu. W specyficznych

3.4.1 Pliki lokalne.

Rys. 3-3. Pliki lokalne na stacji roboczej.

3.4.2 Katalog tymczasowy.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 12 z 106

Rys. 3-4. Szybki sposób pokazania zawartości katalogu tymczasowego.

3.5 Sieć komputerowa.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 13 z 106

4.1 Serwer bazy danych.

Wspieranymi nieserwerowymi systemami operacyjnymi są:

o Microsoft Windows 2000 Professional (niezalecany),

 Serwer bazy danych powinien posiadać wystarczającą pojemność dyskową do

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 14 z 106

 na serwerze bazy danych powinna być udostępniona możliwość zdalnego

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 15 z 106

 dedykowany użytkownik powinien mieć uprawnienia roli:

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 16 z 106

 Standardowo proces obsługujący SQL Server działa na użytkowniku

4.2 Serwer aplikacji COM+.

Wspieranymi nieserwerowymi systemami operacyjnymi są:

o Microsoft Windows 2000 Professional,

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 17 z 106

 Mechanizm rozproszonej pracy aplikacji COM+ opiera się na kilku usługach

4.3 Stacja kliencka.

Ostatnia modyfikacja: 2013-01-05 10:02:00 Strona 18 z 106

4.4 Sieć komputerowa.