Bagikan melalui

Memanggil pemeriksaan Azure Function / REST API

  • Artikel

Pemeriksaan Invoke Azure Function / REST API memungkinkan Anda menulis kode untuk memutuskan apakah tahap alur tertentu diizinkan untuk mengakses sumber daya yang dilindungi atau tidak. Pemeriksaan ini dapat berjalan dalam dua mode:

  • Asinkron (Disarankan): mode pendorongan, di mana Azure DevOps menunggu implementasi Azure Function / REST API untuk memanggil kembali ke Azure DevOps dengan keputusan akses tahap
  • Sinkron: mode polling, di mana Azure DevOps secara berkala memanggil Azure Function / REST API untuk mendapatkan keputusan akses tahapan

Di sisa panduan ini, kami merujuk ke Pemeriksaan Azure Function / REST API hanya sebagai pemeriksaan.

Cara yang disarankan untuk menggunakan pemeriksaan berada dalam mode asinkron. Mode ini menawarkan tingkat kontrol tertinggi atas logika pemeriksaan, memudahkan untuk beralasan tentang status sistem, dan memisahkan Azure Pipelines dari implementasi pemeriksaan Anda, memberikan skalabilitas terbaik. Semua pemeriksaan sinkron dapat diimplementasikan menggunakan mode pemeriksaan asinkron.

Pemeriksaan asinkron

Dalam mode asinkron, Azure DevOps melakukan panggilan ke pemeriksaan Azure Function / REST API dan menunggu panggilan balik dengan keputusan akses sumber daya. Tidak ada koneksi HTTP terbuka antara Azure DevOps dan implementasi pemeriksaan Anda selama periode tunggu.

Bagian lain dari bagian ini berbicara tentang pemeriksaan Azure Functions, tetapi kecuali dinyatakan lain, panduan ini berlaku untuk pemeriksaan Invoke REST API juga.

Mode asinkron yang direkomendasikan memiliki dua langkah komunikasi:

  1. Kirim payload pemeriksaan. Azure Pipelines melakukan panggilan HTTP ke Azure Function / REST API Anda hanya untuk mengirimkan payload pemeriksaan, dan tidak menerima keputusan di tempat. Fungsi Anda hanya harus mengakui penerimaan informasi dan mengakhiri koneksi HTTP dengan Azure DevOps. Implementasi pemeriksaan Anda harus memproses permintaan HTTP dalam waktu 3 detik.
  2. Memberikan keputusan akses melalui panggilan balik. Pemeriksaan Anda harus berjalan secara asinkron, mengevaluasi kondisi yang diperlukan alur untuk mengakses sumber daya yang dilindungi (mungkin melakukan beberapa evaluasi pada titik waktu yang berbeda). Setelah mencapai keputusan akhir, Azure Function Anda melakukan panggilan HTTP REST ke Azure DevOps untuk mengomunikasikan keputusan. Kapan saja, harus ada satu koneksi HTTP terbuka antara Azure DevOps dan implementasi pemeriksaan Anda. Melakukannya menyimpan sumber daya di sisi Azure Functions Anda dan di sisi Azure Pipelines.

Jika pemeriksaan lolos, maka alur diizinkan mengakses sumber daya yang dilindungi dan penyebaran tahap dapat dilanjutkan. Jika pemeriksaan gagal, maka tahap gagal. Jika ada beberapa pemeriksaan dalam satu tahap, semua harus diteruskan sebelum akses ke sumber daya yang dilindungi diizinkan, tetapi satu kegagalan sudah cukup untuk gagal tahap.

Implementasi mode asinkron yang direkomendasikan untuk satu pemeriksaan Azure Function digambarkan dalam diagram berikut.

Diagram that shows the recommended implementation of the async mode for a single Azure Function check.

