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…