Month: March 2026

OpenEdge 13

10 lutego 2026 roku pojawiła się pierwsza wersja OpenEdge 13, jako tzw, Innovation Release, co stanowi przygotowanie pod wersję długoterminową (LTS). Platforma rozwijana przez Progress wchodzi na kolejny poziom nowoczesności. To wydanie skupia się przede wszystkim na zwiększeniu wydajności, bezpieczeństwa oraz lepszej integracji z nowoczesnymi technologiami w chmurze i kontenerowymi. Dla firm korzystających z OpenEdge oznacza to większą elastyczność, łatwiejsze skalowanie aplikacji oraz lepsze przygotowanie na przyszłe wyzwania technologiczne.

OpenEdge 13 to wydanie zaprojektowane z myślą o nowoczesnych wymaganiach biznesowych i technologicznych. Twórcy platformy położyli szczególny nacisk na bezpieczeństwo, dostępność, wydajność aplikacji oraz coraz ważniejsze obszary, takie jak sztuczna inteligencja i zaawansowane zarządzanie danymi.

Nowa wersja przynosi szereg usprawnień, które mogą realnie wpłynąć na funkcjonowanie systemów w organizacji – niezależnie od jej wielkości. OpenEdge konsekwentnie rozwija się jako platforma wspierająca modernizację istniejących aplikacji, jednocześnie przygotowując je na integrację z nowymi nowoczesnymi technologiami.

W praktyce OpenEdge 13 wprowadza zmiany, które przekładają się na codzienną pracę zespołów IT. Platforma zwiększa produktywność w całym swoim ekosystemie, usprawniając zarówno proces developmentu, jak i zarządzanie środowiskiem. Jednocześnie oferuje lepszą, zoptymalizowaną wydajność – zarówno na poziomie aplikacji, jak i operacji bazodanowych.

Istotnym kierunkiem rozwoju jest również otwarcie na rozwiązania oparte o sztuczną inteligencję. OpenEdge 13 tworzy fundamenty, które umożliwiają integrację aplikacji z ekosystemem AI, co staje się coraz ważniejsze w kontekście analityki i automatyzacji procesów biznesowych.

Nie bez znaczenia są także usprawnienia w obszarze bazy danych. Nowa wersja poprawia przepustowość oraz skraca czas działania narzędzi administracyjnych, co przekłada się na zmniejszenie czasu potrzebnego na konserwację systemu. Równocześnie wzmacnia fundamenty bezpieczeństwa, zapewniając solidne i zgodne ze standardami środowisko pracy.

Niektóre z wprowadzonych nowości możecie znać z wersji 12.8 gdzie były testowane.
Zacznijmy od wybranych nowości w administrowaniu bazy danych.

Wielowątkowe tworzenie kopii zapasowych

Skrócenie czasu wykonywania kopii zapasowych ma bezpośredni wpływ na ograniczenie okien serwisowych i zwiększenie dostępności systemu. W OpenEdge 13 wprowadzono mechanizm wielowątkowego backupu, który znacząco przyspiesza operacje tworzenia kopii zapasowych baz danych w trybie offline.

Tryb wielowątkowy został ustawiony jako domyślny zarówno dla backupów offline, jak i online. Dzięki temu system automatycznie wykorzystuje dostępne zasoby CPU, co przekłada się na krótszy czas realizacji operacji. W razie potrzeby zachowanie to można skonfigurować lub całkowicie wyłączyć za pomocą narzędzia PROBKUP.

probkup [baza] … [ -thread 0 | 1 ] [ -threadnum num-threads ]

Jeśli przed wykonaniem komendy pojawia sie ostrzeżenie ESAM to wynika to stąd, że po wyinstalowaniu poprzedniej wersji nie usunąłem katalogów ESAM.

Wielowątkowe sprawdzanie indeksów (offline)

Sprawdzanie indeksów to kluczowe narzędzie administracyjne wykorzystywane do oceny stanu bazy danych, identyfikacji problemów oraz zapewnienia integralności danych. Odgrywa również istotną rolę w planowaniu i realizacji strategii odzyskiwania po awariach.

W OpenEdge 13 rozszerzono to mechanizm o możliwość wielowątkowego sprawdzania indeksów w trybie offline. Administratorzy mogą teraz równolegle walidować rekordy dla poszczególnych kluczy oraz ich kolejność, co znacząco przyspiesza cały proces.

