OpenEdge 12.5

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

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

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

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

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

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

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

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

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

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

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

OpenEdge Command Center

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

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

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

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

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

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


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

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

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

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

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

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

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

Migracja do PASOE

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

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

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

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

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

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

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

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

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

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

OpenEdge 12.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OE Management

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

O OE Explorer pisałem już tutaj.

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

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

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

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


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

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

Bezpieczeństwo w PASOE cz. V – OE Realm

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

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


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

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

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

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

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

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


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

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

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


USING OpenEdge.DataAdmin.*.

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

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

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

service:CreateSequence(sequence).

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

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

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

validateCP=true
debugMsg=true

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

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

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

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

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

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

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

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

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

… a tak pliki w projekcie.

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

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

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

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

Bezpieczeństwo w PASOE cz. IV – LDAP, domeny i CP

W poprzednim artykule wyszliśmy poza technologię Progress Software i dzięki Apache Directory Studio przeprowadziliśmy uwierzytelnienie użytkowników korzystających z restowej aplikacji PASOE.

Pora wykonać następny krok (naprzód!) i uwzględnić w całym procesie token – obiekt CLIENT-PRINCIPAL. Obiekt ten został wprowadzony w OE10, wraz z pojawieniem się technologii Auditing. Przypomnę, że chodziło o rejestrowanie zmian w systemie bazodanowym i niezbędnym było posiadanie informacji, kto te zmiany wprowadza. Domyślnie, auditing korzysta z wartości user-id użytkownika, który jest zdefiniowany w bazie.

Jednakże w kontekście aplikacji bardziej odpowiedni jest identyfikator użytkownika sesji OpenEdge. Dzięki takiemu identyfikatorowi – tokenowi, aplikacja nie musi sprawdzać za każdym razem gdy jest to konieczne, kto jest aktualnie zalogowany. Wszystkie potrzebne informacje są bezpiecznie przechowywane w obiekcie sesji CLIENT-PRINCIPAL. Obiekt ten może zawierać nie tylko dane użytkownika, ale dodatkowe właściwości jak np. role potrzebne w procesie autoryzacji.

CLIENT-PRINCIPAL (CP) jest szczególnie przydatny w aplikacjach rozproszonych (AppServer, PASOE) ponieważ może zarządzać kontrolą dostępu dla wielu procesów aplikacji.

Nie będę omawiał wszystkich szczegółów związanych z CP, gdyż jest to temat zbyt obszerny. Bardzo ważne jest to, że do “zapieczętowania” (seal) obiektu i późniejszego jego użycia w sesji, użytkownik musi być zdefiniowany w tzw. domenie i musi być znany klucz (Access Code) do domeny. Czyli: definiujemy domeny w bazie (nazwa domeny, klucz dostępu), a następnie definiujemy użytkownika w danej domenie. OK, to powinno nam na razie wystarczyć. Na poniższym rysunku widać narzędzie Database Administration i okno do definiowania domen ( opcja: Admin -> Security -> Domain Maintenance -> Domains…).

Teraz uwaga! użytkownicy nie muszą znajdować się w bazie, mogą być zdefiniowani w systemie LDAP, co zaraz pokażę. Definicje domen w bazie będą jednak potrzebne. Później wyjaśnię dlaczego.

Teraz jest dobry moment żeby podłączyć PASOE do serwera bazy danych.

Proszę zwrócić uwagę na dwie domeny: adminusers i webusers (opis: LDAP), które zdefiniowałem na potrzeby tego artykułu. Kodem dostępu do domen jest odpowiednio: adminpa, webpa.
Tworzymy prosty tekstowy plik zawierający pary wartości: nazwa domeny, kod dostępu. Zobaczmy taki przykładowy plik ldapasreg.csv.

Posłuży on jako parametr wejściowy do utworzenia zaszyfrowanego pliku rejestru, który może służyć do zapieczętowania tokena. W oknie znakowym podajemy komendę:
gendomreg ldapasreg.csv ldapasreg.bin.
Wygenerowany plik ldapasreg.bin kopiujemy do podkatalogu PASOE conf.

