Konflikty danych między systemami: co zrobić, gdy obie strony zmienią ten sam rekord

W poniedziałek dział handlowy poprawia adres klienta w CRM. W tym samym czasie dział rozliczeń zmienia adres w systemie finansowym. Obie osoby mają powód, żeby zaufać swojemu ekranowi. Kiedy integracja wymieni dane, potrzebuje jednak odpowiedzi na trudniejsze pytanie: która zmiana ma zostać przyjęta i co zrobić z drugą? Bez ustalonej reguły jeden zapis może po cichu przykryć drugi.

Konflikt danych to sytuacja, w której zmiany nie mogą zostać bezpiecznie połączone według przyjętych zasad. Nie każda różnica nim jest. Dwa systemy mogą przechowywać inne informacje o tej samej firmie i obie wartości mogą być poprawne. Kłopot zaczyna się wtedy, gdy oba próbują ustalić tę samą informację, a proces nie przewiduje sposobu rozstrzygnięcia rozbieżności.

Najpierw odróżnij różnicę od konfliktu

Adres do korespondencji nie zawsze jest adresem dostawy ani adresem siedziby. Jeśli jedna aplikacja przechowuje pierwszy, a druga trzeci, wartości nie muszą być identyczne. Przed uzgadnianiem rekordu trzeba nazwać znaczenie każdego pola. Dopiero wtedy można ustalić, czy oba systemy rzeczywiście opisują to samo. Sama podobna etykieta na ekranie jeszcze tego nie dowodzi.

Wspólnie z osobami pracującymi na danych przejdź kilka przykładów. Wybierz rekord, który pojawia się w obu aplikacjach, i sprawdź, do czego każda z nich używa poszczególnych pól. Zapytaj, kto zmienia wartość, co uruchamia zapis oraz kto zauważa błąd. Taka rozmowa często ujawnia ręczne obejścia, o których nie mówi schemat bazy danych. W artykule o źródłach danych w integracji opisujemy, jak wskazać miejsce odpowiedzialne za informacje.

Dla części pól decyzja może być prosta: identyfikator księgowy nadaje system finansowy, a opis relacji z klientem utrzymuje CRM. W innych przypadkach znaczenie ma zdarzenie, które wywołało zmianę. Zmiana adresu zgłoszona przez klienta w portalu może wymagać innej weryfikacji niż poprawka literówki wykonana przez pracownika. Nie warto sprowadzać tych sytuacji do jednej reguły tylko dlatego, że obie aktualizują tekst.

Zapisz właściciela dla pola i konkretnej decyzji

Mapa odpowiedzialności powinna wskazywać system uprawniony do proponowania zmiany, system przechowujący uzgodnioną wartość i osobę rozstrzygającą wyjątki. Nie musi oznaczać, że jedna aplikacja zawsze wygrywa we wszystkich sprawach. Można na przykład ustalić, że zmiana rachunku do wypłaty wymaga potwierdzenia w systemie finansowym, natomiast aktualizacja numeru telefonu jest przyjmowana z portalu po określonej weryfikacji.

Taka mapa potrzebuje również informacji o czasie. Dane odczytane w chwili wysłania żądania mogą być nieaktualne, zanim dotrą do drugiej aplikacji. Jeśli pracownik otworzył formularz rano, a zapisuje go po południu, ktoś inny mógł w międzyczasie zmienić część danych. Pytanie brzmi, czy aplikacja rozpoznaje, na jakiej wersji rekordu oparto edycję, i czy potrafi uprzedzić o zmianie przed zapisem.

Przy wielu oddziałach ustal, czy pole jest wspólne dla całej organizacji, czy należy do konkretnego oddziału. Globalna nazwa klienta i lokalny opiekun mogą mieć różnych właścicieli. Tę różnicę warto zapisać obok zasad obsługi użytkowników opisanych w materiale o systemie dla wielu oddziałów. Inaczej integracja może poprawnie przenosić dane, ale między niewłaściwymi jednostkami.

Właściciel nie musi własnoręcznie poprawiać każdego rekordu. Jego zadaniem jest określenie reguł i wskazanie osób uprawnionych do obsługi odstępstw. Przygotuj także sytuację zastępstwa: konflikt powstały podczas nieobecności jednej osoby nie powinien zatrzymać całego zespołu. Zakres zastępstwa i czas jego obowiązywania trzeba zapisać w uprawnieniach, a nie ustalać przez przekazanie hasła.

Ostatni zapis nie zawsze powinien wygrywać

