Gdy zmiana konfiguracji lub danych biznesowych może wpłynąć na innych użytkowników, aplikacja może wymagać, aby jedna osoba ją zaproponowała, a inna zweryfikowała przed jej wejściem w życie. Zaprojektowanie takiego procesu jako przepływu zatwierdzania zmian w SaaS PHP wymaga czegoś więcej niż dodania przycisku „zatwierdź”: trzeba oddzielić propozycję od aktualnej wartości, zabezpieczyć każdą zmianę stanu i określić, co się stanie, jeśli kontekst zmieni się, gdy wniosek będzie oczekiwał na rozpatrzenie.
Celem jest zapewnienie, aby system mógł w weryfikowalny sposób odpowiedzieć na pytania: czego dotyczył wniosek, kto go zweryfikował, z jakimi uprawnieniami i czy został zastosowany. Rozwiązanie powinno być proporcjonalne do ryzyka: niepotrzebny przepływ dodaje utrudnienia, a niewystarczający może umożliwić wprowadzenie nieprawidłowych lub trudnych do prześledzenia zmian.
Ustal, które zmiany wymagają zatwierdzenia
Zacznij od sklasyfikowania zmian według ich wpływu, zakresu i możliwości ich skorygowania. Nie każda edytowalna wartość wymaga weryfikacji. Użytkownik, który zmienia ustawienie osobiste o niewielkim znaczeniu, może zapisać zmianę bezpośrednio. Z kolei uzasadnione może być wymaganie zatwierdzenia zmiany reguły rozliczeniowej, konfiguracji współdzielonej przez organizację lub danych podstawowych wpływających na kilka procesów.
Określ jawne kryteria produktowe. Zapytaj na przykład, czy zmiana wpływa na więcej użytkowników niż osoba ją proponująca, czy może zmienić kwoty lub uprawnienia, czy wewnętrzna polityka wymaga udziału drugiej osoby i ile kosztowałoby skorygowanie błędu. Udokumentuj również wyjątki i określ, kto może je zmieniać. Nie przekształcaj zatwierdzania w ogólny mechanizm dla operacji niezwiązanych z tym przypadkiem: zakres obejmuje tu zmiany konfiguracji lub danych biznesowych.
Decyzja musi być egzekwowana na serwerze, a nie tylko odzwierciedlona w interfejsie. Ukrycie przycisku nie uniemożliwia bezpośredniego wywołania endpointu. API musi ustalać, czy dany typ zmiany wymaga zatwierdzenia, i stosować tę regułę zarówno do operacji pojedynczych, jak i masowych oraz integracji, które mogą zmienić te same dane.
Oddziel wniosek od aktualnej wartości
Nie nadpisuj aktualnej wartości podczas tworzenia propozycji. Zapisz osobny wniosek zawierający co najmniej organizację, zasób, którego dotyczy zmiana, proponowane wartości, stan, informację o tym, kto go utworzył, oraz datę utworzenia. W zależności od produktu może być też konieczne zapisanie uzasadnienia, źródła wniosku, terminu ważności lub wersji pierwotnych danych.
Wartości możesz reprezentować za pomocą typowanych pól albo struktury serializowanej, którą waliduje serwer. W obu przypadkach nie przyjmuj dowolnego payloadu tak, jakby był bezpośrednią aktualizacją. Po otrzymaniu propozycji zweryfikuj schemat, dozwolone pola, formaty i reguły biznesowe. Przed zastosowaniem ponownie sprawdź wszystko, co należy zweryfikować, ponieważ warunki mogły się zmienić w czasie oczekiwania.
Taki projekt umożliwia porównanie aktualnej i proponowanej wartości bez zmieniania doświadczenia innych użytkowników. Pozwala też wyświetlić na ekranie weryfikacji zrozumiałą różnicę. Nie przedstawiaj wartości oczekującej na zatwierdzenie jako aktualnej; jasno rozróżnij zastosowane dane od propozycji.
Jawnie modeluj stany i przejścia
Zdefiniuj niewielki zestaw stanów o precyzyjnym znaczeniu. Typowa sekwencja może obejmować proposed (zaproponowano), in_review (w trakcie weryfikacji), approved (zatwierdzono), rejected (odrzucono), expired (wygasł) i applied (zastosowano). Nie każdy produkt potrzebuje stanu weryfikacji: jeśli wystarczy natychmiastowa decyzja, można go pominąć. Najważniejsze, aby każdy stan opisywał sytuację operacyjną, a nie był jedynie ozdobną etykietą.
Określ dozwolone przejścia. Na przykład propozycja może przejść do weryfikacji albo zostać odrzucona; wniosek w trakcie weryfikacji może zostać zatwierdzony lub odrzucony; zatwierdzony wniosek można zastosować, jeśli nadal jest aktualny. Wygasłego wniosku nie należy zatwierdzać tą samą ścieżką co aktywnego. Niedozwolone działania muszą kończyć się spójną odpowiedzią, nawet jeśli interfejs nie udostępnia takiej opcji.
„Zatwierdzono” i „zastosowano” nie oznaczają tego samego. Zatwierdzenie odnotowuje decyzję, a zastosowanie zmienia aktualną wartość. Zachowanie obu etapów pozwala wykrywać błędy zastosowania i wyświetlać zatwierdzone wnioski, które nadal wymagają obsługi. Jeśli proces można zakończyć w ramach jednej krótkiej transakcji, decyzję i zapis można skoordynować, ale model powinien nadal rozróżniać, co się wydarzyło.
Weryfikuj uprawnienia przy każdym przejściu
Autoryzuj każde działanie na serwerze na podstawie organizacji, roli, zasobu i bieżącego stanu. Nie zakładaj, że możliwość utworzenia wniosku daje również uprawnienie do jego zatwierdzenia lub zastosowania. Nie ufaj też identyfikatorowi organizacji przesłanemu przez klienta: ustal zakres na podstawie zweryfikowanej sesji lub poświadczenia i sprawdź, czy wniosek oraz zasób należą do tego samego zakresu.
Jeśli samodzielne zatwierdzanie jest zabronione, sprawdź, czy tożsamość osoby zatwierdzającej różni się od tożsamości osoby, która złożyła propozycję. Regułę tę należy egzekwować podczas zmiany stanu, a nie tylko w widoku. Określ również, jak traktować wnioski administratorów, użytkowników usług i procesów automatycznych; wyjątki wymagają świadomie zaprojektowanej polityki, a nie przypadkowego pominięcia.
Zatwierdzenie powinno być powiązane z konkretną propozycją. Jeśli zmieni się jej treść, poprzednie zatwierdzenie traci ważność: utwórz nową wersję wniosku albo przywróć stan wymagający weryfikacji. Cicha zmiana wartości po zatwierdzeniu zrywa zgodność między tym, co zweryfikowano, a tym, co zastosowano.
Obsługuj współbieżność, wygaśnięcie i zastosowanie
Gdy wniosek oczekuje na rozpatrzenie, inny podmiot może zmienić pierwotne dane. Aby wykryć taką sytuację, przy tworzeniu propozycji zapisz wersję zasobu lub istotne wartości. Podczas zastosowania porównaj oczekiwaną wersję z aktualną. Jeśli są różne, nie nadpisuj nowej zmiany bez uzasadnionej reguły: zablokuj zastosowanie, oznacz konflikt albo zażądaj ponownej weryfikacji zgodnie z zasadami produktu.
W relacyjnej bazie danych transakcja może zabezpieczyć odczyt wniosku, sprawdzenie jego stanu i aktualizację zasobu. Konkretne rozwiązanie zależy od silnika i poziomu współbieżności; odpowiednie może być blokowanie pesymistyczne lub warunkowa aktualizacja na podstawie wersji. W każdym przypadku przejście musi być atomowe: dwa równoczesne wnioski nie powinny dwukrotnie zastosować tej samej zmiany.
Zapewnij idempotentność zastosowania albo bezpieczne odrzucanie ponownych prób. Jeśli aktualizujesz dane w bazie, a ponadto wysyłasz powiadomienie lub publikujesz zdarzenie, rozważ zapisanie oczekującego zdarzenia w ramach tej samej transakcji i przetworzenie go później. Ogranicza to ryzyko wyświetlenia powiadomienia o sukcesie, mimo że zapis nie został zatwierdzony.
Określ również politykę wygaśnięcia: jak długo propozycja może pozostawać aktywna, co powoduje jej wygaśnięcie i czy można ją odnowić. Wygaśnięcie należy sprawdzać na serwerze podczas zatwierdzania i zastosowania; sama zmiana stanu przez zadanie zaplanowane nie wystarczy. Jeśli opóźnienie sprawi, że wartości lub warunki przestaną być wiarygodne, wymagaj nowej propozycji.
Audytuj przepływ i zarządzaj nim operacyjnie
Przechowuj rejestr informacji o tym, kto zaproponował, zatwierdził, odrzucił i zastosował każdą zmianę, wraz z datami, identyfikatorami organizacji i zasobu, wynikiem oraz kontekstem potrzebnym do przeprowadzenia dochodzenia. Zapisuj odwołanie do wersji propozycji i decyzji. Rejestru audytowego nie powinno się dać zmieniać za pomocą standardowych funkcji edycji wniosków. Ogranicz rejestrowane dane do niezbędnego minimum i stosuj zasady dostępu oraz przechowywania obowiązujące w produkcie.
Interfejs operacyjny powinien ułatwiać znajdowanie wniosków oczekujących, wygasłych, zablokowanych z powodu konfliktów oraz zatwierdzonych, ale niezastosowanych. Wyjaśniaj przyczynę blokady i udostępniaj bezpieczną ścieżkę jej rozwiązania; nie zamieniaj błędu zastosowania w automatyczne zatwierdzenie. Powiadomienia mogą informować o nowych zadaniach i decyzjach, ale są tylko pomocą: źródłem prawdy jest zapisany i dostępny do odczytu stan.
Testuj niezmienniki, uprawnienia i błędy
Testy powinny sprawdzać reguły, których nie wolno naruszyć. Niezatwierdzony wniosek nie zmienia aktualnej wartości; osoba bez dostępu do organizacji nie może go odczytać ani zmienić jego stanu; samodzielne zatwierdzenie kończy się niepowodzeniem, jeśli jest zabronione; zatwierdzonego wniosku nie można zastosować z treścią inną niż ta, którą zweryfikowano. Dodaj testy stanów końcowych, wygasłych wniosków i niedozwolonych przejść.
Testuj również wyścigi między dwoma zatwierdzeniami oraz między zatwierdzeniem a edycją pierwotnych danych. Symuluj błędy podczas zastosowania i sprawdzaj, czy wniosek nie zostaje oznaczony jako zastosowany, jeśli zapis nie został zatwierdzony. Jeśli istnieje zadanie wygaszające wnioski, sprawdź, czy jego wielokrotne uruchomienie jest bezpieczne. Testy te przekształcają reguły biznesowe w weryfikowalne gwarancje i pomagają utrzymać przepływ mimo zmian uprawnień lub modelu danych.
Jako zasadę projektową przyjmij, że każdy etap powinien mieć przypisaną osobę odpowiedzialną, weryfikowalny warunek i obserwowalny wynik. Jeśli zespół nie potrafi wyjaśnić, kto ma uprawnienia do każdego przejścia, co dzieje się w przypadku równoczesnej zmiany ani jak odtworzyć przebieg decyzji, przepływ wymaga doprecyzowania, zanim trafi na produkcję.
