Oracle APEX

Jadwiga Gnybek
Artykuł pochodzi z nr 50 czasopisma "Oracle'owe PLOUG'tki".

Oracle Application Express - sprytne, proste narzędzie do budowy aplikacji webowych, to następca HTML DB. Jeśli nie masz zbyt wygórowanych ambicji programistycznych, a aplikacja którą chcesz zbudować wydaje się być funkcjonalnie nieskomplikowana – spróbuj wejść na apex.oracle.com.

Mało jest środowisk deweloperskich łączących w sobie prostotę ze sprytnie dobraną gamą niezbędnych narzędzi, które pozwolą szybko zbudować bezpieczną, skalowalną i wydajną aplikację. Przyjrzyjmy się produktowi APEX - może to jest właśnie to?

Narzędzia APEX
Pierwszą pozytywną obserwacją jest fakt, że aby pracować w APEX nie trzeba instalować żadnego oprogramowania klienckiego. W oknie przeglądarki na stronie startowej widzimy trzy narzędzia: Application Builder, SQL Workshop i Utilities. Cóż znajdziemy wewnątrz tych narzędzi? Application Builder - jak łatwo zgadnąć, to narzędzie służące do budowy interfejsu użytkownika, czyli warstwy HTMLa komunikującego użytkownika z logiką aplikacji oraz danymi zapisanymi w bazie Oracle. SQL Workshop, to narzędzie nieco bardziej złożone. W jego skład wchodzą cztery moduły. Object Browser służący do przeglądania, tworzenia, modyfikacji i usuwania obiektów bazodanowych, mający również funkcjonalność edytora PL/SQL umożliwiającego pisanie i kompilację pakietów, procedur, funkcji i wyzwalaczy tworzących zaawansowaną logikę aplikacji. SQL Commands służy do uruchamiania zapytań SQL oraz skryptów PL/SQL. SQL Scripts przeznaczono do tworzenia, przeglądania, uruchamiania i zarządzania lokalizacją plików skryptowych. I na koniec Query Builder, wspomagający swoim graficznym interfejsem proces budowy skomplikowanych zapytań oraz tworzenia relacji pomiędzy obiektami bazy.
Ostatnim, dużym składnikiem Oracle APEX jest moduł Utilities umożliwiający eksport i import danych, generowanie poleceń DDL oraz wykonywanie innych przydatnych w procesie budowy aplikacji zadań administratorskich na modelu danych. Wygląda więc, że nawet mało doświadczony programista poczuje się tu w miarę bezpiecznie.

Role bazodanowe
Mimo, że środowisko wygląda przyjaźnie i prosto, dla ustanowienia zasad i porządku rzeczy wyposażone zostało w kilka predefiniowanych ról bazodanowych. Najważniejszy jest oczywiście Oracle Application Express Administrator! Jest to pierwsza po Bogu osoba, mająca pod swoją pieczą konsolę Application Express Administration Services. Drugą co do ważności rolą w tym środowisku jest Workspace Administrator – czyli użytkownik wykonujący zadania administratorskie w obszarze podległego mu workspace. Do zadań tych zaliczyć należy zarządzanie użytkownikami i monitorowanie ich aktywności. Dalej jest Developer, czyli użytkownik który tworzy i modyfikuje aplikacje. Developer może mieć przypisany własny workspace lub współdzielić go z innymi developerami. W dalszej kolejności z obowiązku wymieniam jeszcze jedną, zdecydowanie mniej ważną rolę, czyli End User. Rola ta - jak wiemy - przysparza tym wymienionym w pierwszym rzędzie jedynie kłopotów i zmartwień. End User to rola przypisywana osobie chcącej skorzystać z funkcjonalności zbudowanej przez nas aplikacji. Oprócz prawa dostępu do aplikacji, ma ona nadużywane zwykle prawo do - na owe funkcjonalności, narzekania.