Reguła ostatniej zmiany wydaje się prosta: przyjmujemy wartość zapisaną najpóźniej. Może działać dla niektórych pól, o ile obie strony korzystają z wiarygodnych znaczników czasu, a opóźnienia i kolejność dostarczenia są uwzględnione w projekcie. Nie rozstrzyga jednak, która osoba miała aktualniejszą wiedzę. Późniejszy zapis może pochodzić z formularza otwartego przed wcześniejszą poprawką.

Jeszcze inna sytuacja pojawia się przy pracy bez stałego połączenia. Urządzenie terenowe może wysłać zapis po powrocie do sieci, choć zmiana została wykonana znacznie wcześniej. Czas odbioru wiadomości nie jest tym samym co czas podjęcia decyzji. Jeżeli pole dotyczy bezpiecznego zamknięcia zlecenia albo warunków rozliczenia, bezpieczniej wykryć rozbieżność i zastosować uzgodniony proces jej wyjaśnienia.

W części przypadków można połączyć zmiany, które dotyczą różnych pól. Gdy jedna osoba poprawiła telefon, a druga nazwę działu, oba wpisy nie muszą się wykluczać. Nadal trzeba jednak sprawdzić zależności. Zmiana kraju i kodu pocztowego w oddzielnych systemach może stworzyć kombinację, której żadna osoba nie zatwierdziła. Łączenie pól wymaga więc reguł dla danych, które mają wspólny sens. Jeśli dane mają przejść do nowego systemu, sprawdź również przygotowanie i odbiór migracji danych, w tym uzgadnianie wyników importu.

Jak rozpoznać, że rekord zmienił się od odczytu

Jednym ze sposobów jest przekazanie przez system wersji rekordu razem z odczytanymi danymi. Przy zapisie aplikacja podaje wersję, na której opiera zmianę. Jeżeli rekord w międzyczasie otrzymał inną wersję, serwer może odrzucić zapis warunkowy i poprosić klienta o ponowne pobranie danych. Taki mechanizm chroni przed cichym nadpisaniem, ale sam nie podejmuje za firmę decyzji, którą wartość przyjąć.

W HTTP podobną rolę mogą pełnić żądania warunkowe. Dokumentacja MDN opisuje użycie nagłówka If-Match z odpowiednim ETag do sprawdzenia, czy zasób nadal odpowiada wersji, na podstawie której przygotowano zmianę. Gdy warunek nie jest spełniony, serwer może odpowiedzieć statusem 412. Jest to mechanizm konkretnego protokołu, a nie automatyczna funkcja każdej integracji. Trzeba sprawdzić, czy obie strony go obsługują i co dokładnie oznacza wersja danego zasobu.

Systemy mogą również udostępniać numer wersji lub inny znacznik w swoim API. Przy projektowaniu połączenia ustal, czy znacznik obejmuje cały rekord, czy poszczególne pola. Zmiana niepowiązanego pola może bowiem wywołać konflikt na poziomie całego rekordu. To bywa bezpieczne, ale przy częstych aktualizacjach może nadmiernie obciążyć kolejkę wyjątków. Wybór dokładności kontroli jest częścią projektu, nie uniwersalnym przełącznikiem.

Przy porównywaniu wersji potrzebna jest również jasna obsługa braku znacznika. Starszy system może go nie przekazywać albo połączenie może go nie zachować. Ustal wtedy, czy operację zatrzymujecie, czy wykonujecie dodatkowy odczyt, oraz kto przyjmuje ryzyko. Przyjęcie pustej wersji jako automatycznej zgody na nadpisanie może bowiem usunąć właśnie tę ochronę, dla której wprowadzono zapis warunkowy.

Pokaż konflikt osobie, która może go rozstrzygnąć

Komunikat „wystąpił błąd synchronizacji” nie wystarczy do podjęcia decyzji. Osoba odpowiedzialna powinna zobaczyć, jakiej sprawy dotyczy rozbieżność, które wartości porównuje system i kiedy oraz skąd pochodzi każda propozycja. Przy danych wrażliwych zakres informacji musi wynikać z uprawnień. Ktoś może potrzebować informacji o konflikcie bez dostępu do pełnej treści dokumentu.

Zaprojektuj także możliwe działania. Operator może zaakceptować jedną wartość, przygotować poprawkę lub przekazać sprawę właściwemu właścicielowi. Każda decyzja powinna pozostawić zrozumiały ślad: kto ją podjął, czego dotyczyła i jaki był wynik. Jeśli podczas rozstrzygania rekord ponownie się zmieni, aplikacja powinna to zauważyć. W przeciwnym razie osoba rozwiązująca konflikt może sama nadpisać kolejną, jeszcze nowszą zmianę.

