Tham chiếu cấu hình proxy API

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

Là một nhà phát triển làm việc với Apigee Edge, các hoạt động phát triển chính của bạn liên quan đến việc định cấu hình các proxy API hoạt động như proxy cho các API hoặc dịch vụ phụ trợ. Tài liệu này là tài liệu tham khảo về tất cả các phần tử cấu hình mà bạn có thể sử dụng khi tạo proxy API.

Nếu đang tìm hiểu cách tạo proxy API, bạn nên bắt đầu với chủ đề Tạo một proxy API đơn giản.

Sau đây là những cách phổ biến nhất để chỉnh sửa cấu hình proxy:

• Sử dụng trình chỉnh sửa XML trong giao diện người dùng Edge
• Tải cấu hình xuống và chỉnh sửa cục bộ, như mô tả trong phần Phát triển cục bộ cấu hình proxy.

Phát triển cục bộ các cấu hình proxy

Bạn có thể tải cấu hình proxy xuống để chỉnh sửa trên máy cục bộ. Khi hoàn tất, bạn sẽ tải kết quả lên Edge. Phương pháp này cho phép bạn tích hợp các cấu hình proxy vào hệ thống kiểm soát nguồn, phiên bản và các quy trình làm việc dùng chung khác. Ngoài ra, bằng cách làm việc trên cấu hình proxy cục bộ, bạn có thể sử dụng trình chỉnh sửa XML và các công cụ xác thực của riêng mình.

Phần này mô tả cách sử dụng giao diện người dùng để tải một cấu hình proxy hiện có xuống, chỉnh sửa cấu hình đó, rồi tải lại lên Edge để triển khai. Bạn cũng có thể sử dụng apigeetool để tải xuống và triển khai cấu hình proxy mới (bằng cách sử dụng các lệnh fetchproxy và deployproxy tương ứng).

Cách chỉnh sửa cấu hình proxy cục bộ bằng giao diện người dùng:

1. Tải cấu hình hiện tại của proxy xuống trong giao diện người dùng Edge. (Trong chế độ xem API Proxies (API Proxy), hãy chọn Project > Download Revision (Dự án > Tải bản sửa đổi xuống).)
2. Trên máy cục bộ, hãy tạo một thư mục mới và mở rộng tệp ZIP đã tải xuống vào thư mục đó.

   Để mở rộng tệp ZIP, bạn có thể sử dụng một tiện ích như unzip, như ví dụ sau đây minh hoạ:

   mkdir myappdir
   unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

   Nội dung đã mở rộng của tệp ZIP phải tương tự như cấu trúc được mô tả trong cấu trúc proxy API.

3. Chỉnh sửa các tệp nguồn nếu cần. Để biết nội dung mô tả về các tệp nguồn trong cấu hình proxy, hãy xem Tệp cấu hình và cấu trúc thư mục của một proxy API.

   Ví dụ: để bật tính năng giám sát tình trạng trong proxy API, hãy chỉnh sửa tệp cấu hình TargetEndpoint trong thư mục /apiproxy/targets/. Tệp mặc định trong thư mục này là default.xml, mặc dù có thể có các tệp có tên khác nếu bạn sử dụng mục tiêu có điều kiện.

   Trong trường hợp này, nếu tệp cấu hình TargetEndpoint và thư mục của tệp đó không tồn tại, hãy tạo chúng.

4. Sau khi chỉnh sửa xong các tệp cấu hình proxy, hãy nhớ lưu các thay đổi.
5. Chuyển sang thư mục mới mà bạn đã tạo khi giải nén tệp ZIP (thư mục gốc của các tệp cấu hình đã giải nén).

   Ví dụ: nếu bạn mở rộng các tệp vào thư mục /myappdir, hãy thay đổi thành thư mục đó, như ví dụ sau đây cho thấy:

   cd myappdir

   Bạn nên chuyển sang thư mục này trước khi lưu trữ lại các tệp cấu hình proxy vì bạn không muốn thư mục /myappdir có trong tệp ZIP. Thư mục cấp cao nhất trong tệp ZIP phải là /apiproxy.

