MuleSoft - obsługa wyjątków Mule

W przypadku każdego projektu wyjątek jest taki, że na pewno się wydarzy. Dlatego ważne jest, aby wychwytywać, kategoryzować i obsługiwać wyjątki, aby system / aplikacja nie pozostała w niespójnym stanie. Istnieje domyślna strategia wyjątków, która jest domyślnie stosowana do wszystkich aplikacji Mule. Automatyczne wycofywanie wszystkich oczekujących transakcji jest domyślną strategią wyjątków.

Wyjątki w Mule

Zanim zagłębimy się w wyjątkową obsługę, powinniśmy zrozumieć, jakiego rodzaju wyjątki mogą wystąpić, wraz z trzema podstawowymi pytaniami, które programista musi mieć podczas projektowania procedur obsługi wyjątków.

Który transport jest ważny?

To pytanie ma duże znaczenie przed zaprojektowaniem procedur obsługi wyjątków, ponieważ wszystkie transporty nie obsługują ponadnarodowości.

File lub HTTPnie obsługuje transakcji. Dlatego jeśli w takich przypadkach wystąpi wyjątek, musimy nim zarządzać ręcznie.

Databasesobsługiwać transakcje. Projektując procedury obsługi wyjątków w tym przypadku, musimy pamiętać, że transakcje bazy danych mogą automatycznie wycofywać się (jeśli jest to wymagane).

W przypadku REST APIs, powinniśmy pamiętać, że powinny zwracać prawidłowe kody stanu HTTP. Na przykład 404 dla nieznalezionego zasobu.

Który wzorzec wymiany wiadomości ma być używany?

Projektując procedury obsługi wyjątków, musimy zadbać o wzorzec wymiany komunikatów. Może istnieć synchroniczny (żądanie-odpowiedź) lub asynchroniczny (zapomnienie po uruchomieniu) wzorzec komunikatów.

Synchronous message pattern jest oparty na formacie żądanie-odpowiedź, co oznacza, że ​​ten wzorzec będzie oczekiwał odpowiedzi i będzie blokowany do czasu zwrócenia odpowiedzi lub przekroczenia limitu czasu.

Asynchronous message pattern jest oparty na formacie fire-zapomnij, co oznacza, że ​​ten wzorzec zakłada, że ​​żądania zostaną ostatecznie przetworzone.

Jaki to wyjątek?

Bardzo prosta zasada jest taka, że ​​będziesz obsługiwać wyjątek na podstawie jego typu. Bardzo ważne jest, aby wiedzieć, czy wyjątek jest spowodowany problemem systemowym / technicznym czy biznesowym?

Wystąpił wyjątek przez system/technical issue (np. awaria sieci) powinna być obsługiwana automatycznie przez mechanizm ponawiania.

Z drugiej strony wystąpił wyjątek by a business issue (takich jak nieprawidłowe dane) nie należy rozwiązywać przez zastosowanie mechanizmu ponawiania, ponieważ ponawianie próby bez naprawienia przyczyny nie jest przydatne.

Dlaczego należy kategoryzować wyjątki?

Ponieważ wiemy, że wszystkie wyjątki nie są takie same, bardzo ważne jest skategoryzowanie wyjątków. Na wysokim poziomie wyjątki można podzielić na następujące dwa typy:

Wyjątki biznesowe

Głównymi przyczynami występowania wyjątków biznesowych są nieprawidłowe dane lub nieprawidłowy przebieg procesów. Tego rodzaju wyjątki mają zwykle charakter nieodwracalny, dlatego nie jest dobrze konfigurować plikrollback. Nawet aplikującretryMechanizm nie miałby sensu, ponieważ ponawianie próby bez naprawienia przyczyny nie jest przydatne. Aby obsłużyć takie wyjątki, przetwarzanie powinno zostać natychmiast zatrzymane, a wyjątek odesłany jako odpowiedź na kolejkę utraconych wiadomości. Powiadomienie należy również przesłać do operacji.

Wyjątki niezwiązane z działalnością biznesową

Głównymi przyczynami występowania wyjątków niezwiązanych z działalnością biznesową są problemy systemowe lub techniczne. Tego rodzaju wyjątki są z natury odtwarzalne, dlatego dobrze jest skonfigurować plikretry mechanizm w celu rozwiązania tych wyjątków.

