Tag: OE serwis

Web Serwisy SOAP i serwer aplikacji PAS cz.II

W poprzedniej części wygenerowaliśmy 2 pliki r-kodów, które chcemy wystawić jako web serwisy SOAP. Mamy także wygenerowane przy pomocy narzędzia Proxy Generator pliki CustOrder.wsm oraz CustOrder.wsdl.

Plik .wsdl posłuży nam do wygenerowania dokumentacji o zdefiniowanym web serwisie. W oknie komend wpisujemy polecenie:

bprowsdldoc custorder.wsdl ./output

W podkatalogu output znajdziemy nowe pliki .html, zawierające informacje o zdefiniowanych procedurach, funkcjach itp. Są także przykłady kodu do przyłączenia i uruchomienia wybranej metody. Poniżej znajdują się definicje dwóch procedur z listą parametrów. Proszę zauważyć, że został automatycznie dodany parametr result.

Aby wdrożyć nowy web serwis musimy mieć instancję serwera PASOE. Posłużę sie tutaj tą samą instancją z przyłączoną bazą sports2000, jak opisałem w artykule o serwisach REST.

Kopiuję 2 r-kody do podkatalogu openedge w ścieżce PROPATH dla serwera aplikacji, a następnie uruchamiam komendę:

C:\WrkOpenEdge117\oepas1\bin\deploySOAP.bat custorder.wsm ROOT


Web serwis jest już wdrożony. Restartuję serwer aplikacji i przystępuję do testów. Najpierw FindCustomerByName.

DEFINE VARIABLE NAME AS CHARACTER NO-UNDO.
DEFINE VARIABLE CustomerNumber AS INTEGER NO-UNDO.
DEFINE VARIABLE result AS CHARACTER NO-UNDO.
    
DEFINE VARIABLE hWebService AS HANDLE NO-UNDO.
//DEFINE VARIABLE CustomerOrderObj AS HANDLE NO-UNDO.
DEFINE VARIABLE hPortType AS HANDLE NO-UNDO.

DEFINE VARIABLE lReturn AS LOGICAL NO-UNDO.

CREATE SERVER hWebService.

