01
Kiedy API jest pierwszym wyborem
API komunikuje się z logiką systemu bez udawania użytkownika. Zwykle lepiej obsługuje walidację, uprawnienia, duże wolumeny i informację o błędzie. Jest dobrym wyborem, jeśli producent gwarantuje dokumentację, wersjonowanie oraz rozsądne limity.
Przed projektem trzeba sprawdzić, czy API obejmuje dokładnie wymagane operacje. Sam fakt posiadania API nie oznacza możliwości zapisu wszystkich danych ani uruchomienia każdego procesu.
02
Gdzie RPA może być rozsądne
Robot wykonujący kroki w interfejsie bywa użyteczny w starszym systemie bez API, przy małym lub średnim wolumenie i stabilnym ekranie. Może też pomóc w krótkim okresie przejściowym przed wymianą systemu.
RPA jest bardziej podatne na zmianę układu, komunikat, opóźnienie albo dodatkowe okno. Dlatego wymaga monitorowania, kontrolowanych kont, bezpiecznego przechowywania danych dostępowych i procedury ręcznego przejęcia.
03
Nie tylko API i robot
W praktyce dobrą integracją może być również kontrolowana wymiana plików, webhook, kolejka zdarzeń lub dostępny moduł integracyjny. Wybór powinien wynikać z częstotliwości, wymaganego czasu reakcji, krytyczności danych i możliwości obu systemów.
- sposób identyfikacji tej samej sprawy;
- ochrona przed ponownym wykonaniem;
- kolejność zdarzeń i opóźnienia;
- rejestrowanie błędów bez ujawniania danych;
- uzgodnienie danych po awarii.
04
Kryteria decyzji
Porównaj koszt budowy i trzyletniego utrzymania, zależność od zmian dostawcy, bezpieczeństwo, skalę, dostępność wsparcia oraz czas potrzebny na naprawę.
Najtańszy prototyp może być najdroższym rozwiązaniem operacyjnym. Krytyczne procesy wymagają obserwowalności, testów i jasnej odpowiedzialności niezależnie od wybranej technologii.
ŹRÓDŁA
Sprawdzone materiały źródłowe
Stan informacji zweryfikowano w dniu publikacji. W sprawach prawnych zakres obowiązków zawsze należy odnieść do konkretnej organizacji i zastosowania.