19.03.01 - Apigee Edge untuk catatan rilis Public Cloud

Load balancing - kontrol yang lebih besar untuk menghapus server yang gagal

Saat mengonfigurasi load balancer untuk proxy API, Anda dapat menentukan berapa banyak kegagalan respons yang terjadi sebelum server dihapus dari rotasi load balancing. Kegagalan respons berarti Apigee tidak menerima respons apa pun dari server target. Jika hal ini terjadi, penghitung kegagalan akan bertambah satu. Saat Apigee menerima respons dari target, meskipun respons tersebut adalah error HTTP (seperti 500), hal itu dihitung sebagai respons dari server target, dan penghitung kegagalan direset. Untuk membantu memastikan bahwa respons HTTP yang buruk (seperti 500) juga menaikkan penghitung kegagalan untuk mengeluarkan server yang tidak responsif dari rotasi load balancing secepat mungkin, Anda dapat menambahkan elemen <ServerUnhealthyResponse> baru dengan elemen turunan <ResponseCode> ke konfigurasi load balancer Anda. Edge juga akan menghitung respons dengan kode tersebut sebagai kegagalan.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

Peningkatan kebijakan AccessControl

Kebijakan AccessControl menentukan alamat IP mana yang dapat melakukan panggilan ke proxy API. Elemen baru dalam kebijakan tersebut memberi developer API lebih banyak kontrol dalam mengidentifikasi alamat IP yang akan dievaluasi.

<IgnoreTrueClientIPHeader>: Opsional (defaultnya adalah salah). Jika Anda menyetelnya ke benar (true), kebijakan akan mengabaikan header True-Client-IP dan mengevaluasi alamat IP di header X-Forwarded-For, mengikuti perilaku evaluasi X-Forwarded-For yang telah Anda konfigurasi.

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

Untuk mengetahui detailnya, lihat postingan Komunitas ini.

Dua elemen baru tersedia di kebijakan RaiseFault untuk membuat penanganan FaultRules lebih bersih dan efektif.

• ShortFaultReason adalah boolean yang, jika disetel ke benar (true), akan menempatkan nama kebijakan dalam variabel fault.reason.
• AssignVariable, yang tersedia di FaultResponse, memungkinkan Anda menetapkan respons kesalahan ke variabel untuk digunakan oleh kebijakan lain dalam alur proxy API.

Batasan kini diterapkan untuk Target yang Dihosting. Lihat Batas untuk mengetahui detail batas.

Sekarang Anda dapat menggunakan variabel template pesan untuk menetapkan alamat IP dan mask CIDR pada kebijakan AccessControl. Misalnya, jika Anda ingin menyimpan alamat IP dan mask dalam peta nilai kunci (KVM), Anda dapat mengambil nilai tersebut dari variabel yang ditetapkan dalam alur proxy API. Hal ini memungkinkan Anda mengubah nilai IP dengan lebih mudah saat runtime tanpa harus mengubah konfigurasi kebijakan.

Misalnya, bukan:

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

Anda dapat mengonfigurasi kebijakan seperti ini, dengan asumsi nilai disimpan dalam KVM, dan Anda menggunakan kebijakan KeyValueMapOperations untuk mengambil nilai dan menetapkannya ke variabel yang ditampilkan di sini:

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

Pemantauan API menyediakan dua peran: Administrator Pemantauan API dan Pengguna Pemantauan API, yang dijelaskan dalam Mengakses Pemantauan API. Fitur ini tersedia pada Desember 2018.

Edge kini menambahkan header X-Apigee.Message-Timeout ke setiap permintaan. Header ini digunakan secara internal oleh Edge. Jangan mengandalkan nilai di header X-Apigee.* di proxy API Anda karena header ini tidak ditujukan untuk penggunaan pelanggan dan dapat dihapus atau diubah oleh Apigee kapan saja.

Menangani error penghapusan keystore agar panggilan API tidak gagal

x-apigee.edge.execution.sense.action selalu ditetapkan ke null

Dalam kebijakan ResponseCache, NIOThread dieksekusi tanpa penolakan dari kumpulan thread

Beberapa pengekspor log di router Apigee menyebabkan penggunaan CPU yang tinggi

Error 404 yang terjadi sesekali di organisasi tertentu

Alur Bersama yang di-deploy tidak dieksekusi di beberapa pemroses pesan

Perbaikan ini akan disertakan dalam rilis Edge for Private Cloud berikutnya.

Perbaikan ini akan disertakan dalam rilis Edge for Private Cloud berikutnya.

Perbaikan ini akan disertakan dalam rilis Edge for Private Cloud berikutnya.