Firma może korzystać z dobrych aplikacji, a mimo to tracić czas na ręczne przenoszenie danych. Problemem nie jest wtedy pojedynczy system, lecz brak uzgodnionego przepływu informacji. Integracja powinna określać, które narzędzie jest źródłem danych, kiedy następuje aktualizacja i co dzieje się w przypadku błędu.
Połączenie dwóch aplikacji nie jest celem samym w sobie. Celem jest poprawny proces biznesowy, który można monitorować i utrzymać.
API i webhook pełnią różne role
API umożliwia aplikacjom wymianę danych według określonych zasad. Jedno narzędzie może zapytać drugie o klienta, utworzyć rekord albo zmienić status, jeżeli posiada odpowiednie uprawnienia.
Webhook przekazuje informację o zdarzeniu, na przykład o wysłaniu formularza lub opłaceniu zamówienia. Dzięki temu system nie musi stale sprawdzać, czy wydarzyło się coś nowego. Sam webhook może zawierać komplet danych albo jedynie identyfikator potrzebny do pobrania szczegółów przez API.
Dostępność integracji zależy od konkretnego planu usługi, zakresu API i limitów. Informacja, że narzędzie „ma API”, nie potwierdza jeszcze, że udostępnia operację potrzebną w danym procesie.
Wskaż źródło prawdy
Dla każdego rodzaju informacji trzeba wybrać system nadrzędny. Dane klienta mogą być utrzymywane w CRM, status płatności w systemie finansowym, a plik umowy w repozytorium dokumentów.
Jeżeli dwa systemy mogą niezależnie zmieniać to samo pole, pojawia się konflikt. Integracja powinna określać kierunek synchronizacji i sposób rozstrzygnięcia różnic. Kopiowanie danych w obie strony bez reguł może prowadzić do nadpisania poprawnej wartości starszą informacją.
Identyfikatory są ważniejsze niż nazwy
Łączenie rekordów wyłącznie na podstawie nazwy firmy albo imienia i nazwiska jest zawodne. Nazwa może zostać zapisana na kilka sposobów, a różne osoby mogą mieć takie same dane.
Proces powinien korzystać ze stabilnego identyfikatora. Jeżeli systemy używają innych identyfikatorów, potrzebna jest kontrolowana tabela powiązań. Adres e-mail może być pomocny, ale nie zawsze jest unikalny ani stały.
Obsłuż duplikaty i ponowienia
Zdarzenie może zostać wysłane więcej niż raz. Integracja powinna być odporna na ponowienie i rozpoznawać, czy operacja została już wykonana. Bez tego jedno zamówienie może utworzyć kilka faktur lub zadań.
Należy też ustalić kolejność. Jeśli kolejne zdarzenie dotrze przed poprzednim, system nie powinien automatycznie przyjąć, że później odebrana wiadomość opisuje nowszy stan.
Błąd musi być widoczny
Najbardziej niebezpieczna integracja to taka, która przestaje działać po cichu. Każdy krytyczny przepływ powinien mieć rejestr operacji, komunikat o błędzie i właściciela alarmu.
Warto rozróżnić błąd chwilowy od błędu danych. Niedostępność usługi może uzasadniać ponowienie po określonym czasie. Brak wymaganego pola wymaga interwencji albo uzupełnienia danych. Wielokrotne ponawianie niepoprawnego rekordu zwiększa liczbę błędów bez rozwiązania przyczyny.
Minimalne uprawnienia
Integracja powinna otrzymać tylko taki dostęp, jakiego potrzebuje. Jeżeli ma odczytywać status, nie powinna móc usuwać klientów. Osobne konto techniczne ułatwia kontrolę historii i odebranie uprawnień.
Klucze i tokeny dostępu nie powinny znajdować się w arkuszach, wiadomościach ani kodzie dostępnym publicznie. Potrzebny jest bezpieczny sposób przechowywania, wymiany i unieważniania danych dostępowych.
Testy przed uruchomieniem
Test powinien obejmować poprawny rekord, brak pola, duplikat, ponowienie zdarzenia, zmianę danych, niedostępność systemu i przekroczenie limitu zapytań. Należy także sprawdzić, czy błędną operację można odwrócić.
Uruchomienie warto rozpocząć od ograniczonego zakresu i porównywać dane w systemach. Dopiero po potwierdzeniu stabilności można zwiększać wolumen albo dodawać kolejne ścieżki.
Integracja wymaga utrzymania
API, struktura pól i uprawnienia mogą się zmieniać. Właściciel procesu powinien wiedzieć, kto reaguje po aktualizacji jednego z narzędzi. Dokumentacja powinna opisywać cel, źródła danych, mapowanie pól, błędy i sposób ręcznej obsługi.
Audyt integracji pozwala ustalić, gdzie dane są przepisywane, które systemy powinny być połączone i czy koszt utrzymania będzie uzasadniony. Sprawdź zakres audytu.