Oracle Service Bus

TUTORIAL: Konfiguracja kolejki JMS na WebLogic Server

2010-06-05T21:32:00.001+02:00

W niniejszym tutorialu zajmiemy się konfiguracją kolejek JMS na serwerze WebLogic. Nie jest to proces komplikowany, ale spotykając się pierwszy raz z serwerem WebLogic może być dość zawiłym skonfigurowanie kolejek JMS.

Przechodzimy do konsoli WebLogic (http://localhost:7021/console).

Konfiguracja JMS Server

1) Po lewej stronie w okienku Domain Structure przechodzimy do Services->Messaging->JMS Servers.

2) Klikamy w New.

3) W polu Name wpisujemy nazwę naszego serwera JMS: JMSserver i klikamy Next.

4) Z listy wybieramy xbusServer i klikamy Finish.

Konfiguracja JMS Modules

1) Po lewej stronie przechodzimy teraz do JMS Modules.

2) Klikamy w New.

3) W polu Name wpisujemy JMSresources i klikamy w Next.

4) W tabeli Servers zaznaczamy serwer xbusServer i klikamy Next, a następnie Finish.

Konfiguracja JMSresources – Connection Factory

1) W tabelce klikamy w JMSresources i następnie w New.

2) Zaznaczamy Connection Factory i Next.

3) W polu Name wpisujemy JMSConnectionFactory.

4) W polu JNDI Name wpisujemy JMSConnectionFactory i klikamy Next, a następnie Finish.

Connection Factory będzie odpowiedzialne za nasz JNDI prowadzący do kolejki JMS.

Konfiguracja JMSresources – Queue

1) W tabelce klikamy w JMSresources i następnie w New.

2) Zaznaczamy Queue i Next.

3) W polu Name wpisujemy MyQueue.

4) W polu JNDI Name wpisujemy MyQueue i klikamy Next.

5) Klikamy w Create a New Subdeployment.

6) Zostawiamy domyślną nazwę i klikamy Ok.

7) Z tabelki wybieramy JMSserver i klikamy Finish.

Koniec. Kolejka JMS została pomyślnie skonfigurowana. W następnym tutorialu zajmiemy się kolejkami w OSB.

TUTORIAL: Prosty Error Handler dla Stage

2010-06-05T13:19:00.001+02:00

Powróćmy na moment do konfiguracji z tutoriala Validate Action dla Web Services. Jak pamiętamy dla komponentu Request Pipeline dodaliśmy komponent Validate, odpowiedzialny za walidację wysyłanych żądań. Zadaniem Czytelnika będzie dodanie i konfiguracja tego samego komponentu dla Request Pipeline gałęzi dla operacji CelsiusToFahrenheit. Wynik powinien być następujący:

Zmodyfikujemy jednak trochę ten komponent i zamiast walidacji w oparciu o WSDL, przeprowadzimy w oparciu o własny schemat XSD:

Zauważmy podstawową zmiane w stosunku do schematu wiadomości z WSDL. W WSDL żądanie było typu string, natomiast w XSD jest typu int.

Zmieniamy walidację.

Dodamy teraz obsługę błędów dla Validate Stage:

1) Klikamy na Validate Stage i wybieramy Add Stage Error Handler. Zostajemy przekierowani do nowego widoku.

2) Klikamy na Error Handler i wybieramy Add Stage.

3) Klikamy na stage1, zmieniamy jego nazwę na np. Error Stage, a następnie wybieramy Edit Stage.

4) Klikamy w Add an Action i wybieramy Reporting->Alert.

5) Klikamy w Expression i wpisujemy $body.

6) W polu alert-summary wpisujemy dowolny tekst np. Błąd danych wejściowych.

7) Z listy severity level wybieramy Critical.

Krótkie wytłumaczenie akcji Alert.

Akcja Alert pozwala na raportowanie błędów w głównej konsoli OSB dostępnej w zakładce Operations, a następnie w zakładce Pipeline Alerts.

Przetestujmy nasze Proxy Service i zobaczmy jak to wygląda w praktyce:

I przypadek – prawidłowe dane wejściowe dla operacji CelsiusToFahrenheit.

Widzimy, że cały Message Flow został poprawnie wykonany. Validate Stage nie zgłosił żadnego błędu i otrzymaliśmy prawidłowy wynik.

II przypadek – błędne dane wejściowe dla operacji CelsiusToFahrenheit.

Otrzymujemy błąd zgłoszony przez Validate Stage: OSB Validate action failed validation oraz Invalid decimal value: unexpected char '112'.