Teraz zabieramy się za modyfikację struktury w Apache Directory Studio. Po uruchomieniu instancji serwera i otwarciu połączenia dodajemy dwie grupy: OED:adminusers, OED:webusers. Jak łatwo się domyślić, to są nasze domeny. W LDAP nie ma obiektów typu domena, więc definiujemy grupy, a żeby odróżnić je od zwykłych grup dodajmy np. przedrostek. Użyłem przedrostka OED:, ponieważ oznacza OpenEdge Domain, ale można użyć dowolnego jaki nam pasuje.


W grupie OED:adminusers dodałem użytkownika Piotr Adminowy (czyli admin1), a w domenie OED:webusers użytkownika Marek Webowy (user1). Tym samym należą oni do dwóch grup (drugą jest PSCUser).

Przechodzimy do pliku: [working directory]\[instancja pasoe]\webapps\ROOT\WEB-INF\oeablSecurity.properties i dodajemy ustawienia:

## OEClientPrincipalFilter.registryFile=ABLDomainRegistry.keystore
OEClientPrincipalFilter.registryFile=ldapasreg.bin
...
 ## Used to obtain an OE Domain name from the authenticated user's list of
 ## roles if the user did not supply one (overrides the default domain property)
 OEClientPrincipalFilter.domainRoleFilter=ROLE_OED:(.*)

Pierwszy parametr określa binarny plik, który utworzyliśmy wcześniej, drugi to prefix określający domenę. Z poprzedniego artykułu wiemy, że dla określenie roli, do nazwy grupy użytkownika zostanie dodany prefix ROLE_ (parametr ldap.authpopulator.rolePrefix). Natomiast dla określenia domeny, zostanie zidentyfikowany ciąg znaków ROLE_OED: i wszystko co nastąpi po nim, to nazwa domeny. Czyli dla użytkownika admin1 będzie to adminusers, a dla user1 webusers.
Ponieważ w pliku binarnym istnieje taka domena i kod dostępu, uwierzytelnienie powinno się udać.

Zanim przejdę dalej trzeba odpowiedzieć na jedno ważne pytanie: dlaczego informacje o domenach znajdują się w trzech miejscach: bazie danych, pliku bin, serwerze LDAP? Aby to zrozumieć musimy przypomniec sobie, że PASOE to połączenie dwóch technologii: ABL i Java (Tomcat). W Spring Security (Java) tworzony jest token, który Tomcat może zapieczętować dzięki informacjom w pliku bin. Token ten jest transformowany do CLIENT-PRINCIPAL ABL, dzięki czemu możemy korzystać z metod ABL aby np. modyfikować role, zarządzać stanem CP itd. CP nie korzysta z pliku bin, dane o domenach pobiera z bazy. Tutaj w bazie nie trzeba definiować użytkowników w domenach, są oni zdefiniowani tylko na serwerze LDAP.

Ponieważ możemy teraz korzystać z obiektu CP, dodajmy dwie procedury w konfiguracji naszej instancji PASOE, dla otwarcia sesji i rozpoczęciu żądania. Całe procedury można pobrać tutaj.


Pierwsza procedura wczytuje parametry domen z bazy.
cpStartup.p

// Loading domain registry for the session
m_lOK = SECURITY-POLICY:LOAD-DOMAINS(1).

pcActivate.p weryfikuje poprawność zapieczętowania CP i wydruk jego atrybutów do logu.
cpActivate.p

// Verify if the Client-Principal is sealed successfully or not. If not, return error.
IF lOK THEN 
DO:
    // Dump the Client-Principal attributes
   
    MESSAGE "    ID:         '" + hCP:QUALIFIED-USER-ID + "'".
    MESSAGE "    session-id:" hCP:SESSION-ID.
    MESSAGE "    state:" hCP:LOGIN-STATE.
    MESSAGE "    roles: " + hCP:ROLES.
    MESSAGE "     domain: " + hCP:DOMAIN-NAME.
    
    cList = hCP:LIST-PROPERTY-NAMES.
    iListSize = NUM-ENTRIES(cList, ",").
    IF ( 0 < iListSize ) THEN 
    DO iListPos = 1 TO iListSize:
        DEFINE VARIABLE cProp AS CHARACTER NO-UNDO.
        DEFINE VARIABLE cVal  AS CHARACTER NO-UNDO.

        MESSAGE "    properties:".
        cProp = ENTRY(iListPos, cList, ",").
        cVal = hCP:GET-PROPERTY(cProp).
        MESSAGE "          property:" cProp ", value:" cVal.
    END.
    
    // Set the Client-Principal as client to connect with DB.
    SET-DB-CLIENT(hCP).
    