Langkah-langkah dalam diagram adalah:

  1. Periksa Pengiriman. Azure Pipelines bersiap untuk menyebarkan tahap alur dan memerlukan akses ke sumber daya yang dilindungi. Ini memanggil pemeriksaan Azure Function yang sesuai dan mengharapkan konfirmasi tanda terima, dengan panggilan yang berakhir dengan kode status HTTP 200. Penyebaran tahap dijeda menunggu keputusan.
  2. Periksa Evaluasi. Langkah ini terjadi di dalam implementasi Azure Function Anda, yang berjalan pada sumber daya Azure Anda sendiri dan kode yang sepenuhnya berada di bawah kendali Anda. Kami menyarankan Azure Function Anda mengikuti langkah-langkah berikut:
    • 2.1 Memulai tugas asinkron dan mengembalikan kode status HTTP 200
    • 2.2 Masukkan perulangan dalam, di mana ia dapat melakukan beberapa evaluasi kondisi
    • 2.3 Mengevaluasi kondisi akses
    • 2.4 Jika tidak dapat mencapai keputusan akhir, jadwalkan ulang evaluasi ulang kondisi untuk titik selanjutnya, lalu buka langkah 2.3
  3. Komunikasi Keputusan. Fungsi Azure memanggil kembali ke Azure Pipelines dengan keputusan akses. Penyebaran tahap dapat dilanjutkan

Saat Anda menggunakan implementasi yang direkomendasikan, halaman detail eksekusi alur menunjukkan log pemeriksaan terbaru.

Screenshot of pipeline run details with check information.

Di panel konfigurasi pemeriksaan Azure Function / REST API, pastikan Anda:

  • Panggilan Balik yang Dipilih untuk peristiwa Penyelesaian
  • Atur Waktu antara evaluasi (menit) ke 0

Mengatur Waktu antara evaluasi ke nilai bukan nol berarti keputusan pemeriksaan (lulus/gagal) belum final. Pemeriksaan dievaluasi ulang sampai semua Persetujuan & Pemeriksaan lainnya mencapai status akhir.

Meneruskan informasi eksekusi alur ke pemeriksaan

Saat mengonfigurasi pemeriksaan, Anda dapat menentukan informasi eksekusi alur yang ingin Anda kirim ke pemeriksaan Anda. Minimal, Anda harus mengirim:

  • "PlanUrl": "$(system.CollectionUri)"
  • "ProjectId": "$(system.TeamProjectId)"
  • "HubName": "$(system.HostType)"
  • "PlanId": "$(system.PlanId)"
  • "JobId": "$(system.JobId)"
  • "TaskInstanceId": "$(system.TaskInstanceId)"
  • "AuthToken": "$(system.AccessToken)"

Pasangan kunci-nilai ini diatur, secara default, dalam Headers panggilan REST yang dibuat oleh Azure Pipelines.

Anda harus menggunakan AuthToken untuk melakukan panggilan ke Azure DevOps, seperti saat pemeriksaan Anda memanggil kembali dengan keputusan.

Panggilan ke Azure DevOps

Untuk mencapai keputusan, pemeriksaan Anda mungkin memerlukan informasi tentang eksekusi alur saat ini yang tidak dapat diteruskan ke pemeriksaan, sehingga pemeriksaan perlu mengambilnya. Bayangkan pemeriksaan Anda memverifikasi bahwa eksekusi alur menjalankan tugas tertentu, misalnya tugas analisis statis. Pemeriksaan Anda perlu memanggil Azure DevOps dan mendapatkan daftar tugas yang sudah dijalankan.

Untuk memanggil Azure DevOps, kami sarankan Anda menggunakan token akses pekerjaan yang dikeluarkan untuk eksekusi pemeriksaan, alih-alih token akses pribadi (PAT). Token sudah disediakan untuk pemeriksaan Anda secara default, di AuthToken header.

Dibandingkan dengan PATs, token akses pekerjaan kurang rentan untuk dibatasi, tidak memerlukan refresh manual, dan tidak terkait dengan akun pribadi. Token berlaku selama 48 jam.

Menggunakan token akses pekerjaan semua tetapi menghapus masalah pembatasan REST API Azure DevOps. Saat Anda menggunakan PAT, Anda menggunakan PAT yang sama untuk semua eksekusi alur Anda. Jika Anda menjalankan sejumlah besar alur, maka PAT akan dibatasi. Ini kurang dari masalah dengan token akses pekerjaan karena token baru dihasilkan untuk setiap eksekusi pemeriksaan.

Token dikeluarkan untuk identitas build yang digunakan untuk menjalankan alur, misalnya, layanan build FabrikamFiberChat (FabrikamFiber). Dengan kata lain, token dapat digunakan untuk mengakses repositori atau eksekusi alur yang sama dengan yang dapat dilakukan alur host. Jika Anda mengaktifkan Lindungi akses ke repositori di alur YAML, cakupannya dibatasi lebih lanjut hanya untuk repositori yang direferensikan dalam eksekusi alur.