Strategie obsługi wyjątków

Mule ma pięć następujących strategii obsługi wyjątków -

Domyślna strategia wyjątków

Mule implicite stosuje tę strategię do przepływów Mule. Może obsługiwać wszystkie wyjątki w naszym przepływie, ale można go również przesłonić, dodając strategię wyjątku catch, Choice lub Rollback. Ta strategia wyjątków spowoduje wycofanie wszystkich oczekujących transakcji i zarejestrowanie również wyjątków. Ważną cechą tej strategii wyjątków jest to, że rejestruje ona również wyjątek, jeśli nie ma transakcji.

Jako strategia domyślna, Mule implementuje ją, gdy wystąpi jakikolwiek błąd w przepływie. Nie możemy konfigurować w studiu AnyPoint.

Strategia wycofywania wyjątków

Przypuśćmy, że jeśli nie ma możliwości naprawienia błędu, to co zrobić? Rozwiązaniem jest użycie strategii wycofywania wyjątków, która spowoduje wycofanie transakcji wraz z wysłaniem komunikatu do łącznika przychodzącego przepływu nadrzędnego w celu ponownego przetworzenia komunikatu. Ta strategia jest również bardzo przydatna, gdy chcemy ponownie przetworzyć wiadomość.

Example

Tę strategię można zastosować do transakcji bankowych, w których środki są zdeponowane na rachunku bieżącym / oszczędnościowym. Możemy tutaj skonfigurować strategię wyjątków wycofywania, ponieważ w przypadku wystąpienia błędu podczas transakcji strategia ta cofa komunikat z powrotem do początku do przepływu w celu ponownego przetworzenia.

Strategia połowu wyjątków

Ta strategia przechwytuje wszystkie wyjątki, które są zgłaszane w jej przepływie nadrzędnym. Zastępuje domyślną strategię wyjątków Mule, przetwarzając wszystkie wyjątki zgłoszone przez przepływ nadrzędny. Możemy użyć strategii wyjątków catch, aby uniknąć propagowania wyjątków do łączników przychodzących i przepływów nadrzędnych.

Ta strategia zapewnia również, że transakcja przetwarzana przez przepływ nie jest wycofywana w przypadku wystąpienia wyjątku.

Example

Strategię tę można zastosować do systemu rezerwacji lotów, w którym mamy przepływ do przetwarzania komunikatów z kolejki. Moduł wzbogacający wiadomości dodaje właściwość do wiadomości w celu przypisania miejsca, a następnie wysyła wiadomość do innej kolejki.

Teraz, jeśli w tym przepływie wystąpi jakikolwiek błąd, komunikat zgłosi wyjątek. Tutaj nasza strategia wyjątków catch może dodać nagłówek z odpowiednim komunikatem i może wypchnąć ten komunikat z przepływu do następnej kolejki.

Strategia wyboru wyjątków

Jeśli chcesz obsłużyć wyjątek na podstawie treści wiadomości, najlepszym wyborem będzie strategia wyboru wyjątków. Działanie tej strategii wyjątków będzie następujące -

• Po pierwsze, przechwytuje wszystkie wyjątki zgłaszane w przepływie nadrzędnym.
• Następnie sprawdza zawartość wiadomości i typ wyjątku.
• W końcu kieruje wiadomość do odpowiedniej strategii wyjątków.

Byłoby więcej niż jedna strategia wyjątku, taka jak Catch lub Rollback, zdefiniowana w ramach strategii wyjątków wyboru. W przypadku braku strategii zdefiniowanej w ramach tej strategii wyjątku, komunikat zostanie skierowany do domyślnej strategii wyjątku. Nigdy nie wykonuje żadnych działań związanych z zatwierdzaniem, wycofywaniem ani konsumowaniem.

Odniesienie do strategii wyjątków

Odnosi się to do typowej strategii wyjątków, która jest zdefiniowana w oddzielnym pliku konfiguracyjnym. W przypadku, gdy komunikat zgłasza wyjątek, ta strategia wyjątku będzie odnosić się do parametrów obsługi błędów zdefiniowanych w globalnej strategii wyjątku catch, rollback lub choice. Podobnie jak strategia wyjątków wyboru, nigdy nie wykonuje również żadnych działań zatwierdzania, wycofywania ani konsumowania.