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 coba lagi jika kemampuan ini ada 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	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 sumber daya aplikasi logika Anda.
Di bilah sisi sumber daya, ikuti langkah-langkah ini untuk membuka perancang alur kerja, berdasarkan aplikasi logika Anda:
- Penggunaan: Di bawah Alat Pengembangan, pilih pembuat desain untuk membuka alur kerja Anda.
- Standar
  1. Di bawah Alur Kerja, pilih Alur Kerja.
  2. Dari halaman Alur Kerja , pilih alur kerja Anda.
  3. Di bawah Alat, pilih perancang untuk membuka alur kerja Anda.
Pada pemicu atau tindakan di mana Anda ingin mengubah jenis kebijakan coba lagi, ikuti langkah-langkah berikut untuk membuka pengaturan:
1. Pada perancang, pilih operasi.
2. Pada panel informasi operasi, pilih Pengaturan.
3. Di bawah Jaringan, di bawah Kebijakan coba lagi, pilih jenis kebijakan yang Anda inginkan.

Mengubah jenis kebijakan percobaan kembali di editor tampilan kode

Konfirmasi apakah pemicu atau tindakan mendukung kebijakan coba lagi dengan menyelesaikan langkah-langkah sebelumnya di perancang.
Buka alur kerja aplikasi logika Anda di editor tampilan kode.

Dalam definisi pemicu atau tindakan, tambahkan retryPolicy objek JSON ke objek pemicu atau tindakan inputs . Jika tidak ada retryPolicy objek, pemicu atau tindakan menggunakan default kebijakan pengulangan.

"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`	< jenis kebijakan retry>	string	Jenis kebijakan percobaan kembali yang ingin Anda gunakan: `default`, `none`, `fixed`, atau `exponential`
`count`	< coba lagi>	Bilangan bulat	Untuk jenis kebijakan `fixed` dan `exponential`, jumlah upaya percobaan kembali, yang merupakan nilai dari 1 - 90. Untuk mengetahui informasi selengkapnya, tinjau Interval Tetap dan Interval Eksponensial.
`interval`	< interval coba lagi>	string	Untuk jenis kebijakan `fixed` dan `exponential`, nilai interval percobaan kembali dalam Format ISO 8601. Untuk kebijakan `exponential`, 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`	< interval maksimum>	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`	< interval minimum>	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.

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

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	maks(0, <interval minimum>)	min(interval, <maksimum-interval>)
2	max(interval, <minimum-interval>)	min(2 * interval, <maksimum interval>)
3	maks(2 * interval, <minimum-interval>)	min(4 * interval, <maksimum-interval>)
4	maks(4 * interval, <interval-minimum>)	min(8 * interval, <interval maksimum>)
....	....	....

Mengelola perilaku "jalankan setelah"

Saat Anda menambahkan tindakan di perancang alur kerja, Anda secara implisit mendeklarasikan urutan untuk menjalankan tindakan tersebut. Setelah tindakan selesai berjalan, tindakan tersebut ditandai dengan status seperti Berhasil, Gagal, Dilewati, atau Waktu Habis. Dengan kata lain, tindakan pendahulu harus terlebih dahulu selesai dengan salah satu status yang diizinkan sebelum tindakan penerus dapat berjalan.

Secara default, tindakan yang Anda tambahkan dalam perancang hanya berjalan jika tindakan sebelumnya selesai dengan status Berhasil . Ini perilaku 'run after' secara tepat menentukan urutan eksekusi untuk tindakan dalam alur kerja.

Di dalam perancang, Anda dapat mengubah perilaku default "run after" untuk tindakan dengan mengedit pengaturan Jalankan setelah tindakan. Pengaturan ini hanya tersedia pada tindakan berikutnya yang mengikuti tindakan pertama dalam alur kerja. Tindakan pertama dalam alur kerja selalu berjalan setelah pemicu berhasil dijalankan. Jadi, pengaturan Jalankan setelah tidak tersedia dan tidak berlaku untuk tindakan pertama.

Dalam definisi JSON yang mendasari tindakan, pengaturan Jalankan setelah sama dengan runAfter properti . Properti ini menentukan satu atau beberapa tindakan pendahulu yang harus terlebih dahulu selesai dengan status tertentu yang diizinkan sebelum tindakan penerus dapat berjalan. Properti runAfter adalah objek JSON yang memberikan fleksibilitas dengan memungkinkan Anda menentukan semua tindakan pendahulu yang harus diselesaikan sebelum tindakan penerus berjalan. Objek ini juga menentukan array status yang dapat diterima.

Misalnya, untuk menjalankan tindakan setelah tindakan A berhasil dan juga setelah tindakan B berhasil atau gagal saat Anda mengerjakan definisi JSON tindakan, siapkan properti berikut runAfter :

{
   // Other parts in action definition
   "runAfter": {
      "Action A": ["Succeeded"],
      "Action B": ["Succeeded", "Failed"]
    }
}

Perilaku "Pasca Eksekusi" untuk penanganan kesalahan

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.

Mengubah perilaku "jalankan setelah" di perancang

