İlk basit otomasyon sürecimizi oluşturduk ve Orchestrator ile Runbook oluşturma işlemlerinde hemen hemen bütün temel konulara değindik. Sırada daha ayrıntılı, kompleks ve birden fazla Runbooktan oluşan süreçler oluşturmak gibi konular geliyor. Tabi süreçlere girişmeden hemen önce bu aşamalarda kullanabileceğimiz bazı özel aktiviteleri yada metotları öğrenmekte fayda var. Sonrasında edindiğiniz bilgiyle zaten gerisi kendiliğinden gelmeye başlayacaktır.

 

İleri Seviye Süreç Kavramları Derken?

 

Aslında güzel bir soru. İlk makalemizde olduğu gibi aktivite objelerini sırayla ekleyerek düz bir çizgide ilerleyen süreçler oluşturup işlerin büyük bir kısmını yapabiliriz. Fakat süreçlerimize göre akışları aynı anda birkaç dala ayırmak veya duruma göre tamamen farklı başka süreçlerin tetiklenmesini sağlamak isteyebiliriz. Süreçleri aynı anda birden fazla instance olarak çalıştırmak veya zamanlayarak otomatik başlayan süreçler oluşturmak da isteyebiliriz. Durum böyle olunca bazı runbook aktiviteleri ve kavramlar karşımıza çıkıyor. Daha uzatmadan başlıklar altında ve örneklerle bunları incelemeye başlayalım.

 

Invoke Runbook ve Süreçlerin Tetiklenmesi

 

 

 

Birden fazla Runbook'a ayrılmış kapsamlı süreçler oluşturmak ve bir Runbook içerisinden başka bir Runbook'u tetiklemek sık kullanılan yöntemlerdendir. Bütün iş akışını tek bir Runbook içerisinde kısıtlamak istemediğimizde diğer süreçlerle aradaki bağı sağlayan Invoke Runbook aktivitesi Runbook Control grubundaki standart objeler arasında yerini alır. Temel olarak amacı bir Runbook içerisinden başka bir Runbook'un tetiklenmesini veya çağrılmasını sağlamaktadır.

 

 

 

 

Ayarları oldukça basittir. Runbook kısmından çağrılacak süreç seçilebilir. İki adet ek seçeneği vardır: "Invoke by path" seçildiğinde süreç hem isme hemde konuma göre tetiklenir, tabi bu sebepten dolayı konumda bir değişiklik olduğunda çalışmayacaktır. Eğer seçilmezse, Runbook'un yeri değiştirilse bile doğru şekilde tetiklenecektir. Genelde bu özelliği seçmemek daha pratik olmakta.

 

Diğer bir seçenek ise "Wait for Completion" yani tetiklenen Runbook'un tamamlanmasını beklemek. Eğer çağıran Runbook'un, çağrılan Runbook tamamlanmadan devam etmesini istemiyorsak bu özellikten yararlanabiliriz. Arka arkaya sırayla ilerleyen Runbooklar için tercih edilmeyecek olsa da bir süreç ortasında çağrılarak kullanıldığında amaca uygun olduğunu söyleyebiliriz. Bu özelliğin ayrıntılarına yazının bir sonraki kısmında değineceğiz.

 

Son olarak eğer çağrılan Runbook belirli parametreler istiyorsa aktarılacak bilgileri de burada belirleyebiliyoruz. Şimdilik bu konunun ayrıntılarını da Initialize Data kısmına bırakalım.

 

Basit bir örnekle Invoke Runbook aktivitesini göstereyim. Varsayalım önceden belirlediğimiz bir sunucuda bazı process'leri sonlandırmayı ve bir windows servisini restart etmeyi içeren bir sürecimiz olsun. İsteğimiz doğrultusunda bu süreci 2 Runbook ile oluşturabiliriz. Bu Runbook'lardan ilk olanı process sonlandırma yaparken ikincisi servisin restart edilmesinden sorumlu olsun.

 

 

 

 

Bu Runbook'lara ayrılmış sürecin devamlılığını sağlamak içinse Invoke Runbook aktivitesi kullanılmalıdır. Görebildiğiniz gibi ilk Runbook, tamamlandığı son objede 2 numaralı Runbook'u tetikleyerek akış sürdürebilmektedir.

 

 

 

 

Sonuç olarak Invoke Runbook ile aynı süreci destekleyen Runbooklar birbiri ardına tetiklenebilmekte yada akış içerisinde çağrılabilmektedir.

 

Süreçleri Başlatırken Initialize Data ile Parametre Gönderilmesi

 

 