Zarówno w trybie online, jak i offline, operacje realizowane w ramach opcji 2, 3 i 4 wykorzystują domyślnie przetwarzanie wielowątkowe — pod warunkiem, że środowisko dysponuje odpowiednimi zasobami (CPU, pamięć oraz wydajny dostęp do dysku). Dzięki temu możliwe jest równoległe wykonywanie operacji, które wcześniej były realizowane sekwencyjnie.

proutil [baza] -C idxcheck [ -thread 0 | 1 ] [ -threadnum num-threads ]

Wprowadzono ulepszenia polecenia PROUTIL IDXCOMPACT, służącego do kompresji indeksów.
Jednym z nich jest parametr -compactonly — można jej używać do kompresji drzewa indeksu wyłącznie wtedy, gdy indeks jest unikalny. Opcja ta:
– wyłącza skanowanie drzewa w poszukiwaniu symboli zastępczych usuniętych wpisów indeksu, a zamiast tego przeprowadza jego kompresję;
– wpływa na działanie operacji IDXCOMPACT w zależności od tego, czy określono również opcję -unusedblocks
Aby dokładniej zrozumieć działanie operacji warto przeczytać w dokumentacji z jakich faz składa sie kompaktowanie indexów.

Format notacji naukowej w ABL
ABL obsługuje obecnie odczyt i zapis liczb w notacji naukowej, wykorzystywanej m.in. w formatach takich jak JSON czy XML. Taki zapis umożliwia reprezentowanie bardzo małych lub bardzo dużych wartości za pomocą notacji naukowej.

Dzięki tej funkcji programiści ABL mogą uprościć swój kod i zaoszczędzić czas, eliminując konieczność tworzenia dodatkowych procedur konwersji.

Należy podkreślić, że funkcja ta nie wprowadza nowego typu danych, lecz umożliwia przetwarzanie liczb zapisanych w notacji naukowej. Po ich odczytaniu wartości są nadal reprezentowane wewnętrznie jako jeden ze standardowych typów danych ABL: INTEGER, INT64 lub DECIMAL. W dokumentacji są podane ciekawe przykłady takich liczb, ale zobaczmy dla przykładu dwie poniższe wartości.

/* Średnica czerwonej krwinki człowieka w [m] */
VAR DECIMAL RedBloodCellDiameter = 7e-6.

/* Średnica wszechświata w [m] */
VAR DECIMAL UniverseDiameter = 8.8e26.

DISPLAY RedBloodCellDiameter FORMAT "9.99999E-99".
DISPLAY UniverseDiameter FORMAT "9.99999E+99".

PAUSE.

Przy wyświetlaniu ważne jest podanie formatu. Na takim zapisie można robić konwersję z wartości znakowych.

Pisałem w zeszłym roku o integracji OE Developr’s Studio z AI Coding Assistant. Wymagało to wykonania kilku czynności. W OpenEdge 13.0 to środowisko zawiera już zintegrowanego Asystenta Kodowania AI obsługiwanego przez ChatGPT.

Inną ważną informacją jest to, że platforma .NET 8 uzyskała certyfikat zgodności z OpenEdge 13.0 zarówno dla aplikacji ABL, jak i .NET Open Client. Certyfikat ten gwarantuje, że aplikacje ABL oraz .NET Open Client po aktualizacji do .NET 8 mogą korzystać z funkcji tej platformy, pozostając jednocześnie w ramach wspieranej wersji środowiska .NET.
.NET 8 jest wersją objętą długoterminowym wsparciem technicznym (LTS), którego zakończenie planowane jest na listopad 2026 roku (od 2023 r.).

Wprowadzono jak zawsze wiele ulepszęń w dziedzinie zabezpieczeń, np. wsparcie dla FIPS 140-3.
FIPS (Federal Information Processing Standards) to zestaw standardów opracowanych przez rząd USA, określających wymagania m.in. w zakresie bezpieczeństwa danych i stosowania algorytmów kryptograficznych.

W kontekście OpenEdge ich znaczenie polega na tym, że zapewniają zgodność z uznanymi normami bezpieczeństwa. Dzięki wsparciu FIPS system może korzystać wyłącznie z certyfikowanych, bezpiecznych mechanizmów kryptograficznych, co jest szczególnie istotne w środowiskach wymagających wysokiego poziomu ochrony danych (np. w instytucjach finansowych lub administracji).