END.

Restartujemy teraz PASOE i wywołujemy ekran logowania: http://localhost:[port]/rest/_oepingService/_oeping
Podajemy dane: user1, user1. Dane są uwierzytelnione, ale najciekawsze informacje znajdujemy w logu agenta ldapas.agent.[data].log
Po pierwsze mamy wpis o prawidłowym wczytaniu domen z pliku cpStartup.p

Po drugie możemy odczytać parametry tokena CLIENT-PRINCIPAL wygenerowane przez plik cpActivate.p.

Widać, że pełne id użytkownika zostało uzupełnione o nazwę domeny a także, że użytkownik dostał nową rolę.
To chyba jest najbardziej zaawansowany z artykułów, które do tej pory Wam przedstawiłem. Jeśli ktoś przećwiczy cały proces – gratuluję!
W razie pytań piszcie, jak zwykle, na PUG Poland.

Bezpieczeństwo w PASOE cz. III – LDAP

W tym artykule powracamy do tematu związanego z bezpieczeństwem w PASOE, które było omawiane ok. pół roku temu. Dla przypomnienia: część I oraz część II. Warto przypomnieć sobie te wiadomości bo będziemy z nich zaraz korzystać.

Spring Security to elastyczny framework, w którym administrator może wybrać poziom  zabezpieczeń w zależności od wymagań związanych z aplikacją. Pokażę jak przeprowadzić uwierzytelnienie użytkowników, którzy nie znajdują się w bazie, nie są zdefiniowani w plikach tekstowych, ale w zewnętrznym systemie LDAP, na przykładzie Apache Directory.

Instalujemy Apache Directory Studio, które zawiera serwer LDAP oraz środowisko oparte na Eclipse, do stworzenia hierarchicznej struktury, zawierającej m.in. konta użytkowników.

Na temat tworzenia takiej struktury w ADS czy innym systemie LDAP (Active Directory, OpenLDAP, itp) można znaleźć wiele informacji w sieci. Bardzo przydatne na początku są filmiki instruktażowe na youtube. Ja omówię ten proces bardzo ogólnie, na potrzebę niniejszego artykułu. Po pierwsze dodajemy nowy serwer, nazwę go localhost.


W widoku Connections definiuję połączenie dla tego serwera o nazwie local: Hostname: localhost (lub IP), domyślny port 10389.

Następnie w zakładce Authentication, wybieram Bind DN or user: uid=admin,ou=system. Domyślne hasło: secret.

Uruchamiamy zdefiniowany serwer oraz połączenie i możemy przystąpić do tworzenia schematu. Trzeba pamiętać, że będzie on dostępny tylko przy aktywnym połączeniu.
Ten schemat można utworzyć na różne sposoby. Ja zacznę od stworzenia obiektu organizacji.
Pod głównym węzłem dc=example,dc=com dodajemy obiekt typu organization o nazwie o=progress
Pod tym elementem tworzymy dwa obiekty typu organizationalUnit ou=groups oraz ou=users.

Pod users dodajemy przykładowych użytkowników typu inetOrgPerson. Dodałem dwóch użytkowników – nasuwa się pytanie jak ich identyfikować, mamy pola cn i sn… – otóż dla identyfikacji z zewnątrz ważny jest atrybut uid (admin1 i user1) oraz userPassword, taki sam jak nazwa użytkownika. Czyli logując się jako zwykły użytkownik (Marek Webowy) podamy dane: user1, user1.

