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.
OpenEdge 12.5, to kolejna wersja z serii non-LTS Release – skierowana do tych, którzy czekają na wszelkie nowinki techniczne. Przedstawię tutaj pokrótce niektóre z nich.
Niedawno pisałem o nowym darmowym produkcie OpenEdge Command Center. Z wersją 12.5 możemy pobrać OECC w wersji 1.1, dzięki której możemy uzyskać informacje nie tylko o stanie poszczególnych instancji PASOE, ale także o ich aplikacjach. Po lewej stronie na głównym panelu widać nową ikonę (podświetlona na niebiesko) – po kliknięciu w nią znajdziemy się w widoku ABL Applications.
Składa się on z kilku okien. W pierwszym od lewej, widać listę instancji. Dalej, dla wybranej instancji, widać szczegółowe informacje nt aplikacji.
Musze przyznać, że śledzę rozwój tego produktu z dużym zaciekawieniem. Zyska on bardzo na wartości gdy pojawią się możliwości monitorowania baz danych.
W zarządzaniu PASOE pojawiło się nowe rozszerzenie dla komendy TCMAN i PASMAN – OESERVER. Jest ono zalecanym narzędziem do uruchamiania i zatrzymywania PASOE. Obsługuje dodatkowe parametry, aby zamknąć powiązane sesje klienta APSV i zebrać bardziej szczegółowe informacje o instancji. W celu zapewnienia kompatybilnościOESERVER obsługuje istniejące parametry PASOESTART. Poniżej widać kilka parametrów z długiej listy komendy OESERVER.
Przykład działania komendy pasman oeserver -restart oraz –status (status wyświetla więcej informacji niż query). Na końcu podawane są informacje nt agentów i sesji.
Integracja OpenEdge z Apache Kafka – Kafka to otwarta, rozproszona platforma do strumieniowego przesyłania wydarzeń (event-streaming), szeroko stosowana w wielu branżach i organizacjach. Zapewnia przechwytywanie danych w czasie zbliżonym do rzeczywistego ze źródeł, takich jak bazy danych, aplikacje, czujniki, urządzenia mobilne i usługi w chmurze.
OpenEdge udostępnia nowe OpenEdge.Messaging API do wysyłania wiadomości do klastra Kafki poprzez Kafka producer i odbierania wiadomości z tego klastra przez Kafka consumer.
Progress Developer Studio dla OpenEdge obsługuje teraz inteligentną kompilację.Kiedy programista ABL wprowadza zmiany w pliku i go kompiluje, Developer Studio automatycznie kompiluje także wszystkie inne pliki, których mogą dotyczyć te zmiany.Dzięki temu identyfikowane są wszystkie błędy kompilacji wprowadzone w wyniku zmian w kodzie.
Na zakończenie chciałbym wspomnieć o istotnym ułatwieniu w procesie odtwarzaniu bazy po awarii z backupu i plików AI. Administratorzy mogli mieć problem w szybkim określeniu kolejności extentów. W wersji OE 12.5, wprowadzono nowe narzędzie do komendy rfutil, AIMAGE SUMMARY, które uruchamia szybkie skanowanie informacji potrzebnych do zidentyfikowania plików AI.
Jak zwykle, po więcej nowości odsyłam do dokumentacji i internetu.
Czytelnicy niniejszego bloga znają podstawowy i sztandarowy produkt służący do monitorowania systemów – OpenEdge Management (OEM) oraz jego uboższą wersję OpenEdge Explorer (OEE).
Produkt ten został wprowadzony po raz pierwszy wiele lat temu pod nazwą Fathom Management w wersji V9. Wciąż jest rozwijany i świetnie spisuje się w małych i średnich sieciach.
Tym razem chciałbym przybliżyć nowy produkt, OpenEdge Command Center (OECC) służący do zarządzanie wieloma zasobami i instalacjami OpenEdge na różnych komputerach i różnych wersjach OpenEdge.
Pierwsza wersja OpenEdge Command Center została stworzona z myślą o efektywnym zarządzaniu PASOE oraz, w przyszłości, bazami danych. Aktualna wersja 1.0 wspiera OE12.2.5 i wyższe. Nie ma wsparcia wstecz.
OECC jest darmowe dla posiadaczy licencji OE, podobnie jak OEE i ma na celu uproszczenie ogólnego zarządzania platformą OpenEdge.
Serwer OpenEdge Command Center jest obsługiwany na następujących platformach:
Ubuntu 18.04 LTS
Oracle Linux 8
Red Hat Enterprise Linux 8
SUSE Linux Enterprise Server 15
CentOS Linux 8
Windows 64
Można także uruchomić OpenEdge Command Center Server na 64-bitowym serwerze Linux z obsługą chmury, który jest skonfigurowany z MongoDB ATLAS.
Jednym z celów OECC jest zastąpienie produktu OEE, ze względu na niektóre problemy, które były zgłaszane przez użytkowników jak np. przestarzały interfejs, “ciężki” proces zdalnego AdminServera wymagający otwarcia 4 portów czy to, że API muszą być wyeksponowane w standardzie OpenAPI.
Serwer OECC można wdrożyć jako pojedynczy węzeł lub, dla zapewnienia wysokiej dostępności, jako klaster wielowęzłowy. Aby zapewnić wysoką dostępność, serwer współpracuje ze wszystkimi load balancerami obsługującymi transporty HTTP/HTTPS oraz protokoły websocket, takie jak Nginx, Serwer HTTP Apache, AWS, ELB/ALB itp.
OECC do przechowywania danych korzysta z bazy danych MongoDB oraz magazynu plików (patrz rysunek).
MongoDB to nierelacyjna baza, która przechowuje dane w postaci dokumentów w formacie podobnym do JSON. Są w niej zawarte wszystkie szczegóły dotyczące wykrytych komponentów OE takich jak PASOE (w przyszłości także baz danych OE) oraz ustawienia konfiguracyjne OECC. Instalacja bazy MongoDB jest wymagana przed instalacją serwera OECC, który wspiera następujące wersje (www.mongodb.com):
MongoDB Community Server
MongoDB Atlas running on AWS, Azure, and Google Cloud Platform (GCP)
MongoDB Enterprise Edition
Oprócz bazy część danych jest przechowywana w postaci repozytorium plików. Mieszczą się tu informacje o połączeniu z bazą danych, konfiguracji bezpieczeństwa i logowania itp.
O instalację MongoDB (podobnie jak i Java JDK) klient musi zadbać we własnym zakresie.
Ażeby dane były pobierane z różnych środowisk, na każdej maszynie trzeba zainstalować agenta OECC. Jest to lekki proces instalujący się razem z OE. Niezależnie od tego, czy masz jedną czy więcej instalacji OpenEdge na maszynie wystarczy zainstalować jednego agenta (OE 12.2.5 i wyżej).
Proces agenta działa autonomicznie; trzeba tylko upewnić się że jest poprawnie uruchomiony. Dla bezpiecznego połączenia z serwerem OECC trzeba z konsoli wygenerować unikalny klucz dla każdego agenta.
Cały proces konfiguracji i monitorowania przeprowadzamy z konsoli dostępnej z przeglądarek internetowych (HTTP/HTTPS), patrz przykład poniżej.
OpenEdge Command Center to bardzo ciekawy produkt, który obecnie monitoruje tylko procesy PASOE, ale w najbliższym czasie ma być rozszerzony także o procesy baz danych. Warto jest go zainstalować i przetestować.
Najnowsza wersja OE 12.4 pojawiła się jako non-LTS Release. Ponieważ dostaję pytania w tej sprawie, kilka słów wyjaśnienia.
Wersja non-LTS (Non-Long Term Supported), jak sama nazwa wskazuje, jest bez długotrwałego wsparcia technicznego i jest przeznaczona dla tych, którzy wymagają najnowszych rozwiązań i poprawek. Wersja ta zapewnia również klientom możliwość używania i testowania funkcji, które pojawią się w nadchodzących wersjach obsługiwanych długoterminowo.
Wersja LTS (Long Term Supported) umożliwia kilkuletnie wsparcie techniczne i większą stabilizację. Dla przykładu: ostatnia wersja LTS to 12.2 z datą wygaśnięcia 10.2028, a dla wersji OE 11 to 11.7 (04.2025). OE 12.1, która jest non-LTS wygasa w 09.2022, więc za ok. rok (więcej informacji znajdziecie tutaj). Warto pamiętać o tym planując migrację do konkretnej wersji.
Zaczynamy, podobnie jak dla OE 12.3, od nowinek w definiowaniu zmiennych.
Od OE 12.4 dopuszczalne są poniższe konstrukcje, wraz z działaniami:
VAR INT a = 50, b = 20, x = a + b , y = a - b, z = x - y.
Poniższy przykład pokazuje definiowanie i inicjowanie zmiennych za pomocą funkcji standardowej, funkcji zdefiniowanej przez użytkownika, oraz metody:
VAR DATETIME dtm = DATETIME(TODAY,MTIME).
VAR INTEGER x = myFunction().
VAR INTEGER y = classMethod(output v).
Tutaj, z kolei, widzimy przykład definiowania określonych i nieokreślonych elementów macierzy i inicjowanie ich za pomocą wyrażenia:
VAR INT[2] w = [123, a + b].
VAR INT[3] x = [funct( ), 123, a + b].
VAR INT[ ] y = [123, a + b].
VAR INT[ ] z = [funct( ), 123, a + b].
Wprowadzono nową instrukcję języka ABL AGGREGATE do obliczania zagregowanych wartości w bazie danych
po stronie serwera. Wcześniej obliczenia te były wykonywane po stronie klienta przy użyciu instrukcji ACCUMULATE
i funkcji ACCUM.
Teraz można użyć pojedynczej instrukcji AGGREGATE dla COUNT, TOTAL i AVERAGE. Instrukcja AGGREGATE upraszcza kod i poprawia wydajność ponieważ obliczenia są wykonywane po stronie serwera bazy danych. Patrz poniższy przykład:
VAR DECIMAL avgBalance.
AGGREGATE avgBalance = AVERAGE(Balance) FOR Customer
WHERE Country EQ 'USA' AND City EQ 'Chicago'.
MESSAGE "Average balance: " avgBalance
VIEW-AS ALERT-BOX.
Ważną nowością dla administratorów jest wprowadzenie zastrzeżonego trybu bazy danych (restricted database access).
Pamiętacie zapewne, że możliwe jest włączenie w bazie trybu quiet point. Wstrzymuje on aktywne transakcje aż do momentu jego wyłączenia. Są jednak sytuacje gdy trzeba wykonać operacje administracyjne nie martwiąc się o niekompletne transakcje czy nowe logowania w trakcie pracy np: kasowanie dużej ilości niepotrzebnych danych, synchronizacja z innym źródłem, zrzut i ładowanie rekordów itd.
Tryb pracy restricted online umożliwia wykonywanie takich zadań z wykorzystaniem puli buforów czy wspomagających procesów asynchronicznych.
proutil [nazwa-bazy] -C dbrestrict dbadmin enable disconntimeout 500
Powyższa komenda umożliwia dostęp do bazy jedynie dla procesów administracyjnych (database utilities). Ustawiono opcjonalny parametr odłączenia użytkowników na 500 s.
Akcja status pozwala na podgląd czy dany tryb został ustawiony. Patrz na poniższy zrzut ekranu:
Tryb dbadmin nie jest jedynym w OE 12.4. Są jeszcze tryby: datamove – ograniczenie wszystkich operacji z wyjątkiem PROUTIL DATAMOVE partitioncopy – ograniczenie wszystkich operacji z wyjątkiem PROUTIL PARTITIONMANAGE COPY rollforward – ograniczenie wszystkich operacji z wyjątkiem RFUTIL ROLL FORWARD.
Dla każdego trybu można stosować akcje: enable, disable, status.
Inne ciekawe rozwiązania w OE 12.4 z zakresu “Continuous Operations” to zdefiniowanie domyślnego obszaru typu II dla tworzenia nowych obiektów bazodanowych (tabele, indexy, LOBs), uproszczony mechanizm obcinania (truncate) danych w tabeli online czy poprawiony mechanizm zarządzania obszarem before-image. Został on wprowadzony w OE 12.3 w procesie watchdog, a w OE 12.4 to już niezależny proces uruchamiany poleceniem probim [nazwa-bazy].
Wprowadzona została konsola do zarządzania w chmurze OpenEdge Command Center wersja 1.0 , która umożliwia zarządzaniezasobami i instalacją produktów OpenEdge na różnych komputerach i w różnych wersjach OpenEdge.