lReturn = hWebService:CONNECT("-WSDL 'http://192.168.1.21:8810/soap/wsdl?targetURI=CustOrder' 
                               -Port CustOrderObj").

RUN CustOrderObj SET hPortType ON SERVER hWebService.

RUN FindCustomerByName IN hPortType(INPUT "Lift Tours", INPUT-OUTPUT CustomerNumber, OUTPUT result).

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

W wyniku dostajemy nr klienta dla zadanej nazwy.

Test dla GetOrderDetails wygląda podobnie.

DEFINE TEMP-TABLE OrderDetails
    FIELD OrderNum LIKE Order.OrderNum
    FIELD SalesRep LIKE Order.SalesRep
    FIELD OrderDate LIKE Order.OrderDate
    FIELD ShipDate LIKE Order.ShipDate
    FIELD TotalDollars AS DECIMAL
    FIELD OrderStatus LIKE Order.OrderStatus.
    
DEFINE VARIABLE hWebService AS HANDLE NO-UNDO.
DEFINE VARIABLE CustomerOrderObj AS HANDLE NO-UNDO.
DEFINE VARIABLE hPortType AS HANDLE NO-UNDO.
DEFINE VARIABLE result AS CHARACTER NO-UNDO.
DEFINE VARIABLE lReturn AS LOGICAL     NO-UNDO.

CREATE SERVER hWebService.

lReturn = hWebService:CONNECT("-WSDL 'http://192.168.1.21:8810/soap/wsdl?targetURI=CustOrder' 
                               -Port CustOrderObj").

RUN CustOrderObj SET hPortType ON SERVER hWebService.

RUN GetOrderDetails IN hPortType(INPUT 3, OUTPUT RESULT, OUTPUT TABLE OrderDetails).


FOR EACH OrderDetails:
   DISPLAY OrderDetails.
END.

I wynik…

Pragnę zwrócić tutaj uwagę na dwie sprawy. Po pierwsze dla serwisów SOAP nie trzeba było definiować specjalnego projektu w OE Dev Studio. Po drugie nie trzeba było instalować i konfigurować Java Servlet Engine, Web Servera i WS adaptera, bo PASOE wszystko to już zawiera. To ogromne zaleta i ułatwienie pracy.
Życzę udanych projektów!

Development , ,

Web Serwisy SOAP i serwer aplikacji PAS cz.I

Tak się złożyło, że ostatnio kilkakrotnie byłem pytany przez klientów o  wystawianie web serwisów typu SOAP. Takie serwisy określane są czasem jako te “stare” w stosunku do serwisów typu REST. Są większym obciążeniem dla sieci (format danych XML) ale od wielu lat umożliwiają integrację/wymianę danych między różnymi systemami. Wspierane są też przez tradycyjny OpenEdge AppServer.

Pytanie, na które teraz należy odpowiedzieć to, czy nowy serwer aplikacji PASOE, lub jak kto woli PAS (Progress Application Server for OpenEdge) obsługuje także serwisy SOAP.

Żeby odpowiedzieć na to pytanie przyjrzyjmy się najpierw właściwościom pliku dla lokalnej instancji serwera w katalogu roboczym …\oepas1\conf\openedge.properties. W pliku tym znajdziemy wpisy:

[oepas1.ROOT.SOAP],

[oepas1.ROOT.REST],

[oepas1.ROOT.WEB],

[oepas1.ROOT.APSV].

Są to cztery warstwy transportowe; dla każdej zainstalowany i skonfigurowany jest adapter. Żeby wiedzieć czy dany adapter jest włączony trzeba sprawdzić ustawienie adapterEnabled; jeśli 1 to włączony. Pamiętajmy, że te ustawienia lepiej zmieniać poleceniem z linii komend niż bezpośrednio w pliku, a więc np.:
oeprop oepas1.ROOT.SOAP.adapterEnabled=1

Innym miejscem gdzie możemy sprawdzić powyższe ustawienia jest OpenEdge Explorer. Należy otworzyć widok w instancji serwera dla aplikacji webowej ABL ROOT (ABL WebApp: ROOT).

OK, ale jak w ogóle przygotować kod aplikacji do wystawienia za pomocą serwisu SOAP? Pierwszy etap jest dokładnie taki sam jak dla klasycznego AppServera. Ponieważ nie wszyscy korzystali dotychczas z tej metody omówimy ją na prostym przykładzie.

Mamy 2 oddzielne procedury, które chcemy wyświetlić w postaci web serwisów. Pierwsza FindCustomerByName.p zwraca numer rekordu Customer dla zadanej wartości Name.

DEFINE INPUT PARAMETER NAME AS CHARACTER.
DEFINE INPUT-OUTPUT PARAMETER CustomerNumber AS INTEGER.

FIND FIRST Customer WHERE Customer.NAME = NAME NO-ERROR.
IF AVAILABLE Customer THEN
    CustomerNumber = Customer.CustNum.
ELSE
    CustomerNumber = ?.

Druga procedura GetOrderDetails.p zwraca tablicę tymczasową zawierającą dane zamówień dla wybranego rekordu Customer.

DEFINE INPUT PARAMETER thisCust AS INTEGER NO-UNDO.

DEFINE TEMP-TABLE OrderDetails
    FIELD OrderNum LIKE Order.OrderNum
    FIELD SalesRep LIKE Order.SalesRep
    FIELD OrderDate LIKE Order.OrderDate
    FIELD ShipDate LIKE Order.ShipDate
    FIELD TotalDollars AS DECIMAL
    FIELD OrderStatus LIKE Order.OrderStatus.
    
DEFINE OUTPUT PARAMETER TABLE FOR OrderDetails.

FUNCTION GetTotalDollars RETURNS DECIMAL PRIVATE
  (OrderNum AS INTEGER)  FORWARD.

FIND FIRST Customer WHERE Customer.CustNum = thisCust NO-ERROR.
IF NOT AVAILABLE Customer THEN RETURN ERROR. 

EMPTY TEMP-TABLE OrderDetails.

FOR EACH Order WHERE Order.CustNum = thisCust:
    CREATE OrderDetails.
        ASSIGN 
            OrderDetails.OrderNum = Order.OrderNum
            OrderDetails.SalesRep = Order.SalesRep
            OrderDetails.OrderDate = Order.OrderDate
            OrderDetails.ShipDate = Order.ShipDate
            OrderDetails.OrderStatus = Order.OrderStatus.

        OrderDetails.TotalDollars = GetTotalDollars(Order.OrderNum).
END.

FUNCTION GetTotalDollars RETURNS DECIMAL PRIVATE
  (OrderNum AS INTEGER) :

    DEFINE VARIABLE TotalDollars AS DECIMAL NO-UNDO INITIAL 0.0.

    FOR EACH OrderLine WHERE OrderLine.OrderNum = OrderNum:
        TotalDollars = TotalDollars + OrderLine.ExtendedPrice.
    END.
    RETURN TotalDollars.
END FUNCTION.

Obie procedury kompilujemy do postaci r-kodu.
Teraz otwieramy narzędzie Proxy Generator. Służy ono do generowania plików tzw. proxy do integracji z interfejsem Javy i .NET, a także do definiowania web serwisów SOAP.
Definiowanie serwisów jest bardzo proste. Tworzymy nowy projekt np. CustOrder i podajemy ścieżkę do r-kodów.

Następnie w menu Procedure -> Add dodajemy 2 r-kody jako procedury Non-persistent.

Teraz przechodzimy do ustawień: Options -> Preferences. Ustawiamy Client type: Web Service oraz Output directory gdzie zostaną zapisane wygenerowane pliki. Pozostałe ustawienia są wykorzystywane dla klasycznego AppServera i zostaną zignorowane przez serwer PASOE. Przypominam, że dla nowego serwera aplikacji nie trzeba instalować i konfigurować JSE, adaptera WSA ponieważ te elementy są już wbudowane w produkt.

Teraz wybieramy opcję Generate i OK. W wybranym katalogu pojawiły się pliki CustOrder.wsm oraz CustOrder.wsdl (oraz log).
O tym jak wykorzystać te pliki i jak wdrożyć web serwis w serwerze aplikacji PASOE napiszę następnym razem.

Development , ,

Wystawianie serwisów REST z aplikacji ABL cz.II

Po dłuższej przerwie wracamy do zagadnienia związanego z udostępnieniem serwisu typu REST, który został zdefiniowany tutaj.

Taki zdefiniowany serwis trzeba wyeksportować. W tym celu klikamy prawym przyciskiem myszy na nazwę serwisu i wybieramy Export. Eksportowanie można zrobić na 2 sposoby: jako plik WAR lub ZIP. W pierwszym przypadku jest to oddzielny kompletny serwis, w drugim, serwis będzie doinstalowany do domyślnego serwisu ROOT  (Export services incrementally). Tutaj wybieram tę drugą metodę.

Proces wdrożenia przeprowadzimy na innej maszynie, na bazie danych sportsdb (kopia bazy sports2000).

Do wdrożenia potrzebny będzie plik klasy (customer.r) oraz oczywiście definicji serwisu (CustomerServ.zip).

Na nowej maszynie mamy instalację OpenEdge 11.7 z katalogiem roboczym C:\WrkOpenEdge117 i domyślną instalacją PAS: oepas1.

Najpierw w katalogu C:\WrkOpenEdge117\oepas1\openedge umieszczamy plik customer.r. Katalog ten znajduje się na liście PROPATH serwera aplikacji. W parametrach startowych agenta podajemy nazwę bazy, tutaj: -db sportsdb -ld sports2000. Parametr -ld (logiczna nazwa bazy) jest konieczny, ponieważ plik customer.r był skompilowany dla bazy sports2000. Zarówno PROPATH jak i parametry przyłączenia bazy można zobaczyć na poniższym obrazie.

Teraz nawigujemy do katalogu C:\WrkOpenEdge117\oepas1\webapps
gdzie umieszczamy plik CustomerServ.zip.

Uruchamiamy proenv i upewniamy się, że jesteśmy w powyższym katalogu. Podajemy komendę, która wdroży serwis przyrostowy dla ROOTa:

C:\WrkOpenEdge117\oepas1\bin\deployREST.bat CustomerServ.zip ROOT

Po zrestartowaniu serwera aplikacji serwis REST jest gotowy. Możemy go teraz przetestować. W tym celu w przeglądarce Chrome otwieramy Advanced REST client. Aplikacja jest typu application/json. Podajmy żądanie GET dla pobrania wybranego rekordu (metoda ReadCustomer): localhost:8810/rest/CustomerServService/Customers/5

Odpowiedź widać poniżej: rekord o nr 5 został pobrany i wyświetlony.

Podobnie sprawdzamy działanie metody ReadAllCustomers.

Wyświetlone są wszystkie rekordy.

Serwis działa poprawnie.

Następnym razem omówię trochę zapomniane web serwisy typu SOAP, ale wywoływane przez nowy serwer aplikacji PASOE.

Development , ,

Wystawianie serwisów REST z aplikacji ABL cz.I

We wcześniejszych wpisach opisałem sposób tworzenia serwisów uruchamianych na serwerze aplikacji PAS (obecna nazwa to Application Server for OpenEdge), korzystających z danych strukturalnych JSDO.

Pora teraz na bardziej praktyczny przykład, opisujący wystawienie własnych serwisów REST ze zdefiniowaniem wystawianych zasobów i ich mapowaniem. W porównaniu do wcześniejszej metody będzie więcej czynności do wykonania ale dostaniemy znacznie większe pole manewru.

Na początek mamy projekt CustomerServ typu OpenEdge i prostą aplikację – klasę ABL Customer.cls z metodami dla zasobu Customer: ReadCustomer, ReadAllCustoomers, UpdateCustomer.


Ważne jest aby te metody były state-free, tzn. nie przekazywały kontekstu między wywołaniami.

Teraz prawy klik myszy na nazwie klasy Customer.cls -> Progress OpenEdge -> Define Service Interface.

Wybieramy Definition mode: REST i zaznaczamy wszystkie metody klasy, NEXT.

Do pliku klasy zostaną wstawione adnotacje. Nic tu nie zmieniamy. Finnish.

Widzimy, że pod Defined Services został zdefiniowany serwis CustomerServService oraz został dodany katalog PASOEContent dla serwera aplikacji.

Po prawej stronie otwiera się REST Resource URI Editor. Jeśli go nie ma to: prawy klik myszy Defined Service -> CustomerServService i wybieramy Edit.

Z operacjami na danych związane są tzw. czasowniki HTTP (HTTP verbs):

POST: operacja CREATE – tworzy nowy rekord

GET (domyślny): operacja RETRIEVE – zwraca rekord na bazie podanego ID

PUT: operacja UPDATE – aktualizuje istniejący rekord

DELETE: operacja DELETE – usuwa istniejący rekord.

Dodajemy 2 zasoby: /Customer (dla wszystkich rekordów Customer) oraz /Customer/{custNum}.

Dla zasobu /Customer kojarzymy verb GET z metodą ReadAllCustomers. Dla /Customer/{custNum} kojarzymy verb GET z metodą ReadCustomer, a PUT z UpdateCustomer.

Teraz trzeba zmapować parametry dla każdej operacji pomiędzy parametrami wejścia HTTP request a parametrami wejścia ABL oraz parametrami wyjścia ABL a parametrami HTTP response.

Najpierw mapujemy operacje dla ReadAllCustomers GET: input Complete URL w HTTP Request do URI  w Interface Parameters; Query String Parameters w HTTP Request do num w Interface Parameters.
Teraz output: ttAllCustomers w Interface Parameters do Body w HTTP Response.

Dla ReadCustomer GET mapujemy: input – Path Parameters custNum w HTTP Request do custNum w Interface Parameters.
Output: CustomerRecord w Interface Parameters do Body w HTTP Response.

Na koniec dla UpdateCustomer PUT mapujemy: input – Path Parameters custNum w HTTP Request do custNum w Interface Parameters oraz Body w HTTP Request do CustomerRecord w Interface Parameters.
Output: CustomerRecord w Interface Parameters do Body w HTTP Response.

Zakończyliśmy definiowanie serwisu REST.

 

Development , ,

Serwisy REST – porównanie różnych typów

W kilku wcześniejszych artykułach opisałem, krok po kroku, tworzenie serwisu typu REST, wykorzystującego obiekty JSDO.

Wiem od niektórych z Was, że z tymi serwisami wiążą się pewne niejasności. Nic w tym dziwnego, to nie są progressowe technologie i wiążą się o stworzone niedawno standardy.

Kilka osób pytało mnie np. o różnice między tworzeniem serwisu REST na bazie projektów: Data Object, ABL Web App czy REST (rysunek poniżej).

Pierwsze dwa typy projektów służą do tworzenia serwisów Data Object. W Progress Developer Studio for EpenEdge zaimplementowano dwa typy projektów ze względu na dwa rodzaje AppServerów, z którymi współpracują.
Projekt Data Object jest wykorzystywany do tworzenia serwisów przy użyciu klasycznego AppServera, a ABL Web App z Pacific AppServer. Do wersji OpenEdge 11.5 włącznie zamiast tych dwóch projektów był dostępny tylko projekt Mobile.

W obu projektach (Data Object, ABL Web App) można utworzyć Business Entity – obiekt danych np. Customer czy Order, z którym tworzona jest klasa obiektu oraz obiekty JSDO. Klasa zawiera gotowe metody realizujące różne funkcje na danych (Create, Read, Update, Delete). Tworzony jest także plik . json, który można użyć definiując obiekty w środowisku Rollbase czy Telerik. Jest to prosta, szybka metoda, nie wymagająca szczegółowej wiedzy dewelopera nt serwisów REST.

Inne podejście jest reprezentowane w projekcie typu REST. Projekt ten wybierają deweloperzy  gdy aplikacja wymaga bezpośredniego dostępu do kontekstu HTTP (request/response), nagłówka, cookies itp. Daje to dodatkowe możliwości ale wymaga o wiele więcej pracy. Trzeba samemu “zamapować” każdą procedurę, klasę i parametr; dodać notacje itd.

Np. dodać nowe zasoby, parametry oraz przypisać im określone czasowniki (verb) możemy w narzędziu REST Resource URI Editor.

Development , , ,

Rollbase i serwisy OpenEdge

W poprzednim artykule obiecałem, że stworzymy w Rollbase aplikację, opierającą się o dane z bazy danych OpenEdge. Wykorzystamy do tego serwis OE, o którym pisałem w części I i w części II.

W naszej aplikacji będziemy korzystać z dwóch tablic: Customer i Order, dlatego do serwisu OE trzeba dodać obiekt (business entity) Order.

Podobnie jak dla obiektu Customer, klikamy na podkatalog AppServer i wybieramy New -> New -> Business Entity. Podajemy nową nazwę obiektu Order i klikamy Next.

W drugim kroku wybieramy aktywne połączenie z bazą danych i wybieramy  tabelę Order, a następnie Finish.

Widzimy, że w podkatalogu AppServer utworzyły się pliki dla nowego zasobu, w tym plik klasy Order.cls.

Ponownie nowy obiekt biznesowy trzeba dodać do serwisu. Rozwijamy Defined Services i prawym klawiszem klikamy na Edit a następnie Next.

Na ekranie Create a Data Object service zaznaczamy Order.cls i klikamy Finish.

Po zrestartowaniu serwera aplikacji PAS możemy podejrzeć, że nowo-utworzony plik .json zawiera struktury Customer i Order.

Obiekt Order, to plik klasy oraz ProDataSet dsOrder, zawierający tablicę tymczasową ttOrder.

Żeby z serwisu OE utworzyć obiekt w Rollbase wymagane jest aby tablica tymczasowa zawierała przynajmniej jedno pole tekstowe, które posłuży do mapowania dla pola Record Name (w tablicy ttCustomer jest pole Customer.Name).

W tablicy ttOrder takiego pola nie ma, dlatego musimy je utworzyć.

Wygodnie jest posłużyć się tutaj tzw. Callback Procedure. Są to procedury podobne do trygerów w 4GL i dotyczą różnych zdarzeń w ProDataSecie (jeszcze jeden powód, dla którego warto znać ProDataSety!).

Najpierw w pliku oder.i dodamy pole OrderName typu znakowego.

Następnie w pliku Order.cls w metodzie ReadOrder dodajemy dla tablicy ttOrder Callback Procedure o nazwie AddField dla zdarzenia After-Row-Fill, która będzie wywołana po zapełnieniu każdego rekordu w tabeli tymczasowej.

Poniżej metody ReadOrder definiujemy procedurę AddField.

Każdy rekord ttOrder będzie miał tekstową wartość w polu OrderName złożoną z nr klienta i nr zamówienia.

Klasę Order.cls należy teraz skompilować (prawy klik, Compile).

Aby plik .json miał aktualną strukturę z nowym polem postępujemy podobnie jak kilka kroków powyżej.

Teraz przejdźmy do Rollbase’a.

Nasuwa się pytanie czy nie można było utworzyć jeden ProDataSet z dwoma tablicami tymczasowymi i relacją między nimi? Przecież w PDS można to zrobić bez trudu. Otóż Rollbase ma ograniczenie polegające na tym, że mapować można tylko PDS złożone z pojedynczych tablic.

Przejdźmy do ekranu Create a New Application. Kto nie pamieta jak to zrobić niech kliknie TUTAJ.

Klikamy Create from External Data. Pojawia się ekran

Musimy odszukać ścieżkę do pliku .json: [workspace]\mobile6\PASOEContent\static

oraz URI dla serwisu. Next

Chociaż podaliśmy URI dla Customera, Rollbase proponuje na podstawie pliku .json utworzenie 2 obiektów: ttCustomer, ttOrder.

Klikamy Next. Zaznaczamy pola, które maja zawierać obiekty. Trzeba poprawić pola Resource URI, bo mają niepoprawne wartości. Dla pola OrderName ustawiamy typ Record Name. Bez wybrania tego typu dla jednego pola, pojawi sie błąd. Dlatego zadaliśmy sobie wcześniej trochę trudu, aby takie pole utworzyć w ttOrder. W ttCustomer typ Record Name jest przypisany automatycznie dla pola Name.

Klikamy Create. Nasza aplikacja (nazwa mobile6Service) pojawia się na liście aplikacji.

Po wybraniu aplikacji można przeglądać rekordy ttOrders i ttCustomers. Na razie nie są one ze sobą powiązane.

Teraz zbudujemy relację między ttOrders i ttCustomers.

Wchodzimy w ustawienia aplikacji (koło zębate)

Klikamy na nazwę obiektu ttOrder

Tworzymy nowa relację klikając New OpenEdge Relationship.

Ustawiamy pole relacji CustNum

Rodzaj relacji ustawiamy na Many ttOrders to One ttCustomer.

Poniżej sa dodatkowe ustawienia. Warto m.in. mieć możliwość wstawiania ttOrders do widoków ttCustomers (przykład za chwilę). Save.

Wchodzimy ponownie w podgląd danych ttCustomers i budujemy nowy widok (Create New View).

Wybieramy pola wraz z ttOrders, które już się pojawiło na liście.

Mamy efekt końcowy, do którego dążyliśmy.

Development ,

Rollbase – aplikacje w chmurze

Rollbase – platforma PaaS (Platform as a Service), służy do budowania aplikacji biznesowych. Dostęp do Rollbase jest przez przeglądarki internetowe, a budowanie w znaczącej mierze polega na czynnościach “przeciagnij i upuść” i zminimalizowanym programowaniu.

Rollbase oferuje dostęp do środowiska w chmurze prywatnej (Private Cloud), instalowanej w lokalnej sieci lub hostingowej (Host Cloud), dostępnej zdalnie u dostawcy usług.

Rozbudowany interfejs webowy został przeprojektowany w wersji 4.0. Wykorzystuje on obecnie nowoczesne komponenty Kendo UI Telerika (obiekty ekranowe, motywy) i sprawia, że dopasowuje się on automatycznie do zmiennych rozmiarów ekranu oraz pozwala na tworzenie aplikacji o nowoczesnym wyglądzie, które działają na różnych urządzeniach. Nowy interfejs korzysta także z zestawu Font Awesome, skalowalnych ikon wektorowych, które można łatwo dopasować za pomocą CSS.

Administratorzy, zarządzający środowiskiem Rollbase mogą przełączać między nowym a klasycznym interfejsem, w zależności od potrzeb klientów.

Aby mieć darmowy dostęp do tego środowiska możemy zapisać się na okres 30-dni.

Po zalogowaniu się do Rollbase’a widzimy listę przykładowych aplikacji. Większość z nich zawiera mało danych. Możemy sami je dodać, robić zestawienia, edytować itd. Możemy wreszcie utworzyć własną aplikację.

Na tej samej stronie w przeglądarce, po prawej stronie znajdują się odnośniki do tworzenia takich aplikacji oraz do zasobów wiedzy nt Rollbase’a.

Klikając przycisk Quick Create Start rozpoczynamy tworzenie nowej aplikacji od zera, przy czym jesteśmy “prowadzeni za rękę” po kolejnych etapach. Jak to wygląda, można obejrzeć na krótkim filmie.

No dobrze, ale co zrobić jeśli nie chcemy wprowadzać danych od nowa tylko wykorzystać te istniejące w bazie OpenEdge? Jest tutaj kilka opcji, ale najbardziej uniwersalną i zalecaną metodą jest wykorzystanie serwisu OpenEdge typu REST, np. takiego jaki stworzyliśmy w zeszłym miesiącu.

Aby to zrobić należy odszukać w środowisku przycisk tworzenia nowej aplikacji (ale nie od zera). Opiszę jak go znaleźć w wersji 4.0.x

Klikamy nieco ukryte menu (strzałka)…

…i New Applications.

Innym sposobem można rozwinąć menu Rollbase i wybrać Setup Home…

Następnie New Application.

Tym czy innym sposobem, otwiera się okno Create a New Application.

Guide Me Throught It to tworzenie aplikacji od zera.

Install from Marketplace – Marketplace to rodzaj sklepu online, w którym użytkownicy mogą instalować swoje aplikacje i dzielić je z innymi użytkownikami.

Create from Existing Objects – wykorzystujemy w nowej aplikacji zdefiniowane wcześniej obiekty.

Create from External Data – to metoda, której szukamy. Wykorzystuje ona utworzone wcześniej metadane, np. serwisu OpenEdge.

Metodę tę pokażę następnym razem.

Development, Info ogólne ,

Serwis OpenEdge – Telerik Kendo UI

W niniejszym “odcinku” pokażę jak wykorzystać utworzony wcześniej serwis REST OpenEdge jako źródło danych w produkcie Telerik Kendo UI.

Mamy więc gotowy serwis i działający serwer aplikacji PAS.

Kendo UI, to zestaw bibliotek tworzących interfejs webowy oparty na HTML5 i JavaScript.

Należy pobrać plik ZIP i rozpakować w lokalnym katalogu.
Zawiera on bibliotekę funkcji JavaScript dla obiektów JSDO oraz przykładowe pliki HTML. Każdy z takich plików zawiera linki do dalszych bibliotek na stronach Progressa i Telerika.
Pliki te wygodnie jest otwierać w Notepad++.

Otwórzmy w Notepad++ plik Our_Sample.html. W sekcje HEAD znajdują się odnośniki do zewnętrznych bibliotek.

Nas bardziej interesuje sekcja SCRIPT, a dokładniej parametry serviceURI, catalogURI oraz resourceName, które powinny mieć wartości zgodne z utworzonym serwisem.

Po edycji tych parametrów plik HTML wygląda następująco:

Klikając na nagłówek kolumny dane są sortowane wg jej wartości. Można przeciągnąć nagłówek kolumny do górnej strefy i wtedy dane będa pogrupowane. Można także edytować, kasować i tworzyć nowe rekordy.

Pozostałe pliki html prezentują dane z serwisów zewnętrznych. Np. Other_KendoUIPieChart.html

Co teraz? Chciałbym pokazać jak wykorzystać dane z naszego serwisu w Telerik Platform for OpenEdge, ale przedtem trzeba wziąć na warsztat system Rollbase. Do Telerika jednak niedługo wrócimy.

Development , , , ,

Tworzenie serwisów OpenEdge cz. II

W poprzedniej części pokazałem jak stworzyć projekt oraz serwis OpenEdge. Teraz zajmiemy się utworzeniem logiki biznesowej aby wystawić przez ten serwis dane z bazy Progress.

W widoku Project Explorer klikamy prawym klawiszem myszy na podkatalog AppServer i wybieramy New -> Business Entity.

Tworzymy nową klasę obiektu biznesowego np. Customer. Pamiętajmy, że w nazwie rozróżnia się wielkość liter. Można opcjonalnie wypełnić pola Description i Purpose. Klikamy Next.

Ekran Select a schema file. Wybieramy aktywne połączenie z bazą danych oraz tabelę Customer. (W tym miejscu możemy zamiast połączenia z bazą wskazać przygotowany wcześniej plik schematu, w którym będzie zdefiniowany ProDataSet z kilkoma tabelami). Zauważmy listę operacji, jakie zostaną zdefiniowane w klasie. Domyślnie są to CRUD czyli: Create, Read, Update, Delete i takie zostawiamy.

Klikamy Finish.

Można zauważyć, że w projekcie pojawiły się nowe zasoby (podkatalog AppServer): plik klasy Customer.cls, plik customer.i z definicjami ProDataSeta dsCustomer oraz tablicy tymczasowej ttCustomer.

Plik Customer.cls zawiera gotowe metody dla operacji CRUD. Dane będą przekazywane między bazą OpenEdge a ProDataSetem. Możemy modyfikować te metody dla naszych potrzeb. Teraz jednak zostawiamy je w stanie domyślnym.

Teraz nowy obiekt biznesowy trzeba dodać do serwisu. Rozwijamy Defined Services i prawym klawiszem klikamy na Edit.

Ekran Edit an ABL Service. Nic tu nie zmieniamy. Next.

Ekran Create a Data Object service. Zaznaczamy zdefiniowane wcześniej zasoby, czyli klasę Customer. Zanotujmy składnię URI, przez którą będzie dostęp do naszych zasobów OpenEdge w serwisie REST. Finish.

W podkatalogu static został wygenerowany plik mobile6.json zawierający opis serwisu. Zajrzymy do niego za chwilę.

Otwieramy widok Servers i uruchamiamy naszą instancję appservera oepas1 . Może to potrwać kilka minut.

Po uruchomieniu appservera PAS wpisujemy w przeglądarce www link:

http://localhost:8810/mobile6/rest/mobile6Service/Customer

Widać, że udostępniliśmy tabelę Customer poprzez serwis REST.

Jeśli chcemy podejrzeć plik json, możemy go odszukać i otworzyć na dysku lub wpisać poniższy link:

http://localhost:8810/mobile6/static/mobile6Service.json

Następnym razem pokażę prosty przykład jak wykorzystać gotowy serwis z technologią Telerik.

Development , , ,

Tworzenie serwisów OpenEdge cz. I

Chcę teraz napisać o tworzeniu serwisów typu REST, które są bardzo przydatne w integracji danych pochodzących z baz OE z nowym front-endem np. Rollbase, Telerik Kendo UI czy z urządzeniami mobilnymi.

Wspomniałem o tym w zeszłym miesiącu w artykule o JSDO.

Serwisy tworzymy w Progress Developer Studio for OpenEdge. Zakładam, że mamy skonfigurowane środowisko: w zakładce Servers widzimy : Pacific AppServer (domyślna nazwa oepas1)

oraz w Preferencjach mamy zdefiniowane połączenie z bazą danych sports (kopia bazy sports2000).

Gdyby były problemy z dojściem do tego miejsca, to bardzo proszę o wiadomość. Opis jest tutaj.

Proces tworzenia nieznacznie różni się od tego miejsca w OE 11.5 od OE 11.6. Najpierw zajmiemy się wersją OE 11.5.

Tworzymy nowy projekt OpenEdge (nazwa np. mobile5), wybieramy typ Mobile. Klikamy Next.

Pojawia się ekran Select AVM and Layout Options. Nic tu nie zmieniamy, klikamy Next.

Następny ekran: Define AppServer content module. Zaznaczamy, który serwer aplikacji będzie obsługiwał nasz serwis. Tutaj wybieramy PAS, czyli oepas1. (Gdybyśmy chcieli użyć tradycyjnego OE AppServera, to moglibyśmy wybrać restbroker1).

Zaznaczamy Publish changes immediately i Next.

Ekran Create a Mobile service. Upewniamy się, że zaznaczona jest opcja Create a Mobile service oraz jako Supported servers wybrany oepas1. Klikamy Next.

Ekran Create a Mobile App. Ponieważ nie budujemy aplikacji mobilnej, a jedynie serwis, odznaczamy tę opcję. Next.

Ekran Define PROPATH. Nic nie zmieniamy. Next.

Ekran Select database connections. Dodajemy do projektu istniejące połączenie z bazą danych (zdefiniowane wcześniej). Klikamy Next.

Ostatni ekran: Static Web Pages, zawiarający konfigurację folderów serwisu. Nic tu nie zmieniamy. Klikamy Finish. Tworzony jest nowy projekt.

Po utworzeniu powinniśmy zobaczyć zasoby projektu jak poniżej.

Teraz zrobimy to samo dla OE 11.6.

Tworzymy nowy projekt OpenEdge (nazwa np. mobile6), wybieramy typ ABL Web App (dla klasycznego AppServera wybieramy typ Data Object). Klikamy Next.

Ekran Provide ABL Web App deploy details.

Zaznaczamy Web Application: Deploy as WebApp, Sopported servers: oepas1 oraz Publish changes immediately. Klikamy Next.

Na ekranie Ceate an ABL Service zaznaczamy typ serwisu: Data Object (Annotated RPC) i klikamy Next.

Ekran Select AVM and Layout Options. Nic tu nie zmieniamy, klikamy Next.

Kolejny ekran Define PROPATH. Nic nie zmieniamy. Next.

Ekran Select database connections. Dodajemy do projektu istniejące połączenie z bazą danych. Klikamy Finish i czekamy aż serwis zostanie utworzony.

W drugiej części zajmiemy się wystawianiem danych z bazy OpenEdge poprzez utworzony serwis.

 

Development , , ,