Integracja ma konkretne zadanie.
„Połączmy aplikację z magazynem” to początek rozmowy, nie gotowy zakres. Trzeba ustalić, jakie informacje mają przechodzić, w którą stronę i w jakim momencie. Pobieranie listy produktów, sprawdzanie dostępności oraz zapis zamówienia są trzema różnymi zadaniami.
Podobnie kalendarz może służyć tylko do pokazania terminu albo również do potwierdzenia rezerwacji. Sam widok wolnej godziny nie dowodzi, że termin został skutecznie zapisany. Najpierw opisujemy oczekiwany rezultat dla klienta i firmy, potem dobieramy sposób połączenia.
Przygotuj nazwy obecnych narzędzi, kontakt do osoby mającej dostęp i przykładowe dane. W pierwszym etapie można ograniczyć połączenie do jednej operacji. Przykład zamówienia B2B pokazuje interfejs; rzeczywiste połączenie z magazynem wymaga osobnej pracy.
Sprawdzamy dokumentację i uprawnienia.
API jest uzgodnionym sposobem wymiany danych z systemem. Dostawca może określać dostępne operacje, limity, autoryzację i opłaty. Nie każda usługa udostępnia takie same możliwości, nawet jeśli obsługuje podobne procesy. Potrzebny jest dostęp odpowiadający konkretnemu zakresowi.
Warto sprawdzić środowisko testowe i możliwość wykonania próby na danych przykładowych. Kluczy oraz haseł nie wpisujemy do materiałów publicznych ani kodu widocznego w przeglądarce. Produkcyjne połączenia wymagające sekretów wykonuje odpowiednio zabezpieczona warstwa serwerowa.
OWASP opisuje ochronę połączeń REST, sprawdzanie danych i dostępu w REST Security Cheat Sheet. Jest to wskazówka do projektowania, nie potwierdzenie bezpieczeństwa dowolnej integracji.
Każda ważna informacja ma źródło.
Jeśli magazyn odpowiada za dostępność, trzeba określić, czy aplikacja może ją tylko odczytywać czy także zmieniać. Ustalamy identyfikatory produktów, jednostki, statusy i moment aktualizacji. Różnica między sztuką a opakowaniem może zepsuć poprawnie wyglądające zamówienie.
Niektóre połączenia przekazują informacje od razu, inne okresowo. Użytkownik powinien wiedzieć, czy widzi aktualny stan, czy dane z ostatniego odczytu. Nie deklarujemy „synchronizacji w czasie rzeczywistym”, jeśli sposób działania i testy tego nie potwierdzają.
Dla każdego pola zapisujemy znaczenie i odpowiedzialność za zmianę. W razie niezgodności potrzebna jest możliwość wyjaśnienia, skąd pojawiła się wartość. Unikamy dwóch niezależnych miejsc, które bez ustalonych zasad nadpisują tę samą ważną informację.
Brak odpowiedzi nie zawsze oznacza brak operacji.
Serwer zewnętrzny może przyjąć zamówienie, a odpowiedź dotrzeć z opóźnieniem. Ponowne wysłanie bez kontroli może utworzyć duplikat. Dlatego projekt obejmuje identyfikację operacji, sprawdzenie wyniku i zasady ponawiania. To część procesu biznesowego, nie tylko techniczny szczegół.
Inny przypadek to odrzucone dane lub przekroczony limit. Aplikacja powinna pokazać, co zostało zapisane, co wymaga poprawy i czy użytkownik powinien czekać. Nie wyświetlamy potwierdzenia wyłącznie dlatego, że kliknięto przycisk. Potrzebny jest ustalony warunek faktycznego sukcesu.
Zespół firmy może potrzebować listy spraw wymagających ręcznego wyjaśnienia. Taki widok jest czasem bardziej użyteczny na start niż pełna automatyzacja wszystkich wyjątków. Uwzględniamy go w zakresie, jeśli bez niego zgłoszenia znikałyby między systemami.
Testujemy wymianę, a nie tylko ekran.
Próba integracji powinna potwierdzić, że właściwe dane trafiły do właściwego systemu. Sprawdzamy poprawne wykonanie, błędne pole, brak odpowiedzi i ponowienie. Jeżeli połączenie zmienia stan magazynu lub rozliczenie, test wymaga bezpiecznych danych i ustalonego środowiska.
Przykładowy warunek odbioru: po ponowieniu tego samego potwierdzonego zamówienia nie powstaje druga sprawa. Inny: niedostępność kalendarza nie pozwala obiecać terminu, którego nie można zapisać. Takie warunki powinny być znane przed wykonaniem połączenia.
Testy na środowisku dostawcy nie zawsze odtwarzają wszystkie ograniczenia produkcji. Przed uruchomieniem potwierdzamy odpowiednie konta, konfigurację i limit usług. Poradnik testów rozdziela reguły, interfejs oraz sprawdzenie integracji.
Połączenie również wymaga utrzymania.
Dostawca może zmienić API, sposób autoryzacji lub dostępne dane. Dlatego zapisujemy, od którego narzędzia aplikacja zależy i kto odpowiada za kontakt w razie zmiany. Ważne są także monitorowanie nieudanych operacji oraz możliwość ich wyjaśnienia przez obsługę.
W ofercie oddzielamy przygotowanie połączenia od kosztów korzystania z zewnętrznej usługi i dalszej obsługi. Nie zakładamy darmowego ani bezterminowego dostępu. Dokładne warunki zależą od dostawcy i zakresu potrzebnego firmie.
Na początek wybierz połączenie, które usuwa najważniejszą pracę ręczną. Podaj dane, kierunek wymiany i rezultat. Taki opis pomaga przygotować zakres integracji, zamiast wyceniać nieokreślone hasło „aplikacja połączona ze wszystkim”.
Jaką decyzję podjąć dalej?
Gdy dostępność produktu zależy od innego systemu, przeczytaj Jak wskazać nadrzędne źródło stanu magazynowego?.
Przy połączeniu zamówienia z rozliczeniem sprawdź Jak rozdzielić wewnętrzny status i wynik płatności?.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Integracje systemów.
Praktyczny kontekst znajdziesz w opisie Aplikacja dla hurtowni i sprzedaży B2B. To możliwy zakres dla branży, który dobieramy do konkretnej firmy.