Zobaczmy jeszcze konsolę OSB i raport o błędzie:

TUTORIAL: Operational Branch i Insert Action dla Web Services

2010-06-01T16:33:00.010+02:00

W poprzednim tutorialu Validate Action dla Web Services wspomniano o komponencie Operational Branch. Jest to komponent, dzięki któremu najprościej rzecz ujmując można zdefiniować osobny Message Flow dla każdej operacji z Web Service. Inaczej – w zależności od wybranej operacji zostaną wykonane akcje w Message Flow zdefiniowane dla tej operacji.

W naszym przypadku Web Service udostępnia dwie operacje:

- FahrenheitToCelsius
- CelsiusToFahrenheit

Dla każdej z wyżej wymienionych operacji, dzięki Operational Branch jesteśmy w stanie zdefiniować niezależne Message Flow.

Ten tutorial pokaże zastosowanie Operational Branch oraz akcji manipulacji wynikiem w postaci akcji Insert oraz warunku logicznego If… Then…

OPERATIONAL BARNCH

1) Przechodzimy do podstawowej konfiguracji Message Flow (nie zapomnij o aktywowaniu sesji).

2) Klikamy na ConvertTemperature i wybieramy Add Operational Branch, klikamy w OK.

Otrzymaliśmy Default Branch. Możemy zobaczyć co się w niej znajduje. Nas jednak interesują własne Message Flow dla operacji.

3) Klikamy w BranchNode1 i wybieramy Edit Branch.

4) Z listy rozwijalnej wybieramy pierwszą operację CelsiusToFahrenheit i po prawej stronie klikamy ikonkę Add a New Branch. Powtarzamy akcję dla drugiej operacji.

5) Klikamy Save.

Mamy teraz 3 zdefiniowane gałęzie dla operacji w tym jedną defaultową. W tutorialu przedstawimy akcje dla operacji CelsiusToFahrenheit.

6) Klikamy w CelsiusToFahrenheit, a następnie w BranchNode1 : CelsiusToFahrenheit.

7) Wybieramy Add Route. Tutaj w ramach ćwiczenia proponuję sobie odświeżyć w jaki sposób dodać Business Service do Message Flow. Dodam tylko, że przy wyborze operacji w akcji Routing mamy możliwość wyboru konkretnej operacji. Należy pamiętać o wybraniu odpowiedniej.

8) Następnie znów klikamy na BranchNode1 : CelsiusToFahrenheit, ale tym razem wybieramy Add Pipeline Pair.

9) Dodajemy Stage do Responset Pipeline.

10) Zmieniamy nazwę na If... Then Stage i przechodzimy do edycji.

AKCJA IF… THEN

1) Na początek w Add an Action przechodzimy do Flow Control i wybieramy If… Then…

2) Klikamy w Condition.

3) Pod guzikiem Save wybieramy Builder.

4) Po lewej przechodzimy do zakładki Variable Structures i z listy do zmiennej body.

5) Rozwijamy wszystkie elementy z $body - CelsiusToFahrenheit (response) i przenosimy element CelsiusToFahrenheitResult do pola Operand.

6) Zmieniamy Operator na >=.

7) W polu Value wpisujemy 30.

8) Klikamy w Add, Validate i na końcu Save.

9) Klikamy teraz w ikonkę obrazującą warunek i wybieramy Add else Condition.

Otrzymaliśmy pełną strukturę logiczną warunku.

AKCJA INSERT

Zapoznamy się z prostą akcją Insert, która pozwala wstawiać np. tekst wewnątrz lub pomiędzy elementy odpowiedzi zwrotnej.

W tutorialu postaramy się uzyskać wynik w zależności od spełnionego warunku:„Uwaga GORĄCO - Temperatura wynosi: WynikowaTemperatura” lub ZIMNO.

1) Dla dwóch Add an Action wybieramy Message Processing -> Insert.

2) Klikamy w Expression i w wpisujemy 'Uwaga GORĄCO - Temperatura wynosi: ' (należy pamiętać o apostrofach).

3) Klikamy Validate i Save.

4) Z listy wybieramy as first child as.

5) Klikamy w XPath.

6) Przechodzimy do struktury zmiennej $body - CelsiusToFahrenheit (response) i przenosimy element przechowujący wynik czyli CelsiusToFahrenheitResult.

7) Klikamy Validate i Save.

8) W polu variable wpisujemy body.

9) Powtarzamy te same czynności dla drugiej akcji Insert.

