Azure Logic Apps'teki hataları ve özel durumları işleme

Ş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, http eylemi gibi bir tetikleyicide veya eylemde desteklendiğinde 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 İlke sınırlarını yeniden dene'yi 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.

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

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

2. Tüketim veya Standart iş akışı üzerinde çalışıp çalışmadığınıza bağlı olarak tetikleyicinin veya eylemin Ayarlar'ını açın.

   • Tüketim: Eylem şekli üzerinde üç nokta menüsünü (...) açın ve Ayarlar'ı seçin.

   • Standart: Tasarımcıda eylemi seçin. Ayrıntılar bölmesinde Ayarlar'ı seçin.

3. Tetikleyici veya eylem yeniden deneme ilkelerini destekliyorsa, İlkeyi Yeniden Dene'nin 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

1. Gerekirse, tasarımcıdaki önceki adımları tamamlayarak tetikleyicinin veya eylemin yeniden deneme ilkelerini destekleyip desteklemediğini onaylayın.

2. Mantıksal uygulama iş akışınızı kod görünümü düzenleyicisinde açın.

3. Tetikleyici veya eylem tanımında JSON nesnesini bu tetikleyiciye veya eylemin inputs nesnesine ekleyinretryPolicy. Aksi takdirde, nesne yoksa retryPolicy tetikleyici veya eylem yeniden deneme ilkesini kullanır default .

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

   Required

   Özellik	Değer	Type	Açıklama
   type	<retry-policy-type>	String	Kullanılacak yeniden deneme ilkesi türü: default, none, fixedveya exponential
   count	<yeniden deneme denemeleri>	Tamsayı	ve exponential ilke türleri içinfixed, yeniden deneme denemelerinin sayısıdır ve bu değer 1 - 90 arasında bir değerdir. Daha fazla bilgi için Sabit Aralık ve Üstel Aralık'ı gözden geçirin.
   interval	<yeniden deneme aralığı>	String	ve exponential ilke türleri içinfixed, ISO 8601 biçiminde yeniden deneme aralığı değeri. İ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).

   Optional

   Özellik	Değer	Type	Açıklama
   maximumInterval	<maksimum aralık>	String	İlke içinexponential, ISO 8601 biçiminde 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'ı gözden geçirin.
   minimumInterval	<minimum aralık>	String	İlke içinexponential, ISO 8601 biçiminde 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'ı gözden geçirin.

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 saniye ölçeklendirilir ancak 5 ile 45 saniye arasında eşlenir. Ç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 denemediğini belirtmek için retry-policy-type> değerini olarak noneayarlayın<.

Sabit aralıklı yeniden deneme ilkesi

Eylemin veya tetikleyicinin bir sonraki isteği göndermeden önce belirtilen aralığı bekleyeceğini belirtmek için retry-policy-type> değerini olarak fixedayarlayı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ık 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.

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 en fazla ve yeniden deneme sayısı dahil olabilir.

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

İş akışı tasarımcısına eylem eklediğinizde, bu eylemleri çalıştırmak için kullanılacak sırayı ö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. Varsayılan olarak, tasarımcıya eklediğiniz bir eylem yalnızca öncül Başarılı durumuyla tamamlandıktan sonra çalışır. Bir eylemin temel tanımında runAfter özelliği, ardıl eylemin çalıştırılabilmesi için önce bitirmesi gereken öncül eylemin ve bu öncül için izin verilen durumların belirtildiğini belirtir.

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 Atlanan eylemle biterse, bu dalın tamamlanma durumu atlanan eylemin öncül durumuna bağlıdır. İş akışı çalıştırması tamamlandıktan sonra altyapı, tüm dal durumlarını değerlendirerek çalıştırmanın durumunun tamamını belirler. Herhangi bir dal hatayla biterse, iş akışı çalıştırmasının tamamı Başarısız olarak işaretlenir.

Bir eylemin öncül durumuna rağmen hala çalışabileceğinden emin olmak için, bir eylemin "sonra çalıştır" davranışını öncül'ün başarısız durumlarını işleyecek şekilde değiştirebilirsiniz. Bu şekilde eylem, öncül durumunun Başarılı, Başarısız, Atlandı, Zaman Aşımı veya tüm bu durumlar olduğunda ç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

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

1. Azure portalında mantıksal uygulama iş akışınızı kod görünümü düzenleyicisinde açın.

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

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

3. Bu örnek için özelliğini olarak runAfter Succeeded Faileddeğ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"
   }
   

4. Eylemin öncül eylemin olarak FailedSkipped TimedOutişaretlenip işaretlenmediğini 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, başarılı, başarısız gibi bir iş akışı çalıştırma durumunu denetlemek için kullandığınız ölçütlerin aynısını kullanabilirsiniz.

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 özel durumları yakalamak ve bu hataları işleyen eylemleri çalıştırmak için Başarısız kapsamı olan "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.

Hatalar için bağlam ve sonuçlar alma

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. İşlev, result() kapsamlı bir eylemdeki en üst düzey eylemlerden sonuçları 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.

Bir kapsamda başarısız olan eylemler hakkında bağlam almak için, kapsamın @result() adı ve "sonra çalıştır" ayarıyla ifadeyi kullanabilirsiniz. Döndürülen diziyi Başarısız durumundaki eylemlere göre filtrelemek için Diziyi Filtrele eylemini ekleyebilirsiniz. Döndürülen başarısız bir eylem için bir eylem çalıştırmak için, döndürülen filtrelenmiş diziyi alın ve her döngü için bir 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:

1. My_Scope içindeki tüm eylemlerden sonuç almak için, Diziyi Filtrele eylemi şu filtre ifadesini kullanır:@result('My_Scope')

2. Filtre Dizisi koşulu, durumuna eşit Failedolan herhangi @result() bir öğedir. Bu koşul, yalnızca başarısız olan eylem sonuçlarıyla My_Scope diziden bir diziye kadar tüm eylem sonuçlarını içeren diziyi filtreler.

3. Filtrelenmiş dizi çıkışlarında döngü For_each 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 hata başına bir eyleme neden olur.

4. Öğe yanıt gövdesinde For_each bir HTTP POST gönderin; bu ifadedir @item()['outputs']['body'] .

   Öğe @result() şekli, şekille @actions() aynıdır ve aynı şekilde ayrıştırılabilir.

5. Başarısız eylem adına () ve başarısız çalıştırma istemci izleme kimliğine (@item()['name']@item()['clientTrackingId'] ) sahip iki özel üst bilgi ekleyin.

Başvuru için, önceki örnekte ayrıştırılan , bodyve clientTrackingId özelliklerini gösteren nametek @result() bir öğe ö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 eylemi kaldırmayı For_each 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 Bkz . Azure İzleyici günlüklerini ayarlama ve Azure Logic Apps için tanılama verileri toplama.

Sonraki adımlar

• Azure Logic Apps örnekleri ve senaryoları hakkında daha fazla bilgi edinin