Brak gotowego połączenia nie zamyka drogi. Większość platform pozwala wywołać dowolny interfejs samodzielnie.
Co jest potrzebne
Dokumentacja interfejsu systemu, dane dostępowe i zrozumienie struktury przekazywanych danych. Nie wymaga programowania w pełnym sensie — trzeba wskazać adres, metodę, nagłówki i treść zapytania, a to są dane do wypełnienia, nie kod do napisania.
Praktyczny warunek jest inny: ktoś musi wiedzieć, którą operację systemu wywołać. Dokumentacja opisuje możliwości, nie proces firmy. Zestawienie jednego z drugim jest właściwą pracą przy takim przepływie.
Uwierzytelnianie
Klucz, token albo logowanie. Dane dostępowe przechowywane w mechanizmie platformy, nie wpisane w krok przepływu — wpisane wprost trafiają do historii wykonań i widzi je każdy, kto ma podgląd. Część interfejsów wymaga odświeżania tokenu, więc przepływ musi to przewidzieć, inaczej przestanie działać po cichu. Zasady dostępu opisuje tekst o uprawnieniach i dostępach w platformie.
Obsługa odpowiedzi
Sprawdzenie kodu odpowiedzi przed przetworzeniem danych. Odpowiedź błędna potraktowana jak poprawna daje puste rekordy. Część systemów zwraca opis błędu przy poprawnym kodzie odpowiedzi — wtedy trzeba sprawdzać także treść, a nie sam status. Warto z góry ustalić, co przepływ ma zrobić z odpowiedzią, której nie rozumie: przerwać i zgłosić, nie iść dalej.
Ograniczenia częstotliwości
Większość interfejsów je stosuje. Przekroczenie kończy się odrzucaniem zapytań, zwykle w najbardziej ruchliwym momencie. Rozwiązaniem jest pobieranie danych partiami i odstęp między zapytaniami, a przy odpowiedzi o przeciążeniu — ponowienie z rosnącą przerwą. Sposób reagowania opisuje tekst o obsłudze błędów w przepływach.
Zmiany po stronie systemu
Interfejs zmieniony bez uprzedzenia zatrzymuje przepływ. Powiadomienie o błędach jest tu obowiązkowe, bo nikt nie poinformuje firmy z wyprzedzeniem. Jeśli interfejs ma wersjonowanie, warto wskazywać wersję wprost — wtedy zmiana nie wchodzi sama z dnia na dzień.
Dokumentowanie
Co wywołujemy, po co i jakie dane przekazujemy. Bez tego po jakimś czasie nikt nie odtworzy działania przepływu, zwłaszcza gdy autor już w firmie nie pracuje. Wystarczy notatka przy przepływie: nazwa operacji, skąd pochodzi dokumentacja, jakie pola są obowiązkowe, co oznaczają nietypowe odpowiedzi.
Kiedy lepiej odpuścić
Gdy system nie ma udokumentowanego interfejsu i pozostaje sięganie wprost do bazy danych. To działa do pierwszej aktualizacji programu i potrafi uszkodzić dane. Wtedy lepszą drogą jest wymiana plikami albo rozwiązanie po stronie samego systemu.
Drugi taki przypadek to interfejs wymagający wielu następujących po sobie zapytań na jedną sprawę: zaloguj, pobierz listę, pobierz szczegóły, zapisz, potwierdź. W schemacie przepływu robi się z tego długi ciąg kroków, które kosztują przy każdym uruchomieniu i trudno je czytać. Takie zadanie lepiej wykonać po stronie systemu i zwrócić platformie gotowy wynik.
