Phản mẫu: Sử dụng Chính sách RaiseFault trong điều kiện không phù hợp

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ính sáchRaiseFault cho phép nhà phát triển API bắt đầu một luồng lỗi, đặt biến lỗi trong nội dung phản hồi và đặt mã trạng thái phản hồi thích hợp. Bạn cũng có thể sử dụng RaiseFault chính sách để đặt các biến luồng liên quan đến lỗi, chẳng hạn như fault.name, fault.type, và fault.category. Bởi vì các biến này hiển thị trong dữ liệu phân tích và nhật ký truy cập Bộ định tuyến dùng để gỡ lỗi, điều quan trọng là phải xác định chính xác lỗi.

Bạn có thể sử dụng chính sách RaiseFault để coi các điều kiện cụ thể là lỗi, ngay cả khi một lỗi thực tế xảy ra không xảy ra trong một chính sách khác hoặc trong máy chủ phụ trợ của proxy API. Ví dụ: nếu bạn muốn proxy để gửi thông báo lỗi tuỳ chỉnh tới ứng dụng khách bất cứ khi nào phản hồi phụ trợ nội dung chứa chuỗi unavailable, thì bạn có thể gọi chính sách RaiseFault dưới dạng được hiển thị trong đoạn mã dưới đây: 

<!-- /antipatterns/examples/raise-fault-conditions-1.xml  -->
<TargetEndpoint name="default">
...
  <Response>
    <Step>
      <Name>RF-Service-Unavailable</Name>
      <Condition>(message.content Like "*unavailable*")</Condition>
   </Step>
  </Response>
...

Tên của chính sách RaiseFault hiển thị dưới dạng fault.name trong Giám sát API và dưới dạng x_apigee_fault_policy trong nhật ký truy cập của Analytics và Bộ định tuyến. Điều này giúp bạn dễ dàng chẩn đoán nguyên nhân lỗi.

Phản mẫu

Sử dụng chính sách RaiseFault trong FaultRules sau khi một chính sách khác đã báo lỗi

Hãy xem xét ví dụ bên dưới, trường hợp chính sách OAuthV2 trong luồng API Proxy bị lỗi với InvalidAccessToken . Khi không thành công, Edge sẽ đặt fault.name thành InvalidAccessToken, nhập vào luồng lỗi và thực thi mọi FaultRules đã xác định. Trong FaultRule có một chính sách RaiseFault được đặt tên là RaiseFault sẽ gửi phản hồi lỗi tuỳ chỉnh bất cứ khi nào một InvalidAccessToken lỗi xảy ra. Tuy nhiên, việc sử dụng chính sách RaiseFault trong FaultRule có nghĩa là fault.name biến sẽ bị ghi đè và che giấu nguyên nhân thực sự gây ra lỗi. 

<!-- /antipatterns/examples/raise-fault-conditions-2.xml  -->
<FaultRules>
  <FaultRule name="generic_raisefault">
    <Step>
        <Name>RaiseFault</Name>
        <Condition>(fault.name equals "invalid_access_token") or (fault.name equals "InvalidAccessToken")</Condition>
    </Step>
  </FaultRule>
</FaultRules>

Sử dụng chính sách RaiseFault trong FaultRule trong mọi điều kiện

Trong ví dụ bên dưới, chính sách RaiseFault có tên RaiseFault sẽ thực thi nếu fault.name không phải là RaiseFault: 

<!-- /antipatterns/examples/raise-fault-conditions-3.xml  -->
<FaultRules>
    <FaultRule name="fault_rule">
        ....
        <Step>
            <Name>RaiseFault</Name>
            <Condition>!(fault.name equals "RaiseFault")</Condition>
        </Step>
    </FaultRule>
</FaultRules>

Như trong tình huống đầu tiên, các biến lỗi chính fault.name, fault.code, và fault.policy bị ghi đè bằng tên của chính sách RaiseFault. Hành vi này khiến hầu như không thể xác định chính sách nào thực sự gây ra lỗi nếu không truy cập vào dấu vết tệp cho thấy lỗi hoặc tái hiện sự cố.

Sử dụng chính sách RaiseFault để trả về phản hồi HTTP 2xx bên ngoài luồng lỗi.

Trong ví dụ bên dưới, một chính sách RaiseFault có tên HandleOptionsRequest sẽ thực thi khi động từ yêu cầu là OPTIONS: 

<!-- /antipatterns/examples/raise-fault-conditions-4.xml  -->
<PreFlow name="PreFlow">
    <Request>
        …
        <Step>
            <Name>HandleOptionsRequest</Name>
            <Condition>(request.verb Equals "OPTIONS")</Condition>
        </Step>
        …
</PreFlow>

Mục đích là trả về phản hồi cho ứng dụng API ngay lập tức mà không cần xử lý các chính sách khác. Tuy nhiên, điều này sẽ dẫn đến dữ liệu phân tích sai lệch do các biến lỗi sẽ chứa dữ liệu Tên của chính sách RaiseFault, khiến việc gỡ lỗi proxy khó khăn hơn. Phương pháp đúng để triển khai hành vi mong muốn là sử dụng Luồng với các điều kiện đặc biệt, như được mô tả trong Thêm tính năng hỗ trợ CORS.

Tác động

Việc sử dụng chính sách RaiseFault như mô tả ở trên dẫn đến việc ghi đè các biến lỗi chính với Tên của chính sách RaiseFault thay vì tên của chính sách không đạt. Trong nhật ký truy cập Analytics và NGINX, các biến x_apigee_fault_code và x_apigee_fault_policy bị ghi đè. Trong tính năng Giám sát API, Fault Code và Fault Policy bị ghi đè. Hành vi này gây khó khăn cho việc khắc phục sự cố và xác định chính sách nào là nguyên nhân thực sự gây ra lỗi.

Trong ảnh chụp màn hình dưới đây của API Monitoring (Giám sát API), bạn có thể thấy rằng chính sách Mã lỗi và Chính sách về lỗi đã bị ghi đè thành RaiseFault chung khiến không thể xác định nguyên nhân gốc gây ra lỗi từ nhật ký:

Phương pháp hay nhất

Khi chính sách Edge phát sinh lỗi và bạn muốn tuỳ chỉnh thông báo phản hồi lỗi, hãy sử dụng chính sách AttributionMessage hoặc JavaScript thay vì chính sách RaiseFault.

Bạn nên sử dụng chính sách RaiseFault trong quy trình không xảy ra lỗi. Tức là chỉ sử dụng RaiseFault để xử lý điều kiện là lỗi, ngay cả khi lỗi thực tế không xảy ra trong chính sách hoặc trong máy chủ phụ trợ của Proxy API. Ví dụ: bạn có thể sử dụng chính sách RaiseFault để báo hiệu rằng thông tin đầu vào bắt buộc tham số bị thiếu hoặc có cú pháp không chính xác.

Bạn cũng có thể sử dụng RaiseFault trong quy tắc lỗi nếu bạn muốn phát hiện lỗi trong quá trình xử lý lỗi. Ví dụ: chính trình xử lý lỗi của bạn cũng có thể gây ra lỗi mà bạn muốn báo hiệu bằng cách sử dụng RaiseFault.

Tài liệu đọc thêm