10) Zapisujemy i aktywujemy sesję.

Czas na testy.

Pamiętajmy, że zaprojektowaliśmy przepływ tylko dla jednej operacji, dlatego też nasz test będzie bazował na operacji CelsiusToFahrenheit.

Dane testowe I: 15

Wynik I:

Dane testowe II: 30

Wynik II:

TUTORIAL: Validate Action dla Web Services

2010-05-31T17:06:00.030+02:00

Niniejszy tutorial jest pierwszym z serii planowanych tutoriali demonstrujących działanie Message Flow oraz zastosowania różnych komponentów i akcji w OSB. Kolejne tutoriale będą rozwinięciem podstawowej konfiguracji Message Flow przedstawionej w tutorialu Wirtualizacja Web Services na OSB 10gR3.

Jak już wiemy, Message Flow udostępnia grupę komponentów służących do zarządzania przepływem wiadomości pomiędzy Proxy Service, a Business Service. Na początek weźmiemy pod lupę prosty schemat przepływu oparty na komponentach Pipeline Pair Node i Stage. W tym celu zmodyfikujemy bazowy Message Flow, dodając na początek Pipeline Pair Node:

1) Klikamy na ConvertTemperature, a następnie wybieramy Add Pipeline Bar.

Otrzymujemy nowy komponent PipelinePairNode1, dzięki któremu od teraz mamy możliwość konfiguracji wiadomości wchodzących do i wychodzących z Business Service.

Następnym krokiem jest dodanie komponentu Stage dla Request Pipeline, ponieważ to właśnie dla tej części zademonstrujemy działanie akcji Validate, odpowiedzialnej (jak się można domyślić) za walidację wysyłanego żądania do Business Service.

1) Klikamy na Request Pipeline, a następnie z menu wybieramy Add Stage.
2) Otrzymujemy nowy komponent o nazwie stage1.

3) Klikamy na stage1 w celu zmiany jego nazwy:

a) Wybieramy Edit Name and Comments i wpisujemy w polu Name, Validate Action.
b) Klikamy Save.

W tym momencie mamy dodany komponent, w którym możemy definiować wszelkiego rodzaju akcje. W tym tutorialu zajmiemy się akcją walidacyjną wiadomości wysyłanej przez użytkownika.

1) Klikamy na Validate Action i wybieramy Edit Stage.
2) Klikamy na Add an Action.
3) Wybieramy Message Processing -> Validate.

Otrzymujemy edytor akcji Validate, który należy teraz skonfigurować.

1) Klikamy w XPath.

Zostajemy przekierowani do XPath Expression Editor, w którym możemy manipulować elementami zmiennych predefiniowanych. OSB automatycznie tworzy zmienne przechowujące konkretne elementy wiadomości. Aby zobaczyć strukturę zmiennych należy przejść do zakładki Variable Structures, a następnie z listy rozwijalnej wybrać odpowiednią strukturę. Na poniższym zdjęciu widać strukturę elementów zmiennej $body.

