Başlangıç masumdur. Bir rapor için SAP tarafındaki sipariş verisiyle haricî bir veritabanındaki müşteri listesini yan yana getirmek gerekir. Birisi iki dosyayı indirir, bir arama formülü yazar, sonucu paylaşır. Çeyrek saatlik iş.
Sonra o rapor aylık hâle gelir. Ardından ikinci bir birleştirme eklenir. Bir yıl sonra ortada adı “nihai_v7” olan bir dosya, onu hazırlayan tek bir kişi ve o kişinin izne çıktığı hafta gelmeyen bir rapor vardır. Birleştirme kuralı hiçbir yerde yazılı değildir; bir formülün içinde yaşar.
Birleştirme kuralı kimin bilgisayarında yaşıyor
Rakamla ifade edilmesi zor olan kısım burada: bir iş kuralı kurum hafızasından çıkıp bir bilgisayara taşınmıştır. Kural değiştiğinde kimin haber vereceği, sonucun neye göre doğru sayıldığı ve geçen ayın sayısının neden farklı olduğu artık cevapsız sorulardır.
Bu noktada ilk akla gelen çözüm genellikle “bir ETL aracı kuralım” olur. Bazı ihtiyaçlar için doğru karar. Ama tek bir raporun iki kaynağı yan yana getirmesi gerekiyorsa, BI Portal bunu kendi içinde tanımlı bir akış olarak yapar.
Join düğümü ile union düğümü aynı riski taşımaz
Akış, sürükle bırak tasarımcısında kurulan düğümlerden oluşur: kaynak, dönüşüm, filtre, toplulaştırma, birleştirme (join), birleşim (union), veri kaynağına yazma ve e-posta hedefi.
İki birleştirme düğümü farklı sorunu çözer ve farklı bozulur. Join iki veri kümesini ortak anahtar üzerinden yan yana getirir; buradaki risk satır çoğaltmadır. Anahtarın her iki tarafta tekil olduğundan emin olmadan ilerlemeyin. Union satırları alt alta ekler; buradaki risk kolon uyumsuzluğudur. Adlar ve tipler hizalanmazsa sonuç sessizce yanlış çıkar.
Her düğüm tek tek önizlenebildiği için iki risk de tasarım aşamasında görülebilir. Önizlemeyi atlayıp akışın tamamını çalıştırmak, hatayı en son adımda aramak demektir.
Düğüm sırası tasarımı neden belirliyor
Düğümler yönlü bir çizge oluşturur ve topolojik sırayla çalışır. Mevcut yürütücü bu düğümleri tek iş parçacığı üzerinde ardışık işler; düğümler paralel çalışmaz. Bunu bilmek tasarımı doğrudan etkiler: ağır kaynağı akışın başında filtrelemek, gereksiz kolonları erken düşürmek ve ara sonucu küçültmek doğrudan işe yarar.
Akış için satır sayısı ve çalışma süresi sınırları tanımlanabilir; çalıştırma ve düğüm kayıtları tutulur. Düzenli çalışan bir akışta sorun çıktığında hangi çalışmanın farklı davrandığı görülebilir. Bu, birleştirme mantığını her seferinde yeniden sorgulamaktan hızlı bir teşhis yoludur.
Akış çıktısını nereye yazmak işe yarar
Sonuç iki yere gidebilir. Yeni bir BI veri kaynağının önbelleğine yazılabilir: akış bir kez çalışır, birleştirilmiş sonuç bir veri kaynağı hâline gelir ve panolar bu kaynaktan beslenir. Aynı birleştirmeyi her göstergede yeniden kurmak gerekmez.
İkinci yol e-posta hedefidir. Burada doğrulanmış ek biçimi UTF-8 BOM’lu CSV’dir; bu hedefte Excel eki beklemeyin. Akış çalıştırma ve önbellek yenileme işleri ortak görev altyapısıyla zamanlanabilir; böylece aylık raporun tetikleyicisi de bir kişinin takvimi olmaktan çıkar.
Çalıştırmadan önce iki kontrol alışkanlığa değer: birleştirmeden sonra beklediğiniz satır sayısını önceden yazıp sonuçla karşılaştırmak ve birkaç kaydı elle doğrulamak. Toplam doğru görünürken kırılım yanlış olabilir. Elinizde her ay Excel’de birleştirilen iki kaynak varsa, o birleştirme tek bir akış tanımıyla ifade edilebilir; hangi iki kaynak olduğunu bize yazın, ilk akışı birlikte kurgulayalım.