Category: Administracja

OpenEdge Command Center – Server cz. 1

O nowym narzędziu OpenEdge Command Center (OECC) mówi się coraz częściej, także na tym blogu.
Brak niestety dobrej instrukcji instalacji – OECC korzysta z bazy MongoDB, która nie należy do Progressa i trzeba korzystać z zewnętrznych instrukcji.
Ja pokażę jak zainstalować OECC 1.2 na przykładzie darmowej i lokalnej licencji MongoDB Community Server.

Pobieram ze stron mongodb.com wersję 4.2 na Windows (OECC 1.2 nie współpracuje z MongoDB 5.x).
Uruchamiam instalator zostawiając ustawienia domyślne. W kolejnym kroku odznaczam instalację dodatku Compass (można w razie czego doinstalować go później).

W usługach, możemy zlokalizować teraz nowy serwis MongoDB, czyli uruchomiony demon mongod.exe.

Następnym krokiem jest uruchomienie wiersza poleceń CMD jako Administrator i przejście do katalogu gdzie zostały zainstalowane binaria:
C:\Program Files\MongoDB\Server\4.2\bin
Tutaj uruchamiamy shell MongoDB poleceniem mongo (alternatywnie możemy uruchomić plik mongo.exe z Exploratora jako Administrator).
Podajemy komendę show dbs, żeby sprawdzić jakie testowe bazy danych zostały zainstalowane.

Będziemy korzystać z bazy admin dlatego podajemy następną komendę use admin.
Teraz dodamy użytkownika o uprawnieniach admina o nazwie np. “MongoAdmin” i haśle “MongoPass” (OECC wymaga wprawdzie zwykłego użytkownika z prawem read/write, ale co szkodzi zaszaleć :-))

db.createUser({
user:"MongoAdmin",
pwd:"MongoPass",
roles:[{role:"userAdminAnyDatabase",db:"admin"}]
})

Efekt widać poniżej, użytkownik został prawidłowo dodany (wielokropek jest dodawany automatycznie).

Teraz uruchamiamy instalator OECC 1.2, pozostawiając w kilku pierwszych krokach ustawienia domyślne (ewentualnie podając własne katalogi do instalacji, itd.).
Dochodzimy do Database Configuration wstawiając dane logowania nowo utworzonego użytkownika MongoDB.

W kroku First User Setup należy stworzyć dane logowania do panelu Servera OECC…

Sprawdzamy czy wszystko się zgadza i czekamy na zakończenie procesu instalacji.

Na koniec pojawia się ekran logowania – wpisujemy wymyślone dane pierwszego użytkownika.

Voila! Możemy przejść teraz do konfiguracji kont innych użytkowników oraz, przede wszystkim, do utworzenia unikalnych kluczy dla procesów Agentów, ale o tym napiszę następnym razem.

Administracja

OpenEdge 12.6

Wersja OpenEdge 12.6 pojawiła się z końcem września br. jako Innovation Release (termin który zastąpił Non-LTS Release) Podczas instalacji trzeba jak zwykle podać ścieżkę do JDK – w tej wersji jest to JDK 17.
Zaczynamy od nowości związanych z bazami danych.

PROUTIL IDXCOMPACT – to popularne narzędzie poprawiające wydajność indexów także dla bazy online. Komenda ta została wzbogacona o opcję UNUSEDBLOCKS, użyteczną szczególnie po operacji usuwania dużej liczby rekordów. Powoduje ona skanowanie łańcucha “delete” i czyszczenia bloków indexowych w przypadku indexów unikalnych. Stosowanie dla indexów nie-unikalnych nie spowoduje ostrzeżenia ani błędu na konsoli.

Z tą opcję nie można podać stopnia kompresji, gdyż spowoduje to ostrzeżenie i niewykonanie polecenia.

Obcięcie obszaru przechowywania danych online.
Do tej pory obcięcie obszaru (PROUTIL TRUNCATE AREA) można było wykonać jedynie dla zamkniętej bazy, po obcięciu pliku BI i wyłączeniu zapisu AI.
Obecnie operację można przeprowadzić dla bazy włączonej. Obcięcie obszaru stosuje się po usunięciu dużej ilości danych, np. przeniesieniu danych historycznych do innego obszaru. Obcięcie obszaru można wykonać tylko gdy w obszarze nie znajdują się żadne obiekty (tablice, indexy, LOBy).

Wprowadzono obsługę dużych plików dla licencji Workgroup, co ma zlikwidować problem gdy baza działająca w środowisku produkcyjnym Enterprise jest skopiowana do testowania i rozwoju, co często przeprowadza się w niższej licencji Workgroup. Od OE 12.6 znacznik obsługi dużych plików jest włączany automatycznie dla obu typów licencji.

Usprawniony został mechanizm działania narzędzia do naprawy indexów PROUTIL IDXFIX. Dla opcji 1 i 8 skanowane są tylko te bloki obszaru typu II, które należą do podanych tabel i indexów. Usprawnienie nie działa dla bloków obszaru I. Poprawiono także mechanizm kasowania rekordów w tym samym narzędziu.

Przejdźmy teraz do wybranych nowości deweloperskich.
Identyfikacja Memory Leaks. Programiści mogą teraz używać klasy OpenEdge.Core.Util.LeakCheck w bibliotece corelib do przetwarzania logów i identyfikacji wycieków pamięci. Dokładne informacje o tej klasie można znaleźć w dokumentacji.
Praktyczny opis identyfikacji wycieków pamięci znajduje się tutaj.

