„Mamy API" nie znaczy „da się zintegrować"

API to nie jest jedna rzecz

„Mamy API" może znaczyć REST z OAuth2 i dokumentacją. Może też znaczyć bibliotekę COM działającą wyłącznie pod Windows, do której trzeba licencji na każdą sesję. Może znaczyć widok SQL, który ktoś kiedyś wystawił. Może znaczyć plik XML wrzucany na FTP raz na godzinę.

Wszystkie cztery są prawdziwymi odpowiedziami na pytanie „czy macie API". Każda oznacza inny projekt, inny stack i inny rząd wielkości kosztu.

To nie jest złośliwość ze strony klienta. Osoba, która to mówi, zwykle powtarza zdanie, które usłyszała od swojego dostawcy ERP-a - i dla dostawcy to zdanie jest prawdziwe.

Sześć pytań przed wyceną

Zanim ktokolwiek poda liczbę, potrzebujesz odpowiedzi na sześć rzeczy. Żadna z nich nie jest w folderze reklamowym.

1. Czym to jest technicznie? REST, SOAP, COM/.NET, pliki, dostęp do bazy. To przesądza, czy sklep na Linuksie w ogóle może z tym rozmawiać bez mostu po drodze.

2. Ile jest równoległych sesji i czy są licencjonowane? Pytanie, które ratuje najwięcej projektów. Przy Sferze Subiekta odpowiedź brzmi „kilka" i „tak" - i to zmienia całą architekturę, bo nagle potrzebujesz kolejkowania i priorytetów, a nie zwykłych wywołań.

3. Czy są webhooki, czy trzeba odpytywać? Brak webhooków oznacza polling, a polling oznacza opóźnienie i obciążenie. Większość polskich ERP-ów nie ma webhooków. To nie jest wada - to jest fakt, który trzeba wpisać do projektu.

4. Czy da się liczyć cenę kontraktową jednym wywołaniem, czy trzeba odtwarzać reguły? Jeśli API zwraca tylko cennik i musisz sam składać rabaty w odpowiedniej kolejności, właśnie dowiedziałeś się, że projekt jest dwa razy większy - i że wchodzisz w drugie źródło prawdy dla ceny.

5. Co się dzieje przy timeoucie zapisu? Czy da się bezpiecznie powtórzyć zapytanie, czy dostaniesz drugi dokument? Bez idempotencji albo pola na numer referencyjny każdy timeout to ręczne dochodzenie w księgowości.

6. Czy jest środowisko testowe? Odpowiedź „testujemy na produkcji, ale ostrożnie" to nie jest odpowiedź żartobliwa. To jest realny stan wielu wdrożeń i realny czynnik ryzyka.

Najczęstsza niespodzianka

Ze wszystkich sześciu punktów najczęściej boli licencjonowanie sesji, bo jest to jedyny, który nie jest problemem technicznym i którego nie da się obejść lepszym kodem.

Możesz napisać idealny most, opakować wszystko w kolejki i cache. Jeśli klient ma trzy licencje Sfery, a dział sprzedaży zajmuje dwie w godzinach pracy, twoja integracja ma jedną. I to jest fakt, którego nie zmieni refactor - zmieni go tylko faktura u partnera InsERT-u.

Dlatego to pytanie zadaje się przed wyceną, a nie w trzecim miesiącu. Konkrety dla Subiekta rozbieram w tekście o integracji z Subiekt GT.

Jak to sprawdzić w jeden dzień

Nie potrzebujesz tygodni analizy. Potrzebujesz jednego dnia i dostępu do środowiska klienta, żeby wykonać cztery operacje:

• Pobierz listę stu towarów i zmierz, ile to trwało.
• Policz cenę kontraktową dla konkretnego kontrahenta i konkretnego indeksu. Porównaj z tym, co pokazuje ERP na ekranie.
• Utwórz testowe zamówienie i zobacz, co wraca.
• Wywołaj to samo utworzenie drugi raz z tym samym numerem referencyjnym i sprawdź, czy powstały dwa dokumenty.

Ten jeden dzień jest różnicą między wyceną a zgadywaniem. Jeśli klient nie może go udostępnić przed podpisaniem umowy, to też jest informacja - i warto ją wpisać do ryzyk projektu, zamiast do kosztów.

Co zrobić z odpowiedziami i kiedy postawić warstwę pośrednią, opisałem w tekście o middleware kontra integracja bezpośrednia.

Co dalej

• Jak to wygląda przy polskim ERP: Integracja z Subiekt GT
• Co zrobić z odpowiedziami: Middleware vs. bezpośrednio
• Pełny przegląd integracji: pillar /integracje