Orchestrator’da bazı trigger’ların zamanla kendi kendine devre dışı kaldığına rastladım. Bu durum genellikle, sürecin bir trigger’ının uzun süre boyunca başarıyla tamamlanamamasından kaynaklanmaktadır. Ancak bazı trigger’lar, tetiklenmelerine rağmen Pending kuyruğuna bile alınamıyor.
Peki Neden?
Aynı süreci çalıştıran birden fazla trigger varsa ve robot kapasitesi yetersizse, ilk trigger job’u oluşturur ve Pending durumuna düşer. Ancak aynı süreç için sistem yalnızca bir adet Pending job’a izin verir.
Bu nedenle ikinci trigger tetiklense bile job oluşturulamaz, sistem onu Pending kuyruğuna bile almaz.
Bu durum günlerce tekrar ederse, Orchestrator trigger’ı otomatik olarak devre dışı bırakır.
Audit Log’da Ne Görünür?
Orchestrator bu devre dışı bırakmayı açıkça loglar:
Component: Triggers
Action: Deactivate
Operation: User System Administrator deactivated trigger …
Bu, aslında Orchestrator’un kendi kendini koruma mekanizmasıdır.
Bu Bir Bug Değil, Bilinçli Bir Davranış
Orchestrator’daki bu davranış bir hata değil, bilerek tasarlanmış bir koruma önlemidir:
✅ Aynı process’e ait iki job aynı anda pending’e düşemediği için, yeni job’lar pending’e alınamaz ve çalışamaz.
✅ Bu durumda sürekli tetiklenen ama pending’e düşemeyen veya hiç çalışamayan trigger’lar sistemi tıkar.
✅ Sistemin kaynaklarını boşa harcamamak ve stabiliteyi korumak için bu trigger’lar otomatik olarak devre dışı bırakılır.
✅ Böylece sistemin genel stabilitesi korunur, diğer işler aksamadan devam eder.
Örnek Vaka
Bir sürece ait iki farklı trigger var. Biri job’u oluşturup Pending’e düşüyordu, diğeri ise aynı sürece ait olduğu için Pending’e bile alınamıyordu.
Bu durum günlerce tekrar etti. Hiçbir başarılı job oluşmadı. Orchestrator, ikinci trigger’ı otomatik olarak devre dışı bıraktı.
Bu Davranışa Karşı Ne Yapabilirsin?
Trigger’ların Orchestrator tarafından otomatik olarak devre dışı bırakılması yapılandırılamaz. Ancak bu davranışın neden oluştuğunu anlayarak ve süreci iyi planlayarak önleyebilirsin. İşte dikkat etmen gerekenler:
-
Robot/machine kapasitesi yeterli mi?
Mevcut robotlar yetersizse, job’lar sıraya bile giremez. Robot lisanslarını ve kullanılabilirliğini gözden geçirebilirsin. -
Aynı süreci birden fazla trigger tetikliyor mu?
Çakışan trigger’lar aynı sürece iş göndermeye çalıştığında, sistem yalnızca birine izin verir. Bu da diğerinin sürekli başarısız olmasına neden olur. Trigger planlamasını düzenleyebilirsin. -
Trigger saatleri çakışıyor mu, job süreleri uzun mu?
Özellikle job uzun sürüyorsa ve tetikleme aralıkları darsa, yeni job’lar kuyruğa bile alınamaz. Trigger saatlerini düzenleyebilirsin. -
Stop After süresi mantıklı mı ayarlanmış?
Uzun süre Pending’de kalan job’lar sistemi kilitler. Stop After süresini kısa tutarak sistemi daha çevik hâle getirebilirsin. -
Devre dışı kalan trigger’lar takip ediliyor mu?
Audit log’ları düzenli olarak kontrol et. Trigger’ın neden devre dışı kaldığını zamanında fark etmek müdahale şansı sağlar.
Sonuç:
Trigger’ların kendiliğinden kapanması bir hata değil; sistemin aşırı yüklenmesini önlemek için devreye giren otomatik bir koruma mekanizması. Ama sen iyi planlarsan, trigger’lar da sessizce görevine devam eder.