Środowisko Progress Developer Studio dla OpenEdge zostało zaktualizowane i korzysta z wersji Eclipse 4.23.

Został zoptymalizowany tutaj proces inicjalizacji widoczny szczególnie w przypadku złożonych i rozbudowanych workspace’ów.

Warto dodać, że w tym samym czasie pojawiła się nowa wersja OE Command Center 1.2, w której administratorzy systemu mogą monitorować metryki wydajności PASOE oraz baz danych OE. Metryki wydajności są zbierane przy użyciu standardu OpenTelemetry (OTel).
Zarządzanie PASOE zostało wzbogacone o funkcję klonowania instancji.
Ponadto, został zautomatyzowany proces instalacji w systemie Windows, zamiast ręcznej edycji skryptów uruchamiany jest teraz instalator.
O wielu innych nowościach możecie przeczytać w dokumentacji. Zapraszam do dyskusji na polskiej grupie PUG.

Administracja, Development, Info ogólne ,

Swagger UI i PASOE

Swagger UI jest narzędziem które umożliwia wizualizację zasobów API bez konieczności implementacji dodatkowych zewnętrznych aplikacji.

Swagger składa się z plików HTML, JavaScript i CSS, które dynamicznie generują dokumentację na podstawie interfejsu API.
Jest dostępny w PASOE począwszy od wersji OE 12.0 (domyślnie wyłączony). Od wersji OE 12.2 jest domyślnie włączony dla instancji deweloperskich – należy pamiętać aby nigdy nie włączać go w środowiskach produkcyjnych.

