Power Automate Desktop'ta Sağlam Seçiciler ve Bekleme Süreleri

Power Automate Desktop (PAD) ile oluşturulmuş bir UI otomasyonu, üretimde haftalarca çalıştıktan sonra aniden “Failed to get UI element” hatasıyla duruyorsa, bu neredeyse hiçbir zaman tesadüf değildir. Genellikle arka planda seçicinin artık bulamadığı bir şey değişmiştir: bir uygulama güncellemesi, farklı bir ekran çözünürlüğü, açılışta eskisinden bir saniye daha uzun süren bir pencere. Tam olarak bu iki noktada, sağlam seçiciler ve düzgün bekleme süreleri, bir akışın aylarca gözetimsiz modda kararlı çalışıp çalışmayacağını ya da birkaç günde bir elle onarılması gerekip gerekmeyeceğini belirler.

Bu rehber, PAD'de seçicilerin nasıl oluşturulduğunu, hangi operatörlerin ve değişkenlerin onları dinamik hale getirdiğini ve doğru Wait eylemleriyle sabit duraklamaların nasıl gerçek senkronizasyonla değiştirileceğini gösterir. Sonunda, mevcut akışları en sık görülen kesinti nedenlerine karşı hedefli şekilde güçlendirmenizi sağlayacak bir kontrol listesi bulacaksınız.

Seçiciler neden bozulur

Power Automate Desktop'taki bir seçici, bir UI öğesinin bir uygulama ya da web sayfası hiyerarşisinde tam olarak nerede bulunduğunu tanımlar. Microsoft'a göre seçiciler, PAD'in ad, sınıf veya otomasyon kimliği gibi özellikleri ve öğenin UI yapısındaki konumunu yakalamasıyla oluşur. Seçicileri değişikliklere karşı hassas kılan da tam olarak bu yakalama işlemidir. Microsoft, gözetimsiz masaüstü akışlarında sorun giderme kılavuzunda daha önce çalışan bir seçiciyi geçersiz kılabilecek şu faktörleri de sayar:

• Ekran çözünürlüğü ve DPI ölçeklendirmesi
• Uygulama güncellemeleri veya kullanıcı arayüzündeki değişiklikler
• İşletim sistemi sürümü
• Pencere boyutu veya modu, örneğin tam ekran ile pencere modu arasındaki fark
• Bir öğenin durumu, etkin veya devre dışı
• Kullanıcı izinleri, çünkü bir uygulama profile bağlı olarak farklı yüklenebilir

Bir seçicinin tipik olarak hangi noktalarda bozulduğunu bilen kişi, ilk arızadan sonra tepki vermek yerine seçiciyi baştan bu dalgalanmalara dayanacak şekilde oluşturabilir.

Bir seçicinin yapısı: düzeyler, öznitelikler, operatörler

Bir seçici, > karakteriyle birbirine bağlanan birden çok düzeyden oluşur. Her düzey, bir öğeyi element[Attribut1="Wert1"][Attribut2="Wert2"] biçiminde öznitelikleriyle tanımlar. özel seçici oluşturma belgelerindeki basit bir örnek bir düzenleyici penceresi gösterir: :desktop > window[Name="Notizen.txt - Editor"][Process="Notepad"]. İlk düzey her zaman kök öğe :desktop ile başlar, sonraki her düzey bir öncekinin alt öğesidir.

Sabit kodlanmış değerler yerine operatörler

Varsayılan operatör olan Eşittir tam, sabit kodlanmış bir değer arar. Bu, statik uygulamalarda güvenilir şekilde çalışır ama pencere başlıkları örneğin bir dosya adı veya başlıktaki bir zaman damgası nedeniyle dinamik olarak değiştiğinde hızla soruna dönüşür. Power Automate bunun için beş operatör daha sunar:

• Eşit değildir, belirli bir değer dışındaki her değeri kontrol eder
• İçerir, sabit bir kalıbı olmayan ama belirli bir anahtar kelime içeren öğeleri bulur
• İle başlar, bir değerin başlangıcını kontrol eder
• İle biter, bir değerin sonunu kontrol eder
• Normal ifade eşleşmesi, .NET regex motoruna dayalı, kendi tanımladığınız bir kalıba göre kontrol eder

“Notizen.txt - Editor (2)” gibi bir pencere başlığı, İle başlar ile Eşittir operatörüne göre çok daha sağlam biçimde yakalanabilir, çünkü sondaki parantez içindeki rakam seçiciyi bozmadan değişebilir.

