Azure Logic Apps'te iş akışı hatalarını ve istisnalarını ele alın

Şunlar için geçerlidir: Azure Logic Apps (Tüketim + Standart)

Herhangi bir tümleştirme mimarisinin kapalı kalma süresini veya bağımlı sistemlerin neden olduğu sorunları uygun şekilde işlemesi zor olabilir. Azure Logic Apps, sorunları ve hataları düzgün bir şekilde işleyen güçlü ve dayanıklı tümleştirmeler oluşturmanıza yardımcı olmak için hataları ve özel durumları işlemeye yönelik birinci sınıf bir deneyim sağlar.

İlkeleri yeniden deneme

En temel özel durum ve hata işleme için, bu özellik HTTP eylemi gibi bir tetikleyicide veya eylemde varsa yeniden deneme ilkesini kullanabilirsiniz. Tetikleyicinin veya eylemin özgün isteği zaman aşımına ularsa veya başarısız olursa ve 408, 429 veya 5xx yanıtıyla sonuçlanırsa, yeniden deneme ilkesi tetikleyicinin veya eylemin ilke ayarlarına göre isteği yeniden gönderdiğini belirtir.

İlke sınırlarını yeniden deneme

Yeniden deneme ilkeleri, ayarlar, sınırlar ve diğer seçenekler hakkında daha fazla bilgi için Yeniden deneme ilkesi sınırları bölümünü gözden geçirin.

İlke türlerini yeniden deneme

Yeniden deneme ilkelerini destekleyen bağlayıcı işlemleri, farklı bir yeniden deneme ilkesi seçmediğiniz sürece Varsayılan ilkeyi kullanır.

Yeniden deneme ilkesi	Açıklama
Varsayılan	Çoğu işlem için Varsayılan yeniden deneme ilkesi, üstel olarak artan aralıklarda en fazla 4 yeniden deneme gönderen bir üstel aralık ilkesidir. Bu aralıklar 7,5 saniyelik artışlarla ölçeklendirilir, ancak 5 ila 45 saniye ile sınırlandırılmıştır. Çeşitli işlemler, sabit aralık ilkesi gibi farklı bir Varsayılan yeniden deneme ilkesi kullanır. Daha fazla bilgi için Varsayılan yeniden deneme ilkesi türünü gözden geçirin.
Hiçbiri	İsteği yeniden göndermeyin. Daha fazla bilgi için Yok - Yeniden deneme ilkesi yok'u gözden geçirin.
Üstel Aralık	Bu ilke, bir sonraki isteği göndermeden önce üstel olarak büyüyen bir aralıktan seçilen rastgele bir aralığı bekler. Daha fazla bilgi için üstel aralık ilkesi türünü gözden geçirin.
Sabit Aralık	Bu ilke, bir sonraki isteği göndermeden önce belirtilen aralığı bekler. Daha fazla bilgi için sabit aralıklı ilke türünü gözden geçirin.

Tasarımcıda yeniden deneme ilkesi türünü değiştirme

Azure portalında mantıksal uygulama kaynağınızı açın.
Kaynak kenar çubuğunda, mantıksal uygulamanızı temel alan iş akışı tasarımcısını açmak için şu adımları izleyin:
- Tüketim: Geliştirme Araçları'nın altında iş akışınızı açmak için tasarımcıyı seçin.
- Standart
  1. İş Akışları'nın altında İş Akışları'yı seçin.
  2. İş Akışları sayfasından iş akışınızı seçin.
  3. Araçlar'ın altında iş akışınızı açmak için tasarımcıyı seçin.
Yeniden deneme ilkesi türünü değiştirmek istediğiniz tetikleyicide veya eylemde ayarları açmak için şu adımları izleyin:
1. Tasarımcıda işlemi seçin.
2. İşlem bilgileri bölmesinde Ayarlar'ı seçin.
3. Ağ altında, Yeniden Deneme Politikası altında, istediğiniz ilke türünü seçin.

Kod görünümü düzenleyicisinde yeniden deneme ilkesi türünü değiştirme

