Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về
Apigee X. thông tin
Bất kỳ mô hình lập trình ứng dụng nào cũng bao gồm một phương thức để kiểm soát quy trình xử lý. Trong proxy API, việc này được thực hiện với luồng. Đối với các quy trình, bạn thêm logic, câu lệnh điều kiện, cách xử lý lỗi, v.v. Bạn sử dụng luồng để kiểm soát những gì xảy ra và thời điểm.
Luồng là các giai đoạn tuần tự dọc theo đường dẫn xử lý yêu cầu API. Khi thêm logic proxy, chẳng hạn như để xác minh khoá API, bạn sẽ thêm logic đó dưới dạng một bước trong trình tự do quy trình chỉ định. Khi xác định một điều kiện để chỉ định liệu và khi nào logic được thực thi, bạn sẽ thêm điều kiện đó vào một luồng.
Ví dụ về cấu hình luồng sau đây xác định một luồng trong đó chính sách VerifyAPIKey thực thi if đường dẫn yêu cầu đến kết thúc bằng / và động từ HTTP của yêu cầu là GET.
<Flow name="Get Food Carts">
<Description>Get Food Carts</Description>
<Request>
<Step>
<Name>Verify-API-Key</Name>
</Step>
</Request>
<Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>
Giá trị Verify-API-Key trong phần tử <Name> của luồng đóng vai trò
bao gồm một chính sách được định cấu hình ở nơi khác trong proxy bằng XML, chẳng hạn như sau:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key">
<DisplayName>Verify API Key</DisplayName>
<Properties/>
<APIKey ref="request.header.x-api-key"/>
</VerifyAPIKey>
Thiết kế trình tự thực thi luồng
Bạn cấu trúc các luồng để có thể yêu cầu logic được thực thi theo trình tự phù hợp trên đường dẫn xử lý.
Khi quyết định vị trí thêm logic, trước tiên, bạn sẽ chọn thêm logic đó vào điểm cuối proxy hay điểm cuối đích. Proxy API chia mã giữa mã tương tác với ứng dụng khách của proxy (điểm cuối proxy) và mã không bắt buộc tương tác với mục tiêu phụ trợ của proxy, nếu có (điểm cuối mục tiêu).
Cả hai điểm cuối đều chứa các luồng như mô tả ở đây:
| Loại điểm cuối | Nội dung mô tả | Luồng được hỗ trợ |
|---|---|---|
| ProxyEndpoint | Chứa các luồng proxy API gần nhất với ứng dụng. Cung cấp các vị trí để logic thao tác trước tiên theo yêu cầu từ ứng dụng khách rồi sau đó mới thực hiện trong phản hồi với ứng dụng. | PreFlow, luồng có điều kiện, PostFlow, PostClientFlow |
| TargetEndpoint | Chứa các luồng proxy API gần nhất với tài nguyên phụ trợ. Cung cấp các vị trí cho logic để chuẩn bị yêu cầu, sau đó xử lý phản hồi từ một tài nguyên phụ trợ. | PreFlow, luồng có điều kiện, PostFlow |
Bạn định cấu hình quy trình bằng XML chỉ định những gì sẽ xảy ra và theo thứ tự. Hình minh hoạ sau đây cho thấy cách sắp xếp thứ tự các luồng trong một điểm cuối proxy và điểm cuối mục tiêu:
Mỗi điểm cuối proxy và điểm cuối đích chứa các luồng mà bạn có thể sắp xếp theo trình tự sau đây:
| Vị trí | Loại luồng | Nội dung mô tả |
|---|---|---|
| 1 | PreFlow |
Hữu ích khi bạn cần đảm bảo rằng một số mã nhất định sẽ thực thi trước khi bất cứ điều gì khác xảy ra. Nếu PreFlow nằm trong một điểm cuối đích, thì nó sẽ thực thi sau PostFlow của điểm cuối proxy. |
| 2 | Luồng có điều kiện |
Vị trí cho logic có điều kiện. Thực thi sau PreFlow và trước PostFlow.
Chỉ một luồng có điều kiện được thực thi cho mỗi phân đoạn – luồng đầu tiên có điều kiện được đánh giá là true. Điều đó có nghĩa là bạn có thể thực thi một luồng có điều kiện trong mỗi luồng:
|
| 3 | PostFlow |
Một nơi phù hợp để ghi nhật ký dữ liệu, gửi thông báo cho biết có điều gì đó đã xảy ra trong khi xử lý yêu cầu, v.v. Thực thi sau các luồng có điều kiện và PreFlow. Nếu PostFlow nằm trong một điểm cuối proxy và có một điểm cuối đích, thì điểm cuối proxy PostFlow sẽ thực thi trước điểm cuối mục tiêu PreFlow. |
| 4 | PostClientFlow (chỉ luồng proxy) | Quy trình ghi nhật ký thông báo sau khi một phản hồi được trả về máy khách. |
Để mã thực thi trước bằng PreFlow
PreFlow rất hữu ích khi bạn cần đảm bảo rằng một số mã nhất định sẽ thực thi trước khi bất cứ điều gì khác xảy ra.
Trong điểm cuối proxy, PreFlow là một nơi tuyệt vời cho mã xác thực ứng dụng và giới hạn lưu lượng truy cập từ ứng dụng. Trong một điểm cuối mục tiêu, nơi điểm cuối đó bắt đầu chuẩn bị để gửi yêu cầu tới một mục tiêu phụ trợ, PreFlow là công cụ thích hợp cho những bước đầu tiên để chuẩn bị gửi yêu cầu.
Ví dụ: bạn thường không muốn phục vụ khách hàng đã vượt quá hạn mức của họ. Để hỗ trợ các yêu cầu này, bạn cần đặt chính sách bảo mật và hạn mức vào phân đoạn PreFlow. Bằng cách đó, bạn không cần lo lắng về việc điều kiện sẽ không đánh giá được trong luồng có điều kiện sau này. Các chính sách trong quy trình này sẽ luôn thực thi trước khi diễn ra bất kỳ quá trình xử lý nào khác.
Trong ví dụ sau, các chính sách SpikeArrest và Hạn mức sẽ thực thi trước khi xử lý thẻ được chuyển đến các luồng có điều kiện.
<PreFlow name="MyPreFlow">
<Request>
<Step>
<Name>Spike-Arrest</Name>
</Step>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Response/>
</PreFlow>
Yêu cầu mã thực thi theo điều kiện với một luồng có điều kiện
Giữa PreFlow và PostFlow, bạn có thể có các luồng thực thi theo điều kiện. Điều này cho phép bạn định cấu hình nhiều trình tự logic, nhưng chỉ có một trình tự được thực thi dựa trên trạng thái của proxy. Luồng có điều kiện là không bắt buộc nếu bạn có thể thực thi mọi logic trong PreFlow hoặc PostFlow mà không cần điều kiện nào (nói cách khác, chỉ một đường dẫn qua điểm cuối được hỗ trợ).
Mỗi luồng chỉ định một điều kiện kiểm thử các giá trị trạng thái khác nhau. Cách này phân nhánh một cách hiệu quả quá trình thực thi dựa trên các điều kiện. Ví dụ: bạn có thể chỉ chuyển đổi XML thành JSON khi ứng dụng yêu cầu đang chạy trên thiết bị di động.
Ở đây, giới hạn hạn mức chỉ được thực thi nếu yêu cầu là một yêu cầu GET có mẫu URI /issue/** (/issue/ với bất kỳ nội dung nào trong URI sau dấu gạch chéo lên sau cùng).
<Flow name="MyFlow">
<Description/>
<Request>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Response/>
<Condition>(proxy.pathsuffix MatchesPath "/issue/**") and (request.verb = "GET")</Condition>
</Flow>
Bạn sẽ sử dụng các biến luồng để chỉ định các điều kiện. Để biết thêm về cách sử dụng các biến trong các điều kiện, hãy xem phần Điều kiện có các biến luồng.
Để biết ví dụ về cách sử dụng tính năng so khớp mẫu trong các điều kiện, hãy xem phần So khớp mẫu.
Yêu cầu mã thực thi sau logic cốt lõi bằng PostFlow
PostFlow là một nơi tuyệt vời để thực hiện các hành động sau logic chính của điểm cuối và trước khi quá trình xử lý điểm cuối hoàn tất. PostFlow thực thi sau các luồng có điều kiện và PreFlow.
PostFlow là một nơi phù hợp để ghi lại một số dữ liệu, gửi thông báo về việc đã xảy ra sự cố, biến đổi định dạng thông báo phản hồi, v.v.
Trong ví dụ sau, chính sáchassignMessage có tên là SetResponseHeaders sẽ đặt tiêu đề của thông báo phản hồi trước khi Apigee Edge gửi lại phản hồi cho ứng dụng khách.
<PostFlow>
<Response>
<Step>
<Name>SetResponseHeaders</Name>
</Step>
</Response>
</PostFlow>
Yêu cầu mã thực thi sau khi ứng dụng nhận được phản hồi của proxy bằng PostClientFlow
PostClientFlow có thể bao gồm các chính sách sau:
- Chính sách về chú thích cho phần mở rộng
- Chính sách về chú thích quy trình*
- Chính sách về việc ghi nhật ký thư
- Chính sách về chú thích dịch vụ
* Chính sách Flowchú thích chỉ có thể gọi các luồng được chia sẻ mà chính các luồng đó đáp ứng các tiêu chí để được đưa vào PostClientFlow (tức là chỉ chứa các chính sách tương thích).
Nếu bạn đưa một quy tắc vào, thì PostClientFlow sẽ là luồng cuối cùng cần thực thi, thực thi sau khi một phản hồi được gửi đến ứng dụng.
PostClientFlow rất phù hợp cho việc ghi nhật ký cuối cùng. Ngoài ra, bạn có thể ghi nhật ký dấu thời gian bắt đầu và kết thúc của tin nhắn phản hồi.
Dưới đây là ví dụ về PostClientFlow có đính kèm chính sách MessageLogging.
...
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<PostClientFlow>
<Request/>
<Response>
<Step>
<Name>Message-Logging-1</Name>
</Step>
</Response>
</PostClientFlow>
...
Video: Hãy xem video ngắn này hướng dẫn cách tạo PostClientFlow bằng chính sách MessageLogging trong loạt video Bốn phút dành cho nhà phát triển (4MV4D).
Để biết thêm thông tin, hãy xem các bài viết sau:
- Tài liệu tham khảo về cấu hình proxy API
- Hướng dẫn : Bài viết trong cộng đồng Apigee Edge – Luồng ứng dụng khách
Thêm logic vào luồng
Khi thêm logic vào proxy của mình, bạn thực hiện việc này bằng cách thêm chính sách vào luồng của proxy. Cũng giống như các luồng thực thi theo trình tự (PreFlow, Flow rồi PostFlow, như mô tả trong chủ đề này), nội dung của một luồng thực thi theo trình tự.
Ví dụ sau đây về cấu hình quy trình tham chiếu đến ba chính sách (được định cấu hình ở nơi khác trong các tệp XML riêng). Chính sách mà Verify-API-Key tham chiếu thực thi trước chính sách mà Remove-API-Key tham chiếu; cả hai chính sách đều tuân theo chính sách do Quota biểu thị.
<Flow name="Get Food Cart Menus">
<Description>Get Food Cart Menus</Description>
<Request>
<Step>
<Name>Verify-API-Key</Name>
</Step>
<Step>
<Name>Remove-API-Key</Name>
</Step>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>
Bảng điều khiển Apigee Edge trình bày trình tự các chính sách này dưới dạng một hàng biểu tượng, trong đó mỗi biểu tượng đại diện cho chính sách.
Quy trình gỡ lỗi
Công cụ theo dõi Apigee Edge cung cấp một cách biểu đồ để xem logic trong proxy API của bạn thực thi như thế nào sau một yêu cầu. Công cụ này minh hoạ quá trình xử lý giữa yêu cầu và phản hồi. Tệp này không minh hoạ cụ thể sự phân tách giữa PreFlow, luồng có điều kiện và PostFlow.
Để biết thêm về cách theo dõi proxy, hãy xem phần Sử dụng công cụ Theo dõi.
Xử lý lỗi trong luồng
Bạn có thể báo lỗi từ nhiều vị trí trong proxy API, bao gồm cả lỗi từ các luồng.
Ví dụ sau đây là khổ thơ phản hồi từ một PreFlow trong một điểm cuối mục tiêu. Nói cách khác, đây là mã sẽ thực thi ngay sau khi nhận được phản hồi từ một mục tiêu phụ trợ. Trong ví dụ này, lỗi sẽ xảy ra nếu phản hồi từ mục tiêu không phải là 200 (thành công).
<PreFlow name="PreFlow">
<Response>
<Step>
<Name>RaiseFault</Name>
<Condition>(response.status.code GreaterThan "200")</Condition>
</Step>
</Response>
</PreFlow>
Để biết thêm về cách xử lý lỗi, hãy xem phần Xử lý lỗi.