Zamiast pytać co pięć minut „czy jest coś nowego", można poprosić partnera, żeby sam się odezwał. To oszczędza zasobów i skraca opóźnienie.
Podajemy partnerowi adres, pod który ma wysyłać informacje o zdarzeniach. Nowe zamówienie, zmiana statusu przesyłki, zaksięgowana płatność — trafiają do nas natychmiast po wystąpieniu.
Po naszej stronie potrzebny jest adres dostępny z internetu, działający bez przerwy i zabezpieczony certyfikatem. To pierwsza rzecz do sprawdzenia: firma, której system stoi na komputerze w biurze i bywa wyłączany, powiadomień po prostu nie odbierze.
Do uruchomienia powiadomień potrzebny jest adres widoczny z internetu, konto u partnera z prawem do jego skonfigurowania oraz miejsce na zapis przyjętych zgłoszeń. Przydaje się też możliwość podejrzenia surowej treści powiadomienia — przy sporze o to, co partner faktycznie przysłał, jest to jedyny rozstrzygający dowód. Warto z góry ustalić, jak długo takie zapisy przechowujemy i kto ma do nich dostęp, bo trafiają tam dane klientów.
Po stronie organizacyjnej trzeba wskazać osobę, która dostaje informację o zgłoszeniach odrzuconych. Powiadomienie przyjęte i nieprzetworzone jest gorsze od nieodebranego: partner ma potwierdzenie, więc go nie powtórzy.
Odpowiedź musi być szybka i mówić wyłącznie, że przyjęliśmy zgłoszenie. Przetwarzanie należy wykonać później, bo partner zwykle czeka krótko i przy braku odpowiedzi ponawia wysyłkę.
Praktyczny układ jest taki: zapisujemy zgłoszenie, odpowiadamy potwierdzeniem, a właściwą pracę zlecamy kolejce. Przetwarzanie w trakcie odpowiedzi kończy się tym, że wolniejsza baza albo dłuższe wyliczenie powodują przekroczenie czasu i ponowną wysyłkę tego samego zdarzenia.
Awaria naszego serwera, chwilowy brak łącza, błąd w kodzie — powiadomienie przepada. Dlatego samo poleganie na powiadomieniach jest ryzykowne.
Powiadomienia dla szybkości, uzupełnione cyklicznym odpytywaniem jako siatka bezpieczeństwa. Odpytywanie może być rzadkie — wyłapuje wyłącznie to, co przepadło.
Zasada działania jest tu taka sama jak przy zwykłej wymianie zapytanie–odpowiedź: pobieramy zdarzenia z ostatniego okresu i porównujemy z tym, co już mamy. Nadmiarowe pozycje odpadną przy rozpoznawaniu duplikatów.
Adres przyjmujący powiadomienia jest dostępny publicznie. Bez sprawdzenia podpisu żądania każdy może wysłać fałszywe zdarzenie — na przykład o opłaceniu zamówienia.
Sam podpis nie wystarcza przy operacjach dotyczących pieniędzy. Powiadomienie mówi, że coś się wydarzyło; kwotę i status transakcji warto potwierdzić dodatkowym zapytaniem do partnera, zanim towar pojedzie.
Partnerzy ponawiają wysyłkę przy braku potwierdzenia, więc to samo zdarzenie potrafi przyjść kilka razy. Rozpoznawanie duplikatów po identyfikatorze zdarzenia jest konieczne.
Zdarzenia potrafią też przyjść w innej kolejności, niż powstały. Informacja o wysyłce odebrana przed informacją o przyjęciu zamówienia nie powinna cofać jego stanu — decyduje znacznik czasu zdarzenia, a nie moment odbioru.
Przy niewielkiej liczbie zdarzeń dziennie i tolerancji na kilkunastominutowe opóźnienie odpytywanie w zupełności wystarcza i jest prostsze w utrzymaniu. Powiadomienia wymagają publicznego adresu, obsługi podpisu oraz nadzoru nad tym, czy w ogóle przychodzą — cisza wygląda tu identycznie jak brak zdarzeń.