Power Automate'de Adlandırma Kuralları

“Untitled” ya da “Instant cloud flow-3” adını taşıyan bir Flow ilk bakışta küçük bir ayrıntı gibi görünür. Ancak bir Tenant içinde birkaç Flow’dan fazlası bulunduğunda ve bunları birden çok kişi oluşturup baktığında, bir kişinin Flow’un ne yaptığını beş dakikada mı anlayacağı yoksa yarım saat boyunca Trigger’dan Trigger’a mı tıklayacağı tam olarak bu ada bağlıdır. NordFlux olarak, sizin için oluşturduğumuz her dijital çalışanda sabit adlandırma kurallarına güveniyoruz; çünkü bunlar mevcut en uygun maliyetli yönetişim önlemidir: ek bir araç yok, lisans yok, yalnızca oluşturma sırasında disiplin.

Bu nedenle Microsoft, adlandırma kurallarını isteğe bağlı bir ek değil, resmi Power Automate kodlama yönergelerinin ve Power Platform yönetişim önerilerinin sabit bir parçası olarak ele alır. Bu makale, Flow’lar, eylemler, bağlantılar ve ortamlar için en önemli kuralları doğrudan Microsoft belgelerinden türeterek özetler; böylece bunları ekibinizde bir stil kılavuzu olarak belirleyebilirsiniz. Bu sırada, otomasyonlarınızın nasıl büyüdüğü üzerindeki kontrolü her zaman elinizde tutar ve daha sonra zahmetli bir temizlik yapmak zorunda kalmazsınız.

Bir adlandırma kuralı neden yönetişimin temelidir?

Microsoft’a göre, Power Platform için bir Center of Excellence birden çok sütun üzerinde durur; bunların arasında veri güvenliği, erişim hakları ve izleme yer alır. Bunlardan biri çözüm geliştirmedir ve Microsoft burada yönetişimin bir görevi olarak açıkça “okunabilirliği ve bakım yapılabilirliği sağlamak için kodlama standartları ve adlandırma kuralları”nı belirtir. Gerekçesi açıktır: Tutarlı adlar olmadan ne otomatik raporlama yapılabilir ne de acil bir durumda hangi Flow’un hangi bağlantıyı kullandığı veya hangi ortamın üretimde olduğu hızlıca anlaşılabilir. Böylece adlandırma kuralları kozmetik bir mesele değil, erişim denetiminin, izlemenin ve raporlamanın çalışabilmesinin dayandığı temeldir.

Flow’ları, Trigger’ları ve eylemleri nasıl adlandırmalısınız?

Bir Flow içindeki bileşenler için Microsoft belgelerindeki Flow bileşenleri için tutarlı adlandırma kullanma başlığı beş somut öneri sunar:

• Genel adlandırmalar yerine açıklayıcı adlar. Bir Trigger “Trigger1” olarak değil, örneğin “Yeni e-posta alındı” olarak adlandırılmalıdır; böylece amaç hemen anlaşılır.
• Kelime ayırma için CamelCase veya alt çizgi. “sendEmailNotification” veya “send_email_notification” gibi eylemler bir bakışta okunabilirken, “sendemailnotification” okunmaz.
• Kategorilendirme için ön ekler. Microsoft, bir bileşenin rolünün hemen anlaşılabilmesi için Trigger’ları “Trg_”, eylemleri “Act_” ve değişkenleri “Var_” ile işaretlemeyi önerir.
• Tüm Flow’lar genelinde tutarlılık. Aynı kuralı her Flow’da uygulayan bir ekip, her yeni meslektaş Flow’unda yabancı bir stili çözmek zorunda kalmaz.
• Kuralın belgelenmesi. Örneğin ortak bir SharePoint sayfasındaki bir stil kılavuzu, yeni ekip üyelerinin kuralları mevcut Flow’lardan çıkarmak yerine bilmesini sağlar.

Microsoft ayrıca, özellikle karmaşık Flow’larda veya birden çok kişinin üzerinde çalıştığı durumlarda eylemlere yorum eklemeyi önerir. Bir ad, bir eylemin ne yaptığını söyler; bir yorum ise neden bu şekilde oluşturulduğunu söyler.

Adlandırmada bağlantılar ile bağlantı başvuruları arasındaki fark nedir?

Bağlantılarda (Connections) adlandırma sorusu hızla karmaşıklaşır; çünkü Power Automate iki farklı kavram tanır. Çözüm özellikli Cloud Flow kullanmanın avantajları başlıklı belgeye göre bağlantılar, kimlik doğrulama ayrıntılarını içeren ve çözümlerin dışında doğrudan eylemlere gömülen kullanıcıya özel yapılandırmalardır. Bir bağlantıyı değiştirdiğinizde, onu kullanan her eylemin ayrı ayrı güncellenmesi gerekir. Buna karşılık bağlantı başvuruları, bir bağlantıya işaret eden bir işaretçidir ve çözüm özellikli Cloud Flow’larda kullanılır. Flow tasarımını somut oturum açma bilgisinden ayırır ve her eyleme dokunmanıza gerek kalmadan geliştirme, test ve üretim ortamı arasında değiştirilebilir.