Tasarımcıda önceki adımları tamamlayarak tetikleyicinin veya eylemin yeniden deneme ilkelerini destekleyip desteklemediğini onaylayın.
Mantıksal uygulama iş akışınızı kod görünümü düzenleyicisinde açın.

Tetikleyici veya eylem tanımında JSON nesnesini tetikleyicinin veya eylemin retryPolicy nesnesine ekleyininputs. Eğer retryPolicy nesne mevcut değilse, tetikleyici veya eylem default yeniden deneme politikasını kullanır.

"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": {}

Zorunlu

Özellik	Değer	Type	Açıklama
`type`	< tekrar-deneme-politikası-türü>	Dize	Kullanılacak yeniden deneme ilkesi türü: `default`, `none`, `fixed`veya `exponential`
`count`	< yeniden deneme denemeleri>	Tamsayı	`fixed` ve `exponential` ilke türleri için, 1 ile 90 arasında bir değer olan yeniden deneme sayısı. Daha fazla bilgi için Sabit Aralık ve Üstel Aralık'ı gözden geçirin.
`interval`	< yeniden deneme aralığı>	Dize	`fixed` ve `exponential` ilke türleri için, yeniden deneme aralığı değeri ISO 8601 biçiminde olmalıdır. İlke için `exponential` isteğe bağlı maksimum ve en düşük aralıkları da belirtebilirsiniz. Daha fazla bilgi için Sabit Aralık ve Üstel Aralık'ı gözden geçirin. Tüketim: 5 saniye (`PT5S`) ile 1 gün (`P1D`). Standart: Durum bilgisi olan iş akışları için 5 saniye (`PT5S`) ile 1 gün (`P1D`). Durum bilgisi olmayan iş akışları için 1 saniye (`PT1S`) ile 1 dakika (`PT1M`).

Opsiyonel

Özellik	Değer	Type	Açıklama
`maximumInterval`	< maksimum aralık>	Dize	`exponential` ilkesi için, ISO 8601 biçimindeki rastgele seçilen aralık için en büyük aralık. Varsayılan değer 1 gündür (`P1D`). Daha fazla bilgi için, Üstel Aralık bölümünü inceleyin.
`minimumInterval`	< minimum aralık>	Dize	`exponential` ilkesi için, ISO 8601 biçimindeki rastgele seçilen aralık için en küçük aralık. Varsayılan değer 5 saniyedir (`PT5S`). Daha fazla bilgi için Üstel Aralık'ı inceleyin.

Varsayılan yeniden deneme ilkesi

Yeniden deneme ilkelerini destekleyen bağlayıcı işlemleri, farklı bir yeniden deneme ilkesi seçmediğiniz sürece Varsayılan ilkeyi kullanır. Çoğu işlem için Varsayılan yeniden deneme ilkesi, üstel olarak artan aralıklarda en fazla 4 yeniden deneme gönderen bir üstel aralık ilkesidir. Bu aralıklar 7,5 saniyelik artışlarla ölçeklendirilir, ancak 5 ila 45 saniye ile sınırlandırılmıştır. Çeşitli işlemler, sabit aralık ilkesi gibi farklı bir Varsayılan yeniden deneme ilkesi kullanır.

İş akışı tanımınızda tetikleyici veya eylem tanımı varsayılan ilkeyi açıkça tanımlamaz, ancak aşağıdaki örnekte varsayılan yeniden deneme ilkesinin HTTP eylemi için nasıl davrandığı gösterilir:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "http://myAPIendpoint/api/action",
      "retryPolicy" : {
         "type": "exponential",
         "interval": "PT7S",
         "count": 4,
         "minimumInterval": "PT5S",
         "maximumInterval": "PT1H"
      }
   },
   "runAfter": {}
}

Yok - Yeniden deneme ilkesi yok

Eylemin veya tetikleyicinin başarısız istekleri yeniden denememesini belirtmek için <retry-policy-type> değerini none olarak ayarlayın.

Sabit aralıklı yeniden deneme ilkesi

Eylemin veya tetikleyicinin bir sonraki isteği göndermeden önce belirtilen aralığı beklemesini sağlamak için <retry-policy-type> değerini fixed olarak ayarlayın.

Örnek

