به عنوان بخشی از کار GA برای ExecuteQueries REST API، یک عملکرد Power Automate جدید برای اجرای پرسوجوها در برابر مجموعه داده‌های Power BI ارائه کردیم. این عمل یک تجربه ساده با کد پایین/بدون کد را به کاربران BI ارائه می دهد که می خواهند وظایف و فرآیندهای تکراری و پیش پا افتاده را ساده کنند. شما می توانید به راحتی فضای کاری و مجموعه داده مورد نظر را در رابط کاربری انتخاب کنید، پرس و جوی DAX خود را در جعبه متن پرس و جو قرار دهید، و به طور خودکار حذف کنید! خودشه! نیازی نیست در مورد REST API چیزی بدانید. حتی برای شروع نیازی به دانستن DAX ندارید زیرا می توانید با استفاده از آنالیز عملکرد، درخواست ها را مستقیماً از Power BI Desktop کپی کنید. اقدام جدید ما برای اجرای پرسوجوها در برابر مجموعه داده‌های Power BI، سناریوهای کاملاً جدید سلف سرویس BI را در Power Automate باز می‌کند!
مجموعه داده های Power BI نشان دهنده یک سرمایه گذاری قابل توجه و دارایی حیاتی است. سازمان‌ها در حال حاضر از مجموعه داده‌های مشترک و تایید شده برای حمایت از کارکنان اداری و تصمیم‌گیرندگان خود از طریق داده‌های انتخاب‌شده، منطق تجاری تأیید شده و تجزیه و تحلیل قابل اعتماد استفاده می‌کنند. این مجموعه داده‌ها پایه و اساس تجسم‌های داده‌های تعاملی و صفحه‌بندی‌شده غنی را فراهم می‌کنند که بینش‌های تجاری را ارائه می‌دهند که باعث موفقیت می‌شود. اما در مورد گردش کار و سایر فرآیندهای تجاری خودکار چطور؟ اغلب، سازمان‌ها باید چرخ را در اینجا دوباره اختراع کنند، زیرا استفاده مستقیم از مجموعه داده‌ها در این زمینه‌ها بسیار سخت است. شما باید یک توسعه دهنده باشید، باید کد بنویسید، باید خدمات وب و API های REST را بدانید، باید برنامه ها را در Azure Active Directory ثبت کنید، باید کتابخانه های مشتری را بارگیری کنید و غیره. بیایید این موانع را برداریم! شما در حال حاضر داده های نظارتی، منطق تجاری تأیید شده، معیارهای تحلیلی قابل اعتماد را دارید. کاربران شما قبلاً گزارش های Power BI فوق العاده ای را در بالای مجموعه داده های شما ایجاد می کنند. به آنها اجازه دهید از همان مجموعه داده های تایید شده و قابل اعتماد در جریان های ابری سلف سرویس استفاده کنند. بیایید بازده سرمایه گذاری را در مجموعه داده های Power BI که قبلاً دارید به حداکثر برسانیم!
هدف از این پست وبلاگ این است که به شما کمک کند تا بر اساس سه سناریو زیر شروع به اجرای پرس و جوها در برابر مجموعه داده ها در Power Automate کنید:
صادرات داده ها به فایل های csv. این یک سناریوی محدود است زیرا ExecuteQueries REST API نتایج پرس و جو را به 100000 ردیف یا 1000000 مقدار در هر پرس و جو (هر کدام که ابتدا با آن مواجه می شود) و تعداد پرس و جوها را به 120 در دقیقه محدود می کند. ما هیچ برنامه ای برای افزایش این محدودیت ها نداریم. بنابراین، اگر باید نتایج پرس و جو را صادر کنید، مقادیر داده را قابل مدیریت نگه دارید.
آزمایش مجموعه داده های Power BI. عملکرد جدید Power Automate این کار را به یک پیاده روی شاد در پارک تبدیل می کند. در یک جدول با موارد آزمایشی بخوانید، ردیف به ردیف را تکرار کنید، یک پرس و جو از پیش تعریف شده را اجرا کنید، نتایج برگشتی را با نتایج مورد انتظار مقایسه کنید، کار انجام شده است! و اگر می‌خواهید امنیت سطح ردیف (RLS) را آزمایش کنید، هر پرس‌وجو می‌تواند هویت یک حساب کاربری متفاوت را جعل کند. توجه داشته باشید که برای استفاده از جعل هویت، باید مجوزهای نوشتن مجموعه داده داشته باشید، که معمولاً اگر مالک مجموعه داده یا عضوی از نقش‌های سرپرست، عضو یا مشارکت‌کننده فضای کاری هستید، دارید.
ایجاد جریان های ابری مبتنی بر BI. یک رویداد در جایی اتفاق می‌افتد، یک رویداد دیگر باید در جای دیگری رخ دهد، و منطق مبتنی بر BI در بین آنها تعیین می‌کند که رویدادها چگونه رخ می‌دهند. Power Automate مجموعه گسترده ای از ماشه ها را ارائه می دهد. شاید شخصی یک فایل csv را در شیرپوینت آنلاین آپلود کرده باشد، رکوردی را در پایگاه داده پشتیبانی مشتری به روز کند، یا یک کلمه کلیدی مهم را توییت کرده باشد، یا شاید یک Power BI Metric یا یک هشدار داده که به تازگی فعال شده است را به روز کند. صدها محرک وجود دارد، اما هر رویدادی که باشد، جریان شما اکنون نیاز به اتخاذ برخی تصمیمات مبتنی بر داده دارد. به‌جای رفتن به سیلوهای داده‌های فردی و دوخت نتایج به‌صورت یک‌باره، اکنون می‌توانید به داده‌های تنظیم‌شده و معیارهای تأییدشده مجموعه داده‌های مشترک و تأییدشده خود که نتایج قابل اعتمادی را به شما می‌دهند تکیه کنید.
خیلی خوب به نظر می رسد که درست باشد؟ کمربند ایمنی خود را ببندید! برای شروع، برای صادر کردن نتایج جستجوی مجموعه داده در قالب csv، می‌توانید با یک جریان راه‌اندازی دستی شروع کنید. یک مرحله جدید اضافه کنید، Power BI را در قسمت جستجوی کانکتور جستجو کنید و Power BI را انتخاب کنید و سپس در برگه Actions، اقدامی را با عنوان Run a query در مقابل یک مجموعه داده انتخاب کنید. توجه داشته باشید که اگر می‌خواهید کل بدنه درخواست JSON را از ابتدا بسازید، یک پرس و جوی JSON در مقابل یک اقدام مجموعه داده نیز وجود دارد، اما اجرای یک پرس و جو در برابر یک عملکرد مجموعه داده بسیار کاربرپسندتر است زیرا می‌توانید پرس و جو DAX خود را مستقیماً در آن جای‌گذاری کنید. جعبه متن Query بدون نیاز به پرداختن به جزئیات JSON. یک پرس و جو ساده DAX می تواند "Evaluate <tablename>" یا شاید "EVALUATE TOPN(100, <tablename>)" باشد تا مطمئن شوید نتایج در محدوده تعداد ردیف باقی می مانند. البته، می توانید با استفاده از ابزار ویرایشگر DAX مورد علاقه خود، عبارات مفیدتر و واقعی تر DAX ایجاد کنید. با استفاده از داده های نمونه AdventureWorks، یک پرس و جو نمونه می تواند "EVALUATE TOPN(100, vFactInternetSalesReason)" باشد. فراموش نکنید که فضای کاری و مجموعه داده مورد نظر را به راحتی از کادرهای لیست موجود در کارت اکشن انتخاب کنید. جریان را ذخیره و آزمایش کنید. نتایج باید مانند تصویر زیر باشد.
مراحل باقیمانده، اقدامات روتین Power Automate هستند. برای خروجی csv باید سطرها را به جدول csv تبدیل کنید. دوباره جریان را ویرایش کنید، یک اکشن جدول ایجاد CSV را مانند تصویر زیر اضافه کنید، و شی محتوایی به نام ردیف‌های جدول اول را از Run a query در برابر یک عملکرد مجموعه داده به عنوان ورودی انتخاب کنید. ردیف های اول جدول حاوی نتایج پرس و جو شما هستند. (در آینده، API ExecuteQueries احتمالاً از پرس‌و‌جوهایی با بلوک‌های ارزیابی متعدد که منجر به ایجاد چندین جدول در پاسخ می‌شود، پشتیبانی می‌کند. با این حال، در حال حاضر، تنها یک Evaluate در هر کوئری پشتیبانی می‌شود.)
عمل ایجاد جدول CSV نتایج پرس و جو را به یک جدول CSV تبدیل می کند و به شما امکان می دهد سرصفحه های ستون را در صورت تمایل سفارشی کنید، اما داده ها را ذخیره نمی کند. برای ذخیره آن، یک اقدام ایجاد فایل را به عنوان مرحله بعدی انتخاب کنید، مانند ایجاد یک فایل در شیرپوینت آنلاین، و خروجی را از عملکرد جدول ایجاد CSV به عنوان محتوای فایل اختصاص دهید. جریان را ذخیره و آزمایش کنید. اسکرین شات زیر نتایج را نشان می دهد. البته، شما همچنین باید یک فایل csv جدید با داده های مورد انتظار در کتابخانه SharePoint هدف خود داشته باشید.
تا اینجای کار خیلی خوبه. با افزودن تصویری Power Automate به گزارش Power BI که یک جریان ابری را راه‌اندازی می‌کند که یک عکس فوری از داده‌های جالب را صادر می‌کند، یک قدم جلوتر برویم، مانند گزارش رویدادهای پشتیبانی روزانه که در تصویر زیر نشان داده شده است. این گزارش حجم تماس های پشتیبانی ساختگی را بر حسب روز و بر اساس منطقه ویژگی همراه با میانگین متحرک 30 روزه تعداد حوادث (خط سبز) و یک آستانه هشدار بر اساس همان میانگین متحرک به اضافه 2 برابر انحراف استاندارد 7 روزه (نور) نشان می دهد. خط بنفش). به هر حال، به دکمه Take Snapshot در گوشه سمت راست بالای گزارش توجه کنید؟ این دکمه به شما امکان می دهد حوادث پشتیبانی آخرین روز را مستقیماً از گزارش خود بر اساس انتخاب های فعلی در گزارش صادر کنید.
برای جزئیات در مورد نحوه افزودن تصویری Power Automate به گزارش Power BI، به مبحث راه اندازی یک جریان ابری از هر گزارش Power BI در مستندات محصول مراجعه کنید. در میان چیزهای دیگر، می توانید فیلدهای داده را به این تصویر اضافه کنید، که سپس به عنوان پارامترهای ورودی به جریان ابری عمل می کنند. به عنوان مثال، گزارش بالا به شما امکان می دهد تعداد حوادث پشتیبانی را بر اساس مناطق ویژگی تقسیم کنید. بنابراین منطقی است که مقادیر Area انتخاب شده را به تصویر منتقل کنیم تا جریان عکس فوری بتواند حوادث پشتیبانی صادر شده را به مناطق انتخاب شده فعلی نیز محدود کند. اگر دستورالعمل‌های موجود در مستندات محصول را برای ایجاد یک جریان ابری جدید دنبال کنید، تصویر Power Automate به طور خودکار پارامترهای ورودی را با کلیک روی دکمه On Power BI سیم‌کشی می‌کند. شما فقط باید پارامترهای ورودی را از روی دکمه On Power BI در متن جستجوی Run a query در برابر یک عملکرد مجموعه داده دریافت کنید. زیر نقطه شروع متن پرس و جو است.
تعریف کردن
VAR selectedAreas = TREATAS({"دسترسی به داده ها"، "جلوهای"}، 'SupportRequests'[Area])
VAR maxAbsDate = MAX('Support Requests'[ایجاد شده])
VAR maxSelDate = CALCULATE(MAX('Support Requests'[Created])، ناحیه های انتخاب شده)
ارزیابی (
SUMMARIZECOLUMNS(
"درخواست های پشتیبانی"[ایجاد شده]،
«درخواست‌های پشتیبانی»[مسئله]،
'Support Requests' [منطقه]،
'Support Requests' [Subarea]،
'Support Requests' [وضعیت]،
"درخواست های پشتیبانی" [مالک]،
FILTER(SupportRequests، maxAbsDate = maxSelDate && 'SupportRequests'[Created] = maxSelDate)
مناطق انتخاب شده
)
)
پرس و جوی DAX بالا، حوادث پشتیبانی را برای دو ناحیه «دسترسی به داده» و «فرونت» بازیابی می کند. به استفاده از تابع TREATAS توجه کنید. همانطور که از تصویر زیر می توانید دریافت کنید، جریان ابری ما باید این مقادیر استاتیک را با یک رشته ساخته شده به صورت پویا جایگزین کند. بر این اساس، جریان ابری ما باید آرایه ای از مقادیر Area ارسال شده از گزارش را به رشته ای تبدیل کند که جریان آن را در متن پرس و جو درج می کند. این یک فرآیند چند مرحله ای است. ابتدا یک اقدام Select اضافه کنید، در کادر From کلیک کنید و شی داده Power BI را انتخاب کنید. سپس با کلیک بر روی دکمه کوچک T برای نقشه، اقدام Select را به حالت متنی تغییر دهید و سپس در کادر متن Map کلیک کنید. شما می توانید مستقیماً شیء محتوای Area را انتخاب کنید، اما بهتر است از عبارتی استفاده کنید که از هر علامت نقل قول در مقادیر با یک علامت نقل قول دوم فرار کند و هر مقدار را در علامت نقل قول قرار دهد. با این کار تبدیل آرایه به رشته ای با فرمت صحیح متعاقبا آسان تر می شود. اگر به درستی فرار کنید و علامت نقل قول بسته شده باشد، فقط باید اعضای آرایه را به هم بپیوندید تا رشته ای را ایجاد کنید که سپس می توانید آن را در پرس و جو وارد کنید. جدول زیر خلاصه مراحل را نشان می دهد.
نتیجه بیان عمل
انتخاب کنید concat(‘”’, replace(item()?[‘Area’], ‘”’, ‘””’), ‘”’) [
"\"دسترسی به داده\"",
"\"جلویی\"",
"\"ورود به سیستم/تایید\"",
"\"REST APIs\"",
"\"سرویس وب\""
]
یک پرس و جو در برابر یک اتصال داده (متغیرها ('مناطق انتخابی')، ', ') "\"دسترسی به داده\", \"جلویی\", \"ورود/تأیید\"، \"REST APIs\" اجرا کنید ، \"سرویس وب\""
و در اینجا جریان ابری حاصل است که کار را انجام می دهد. مراحل ایجاد جدول CSV و ایجاد فایل مشابه نمونه صادرات قبلی است. اکنون می توانید داده ها را مستقیماً از راحتی گزارش Power BI خود صادر کنید! و این تمام چیزی است که در آن وجود دارد.
با این سناریوهای صادرات داده در زیر کمربند، بیایید اکنون توجه خود را به یک سناریوی پویاتر معطوف کنیم: آزمایش مجموعه داده. تصویر زیر جدولی را با چهار ستون نشان می دهد: شناسه آزمایشی، پرس و جو برای اجرا، هویت کاربر در قالب UPN برای جعل هویت، و نتیجه مورد انتظار پرس و جو. راه حل Power Automate ما هر ردیف را تجزیه می کند، پرس و جو را با هویت کاربر مشخص شده اجرا می کند و تأیید می کند که نتیجه برگشتی با نتیجه مورد انتظار مطابقت دارد. اگر نتایج مطابقت نداشت، ایمیلی برای ما ارسال می‌کند.
این بار اجازه دهید یک جریان برنامه ریزی شده برای اجرای روزانه آزمایش های مجموعه داده ایجاد کنیم. ردیف های لیست موجود در یک عملکرد جدول از Excel Online را اضافه کنید، مکان و مسیر صحیح را به کتاب کار اکسل خود مشخص کنید و جدول را با تعاریف تست انتخاب کنید. سپس به هر عمل کنترلی یک Apply اضافه کنید و مقدار شی خروجی پویا را از ردیف های List موجود در یک عملکرد جدول به عنوان ورودی انتخاب کنید. اکنون می‌توانید روی Add an action در Apply to every action card کلیک کنید و اکشن Power BI Run a query در مقابل یک مجموعه داده را انتخاب کنید. فضای کاری و مجموعه داده خود را انتخاب کنید و سپس در کادر متنی Query کلیک کنید تا کادر محاوره ای محتوای پویا نمایش داده شود. DAX Query را به عنوان ورودی متن Query انتخاب کنید. سپس بر روی Show advanced options کلیک کنید، در کادر متنی تقلید کاربر کلیک کنید و User UPN را از گفتگوی Dynamic Content انتخاب کنید. پیکربندی باید مانند تصویر زیر باشد.
تا اینجا، این کار نسبتا آسان است. شاید کمی پیچیده تر، مقایسه نتیجه بازگشتی برای هر پرس و جو با نتیجه مورد انتظار آن باشد. اجازه دهید ابتدا جریان را کامل کنیم و سپس جزئیات را مورد بحث قرار دهیم. به عنوان مرحله بعدی در Apply to every action card، یک کنش کنترل شرط اضافه کنید. برای نمایش کادر گفتگوی محتوای پویا، روی کادر متنی سمت چپ کلیک کنید، روی Expression کلیک کنید و عبارت زیر را وارد کنید: string(outputs('Run_a_query_against_a_dataset')?['body/firstTableRows']?[0]?['[نتیجه]'] ). روی OK کلیک کنید. مقایسه انتخاب شده باید برابر باشد و سپس در کادر سمت راست کلیک کنید و از ردیف های لیست موجود در یک عملکرد جدول، نتیجه مورد انتظار را انتخاب کنید. همانطور که گفته شد، اگر نتیجه برگشتی با نتیجه مورد انتظار مطابقت نداشته باشد، جریان باید یک اعلان ایمیل ارسال کند. فقط یک اقدام Send an email را به کارت If no اضافه کنید و گیرنده، خط موضوع و متن پیام را مشخص کنید. ممکن است مانند تصویر زیر، شناسه آزمون، نتیجه برگشتی، نتیجه مورد انتظار و درخواست آزمایش واقعی را در پیام ایمیل اضافه کنید. جریان را با مقدار اشتباه عمدی در ستون نتیجه مورد انتظار یک مورد آزمایشی آزمایش کنید. شما باید به سرعت یک ایمیل دریافت کنید.
عبارت برای رسیدن به نتایج برگشتی نیاز به توضیح عمیق تری دارد. همه پرس و جوهای آزمایشی از یک تابع SUMMARIZECOLUMNS با نتیجه محاسبه شده در ستونی به نام [نتیجه] استفاده می کنند. طبق کنوانسیون ExecuteQueries REST API، ستون هایی که تغییر نام داده یا در پرس و جو ایجاد می شوند، در داخل پرانتز بازگردانده می شوند. و از آنجایی که محاسبات هر کدام یک مقدار واحد را برمی گرداند، جدول خلاصه عملاً فقط یک ردیف دارد. جدول زیر عبارت string(outputs('Run_a_query_against_a_dataset')?['body/firstTableRows']?[0]?['[Result]']) را به بخش های جداگانه آن تقسیم می کند تا به آن مقدار محاسبه شده برسد.
شرح بیان
outputs('Run_a_query_against_a_dataset') کل پاسخ ExecuteQueries REST API را برای اقدامی به نام Run a query در برابر مجموعه داده دریافت می کند.
خروجی ها(...)؟['body/firstTableRows'] تمام ردیف های مجموعه نتیجه اول را در بدنه پاسخ انتخاب می کند.
خروجی ها(...)؟[…]؟[0] ردیف اول را در تمام ردیف های اولین مجموعه نتیجه انتخاب می کند.
خروجی ها(...)؟[…]؟[0]؟[‘[نتیجه]’] مقدار ستون [نتیجه] سطر اول را انتخاب می کند.
string(…) مقدار انتخاب شده را به رشته تبدیل می کند. این امر ضروری است زیرا نتایج بازگشتی ممکن است از هر نوع داده ای باشد در حالی که ردیف های لیست موجود در یک عملکرد جدول مقدار نتیجه مورد انتظار را به عنوان یک رشته می خواند.
و شما آن را دارید. آزمایش مجموعه داده‌ها می‌تواند بسیار آسان باشد، از جمله جعل هویت در صورتی که مجموعه داده شما دارای RLS باشد!
اما صبر کنید، بیشتر وجود دارد! BI محور جریان ابر! اگر به مثال قبلی «حوادث پشتیبانی روزانه» برگردیم، آیا نمی‌خواهید درباره این افزایش عظیم حجم پشتیبانی در روز اخیر بیشتر بدانید؟ خیلی بیشتر از آستانه! این بخش پشتیبانی در حال چکش خوردن است! چه چیزی باعث این جهش شد؟ و شاید مهمتر از آن، کدام مهندسان پشتیبانی برای کمک به کنترل سریع این وضعیت مناسب هستند؟ یک جریان ابری مبتنی بر BI می تواند این پاسخ ها را حتی قبل از اینکه سؤال بپرسید ارائه دهد!
گزارش رویدادهای پشتیبانی روزانه در حال حاضر آخرین حجم پشتیبانی را اندازه گیری می کند و آستانه هشدار را محاسبه می کند. از بین این دو پارامتر، ما می توانیم یک ماشه برای یک جریان ابری بسازیم. یک گزینه استفاده از هشدار داده است، همانطور که در راهنمای نحوه ادغام هشدارهای داده Power BI با Power Automate در مستندات محصول نشان داده شده است. با این حال، هشدارهای داده از مقادیر آستانه ایستا استفاده می کنند در حالی که آستانه هشدار ما ماهیت پویا دارد زیرا بر میانگین متحرک و انحراف استاندارد متکی است. خوشبختانه، این روزها انتخاب بسیار بسیار بهتری وجود دارد: Power BI Metrics متصل به مقادیر داده! Power BI Metrics نیز می‌تواند در جریان Power Automate ادغام شود، همانطور که در استفاده از Power Automate برای به‌روزرسانی خودکار اهداف در مستندات محصول توضیح داده شده است.
توجه داشته باشید که Power BI Metrics نام جدید ویژگی است که قبلاً به عنوان اهداف شناخته می شد. بازخورد مشتریان در طول پیش نمایش اهداف نشان داد که نام قدیمی باعث سردرگمی شده است. Power BI Metrics در واقع هدف سنجش موفقیت و پیشرفت در یک تلاش یا ابتکار را به طور شهودی تری بیان می کند، اما اقدامات Power Automate مربوط به Metrics همچنان با عنوان "اهداف" شناخته می شوند تا زمانی که تغییرات نام به طور کامل در Power Automate نیز اعمال شود. از آنجایی که تغییرات هنوز به طور کامل انجام نشده است، توضیحات زیر همچنان به اهداف در اقدامات Power Automate اشاره دارد.
مزیت بزرگ Power BI Metrics این است که Metrics متصل به داده می تواند برش دهنده ها و فیلترها را اعمال کند. این باعث می شود که تعریف سطح بالا و زیر متریک بسیار آسان شود. به کارت امتیازی زیر توجه کنید. برای هر ناحیه پشتیبانی یک زیر متریک دارد. این همان اقدامات برای حجم پشتیبانی و آستانه هشدار است، فقط با انتخاب های مختلف برش دهنده منطقه. قوانین وضعیت تعریف می‌کنند که اگر حجم پشتیبانی بیشتر از آستانه هشدار باشد، وضعیت متریک باید در معرض خطر باشد و در غیر این صورت در مسیر قرار دارد. نام متریک ناحیه پشتیبانی را منعکس می‌کند به طوری که می‌توانید اطلاعات وضعیت مهم را فقط از کارت امتیاز جمع‌آوری کنید. بلافاصله می توانید ببینید که قسمت Front-end داغ است.
شناسایی منطقه مشکل‌دار شروع خوبی است، اما ما می‌خواهیم وقتی یک موقعیت بحرانی پیش می‌آید، اطلاعات کاربردی‌تر به دست ما برسد. بر این اساس، جریان ابری ما می‌تواند از ماشه هنگامی که وضعیت یک هدف تغییر می‌کند استفاده کند. با این حال، کارت امتیازی پشتیبانی محصول ما چندین هدف/معیار دارد. خوشبختانه، کانکتور Power BI همچنین شامل یک اقدام چند هدفه است. یک جریان برنامه‌ریزی‌شده می‌تواند از این عمل برای بازیابی همه اهداف/معیارها از کارت امتیازی استفاده کند و سپس فهرست را به اهدافی که وضعیت «در معرض خطر» دارند فیلتر کند. سپس یک Apply برای هر حلقه روی این اهداف/معیارها تکرار می‌شود، مجموعه داده را برای اطلاعات کاربردی مورد نظر جستجو می‌کند، و سپس یک ایمیل اعلان برای مدیر صاحب منطقه پشتیبانی ارسال می‌کند. تصویر زیر جریان و پیام ایمیل حاصل را نشان می دهد.
پرس و جوهای مجموعه داده در تصویر بالا برای صرفه جویی در فضا به اختصار نوشته شده اند. یک پست وبلاگ بعدی ممکن است این سوالات را با جزئیات بیشتری بررسی کند. با این فرض که نام هدف/متریک با نام یک ناحیه پشتیبانی مطابقت دارد، اولین پرس‌وجو در برابر یک اقدام مجموعه داده، نام را به عنوان پارامتر ورودی می‌گیرد و شناسه‌ها یا کلیدهای تمام زیرمنطقه‌های سطح بعدی را که بیشتر از حوزه‌های زیرمجموعه آنها است، برمی‌گرداند. آستانه هشدار این سطح دقیق‌تر از جزئیات در ناحیه پشتیبانی گسترده‌تر به محدود کردن سریعتر علل احتمالی کمک می‌کند. جریان از عبارت زیر برای فرار از علامت نقل قول احتمالی در نام هدف/متریک استفاده می‌کند و سپس دوباره کل رشته را در علامت نقل قول قرار می‌دهد، همانطور که قبلاً برای مثال صادرات داده توضیح داده شد: concat('"', replace(item()[ 'نام']، '"'، '""')، '"').
پرس و جوی دوم کلیدهای زیر ناحیه و نام مدیر پشتیبانی را به عنوان ورودی انتظار دارد. یک اقدام Select آرایه را با کلیدهای زیر ناحیه از پاسخ پرس و جو اول ایجاد می کند، که جریان آن را با استفاده از تابع join() به یک رشته تبدیل می کند، مانند مثال قبلی صادر کردن داده. از سوی دیگر، مدیر پشتیبانی را می‌توان در ویژگی مالک هدف/متریک (آیتم()['owner'] یافت. مجدداً، تمام مقادیر با استفاده از همان تابع concat() مانند قبل خارج شده و در علامت نقل قول قرار می گیرند. این پرسش دوم مهندسان پشتیبانی را که به مدیر مشخص شده گزارش می دهند، جستجو می کند و سپس موارد کار پشتیبانی گذشته و فعلی آنها را تجزیه و تحلیل می کند تا تجربیات و حجم کاری فعلی هر مهندس را خلاصه کند. به عنوان مثال، مهندسی که روی بیش از 20 مورد پشتیبانی در همان زیرحوزه کار کرده است، با تجربه در نظر گرفته می شود، در حالی که مهندسان بدون سابقه کار، تجربه ندارند.
مراحل باقی مانده بدنه پیام ایمیل را جمع آوری می کند. آنها نسبتاً بی حادثه هستند. شما می توانید یک جدول HTML را به همان روشی که جدول CSV قبلا در این پست وبلاگ نشان داده شده است ایجاد کنید. این جریان همچنین تعدادی لوازم آرایشی HTML و CSS را اعمال می کند و سپس پیام ایمیل را در مسیر شادی خود به گیرنده مورد نظر ارسال می کند.
و این برای یک گشت و گذار طوفانی از طریق جریان های Power Automate است که از عملکرد جدید برای اجرای پرس و جوها در برابر مجموعه داده های Power BI استفاده می کند. امیدواریم که نمونه‌های تحت پوشش را مرتبط با سناریوهای خود بیابید و برای شروع بازی سلف سرویس BI خود به سطح بعدی مفید باشد. ادغام ExecuteQueries REST API با Power Automate به کارمندان اداری و تصمیم‌گیرندگان به روش‌های جدید و خلاقانه قدرت می‌دهد و در عین حال بازده سرمایه‌گذاری سازمان را در مجموعه داده‌های مشترک و تایید شده به حداکثر می‌رساند. می‌توانید با ترکیب کردن عبارت Run a Query در برابر عملکرد مجموعه داده با سایر اقدامات Power BI، مانند خواندن، به‌روزرسانی و حتی ایجاد Power BI Metrics، مزایا را بیشتر ترکیب کنید. دیگر نیازی به شکار سیلوهای داده و اختراع مجدد چرخ ندارید. Power BI و Power Automate به شما این امکان را می دهند که از داده های انتخاب شده، منطق تجاری تأیید شده و تجزیه و تحلیل قابل اعتمادی که قبلاً در مجموعه داده های خود دارید استفاده مجدد کنید. شما می توانید جریان های مبتنی بر BI را در عرض چند دقیقه بدون نیاز به نوشتن کد پیچیده ایجاد کنید. چند عبارت اساسی برای دسترسی به خواص و مقادیر رشته فرار تنها چیزی است که لازم است. با سناریوهای سلف سرویس BI در Power Automate، فرآیندهای کسب و کار مبتنی بر بینش شما حتی بیشتر بینش محور می شوند. شما واقعاً می توانید قبل از اینکه سؤالات را بپرسید، پاسخ دریافت کنید. ما امیدواریم که شما نیز مانند ما در مورد این امکانات جدید پیشگامانه هیجان زده باشید. و مثل همیشه، لطفاً هنگام امتحان کردن اقدامات Power BI در Power Automate، بازخورد خود را به ما ارائه دهید. دوست داریم بیشتر از شما بشنویم!