Adlandırma kuralı açısından bu şu anlama gelir: Bir bağlantı başvurusu, Flow tasarımcısının otomatik olarak atadığı genel öneriye güvenmek yerine, hizmeti ve kullanım amacını adında taşımalıdır; örneğin “conref_sharepoint_freigabeliste”. Böylece bir çözümü ortamlar arasında taşırken, her eylemi tek tek açmadan hangi başvurunun hangi harici hizmete karşılık geldiğini hemen görürsünüz.

Ortamlar için bir adlandırma kuralını nasıl oluşturursunuz?

Tek tek Flow’ların ötesinde de sabit kurallar gerekir. Microsoft’un ortam stratejisi önerileri dört yapı taşından oluşan bir model önerir: yaşam döngüsü aşaması, bölge, iş birimi ve amaç; örneğin “Prod-US-Finance-Payroll”. Alternatif olarak, daha küçük kuruluşlarda çoğu zaman “Contoso Dev”, “Contoso Test” ve “Contoso Prod” gibi daha basit bir şema da yeterlidir; yeter ki hangi ortamın hangi amaca hizmet ettiğini tutarlı biçimde ayırsın. Ayrıca Microsoft’a göre, ortam adlarına gizli bilgiler eklememek önemlidir; çünkü bunlar Admin Center’a erişimi olan herkes tarafından görülebilir. Adları da, yıllar süren büyümenin ardından bile yönetilebilir kalacak kadar kısa tutmak gerekir.

Bir adlandırma kuralını ekipte nasıl tutarlı biçimde uygularsınız?

Yalnızca kağıt üzerinde kalan bir kural pratikte etkisiz kalır. Bu nedenle Microsoft, kuralları bir stil kılavuzunda belgelemeyi ve bunları tek tek kişilerin aklında bırakmak yerine SharePoint sayfası gibi ortak bir başvuru noktası üzerinden maker topluluğuyla paylaşmayı önerir. Daha büyük kuruluşlar için ayrıca, kod incelemelerini destekleyen ve Flow’ların belgelenmiş en iyi uygulamalardan (adlandırma kuralları dahil) saptığını otomatik olarak algılayan Power CAT Toolkit bulunur. Böylece giderek daha fazla departman kendi otomasyonlarını oluştursa bile, büyüyen Flow ortamları üzerindeki kontrol korunur.

Şirketiniz için bir adlandırma kuralı oluşturmak istiyor ancak sıfırdan başlamak istemiyorsanız, Power Automate konusunda NordFlux yönetişim kurallarını tanımlamanızda ve bunları çalışan süreçler kesintiye uğramadan mevcut Flow’lara aktarmanızda size destek olur.

Sık Sorulan Sorular

“Trg_” veya “Act_” gibi ön ekleri gerçekten her bileşen için kullanmam gerekir mi?

Hayır, Microsoft ön ekleri kategorilendirme için olası bir seçenek olarak belirtir, zorunluluk olarak değil. Önemli olan, ekibiniz içinde bir şema üzerinde anlaşmanız ve ister ön eklerle, ister CamelCase ister alt çizgilerle olsun, bunu tutarlı biçimde uygulamanızdır.

Adlandırma kuralımızı en iyi nerede belgelerim?

Microsoft, tüm oluşturuculara açık merkezi bir yer önerir; örneğin maker topluluğunuz için Power Platform hub’ı işlevi gören bir SharePoint sayfası. Önemli olan, somut araçtan çok, her yeni kişinin ilk kendi Flow’unu oluşturmadan önce kuralları bulmasıdır.

Aynı adlandırma kuralı çözümlerdeki bağlantı başvuruları için de geçerli mi?

Evet, bağlantı başvuruları teknik olarak basit bağlantılardan farklı çalışsa da, aynı açıklayıcı adlandırma kurallarına uymalıdır. Bağlanan hizmeti ve kullanım amacını belirten bir ad, özellikle çözümleri geliştirme, test ve üretim ortamı arasında taşırken yardımcı olur.

Adlandırma kuralları ile ortam stratejisi nasıl bağlantılıdır?

İki konu iç içe geçer: “Prod-US-Finance-Payroll” gibi ortamlar için net bir adlandırma kuralı, hangi Flow’ların ve bağlantıların hangi ortama gidebileceğini hemen gösterir. Bu netlik olmadan, en iyi Flow adlandırması bile daha büyük bir yönetişim yapısına anlamlı biçimde yerleştirilemez.

Yalnızca birkaç Flow varken bile bir adlandırma kuralı işe yarar mı?

Evet, çoğu kuruluşta Flow sayısı planlanandan daha hızlı arttığı için, erken benimsenen bir kural kendini amorti eder. Yüzlerce mevcut Flow’u sonradan yeniden adlandırmak, en baştan basit bir kuralı tutarlı biçimde uygulamaktan çok daha zahmetlidir.