Po uwierzytelnieniu przychodzi pora na autoryzację. Ta jest realizowana za pomocą ról. Zaglądając do poprzednich artykułów możemy zobaczyć, że w pliku pasoe oeablSecurity.csv są zdefiniowane role ROLE_PSCUser, ROLE_PSCAdmin, ROLE_PSCDebug. Dla demonstracji wykorzystamy tylko jedna rolę i stworzymy jedną grupę PSCUser typu groupOfUniqueNames.

W grupie tej umieszczamy użytkowników, tzn. ich atrybuty cn (Common Name). Pamiętajmy, że pełna nazwa zawiera elementy aż do węzła głównego, czyli np. dla użytkownika user1:
cn=Marek Webowy,ou=users,o=progress,dc=example,dc=com.

OK, zrestartujmy połączenie. Możemy teraz przystąpić do konfiguracji PASOE. Ja tworzę nową instancję o nazwie ldapas bez dostępu do bazy.
Konfigurację tę przeprowadzimy w, omawianym już w poprzednich częściach, pliku [working directory]\[instancja pasoe]\webapps\ROOT\WEB-INF\oeablSecurity.properties.
Wybieramy proces zarządzający uwierzytelnieniem ldap oraz model logowania form.

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

Następnie dodajemy parametry logowania do serwera ldap oraz filtry wyszukiwania informacji o użytkowniku oraz grupie, do której należy.

ldap.root.dn to definicja węzła, od którego zaczyna się wyszukiwanie informacji w strukturze, ldap.usersearch.base to z kolei węzeł, pod którym znajdują się definicje użytkowników, ldap.usersearch.filter określa zakończenie wyszukiwania po znalezieniu elementu uid.

Podobne parametry definiujemy dla grup. Całość wygląda mniej więcej tak:

 ## Required LDAP Server Authentication Manager configuration properties 
 ldap.url=ldap://localhost:10389
 ldap.manager-dn=uid=admin,ou=system
 ldap.manager-password=secret
 
 ldap.root.dn=o=progress,dc=example,dc=com

 ldap.usersearch.base=ou=users  
 ldap.usersearch.searchSubtree=true
 ldap.usersearch.filter=(uid={0})
 
 ldap.grouprole.attribute=cn
 ldap.groupsearch.base=ou=groups
 ldap.groupsearch.searchSubtree=true
 ldap.groupsearch.filter=(uniqueMember={0})

 ldap.authpopulator.rolePrefix=ROLE_

Podawanie hasła w postaci jawnej (secret), to niezbyt dobry pomysł. Można to wyeliminować kodując hasło przy pomocy komendy: stspwdutil encrypt [hasło].

Ostatni parametr (wartość domyślna ROLE_) określa prefix dla roli jaki będzie dodany do nazwy grupy, czyli dla PSCUser pełna nazwa będzie ROLE_PSCUser.

Według konwencji nazewnictwa w LDAP, nazwy ról mają być pisane dużymi literami. W LDAP są one zamieniane z automatu, my musimy zmienić je w pliku oeablSecurity.csv, np. z ROLE_PSCUser na ROLE_PSCUSER itd.

Restartujemy PASOE. Wchodzimy do linku testującego:
http://localhost:[port]/rest/_oepingService/_oeping
Podajemy dane: user1, user1.

Mamy dostęp do serwisu.

OK, ale zazwyczaj nie ma tak dobrze. Często zanim wszystko skonfigurujemy pojawia się komunikat o braku dostępu. W logach nic nie ma, gdzie szukać informacji? Musimy odblokować ilość informacji zapisywanych do logów. W pliku [working directory]\[instancja pasoe]\conf\logging-pasoe.properties zmieniamy poziom zapisów z WARN na DEBUG, a ERROR na INFO, jak poniżej. Konfigurację zapisów do logów możemy zrobić także z poziomu danej aplikacji, ale tutaj poniższa zmiana wystarczy. Uwaga! ta zmiana powoduje znaczne zwiększenie tekstu w logach.