Kolejka wyjątków potrzebuje właściciela i uzgodnionego czasu reakcji. W przeciwnym razie system będzie poprawnie wykrywał konflikty, a sprawy będą czekały bez końca. W tekście o monitorowaniu automatyzacji opisujemy, jak powiązać sygnał z konkretną odpowiedzialnością. Tu warto dodać widok spraw oczekujących i regułę eskalacji wtedy, gdy konflikt blokuje ważny etap pracy.

Unikaj pętli aktualizacji

Po rozwiązaniu konfliktu jedna aplikacja przekazuje zaakceptowaną wartość do drugiej. Druga może potraktować tę aktualizację jako nową zmianę i odesłać ją z powrotem. Jeżeli po drodze każda strona dodaje własny znacznik lub inaczej formatuje dane, proces może wymieniać te same informacje wielokrotnie. Warto ustalić, jak rozpoznawane jest pochodzenie zdarzenia oraz kiedy nie należy generować kolejnej aktualizacji.

Rozwiązanie trzeba sprawdzić w warunkach opóźnienia i ponownego dostarczenia komunikatu. Ten sam komunikat może dotrzeć po późniejszej zmianie lub zostać odebrany więcej niż raz. Bezpieczne ponawianie operacji opisujemy osobno w materiale o API i webhookach. Tutaj istotne jest połączenie dwóch kwestii: rozpoznania wiadomości oraz oceny, czy jej treść nadal odpowiada aktualnemu stanowi rekordu.

Nie zakładaj również, że samo zastosowanie kolejki zachowa sens biznesowy każdej operacji. Zapis zamówienia i późniejsza anulacja mogą mieć zależność, której nie wolno zgubić. Jeśli system przyjmuje zdarzenia w innej kolejności niż powstały, potrzebuje sposobu rozpoznania brakującego kroku albo odczytania aktualnego stanu. To szczególnie ważne tam, gdzie dane z kilku aplikacji trafiają do wspólnego procesu.

Sprawdź przypadki, które naprawdę zdarzają się w pracy

Przygotuj test z dwiema osobami edytującymi ten sam rekord na dwóch ekranach. Niech jedna zapisze zmianę, a druga spróbuje zapisać swoją starszą wersję. Sprawdź komunikat, dostępne decyzje i końcowy stan w obu systemach. Następnie wykonaj wariant zmian w różnych polach oraz wariant, w którym powiązane pola nie powinny zostać połączone automatycznie. Wynik należy sprawdzić także w historii, nie tylko w aktualnym widoku.

Dodaj opóźniony komunikat, chwilowy brak połączenia i ponowne dostarczenie zdarzenia. Sprawdź, co stanie się po restarcie integracji oraz po odebraniu użytkownikowi dostępu w trakcie oczekiwania sprawy. Porównaj wynik z ustalonymi zasadami biznesowymi. Jeżeli w raporcie suma nagle się zmienia, przyczyną może być zmiana definicji albo brak danych, a nie faktyczna zmiana działalności. Kontekst tych rozróżnień opisujemy przy definicjach wskaźników.

Dobrze dobrać próbki również z danych, które zwykle wymagają ręcznego sprawdzenia. Zanim wykorzystasz informacje w kolejnych procesach lub w AI, ustal odpowiedzialność za ich jakość i aktualność. Pomocny będzie materiał o porządkowaniu danych przed wdrożeniem AI. Dane widoczne w nowym systemie nie stają się automatycznie poprawne tylko dlatego, że dotarły przez integrację.

Jak przygotować brief dla wykonawcy

Wybierz jeden przykład rozbieżności i opisz, kto ją zauważył, gdzie wprowadzono zmiany oraz jaki skutek miała dla pracy. Wskaż systemy uczestniczące w procesie i osobę, która rozstrzyga znaczenie danych. Jeżeli problem jeszcze nie wystąpił, opisz scenariusz, którego chcesz uniknąć. Do pierwszej rozmowy wystarczą dane zastępcze oraz dokumentacja dostępnych interfejsów. Sekrety dostępowe i prawdziwe dane klientów wymagają osobnego, uzgodnionego kanału.

Możesz wysłać opis przez kontakt z Archifutura. Na jego podstawie ustalimy, które pola i zdarzenia obejmuje projekt, gdzie powinna pojawić się decyzja człowieka i jak sprawdzić wynik. Zakres integracji systemów można następnie oprzeć na przykładach z pracy zespołu oraz na możliwościach konkretnych usług.

W briefie opisz też skalę i częstotliwość zmian bez zgadywania dokładnych liczb. Przybliżona liczba spraw, godziny intensywnej pracy oraz informacja o oczekiwanym czasie uzgodnienia pomogą zaplanować próbę. Zespół wykonawcy powinien następnie sprawdzić ograniczenia usług i zaproponować sposób pomiaru, zanim zadeklaruje konkretny czas synchronizacji.