Integracje systemów, które utrzymują ciągłość procesów

Integracja powinna znać źródło prawdy

Ten sam klient może występować w CRM-ie, programie księgowym, narzędziu projektowym i systemie mailingowym. Przed połączeniem ustalam, który system odpowiada za dane kontaktowe, status sprzedaży, rozliczenie i zgodę marketingową. Każde pole dostaje kierunek przepływu oraz regułę rozstrzygania zmian.

W obu systemach zapisuję powiązane identyfikatory rekordów. Dzięki temu kolejna aktualizacja trafia do właściwego klienta lub projektu. Integracja może także rozpoznać, czy przetwarza nowe zdarzenie, ponowioną dostawę czy zmianę wykonaną już po pierwszym uruchomieniu procesu.

Webhook rozpoczyna pracę, kolejka pomaga ją dokończyć

Webhook może natychmiast poinformować o wysłanym formularzu, opłaconym zamówieniu albo zmianie etapu sprzedaży. Odbiorca weryfikuje źródło i zapisuje zdarzenie. Dłuższe operacje trafiają do kolejki, gdzie można kontrolować tempo oraz ponawiać wybrane kroki.

Ponowienia mają limit i dotyczą błędów chwilowych, takich jak timeout lub przekroczony limit zapytań. Błędne dane i brak uprawnień wymagają działania człowieka. Alert wskazuje rekord, etap, liczbę prób i odpowiedź systemu w zakresie bezpiecznym dla logów.

Przy fakturowaniu takie rozróżnienie ma bezpośredni skutek biznesowy. Integracja powinna wiedzieć, czy dokument czeka na wysyłkę, został przyjęty, został odrzucony lub wymaga decyzji. Trwały identyfikator sprzedaży oraz zapis odpowiedzi API chronią przed utworzeniem drugiej faktury po utracie połączenia.

Uprawnienia i logi projektuję razem z przepływem danych

Osobne konto techniczne ułatwia kontrolę operacji i zapobiega przerwaniu integracji po zmianie konta pracownika. Nadaję mu zakres potrzebny do konkretnego procesu. Dostęp do odczytu, zapisu i zarządzania konfiguracją może wymagać różnych uprawnień.

Poświadczenia przechowuję poza kodem i treścią scenariusza. Logi pokazują przebieg, identyfikatory i przyczynę błędu, a dane klientów i sekrety są ograniczone do zakresu potrzebnego przy diagnozie. Dokumentacja wskazuje miejsce przechowywania konfiguracji, właściciela dostępów i sposób ich wymiany.

Livespace CRM MCP jako przykład warstwy nad API

W projekcie Livespace CRM MCP zamieniłem około 80 metod API w 11 narzędzi opisanych zadaniami użytkownika. Serwer sprawdza argumenty, pilnuje limitów, składa właściwe wywołania i zwraca agentowi wynik w formie, którą może bezpiecznie wykorzystać.

Sześć narzędzi odczytuje dane, a pięć wykonuje zapis. Każda zmiana najpierw tworzy plan. Zapis wymaga jednorazowego potwierdzenia człowieka, a serwer po operacji ponownie odczytuje rekord i sprawdza przesłane pola. Dostęp można uruchomić w trybie read-only, poświadczenia zostają po stronie serwera, a uprawnienia wynikają z konta użytkownika Livespace.

Ten projekt pokazuje, jak ważna jest warstwa dopasowana do zadania. Integracja przejmuje ograniczenia API, kontrolę kolejności, weryfikację identyfikatorów i opis niepewnego wyniku. Dzięki temu system korzystający z połączenia dostaje mniejszy, przewidywalny zestaw operacji.

Konkretne narzędzia

Dla dwóch systemów rozpisałem możliwości integracji osobno, razem z modułami, metodami API i pułapkami, na które trzeba zaprojektować scenariusz:

• Automatyzacja Livespace: reguły w samym CRM-ie, 30 modułów w Make, API RPC z około 80 metodami i serwer MCP.
• Automatyzacja Easytools: 14 zdarzeń webhooka, easycart i easymail API oraz oficjalny serwer MCP.