W pliku ldapas_authn.[data].log (przypominam, że moja instancja nazywa się ldapas) znajduje się informacja o udanym uwierzytelnieniu. Informacje o nieudanych logowaniach znajdują się w pliku ldapas_authz.[data].log

[data i czas] ldapas ROOT:f:0000000a success user1

W logu ldapas.[data].log znajduja się m.in. wpisy:

...LdapAuthenticationProvider - Processing authentication request for user: user1...
...FilterBasedLdapUserSearch - Searching for user 'user1', with user search [ searchFilter: '(uid={0})', searchBase: 'ou=users  '...
...Searching for entry under DN 'o=progress,dc=example,dc=com', base = 'ou=users', filter = '(uid={0})'... 
...Found DN: cn=Marek Webowy,ou=users...
......
...Searching for roles for user 'user1', DN = 'cn=Marek Webowy,ou=users,o=progress,dc=example,dc=com', with filter (uniqueMember={0}) in search base 'ou=groups'...
......
...Granted Authorities: ROLE_PSCUSER;...

Wpisów jest wiele, ale można prześledzić proces wyszukiwania oraz uwierzytelniania i autoryzacji.

Następnym razem chciałbym pokazać jak PASOE korzysta z obiektu CLIENT-PRINCIPAL przy autoryzacji LDAP.

MOVEit Automation – podstawy

Dzisiaj chciałbym przedstawić podstawy drugiego produktu Ipswitch – MOVEit® Automation.
MOVEit Automation (poprzednia nazwa MOVEit Central) pozwala w łatwy sposób zautomatyzować złożone przepływy danych (workflows) bez konieczności programowania.
Przepływy złożone są z zadań (tasków), a te z kolei mogą być uruchamiane wg harmonogramu, sterowane zdarzeniami lub na żądanie. Zadania mogą wymieniać pliki między systemami wewnętrznymi i zewnętrznymi, w tym serwerami MOVEit Transfer, przy użyciu wielu protokołów i przetwarzać pliki za pomocą wielu wbudowanych funkcji.

O ile miejsce MFT jest w strefie DMZ, to MA powinien znajdować się w bezpiecznej strefie sieci wewnętrznej (patrz rysunek poniżej).

Poniżej widzimy podobną architekturę, gdzie zamiast MFT jest inny produkt z grupy Ipswitch – WS_FTP Server. Możliwe są inne rozwiązania, serwery innych producentów, pominięcie strefy DMZ i połączenie np. z chmurą (MOVEit Cloud), ale o tym innym razem.

MOVEit Transfer (MFT) łatwo skonfigurować do współpracy z MOVEit Automation. W tym celu w MFT dodajemy użytkownika np. micentral z uprawnieniami admina.
Konto to będzie wykorzystywane do wysyłania dużej liczby pakietów dlatego wyłączamy dla niego notyfikacje. Można ustawić odpowiednie zabezpieczenia jak np. mocne hasło czy brak wygaśnięcia konta.
Logujemy się do MOVEit Automation, widzimy główne menu.

klikamy na HOSTS i Add Host. Z listy kilkunastów typów hostów wybieramy MOVEit Transfer.

Podajemy IP oraz dane logowania użytkownika micentral.

Można wprowadzić ograniczenia Limits i Timeouts itd. oraz przetestować połączenie.
Przejdźmy teraz do jednej z podstawowych czynności, tzn. do definiowania tasków.
W głównym menu wybieramy TASKS i Add Task.

Jak widać są trzy rodzaje tasków. Każdy rodzaj ma inne przeznaczenie. Najczęściej definiuje się taski typu Traditional, które zaspokajają większość potrzeb jakie występują w systemie.
Utwórzmy przykładowy tradycyjny task o nazwie myFirstTask. Pierwszym krokiem jest wybór kroku w definiowaniu (przycisk Step): Source, Process, Destination.

Zaczynam od źródła, czyli Source.

Wybieram dodany wcześniej serwer MFT oraz katalog i wzorzec plików, które będą przetwarzane. Możemy dodać czynności po udanym transferze jak np. skasować pliki, zmienić ich nazwę itp. Jeśli klikniemy w opcji Step na Process, dostaniemy listę skryptów do wyboru. Ja ten krok tutaj pominę.

Wybieram natomiast krok Destination, a w nim podaję adres email, na który pliki mają być wysłane.

OK, następny krok to zdefiniowanie harmonogramu (Schedule).

W kroku Next Action można wybrać Send Email, co jest rodzajem notyfikacji oraz ewentualnie Run Task, czyli uruchomienie innego wcześniej zdefiniowanego tasku. W ten sposób można zdefiniować cały cykl zadań.
OK, mój task ma być uruchamiany tylko we wtorki o określonej godzinie. Musimy go jeszcze włączyć i po pewnym czasie mamy raport z jego działania.

Zadania zaawansowane (Advanced Task) podobnie do zadań tradycyjnych mogą również korzystać z procesów. Mogą ponadto używać elementów warunkowych IF i FOR, aby określić, czy i kiedy inne elementy mają być uruchomione.
Elementy te zapewniają kontrolę przepływu pracy bez konieczności programowania.
Trzecim typem zadań sa zadania synchronizujące (Synchronization Task).

Ich zadaniem jest synchronizacja folderów, dlatego konfiguracja składa się z folderu A, folderu B i strzałki określającej kierunek synchronizacji.

MOVEit Automation, podobnie do MFT gwarantuje dostarczenie danych, szyfrowanie danych w spoczynku i szczegółową kontrolę dostępu. Na tym zakończę to wprowadzenie do systemu MA.
Jeśli ktoś ma pytania to proszę o kontakt na grupie PUG Poland.

OpenEdge 12.3

Powróćmy do tematu związanego z OpenEdge, ponieważ już od pewnego czasu mamy na rynku nową wersję OE 12.3.
Zacznijmy od nowinki dla programistów; dodano nową, bardziej zwięzłą instrukcję definicji zmiennych. Do tej pory ile zmiennych chcieliśmy zdefiniować, tyle musieliśmy wstawić definicji. Obecnie zapis jest krótszy, a w jednej instrukcji można zdefiniować wiele zmiennych. Zmienne zdefiniowane poprzez nową instrukcję są zawsze NO-UNDO.

Następna nowinka związana jest z definicją tablicy (extentu) o nieokreślonym rozmiarze. Rozmiar ten można teraz określić podczas fazy runtime, nawet jeśli tablica ma przypisane wartości początkowe.

W ABLu wprowadzono także operatory przypisania (+=, -=, *=, /=) do wykonywania operacji i przypisywania
wartość, używając skróconej notacji.

Od 12.3 jeśli zachodzi potrzeba aktualizacji aplikacji ABL, przy czym ta aktualizacja jest związana z nowymi elementami schematu, nie trzeba już
restartować maszyny wirtualnej ABL (AVM).

W OpenEdge 12.3 dodano ciekawą opcję komendy PROUTIL: PROUTIL TABLEREORG – umożliwia to reorganizację pofragmentowanych danych w tabeli, podczas gdy sama tabela pozostaje dostępna dla operacji OLTP (przetwarzanie transakcji online). Nowy proces zastępuje długotrwałe operacje zrzutu i ładowania danych oraz odbudowy powiązanych indeksów. Rekordy tabeli muszą znajdować się w tym samym obszarze przechowywania typu II. Operacja ta obsługuje także tabele multi-tenant oraz podzielone na partycje.

Kolejne parametry mogą być modyfikowane online, tym razem dla brokera secondary.
Maximum Clients per Server (-Ma)
Maximum Dynamic Server (-maxport)
Minimum Clients per Server (-Mi)
Minimum Dynamic Server (-minport)
Message Buffer Size (-Mm)
Maximum Servers per Broker (-Mpb)
Pending Connection Time (-PendConnTime)

Zmiany parametrów można dokonać w R&D -> opcja 4. Administrative Functions -> 16. Adjust Startup Parameters.

Jest jeszcze kilka ciekawych zmian związanych z tzw. Continuous Operations, bezpieczeństwem, programowaniem, ale to już musicie poszukać w sieci sami.

1 2 3