Bu yeniden deneme ilkesi, ilk başarısız istek sonrasında her deneme arasında 30 saniyelik bir gecikmeyle en son haberleri iki kez daha almaya çalışır:

"Get_latest_news": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest",
      "retryPolicy": {
         "type": "fixed",
         "interval": "PT30S",
         "count": 2
      }
   }
}

Üstel aralıklı yeniden deneme ilkesi

Üstel aralık yeniden deneme ilkesi, tetikleyicinin veya eylemin bir sonraki isteği göndermeden önce rastgele bir aralık beklediğini belirtir. Bu rastgele aralık, üstel olarak büyüyen bir aralıktan seçilir. İsteğe bağlı olarak, Tüketim veya Standart mantıksal uygulama iş akışınız olup olmadığına bağlı olarak kendi minimum ve maksimum aralıklarınızı belirterek varsayılan minimum ve maksimum aralıkları geçersiz kılabilirsiniz.

Veri Akışı Adı	Tüketim sınırı	Standart sınır	Notlar
En fazla gecikme	Varsayılan: 1 gün	Varsayılan: 1 saat	Tüketim mantıksal uygulaması iş akışında varsayılan sınırı değiştirmek için yeniden deneme ilkesi parametresini kullanın. Standard mantık uygulaması iş akışındaki varsayılan sınırı değiştirmek için tek kiracılı Azure Logic Apps'te mantık uygulamaları için konak ve uygulama ayarlarını düzenleme bölümünü gözden geçirin.
En düşük gecikme	Varsayılan: 5 sn	Varsayılan: 5 sn	Tüketim mantıksal uygulaması iş akışında varsayılan sınırı değiştirmek için yeniden deneme ilkesi parametresini kullanın. Standard mantık uygulaması iş akışındaki varsayılan sınırı değiştirmek için Tek kiracılı Azure Logic Apps'te mantık uygulamaları için konak ve uygulama ayarlarını düzenleme bölümünü gözden geçirin.

Veri Akışı Adı

Tüketim sınırı

Standart sınır

Notlar

En fazla gecikme

Varsayılan: 1 gün

Varsayılan: 1 saat

Tüketim mantıksal uygulaması iş akışında varsayılan sınırı değiştirmek için yeniden deneme ilkesi parametresini kullanın.

Standard mantık uygulaması iş akışındaki varsayılan sınırı değiştirmek için tek kiracılı Azure Logic Apps'te mantık uygulamaları için konak ve uygulama ayarlarını düzenleme bölümünü gözden geçirin.

En düşük gecikme

Varsayılan: 5 sn

Tüketim mantıksal uygulaması iş akışında varsayılan sınırı değiştirmek için yeniden deneme ilkesi parametresini kullanın.

Standard mantık uygulaması iş akışındaki varsayılan sınırı değiştirmek için Tek kiracılı Azure Logic Apps'te mantık uygulamaları için konak ve uygulama ayarlarını düzenleme bölümünü gözden geçirin.

Rastgele değişken aralıkları

Üstel aralık yeniden deneme ilkesi için aşağıdaki tabloda, Azure Logic Apps'in her yeniden deneme için belirtilen aralıkta tekdüzen rastgele değişken oluşturmak için kullandığı genel algoritma gösterilmektedir. Belirtilen aralık, yeniden deneme sayısına kadar (bu sayı dahil) olabilir.

Yeniden deneme numarası	Minimum aralık	Maksimum aralık
1	max(0, <minimum-interval>)	min(aralık, <maksimum aralık>)
2	max(aralık, <minimum aralık>)	min(2 * aralık, <maksimum-aralık>)
3	max(2 * aralık, <minimum aralık>)	min(4 * aralık, <maksimum-aralık>)
4	max(4 * aralık, <minimum aralık>)	min(8 * aralık, <maksimum aralık>)
....	....	....

"Sonra çalıştır" davranışını yönetme

İş akışı tasarımcısına eylem eklediğinizde, bu eylemleri çalıştırma sırasını örtük olarak bildirirsiniz. Bir eylemin çalışması tamamlandıktan sonra, bu eylem Başarılı, Başarısız, Atlandı veya Zaman Aşımı gibi bir durumla işaretlenir. Başka bir deyişle, ardıl eylemin gerçekleşebilmesi için önce öncül eylemin izin verilen durumlardan herhangi biriyle tamamlanması gerekir.