Di portal Microsoft Azure, buka sumber daya aplikasi logika Anda.
Di bilah sisi sumber daya, ikuti langkah-langkah ini untuk membuka perancang alur kerja, berdasarkan aplikasi logika Anda:
- Penggunaan: Di bawah Alat Pengembangan, pilih pembuat desain untuk membuka alur kerja Anda.
- Standar
  1. Pada bilah sisi sumber daya, di bawah Alur Kerja, pilih Alur Kerja.
  2. Dari halaman Alur Kerja , pilih alur kerja Anda.
  3. Di bawah Alat, pilih perancang untuk membuka alur kerja Anda.
Pada pemicu atau tindakan di mana Anda ingin mengubah perilaku "jalankan setelah", ikuti langkah-langkah berikut untuk membuka pengaturan operasi:
1. Pada perancang, pilih operasi.
2. Pada panel informasi operasi, pilih Pengaturan.
  
  Bagian Jalankan setelah berisi daftar Pilih tindakan , yang memperlihatkan operasi pendahulu yang tersedia untuk operasi yang saat ini dipilih, misalnya:
3. Di bawah daftar Pilih tindakan , perluas operasi pendahulu saat ini, yaitu HTTP dalam contoh ini:
  
  Secara default, status "jalankan setelah" diatur ke Berhasil. Nilai ini berarti operasi pendahulu harus berhasil diselesaikan sebelum tindakan saat ini dapat berjalan.
Untuk mengubah perilaku "jalankan setelah" ke status yang Anda inginkan, pilih status tersebut.

Contoh berikut memilih Telah gagal.
Untuk menentukan bahwa operasi saat ini hanya berjalan ketika tindakan pendahulu selesai dengan status Telah gagal, Dilewati, atau Telah kehabisan waktu , pilih status ini, lalu kosongkan status default, misalnya:

Catatan

Sebelum Anda menghapus status default, pastikan Anda terlebih dahulu memilih status lain. Anda harus selalu memilih setidaknya satu status.
Untuk mengharuskan beberapa operasi pendahulu dijalankan dan diselesaikan, masing-masing dengan status "jalankan setelah" mereka sendiri, ikuti langkah-langkah berikut ini:
1. Buka daftar Pilih tindakan , dan pilih operasi pendahulu yang Anda inginkan.
2. Pilih status "dijalankan setelahnya" untuk setiap operasi.
Setelah selesai, tutup panel informasi operasi.

Mengubah perilaku "jalankan setelah" di editor tampilan kode

Di bilah sisi sumber daya, ikuti langkah-langkah ini untuk membuka editor tampilan kode, berdasarkan aplikasi logika Anda:
- Konsumsi: Di bawah Alat Pengembangan, pilih tampilan kode untuk membuka alur kerja Anda di editor JSON.
- Standar
  1. Di bawah Alur Kerja, pilih Alur Kerja.
  2. Dari halaman Alur Kerja , pilih alur kerja Anda.
  3. Di bawah Alat, pilih tampilan kode untuk membuka alur kerja Anda di editor JSON.

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 runAfter dari Succeeded menjadi Failed:

"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, atau TimedOut, 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.

Menyiapkan cakupan dengan "run after" untuk penanganan pengecualian

Di portal Microsoft Azure, buka sumber daya dan alur kerja aplikasi logika Anda di perancang.

Alur kerja Anda harus sudah memiliki pemicu yang memulai alur kerja.
Pada perancang, ikuti langkah-langkah umum ini untuk menambahkan tindakan Kontrol bernama Cakupan ke alur kerja Anda.
Dalam tindakan Cakupan, ikuti langkah-langkah umum ini ke tambahkan tindakan yang akan dijalankan, misalnya:

Daftar berikut ini memperlihatkan beberapa contoh tindakan yang mungkin Anda sertakan di dalam tindakan Cakupan :
- Mendapatkan data dari API.
- Memproses data.
- Simpan data ke database.
Sekarang tentukan aturan "jalankan setelah" untuk menjalankan tindakan dalam cakupan.
1. Pada perancang, pilih judul Cakupan . Saat panel informasi cakupan terbuka, pilih Pengaturan.
2. Jika Anda memiliki lebih dari satu tindakan sebelumnya dalam alur kerja, dari daftar Pilih tindakan , pilih tindakan setelah itu Anda ingin menjalankan tindakan terlingkup.
3. Untuk tindakan yang dipilih, pilih semua status tindakan yang dapat menjalankan tindakan terlingkup.
  
  Dengan kata lain, salah satu status yang dipilih yang dihasilkan dari tindakan yang dipilih menyebabkan tindakan dalam cakupan berjalan.
  
  Dalam contoh berikut, tindakan terlingkup berjalan setelah tindakan HTTP selesai dengan salah satu status yang dipilih:

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 dengan Failed. Kondisi ini memfilter array yang memiliki semua hasil tindakan dari My_Scope ke array dengan hanya hasil tindakan yang gagal.
Lakukan tindakan loop For_each pada 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_each hanya 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.

Contoh dan skenario Azure Logic Apps

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2025-07-09