Power Automate: Çalıştırma Geçmişini Okuma ve Hataları Bulma

Bir akış beklendiği gibi çalışmaz, ancak bunun tam olarak nedeni ilk bakışta nadiren nettir. Power Automate her bir çalıştırmayı, başlangıç saati, süre, durum ve hata durumunda tam olarak hangi adımda takıldığı bilgisiyle birlikte çalıştırma geçmişine kaydeder. Bu bilgilerin nerede olduğunu ve nasıl okunacağını bilenler, nedeni genellikle uzun uzun denemek yerine birkaç dakika içinde bulur.

Bu makale, Power Automate'te çalıştırma geçmişini nerede açacağını, başarısız bir çalıştırmayı adım adım nasıl okuyacağını ve pratikte en sık karşılaşılan hata kodları ile ifade hatalarını gösterir. Böylece bir şeyler ters gitse bile akışların üzerindeki kontrolü elinde tutarsın.

Çalıştırma geçmişini nerede bulursun

Şu adresten oturum aç: make.powerautomate.com ve solda Akışlarım öğesini seç. İlgili akışın satırında akışı doğrudan açabilir veya üç noktalı menü üzerinden Ayrıntılar sayfasını açabilirsin. Orada, her çalıştırmayı başlangıç zamanı, süre ve durumla birlikte ayrı bir satır olarak listeleyen Çalıştırma geçmişi bölümünü bulursun (eski arayüzlerde 28 günlük çalıştırma geçmişi olarak da adlandırılır). Yeşil bir onay işareti başarıyı, kırmızı bir ünlem işareti ise bir hatayı gösterir.

Bilinmesi gereken önemli bir nokta: Power Automate, çalıştırma verilerini varsayılan olarak yalnızca 28 gün boyunca saklar. Akışın nadiren çalışıyorsa veya geçmişin daha uzun süre izlenebilir kalması gerekiyorsa, bu konudaki ayrıntılara bir göz atmakta fayda var, çünkü aksi takdirde eski çalıştırmalar artık bulunamaz hale gelir. Microsoft bu ayrıntıları, çalıştırma geçmişini Dataverse üzerinden daha uzun süre saklama seçeneği de dahil olmak üzere, şu makalede açıklar: Bir akış için eksik çalıştırma veya tetikleyici geçmişi.

Başarısız bir çalıştırmayı adım adım okumak

Ayrıntılı görünüme geçmek için listede başarısız çalıştırmanın başlangıç tarihine tıkla. Orada tüm akış bir eylemler zinciri olarak görünür ve en az bir adım kırmızı bir ünlem işaretiyle işaretlenmiştir. Asıl hata noktası burasıdır; öncesindeki tüm eylemler başarıyla tamamlanmıştır.

• İşaretlenen adımı genişletmek için üzerine tıkla.
• Sağ bölümde, Ayrıntılar altında bağlayıcının durum kodunu ve somut hata mesajını görürsün.
• Ayrıca önceki adımların Girişler ve Çıkışlar sekmelerini de kontrol et, çünkü asıl neden çoğu zaman başarısız olan adımın kendisinde değil, daha yukarıdan aktarılan yanlış veya boş bir değerdedir.
• Hata bir Scope bloğu içinde oluşursa, sonraki birkaç eylemin "atlandı" olarak işaretlenmiş olması mümkündür. Bu normaldir, çünkü başarısız olan bir Scope, içindeki tüm bağımlı eylemleri iptal eder.

Rastgele tıklamak yerine yapılandırılmış bir yaklaşımı tercih edenler için Microsoft bir tür karar ağacı yayımladı: Akış hiç kaydetmiyorsa, tetiklenmiyorsa, bir eylem başarısız oluyorsa veya sadece yanlış bir sonuç veriyorsa, Bulut akışı hatalarını giderme makalesi, somut kontrol adımlarıyla ilgili bölüme yönlendirir.

En önemli hata kodlarına genel bakış