Varsayılan olarak, tasarımcıya eklediğiniz bir eylem yalnızca önceki eylem Başarılı durumuyla tamamlanırsa çalışır. Bu sonra çalıştır davranışı, bir iş akışındaki eylemler için çalıştırma sırasını kesin olarak belirtir.

Tasarımcıda, eylemin Sonra çalıştır ayarını düzenleyerek bir eylemin varsayılan "sonra çalıştır" davranışını değiştirebilirsiniz. Bu ayar yalnızca iş akışındaki ilk eylemi izleyen sonraki eylemlerde kullanılabilir. bir iş akışındaki ilk eylem her zaman tetikleyici başarıyla çalıştırıldıktan sonra çalıştırılır. Bu nedenle, Sonra çalıştır ayarı kullanılamaz ve ilk eyleme uygulanmaz.

Eylemin temel alınan JSON tanımında, Sonra çalıştır ayarı özelliğiyle runAfter aynıdır. Bu özellik, ardıl eylemin çalıştırılabilmesi için önce izin verilen belirli durumlarla bitması gereken bir veya daha fazla öncül eylemi belirtir. runAfter özelliği, ardıl eylem çalışmadan önce bitilmesi gereken tüm öncül eylemleri belirtmenize olanak sağlayarak esneklik sağlayan bir JSON nesnesidir. Bu nesne ayrıca kabul edilebilir durumlardan oluşan bir dizi tanımlar.

Örneğin, bir eylemin A eylemi başarılı olduktan ve B eylemi başarılı olduktan veya bir eylemin JSON tanımı üzerinde çalışırken başarısız olduktan sonra çalıştırılmasını sağlamak için aşağıdaki runAfter özelliği ayarlayın:

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

Hata işleme için "Sonra çalıştır" davranışı

Bir eylem işlenmeyen bir hata veya özel durum oluşturursa, eylem Başarısız olarak işaretlenir ve ardıl eylem Atlandı olarak işaretlenir. Paralel dalları olan bir eylemde bu davranış gerçekleşirse, Azure Logic Apps altyapısı diğer dalları takip ederek tamamlanma durumlarını belirler. Örneğin, bir dal Atlandı eylemiyle sona ererse, bu dalın tamamlanma durumu bu atlanan eylemden önceki eylemin durumuna bağlıdır. İş akışı çalıştırması tamamlandıktan sonra motor, tüm dal durumlarını değerlendirerek çalıştırmanın genel durumunu belirler. Herhangi bir dal hatayla biterse, iş akışı çalıştırmasının tamamı Başarısız olarak işaretlenir.

Bir eylemin, önceki eylemin durumuna rağmen yine de çalışabilmesini sağlamak için, bir eylemin "run after" davranışını önceki eylemin başarısız durumlarını da işleyecek şekilde değiştirebilirsiniz. Bu şekilde, önceki adımın durumu Başarılı, Başarısız, Atlandı, Zaman Aşımına Uğradı olduğunda ya da bu durumların tümünde eylem çalıştırılır.

Örneğin, Excel Online Tablo öncül eylemine satır ekle eylemi Başarılı yerine Başarısız olarak işaretlendikten sonra Office 365 Outlook E-posta gönder eylemini çalıştırmak için tasarımcıyı veya kod görünümü düzenleyicisini kullanarak "sonra çalıştır" davranışını değiştirin.

Tasarımcıda "sonra çalıştır" davranışını değiştirme

Azure portalında mantıksal uygulama kaynağınızı açın.
Kaynak kenar çubuğunda, mantıksal uygulamanızı temel alan iş akışı tasarımcısını açmak için şu adımları izleyin:
- Tüketim: Geliştirme Araçları'nın altında iş akışınızı açmak için tasarımcıyı seçin.
- Standart
  1. Kaynak kenar çubuğundaki İş Akışları'nın altında İş Akışları'nı seçin.
  2. İş Akışları sayfasından iş akışınızı seçin.
  3. Araçlar'ın altında iş akışınızı açmak için tasarımcıyı seçin.
