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 thiết lập khi xảy ra lỗi chính sách. Thông tin này là 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 đã nắm được kiến thức chung về cách hoạt động của quá trình xử lý lỗi trong Edge cũng như bạn biết các quy tắc về lỗi. Nếu bạn cần xem xét, hãy xem bài viết Xử lý lỗi. Thông tin ở đây cũng sẽ giúp bạn làm quen 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 chính sách báo lỗi, Edge sẽ ngay lập tức chuyển sang quy trình lỗi và tạo một 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 hai 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 giải mã nhanh thông báo lỗi này:

Mã lỗi bao gồm tiền tố và 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 đã gây ra lỗi. Trong ví dụ trên, bạn có thể biết rằng chính sách Extract Variables (Trích xuất biến) đã tạo ra lỗi và tên lỗi là SourceMessageNotAvailable.

faultstring (Chuỗi lỗi) chứa nội dung mô tả 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 phân giải hoặc bất kỳ yếu tố nào 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 giải quyết đượ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 cụ thể cho lỗi chính sách

Khi lỗi chính sách được kích hoạt, một số biến luồng cụ thể theo 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, bạn nên theo dõi các lỗi chính sách do hệ thống tạo ra và thực hiện thao tác tiếp theo như tạo một phản hồi lỗi tuỳ chỉnh. Ví dụ: vì lý do bảo mật, bạn nên ngăn khách hàng nhìn thấy 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). Thông thường, bạn nên đánh giá biến này để thực thi các quy tắc lỗi có điều kiện.

Dưới đây là ví dụ về một 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 nhớ 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à các nhà phát triển thường kiểm tra là cờ [prefix].[policy_name].failed. Cờ này sẽ được đặt thành true hoặc false khi thực thi một chính sách. Trong quy tắc lỗi, bạn nên kiểm tra xem khi nào giá trị là true (đúng) – tức là kiểm tra xem lỗi có xảy ra hay không. Dưới đây là cách tạo đ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 2 đ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 của chính sách, chứ không phải tên hiển thị. Thuộc tính này luôn có trong 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ạ, dưới đâ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à đúng. Mẹo hay: vì quy tắc lỗi có thể chứa nhiều bước, mẫu này là một cách hiệu quả để 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ề biến error và message

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

Vui lòng 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 của Edge, bao gồm cả error và message.