Posts Tagged ‘ Power Apss ’
Bu yazıda Dynamics 365 Finance and Operations toplu iş geçmişini(Batch job history) periyodik olarak nasıl silebileceğinizi anlatacağım. Bunun için standartta olan bir temizle toplu işini kullanacağım.
Modules > System Administration > Periodic tasks > Batch job history clean-up (custom) yolunu kullanarak sınıfı çalıştırıyoruz.
Resim-1
Bu yazıda SysOperation kullanarak Dynamics 365 Finance and Operations için yeni bir toplu iş (Batch Job) nasıl oluşturulur anlatmaya çalışacağım. SysOperation RunBaseBatch’in daha gelişmiş hali diyebiliriz. Birçok farklı kullanımı var. Bu örnekte normal toplu iş olarak kullanımını anlatacağım. Yapısına gelecek olursak SysOperation MVC (Model–View–Controller) design pattern’ı kullanır. Bu yapının temel sınıfları şunlardır:
• Service: Servis sınıfı SysOperationServiceBase sınıfından türetilir. İşlemin yapıldığı sınıftır. Kodlarımız bu sınıfta olmalı.
• Data Contract: Özellikleri (attributes) tanımladığımız model sınıfıdır. Diyalogdan veri almak için DataContractAttribute attribute kullanılır.
• Controller: Kontrol sınıfı SysOperationServiceController sınıfından türetilir. Toplu işle ilgili bilgileri tutar. Diyalog ve progress bar gibi.
• UI Builder: UI Builder sınıfı SysOperationAutomaticUIBuilder sınıfından türetilir ve diyaloglara daha gelişmiş ara yüzler sağlamak için kullanılır.
Bu örnekte ilk 3 sınıfı kullanarak RunBaseBatch ile yaptığımız örneğin aynısı yapacağım. Öncelikle yeni bir proje oluşturuyorum.
Resim-1
Bu yazıda Dynamics 365 Finance and Operations için yeni bir toplu iş (Batch Job) nasıl oluşturulur anlatmaya çalışacağım. RunBaseBatch kullanarak bir örnek oluşturacağım. İleriki yazılarımda SysOperation ile de örnekler vereceğim. Toplu iş nedir ona bakalım. Bir işi farklı sunucuda ve belli zamanda istersek tekrarlayan şekilde çalıştırmaya yarayan bir alt yapı diyebiliriz. En basit örneği vereyim. Merkez bankası her gün kurları belli saatte açıklıyor. Sizin bu değerleri alıp sisteme kaydetmeniz gerekiyor. Bunun için bir sınıf yazdınız ve bu sınıf servise bağlanıyor ve değerleri alıyor. Ancak bunun her gün aynı saatte tetiklenmesi lazım. İşte burada toplu iş devreye giriyor ve size bu ayarları yapma imkânı veriyor.
Bu örnekte çok basit bir sınıf oluşturup çalıştıracağız. Öncelikle yeni bir proje oluşturuyorum.
Resim-1
Dynamics 365 Finance and Operations Segregation of Duties Nedir?
Segregation of Duties görev ayrılığı olarak çevriliyor. Şöyle izah etmeye çalışayım. İki kritik görevi(Duty) aynı kişide toplanmasın istiyorsunuz örneğin fatura işleme ve ödeme çıkma gibi iki görevin aynı kişide olmaması gerekiyor. Binlerce kişinin çalıştığı bir firmadasınız ve bunu takip etmek belli bir aşamada mümkün olmuyor işte tam burada SoD devreye giriyor. Duty üzerinden yaptığınız bir tanım size bu tip durumlar için uyarı veriyor ve kontrol etme imkânı sağlıyor.
Önceki yazılarda kullandığımız güvenlik nesnelerini kullanarak bir örnek yapalım. Security Configuration formunu açıyoruz.
Resim-1
Segregation of duties sekmesinden Segregation of duties rules butonuna tıklıyoruz. Bu form direk menüde de var. Resim-9’da görebilirsiniz.
Resim-2
Açılan formda henüz kayıt yok New ile bir tane kayıt oluşturalım.
Resim-3
Bir isim veriyoruz ve iki tane Duty seçmemiz gerekiyor. Ben örnek iki Duty seçtim. Dikkat ettiğim tek konu bu iki Duty hangi rolde kullanılıyor biliyorum. Örneği gösterebilmek için ihtiyacım olacak. Tabi siz iş ihtiyacına göre bu tanımı yapacaksınız.
Resim-4
Kaydettikten sonra test kullanıcıma geliyor. Şu anda olan rolden dolayı FD Müşteri listeleme görevi ekli. Yeni bir rol ekleyip Customer Invoicing içeren bir rol seçiyorum. Ekle dediğimde bir çakışma oluştuğu uyarısı geliyor. Eğer Yes dersem benim için bir çözüm kaydı oluşturacak.
Resim-5
Oluşan kayıtta bu işlemin bilgileri var. Allow Assigment ile atamayı kabul edebilirim.
Resim-6
Kabul edersem aslında kuralı ezmiş oluyoruz bu yüzden bir açıklama soruyor. Girdikten sonra rolü eklemiş olduk. İstersek engelleyebilirdik.
Resim-7
Yeni bir SoD oluşturduğunuzda bu kurala uymayan durumlar var mı diye kontrol edebilirsiniz. Benim kurala uymayan bir durum var ama ona bir ezme kaydı oluşturduk bu yüzden burada gelemdi.
Resim-8
Oluşan kayıtları Resim-9’daki menüden takip edebilirsiniz.
Resim-9
Bu yazıda Segregation of Duties nedir kısaca anlatmaya çalıştım. Çok güzel bir özellik olmakla birlikte hala çok eksiği var. Örneğin sadece Duty ile çalışıyor ama Role atan direk Privilege’lar için bir çözüm yok. Role eklerken soruyor ama sonrasında değişen görev içeriklerini kontrol eden bir mekanizması yok. Kullanmak mümkün özellikle Duty haricinde yetki tanımı yapmaz Duty’lerinizi doğru bir mantıkta oluşturursanız çok kolay kullanabilirsiniz. Bu özelliğe hala yatırım yapılmaya devam ediliyor kısa sürede çok daha gelişmiş bir hala geleceğini düşünüyorum.
Selamlar.
www.fatihdemirci.net
TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, Segregation of Duties, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apss, Power Virtual Agents, Dynamics 365 nedir, Dynamics 365 ERP, Dynamics 365 CRM
Bu yazıda Dynamics 365 Finance and Operation uygulamasında herhangi bir nesneye nasıl yetki tanımı yapılır anlatmaya çalışacağım. Bunu çok kullanmanızı tavsiye etmiyorum. Ne kadar çok ayrıntıya girerseniz güvenliği yönetmek o kadar zor olacaktır. Ancak tabi bazı durumlarda bu ihtiyaç olacaktır. Bu durumlarda gördüğüm bir yanlışta bunu güvenlik altyapısıyla değil de kodla çözmek oluyor. Kesinlikle güvenlikle ilgili işler için kod yazmayın ilk etapta hızlı çözümmüş gibi görünür ama ilerde çok baş ağrısı olur. Desteği ve sonra gelen taleplerin karşılanması çok zorlaşır. Bu yazıda önceki yazılarımda kullandığım proje ile devam edeceğim. Bir test kullanıcısına Müşteriler formu yetkisi vermiştik. Artık formu açıp verilerini görebiliyor. Varsayalım Customer group alanı bu kullanıcıda görünmesin istendi. Bunu nasıl yapabiliriz görelim.
Resim-1
Yeni bir Privilege ekliyorum.
Resim-2
Privilage altında Form Control Permissions kısmı sağ tıklayıp New Form diyoruz.
Resim-3
Name kısmından CustTable formunu seçiyoruz.
Resim-4
CustTable’a sağ tıklayarak yeni nesne oluştur diyoruz ve yetki vermek istediğimiz nesnenin adını yazıyoruz. Grant asıl işi yapan yer No Access ile bu Privilege’e sahip olanların bu nesneyi görmemelerini sağlıyoruz. Burada lookup ta çıkmayabilir önemli değil direk ismi yazabilirsiniz. Bu tanımlar yeterli olmayacak yetki tanımı yapacağımız nesnenin bir özelliğini değiştirmemiz gerekiyor.
Resim-5
Bu değişikliği yapabilmek için nu aşamada formumuz için bir extension oluşturmamız gerekiyor.
Resim-6
Oluşturduğumuz Extension’ı açıyoruz. Yetki vermek istediğimiz nesneyi bulup özelliklerinden NeedPermission’ı Manuel’e çekiyoruz. Yani bu nesnenin yetkisini biz yöneteceğiz demiş oluyoruz. Extension’ı ilk adım olarak yapmak daha mantıklı aslında.
Resim-7
Sonrasında önceki yazılarımızda kullandığımız Duty’e Privilege’i ekliyoruz.
Resim-8
Projemizi kaydedip derliyoruz ve sadece projemiz için DB senkronizasyonunu çalıştırıyoruz. Bundan sonra test kullanıcımızla giriş yapıp Müşteriler formunu açtığımızda Customer Group alanının görünmediğini göreceksiniz.
Resim-9
Bu yazıda alt seviye bir nesneye nasıl yetki verilir anlatmaya çalıştım. Çok basit halledilebiliyor ama çok fazla alt seviye yetki tanımı yaparsanız işin içinden çıkmak çok zor oluyor mümkün olduğunca giriş noktasından yetki vermeye çalışın.
Selamlar.
www.fatihdemirci.net
TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, Security, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apss, Power Virtual Agents, Dynamics 365 nedir, Dynamics 365 ERP, Dynamics 365 CRM
Bu yazıda Dynamics 365 Finance and Operations uygulaması üzerinden güvenlik nesnelerinin faklı ortamlara nasıl taşıyabileceğinizi anlatacağım. Bu işlemi yapmak için benim tercihim Visual Studio içinden nesneleri oluşturup klasik geliştirme sürecini takip etmek. Ancak bunun için yazılımcıya ihtiyaç var ve her zaman güvenlik işini yazılımcılar yapmıyor. Bu yüzden aynı işlemi arayüzden de yapabiliyoruz. Aslında bu klasik bir Export Import işlemi. Şimdi gelin nasıl yapıldığına bakalım.
Önceki yazımda oluşturduğum bir role var onu kullanacağım. System Administration-> Security Configuration formunu açıyorum.
Resim-1
Dışarı aktarmak istediğim rolü seçip Data->Export diyorum.
Resim-2
Biz xml dosyası oluşturuyor. İstediğiniz bir yere kaydedebilirsiniz.
Resim-3
XML’i biraz incelemekte fayda var neler export etmişsiniz daha net görebiliyorsunuz.
Resim-4
Export işlemi bu kadar aslında şimdi Import edebilmek için öncelikle bu rolü silelim.
Resim-5
Silinen veya import edilen nesneler Unpublished Objects tabına düşüyorlar buradan yayınladığınızda işlem gerçekleşmiş oluyor. Silmenin tamamlanması için Publish All diyoruz.
Resim-6
Aynı menüden Import diyoruz.
Resim-7
Açılan penceren Export ettiğimiz dosyayı seçiyoruz.
Resim-8
Seçimle birlikte import işlemi gerçekleşiyor. Nesnelerinin yine Unpublished Objects’e düşüyor. Burada faklı nesnelerde geldi bunun sebebini araştırdım Export ederken ilişkili nesneler buraya geliyor diyorlar. Çok mantıklı gelmedi ama Publish All demek gerekiyor. Bundan sonra Rol listesine bakarsanız sildiğimiz rolün geldiğini görebilirsiniz.
Resim-9
Bu yazıda kısaca güvenlik nesnelerinin uygulama üzerinden nasıl Export Import yapılabileceğini anlattım. Burada dikkat etmek gereken bir husus var. Eğer güvenlik nesneleri yeni geliştirilmiş bir uygulamaya aitse önce bu nesnelerin taşınması lazım. Yoksa zaten hatalı işlem yapmış olursunuz.
Selamlar.
www.fatihdemirci.net
TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, Securty Export Import, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apss, Power Virtual Agents, Dynamics 365 nedir, Dynamics 365 ERP, Dynamics 365 CRM
Bu yazıda Dynamics 365 Finance and Operations geliştirme ortamı üzerinden yaznı Visual Studio2dan nasıl yetki nesneleri oluşturulur anlatmaya çalışacağım. Bir önceki Dynamics 365 Finance and Operations Arayüzünden Yetki Tanımı Nasıl yapılır? isimli yazımda arayüzden yetki nesnelerinin nasıl oluşturulduğunu anlatmıştım. O yazıda da söylediğim gibi benim tercihim yetkinin geliştirme ortamından oluşturulması. Birkaç sebebi var en önemlisi geliştirme ortamından oluşturulan nesneler versiyon kontrole dahil edilebiliyor bu sayede direk paketinizde olacaklar ve istediğiniz ortama taşınası geliştirmenizle birlikte olacak yönetmesi daha kolay diye düşünüyorum.
Bir önceki yazımda yaptığım örneğin aynısını şimdi Visual Studio üzerinden yapacağım. Test kullanıcımda sadece System user rolü var.
Resim-1
Bu yazıda Dynamics 365 Finance and Operations uygulaması üzerinden güvenlik nesnelerinin faklı ortamlara nasıl taşıyabileceğinizi anlatacağım. Bu işlemi yapmak için benim tercihim Visual Studio içinden nesneleri oluşturup klasik geliştirme sürecini takip etmek. Ancak bunun için yazılımcıya ihtiyaç var ve her zaman güvenlik işini yazılımcılar yapmıyor. Bu yüzden aynı işlemi arayüzden de yapabiliyoruz. Aslında bu klasik bir Export Import işlemi. Şimdi gelin nasıl yapıldığına bakalım.
Önceki yazımda oluşturduğum bir role var onu kullanacağım. System Administration-> Security Configuration formunu açıyorum.
Resim-1
Bu yazıda Dynamics 365 Finance and Operations güvenlik altyapısını (security architecture) anlatmaya çalışacağım. Çok beğendiğim bir docs makalesi var onu referans alıp konuları toparlamaya çalışacağım. Güvenlik altyapısını anlamak çok önemli. Günümüz projelerinde güvenlik ve yetkileri yönetmek çok zahmetli bir süreç olabiliyor. İhtiyaçları doğru yönetebilmek için altyapıyı ve güvenlik araçlarının özellik, yetenek ve kısıtlarını iyi bilmek gerekiyor. Bu makalede aşağıdaki konulara değineceğim. Türkçeleştirmedim. Bazen terimlerde anlam kayması oluyor o yüzden açıklamayı daha doğru buldum.
• Security architecture
• Role-based security
• Duties
• Privileges
• Permissions
• Authentication
• Authorization
• Auditing
Finance and Operations uygulaması role-based security yapısını kullanır. Yetkiler role verilir kullanıcılara direk yetki verilmez. Kullanıcılara roller atanır. Hiçbir rolü olmayan kullanıcının sistemde hiçbir yetkisi yoktur. Admin rolü atanan kullanıcı tüm yetkilere sahip olur. Daha doğrusu hiçbir yetki kısıtlanmasına tabi olmaz. Role-based security Resim-1’de görüldüğü gibi hiyararşik bir yapıdır.
Resim-1
Bu yazıda Dynamics 365 Finance and Operations için yeni kullanıcılar nasıl tanımlanır anlatmaya çalışacağım. Eğer test ve canlı sisteme kullanıcı eklemek istiyorsanız genelde Azure Active Directory’den içeri aktarmayı kullanırsınız. Eğer kendi geliştirme makineniz için bir test kullanıcısı oluşturmak istiyorsanız yeni kullanıcı oluşturabilirsiniz. Şimdi ikisine de bakalım.
Öncelikle System Administration->Users formunu açıyoruz. Buraya Admin hakkı olan bir kullanıcı ile giriş yapmanız gerekiyor. Eğer bu bir geliştirme ortamı ise zaten kurulum yaptığınız hesaba bu hak geliyor. Önceki yazılarımda anlatmıştım.
Resim-1
| Pts | Sal | Çar | Per | Cum | Cts | Paz |
|---|---|---|---|---|---|---|
| « Eyl | ||||||
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | |
