Tag: PASOE

Modele zabezpieczeń serwera PASOE

“Temat PASOE nie schodzi z afisza”, można powiedzieć, ale co zrobić jeśli to wciąż kluczowy produkt w architekturze aplikacji progressowych i w dodatku wciąż rozwijany. Zwykle piszę na temat, z którym związane są pewne niejasności i pytania. Tak samo jest tym razem. Chodzi o tworzenie instancji PASOE jako model deweloperski i produkcyjny. Każdy z tych modeli związany jest z inną licencją, jako że jest to nieco inny produkt. Zestawmy ich krótkie porównanie:

Model deweloperski:

  • kompilacja procedur
  • brak zabezpieczeń w konfiguracji
  • wbudowana aplikacja web oeabl.w (ROOT). Wszystkie warstwy transportowe wdrożone i włączone
  • ograniczenie do 5 jednoczesnych żądań. 1 agent
  • dołączona instancja dla testów (oepas1)

Model produkcyjny:

  • brak możliwości kompilacja procedur w locie
  • konfiguracja zabezpieczona
  • wbudowana aplikacja web oeabl.w (ROOT). Wszystkie warstwy transportowe wdrożone ale wyłączone
  • liczba jednoczesnych żądań jest ograniczona jedynie licencją
  • brak instancji testowej

Jeśli mamy utworzoną już instancję i chcemy sprawdzić jej tryb to możemy zrobić to na różne sposoby np.:

  • w pliku openedge.properties:srvrAppMode=development | production
  • w pliku appserver.properties:spsc.as.security.model=development | production
  • uruchomić komendę:pasman env –I nazwa_instancji

OK, przejdżmy teraz do kilku opcji tworzenia instancji. Po pierwsze mamy do dyspozycji parametr -f, którego użycie spowoduje wdrożenie wszystkich aplikacji webowych (pliki .war) z ${DLC}/servers/pasoe/webapps do nowej instancji. Przyda on się nam za chwilę.

Po drugie, możemy tworzyć instancję o określonym trybie, korzystając z parametru -Z. Mamy tu trzy wartości do wyboru: dev, prod i pas.

Większość z Was słyszała zapewne o dwóch pierwszych ale mało kto wie po co jest i jak działa trzecia wartość (pas). Napiszę o tym za chwilę.

Pierwsza watość (dev) najmniej nas tutaj interesuje; druga jest o wiele ciekawsza ponieważ stwarza wrażenie, że jeśli jej użyjemy to mamy od razu wersję produkcyjną. Załóżmy, że mamy licencję deweloperską i tworzymy nową instancję PASOE o nazwie myProdInst (numery portów są pominięte):

pasman create -Z prod %WRKDIR%\myProdInst

Pytanie brzmi: czy stworzyliśmy wersję produkcyjną czy wciąż deweloperską?

Sprawdzamy np. komendą pasman.


Widać, że znacznik security model = production.

Teraz zobaczmy warstwy transportowe dla domyślnej aplikacji webowej ROOT w narzędziu OEM/OEE (mozna alternatywnie sprawdzić w pliku konfiguracyjnym):


Wszystkie warstwy są wdrożone i wyłączone, jak dla modelu production.

Pomimo tego nasza instancja nie jest do końca produkcyjna i firma Progress zdecydowanie zaleca używanie w środowisku produkcyjnym licencji modelu produkcyjnego. Po pierwsze w naszej nazwijmy quasi-produkcyjnej instancji nie są wymagane r-kody, a więc procedury mogą być kompilowane w locie, co stanowi duże zagrożenie. Po drugie instancja nie może zmienić uprawnień w katalogu $DLC/servers/pasoe. I wreszcie nie można uruchomić więcej niż 1 agenta z 5 sesjami.

Powróćmy teraz do trzeciej wartości dla opcji -Z pas. Jest to instancja podobna do tej -Z dev ale domyślną aplikację ROOT (oeabl.war) zastępuje aplikacja noaccess.war. W rzeczywistości nie jest to serwer PASOE, a serwer aplikacji Tomcat.

Zróbmy test i stwórzmy przykładową instancję poleceniem (numery portów pominięte):

pasman create -Z pas %WRKDIR%\myProdPas


Widać, że nie ma żadnej aplikacji ABL oraz wdrożonej aplikacji webowej opartej na oeabl.war i start tekiej instancji przy pomocy komend OpenEdge np. pasman start czy tcman pasoestart nie powiedzie się. Uda się, natomiast start przy pomocy tcman start (to komenda Tomcata).

Jakakolwiek próba zdalnego dostępu do takiej instancji kończy się komunikatem “Request refused”. Instancja taka to zabezpieczony pusty kontener. Żeby z niego skorzystać musimy wdrożyć w nim aplikacje webowe. Metoda ta jest szczególnie wygodna gdy mamy wygenerowane pliki .OEAR (OpenEdge Application Archive), przy pomocy których możemy importować całe fragmenty architektury PASOE: aplikacje ABL, aplikacje webowe, zabezpieczenia… Pisałem o tym kiedyś krótko (pasman export/import). Po więcej zapraszam do dokumentacji.

Pozostaje jeszcze pytanie czy korzystać w instancjach produkcyjnych z managerów? Jeśli widzimy taką konieczność to oczywiście tak, ale trzeba je najpierw zabezpieczyć, o czym napiszę w następnym artykule.

Administracja , ,

PASOE i SSL cz. II

W poprzednim artykule omówiłem czynności wstępne związane z wygenerowaniem kluczy i certyfikatów. Czas teraz zająć się konfiguracją po stronie klienta ABL i przetestowaniem połączenia.
Gdy serwer przedstawia swój certyfikat klientowi, klient musi mieć (w celu weryfikacji) certyfikat zaimportowany do swojego magazynu certyfikatów.

OpenEdge udostępnia narzędzie certutil do importowania certyfikatu CA do magazynu certyfikatów OpenEdge w katalogu %DLC%\certs. W naszym przypadku składnia wygląda następująco:
certutil -import C:\OpenEdge128\keys\requests\mycert.cer

Każdy klient łączący się z instancją musi mieć kopię pliku certyfikatu wygenerowanego podczas importu (tutaj: 1cafad6a). Należy więc skopiować ten plik do katalogu %DLC%\certs po stronie klienta.

Teraz zajmiemy się PASOE. Przechodzimy do katalogu conf dla naszej instancji (tu: C:\WrkOpenEdge128\mypasoe\conf) i wykonujemy kopię zapasową pliku tomcat-keystore.p12 np. do pliku tomcat-keystore.p12.original.

Wykonujemy polecenie sslc, aby wyeksportować informacje z pliku PEM do magazynu kluczy Tomcat o nast. składni:
sslc pkcs12 -export -in [signed public key file name].pem -out tomcat-keystore.p12 -name [alias name]
W nazwie aliasu należy unikać dużych liter. Musimy pamiętać ustanowione wcześniej hasło dla PEM oraz podać dwa razy nowe hasło dla exportu (tutaj: MyExpPass).

sslc pkcs12 -export -in C:\OpenEdge128\keys\mycert.pem -out tomcat-keystore.p12 -name mysslkey

Teraz trzeba zaktualizować plik mypasoe/conf/catalina.properties a dokładnie dwa wpisy w sekcji JSSE keystore: psc.as.https.keypass musi mieć wartość naszego hasła do exportu, a psc.as.https.keyalias wartość aliasu, jak poniżej.

Po tych wszystkich zabiegach można przetestować połączenie. Zaczniemy od REST, czyli https:localhost:8814… Widać, że usługa zwraca dane.

Powinniśmy dodać także certyfikat do przeglądarki, ale tylko w przypadku prawdziwego certyfikatu, wydanego przez CA. Tutaj nie ma to znaczenia.

Teraz przetestujemy warstwę transportową APSV. Z procedury ABL łączymy się po https i uruchamiamy znaną już procedurę na appserwerze. Wszystko działa poprawnie.

Administracja , ,

PASOE i SSL cz. I

W niniejszym i następnym artykule chciałbym poruszyć ważny temat certyfikatów i połączenia PASOE z aplikacja kliencką z zastosowaniem protokułu SSL (TLS). TLS wyewoluował z protokołu SSL (zastępując go gdy jest to możliwe) i jest to standardowy protokół implementujący szyfrowanie wymagane w komunikacji HTTPS.

PASOE umożliwia określenie portu HTTPS podczas tworzenia instancji. Przypomnijmy sobie przykładową komendę:
pasman create -v -f -p 8813 -P 8814 -s 8815 %WRKDIR%\mypasoe
gdzie port komunikacji po HTTPS jest określony przez parametr -P (tutaj 8814).

Do nawiązania połączenia serwer-klient wykorzystywana jest technologia szyfrowania asymetrycznego lub inaczej Public Key Infrastructure (PKI). Po nawiązaniu połączenia i wymianie kluczy można już stosować mniej skomplikowane algorytmy szyfrowania symetrycznego. Prześledzimy tutaj przykładowy proces prowadzący do uzyskania i zaimportowania certyfikatu oraz zaimportowania certyfikatów do magazynów klucza po obu stronach. Każdy certyfikat cyfrowy powinien być podpisany przez wystawiający go urząd certyfikacji (CA). Może on być również certyfikatem z podpisem własnym (tzw. self-signed) ale tylko dla zastosowania w fazie testowania i rozwoju, i w żadnym razie nie w środowisku produkcyjnym.
Cały ten proces wymaga użycia narzędzi OpenEdge:

  • PKIUTIL – do generowania pary kluczy: prywatny, publiczny, a następnie importowania certyfikatu do magazynu kluczy dla serwerów
  • CERTUTIL – do importowania nowych certyfikatów dla klientów
  • SSLC – w OpenEdge dodano implementacje OpenSSL. Można ją wykorzystać opcjonalnie do utworzenia certyfikatu z podpisem własnym wygenerowanym dla klucza prywatnego (dla testów) oraz do wielu innych operacji.

Zaczniemy od wygenerowanie pary kluczy prywatny/publiczny.

Otwieramy proenv jako administrator
Przechodzimy do katalogu %DLC%\keys\requests

pkiutil -keysize 2048 -newreq mycert
Będziemy musieli utworzyć hasło PEM (tutaj: Mypass1) – to nasze hasło należy zapisać bo będzie jeszcze nam potrzebne.
Będziemy pytani o szereg informacji składających się na tzw. Distinguished Name (DN): symbol kraju, województwo, organizacja itd. Nie wszystkie są niezbędne, ale najważniejsze z nich to nazwa organizacji i domeny dla naszego serwera. Przykładowe dane widać poniżej.


Otwieramy proenv jako administrator
Przechodzimy do katalogu %DLC%\keys\requests

Zostały w nim utworzone pliki:
1. mycert.pk1 – klucz prywatny, którego pilnie strzeżemy
2. mycert.pk10 – klucz publiczny + informacje o Twojej organizacji. Służy on do utworzenia tzw. żądania podpisania certyfikatu (CSR), które należy przesłać do urzędu certyfikacji (CA).

Po przesłaniu pliku klucza publicznego (mycert.pk10 w tym przykładzie) do CA, powinniśmy uzyskać podpisany certyfikat TLS, który jest zazwyczaj plikiem z rozszerzeniem .crt lub .cer.
My posłużymy się jednak tutaj certyfikatem z własnym podpisem wygenerowanym dla klucza prywatnego. Przypominam, że można go stosować wyłącznie dla celów testowych.
(Również dla celów testowych możemy skorzystać z darmowego serwisu getaCert).

sslc req -key C:\OpenEdge128\keys\requests\mycert.pk1 -new -x509 -days 360 -out C\OpenEdge128\keys\requests\mycert.cer

Jeśli otrzymalibyśmy certyfikat z CA należałoby go skopiować do katalogu %DLC%\keys\requests\

Następnie musimy wygenerować plik PEM (Privacy-enhanced Electronic Mail), zawierający prywatny klucz serwera oraz certyfikat.
Wykonujemy następujące polecenie (będziemy musieli podać wcześniej utworzone hasło!):
pkiutil -import mycert C:\OpenEdge128\keys\requests\mycert.cer

Plik mycert.pem pojawi się w katalogu %DLC%\keys


Na tym kończę ten odcinek, w następnym zajmiemy się klientem i przetestowaniem połączenia SSL.

Administracja , ,

OpenEdge 12.8

Nareszcie mamy na rynku następną wersję LTS (Long-Term Support) OE 12.8. Poprzednia OE 12.2 pojawiła się 4 lata temu. 12.8 zawiera elementy wprowadzane w kolejnych wersjach Innovation 12.3-12.7 włącznie, co z grubsza opisałem na tym blogu. Teraz zobaczymy co ciekawego jest w samej wersji 12.8.

Zacznijmy od administracji PASOE. W poprzednim artykule opisałem nową komendę OEMANAGER, stosowaną do przeglądu statystyk i podstawowych operacji. Osoby zainteresowane odsyłam bezpośrednio do tego wpisu.

Inną ciekawą i bardzo ważną funkcją jest zapowiadana technologia Dynamic Data Masking (DDM) służąca do dynamicznego zaciemniania lub maskowania wrażliwych danych w bazie przed nieautoryzowanymi użytkownikami. Przykładem może być maskowanie w danych osobowych pola “pesel” lub w danych finansowych pola “wynagrodzenie”.

Technologia ta składa się niejako z dwóch etapów. Pierwszy należy do administratora bazy i polega na włączeniu funkcji poleceniem PROUTIL [baza] -C ENABLEDDM. Komenda ta sprawdza czy baza jest licencjonowana do użycia DDM. Następne polecenie PROUTIL [baza] -C ACTIVATEDDM uaktywnia DDM w bazie (dostępne są także opcje DEACTIVATEDDM i DISABLEDDM).

DDM do kontrolowania uprawnień przyznawanych użytkownikom w zakresie maskowania danych wykorzystuje konfigurację opartą na rolach. Administrator DDM może skonfigurować maskę nad polami tabeli, która ukrywa wrażliwe dane w zestawie wynikowym zapytania, a także utworzyć i przypisać nowe tagi autoryzacyjne do ról zdefiniowanych przez użytkownika.

Drugim etapem jest zatem zdefiniowanie własnych ról oraz znaczników autoryzacji i przypisanie ich do zdefiniowanych ról, przydzieleniu ról uwierzytelnionym użytkownikom, konfiguracja masek i znaczników autoryzacji dla pól tabeli. Etap ten realizujemy wykorzystując interfejs IDataAdminService, który udostępnia zestaw właściwości i metod obsługujących operacje CRUD związane z DDM. Poniżej zamieszczam wzięty z dokumentacji przykład utworzenia własnej roli TestUser.

USING OpenEdge.DataAdmin.*.

VAR DataAdminService oDAS. VAR IRole oRole.
VAR LOGICAL lResult.

ASSIGN oDAS = NEW DataAdminService(LDBNAME("DICTDB")).

oRole = oDAS:NewRole("TestUser"). 
oRole:Description = "A Test User".
// This role will be used for DDM
oRole:IsDDM = true.
lResult = oDAS:CreateRole(oRole). 

DELETE OBJECT oDAS.

W OpenEdge jest systematycznie rozwijana technologia wizualizacji danych poprzez standard OpenTelemetry i wykorzystanie zewnętrznych aplikacji typu APM (Application Performance Monitoring).
W 12.8 dodano możliwość monitorowania procesów agentów PASOE oraz klientów ABL. W tym drugim przypadku należy uruchomić sesję ABL z parametrem -otelconfig myotelConfig.json, wskazującym na plik konfiguracyjny w standardzie JSON. Przykładowy taki plik zamieszczam poniżej:

{
"OpenTelemetryConfiguration": {
        "exporters": {
            "otlp": {
                "grpc": [
                    {
                        "endpoint": "http://localhost:4317",
                        "span_processor": "batch",              
                     }
            ]
        }
      }
    },
    "OpenEdgeTelemetryConfiguration": {
        "trace_procedures": "Customer*.p",
		"trace_classes": "*",
        "trace_abl_transactions": true,
        "trace_requires_parent": true,
        "trace_request_start": true
    }
}

Plik ten określa m.in. proces OTel Collectora (port:4317), a także maskę monitorowanych plików np. każda procedura zawierająca w nazwie słowo Customer i wszystkie klasy (*). O pełnej konfiguracji monitorowania przy pomocy Open Telemetry napiszę innym razem.

A teraz kilka słów na temat administrowania bazą. Pojawiła się komenda PROUTIL [baza] -C PROBE [state] która sprawdza aktualny operacyjny stan bazy. Sprawdzane są trzy stany (parametr state):

  • startup – czy baza danych zakończyła uruchamianie
  • liveness – czy broker bazy danych działa i odpowiada
  • readiness – czy baza danych może wykonywać operacje (np. CRUD)

Jeśli wykonanie komendy z parametrem –verbose nie wyświetli żadnych informacji, będzie to oznaczać sukces.

Administratorzy wykorzystujący możliwość zwiększania wartości niektórych parametrów poleceniem PROUTIL… INCREASETO mogą teraz wygenerować plik .pf z aktualnymi ustawieniami podczas runtime’u. Daje to możliwość zapamiętywania i porównywania różnych konfiguracji. Plik możemy wygenerować wykorzystując tablice VST lub z poziomu narzędzia PROMON -> R&D Advanced Options -> 4. Administrative Functions -> 17. Generate parameter file

Dużym zainteresowaniem cieszyła się nowa komenda PROUTIL… TABLEREORG wprowadzona w OE 12.7, która pozwala na przeładowanie tablicy i polepszenie stopnia fragmentacji i rozrzucenia rekordów przy pracującej bazie. Podczas ładowania wykorzystuje się sortowanie rekordów wg indeksu. W OE 12.7 musiał to być indeks unikalny, jednakże czasami lepszą wydajność można uzyskać dla indeksu nieunikalnego ale często używanego w aplikacji. W OE 12.8 indeksy mogą już być nieunikalne.

Inne ciekawe i ważne nowości to np. podniesie wersji Spring Security 6.1.4 oraz Tomcata 10.1.15. Ma to swoje implikacje podczas migracji z wcześniejszych wersji PASOE.
W Developer’s Studio dodano typ projektu .NET z narzędziami: Class Browser, Content Assist, Outline View, co ma pomóc w programowaniu przy użyciu .NET 6.

Jest jeszcze sporo innych nowinek po które zapraszam do dokumentacji.

Administracja, Development, Info ogólne , ,

PASOE – OEMANAGER

Właśnie pojawiła się nowa wersja OpenEdge LTS 12.8 a wraz z nią sporo nowości. Poświęcę im cały artykuł, ale to następnym razem. Teraz chciałbym skupić się na jednym elemencie dotyczącym serwera aplikacji PASOE, a mianowicie na narzędziu OEMANAGER.
Pamiętacie może, że dla klasycznego appservera czy webspeeda można było uruchomić z poziomu wiersza poleceń (proenv) komendę ASBMAN czy WTBMAN aby uzyskać status procesu i podstawowe metryki.
Podobnie jest z OEMANAGER – można uzyskać wszystkie potrzebne metryki w jednym wywołaniu, w przeciwieństwie do innych sposobów jak wywołania API. Ponadto, narzędzie OEMANAGER może być wykorzystywane podczas runtime’u.
Aby można było z niego skorzystać instancja musi zawierać wdrożone aplikacje: OpenEdge Manager (oemanager.war) i Tomcat Manager (manager.war). Możemy wdrożyć je odpowienimi poleceniami do istniejącej instancji lub stworzyć nową z już wdrożonymi tymi aplikacjami używając opcji -f. Poniżej zamieszczam komendę utworzenia takiej instancji mypasoe. Do niedawna zalecani nie instalować tych aplikacji w środowisku produkcyjnym ale obecnie nie ma takich przeciwskazań o ile odpowienio je zabezpieczymy. Jednym takim elementem zabezpieczeń jest oczywista zmiana domyślnych haseł. Po resztę informacji odsyłam do dokumentacji. Ja w tym przykładzie pozostanę przy domyślnych hasłach, a dlaczego, to zaraz pokażę.

pasman create -v -f -p 8813 -P 8814 -s 8815 %WRKDIR%\mypasoe
Teraz uruchamiam instancję poleceniem:
pasman oeserver -start -I mypasoe
Jest to nowsza forma komendy tcman (pasman) pasoestart, wprowadzona od OE 12.5. Po prawidłowym uruchomieniu procesu Tomcata nie oznacza, że wszystkie komponenty OpenEdge zostały uruchomione. Polecenie tcman -oeserver start sprawdza logi pod kątem takich błędów. Polecenie posiada kilka jeszcze innych opcji, a więc ci, którzy mają wersję 12.5+ powinni korzystać właśnie z niej.

Po uruchomieniu oemanager (z poziomu katalogu bin dla danej instancji) dostajemy poniższą długą listę opcji.

     [echo]  TCMAN Shortcuts:
     [echo]
     [echo]  oemanager query    - Use TCMAN to query the PAS instance
     [echo]
     [echo]  oemanager startup  - Use TCMAN to start the PAS instance
     [echo]                       [OPTIONAL] timeout=300 - Time (seconds) to wait for a proper startup
     [echo]
     [echo]  oemanager shutdown - Use TCMAN to stop the PAS instance
     [echo]                       [OPTIONAL] timeout=300 - Time (seconds) to wait for a proper shutdown
     [echo]
     [echo]
     [echo]  Support Tools:
     [echo]
     [echo]  oemanager inventory - Bundle useful PAS instance files (as .zip) for support tickets
     [echo]
     [echo]
     [echo]  Status/Info:
     [echo]
     [echo]  oemanager status - [RO] Obtain MSAgent/connection status information for an ABL App
     [echo]                     [OPTIONAL] basemem=819200 - Minimum memory threshold (bytes) to consider as 'unused' agent sessions
     [echo]
     [echo]  oemanager stacks - [RO] Obtain stack information for all MSAgents for an ABL App
     [echo]
     [echo]  oemanager flush  - [RO] Flush the available deferred log buffer to agent log file
     [echo]
     [echo]  oemanager locks  - [RO] Display database users and their table locks related to an MSAgent-Session
     [echo]                     This utilizes a single DBConnection; edit the 'locks' task in build.xml to add more as necessary
     [echo]                     Note: Only provides session data if using self-service DB connections for OE versions under 12.5
     [echo]                     [REQUIRED] pf=[PF_NAME] - PF file to use for database connection(s)
     [echo]
     [echo]  oemanager users  - [RO] Alias for 'locks' task
     [echo]
     [echo]
     [echo]  Agent Management:
     [echo]
     [echo]  oemanager add     - Add (read: start) one new MSAgent for an ABL App
     [echo]
     [echo]  oemanager close   - Perform a 'soft restart' of an ABL App (runs: status, flush + trimhttp + stop, status)
     [echo]                                       For this task the 'trimhttp' will be called with the termination option 1 (forced)
     [echo]                      [REQUIRED] webapp=[WEBAPP_NAME] - WebApp for Tomcat Manager to terminate active client sessions
     [echo]                                  The given WebApp is expected to be associated with the provided ablapp name
     [echo]                      [OPTIONAL] sleep=1 - Sleep time in minutes after stop, prior to final 'status' output
     [echo]
     [echo]  oemanager clean   - Alias for 'close' task [Deprecated]
     [echo]
     [echo]  oemanager refresh - Refresh ABL Sessions for each MSAgent for an ABL App (OE 12 Only)
     [echo]                      Note: This will essentially terminate all sessions (gracefully),
     [echo]                            and prepare the Agent to pick up any R-code changes
     [echo]
     [echo]  oemanager reset   - Reset an aspect of each MSAgent for an ABL App
     [echo]                      [REQUIRED] resettype=stats [stats|logs]
     [echo]
     [echo]  oemanager stop    - Gracefully stop one or all MSAgents (+stacks output) for an ABL App
     [echo]                      [OPTIONAL] waitfinish=120000 - How long to wait (milliseconds) if the MSAgent is busy serving a request
     [echo]                      [OPTIONAL]  waitafter=60000  - Additional time to wait (milliseconds) before killing [hard stop] the MSAgent
     [echo]                      [OPTIONAL]        pid=[AGENT_PID] - Numeric process ID for a specific MSAgent to be stopped
     [echo]
     [echo]
     [echo]  Session Management:
     [echo]
     [echo]  Note: All trim actions listed below will write application stack information to a file.
     [echo]
     [echo]  oemanager trimsingle - Trim a single ABL Session (via the Agent Manager) for a specific MSAgent
     [echo]                         [REQUIRED]          pid=[AGENT_PID]  - Numeric process ID of the MSAgent for context
     [echo]                         [REQUIRED]       sessid=[SESSION_ID] - Numeric ID for the ABL Session to be stopped
     [echo]                         [OPTIONAL] terminateopt=0 - Termination Option: 0=graceful, 1=forced, 2=finish+stop
     [echo]
     [echo]  oemanager trimall    - Trim all available ABL Sessions (via the Agent Manager) for each MSAgent for an ABL App
     [echo]                         Note: For any busy sessions considered stuck use 'trimhttp' with a specific Session ID
     [echo]                         [OPTIONAL] terminateopt=0 - Termination Option: 0=graceful, 1=forced, 2=finish/stop
     [echo]
     [echo]  oemanager trimidle   - Trim only the IDLE ABL Sessions (via the Agent Manager) for each MSAgent for an ABL App
     [echo]                         Allows for manually scaling down an MSAgent which may have many unused ABL Sessions
     [echo]                         [OPTIONAL] terminateopt=0 - Termination Option: 0=graceful, 1=forced, 2=finish+stop
     [echo]
     [echo]  oemanager trimhttp   - Trim one or all Client HTTP Sessions (via the Session Manager) for an ABLApp + WebApp
     [echo]                         Terminating a client HTTP session will also terminate its associated ABL Session
     [echo]                         [REQUIRED]       webapp=[WEBAPP_NAME] - WebApp for Tomcat Manager to terminate active sessions
     [echo]                                           The given WebApp is expected to be associated with the provided ablapp name
     [echo]                         [OPTIONAL]       sessid=[SESSION_ID]  - Alphanumeric Client Session ID to be stopped
     [echo]                                           When no session ID provided, all available Client HTTP Sessions will be expired
     [echo]                         [OPTIONAL] terminateopt=0 - Termination Option: 0=graceful, 1=forced, 2=finish+stop
     [echo]
     [echo]
     [echo] Current parameter values, override via command line or 'oemanager.properties':
     [echo]     scheme=http
     [echo]       host=localhost
     [echo]       port=8813
     [echo]     userid=tomcat
     [echo]     passwd=tomcat
     [echo]     ablapp=mypasoe

Niektóre są oczywiste jak: start, stop, status itp. ale niektóre wyglądają bardzo ciekawie, np. opcja flush – pomaga znaleźć przyczynę powtarzających się awarii agenta, poprzez opóżnione zrzucenie informacji ze specjalnego bufora do pliku.
Na samym dole widać użytkownika i hasło do procesu Tomcata. Należy dla bezpieczeństwa wejść do pliku oemanager.properties, znajdującego się w podkatalogu bin dla instancji, odkomentować dwie linie i ustawić puste dane logowania, jak na poniższym obrazku.

OK, poniżej zamieściłem wynik działania komendy oemanager status.

 [PCTRun]  PASOE Instance: http://localhost:8813
   [PCTRun]
   [PCTRun] ABL Application Information [mypasoe - v12.8.0 ( 2023-12-21 )]
   [PCTRun]     WebApp: ROOT
   [PCTRun]       APSV: ENABLED
   [PCTRun]       SOAP: ENABLED
   [PCTRun]       REST: ENABLED
   [PCTRun]        WEB: ENABLED
   [PCTRun]
   [PCTRun] Manager Properties
   [PCTRun]             Maximum Agents:           2
   [PCTRun]             Minimum Agents:           1
   [PCTRun]             Initial Agents:           1
   [PCTRun]     Max. Connections/Agent:         200
   [PCTRun]     Max. ABLSessions/Agent:         200
   [PCTRun]         Idle Conn. Timeout:     300.000 ms (00:00:05:00.000)
   [PCTRun]       Idle Session Timeout:   1.800.000 ms (00:00:30:00.000)
   [PCTRun]         Idle Agent Timeout:   1.800.000 ms (00:00:30:00.000)
   [PCTRun]      Idle Resource Timeout:           0 ms (00:00:00:00.000)
   [PCTRun]         Conn. Wait Timeout:       3.000 ms (00:00:00:03.000)
   [PCTRun]       Request Wait Timeout:      15.000 ms (00:00:00:15.000)
   [PCTRun]     Initial Sessions/Agent:           2
   [PCTRun]     Min. Avail. Sess/Agent:           1
   [PCTRun]
   [PCTRun] > Agent PID 13208: AVAILABLE
   [PCTRun]     Est. Agent Lifetime: 00:00:00:00.000
   [PCTRun]     DynMax ABL Sessions:          200
   [PCTRun]      Total ABL Sessions:            2
   [PCTRun]      Avail ABL Sessions:            2
   [PCTRun]        Open Connections:            1
   [PCTRun]         Overhead Memory: 13.897 KB
   [PCTRun]
   [PCTRun]     SESSION ID      STATE           STARTED                         LIFETIME          SESS. MEMORY     ACTIVE MEM.   REQUESTS       BOUND/ACTIVE CLIENT SESSION
   [PCTRun]                4    IDLE            18/02/2024 15:18:40,229-01:00   00:00:01:28.600         742 KB         742 KB           0        -
   [PCTRun]                7    IDLE            18/02/2024 15:18:40,229-01:00   00:00:01:28.600         742 KB         742 KB           0        -
   [PCTRun]       Active Agent-Sessions: 0 of 2 (0% Busy)
   [PCTRun]     Utilized Agent-Sessions: 0 of 2 (>801 KB)
   [PCTRun]        Approx. Agent Memory: 15.380 KB
   [PCTRun]
   [PCTRun] Session Manager Metrics (Count-Based)
   [PCTRun]            # Requests to Session:           0
   [PCTRun]           # Agent Responses Read:           0 (0 Errors)
   [PCTRun]         # Agent Requests Written:           0 (0 Errors)
   [PCTRun]     Concurrent Connected Clients:           0 (Max: 0)
   [PCTRun]       # Reserve ABLSession Waits:           0
   [PCTRun]     # Reserve ABLSession Timeout:           0
   [PCTRun]
   [PCTRun] Client HTTP Sessions: 0

Administrator otrzymuje natychmiastową całościową informację o warstwach transportowych, właściwościach agentów itd.
Zachęcam do przetestowania i korzystania z opcji komendy OEMANAGER.

Administracja ,

Debugging w aplikacjach PASOE

W kilkunastu postach opisywałem tworzenie serwisów i aplikacji z udziałem serwera aplikacji PASOE i coraz więcej naszych klientów korzysta z tej technologii. Coraz częściej powtarza się pytanie: jak można wykorzystać debugger aby wychwytywać błędy i testować aplikacje.
PASOE to połączenie technologii Tomcat (Java) i OpenEdge (ABL), więc kompletny proces debuggowania jest dość złożony.
Tutaj chciałbym pokazać jak zacząć ten proces z punktu widzenia OpenEdge’a.

Jak zwykle przed przystąpieniem do wykorzystania debuggera, trzeba włączyć tę funkcjonalność w środowisku OpenEdge. Należy uruchomić komendę prodebugenable -enable-all jako administrator.

Drugim krokiem jest wdrożenie web aplikacji oedb.war w testowanej instancji. Pamiętajmy, że ze względów bezpieczeństwa, nigdy nie wdrażać jej w środowisku produkcyjnym!
pasman deploy -I oepas1 %DLC%\servers\pasoe\extras\oedbg.war


Cały proces debuggowania będzie odbywał się w Progress Developer’s Studio for OpenEdge.
Wykorzystam do testowania plik klasy wygenerowany przy tworzeniu prostego serwisu REST i dodania zasobu (Business Entity) Customer, co opisywałem na początku 2016 roku.
Dostajemy klasę customer.cls z metodami CRUD: CreateCustomer, ReadCustomer, UpdateCustomer i DeleteCustomer. Ja wykorzystam metodę ReadCustomer i wstawię breakpoint zaraz za instrukcją SUPER:ReadData(filter). klikając po lewej stronie dwukrotnie myszką.

Teraz klikając prawym przyciskiem myszy na instancję PASOE wybieramy Restart in Debug.


Następnie uruchamiamy serwis w przeglądarce poprzez link dla Custnum=1,
http://localhost:8810/CustProj/rest/CustProjService/customer?filter=Custnum=1
a w następnej kolejności dla Custnum < 5.
http://localhost:8810/CustProj/rest/CustProjService/customer?filter=Custnum<5

W PDSOE w widoku dla zmiennych zobaczymy wartość filtra odpowiednio “Custnum=1″oraz “Custnum<5”.
Widać z tego, że zasada testowania aplikacji przy pomocy debuggera jest dość prosta.



Dodam jeszcze jedną informację, ponieważ byłem o to kilka razy pytany: W sytuacji gdy mamy wiele projektów i instancji PASOE, jak sprawdzić która instancja obsługuje dany serwis.
Można sprawdzić np. poleceniem tcman jakie serwisy są wdrożone w danej instancji, a w PDSOE podejrzeć właściwości danego projektu jak na widoku poniżej.

Cały proces debuggowania można prześledzić na kanale Youtube.
Webinar ten jest rozszerzony o testowanie aplikacji nie tylko lokalnych ale także zdalnych.

Development , ,

OpenEdge Command Center 1.3

Witajcie wciąż w wakacyjnym nastroju! Ponieważ pojawiła się ostatnio nowa wersja OpenEdge Command Center – 1.3, właśnie jej poświęcam sierpniowy wpis.
Na początku wspomnę jeszcze o jednym elemencie, o którym nie napisałem uprzednio, a który jest od pierwszej wersji OECC – o etykietach. Na poniższym obrazie widać takie etykiety, które reprezentują nazwę maszyny, tryb instancji oraz jej nazwę. Dodatkowo usunąłem niektóre kolumny, zostawiając te najważniejsze, z punktu widzenia czytelności. Etykiety są ważnym elementem szczególnie w sytuacji gdy instancji jest bardzo wiele i są kłopoty z identyfikacją.

Ale przejdźmy teraz do instalacji nowej wersji OECC 1.3. Tym razem w dokumentacji możemy znaleźć opis całego procesu, choć niektóre istotne informacje są pominięte, dlatego zamiast korzystać z instrukcji pdf, polecam raczej dokumentację online.
Nowa wersja OECC wymaga także nowszej wersji MongoDB: 4.4, 5.0, lub 6.0. Ja zainstalowałem wersji 6.0 na Windows Server 2019. Tym razem nie instaluję MongoDB jako serwis Windows.

Po zainstalowaniu MongoDB gdy baza i OECC są zainstalowane na tej samej maszynie i w takiej sytuacji trzeba związać adres ip 0.0.0.0.

W pliku konfiguracyjnym …\conf\db-config.json
ustawiam wartość:

"dbHostNameAndPort": "0.0.0.0:27017"

Ponadto od wersji MongoDB 6.x w pliku …\bin\mongod.cfg ustawiamy

Dodaję katalog np. c:\mongodata i startuję MongoDB jako administrator poleceniem:
mongod.exe –dbpath c:\mongodata -bind_ip 0.0.0.0
(Tego okna nie zamykam, dopóki proces MongoDB ma działać).

Dodaję użytkownika do bazy admin (tak jak opisałem to wcześniej).

Teraz restartujemy MongoDB z włączoną autoryzacją:
mongod.exe –dbpath c:\mongodata -bind_ip 0.0.0.0 –-auth

I możemy przystąpić do instalacji OECC 1.3, jak było to opisane wcześniej.
Po zainstalowaniu na jednej lub kilku systemach Agenta OECC, możemy w końcu zobaczyć jakie informacje są przekazywane do konsoli na serwerze.
Widzimy, że została dodana nowa ikonka po lewej stronie, reprezentująca bazy danych.

Klikając ikonkę mamy dostęp do następujących danych:

  • Nazwa bazy danych.
  • Etykiety przypisane do bazy danych.
  • Pełna ścieżka do bazy.
  • Nazwa agenta OECC.
  • Status uruchomienia bazy.
  • Nazwa portu/usługi.
  • Wersja bazy danych.
  • Nazwa hosta na którym pracuje baza danych.
  • Instalacja OpenEdge, w której znajduje się baza.

Podobnie jak dla PASOE wygodnie jest ustawić etykiety identyfikujące instancje bazy.

Jeśli agent nie wychwycił jakiejś instancji, musimy ją dodać ręcznie. W polu OpenEdge Installation wybieramy wersję OE. Dodajemy pełną ścieżkę, numer portu/nazwę usługi oraz dane logowania. Możemy dodać też opcjonalnie dodatkowe parametry startowe.

Jak widać nie ma tutaj szczegółowych danych wydajności bazy znanych z OE Management. Takie dane można uzyskać wykorzystując technologię OpenTelemetry oraz aplikację typu APM (Application Performance Monitor).

Administracja , , ,

OpenEdge Command Center – cz. 2

W niniejszym wpisie powracamy do tematu OECC. Muszę powiedzieć na wstępie, że ten produkt cieszy się coraz większym zainteresowaniem klientów ze względu na nowoczesny interfejs, duże bezpieczeństwo, wydajność czy łatwość w monitorowaniu zdalnymi zasobami. Te zalety są kluczowe w porównaniu z OEM/OEE, który jest bardzo wygodny do stosowania raczej dla lokalnych zasobów. Należy przypomnieć że technologia OECC zaczyna się od OE 12.2 – nie da się monitorować wcześniejszych wersji.

Tym razem zainstalujemy agenta na maszynie z zainstalowanym środowiskiem OpenEdge (PASOE, bazy danych), który będzie zbierał dane i przesyłał je do OECC Servera.
Pierwszym krokiem jest wygenerowanie klucza na serwerze, który posłuży do uwierzytelnienia połączenia z agentem. Wybieramy Generate Agent Keys.


Wygenerowany nowy klucz zapisujemy na dysku. Jest to plik o nazwie serverInfo.json. Będzie potrzebny do zainstalowania agenta (najczęściej na innej maszynie).

Sama instalacja jest bardzo prosta. Jedynym ciekawym krokiem jest moment wczytania danych z podanego pliku, co zaoszczędzi nam ręcznego wpisywania danych.

Jeśli instalujemy nowszą wersję agenta w miejsce starej, pojawi się poniższy komunikat (nie będzie wtedy konieczności podawania danych z pliku json).

OK, zainstalowaliśmy agenta i teraz chcemy zobaczyć czy wysyła on dane do centrum monitorowania na serwerze. Musimy jeszcze upewnić się czy w zaporze otwarty jest port (domyślnie 8000), bo w przeciwnym wypadku dane będą blokowane. W moim przykładzie serwer OECC został zainstalowany na VM z systemem Windows Server 2016, a agent i OpenEdge 12 na Windows 10.

Z poziomu konsoli serwera OECC możemy dla danej instancji PASOE wybrać kilka akcji. Najciekawiej wygląda Clone, która ma utworzyć kopię instancji w nowej lokalizacji. Zróbmy to dla mypasoe. Nowa nazwa (mało wyszukana) mypasoeCLONE.

Na sklonowanie zwykle trzeba chwilę zaczekać, szczególnie jeśli instancji jest online.

I po chwili mamy nowego clona. Instancja jest zatrzymana i zwykle wymaga pewnego dostosowania w konfiguracji aby była w pełni działająca.

Zobaczmy jeszcze dla mypasoe jakie inne ciekawe informacje możemy tu znaleźć. Jest np. info o wdrożonych aplikacjach webowych, usługach, ich parametry i aktualny status.

Tyle o wersji OECC 1.2. W następnym artykule chciałbym pokazać jakie inne elementy monitorowania zostały dodane w OECC 1.3 !

Administracja , , ,

OpenEdge 12.7

5 maja pojawiła się wersja OpenEdge 12.7. Ma być ona ostatnią z wersji Innovation dla dwunastki ponieważ ostatnia, zapowiadana na koniec roku, ma być wersją LTS. Przyjrzyjmy się wybranym nowościom.

PROSTRCT REMOVEONLINE – nowa komanda poprawiająca dostępność bazy danych. Umożliwia usuwanie extentów lub całych obszarów bez konieczności zamykania bazy.

PROUTIL TABLEREORG to narzędzie służące do poprawy stopnia fragmentacji w tabelach (zastępuje operacje dump i load online) dla obszarów typu II. Wprowadzono je w OE 12.3, a teraz dodano nowe parametry np. restrict czy nosmartscan. Pierwsza opcja jest przeznaczona dla dużych tabel i pozwala na reorganizację wybranego fragmentu tabeli wg. wartości pola. Druga opcja wyłącza domyślne inteligentne skanowanie. Przykład poniżej.

Wprowadzono nowy typ pakietu (lub biblioteki) kodu aplikacji ABL, który można podpisać i weryfikować, aby mieć pewność, że skompilowany kod aplikacji ABL nie został uszkodzony ani zmodyfikowany. Ten nowy typ biblioteki jest znany jako plik archiwum i ma rozszerzenie .apl. Do utworzenia archiwum, dodawania r-kodów służy komenda PROPACK, a do podpisywania PROSIGN.

OpenEdge obsługuje teraz OAuth2 i SAML do uwierzytelniania i autoryzacji. Te standardowe protokoły zapewniają bezpieczny i wygodny mechanizm uwierzytelniania użytkowników bez udostępniania poufnych informacji. OpenEdge Authentication Gateway może automatycznie przekonwertować zweryfikowane tokeny na token OpenEdge Client Principal, który możemy obsługiwać w aplikacjach ABL.

Administrowanie PASOE: do tej pory można było skonfigurować instancje tak aby w razie potrzeby agent wielosesyjny uruchamiał dodatkowe sesje, ale nie było możliwości aby te sesje były automatycznie przycinane. W obecnej wersji OpenEdge dodano nowe właściwości do pliku openedge.properties, które umożliwiają administratorowi systemu skonfigurowanie instancji PASOE tak, aby sesje ABL były przycinane gdy nie są już potrzebne czy też gdy osiągnęły limit czasu lub pamięci.

W Developer Studio dodano ABL Type Hierarchy View, który pokazuje relacje rodzic-dziecko między klasami ABL i interfejsami, aby pomóc programiście ABL zobaczyć hierarchię i strukturę dziedziczenia klasy i przechodzenie do dowolnego elementu widocznego w widoku.

Dla wykorzystujących AI Archiver do zapisu After Image pojawiła się ciekawa możliwość wystartowania tego procesu online bez konieczności wykonania backupu. Jest to szczególnie istotne dla dużych baz gdy wykonanie kopii powodowało wstrzymanie wykonywanie transakcji.

W operacja przywracanie bazy PROREST dodano parametry do wykonania jej jako proces wielowątkowy.

Jest jeszcze kilka nowinek po które odsyłam do dokumentacji.

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 ,
1 2 3