Integracje i API na zamówienie

Najczęstszy przypadek to przyjmowanie zleceń bezpośrednio z systemu nadawcy — zamiast maila, przez interfejs, którym zlecenia spływają automatycznie, wraz ze zmianami i anulacjami. Drugi w kolejności to raportowanie zwrotne: statusy, godziny podstawienia, potwierdzenia dostawy przekazywane do systemu klienta w formacie, którego on oczekuje.

Osobną kategorią są systemy magazynowe i produkcyjne, gdzie transport jest tylko końcówką procesu, oraz wymiana dokumentów w ustalonych formatach, wciąż powszechna w relacjach z dużymi odbiorcami.

Samo przesłanie danych między dwoma systemami jest zadaniem rutynowym. Trudność leży w uzgodnieniu, co dane znaczą. Kiedy przewóz jest „rozpoczęty” — gdy kierowca ruszył, gdy dojechał na załadunek, czy gdy dokument został podpisany? Co to jest jedna przesyłka po stronie nadawcy, a co po stronie przewoźnika?

Te rozbieżności ujawniają się dopiero na produkcji i to one generują większość kosztów utrzymania. Dlatego zaczynamy od słownika pojęć uzgodnionego z obiema stronami, zanim powstanie pierwsza linijka kodu.

Zdarza się częściej, niż wynikałoby z ofert: system po drugiej stronie działa od lat, obsługuje go jedna osoba, a opis interfejsu nie istnieje albo jest nieaktualny. Taki projekt daje się przeprowadzić, ale wymaga innego podejścia — pracy na przykładach, testów na danych rzeczywistych i budżetu z zapasem na odkrycia.

Uczciwie oznaczamy takie przypadki jako obarczone większą niepewnością. Wycena ryczałtowa integracji z niedokumentowanym systemem jest albo zawyżona, albo skończy się aneksem.

Ruch bywa też w drugą stronę: firma ma własne narzędzia — raportowanie, portal dla klientów, aplikację handlowców — i potrzebuje sięgać do danych z systemu transportowego. Udostępniamy do tego interfejs programistyczny, z którego może korzystać zespół klienta albo jego dostawca.

Dostęp jest zakresowy, więc zewnętrzne narzędzie widzi tylko to, do czego zostało uprawnione. Ma to znaczenie, gdy z API korzysta firma trzecia.

Integracja nie jest projektem zamkniętym. Druga strona zmienia wersję, dokłada pole, zmienia zakres statusów albo migruje na inny system. Bez ustalonego trybu reagowania połączenie działa do pierwszej takiej zmiany, a potem cicho przestaje, zwykle w najgorszym możliwym momencie.

Dlatego przy każdym takim projekcie ustalamy monitoring i tryb reakcji na awarię. Sama integracja to zwykle mniejsza część kosztu w perspektywie kilku lat.

Przy integracji szybko wychodzi na jaw jakość danych u obu stron. Ta sama firma figuruje pod trzema nazwami, adres załadunku jest wpisany w polu na uwagi, kod pocztowy bywa pusty. Dopóki dane czyta człowiek, wszystko działa, bo człowiek się domyśla. System się nie domyśla.

Dlatego etap rozpoznania obejmuje przegląd realnej próbki danych, a nie tylko opisu interfejsu. Czasem wnioskiem z tego przeglądu jest, że przed integracją trzeba uporządkować kartotekę — i lepiej dowiedzieć się tego przed podpisaniem umowy niż w połowie prac.

Przy kilku zleceniach miesięcznie od jednego kontrahenta integracja się nie zwróci — przepisanie ich ręcznie jest tańsze niż jakiekolwiek połączenie systemów, także w perspektywie kilku lat.

Nie warto też budować integracji z systemem, który po drugiej stronie ma zostać wymieniony w przewidywalnym terminie. Lepiej poczekać na następcę niż płacić dwa razy w odstępie roku, a przy okazji utrzymywać przez ten czas połączenie, o którym z góry wiadomo, że zostanie wyrzucone.