"Sonra çalıştır" davranışını değiştirmek istediğiniz tetikleyicide veya eylemde, işlemin ayarlarını açmak için şu adımları izleyin:
1. Tasarımcıda işlemi seçin.
2. İşlem bilgileri bölmesinde Ayarlar'ı seçin.
  
  Sonra çalıştır bölümü, seçili durumdaki işlem için kullanılabilir öncül işlemleri gösteren bir Seçim eylemleri listesi içerir, örneğin:
3. Eylemleri seç listesinin altında, bu örnekte HTTP olan geçerli öncül işlemi genişletin:
  
  Varsayılan olarak, "sonra çalıştır" durumu Başarılı olarak ayarlanır. Bu değer, geçerli eylemin çalışabilmesi için öncül işleminin başarıyla bitması gerektiği anlamına gelir.
"Sonra çalıştır" davranışını istediğiniz durumlara değiştirmek için bu durumları seçin.

Aşağıdaki örnekte Başarısız oldu seçeneğini belirleyin.
Geçerli işlemin yalnızca öncül eylemi Başarısız oldu, Atlandı veya Zaman aşımına uğradı durumu ile tamamlandığında çalıştırılacağını belirtmek için, bu durumları seçin ve varsayılan durumu temizleyin, örneğin:

Not

Varsayılan durumu temizlemeden önce başka bir durum seçtiğinizden emin olun. Her zaman en az bir durumun seçili olmasını sağlamalısınız.
Birden çok öncül işlemin çalıştırılmasını ve tamamlanıp bitmelerini gerektirmek için, her biri kendi "sonra çalıştır" durumlarına sahip aşağıdaki adımları izleyin:
1. Eylemleri seç listesini açın ve istediğiniz öncül işlemleri seçin.
2. Her işlem için "sonra çalıştır" durumlarını seçin.
bitirdiğinizde, işlem bilgileri bölmesini kapatın.

Kod görünümü düzenleyicisinde "sonra çalıştır" davranışını değiştirme

Kaynak kenar çubuğunda, mantıksal uygulamanızı temel alan kod görünümü düzenleyicisini açmak için şu adımları izleyin:
- Tüketim: Geliştirme Araçları'nın altında kod görünümünü seçerek iş akışınızı JSON düzenleyicisinde açın.
- Standart
  1. İş Akışları'nın altında İş Akışları'yı seçin.
  2. İş Akışları sayfasından iş akışınızı seçin.
  3. Araçlar'ın altında kod görünümünü seçerek iş akışınızı JSON düzenleyicisinde açın.

Eylemin JSON tanımında, aşağıdaki söz dizimine sahip runAfter özelliğini düzenleyin:

"<action-name>": {
   "inputs": {
      "<action-specific-inputs>"
   },
   "runAfter": {
      "<preceding-action>": [
         "Succeeded"
      ]
   },
   "type": "<action-type>"
}

Bu örnekte, runAfter özelliğini Succeeded değerinden Failed değerine değiştirin:

"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"
}

Eylemin, önceki eylem Failed, Skipped veya TimedOut olarak işaretlenmiş olsa da çalışacağını belirtmek için diğer durumları ekleyin:
```
"runAfter": {
   "Add_a_row_into_a_table": [
      "Failed", "Skipped", "TimedOut"
   ]
},
```

Kapsamlar ve sonuçlarıyla eylemleri değerlendirme

"Sonra çalıştır" ayarıyla tek tek eylemlerden sonraki adımları çalıştırmaya benzer şekilde, eylemleri bir kapsam içinde birlikte gruplandırabilirsiniz. Eylemleri mantıksal olarak gruplandırmak, kapsamın toplam durumunu değerlendirmek ve bu duruma göre eylemler gerçekleştirmek istediğinizde kapsamları kullanabilirsiniz. Kapsamdaki tüm eylemler çalışmasını tamamladıktan sonra kapsamın kendisi kendi durumunu alır.