Jika pemeriksaan Anda perlu mengakses sumber daya terkait non-Alur, misalnya, Cerita pengguna Papan, Anda harus memberikan izin tersebut ke identitas build alur. Jika pemeriksaan Anda dapat dipicu dari beberapa proyek, pastikan bahwa semua alur di semua proyek dapat mengakses sumber daya yang diperlukan.

Mengirim keputusan kembali ke Azure DevOps

Implementasi pemeriksaan Anda harus menggunakan panggilan POST Event REST API untuk mengomunikasikan keputusan kembali ke Azure Pipelines. Pastikan Anda menentukan properti berikut:

  • Headers: Basic: {AuthToken}
  • Body:
{
    "name": "TaskCompleted",
    "taskId": "{TaskInstanceId}",
    "jobId": "{JobId}",
    "result": "succeeded|failed"
}

Mengirim pembaruan status ke Azure DevOps dari pemeriksaan

Anda dapat menyediakan pembaruan status untuk pengguna Azure Pipelines dari dalam pemeriksaan Anda menggunakan REST API Azure Pipelines. Fungsionalitas ini berguna, misalnya, jika Anda ingin memberi tahu pengguna bahwa pemeriksaan sedang menunggu tindakan eksternal, seperti seseorang perlu menyetujui tiket ServiceNow.

Langkah-langkah untuk mengirim pembaruan status adalah:

  1. Membuat log tugas
  2. Tambahkan ke log tugas
  3. Memperbarui catatan garis waktu

Semua panggilan REST API perlu diautentikasi.

Contoh

Pemeriksaan Fungsi Azure Dasar

Dalam contoh dasar ini, Azure Function memeriksa apakah eksekusi alur pemanggilan menjalankan CmdLine tugas, sebelum memberinya akses ke sumber daya yang dilindungi.

Azure Function melalui langkah-langkah berikut:

  1. Mengonfirmasi penerimaan payload pemeriksaan
  2. Mengirim pembaruan status ke Azure Pipelines bahwa pemeriksaan dimulai
  3. {AuthToken} Menggunakan untuk melakukan panggilan balik ke Azure Pipelines untuk mengambil entri Garis Waktu eksekusi alur
  4. Memeriksa apakah Garis Waktu berisi tugas dengan "id": "D9BAFED4-0B18-4F58-968D-86655B4D2CE9" (ID CmdLine tugas)
  5. Mengirim pembaruan status dengan hasil pencarian
  6. Mengirim keputusan pemeriksaan ke Azure Pipelines

Anda dapat mengunduh contoh ini dari GitHub.

Untuk menggunakan pemeriksaan Azure Function ini, Anda perlu menentukan hal berikut Headers saat mengonfigurasi pemeriksaan:

{
    "Content-Type":"application/json", 
    "PlanUrl": "$(system.CollectionUri)", 
    "ProjectId": "$(system.TeamProjectId)", 
    "HubName": "$(system.HostType)", 
    "PlanId": "$(system.PlanId)", 
    "JobId": "$(system.JobId)", 
    "TimelineId": "$(system.TimelineId)", 
    "TaskInstanceId": "$(system.TaskInstanceId)", 
    "AuthToken": "$(system.AccessToken)",
    "BuildId": "$(build.BuildId)"
}

Pemeriksaan Fungsi Azure Tingkat Lanjut

Dalam contoh lanjutan ini, Azure Function memeriksa bahwa item kerja Azure Boards yang direferensikan dalam pesan penerapan yang memicu eksekusi alur berada dalam status yang benar.

Azure Function melalui langkah-langkah berikut:

  1. Mengonfirmasi penerimaan payload pemeriksaan
  2. Mengirim pembaruan status ke Azure Pipelines bahwa pemeriksaan dimulai
  3. {AuthToken} Menggunakan untuk melakukan panggilan balik ke Azure Pipelines untuk mengambil status item kerja Azure Boards yang direferensikan dalam pesan penerapan yang memicu eksekusi alur
  4. Memeriksa apakah item kerja dalam status Completed
  5. Mengirim pembaruan status dengan hasil pemeriksaan
  6. Jika item kerja tidak dalam status Completed , item kerja akan menjadwalkan ulang evaluasi lain dalam 1 menit
  7. Setelah item kerja dalam keadaan benar, item tersebut mengirimkan keputusan positif ke Azure Pipelines

