ایجاد دسترسی Dynamic RLS برای  Multidimensional OLAP

ایجاد دسترسی Dynamic Row Level Security برای پروژه Multidimensional OLAP زمانی که نیاز دارید تعداد کاربرهای زیادی به پروژه BI شما دسترسی داشته باشند کاربرد فراوانی دارد.Dynamic Row Level Security With OLAP MDXدر حالت های معمول با تعریف Role و ایجاد Member که از جنس لاگین ویندوزی بودند میتوانستیم به یک یا چند کاربر از طریق Active directory و Domain دسترسی RLS بدهیم. این کار ضریب خطای بالا و از طرفی زمان بر است. راه حل سریع تر و ایمن تر DRLS است.در این مقاله مراحلی که برای این پیاده سازی گذرانده شد رو با شما به اشتراک میگذارم.فرض بر این است که Cub بطور صحیح ایجاد شده و در حال کار کردن است.Cubدر اینجا میخواهیم بر اساس Dimension project کاربران دیتا ها را مربوط به پروژه خود را مشاهده کنند.حالا به دو چیز دیگر نیازمندیم :به یک جدول که Account ها را برای ما مشخص کند.و جدول دیگری که بگوید کدام Account به کدام پروژه دسترسی دارد. این کار با استفاده از رابطه AccountId و ProjectId امکان پذیر است :Resource 1 ----> Project A Resource 1 ----> Project B Resource 1 ----> Project C Resource 2 ----> Project A Resource 2 ----> Project E Resource 3 ----> Project FNew measure and Dimensionباید دقت داشت که جدول Fact / Measure با سطوح دسترسی مد نظر ایجاد و یک Dimension برای Account ها که منبع اصلی فیلتر ما هستند ایجاد نموده.ایده ای که در اینجا وجود دارد این است که در زمان اتصال کاربر ابتدا AccountId او گرفته میشود و بعد گزارش به او نمایش داده میشود.حالا باید رل داینامیک را ایجاد کرد.با باز کردن Solution Explorer و کلیک راست بر روی رل یک رل جدید ایجاد کرده.New roleدرتب data source گزینه read را انتخاب کنیدRead Access sourceدر تب Cub نیز دسترسی ها را به Read داده شود.Read access cubبرای همه Dimension ها نیز دسترسی Read را تنظیم داده شود.و مهمترین اتفاق و جادوی این تکنیک در اینجا اتفاق میافتد :اگر به دیاگرام دقت کرده باشید ارتباط بین حساب ها با دسترسی پروژه ها و بعد از پروژه ها به ترتیب است.حالا اگر بتوانیم حساب محدودی را معرفی کنیم آن وقت بر اساس دسترسی آن حساب به پروژه ها، فقط پروژه هایی فیلتر میشود که آن حساب به آن دسترسی دارد و بقیه جداول و ارتباطات نیز از همین روند استفاده میکنند. چرا که جدول پروژه به Fact های ما متصل است و از این مسیر این دیتاها محدود میشود.حال Dimension Data را باز میکنیم :Dimension Dataحالا Attribute Hierarchy مورد نظر که ProjectName هست را انتخاب میکنیم.حالا برروی تب Advanced رفته و در فیلد اول کوئری MDX زیر را مینویسیم:NONEMPTY( [Project].[Project Name].[Project Name].MEMBERS, ( [Measures].[Project ID], StrToMember(“[Users].[Resource NT Account].&[” + username() + “]”) ) )برای تست این عملکرد در Visual studio میتوان خط NT Account را میتوان تغییر داد و نتیجه را بررسی کرد. [Users].[Resource NT Account].&[ad\amirhossein]و برای مشاهده بدون فیلتر میتوان یک رل متناسب با رل دیگری داشت که قاعدتا کوئری MDX مجزایی نیاز دارد. وارد بخش Cub شده، تب Browser را زده از Security Context گزینه Current User را انتخاب نمود.Set userاگر شما دسترسی ادمین داشته باشید همه دیتاها را مشاهده میکنید.View sample data by adminحالا دسترسی را به یک مدیر پروژه محدود میکنیم و انتظارباید داشته باشیم که دیتاهای متناسب با آن حساب فیلتر بشوند.برای این کار کد MDX را تغییر و بجای amirhossein از حسابی به نام account استفاده میکنم.Set roleاین بار بجای current user از role استفاده کرده و رل dynamic را انتخاب کرده.View sample data by roleخوب این نتیجه نشان میدهد که با تغییر رخ داده در MDX متغییری که در جدول داشتیم میتواند مدیریت کند که کدام حساب چه دیتایی را نمایش دهد.اکنون اگر این گزارش را در بستر هایی نظیر اکسل و گزارش سازها ارائه دهید فقط نیاز دارید که اطلاعات حساب کاربری برای user ها در جدول users قرار داده و هر فردی دیتای مورد نظر خود را مشاهده کند.برگرفته از مقاله Diego Pereira