zduplikowane rekordy przez API

Zduplikowane rekordy przez API powstają, gdy integracja wielokrotnie zapisuje ten sam obiekt bez sprawdzenia jego istnienia.

Jak integracja API tworzy zduplikowane rekordy

Zduplikowane rekordy przez API pojawiają się wtedy, gdy aplikacja wysyła żądanie zapisania obiektu więcej niż jeden raz, a system odbierający każde żądanie traktuje je jako utworzenie nowego wpisu. Ten sam klient, produkt, dokument, zgłoszenie albo wynik pomiaru może wówczas zostać zapisany pod kilkoma identyfikatorami technicznymi. Przyczyną nie musi być błąd użytkownika. Powtórzenie może wynikać z ponowienia żądania po przekroczeniu limitu czasu, chwilowej utraty połączenia, ponownego uruchomienia procesu integracyjnego albo wielokrotnego przetworzenia tej samej wiadomości z kolejki.

Istotne jest rozróżnienie między identyfikatorem nadanym przez system źródłowy a identyfikatorem utworzonym przez system docelowy. Jeżeli integracja przy każdym wywołaniu używa wyłącznie nowego identyfikatora lokalnego, odbiorca nie ma prostego sposobu ustalenia, że obiekt już istnieje. Bez sprawdzenia klucza biznesowego, takiego jak numer zamówienia, identyfikator urządzenia lub identyfikator rekordu źródłowego, operacja zakończy się kolejnym zapisem zamiast aktualizacją istniejących danych.

Idempotencja, klucz naturalny i bezpieczne ponawianie

Podstawowym mechanizmem ograniczającym duplikaty jest idempotencja operacji. Oznacza ona, że wielokrotne wykonanie tego samego żądania prowadzi do takiego samego stanu danych jak wykonanie go jeden raz. W praktyce klient API przekazuje stabilny klucz idempotencji albo identyfikator obiektu pochodzący ze źródła. Serwer zapamiętuje wynik pierwszego przetworzenia i przy ponownym żądaniu rozpoznaje, że dotyczy ono tej samej operacji. Klucz powinien być jednoznaczny dla konkretnego obiektu i nie może być generowany ponownie przy każdym automatycznym ponowieniu.

Drugim zabezpieczeniem jest unikalność wymuszana po stronie bazy danych lub warstwy przechowującej dane. Dla pola zawierającego identyfikator źródłowy można zdefiniować ograniczenie UNIQUE, dzięki któremu drugi zapis tego samego obiektu zostanie odrzucony albo obsłużony jako aktualizacja. Samo wyszukiwanie rekordu przed zapisem nie zawsze wystarcza, ponieważ dwa równoległe żądania mogą jednocześnie stwierdzić, że wpisu jeszcze nie ma. Ostateczną ochronę zapewnia atomowa operacja zapisu połączona z unikalnym kluczem, transakcją lub mechanizmem upsert dostępnym w używanym systemie.

Ślady powtórnego zapisu w przepływie danych

Rozpoznanie problemu wymaga porównania danych przesyłanych przez integrację z rekordami zapisanymi w systemie docelowym. Należy sprawdzić, czy powtarza się identyfikator źródłowy, treść obiektu, znacznik czasu, numer żądania lub identyfikator korelacyjny. Pomocne są logi zawierające metodę HTTP, adres zasobu, kod odpowiedzi, czas wykonania, identyfikator żądania oraz informację o liczbie prób. Kilka wpisów POST dla tego samego obiektu w krótkim odstępie może wskazywać na ponawianie, natomiast powtarzalne wywołania po restarcie procesu mogą świadczyć o braku trwałego oznaczenia wiadomości jako przetworzonej.

Trzeba również ustalić, czy duplikat powstaje w źródle, podczas transportu, czy dopiero przy zapisie. Jeżeli system źródłowy wysyła jeden obiekt, a odbiorca rejestruje kilka żądań, problem dotyczy klienta, mechanizmu retry, kolejki lub pośrednika. Jeżeli żądań jest tyle samo co obiektów, lecz w bazie pojawia się więcej rekordów, należy przeanalizować logikę zapisu i mapowanie identyfikatorów. Weryfikacja powinna obejmować także paginację oraz synchronizację przyrostową: błędne użycie znacznika czasu lub numeru strony może wielokrotnie pobierać te same dane, nawet gdy każde pojedyncze żądanie działa poprawnie.

Porządkowanie danych i kontrola kolejnych synchronizacji

Naprawa nie powinna polegać wyłącznie na usunięciu widocznych powtórzeń. Najpierw należy ustalić regułę, według której rekordy reprezentują ten sam obiekt, a następnie wybrać wpis nadrzędny i zachować informacje, które nie mogą zostać utracone. Po scaleniu danych warto oznaczyć rekordy powiązane, sprawdzić relacje z innymi tabelami oraz zweryfikować raporty i wyszukiwanie. Usuwanie bez analizy zależności może spowodować odwołania do nieistniejącego identyfikatora albo rozbieżność między stanem aplikacji i bazy danych.

Po korekcie przepływu należy ponownie uruchomić synchronizację w kontrolowanych warunkach i sprawdzić scenariusze: odpowiedź zakończona sukcesem, timeout po stronie klienta, ponowienie tego samego żądania, równoległe próby zapisu oraz restart procesu w trakcie obsługi obiektu. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, a przy problemach z aplikacją używaną na takim sprzęcie można rozpocząć od sprawdzenia logów, konfiguracji oraz poprawności działania programu i połączenia sieciowego.