6. Lưu trữ lại các tệp cấu hình proxy, bao gồm cả các tệp mới hoặc đã thay đổi. Bạn có thể sử dụng một tiện ích như zip, như trong ví dụ sau:

   zip my-new-proxy.zip -r .

   Thư mục cấp cao nhất trong tệp ZIP phải là /apiproxy.

   Không có yêu cầu đặc biệt nào đối với tên tệp ZIP. Ví dụ: bạn không cần tăng số phiên bản hoặc chỉ định ngày trong tên tệp, nhưng việc này có thể hữu ích cho việc gỡ lỗi hoặc kiểm soát nguồn.

   Edge sẽ tự động tăng số phiên bản của cấu hình proxy mới cho bạn khi bạn tải cấu hình đó lên.

7. Tải cấu hình proxy mới lên bằng giao diện người dùng Edge. (Trong chế độ xem API Proxies (API Proxy), hãy chọn Project > Upload a New Revision (Dự án > Tải phiên bản mới lên).)

   Nếu bạn gặp lỗi như Bundle is invalid. Empty bundle., hãy đảm bảo rằng thư mục cấp cao nhất của tệp ZIP là /apiproxy. Nếu không, hãy lưu trữ lại các tệp cấu hình proxy từ thư mục gốc của thư mục đã mở rộng.

   Sau khi bạn tải cấu hình proxy mới lên, Edge sẽ tăng số phiên bản và hiển thị số đó trong chế độ xem Tóm tắt phiên bản.

   Edge không triển khai bản sửa đổi mới cho bạn sau khi bạn tải bản sửa đổi đó lên bằng giao diện người dùng.

8. Triển khai bản sửa đổi mới.

Để biết thêm thông tin, hãy xem Hướng dẫn: Cách tải một proxy xuống bằng giao diện người dùng và API quản lý trong Cộng đồng Apigee.

Cấu trúc proxy API

Một proxy API bao gồm cấu hình sau:

Cấu trúc thư mục và nội dung của proxy API

Các thành phần trong bảng trên được xác định bằng các tệp cấu hình trong cấu trúc thư mục sau:

Tệp cấu hình và cấu trúc thư mục của một proxy API

Phần này giải thích các tệp cấu hình và cấu trúc thư mục của một proxy API.

• Cấu hình cơ bản
• ProxyEndpoint
• TargetEndpoint
  • Cấu hình TargetEndpoint TLS/SSL
• Chính sách
• Luồng
• Tài nguyên

Cấu hình cơ bản

/apiproxy/weatherapi.xml

Cấu hình cơ bản cho một proxy API, xác định tên của proxy API. Tên này không được trùng lặp trong một tổ chức.

Cấu hình mẫu:

<APIProxy name="weatherapi">
</APIProxy>

Các phần tử cấu hình cơ bản

ProxyEndpoint

Hình ảnh sau đây cho thấy quy trình yêu cầu/phản hồi:

/apiproxy/proxies/default.xml

Cấu hình ProxyEndpoint xác định giao diện đầu vào (hướng đến máy khách) cho một proxy API. Khi định cấu hình ProxyEndpoint, bạn đang thiết lập một cấu hình mạng xác định cách các ứng dụng khách ("ứng dụng") sẽ gọi API được uỷ quyền.

Cấu hình ProxyEndpoint mẫu sau đây sẽ được lưu trữ trong /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Các phần tử cấu hình bắt buộc trong một ProxyEndpoint cơ bản là:

Các phần tử cấu hình ProxyEndpoint

Cách định cấu hình RouteRules

TargetEndpoint được đặt tên đề cập đến một tệp cấu hình trong /apiproxy/targets mà RouteRule chuyển tiếp một yêu cầu sau khi được ProxyEndpoint xử lý.

Ví dụ: RouteRule sau đây đề cập đến cấu hình /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Gọi trực tiếp URL

