28 maja w hotelu Royal Tulip Warsaw Centre odbyło się kolejne spotkanie World Tour.
Tym razem Dyrektor Regionu Europy Środkowo-Wschodniej, Thomas Schuller nie mógł uczestniczyć i rolę prowadzącego przejął Bartosz Żelek, a nad całością organizacyjną czuwał Michael Ryan.
Na poprzednich spotkaniach łączyliśmy się podczas sesji z naszymi konsultantami żeby wysłuchać prezentacji lub obejrzeć demo w sposób zdalny i w języku angielskim. Tym razem postanowiliśmy, że trzy prezentacje będą nagrane wcześniej, a sztuczna inteligencja dokona transkrypcji nagrań na język polski.
Lista wszystkich wystąpień prezentowała się następująco:
The Future of OpenEdge Is Bright – Bartosz Żelek
OpenEdge 13 & OpenEdge Roadmap – Piotr Tucholski
The Time is Now for the Progress OpenEdge Platform – Andrea Drees – Video z lektorem AI PL
Unleash the Power of AI for Your Business – Stefan Bolte – Video z lektorem AI PL
Accelerate ABL Development with AI – Roland de Pijper – Video z lektorem AI PL
Securing your Progress OpenEdge Applications – Piotr Tucholski
Byliśmy z Bartkiem bardzo ciekawi jak odebrano zwłaszcza nagrania z AI. Zdania były podzielone, ale jeśli chodzi o drugie i trzecie wystąpienie, przeważały opinie pozytywne. Prezentacje te dotyczyły zresztą ciekawych rozwiązań, polegających na integracji OE i AI i po polsku łatwiej można było przyswoić sobie te nowe tematy.
Ja zanotowałem ciekawe pytania odnośnie maskowania danych (DDM) i postanowiłem napisać następny artykuł jako rozwinięcie podstaw technologii, o której pisałem niedawno.
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.
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.
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).
Wracamy do tematu związanego z użyciem Memory Profilera, dostępnego od wersji OE 12.8.9.
W poprzednim artykule pokazałem jak zainstalować i uruchomić to narzędzie.
Startujemy zatem MP, który jest instancją PASOE komendą: oemp startup
Teraz przygotujemy prosty plik konfiguracyjny mpconfig.cfg, zawierący informacje co ile ma odbyć się zrzut pamięci (cadence = 5 sek.) i do którego katalogu. Parametrów może być więcej ale na razie te wystarczą. mpconfig.cfg
cadence 5
report-dir ./mpfiles
Można w ogóle pominąć te ustawienia i wtedy zrzut będzie odbywać się domyślnie co 10 sek. do aktualnego katalogu roboczego.
W AVM profilowanie pamięci włącza się za pomocą parametru -profileMemory.
Startuję sesję edytora prowin ./db/t -1 -profileMemory mpconfig.cfg
Jako przykład wezmę aplikację wykorzystywaną kiedyś podczas szkolenia z dynamicznych obiektów baz danych. Składa się z dwóch okienek wyswietlających dane dla dowolnych wybranych tabel, pól i zapytania. Uruchamiam aplikację i wybieram różne dane dla dynamicznych obiektów. Powtarzam cały proces jeszcze raz. Kończę sesję – w katalogu ./mpfiles wygenerowały się pliki.
Wchodzę do narzędzia MP podając w przeglądarce adres http://localhost:8880.
Widać od razu następujący komunikat: Displays all the memory profiler recording files from the watched directories: C:/WrkOpenEdge128/oemp/upload, C:/WrkOpenEdge128/oemp/import
Kopiuję zatem do katalogu .oemp/upload te pliki .oem, których zawartośc chcę wyświetlić.
WYbrany plik najpierw trzeba zaimportować, klikam na przycisk Import, a następnie Review.
Otrzymuję wykres zmian pamięci aplikacji w funkcji czasu. Poniżej znajdują się dane dla wyswietlanej próbki.
Nazwa aplikacji _edit jest stąd, że uruchomiłem najpierw sesję edytora. Gdybym chciał rozróżnić nazwy trzeba uruchomić sesję bezpośrednio z parametrem -p [nazwa procedury.p].
Na zakończenie dodam, że zrzuty pamięci można realizować programowo wstawiając odpowiednie komendy w wybranych miejscach w kodzie. Tę metodę powinno się stosować kiedy podejrzewamy gdzie może być wyciek pamięci. Do tego tematu jeszcze powrócę.
W OpenEdge od wersji 12.8.9 mamy długo oczekiwane narzędzie Memory Profiler.
Umożliwia ono analizę wykorzystania pamięci przez aplikację w funkcji czasu a także w określonych interwałach, umożliwiając wizualizację wykorzystania pamięci przez kod aplikacji.
Wycieki pamięci występują, gdy aplikacja nie zwalnia niepotrzebnej już pamięci. W konsekwencji wykorzystanie jej przez aplikację rośnie z czasem, co może prowadzić do spadku wydajności, a ostatecznie do wyczerpania zasobów pamięci i awarii aplikacji lub systemu. Wycieki pamięci są szczególnie problematyczne w długo działających aplikacjach lub systemach wymagających wysokiej wydajności i niezawodności działania.
Memory Profiler zapewnia wizualizację wykorzystania pamięci i pomaga programistom ABL w skutecznym wykrywaniu i diagnozowaniu problemów z wykorzystaniem pamięci w ich aplikacjach ABL.
Korzyści płynące z używania narzędzia:
Identyfikacja wycieków pamięci — poprzez śledzenie nadmiernego zużycia pamięci i identyfikację wykorzystania pamięci w celu poprawy wydajności aplikacji.
Zwiększenie stabilności systemu i aplikacji — śledząc wykorzystanie pamięci, które nie jest zwalniane w działających aplikacjach lub w fazach testowania, zapobiegając w ten sposób potencjalnym awariom i niestabilności systemu w środowiskach produkcyjnych.
Debugowanie złożonych problemów — udostępniając statystyki i wizualizację, które upraszczają proces debugowania i przyspieszają rozwiązywanie problemów związanych z pamięcią.
Zapewnienie stosowania najlepszych praktyk — identyfikując obszary wymagające odpowiednich operacji czyszczenia i zachęcając do stosowania efektywnych praktyk kodowania.
Z technicznego punktu widzenia to narzędzie jest specjalną instancją PASOE, którą możemy utworzyć korzystając z dostarczonych plików.
Spakowane pliki te znajdują sie w katalogu [DLC]/servers/redist/oemp-[wersja oe].zip (np. oemp-12.8.9.zip).
Plik zip kopiujemy do jakiegoś katalogu z pełnymi uprawnieniami i rozpakowujemy, przechodzimy do podkatalogu oemp\bin, a następnie w oknie komend proenv uruchamiamy komendę oemp install.
Należy pamiętać żeby katalogiem, w którym umieścimy pliki nie byl podkatalog oemp w lokalizacji working directory ponieważ pojawi się wtedy poniższy błąd:
Jak wybrałem podkatalog c:\oemp i wszystko poszło jak po maśle.
Proces instalacji jest dość długi, u mnie trwał prawie 5 minut.
Po zakończonej instalacji mamy nową instancję PASOE oemp, która odwołuje się do bazy danych /db/reportdb. Narzędzie startujemy poleceniem: oemp startup.
Kiedy instancja jest już uruchomiona, wpisujemy następujący URL w przeglądarce: http://localhost:8880 i dostajemy główny widok Memory Profilera.
Niedługo napiszę jak korzystać z OE Memory Profilera.
W niniejszym wpisie chciałbym przedstawić krótką historię Progress Software. Historię której nie powstydziłyby się takie firmy jak Microsoft czy Apple.
Cofniemy się aż do poczatku lat 80-tych, w więc czasów, gdy pracowało się bez Internetu i twardych dysków…
Przyjrzymy się najważniejszym elementom dodawanym i rozwijanym w poszczególnych wersjach aż do dnia dzisiejszego.
Kiedyś, w czasach jeszcze przed pandemią gdy spotkania i szkolenia rzadko były w formie zdalnej byłem dość często pytany o to kiedy pojawił się jakiś element w Progressie; np. od jakiej wersji jest binarny zrzut danych, zniesiony limit rozmiaru plików, kiedy pojawiły się dynamiczne obiekty itp., itd.
Informacje te nie mają znaczenia gdy chcemy pracować na najnowszej technologii. Jednak w tym artykule chodzi o to, że takie informacje są ciekawą historią rozwoju technologii, dlatego cofniemy się w czasie do samego początku Progressa, a więc do pierwszej wersji komercyjnej 2. Okazało się, że zdobycie takich informacji nie jest wcale proste. Dlatego niniejszy tekst nie należy traktować jako kompletne źródło informacji, lecz jako tekst „otwarty” zawierający tyle danych, ile udało się zgromadzić.
Podręcznik wersji 4. z 1987 r. Widać zmienioną już nazwę na Progress Software Corporation
Progress Software Corporation powstał w 1981 roku jako Data Language Corporation. Dlatego nazwa DLC obowiązuje do dziś jako domyślny katalog instalacji do wersji 9. Pierwszy zespół składał się z założycieli: Josepha W. Alsopa, Chipa Zieringa i Clyde’a Kessela wraz z pierwszym pracownikiem Mary Szekely. Pierwszy produkt nazywał się „Relational Data Language”, w skrócie RDL, wymawiany „riddle” (w tłum. na polski – zagadka). Biuro mieściło się w Billerica, w stanie Massachusetts, w starym gabinecie dentystycznym. Większość początkowych prac projektowych powstało na stole w jadalni Mary Szekely przy użyciu komputera PC-AT, ze stacją dyskietek i bez twardego dysku.
W 1983 RDL był pokazany na COMDEX (Computer Dealers’ Exhibition w Las Vegas). Nie był to jeszcze produkt komercyjny i zawierał proste narzędzie napisane w języku 4GL, pozwalające na definiowanie tabel, pól i indeksów.
Pierwsza wersja komercyjna produktu pojawiła się w 1984 pod zmienioną nazwą Progress Version 2. Posiadała zaawansowane jak na ówczesne czasy cechy jak obsługę skompilowanych plików .r czy niepełną obsługę konfiguracji klient/serwer. Interfejs użytkownika był wyłącznie znakowy i zawierał kompletne narzędzia napisane w języku 4GL: słownik baz danych (do tworzenia schematu baz) oraz narzędzie do administracji.
Większość podstawowych elementów tej wersji przeszła wiele udoskonaleń i jest obecna w dzisiejszych produktach. Progress w V2 działał na różnych systemach UNIX i DOS.
Progress V3 (1985) – wersja zawierała pierwsze elementy zapowiadające nadejście graficznego interfejsu jak nakładające się ramki, pozwalające wyświetlać różne rodzaje informacji, czy zaznaczanie fragmentów tekstu innym kolorem. Narzędzie do administracji zyskało możliwość zrzutu i ładowania danych do/z innych popularnych wówczas produktów jak dBase czy Excel. Sama firma przeniosła się do „prawdziwego” biura w Billerica.
Progress V4 (1987) – Firma Data Language Corporation przyjęła nazwę swojego produktu, przekształcając się w Progress Software Corporation. W tym samym czasie powstały przedstawicielstwa w Europie. Rozwój aplikacji stał się możliwy na platformach VAX/ VMS, BTOS oraz DOS i UNIX. Data Dictionary wzbogacono o funkcje bezpieczeństwa (security), tak aby deweloperzy mogli zdefiniować uprawnienia do plików bazy.
Box z wersją 5
Progress V5 (1988) – Powstało narzędzie Fast Track, służące do generowania aplikacji. Data Dictionary został poddany gruntownej renowacji. Wszystkie funkcje związane z administrowaniem zostały udoskonalone, włączając obsługę przyrostowego zrzutu i ładowania danych. Wersja zawierała także możliwość jednoczesnego przyłączenia kilku baz oraz pełną obsługę konfiguracji klient-serwer.
Progress V6 (1990) – Pojawił się produkt Data Server (nazwany Gateway) do obsługi innych baz jak Oracle, Sybase czy RMS. Wersja zawierała znakową wersję Results – produktu 4GL do generowania raportów i zapytań.
Progress V6.3 (1991) – W 10. rocznicę powstania, Progress Software Corporation osiągnął znaczącą poprawę wydajności baz danych, wprowadzając procesy asynchroniczne (asynchronous page writers). Firma przeniosła siedzibę do Bedford, w stanie Massachusetts, w której pozostaje do dziś.
Progress V7 (1993) – Deweloperskie środowisko klienckie zostało całkowicie zmodernizowane, w celu przystosowania go do nadchodzących zmian związanych z interfejsem graficznym. Proceduralny model programowania został zmieniony, tak aby mógł obsługiwać model oparty na zdarzeniach. Dodano przy tym wiele konstrukcji językowych do definiowania i obsługi różnych obiektów graficznych budowanego interfejsu w systemie Windows (oraz Motif).
V7 zawierała nowy zestaw narzędzi deweloperskich zwany Application Development Environment (ADE). Wprowadzono tablice tymczasowe i wiele wizualnych elementów, które można było przesuwać i zmieniać ich wymiary. Edytor trygerów był na początku prostym oknem dialogowym, w którym można było napisać kod do obsługi obiektów, a tablica TRG przechowywała ten kod w pamięci.
Graficzne środowisko, a w szczególności główne narzędzie deweloperskie UIB (User Interface Builder) ewoluowało i w swej ostatecznej postaci zawierało Section Editor – edytor do pisania kodu dla wybranej sekcji programu, generowało kod, reprezentujący także wszystkie elementy graficzne wstawione do interfejsu, tworzyło definicje zapytań dla tablic użytych w każdym oknie czy ramce, a także kod do obsługi tych zapytań.
Dokumentacja do V5
ADE składało się przede wszystkim z narzędzi graficznych: Data Dictionary, Data Administration, UIB i Procedure Editor. Do tego doszedł Results, napisany od nowa dla pracy w trybie graficznym, oraz Report Builder – narzędzie do tworzenia bardziej wymagających raportów. W V7 pojawił się także Translation Manager, do obsługi aplikacji wielojęzykowych.
Progress V7.3 (1995) – Dalszy rozwój graficznego środowiska programistycznego. Wprowadzono zestawy szablonów, definicje pre-procesora, umożliwiające pisania uniwersalnych bloków kodu dla obiektów. Znaczącym elementem jest dodanie do języka 4GL składni pozwalającej na uruchamianie procedur w trybie PERSISTENT, umożliwiający pozostawanie procedury w pamięci do końca sesji (lub ich jawnego usunięcia) i zastosowanie technik quasi-obiektowych (uruchamiania instancji obiektów, wywoływania metod). Środowisko deweloperskie zostało wzbogacone o zestaw prostych narzędzi ProTools. Zestaw ten był systematycznie rozszerzany w kolejnych wersjach Progressa.
Progress V8 (1995) – Idea implementacji technik obiektowych w środowisku deweloperskim została rozwinięta w wersji 8, która zawierała Progress Application Development Model (ADM) i SmartObiekty. Technologia SmartObiektów polegała na tworzeniu interfejsu aplikacji z komponentów (okno, ramka, browser itp.) typu PERSISTENT. W modelu ADM dodano także mechanizm definiowania zdarzeń proceduralnych i zachowania obiektów oraz wprowadzono standaryzację komunikacji między nimi. Pojawił się system do tworzenia i obsługi internetowego interfejsu aplikacji – WebSpeed. Składał się z dwóch głównych produktów: Transaction Servera, odpowiedzialnego za komunikację i działanie aplikacji ,oraz Workshopa – narzędzia deweloperskiego. Późniejsza wersja 8 (1997-od tego roku zacząłem pracę z produktami Progress, którą kontynuuję do dziś :-)) wprowadziła po raz pierwszy serwer aplikacji (AppServer), posiadający tryby pracy: state-aware i state-reset. W 1999 powstało polskie przedstawicielstwo Progress Software w Warszawie na ul. Płowieckiej.
Progress V9 (1998) – Wprowadzono wielki zmiany w stosunku do poprzednich wersji z punku widzenia zarówno tworzenia aplikacji, jak i wydajności baz danych. Zaimplementowano w języku 4GL obsługę przesyłania powiadomień PUBLISH/SUBSCRIBE oraz definiowanie tzw. superprocedur dla wybranych procedur lub sesji. Techniki te rozwinęły obiektowość języka 4GL; wykorzystano je w nowym modelu ADM2. Model ten umożliwia tworzenie aplikacji rozproszonych (z wykorzystaniem AppServera) i odseparowanie warstwy interfejsu od źródła danych. W miejsce narzędzia
UIB powstał bardziej zaawansowany AppBuilder. Z ważniejszych jego funkcji należy wymienić integrację z WebSpeedem i wydajniejsze tworzenie aplikacji internetowych. Edytor zyskał funkcjonalność zaznaczania kolorem pisanej składni. W języku 4GL dodano implementację dynamicznych obiektów, zarówno graficznych (okna, ramki, browsery, przyciski, menu itp.) jak i związanych z przechowywaniem danych (bufory, pola,
tablice tymczasowe, zapytania). Wprowadzono technologię OpenClient i narzędzie ProxyGen (generator proxy) dając możliwość przyłączenia do logiki biznesowej 4GL interfejsu stworzonego w innej technologii (Java, ActiveX). Rozwinięto produkt AppServer, wprowadzając tryb pracy stateless. Zaimplementowano obsługę standardu XML (model DOM).
W późniejszej wersji 9.1D (2002) dodano nowy debugger graficzny oraz wczytywanie danych XML w modelu SAX (SAXReader).
Dokumentacja narzędzia Fast Track
V9 zawierała nową technologię WebClient, która dała możliwość generowania graficznego interfejsu po stronie klienta i łączenia się ze zdalną bazą (za pośrednictwem AppServera) przez Internet (interfejs miał postać aplikacji graficznej 4GL i był darmowy). Na bazie rozszerzonych możliwości języka powstała platforma do tworzenia graficznego interfejsu aplikacji – Dynamics. Interfejs tworzony jest w sposób dynamiczny, przy wykorzystaniu parametrów przechowywanych w specjalnej bazie – tzw. repozytorium (9.1A).
Niezwykle ważną cechą V9 było wprowadzenie nowej struktury baz danych. Wprowadzono tzw. Obszary Przechowywania Danych Typu I, z których każdy można porównać do wcześniejszej bazy wielo-wolumenowej. Każdy taki obszar może zajmować wybrane obiekty bazy i posiadać określone parametry (np. liczbę rekordów w bloku). Nowa architektura przyczyniła się do zwiększenia możliwości projektowanej bazy, lepszego dobrania jej parametrów w stosunku do charakteru danych, praktycznie nieograniczonej ilości przechowywanych informacji oraz lepszej wydajności. Znacznie usprawniono proces odbudowy indeksów oraz dodano obsługę dużych plików (większych od 2GB). Wprowadzono obsługę strony kodowej UTF-8 dla baz oraz klienta wsadowego. Pojawił się silnik SQL92 wbudowany w serwer baz (systematycznie rozwijany w kolejnych wersjach), narzędzie do monitorowania systemów baz danych z konsoli WWW – Fathom Management (znane później jako OpenEdge Management), produkt do replikacji bloków AI z bazy głównej do zapasowej w czasie rzeczywistym – Fathom Replication (później OpenEdge Replication) oraz oprogramowanie wspomagające architekturę klastrową (Failover Clusters).
OpenEdge 10 (2003) – PSC zamiast kolejnej wersji Progress V10, wprowadził produkt OpenEdge (numeracja pozostała bez zmian), który był kontynuacją V9. Celem platformy OpenEdge jest budowanie w łatwy i przejrzysty sposób zaawansowanych aplikacji biznesowych, integracja z nowopowstającymi technologiami oraz wysoka wydajność systemu baz danych. Wprowadzone zostały Obszary Przechowywania Danych Typu II, różniące się od Typu I możliwością zdefiniowania tzw. klastra danych, czyli n sąsiadujących bloków należących do jednego obiektu bazy. Poprawiono wydajność odbudowy indeksów wprowadzając m.in. definiowanie liczby grup sortowania (-SG) oraz buforów (-B). Dodano typy danych: BLOB, CLOB, DateTime, DateTime Timezone. Z punktu widzenia integracji został zaimplementowany OpenEdge adapter dla Sonica ESB oraz technologia wywoływania Web Serwisów z aplikacji OpenEdge a także wystawiania progressowej logiki biznesowej w postaci Web Serwisów. AppServer zyskał kolejny tryb pracy – state-free. W języku 4GL wprowadzono w ProDatSety – obiekty zawierające jedną lub kilka tablic tymczasowych, relacje między nimi i obsługę zdarzeń. Oprócz dodania nowych możliwości do kodowania logiki biznesowej, wspomagają one wymianę informacji przez WebSerwisy i są ważnym elementem architektury OERA. W technologii OpenClient .NET zastąpił ActiveX. Wdrożono obsługę strony kodowej UTF-8 dla klienta graficznego.
Box z wersją 6
OpenEdge 10.0B (2004) – Zwiększono bezpieczeństwo danych na dwóch poziomach. Po pierwsze wprowadzono szyfrowanie transmisji między procesami (klienta, serwera, AppServera itd.), obsługę certyfikatów, zarządzanie kluczami szyfrowania. Po drugie zaimplementowano w język instrukcje pozwalające deweloperowi decydować o wyborze szyfrowanych danych i ich wykorzystaniu.
OpenEdge 10.1A (2005) – Znów pojawiły się duże zmiany. Pierwszą z nich to OpenEdge Architect – nowe zintegrowane środowisko deweloperskie (IDE) do projektowania, testowania i wdrażania aplikacji OpenEdge, oparte na platformie Eclipse. Został zaprojektowany aby poprawić łatwość i wydajność tworzenia nowoczesnych aplikacji biznesowych. Poza AppBuilderem pozostałe narzędzia: edytor, debugger, DB Navigator (zastępujący słownik) zyskały nowy wygląd i funkcjonalność. Zaimplementowane zostały rozszerzenia języka obiektowego. Chodzi tu o „obiektowość” z prawdziwego zdarzenia z enkapsulacją, dziedziczeniem, polimorfizmem. Tak rozszerzony język zyskał nową nazwę: Advanced Business Language (ABL). Trzecią nowością był Auditing – zintegrowany i w pełni konfigurowalny serwis stworzony do kontrolowania zdarzeń w bazach danych OpenEdge, narzędziach bazodanowych oraz aplikacjach ABL i SQL. W technologii XML pojawił się obiekt SAX-Writer. Nowości objęły także administrowanie bazami danych.
Należy wymienić po pierwsze AI Management – usługę związaną z automatycznym zarządzaniem ekstentami after-image. Zastosowano wielowątkowy zrzut danych i odbudowę indeksów, a także możliwość dodawania ekstentów w trybie online.
OpenEdge 10.1B (2007) – Wprowadzono zmiany szczególnie istotne z punktu widzenia architektury baz danych. Dodano nowy 64-bitowy typ danych INT64, co umożliwiło wprowadzenie: obsługi dużych wartości kluczy indeksowych, 64-bitowe klucze adresowania (dla obszaru Typu II), 64-bitowe wartości sekwencji. Podniesiono maksymalny limit obszarów oraz maks. rozmiar pamięci dzielonej. Zrealizowano mechanizm umożliwiający skopiowanie uprawnień użytkowników zdefiniowanych w bazie z fazy kompilacji do runtime’u. Rozszerzono instrukcję wykonania backupu online o opcję włączenia zapisu AI.
V7 – narzędzie User Interface Builder
OpenEdge 10.1C (2008) – OE 10.1C wprowadził do języka ABL składnię do Structured Error Handling – obsługę błędów charakterystyczną dla obiektowych języków programowania jak Java czy C++. Rozwinięto możliwości komunikacyjne poprzez włączenie protokołu IPv6 (Internet Protocol V6). Od OE 10.1C Administratorzy baz mogą zwiększać wartości następujących parametrów online: -B, -bibufs, aibufs, -L, -Mxs. Dodano nowe elementy do OOP, XMLa, ProDataSetów, OpenEdge Architecta.
OpenEdge 10.2A (2009) – Najważniejszą „rewolucyjną” zmianą była implementacji obiektów .NET z interfejsem języka ABL. Na platformie OpenEdge Architect dodano narzędzia dedykowane do budowy interfejsu aplikacji z wykorzystaniem takich obiektów:
• Visual Designer – edytor WYSIWYG dla tworzenia aplikacji metodą „przeciągnij i upuść”, wspierający obsługę obiektów .NET.
• Class browser, wspierający obsługę klas .NET.
• Wprowadzono rozszerzenia Edytora ABL o nowe cechy UI.
Zastosowano ulepszone metody zapisu/odczytu danych XML do/z ProDataSetów, redukujące rozmiar plików i obciążenie sieci. Wprowadzono OpenEdge Explorer – narzędzie do zarządzania procesami z poziomu przeglądarki internetowej, oparte na interfejsie OpenEdge Management. Ulepszono Data-Server dla Oracle i Microsoft SQL Server. Zmodernizowano Adapter dla SonicMQ.
V7 – narzędzie Results
OpenEdge 10.2B (2010) – W celu umożliwienia budowania bezpieczniejszych aplikacji wprowadzono w OpenEdge Enterprise RDBMS – Transparent Data Encryption (TDE). Zapewnia to szyfrowanie danych, znajdujących się w plikach: baz danych, backupach, plikach zrzutu binarnego. TDE wykorzystuje biblioteki szyfrowania zgodne ze standardami PCI, stosowane przez firmy przetwarzające informacje z kart kredytowych. TDE w minimalnym stopniu wpływa na koszt i czas rozwoju aplikacji. Nie jest wymagana jakakolwiek zmiana samej aplikacji a zarządzanie szyfrowaniem odbywa się niezależnie od kodu ABL. TDE ma minimalny wpływ na wydajność – ok. 5% dla typowych aplikacji OLTP. Deweloperzy mogą teraz przy pomocy składni ABL odczytywać/zapisywać dane ProDataSetów i tablic tymczasowych z/do obiektów JSON. Umożliwia to tworzenie aplikacji typu RIA (Ajax-based Internet Applications), zwiększając ich dostępność poprzez sieć internetową. Zaimplementowano pełne wykorzystanie możliwości .NET z poziomu ABL.
OpenEdge 11 to przede wszystkim nowy serwer aplikacji nazwany najpierw Pacific Application Server, a ostatecznie PASOE (Progress Application Server for OpenEdge). Będzie miał on duży wpływ na migrację aplikacji. W tej wersji oba serwery sa dostępne, ale zapowiedziano, że w następnej wersji nie będzie już klasycznego AppServera. W OE 11 rozwinęły się różne techniki tworzenia aplikacji webowych z wykorzystaniem PASOE i systemy zabezpieczeń bazujące na Spring Security. Powstał produkt OE Authentication Gateway oraz wiele innych udoskonaleń.
Różne książki o Progressie
W OpenEdge 12 Progress reklamował przede wszystkim nowy serwer baz danych, który obsługuje klientów zdalnych wielowątkowo oraz realizujący złączenia tabel (server-side joins). Udoskonalono mechanizm BHT (Buffer Hash Table), zmniejszając liczbę konfliktów dostępu do pamięci dzielonej. Usprawniono technologię serwera replikacji. Systematycznie dodawane są elementy w programowaniu obiektowym. Stworzono następcę mało wydajnego w rozproszonych systemach OE Management – OpenEdge Command Center (OECC). Progress wspiera integrację z niektórymi wiodącymi technikami, i tak w OECC można wykorzystać Open Telemetry oraz produkty z grupy APM (Application Performance Monitorong). Dalej rozwijany jest PASOE. W bazach danych można przeładować tabelę online lub jej fragment itd.
Nowa wersja OE 13 również zapowiada się ciekawie, o czym będę pisać zapewne na początku przyszłego roku. Jeśli ktoś jest zainteresowany większą ilością szczegółów począwszy od OE 11, to może prześledzić artykuły od 2015 (tak, tak, to już 10 lat!).
Na zakończenie chciałbym serdecznie podziękować Gusowi Björklundowi, Danowi Foremanowi i wszystkim, którzy nadesłali archiwalne zdjęcia.
20 maja w hotelu Royal Tulip Warsaw Centre miało miejsce kolejne spotkanie World Tour. Podobnie jak roku temu przybyło wielu naszych gości, a gospodarzami byliśmy my, czyli: Thomas Schuller – Dyrektor Regionu Europy Środkowo-Wschodniej, Bartosz Żelek i Piotr Tucholski (czyli autor bloga). Przygotowaliśmy następujące prezentacje (moje są do pobrania w formacie pdf).
Progress Business Update – Thomas Schuller
Uncovering the Hidden Value of Your OpenEdge Investment – Bartosz Żelek
World Tour 2024 to seria spotkań użytkowników Progressa na całym świecie. 11 kwietnia zawitał ponownie do Warszawy (pamiętacie tę imprezę z 2023 roku?), a jego miejscem był Holiday Inn.
Spotkanie uświetniło przybycie ok. 20 gości, a gospodarzami byli z ramienia Progressa: Thomas Schuller – Dyrektor Regionu Europy Środkowo-Wschodniej, Bartosz Żelek (jego przedstawiać chyba nie trzeba) i Piotr Tucholski (czyli ja). Przygotowaliśmy kilka prezentacji, które odbyły się w następującej kolejności:
Progress Business Update & MarkLogic Introduction – Thomas Schuller
The 4 Key Pillars of OpenEdge – John Ainsworth – prezentacja online
Prezentacja SIG – Software Improvement Group – Roland de Pijper – prezentacja online
Edukacja OpenEdge – Bartosz Żelek
Doświadczenia z migracji do OpenEdge 12 – Wiesław Kurzątkowski, Novum
Chciałbym zwrócić szczególna uwagę na ostatnią prezentację, ponieważ była przygotowana przez naszego partnera, firmę Novum z Łomży i dotyczyła praktycznej strony migracji ich systemu z technologii OpenEdge 10 do 12. Następne spotkanie ma się odbyć za rok i jeśli ktoś z Was chciałby pokazać własną prezentację to myślę, że byłaby to ciekawa pozycja w agendzie.
Po ostatniej prezentacji był czas na rozmowy i drinki.
Firma Novum w akcji. Butelki na stole zawierają zwykłą wodę, osobiście sprawdzałem.
A tutaj większość uczestników naszej imprezy (część osób śpieszyła się na pociąg). W środku Thomas Schuller.
Zapraszamy za rok!
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:
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.
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.
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.