W tym miejscu warto wyjaśnić pojawiające się kilkakrotnie pojęcie workspace. Krótko mówiąc - workspace to obszar, w którym budowana jest aplikacja. To coś jakby prywatna wirtualna baza danych wykorzystywana przez developerów i użytkowników aplikacji. Obszar ten umożliwia pracę wielu środowisk Oracle Application Express na tej samej instancji bazy danych Oracle z zachowaniem rozdzielności praw do obiektów bazodanowych. Oczywiście tworzenie rozdzielnych obszarów deweloperskich nie jest koniecznością. Możliwa jest budowa kilku aplikacji w jednym workspace. Wygodniej i przejrzyściej jest jednak podzielić zasoby Oracle APEX na aplikacje lub projekty.


Do czego i dla kogo APEX?
Zastanówmy się zatem, do jakich zastosowań najlepiej wykorzystać to środowisko. Z pewnością APEX to prosty sposób na prezentację danych zapisanych w bazie, a więc „aplikacja raportowa” z możliwością wprowadzenia graficznej prezentacji danych. A co z edycją? Oczywiście tak! Builder pozwoli nam stworzyć całkiem funkcjonalny interfejs edycji danych.
Aby zostać projektantem i programistą aplikacji APEX w zasadzie wystarczą dobre chęci. Nie musimy gruntownie znać poleceń, pozwalających nam tworzyć niezbędne struktury danych. Podobnie, niezbyt wysokie kwalifikacje programistyczne wcale nie staną nam na przeszkodzie w zbudowaniu interfejsu użytkownika. Będziemy bowiem posługiwać się techniką nazwaną w dokumentacji „declarative programming”. W praktyce oznacza to, że użytkownik tego środowiska deweloperskiego definiować będzie interfejs użytkownika przy pomocy parametrów różnego typu wizardów. Nie oznacza to jednak, że znajomość SQLa możemy zupełnie odstawić do lamusa. Nie wymyślono bowiem jeszcze takiego wizarda, który pozwoliłby zrealizować wszystkie potrzeby biznesowe bez napisania choćby kilku linii kodu, czy przemedytowania wygenerowanego automatycznie zapytania. Innymi słowy: to, co proste i żmudne oddajemy w ręce automatu, koncentrując się na cyzelowaniu detali.

Architektura APEX
Zanim wejdziemy w głąb, powiedzmy jeszcze słów kilka o architekturze tego rozwiązania. Motor Application Express renderuje aplikacje w czasie rzeczywistym, korzystając z metadanych zapisanych w bazie. Uruchomienie aplikacji polega zatem na odczytaniu odpowiednich informacji z metadanych i wyświetleniu odpowiedniego fragmentu aplikacji. Całe środowisko deweloperskie zawarte jest zatem w bazie danych i składa się z zawierającej 215 tabel struktury danych i sporego (liczącego ponad trzysta tysięcy linii kodu) zbioru około dwustu obiektów PL/SQL. Dostęp do motoru APEX realizowany jest za pośrednictwem serwera Oracle HTTP Server (Apache) wyposażonego w plug-in mod_plsql. Mapuje on żądania Web browsera na wywoływane w bazie procedury PL/SQLowe.


Jeśli mamy do dyspozycji Oracle Database 11.1 możemy zrezygnować z usług Apache i jako medium komunikacyjne użyć PL/SQL gateway. PL/SQL gateway uruchamia w serwerze bazy Oracle XML DB odpowiedni http, zawierający w sobie właściwości mod_plsql.


Pod pojęciem Application Express Engine kryje się nie tylko rendering stron. Kryje się tu szereg funkcjonalności niezbędnych do poprawnej i bezpiecznej pracy aplikacji. Moduł odpowiada za zarządzanie sesjami, identyfikację i autoryzację użytkowników, proces walidacji i zarządzanie przepływem zadań w aplikacji (page flow control).
Jeśli popełniliśmy już kiedyś potrzebną nam do dziś aplikację w technologii Forms/Reports lub na przykład w MS Access, możemy przenieść ją stosunkowo małym nakładem pracy do technologii APEX. Pomoże nam w tym na pewno moduł Oracle Application Express Application Migration Workshop, który pozwoli nam na konwersję posiadanych kodów. Jeśli jesteśmy w posiadaniu przydatnych biznesowo kodów Oracle Forms, możemy je zaimportować do Oracle Application Express 3.2 i wygenerować szkielet aplikacji APEX zawierający elementy interfejsu użytkownika, odpowiadające obiektom użytym w technologii Forms. Niestety konwersji nie ulegnie logika biznesowa zapisana w wyzwalaczach i procedurach PL/SQL. Funkcjonalności te przekonwertowane zostaną za pośrednictwem wizardów wykorzystujących możliwości Web 2.0.

