MuleSoft - Obsługa błędów Mule
Nowa obsługa błędów w Mule jest jedną z największych i głównych zmian wprowadzonych w Mule 4. Nowa obsługa błędów może wydawać się skomplikowana, ale jest lepsza i wydajniejsza. W tym rozdziale omówimy komponenty błędu Mule, typy błędów, kategorie błędów Mule oraz komponenty obsługi błędów Mule.
Składniki błędu Mule
Błąd Mule jest wynikiem niepowodzenia wyjątku Mule i składa się z następujących elementów -
Opis
Jest to ważny składnik błędu Mule, który da opis problemu. Jego wyraz jest następujący -
#[error.description]Rodzaj
Składnik Type błędu Mule służy do scharakteryzowania problemu. Umożliwia także routing w ramach obsługi błędów. Jego wyraz jest następujący -
#[error.errorType]Przyczyna
Składnik „Przyczyna” błędu Mule udostępnia bazowy element uruchamiający Java, który powoduje awarię. Jego wyraz jest następujący -
#[error.cause]Wiadomość
Składnik Message błędu Mule zawiera opcjonalny komunikat dotyczący błędu. Jego wyraz jest następujący -
#[error.errorMessage]Błędy dzieci
Składnik Child Errors błędu Mule zawiera opcjonalny zbiór błędów wewnętrznych. Te błędy wewnętrzne są używane głównie przez elementy takie jak Scatter-Gather do dostarczania zagregowanych błędów tras. Jego wyraz jest następujący -
#[error.childErrors]Przykład
W przypadku niepowodzenia żądania HTTP z kodem stanu 401, błędy Mule są następujące:
Description: HTTP GET on resource ‘http://localhost:8181/TestApp’
failed: unauthorized (401)
Type: HTTP:UNAUTHORIZED
Cause: a ResponseValidatorTypedException instance
Error Message: { "message" : "Could not authorize the user." }| Sr.NO | Typ i opis błędu |
|---|---|
| 1 | TRANSFORMATION Ten typ błędu wskazuje, że wystąpił błąd podczas przekształcania wartości. Transformacja jest wewnętrzną transformacją Mule Runtime, a nie transformacjami DataWeave. |
| 2 | EXPRESSION Ten rodzaj błędu wskazuje, że wystąpił błąd podczas oceniania wyrażenia. |
| 3 | VALIDATION Ten rodzaj błędu wskazuje, że wystąpił błąd weryfikacji. |
| 4 | DUPLICATE_MESSAGE Rodzaj błędu walidacji, który występuje, gdy wiadomość jest przetwarzana dwukrotnie. |
| 5 | REDELIVERY_EXHAUSTED Ten rodzaj błędu występuje, gdy została wyczerpana maksymalna liczba prób ponownego przetworzenia wiadomości ze źródła. |
| 6 | CONNECTIVITY Ten typ błędu wskazuje na problem podczas nawiązywania połączenia. |
| 7 | ROUTING Ten typ błędu wskazuje, że wystąpił błąd podczas kierowania wiadomości. |
| 8 | SECURITY Ten typ błędu wskazuje, że wystąpił błąd zabezpieczeń. Na przykład otrzymano nieprawidłowe poświadczenia. |
| 9 | STREAM_MAXIMUM_SIZE_EXCEEDED Ten typ błędu występuje, gdy maksymalny rozmiar dozwolony dla strumienia został wyczerpany. |
| 10 | TIMEOUT Wskazuje limit czasu podczas przetwarzania wiadomości. |
| 11 | UNKNOWN Ten typ błędu wskazuje, że wystąpił nieoczekiwany błąd. |
| 12 | SOURCE Reprezentuje wystąpienie błędu w źródle przepływu. |
| 13 | SOURCE_RESPONSE Reprezentuje wystąpienie błędu w źródle przepływu podczas przetwarzania pomyślnej odpowiedzi. |
W powyższym przykładzie możesz zobaczyć komponent wiadomości o błędzie mule.
Typy błędów
Pozwól nam zrozumieć typy błędów za pomocą ich cech -
Pierwszą cechą charakterystyczną typów błędów mułów jest to, że składają się one z obu: a namespace and an identifier. To pozwala nam rozróżnić typy według ich domeny. W powyższym przykładzie Typ błędu toHTTP: UNAUTHORIZED.
Drugą i ważną cechą jest to, że typ błędu może mieć typ nadrzędny. Na przykład Error TypeHTTP: UNAUTHORIZED ma MULE:CLIENT_SECURITY jako rodzic, który z kolei ma również nazwanego rodzica MULE:SECURITY. Ta cecha określa typ błędu jako specyfikację pozycji bardziej globalnej.
Rodzaje typów błędów
Poniżej znajdują się kategorie, do których należą wszystkie błędy -
KAŻDY
Błędy w tej kategorii to błędy, które mogą wystąpić w przepływie. Nie są tak poważne i można je łatwo obsługiwać.
KRYTYCZNY
Błędy w tej kategorii to poważne błędy, których nie można obsłużyć. Poniżej znajduje się lista typów błędów w tej kategorii -
| Sr.NO | Typ i opis błędu |
|---|---|
| 1 | OVERLOAD Ten typ błędu wskazuje, że wystąpił błąd z powodu problemu z przeciążeniem. W takim przypadku wykonanie zostanie odrzucone. |
| 2 | FATAL_JVM_ERROR Ten rodzaj błędu wskazuje na wystąpienie błędu krytycznego. Na przykład przepełnienie stosu. |
CUSTOM Error Type
NIESTANDARDOWE typy błędów to zdefiniowane przez nas błędy. Można je zdefiniować podczas mapowania lub zgłaszania błędów. Musimy nadać tym typom błędów określoną niestandardową przestrzeń nazw, aby odróżnić je od innych istniejących typów błędów w aplikacji Mule. Na przykład w aplikacji Mule korzystającej z protokołu HTTP nie możemy użyć protokołu HTTP jako niestandardowego typu błędu.
Kategorie błędów mułów
W szerokim sensie błędy w Mule można podzielić na dwie kategorie, a mianowicie: Messaging Errors and System Errors.
Błąd wiadomości
Ta kategoria błędów Mule jest związana z przepływem Mule. Ilekroć wystąpi problem w przepływie Mule, Mule zgłasza błąd wiadomości. Możemy założyćOn Error w komponencie obsługi błędów, aby obsłużyć te błędy Mule.
Błąd systemu
Błąd systemu wskazuje na wyjątek występujący na poziomie systemu. Jeśli nie ma zdarzenia Mule, błąd systemowy jest obsługiwany przez program obsługi błędów systemu. Następujący rodzaj wyjątków obsługiwanych przez program obsługi błędów systemu -
- Wyjątek występujący podczas uruchamiania aplikacji.
- Wyjątek, który występuje, gdy połączenie z systemem zewnętrznym nie powiedzie się.
W przypadku wystąpienia błędu systemu Mule wysyła powiadomienie o błędzie do zarejestrowanych słuchaczy. Rejestruje również błąd. Z drugiej strony Mule wykonuje strategię ponownego połączenia, jeśli błąd został spowodowany awarią połączenia.
Obsługa błędów Mule
Mule ma następujące dwa programy obsługi błędów do obsługi błędów -
Programy obsługi błędów w przypadku błędów
Pierwszą obsługą błędów Mule jest komponent On-Error, który definiuje typy błędów, które mogą obsłużyć. Jak wspomniano wcześniej, możemy skonfigurować komponenty On-Error wewnątrz komponentu Error Handler podobnego do zakresu. Każdy przepływ Mule zawiera tylko jedną procedurę obsługi błędów, ale ta procedura obsługi błędów może zawierać tyle zakresów On-Error, ile potrzebowaliśmy. Kroki obsługi błędu Mule w przepływie za pomocą komponentu On-Error są następujące:
Po pierwsze, ilekroć przepływ Mule wywoła błąd, normalne wykonanie przepływu zostaje zatrzymane.
Następnie proces zostanie przeniesiony do Error Handler Component które już mam On Error component aby dopasować typy błędów i wyrażenia.
W końcu składnik obsługi błędów kieruje błąd do pierwszego On Error scope który pasuje do błędu.
Poniżej znajdują się dwa typy komponentów działających w przypadku błędów obsługiwanych przez Mule -
Propaguj po błędzie
Składnik On-Error Propagate jest wykonywany, ale propaguje błąd do następnego poziomu i przerywa wykonywanie przez właściciela. Transakcja zostanie wycofana, jeśli jest obsługiwana przezOn Error Propagate składnik.
Kontynuuj w przypadku błędu
Podobnie jak składnik On-Error Propagate, składnik On-Error Continue również wykonuje transakcję. Jedynym warunkiem jest to, że jeśli właściciel pomyślnie zakończył wykonanie, to komponent ten wykorzysta wynik wykonania jako wynik jego właściciela. Transakcja zostanie zatwierdzona, jeśli jest obsługiwana przez składnik Kontynuacja błędu.
Wypróbuj komponent zakresu
Try Scope to jedna z wielu nowych funkcji dostępnych w Mule 4. Działa podobnie do bloku try JAVA, w którym kiedyś umieszczaliśmy kod mający możliwość bycia wyjątkiem, dzięki czemu można go obsługiwać bez łamania całego kodu.
Możemy zawrzeć jeden lub więcej procesorów zdarzeń Mule w Try Scope, a następnie try scope przechwyci i obsłuży każdy wyjątek zgłoszony przez te procesory zdarzeń. Główne działanie try scope obraca się wokół własnej strategii obsługi błędów, która obsługuje obsługę błędów w jej wewnętrznym komponencie zamiast w całym przepływie. Dlatego nie musimy wyodrębniać przepływu do oddzielnego przepływu.
Example
Poniżej znajduje się przykład użycia try scope -
Konfigurowanie zakresu try do obsługi transakcji
Jak wiemy, transakcja to seria działań, które nigdy nie powinny być wykonywane częściowo. Wszystkie operacje w ramach transakcji są wykonywane w tym samym wątku i jeśli wystąpi błąd, powinien prowadzić do wycofania lub zatwierdzenia. Zakres try możemy skonfigurować w następujący sposób, aby traktować operacje potomne jako transakcję.
INDIFFERENT [Default]- Jeśli wybierzemy tę konfigurację w bloku try, to akcje potomne nie będą traktowane jako transakcja. W takim przypadku błąd nie powoduje ani wycofania, ani zatwierdzeń.
ALWAYS_BEGIN - Wskazuje, że nowa transakcja zostanie uruchomiona za każdym razem, gdy zakres zostanie wykonany.
BEGIN_OR_JOIN- Wskazuje, że jeśli bieżące przetwarzanie przepływu już rozpoczęło transakcję, dołącz do niej. W przeciwnym razie rozpocznij nowy.