Po więcej szczegółów zapraszam do dokumentacji.

Administracja, Development, Info ogólne

Promon 4 – strojenie sieci

W środowisku aplikacji wielowarstwowej komunikaty sieciowe są nieustannie przesyłane pomiędzy klientami zdalnymi a serwerem bazy danych. Komunikacja sieciowa może stanowić potencjalne wąskie gardło, które negatywnie wpływa na wydajność systemu.
Podczas pracy bazy danych należy proaktywnie monitorować parametry komunikacji sieciowej. W przypadku zauważenia jej pogorszenia warto rozważyć dostrojenie odpowiednich parametrów, aby poprawić wydajność.

Aby skutecznie monitorować wydajność komunikacji w czasie, należy najpierw ustalić punkt odniesienia (baseline), obejmujący m.in.:
– czas reakcji operacji pobierania danych,
– liczbę komunikatów sieciowych wysłanych i odebranych w ramach pojedynczego zapytania.

Jeżeli w trakcie dalszego monitorowania zaobserwujesz wydłużenie czasu reakcji na zapytania lub istotny wzrost liczby wysyłanych i odbieranych komunikatów sieciowych, może to oznaczać konieczność dostrojenia parametrów komunikacji w celu przywrócenia optymalnej wydajności.

Podstawowym parametrem jest tutaj rozmiar komunikatu sieciowego, w którym przesyłane są rekordy -Mm. Jeśli zaobserwujesz wzrost liczby wysyłanych i odbieranych komunikatów sieciowych lub wydłużenie czasu odpowiedzi na zapytanie, warto rozważyć zwiększenie wartości parametru –Mm. Większy rozmiar bufora komunikatów pozwala przesyłać więcej rekordów w ramach mniejszej liczby komunikatów, co ogranicza fragmentację rekordów pomiędzy pakietami i może przełożyć się na poprawę czasu odpowiedzi. Zaleca się ustawić wartość -Mm na 8192 i taka wartość domyslna jest w OE 12.

Należy pamiętać, że aby zmienić rozmiar bufora komunikatów trzeba zamknąć serwer bazy danych.
Od wersji OpenEdge 11.6 w przypadku rozbieżności między ustawieniem parametru –Mm po stronie serwera i klienta, pierwszeństwo ma wartość określona na serwerze, a wartość po stronie klienta ustawi się automatycznie na taką samą jak na serwerze. We wcześniejszych wersjach OE sygnalizowany był błąd.

Kilka kolejnych parametró strojenia komunikacji sieciowej bazy danych zostało wprowadzonych w systemie OpenEdge w wersji OE 10.2B oraz 11.1. Ich celem jest poprawienie wydajności komunikacji sieciowej, szczególnie w dużych instalacjach.

Umożliwiają one precyzyjne dostrojenie mechanizmu pakowania komunikatów dla zapytań typu prefetch, a także regulację częstotliwości wywoływania funkcji systemowej poll().