Elementy aplikacji
Przyjrzyjmy się teraz, jakie narzędzia oferuje nam to środowisko, czyli z jakich elementów będziemy mogli zbudować swoją aplikację. Zacznijmy od formularzy. Możemy je oprzeć o zbiór danych zapisanych w tabeli lub o wynik działania składowanej w bazie procedury PL/SQL. Budowa formularza opartego o tabelę automatycznie wyposaży go w mechanizmy wprowadzania, modyfikacji i kasowania danych. Jedyną rzeczą, która wymaga naszej ingerencji, jest rozmieszczenie poszczególnych obiektów formularza na ekranie. Podobnie, jak w aplikacjach realizowanych w innych technologiach, interfejs użytkownika zawierać może pola tekstowe, listy wyboru, przyciski radiowe, listy wyboru, check boxy itp. W graficznym przedstawianiu danych pomogą nam narzędzia do tworzenia wykresów. Możemy tu korzystać zarówno z technik HTML, SVG jak i Flash. Wykresy mogą być wzajemnie zagnieżdżone lub wywoływać szczegółowe dane źródłowe zebrane w postaci raportów. Aby zwiększyć wydajność i funkcjonalność aplikacji, graficzne prezentacje danych mogą być odświeżane z wykorzystaniem technologii Partial Page Refresh (PPR), a więc bez konieczności odświeżenia całej strony. Możemy również zdefiniować cykliczne odświeżanie danych na wykresie. Skoro mamy już jakiś zestaw danych, zapewne przydałaby się możliwość ich wyświetlania i drukowania w postaci raportów. Na ekranie przeglądarki raporty generowane są szybko za pośrednictwem HTML, ale w druku mamy już możliwość formatowania ich również w formatach XLS, PDF i RTF. Raporty wyświetlane w przeglądarce webowej mogą być wzajemnie zagnieżdżone, umożliwiając w ten sposób drążenie danych w dół. Ich wygląd graficzny zależy oczywiście o wybranego szablonu, który również może podlegać modyfikacji. Standardowe narzędzia dostępne przy budowie raportów to: sumowanie, agregacje, filtrowanie, boldowanie danych oraz sortowanie i stronicowanie z wykorzystaniem mechanizmu Partial Page Refresh. Możliwe jest również uzupełnianie danych tabelarycznych wykresami oraz zapisywanie raportów w formatach CSV i XML.