Bir kapsamın durumunu denetlemek için, bir iş akışı çalıştırma durumunu denetlemek için kullandığınız ölçütlerin aynısını kullanabilirsiniz; örneğin Başarılı, Başarısız ve benzeri.

Varsayılan olarak, kapsamın tüm eylemleri başarılı olduğunda kapsamın durumu Başarılı olarak işaretlenir. Kapsamdaki son eylem Başarısız veya Durduruldu olarak işaretlenirse kapsamın durumu Başarısız olarak işaretlenir.

Başarısız kapsamındaki istisnaları yakalamak ve bu hataları işleyen eylemleri çalıştırmak için Başarısız kapsamı için "sonra çalıştır" ayarını kullanabilirsiniz. Bu şekilde, kapsamdaki herhangi bir eylem başarısız olursa ve bu kapsam için "sonra çalıştır" ayarını kullanırsanız, hataları yakalamak için tek bir eylem oluşturabilirsiniz.

Kapsamlarla ilgili sınırlar için bkz . Sınırlar ve yapılandırma.

Özel durum işleme için "run after" ile bir kapsam oluşturma

Azure portalında mantıksal uygulama kaynağınızı ve iş akışınızı tasarımcıda açın.

İş akışınızın zaten iş akışını başlatan bir tetikleyicisi olmalıdır.
Tasarımcıda, iş akışınıza Scope adlı bir Denetim eylemi eklemek için bu genel adımları izleyin.
Kapsam eyleminde, çalıştırılacak eylemleri eklemek için şu genel adımları izleyin, örneğin:

Aşağıdaki listede Kapsam eylemine dahil edebileceğiniz bazı örnek eylemler gösterilmektedir:
- API'den veri alma.
- Verileri işleme.
- Verileri bir veritabanına kaydedin.
Şimdi kapsam içindeki eylemleri çalıştırmak için "sonra çalıştırma" kurallarını tanımlayın.
1. Tasarımcıda Kapsam başlığını seçin. Kapsamın bilgi bölmesi açıldığında Ayarlar'ı seçin.
2. İş akışında birden fazla önceki eyleminiz varsa, Eylemleri seç listesinden, kapsamlı eylemleri çalıştırmak istediğiniz eylemi seçin.
3. Seçili eylem için, kapsamlı eylemleri çalıştırabilecek tüm eylem durumlarını seçin.
  
  Başka bir deyişle, seçilen eylemden kaynaklanan seçili durumların herhangi biri kapsamdaki eylemlerin çalışmasına neden olur.
  
  Aşağıdaki örnekte, HTTP eylemi seçilen durumlardan herhangi biriyle tamamlanmasının ardından kapsam içindeki eylemler çalıştırılır:

Hatalara ilişkin bağlam ve sonuçları alın

Bir kapsamdan hataları yakalamak yararlı olsa da, tam olarak başarısız eylemlerin yanı sıra hataları veya durum kodlarını öğrenmenize yardımcı olacak daha fazla bağlam da isteyebilirsiniz. result() işlevi, kapsamlı bir eylem içindeki üst düzey eylemlerin sonuçlarını döndürür. Bu işlev, kapsamın adını tek bir parametre olarak kabul eder ve bu üst düzey eylemlerden elde edilen sonuçları içeren bir dizi döndürür. Bu eylem nesneleri, eylemin başlangıç saati, bitiş saati, durumu, girişleri, bağıntı kimlikleri ve çıkışları gibi işlev tarafından actions() döndürülen özniteliklerle aynı özniteliklere sahiptir.

Not

result() işlevi sonuçları yalnızca üst düzey eylemlerden döndürür, anahtar veya koşul eylemleri gibi daha derin iç içe eylemlerden döndürmez.

Bir kapsamda başarısız olan eylemler hakkında bağlam elde etmek için, kapsamın adı ve "sonra çalıştır" ayarıyla birlikte @result() ifadesini kullanabilirsiniz. Döndürülen diziyi durumu Failed olan eylemlere göre filtrelemek için Diziyi Filtrele eylemini ekleyebilirsiniz. Döndürülen başarısız eylemler için bir eylem çalıştırmak üzere, döndürülen filtrelenmiş diziyi alın ve For each döngüsünü kullanın.

