Hata Takibi

Bir süreç platformunun en büyük özelliklerinden birisi de İzlenebilirlik kavramıdır. Bu hangi akışın, kimde olduğundan ziyade hangi entegrasyonlarım çalışıyor, hangi kodum nasıl çalıştı sorularının da cevabını getirir. Bunu sağlamanın yöntemi de akışı olası hataları da düşünerek tasarlamaktır.

Aşağıda çeşitli başlıklar altında olası hataların nasıl tespit edileceği veya olası hataların nasıl ortaya çıkarılacağı konusunda açıklamalar ve senaryolar bulunur.

Tip Alanlarının Değişimi

Akışlarda tip alanları ilk oluştuktan sonra her veri güncellemesinde AUDIT tablolarına kaydı oluşturulur. Veri güncellemesi her iş adımında (otomatik veya manuel aktivite) gerçekleşebilir. Manuel aktivitede birden fazla da gerçekleşebilir. Örneğin kullanıcının akış formunu çeşitli zamanlarda açıp bir bilgi yazıp kaydetmesi durumu gibi. Bu durumda her kayıtta AUDIT tablosunda bir satır oluşur.

Audit tabloları ilk tip tablosu oluşturulurken oluşur. Örneğin yeni oluşturduğunuz tip adı T_YENI_AKIS olsun. Oluşan Audit tablosunun adı da AUDIT_T_YENI_AKIS olur. Tip tablosunda her kaydın tekil numarası olan Nesne Numarası(OBJECT_ID) ile Audit tablosunda bulunan aynı isimdeki kolon ile ilişkilendirilir. Audit tablosunda her nesne numarası için birden fazla kayıt olabilir. Bu tabloda ayrıca şu kolonlar bulunur;

MODIFIER: Kaydeden kullanıcının giriş adıdır.

MODIFY_DATE:Kayıt tarihidir.

ITEM_ID: Akışın adım adı(WORKITEM_ID)

İş Akışı Yönetimi ekranında akış tarihçesi incelendiğinde standart adım bilgilerinden sonra tipin aranabilir işaretlenmiş kolonları alfabetik sırada bulunur.

Aşağıdaki örnek ekranda tip alanlarının hangi akış adımında nasıl değiştiği takip edilebilmektedir. Örneğin belli bir adıma kadar izin onay durumu alanı boş gelmiş, ondan sonra Onaylandı olarak değişmiştir.

Tasarım Esnasında Kullanılan Yazı Alanları

Çoğu akışta karar nesnelerinde kullanılmak üzere yazı alanları bulunur. Örneğin bir önceki adımda kullanıcının onay işleminde alana ONAY, ret işleminde ise RET yazılarak bir sonraki kontrol adımında ise duruma göre akış farklı yollara girebilir.

1. Burada kullanılacak alanların Türkçe karakter içarmemesi, her yerde aynı yazılması(örneğin hep büyük harf gibi), yazı arasında boşluk olmaması tavsiye edilir. Bu her bölümde bu alanın değerinin kontrolünü kolaylaştırır. Örneğin "Onaylandı", "Onay Verildi" gibi değerler yerine ONAY yazılması, bu yöntemin tüm tasarımlarda standart olması yapılacak tasarımı kolaylaştırır.
2. Karar aktivitelerinde çok fazla çıkış adımından kaçının. 

Örneğin yukarıdaki tasarımı okumak son derece zordur. Karar adımı 5 değişik aktiviteye gitmektedir. Bunlardan biri de Diğer Durumda (ELSE) seçeneğidir. Ayrıca AND ile bağlanan her bölümde birden fazla alanın değeri kontrol edilebilir.

Bunu kolaylaştırmanın yolu birden fazla karar aktivitesi kullanmaktır. Bu durumda her karar aktivitesinin değeri daha sade olur ve akışın hangi değerle hangi adımlara yönlendirildiği daha rahat takip edilebilir.

Ayrıca yukarıda görüldüğü gibi her karar aktivitesinden çıkan bağlaç üzerinde alan ve değeri yazılarak okuma kolaylığı sağlanmıştır. Tasarımda daha fazla dikkat çekebilmek adına bağlantılar renklendirilebilir.

Makro Aktivitelerinin Planlanması

Makro aktiviteleri genelde biryerlerden (veya akışın kendisinden) bazı verilerin okunduğu, bununla birlikte bazı hesaplamaların yapıldığı, daha sonra akış tipinde alanların güncellendiği ve tekrar yazıldığı aktivitelerdir. Eğer Makro aktivitesi doğru yazılıyor ise sorun olduğunda hata (exception) üretir. Ama kod yazarken olası ihtimallerin düşünülmediği durumlarda akış verisi yanlış bir değer alır ve ona göre devam eder.

Makro aktivitesinde bir kod hatası var ise, hatanın yeri ve şekli hata mesajında belirtilir.

Daha rahat açıklayabilmek adına şöyle bir senaryo belirleyelim;

Akış başlangıç formunda kullanıcı giriş adı ile beraber pozisyon bilgisi bir tabloya yazılır. Kural motorunda pozisyonların hangi yetki seti ile akış eklentisini göreceği belirlenmiştir. Akışın ilk adımı makrodur ve kullanıcının pozisyon bilgisinden eklentiye atanacak yetki seti bulunur ve eklentinin yetkisi güncellenir. 

Bu makro üzerinde olası hatalar şunlardır;

• Platformlar arası taşımada kural motoru alınmamıştır veya derlenememiştir.
• Kullanıcının pozisyonu kural motorundaki tabloda bulunmaz.
• Yetki setleri/pozisyonlar platformlar arası taşınmamıştır.
• Yetki setinin adı /pozisyonun adı ilgili ekranda değiştirilmiştir.
• Kural motorunda yetki seti veya pozisyon yazılırken yazım hatası yapılmıştır.