Başarısız bir eylemdeki hataların çoğu, hata mesajını ayrıntılı olarak okumadan önce bile durum koduna göre kabaca sınıflandırılabilir.

| Kod | Anlamı | İlk kontrol |

| --- | --- | --- |

| 401 | Kimlik doğrulama başarısız | Bağlantıyı Bağlantılar altından yeniden kimlik doğrula |

| 403 | Erişim reddedildi | Hedef kaynak üzerindeki izinleri kontrol et, ardından DLP politikalarını yöneticiyle netleştir |

| 404 | Kaynak bulunamadı | SharePoint listesi, dosya, posta kutusu veya uç nokta yeniden adlandırılmış, taşınmış veya silinmiş |

| 429 | Çok fazla istek (hız sınırı) | Eyleme bir gecikme ekle veya eylem ayarlarında geri çekilmeli (backoff) yeniden deneme özelliğini etkinleştir |

| 500 / 502 | Hedef hizmette sunucu hatası | Genellikle geçicidir, çalıştırmayı Yeniden gönder ile tekrar dene |

400 aralığındaki kodlar neredeyse her zaman kendi yapılandırmanla ilgili bir soruna işaret ederken, 500 aralığındaki kodlar daha çok çağrılan hizmette geçici bir sorun olduğunu gösterir ve genellikle çalıştırmayı basitçe tekrarlayarak çözülebilir.

İfade hatalarını tanımak ve sınıflandırmak

Çalıştırma geçmişinde özellikle sık görülen iki hata mesajı vardır: "Invalid template" ya da "Unable to process template language expressions" ve "ExpressionEvaluationFailed". Her ikisi de bir ifadenin sözdizimsel olarak hatalı olduğu veya çalışma zamanında hiç var olmayan bir değere referans verdiği anlamına gelir. Bunun tipik nedenleri şunlardır:

• Bir koşulun karşılanmaması nedeniyle hiç çalıştırılmamış bir adımdan dinamik içeriğe yapılan bir referans.
• Yanlış bir veri türü, örneğin bir sayının beklendiği yerde bir metin dizesi.
• Güvenlik önlemi olmadan işlenmeye devam eden boş veya null bir değer. Bir `coalesce()` işlevi veya öncesinde bir `if(empty(...))` kontrolü bunu yakalar.

Geçmiş bunun yerine "ActionFailed. An action failed. No dependent actions succeeded." bildiriyorsa, gerçek tetikleyici genellikle üst düzey bir Scope bloğudur. Başarısız olarak işaretlenen sonraki eylemlerin her birini tek tek incelemek yerine, Scope içindeki ilk başarısız eylemi özellikle aramakta fayda var, çünkü asıl neden orada yatar.

Akış tamamlanıyor ama sonuç yanlışsa

Her hata kırmızı bir ünlem işareti olarak görünmez. Bazen akış tamamen yeşil olarak tamamlanır, ancak sonunda yanlış bir sonuç ortaya çıkar; örneğin gönderilmemiş bir onay e-postası veya yanlış doldurulmuş bir alan. Bu durumda klasik kırmızı hata arayışı işe yaramaz, bunun yerine her eylemi tek tek incelemen ve girişleri çıkışlarla karşılaştırman gerekir.

• Koşullarda gerçekte karşılaştırılan değerleri kontrol et. Yaygın tuzaklar arasında baştaki boşluklar, büyük/küçük harf farkı ("Onaylandı" ile "onaylandı") veya metin dizesi olarak gelen bir sayısal değer bulunur.
• Bir Her Değer İçin döngüsünde, döngünün üzerinden geçtiği girişe bakmakta fayda var. Dizi beklenenden daha fazla veya daha az öğe içeriyorsa, sorun genellikle önceki alma adımında zaten mevcuttur.
• Akış bir kaydı güncelleyip hemen ardından yeniden okuyorsa, güncel olmayan verilerin geri gelmemesi için yazma ile okuma arasında birkaç saniyelik kısa bir gecikme gerekebilir.
• Hedefe yönelik hata ayıklama için akışın önemli noktalarına eklenen Compose eylemleri yardımcı olur. Bunlar kontrol etmek istediğin değeri tam olarak verir ve gerçek akışı değiştirmeden çalıştırma geçmişinde sonradan görüntülenebilir.