Poniższe parametry uruchamiania bazy danych są dostępne wyłącznie w ramach licencji Enterprise i mogą być strojone online:

  • -prefetchDelay – po włączeniu tego parametru (nie ma on wartości) serwer przed wysłaniem do klienta pierwszego komunikatu sieciowego z pierwszym rekordem wypełnia go większą liczbą rekordów. Dzięki temu zmniejsza się liczba przesyłanych komunikatów, co przekłada się na lepszą wydajność. Włączając ten parametr trzeba ustawić przynajmniej jeden z dwóch poniższych, określających jak mają być wypełnione komunikaty.
  • -prefetchFactor – parametr ten określa stopień (w %) wypełnienia komunikatu przed wysłaniem go do klienta. Zalecaną wartością jest 100.
  • -prefetchNumRecs – określa liczbę rekordów umieszczanych w komunikacie przed jego wysłaniem przez sieć. Dopuszczalny zakres mieści się w przedziale od 1 do 32 766. Z reguły im więcej rekordów można umieścić w pojedynczym komunikacie, tym wydajniejsze jest ich pobieranie, co pozytywnie wpływa na ogólną wydajność bazy danych.
  • -prefetchPriority – To dość ciekawy parametr. Po ustawieniu powyższych parametrów typu prefetch, serwer działa domyślnie w następujący sposób: kopiuje pierwszy rekord zapytania do bufora komunikatów, a następnie sprawdza, czy inni użytkownicy zgłaszają jakieś żądania. Jest to tzw. mechanizm poll(). Jeśli nie ma innych żądań, serwer kopiuje kolejny rekord do bufora komunikatów i ponownie sprawdza kolejkę żądań. Jeśli pojawi się żądanie od innego użytkownika, serwer przetwarza je, wstrzymując tymczasowo obsługę zapytania prefetch. Po zakończeniu jego obsługi wraca do kopiowania kolejnych rekordów.

    Mechanizm poll() generuje stosunkowo duże obciążenie procesora systemowego. Z kolei samo kopiowanie rekordów zapytania do bufora komunikatów powoduje znacznie mniejsze obciążenie CPU.

    Z tego względu bardziej efektywne jest skopiowanie kilku lub więcej rekordów do bufora przed kolejnym sprawdzeniem nowych żądań użytkowników. W tym celu można użyć parametru –prefetchPriority, który określa liczbę rekordów prefetch dodawanych do bufora bez wywoływania mechanizmu odpytywania.

    Dzięki temu zapytanie prefetch zyskuje wyższy priorytet względem nowych żądań z innych połączeń zdalnych.

    Zastosowanie parametru –prefetchPriority pozwala zmniejszyć obciążenie procesora systemowego kosztem większego wykorzystania procesora po stronie użytkownika, co w praktyce może przełożyć się na poprawę ogólnej wydajności bazy danych. Dobrą wartością tego parametru jest 100.

  • -Nmsgwait – określa liczbę sekund, przez które serwer zdalny czeka na zdalny komunikat sieciowy przed sprawdzeniem innych zdarzeń, takich jak quiet point w bazie danych, wyłączenie (shutdown) lub wymuszone wyłączenie (forced shutdown) zdalnego klienta. Domyślna dobra wartości tego parametru wynosi 2 sekundy.

Parametry te możemy stroić w promonie: R&D -> 4. Administrative Functions -> 7. Server Options
Pamiętajmy, żeby wystartować serwer z parametrem -S [numer portu/nazwa serwisu]. Proces klienta też musi być wystartowany z parametrem -S.


Do monitorowania napiszmy procedurę zawierającą proste zapytanie do bazy sports2000, którą uruchamiamy z poziomu zdalnego klienta.

// timer.p
DEFINE VARIABLE i AS INTEGER NO-UNDO.

// Start stopera
i  = ETIME(YES).

FOR EACH customer NO-LOCK:
END.

// Złapanie czasu
i  = ETIME.
MESSAGE i " milisekund"
    VIEW-AS ALERT-BOX INFORMATION BUTTONS OK.

W celu monitorowania wchodzimy w promonie: R&D -> 2. Activity -> Servers
Najpierw naciskamy “z” żeby wyzerować liczniki, potem uruchamiamy procedurę i wreszcie naciskamu “u” dla uaktualnienia statystyk.

W menu ustawienia opcji serwera naciśnijmy 2 a następnie wartość 0, żeby wyłączyć opcję prefetch. Enabled zmieni się w Disabled. Uruchamiamy ponownie procedurę i uaktualniamy statystyki, jak poprzednio. Widzimy, że liczba komunikatów nieznacznie się zwiększyła, ale to w końcu proste zapytanie i niezbyt duża ilość rekordów.

Na koniec zmienię rozmiar parametru -Mm z 8192 do 1024 B. Robimy to oczywiście na zamkniętej bazie i powtarzamy test.

Widać wielokrotne zwiększenie liczby komunikatów. Czas wywołania procedury zwiększył się z 6 ms do ok. 20 ms. Ilość komunikatów rzadko kiedy zmienia się proporcjonalnie do rozmiaru -Mm. W końcu transfer sieciowy jest oparty o protokół tcp, a ten z kolei ma swoje mechanizmy i tzw. Maximum Transfer Unit, więc komunikaty z bazy mogą byc dzielone na mniejsze, ale znamy już podstawowe sposoby strojenia od strony OpenEdge’a.

Administracja , ,