Dinamik değerler için değişkenler

Bir öznitelik değeri önceki bir eyleme bağlıysa, örneğin yalnızca çalışma zamanında belli olan bir dosya adıysa, seçiciye yüzde gösteriminde bir değişken eklenebilir, örneğin :desktop > window[Name="%WindowName%"][Process="Notepad"]. Böylece beklenen değer çalıştırmadan çalıştırmaya değişse bile seçici geçerli kalır.

Birden çok seçici ve yedek kullanmak

Tek bir UI öğesinin PAD'de birden çok seçicisi olabilir. İlki başarısız olursa Power Automate, akışınızda ek bir programlama adımına gerek kalmadan tanımlanan sırada otomatik olarak bir sonrakine geçer. Yeniden yakalama ile seçim düğmesi ile ya da mevcut bir seçiciyi kopyalayarak, örneğin normal durum için Eşittir kullanan bir tane ve yedek düzey olarak İçerir veya Regex kullanan bir tane olmak üzere ek varyantlar oluşturulabilir.

Terminal oturumları veya temiz bir UI hiyerarşisi olmayan eski uygulamalar gibi özellikle kararsız arayüzler için Microsoft, aynı kılavuzda normal bir seçicinin artık işe yaramadığı durumlarda PAD'in UI özniteliklerine değil görüntü tanımaya dayandığı görüntü yedeğini de önerir.

Sabit duraklamalar yerine bekleme süreleri

Sabit bir saniye sayısıyla çalışan “Wait” eylemleri, akışların ya gereksiz yere yavaş çalışmasının ya da yine de bir öğeye çok erken erişmeye çalışmasının sık görülen bir nedenidir. Power Automate Desktop bunun için, bir zaman aralığının körü körüne geçmesini beklemek yerine uygulamanın gerçek durumunu bekleyen özel senkronizasyon eylemleri sunar.

• Pencereyi bekle, belirli bir pencere açılana, kapanana, odağı alana veya kaybedene kadar yürütmeyi duraklatır. Arama bir UI öğesi üzerinden, örnek veya tanıtıcı (handle) üzerinden ya da başlık ve sınıf üzerinden yapılabilir.
• Pencere içeriğini bekle, bir pencerede belirli bir metin veya UI öğesi görünene ya da kaybolana kadar, isteğe bağlı olarak öğenin etkin mi yoksa devre dışı mı olduğu kontrolünü de içerecek şekilde duraklatır. Bir UI öğesi yürütme sırasında henüz kullanılabilir değilse Microsoft'un UI otomasyon eylemleri referansında önerdiği eylem tam olarak budur.
• Görüntüyü bekle, ekranda veya ön plandaki pencerede bir görüntü görünene ya da kaybolana kadar bekler; ayarlanabilir tolerans ile basit ve gelişmiş görüntü eşleştirme arasında seçim içerir.

Üç eylem de sonsuza kadar beklemek yerine, tanımlanan bir süre geçtikten sonra zaman aşımı hatasıyla başarısız olacak şekilde yapılandırılabilir. Bu, gözetimsiz akışlar için önemlidir; böylece takılı kalan bir pencere tüm çalıştırmayı bloke etmek yerine kontrollü biçimde hata işlemeye geçer.

Seçicileri test etme ve onarma

Bir akış gözetimsiz çalışmaya geçmeden önce, her kritik seçiciyi doğrudan Selector Builder içinde test etmek işe yarar. Bir seçici yine de bozulursa, “Seçiciyi onar” özelliği hızlı bir ilk yardım sunar: öğeyi Ctrl+sol tıklama ile yeniden yakalarsınız, PAD eski yapıyı yenisiyle karşılaştırır ve kabul etmeden önce inceleyebileceğiniz onarılmış bir seçici önerir. Bir seçici değişken içeriyorsa Microsoft'a göre otomatik onarım çalışmaz, bu durumda yalnızca Selector Builder'ın metin düzenleyicisinde elle yapılan düzenleme kalır.

Gözetimsiz modda kararlı akışlar için kontrol listesi

Kalıcı olarak gözetimsiz çalışması gereken akışlar için Microsoft, uygulamada kanıtlanmış birkaç öneriyi bir araya getirir:

• Bir yedek devreye girebilsin diye her öğe için birden çok seçici kaydedin
• Statik özniteliklerle seçiciler oluşturun ve dinamik kısımları operatörler veya değişkenlerle yakalayın
• UI özniteliklerinin yeterince güvenilir olmadığı yerlerde görüntü yedeğini kullanın
• Her kritik eylemin hata işlemesinde bir yeniden deneme politikası tanımlayın
• Doğru eylem türünü seçin: web öğeleri için web otomasyonu, masaüstü öğeleri için UI otomasyonu
• Uygulamanın gözetimsiz modda, gözetimli testte olduğu gibi aynı pencere modunda başladığından emin olun
• Seçiciyi doğrudan gözetimsiz makinede yeniden yakalayıp test edin

Sağlam seçiciler ile gerçek bekleme koşullarının bu birleşimiyle bir akış çok daha nadiren boşa düşer. Süreç üzerindeki kontrolü elinde tutarsınız, çünkü her eylem, tahmini bir bekleme süresinden sonra şansa güvenerek başlamak yerine yalnızca uygulama gerçekten hazır olduğunda başlar. Power Automate Desktop'ı daha büyük ölçekte üretken şekilde kullananların bu kararlılık önlemlerini, ilk gece kesintilerinden sonra sonradan eklemek yerine, örneğin refakatli otomasyon projeleri kapsamında en baştan planlaması gerekir.

Sık sorulan sorular

Sabit bir saniye sayısına sahip basit bir “Wait” eylemi neden yeterli değildir?

Sabit bir bekleme süresi yalnızca bir uygulamanın ne kadar zamana ihtiyaç duyduğunu tahmin eder, ancak gerçek duruma tepki vermez. Uygulama daha hızlıysa akış gereksiz yere zaman kaybeder; örneğin ağ yükü veya yavaş bir sunucu nedeniyle daha yavaşsa, sonraki eylem henüz orada olmayan bir öğeye erişmeye çalışır. Pencere içeriğini bekle veya Pencereyi bekle gibi eylemler bunun yerine uygulamanın gerçek durumunu kontrol eder ve yalnızca koşul gerçekten sağlandığında devam eder.

“Pencereyi bekle” ile “Pencere içeriğini bekle” arasındaki fark nedir?

Pencereyi bekle, pencerenin bütün olarak açılıp açılmadığı, kapanıp kapanmadığı, odağı alıp almadığı ya da kaybedip kaybetmediğiyle ilgilenir. Pencere içeriğini bekle bir düzey daha derine iner ve zaten açık olan bir pencere içinde belirli bir metnin veya belirli bir UI öğesinin görünüp görünmediğini, kaybolup kaybolmadığını ya da etkin/devre dışı durumunu değiştirip değiştirmediğini kontrol eder. Pratikte genellikle ikisi birlikte kullanılır: önce pencereyi, ardından somut içeriği beklersiniz.

Bir UI öğesi başına kaç seçici oluşturmalıyım?

Sabit bir sayı yoktur, ancak Microsoft, ilki başarısız olduğunda bir yedeğin devreye girmesi için her öğe başına birden çok seçici kaydedilmesini açıkça önerir. Pratikte çoğu öğe için iki ile üç varyant yeterlidir; örneğin normal durum için Eşittir kullanan bir tane, yedek düzey olarak İçerir veya Regex kullanan bir tane ve özellikle kararsız arayüzler için ayrıca bir görüntü yedeği.

Değişken içeren bir seçici otomatik olarak onarılabilir mi?

Hayır. Microsoft belgelerine göre otomatik onarım işlevi, bir veya daha fazla değişken içeren seçicilerde çalışmaz. Bu durumda ya onarımı kullanmak için değişkenleri geçici olarak statik değerlerle değiştirmeniz ya da seçiciyi doğrudan Selector Builder'ın metin düzenleyicisinde elle ayarlamanız gerekir.

Onarım ve yedeğe rağmen bir seçici bozulmaya devam ederse ne yapmalıyım?

Birden çok yedek düzeyine sahip onarılmış bir seçici bile kararlı çalışmıyorsa, Microsoft'a göre genellikle görüntü yedeğine veya fare, klavye ve OCR eylemleriyle çalışan yüzey otomasyonuna geçmek yardımcı olur; özellikle sanal masaüstü ortamları gibi temiz bir UI hiyerarşisi olmayan uygulamalarda. Ayrıca temel nedene bakmakta fayda var: genellikle geliştirme ortamı ile gözetimsiz hedef makine arasındaki ekran çözünürlüğü, DPI ölçeklendirmesi veya pencere modu farkından kaynaklanır.