Dostęp do Swaggera jest z poziomu oemanagera (http://host:port/oemanager/), ale jeśli dostęp jest zabroniony, to wchodzimy z poziomu managera, czyli http://host:port/manager/, np. http://localhost:8813/manager.


Tutaj klikając oemanager dostajemy ekran dokumentacji Swaggera.


Ekran składa się z sekcji np. dla każdej warstwy transportowej,  Agent Manager, Session Manager i OEABL ManagerService.
Przechodzimy do tej drugiej i klikamy na GET /applications, następnie Try it out i Execute.


Dostajemy listę wszystkich aplikacji ABL dla instancji PASOE wraz z parametrami w postaci JSON. Listę tę można pobrać jako plik tekstowy.

Jeśli w OEABL ManagerService kliknę GET /applications/{AppName}/webapps i wpiszę nazwę aplikacji ABL, dostanę w podobnej postaci listę wszystkich aplikacji webowych dla tejże aplikacji.

Aby pobrać listę web servisów dla danej aplikacji webowej wybieram GET/applications/{AppName}/webapps/{WebAppName} i podaję nazwę aplikacji ABL i web serwisu.

Jak widać na obrazkach czasowniki GET nie są jedynymi do użycia. Można np. zaktualizować listę poprzez czasownik POST czy zerować metryki (DELETE).
Opcji jest bardzo wiele.

Administracja, Development ,

PASOE HealthScanner

OpenEdge HealthScanner został stworzony po to, aby ostrzegać administratorów o potencjalnych problemach z instancją PASOE, dzięki czemu serwer może zostać wyłączony z eksploatacji zanim wystąpi awaria.Usługa nie jest przeznaczona do badania ani rozwiązywania problemu lecz do oznaczenia serwera, który znajduje się poniżej pewnego, zdefiniowanego progu.

OpenEdge HealthScanner jest przeznaczony do użytku z instancjami PASOE w środowisku produkcyjnym chociaż można go testować również w środowisku deweloperskim. HealthScanner jest serwisem Tomcata z własnym portem HTTP, pulą wątków i konfiguracją.

Tradycyjnie będę tutaj korzystać z polecenia pasman (zamiast tcman) i tak polecenie:
pasman feature -I mypasoe wyświetli funkcje instancji PASOE (tutaj: mypasoe) i ich stan. Widać, że funkcja HealthCheck jest wyłączona.

Włączenie funkcji można wykonać przez komendę tcman feature (pasman feature), a następnie sprawdzić tę samą komendą czy polecenie przyniosło zamierzony efekt. Obie komendy widać poniżej.

Innym sposobem jest skorzystanie z interfejsu OEM/OEE.

Samo włączenie funkcji jednak nie wystarczy. Potrzebne jest także włączenie tzw. data collectora, czyli procesu zbierającego dane. Komendy włączające proces i sprawdzające jego status są widoczne poniżej.

Proces ten pobiera dane z różnych wirtualnych “sond” takich jak: PASOE HealthScanner, JVM Health, Tomcat Health, Transport Health i wielu innych. Każda próbka ma określona wagę, wykorzystywaną do obliczenia ogólnego współczynnika “zdrowia” PASOE.

Wszystkie sondy i ich wagi możemy podejrzeć w pliku: [instancja]/conf/health.config.

Jeśli przyjrzymy się np. sekcji Transport Health, zauważymy, że są tu trzy warstwy transportowe APSV, WEB i REST. Udział każdej wynosi 0.33333. Jeśli w naszym systemie aplikacyjnym nie ma np. warstwy WEB, to możemy ustawić udział w niej na 0, a w pozostałych dwóch na 0.5.

Warto przeczytać także informacje dot. wyliczeń współczynników zawarte w pliku [instancja]/conf/health.config.README.

Usługa działa domyślnie na porcie 8899 i generuje kilka zestawień w formacie JSON np:
http://localhost:8899/health?view=summary

zestawienie szczegółowe:
http://localhost:8899/health?view=details

czy bardzo ciekawe zestawienie przedstawiające konfigurację sond i wyliczeń:
http://localhost:8899/health?view=config

Korzystanie z PASOE HealthScanner wymaga pewnej wprawy i dlatego nie jest to usługa dostępna od razu po instalacji, a dopiero po włączeniu jej przez administratora, ale warto ją przetestować i poznać bliżej.

Administracja ,

OpenEdge 12.5

OpenEdge 12.5, to kolejna wersja z serii non-LTS Release – skierowana do tych, którzy czekają na wszelkie nowinki techniczne. Przedstawię tutaj pokrótce niektóre z nich.

Niedawno pisałem o nowym darmowym produkcie OpenEdge Command Center. Z wersją 12.5 możemy pobrać OECC w wersji 1.1, dzięki której możemy uzyskać informacje nie tylko o stanie poszczególnych instancji PASOE, ale także o ich aplikacjach. Po lewej stronie na głównym panelu widać nową ikonę (podświetlona na niebiesko) – po kliknięciu w nią znajdziemy się w widoku ABL Applications.

Składa się on z kilku okien. W pierwszym od lewej, widać listę instancji. Dalej, dla wybranej instancji, widać szczegółowe informacje nt aplikacji.
Musze przyznać, że śledzę rozwój tego produktu z dużym zaciekawieniem. Zyska on bardzo na wartości gdy pojawią się możliwości monitorowania baz danych.

W zarządzaniu PASOE pojawiło się nowe rozszerzenie dla komendy TCMAN i PASMAN – OESERVER. Jest ono zalecanym narzędziem do uruchamiania i zatrzymywania PASOE. Obsługuje dodatkowe parametry, aby zamknąć powiązane sesje klienta APSV i zebrać bardziej szczegółowe informacje o instancji. W celu zapewnienia kompatybilności OESERVER obsługuje istniejące parametry PASOESTART. Poniżej widać kilka parametrów z długiej listy komendy OESERVER.

Przykład działania komendy pasman oeserver -restart oraz –status (status wyświetla więcej informacji niż query). Na końcu podawane są informacje nt agentów i sesji.

Pełną listę parametrów znajdziecie tutaj.

Integracja OpenEdge z Apache Kafka – Kafka to otwarta, rozproszona platforma do strumieniowego przesyłania wydarzeń (event-streaming), szeroko stosowana w wielu branżach i organizacjach. Zapewnia przechwytywanie danych w czasie zbliżonym do rzeczywistego ze źródeł, takich jak bazy danych, aplikacje, czujniki, urządzenia mobilne i usługi w chmurze.

OpenEdge udostępnia nowe OpenEdge.Messaging API do wysyłania wiadomości do klastra Kafki poprzez Kafka producer i odbierania wiadomości z tego klastra przez Kafka consumer.

Progress Developer Studio dla OpenEdge obsługuje teraz inteligentną kompilację. Kiedy programista ABL wprowadza zmiany w pliku i go kompiluje, Developer Studio automatycznie kompiluje także wszystkie inne pliki, których mogą dotyczyć te zmiany. Dzięki temu identyfikowane są wszystkie błędy kompilacji wprowadzone w wyniku zmian w kodzie.

Na zakończenie chciałbym wspomnieć o istotnym ułatwieniu w procesie odtwarzaniu bazy po awarii z backupu i plików AI. Administratorzy mogli mieć problem w szybkim określeniu kolejności extentów. W wersji OE 12.5, wprowadzono nowe narzędzie do komendy rfutil,  AIMAGE SUMMARY, które uruchamia szybkie skanowanie informacji potrzebnych do zidentyfikowania plików AI.

Jak zwykle, po więcej nowości odsyłam do dokumentacji i internetu.

Administracja, Info ogólne

OpenEdge Command Center

Czytelnicy niniejszego bloga znają podstawowy i sztandarowy produkt służący do monitorowania systemów – OpenEdge Management (OEM) oraz jego uboższą wersję OpenEdge Explorer (OEE).
Produkt ten został wprowadzony po raz pierwszy wiele lat temu pod nazwą Fathom Management w wersji V9. Wciąż jest rozwijany i świetnie spisuje się w małych i średnich sieciach.

Tym razem chciałbym przybliżyć nowy produkt, OpenEdge Command Center (OECC) służący do zarządzanie wieloma zasobami i instalacjami OpenEdge na różnych komputerach i różnych wersjach OpenEdge.

Pierwsza wersja OpenEdge Command Center została stworzona z myślą o efektywnym zarządzaniu PASOE oraz, w przyszłości, bazami danych. Aktualna wersja 1.0 wspiera OE 12.2.5 i wyższe. Nie ma wsparcia wstecz.
OECC jest darmowe dla posiadaczy licencji OE, podobnie jak OEE i ma na celu uproszczenie ogólnego zarządzania platformą OpenEdge.
Serwer OpenEdge Command Center jest obsługiwany na następujących platformach:

  • Ubuntu 18.04 LTS
  • Oracle Linux 8
  • Red Hat Enterprise Linux 8
  • SUSE Linux Enterprise Server 15
  • CentOS Linux 8
  • Windows 64

Można także uruchomić OpenEdge Command Center Server na 64-bitowym serwerze Linux z obsługą chmury, który jest skonfigurowany z MongoDB ATLAS.
Jednym z celów OECC jest zastąpienie produktu OEE, ze względu na niektóre problemy, które były zgłaszane przez użytkowników jak np. przestarzały interfejs, “ciężki” proces zdalnego AdminServera wymagający otwarcia 4 portów czy to, że API muszą być wyeksponowane w standardzie OpenAPI.

Serwer OECC można wdrożyć jako pojedynczy węzeł lub, dla zapewnienia wysokiej dostępności, jako klaster wielowęzłowy. Aby zapewnić wysoką dostępność, serwer współpracuje ze wszystkimi load balancerami obsługującymi transporty HTTP/HTTPS oraz protokoły websocket, takie jak Nginx, Serwer HTTP Apache, AWS, ELB/ALB itp.
OECC do przechowywania danych korzysta z bazy danych MongoDB oraz magazynu plików (patrz rysunek).


MongoDB to nierelacyjna baza, która przechowuje dane w postaci dokumentów w formacie podobnym do JSON. Są w niej zawarte wszystkie szczegóły dotyczące wykrytych komponentów OE takich jak PASOE (w przyszłości także baz danych OE) oraz ustawienia konfiguracyjne OECC. Instalacja bazy MongoDB jest wymagana przed instalacją serwera OECC, który wspiera następujące wersje (www.mongodb.com):

  • MongoDB Community Server
  • MongoDB Atlas running on AWS, Azure, and Google Cloud Platform (GCP)
  • MongoDB Enterprise Edition

Oprócz bazy część danych jest przechowywana w postaci repozytorium plików. Mieszczą się tu informacje o połączeniu z bazą danych, konfiguracji bezpieczeństwa i logowania itp.
O instalację MongoDB (podobnie jak i Java JDK) klient musi zadbać we własnym zakresie.

Ażeby dane były pobierane z różnych środowisk, na każdej maszynie trzeba zainstalować agenta OECC. Jest to lekki proces instalujący się razem z OE. Niezależnie od tego, czy masz jedną czy więcej instalacji OpenEdge na maszynie wystarczy zainstalować jednego agenta (OE 12.2.5 i wyżej).

Proces agenta działa autonomicznie; trzeba tylko upewnić się że jest poprawnie uruchomiony. Dla bezpiecznego połączenia z serwerem OECC trzeba z konsoli wygenerować unikalny klucz dla każdego agenta.

Cały proces konfiguracji i monitorowania przeprowadzamy z konsoli dostępnej z przeglądarek internetowych (HTTP/HTTPS), patrz przykład poniżej.

OpenEdge Command Center to bardzo ciekawy produkt, który obecnie monitoruje tylko procesy PASOE, ale w najbliższym czasie ma być rozszerzony także o procesy baz danych. Warto jest go zainstalować i przetestować.

Administracja, Info ogólne , , ,

Migracja do PASOE

O PASOE sporo pisałem. Wiadomo, w OE12 nie ma już klasycznego AppServera i trzeba podjąć decyzję o migracji aplikacji, a przed decyzją dobrze jest poznać za i przeciw nowego produktu.
Teraz jednak powracam do tematu samej migracji w szerszym kontekście (pisałem o podstawach migracji w 2017).

Korzyść z nowego AppServera widać już podczas instalacji: możemy wybrać czy instalowana instancja będzie deweloperska czy produkcyjna. Dla tej ostatniej dodajemy w komendzie parametr -Z prod i mamy instalowanie instancji z implementacją silniejszych zabezpieczeń niż dla wersji deweloperskiej. O samych zabezpieczeniach nie będę pisał ponieważ temu tematowi poświęciłem tutaj kilka wpisów.

Następnym krokiem jest migracja ustawień, czyli pliku z właściwościami. Istniejący plik ubroker.properties musi zostać przekonwertowany na nowy format używany przez PASOE openedge.properties.
Kolejność działania jest następująca: najpierw uruchamiamy polecenie paspropconv, które konwertuje właściwości z pliku ubroker.properties do tymczasowego pliku ubrokername.oemerge. Plik ten można dopasować do naszych potrzeb i włączyć ustawienia naszej nowej instancji do pliku openedge.properties.

Komendę paspropconv uruchamiamy w podkatalogu conf dla instancji PASOE z przykładowymi parametrami, które są wymagane. Podwójne myślniki przed nazwą parametru wynikają stąd, że skrypt jest napisany w języku Perl.

--ubrokerPropsFile C:\classicapp\ubroker.properties 
--ubrokerName UBroker.AS.asbroker1 
--pasoeAppName myprod

Pierwszy parametr określa ścieżkę do pliku z właściwościami dla klasycznego AppServera, drugi jest nazwą instancji tego AppServera, wreszcie trzeci określa nazwę nowej instancji PASOE.
Po uruchomieniu komendy w katalogu conf zostały utworzone poniższe pliki:

Dla nas istotny jest plik .oemerge. Niemal całą jego zawartość stanowi przewodnik po migracji, zawierający sekcje np:
Tryby pracy (operating modes) – zawiera porady dotyczące migracji istniejących trybów pracy (state-reset, state-aware, stateless, statefree) na tryby pracy w PASOE. Omówione są proste instrukcje, realizujące ten etap migracji, które wiążą i zwalniają bieżącą sesję ABL (były omawiane na blogu kilka lat temu).
Procedury zdarzeniowe (event procedures) – omawiane są stare i nowe procedury (agentStartupProc, sessionStartupProcParam) związane z inicjalizacją agenta wielo-sesyjnego oraz każdej sesji ABL.

# paspropconv  v1.15 (MSWin32)
# 
# Input arguments:
# 
#   ubrokerPropsFile    = C:\classicapp\ubroker.properties
#   ubrokerMergeFile    = 
#   ubrokerName         = UBroker.AS.asbroker1
#   pasoeAppName        = myprod
#   pasoeWebAppName     = ROOT
#   pasoeMergeFile      = myprod.asbroker1.oemerge
#   pasoeSetEnvFile     = asbroker1_setenv
#   convNotesDBFile     = C:\OPENED~1\bin\paspropconv_notesdb.en
#   logFile             = paspropconv.log
#   loggingLevel        = 2
# 
# Operating Modes
# ---------------
# 
# The classic AppServer supports 4 operating modes:
#   state-reset
#   state-aware
#   stateless
#   statefree
# 
# In the classic AppServer, the operating mode is specified when the AppServer
# is deployed.  Consequently, all ABL sessions supported by the AppServer
# employ the same operating mode.
# 
# In PASOE, the operating mode of a session is not specified during deployment.
# As such, a single PAS server can support concurrent ABL sessions, each
# emulating the behavior of different classic operating modes.
# 
# To support the different types of operating mode behavior
# provided in the various classic modes, some ABL code modifications
# may be required.  It is recommended that these changes are made in 
# the PASOE sessionConnectProc () and
# sessionDisconnProc () event procedures.
.......
[AppServer.Agent.myprod]
    PROPATH=${CATALINA_BASE}/openedge,${CATALINA_BASE}/webapps/ROOT/WEB-INF/openedge,.....
    agentMaxPort=2202
    agentMinPort=2002
    keyAlias=
    keyAliasPasswd=
    keyStorePasswd=
    keyStorePath=${DLC}/keys/
    noSessionCache=0
    numInitialSessions=5
    sessionActivateProc=
    sessionConnectProc=
    sessionDeactivateProc=
    sessionDisconnProc=
    sessionExecutionTimeLimit=0
    sessionShutdownProc=
    sessionStartupProc=
    sessionStartupProcParam=
    sessionTimeout=180
    sslAlgorithms=
    sslEnable=0
.......

Ostatnia sekcja nie jest komentarzem – zawiera zestaw właściwości, które powinny zostać scalone z plikiem openge.properties dla nowej instancji serwera.

Dalsze porady dotyczą ręcznej konfiguracji wynikającej z różnic w ścieżkach dostępu, architektury systemu operacyjnego, zmiennych środowiskowych, połączeń z bazami danych itd.
Dla pełniejszych informacji warto pobrać i przeczytać dokument: Quick Start: Moving Your Classic AppServer Applications to the Progress® Application Server for OpenEdge®.

Administracja, Development , ,

OpenEdge 12.4

Najnowsza wersja OE 12.4 pojawiła się jako non-LTS Release. Ponieważ dostaję pytania w tej sprawie, kilka słów wyjaśnienia.
Wersja non-LTS (Non-Long Term Supported), jak sama nazwa wskazuje, jest bez długotrwałego wsparcia technicznego i jest przeznaczona dla tych, którzy wymagają najnowszych rozwiązań i poprawek. Wersja ta zapewnia również klientom możliwość używania i testowania funkcji, które pojawią się w nadchodzących wersjach obsługiwanych długoterminowo.
Wersja LTS (Long Term Supported) umożliwia kilkuletnie wsparcie techniczne i większą stabilizację. Dla przykładu: ostatnia wersja LTS to 12.2 z datą wygaśnięcia 10.2028, a dla wersji OE 11 to 11.7 (04.2025). OE 12.1, która jest non-LTS wygasa w 09.2022, więc za ok. rok (więcej informacji znajdziecie tutaj). Warto pamiętać o tym planując migrację do konkretnej wersji.

Zaczynamy, podobnie jak dla OE 12.3, od nowinek w definiowaniu zmiennych.
Od OE 12.4 dopuszczalne są poniższe konstrukcje, wraz z działaniami:

VAR INT a = 50, b = 20, x = a + b , y = a - b, z = x - y.

Poniższy przykład pokazuje definiowanie i inicjowanie zmiennych za pomocą funkcji standardowej, funkcji zdefiniowanej przez użytkownika, oraz metody:

VAR DATETIME dtm = DATETIME(TODAY,MTIME).
VAR INTEGER x = myFunction().
VAR INTEGER y = classMethod(output v).

Tutaj, z kolei, widzimy przykład definiowania określonych i nieokreślonych elementów macierzy i inicjowanie ich za pomocą wyrażenia:

VAR INT[2] w = [123, a + b].
VAR INT[3] x = [funct( ), 123, a + b].
VAR INT[ ] y = [123, a + b].
VAR INT[ ] z = [funct( ), 123, a + b].

Wprowadzono nową instrukcję języka ABL AGGREGATE do obliczania zagregowanych wartości w bazie danych
po stronie serwera. Wcześniej obliczenia te były wykonywane po stronie klienta przy użyciu instrukcji ACCUMULATE
i funkcji ACCUM.
Teraz można użyć pojedynczej instrukcji AGGREGATE dla COUNT, TOTAL i AVERAGE. Instrukcja AGGREGATE upraszcza kod i poprawia wydajność ponieważ obliczenia są wykonywane po stronie serwera bazy danych. Patrz poniższy przykład:

VAR DECIMAL avgBalance.
AGGREGATE avgBalance = AVERAGE(Balance) FOR Customer
WHERE Country EQ 'USA' AND City EQ 'Chicago'.
MESSAGE "Average balance: " avgBalance
VIEW-AS ALERT-BOX.

Ważną nowością dla administratorów jest wprowadzenie zastrzeżonego trybu bazy danych (restricted database access).
Pamiętacie zapewne, że możliwe jest włączenie w bazie trybu quiet point. Wstrzymuje on aktywne transakcje aż do momentu jego wyłączenia. Są jednak sytuacje gdy trzeba wykonać operacje administracyjne nie martwiąc się o niekompletne transakcje czy nowe logowania w trakcie pracy np: kasowanie dużej ilości niepotrzebnych danych, synchronizacja z innym źródłem, zrzut i ładowanie rekordów itd.
Tryb pracy restricted online umożliwia wykonywanie takich zadań z wykorzystaniem puli buforów czy wspomagających procesów asynchronicznych.

proutil [nazwa-bazy] -C dbrestrict dbadmin enable disconntimeout 500
Powyższa komenda umożliwia dostęp do bazy jedynie dla procesów administracyjnych (database utilities). Ustawiono opcjonalny parametr odłączenia użytkowników na 500 s.
Akcja status pozwala na podgląd czy dany tryb został ustawiony. Patrz na poniższy zrzut ekranu:

Tryb dbadmin nie jest jedynym w OE 12.4. Są jeszcze tryby:
datamove – ograniczenie wszystkich operacji z wyjątkiem PROUTIL DATAMOVE
partitioncopy – ograniczenie wszystkich operacji z wyjątkiem PROUTIL PARTITIONMANAGE COPY
rollforward – ograniczenie wszystkich operacji z wyjątkiem RFUTIL ROLL FORWARD.
Dla każdego trybu można stosować akcje: enable, disable, status.

Inne ciekawe rozwiązania w OE 12.4 z zakresu “Continuous Operations” to zdefiniowanie domyślnego obszaru typu II dla tworzenia nowych obiektów bazodanowych (tabele, indexy, LOBs), uproszczony mechanizm obcinania (truncate) danych w tabeli online czy poprawiony mechanizm zarządzania obszarem before-image. Został on wprowadzony w OE 12.3 w procesie watchdog, a w OE 12.4 to już niezależny proces uruchamiany poleceniem probim [nazwa-bazy].

Wprowadzona została konsola do zarządzania w chmurze OpenEdge Command Center wersja 1.0 , która umożliwia zarządzanie zasobami i instalacją produktów OpenEdge na różnych komputerach i w różnych wersjach OpenEdge.

Po więcej nowości zapraszam do dokumentacji OE.

Administracja, Info ogólne

OE Management

OpenEdge Management (OEM), następca Fathom Management, jest dobrze znany administratorom baz danych od wielu lat. Jego zubożona wersja, OpenEdge Explorer, jest dołączana darmowo do licencji serwera baz danych. Jest więc narzędziem bardzo popularnym i ze względu na interfejs webowy, stosowanym na każdej platformie. Postanowiłem więc cofnąć się do tego produktu i napisać o kilku kwestiach, co do których pojawiają się pytania i niejasności.

O OE Explorer pisałem już tutaj.

Przypomnijmy za dokumentacją OpenEdge przykładowe konfiguracje w jakich może pracować OEM. Pierwsza, gdy wszystkie komponenty OEM znajdują się na jednej maszynie przedstawia poniższy rysunek.

Z punktu widzenia monitorowania mamy dwa rodzaje baz: baza zarządzana (managed database), taka która rejestruje się i jest zarządzana przez AdminServer oraz baza skryptowa (scripted database) jest to baza nie zarządzana przez AdminServer – w tym  przypadku trzeba na maszynie zdalnej trzeba wystartować proces dbagent. Aby to zrobić na maszynie host dodajemy w zasobach zdalnych bazę skryptową. Następnie odczytujemy komendę jaką należy uruchomić na maszynie remote np.

dbagent -db C:\WrkOpenEdge123\db\sports2000 -H hostname -S 8850 -ipver IPv4 (-S jest portem nasłuchu OEM, nie bazy).
Po uruchomieniu tej komendy agent kontaktuje się z OEM na maszynie host. Każdą bazę scripted można w prosty sposób zamienić w konsoli OEM na managed, Musi być ona uruchomiona z parametrem -S.

Poniższa konfiguracja jest już bardziej złożona – na trzech maszynach A, B i C jest zainstalowany AdminServer. Monitorowanie odbywa się na maszynie A (host). Maszyny B i C (remote) przesyłają dane do hosta. O tym jak wygląda ta komunikacja, napiszę za chwilę. Na maszynach B i C można mieć zainstalowany także OEM i skonfigurowane wszystkie potrzebne lokalne zasoby. W tej sytuacji poprzez zdalne AdminServery mamy dostęp do wszystkich trzech środowisk i to wszystko z jednej konsoli OEM.


Teraz w OEM na hoście możemy dodać zdalne AdminServery i monitorować te maszyny z jednej konsoli. Przykład mamy na poniższym rysunku.

Tu dochodzimy do ważnego punktu. Otóż w wersji OE 11.3 zmienił się mechanizm zdalnego monitorowania (messaging system), SonicMQ został zastąpiony przez ActiveMQ.
Jeśli monitorujemy środowisko posiadając wersję OE 11.3 lub wyższą możemy monitorować bazy scripted w niższych wersjach niż 11.3. Dzieje się tak dlatego, że dbagent nie korzysta z AdminServera.
Jednakże w sytuacji gdy monitorujemy całe kontenery, czyli zdalne AdminsServery, to musimy zachować kompatybilność z systemem przesyłania komunikatów. Czyli, posiadając wersję 11.3+ możemy monitorować inne wersje OE 11.3+. Jeśli zachodzi potrzeba monitorowania wcześniejszych wersji OE, trzeba zainstalować wcześniejsza wersję OEM z systemem SonicMQ.
Korzyść płynąca z ActiveMQ to większa niezawodność, ponadto możemy mieć na wszystkich maszynach zainstalowany nie tylko AdminServer ale także OEM, który w kapitalnym stopniu ułatwia konfigurację. W poprzednich wersjach po przeprowadzeniu konfiguracji trzeba było “wyłączyć” produkt OEM poprzez instrukcję unglue (włączenie instrukcją glue). W ActiveMQ nie mam tej potrzeby. W OE 12 nie ma nawet takiej instrukcji.

Administracja , , , ,

Bezpieczeństwo w PASOE cz. V – OE Realm

Po ostatnim artykule dostałem pytanie: czy można wykorzystać obiekt CLIENT-PRINCIPAL w PASOE bez konieczności korzystanie z LDAP. Otóż można i zaraz pokażę jak to zrobić na podstawie informacji zaczerpniętych z bazy wiedzy (000194706). (Uwaga: technika ta dotyczy wersji OE 12.2. W bazie można znaleźć podobne rozwiązanie np. dla OE 11, które nie działa poprawnie).

Na początek trzeba powiedzieć czym jest OERealm. Jest to implementacja SPA (Single Point of Authentication), rozszerzająca proces uwierzytelniania Spring Security. Implementacja ta składa się z komponentu klienta i servera OERealm napisanych w języku obiektowym ABL (OO ABL).


Źródłem danych może być nie tylko baza, ale także omawiane wcześniej LDAP lub inne żródło.
OE Realm Service Interface jest klasą OO ABL, która zawiera metody sprawdzające tożsamość użytkownika i dostarczające informację o atrybutach zweryfikowanego użytkownika.

Po stronie klienta należy zaimplementować własny proces uwierzytelniający. Aktualnie klientem OE Realm może być REST, BPM i Rollbase.

W niniejszym artykule zajmiemy się uwierzytelnianie klientów REST, przy czym dane użytkowników są zdefiniowane w tabeli _User w domenach bazy danych OpenEdge.

Na początek przygotujmy bazę (realmdb, kopia bazy sports2000), dadajmy domenę RealmDom, kod dostępu do domeny realmpa.

Dodajmy użytkownika restuser1 do domeny RealmDom oraz user1 do domeny pustej (hasło np. takie samo jak nazwa użytkownika).

Teraz trzeba stworzyć rolę i nadać ją użytkownikowi restuser1…


CREATE _Sec-role.
ASSIGN _Role-name = “PSCUser”
_Role-description = “User level role”.
_Role-creator = “”. /* Name of the user or Role that created this role */

CREATE _sec-granted-role.
ASSIGN _sec-granted-role._grantee = “restuser1@RealmDom”.
_sec-granted-role._role-name = “PSCUser”.
_sec-granted-role._grantor = “”. /* the user or role that granted use of this role */
_sec-granted-role._grant-rights = YES.
_sec-granted-role._granted-role-guid = substring(base64-encode(generate-uuid), 1, 22).

…oraz sekwencję wymaganą przez klasę OEUserRealm.cls.


USING OpenEdge.DataAdmin.*.

DEFINE VARIABLE sequence AS ISequence NO-UNDO.
DEFINE VARIABLE service AS CLASS DataAdminService.
service = NEW DataAdminService().

sequence = service:NewSequence("Next-User-Num").

sequence:InitialValue = 1.
sequence:IncrementValue = 1.
sequence:IsCyclic = FALSE.
sequence:MaximumValue = ?.

service:CreateSequence(sequence).

Tworzymy nową instancję PASOE (nazwałem ją realmpas) z przyłączoną bazą realmdb.
Aby tylko ta instancja mogła uruchomić plik klasy Oe Realm, wygenerujemy plik CP poleceniem:
genspacp -user oerealm -password RESTSPAPassword -role RESTSpaClient -file realm.cp

W komendzie tej dane użytkownika nie mają nic wspólnego z użytkownikami zdefiniowanymi w bazie.
Dane te będą znajdować się w pliku spaservice.properties, który należy umieścić w podkatalogu …/realmpas/openedge.
Wygenerowany plik realm.cp umieścimy natomiast w podkatalogu …/realmpas/common/lib/.

Teraz, podobnie jak w poprzednim artykule, wygenerujemy zaszyfrowany plik rejestru. Najpierw tworzymy prosty plik tekstowy domreg.csv zawierający tylko jedną linię: nazwa domeny, kod dostępu.
RealmDom, realmpa.
Zaszyfrowany plik generujemy poleceniem gendomreg domreg.csv ABLDomainRegistry.keystore.
Nazwa pliku jest dowolna. W tym przykładzie jest to nazwa domyślna, używana w pliku z ustawieniami PASOE. Umieszczamy go w podkatalogu …/realmpas/conf.
Plik OEUserRealm.properties kopiujemy do podkatalogu …/realmpas/openedge. Zawiera on tylko dwie linie:

validateCP=true
debugMsg=true

Wszystkie pliki potrzebne aby uruchomić ten przykład możemy pobrać STĄD.

Przejdżmy teraz do Developer’s Studio i stwórzmy prosty projekt oparty na naszym PASOE typu REST z wykorzystaniem JSDO (pokazywałem kiedyś jak to zrobić na tym blogu). W projekcie tym (nazwałem go myrealm) tworzymy Busineee Entity dla tabeli Customer. Zresztą, może to być jakikolwiek inny projekt dla serwisu REST. Mamy więc projekt i wygenerowany podkatalog AppServer. Importujemy do tego podkatalogu pobraną strukturę psc/stat/realm z plikami klasy.
Jeśli tworzycie takie projekty to pewnie dobrze wiecie jak to zrobić. Jeśli nie, to wg. mnie, najwygodniej utworzyć plik zip tylko ze strukturą i plikami, które chcemy zaimportować (pobrany plik .zip zawiera także ustawienia, plik .cp itp.), a następnie klikamy prawym klawiszem na podkatalog AppServer i wybieramy import -> Archive File. Radzę skasować pliki .r ponieważ były skompilowane dla bazy sports2000 i mogą generowac błędy.

Przechodzimy teraz do pliku z ustawieniami PASOE oeablSecurity.properties. Możemy to zrobić bezpośrednio w podkatalogu …\realmpas\webapps\myrealm\WEB-INF, bądź z Dev. Studio pod naszym projektem PASOEContent/WEB-INF/oeablSecurity.properties.

Dodajemy w nim ustawienia lub upewniamy się, że są tam takie jak poniżej (niektóre ustawienia powinny mieć domyślne wartości).

http.all.authmanager=oerealm
client.login.model=form

OEClientPrincipalFilter.enabled=true
OEClientPrincipalFilter.registryFile=ABLDomainRegistry.keystore

OERealm.UserDetails.realmClass=psc.stat.realm.OEUserRealm
OERealm.UserDetails.grantedAuthorities=ROLE_PSCUser.ROLE_PSCAdmin,ROLE_PSCDebug
OERealm.UserDetails.appendRealmError=false
OERealm.UserDetails.realmTokenFile=realm.cp

W ustawieniach PASOE dodajemy procedurę activate.p. Można to zrobić w OE Explorer (jak poniżej), w pliku openedge.properties lub w Dev. Studio Open Launch configuration -> Startup. Ta ostatnia metoda ustawia zmienne tylko tymczasowo i jest bardzo wygodna w testowaniu.
Procedura ta jest zapisana w podkatalogu …/realmpas/openedge. Uruchamia ona procedurę dumpCP.p, którą także musimy umieścić w tym katalogu. Zapisuje ona do logu dane o Client-Proncipal.

Po tych wszystkich zabiegach tak wygląda podkatalog …/realmpas/openedge…

… a tak pliki w projekcie.

Uruchamiam PASOE i próbuję zalogować się do mojego serwisu: http://localhost:8853/myrealm/static/auth/login.jsp

Próba jest udana i w logu agenta możemy znaleźć nast. informacje:

.....
(Procedure: 'dumpCP.p' Line:16) psc.stat.realm.OEUserRealm&ValidateUser Client-Principal:
(Procedure: 'dumpCP.p' Line:17) ID:         'oerealm@OESPA'
(Procedure: 'dumpCP.p' Line:18) session-id: 1ehUo504Taq+XFpP8CFSMw
(Procedure: 'dumpCP.p' Line:19) state:      SSO
(Procedure: 'dumpCP.p' Line:25) details: The CLIENT-PRINCIPAL object credentials were validated by an external system
(Procedure: 'dumpCP.p' Line:27) roles: RESTSpaClient
.....
(Procedure: 'ValidateUser psc.stat.realm.OEUserRealm' Line:590) Lookup ABL user account for: restuser1@RealmDom
(Procedure: 'ValidateUser psc.stat.realm.OEUserRealm' Line:599) ValidateUser found user: restuser1@RealmDom
(Procedure: 'ValidateUser psc.stat.realm.OEUserRealm' Line:613) Lookup user account for: restuser1@RealmDom returned id: 2
.....

Pliki klas możemy oczywiście napisać sami, ale potrzebna jest do tego odpowiednia wiedza. Na początek warto bazować na tych przykładowych plikach.
I to by było na tyle.

Administracja , , ,
1 2 3