## sap-channel
Pierwsza aplikacja kanałowa sap-channel, jak wcześniej wspomniałem jest to stary interfejs oparty o SOAP, ponieważ takie było wymaganie projektu --- zachowanie SOAP API dla systemu SAP.
To co istotne dla nas to model danych zdefiniowany w pliku WSDL:
```xml
```
Model ten różni się od naszego kanonicznego konwencją nazewniczą oraz tym, iż jest oparty o XML. Zgodnie z diagramem, istotnym punktem w implementacji naszej warstwy kanałowej będzie nie tylko wywołanie usługi na warstwie business ale także poprawny mapping odpowiedzi.
Powyższy screen prezentuje realizację w Mule ESB przepływu dla sap-channel. Poniżej omówimy najważniejsze jego części:
Api-main to przepływ odpowiedzialny za publikację interfejsu SOAP opartego o plik WSDL. To co istotne, to komponent SOAP Router odpowiedzialny za przekierowywanie w zależności od wywołanej operacji na adekwatny przepływ z implementacją. W naszym przypadku jest to operacja GetAccount zdefiniowana poniżej:
```XML
```
W samej uproszczonej implementacji mamy 3 kroki:
set account id --- odpowiada za przypisanie do payload-u komunikatu wartości account_id. Krok realizowany dzięki Data Weave.
/account --- wywołanie REST-owej usługi w ramach aplikacji business-account.
Response-mapping --- transformacja odpowiedzi z business-account do XML zgodnego z WSDL.
## webapp-channel
Druga aplikacja webapp będzie korzystać z naszego nowego API REST opartego o kanoniczny model w JSON-ie.
Usługi zostały zdefiniowane w ramach pliku RAML i opublikowane w ramach aplikacji webapp-channel. Poniżej jej uproszczona definicja a także realizacja w ramach Mule ESB.
```yaml
#%RAML 1.0
title: Webapp API
types:
Account:
type: object
properties:
name: string
phone: string
id: string
/account/{id}:
get:
responses:
200:
body:
application/json:
type: Account
```
Analogicznie jak w przypadku aplikacji sap-channel mamy HTTP input odpowiedzialny za wystawienie usługi GET /account/{id} oraz APIkit za adekwatny routing na przepływ realizujący implementację. W naszym scenariuszu zakładamy, iż webapp operuje na modelu kanonicznym w JSON, gdzie nie ma potrzeby wykonywania mappingu pomiędzy modelami stąd implementacja polegająca na wywołaniu operacji GET /account{id} z aplikacji business-account bez mapowania zwrotnego.
## business-account
Aplikacja business-account zgodnie z założeniami ma wystawiać kanoniczny interfejs oraz realizować jedynie orkiestrację usług.
Aplikacja odbiera HTTP GET, wykonuje wywołanie usługi pobrania danych o koncie z systemu salesforce dzięki aplikacji salesforce-adapter. Następnie w ramach kroku “check status” sprawdzamy czy dane o koncie zostały zwrócone. jeżeli tak, zwracamy odpowiedź, w przeciwnym razie pobieramy dane o koncie z systemu bazodanowego.
## salesforce-adapter
Pierwsza z dwóch aplikacji odpowiedzialnych za integrację z systemami domenowymi. Zadaniem tej aplikacji jest odebranie operacji HTTP GET z warstwy business, zbudowanie requestu wyjściowego do systemu Salesforce oraz przetworzenie odpowiedzi do modelu kanonicznego w JSON.
Pierwszym ważnym krokiem w przepływie jest wykonanie operacji SELECT w systemie Salesforce. Realizujemy to dzięki wbudowanego konektora. Dzięki wbudowanemu mechanizmowi DataSense pobieramy metadane obiektów z Salesforce na których będziemy pracować. Pobranie tych danych daje nam możliwość budowania zapytań dzięki narzędzia Query Builder oraz możliwość łatwego mapowania w kroku “map to json” ponieważ mamy zaimportowany model danych obiektu zwrotnego z Salesforce.
Następny krok to weryfikacja czy Salesforce zwrócił odpowiedź. W przypadku pobrania danych, dokonujemy mapowania z obiektu Account zwracanego przez Salesforce do odpowiedzi kanonicznej w JSON.
W przeciwnym razie, dzięki komponentu Groovy możemy wygenerować wyjątek, który spowoduje nam zwrócenie HTTP 404 Resource not found.
throw new org.mule.module.apikit.exception.NotFoundException()
Wygenerowanie tego wyjątku spowoduje zwrócenie do business-account statusu 404 na bazie którego przepływ zdecyduje o wywołaniu dodatkowo aplikacji database-adapter.
## database-adapter
Druga z dwóch aplikacji domenowych. Jej zadanie jest identyczne jak w salesforce-adapter. Aplikacja ma na bazie przekazanego id pobrać z bazy danych informacje o koncie oraz wygenerować odpowiedź w modelu kanonicznym w JSON.
Podobnie jak w przypadku Salesforce, tak tu mamy możliwość skorzystać z wbudowanego konektora, który wykorzystuje DataSeanse w celu pobrania modelu danych.
Omówiliśmy jeden z bardzo typowych scenariuszy integracyjnych, z którymi można spotkać się na projekcie wdrożenia ESB. W modelowym wdrożeniu interfejs usług publikowanych na ESB byłby przedstawiony systemom klienckim (konsumentom API) podczas etapu analizy i cała późniejsza realizacja byłaby skupiona na implementacji katalogu usług oraz integracji Mule z systemami domenowymi. Takie projekty się zdarzają, sam miałem przyjemność brać udział w dwóch takich, jednak większość decyzji o wdrożeniu warstwy integracyjnej zapada w realiach, w których systemy w przedsiębiorstwie istnieją od wielu lat i ESB ma za zadanie pewne rzeczy poprawić, inne uporządkować, wprowadzić pewną przewidywalność w projektowaniu przyszłych zmian i funkcjonalności. W takich warunkach nie jesteśmy wstanie zrobić modelowego wdrożenia omawianego często na konferencjach, ale możemy dzięki ESB znacznie uporządkować rzeczywistość, z jaką zmagają się osoby odpowiedzialne za rozwój IT w przedsiębiorstwie.
### Wszystkie posty z tego cyklu:
1. [Wstęp do integracji systemów w oparciu o Mule ESB]({{ "/wstep-do-integracji-systemow-w-oparciu-o-mule-esb/" | prepend: site.baseurl }})
2. [Wstęp do integracji systemów w oparciu o Mule ESB (część 2)]({{ "/wstep-do-integracji-systemow-w-oparciu-o-mule-esb-czesc-2/" | prepend: site.baseurl }})
