CRM wysyła zamówienie z własnym identyfikatorem, a integracja przekazuje je do ERP. Dokument i rezerwacja powstają, lecz odpowiedź nie dociera do systemu źródłowego. Po piętnastu sekundach CRM ponawia operację. Drugie wywołanie może utworzyć dubel, jeżeli aplikacja nie rozpozna tego samego klucza idempotencji. Na prywatnych serwerach G2E integrator może uruchomić środowisko wykonawcze, rejestr operacji, bufor wiadomości i logi integracji; znaczenie klucza oraz sposób zapisu pozostają częścią jej logiki.
Pierwsza próba kończy się w ERP
Po odebraniu komunikatu integracja zapisuje identyfikator, źródło i czas, a następnie przekazuje dane do ERP. Rejestr operacji wiąże klucz idempotencji z przebiegiem żądania i numerem utworzonego dokumentu. Sam ERP pozostaje źródłem informacji o zamówieniu, rezerwacji i skutkach księgowych.
Prywatna sieć może łączyć systemy klienta z serwerami wirtualnymi G2E, na których integrator uruchamia środowisko wykonawcze, rejestr, bufor i logi. Konta techniczne otrzymują dostęp tylko do potrzebnych usług. Konfigurację połączeń, bazy rejestru oraz reguł aplikacyjnych przygotowuje integrator zgodnie z architekturą ERP i CRM.
Piętnaście sekund bez odpowiedzi
Brak odpowiedzi mówi o komunikacji między systemami, a nie o skutku biznesowym. ERP mógł już zatwierdzić dokument, podczas gdy wiadomość zwrotna zaginęła albo wraca z opóźnieniem. Uznanie każdej ciszy za nieudaną operację usuwa rozróżnienie najważniejsze dla ochrony przed duplikatem.
Pierwsze wywołanie zapisuje pod kluczem status oraz numer dokumentu, gdy jest dostępny. Drugie z tym samym kluczem odczytuje wcześniejszy zapis i nie rozpoczyna ponownie tworzenia zamówienia. Ograniczenie unikalności, atomowy zapis i obsługa równoległych żądań należą do aplikacji oraz używanej przez nią bazy.
Najtrudniejsza luka pojawia się między odczytem klucza a zatwierdzeniem dokumentu. Dwa żądania mogą w tym samym czasie zobaczyć brak wcześniejszej operacji. Sama prywatna infrastruktura nie rozstrzyga tego wyścigu; integracja potrzebuje reguły, która dopuści jeden zapis i skieruje drugi do już istniejącego rezultatu.
Log zachowuje oba komunikaty. Podstawą powiązania jest ten sam identyfikator operacji, nie podobna godzina ani kwota. Późniejsze wyjaśnienie nie wymaga więc zgadywania, czy dwa zamówienia dotyczą jednego zakupu.
Ponowienie używa tego samego klucza
CRM wysyła drugą wiadomość z identyfikatorem pierwszej operacji. Rejestr znajduje numer dokumentu ERP i zwraca go do systemu źródłowego. W ERP pozostaje jedno zamówienie i jedna rezerwacja, a w logu dwa techniczne wywołania odnoszące się do tego samego skutku biznesowego.
Inny przebieg dotyczy operacji bez dokumentu. Gdy źródła jednoznacznie pokazują błąd przejściowy i brak zapisu w ERP, wiadomość można przetworzyć ponownie zgodnie z regułą aplikacji. Brak kontrahenta, niezgodna waluta albo częściowy zapis wymagają zatrzymania, ponieważ automatyczne ponowienie nie powinno rozstrzygać niejasnego skutku.
Monitoring infrastruktury może pokazać przerwane połączenie, zatrzymany proces lub rosnącą liczbę oczekujących wiadomości. Dopiero zestawienie tych sygnałów z rejestrem i dokumentami ERP odpowiada na pytanie, które operacje są zakończone, które można wznowić, a które wymagają wyjaśnienia.
Przywrócenie wymaga zgodności zapisów
Restart procesu integracji nie może wymazać wiedzy o wcześniej obsłużonych zamówieniach. Po odtworzeniu trzeba sprawdzić, czy dokumenty ERP zapisane w SQL zgadzają się z rejestrem operacji oraz statusem wiadomości w buforze i logach. Uruchomienie samego procesu bez jego historii otwiera drogę do ponownego utworzenia dokumentów.
W standardzie G2E kopia VM jest wykonywana co 24 godziny i pozostaje dostępna przez 3 dni. Nie oznacza to automatycznej zgodności transakcyjnej kilku osobnych komponentów ani wiedzy o zamówieniach utworzonych po danym momencie wykonania kopii.
Przed wznowieniem ruchu ustala się moment, z którego pochodzą stany ERP i bazy SQL, rejestru, logów oraz bufora. Następnie porównuje się klucze operacji z dokumentami ERP. Istniejący dokument zamyka drogę do kolejnego zapisu, jednoznacznie odrzucona wiadomość może zostać obsłużona ponownie, a niejasna pozostaje wstrzymana do wyjaśnienia.
Kolejność uruchamiania i reguły uwalniania wiadomości wynikają z architektury aplikacji. G2E dostarcza serwery, prywatną sieć oraz kopie VM. Backup maszyny nie zastępuje powiązania klucza z dokumentem ani kontroli stanu bazy po przywróceniu.
Jeden dokument po dwóch wywołaniach
Najważniejszy przypadek odbioru jest prosty do opisania: ERP zapisuje zamówienie, odpowiedź nie wraca do CRM, a po piętnastu sekundach pojawia się drugie wywołanie z tym samym kluczem. Rejestr zwraca numer istniejącego dokumentu, więc sprzedaż i księgowość nie dostają dubla do ręcznej korekty.
W logu powinny pozostać dwa czasy przyjęcia oraz jeden numer dokumentu ERP. Taki układ pokazuje, że ponowienie rzeczywiście dotyczyło wcześniejszej operacji, a mechanizm nie ukrył drugiego komunikatu ani nie stworzył kolejnego skutku biznesowego.
Osobno ocenia się wiadomość bez dokumentu oraz operację o niejasnym skutku. Pierwsza może wrócić do obsługi po spełnieniu reguły, druga czeka na wyjaśnienie. Dobra idempotencja nie usuwa ponowień z komunikacji; sprawia, że dwa wywołania tej samej operacji kończą się jednym dokumentem biznesowym.