MuleSoft - Xử lý ngoại lệ Mule

Trong trường hợp của mọi dự án, thực tế về các ngoại lệ là chúng nhất định xảy ra. Đó là lý do tại sao điều quan trọng là phải nắm bắt, phân loại và xử lý các trường hợp ngoại lệ để hệ thống / ứng dụng không bị rơi vào trạng thái không nhất quán. Có một chiến lược ngoại lệ mặc định được áp dụng ngầm cho tất cả các ứng dụng Mule. Tự động khôi phục mọi giao dịch đang chờ xử lý là chiến lược ngoại lệ mặc định.

Ngoại lệ trong Mule

Trước khi đi sâu vào xử lý ngoại lệ, chúng ta nên hiểu loại ngoại lệ nào có thể xảy ra cùng với ba câu hỏi cơ bản mà nhà phát triển phải có khi thiết kế trình xử lý ngoại lệ.

Giao thông vận tải nào là quan trọng?

Câu hỏi này có nhiều mức độ liên quan trước khi thiết kế các trình xử lý ngoại lệ vì tất cả các phương tiện vận tải không hỗ trợ tính xuyên quốc gia.

File hoặc là HTTPkhông hỗ trợ giao dịch. Đó là lý do tại sao, nếu một ngoại lệ xảy ra trong những trường hợp này, chúng ta phải quản lý nó theo cách thủ công.

Databaseshỗ trợ giao dịch. Trong khi thiết kế các trình xử lý ngoại lệ trong trường hợp này, chúng ta phải lưu ý rằng các giao dịch cơ sở dữ liệu có thể tự động khôi phục (nếu cần).

Trong trường hợp REST APIs, chúng ta nên nhớ rằng chúng phải trả về mã trạng thái HTTP chính xác. Ví dụ: 404 cho một tài nguyên không tìm thấy.

Mẫu Trao đổi Thư nào sẽ được sử dụng?

Trong khi thiết kế các trình xử lý ngoại lệ, chúng ta phải quan tâm đến mẫu trao đổi Thư. Có thể có mẫu thông báo đồng bộ (yêu cầu trả lời) hoặc không đồng bộ (hỏa hoạn).

Synchronous message pattern dựa trên định dạng yêu cầu trả lời có nghĩa là mẫu này sẽ mong đợi phản hồi và sẽ bị chặn cho đến khi phản hồi được trả lại hoặc hết thời gian xảy ra.

Asynchronous message pattern dựa trên định dạng fire-forget, có nghĩa là mẫu này giả định rằng các yêu cầu cuối cùng sẽ được xử lý.

Đó là loại ngoại lệ nào?

Quy tắc rất đơn giản là bạn sẽ xử lý ngoại lệ dựa trên loại của nó. Điều rất quan trọng là phải biết liệu trường hợp ngoại lệ là do vấn đề hệ thống / kỹ thuật hay vấn đề kinh doanh?

Một ngoại lệ xảy ra bởi system/technical issue (chẳng hạn như mất mạng) sẽ được tự động xử lý bằng cơ chế thử lại.

Mặt khác, một ngoại lệ đã xảy ra by a business issue (chẳng hạn như dữ liệu không hợp lệ) không nên được giải quyết bằng cách áp dụng cơ chế thử lại vì sẽ không hữu ích nếu thử lại mà không khắc phục nguyên nhân cơ bản.

Tại sao phải phân loại ngoại lệ?

Như chúng ta biết rằng tất cả các ngoại lệ không giống nhau, điều rất quan trọng là phải phân loại các ngoại lệ. Ở cấp độ cao, các ngoại lệ có thể được phân loại thành hai loại sau:

Ngoại lệ kinh doanh

Các lý do chính cho sự xuất hiện của các ngoại lệ kinh doanh là dữ liệu không chính xác hoặc luồng quy trình không chính xác. Về bản chất, những loại ngoại lệ này thường không thể kiểm tra lại được và do đó, việc định cấu hình mộtrollback. Ngay cả khi áp dụngretrycơ chế sẽ không có ý nghĩa gì vì sẽ không hữu ích nếu thử lại mà không khắc phục nguyên nhân cơ bản. Để xử lý các ngoại lệ như vậy, quá trình xử lý phải dừng ngay lập tức và ngoại lệ được gửi lại dưới dạng phản hồi cho hàng đợi thư đã chết. Một thông báo cũng sẽ gửi đến các hoạt động.

Ngoại lệ phi kinh doanh

Các lý do chính cho sự xuất hiện của các ngoại lệ không phải do kinh doanh là vấn đề hệ thống hoặc vấn đề kỹ thuật. Về bản chất, các loại ngoại lệ này có thể truy xuất lại và do đó, rất tốt để định cấu hìnhretry cơ chế để giải quyết các ngoại lệ này.

Các chiến lược xử lý ngoại lệ

Mule có năm chiến lược xử lý ngoại lệ sau:

Chiến lược ngoại lệ mặc định

Mule hoàn toàn áp dụng chiến lược này cho dòng Mule. Nó có thể xử lý tất cả các ngoại lệ trong quy trình của chúng tôi, nhưng nó cũng có thể bị ghi đè bằng cách thêm chiến lược ngoại lệ catch, Choice hoặc Rollback. Chiến lược ngoại lệ này sẽ khôi phục mọi giao dịch đang chờ xử lý và ghi lại các ngoại lệ. Một đặc điểm quan trọng của chiến lược ngoại lệ này là nó cũng sẽ ghi lại ngoại lệ nếu không có giao dịch.

Là chiến lược mặc định, Mule thực hiện điều này khi bất kỳ lỗi nào xảy ra trong luồng. Chúng tôi không thể cấu hình trong AnyPoint studio.

Chiến lược ngoại lệ khôi phục

Giả sử nếu không có giải pháp khả thi để sửa lỗi thì phải làm thế nào? Một giải pháp là sử dụng Chiến lược ngoại lệ khôi phục, chiến lược này sẽ khôi phục giao dịch cùng với việc gửi thông báo đến trình kết nối gửi đến của luồng mẹ để xử lý lại thông báo. Chiến lược này cũng rất hữu ích khi chúng ta muốn xử lý lại một tin nhắn.

Example

Chiến lược này có thể được áp dụng cho giao dịch ngân hàng mà tiền được gửi vào tài khoản séc / tiết kiệm. Chúng ta có thể định cấu hình chiến lược ngoại lệ khôi phục ở đây bởi vì trong trường hợp nếu có lỗi xảy ra trong quá trình giao dịch, chiến lược này sẽ chuyển thông báo trở lại đầu luồng để thử xử lý lại.

Chiến lược Bắt ngoại lệ

Chiến lược này nắm bắt tất cả các trường hợp ngoại lệ được ném trong luồng mẹ của nó. Nó ghi đè chiến lược ngoại lệ mặc định của Mule bằng cách xử lý tất cả các ngoại lệ do luồng cha ném ra. Chúng ta có thể sử dụng chiến lược bắt ngoại lệ để tránh lan truyền các ngoại lệ cho các trình kết nối gửi đến và cả luồng gốc.

Chiến lược này cũng đảm bảo rằng một giao dịch được xử lý bởi luồng không bị quay ngược trở lại khi một ngoại lệ xảy ra.

Example

Chiến lược này có thể được áp dụng cho hệ thống đặt vé máy bay trong đó chúng tôi có quy trình xử lý tin nhắn từ một hàng đợi. Trình bổ sung thông báo thêm một thuộc tính trên thông báo để chỉ định chỗ ngồi và sau đó gửi thông báo đến một hàng đợi khác.

Bây giờ nếu có bất kỳ lỗi nào xảy ra trong luồng này, thì thông báo sẽ đưa ra một ngoại lệ. Ở đây, chiến lược ngoại lệ bắt của chúng tôi có thể thêm tiêu đề với thông báo thích hợp và có thể đẩy thông báo đó ra khỏi luồng đến hàng đợi tiếp theo.

Chiến lược ngoại lệ lựa chọn

Trong trường hợp bạn muốn xử lý ngoại lệ dựa trên nội dung thư, thì chiến lược lựa chọn ngoại lệ sẽ là lựa chọn tốt nhất. Hoạt động của chiến lược ngoại lệ này sẽ như sau:

• Đầu tiên, nó bắt tất cả các ngoại lệ được ném trong luồng cha.
• Tiếp theo, nó sẽ kiểm tra nội dung tin nhắn và loại ngoại lệ.
• Và cuối cùng, nó định tuyến thông điệp đến chiến lược ngoại lệ thích hợp.

Sẽ có nhiều hơn một chiến lược ngoại lệ như Catch hoặc Rollback, được xác định trong chiến lược ngoại lệ lựa chọn. Trong trường hợp không có chiến lược nào được xác định theo chiến lược ngoại lệ này, thì nó sẽ định tuyến thông báo đến chiến lược ngoại lệ mặc định. Nó không bao giờ thực hiện bất kỳ hoạt động cam kết hoặc khôi phục hoặc tiêu thụ nào.

Tham chiếu Chiến lược Ngoại lệ

Điều này đề cập đến một chiến lược ngoại lệ chung được xác định trong một tệp cấu hình riêng biệt. Trong trường hợp khi một thông báo ném một ngoại lệ, chiến lược ngoại lệ này sẽ tham chiếu đến các tham số xử lý lỗi được xác định trong chiến lược ngoại lệ bắt, khôi phục hoặc lựa chọn toàn cục. Giống như chiến lược ngoại lệ lựa chọn, nó không bao giờ thực hiện bất kỳ hoạt động cam kết hoặc khôi phục hoặc tiêu thụ nào.