Jak połączyć dwa systemy bez API: pięć dróg od najlepszej do najgorszej

Jak połączyć dwa systemy bez API — to pytanie pada zwykle w chwili, w której ktoś w firmie po raz czwarty przepisuje te same dane z jednego okna do drugiego. Poniżej pięć dróg połączenia ułożonych od najlepszej do najgorszej, przy każdej uczciwa informacja, kiedy jest akceptowalna, a kiedy staje się długiem technicznym. Zacznij jednak od sprawdzenia, czy interfejs faktycznie nie istnieje — bywa, że jest, tylko w wyższym pakiecie albo za dopłatą.

Czym jest API i dlaczego „nie ma API” bywa nieprawdą

API to opisany przez dostawcę zestaw poleceń, dzięki którym jeden program odczytuje i zapisuje dane w drugim bez człowieka klikającego w oknie. Spotkasz kilka jego odmian: REST (dziś najczęstsza, dane przesyłane zwykle w formacie JSON), SOAP (starszy standard oparty na XML, wciąż obecny w systemach księgowych) i GraphQL (pozwala odpytać dokładnie o te pola, których potrzebujesz). Dostęp zabezpiecza się kluczem API, tokenem albo standardem OAuth 2.0, czyli mechanizmem, w którym system nadaje aplikacji ograniczone uprawnienia bez przekazywania jej Twojego hasła.

Dane płyną na dwa sposoby: webhookiem, czyli powiadomieniem wysyłanym przez system natychmiast po zdarzeniu, albo przez odpytywanie cykliczne, czyli sprawdzanie co kilka minut, czy coś się zmieniło. Różnicę między nimi rozkłada osobny tekst o integracji systemów w firmie. Część starszych systemów księgowo-magazynowych obecnych na polskim rynku nie ma publicznego, wspieranego interfejsu — to realna sytuacja, nie wymówka wykonawcy. Zakres dostępnych interfejsów różni się też między wersjami tego samego produktu, co dotyczy między innymi Comarch ERP Optima i Comarch ERP XL, enova365, Symfonii, Subiekta GT i Subiekta nexo, Streamsoft Prestiż, Microsoft Dynamics 365 Business Central oraz SAP.

Pytania do dostawcy, zanim uznasz, że API nie ma

Zapytaj dostawcę na piśmie, zanim uznasz, że interfejsu nie ma — brak wzmianki na stronie produktu nie jest dowodem. API bywa dostępne dopiero w wyższym pakiecie, jako osobny moduł za dopłatą, w nowszej wersji systemu albo wyłącznie dla partnerów wdrożeniowych. Pytanie wysłane mailem ma dodatkową wartość: odpowiedź zostaje na piśmie i można ją pokazać wykonawcy zamiast opowiadać, co powiedziano przez telefon.

Trzy fragmenty odpowiedzi decydują o koszcie na lata: czy zmiany w interfejsie są zapowiadane z wyprzedzeniem, jak długo utrzymywane są starsze wersje i czy istnieje środowisko testowe, na którym da się sprawdzić aktualizację przed wdrożeniem jej u siebie. Pytanie „jak połączyć dwa systemy bez API” ma sens dopiero wtedy, gdy masz pisemną odpowiedź, że interfejsu naprawdę nie ma.

Droga pierwsza: oficjalne, wspierane API dostawcy

Oficjalne API to jedyna droga, którą ktoś poza Twoją firmą ma obowiązek utrzymywać — i dlatego zawsze zaczyna się od sprawdzenia, czy jest dostępna. Dostawca opisuje interfejs, zapowiada zmiany i odpowiada, gdy coś przestaje działać zgodnie z dokumentacją. Po Twojej stronie zostaje utrzymanie własnego klienta: obsługa błędów, ponowienia i logi.

Długiem technicznym staje się tylko wtedy, gdy zbudujesz połączenie bez logów i bez kolejki nieudanych komunikatów, czyli miejsca, w którym lądują odrzucone zdarzenia. Wtedy pierwsza zmiana wersji interfejsu kończy się szukaniem po omacku. Osobno dopytaj o limity liczby zapytań — przy pierwszym imporcie kilkudziesięciu tysięcy rekordów potrafią one przesądzić o kształcie całego rozwiązania.

Droga druga: pliki wymieniane przez SFTP według harmonogramu

Wymiana plików jest najstarszym wciąż sensownym rozwiązaniem: jeden system odkłada o ustalonej porze plik z danymi, a drugi go pobiera i wczytuje. SFTP to szyfrowany sposób przesyłania plików na cudzy serwer i pobierania ich stamtąd; w środku pliku najczęściej jest CSV, XML albo JSON. Ta droga bywa rozwiązaniem docelowym, nie protezą, pod jednym warunkiem: proces może działać wsadowo, czyli nikt nie czeka na wynik przed ekranem.

