Tworzenie pierwszego przykładu procesu biznesowego typu Human Task na WID, problem z uruchomieniem WPS na WID.

Sama instalacja WID'a przebiegła bez większych trudności, tu wymagane było tylko uruchomienie instalatora z poziomu root'a, po instalacji zastosowałem komendę chown -R rafal na całym katalogu z WID'em. Jako, że wcześniej instalowałem WAS/WPS na tym systemie pominąłem instalację WAS'a , miałem nadzieję, że z dodaniem wcześniej zainstalowanego serwera do WID'a nie będzie problemu i z samym dodaniem faktycznie nie było, ale z uruchomieniem już tak. Na początku myślałem, że to wina limitu na czas uruchomienia WPS'a, standardowo w programie ustawiony na 10 minut (a wiedziałem, że przynajmniej w tej konfiguracji sprzętowej potrafił się dłużej uruchamiać), zwiększyłem więc limit do 20, ale nie pomogło. Wszystko wskazuje na to, że serwer się uruchamia, tylko w programie po upłynięciu określonego czasu wyskakuje błąd:

Czyli jak na razie chyba nie ma szansy żeby WID pomógł wdrożyć stworzony proces biznesowy na WPS, zamieszczam LOGI, w których półki co nie doszukałem się żadnej odpowiedzi(może dlatego, że serwer startuje bez błędu?), poświęcam teraz więcej czasu na naukę usług sieciowych i procesów biznesowych z zadaniem użytkownika (ang. Human Task). Gdy uda mi się przebrnąć przez stworzenie przykładu i uruchomienie go na WPS'ie zamieszczę tu wyniki.

//EDIT 12-05-2010 13:30

Miałem zamiar wcześniej uporać się z problemem wdrożenia na WPS przykładów stworzonych w WID. Wtedy po dwóch - trzech dniach dopisałbym efekty i uruchomienie pierwszego przykładu, ale niestety nie udało mi się tak szybko znaleźć rozwiązania, więc przykład zamieszczam w nowej notce.

Co do samego problemu, rozwiązany był już jakiś czas temu, okazało się, że konieczne jest zainstalowanie WebSphere Integration Developer V7.0.0 Fix Pack 2 for Linux, który wraz z intrukcją znajduje sie w LINK. Menadżera instalacji WID trzeba było uruchomić z uprawnieniami root. Ważne jest także aby po uaktualnieniu oprogramowania ponownie nadać prawa użytkownikowi(chown -R user) żeby wszystko działało poprawnie. Można także dodatkowo aktualizować WPS, wystarczy odpalić menadżera instalacji dla tego programu i kliknąć aktualizuj, wszystko odbywa się automatycznie.

Jednak to nie był koniec moich zmagań z uruchomieniem przykładów. Przy wywoływaniu pierwszego przykładu otrzymałem błąd:

"The server is not running in Development mode" - z tym nie miałem większego problemu, przypomniało mi się, że kiedy wcześniej przeglądałem konsolę administratora napotkałem na opcję, której włączenie mogło pomóc. Zaznaczamy wariant znajdujący się w Servers>Server Types>WebSphere Application Server>server1>Configuration.

 

Po zrestartowaniu serwera przykład powinien uruchamiać się bez błędu.

Instalacja DB2 na RedHat Enterprise Linux i uruchomienie aplikacji Grails na WPS