Runbook'ları çalıştırırken veri gönderilmesini sağlayan Initialize Data standart aktivitesi süreçlerde bir başlangıç noktası oluşturmak için kullanılır. Runbook Control objeleri arasında bulunan aktivite, Runbook çalışmadan önce gereken parametrelerin aktarılmasına olanak tanır. Bu parametreler başka bir süreçten çıktı olarak yada Orchestration web konsolundan el ile girilerek aktarılıyor olabilir.

 

Örneğin dosya işlemleri içeren yedekleme amaçlı bir Runbook yaptınız ve bu yedeklenecek klasör bilgisinin süreç başlamadan önce değişken olarak aktarılmasını istiyorsunuz.

 

 

 

 

Bunun için sürecinizin başına bir Initialize Data aktivitesi eklemeli ve details kısmında klasör adını belirten bir string parametre oluşturmalısınız.

 

 

 

 

Böylece klasör bilgisini içeren bir girdi databus üzerinden ileriye aktarılabilecek ve dosya sıkıştırma işlevi gören bir objeyi besleyebilecektir. Sonuç olarak her seferinde farklı klasörlerle çalışabilen Runbook daha dinamik bir hale gelecektir. Aşağıdaki Orchestration web konsolu ekran görüntüsünde ilgili Runbook başlatılmak istendiğinde gelen parametre giriş bölümünü görebilirsiniz.

 

 

 

 

