Integracja to nie pojedynczy eksport pliku, tylko umowa między systemami: jakie zdarzenia idą w któją stronę, jak obsługujemy błędy i ponowienia. Projektujemy API tak, by dało się je rozszerzać w kolejnych etapach wdrożenia.
Problem
Integracja to nie pojedynczy eksport pliku, tylko umowa między systemami: jakie zdarzenia idą w któją stronę, jak obsługujemy błędy i ponowienia. Projektujemy API tak, by dało się je rozszerzać w kolejnych etapach wdrożenia.
Rozwiązanie
Ustalamy zdarzenia (cena zaktualizowana, zamówienie utworzone), format payloadu, kody błędów i politykę ponowień. Wersjonujemy kontrakt tak, żeby zmiana po stronie ERP nie wyłączała portalu B2B w środku dnia — środowisko testowe i monitoring to must-have, nie dodatek.
Dowód
W projektach z SAP i lokalnymi ERP-ami największe opóźnienia wynikają z braku opisanego kontraktu API — nie z samego kodowania. Filar integracji CPQ z ERP i case studies pokazują fazowy model wdrożenia.
Integracja to nie jednorazowy „patch” — to umowa między systemami: co jest źródłem prawdy, jak często synchronizujemy dane i kto reaguje na błąd. Dlatego przed kodem jest architektura i testy na danych produkcyjnych.
Przykłady
Część integracji opiera się na standardowych wzorcach dla danego ERP; warstwa domenowa (mapowanie pól) zawsze jest dopasowywana do klienta.
Stosujemy strategie kolejki, retry i komunikatów dla użytkownika — szczegóły uzgadniamy w fazie NFR.
Kontynuuj temat
Zacznij od checklisty procesu, sprawdź narzędzie na stronie albo napisz — opiszę, czy temat ma sens w Twojej sytuacji.