ProxyEndpoint cũng có thể trực tiếp gọi một dịch vụ phụ trợ. Lệnh gọi URL trực tiếp sẽ bỏ qua mọi cấu hình TargetEndpoints có tên trong /apiproxy/targets). Vì lý do này, TargetEndpoint là một cấu hình proxy API không bắt buộc, mặc dù trên thực tế, bạn không nên dùng lệnh gọi trực tiếp từ ProxyEndpoint.

Ví dụ: RouteRule sau đây thực hiện một lệnh gọi HTTP đến http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Tuyến đường có điều kiện

Bạn có thể xâu chuỗi RouteRules để hỗ trợ định tuyến động trong thời gian chạy. Các yêu cầu đến có thể được định tuyến đến các cấu hình TargetEndpoint được đặt tên, trực tiếp đến URL hoặc kết hợp cả hai, dựa trên tiêu đề HTTP, nội dung thông báo, tham số truy vấn hoặc thông tin theo bối cảnh như thời gian trong ngày, ngôn ngữ, v.v.

Conditional RouteRules hoạt động giống như các câu lệnh có điều kiện khác trên Apigee Edge. Xem Thông tin tham khảo về điều kiện và Thông tin tham khảo về biến.

Ví dụ: tổ hợp RouteRule sau đây trước tiên sẽ đánh giá yêu cầu đến để xác minh giá trị của tiêu đề HTTP. Nếu tiêu đề HTTP routeTo có giá trị TargetEndpoint1, thì yêu cầu sẽ được chuyển tiếp đến TargetEndpoint có tên TargetEndpoint1. Nếu không, yêu cầu đến sẽ được chuyển tiếp đến http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Null Routes

Bạn có thể xác định một RouteRule rỗng để hỗ trợ các trường hợp mà thông báo yêu cầu không cần được chuyển tiếp đến TargetEndpoint. Điều này hữu ích khi ProxyEndpoint thực hiện tất cả quy trình xử lý cần thiết, chẳng hạn như bằng cách sử dụng JavaScript để gọi một dịch vụ bên ngoài hoặc truy xuất dữ liệu từ một bảng tra cứu vào kho khoá/giá trị của Dịch vụ API.

Ví dụ: đoạn mã sau đây xác định một Tuyến đường rỗng:

<RouteRule name="GoNowhere"/>

Các tuyến đường rỗng có điều kiện có thể hữu ích. Trong ví dụ sau, một Tuyến đường rỗng được định cấu hình để thực thi khi tiêu đề HTTP request.header.X-DoNothing có giá trị khác null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Hãy nhớ rằng bạn có thể liên kết RouteRules, vì vậy, một Route có giá trị rỗng có điều kiện thường sẽ là một thành phần của một tập hợp RouteRules được thiết kế để hỗ trợ định tuyến có điều kiện.

Một trường hợp sử dụng thực tế của Tuyến đường rỗng có điều kiện là để hỗ trợ lưu vào bộ nhớ đệm. Bằng cách sử dụng giá trị của biến do chính sách Bộ nhớ đệm đặt, bạn có thể định cấu hình một proxy API để thực thi Tuyến đường rỗng khi một mục được phân phát từ bộ nhớ đệm.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

TargetEndpoint là phiên bản tương đương đầu ra của ProxyEndpoint. TargetEndpoint hoạt động như một máy khách cho dịch vụ hoặc API phụ trợ – nó gửi yêu cầu và nhận phản hồi.

Một proxy API không cần có TargetEndpoints. Bạn có thể định cấu hình ProxyEndpoints để gọi trực tiếp các URL. Một proxy API không có TargetEndpoints thường chứa một ProxyEndpoint gọi trực tiếp một dịch vụ phụ trợ hoặc được định cấu hình để gọi một dịch vụ bằng Java hoặc JavaScript.

Cấu hình TargetEndpoint

/targets/default.xml

TargetEndpoint xác định kết nối đi từ Apigee Edge đến một dịch vụ hoặc tài nguyên khác.

Dưới đây là một cấu hình TargetEndpoint mẫu:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Các phần tử cấu hình TargetEndpoint