Initialize data aktivitesini iki şekilde kullanabileceğimizden bahsetmiştik. Bunlardan bir diğer ise Invoke Runbook aktivitesi ile olmaktadır. Birbiri ardına yada akış içerisinden Runbook çağrılabildiğini konuşurken de fark ettiğiniz gibi Invoke Runbook aktivitesi içerisinde parametreler alabilmektedir. (Çağrılan Runbook Initialize Data ile başlamıyorsa Invoke Runbook'da herhangi bir parametre görünmeyecektir.)

 

 

 

 

Bu parametrelerse aslında tetiklenmek için seçilen Runbook'un başlangıcındaki Initialize Data objesinden aktarılmaktadır.

 

 

.

 

 

Yukarıdaki örnek süreci inceleyelim. İlk Runbook ile Insan Kaynakları uygulaması veritabanı sorgulanarak yeni işe başlayan bir çalışanın Ad, Soyad ve Departman gibi bilgileri alınıyor. Hemen sonrasında Active Directory üzerinde kullanıcı oluşturan süreç Invoke Runbook ile tetikleniyor. İkinci Runbook bir Initialize Data objesiyle başladığı için AD kullanıcı hesabı yaratılırken gereken bilgiler ilk süreçten aktarılabiliyor.

 

Gördüğünüz gibi Initialize Data ve Invoke Runbook çoğu zaman birbirini tamamlayan, otomasyon süreçlerimizde çok sık kullanacağımız oldukça önemli işlevlere sahip aktivitelerdir.

 

İç içe yerleştirilmiş (Nested Runbooks) Süreçler ve Return Data

 

Runbook Control aktivitelerinden bir diğeriyle devam etmeden önce Nested Runbook yani iç içe yerleştirilmiş süreçler kavramını açmak istiyorum. Invoke Runbook aktivitesinden bahsederken bir akış içerisinden başka bir sürecin çağrılabildiğini söylemiştik. Eğer bir Runbook ana sürecin içerisindeki adımlardan tetikleniyor, çalışıp görevini tamamladıktan sonra tetikleyen Runbook'un yönü değişmeden süreç devam ediyorsa buna yuvalanmış bir Runbook diyebiliriz. Bir süreç üzerinde bunu açıklayayım.

 

 

 

 

Yukarıdaki örnekte bir sanal sunucu provision işlemi gerçekleşiyor. Sağlanan belirli bilgilerle oluşturulan sanal makinanın network ve ek disk ayarları yapıldıktan sonra işletim sistemi konfigürasyonu için farklı bir süreç tetiklenmekte. Bu Runbookta gördüğünüz 1.1 Network Ayarla ve 1.2 Ek Disk süreçleri birer Nested Runbook'tur. Tek başlarına çok bir işlevleri olmasa da ana Runbook'u destekleyerek sürecin bütününe katkıda bulunuyorlar.

 

Aşağıda bu süreçleri çağıran aktivitenin özelliklerine baktığınızda önemli bir farklılık göreceksiniz. "Wait for completion" seçeneği Nested Runbook'lar için sıklıkla kullanılmaktadır. Seçili olduğu takdirde çağrılan 1.1 Network ayarla süreci tamamlanmadan bir sonra adıma geçilmeyecektir. Bu durum sürecin doğasına da oldukça uygundur.

 

 

 

 

Süreçlerinizi bölümleyip modüller halinde Runbook'lara ayırmak ve bunları yuvalanmış şekilde çağırmak kullanılabilirliği artıracaktır. Best practice olarak da önerilen yöntemlerdendir.

 

 

 

Yeri gelmişken Nested Runbook gibi özel durumlarda kullanılabilen "Return Data" aktivitesinden de bahsedelim. Invoke Runbook ve Initialize Data sayesinden çağırdığımız dış süreçlere databus içerisinden veri iletebiliyoruz. Benzer durumda bir Nested Runbook çağırıp tamamlanmasını bekledikten sonra bu çağrılan sürecin databus'ından da geri veri almak isteyebiliriz. Bu noktada Returned Data Nested Runbooktan tetikleyen akışa veri dönmesini sağlamaktadır.

 

İlk örneğimiz olan sanal sunucu provision sürecinden devam ederek açıklayalım. Tetiklediğimiz 1.1 Network Ayarla Runbook'u içerisinde sanal sunucu için bir network adaptörü ekleniyor. Bu kısa süreç tamamlandıktan sonra tetikleyen Runbook'a eklenen adaptörün MAC adresini ve Add Network Adapter aktivitesinin durumunu döndürmek istediğimizi düşünelim. Bunu 2 adımda gerçekleştirebiliriz. Öncelikle Nested Runbook için properties kısmında Returned Data tanımları yapılmalıdır.

 

 

 

 

Runbook içerisinden geri döndürmek istediğimiz bütün verilerin tanımlanması gerek. Gerekmediği halde databus da bulunabilen her veriyi aktarmanın da bir anlamı olmayacaktır. String, Integer, Date, Boolean tiplerinden seçerek parametreler tanımlayabilirsiniz.

 

 

 

 

İkinci adım olarak bu parametreleri kullanabilmek ve aktarılacak verileri eşleştirebilmek için bir Return Data aktivitesine ihtiyacımız var. Genelde Runbook'un sonunda tercih edebileceğiniz bu objeyi birden fazla yerde kullanırken çalışma prensiplerine dikkat etmeniz gerekebilir. Bu şekilde Runbook tamamlandığında veriler tetikleyen sürece gönderilebilir.

 

 

 

 

Tetikleyen süreç tarafında bu verilere ulaşmak oldukça kolay. Süreçte nested runbook tetiklendikten sonraki bir noktadan yayımlanan veriler arasında tanımladığımız parametreleri görebilirsiniz.

 

 

 

 

Returned Data'nın Nested Runbooklar ile kullanımı çok yerde işinize yarayacaktır. Yerine göre tamamen bir fonksiyon yada method kullanmak gibi düşünebilirsiniz. Mesela, süreç içerisinden sayısal işlem yapan bir Runbook'a gerekli parametreler ve sayıları gönderip işlem sonucunu Returned data sayesinde çekerek faydalanabilirsiniz.

 

 

Job Currency ve Süreçlerin Eşzamalı Çalışması

 

Konumuzu kısa süreliğine aktivitelerden tekrar kavramlara çevirelim. Runbook'larla ilgili olarak kullanabileceğimiz özelliklerden biri de Job Currency yani süreçlerin eş zamanlı çalışmasıdır. Varsayılan olarak oluşturulan bütün Runbooklar aynı anda aktif olarak sadece 1 adet çalışabilmektedir. Yani işleyen bir Runbook'u durdurmadan aynı Runbook için yeni bir süreç başlatamazsınız. Bu durumda bir Invoke Runbook aktivitesinden birden fazla sayıda veri gönderildiğinde bir kuyruk oluşacak ve Runbook yapısı gereği her veri için tek tek ve sırayla çalıştırılacaktır.

 

Tabi System Center Orchestrator da eş zamanlı Runbook çalıştırmak için 1 adetle kısıtlanmış durumda değiliz. Job Currency ayarları ile yapılabilecek paralel iş sayısını artırabiliriz. Runbook başına değiştirilebilen bu değere Runbook Properties kısmından ulaşabilirsiniz.

 

 

 

 

Maksimum eş zamanlı iş sayısını artırdığınız takdirde sürecinize paralel iş yapma yeteneği kazandırmış olursunuz. Bu Runbook aktif haldeyken Run butonu ile bir instance daha başlatabilirsiniz yada başka bir süreç içerisinden tekrar çağırabilirsiniz. Bu sayının kaç olarak değiştireleceği ise duruma ve ihtiyacınıza göre değişebilir. Her yeni instance, Runbook Action sunucusuna ek bir yük getirecektir.

 

 

 

 

Tabi bu özelliğin kullanımı sırasında dikkat edilmesi gereken bazı konular ve limitlerde mevcut:

 

• Bir Runbook için eş zamanlı iş değerini değiştirmeden önce sürecin paralel çalışması halinde başarıyla tamamlanabileceğinden emin olmalısınız. Dosya operasyonları gibi işlemlerin birden fazla yada eş zamanlı çalıştırılması oldukça hassas bir konudur. Örneğin belirli bir dosyayı silme ve oluşturma aktiviteleri ya belirli bir klasörde çalışıldığı durumlarda Runbook'un eş zamanlı çalışması aynı dosyalar üzerinde yapılmaya çalışan işlemlerin çakışması ve başarısız olması anlamına gelecektir.
• Monitor aktiviteleri (Örn: Klasör, Servis, SCOM Alert izleyen) dediğimiz türden sürekli aktif ve çalışan objeler ile başlayan süreçler doğası gereği birden fazla çalıştırılamaktadır. Bu Runbookların Job currency değerini değiştirdiğiniz takdirde bir hata mesajı görüntülenir ve tekrar değer 1 olarak eski haline döndürülür.
• Orchestrator ile çalıştırılabilecek maksimum iş sayısı Runbook Server üzerindeki maksimum Runbook işleme limitiyle sınırlıdır. Bu değer bir tool aracılığıyla değiştirilebilir.
• Entegrasyon yapılan özellikle Microsoft ürünü olmayan ticket yada izleme sistemleri gibi uygulamaların çoklu ve eş zamanlı bağlantı desteği olup olmadığına dikkat etmelisiniz. Bu durumdan emin değilseniz paralel işlemeyi kullanmamak yararınıza olacaktır.
• Paralel süreçlerin çalıştığı Runbook sunucuda hata oluşması durumunda başka bir Runbook sunucuya fail-over olabileceğini de göz önünde bulundurun.

 

Bu uyarılardan sonra umarım hala kullanmayı düşünüyorsunuzdur. Süreçlerin eş zamanlı çalışması çoğu durumda size büyük avantaj sağlar ve bir otomasyon sisteminden alacağınız verimi oldukça artırır. Süreçleri tasarlarken paralel işlemeyi desteklemesini ve beraberinde bu uyarıları dikkate almakta fayda var.

 

Süreç İçerisinde Dallanma (Branching) ve Junction Kullanımı

 

Runbook dizayn aşamalarında aktiviteler arası bağlantı ve şartları belirlemek açısından Link durumlarından (Link Conditions) faydalandığımızı konuşmuştuk. Bu akıllı linkleri (smart links) kullanarak Runbook içerisinde branch dediğimiz dallandırılmış yapılar oluşturabiliriz. Bu sayede durum ve çıktılara göre süreci yönlendirebilir veya istenirse aynı anda paralel bir şekilde yürütülmesini sağlayabiliriz.

 

Fikir vermesi açısından görsel olarak birkaç örnekle açıklayalım. İlk Runbook'a baktığımızda belirli bir windows uygulama servisinin durumunu kontrol eden bir aktivite ve bu servisin durumuna göre farklı dallara ayrılan bir yapı olduğunu görüyoruz. Süreç çalıştırıldığında kontrol edilen servisin durumuna göre iki yönden birine doğru akarak ilerliyor.

 

Benzer bir diğer örnek ise sanal sunucu provision işlemi için uygulanmış. Girdilere göre oluşturulacak sanal sunucunun Hyper-V yada Vmware platformunda mı olacağı linkler ile şartlandırılarak yönlendiriliyor.

 

 

 

 

Bu dallara ayrılan sürecin yönünü nasıl yapılandırdığımıza bir bakalım. İlk makalede bahsettiğim gibi oluşturduğumuz link üzerine çift tıklayarak şartların belirlenebileceği kısıma erişebiliriz. Include bölümü içinde linkin başlangıç ucundaki aktiviteden yayımlanan verilerden birini seçip koşulu yapılandırabiliriz. İlk Runbook örneğinde Servis durumunu seçip stopped string'ini içeren bir çıktı olduğunda alttaki dal olan Start/Stop Service aktivitesine gitmesi sağlanabilir.

 

 

 

 

İkinci örneğimiz için de aynı şekilde Initialize Data aracılığıyla girilen veriyi koşullar ile yorumlayarak ilgili dala ayırıp yönlendirilmesini sağlayabiliriz.

 

Aynı link için birden fazla koşul eklenebilmektedir. Yalnız bu koşullar eklenirken aralarındaki ilişki sadece mantıksal OR (yada) olarak yapılandırılabilmektedir, yani eklediğiniz takdirde elinizde birden farklı durumlarda aynı link üzerinden ilerleyen bir yapı olacaktır. Exclude bölümünde de benzer şekilde koşullar belirleyebiliriz, fakat bu koşullar linkin ilerlememesi yönünde tanımlanan durumlar olacaktır. Yani Include içerisindeki bir şart gerçekleşse bile Exclude içerisinde aynı anda gerçekleşen bir şart baskın gelerek yönlendirmeyi engelleyecektir.

 

 

 

 

 

Dallandırma yaparken gözden kaçırılmaması gereken bir konu link üzerinde kullanılabilecek yayımlanan verilerin sadece o linkin başlangıç noktası olan aktiviteden alınabileceğidir. Önceki aktiviteler yada uzaktaki Initialize Data aktivitesinden gelen verileri link üzerinde kullanamamaktayız. Bu bakımdan biraz kısıtlayıcı gibi görünse de, Runbook dizayn aşamasında geçilmesi çok zor bir engel değildir. İşe yarar birer eklenti olarak Options kısmında linklerin istenirse gecikme sürelerini, renk ve çizgi kalınlığını ayarlayabileceğinizi hatırlatmakta fayda var. Ayrıca Runbook Designer ayarlarından Show Link Labels seçeneğini aktif hale getirdiğinizde takdirde Linklerin adları da Runbook üzerinden görülebilmektedir.

 

Dallara ayırdığımız Runbook içerisindeki aktiviteler her zaman tek bir dal üzerinde gitmek zorunda değildir. Duruma göre aynı anda paralel giden branch'lar oluşturabiliriz ve bu da bize paralel işlem avantajı getirir. Runbook kontrol aktivitelerinden "Junction" burada Paralel dalları kesişebileceği veya sonlanacağı noktalarda durdurmayı sağlamaktadır. Durdurmaktan kasıt aslında bütün dalların tamamlanmasının bekletilmesi anlamına gelmektedir. Bu sayede dalların sürecin akışını bozacak şekilde önceden ilerlemesi veya işlemlerin sırasının bozulması engellenir. Kullanım alanlarından biri de kollardan gelen veri akışını kısıtlayarak dalın sonlandığı aktivitelerin gereksiz yere birden fazla çalıştırılmamasını sağlamaktır.

 

Aşağıdaki örnekte bir uygulama SCOM üzerinde alert ürettiğinde devreye giren bir Runbook var. Hata tespit edildiği anda 3 koldan çalışan aktiviteler junction ile kesilerek, bittiklerinden emin olunduktan sonra diğer adımlara geçilmekte.

 

 

 

 

Birbirinden bağımsız işlemlerin paralel çalıştırılarak sürecin hızlandırılabileceğini burada açık bir şekilde görebiliyoruz. Hemen sonrasında ise bir Junction eklenerek işlemlerin tek koldan devam edilmesi ve sonraki aktiviteye geçmeden önce tamamlanmaları garantilenmiş.

 

Junction objesinin özelliklerine baktığımızda "Return data from" ile sadece gelen kollardan birindeki verilerinin alınabildiğini görüyoruz. Bazen kalan diğer verilerin ileriye aktarılamaması dezavantaj gibi görünse de uygulamanın mimarisi bunu gerektiriyor.

 

 

 

 

Süreçlerinizde Junction kullanarak karmaşıklaşmış Runbooklar içerisindeki gereksiz veri aktarımının durdurmasını ve dallandırma yapıldığında dalların tek bir noktada toplamasını sağlayabilirsiniz. Dikkat edilmesi gereken nokta ise, Junction objesi sonrası yayımlanan veriler arasında kollardan gelen objeler görülmesine rağmen değer olarak boş gelmektedirler. Bir bakıma Junction databus üzerinde bir kesinti yaratmaktadır.

 

Çok Değerli (Multi-Value) Çıktılar ile Çalışmak

 

Kavramlardan bahsetmeye aktiviteleri ilgilendiren bir konu üzerinden devam edelim. Aktivitelerin hemen hemen hepsi amacını gerçekleştirdikten sonra çeşitli değerler üretmektedir. Bazı aktiviteler ise çıktı olarak multi-value dediğimiz çoklu değerler içeren veriler üretebilir ve bunları geri döndürebilir. Read Line text aktivitesi buna güzel bir örnektir. İçerisinde birden fazla satır olan bir text dosyası bu aktivite ile okunduğunda her satırı ayrı bir değer olarak dönecektir. Tek ve çoklu değerler arasındaki fark bu veriler bir sonraki aktiviteye aktarıldığında ortaya çıkar. Çoklu değer içeren bir aktivite tetiklediği bir sonraki aktiviteyi bu değer sayısı kadar çalıştıracaktır, yani read line ile 10 satır okunduysa bir sonraki obje 10 kere çalıştırılmaktadır. Bu durum Orchestrator'ın genel davranış biçimidir.

 

 

 

 

Bir örnek ile durumu açıklamaya çalışalım. Belirli bir klasördeki dosyaların bilgilerini alıp bir text dosyasına yazan bir sürecimiz olsun. Aşağıda olduğu gibi bu süreci çalıştırdığımızda Get File Status aktivitesi 5 adet dosya bulmakta ve her biri için Append Line aktivitesini çalıştırmaktadır. Runbook loglarına baktığımızda da bunu doğrulayabiliriz.

 

 

 

 

 

 

Multi-value çıktılar çoğunlukla Runbook'larda gereken amaca hizmet etmektedir. Peki ya bu davranışı değiştirmek gerekirse? O zaman devreye bütün objelerde kullanılabilen çalışma davranışı (Run Behavior) dediğimiz bir özellik girmektedir. Runbook dizayn aşamasında oldukça faydalı olan bu seçerek standart ve düzleştirilmiş (Flatten) olmak üzere 2 çeşide ayrılır. Standart davranışta multi-value veriler anlattığım gibi çoklu tek çıktılar halinde aktarılırlar. Flatten (düzleştirilmiş) davranışla bu satır satır olan verilerin, tek bir çıktı olarak aktarılması sağlanır.

 

Bu ayarları aktivitenin özelliklerinden değiştirebiliriz. Aşağıdaki gibi ilk aktivite olan Get File Status için Run Behaviour kısmını açalım. Flatten dediğimiz takdirde düzleştirilmiş veriler için bir format belirlenebiliyor. Belirlediğiniz format data manipulation fonksiyonları kullanırken işinize yarayabilir. Ben örnek olarak ||| karakterlerini tercih ettim.

 

 

 

 

Yukarıdaki aynı süreci bu sefer aktiviteyi düzleştirerek tekrar çalıştıralım. Gördüğünüz gibi Append Line aktivitesi 1 kez çalıştırılacak, çünkü Get File Status objesinden gelen File name verileri tek bir satırda aralarında ||| karakteri ile ayrılacak şekilde düzleştirilmiş durumda.

 

 

 

 

Standart ve düzleştirilmiş çıktıları tek bir görüntüyle özetlemeye çalışırsak Append Line aktivitesinin oluşturduğu text dosyası aşağıdaki gibi olacaktır.

 

 

 

 

Aktivite çalışma davranışını düzleştirmek çok çeşitli durumlarda işe yarayabilir. Tetiklenen aktivitenin birden fazla instance oluşturmaması istendiği yada aktarılacak verilerin tek seferde gönderilmesinin uygun ve gerekli olduğu durumlar bunlardan birkaçıdır.

 

Düzleştirmeyle ilgili dikkat edilmesi gereken bir nokta aktivitenin çoklu instance oluşturduğu durumlarda etkili olmayacağıdır. Bu gibi durumlarda Junction kullanmak fayda edebilir. Düzleştirme sadece tek bir aktivite instance'sı için çoklu değer döndüğünde uygulanabilir.

 

Aktivite Döngüleri (Looping)

 

Aktivitelerle ilgili önemli özelliklerden biri de kendi içlerinde döngüler oluşturabilmeleridir. Looping denilen bu özelliği kullanarak aktivitelerin otomatik şekilde kendi içlerinde tekrar etmesini sağlayabilirsiniz. Döngüler sayesinde aktiviteler işlem başarılı olamazsa yeniden deneyebilir yada çıktının doğruluğundan emin olmak için birden fazla kez çalıştırılabilir. Aynı şekilde bu mekanizmaları süreç içerisinde bekleme durumları yaratmak istediğinizde de kullanabilirsiniz.

 

Bir örnekle daha anlaşılır hale getirmeye çalışayım. Aşağıdaki Runbook da bir sistem üzerinde basit bir uygulama bakım çalışması yürütülüyor. Belirli bir sunucu üzerinde çalıştırılan script sonrası makina restart ediliyor ve makinadaki çalışma yaptığımız uygulama process'inin durumu kontrol edilmeye başlanıyor. Eğer uygulama çalışıyorsa runbook bir daldan çalışmıyorsa başka bir daldan ilerliyor. Bu süreçte Get Process Status objesinde kullanılan Looping özelliğinin neden gerektiğine bir bakalım.

 

 

 

 

Fark ettiğiniz gibi Restart System aktivitesiyle sunucu için restart işlemi tetikleniyor. Sunucu işletim sistemi yüklendiği sırada süreçte bir sonraki obje yani process'in durumunun kontrolü çalıştırıldığında başarısızlığa uğraması kaçınılmaz olacaktır. Bu durumu aşmak için Get Process Status aktivitesini sonuçtan emin olana kadar döngüye sokup belirli bir süre daha tekrar ve tekrar çalıştırılmasını sağlayabiliriz.

 

Döngülerin ayarlanması oldukça kolay, bir aktiviteyi döngüye sokmak için sağ tuşla tıklayarak" Looping..." ayarlarına girmeniz yeterli.

 

 

 

 

Burada öncelikle bu özelliği aktif etmeli, sonrasında ise tekrar denemelerinin arasında ne kadar saniye bekleneceğini belirlemelisiniz. Bu süre aktiviteye ve sürece göre değişiklik gösterecektir, ama çok düşük tuttuğunuzda Runbook sunucusunun iş yükünü artırabileceğini unutmayın

 

 

.

 

 

Bir sonraki adımda hangi durumun bu döngüyü sonlandıracağı belirtilmelidir. Eğer bir çıkış koşulu belirlemezsek sürecimiz bu noktada sonsuza kadar takılıp kalacaktır. Exit kısmında bulunan çıkış kriterleri aynı link yapılandırmaları gibi oluşturulmaktadır. Aktivite içerisinden gelen herhangi bir yayımlanan veri bu iş için kullanılabilir. Bunlarla beraber ortak yayımlanan veriler arasındaki Loop bilgilerini içeren öğeler de bu kriterleri belirlerken oldukça faydalı olmaktadır. Birden fazla kriter kullanılabilirsiniz fakat bu koşullar sadece OR mantıksal operatörü ile bağlanabilir.

 

 

 

 

Örneğimizde iki adet koşul belirlenmiş durumda. İlk olanı döngüye soktuğumuz aktivitenin bir çıktısı olan çalışan process sayısı. Eğer bu sayı 1 ise aktivitemiz amacına ulaşmış ve süreç devam edebilir diyebiliriz. Fakat bu sayı 1 değilse döngü sonsuz sayıda tekrar edecektir. Bunu istemediğimiz için ikinci bir koşul olarak aktivite döngüsü tekrar sayısının 10 olması durumunu da çıkış ayarlarına ekleyebiliriz. Ayrıca bu şekilde 30sn de bir çalışacak aktiviteye en fazla 300sn gibi bir süre çalışma limiti koymuş oluyoruz.

 

Son adımda opsiyonel olarak döngüden çıkılmasını engelleyen bir koşul belirtebiliriz. "Do Not Exit" kısmında belirlediğimiz şartlar çıkış için belirttiğimiz şartlara baskın gelmektedir. Yani döngüden çıkış şartları sağlansa bile bu kısımdaki şartlardan biri gerçekleşiyorsa döngü çalışmaya devam edecektir. Aşağıda örnek olması için aktivitenin düzgün çalışmama durumlarını bu kısma ekledim.

 

 

 

 

Aktivite döngülerinin kullanılması Runbook'ların başarımını oldukça artırmaktadır. Yalnız kullanırken multi-value çıktı üreten aktivitelerde biraz daha dikkat etmeniz gerekebilir. Döngü yapılması ayarlanmış bir objeye bir önceki aktiviteden multi-value çıktılar geldiği takdirde her veri için ayrı ayrı döngüler oluşacaktır. Read Line aktivitesinden gidecek olursak buradan okunan 3 satır döngüye girmiş bir sonraki obje için 3 ayrı instance ve beraberinde 3 ayrı döngü anlamına gelmektedir. Ayrıca bu gibi durumda döngüler sırayla oluşacak, bir aktivite instance'ı bitmeden diğeri çalışmayıp kuyrukta bekleyecektir.

 

Süreçleri Zamanlama ve Scheduling Aktiviteleri

 

 

Runbook'ları önce manuel çalıştırdık, sonra başka Runbooklar üzerinde Invoke Runbook ile tetikledik şimdi ise sıra bu süreçleri zamanlayarak otomatik çalıştırmaya geldi. Orchestrator bize Runbookları zamanlayabilmek için 2 ayrı aktiviye sunuyor. Monitor Date/Time aktivitesi süreçlerin başına getirilerek belirli aralıklarla çalışmalarını sağlıyor. Bu aralıklar günün belirli bir saati olabileceği gibi dakika, saat ve gün cinsinden genel sürelerde belirlenebiliyor. Check Schedule aktivitesi ise daha pasif olarak çalışıyor. Bu objede önceden belirlenen zaman şablonları çalıştırıldığı andaki zaman bilgisiyle karşılaştırılarak True yada False bir değer döndürülüyor.

 

Aşağıdaki basit bir Runbook ile bu iki aktivitenin nasıl işlediğine bir bakalım. Amacı çok da önemli olmayan sürecimiz için kısaca hafta içi günlerde saatte bir çalışacak bir zamanlama yapmak istediğimizi varsayacağım.

 

 

 

 

İlk olarak Runbook'da konumlandırılmış sadece Runbook'ların en başına eklenebilen Monitor Date/Time objesinin özelliklerine bakalım. Kolayca anlaşıldığı gibi Runbook'un otomatik olarak çalıştırılacağı zaman aralığı saatte bir olarak şeçilmiş. Böylece runbook ilk çalıştırıldığı saatten itibaren 1 saat sonra tekrar çalıştırılacaktır.

 

 

 

 

İkinci olarak kullanılan Check Schedule objesi ise bir çeşit filtre görevi görmektedir. Bu aktivite Monitor Date/Time ile beraber kullanıldığı gibi ayrı olarakta rahatlıkla süreçler içine yerleştirilebilir. Objenin özelliklerine girdiğinizde sadece bir zamanlama şablonu seçebildiğinizi göreceksiniz.

 

 

 

 

Bu zaman şablonlarını ise Global Settings bölümünden ayarlanabilmektedir. Yeni bir şablon oluşturarak istediğimiz Check Schedule aktivitelerinde tekrar tekrar kullanabiliriz.

 

 

 

 

Bir şablona daha yakından bakalım. Örneğimizde olduğu gibi sadece hafta içi günleri seçerek bir şablon oluşturabiliriz. İstersek hafta kısıtlamaları uygulayabilir veya el ile ayın günlerini girebiliriz. Günün saatleri bazında da bir kısıtlama belirtmek mümkün. Bunların yanında Execptions kısmından istenirse istisna bir zaman belirleyerek şablonun o tarihte doğrulanmamasını yani olumsuz sonuçlanmasını sağlayabiliriz.

 

 

 

 

Peki bu Check Schedule aktivitesini Runbook içerisine yerleştirdikten sonra nasıl kullanacağız? Aktivite çalıştıktan sonra anlık zaman bilgisiyle zaman şablonunun uyup uymadığının kontrolünü yapmaktadır. Her zaman olduğu gibi akıllı linkler bu aktivitenin de koşullarını belirlemekte kullanılır. Aktiviteden yayımlanan bu değer sonrasında olumlu yada olumsuz belirttiğimiz koşula göre süreci ilerletebiliriz.

 

 

 

 

Buraya kadar sabırla okuduğunuz için teşekkürler. Örneklerle desteklemeye çalıştığım makalede umarım kavramlar arasında kaybolmamışsınızdır. System Center Orchestrator üzerinde kompleks süreçler oluşturabilmek ve ürünün bütün nimetlerinden faydalanabilmek için ileri seviye diyebileceğimiz kavramları açıklamaya çalıştım, umarım faydalı olmuştur. Son olarak nelere değindik bir bakalım:

 

• Invoke Runbook aktivitesi ile Runbook içerisinden başka süreçlerin tetiklenmesi,
• Süreçleri başlatırken Initialize Data ile veri ve parametrelerin gönderilmesi,
• İç içe yerleştirilmiş (Nested Runbooks) süreçler oluşturma ve Return Data ile bu süreçlerin geri beslenmesi,
• Job Currency ayarları ve süreçlerin eşzamalı çalıştırılabilmesi,
• Süreç içerisinde dallanma (Branching) ve Junction kullanımı ile dalların bağlanması,
• Aktivitelerin ürettiği çok değerli (Multi-Value) dediğimiz çıktılar ile çalışmak ve aktivite çalışma davranışları,
• Aktivite Döngüleri (Looping) oluşturmak,
• Süreçleri zamanlayarak çalıştırma ve scheduling aktivitelerinin kullanımı.