Żeby wytrzymała lata, potrzebuje trzech rzeczy: spisanej umowy formatu (lista kolumn, kodowanie znaków, separator, format daty i kwoty), katalogu na rekordy odrzucone wraz z powodem odrzucenia oraz alertu, gdy plik nie pojawi się o umówionej godzinie. Przy aktualizacji dostawcy psuje się zwykle po cichu: dochodzi kolumna albo zmienia się kodowanie i import wczytuje śmieci, nie zgłaszając błędu. Awaria wygląda tu jak cisza, więc monitoruj brak plików tak samo uważnie jak błędy.

Droga trzecia: wejście wprost do bazy danych systemu

Integracja przez bazę danych to sięganie po dane z pominięciem samego programu — prosto do magazynu, w którym trzyma on swoje tabele. Działa i bywa jedyną opcją, ale jest długiem technicznym z odroczonym terminem płatności: dostawca nigdy nie obiecywał, że struktura tabel się nie zmieni, więc bywa łamana przy kolejnych aktualizacjach. Zapis do bazy jest znacznie ryzykowniejszy niż odczyt, bo omija reguły, które program wykonuje sam: numerację dokumentów, przeliczenia i wpisy w historii zmian.

Akceptowalny wariant jest wąski — odczyt do raportu, najlepiej z kopii bazy, po pisemnym potwierdzeniu, że dostawca się temu nie sprzeciwia. Utrzymuje to wyłącznie Twoja firma, bo takie użycie zwykle nie jest objęte wsparciem. Awaria bywa najbardziej kosztowna ze wszystkich pięciu dróg: dane rozjeżdżają się po cichu i wychodzi to przy inwentaryzacji albo zamknięciu miesiąca. Przed decyzją sprawdź umowę licencyjną systemu oraz to, jakie dane osobowe znajdą się w kopii bazy — ten materiał ma charakter informacyjny i nie jest poradą prawną.

Droga czwarta: ręczny import i eksport plików CSV

Ręczne przenoszenie plików nie jest integracją, tylko procedurą wykonywaną przez człowieka, i tak należy je planować. CSV to zwykły plik tekstowy z tabelą, w którym kolejne pola oddziela przecinek albo średnik. Rozwiązanie broni się przy jednym kierunku przepływu, małym wolumenie, jednej odpowiedzialnej osobie i spisanej procedurze — jako most na kilka tygodni, nie na kilka lat.

Długiem staje się w dniu, w którym eksport trzeba robić codziennie. Awaria nie ma tu komunikatu błędu: ktoś zachorował, pojechał na urlop albo wczytał ten sam plik dwa razy i w systemie pojawiły się duplikaty. Przy stanach magazynowych ta droga jest szczególnie zdradliwa, bo dane starzeją się w godzinach, co rozkłada tekst o synchronizacji stanów magazynowych. Jeżeli decydujesz się na CSV, ustal datę wygaszenia, zanim uruchomisz procedurę.

Droga piąta: odczyt z panelu, czyli scraping — i dlaczego prawie nigdy

Scraping to program, który loguje się do panelu jak człowiek i odczytuje dane z ekranu, bo żadne drzwi dla programów nie zostały udostępnione. Wchodzi w grę wyłącznie w wąskim przypadku: jednorazowe pobranie własnych danych przed migracją, tylko do odczytu, w ustalonym terminie i po pisemnym potwierdzeniu, że dostawca tego nie zabrania. Jako stałe połączenie dla procesu, na którym stoi sprzedaż, jest najgorszym możliwym wyborem.

Powody są trzy i żaden nie jest techniczną drobnostką. Po pierwsze, rozwiązanie psuje się przy dowolnej zmianie wyglądu panelu, a dostawca nie ma obowiązku jej zapowiadać. Po drugie, wymaga przechowywania danych logowania prawdziwego użytkownika, więc w historii systemu wszystkie operacje przypisane są tej osobie, a uwierzytelnianie dwuskładnikowe zwykle blokuje automat. Po trzecie, regulaminy części systemów wprost zakazują automatycznego dostępu — sprawdź to, zanim ktokolwiek zacznie pisać kod.

Jak połączyć dwa systemy bez API: pięć dróg obok siebie

Wybór sprowadza się do trzech pytań: kto ma obowiązek utrzymać połączenie, co się z nim stanie przy najbliższej aktualizacji dostawcy i po czym poznasz, że przestało działać. Tabela poniżej odpowiada na nie dla każdej z pięciu dróg.

Niezależnie od wybranej drogi zamów ten sam zestaw minimum: logi z treścią komunikatu, alert na ciszę, kolejkę nieudanych komunikatów, procedurę ponowienia i jednego właściciela po stronie firmy — to lista wspólna dla każdej integracji systemów w firmie. To, czy przepływ zbudujesz w gotowym narzędziu, czy własnym kodem, jest osobną decyzją, którą porządkuje porównanie Make, n8n i własnej integracji. Koszt rządzi się natomiast tą samą logiką co wycena aplikacji mobilnej: płacisz za przypadki brzegowe i uzgodnienia, nie za liczbę przepisywanych pól.

Jeżeli nie wiesz, którą drogą pójść, opisz oba systemy w kreatorze briefu — sześć kroków wystarczy, żeby rozmowa zaczęła się od tego, jakie dane mają przechodzić między systemami i jak często, a nie od nazwy narzędzia.