Droga zamówienia przez system¶
Opis kompletnej ścieżki jednego zamówienia — od momentu złożenia przez klienta w Rainbow do pojawienia się na serwerze analitycznym z poprawnie przypisanym klientem.
Skrócony widok¶
flowchart LR
RB["Rainbow\n(sklep)"]
SC["Scanner"]
S1["Stage1\nidentyfikacja"]
S2["Stage2\ndeduplikacja"]
AS["AnalyticsSync"]
AN["Serwer\nanalityczny"]
RB -->|"zamówienie"| SC
SC -->|"osoba\nz zamówienia"| S1
S1 -->|"profil klienta\ndo weryfikacji"| S2
S2 -->|"wynik\ndeduplikacji"| AS
AS --> ANKrok 1 — Zamówienie trafia do bazy wymiany danych¶
Punktem styku między Rainbow a Deduplikatorem jest wspólna baza wymiany danych. Rainbow zapisuje do niej dane zamówień; Deduplikator je z niej odczytuje.
Z perspektywy Deduplikatora ta baza to po prostu skrzynka wejściowa: system obserwuje ją i reaguje na to, co się w niej pojawi. Interesują go dane osób powiązanych z zamówieniem — imię, nazwisko, płeć, data urodzenia, a często też adres e-mail, numer telefonu lub adres dostawy.
Deduplikator niczego nie zmienia po stronie Rainbow — bazę wymiany danych czyta wyłącznie w trybie odczytu.
Krok 2 — Scanner wykrywa zmianę¶
Co kilka sekund Scanner sprawdza, czy pojawiły się zamówienia nowe lub zmienione od ostatniego sprawdzenia. Interesują go tylko zamówienia zakończone sprzedażą — anulowane i w trakcie realizacji są pomijane.
Gdy Scanner znajdzie nowe zamówienie, wyciąga z niego każdą osobę (zamawiający, płatnik) i przekazuje ją dalej do przetworzenia. Jeśli zamówienie zostało zmodyfikowane (np. zmiana adresu), Scanner przetworzy je ponownie.
Scanner zapamiętuje, jak daleko zaszedł — w razie restartu wznawia od miejsca, w którym skończył.
Krok 3 — Stage1: porządkowanie danych i identyfikacja¶
Stage1 odbiera dane osoby i decyduje, co z nią zrobić.
Porządkowanie danych (normalizacja) — dane z zamówień rzadko są jednolite. Stage1 je ujednolica: sprowadza imiona do wspólnej formy (rozpoznaje zdrobnienia), usuwa przedrostki z nazw ulic, formatuje numery telefonów według standardu krajowego, porządkuje adresy e-mail.
Filtrowanie — jeśli brakuje któregoś z czterech kluczowych pól (imię, nazwisko, płeć, data urodzenia), osoba jest pomijana. Nie da się deduplikować kogoś, kogo nie można zidentyfikować.
Decyzja — Stage1 sprawdza, czy ta osoba z tego zamówienia była już wcześniej widziana:
| Sytuacja | Co robi Stage1 |
|---|---|
| Nowa osoba | Tworzy profil klienta, przekazuje do Stage2 |
| Znana, dane bez zmian | Kończy — nic do zrobienia |
| Znana, dane się zmieniły | Zapisuje nowe dane, przekazuje do Stage2 |
Stage1 celowo nie scala profili — może tworzyć duplikaty. To zadanie Stage2.
Krok 4 — Stage2: deduplikacja¶
Stage2 obsługuje dwa przypadki: nowy profil klienta (pierwsze pojawienie się osoby w systemie) oraz aktualizację istniejącego (dane w zamówieniu się zmieniły). W obu cel jest ten sam — sprawdzić, czy ten klient nie figuruje już w bazie pod innym profilem.
Nowy profil — Stage2 przejmuje świeżo utworzony profil i od razu przechodzi do wyszukiwania duplikatów.
Aktualizacja istniejącego profilu — Stage2 najpierw odświeża dane klienta na podstawie najnowszych danych z zamówienia. Kontakty (e-mail, telefon) są dołączane do historii — nie zastępują poprzednich. Dane podstawowe i adres są nadpisywane. Jeśli klient jest powiązany z wieloma zamówieniami (bo wcześniej scalono kilka profili), Stage2 weryfikuje, czy każde z nich nadal pasuje do profilu. Zamówienie, którego dane przestały pasować, zostaje odłączone i dostaje własny nowy profil — który trafi do Stage2 jako osobny przebieg. Jeśli po odłączeniu nie zostaje żadne zamówienie, profil jest usuwany.
Wyszukiwanie duplikatów¶
Jeśli klient jest powiązany z kontem w systemie LDE, Stage2 najpierw szuka w bazie innego klienta z tym samym identyfikatorem LDE. Trafienie oznacza automatyczne scalenie z najwyższą możliwą pewnością — ten sam identyfikator LDE to ta sama osoba, bez wątpliwości.
W pozostałych przypadkach Stage2 przechodzi do dopasowania na podstawie danych osobowych. Zamiast porównywać klienta ze wszystkimi innymi, najpierw zawęża poszukiwania do osób o podobnie brzmiącym imieniu i nazwisku, tej samej płci i roku urodzenia — i bierze pod uwagę do 50 najbardziej podobnych kandydatów.
Każdy kandydat jest następnie porównywany szczegółowo według zestawu reguł (szczegóły w rozdziale Algorytmy):
| Wynik | Co się dzieje |
|---|---|
| Ta sama osoba — pewne | Automatyczne scalenie |
| Prawdopodobnie ta sama — z rozbieżnościami | Scalenie, ale z oznaczeniem do weryfikacji przez operatora |
| Różne osoby | Brak działania |
Jeśli znaleziono dopasowanie, Stage2 tworzy nowy scalony profil klienta, przenosi na niego wszystkie zamówienia i usuwa stare profile. Na koniec przekazuje dalej informację o wyniku — który identyfikator klienta ostatecznie przypisano.
Krok 5 — AnalyticsSync: zapis na serwerze analitycznym¶
AnalyticsSync nasłuchuje na wyniki z Stage2. Gdy dostaje potwierdzenie zakończonej deduplikacji, aktualizuje rekord zamówienia na serwerze analitycznym — wpisuje identyfikator osoby, który łączy zamówienie z profilem klienta.
Równolegle AnalyticsSync kopiuje na serwer analityczny pełne dane zamówienia (dane produktowe, kwoty, daty itp.).
Dopiero w tym momencie zamówienie jest kompletne na serwerze analitycznym — ma dane zamówienia i wie, kto je złożył, w ujednolicony, zdeduplikowany sposób. To umożliwia raportowanie powracalności klientów.
Zamówienie anulowane¶
Scanner wychwytuje nie tylko nowe zamówienia, ale też zmiany statusu istniejących — w tym anulowanie.
Obsługa anulowania zamówień¶
Każdy profil klienta istnieje tylko dlatego, że są do niego przypisane zamówienia. Gdy ostatnie zamówienie znika — czy to przez pełne anulowanie, czy przez usunięcie osoby z zamówienia grupowego — profil traci rację bytu i jest usuwany. Informacja o anulowaniu trafia do systemu analitycznego, aby mógł on usunąć zamówienie ze swoich danych.
Profil klienta istnieje wyłącznie dzięki zamówieniom — brak powiązań oznacza usunięcie¶
Deduplikator nie przechowuje klientów na zapas. Profil powstaje, kiedy zamówienie wchodzi do systemu, i znika, kiedy ostatnie zamówienie zostaje anulowane lub odpięte. Jeśli klient kupił dwa razy i pierwsze zamówienie zostaje anulowane — profil pozostaje, bo drugie nadal istnieje. Dopiero gdy nie ma już żadnego zamówienia — profil jest usuwany.
Scenariusz: Anulowanie całego zamówienia usuwa klienta z bazy i triggeruje sync Analytics
Zakładając że w bazie istnieje przetworzone zamówienie "1001" z klientem:
| Imię | Nazwisko | Data urodzenia | Płeć |
|---|---|---|---|
| Jan | Kowalski | 1985-03-15 | M |
Gdy przetworzę zamówienie "1001" jako anulowane
Wtedy klient "Jan Kowalski" nie powinien istnieć w bazie
I powiązania zamówienia "1001" nie powinny istnieć
I usunięcie zamówienia "1001" powinno być zakolejkowane w outboxie
Scenariusz: Anulowanie zamówienia nie usuwa klienta który ma inne aktywne zamówienie
Zakładając że klient Jan Kowalski jest powiązany z zamówieniami "1003" i "1004"
Gdy przetworzę zamówienie "1003" jako anulowane
Wtedy klient "Jan Kowalski" powinien nadal istnieć w bazie
I powiązanie z zamówieniem "1003" nie powinno istnieć
I powiązanie z zamówieniem "1004" powinno nadal istnieć
W zamówieniu grupowym każda osoba jest niezależna — odpinana osobno¶
Wycieczki grupowe to zamówienie z wieloma pasażerami, każdy z własnym profilem klienta. Gdy aktualizacja zamówienia usuwa z niego jedną osobę, odpinany jest tylko jej profil. Pozostałe osoby z tego samego zamówienia pozostają niezmienione.
Scenariusz: Anulowanie jednej osoby w aktywnym zamówieniu odpina ją od klienta
Zakładając że w bazie istnieje przetworzone zamówienie "1002" z osobami:
| OrderPersonId | Imię | Nazwisko | Data urodzenia | Płeć |
|---|---|---|---|---|
| 101 | Jan | Kowalski | 1985-03-15 | M |
| 102 | Anna | Nowak | 1990-07-22 | K |
Gdy przetworzę zamówienie "1002" z aktywną listą osób: "101"
Wtedy klient "Jan Kowalski" powinien nadal istnieć w bazie
I klient "Anna Nowak" nie powinien istnieć w bazie
I powiązanie osoby "101" z zamówieniem "1002" powinno istnieć
I powiązanie osoby "102" z zamówieniem "1002" nie powinno istnieć
Zmiany danych po pierwszym przetworzeniu¶
Zamówienie może się zmieniać także po pierwszym przetworzeniu — klient koryguje dane, ktoś dołącza do wycieczki grupowej lub z niej rezygnuje.
Obsługa aktualizacji zamówień¶
Zamówienia mogą się zmieniać po pierwszym przetworzeniu — dane osobowe mogą być korygowane, osoby dopisywane lub usuwane z wycieczki grupowej, zamówienie może zostać opróżnione. Każda taka zmiana wymaga od Deduplikatora reakcji: zaktualizować, odpiąć lub usunąć to, co już nie pasuje do aktualnego stanu.
Kontekst: Zakładając że system deduplikacji jest uruchomiony
Zmiana danych na zamówieniu odpina je od klienta gdy przestają pasować¶
Profil klienta reprezentuje osobę o konkretnej tożsamości. Jeśli zamówienie przychodziło z danymi Jana Kowalskiego, ale teraz przychodzi z danymi Piotra Nowaka — to nie jest aktualizacja tego samego klienta, lecz inna osoba na tym samym zamówieniu. System odpina zamówienie od dotychczasowego klienta (który pozostaje, jeśli ma inne zamówienia) i tworzy nowy profil dla nowych danych.
Scenariusz: Update zamówienia z danymi które nie pasują do klienta - odpięcie i nowy klient
Zakładając że istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
| Status | Active |
I zamówienie "ORD-A" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P0 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
I zamówienie "ORD-B" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
Kiedy przychodzi aktualizacja zamówienia "ORD-B" z zupełnie innymi danymi:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Piotr |
| LastName | Nowak |
| Gender | M |
| BirthDate | 1985-08-20 |
Wtedy zamówienie "ORD-B" jest odpinane od klienta 1
I tworzony jest nowy klient z danymi:
| Pole | Wartość |
|---|---|
| FirstName | Piotr |
| LastName | Nowak |
I klient 1 pozostaje aktywny
Scenariusz: Kaskadowe odpięcie - zamówienie odpinane od klienta z wieloma linkami tworzy nowego klienta
Zakładając że istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
| Status | Active |
I zamówienie "ORD-A" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
I zamówienie "ORD-B" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
Kiedy przychodzi aktualizacja zamówienia "ORD-B" z zupełnie innymi danymi:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Piotr |
| LastName | Wiśniewski |
| Gender | M |
| BirthDate | 1978-08-10 |
Wtedy zamówienie "ORD-B" jest odpinane od klienta 1
I tworzony jest nowy klient z danymi:
| Pole | Wartość |
|---|---|
| FirstName | Piotr |
| LastName | Wiśniewski |
I klient 1 pozostaje aktywny
I zamówienie "ORD-A" pozostaje powiązane z klientem 1
Usunięcie osoby z zamówienia grupowego odpina tylko tę osobę¶
System wykrywa, które osoby nadal są aktywne w zamówieniu. Jeśli osoba zniknie z aktualnej listy uczestników (np. rezygnacja z wycieczki grupowej), zostaje odpięta od zamówienia. Inne osoby z tego samego zamówienia pozostają niezmienione.
Scenariusz: Zamówienie z 3 osobami aktualizowane do 2 osób - trzecia osoba odpinana
Zakładając że istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
I istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 2 |
| FirstName | Anna |
| LastName | Nowak |
| Gender | F |
| BirthDate | 1985-03-20 |
I istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 3 |
| FirstName | Piotr |
| LastName | Wiśniewski |
| Gender | M |
| BirthDate | 1978-08-10 |
I zamówienie "ORD-A" ma 3 powiązane osoby:
| OrderPersonId | CustomerId |
|---|---|
| P1 | 1 |
| P2 | 2 |
| P3 | 3 |
Kiedy przychodzi aktualizacja zamówienia "ORD-A" z tylko 2 osobami:
| OrderPersonId | FirstName | LastName | Gender | BirthDate |
|---|---|---|---|---|
| P1 | Jan | Kowalski | M | 1990-05-15 |
| P2 | Anna | Nowak | F | 1985-03-20 |
Wtedy osoba P3 jest odpinana od zamówienia "ORD-A"
I klient 3 jest usuwany jako osierocony
I klienci 1 i 2 pozostają aktywni
Scenariusz: Usunięcie osoby z zamówienia - klient ma inne zamówienia więc nie jest usuwany
Zakładając że istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
I istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 2 |
| FirstName | Piotr |
| LastName | Wiśniewski |
| Gender | M |
| BirthDate | 1978-08-10 |
| Status | Active |
I zamówienie "ORD-A" ma 2 powiązane osoby:
| OrderPersonId | CustomerId |
|---|---|
| P1 | 1 |
| P2 | 2 |
I zamówienie "ORD-B" jest powiązane z klientem 2:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Piotr |
| LastName | Wiśniewski |
| Gender | M |
| BirthDate | 1978-08-10 |
Kiedy przychodzi aktualizacja zamówienia "ORD-A" z tylko 1 osobą:
| OrderPersonId | FirstName | LastName | Gender | BirthDate |
|---|---|---|---|---|
| P1 | Jan | Kowalski | M | 1990-05-15 |
Wtedy osoba P2 jest odpinana od zamówienia "ORD-A"
I klient 2 pozostaje aktywny
Profil bez żadnego zamówienia jest natychmiast usuwany¶
Deduplikator nie gromadzi historycznych profili. Gdy zamówienie zostaje odpięte od klienta — bo dane nie pasują, bo osoba zrezygnowała z wycieczki, albo bo zamówienie zostało opróżnione — system sprawdza, czy klient nadal ma jakiekolwiek powiązanie. Nie ma? Profil jest usuwany. Ma inne zamówienia? Pozostaje.
Scenariusz: Zamówienie staje się puste - klient jest usuwany
Zakładając że istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
| Status | Active |
I zamówienie "ORD-A" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
Kiedy przychodzi aktualizacja zamówienia "ORD-A" bez osób
Wtedy zamówienie "ORD-A" jest odpinane od klienta 1
I klient 1 jest usuwany jako osierocony
Scenariusz: Klient z wieloma zamówieniami - jedno zamówienie puste - klient pozostaje
Zakładając że istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
| Status | Active |
I zamówienie "ORD-A" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
I zamówienie "ORD-B" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
Kiedy przychodzi aktualizacja zamówienia "ORD-A" bez osób
Wtedy zamówienie "ORD-A" jest odpinane od klienta 1
I klient 1 pozostaje aktywny
I klient 1 pozostaje w systemie
Scenariusz: Klient z wieloma zamówieniami - oba puste - klient usuwany
Zakładając że istnieje klient:
| Pole | Wartość |
|---|---|
| CustomerId | 1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
| Status | Active |
I zamówienie "ORD-A" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
I zamówienie "ORD-B" jest powiązane z klientem 1:
| Pole | Wartość |
|---|---|
| OrderPersonId | P1 |
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
Kiedy przychodzi aktualizacja zamówienia "ORD-A" bez osób
I przychodzi aktualizacja zamówienia "ORD-B" bez osób
Wtedy klient 1 jest usuwany jako osierocony
Odświeżanie profilu klienta przy zmianie danych zamówienia¶
Gdy dane osobowe na zamówieniu się zmieniają, system odświeża profil klienta na podstawie najnowszych wersji danych. Ale tylko wtedy, gdy jest co odświeżać — to samo zamówienie z tymi samymi danymi przetworzone po raz drugi nie wymusza ponownego porównywania.
Identyczne dane na zamówieniu nie wymuszają ponownego przetworzenia¶
To samo zamówienie może trafić do systemu wielokrotnie — przy ponownym uruchomieniu, przy rededuplikacji, przy normalnym pobieraniu danych. System porównuje nowe dane z ostatnio zapamiętaną wersją. Jeśli są identyczne, uznaje zamówienie za już przetworzone i nie kieruje go do dalszego porównywania. Chroni to przed zbędnym obciążeniem systemu i zapobiega przypadkowym zmianom danych.
Scenariusz: Ponowne zamówienie z identycznymi danymi zwraca AlreadyProcessed
Zakładając że klient powiązany z zamówieniem "ORD-A" ma dane osoby:
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
Kiedy zamówienie "ORD-A" jest przetworzone ponownie z tymi samymi danymi
Wtedy decyzja Stage1 to "AlreadyProcessed"
I kolejka Stage2 jest pusta
Nowe dane na zamówieniu przepływają do profilu — kontakty się sumują, podstawowe dane nadpisują¶
Gdy dane na zamówieniu się zmieniają (nowy telefon, korekta nazwiska), system odświeża profil klienta na podstawie wszystkich aktualnych danych z jego zamówień. Dane kontaktowe (e-mail, telefon) są sumowane ze wszystkich zamówień — każde może dołożyć nowy kontakt do profilu. Dane podstawowe (imię, nazwisko, data urodzenia) pochodzą z najnowszej wersji — ostatnia wersja wygrywa. Jeśli po zmianie danych klient zaczyna pasować do innego istniejącego profilu, system łączy je automatycznie.
Scenariusz: Nowy numer telefonu z zamówienia jest dodawany do klienta powiązanego z wieloma zamówieniami
Zakładając że klient powiązany z zamówieniami "ORD-A" i "ORD-B" ma dane osoby:
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
I snapshot zamówienia "ORD-A" zawiera numer telefonu "+48500100200"
I snapshot zamówienia "ORD-B" zawiera numer telefonu "+48500100200"
Kiedy zamówienie "ORD-A" jest przetworzone ponownie z dodatkowym numerem "+48600200300"
I Stage2 przetwarza głównego klienta
Wtedy klient zawiera numer telefonu "+48500100200"
I klient zawiera numer telefonu "+48600200300"
Scenariusz: Drobna zmiana nazwiska w nowszym snapzhocie odświeża dane klienta
Zakładając że klient powiązany z zamówieniami "ORD-A" i "ORD-B" ma dane osoby:
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
| jan@example.com |
I snapshot zamówienia "ORD-A" ma nazwisko "Kowalski" z wcześniejszą datą przetworzenia
I snapshot zamówienia "ORD-B" ma nazwisko "Kovalsky" z późniejszą datą przetworzenia
Kiedy Stage2 przetwarza głównego klienta
Wtedy nazwisko klienta to "Kovalsky"
I klient nadal jest powiązany z zamówieniami "ORD-A" i "ORD-B"
Scenariusz: Zmiana nazwiska na zamówieniu powoduje scalenie z istniejącym klientem
Zakładając że klient C1 powiązany z zamówieniem "ORD-A" ma dane osoby:
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kowalski |
| Gender | M |
| BirthDate | 1990-05-15 |
I klient C2 powiązany z zamówieniem "ORD-B" ma dane osoby:
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kovalsky |
| Gender | M |
| BirthDate | 1990-05-15 |
Kiedy zamówienie "ORD-A" jest przetworzone ponownie z danymi:
| Pole | Wartość |
|---|---|
| FirstName | Jan |
| LastName | Kovalsky |
| Gender | M |
| BirthDate | 1990-05-15 |
I Stage2 przetwarza klienta z zamówienia "ORD-A"
Wtedy zamówienia "ORD-A" i "ORD-B" są powiązane z tym samym klientem
Co, jeśli coś pójdzie nie tak?¶
System jest zaprojektowany odpornie na błędy:
- Każdy krok jest powtarzalny — jeśli przetwarzanie zwróci błąd, dana informacja jest ponawiana automatycznie. Po przekroczeniu limitu prób trafia do kolejki błędów, z której operator może ją ręcznie powtórzyć lub odrzucić.
- Scanner wznawia od miejsca przerwania — restart nie powoduje pominięcia zamówień.
- Późna modyfikacja zamówienia — jeśli klient zmieni dane po pierwszym przetworzeniu, Scanner wykryje modyfikację i całe zamówienie przejdzie przez system ponownie.