Integracja

Współczesny system informatyczny to twórcze połączenie kilku systemów, które razem dają wartość większą niż każdy z nich osobna.

 
 
 

API

API, czyli interfejs programowania aplikacji (ang. Application Programming Interface, API) to sposób komunikacji z aplikacją przez inne oprogramowanie. W przypadku aplikacji internetowych, w których podstawowym sposobem dostępu jest przeglądarka internetowa użytkownika (np. Firefox lub Internet Explorer), API stanowi alternatywny sposób pobierania danych lub wykonywania operacji. Obecnie modny temat to aplikacje mobilne, które komunikują się z serwerami właśnie przez takie API.

Odpowiednia, przemyślana konstrukcja API sprawia, że mogą z niego korzystać również inni dostawcy oprogramowania dla Klienta, którzy tworzą inne, dedykowane jednemu aspektowi aplikacje, często powstające na przykład na użytek tylko jednej kampanii marketingowej.

Przykładem aplikacji udostępniającej publiczne API z którym komunikuje się wiele systemów i aplikacji zewnętrznych jest działający od kilku lat system ActiveForms.

Ciągły rozwój tej aplikacji i wprowadzanie nowych funkcjonalności wiąże się ze zmianami API. Aby już wcześniej zintegrowane systemy mogły nadal korzystać z API bez konieczności dostosowywania się do kolejnych zmian, cały czas udostępniamy starsze wersje API.

e-point, oprócz implementacji API dostarcza również dokumentację z przykładami, a czasem również gotowe biblioteki dla różnych języków programowania, co zmniejsza barierę wejścia dla nowych użytkowników rozpoczynających integracje z użyciem takiego API.

USŁUGI INTERNETOWE - WEBSERVICES

Usługi internetowe (ang. web service) oparte na standardach OASIS to bez wątpienia najpopularniejsza obok REST technologia używana w integracji systemów. W e-point używamy usług internetowych od kilku lat, przy czym wykorzystanie przyjmuje wiele form:

  • nasz system udostępnia własne usługi zgodnie z WSDL przygotowanym przez naszych architektów,
  • nasz system udostępnia usługi zgodnie z  WSDL dostarczonym przez dostawcę systemu z którym się integrujemy,
  • nasz system korzysta z usług innych dostawców.

Użycie usług sieciowych wiąże się z koniecznością zapewnienia bezpieczeństwa komunikacji. Istnieje wiele możliwości będących wynikiem lokalnych uwarunkowań i polityki klienta, a także poziomu krytyczności przetwarzanych informacji:

  • zabezpieczenie kanału transportowego - SSL, VPN,
  • autoryzacja BasicAuth na poziomie serwera WWW lubcertyfikatu klienckiego SSL,
  • implementacja podzbioru WS-Security np. Web Services Security,
  • UsernameToken Profile oraz aspekty PKI: podpis oraz szyfrowanie danychzgodne z WS-SecurityPolicy 1.3

Użycie usług sieciowych, zwłaszcza z zaawansowanymi opcjami z WS-Security jest, wbrew temu co można sądzić, bardzo zależne od zastosowanych implementacji po obu stronach komunikujących się systemów. Wdrażając rozwiązania dla naszych Klientów komunikowaliśmy się przez usługi internetowe korzystając z serwerów aplikacyjnych JBoss, WebSphere oraz JonAS.

REST

REST (ang. Representational State Transfer) to też usługi sieciowe, ale, w odróżnieniu od WebService są "lżejsze". Nie ma w nich wielu standardów i funkcji jak w WebService, lecz jedynie zbiór ogólnych wytycznych pomyślanych jako nadbudowa nad standardem HTTP 1.1.Z powodu łatwości implementacji i możliwości budowania integracji w oparciu nie tylko o format XML, ale również coraz bardziej popularny format danych JSON (ang. JavaScript Object Notation) większość API naszych aplikacji zbudowana jest wg. zasad REST.

Dzięki wzorcowi REST można budować złożone rozwiązania, które pod względem zabezpieczeń, wydajności i stabilności nie ustępują klasycznym usługom sieciowym (WebServices).

Tworzone przez e-point API zgodne z REST zawiera autoryzacje, autentykację, weryfikację poprawności danych, a kanał transportowy jest szyfrowany.W przypadku Javy możemy użyć JAXB i uzyskać podobny sposób kontroli typów i wygodę użytkowania jak w usługach sieciowych z definicją WSDL.

INNE TECHNOLOGIE WYMIANY DANYCH

Wiele systemów z którymi integrują się aplikacje powstało dawno temu i nie wspierają one współczesnych technologii integracji. Z niektórymi systemami można się porozumieć wyłącznie za pomocą starszych technologii, jak wymiana plików przez FTP lub nawet bezpośrednia komunikacja z bazą danych.

Tworząc oprogramowanie dla naszych klientów zyskaliśmy doświadczenie w integracji z takimi systemami. Implementując integracje w oparciu o serwer plików FTP napotkaliśmy na problem  transakcji, których serwer FTP nie wspiera. Aby ten problem rozwiązać zastosowaliśmy własną implementację serwera FTP ze składnicą danych opartą o bazę danych.

