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 đặ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 quá trình xử lý lỗi cho các proxy.

Chủ đề này giả định rằng bạn đã hiểu chung về cách hoạt động của quá trình xử lý lỗi trong Edge, và biết 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 ở đây sẽ cũng giúp bạn điều hướng 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 tạo ra lỗi, Edge sẽ ngay lập tức nhập quy trình xảy ra 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 hai bit thông tin: một 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 loại bỏ thông báo lỗi này:

errorcode bao gồm một tiền tố và một 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 phần trên ví dụ: 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 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. Cho ví dụ: trong thông báo lỗi ở trên, "foo" xảy ra là tên của sự kiện chưa được giải quyết biến thông báo được dẫn 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 cụ thể cho lỗi 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 các biến rất hữu ích trong việc xử lý lỗi. Như đã giải thích trong chủ đề Xử lý lỗi, đây là phương pháp thông dụng để chặn các lỗi chính sách do hệ thống tạo ra và thực hiện hành động tiếp theo 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 khách hàng xem lỗi thực tế và mã trạng thái mà Edge trả về.

fault.name biến

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

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 nhớ là khi một chính sách kích hoạt lỗi, fault.name biến luôn được đặt thành tên lỗi.

Các 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à biến cờ [prefix].[policy_name].failed, được đặt thành đúng hoặc sai khi một chính sách này sẽ 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 -- tức là để kiểm tra xem đã xảy ra lỗi hay chưa. Dưới đây là cách tạo một điều kiện kiểm tra giá trị Cờ [prefix].[policy_name].failed. Để kiểm tra biến này một cách chính xác, bạn cần 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 chính sách name chứ không phải tên hiển thị. Thuộc tính này luôn có trong chính sách XML của định nghĩa.
  • 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ẽ hãy giải thích cách tìm tiền tố dưới đây.)

Để 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 phần này trường hợp, quy tắc lỗi sẽ chỉ thực thi nếu biến này là true. Sau đây là mẹo: do lỗi quy tắc có thể chứa nhiều bước, mẫu này là một cách hay để sắp xếp các quy tắc lỗi thành chặn.

<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ề Biến error và message

Biến error chỉ có trong luồng lỗi của một proxy. Bạn có thể nhận được thông tin hữu ích từ biến lỗi, chẳng hạn như thông báo lỗi, trạng thái mã, 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 quy trình lỗi và có thể dùng để có mục đích tương tự như biến error. Biến tin nhắn này đặc biệt vì là theo 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, biến này có thể được dùng để nhận/đặt giá trị phản hồi. Nếu bạn muốn biết thêm, hãy xem phần Sử dụng các trường hợp cho biến thông báo.

Tham khảo Tham chiếu biến để biết thông tin về tất cả các biến Edge, bao gồm error và message.