a) W tutorialu zajmiemy się walidacją wszystkich elementów zmiennej $body dlatego też w pustym polu wpisujemy ./*

b) Klikamy na Validate.
c) Klikamy na Save.

2) Następnie w polu obok in variable wpisujemy body (bez znaku $).
3) Klikamy w Resource.

a) Wybieramy WSDL ponieważ będziemy walidować naszą wiadomość w oparciu o WSDL. b) Wybieramy CovertTemperature_WSDL, a następnie CelsiusToFahrenheit i klikamy Submit.

W tym miejscu małe wyjaśnienie. Otóż wybraliśmy jeden element z WSDL o nazwie CelsiusToFahrenehit. Stąd walidacji będzie poddana tylko wiadomość wysłane przez operację CelsiusToFahrenheit.

4) Zaznaczamy opcję Raise Error on validation failure.

5) Klikamy Save.

6) I raz jeszcze Save.
7) Aktywujemy sesję.

Konfiguracja najprostszej akcji Validate zakończona. Teraz możemy przetestować Proxy Service. Testując operację CelsiusToFahrenheit otrzymujemy poprawny wynik. Możemy również prześledzić w jaki sposób zostały wykonane poszczególne etapy Message Flow. Jeśli natomiast wywołamy operację FahrenheitToCelsius otrzymamy error - BEA-382505: OSB Validate action failed validation.

Przyczyna jest prosta. Walidację należy przeprowadzić dla każdej operacji request lub zastosować komponent Branch Node – Operational Branch o czym w następnym tutorialu!

Wprowadzenie do Message Flow w OSB 10gR3

2010-05-29T16:05:00.021+02:00

DEFINICJA

Messgae Flow czyli Przepływ Wiadomości najprościej ujmując definiuje implementację Proxy Service. Każdy Message Flow jest zbudowany z komponentów, które określają pewną logikę dla przepływu i zarządzania wiadomościami przechodzących przez Proxy Service.

LISTA KOMPONENTÓW Messgae Flow – krótkie omówienie

Start Node – każdy Message Flow zaczyna się od Start Node, do którego wchodzi każda wiadomość oraz przez który przechodzi każda wiadomość zwrotna. Star Node nie jest konfigurowalny.

Pipeline Pair Node – większość logiki przepływu odbywa się w Pipeline Pair Node. Komponent ten łączy w sobie Request Pipeline i Response Pipeline, a więc elementy odpowiedzialne za przepływ żądania klienta i odpowiedzi do klienta.

Stage – w elemencie Stage możliwa jest konfiguracja akcji w celu manipulowania wiadomościami przesyłanymi przez Piepeline. Komponent Stage może być dodany do Request Pipeline, Response Pipeline oraz Error Handler.

Error Handler – komponent odpowiedzialny za obsługę błędów. Może być użyty dla Stage lub Node.

Branch Node – komponent ten pozwala na wybór dokładnie jednej z wielu ścieżek przepływu. Możemy wyróżnić Operational branching i Conditional branching. Pierwszy jest dostępny dla usług opartych na WSDL i zdefiniowanych w nim operacjach, drugi dla warunków w XPath Switch Table.

Route Node – komponent odpowiedzialny za komunikację typu request/response z inną usługą.

BUDOWA MESSAGE FLOW

Jedynymi wymaganymi komponentami w Message Flow są Start Node i Route Node. Inne komponenty są opcjonalne.

Wyróżniamy dwa rodzaje Message Flow:

Dla non-operational services (usługi nie bazujące na operacjach WSDL) – przepływ składa się z jednej Pipeline Pair i Route Node.

Dla operational services – przepływ zawiera Pipeline Pair, a następnie Branch Node (w oparciu o operacje usługi). Każde rozgałęzienie Branch Node zawiera Pipeline Pair i Route Node.

AKCJE

Akcje dostarczają instrukcje do obsługi przepływających wiadomości przez Pipeline, Error Handler i Route Nodes.

Możemy wyróżnić cztery grupy akcji:

Akcje komunikacyjne (ang. Communication Actions)

Akcje kontroli przepływu (ang. Flow Control Actions)

Akcje przetwarzania wiadomości (ang. Message Processing Actions)

Akcje raportujące (ang. Reporting Actions)

Dokładny opis akcji znajduje się na stornie dokumentacji OSB pod linkiem: http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/modelingmessageflow.html#wp1086777

TUTORIAL: Wirtualizacja Web Services na OSB 10gR3

2010-05-26T14:25:00.030+02:00

Na początek, przedstawmy krótki wstęp teoretyczny dotyczący działania zwirtualizowanej usługi sieciowej na szynie Oracle Service Bus 10.3.

Po lewej stronie znajduje się klient (Service consumer) naszej zwirtualizowanej usługi sieciowej. Jego żądania są wysyłane do Proxy na szynie, która komunikuje się wewnątrz szyny z Business Service (ta z kolei komunikuje się z zewnętrzną usługą sieciową), definiującej całą logikę działania usługi sieciowej. Należy zapamiętać, że najważniejszymi pojęciami OSB są Proxy i Business Service.

Proces konfiguracji OSB można podzielić na 3 główne etapy:

1) Stworzenie projektu i import zasobów

2) Konfiguracja Business Service

3) Konfiguracja Proxy

Usługa sieciowa, którą będziemy wirtualizować to przykładowa usługa z W3C zamieniająca temperaturę ze stopni Celsjusza na Fahrenheita i na odwrót, której opis WSDL znajduje się pod adresem: http://www.w3schools.com/webservices/tempconvert.asmx?WSDL.

Ważnym aspektem działania szyny OSB są sesje, dzięki którym możemy dokonywać zmian. Aby wprowadzić jakieś zmiany konfiguracyjne należy stworzyć nową sesję, a po wykonaniu wszystkich czynności aktywować ją. Istnieje również możliwość cofnięcia sesji, co bardzo ułatwia anulowanie wprowadzonych zmian.

PROJEKT I IMPORT ZASOBÓW

Na początku działań z OSB należy stworzyć dla każdego projektu pewną strukturę katalogów. W tym celu wybieramy zakładkę Project Explorer, aktywujemy nową sesję i dodajemy katalog. Głównym katalogiem będzie nazwa naszego projektu WebServiceTemp.

Następnie przechodzimy do utworzonego katalogu i w nim tworzymy trzy inne: BusinessServices, ProxyServices i Resources. Aktywujemy sesję podając dodatkowo jej opis, aby łatwiej rozpoznać poszczególne etapy.

Drugim krokiem jest import URL pliku WSDL opisującego usługę przeznaczoną do wirtualizacji do katalogu Resources. W naszym wypadku jest to link http://www.w3schools.com/webservices/tempconvert.asmx?WSDL

Dalej przeprowadzamy krótką konfigurację.

Klikamy Next , a następnie Import i aktywujemy sesję.

KONFIGURACJA BUSINESS SERVICE

Business Service definiuje interfejs i informacje o połączeniu do endpoint’a czyli zdalnej usługi na serwerze. Pełną konfigurację przeprowadzamy z poziomu katalogu BusinessServices, gdzie ustalamy m. in. nazwę usługi oraz jej opis, ścieżkę do wcześniej zaimportowanego pliku WSDL, operacje usługi oraz inne opcje związane z protokołem SOAP, zabezpieczeniem i monitoringiem usługi. Na tym etapie istnieje również możliwość testowana usługi.

Konfiguracji Business Service:

Przechodzimy do katalogu Business Service i aktywujemy sesję. Z listy rozwijalnej Create Resource wybieramy Business Service i przeprowadzamy konfigurację: wpisujemy nazwę usługi, opcjonalnie opis i wybieramy WSDL z katalogu Resources.

W tym miejscu zakładam, że czytelnik posiada wiedzę dotyczącą WSDL i Web Service. Wybieramy Port TempConvertSoap i klikamy w Submit.

Następnie możemy kliknąć w Last aby przejść do ostatniej strony i zapisać Business Service lub klikać Next i przejrzeć/ustawić dodatkowe opcje dla Business Service. W naszym przypadku zostawiamy wszystkie opcje na poziomie domyślnym i zapisujemy usługę.

Aktywujemy sesję.

W tym momencie mamy już skonfigurowany Business Service. OSB udostępnia możliwość przetestowania endpointa. W tym celu należy kliknąć w ikonkę przypominającą zielonego robaczka, która znajduje się po prawej stronie CovertTemperature_BusinessService. Test przeprowadzamy bez konieczności tworzenia sesji.

Jak widać OSB udostępnia mnóstwo opcji związanych z usługami sieciowymi. Możemy przetestować naszą usługę.

KONFIGURACJA PROXY

Przechodzimy do katalogu ProxyServices i aktywujemy sesję. Z listy rozwijalnej Create Resource wybieramy Proxy Service.

Przeprowadzamy konfigurację Proxy.

Pomijamy dodatkowe opcje konfiguracji i klikamy Last, a następnie Save.

Następnie klikamy w ikonkę Edit Message Flow.

Znajdujemy się w ekranie konfiguracji przepływu wiadomości, co tak naprawdę jest punktem centralnym naszej zwirtualizacji usługi sieciowej. Na tym etapie dokonamy podstawowej konfiguracji Proxy.

Klikamy na ikonkę koperty ConvertTemperature i z listy wybieramy Add Route. Klikamy teraz w RouteNode1 i wybieramy Edit Name and Comments. Wpisujemy przyjazną nazwę np. RouteTo_ConvertTemperature_BusinessService – wiadomo o co chodzi.

Klikamy teraz w RouteTo_ConvertTemperature_BusinessService i wybieramy Edit Route.

Klikamy w Add an Action->Communication->Routing.

Klikamy w Service* i wybieramy CovertTemperature_BusinessService, a następnie w Submit. Zaznaczamy pole Use inbound operation for outbound, klikamy w Save All i aktywujemy sesję.

Stworzyliśmy kompletne Proxy, które rutuje wiadomości do Business Service i realizuje całą logikę przepływu informacji typu Request/Response.

Nasza usługa jest od teraz dostępna pod nowym adresem: http://localhost:7021/WebServiceTemp/ProxyServices/ConvertTemperature?WSDL.

Powyższy tutorial przedstawia podstawową konfigurację Proxy w OSB. Następny tutorial przybliży Czytelnikowi zaawansowane możliwości przepływu informacji jak np. walidacja i obsługa błędów.