Anda dapat mengunduh contoh ini dari GitHub.

Untuk menggunakan pemeriksaan Azure Function ini, Anda perlu menentukan hal berikut Headers saat mengonfigurasi pemeriksaan:

{
    "Content-Type":"application/json", 
    "PlanUrl": "$(system.CollectionUri)", 
    "ProjectId": "$(system.TeamProjectId)", 
    "HubName": "$(system.HostType)", 
    "PlanId": "$(system.PlanId)", 
    "JobId": "$(system.JobId)", 
    "TimelineId": "$(system.TimelineId)", 
    "TaskInstanceId": "$(system.TaskInstanceId)", 
    "AuthToken": "$(system.AccessToken)",
    "BuildId": "$(build.BuildId)"
}

Penanganan kesalahan

Saat ini, Azure Pipelines mengevaluasi satu instans pemeriksaan paling banyak 2.000 kali.

Jika pemeriksaan Anda tidak memanggil kembali ke Azure Pipelines dalam batas waktu yang dikonfigurasi, tahap terkait akan dilewati. Tahapan tergantung pada itu dilewati juga.

Pemeriksaan sinkron

Dalam mode sinkron, Azure DevOps melakukan panggilan ke pemeriksaan Azure Function / REST API untuk mendapatkan keputusan segera apakah akses ke sumber daya yang dilindungi diizinkan atau tidak.

Implementasi mode sinkronisasi untuk satu pemeriksaan Fungsi Azure digambarkan dalam diagram berikut.

Diagram that shows the implementation of the sync mode for a single Azure Function check.

Langkah-langkahnya adalah:

  1. Azure Pipelines bersiap untuk menyebarkan tahap alur dan memerlukan akses ke sumber daya yang dilindungi
  2. Ini memasuki perulangan dalam di mana:
  • 2.1. Azure Pipelines memanggil pemeriksaan Azure Function yang sesuai dan menunggu keputusan
  • 2.2. Azure Function Anda mengevaluasi kondisi yang diperlukan untuk mengizinkan akses dan mengembalikan keputusan
  • 2.3. Jika isi respons Azure Function tidak memenuhi kriteria Keberhasilan yang Anda tentukan dan Waktu antara evaluasi bukan nol, Azure Pipelines menjadwalkan ulang evaluasi pemeriksaan lain setelah Waktu antar evaluasi

Mengonfigurasi pemeriksaan sinkron

Untuk menggunakan mode sinkron untuk Azure Function / REST API, di panel konfigurasi pemeriksaan, pastikan Anda:

  • ApiResponse yang Dipilih untuk peristiwa Penyelesaian di bawah Tingkat Lanjut
  • Menentukan kriteria Keberhasilan yang menentukan kapan harus melewati pemeriksaan berdasarkan isi respons pemeriksaan
  • Atur Waktu antara evaluasi ke 0 di bawah Opsi kontrol
  • Atur Batas Waktu ke berapa lama Anda ingin menunggu pemeriksaan berhasil. Jika tidak ada keputusan positif dan Batas Waktu tercapai, tahap alur yang sesuai akan dilewati

Pengaturan Waktu antar evaluasi menentukan berapa lama keputusan pemeriksaan valid. Nilai 0 berarti keputusan bersifat final. Nilai bukan nol berarti pemeriksaan akan dicoba kembali setelah interval yang dikonfigurasi, ketika keputusannya negatif. Ketika beberapa Persetujuan dan Pemeriksaan berjalan, pemeriksaan dicoba kembali terlepas dari keputusan.

Jumlah maksimum evaluasi ditentukan oleh rasio antara Batas Waktu dan Waktu antara nilai evaluasi . Kami sarankan Anda memastikan rasio ini paling banyak 10.

Meneruskan informasi eksekusi alur ke pemeriksaan

Saat mengonfigurasi pemeriksaan, Anda dapat menentukan informasi eksekusi alur yang ingin Anda kirim ke pemeriksaan Azure Function / REST API Anda. Secara default, Azure Pipeline menambahkan informasi berikut dalam Headers panggilan HTTP yang dilakukannya.

  • "PlanUrl": "$(system.CollectionUri)"
  • "ProjectId": "$(system.TeamProjectId)"
  • "HubName": "$(system.HostType)"
  • "PlanId": "$(system.PlanId)"
  • "JobId": "$(system.JobId)"
  • "TaskInstanceId": "$(system.TaskInstanceId)"
  • "AuthToken": "$(system.AccessToken)"

