Những điều bạn cần biết về lỗi chính sách

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Chủ đề này mô tả cấu trúc của lỗi chính sách và các loại biến luồng được đặt khi lỗi chính sách xảy ra. Thông tin này rất cần thiết nếu bạn đang thiết kế và triển khai tính năng xử lý lỗi cho proxy.

Chủ đề này giả định rằng bạn có hiểu biết chung về cách hoạt động của tính năng xử lý lỗi trong Edge và bạn biết các quy tắc lỗi là gì. Nếu bạn cần xem xét, hãy xem phần Xử lý lỗi. Thông tin tại đây cũng sẽ giúp bạn điều hướng và sử dụng Tài liệu tham khảo về lỗi liên quan đến chính sách.

Giới thiệu về phản hồi lỗi chính sách mặc định

Khi một chính sách gửi lỗi, Edge sẽ ngay lập tức chuyển sang luồng lỗi và tạo thông báo lỗi. Thông báo do hệ thống tạo ra là một đối tượng JSON bao gồm 2 bit thông tin: mã lỗi và chuỗi lỗi.

Ví dụ:

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
   }
}

Hãy nhanh chóng loại bỏ thông báo lỗi này:

errorcode bao gồm một tiền tố và một tên lỗi như sau: [prefix].[error_name]. Trong ví dụ trên, "steps.extractvariables" là tiền tố và SourceMessageNotAvailable là tên lỗi. Tiền tố này cho bạn biết loại chính sách nào đã tạo ra lỗi. Trong ví dụ trên, bạn có thể biết rằng chính sách Trích xuất biến đã tạo ra lỗi và tên lỗi là SourceMessageNotAvailable.

Chuỗi lỗi chứa nội dung mô tả về lỗi. Chuỗi lỗi thường bao gồm các gợi ý giúp bạn tìm ra vấn đề cụ thể đã gây ra lỗi, chẳng hạn như tên chính sách, tên của một biến chưa được giải quyết hoặc bất kỳ yếu tố nào góp phần gây ra lỗi. Ví dụ: trong thông báo lỗi ở trên, "foo" là tên của một biến thông báo chưa được phân giải được tham chiếu trong chính sách và "ParseJsonResponse" là tên của chính sách đã kích hoạt lỗi.

Các biến dành riêng cho lỗi vi phạm chính sách

Khi một lỗi chính sách được kích hoạt, một số biến luồng dành riêng cho lỗi sẽ được điền. Các biến này cực kỳ hữu ích trong việc xử lý lỗi. Như đã giải thích trong chủ đề Xử lý lỗi, thông thường, bạn nên phát hiện lỗi chính sách do hệ thống tạo và thực hiện một hành động tiếp theo, chẳng hạn như tạo phản hồi lỗi tuỳ chỉnh. Ví dụ: vì lý do bảo mật, bạn có thể muốn ngăn ứng dụng xem các lỗi và mã trạng thái thực tế mà Edge trả về.

Biến fault.name

Khi xảy ra lỗi, chính sách sẽ đặt biến luồng fault.name thành phần error_name của mã lỗi (như mô tả trong phần trước). Rất phổ biến khi đánh giá biến này để thực thi các quy tắc lỗi theo điều kiện.

Dưới đây là ví dụ về quy tắc lỗi giúp kiểm tra giá trị của fault.name:

<faultrule name="VariableOfNonMsgType"<>/faultrule><FaultRule name="Source Message Not Available Fault">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
    </Step>
</FaultRule>

Điều cần lưu ý là khi một chính sách kích hoạt lỗi, biến fault.name sẽ luôn được đặt thành tên lỗi.

Biến [prefix].[policy_name].failed

Ngoài fault.name, một biến khác mà nhà phát triển thường kiểm tra là cờ [prefix].[policy_name].failed. Cờ này được đặt thành true hoặc false khi một chính sách thực thi. Trong quy tắc lỗi, bạn nên kiểm tra xem khi nào giá trị này là true (đúng) – tức là để kiểm tra xem có lỗi xảy ra hay không. Dưới đây là cách tạo một điều kiện kiểm tra cờ [prefix].[policy_name].failed. Để kiểm tra chính xác biến này, bạn cần biết hai điều:

• Tên của chính sách mà bạn đang kiểm tra. Đây là giá trị của thuộc tính tên chính sách, chứ không phải tên hiển thị. Thuộc tính này luôn có trong tệp XML của định nghĩa chính sách.
• Tiền tố dành riêng cho loại chính sách mà bạn đang kiểm tra. (Chúng tôi sẽ giải thích cách tìm tiền tố ở bên dưới.)

Để minh hoạ, sau đây là một ví dụ khác về quy tắc lỗi. Lưu ý trong điều kiện bên ngoài, cách tạo tên biến [prefix].[policy_name].failed. Trong trường hợp này, tiền tố là extractvariables và tên chính sách là ParseJsonResponse. Trong trường hợp này, quy tắc lỗi sẽ chỉ thực thi nếu biến này là true. Mẹo sau đây: vì các quy tắc lỗi có thể chứa nhiều bước, nên mẫu này là một cách hay để sắp xếp các quy tắc lỗi thành các khối.

<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Extract Variable Faults">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
    </Step>
    <Condition>(extractvariables.ParseJsonResponse.failed = true) </Condition>
</FaultRule>

Giới thiệu về các biến error và message

Biến error chỉ có trong luồng lỗi của một proxy. Bạn có thể lấy thông tin hữu ích từ biến lỗi, chẳng hạn như thông báo lỗi, mã trạng thái, cụm từ lý do, v.v. Mẫu định dạng cho biến lỗi là:

error.[error_component] = [value]

Ví dụ:

error.message = "request message is not available for ExtractVariable: ParseJsonResponse inch

và

error.status.code = "500"

Biến message cũng có trong luồng lỗi và có thể được dùng cho các mục đích tương tự như biến error. Biến tin nhắn này đặc biệt vì dựa trên ngữ cảnh. Trong luồng yêu cầu, biến này hoạt động như một biến yêu cầu và trong luồng phản hồi, bạn có thể dùng biến này để nhận/đặt giá trị phản hồi. Nếu bạn muốn biết thêm, hãy xem phần Các trường hợp sử dụng cho biến thông báo.

Hãy tham khảo Tài liệu tham khảo về biến để biết thông tin về tất cả các biến Edge, bao gồm cả error và message.