Aşağıdaki JSON örneği, My_Scope adlı kapsam eyleminde başarısız olan eylemler için yanıt gövdesine sahip bir HTTP POST isteği gönderir. Ayrıntılı bir açıklama örneği izler.

"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"
      ]
   }
}

Aşağıdaki adımlarda bu örnekte neler olduğu açıklanmaktadır:

My_Scope içindeki tüm eylemlerden sonuç almak için, Diziyi Filtrele eylemi şu filtre ifadesini kullanır:@result('My_Scope')
Filtre Dizisi için koşul, durumu Failed değerine eşit olan herhangi bir @result() öğedir. Bu koşul, My_Scope içindeki tüm eylem sonuçlarını içeren diziyi, yalnızca başarısız eylem sonuçlarını içeren bir diziye filtreler.
Filtrelenmiş dizi çıkışları üzerinde bir For_each döngü eylemi gerçekleştirin. Bu adım, daha önce filtrelenmiş olan her başarısız eylem sonucu için bir eylem gerçekleştirir.

Kapsamdaki tek bir eylem başarısız olursa, döngüdeki For_each eylemler yalnızca bir kez çalıştırılır. Birden çok başarısız eylem, her başarısızlık için bir eylemi tetikler.
For_each öğe yanıt gövdesine bir HTTP POST isteği gönderin; bu, @item()['outputs']['body'] ifadesidir.

Öğe @result() şekli, şekille @actions() aynıdır ve aynı şekilde ayrıştırılabilir.
Başarısız eylem adını (@item()['name']) ve başarısız çalıştırmanın istemci izleme kimliğini (@item()['clientTrackingId']) içeren iki özel üst bilgi ekleyin.

Referans olması için, önceki örnekte ayrıştırılan name, body ve clientTrackingId özelliklerini gösteren tek bir @result() öğesi örneği aşağıda verilmiştir. Eylemin For_each dışında, @result() bu nesnelerin bir dizisini döndürür.

{
   "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"
}

Farklı özel durum işleme desenleri gerçekleştirmek için, bu makalede daha önce açıklanan ifadeleri kullanabilirsiniz. Filtrelenmiş hata dizisinin tamamını kabul eden kapsamın dışında tek bir özel durum işleme eylemi yürütmeyi ve For_each eylemini kaldırmayı seçebilirsiniz. Daha önce açıklandığı gibi yanıttan \@result() diğer yararlı özellikleri de ekleyebilirsiniz.

Azure İzleyici günlüklerini ayarlama

Önceki desenler, bir çalıştırmada gerçekleşen hataları ve özel durumları işlemenin yararlı yollarıdır. Ancak, çalıştırmadan bağımsız olarak oluşan hataları da belirleyebilir ve yanıtlayabilirsiniz. Çalıştırma durumlarını değerlendirmek için çalıştırmalarınızın günlüklerini ve ölçümlerini izleyebilir veya bunları tercih ettiğiniz herhangi bir izleme aracında yayımlayabilirsiniz.

Örneğin Azure İzleyici, tüm çalıştırma ve eylem durumları dahil olmak üzere tüm iş akışı olaylarını bir hedefe göndermek için kolaylaştırılmış bir yol sağlar. Azure İzleyici'de belirli ölçümler ve eşikler için uyarılar ayarlayabilirsiniz. İş akışı olaylarını log analytics çalışma alanına veya Azure depolama hesabına da gönderebilirsiniz. İsterseniz Azure Event Hubs aracılığıyla tüm olayları Azure Stream Analytics'e aktarabilirsiniz. Stream Analytics'te, tanılama günlüklerindeki anomalileri, ortalamaları veya hataları temel alan canlı sorgular yazabilirsiniz. Stream Analytics'i kullanarak kuyruklar, konular, SQL, Azure Cosmos DB veya Power BI gibi diğer veri kaynaklarına bilgi gönderebilirsiniz.

Daha fazla bilgi için Azure Logic Apps için Azure İzleyici günlüklerini kurma ve tanılama verilerini toplama makalesini inceleyin.

Azure Logic Apps örnekleri ve senaryoları

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-07-10