Kısacası kurguda olmayan bir durum oluşmuştur. Bu durumda makro çalışır, eğer yazılan C# kodunda bir hata almıyor ise bir hata(exception) üretmez ve akış kaldığı yerden devam eder. Yukarıdaki örnekte İşlem Adımı aktivitesine yanlış bilgiler ile gider. Burada önemli olanın akışın ilk tasarımı değil daha sonra akışın üretim ortamındaki operasyonunun olduğu da unutulmamalıdır.

Burada süreç sahibinin akışı yaşatabilmesi ve operasyon maliyetini düşürebilmesi için akış üzerinde tasarım buna göre yapılmalıdır. Örneğin yukarıdaki durum şu şekilde kontrol edilmelidir;

Akış tipine 2 alan daha eklenir. Örneğin; HATA_VAR(yazı 1), HATA_DETAY(yazı 100). Daha sonra akışın çizimi aşağıdaki gibi yapılır;

 Burada ilk makro adımından sonra bir karar adımı eklenmiştir. Senaryomuza göre makro adımının en başında HATA_VAR değeri F, HATA_DETAY değeri de boşluk olacak şekilde ayarlanır. Kod üzerinde yukarıda örneklenmiş olası hataların hepsinde HATA_VAR alanına T değeri ve HATA_DETAY alanına açıklayıcı metin yazdırılır. Karar adımında eğer değer T ise Hata Adımı aktivitesine değil ise İş Adımı aktivitesine yönlendirilir. Hata Adımı aktivitesi için bir form tasarlanır ve form üzerinde HATA_DETAY alanının değeri görüntülenir.

Hata Adımı kullanıcısı, kurumun içinde ve bu akışın bakımını yapmakla sorumlu kullanıcı olmalıdır. Kullanıcı alınan hataya göre örneğin yetki setinin adını değiştirir ve akışın adımını tekrar bitirir. Bu durumda makro adımı tekrar çalışır, başka bir hata almadıysa çalışmasına devam eder.

Diğer bir konu ise Makro aktivitesinin aslında yarım kalması sonucu atanan tip değerleridir. Örneğin yukarıdaki senaryoya ek olarak Yetki deti A ise tipin YETKILI_A alanına, Yetki seti B ise YETKILI_B alanına değer atandığını varsayalım. Makro ilk çalıştığında yanlış işlem yapmış ve YETKILI_B alanına değer atamıştır. 2nci geldiğinde de senaryoya göre YETKI_B alanına değer atayacaktır. Burada verinin de doğru atanması için makro aktivitesi başında HATA_VAR alanının sıfırlandığı gibi YETKILI_A ve YETKILI_B alanları da sıfırlanmalıdır.

Bu yapı kurumun akışların operasyonunun uygun bir şekilde yapılmasını sağlar ve izlenebilirlik ilkesini tamamlar. Bu yöntem ayrıca web servis, sap konnektörü gibi dış sistemler ile entegrasyonun olduğu tüm aktiviteler için tavsiye edilir.

Hata Kullanıcısı

Aktivitelerin çalışmaları esnasında bir hata alınması durumunda akış hata kullanıcısına yönlendirilir. Örneğin aktivitenin yerine getiren kullanıcısı tip alanından alınır ve tip alanı boştur. Yerine getiren kullanıcı aktif değildir. Adımın elektronik posta desteği vardır fakat posta gönderimi esnasında SMTP sunucusundan hata alınır. Makro adımında yazılan kod bir hata üretir. Web Servis aktivitesinde kullanılan servisin adresine erişilemez veya servis kendi içinde hata (exception) üretir. Bu örnekler çoğaltılabilir.

Akışın ilk tasarımı esnasında akışa bir hata kullanıcısı belirlenir. Tasarım ekranı akışı tasarlayan kullanıcıyı hata kullanıcısı olarak atar. Gerekiyor ise bu kullanıcı daha sonra değiştirilebilir. Hata kullanıcısı kurumun aktif ve gerçek bir kullanıcısı olmalıdır. Aksi durumda akışta bir hata oluştuğunda kurum içinden hiç bir kullanıcının haberi olmaz. Akış çalışması esnasında yukarıda da örneklenen durumlardan biri olduğunda aldığı hata ile beraber hata kullanıcısına gider.

Akış tasarımı esnasında her yeni aktivite eklendiğinde hata kullanıcısı ilk akış tasarlarken akış için belirlenen kullanıcı olarak güncellenir. Eğer aktivitenin tipine göre hata kullanıcısı belirlemek istiyorsanız (örneğin belirli bir web servisi hatasında A kullanıcısı, veri tabanı işlemi esnasında hata alınıyor ise B kullanıcısı gibi) ilk aktivite oluştuktan sonra değiştirebilirsiniz.

Zaman zaman akışın aktivitelerinin hata kullanıcısını değiştirmek isteyebilirsiniz. Bu durumda akışın hata kullanıcısı değiştirilir. Değiştirildiğinde aşağıdaki mesaj alınır;

Evet seçeneği ile beraber yeni seçilen kullanıcı tüm aktivitelerde hata kullanıcısı olarak atanır.

Akışlarda olası hatalardan kurumun haberdar olması için hata kullanıcısının aktif bir gerçek kullanıcı olması gerekir.

Akış Sistem Tarihçelerinin İncelenmesi

Akış servisinin sistem tarihçeleri düzenli olarak incelenmelidir. Bazı durumlarda akış hata almakta, hata kullanıcısına yönlendirme rutinine gelemediği için döngü içerisinde devamlı aynı hata ile sunucu kaynaklarını tüketmektedir. Servis Yönetimi sayfasında tüm servisler ve tarihçe dosyalarının yapısı açıklanmıştır.