Microsoft bu ve diğer senaryoları, kimlik doğrulama hatalarına ilişkin somut örnekler ve yeni tasarımcıda Copilot destekli sorun giderme dahil olmak üzere, şu makalede ayrıntılı olarak açıklar: Bulut akışında sorun giderme.

Topluluğa bakmak ne zaman mantıklıdır

Özellikle bağlayıcı ve veri kaynağının olağandışı kombinasyonlarında her hata mesajı net değildir. Bu gibi durumlarda, olası her nedeni kendin denemek yerine, tam hata metnini kopyalayıp powerusers.microsoft.com üzerindeki Power Automate topluluk forumlarında aramak genellikle daha hızlıdır. Çoğu zaman başka biri zaten tam olarak aynı hata mesajını paylaşmış ve işe yarayan bir çözüm bulmuştur.

Çalıştırma geçmişini düzenli olarak inceleyen biri, hangi hataların zararsız hangilerinin yapısal olduğuna dair hızla bir sezgi geliştirir. Deneyimli bir dış bakışa güvenmeyi tercih edenler veya bir akışın başından itibaren sağlam bir şekilde kurulmasını isteyenler, NordFlux'un Power Automate danışmanlığında saatlik ücret yerine sabit fiyatla tek bir muhatap bulur.

Sık sorulan sorular

Başarısız bir çalıştırma, çalıştırma geçmişinde ne kadar süre görünür kalır?

Varsayılan olarak 28 gün. Bundan sonra, akışın kendisi var olmaya devam etse bile çalıştırma normal çalıştırma geçmişinden kaybolur. Daha uzun süreli izlenebilirliğe ihtiyaç duyanlar, çalıştırma geçmişini Dataverse bağlantısı üzerinden saklayabilir veya hata ayrıntılarını silinmeden önce manuel olarak belgeleyebilir.

Asıl hatadan sonraki birkaç adım neden atlandı olarak işaretleniyor?

Bu genellikle hata bir Scope bloğu içinde oluştuğunda gerçekleşir. İçindeki bir eylem başarısız olursa, aynı bloktaki buna bağlı tüm sonraki eylemler otomatik olarak iptal edilir ve atlandı olarak gösterilir. Asıl neden neredeyse her zaman Scope içindeki ilk başarısız eylemdedir.

Çalıştırma geçmişinde 429 hata kodu ne anlama gelir?

429 kodu, çağrılan hizmetin çok kısa bir sürede çok fazla istek aldığını ve bu nedenle isteği reddettiğini gösterir. Genellikle çözüm, ilgili adımdan önce kısa bir gecikme eklemek veya eylem ayarlarında geri çekilmeli (backoff) yeniden deneme mantığını etkinleştirmektir.

Akış yeşil olarak tamamlanıyor ama görünür hiçbir şey olmuyor. Bunun nedeni nedir?

Bu durumda genellikle teknik bir hata değil, bir mantık sorunu söz konusudur; örneğin beklenenden farklı sonuç veren bir koşul veya boş bir diziyle karşılaşan bir döngü. Burada her eylemi geçmişte tek tek açmak ve gerçek girişleri ve çıkışları beklentilerle karşılaştırmak yardımcı olur.

Her başarısız çalıştırma için tüm akışı yeniden başlatmam gerekir mi?

Hayır. Başarısız bir çalıştırmanın ayrıntılı görünümünde Yeniden gönder seçeneği bulunur. Bu, bağlantıyı yeniden kimlik doğrulamak veya hatalı bir eylemi düzeltmek gibi altta yatan nedeni giderdiğinde, çalıştırmayı aynı giriş verileriyle tekrarlar.