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.
| 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 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. 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 iş akışınızı tasarımcıda açın.
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.
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
Gerekirse, tasarımcıdaki ö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 bu tetikleyiciye veya eylemin
inputsnesnesine ekleyinretryPolicy. Aksi takdirde, nesne yoksaretryPolicytetikleyici veya eylem yeniden deneme ilkesini kullanırdefault."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,fixedveyaexponentialcount<yeniden deneme denemeleri> Tamsayı ve exponentialilke 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 exponentialilke türleri içinfixed, ISO 8601 biçiminde yeniden deneme aralığı değeri. İlke içinexponentialisteğ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çin exponential, 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çin exponential, 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.
| 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. Standart mantıksal uygulama iş akışında varsayılan sınırı değiştirmek için Tek kiracılı Azure Logic Apps'te mantıksal uygulamalar için konak ve uygulama ayarlarını düzenleme'yi 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. Standart mantıksal uygulama iş akışında varsayılan sınırı değiştirmek için Tek kiracılı Azure Logic Apps'te mantıksal uygulamalar için konak ve uygulama ayarlarını düzenleme'yi 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 en fazla ve yeniden deneme sayısı dahil olabilir.
| Yeniden deneme numarası | Minimum aralık | Maksimum aralık |
|---|---|---|
| 1 | max(0, <minimum aralık>) | 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ı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.
Not
Tasarımcıda, ilk eylemin çalıştırılabilmesi için tetikleyicinin başarıyla çalışması gerektiğinden, "sonra çalıştır" ayarı tetikleyiciyi hemen izleyen eyleme uygulanmaz.
Tasarımcıda "sonra çalıştır" davranışını değiştirme
Azure portalında mantıksal uygulama iş akışını tasarımcıda açın.
Tasarımcıda eylem şeklini seçin. Ayrıntılar bölmesinde, Sonra Çalıştır'ı seçin.
Sonra Çalıştır bölmesi, seçili durumdaki eylemin öncül eylemini gösterir.
Tüm "sonra çalıştır" durumlarını görüntülemek için öncül eylem düğümünü genişletin.
Varsayılan olarak, "sonra çalıştır" durumu başarılı olarak ayarlanır. Bu nedenle, seçili durumdaki eylemin çalıştırılabilmesi için öncül eylemin başarıyla çalıştırılması gerekir.
"Sonra çalıştır" davranışını istediğiniz durumla değiştirin. Varsayılan seçeneği temizlemeden önce bir seçenek belirlediğinizden emin olun. Her zaman en az bir seçeneğin seçili olması gerekir.
Aşağıdaki örnek başarısız oldu öğesini seçer.
Öncül eylemin Başarısız, Atlandı veya Zaman Aşımı olarak işaretlenip işaretlenmediğini geçerli eylemin çalıştırılacağını belirtmek için diğer durumları seçin.
Her biri kendi "sonra çalıştır" durumlarına sahip birden fazla öncül eylemin çalıştırılmasını zorunlu kılacak şekilde Eylemleri seç listesini genişletin. İstediğiniz öncül eylemleri seçin ve gerekli "sonra çalıştır" durumlarını belirtin.
Hazır olduğunuzda Bitti'yi seçin.
Kod görünümü düzenleyicisinde "sonra çalıştır" davranışını değiştirme
Azure portalında mantıksal uygulama iş akışınızı kod görünümü düzenleyicisinde açın.
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>" }Bu örnek için özelliğini olarak
runAfterSucceededFaileddeğ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 öncül eylemin olarak
FailedSkippedTimedOutiş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.
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 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:
My_Scope içindeki tüm eylemlerden sonuç almak için, Diziyi Filtrele eylemi şu filtre ifadesini kullanır:
@result('My_Scope')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.Filtrelenmiş dizi çıkışlarında döngü
For_eacheylemi 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_eacheylemler yalnızca bir kez çalıştırılır. Birden çok başarısız eylem hata başına bir eyleme neden olur.Öğe yanıt gövdesinde
For_eachbir HTTP POST gönderin; bu ifadedir@item()['outputs']['body'].Öğe
@result()şekli, şekille@actions()aynıdır ve aynı şekilde ayrıştırılabilir.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.