← Blog / Integracja SAP i Salesforce

Integracja zdarzeniowa SAP i Salesforce: kiedy ma sens

Opublikowano: 9 września 2026

Klient zmienia adres w Salesforce o dziesiątej rano, a SAP dowiaduje się o tym z nocnego przebiegu wsadowego, więc faktura wystawiona po południu idzie pod stary adres. Stan magazynu zmienia się w SAP co kilka minut, a handlowiec w Salesforce widzi liczbę z wczoraj. Oba problemy mają tę samą przyczynę: system, w którym coś się zmieniło, nikomu o tym nie mówi, a pozostałe systemy pytają wtedy, gdy im wygodnie. Integracja zdarzeniowa odwraca ten układ. System źródłowy ogłasza zmianę w chwili, gdy zachodzi, a zainteresowani reagują. SAP i Salesforce mają do tego dojrzałe mechanizmy, ale każdy z nich ma limity, które w prezentacjach nie padają, i sytuacje, w których zwykłe wywołanie API jest po prostu lepsze.

Czym zdarzenie różni się od wywołania

W integracji przez API system pytający czeka na odpowiedź: Salesforce pyta SAP o cenę i nie ruszy dalej, dopóki jej nie dostanie. W integracji zdarzeniowej S/4HANA publikuje komunikat „partner biznesowy 1000667 zmieniony” do brokera, a każdy system, który się na ten typ zdarzenia zapisał, odbiera go we własnym tempie. Nadawca nie wie, ilu ma odbiorców, i nie czeka na żadnego z nich.

Obaj dostawcy podają ten sam warunek użycia. Salesforce w przewodniku dla architektów pisze, że architektura zdarzeniowa nadaje się do procesów, które nie wymagają synchronicznej odpowiedzi, a każda integracja, w której człowiek czeka na wynik, jest dla niej złym kandydatem. SAP w metodyce ISA-M klasyfikuje integrację zdarzeniową jako wzorzec przekrojowy służący do rozprzęgania aplikacji przez zasadę publikuj i subskrybuj, z przykładem dokładnie z naszego otwarcia: powiadomić zdalne systemy o danych klienta utworzonych, zmienionych albo usuniętych w S/4HANA.

Co oferuje SAP

S/4HANA ma wbudowany komponent Enterprise Event Enablement, który wysyła zdarzenia biznesowe do SAP Event Mesh, SAP Cloud Application Event Hub albo Advanced Event Mesh. Zdarzenia są zgodne ze specyfikacją CloudEvents, otwartym standardem prowadzonym przez CNCF, więc odbiorca spoza SAP rozumie ich strukturę bez własnego parsera. Nazwa zdarzenia mówi, co się stało, na przykład sap.s4.beh.businesspartner.v1.BusinessPartner.Changed.v1.

Jedna cecha tych zdarzeń zaskakuje zespoły przy pierwszym projekcie. Ładunek zdarzenia o zmianie partnera biznesowego zawiera wyłącznie jego numer. To zdarzenie powiadamiające: SAP opisuje, że takie zdarzenia są możliwie małe, a odbiorca dociąga resztę danych osobnym wywołaniem API, w odróżnieniu od zdarzeń z danymi, które niosą pełny rekord. Standardowe zdarzenia S/4HANA są w większości powiadamiające, więc integracja zdarzeniowa z SAP prawie zawsze oznacza dwa kroki: odbiór zdarzenia i wywołanie API po dane. Według przeglądu SAP z 2024 roku S/4HANA i S/4HANA Cloud udostępniają łącznie ponad 600 zdarzeń z 17 obszarów.

Do przesyłania zdarzeń SAP ma dwa produkty, które łatwo pomylić. SAP Event Mesh jest prostszym brokerem z twardymi limitami: komunikat do 1 MB, przepustowość 250 KB/s na subkonto, przestrzeń na komunikaty domyślnie 2000 MB, maksymalnie 4000 MB. Jako zdolność jest wliczony w SAP Integration Suite. SAP Integration Suite, advanced event mesh to osobna platforma do strumieniowania, zarządzania i monitorowania zdarzeń, oparta na technologii Solace, z protokołami AMQP, MQTT, REST i natywnym Solace, rozliczana osobno za godzinę pracy brokera. SAP publikuje przewodnik migracji z Event Mesh do advanced event mesh, co wskazuje kierunek, choć żadna strona nie nazywa jednego z produktów strategicznym. Dla większości integracji SAP z Salesforce wliczony Event Mesh wystarcza. Advanced event mesh ma sens, gdy zdarzenia z zakładów, maszyn i systemów spoza SAP mają płynąć przez jedną sieć brokerów, a wolumen liczy się w milionach dziennie.

Co oferuje Salesforce

Po stronie Salesforce są dwa rodzaje zdarzeń. Platform Events to komunikaty definiowane przez klienta, publikowane z procesów, kodu lub z zewnątrz. Change Data Capture publikuje zdarzenia o utworzeniu, zmianie, usunięciu i przywróceniu rekordów wybranych obiektów bez pisania czegokolwiek, co dla synchronizacji klientów, kontaktów i zamówień do SAP jest najkrótszą drogą. Zewnętrzne systemy odbierają oba rodzaje przez Pub/Sub API oparte na gRPC i formacie Avro.

Limity trzeba znać przed projektem. Salesforce przechowuje zdarzenia przez 72 godziny i w tym oknie odbiorca może je odtworzyć od zapamiętanego punktu. Odbiorca niedostępny dłużej, na przykład przez awarię w długi weekend, traci zdarzenia bezpowrotnie i musi zrobić pełną resynchronizację przez API. Do tego dochodzą przydziały: domyślnie 50 000 dostarczonych zdarzeń na 24 godziny w edycjach Performance i Unlimited oraz 25 000 w Enterprise, 250 000 publikacji na godzinę, komunikat do 1 MB, a przydział dostarczeń jest wspólny dla Platform Events i Change Data Capture i można go zwiększyć płatnym dodatkiem. Włączenie Change Data Capture na obiekcie o dużym ruchu, na przykład na pozycjach zamówień, potrafi zużyć dzienny przydział przed południem.

Zdarzenie z SAP i tak kończy się wywołaniem API, więc obowiązują też jego limity i zasady, o których pisaliśmy we wpisie o strategii API.

Jak to spiąć w praktyce

Typowy przepływ z SAP do Salesforce wygląda tak: S/4HANA publikuje zdarzenie o zmianie partnera biznesowego do Event Mesh, przepływ w Cloud Integration odbiera je, wywołuje API partnera biznesowego po pełne dane i zapisuje zmianę w Salesforce. W drugą stronę Change Data Capture na obiekcie Account trafia do adaptera Pub/Sub w Cloud Integration, który jest częścią standardowego wyposażenia Integration Suite, a przepływ aktualizuje partnera w SAP.

Ten opis pomija to, co zajmuje najwięcej czasu w projekcie: obsługę zdarzeń, których nie da się przetworzyć wprost. Zdarzenie o zmianie klienta może dotrzeć przed zdarzeniem o jego utworzeniu. To samo zdarzenie może przyjść dwa razy po restarcie brokera albo po odtworzeniu z punktu zapisu. Wywołanie API po dane może się nie powieść, gdy SAP jest w oknie serwisowym, i wtedy zdarzenie trzeba odłożyć, a nie zgubić.

Zespoły radzą sobie z tym kilkoma nawykami, które warto przyjąć od pierwszego przepływu. Odbiorca zapisuje w Salesforce nie po identyfikatorze zdarzenia, tylko po kluczu biznesowym, na przykład numerze partnera, jako operację wstaw albo aktualizuj, dzięki czemu duplikat zdarzenia nadpisuje rekord tymi samymi danymi i nie robi szkody. Znacznik czasu zdarzenia porównuje się z czasem ostatniej zmiany rekordu w systemie docelowym i zdarzenie starsze od rekordu jest odrzucane, co rozwiązuje problem kolejności bez gwarancji brokera. Identyfikatory przetworzonych zdarzeń trzyma się przez kilka dni w magazynie danych przepływu, a zdarzenia, dla których wywołanie API zawiodło, trafiają do osobnej kolejki z ponowieniem, którą ktoś ogląda. Żadna z tych rzeczy nie jest skomplikowana, ale każdą trzeba zaprojektować, a w integracji wsadowej żadnej nie było.

Kiedy zdarzenia się opłacają, a kiedy nie

Zdarzenia opłacają się, gdy jedną zmianę konsumuje kilka systemów: stan magazynu z SAP potrzebny jednocześnie w sklepie internetowym, w Salesforce i w systemie kurierskim, jak w integracji omnichannel w handlu. Zamiast trzech interfejsów odpytujących SAP powstaje jedno zdarzenie i trzech odbiorców, a dodanie czwartego nie dotyka SAP. Opłacają się też tam, gdzie ruch jest nierówny: zamknięcie miesiąca generuje tysiące zmian w godzinę, a broker je buforuje, zamiast zalewać Salesforce wywołaniami.

Nie opłacają się, gdy ktoś czeka. Sprawdzenie ceny i dostępności w ofercie musi być wywołaniem synchronicznym, bo handlowiec patrzy na ekran. Nie opłacają się także, gdy odbiorca i tak potrzebuje pełnego rekordu, a jest tylko jeden: zdarzenie powiadamiające plus wywołanie API to dwa kroki tam, gdzie codzienna replikacja przez API wystarczyłaby w jednym. Nie opłacają się też w zespole, który nie ma kto obsługiwać kolejki błędów, bo zdarzenia, których nikt nie ogląda, są gorsze niż wsad, o którym przynajmniej wiadomo, że nie poszedł.

Ile z interfejsów w Twojej firmie kwalifikuje się do modelu zdarzeniowego, wychodzi dopiero po ich przejrzeniu. W projektach, które znamy, było to zwykle mniej niż połowa, a największy zysk dawało kilka zdarzeń o danych podstawowych, na które czekało najwięcej systemów.

FAQ

#Integracja zdarzeniowa #Event Mesh #Salesforce #SAP BTP #Architektura