Tag: APSV

Tworzenie projektów w OE Developer Studio 11.7.2

Podczas kilku wcześniejszych artykułów pokazywałem jak utworzyć różne proste projekty w OpenEdge Developer Studio. Służyły one np. do wystawienia serwisów REST z wykorzystaniem obiektów JSDO i automatycznym generowaniem klas lub bardziej złożone z ręcznym mapowaniem parametrów. Przykłady te dotyczyły nowego serwera PASOE choć można było wykorzystać także klasyczny AppServer.

Takie tworzenie projektów odbywa się poprzez tzw. wizardy, których zadaniem jest “poprowadzenie za rękę” dewelopera, aby ułatwić mu życie. Jeśli idzie o intuicyjność wizardów, np. dla projektów typu OpenEdge, których jest kilka rodzajów, to pozostawiały one nieco do życzenia i bez znajomości zdobytej np. poprzez webinary lub dokukmentację łatwo można było popełnić błąd.

W ostatnich wersjach OpenEdge proces ten został poprawiony a jego klarowność jest zdecydowanie lepsza.

Tworząc nowy projekt typu OpenEdge od razu pojawia się okno (poniżej), w którym rodzaje projektów są pogrupowane w 3 grupy: Server, Client, General. Wybierając grupę i typ projektu w polu Description pojawia się krótki opis.


W grupie Server można zdecydować czy wykorzystany będzie serwer PASOE czy klasyczny AppServer.

Dla PASOE można dalej wybrać warstwę transportową: APSV, REST lub WEB.
Pierwsze dwie warstwy były omawiane na tym blogu. APSV służy do obsługi procedur ABL poprzez HTTP.
REST to projekt, w którym możemy wykorzystać wywołania RESTful API i ręcznie mapować wybrane pola. Jeśli zaznaczymy Create a DataObject Service, będzie to projekt z automatycznym mapowaniem struktur ProDataSet do JSDO.

WEB służy do utworzenia projektu z wykorzystaniem wywołań RESTful API przez klasę WebHandler. Ten rodzaj nie był jeszcze omawiany na blogu.

Jeśli zamiast PASOE wybierzemy klasyczny AppServer to będziemy miali do wyboru 2 rodzaje: APSV i REST.

Grupa Client to przede wszystkim projekty związane z budowaniem aplikacji desktopowej, może to być aplikacja GUI for .NET, z wykorzystaniem AppBuildera lub znakowa (ChUI). Można także budować interfejs webowy WEB UI lub klasyczny WebSpeed.

Grupa General, to podstawowy projekt oraz pozostałe z grupy OpenEdge, np. Dynamics lub (omawiany na Pizza & Beer) ABLUnit do przeprowadzania testów ABL. Można wreszcie stworzyć projekt Custom z konfiguracją dopasowaną do własnych potrzeb.

Development , , , , ,

Procedury ABL i serwer aplikacji PAS cz.II

Kontynuując omawianie różnych zagadnień związanych z uruchamianiem aplikacji ABL na serwerze PAS zobaczmy jak osiągnąć połączenie w różnych trybach pracy, charakterystycznych dla klasycznego AppSerwera, co może być istotne podczas procesu migracji aplikacji.

W poprzedniej części zobaczyliśmy jak przyłączyć się do serwera PAS w modelu session-free i session-managed. Wybór modelu należy do klienta, a nie serwera aplikacji, którego pojedyncza instancja potrafi obsłużyć jednocześnie oba modele.

Dla session-free nie potrzebne są żadne zmiany w aplikacji poza samą instrukcją przyłączenia.

Dla session-managed mamy w AppSerwerze 3 tryby pracy:

  • state-reset
  • state-aware
  • stateless

Tryby te związane są z zarządzaniem kontekstem między żądaniami i wprowadzono je dla ułatwienia procesu programowania.

Przywiązanie procesu agenta do określonej sesji klienta powoduje zachowanie kontekstu, ale zmniejsza skalowalność. Różne tryby pracy dają więc programoście możliwość wyboru. Istotne jest, że tryby te w klasycznym AppSerwerze wybiera się podczas jego startu i nie mogą być zmienione jak długo serwer pracuje.

Jeśli więc będziemy potrzebować wszystkie trzy tryby jednocześnie, należy uruchomić trzy procesy AppServera. W serwerze PAS wystarczy jeden proces, a sposób pracy określa jedynie kod programu klienckiego.

Przypomnijmy, że dla serwera PAS połączenie z wybraną sesją ABL może być warunkowo związane/zwolnione poprzez ustawienie atrybutu SESSION:SERVER-CONNECTION-BOUND-REQUEST.

Zdefiniujmy teraz dwie procedury:
bound.p

/* bound.p  */
.....
SESSION:SERVER-CONNECTION-BOUND-REQUEST = TRUE.

oraz unbound.p

/* unbound.p  */
.....
SESSION:SERVER-CONNECTION-BOUND-REQUEST = FALSE.
QUIT.

Pierwsza procedura (patrz poprzedni artykuł) wiąże sesję klienta ABL z sesją PAS, drugą ją zwalnia.
Przejdżmy teraz do ustawień serwera PAS w OE Explorer -> Startup Parameters and Environment. Możemy podać tu nazwy procedur dla różnych operacji. Podobne ustawienia są możliwe na klasycznych AppSerwerze.

Dla trybu state-reset wystarczy podać nazwy tych procedur dla Connect i Disconnect jak na powyższym rysunku. Komenda QUIT powoduje zresetowanie sesji ABL. Jeśli procedury te zawierają inne Wasze instrukcje, to instrukcja wiążąca powinna być na początku w bound.p a procedura zwalniająca i QUIT na końcu unbound.p.

