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.
Truy cập vào tài liệu 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 xảy ra lỗi chính sách. Thông tin này rất cần thiết nếu bạn đang thiết kế và triển khai quy trình xử lý lỗi cho các proxy.

Chủ đề này giả định rằng bạn hiểu rõ cách xử lý lỗi trong Edge và bạn biết quy tắc lỗi là gì. Nếu bạn cần xem lại, hãy xem phần Xử lý lỗi. Thông tin tại đây cũng sẽ giúp bạn tìm hiểu và sử dụng Tài liệu tham khảo về lỗi 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ặp lỗi, Edge sẽ ngay lập tức chuyển sang quy trình xử lý lỗi và tạo thông báo lỗi. Thông báo do hệ thống tạo này là một đối tượng JSON bao gồm 2 phần thông tin: errorcode và faultstring.

Ví dụ:

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

Hãy nhanh chóng phân tích 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ố cho biết loại chính sách đã 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.

faultstring chứa nội dung mô tả về lỗi. Chuỗi lỗi thường bao gồm các manh mối giúp bạn tìm ra vấn đề cụ thể gây ra lỗi, chẳng hạn như tên của 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 về chính sách

Khi 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 sẵn. Những 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, bạn nên chặn các 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 các ứng dụng khách nhìn thấy lỗi thực tế và mã trạng thái mà Edge trả về.

Biến fault.name

Khi một chính sách gặp 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). Việc đánh giá biến này để thực thi có điều kiện các quy tắc lỗi là điều rất phổ biến.

Sau đây là một ví dụ về quy tắc lỗi kiểm thử 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 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 các quy tắc lỗi, bạn nên kiểm tra xem khi nào giá trị là true, tức là kiểm tra xem có xảy ra lỗi hay không. Sau đâ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 trong chính sách, chứ không phải tên hiển thị. Thuộc tính này luôn được đưa vào XML định nghĩa chính sách.
  • Một 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. Hãy lưu ý cách tên biến [prefix].[policy_name].failed được tạo trong điều kiện bên ngoài. 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 có giá trị true. Và đây là một mẹo: 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"

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 thông báo là biến đặc biệt vì nó mang tính ngữ cảnh. Trong một luồng yêu cầu, nó hoạt động như một biến yêu cầu và trong một luồng phản hồi, bạn có thể dùng biến này để nhận/đặt các giá trị phản hồi. Nếu bạn muốn biết thêm, hãy xem bài viết Các trường hợp sử dụng 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.