TargetEndpoint có thể gọi một mục tiêu theo một trong những cách sau:

• HTTPTargetConnection cho các lệnh gọi HTTP(S)
• LocalTargetConnection để liên kết proxy với proxy cục bộ
• ScriptTarget cho các lệnh gọi đến tập lệnh Node.js được lưu trữ trên Edge

Chỉ định cấu hình một trong các thuộc tính này trong TargetEndpoint.

Cấu hình TargetEndpoint TLS/SSL

TargetEndpoints thường cần quản lý các kết nối HTTPS với cơ sở hạ tầng phụ trợ không đồng nhất. Vì lý do này, một số chế độ cài đặt cấu hình TLS/SSL được hỗ trợ.

TLS/SSL Các phần tử cấu hình TargetEndpoint

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

TargetEndpoint mẫu có bật chế độ xác thực ứng dụng đi

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Để biết hướng dẫn chi tiết, hãy xem phần Định cấu hình TLS từ Edge đến phần phụ trợ (Cloud và Cloud riêng tư).

Sử dụng các biến luồng để đặt giá trị TLS/SSL một cách linh động

Bạn cũng có thể đặt thông tin chi tiết về TLS/SSL một cách linh hoạt để hỗ trợ các yêu cầu linh hoạt về thời gian chạy. Ví dụ: nếu proxy của bạn kết nối với 2 mục tiêu có thể khác nhau (mục tiêu kiểm thử và mục tiêu phát hành công khai), bạn có thể để proxy API của mình tự động phát hiện môi trường mà proxy đang gọi và đặt động các tham chiếu đến kho khoá và kho tin cậy thích hợp. Bài viết sau đây trên Cộng đồng Apigee giải thích chi tiết hơn về trường hợp này và cung cấp các ví dụ về proxy API có thể triển khai: Dynamic SSLInfo for TargetEndpoint using variable reference (SSLInfo động cho TargetEndpoint bằng cách sử dụng tham chiếu biến).

Trong ví dụ sau về cách đặt thẻ <SSLInfo> trong cấu hình TargetEndpoint, bạn có thể cung cấp các giá trị tại thời gian chạy, chẳng hạn như bằng Java Callout, chính sách JavaScript hoặc chính sách Assign Message. Sử dụng bất kỳ biến thông báo nào có chứa các giá trị bạn muốn đặt.

Bạn chỉ được phép dùng biến trong các phần tử sau.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Sử dụng các tham chiếu để đặt giá trị TLS/SSL một cách linh động

Khi định cấu hình một TargetEndpoint sử dụng HTTPS, bạn phải cân nhắc trường hợp chứng chỉ TLS/SSL hết hạn hoặc một thay đổi đối với cấu hình hệ thống yêu cầu bạn cập nhật chứng chỉ. Trong quá trình cài đặt Edge cho Đám mây riêng tư, khi định cấu hình TLS/SSL bằng cách sử dụng các giá trị tĩnh hoặc bằng cách sử dụng các biến luồng, có thể bạn sẽ phải khởi động lại Trình xử lý thông báo.

Để biết thêm thông tin, hãy xem bài viết Cập nhật chứng chỉ TLS.

Tuy nhiên, bạn có thể tuỳ ý định cấu hình TargetEndpoint để sử dụng một reference (tham chiếu) thay cho kho khoá hoặc kho tin cậy. Lợi ích của việc sử dụng một tham chiếu là bạn có thể cập nhật tham chiếu để trỏ đến một kho khoá hoặc kho tin cậy khác nhằm cập nhật chứng chỉ TLS/SSL mà không cần phải khởi động lại Bộ xử lý thông báo.

Ví dụ: bên dưới là một TargetEndpoint sử dụng một tham chiếu đến kho khoá:

<SSLInfo>
    <Enabled>true</Enabled>
    <ClientAuthEnabled>false</ClientAuthEnabled>
    <KeyStore>ref://keystoreref</KeyStore>
    <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Sử dụng lệnh gọi API POST sau đây để tạo tham chiếu có tên là keystoreref:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

Tham chiếu này chỉ định tên của kho khoá và loại kho khoá.

Sử dụng lệnh gọi API GET sau đây để xem thông tin tham khảo:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Để sau này thay đổi thông tin tham chiếu để trỏ đến một kho khoá khác, hãy đảm bảo rằng bí danh có cùng tên, hãy dùng lệnh gọi PUT sau:

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint có tính năng cân bằng tải mục tiêu

TargetEndpoints hỗ trợ cân bằng tải trên nhiều TargetServer được đặt tên bằng cách sử dụng 3 thuật toán cân bằng tải.

Để biết hướng dẫn chi tiết, hãy tham khảo bài viết Cân bằng tải trên các máy chủ phụ trợ.

Chính sách

Thư mục /policies trong một proxy API chứa tất cả các chính sách có thể được đính kèm vào các Luồng trong proxy API.

Các phần tử trong cấu hình chính sách

Tài liệu đính kèm chính sách

Hình ảnh sau đây cho thấy trình tự thực thi luồng proxy API:

Như minh hoạ ở trên:

Các chính sách được đính kèm dưới dạng các bước xử lý vào Luồng. Tên của chính sách được dùng để tham chiếu đến chính sách cần thực thi dưới dạng một Bước xử lý. Định dạng của tệp đính kèm chính sách như sau:

<Step><Name>MyPolicy</Name></Step>

Các chính sách được thực thi theo thứ tự mà chúng được đính kèm vào một Luồng. Ví dụ:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Các phần tử trong cấu hình tệp đính kèm chính sách

Luồng

ProxyEndpoint và TargetEndpoint xác định một quy trình để xử lý thông báo yêu cầu và phản hồi. Một quy trình xử lý bao gồm một luồng yêu cầu và một luồng phản hồi. Mỗi luồng yêu cầu và luồng phản hồi được chia thành một PreFlow, một hoặc nhiều luồng "có điều kiện" hoặc "được đặt tên" không bắt buộc và một PostFlow.

• PreFlow: Luôn thực thi. Thực thi trước mọi Luồng có điều kiện.
• PostFlow: Luôn thực thi. Thực thi sau mọi Luồng có điều kiện.

Ngoài ra, bạn có thể thêm PostClientFlow vào ProxyEndpoint. PostClientFlow sẽ thực thi sau khi phản hồi được trả về cho ứng dụng khách yêu cầu. Chỉ có thể đính kèm chính sách MessageLogging và Tiện ích ghi nhật ký Google Stackdriver vào luồng này. PostClientFlow giúp giảm độ trễ của proxy API và cung cấp thông tin để ghi nhật ký mà không được tính cho đến khi phản hồi được trả về cho ứng dụng, chẳng hạn như client.sent.start.timestamp và client.sent.end.timestamp.Luồng này chủ yếu được dùng để đo khoảng thời gian giữa dấu thời gian bắt đầu và dấu thời gian kết thúc cho thông báo phản hồi.

Xem video hướng dẫn ngắn

Sau đây là ví dụ về PostClientFlow có chính sách ghi nhật ký thông báo được đính kèm.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

Quy trình xử lý của API proxy sẽ thực thi các Luồng theo trình tự sau:

Quy trình yêu cầu:

1. Proxy Request PreFlow
2. Luồng có điều kiện của yêu cầu proxy (Không bắt buộc)
3. Proxy Request PostFlow
4. Target Request PreFlow
5. Luồng có điều kiện của yêu cầu nhắm mục tiêu (Không bắt buộc)
6. Target Request PostFlow

Quy trình phản hồi:

1. Target Response PreFlow
2. Luồng phản hồi có điều kiện mục tiêu (Không bắt buộc)
3. Target Response PostFlow
4. Proxy Response PreFlow
5. Luồng có điều kiện phản hồi của proxy (Không bắt buộc)
6. Proxy Response PostFlow
7. Phản hồi PostClientFlow (Không bắt buộc)

