Przejdź do głównej zawartości

Eventy i webhooki

Comers Events pozwala systemom zewnętrznym reagować na obsługiwane zdarzenia biznesowe bez konieczności tworzenia natywnego konektora do każdej aplikacji.

Zarejestrowany webhook może odbierać wybrane eventy Comers i przekazywać je do platformy automatyzacji, usługi integracyjnej albo innego systemu, który ma kontynuować proces.

flowchart TD
    C[Zdarzenie biznesowe w Comers] --> E[Comers Event]
    E --> S[Subskrypcja eventów]
    S --> W[Dostarczenie webhooka]
    W --> A[Automatyzacja lub integracja]
    A --> X[System zewnętrzny]

Event reprezentuje zdarzenie, które nastąpiło w jednym z obszarów biznesowych Comers.

Zależnie od aktualnie dostępnego katalogu eventy mogą dotyczyć między innymi Zamówień, Wysyłki, Wiadomości, Produktów, zapasu, Support lub innych obszarów operacyjnych.

Katalog określa, które eventy można subskrybować. Nie należy zakładać, że każda zmiana w każdym module jest udostępniana jako event.

Subskrypcja łączy wybrane obsługiwane eventy z zewnętrznym miejscem docelowym.

Dzięki temu różne workflowy i systemy mogą niezależnie subskrybować tylko te zdarzenia, których potrzebują.

Przykładowo jeden workflow może reagować na event Support, a drugi na event Wysyłki bez konieczności współdzielenia tego samego odbiorcy i cyklu życia subskrypcji.

Dostarczanie webhooków jest zaprojektowane dla realnych integracji operacyjnych, a nie wyłącznie jako powiadomienie typu best effort.

Tymczasowa awaria odbiorcy może spowodować ponowienie dostarczenia. Jeżeli webhooka nie uda się dostarczyć po obsługiwanym procesie ponowień, nieudane dostarczenie może pozostać dostępne do analizy lub ponownego odtworzenia zgodnie z dostępnymi narzędziami integracyjnymi.

Ponieważ mechanizm toleruje ponowienia i replay, odbiorca powinien traktować eventy jako dostarczane co najmniej raz. Workflow powinien więc zachowywać się poprawnie również wtedy, gdy ten sam event biznesowy zostanie odebrany więcej niż raz.

Jeżeli envelope eventu udostępnia stabilny identyfikator zdarzenia, używaj go do deduplikacji tam, gdzie jest ona potrzebna.

Odbiorca webhooka powinien weryfikować, czy dostarczenie rzeczywiście pochodzi z zaufanej instalacji Comers.

Comers udostępnia podpisane dostarczenia eventów dla integracji obsługujących weryfikację. Konkretny mechanizm weryfikacji należy do kontraktu integracyjnego i powinien być obsługiwany przez konektor lub aplikację odbierającą.

Nie umieszczaj sekretów weryfikacyjnych ani danych dostępowych w notatkach workflow, zrzutach ekranu, kodzie źródłowym ani zwykłej dokumentacji.

Eventy i webhooki są przydatne, gdy inny system powinien zareagować po zdarzeniu w Comers.

Typowe zastosowania to:

  • uruchomienie zewnętrznej automatyzacji po obsługiwanym evencie Zamówienia,
  • przekazanie wybranych zdarzeń operacyjnych do innego systemu biznesowego,
  • uruchamianie powiadomień lub wewnętrznych workflowów,
  • wzbogacanie eventu danymi z innej aplikacji,
  • połączenie Comers z dedykowaną integracją klienta.

Webhook jest wyzwalaczem. Dalsze działanie należy do odbierającego workflow lub aplikacji.

Integracje natywne i webhooki rozwiązują inne problemy

Dział zatytułowany „Integracje natywne i webhooki rozwiązują inne problemy”

Webhook nie zastępuje natywnej integracji z marketplace’em.

Integracje natywne są właściwe tam, gdzie Comers potrzebuje głębokiego zachowania specyficznego dla dostawcy, synchronizacji albo pełnego procesu operacyjnego.

Eventy i webhooki lepiej nadają się do rozszerzania Comers o szerszy ekosystem klienta.

flowchart TD
    N[Potrzeba połączenia z systemem zewnętrznym] --> Q{Potrzebne głębokie zachowanie specyficzne dla dostawcy?}
    Q -->|Tak| I[Integracja natywna]
    Q -->|Nie| E[Eventy / webhooki / automatyzacja]
    I --> C[Model operacyjny Comers]
    E --> C

Eventy webhooków mogą być odbierane przez platformy automatyzacji, które kontynuują proces w innych aplikacjach.

Comers ma dedykowaną integrację z n8n do odbierania Comers Events w workflowach n8n.

Szerszy model opisuje strona Integracje.