W integracji pomiędzy systemami opartej na bezpośredniej komunikacji z bazami danych, niezależnie od tego czy to my komunikujemy się ze zdalną bazą czy udostępniamy dane z własnej bazy danych, musimy bezwzględnie pamiętać o ograniczeniu praw dostępu do niezbędnego minimum oraz o użyciu poziomu izolacji transakcji właściwej dla danej bazy. To pozwala na uniknięcie sytuacji, w której obcy system integrujący się z naszym może doprowadzić do zakleszczenia wątków aplikacji na bazie danych i w efekcie do niedostępności systemu.

SYNCHRONICZNOŚĆ A ASYNCHRONICZNOŚĆ ORAZ KOLEJKI

W naszej pracy nad systemami integrującymi implementowaliśmy zarówno rozwiązania oparte na synchronicznej jak i na asynchronicznej wymianie danych.

W zdecydowane większości przypadków warto wybrać integrację asynchroniczną w oparciu o kolejki (w przypadku Javy będzie to JMS i beany MDB sterowane komunikatami). Takie podejście pozwala nam "izolować" systemy które się integrują i nie dopuścić do negatywnego wpływu jednego na drugi. Taka sytuacja może mieć miejsce np. w przypadku wysycenia zasobów wątków, procesora czy pamięci w sytuacji gdy zewnętrzny system jest przeciążony ze względów biznesowych (np. w trakcie kampanii medialnych czy okresów promocyjnych) lub błędu w oprogramowaniu.

Dzięki kolejkom można elastycznie sterować szybkością przetwarzania komunikatów i przydzielać takie zasoby na potrzeby integracji, na ile możemy sobie pozwolić, nie zaniedbując przy tym podstawowych funkcji stojących przed naszym systemem udostępnionych użytkownikom końcowym.

Stosując integrację synchroniczną tam gdzie to konieczne, szczególną uwagę zwracamy na odpowiednie ustawienie limitu czasów na poszczególne operacje i kompensację ewentualnie powstających błędów.

W każdym modelu integracji bardzo ważne jest wdrożenie systemów monitoringu tak, aby dyżurni administratorzy mogli zareagować w przypadku powstawania błędów i nietypowych sytuacji, np. wynikających ze zwiększonej ilości komunikatów lub ich zbyt długiego przetwarzania.

W naszych zastosowaniach aplikacje zawsze udostępniają dane o swoim działaniu dla systemów monitorujących. Najczęściej są one udostępniane przez JMX lub przez pliki generowane w formacie przetwarzanym przez system monitorujący np. Nagios czy Zabbix.

ZADANIA WSADOWE

Kolejny aspekt integracji o którym nie można nie wspomnieć, to zadania wsadowe wyzwalane przez systemy zdalne lub uruchamiane jako zadania okresowe. Są one wykonywane z różną częstotliwością, od cominutowej aż do comiesięcznej. Z naszego doświadczenia wynika, że trudno o wygodniejszy mechanizm niż użycie usługi systemowej „cron” do uruchamiania takich zadań. Nasze narzędzia do uruchamiania zadań wsadowych dbają aby uruchomione zadania nie zachodziły na siebie w przypadku przedłużenia się czasu wykonywania zadania poprzedniego oraz zapewniają monitorowanie czasu wykonania zadania i umożliwiają przerwanie go, jeżeli trwa zbyt długo.

W przypadku uruchamiania zadań wsadowych w systemie typu OLTP, którego charakter działania jest zasadniczo różny, dzielimy duże zadania na mniejsze z zachowaniem kolejności i transakcyjności. Dzięki temu unikamy tworzenia dużej ilości blokad na bazie danych, które mogłyby doprowadzić do braku dostępności systemu dla użytkowników końcowych.

INTEGRACJA PRZEZ PRZEGLĄDARKĘ KLIENTA

Kolejnym sposobem integracji jest integracja, która odbywa się nie bezpośrednio pomiędzy dwoma aplikacjami, tylko z udziałem przeglądarki internetowej użytkownika. Najczęściej służy ona do autentykacji SSO (ang. Single Sign-On). Jeżeli pozwala na to zgodność domen to wykorzystujemy ciasteczka (ang. Cookies) lub generowane unikalne tokeny z dodatkową komunikacją między serwerami przy schematach typu OAuth.

INTEGRACJA NA POTRZEBY AUTORYZACJI

Klienci korporacyjni często mają własne rejestry użytkowników i chcą aby ich pracownicy korzystali z loginu i hasła używanego w innych systemach. W tym celu często integrujemy nasze aplikacje z serwerami LDAP lub ActiveDirectory działającymi w sieci Klienta.

ŚRODOWISKA TESTOWE

Kolejny wymiar komplikacji zarządzania tak złożonym systemem są środowiska testowe aplikacji. Aby przeprowadzić skuteczne i wartościowe testy aplikacji, to scenariusze muszą one uwzględniać aspekt integracji z systemami zewnętrznymi. Oczywiste jest, że testowe środowisko jednej aplikacji musi być połączone z testowymi odpowiednikami zewnętrznych systemów. Błędy w konfiguracji takiego środowiska mogą prowadzić do bardzo poważnych problemów biznesowych, jak złożenie prawdziwego zamówienia, złożenie przelewu lub omyłkowe wysłanie informacji mailem na adres użytkownika końcowego.

W e-point radzimy sobie z tą złożonością takich konfiguracji korzystając z wersjonowanego systemu zarządzanie ustawieniami, gdzie każda konfiguracja integracji jest przypisywana do konkretnej instancji systemu; środowisku produkcyjnemu lub jednemu ze środowisk testowych.