Integrację warto zacząć od ustalenia, który system odpowiada za konkretną informację. Dopiero potem wybiera się sposób jej przesyłania. Bez tych zasad połączenie programów może szybciej rozprowadzać błędne dane, zamiast ograniczać ręczną pracę.
Jedna informacja, jedno uzgodnione źródło
Cena może pochodzić z programu handlowego, opis produktu ze sklepu, a status wysyłki od przewoźnika. Dla każdego pola trzeba wskazać, gdzie jest zmieniane i kto może je nadpisać. To szczególnie ważne, gdy pracownicy przywykli poprawiać te same dane w kilku miejscach.
Przygotuj prostą listę: informacja, system źródłowy, odbiorca, moment aktualizacji. Jeśli firma nie potrafi ustalić źródła prawdy dla stanu magazynowego, sama integracja nie rozstrzygnie rozbieżności. Najpierw potrzebna jest decyzja organizacyjna.
Opisz kierunek i częstotliwość synchronizacji
Przesłanie zamówienia do magazynu nie oznacza jeszcze zwrotnego przesyłania statusów, dokumentów i numerów przesyłek. Każdy kierunek ma własny zakres. Wycena powinna je wymieniać, zamiast ograniczać się do stwierdzenia, że dwa programy zostaną połączone.
Nie każda informacja musi być aktualizowana natychmiast. Ustal akceptowalne opóźnienie oraz skutek jego przekroczenia. Dzienny raport i dostępność ostatniej sztuki produktu mają inne wymagania. Częstotliwość trzeba też dopasować do limitów i możliwości dostawców.
API, plik czy powiadomienie o zdarzeniu?
API pozwala programom wykonywać udostępnione przez dostawcę operacje. Plik CSV lub XML może służyć do okresowego importu. Powiadomienie o zdarzeniu informuje inny system, że coś się zmieniło. Są to narzędzia do wykonania uzgodnionego zadania, a nie zamienne obietnice pełnej synchronizacji.
Na przykład WooCommerce opisuje webhooks jako powiadomienia o zdarzeniach, między innymi związanych z zamówieniami i produktami. Samo wysłanie powiadomienia nie oznacza jednak, że system odbiorcy poprawnie przetworzył operację.
Przed wyceną sprawdzamy dokumentację, wersje programów, wymagane uprawnienia i warunki dostępu do integracji. Nie każdy dostawca udostępnia wszystkie potrzebne dane lub działania w posiadanym pakiecie.
Zaplanuj brak odpowiedzi i powtórne wysłanie
Połączenie może zostać przerwane w chwili, gdy odbiorca zapisał zamówienie, ale nadawca nie otrzymał potwierdzenia. Ponowienie nie powinno wtedy tworzyć drugiego zamówienia. Potrzebny jest sposób rozpoznania tej samej operacji i sprawdzenia jej wyniku.
- Co można ponowić automatycznie, a co wymaga decyzji człowieka?
- Kto dostaje informację o nieudanym przesłaniu?
- Gdzie widać ostatnią poprawną synchronizację?
- Jak poprawić odrzucone dane i wznowić obsługę?
- Jak wykryć zdarzenia pominięte podczas przerwy?
Widoczna kolejka błędów i możliwość wyjaśnienia pojedynczego przypadku są istotną częścią projektu. Nie warto odkładać ich do momentu pierwszej awarii.
Jak odebrać gotowe połączenie?
Przykład demonstracyjny: zamówienie przechodzi ze sklepu do systemu obsługi, a numer przesyłki wraca do klienta. Odbiór obejmuje zwykłe zamówienie, brak produktu, anulowanie, ponowne powiadomienie oraz przerwę połączenia. Każdy przypadek powinien mieć uzgodniony wynik.
Do testów używaj fikcyjnych danych i środowiska, które nie uruchomi przypadkiem prawdziwej wysyłki, płatności ani zamówienia u dostawcy. Przed startem ustal odpowiedzialność za monitoring i zmiany po aktualizacji jednego z systemów.
Integracja bywa małym samodzielnym projektem albo częścią większego programu. Zobacz też, co wpływa na wycenę programu na zamówienie. W MAXIKAZ pomagamy najpierw uporządkować zakres, a następnie połączyć narzędzia w uzgodnionym procesie.