Systemy informatyczne warto ze sobą integrować, należy to jednak robić z głową - pamiętając o wzbogaceniu mechanizmów synchronizacyjnych o obsługę błędów. Jej brak może skutkować wieloma problemami, jak np. niespójność danych w zintegrowanych systemach - a wystąpienie duplikatów bądź luk w przechowywanych zasobach to zawsze bardzo nieprzyjemny scenariusz. Dziś parę słów o tym, jak rozpoznać dobry projekt integracji systemów, właściwie traktujący o obsłudze błędów.
{flike}
Na czym polega błąd integracji?
Niezależnie od tego, jak dobrze nie zostałaby zaprojektowana i wykonana integracja systemów informatycznych, podczas jej eksploatacji mogą pojawić się pewne problemy - błędy synchronizacji danych. Najczęściej wynikają one z braku możliwości nawiązania połączenia między systemami, będącego skutkiem np. czasowej niedostępności jednego z nich (np. awaria) bądź braku dostępu do sieci.
Przykładowo: w sklepie internetowym firmy Super-Sell przyjęto zamówienie. W wyniku działającej integracji sklepu internetowego z systemem kurierskim, przyjęcie zamówienia skutkuje automatycznym wezwaniem kuriera po odbiór zapakowanego towaru. W związku z powyższym, sklep internetowy wysyła informację do systemu kurierskiego o oczekującej przesyłce - jednak system kurierski jest chwilowo przeciążony i komunikat sklepu internetowego nie może do niego dotrzeć. Towar, mimo że zakupiony przez klienta, nie zostanie wysłany na skutek usterki technicznej. Sytuacja, na którą żaden profesjonalny sklep internetowy nie może sobie pozwolić. Co teraz?
Opisany przypadek, a także szereg podobnych, ale wynikających z innej przyczyny, należy obsłużyć - czyli wykonać rozwiązanie integracyjne w taki sposób, aby pojawiające się problemy (a tych nie możemy wykluczyć) były rozwiązywane automatycznie, bez ludzkiej ingerencji.
Dobra obsługa błędów integracji systemów, czyli jaka?
- System, który jest stroną aktywną integracji (a więc tą, która inicjuje synchronizację komunikatów - tj. pobiera i wysyła informacje na własne żądanie) powinien być wyposażony w rejestr synchronizowanych komunikatów, czyli miejsce, w którym jego administrator mógłby zweryfikować jakie dane powinny zostać zsynchronizowane, a jakie faktycznie zostały. Poszczególne wpisy rejestru muszą posiadać szczegółowe informacje o źródle powstania komunikatu, dacie jego powstania oraz dacie i statusie jego synchronizacji.
- W przypadku braku możliwości synchronizacji (a więc wysyłki bądź pobrania) komunikatu, system automatycznie powinien ponowić próbę jej wykonania (np. po określonym czasie bądź w ramach kolejnego cyklu synchronizacji) - do skutku. Przy czym ponowienie próby wysyłki komunikatu powinno nastąpić jedynie wówczas, gdy komunikat w dalszym ciągu ma zastosowanie. Przykładowo: w systemie A zmieniamy adres klienta, system A podejmuje nieudaną próbę wysyłki informacji o tej zmianie do systemu B, w międzyczasie w systemie A adres klienta zostaje ponownie zmieniony - w takim przypadku wznowienie synchronizacji przez system A nie powinno mieć miejsca (konieczna więc weryfikacja źródła komunikatu przed ponowną próbą jego wysłania).
- Przyczyna nieudanej synchronizacji komunikatu (tj. kod błędu - np. 404 - not found, 500 - internal server error itp.), powinna zostać odnotowania w systemie w ramach logu integracji systemów.
- Administrator systemu powinien mieć możliwość manualnego wpływania na przesyłane komunikaty - poprzez np. ich modyfikację, usuwanie, ponawianie wysyłki na żądanie.
- Dobrą praktyką jest automatyczne powiadamianie przez system jego administratora (np. w formie maila bądź okresowego raportu) o komunikatach, które w określonym okresie nie zostały skutecznie zsynchronizowane.
Integracja systemów informatycznych bez obsługi błędów?
Oczywiście, istnieją przykłady integracji, w których obsługa błędów nie jest konieczna - np. wyświetlanie w danym systemie (na żądanie) informacji o kliencie, pozyskanych z Facebooka. Takie informacje nie muszą fizycznie trafiać do bazy danych systemu, trudno więc tutaj mówić o jakiejkolwiek synchronizacji, a zwłaszcza obsłudze jej niepowodzeń.
Natomiast w przypadku każdej integracji, w ramach której dwa systemy informatyczne wymieniają się jakimikolwiek danymi, wymagane jest stworzenie przemyślanego projektu, solidne wykonanie i rzetelne testy. Tego typu prace oznaczają niemały koszt i wysiłek organizacyjny dla beneficjenta integracji. Warto je jednak ponieść - w przeciwnym wypadku bowiem, integracja wykonana niepoprawnie, np. bez obsługi błędów synchronizacji może przynieść firmie więcej szkód niż korzyści.
Komentarze (1)