Elastyczność interfejsu
Aby uelastycznić pracę nad interfejsem, jest on oddzielony od logiki aplikacji tak dalece, że możemy ten interfejs bez uszczerbku dla warstwy logicznej zmieniać i przystosowywać do upodobań poszczególnych grup użytkowników. Możemy zatem stworzyć jeden obowiązujący w naszej firmie szablon interfejsu (Public Themes) lub zbudować takie szablony na poziomie poszczególnych workspace`ów (Workspace Themes). Jeśli logika naszej aplikacji tego wymaga, możemy sięgnąć także po funkcjonalności udostępniane za pomocą Web Services. Application Express Web Services Engine umożliwi nam skorzystanie na przykład z usług formatujących dokumenty, czy też bardziej ambitnie z serwisów webowych Oracle BPEL. W tym przypadku komunikacja odbywać się może z wykorzystaniem mechanizmów SSL. Innym prostym, ale jakże lubianym sposobem komunikacji aplikacji z światem zewnętrznym (a właściwie z zewnętrznymi danymi), jest mechanizm importu danych z arkuszy kalkulacyjnych z opcją tworzenia nowych tabel lub wstawiania danych do tabel już istniejących.
Elastyczność interfejsu, to również możliwość warunkowego umieszczania określonych komponentów na ekranie. Właściwość tę mają również aplikacje budowane w technologii APEX. Warunki wyświetlania poszczególnych komponentów interfejsu zależeć mogą od różnych uwarunkowań funkcjonalności aplikacyjnej, od ścieżki procesowania aktualnie wyświetlanych lub wprowadzanych danych lub od zawartości, właściwości, czy specyfiki samych danych. W zależności od kontekstu wyświetlenia ekranu, użytkownik może widzieć komponenty takie, jak przyciski, listy wyboru, pola danych itp.
Budowa interfejsu aplikacji Oracle Application Express nie musi jednak ograniczać się do wykorzystywania gotowych komponentów. Jeśli istniejące elementy interfejsu nie odpowiadają naszym oczekiwaniom, możemy pokusić się o napisanie własnych. Oprócz wywoływania Web serwisów możemy także korzystać z API, które umożliwi nam integrację naszej aplikacji z serwerem pocztowym. Do dyspozycji mamy również wszystko, co zaszyte jest w motorze bazy danych, a więc połączenia między bazami danych database links, składowane w bazie fragmenty kodu napisane w Javie, dostęp do zasobów dyskowych poza obszarem tablespace bazy i wiele innych.

Bezpieczeństwo i inne ważne sprawy
Jeśli myślimy o biznesowym zastosowaniu aplikacji, warto kilka słów poświęcić bezpieczeństwu, wydajności i zagadnieniom związanym z wdrożeniem. Oracle Application Express bardzo elastycznie podchodzi to tematu bezpieczeństwa. Jeśli nasza aplikacja jest ogólnie dostępna i nie wymaga szczególnych mechanizmów ochrony danych, możemy zbudować ją tak, by nie wymagała logowania użytkowników. Natomiast, jeśli nasze oczekiwania są diametralnie odmienne, możemy używając tego samego środowiska deweloperskiego zbudować aplikację wymagającą autoryzacji z użyciem wszystkich aktualnie wykorzystywanych narzędzi - takich, jak: Single Sign On, Database Account Credentials czy Microsoft Active Directory. Autoryzacja użytkownika może uprawniać go do dostępu do całej aplikacji lub do jej wybranych ekranów, czy też komponentów ekranu. Idąc nieco w innym kierunku - jeśli chcemy rozpocząć pracę z aplikacją APEX szybko, a nasze oczekiwania są dość standardowe, możemy sięgnąć do zbioru aplikacji przykładowych, dołączanych do środowiska w Packaged Applications. Znajdziemy tam w pełni funkcjonalne przykłady aplikacji obsługujących standardowe biznesowe funkcjonalności. Wystarczy je rozpakować i uruchomić, a jeśli czegoś im brakuje, po prostu rozwijać pod kątem własnych potrzeb.
Aby ułatwić przenoszenie aplikacji pomiędzy instalacjami Oracle Application Express - na przykład ze środowiska deweloperskiego na produkcyjne - do przygotowywania paczki instalacyjnej możemy użyć Supporting Objects Utility. Narzędzie to pozwoli nam wyekstrahować i spakować wszystkie niezbędne źródła potrzebne do budowy aplikacji na nowej instalacji Application Express. Innym ważnym zagadnieniem wdrożeniowym jest strojenie wydajności aplikacji. Aby wspomóc ten proces, developerzy i administratorzy zostali wyposażeni w szereg raportów dostarczających informacje niezbędne do strojenia aplikacji APEX.

Szybko, łatwo i przyjemnie - tak chyba podsumować można to nowe lekkie wcielenie deweloperskiego środowiska do budowy prostych aplikacji.
Jeśli się mylę, proszę o stosowny komentarz...

Ilustracje zostały zaczerpnięte z Oracle Application Express Developer’s Guide.

Autorka artykułu jest Członkiem Zarządu Stowarzyszenia Polskiej Grupy Użytkowników Systemu Oracle (PLOUG) oraz pełni funkcję Redaktora Naczelnego czasopisma "Oracle'owe PLOUG'tki".

Strona internetowa PLOUG: http://www.ploug.org.pl/