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.