Kami tidak menyarankan untuk melakukan panggilan ke Azure DevOps dalam mode sinkron, karena kemungkinan besar akan menyebabkan pemeriksaan Anda membutuhkan waktu lebih dari 3 detik untuk membalas, sehingga pemeriksaan gagal.

Penanganan kesalahan

Saat ini, Azure Pipelines mengevaluasi satu instans pemeriksaan paling banyak 2.000 kali.

Kapan menggunakan pemeriksaan asinkron vs sinkron

Mari kita lihat beberapa contoh kasus penggunaan dan apa jenis pemeriksaan yang direkomendasikan untuk digunakan.

Informasi eksternal harus benar

Katakanlah Anda memiliki Koneksi si Layanan ke sumber daya produksi, dan Anda ingin memastikan bahwa akses ke sumber daya tersebut diizinkan hanya jika informasi dalam tiket ServiceNow sudah benar. Dalam hal ini, alurnya adalah sebagai berikut:

  • Anda menambahkan pemeriksaan Fungsi Azure asinkron yang memverifikasi kebenaran tiket ServiceNow
  • Saat alur yang ingin menggunakan Layanan Koneksi ion berjalan:
    • Azure Pipelines memanggil fungsi pemeriksaan Anda
    • Jika informasi salah, pemeriksaan mengembalikan keputusan negatif. Asumsikan hasil ini
    • Tahap alur gagal
    • Anda memperbarui informasi di tiket ServiceNow
    • Anda memulai ulang tahap yang gagal
    • Pemeriksaan berjalan lagi dan kali ini berhasil
    • Eksekusi alur berlanjut

Persetujuan eksternal harus diberikan

Katakanlah Anda memiliki Koneksi Layanan ke sumber daya produksi, dan Anda ingin memastikan bahwa akses ke layanan tersebut diizinkan hanya setelah administrator menyetujui tiket ServiceNow. Dalam hal ini, alurnya adalah sebagai berikut:

  • Anda menambahkan pemeriksaan Fungsi Azure asinkron yang memverifikasi tiket ServiceNow telah disetujui
  • Saat alur yang ingin menggunakan Layanan Koneksi ion berjalan:
    • Azure Pipelines memanggil fungsi pemeriksaan Anda.
    • Jika tiket ServiceNow tidak disetujui, Azure Function mengirimkan pembaruan ke Azure Pipelines, dan menjadwalkan ulang dirinya sendiri untuk memeriksa status tiket dalam 15 menit
    • Setelah tiket disetujui, pemeriksaan memanggil kembali ke Azure Pipelines dengan keputusan positif
    • Eksekusi alur berlanjut

Proses pengembangan diikuti

Misalnya Anda memiliki Koneksi Layanan ke sumber daya produksi, dan Anda ingin memastikan bahwa akses ke sumber daya tersebut diizinkan hanya jika cakupan kode di atas 80%. Dalam hal ini, alurnya adalah sebagai berikut:

  • Anda menulis alur singgah kegagalan tahapan menyebabkan build gagal
  • Anda menambahkan pemeriksaan Fungsi Azure asinkron yang memverifikasi cakupan kode untuk eksekusi alur terkait
  • Saat alur yang ingin menggunakan Layanan Koneksi ion berjalan:
    • Azure Pipelines memanggil fungsi pemeriksaan Anda
    • Jika kondisi cakupan kode tidak terpenuhi, pemeriksaan mengembalikan keputusan negatif. Asumsikan hasil ini
    • Kegagalan pemeriksaan menyebabkan tahap Anda gagal, yang menyebabkan eksekusi alur Anda gagal
  • Tim teknik menambahkan pengujian unit yang diperlukan untuk mencapai cakupan kode 80%
  • Eksekusi alur baru dipicu, dan kali ini, pemeriksaan lolos
    • Eksekusi alur berlanjut

Kriteria performa harus terpenuhi

