W aplikacji Panel System można skonfigurować system oraz grupy deweloperskie oraz monitorować działanie systemów. Można przeglądać, tworzyć, edytować lub usuwać następujące komponenty w celach konfiguracyjnych:
- Baza danych
- Grupa deweloperska
- Grupa systemów
- Grupa użytkowników
- Kolejka przetwarzania
- Licencja
- Moduł
- Obszar roboczy
- Oznaczenie bazy danych
- Połączenie z ERP System Output Manager
- Serwer aplikacji
- System
- Urząd certyfikacji
- Użytkownik
Poniższe obiekty nie są bezpośrednio powiązane z systemem:
- Użytkownik
- Grupa użytkowników
- Baza danych z wskazanym w polu Typ zawartości wartością: Dane konfiguracyjne systemu
- Oznaczenie bazy danych
- Licencja
- Urząd certyfikacji
Obiekty te są dostępne we wszystkich systemach. Jeśli system został utworzony po zaimportowaniu licencji, może zawierać następujące składniki:
- Baza danych
- Serwer aplikacji
- Kolejka przetwarzania
- Połączenie z ERP System Output Manager
- Obszar roboczy
Aby wprowadzić lub otworzyć te komponenty, należy zawsze podać nazwę systemu, a następnie kropkę i rzeczywistą nazwę obiektu.
Istnieją inne obiekty, które nie są powiązane z systemem:
- Grupa deweloperska – jest tworzona bez określania nazwy systemu. Jeśli grupa deweloperska została utworzona można wprowadzić obiekty: Moduł oraz Grupa systemów.
Aby wprowadzić lub otworzyć te komponenty (Moduł oraz Grupa systemów) należy zawsze wprowadzić nazwę grupy deweloperskiej, a następnie kropkę i rzeczywistą nazwę obiektu.
Panel System oferuje rozbudowane funkcje i opcje zapytań do monitorowania aktywnych komponentów, takich jak systemy, serwery aplikacji i połączenia ERP System Output Manager.
Instrukcje przed, w trakcie i po skonfigurowaniu systemu są dostępne
- w kategorii Tworzenie i konfiguracja systemu
- w artykule Konfiguracja topologii systemu
Zmiany w obiektach konfiguracyjnych
Baza konfiguracyjna jest bazą danych, która jest używana przez kilka systemów jednocześnie. Oznacza to, że dane międzysystemowe, takie jak użytkownicy, należy wprowadzić tylko raz, a topologią i ustawieniami centralnymi jednego systemu można zarządzać z innego systemu. Jest to między innymi pomocne, gdy trzeba wprowadzić nowy system lub istniejący system nie może zostać uruchomiony z powodu problemów z konfiguracją lub sprzętem i musi zostać ponownie skonfigurowany.
Buforowanie obiektów konfiguracyjnych
Aby zminimalizować liczbę dostępów do bazy danych obiektów konfiguracyjnych, podobnie jak w przypadku wszystkich innych obiektów biznesowych w systemie, ich dane są również buforowane we współdzielonej pamięci podręcznej serwera aplikacji. Po zalogowaniu się do systemu A i zmianie danych serwera aplikacji X systemu A, zmiany te są przekazywane do wszystkich serwerów aplikacji systemu A za pośrednictwem mechanizmu synchronizacji pamięci podręcznej. W przypadku zalogowania się do systemu B i zmiany danych serwera aplikacji A.X, tylko serwery aplikacji systemu B zostają poinformowane o tych zmianach. Ponieważ w systemie B nie jest znane, które inne systemy zostały uruchomione, a odpytywanie każdego potencjalnie uruchomionego systemu byłoby czasochłonne, początkowo aktualizowane są jedynie współdzielone pamięci podręczne systemu B. Na serwerach aplikacji systemu A, które już przechowują te dane we współdzielonej pamięci podręcznej, w aplikacji Panel System początkowo widoczne są nieaktualne dane w tym przypadku.
Istnieje kilka sposobów, aby zmiany były widoczne w innych systemach, jeśli jest to konieczne:
-
Otwarcie i zapisanie zmodyfikowanego obiektu w systemie A
Po zalogowaniu się do dowolnego serwera aplikacji systemu A należy otworzyć aplikację Panel System. Następnie należy otworzyć obiekt, w którym wyświetlane są nieaktualne dane, i użyć przycisku [Zapisz] na standardowym pasku narzędzi. Wyświetlany jest komunikat informujący, że dane w bazie danych zostały już zmienione, a obiekt należy otworzyć ponownie. Po ponownym otwarciu obiektu wyświetlane są już aktualne dane. Czynność ta wpływa automatycznie na wszystkie serwery aplikacji systemu A, dlatego wystarczy wykonać ją tylko raz.
-
Ponowne uruchomienie jednego lub wszystkich serwerów aplikacji systemu A:
Podczas ponownego uruchomienia współdzielone pamięci podręczne zostają opróżnione i ponownie wypełnione aktualną zawartością bazy konfiguracyjnej. Jest to najskuteczniejsza procedura, szczególnie w przypadku rzadko używanych systemów oraz systemów demonstracyjnych. Procedura ta jest również wymagana w przypadku niektórych zmian – szczegóły opisano poniżej.
Tworzenie nowych obiektów konfiguracji
Podczas wprowadzania nowych obiektów konfiguracji, np. użytkownika, a w większości przypadków także podczas dodawania powiązań, np. przyporządkowania użytkownika do grupy użytkowników lub systemu, zwykle nie są konieczne żadne dalsze działania, aby użyć nowych danych we wszystkich systemach. Wynika to z faktu, że dane obiektów konfiguracyjnych są buforowane we współdzielonej pamięci podręcznej wyłącznie wtedy, gdy istnieją, zgodnie z ich ustawieniami pamięci podręcznej. Dopiero po odnalezieniu obiektu jego dane są przechowywane we współdzielonej pamięci podręcznej, a zastosowanie mają zasady opisane w poprzedniej sekcji. Wyjątki od zachowania podczas tworzenia nowych obiektów konfiguracyjnych opisano w następnej rozdziale Tworzenie i zmiana aktywnych komponentów.
Tworzenie i zmiana aktywnych komponentów
W przypadku większości zmian ustawień aktywnych komponentów systemu (np. serwera aplikacji, bazy danych, SOM), np. zmiany połączeń z bazą danych serwera aplikacji, zwykle konieczne jest ponowne uruchomienie serwera aplikacji lub systemu. Powodem tego jest to, że wiele z tych ustawień jest odczytywanych raz po uruchomieniu serwera aplikacji i w tym celu tworzone są odpowiednie obiekty runtime (np. połączenia JDBC, wątki), których nie można zmienić bez dalszych czynności. Zasadniczo obowiązują następujące zasady:
- w przypadku wprowadzenia zmian na serwerze aplikacji i obiektach przypisanych do serwera aplikacji (np. kolejka przetwarzania), serwer aplikacji musi zostać ponownie uruchomiony.
- w przypadku wprowadzenia zmian w systemie i obiektach przypisanych do systemu (np. połączenie z ERP System Output Manager), system musi zostać ponownie uruchomiony.
Istniejące obiekty konfiguracji mogą zostać usunięte tylko wtedy, gdy nie są już używane w tej samej bazie konfiguracyjnej. Podczas usuwania obiektu konfiguracyjnego nie są sprawdzane jego użycia w innych bazach danych, na przykład użycie użytkownika w informacjach o zmianach artykułu w bazie danych OLTP lub użycie kolejki przetwarzania w konfiguracji systemu. Na przykładzie użytkownika łatwo zauważyć, że sprawdzenie wszystkich użyć we wszystkich informacjach o zmianach w bazach danych wszystkich systemów byłoby zarówno technicznie, jak i pod względem wydajności nieuzasadnione. Z tego powodu wszystkie użycia obiektów konfiguracyjnych poza bazą danych konfiguracji są zawsze tolerancyjne względem faktu, że używany obiekt konfiguracyjny może nie być dostępny w czasie wykonywania. Aby usunąć dane, które mogły stać się w ten sposób nieprawidłowe, dostępne są odpowiednie aplikacje i polecenia Toolshell, które można uruchomić w danym systemie. Podczas próby usunięcia obiektu konfiguracyjnego, który nie jest już używany w bazie konfiguracyjnej, wyświetlany jest odpowiedni komunikat.
Ustawienia wpływające na wydajność
Obiekty w bazie konfiguracyjnej systemu definiują topografię systemu oraz ścieżki i ustawienia komunikacyjne aktywnych komponentów systemu. Aktywnymi komponentami systemu są SAS i SOM oraz używane bazy danych. Ich liczba i ustawienia mają decydujący wpływ na:
-
wykorzystanie zasobów systemowych na obsługiwanych maszynach
-
stabilność systemu
- wydajność systemu
Ustawienia JVM
System został opracowany przy użyciu języka programowania Java, dlatego zarządzanie pamięcią główną w czasie działania serwera aplikacji SAS jest w dużej mierze przejmowane przez automatyczne wykonanie garbage collection maszyny wirtualnej Java (JVM). Aby umożliwić wysokowydajne działanie SAS, konieczne są ustawienia parametrów dla wirtualnej maszyny Java, aby wpłynąć na garbage collection. Ustawień należy dokonać w widoku dla typu Serwer aplikacji. Zalecenia dotyczące konfiguracji znajdują się w dokumentacji ustawień JVM.
Ustawienia pamięci podręcznej serwera aplikacji
Współdzielona pamięć podręczna służy do przechowywania instancji Business Objects w pamięci głównej. Wszystkie sesje serwera aplikacji używają wspólnie tej pamięci podręcznej. Zapewnia to, że dane, które są często odczytywane przez różne sesje, muszą być dostępne tylko raz w pamięci głównej. Dostęp do bazy danych jest również zredukowany, co skutkuje zwiększeniem szybkości systemu. Należy tutaj wziąć pod uwagę fizycznie dostępną pamięć i jej alokację w JVM i systemie. Z tego powodu są one również powiązane z ustawieniami JVM. Możesz dokonać ustawień współdzielonej pamięci podręcznej dla wszystkich lub poszczególnych serwerów aplikacji w aplikacji Ustawienia serwera aplikacji.
Połączenia z bazą danych
Połączenie z bazą danych jest wymagane dla każdego dostępu do bazy danych. Im więcej dostępów do bazy danych odbywa się równolegle, tym więcej połączeń z bazą danych jest wymaganych. Liczba równoległych dostępów do bazy danych zależy od obciążenia serwera aplikacji, które zależy od liczby interaktywnych użytkowników, dostępów SOM, innych zdalnych dostępów lub aktywnych zadań przetwarzania. Jeśli liczba połączeń z bazą danych jest zbyt mała, mogą wystąpić błędy podczas pracy. Z drugiej strony, każde połączenie z bazą danych kosztuje zasoby serwera bazy danych. Konieczne jest zatem rozważenie tych dwóch wymagań przy wyborze liczby połączeń z bazą danych. Poniżej wymieniono zmienne mające wpływ i sposób obliczania odpowiedniej liczby połączeń z bazą danych.
Połączenia z bazą danych OLTP
Wszystkie istotne dane biznesowe są przechowywane w bazie danych OLTP i dlatego ta baza danych ma najwięcej dostępów do bazy danych. Liczba połączeń z bazą danych jest zatem najwyższa dla tej bazy danych. Cel serwera aplikacji określa sposób obliczania liczby połączeń z bazą danych dla bazy danych OLTP.
Czynniki wpływające: Użytkownicy interaktywni
Liczba użytkowników interaktywnych, którzy jednocześnie uzyskują dostęp do serwera aplikacji, określa, ile połączeń z bazą danych jest potrzebnych do obsługi tego ruchu. Nawet jeśli żaden użytkownik interaktywny nie łączy się z serwerem aplikacji, system powinien zawsze mieć co najmniej 10 dostępnych połączeń z bazą danych. Jeśli serwer aplikacji jest wykorzystywany interaktywnie, tzn. gdy przynajmniej 10 użytkowników interaktywnych pracuje jednocześnie na jednym serwerze aplikacji, to liczba aktywnych w danym momencie wątków przetwarzających zapytania dialogowe określa wymaganą liczbę połączeń z bazą danych.
Artykuł Właściwości ERP opisuje, jak ograniczyć liczbę wątków dialogowych dla użytkowników interaktywnych za pomocą funkcji com.cisag.sys.gui.jobcontrol.MaximumDialogOnlineThreads. Poniższy wzór do szacowania wymaganych połączeń z bazą danych jest podstawą dla wszystkich kolejnych rozdziałów.
Połączenia z bazą danych OLTP = 10 + (liczba wątków dla użytkowników interaktywnych * 2)
W przypadku serwera aplikacji, na którym zalogowanych jest ponad 10 użytkowników interaktywnych, oznacza to:
10 + (5 × 2) = 20 połączeń z bazą danych
Czynniki wpływające: Kolejki przetwarzania
Oprócz wcześniej obliczonych połączeń z bazą danych, jeżeli na serwerze aplikacji zostały skonfigurowane kolejki przetwarzania, to dla każdego wątku w każdej kolejce przetwarzania potrzebne są dwa dodatkowe połączenia z bazą danych.
Połączenia OLTP z bazą danych += (liczba wątków kolejek przetwarzania × 2)
Czynniki wpływające: Dostępy ODBC i SOM
Oprócz wcześniej obliczonych połączeń z bazą danych, jeżeli na ten serwer aplikacji następuje dostęp przez ODBC, dla każdego jednoczesnego dostępu przez ODBC wymagane są trzy połączenia z bazą danych. Liczba jednoczesnych dostępów przez ODBC wynika z konfiguracji SOM, który uzyskuje dostęp do serwera aplikacji, oraz z tego, ile osób jednocześnie łączy się z tym serwerem aplikacji za pomocą interaktywnego sterownika ODBC.
#Sesje ODBC = #Procesory raportów SOM + #Interaktywni użytkownicy ODBC
OLTP-połączenia z bazą danych += (liczba sesji ODBC * 3)
Czynniki wpływające: Dostępy CORBA
Oprócz wcześniej obliczonych połączeń z bazą danych wymagane są dodatkowe połączenia z bazą danych, jeżeli na tym serwerze aplikacji uruchomiony jest serwer CORBA i klienci CORBA uzyskują do niego dostęp. Dla każdego jednoczesnego dostępu klienta CORBA wymagane są dwa połączenia z bazą danych.
OLTP-połączenia z bazą danych += (liczba sesji CORBA * 2)
Połączenia z innymi bazami danych
Liczba połączeń z bazą danych OLTP jest wykorzystywana jako miara całkowitego obciążenia serwera aplikacji i tym samym określa także liczbę połączeń z innymi bazami danych.
Baza konfiguracyjna jest używana w normalnym trybie pracy tylko sporadycznie:
Połączenia z bazą konfiguracji = 5 + (połączenia z OLTP / 10)
Baza danych repozytorium systemu zawiera wszystkie dane techniczne niezbędne do działania systemu oraz wszystkie dane wspólne dla baz danych OLTP:
Połączenia z repozytorium = 10 + (połączenia z OLTP / 3)
Bazy danych OLAP zawierają dane statystyczne dotyczące baz danych OLTP:
Połączenia z OLAP = 10 + (połączenia z OLTP / 5)
Wątki
Wątki są podziałem procesu systemu operacyjnego wirtualnej maszyny Java, który umożliwia równoległe wykonywanie wątków w tym samym procesie i lepsze wykorzystanie mocy procesora. Liczba wątków, którymi zarządza serwer aplikacji, a tym samym JVM, ma wpływ na zapotrzebowanie na pamięć i wykorzystanie procesora. Każdy wątek – niezależnie od tego, czy jest aktywny, czy nie – wymaga około 0,5 MB pamięci dla swojego stosu i natywnych struktur zarządzania. Każdy aktywny wątek zajmuje również pojemność procesora. Ponieważ procesor może przetwarzać tylko jeden wątek na raz, a przełączanie się między dwoma wątkami powoduje koszty uruchomienia, należy zadbać o to, aby zbyt wiele wątków nie było aktywnych w tym samym czasie. Jeśli liczba aktywnych wątków jest zbyt duża, wykorzystanie procesora:
- wykorzystanie procesora może przekroczyć 70%, a serwer aplikacji znajdzie się w zakresie przeciążenia. Staje się on niestabilny, a czasy odpowiedzi stają się nieproporcjonalnie dłuższe.
- zbyt duże obciążenie przychodzące może być przekazywane do bazy danych, wpływając w ten sposób również na wydajność innych serwerów aplikacji.
Liczba wątków i czasy, w których serwer aplikacji je generuje, zależą od świadczonych przez niego usług.
- wątki dla serwera WWW systemu – każdy serwer aplikacji, który nie jest uruchamiany z parametrem -tool automatycznie uruchamia Web Server systemu. To początkowo tworzy 20 wątków do przetwarzania żądań https://, np. do dostępu do Knowledge Store. Wątki te są zarządzane w puli. Ze względu na właściwości przeglądarki, przetwarzanie w obie strony wymaga od jednego do około 3 wątków, np. do przeładowania ikon. Jeśli otrzymanych zostanie więcej żądań niż dostępnych wątków, tworzone są nowe wątki, które następnie pozostają w puli. Jeśli zbyt wiele loginów jest otwartych do serwera WWW, tworzonych jest zbyt wiele wątków. W takim przypadku należy skonfigurować inny serwer aplikacji i przekierować do niego część żądań.
- wątki dla serwera CORBA – jeśli CORBA Serwer jest uruchomiony na serwerze aplikacji systemu, tworzy on wątek do odbierania żądań CORBA. Każde aktywne logowanie klienta CORBA do CORBA serwer tworzy kolejny wątek do wykonywania aplikacji w tle w System Engine (silnik systemu). Wątek ten pozostaje do momentu wylogowania się klienta CORBA. Więcej informacji na temat CORBA serwer i wykorzystania jego zasobów można znaleźć w artykule Interfejs CORBA.
- wątki dla Serwera księgowania – jeśli serwer księgowania jest uruchomiony na serwerze aplikacji, tworzone są wątki do komunikacji CORBA z klientami księgowymi, dostępu do bazy danych i przetwarzania asynchronicznego. Wątki te są zarządzane przez ORB lub sam serwer księgowy. Z tego powodu dedykowany serwer aplikacji powinien być skonfigurowany do tego celu w systemach wykorzystywanych produkcyjnie.
- wątki dla kolejek przetwarzania – kolejki przetwarzania dzielą i koordynują wykonywanie aplikacji działających w tle. Celem kolejki przetwarzania jest ograniczenie liczby aplikacji działających w tle wykonywanych równolegle, tak aby procesor serwera aplikacji nie był przeciążony. W tym celu kolejka przetwarzania ma ustawienie liczby wątków, które są tworzone i rezerwowane do przetwarzania w tle po uruchomieniu serwera aplikacji. Zalecenia dotyczące tego ustawienia zależą od wykorzystania serwera aplikacji i zostały opisane poniżej.
Wątki do przetwarzania kolejek
W systemie istnieje kilka typów aplikacji działających w tle, które mają różny wpływ na obciążenie i wymagania procesora.
- stałe, pasywne usługi – zadania przetwarzania dla stałych usług pasywnych, takich jak serwer usługi zadań programistycznych, są uruchamiane z typem uruchamiania Przy ponownym uruchomieniu serwera aplikacji i pozostają w nieskończonej pętli po uruchomieniu, w której otrzymują żądania od klientów, np. klientów usługi zadań programistycznych innych systemów. Usługi te zajmują wątek w kolejce przetwarzania i zazwyczaj same tworzą kolejny wątek do komunikacji z klientami. W przypadku usług pasywnych wątki te są prawie zawsze w stanie oczekującym i zajmują pamięć, ale nie zajmują zasobów procesora.
- stałe, aktywne usługi – zadania przetwarzania dla stałych aktywnych usług, takich jak serwer logistyki magazynowej lub reorganizacja historii, są również uruchamiane z typem uruchamiania Przy ponownym uruchomieniu serwera aplikacji i pozostają w nieskończonej pętli po uruchomieniu. W tej pętli usługa automatycznie (okresowo lub wyzwalana przez synchronizację pamięci podręcznej) wykonuje zwykle dość złożone operacje na serwerze aplikacji i w bazie danych. Wątek kolejki przetwarzania zarezerwowany dla usługi jest często w stanie aktywnym, a następnie zajmuje zasoby procesora i bazy danych, a także pamięć. Jeśli zbyt wiele z tych usług jest przypisanych do tego samego serwera aplikacji, może to prowadzić do przeciążenia serwera aplikacji lub bazy danych przy dużym obciążeniu.
- jednorazowe zadania przetwarzania – największa ilość zleceń przetwarzania pod względem liczby to jednorazowe żądania przetwarzania generowane przez użytkowników, takie jak generowanie i wysyłanie potwierdzenia zamówienia. Te zadania przetwarzania są zazwyczaj bardzo zasobochłonne. Z tego powodu kolejka przetwarzania przejmuje przetwarzanie w formie rzeczywistej kolejki. Jeśli wątek w kolejce przetwarzania staje się wolny, wyszukuje następne zadanie przetwarzania przypisane do kolejki przetwarzania ze statusem zwolniony i przejmuje jego wykonanie. Ponieważ procesor może efektywnie przetwarzać tylko bardzo ograniczoną liczbę aktywnych wątków, liczba wątków przeznaczonych do tego typu zadań przetwarzania na serwerze aplikacji nie powinna być większa niż 2-3 na procesor.
Skutkuje to zaleceniem dotyczącym liczby wątków w kolejce przetwarzania:
# Threads = # Permanent services + ( 2.5 * #CPUs )
Monitorowanie wątków i sesji
Aplikacja Panel System zapewnia rozszerzone opcje monitorowania wątków. Oprócz możliwości nawigowania między wątkami i sesjami, można również sprawdzać określone czasy, takie jak czas procesora używany przez wątek lub sesję. W zależności od implementacji JVM, monitorowanie tych czasów i innych informacji nie jest możliwe, nie jest domyślnie aktywne lub może być aktywowane jawnie. Jeśli implementacja JVM obsługuje to w zasadzie, można ją aktywować za pomocą właściwości com.cisag.sys.kernel.ThreadManagerThreadCpuTimeMode lub com.cisag.sys.kernel.ThreadManagerThreadContentionMonitoringMode. Więcej informacji znajduje się w artykule Właściwości ERP.
Aktualny stan monitorowania można sprawdzić na zakładce Wątki dla typu Serwer aplikacji.
Aby ułatwić analizę, na listach, w których przedstawiane są sesje i wątki, zawsze wyświetlane są również całkowite identyfikatory sesji lub wątku. Te identyfikatory umożliwiają identyfikację konkretnej sesji lub wątku w ramach serwera aplikacyjnego systemu ERP.
Całkowity identyfikator wątku jest również zazwyczaj wykorzystywany przez zewnętrzne narzędzia monitorujące, które mogą być używane do nadzorowania środowiska JVM.
Pola, w których przedstawiane są całkowite identyfikatory, posiadają zintegrowaną funkcję nawigacyjną w formie linku, podobnie jak pola dla jednostek biznesowych (Business Entity). Wybranie identyfikatora sesji przenosi użytkownika do zakładki Sesje dla typu Serwer aplikacyjny, gdzie domyślnie wyświetlana jest wybrana sesja oraz jej aktywne wątki. Wybranie identyfikatora wątku przenosi użytkownika do zakładki Sesje dla typu Serwer aplikacyjny, gdzie domyślnie wyświetlany jest wybrany wątek oraz jego stacktrace (ślad stosu).
Umożliwia to na przykład wykonanie analizy:
- która sekcja programu zużywa obecnie większość czasu procesora:
- wybrać jako typ System
- przejść na zakładkę Sesje
- wybrać sortowanie po kolumnie Czas CPU
- zidentyfikować sesję o największym bezwzględnym zapotrzebowaniu na czas procesora lub o największym wzroście czasu procesora na aktualizację.
- wybrać identyfikator tej sesji
- system przełączy się na typ Serwer aplikacji zakładka Sesje i wyświetli aktywne wątki dla tej sesji.
- należy sprawdzić stan wątków i kliknąć w jego identyfikator.
- system przełączy się na zakładkę Wątki i wyświetli stacktrace (ślad stosu) wybranego wątku.
- w której lokalizacji programu znajduje się połączenie z bazą danych
- przejść do typu Serwer aplikacji
- przejść na zakładkę Połączenia z bazą danych
- zidentyfikować odpowiednie aktywne połączenie z bazą danych na podstawie stanu połączenia lub właściwości połączenia z bazą danych.
- wybrać identyfikator wątku, który jako ostatni zażądał połączenia z bazą danych.
- system przełączy się na zakładkę Wątki i wyświetli (stacktrace) ślad stosu wybranego wątku
Informacje o wydajności
System posiada rozbudowane opcje rejestrowania, podsumowywania i oceny informacji o wydajności. Podstawowe zasady i procedury można znaleźć w dokumencie Rejestracja i analiza informacji o wydajności. Oprócz opisanych tam opcji wyszukiwania informacji o wydajności, np. w formie raportów, aplikacja Panel System oferuje również opcję wyszukiwania trwałych i przejściowych danych o wydajności systemu z innych systemów.
Grupa docelowa
- Administratorzy systemu
Opis aplikacji
Aplikacja składa się z nagłówka i obszaru roboczego. W nagłówku wybierany jest typ obiektu oraz obiekt, który ma zostać wyświetlony lub edytowany w aplikacji. Odpowiednie ustawienia obiektu są wyświetlane kontekstowo w obszarze roboczym.
Wzorce zapytań i historia
Aplikacja Panel system zawiera, oprócz zakładek do rejestrowania i edytowania obiektów konfiguracyjnych dla wszystkich aktywnych komponentów, takich jak np. serwer aplikacji, również dodatkowe zakładki z polami zapytań. Oprócz aktualnie otwartego obiektu konfiguracyjnego zapisywane są także aktywna zakładka, zawartość pól zapytań, bieżące sortowanie oraz stan przycisków przełączających – zarówno w historii, jak i we wzorcach zapytań. Umożliwia to z jednej strony zapisywanie złożonych zapytań, np. w przypadku informacji o wydajności, a z drugiej strony nawigację wewnątrz aplikacji Panel System za pomocą przycisków [Dalej] i [Wstecz] dostępnych na zakładce Sesje lub Wątki.
Nagłówek
Nagłówek zawiera pola, które jednoznacznie identyfikują obiekt wyświetlany w aplikacji Panel System. Dostępne pola:
Typ – pozwala na wskazanie typu obiektu, który ma być wyświetlany w aplikacji. Widok w obszarze roboczym aplikacji zmieni się odpowiednio w zależności od wskazanego typu.
Nazwa – nazwa obiektu. Jeśli obiekt należy do typu:
- system, bazy danych (z wyjątkiem baz konfiguracyjnej), serwer aplikacji, kolejka przetwarzania, połączenie z ERP System Output Manager, obszary robocze – zapis jest następujący: Nazwa systemu, kropka, nazwa obiektu. Wprowadzenie nazwy bez kropki dla jednego z tych typów obiektów otworzy pomoc wprowadzania, a wyszukiwanie zostanie przeprowadzone we wszystkich systemach.
- grupa deweloperska, grupa systemów, moduł – zapis jest następujący: Nazwa grupy deweloperskiej, kropka, nazwa obiektu. Dotyczy to grup systemów i modułów.
W przypadku obiektów, które mają zostać otwarte lub nowo utworzone, należy wprowadzić nazwę obiektu. Nazwa jest wyświetlana dla otwartych obiektów. Nazwy nie można zmienić po jej pierwszym zapisaniu.
Oznaczenie – opis otwartego obiektu. Unikalne oznaczenia ułatwiają wyszukanie obiektu. Nazwa jest dowolna i może być niejednoznaczna, tzn. kilka obiektów może mieć tę samą nazwę. Zaleca się przypisywanie różnych oznaczeń w każdym przypadku. Oznaczenie można wprowadzić w kilku językach. Dla typu Licencja nie można wprowadzić ani zmienić żadnego oznaczenia.
Obszar roboczy
Obszar roboczy oferuje różne widoki w zależności od typu otwartego obiektu. Można zmienić widok, wybierając inny typ obiektu w nagłówku aplikacji.
Dla każdego typu obiektu dostępna jest zakładka Edytor, w której można wprowadzać poszczególne ustawienia. Dla niektórych typów obiektów dostępne są dodatkowe pozakładki. Służą one do wyszukiwania wartości w ramach procesu monitorowania. Otwarcie zakładek monitorowania może być czasochłonne, jeśli serwer komunikatów systemu lub wybrany serwer aplikacji nie jest uruchomiony lub jeśli jeden z aktywnych serwerów aplikacji systemu jest w trybie debugowania i dlatego nie odpowiada.
W przeciwieństwie do wszystkich innych aplikacji w systemie, klucz techniczny (GUID) można również jawnie określić w Panelu System i za pomocą powiązanych poleceń Toolshell podczas tworzenia nowego obiektu. Zazwyczaj nie jest to konieczne i może być wykorzystane na przykład do tworzenia dokładnych kopii obiektów konfiguracyjnych w innej bazie konfiguracyjnej. Na przykład można utworzyć kopię systemu z innej bazy konfiguracyjnej w celu monitorowania go za pomocą funkcji monitorowania.
Poszczególne widoki obszaru roboczego są opisane dla każdego typu w artykułach:
- Baza danych
- Grupa deweloperska
- Grupa systemów
- Grupa użytkowników
- Kolejka przetwarzania
- Licencja
- Moduł
- Obszar roboczy
- Oznaczenie bazy danych
- Połączenie z ERP System Output Manager
- Serwer aplikacji
- System
- Urząd certyfikacji
- Użytkownik
Konfiguracja
Dla aplikacji Panel System w aplikacji Konfiguracja nie wykonuje się dodatkowej konfiguracji.
Uprawnienia
Następujące jednostki biznesowe i grupy jednostek biznesowych są istotne dla ustawień autoryzacji dla aplikacji Panel System dla:
- serwera aplikacji:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.SVM
- Grupa jednostek biznesowych: com.cisag.sys.configuration.SystemObjects
- obszarów roboczych:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.WorkSpace
- Grupa jednostek biznesowych: com.cisag.sys.configuration.SystemObjects
- użytkowników:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.User
- Grupa jednostek biznesowych: com.cisag.sys.configuration.UserObjects
- grup użytkowników:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.UserGroup
- Grupa jednostek biznesowych: com.cisag.sys.configuration.UserObjects
- baz danych:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.Database
- Grupa jednostek biznesowych: com.cisag.sys.configuration.SystemObjects
- oznaczeń baz danych:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.ManagingSystem
- Ta jednostka biznesowa nie jest przypisana do grupy jednostek biznesowych.
- grup deweloperskich:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.DevelopmentGroup
- Ta jednostka biznesowa nie jest przypisana do grupy jednostek biznesowych.
- licencji:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.Licence
- Ta jednostka biznesowa nie jest przypisana do grupy jednostek biznesowych.
- modułów:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.Module
- Ta jednostka biznesowa nie jest przypisana do grupy jednostek biznesowych.
- połączeń z ERP System Output Manager:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.OutQueue
- Grupa jednostek biznesowych: com.cisag.sys.configuration.SystemObjects
- systemów:
- Jednostka biznesowa com.cisag.sys.configuration.obj.System
- Grupa jednostek biznesowych: com.cisag.sys.configuration.SystemObjects
- grup systemów:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.SystemGroup
- Ta jednostka biznesowa nie jest przypisana do grupy jednostek biznesowych.
- kolejek przetwarzania:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.JobQueue
- Grupa jednostek biznesowych: com.cisag.sys.configuration.SystemObjects
- urzędów certyfikacji:
- Jednostka biznesowa: com.cisag.sys.configuration.obj.CertificateAuthority
- Grupa jednostek biznesowych: com.cisag.sys.configuration.UserObjects
Specjalne uprawnienia i prawa dostępu nie są wymagane dla tej aplikacji.
Uprawnienia mogą zostać przypisane za pomocą ról uprawnień jak również poprzez przyporządkowanie organizacji. Szczegółowe informacje można znaleźć w artykule Uprawnienia.