Menangani kesalahan dan pengecualian di Azure Logic Apps
Berlaku untuk: Azure Logic Apps (Konsumsi + Standar)
Cara arsitektur integrasi apa pun menangani waktu henti atau masalah yang disebabkan oleh sistem dependen dapat menimbulkan tantangan. Untuk membantu Anda membuat integrasi yang kuat dan tangguh yang menangani masalah dan kegagalan dengan anggun, Azure Logic Apps memberikan pengalaman kelas satu untuk menangani kesalahan dan pengecualian.
Kebijakan percobaan kembali
Untuk pengecualian paling mendasar dan penanganan kesalahan, Anda dapat menggunakan kebijakan percobaan kembali saat didukung pada pemicu atau tindakan, seperti tindakan HTTP. Jika waktu permintaan asli pemicu atau tindakan habis atau gagal, menghasilkan respons 408, 429, atau 5xx, kebijakan percobaan kembali menentukan bahwa pemicu atau tindakan mengirim ulang permintaan per pengaturan kebijakan.
Batas kebijakan percobaan kembali
Untuk mengetahui informasi selengkapnya tentang kebijakan percobaan kembali, pengaturan, batas, dan opsi lainnya, tinjau Batas kebijakan percobaan kembali.
Jenis kebijakan percobaan kembali
Operasi konektor yang mendukung kebijakan percobaan kembali menggunakan kebijakan Default kecuali Anda memilih kebijakan percobaan kembali yang berbeda.
| Kebijakan percobaan kembali | Deskripsi |
|---|---|
| Default | Untuk sebagian besar operasi, kebijakan percobaan kembali Default adalah kebijakan interval eksponensial yang mengirimkan hingga 4 percobaan ulang pada interval meningkat secara eksponensial. Interval ini berskala 7,5 detik tetapi dibatasi antara 5 dan 45 detik. Beberapa operasi menggunakan kebijakan percobaan kembali Default yang berbeda, seperti kebijakan interval tetap. Untuk informasi selengkapnya, tinjau Jenis kebijakan percobaan kembali default. |
| Tidak ada | Jangan mengirim ulang permintaan. Untuk informasi lebih lanjut, tinjau Tidak ada - Tidak ada kebijakan percobaan kembali. |
| Interval Eksponensial | Kebijakan ini menunggu interval acak, yang dipilih dari rentang pertumbuhan eksponensial sebelum mengirim permintaan berikutnya. Untuk informasi selengkapnya, tinjau jenis kebijakan interval eksponensial. |
| Interval Tetap | Kebijakan ini menunggu interval yang ditentukan sebelum mengirim permintaan berikutnya. Untuk informasi selengkapnya, tinjau jenis kebijakan interval tetap. |
Mengubah jenis kebijakan percobaan kembali di perancang
Di portal Microsoft Azure, buka alur kerja aplikasi logika Anda di perancang.
Berdasarkan apakah Anda sedang mengerjakan alur kerja Konsumsi atau Standar, buka Pengaturan pemicu atau tindakan.
Konsumsi: Pada bentuk tindakan, buka menu elipsis (...), dan pilih Pengaturan.
Standar: Pada perancang, pilih tindakan. Pada panel detail, pilih Pengaturan.
Jika tindakan atau pemicu mendukung kebijakan percobaan kembali, di bawah Kebijakan Percobaan Kembali, pilih jenis kebijakan yang Anda inginkan.
Mengubah jenis kebijakan percobaan kembali di editor tampilan kode
Jika perlu, konfirmasi apakah pemicu atau tindakan mendukung kebijakan percobaan kembali dengan menyelesaikan langkah-langkah sebelumnya di perancang.
Buka alur kerja aplikasi logika Anda di editor tampilan kode.
Dalam definisi pemicu atau tindakan, tambahkan objek JSON
retryPolicyke objekinputspemicu atau tindakan tersebut. Jika tidak, jika tidak ada objekretryPolicy, pemicu atau tindakan menggunakan kebijakan percobaan kembalidefault."inputs": { <...>, "retryPolicy": { "type": "<retry-policy-type>", // The following properties apply to specific retry policies. "count": <retry-attempts>, "interval": "<retry-interval>", "maximumInterval": "<maximum-interval>", "minimumInterval": "<minimum-interval>" }, <...> }, "runAfter": {}Diperlukan
Properti Nilai Tipe Deskripsi type<retry-policy-type> String Jenis kebijakan percobaan kembali yang ingin Anda gunakan: default,none,fixed, atauexponentialcount<retry-attempts> Bilangan bulat Untuk jenis kebijakan fixeddanexponential, jumlah upaya percobaan kembali, yang merupakan nilai dari 1 - 90. Untuk mengetahui informasi selengkapnya, tinjau Interval Tetap dan Interval Eksponensial.interval<retry-interval> String Untuk jenis kebijakan fixeddanexponential, nilai interval percobaan kembali dalam Format ISO 8601. Untuk kebijakanexponential, Anda juga dapat menentukan interval maksimum dan minimum opsional. Untuk mengetahui informasi selengkapnya, tinjau Interval Tetap dan Interval Eksponensial.
Konsumsi: 5 detik (PT5S) hingga 1 hari (P1D).
Standar: Untuk alur kerja stateful, 5 detik (PT5S) hingga 1 hari (P1D). Untuk alur kerja tanpa status, 1 detik (PT1S) hingga 1 menit (PT1M).Opsional
Properti Nilai Tipe Deskripsi maximumInterval<maximum-interval> String Untuk kebijakan exponential, interval terbesar untuk interval yang dipilih secara acak dalam format ISO 8601. Nilai defaultnya adalah 1 hari (P1D). Untuk mengetahui informasi selengkapnya, tinjau Interval Eksponensial.minimumInterval<minimum-interval> String Untuk kebijakan exponential, interval terkecil untuk interval yang dipilih secara acak dalam format ISO 8601. Nilai default-nya adalah 5 detik (PT5S). Untuk mengetahui informasi selengkapnya, tinjau Interval Eksponensial.
Kebijakan percobaan kembali default
Operasi konektor yang mendukung kebijakan percobaan kembali menggunakan kebijakan Default kecuali Anda memilih kebijakan percobaan kembali yang berbeda. Untuk sebagian besar operasi, kebijakan percobaan kembali Default adalah kebijakan interval eksponensial yang mengirimkan hingga 4 percobaan ulang pada interval meningkat secara eksponensial. Interval ini berskala 7,5 detik tetapi dibatasi antara 5 dan 45 detik. Beberapa operasi menggunakan kebijakan percobaan kembali Default yang berbeda, seperti kebijakan interval tetap.
Dalam definisi alur kerja Anda, definisi pemicu atau tindakan tidak secara eksplisit menentukan kebijakan default, tetapi contoh berikut menunjukkan bagaimana kebijakan percobaan kembali default berperilaku untuk tindakan HTTP:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "http://myAPIendpoint/api/action",
"retryPolicy" : {
"type": "exponential",
"interval": "PT7S",
"count": 4,
"minimumInterval": "PT5S",
"maximumInterval": "PT1H"
}
},
"runAfter": {}
}
Tidak Ada - Tidak ada kebijakan percobaan kembali
Untuk menentukan bahwa tindakan atau pemicu tidak mencoba lagi permintaan yang gagal, atur <retry-policy-type> ke none.
Memperbaiki kebijakan percobaan kembali interval
Untuk menentukan bahwa tindakan atau pemicu menunggu interval yang ditentukan sebelum mengirim permintaan berikutnya, atur <retry-policy-type> ke fixed.
Contoh
Kebijakan percobaan kembali ini mencoba untuk mendapatkan berita terbaru dua kali lagi setelah permintaan pertama yang gagal dengan penundaan 30 detik antara setiap upaya:
"Get_latest_news": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://mynews.example.com/latest",
"retryPolicy": {
"type": "fixed",
"interval": "PT30S",
"count": 2
}
}
}
Kebijakan percobaan kembali interval eksponensial
Kebijakan percobaan kembali interval eksponensial menentukan bahwa pemicu atau tindakan menunggu interval acak sebelum mengirim permintaan berikutnya. Interval acak dipilih dari rentang pertumbuhan eksponensial. Secara opsional, Anda dapat mengganti interval minimum dan maksimum default dengan menentukan interval minimum dan maksimum Anda sendiri, berdasarkan apakah Anda memiliki alur kerja aplikasi logika Konsumsi atau Standar.
| Nama | Batas konsumsi | Batas standar | Catatan |
|---|---|---|---|
| Penundaan maksimum | Default: 1 hari | Default: 1 jam | Untuk mengubah batas default dalam alur kerja aplikasi logika Konsumsi, gunakan parameter kebijakan percobaan kembali. Untuk mengubah batas default di alur kerja aplikasi logika Standar, tinjau Mengedit host dan pengaturan aplikasi untuk aplikasi logika di Azure Logic Apps penyewa tunggal. |
| Penundaan minimum | Default: 5 detik | Default: 5 detik | Untuk mengubah batas default dalam alur kerja aplikasi logika Konsumsi, gunakan parameter kebijakan percobaan kembali. Untuk mengubah batas default di alur kerja aplikasi logika Standar, tinjau Mengedit host dan pengaturan aplikasi untuk aplikasi logika di Azure Logic Apps penyewa tunggal. |
Rentang variabel acak
Untuk kebijakan percobaan kembali interval eksponensial, tabel berikut menunjukkan algoritme umum yang Azure Logic Apps gunakan untuk menghasilkan variabel acak yang seragam dalam rentang yang ditentukan untuk setiap percobaan kembali. Rentang yang ditentukan bisa sampai dan termasuk jumlah percobaan kembali.
| Jumlah percobaan kembali | Interval minimum | Interval maksimum |
|---|---|---|
| 1 | max(0, <minimum-interval>) | min(interval, <maximum-interval>) |
| 2 | max(interval, <minimum-interval>) | min(2 * interval, <maximum-interval>) |
| 3 | max(2 * interval, <minimum-interval>) | min(4 * interval, <maximum-interval>) |
| 4 | max(4 * interval, <minimum-interval>) | min(8 * interval, <maximum-interval>) |
| .... | .... | .... |
Mengelola perilaku "jalankan setelah"
Saat menambahkan tindakan dalam perancang alur kerja, Anda secara implisit mendeklarasikan urutan yang akan digunakan untuk menjalankan tindakan tersebut. Setelah tindakan selesai berjalan, tindakan tersebut ditandai dengan status seperti Berhasil, Gagal, Dilewati, atau Waktu Habis. Secara default, tindakan yang Anda tambahkan di perancang hanya berjalan setelah pendahulunya selesai dengan status Berhasil. Dalam setiap definisi tindakan, properti runAfter menentukan tindakan pendahulu yang harus terlebih dahulu selesai dan status yang diizinkan untuk pendahulunya sebelum tindakan penerus dapat berjalan.
Saat tindakan melemparkan kesalahan atau pengecualian yang tidak tertangani, tindakan ditandai Gagal, dan tindakan penerus ditandai Dilewati. Jika perilaku ini terjadi untuk tindakan yang memiliki cabang paralel, mesin Azure Logic Apps mengikuti cabang lain untuk menentukan status penyelesaiannya. Misalnya, jika cabang berakhir dengan tindakan Dilewati, status penyelesaian cabang tersebut didasarkan pada status tindakan yang dilewati pendahulunya. Setelah aplikasi logika selesai, mesin menentukan seluruh status eksekusi dengan mengevaluasi semua status cabang. Jika ada cabang yang berakhir dengan kegagalan, seluruh aplikasi logika yang dijalankan ditandai dengan Gagal.
Untuk memastikan bahwa suatu tindakan masih dapat berjalan meskipun status pendahulunya, Anda dapat mengubah perilaku "jalankan setelah" tindakan untuk menangani status pendahulunya yang gagal. Dengan begitu, tindakan berjalan saat status pendahulunya Berhasil, Gagal,Dilewati, Waktu Habis, atau semua status ini.
Misalnya, untuk menjalankan tindakan Office 365 Outlook Kirim email setelah Excel Online tindakan pendahulu Tambahkan baris ke dalam tabel ditandai Gagal, bukan Berhasil, ubah perilaku "jalankan setelah" menggunakan perancang atau editor tampilan kode.
Catatan
Di perancang, pengaturan "jalankan setelah" tidak berlaku untuk tindakan yang segera mengikuti pemicu karena pemicu harus berjalan dengan sukses sebelum tindakan pertama dapat berjalan.
Mengubah perilaku "jalankan setelah" di perancang
Di portal Azure, buka alur kerja aplikasi logika di perancang.
Di perancang, pilih bentuk tindakan. Di panel detail, pilih Jalankan Setelah.
Panel Jalankan Setelah menampilkan tindakan pendahulu untuk tindakan yang saat ini dipilih.
Perluas node tindakan pendahulu untuk melihat semua status "jalankan setelah".
Secara default, status "jalankan setelah" diatur ke berhasil. Jadi, tindakan pendahulunya harus berjalan dengan sukses sebelum tindakan yang saat ini dipilih dapat berjalan.
Ubah perilaku "jalankan setelah" ke status yang Anda inginkan. Pastikan Anda terlebih dahulu memilih opsi sebelum menghapus opsi default. Anda harus selalu memilih setidaknya satu opsi.
Contoh berikut memilih telah gagal.
Untuk menentukan bahwa tindakan saat ini berjalan saat tindakan pendahulu ditandai sebagai Gagal, Dilewati, atau Waktu Habis, pilih status lainnya.
Untuk mengharuskan lebih dari satu tindakan pendahulu berjalan, masing-masing dengan status "jalankan setelah" mereka sendiri, perluas daftar Pilih tindakan. Pilih tindakan pendahulu yang Anda inginkan, dan tentukan status "jalankan setelah" yang diperlukan.
Jika Anda sudah siap, pilih Selesai.
Mengubah perilaku "jalankan setelah" di editor tampilan kode
Di portal Azure, buka alur kerja aplikasi logika Anda di editor tampilan kode.
Dalam definisi JSON tindakan, edit properti
runAfter, yang mengikuti sintaksis berikut:"<action-name>": { "inputs": { "<action-specific-inputs>" }, "runAfter": { "<preceding-action>": [ "Succeeded" ] }, "type": "<action-type>" }Untuk contoh ini, ubah properti
runAfterdariSucceededmenjadiFailed:"Send_an_email_(V2)": { "inputs": { "body": { "Body": "<p>Failed to add row to table: @{body('Add_a_row_into_a_table')?['Terms']}</p>", "Subject": "Add row to table failed: @{body('Add_a_row_into_a_table')?['Terms']}", "To": "Sophia.Owen@fabrikam.com" }, "host": { "connection": { "name": "@parameters('$connections')['office365']['connectionId']" } }, "method": "post", "path": "/v2/Mail" }, "runAfter": { "Add_a_row_into_a_table": [ "Failed" ] }, "type": "ApiConnection" }Untuk menentukan bahwa tindakan berjalan saat apakah tindakan pendahulu ditandai sebagai
Failed,Skipped, atauTimedOut, tambahkan status lainnya:"runAfter": { "Add_a_row_into_a_table": [ "Failed", "Skipped", "TimedOut" ] },
Evaluasi tindakan dengan cakupan dan hasilnya
Mirip dengan menjalankan langkah-langkah setelah tindakan individual dengan pengaturan “jalankan setelah”, Anda dapat mengelompokkan tindakan bersama-sama di dalam sebuah cakupan. Anda dapat menggunakan cakupan saat Anda ingin mengelompokkan secara logis tindakan bersama-sama, menilai status agregat cakupan, dan melakukan tindakan berdasarkan status tersebut. Setelah semua tindakan dalam cakupan selesai berjalan, ruang cakupan juga mendapatkan statusnya sendiri.
Untuk memeriksa status cakupan, Anda dapat menggunakan kriteria yang sama dengan yang Anda gunakan untuk menentukan status eksekusi alur kerja, seperti Berhasil, Gagal, dan sebagainya.
Secara default, saat semua tindakan cakupan berhasil, status cakupan ditandai sebagai Berhasil. Jika tindakan final dalam cakupan ditandai Gagal atau Dibatalkan, status cakupan ditandai Gagal.
Untuk menangkap pengecualian dalam cakupan Gagal dan menjalankan tindakan yang menangani kesalahan tersebut, Anda dapat menggunakan pengaturan “jalankan setelah” cakupan Gagal tersebut. Dengan demikian, jika ada tindakan dalam cakupan yang gagal, dan Anda menggunakan pengaturan “jalankan setelah” untuk cakupan tersebut, Anda dapat membuat satu tindakan untuk menangkap kegagalan.
Untuk batasan cakupan, lihat Batas dan konfigurasi.
Dapatkan konteks dan hasil untuk kegagalan
Meskipun menangkap kegagalan dari cakupan berguna, Anda mungkin juga menginginkan lebih banyak konteks untuk membantu mempelajari tindakan gagal yang tepat ditambah kesalahan atau kode status apa pun. Fungsi result() mengembalikan hasil dari tindakan tingkat atas dalam tindakan tercakup. Fungsi ini menerima nama cakupan sebagai parameter tunggal, dan mengembalikan array dengan hasil dari tindakan tingkat atas tersebut. Objek tindakan ini mencakup atribut yang sama dengan atribut yang dikembalikan oleh fungsi actions(), seperti waktu mulai tindakan, waktu berakhir, status, masukan, ID korelasi, dan output.
Catatan
Fungsi result() mengembalikan hasil hanya dari tindakan tingkat pertama dan bukan dari tindakan bertumpuk yang lebih dalam seperti tindakan pengalih atau kondisi.
Untuk mendapatkan konteks tentang tindakan yang gagal dalam cakupan, Anda dapat menggunakan ekspresi @result() dengan nama cakupan dan pengaturan “jalankan setelah”. Untuk memfilter array yang dikembalikan ke tindakan yang memiliki status Gagal, Anda dapat menambahkan tindakan Filter Array. Untuk menjalankan tindakan untuk tindakan gagal yang dikembalikan, ambil array yang difilter yang dikembalikan dan gunakan loop For each.
Contoh JSON berikut mengirimkan permintaan HTTP POST dengan badan respons untuk tindakan apa pun yang gagal dalam tindakan cakupan bernama My_Scope. Penjelasan terperinci mengikuti contoh.
"Filter_array": {
"type": "Query",
"inputs": {
"from": "@result('My_Scope')",
"where": "@equals(item()['status'], 'Failed')"
},
"runAfter": {
"My_Scope": [
"Failed"
]
}
},
"For_each": {
"type": "foreach",
"actions": {
"Log_exception": {
"type": "Http",
"inputs": {
"method": "POST",
"body": "@item()['outputs']['body']",
"headers": {
"x-failed-action-name": "@item()['name']",
"x-failed-tracking-id": "@item()['clientTrackingId']"
},
"uri": "http://requestb.in/"
},
"runAfter": {}
}
},
"foreach": "@body('Filter_array')",
"runAfter": {
"Filter_array": [
"Succeeded"
]
}
}
Langkah-langkah berikut menjelaskan apa yang terjadi dalam contoh ini:
Untuk mendapatkan hasil dari semua tindakan di dalam My_Scope, tindakan Filter Array menggunakan ekspresi filter ini:
@result('My_Scope')Kondisi untuk Filter Array adalah item
@result()apa pun yang memiliki status sama denganFailed. Kondisi ini memfilter array yang memiliki semua hasil tindakan dari My_Scope ke array dengan hanya hasil tindakan yang gagal.Lakukan tindakan loop
For_eachpada output array yang difilter. Langkah ini melakukan tindakan untuk setiap hasil tindakan yang gagal yang sebelumnya difilter.Jika satu tindakan dalam cakupan gagal, tindakan dalam loop
For_eachhanya berjalan sekali. Beberapa tindakan yang gagal menyebabkan satu tindakan per kegagalan.Kirim HTTP POST pada isi respons item
For_each, yang merupakan ekspresi@item()['outputs']['body'].Bentuk item
@result()sama dengan bentuk@actions()dan dapat diurai dengan cara yang sama.Sertakan dua header kustom dengan nama tindakan yang gagal (
@item()['name']) dan ID pelacakan klien yang gagal dijalankan (@item()['clientTrackingId']).
Sebagai referensi, berikut ini contoh item tunggal @result(), yang memperlihatkan properti name, body, dan clientTrackingId yang diuraikan dalam contoh sebelumnya. Di luar tindakan For_each, @result() mengembalikan array objek ini.
{
"name": "Example_Action_That_Failed",
"inputs": {
"uri": "https://myfailedaction.azurewebsites.net",
"method": "POST"
},
"outputs": {
"statusCode": 404,
"headers": {
"Date": "Thu, 11 Aug 2016 03:18:18 GMT",
"Server": "Microsoft-IIS/8.0",
"X-Powered-By": "ASP.NET",
"Content-Length": "68",
"Content-Type": "application/json"
},
"body": {
"code": "ResourceNotFound",
"message": "/docs/folder-name/resource-name does not exist"
}
},
"startTime": "2016-08-11T03:18:19.7755341Z",
"endTime": "2016-08-11T03:18:20.2598835Z",
"trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
"clientTrackingId": "08587307213861835591296330354",
"code": "NotFound",
"status": "Failed"
}
Untuk melakukan pola penanganan pengecualian yang berbeda, Anda bisa menggunakan ekspresi yang sebelumnya dijelaskan dalam artikel ini. Anda dapat memilih untuk menjalankan satu tindakan penanganan pengecualian di luar cakupan yang menerima seluruh array kegagalan yang difilter, dan menghapus tindakan For_each. Anda juga dapat menyertakan properti berguna lainnya dari respons \@result() seperti yang dijelaskan sebelumnya.
Menyiapkan log Azure Monitor
Pola sebelumnya adalah cara yang berguna untuk menangani kesalahan dan pengecualian yang terjadi dalam eksekusi. Namun, Anda juga dapat mengidentifikasi dan menanggapi kesalahan yang terjadi secara independen dari eksekusi. Untuk mengevaluasi status eksekusi, Anda dapat memantau log serta metriknya, atau menerbitkannya ke alat pemantauan pilihan Anda.
Contohnya, Azure Monitor menyediakan cara yang efisien untuk mengirim semua aktivitas alur kerja, termasuk semua status proses dan tindakan, ke tujuan. Anda dapat menyiapkan peringatan untuk metrik dan ambang batas tertentu di Azure Monitor. Anda juga dapat mengirimkan peristiwa alur kerja ke ruang kerja Log Analytics atau akun penyimpanan Azure. Atau Anda dapat memutar seluruh peristiwa melalui Azure Event Hubs ke dalam Azure Stream Analytics. Di Stream Analytics, Anda dapat menulis kueri langsung berdasarkan anomali, rata-rata, atau kegagalan dari log diagnostik. Anda bisa menggunakan Stream Analytics untuk mengirim informasi ke sumber data lain, seperti antrean, topik, SQL, Azure Cosmos DB, atau Power BI.
Informasi selengkapnya, lihat Menyiapkan log Azure Monitor serta mengumpulkan data diagnostik untuk Azure Logic Apps.