Screen Scraping mi API mi: RPA ne zaman hâlâ gerçekten gerekli

Screen scraping'in kötü bir şöhreti vardır ve çoğu zaman haklı olarak. Bir yazılım robotu, verileri bir arayüz üzerinden almak yerine ekran maskeleri arasında tıklayarak ilerliyorsa, bu nadiren temiz bir çözümdür. Yine de KOBİ'lerde tam olarak bunun tek yol olduğu süreçler vardır. Belirleyici soru, yöntemin eski moda görünüp görünmediği değil, hedef sistemin kullanılabilir bir arayüze sahip olup olmadığıdır.

Screen scraping nedir ve API entegrasyonundan nasıl farklıdır?

Screen scraping, bir uygulamanın ekran arayüzü üzerinden otomatik olarak okunmasını ve kullanılmasını ifade eder: bir robot fare imlecini hareket ettirir, alanları doldurur ve değerleri ekrandan okur, tıpkı bir insanın yapacağı gibi. API entegrasyonu ise arayüzü atlar ve doğrudan sistemin veri arayüzüyle konuşur.

Microsoft, Power Automate belgelerinde bu farkı kısa bir formülle özetliyor: API ile uygulamaya ne yapması gerektiği söylenir, arayüz ile bu ona gösterilir (Süreç otomasyonu türleri, Microsoft Learn). Bunlardan yalnızca biri bir taahhüttür. Bir arayüz, üreticinin alanların ve formatların aynı kalacağına dair bir sözüdür. Bir ekran maskesi bu söz değildir.

API mi screen scraping mi: üreticilerin kendi önerileri

Öneri açık ve nettir, üstelik doğrudan RPA üreticilerinden gelir. Microsoft, kullanılabilir bir API bağlayıcısına sahip her uygulama için API tabanlı otomasyonun seçilmesini tavsiye eder, çünkü uygulama değişse bile arayüzlerin kararlı kalması beklenir.

Üreticinin verdiği bilgiye göre Power Automate, hazır API bağlayıcılarıyla 380'den fazla uygulamayı kapsıyor, buna kullanılabilir bir API'ye sahip her sistem için özel olarak oluşturulan bağlayıcılar da ekleniyor (Microsoft Learn). Arayüz üzerinden otomasyon bu nedenle API entegrasyonuna eşdeğer bir alternatif değil, belgelenmiş acil çıkıştır. Önce robota yönelen kişi, kimsenin talep etmediği bir bakım yükü satın almış olur.

Screen scraping bakımda neden daha pahalıya mal olur

Bunun bedeli bakım yüküdür ve bu iyi belgelenmiştir. Arayüz üzerinden yapılan otomasyonlar seçicilere, yani bir kontrol öğesinin nerede bulunduğunun ve nasıl adlandırıldığının teknik tanımına bağlıdır. Bu tanım değişirse robot öğeyi artık bulamaz ve çalıştırma başarısız olur.

Microsoft, gözetimsiz çalışan masaüstü akışları için bir seçiciyi kullanılamaz hale getirebilecek altı faktör sıralıyor: ekran çözünürlüğü ve DPI ölçeklendirmesi, uygulama güncellemeleri, işletim sistemi sürümü, pencere boyutu, bir öğenin durumu ve oturum açan kullanıcının izinleri (Gözetimsiz çalıştırma sorunlarını giderme, Microsoft Learn). Bu noktaların hiçbiri iş süreciyle ilgili değildir. Süreç değişmeden doğru kalır, otomasyon paketlemeye takılır.

UiPath aynı sorunu diğer yönden anlatıyor: Klasik seçiciler katı özniteliklere ve hiyerarşilere dayanır, bu yüzden değişen bir etiket, dinamik bir öğe kimliği veya yeni bir tema bile otomasyonu durdurur. Üretici, bundan kaynaklanan bakım yükünü kendisi yüksek olarak değerlendiriyor (Anlamsal Seçiciler Hakkında, UiPath Docs). Bir API entegrasyonunda bu sorunların hiçbiri yoktur. Bir arayüz ekran çözünürlüğüyle ilgilenmez.

Screen scraping gerçekten ne zaman doğru seçimdir?

Screen scraping, bir sistemin kullanılabilir bir arayüzü olmadığında ve yalnızca ekranı üzerinden çalıştırılabildiğinde doğru araçtır. Microsoft, lisans belgelerinde bu koşulu net bir şekilde tanımlar: RPA, ne hazır bir bağlayıcının ne de kendi bağlayıcısının oluşturulabileceği bir API'nin bulunmadığı uygulamalar için gereklidir.

Pratikte bu beş duruma karşılık gelir:

• API'siz eski özel yazılımlar: hiçbir zaman entegrasyon için tasarlanmamış, zamanla büyümüş sektör yazılımları.
• Terminal ve Citrix uygulamaları: yalnızca bir ekran görüntüsü geliyorsa, teknik olarak maskeden başka tutunacak bir şey yoktur.
• Arayüz kilitli: bazı üreticiler API modülünü ayrı olarak lisanslar veya küçük müşterilere hiç sunmaz. Bu durumda soru teknik değil, ticari hale gelir.
• API süreci kapsamıyor: yalnızca okuyan bir arayüz, gerekli yazma işleminde yardımcı olmaz.
• Bir değişiklikten önceki geçiş dönemi: sistem bir veya iki yıl içinde değiştirilecekse, temiz bir entegrasyon çoğu zaman artık karşılığını vermez. Bilinçli olarak tek kullanımlık bir çözüm olarak inşa edilen bir robot, o zaman daha dürüst bir yatırım olur.

Son nokta düzenli olarak gözden kaçırılır: yaklaşım meşru bir köprü teknolojisidir. Sorun ancak köprü kalıcı bir duruma dönüştüğünde ve artık kimse neden orada durduğunu bilmediğinde ortaya çıkar. Araç sorusunu kendisi n8n ve Power Automate'in pratik karşılaştırması içinde ele aldık.

O zaman API varyantında ortadan kalkan lisans maliyetleri de hesaba katılmalıdır. Power Automate'te, masaüstü akışlarını gözetimsiz çalıştıran her makine bir Process lisansına, Microsoft 365 için ayrıca bir Unattended lisansına ihtiyaç duyar (Microsoft Learn). Lisanslama açısından robot yalnızca bir kullanıcı daha demektir. UiPath lisans bileşenlerini KOBİ'ler için UiPath lisansları başlıklı yazımızda ayrıntılı olarak ele aldık.

Gerçekten hiçbir arayüzün olmadığı nasıl kontrol edilir?

Her RPA kararından önce, genellikle yarım saat süren ve robotu düzenli olarak gereksiz kılan bir kontrol yapılmalıdır. Çoğu zaman bir arayüz vardır, sadece adı farklıdır. Dört soru bunu netleştirir:

• Üretici belgeleri ne diyor? API modülleri genellikle teklife girmeden çok önce teknik belgelerde ortaya çıkar.
• Bir veri dışa aktarma seçeneği var mı? en sıradan arayüz, planlanmış bir CSV veya XML dışa aktarımıdır. Kararlıdır, belgelenmiştir ve hiçbir maliyeti yoktur.
• Salt okunur bir veritabanı erişimi mümkün mü? raporlama amaçları için çoğu zaman tamamen yeterlidir.
• Arayüz modülü ne kadara mal olur? tek seferlik olarak genellikle üç yıllık robot bakımından daha ucuzdur.

Karar yine de robottan yana verilirse, gerekçenin yazılı olarak belgelenmesi gerekir. Bir belediye yönetimi için tam olarak bu değerlendirmeyi Temmuz 2026'da sunduk ve RPA'yı otomasyon stratejisinin temeli haline getirmemesini tavsiye ettik: noktasal bir ek olarak evet, temel olarak hayır. Araç kötü değildi, sadece göreve uymuyordu. Bu değerlendirme, bir arayüz ve entegrasyon danışmanlığı hizmetinin asıl içeriğidir.

Sıkça Sorulan Sorular

Screen scraping ile web scraping arasındaki fark nedir?

Web scraping, genellikle HTML kaynak kodu üzerinden web sayfalarındaki içerikleri okur ve bunun için görünür bir arayüze ihtiyaç duymaz. Screen scraping, uygulamayı bir insanın gördüğü şekilde çalıştırır ve masaüstü programlarını, terminal ile Citrix oturumlarını da kapsar.

Screen scraping'e izin veriliyor mu?

Teknik olarak evet, sözleşme açısından duruma bağlıdır. Bazı yazılım üreticileri kullanım koşullarında otomatik kullanımı hariç tutar veya ek lisanslara bağlar. Bir robot oluşturmadan önce hedef sistemin lisans koşulları kontrol edilmeli, şüphe durumunda hukuki görüş alınmalıdır.

Screen scraping gerçekten her güncellemede bozuluyor mu?

Hayır, ama risk programlanarak ortadan kaldırılamaz. Yalnızca iş mantığını değiştiren bir güncelleme robotu etkilemez. Etiketler, pencere düzeni veya öğe kimlikleri kaydığı anda seçiciler boşa düşer. RPA kullananlar bu nedenle bakımı bir arıza durumu olarak değil, sabit bir plan öğesi olarak ele almalıdır.

Yapay zeka (YZ) destekli seçiciler sorunu çözer mi?

Sorunu hafifletirler, ortadan kaldırmazlar. UiPath gibi üreticiler, bir öğeyi konumuna göre değil anlamına göre tanıyan seçiciler üzerinde çalışıyor. Bu, bakım yükünü azaltır ama otomasyonun, hiç kimsenin sözleşmeyle kararlı tutmadığı bir arayüze bağlı olduğu gerçeğini değiştirmez.