Rozszerzenia, zdarzenia i workflow
Panel serwisowy na karcie klienta, blokada błędnego zapisu i powiadomienie po zamknięciu szansy sprzedaży wymagają różnych rozszerzeń. Poniżej pokazujemy, które wybrać i jak podłączyć je do własnego modułu.
Na tej stronie
Przed zapisem czy po zmianie?
Reguła, która ma odrzucić operację, musi zadziałać przed zapisem. Na przykład zamknięcie sprawy serwisowej może wymagać przypisanego technika. Sprawdzenie umieść na serwerze, aby obejmowało też wywołania API i importy korzystające z tej samej ścieżki.
Zdarzenie informuje o tym, co się stało. Powiadomienie wysyłane po zamknięciu sprawy może się nie udać mimo poprawnego zapisu. Warunek wymagany do zapisu umieść w regule sprawdzającej operację, nazywanej guardem, albo w walidacji komendy.
Trasa i komenda określają użyte rozszerzenia. Bezpośredni zapis do bazy nie przechodzi automatycznie przez całą tę ścieżkę.
Kod i dokumentacja
Którego mechanizmu użyć?
| Co chcesz zrobić | Mechanizm i plik |
|---|---|
| Pokazać sprawy serwisowe na karcie klienta | Widget: widgets/injection/. Przypisz go do miejsca na stronie w widgets/injection-table.ts. |
| Dodać obliczoną wartość do odpowiedzi API | Rozszerzenie odpowiedzi: data/enrichers.ts. Na przykład dołącz liczbę otwartych spraw. |
| Odrzucić zapis po niespełnieniu warunku | Reguła zapisu: data/guards.ts. Zwróć przyczynę odmowy przed zapisaniem zmiany. |
| Dodać działanie przed lub po komendzie | Rozszerzenie komendy: commands/interceptors.ts, z etapem beforeExecute albo afterExecute. |
| Zareagować na zdarzenie biznesowe | Procedura obsługi zdarzenia: subscribers/. W metadata wskazuje nazwę zdarzenia. |
| Zmienić obsługę żądania lub odpowiedzi trasy API | Rozszerzenie trasy API: api/interceptors.ts. Wybierz etap obsługiwany przez daną trasę. |
Kod i dokumentacja
Przykład: panel serwisowy na karcie klienta
Sprawy serwisowe przechowuj we własnym module. Panel otrzymuje kontekst klienta i pobiera powiązane sprawy przez Twoje API. API sprawdza dostęp do tych spraw również wtedy, gdy użytkownik ma już dostęp do karty klienta.
- Znajdź miejsce na rozszerzenie udostępnione przez kartę klienta i sprawdź przekazywany kontekst.
- Przygotuj widget i powiąż jego identyfikator z tym miejscem w widgets/injection-table.ts.
- Włącz moduł i odtwórz rejestry. Oprócz listy spraw przygotuj widok ładowania, braku danych i błędu.
Kod i dokumentacja
extensibility/current-surfaces.mdx · generators/module-registry.ts
Przykład z kodu: powiadomienie o przegranej szansie
Moduł customers zawiera plik deal-lost-notification.ts. Poniższa deklaracja łączy jego funkcję z customers.deal.lost. Funkcja obsługi wywołuje deliverDealClosureNotification, przekazując dane zdarzenia i kontekst usług.
event wskazuje nazwę zdarzenia. id identyfikuje procedurę obsługi. persistent oznacza obsługę trwałych zdarzeń; sposób dostarczenia zależy również od konfiguracji kolejki i emisji zdarzenia.
export const metadata = {
event: 'customers.deal.lost',
persistent: true,
id: 'customers:deal-lost-notification',
}Kod i dokumentacja
Co się stanie, jeśli wysyłka się nie uda?
Załóżmy, że wysyłasz zamówienie do magazynu. Magazyn je tworzy, ale odpowiedź nie dociera. Kolejna próba może utworzyć drugie zamówienie. Przesyłaj stały identyfikator operacji, jeśli docelowe API go obsługuje. W pozostałych przypadkach sprawdź istniejący rekord przed kolejną próbą utworzenia.
Obsługa synchroniczna wykonuje się w trakcie bieżącej operacji; określ, jak jej błąd wpływa na wynik. Kolejka pozwala użytkownikowi kontynuować pracę, gdy zadanie wykona się później. Przy pracy w tle monitoruj workera, zapisuj przyczynę błędu i ustal, które błędy pozwalają na ponowienie.
Kod i dokumentacja
Kiedy opisać cały proces
Proces zgłoszenie → akceptacja kierownika → realizacja potrzebuje zapisanego stanu i jasno określonych przejść. Workflow może obsłużyć oczekiwanie na człowieka oraz kolejne działania. Do pojedynczego powiadomienia zwykle wystarczy obsługa zdarzenia. Workflow przydaje się wtedy, gdy trzeba wznawiać i śledzić proces obejmujący kilka kroków.