Bạn chỉ cần định cấu hình những Luồng có tệp đính kèm chính sách trong cấu hình ProxyEndpoint hoặc TargetEndpoint. Bạn chỉ cần chỉ định PreFlow và PostFlow trong cấu hình ProxyEndpoint hoặc TargetEndpoint khi cần thực thi một chính sách trong quá trình xử lý PreFlow hoặc PostFlow.

Ngược lại với các luồng có điều kiện, thứ tự của các phần tử PreFlow và PostFlow không quan trọng – proxy API sẽ luôn thực thi từng phần tử tại thời điểm thích hợp trong quy trình, bất kể chúng xuất hiện ở đâu trong cấu hình Endpoint.

Luồng có điều kiện

ProxyEndpoints và TargetEndpoints hỗ trợ số lượng luồng có điều kiện không giới hạn (còn gọi là "luồng có tên").

API proxy kiểm tra điều kiện được chỉ định trong luồng có điều kiện và nếu điều kiện được đáp ứng, thì các bước xử lý trong luồng có điều kiện sẽ được API proxy thực thi. Nếu điều kiện không được đáp ứng, các bước xử lý trong quy trình có điều kiện sẽ bị bỏ qua. Các luồng có điều kiện được đánh giá theo thứ tự được xác định trong proxy API và luồng đầu tiên đáp ứng điều kiện sẽ được thực thi.

Bằng cách xác định các luồng có điều kiện, bạn có thể áp dụng các bước xử lý trong một proxy API dựa trên:

• URI yêu cầu
• Động từ HTTP (GET/PUT/POST/DELETE)
• Giá trị của tham số truy vấn, tiêu đề và tham số biểu mẫu
• Nhiều loại điều kiện khác

Ví dụ: luồng có điều kiện sau đây chỉ định rằng luồng này chỉ được thực thi khi đường dẫn tài nguyên yêu cầu là /accesstoken. Mọi yêu cầu đến có đường dẫn /accesstoken đều khiến quy trình này được thực thi, cùng với mọi chính sách được đính kèm vào quy trình. Nếu đường dẫn yêu cầu không bao gồm hậu tố /accesstoken, thì quy trình sẽ không thực thi (mặc dù có thể có một quy trình có điều kiện khác).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request>
  </Flow>
</Flows>

Các phần tử cấu hình quy trình công việc

Xử lý theo bước

Apigee Edge thực thi thứ tự tuần tự của các Luồng có điều kiện. Luồng có điều kiện thực thi từ trên xuống dưới. Quy trình công việc có điều kiện đầu tiên có điều kiện được đánh giá là true sẽ được thực thi và chỉ một Quy trình công việc có điều kiện được thực thi.

Ví dụ: trong cấu hình Flow sau, mọi yêu cầu đến không bao gồm hậu tố đường dẫn /first hoặc /second sẽ khiến ThirdFlow thực thi, thực thi chính sách có tên là Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Tài nguyên

"Tài nguyên" (tệp tài nguyên để sử dụng trong các proxy API) là tập lệnh, mã và các phép biến đổi XSL có thể được đính kèm vào các Luồng bằng cách sử dụng chính sách. Các tập lệnh này xuất hiện trong mục "Tập lệnh" của trình chỉnh sửa proxy API trong giao diện người dùng quản lý.

Hãy xem phần Tệp tài nguyên để biết các loại tài nguyên được hỗ trợ.

Bạn có thể lưu trữ tài nguyên trong một proxy API, một môi trường hoặc một tổ chức. Trong mỗi trường hợp, một tài nguyên được tham chiếu theo tên trong Chính sách. Dịch vụ API phân giải tên bằng cách di chuyển từ proxy API, đến môi trường, đến cấp tổ chức.

Các chính sách trong mọi môi trường đều có thể tham chiếu đến tài nguyên được lưu trữ ở cấp tổ chức. Các Chính sách trong môi trường đó có thể tham chiếu đến tài nguyên được lưu trữ ở cấp môi trường. Bạn chỉ có thể tham chiếu tài nguyên được lưu trữ ở cấp proxy API bằng các Chính sách trong proxy API đó.