Dla trybu state-aware postępujemy analogicznie, tylko że w procedurze unbound.p NIE umieszczamy instrukcji QUIT.

Dla trybu stateless nie trzeba robić żadnych zmian ponieważ wiązanie i zwalnianie sesji może wystąpić w różnych miejscach logiki biznesowej i zależy od dewelopera aplikacji.

Load Balancing. Jeśli posiadamy produkt Name Server Load Balancer, to może konfigurować balansowanie obciążeniem klasycznego AppSerwera. Polega to z grubsza na dodaniu logicznej nazwy serwisu w kilku instancjach AppSerwera i określeniu procentu obciążenia w polu Weight.

Serwer aplikacji PAS nie łączy się jednak przez Name Server i nie da się tego tutaj tak zrobić. Load balancing dla PASOE można skonfigurować korzystając ze standardów HTTP takich jak: Apache proxy host load balancing, Tomcat load balancing, Amazon load balancing. Zainteresowanych tym tematem odsyłam do dokumentacji: Progress® Application Server for OpenEdge®: Administration Guide.

Development , ,

Procedury ABL i serwer aplikacji PAS cz.I

Od kilku miesięcy informujemy o nowych możliwościach serwera aplikacji PAS. Pytanie co z uruchamianiem procedur ABL, które działały do tej pory na klasycznym AppSerwerze? Czy trzeba je modyfikować? Czy migracja jest trudna dla przeciętnego programisty? Na te i podobne pytania postaram się odpowiedzieć w tym i następnym artykule.

Zacznijmy od uruchomienia instancji serwera aplikacji PAS o nazwie oepas1 (podobnie jak w poprzednich artykułach).
Przypominam, że PAS jest podłączony do bazy sportsdb, a w PROPATH znajduje się podkatalog openedge, do którego skopiujemy procedury abl (patrz poniżej).

Do uruchamiania procedur openedge potrzebny jest aktywny adapter, obsługujący warstwę transportową apsv. Sprawdzamy czy jest on aktywny w OpenEdge Explorerze lub wpisując w przeglądarce url: localhost:[port]/apsv. Jak widać poniżej adapter jest aktywny.


Teraz możemy uruchomić na kliencie program podłączający się do serwera aplikacji i uruchamiający tę samą procedurę FindCustomerByName, którą uruchamialiśmy dla web serwisów SOAP.
Najpierw zrobimy to dla modelu SESSION-FREE.

/* SESSION-FREE  */

DEFINE VARIABLE hServer AS HANDLE NO-UNDO.
DEFINE VARIABLE lReturn AS LOGICAL NO-UNDO.
DEFINE VARIABLE CustomerNumber AS CHARACTER NO-UNDO.

CREATE SERVER hServer.
lReturn = hServer:CONNECT("-URL http://localhost:8810/apsv
  -sessionModel Session-free"). 

IF NOT lReturn THEN DO:
  DELETE OBJECT hServer NO-ERROR.
  RETURN ERROR "Failed to connect to the ABL web application: " + RETURN-VALUE.
END.

RUN FindCustomerByName ON hServer (INPUT "Lift Tours", INPUT-OUTPUT CustomerNumber).

MESSAGE CustomerNumber
    VIEW-AS ALERT-BOX INFORMATION BUTTONS OK.

lReturn = hServer:DISCONNECT().
DELETE OBJECT hServer NO-ERROR.

Kod podłączenia i uruchomienia procedury jest bardzo podobny jak dla klasycznego AppServera.

W OpenEdge Explorerze w widoku Sessions widać otwartą sesję ze stanem Unbound (Bound=false), czyli sesja agenta nie jest powiązana z klientem.


Kod dla podłączenia w modelu SESSION-MANAGED różni się tylko dla metody CONNECT. Jego działanie jest identyczne jak w powyższym przykładzie.

/* SESSION-MANAGED */

DEFINE VARIABLE hServer AS HANDLE  NO-UNDO.
DEFINE VARIABLE lReturn AS LOGICAL NO-UNDO.
DEFINE VARIABLE CustomerNumber AS CHARACTER NO-UNDO.

CREATE SERVER hServer.
lReturn = hServer:CONNECT
  ("-URL http://localhost:8810/apsv","","").

IF NOT lReturn THEN DO:
  DELETE OBJECT hServer NO-ERROR.
  RETURN ERROR "Failed to connect to the ABL web application: " + RETURN-VALUE.
END.

RUN FindCustomerByName ON hServer (INPUT "Lift Tours", INPUT-OUTPUT CustomerNumber).

MESSAGE CustomerNumber
    VIEW-AS ALERT-BOX INFORMATION BUTTONS OK.

lReturn = hServer:DISCONNECT().
DELETE OBJECT hServer NO-ERROR.

Ponieważ uruchomiłem 3 takie same programy na kliencie, to w widoku Agents mam co prawda dalej tylko jednego agenta, ale 3 jego sesje.


Żeby powiązać daną sesję agenta z klientem stosujemy tę samą sztuczkę jak w przypadku klasycznego AppSerwera: w procedurze uruchamianej na serwerze aplikacji dodajemy komendę:

SESSION:SERVER-CONNECTION-BOUND-REQUEST = TRUE.

Powiązanie stosuje się aby łatwiej zarządzać kontekstem, gdyż ta sama sesja agenta może obsłużyć kilka/wiele żądań pomiędzy aplikacją kliencką a daną sesją. Zwolnienie sesji odbywa się zazwyczaj przez uruchomienie tej samej komendy z wartością FALSE.  Poniżej, w widoku Sessions widać 3 sesje ze stanem Bound (Bound=true).


Ciąg dalszy niebawem w drugiej cześci…

Development ,