Nadszedł czas na napisanie kolejnej notki, co prawda, to co będę tu opisywał udało mi się wykonać z powodzeniem już jakiś czas temu(ostatni krok, czyli wdrożenie war'a na WPS z DB2 jakoś w poniedziałek), ale coś ostatnio nie mogłem zebrać myśli i podsumować zakończone zadanie na moim blogu.

Zabieramy się do roboty, w tym miejscu Drogi Czytelniku zakładam, że masz zainstalowany serwer WPS i stworzony odpowiedni profil(jeżeli nie odsyłam do poprzedniego wpisu LINK). Na początek potrzebujemy zainstalować JDK i Grails, żeby stworzyć war'a, którego potem będziemy wdrażać na WPS.

Instalacja JDK, Grails i wyeksportowanie war'a

Pobieramy JDK na Linuxa - LINK.
Pobieramy najnowszą(v 1.1.2) dostępną pod Linux'a wersję Grails - LINK.

Instalujemy JDK, myślę, że będzie lepiej jak nie będę tutaj opisywał krok po kroku co należy robić, znalazłem świetny materiał znajdujący się na Polskim Forum Linuksa - LINK, który wyczerpuje ten temat. Wystarczy znaleźć interesujący nas podpunkt(ja wybrałem instalację JDK ze źródeł z prawami administratora) i robić kolejno co jest tam napisane. Zwracamy szczególną uwagę przy dodawaniu zmiennych środowiskowych, ponieważ później przyda nam się ta wiedza przy dodawaniu zmiennych Grails'a.

Instalując Grails'a nie używamy komendy chmod a+x, ponieważ tak jak w przypadku WPS chcemy, aby uprawnienia do wykonywania operacji na nim przypadły użytkownikowi. Dlatego też, rozpakowujemy nasze pliki w katalogu domowym wcześniej stworzonego użytkownika(u mnie /home/rafal). Po dodaniu zmiennych środowiskowych tym razem wskazujących na katalog z Grails'em możemy zrestartować system żeby zmiany były widoczne.

Dalej przygotujemy sobie plik war, pozostawiam tu Wam pewną dowolność, ponieważ sama aplikacja nie jest tutaj istotna, może to być najprostszy kod typu HelloWorld, co nam teraz jest potrzebne, to wyeksportować plik war komendą:

$ grails war NaszaAplikacja.war

Wygenerowana w konsoli odpowiedź naprowadzi nas na folder, w którym znajduje się stworzony plik. Jeżeli ktoś chce użyć przykładu stworzonego przeze mnie odsyłam do wcześniejszej notki - LINK(był on pisany na Windows'ie, ale na Linux'ie wszystko robimy analogicznie).

Instalacja DB2

Pobieramy DB2 - LINK, rozpakowujemy w dowolnym miejscu w katalogu domowym użytkownika(instalacja DB2 jako non-root i tak domyślnie wrzuci nam pliki do /home/nazwaUzytkownika/sqllib). Po zainstalowaniu otwieramy okno First Steps w celu stworzenia SAMPLE database. Wybieramy lokacje bazy danych, przeglądając później ten katalog widzimy, że stworzyliśmy węzeł(ang. node) o domyślnym indeksie 0000 oraz z ID użytkownika, dla którego instalowaliśmy DB2.

Otwieramy Applications>IBM DB2>Command Line Processor, uruchamiamy usługę DB2 komendą:

db2 => db2start

Tworzymy bazę danych, jeżeli stworzyliśmy aplikację Biblioteka, to tak jak podane jest w wcześniejszym wpisie tworzymy bazę danych i łączymy się z nią.


Tworzenie połączenia JDBC i wdrożenie war'a na WPS

Uruchamiamy serwer WPS, klikamy i rozwijamy pierwszą opcję czyli Guided Activities>Connecting to a database, tam mamy kolejno opcje do konfiguracji połączenia z bazą danych, na ten moment możemy ominąć pierwszy krok czyli Configure credentials for secure database access. Przechodzimy zatem do Configure a JDBC provider => Click to perform. Po prawej w oknie gdzie figurują dostępni dostawcy JDBC klikamy New.

Wybieramy kolejno:

Step 1: Create a new JDBC Provider:
*Database type: DB2
*Provider type: DB2 Using IBM JCC Driver
*Implementation type: Connection pool data source

Step 2: Enter database class path information
${DB2_JCC_DRIVER_PATH}
/home/nazwaUzytkownika/sqllib/java

Pole Native library path(wiąże się to ze zmiennymi dla WebSphere'a, patrz niżej) możemy zostawić puste i korzystamy z tego przywileju. Pomijamy także następny krok czyli Configure WebSphere variables, ponieważ żadna taka zmienna nie jest nam potrzebna do połączenia z bazą. Klikamy Next i dalej na podsumowaniu Finish.

Teraz konfiguracja Datasource, wybieramy wcześniej utworzonego dostawcę JDBC i po prawej w rubryce Additional Properties klikamy Datasources.

Podajemy JNDI name, dalej wybieramy Driver type - 2 i wpisujemy nazwę wcześniej utworzonej bazy danych, pole Server name zostawiamy puste. Na tym konczymy naszą konfigurację połączenia.

Testujemy nasze połączenie, pamiętając, że jeszcze musimy zapisać nasze zmiany, wyświetli się odpowiedni komunikat, klikamy Save.

Nawiązanie połączenia po wykonaniu powyższych czynności powinno zakończyć się powodzeniem.
Zmieniamy plik DataSource.groovy aby wygladal tak(w miejsce biblio możesz umieścić swoją nazwę):

Wdrażamy war’a na WPS, w konsoli administratora przechodzimy do Application>New Application>New Enterprise Application.

Wyszukujemy nasz wcześniej stworzony plik, klikamy next, wybieramy metodę instalacji - Fast Path. :)

Dalej wszystkie ustawienia do kroku 4 zostawiamy domyślne, jedynie zmieniamy mapowanie context root, jeżeli tego nie zrobimy prawdopodobnie otrzymamy taki błąd:

com.ibm.ws.wswebcontainer.VirtualHost addWebApplication SRVE0164E: Web Application HumanTasks_war#/HumanTasks-production-0.1 uses the context root /*, which is already in use by Web Application DefaultApplication#Default Web Application. Web Application /HumanTasks-production-0.1 will not be loaded. 

Teraz przechodzimy do Applications>Applications Types>WebSphere enterprise applications, zaznaczamy naszą aplikacje naciskamy start.

Następnie w zależności od podanego context root'a dla naszej aplikacji i adresu waszego hosta(u mnie defoult_host na porcie 9080) wpisujemy adres naszej aplikacji:

http://localhost:9080/grails

I możemy cieszyć się rezultatem naszej pracy.

Problem z uruchomieniem konsoli administratora dla WAS/WPS

Na kolejne trudności nie trzeba było długo czekać, po stworzeniu profilu WPS przyszedł czas na uruchomienie konsoli administratora w przeglądarce. I tu po wpisaniu prawidłowego adresu do mojego localhosta tj.:

http://localhost:9060/ibm/console

 pojawia się kolejny błąd.

//EDIT 1 - 09.04.2010r. 12:40

Nadal nie uporałem się z powyższym problemem, dla zainteresowanych i chętnych do pomocy zamieszczam logi serwera wyrzucane podczas uruchamiania serwera - PLIK DO POBRANIA.

//EDIT 2 - 11.04/2010r 13:30

Przyczyną błędu powodującego całe zamieszanie był systemowy limit na liczbę otwartych plików:  

java.io.FileNotFoundException: /home/rafal/ibm/WebSphere/ProcServer/profiles/ProcSrv01/databases/WPRCSDB/seg0/cb10.dat (Too many open files)

Żeby rozwiązać ten problem odpowiednio modyfikujemy parametr ulimit, postępując zgodnie z LINKIEM, logujemy się w terminalu jako root, podajemy komendę:

#vi /root/.bashrc

Naciskamy "i" i dopisujemy do pliku:

ulimit -u unlimited

ulimit -n 90000

Wciskamy Esc i wpisujemy :wq aby wyjść z pliku i zapisać zmiany. Ustawiliśmy dzięki temu limit uruchomionych procesów dla użytkownika root na nieskończony i maksymalną ilość otwartych plików dla danego procesu na 90 tyś.. Teraz trzeba się prze-logować, wejść z powrotem do terminala dla użytkownika root żeby zmiany były widoczne dla systemu, możemy sprawdzić zmianę ustawień wpisując komendę:

# ulimit -a

Dzięki temu stworzona instancja serwera uruchamia się bez żadnych komplikacji i w końcu mamy dostęp do konsoli administratora.

//EDIT 3 - 12.04.2010r 16:00

Jeżeli chcemy korzystać z serwera z poziomu dowolnego użytkownika, najpierw upewniamy się, że nie otrzymamy ponownie błędu spowodowanego limitem na liczbę otwartych plików, tym razem zwiększamy limit dla danego użytkownika, pomocny LINK.

Otwieramy z poziomu roota plik limits.conf:

# vi /etc/security/limits.conf 

Dodajemy dwie linijki tuż przed końcem pliku:

uzytkownik hard nofile 65535

uzytkownik soft nofile 65535

Wychodzimy z pliku zapisując go i przechodzimy do najważniejszej części, czyli nadania wybranemu użytkownikowi praw do katalogu z WAS/WPS, logujemy się jako root w terminalu i wpisujemy komendę:

# chown -R uzytkownik /katalog/z/WAS/WPS

w moim przypadku: # chown -R rafal /home/rafal/ibm

Dzięki temu serwer uruchamia się bez poniższego błędu:

The system is unable to read document cells/localhostNode01Cell/nodes/localhostNode01/node-metadata.properties:java.io.IOException:Permission denied

Kolejnym krokiem w realizowanym projekcie będzie konfiguracja bazy danych DB2 i uruchomienie pierwszej aplikacji Grails na WPS.

Instalacja WAS i WPS na Red Hat Enterprise Linux

Zainstalowałem linuxa na VMware, przeglądarkę firefox (v. 3.6.2) i przy instalacji WebSphere Process Server v7 (WPS) zaczynają się schody. WebSphere Application Server v7 (WAS) instaluje się bez problemu, jednak gdy odpalam komendę ./launchpad.sh i próbuję zainstalować WPS nie jest już tak kolorowo. Już na samym starcie konsola pokazuje jakiś błąd, a kolejny pojawia się w momencie kliknięcia w miejsce, po którym powinna rozpocząć się instalacja WPS, oto błędy:

Ja próbuję dalej, pomysły jak rozwiązać ten problem mile widziane.

//EDIT 1

Gdy nie wywołuję launchpad.sh jako root i chcę zainstalować WPS jako non-root installation drugi błąd dalej występuje (bez pierwszego ostrzeżenia, które tak naprawdę można zignorować).

//EDIT 2

Problem rozwiązany, a był nim Security-Enhanced Linux (SELinux) i pewnie po części moja niewiedza, bo jakbym wcześniej korzystał z Linuxa to może bym wiedział o tej koncepcji. A chodzi w niej o politykę bezpieczeństwa opartej na zapewnieniu jak najmniejszej ilości uprawnień dla danego obiektu (np. konta użytkownika, urządzenia, programu) potrzebnych do jego poprawnego funkcjonowania, co ogranicza wielkość wyrządzonych szkód po przejęciu kontroli nad obiektem przez osoby nie powołane(źródło: wikipedia).

Aby temu zaradzić wybieramy z menu System>Administration>SELinux Management i zmieniamy ustawienia Enforcing Mode na Permissive(lub całkowicie wyłączamy tą usługę). Dalej instalacja przebiega bez powyższego błędu.


WAS i WPS zainstalowany, profile stworzone, kolejnym realizowanym celem będzie uruchomienie pierwszej aplikacji Grails na WPS.