Katakanlah Anda menyebarkan versi baru sistem Anda dalam beberapa langkah, dimulai dengan penyebaran kenari. Anda ingin memastikan performa penyebaran kenari Anda memadai. Dalam hal ini, alurnya adalah sebagai berikut:

  • Anda menambahkan pemeriksaan Fungsi Azure asinkron
  • Saat alur yang ingin menggunakan Layanan Koneksi ion berjalan:
    • Azure Pipelines memanggil fungsi pemeriksaan Anda
    • Pemeriksaan memulai monitor performa penyebaran kenari
    • Pemeriksaan menjadwalkan beberapa titik pemeriksaan evaluasi, untuk melihat bagaimana performa berkembang
    • Setelah Anda mendapatkan keyakinan yang cukup dalam performa penyebaran kenari, Azure Function Anda memanggil kembali ke Azure Pipelines dengan keputusan positif
    • Eksekusi alur berlanjut

Alasan penyebaran harus valid

Misalnya Anda memiliki Koneksi Layanan ke sumber daya lingkungan produksi, dan Anda ingin memastikan bahwa akses ke sumber daya tersebut hanya terjadi untuk build yang diantrekan secara manual. Dalam hal ini, alurnya adalah sebagai berikut:

  • Anda menambahkan pemeriksaan Fungsi Azure sinkron yang memverifikasi bahwa Build.Reason untuk eksekusi alur adalah Manual
  • Anda mengonfigurasi pemeriksaan Azure Function untuk meneruskannya Build.ReasonHeaders
  • Anda mengatur Waktu pemeriksaan antara evaluasi ke 0, sehingga kegagalan atau lulus bersifat final dan tidak diperlukan evaluasi ulang
  • Saat alur yang ingin menggunakan Layanan Koneksi ion berjalan:
    • Azure Pipelines memanggil fungsi pemeriksaan Anda
    • Jika alasannya selain Manual, pemeriksaan gagal, dan eksekusi alur gagal

Memeriksa kepatuhan

Panggil pemeriksaan Azure Function dan REST API sekarang menyertakan aturan untuk mencocokkan penggunaan yang direkomendasikan. Pemeriksaan perlu mengikuti aturan ini tergantung pada mode dan jumlah percobaan ulang:

  • Pemeriksaan asinkron (mode Panggilan balik): Azure Pipelines tidak mencoba kembali pemeriksaan asinkron. Anda harus memberikan hasil secara asinkron ketika evaluasi sudah final. Agar pemeriksaan asinkron dianggap sesuai, interval waktu antara evaluasi perlu 0.

  • Pemeriksaan sinkron (mode ApiResponse): Jumlah maksimum percobaan ulang untuk pemeriksaan Anda adalah 10. Anda dapat mengatur dalam sejumlah cara. Misalnya, Anda dapat mengonfigurasi batas waktu hingga 20 dan interval waktu antara evaluasi ke 2. Atau, Anda dapat mengonfigurasi batas waktu hingga 100 dan interval waktu antara evaluasi hingga 10. Tetapi, jika Anda mengonfigurasi batas waktu hingga 100 dan mengatur interval waktu antara evaluasi ke 2, pemeriksaan Anda tidak akan sesuai karena Anda meminta 50 percobaan ulang. Rasio interval waktu habis terhadap waktu antara evaluasi harus kurang dari atau sama dengan 10.

Pelajari selengkapnya tentang peluncuran kepatuhan pemeriksaan.

Beberapa pemeriksaan

Sebelum Azure Pipelines menyebarkan tahap dalam eksekusi alur, beberapa pemeriksaan mungkin perlu diteruskan. Sumber daya yang dilindungi mungkin memiliki satu atau beberapa Pemeriksaan yang terkait dengannya. Tahap dapat menggunakan beberapa sumber daya yang dilindungi. Azure Pipelines mengumpulkan semua pemeriksaan yang terkait dengan setiap sumber daya yang dilindungi yang digunakan dalam tahap dan mengevaluasinya secara bersamaan.

Eksekusi alur diizinkan untuk disebarkan ke tahap hanya ketika semua pemeriksaan lolos secara bersamaan. Satu keputusan negatif akhir menyebabkan alur ditolak aksesnya dan tahap gagal.

Ketika Anda menggunakan pemeriksaan dengan cara yang direkomendasikan (asinkron, dengan status akhir) membuat keputusan akses mereka menjadi final, dan memudahkan memahami status sistem.

Lihat bagian Beberapa Persetujuan dan Pemeriksaan misalnya.

Pelajari selengkapnya