Halaman ini berlaku untuk Apigee dan Apigee Hybrid.
Lihat dokumentasi
Apigee Edge.
Kebijakan ini menyimpan data dalam cache dari resource backend, sehingga mengurangi jumlah permintaan ke resource. Saat aplikasi membuat permintaan ke URI yang sama, Anda dapat menggunakan kebijakan ini untuk menampilkan respons yang di-cache, bukan meneruskan permintaan tersebut ke server backend. Kebijakan ResponseCache dapat meningkatkan performa API Anda melalui pengurangan latensi dan traffic jaringan.
Kebijakan ini adalah Kebijakan yang dapat diperluas dan penggunaan kebijakan ini mungkin memiliki implikasi biaya atau penggunaan, bergantung pada lisensi Apigee Anda. Untuk mengetahui informasi tentang jenis kebijakan dan implikasi penggunaannya, lihat Jenis kebijakan.
Anda mungkin akan merasa ResponseCache paling berguna saat data backend yang digunakan oleh API Anda hanya diperbarui secara berkala. Misalnya, bayangkan Anda memiliki API yang menampilkan data laporan cuaca yang diperbarui hanya setiap sepuluh menit. Dengan menggunakan ResponseCache untuk menampilkan respons yang di-cache di antara penyegaran, Anda dapat mengurangi jumlah permintaan yang mencapai backend. Tindakan ini juga mengurangi jumlah hop jaringan.
Untuk caching jangka pendek tujuan umum, pertimbangkan untuk menggunakan kebijakan PopulateCache. Kebijakan tersebut digunakan bersama dengan kebijakan LookupCache (untuk membaca entri cache) dan kebijakan InvalidateCache (untuk membatalkan entri).
Tonton video berikut untuk mengetahui pengantar kebijakan Response Cache.
Sampel
Cache 10 menit
Contoh ini menunjukkan cara agar respons yang di-cache tetap disimpan selama 10 menit.
Misalkan Anda memiliki API di URL berikut:
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
Anda menggunakan parameter kueri w
sebagai kunci cache. Apigee memeriksa
nilai parameter kueri w
setiap kali permintaan diterima. Jika respons yang valid (yaitu, tidak
kedaluwarsa) ada dalam cache, maka pesan respons yang di-cache akan
dikembalikan ke klien yang meminta.
Sekarang bayangkan Anda telah mengonfigurasi kebijakan ResponseCache sebagai berikut.
<ResponseCache name="ResponseCache"> <CacheKey> <KeyFragment ref="request.queryparam.w" /> </CacheKey> <ExpirySettings> <TimeoutInSeconds>600</TimeoutInSeconds> </ExpirySettings> </ResponseCache>
Saat pertama kali menerima pesan permintaan untuk URL berikut, respons proxy API akan di-cache. Pada permintaan kedua dalam waktu 10 menit, pencarian cache akan terjadi -- respons yang di-cache akan ditampilkan ke aplikasi tanpa permintaan diteruskan ke layanan backend.
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
Melewati pencarian cache
Contoh berikut menunjukkan cara melewati pencarian cache dan memperbarui cache. Lihat juga video ini tentang penggunaan SkipCacheLookup.
Kondisi SkipCacheLookup opsional (jika dikonfigurasi) dievaluasi di jalur permintaan. Jika kondisi bernilai benar, pencarian cache akan dilewati dan cache akan dimuat ulang.
Penggunaan umum refresh cache bersyarat adalah kondisi yang menentukan header HTTP tertentu yang menyebabkan kondisi dievaluasi menjadi benar. Aplikasi klien yang dibuat dengan skrip dapat dikonfigurasi untuk mengirimkan permintaan secara berkala dengan header HTTP yang sesuai, sehingga secara eksplisit menyebabkan cache respons dimuat ulang.
Misalnya, bayangkan panggilan ke API di URL berikut:
'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"
Sekarang bayangkan kebijakan ResponseCache berikut dikonfigurasi di proxy tersebut. Perhatikan bahwa kondisi bypass-cache disetel ke benar.
<ResponseCache name="ResponseCache"> <CacheKey> <KeyFragment ref="request.queryparam.w" /> </CacheKey> <!-- Explicitly refresh the cached response --> <SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup> <ExpirySettings> <TimeoutInSeconds>600</TimeoutInSeconds> </ExpirySettings> </ResponseCache>
Untuk mengetahui informasi selengkapnya tentang kondisi, lihat Variabel dan kondisi alur.
Referensi elemen
Referensi elemen menjelaskan elemen dan atribut kebijakan.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1"> <DisplayName>Response Cache 1</DisplayName> <Properties/> <CacheKey> <Prefix/> <KeyFragment ref="request.uri" /> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <ExpiryDate/> <TimeOfDay/> <TimeoutInSeconds ref="flow.variable.here">300</TimeoutInSeconds> </ExpirySettings> <CacheResource>cache_to_use</CacheResource> <CacheLookupTimeoutInSeconds/> <ExcludeErrorResponse/> <SkipCacheLookup/> <SkipCachePopulation/> <UseAcceptHeader/> <UseResponseCacheHeaders/> </ResponseCache>
Atribut <ResponseCache>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
Tabel berikut menjelaskan atribut yang umum untuk semua elemen induk kebijakan:
Atribut | Deskripsi | Default | Kehadiran |
---|---|---|---|
name |
Nama internal kebijakan. Nilai atribut Secara opsional, gunakan elemen |
T/A | Wajib |
continueOnError |
Tetapkan ke Tetapkan ke |
false | Opsional |
enabled |
Tetapkan ke Tetapkan ke |
benar | Opsional |
async |
Atribut ini tidak digunakan lagi. |
false | Tidak digunakan lagi |
Elemen <DisplayName>
Gunakan selain atribut name
untuk melabeli kebijakan di editor proxy UI pengelolaan dengan nama bahasa alami yang berbeda.
<DisplayName>Policy Display Name</DisplayName>
Default |
T/A Jika Anda menghapus elemen ini, nilai atribut |
---|---|
Kehadiran | Opsional |
Jenis | String |
Elemen <CacheKey>
Mengonfigurasi pointer unik ke bagian data yang disimpan dalam cache.
Kunci cache dibatasi hingga ukuran 2 KB.
<CacheKey> <Prefix>string</Prefix> <KeyFragment ref="variable_name" /> <KeyFragment>literal_string</KeyFragment> </CacheKey>
Default: |
T/A |
Kehadiran: |
Wajib |
Jenis: |
T/A |
<CacheKey>
membuat nama setiap bagian data yang disimpan dalam cache.
Kunci sering kali ditetapkan menggunakan nilai dari header entity atau parameter kueri. Dalam kasus tersebut, Anda akan
memiliki atribut ref elemen yang menentukan variabel yang berisi nilai kunci.
Saat runtime, nilai <KeyFragment>
diawali dengan nilai elemen
<Scope>
atau nilai <Prefix>
. Misalnya, berikut menghasilkan kunci cache
UserToken__apiAccessToken__
<value_of_client_id>:
<CacheKey> <Prefix>UserToken</Prefix> <KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" /> </CacheKey>
Anda menggunakan elemen <CacheKey>
bersama dengan
<Prefix>
dan <Scope>
. Untuk mengetahui informasi selengkapnya, lihat Bekerja dengan kunci cache.
Elemen <CacheLookupTimeoutInSeconds>
Menentukan jumlah detik setelah pencarian cache yang tidak berhasil akan dianggap sebagai miss cache. Jika hal ini terjadi, alur akan dilanjutkan di sepanjang jalur miss cache.
<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>
Default: |
30 |
Kehadiran: |
Opsional |
Jenis: |
Bilangan bulat |
Elemen <CacheResource>
Menentukan cache tempat pesan harus disimpan. Hapus elemen ini untuk menggunakan cache bersama yang disertakan. Anda harus menentukan CacheResource
menurut nama jika ingin dapat
menghapus entri yang ada dalam cache secara administratif. Untuk mengetahui informasi selengkapnya, lihat Caches API.
<CacheResource>cache_to_use</CacheResource>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Elemen <CacheKey>/<KeyFragment>
Menentukan nilai yang harus disertakan dalam kunci cache, sehingga membuat namespace untuk mencocokkan permintaan dengan respons yang di-cache.
<KeyFragment ref="variable_name"/> <KeyFragment>literal_string</KeyFragment>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
T/A |
Ini dapat berupa kunci (nama statis yang Anda berikan) atau nilai (entri dinamis yang ditetapkan dengan mereferensikan variabel). Semua fragmen yang ditentukan digabungkan (ditambah awalan) untuk membuat kunci cache.
<KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" />
Anda menggunakan elemen <KeyFragment>
bersama dengan
<Prefix>
dan <Scope>
. Untuk mengetahui informasi selengkapnya, lihat Bekerja dengan kunci cache.
Atribut
Atribut | Jenis | Default | Wajib | Deskripsi |
---|---|---|---|---|
ref | string | Tidak |
Variabel yang akan diambil nilainya. Tidak boleh digunakan jika elemen ini berisi nilai literal. |
Elemen <CacheKey>/<Prefix>
Menentukan nilai yang akan digunakan sebagai awalan kunci cache.
<Prefix>prefix_string</Prefix>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Gunakan nilai ini, bukan <Scope>
, jika Anda ingin menentukan nilai Anda sendiri, bukan nilai yang di-enumerasi <Scope>
. Jika ditentukan,
<Prefix>
menambahkan nilai kunci cache untuk entri yang ditulis ke cache. Nilai elemen
<Prefix>
menggantikan nilai elemen <Scope>
.
Anda menggunakan elemen <Prefix>
bersama dengan
<CacheKey>
dan <Scope>
. Untuk mengetahui informasi selengkapnya, lihat Bekerja dengan kunci cache.
Elemen <ExcludeErrorResponse>
Kebijakan ini dapat meng-cache respons HTTP dengan kode status apa pun. Artinya, respons berhasil dan error dapat di-cache, termasuk kode status 2xx dan 3xx.
Setel elemen ini ke true
(default) untuk mengecualikan respons error. Setel ke
false
jika Anda tidak ingin mengecualikan respons target cache
dengan kode status error HTTP.
Untuk pembahasan pola Cache Respons yang berguna bagi elemen ini, lihat Pengantar antipola.
<ExcludeErrorResponse>true</ExcludeErrorResponse>
Default: |
true |
Kehadiran: |
Opsional |
Jenis: |
Boolean |
Elemen <ExpirySettings>
Menentukan kapan entri cache harus berakhir masa berlakunya. Jika ada, <TimeoutInSeconds>
akan menggantikan <TimeOfDay>
dan <ExpiryDate>
.
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> <ExpiryDate ref="date_variable">expiration_date</ExpiryDate> </ExpirySettings>
Default: |
T/A |
Kehadiran: |
Wajib |
Jenis: |
T/A |
Elemen <ExpirySettings>/<ExpiryDate>
Menentukan tanggal saat entri cache harus habis masa berlakunya. Gunakan formulir mm-dd-yyyy
.
Jika ada, elemen seinduk ini, <TimeoutInSeconds>
, akan menggantikan
<ExpiryDate>
.
<ExpirySettings> <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate> </ExpirySettings>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Atribut
<ExpiryDate ref="" />
Atribut | Deskripsi | Default | Kehadiran | Jenis |
---|---|---|---|---|
ref |
Variabel yang akan diambil nilainya. Tidak boleh digunakan jika elemen ini berisi nilai literal. |
T/A | Opsional | String |
Elemen <ExpirySettings>/<TimeOfDay>
Waktu dalam sehari saat entri cache harus berakhir masa berlakunya. Gunakan formulir hh:mm:ss
.
Jika ada, elemen seinduk ini, <TimeoutInSeconds>
, akan menggantikan
<TimeOfDay>
.
Masukkan waktu dalam format HH:mm:ss, dengan HH mewakili jam pada jam 24 jam. Contoh, 14:30:00 untuk 14.30.
Untuk waktu dalam sehari, lokalitas dan zona waktu default akan bervariasi bergantung pada tempat kode dijalankan (yang tidak dapat diketahui saat Anda mengonfigurasi kebijakan).
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> </ExpirySettings>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Atribut
Atribut | Deskripsi | Default | Kehadiran | Jenis |
---|---|---|---|---|
ref | Variabel dengan nilai waktu habis masa berlaku. | T/A | Opsional | String |
Elemen <ExpirySettings>/<TimeoutInSec>
Jumlah detik setelah entri cache harus berakhir.
Elemen <ExpirySettings>/<TimeoutInSeconds>
Jumlah detik setelah entri cache harus berakhir. Jika ada, elemen ini
menggantikan elemen saudaranya, <TimeOfDay>
dan <ExpiryDate>
.
<ExpirySettings> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> </ExpirySettings>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Atribut
Atribut | Deskripsi | Default | Kehadiran | Jenis |
---|---|---|---|---|
ref | Variabel dengan nilai waktu tunggu. |
T/A
|
Opsional | String |
Elemen <Scope>
Enumerasi yang digunakan untuk membuat awalan untuk kunci cache saat elemen <Prefix>
tidak disediakan dalam elemen <CacheKey>
.
<Scope>scope_enumeration</Scope>
Default: |
"Eksklusif" |
Kehadiran: |
Opsional |
Jenis: |
String |
Setelan <Scope>
menentukan kunci cache yang ditambahkan di awal sesuai dengan
nilai <Scope>
. Misalnya, kunci cache akan berbentuk sebagai berikut jika
cakupan ditetapkan ke Exclusive
:
orgName__envName__apiProxyName__proxy|TargetName__ [
serializedCacheKey ].
Jika elemen <Prefix>
ada di <CacheKey>
, elemen tersebut akan menggantikan nilai elemen <Scope>
. Nilai yang valid mencakup enumerasi
di bawah.
Anda menggunakan elemen <Scope>
bersama dengan
<CacheKey>
dan <Prefix>
. Untuk mengetahui informasi selengkapnya, lihat Bekerja dengan kunci cache.
Nilai yang dapat diterima
Nilai Cakupan | Deskripsi |
---|---|
Global |
Kunci cache dibagikan di semua proxy API yang di-deploy di lingkungan. Kunci cache ditambahkan dalam bentuk orgName __ envName __. Jika Anda menentukan entri |
Application |
Nama proxy API digunakan sebagai awalan. Kunci cache diawali dalam bentuk orgName__envName__apiProxyName. |
Proxy |
Konfigurasi ProxyEndpoint digunakan sebagai awalan. Kunci cache diawali dalam bentuk orgName__envName__apiProxyName__proxyEndpointName . |
Target |
Konfigurasi TargetEndpoint digunakan sebagai awalan. Kunci cache yang ditambahkan dalam bentuk orgName__envName__apiProxyName__targetEndpointName . |
Exclusive |
Default. Ini adalah yang paling spesifik, sehingga menimbulkan risiko minimal terjadinya konflik namespace dalam cache tertentu. Awalan memiliki salah satu dari dua bentuk berikut:
Kunci cache yang ditambahkan dalam bentuk orgName__envName__apiProxyName__proxyNameITargetName Misalnya, string lengkapnya mungkin terlihat seperti ini: apifactory__test__weatherapi__default__apiAccessToken |
Elemen <SkipCacheLookup>
Menentukan ekspresi yang, jika dievaluasi ke benar saat runtime, menentukan bahwa penelusuran cache
harus dilewati dan cache harus di-refresh. Lihat juga
Video penggunaan kebijakan ResponseCache tentang penggunaan SkipCacheLookup
.
<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Dari contoh berikut, jika variabel bypass-cache disetel ke benar (true) di header masuk, pencarian cache dilewati dan cache diperbarui.
<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
Elemen <SkipCachePopulation>
Menentukan ekspresi yang, jika dievaluasi ke benar (true) saat runtime, menentukan bahwa penulisan ke
cache harus dilewati. Lihat juga video
ini tentang penggunaan SkipCachePopulation
.
<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: |
String |
Misalnya, kode berikut akan melewati penulisan cache jika kode status respons adalah 400 atau lebih tinggi:
<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>
Elemen <UseAcceptHeader>
Disetel ke true
agar kunci cache entri cache respons ditambahkan dengan nilai dari
header Accept respons.
Apigee menggunakan header permintaan Accept
, Accept-Encoding
, Accept-Language
dan Accept-Charset
saat menghitung kunci cache. Pendekatan ini
mencegah klien mendapatkan jenis media yang tidak mereka minta.
Misalnya, pertimbangkan jika dua permintaan masuk dari URL yang sama, dengan permintaan pertama menerima gzip dan yang kedua tidak. Permintaan pertama akan di-cache, dan entri yang di-cache akan (mungkin) berupa respons yang di-gzip. Permintaan kedua akan membaca nilai yang di-cache dan kemudian dapat menampilkan entri yang di-gzip ke klien yang tidak dapat membaca gzip.
Lihat Mengonfigurasi kunci cache untuk mengetahui informasi selengkapnya.
<UseAcceptHeader>false</UseAcceptHeader>
Default: |
false |
Kehadiran: |
Opsional |
Jenis: |
Boolean |
Elemen <UseResponseCacheHeaders>
Setel ke true
agar header respons HTTP dipertimbangkan saat menyetel "time to live" (TTL) respons dalam cache. Jika benar, Apigee akan mempertimbangkan nilai header respons berikut, membandingkan nilai dengan yang ditetapkan oleh <ExpirySettings>
saat menetapkan waktu aktif:
Cache-Control s-maxage
Cache-Control max-age
Expires
Lihat Menetapkan masa berlaku entri cache untuk mengetahui detail selengkapnya.
<UseResponseCacheHeaders>false</UseResponseCacheHeaders>
Default: |
false |
Kehadiran: |
Opsional |
Jenis: |
Boolean |
Catatan penggunaan
Ukuran maksimum untuk setiap objek yang di-cache adalah 256 KB. (Untuk mengetahui informasi mendetail tentang cara Apigee memproses cache, lihat Internal cache.)
Melalui konfigurasi dalam kebijakan ResponseCache, Anda dapat membuat Apigee menyertakan header respons HTTP dalam menetapkan masa berlaku entri cache dan kunci cache. Bagian ini menjelaskan cara menggunakan kebijakan dengan header untuk mengelola masa berlaku cache dan kunci cache.
Untuk mengetahui informasi selengkapnya tentang cara Apigee menangani header respons dengan kebijakan ResponseCache, lihat Dukungan untuk header respons HTTP.
Menyetel masa berlaku entri cache
Seperti PopulateCache policy, Anda dapat menetapkan masa berlaku entri cache respons (waktu aktifnya) menggunakan elemen
<ExpirySettings>
. Dalam kebijakan ResponseCache, Anda juga dapat membuat Apigee
mempertimbangkan header respons jika ada.
Untuk menggunakan header respons, Anda menetapkan nilai elemen <UseResponseCacheHeaders>
ke
benar. Setelan tersebut menyebabkan Apigee mempertimbangkan header respons, membandingkannya dengan nilai yang ditetapkan oleh <ExpirySettings>
, lalu menggunakan nilai terendah di antara keduanya. Saat
mempertimbangkan header respons, Apigee memilih nilai yang tersedia seperti yang dijelaskan di
bawah ini:
Misalnya, bayangkan respons di-cache dengan nilai berikut:
- Tidak ada nilai
Cache-Control s-maxage
- Nilai
Cache-Control max-age
sebesar 300 - Tanggal
Expires
dalam tiga hari - Nilai
<ExpirySettings>
TimeoutInSeconds
sebesar 600.
Dalam hal ini, nilai Cache-Control
max-age
akan digunakan untuk
TTL karena lebih rendah dari nilai <ExpirySettings>
dan karena tidak ada
nilai Cache-Control s-maxage
(yang lebih diutamakan daripada
max-age
).
Mengonfigurasi kunci cache
Seperti kebijakan cache tujuan umum seperti kebijakan PopulateCache, dengan
ResponseCache, Anda menggunakan elemen <CacheKey>
dan <Scope>
untuk
mengonfigurasi pembuatan kunci cache untuk entri cache. Dengan ResponseCache, Anda juga dapat membuat kunci cache
lebih bermakna dengan menambahkan header Accept respons ke nilai kunci.
Untuk mengetahui informasi umum tentang cara mengonfigurasi kunci cache, lihat Bekerja dengan kunci cache. Untuk
informasi tentang penggunaan header Accept, lihat <UseAcceptHeader>
.
Tentang enkripsi cache
Apigee dan Apigee Hybrid (versi 1.4 dan yang lebih baru): Data Cache dan KVM selalu dienkripsi.
Variabel alur
Variabel Alur yang telah ditentukan sebelumnya berikut diisi saat kebijakan ResponseCache dijalankan. Untuk mengetahui informasi selengkapnya tentang variabel Alur, lihat Referensi variabel alur.
Variabel | Jenis | Izin | Deskripsi |
---|---|---|---|
responsecache.{policy_name}.cachename |
String | Hanya Baca | Menampilkan cache yang digunakan dalam kebijakan |
responsecache.{policy_name}.cachekey |
String | Hanya Baca | Menampilkan kunci yang digunakan |
responsecache.{policy_name}.cachehit |
Boolean | Hanya Baca | Benar jika eksekusi kebijakan berhasil |
responsecache.{policy_name}.invalidentry |
Boolean | Hanya Baca | Benar jika entri cache tidak valid |
Kode error
Bagian ini menjelaskan pesan error dan variabel alur yang ditetapkan saat kebijakan ini memicu error. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan error untuk proxy. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani error.
Awalan kode error
T/A
Error runtime
Kebijakan ini tidak menampilkan error runtime.
Error saat deployment
Error ini dapat terjadi saat Anda men-deploy proxy yang berisi kebijakan ini.
Nama error | Penyebab | Perbaiki |
---|---|---|
InvalidTimeout |
Jika elemen <CacheLookupTimeoutInSeconds> kebijakan ResponseCache ditetapkan ke bilangan negatif, deployment proxy API akan gagal. |
build |
InvalidCacheResourceReference |
Error ini terjadi jika elemen <CacheResource> dalam kebijakan ResponseCache ditetapkan ke nama yang tidak ada di lingkungan tempat proxy API di-deploy. |
build |
ResponseCacheStepAttachmentNotAllowedReq |
Error ini terjadi jika kebijakan ResponseCache yang sama dilampirkan ke beberapa jalur permintaan dalam alur proxy API. |
build |
ResponseCacheStepAttachmentNotAllowedResp |
Error ini terjadi jika kebijakan ResponseCache yang sama dilampirkan ke beberapa jalur respons dalam alur proxy API. |
build |
InvalidMessagePatternForErrorCode |
Error ini terjadi jika elemen <SkipCacheLookup> atau <SkipCachePopulation>
dalam kebijakan ResponseCache berisi kondisi yang tidak valid. |
build |
CacheNotFound |
Error ini terjadi jika cache tertentu yang disebutkan dalam pesan error belum dibuat di komponen Message Processor tertentu. | build |
Variabel error
T/A
Contoh respons error
T/A
Skema
Setiap jenis kebijakan ditentukan oleh skema XML (.xsd
). Sebagai referensi, skema kebijakan
tersedia di GitHub.