پاور BI ایمبیڈڈ: آپ کی درخواست میں تجزیات شامل کرنا

ہر SaaS ایپلیکیشن کو آخر کار تجزیات کی ضرورت ہوتی ہے۔ صارفین ڈیش بورڈز چاہتے ہیں جو ان کے استعمال کے پیٹرن، کارکردگی کی پیمائش اور کاروباری نتائج کو ظاہر کرے۔ شروع سے ایک حسب ضرورت تجزیاتی تہہ بنانا --- چارٹنگ لائبریریاں، ڈیٹا پائپ لائنز، کیشنگ، برآمدی فعالیت، ڈرل ڈاؤن تعاملات --- انجینئرنگ کی کوششوں اور جاری دیکھ بھال کے 6-12 مہینے لگتے ہیں۔ پاور BI ایمبیڈڈ ایک متبادل پیش کرتا ہے: انٹرپرائز-گریڈ تجزیاتی صلاحیتیں براہ راست آپ کی ایپلیکیشن میں سرایت شدہ، مائیکروسافٹ کے بنیادی ڈھانچے کی مدد سے۔

پاور BI ایمبیڈڈ صرف "صفحہ پر iframe ڈالنا" نہیں ہے۔ یہ آپ کی اپنی درخواست کے UI میں انٹرایکٹو، محفوظ، کثیر کرایہ دار تجزیات کے تجربات فراہم کرنے کا ایک مکمل پلیٹ فارم ہے۔ آپ کے گاہک ایسے تجزیات کے ساتھ تعامل کرتے ہیں جو آپ کے پروڈکٹ کے مقامی نظر آتے ہیں اور محسوس کرتے ہیں جب کہ آپ Power BI کے بالغ نظری انجن، DAX کیلکولیشن لیئر، اور ڈیٹا کنیکٹیویٹی انفراسٹرکچر کا فائدہ اٹھاتے ہیں۔

یہ گائیڈ آپ کی درخواست میں پاور BI کو شامل کرنے کے لیے فن تعمیر، تصدیقی ماڈلز، کثیر کرایہ دار سیکیورٹی، صلاحیت کی منصوبہ بندی، SDK انضمام، اور قیمتوں کے تعین کے تحفظات کا احاطہ کرتا ہے۔ اگر آپ ایمبیڈڈ اینالیٹکس کے نفاذ کا منصوبہ بنا رہے ہیں، تو آرکیٹیکچر گائیڈنس اور ڈیولپمنٹ سپورٹ کے لیے ہماری Power BI ایمبیڈڈ اینالیٹکس سروسز کو تلاش کریں۔

اہم ٹیک ویز

• پاور BI ایمبیڈڈ دو منظرناموں کو سپورٹ کرتا ہے: "اپنے صارفین کے لیے ایمبیڈ کریں" (ایپ کے پاس ڈیٹا ہے) اور "آپ کی تنظیم کے لیے ایمبیڈ کریں" (صارف کا ڈیٹا ہے)
• کثیر کرایہ دار SaaS ایپلی کیشنز کے لیے سروس پرنسپل تصدیق کی سفارش کی جاتی ہے۔ ماسٹر صارف اکاؤنٹس آسان ہیں لیکن ناکامی کے واحد پوائنٹس بناتے ہیں۔
• قطار کی سطح کی سیکیورٹی (RLS) مشترکہ ڈیٹاسیٹس میں کرایہ داروں کے ڈیٹا کی تنہائی کو یقینی بنانے کا بنیادی طریقہ کار ہے۔
• Fabric F SKUs ایمبیڈڈ منظرناموں کے لیے سب سے زیادہ سرمایہ کاری کی صلاحیت فراہم کرتے ہیں، ترقی کے لیے F2 سے شروع
• JavaScript SDK گہرے پروگرامی کنٹرول کو قابل بناتا ہے: فلٹرز لگانا، ایونٹس کیپچر کرنا، نیویگیشن کو کنٹرول کرنا، اور تھیمز کو حسب ضرورت بنانا
• صلاحیت کا سائز ہم وقت استعمال کرنے والے، استفسار کی پیچیدگی، اور ڈیٹا کے حجم پر منحصر ہے --- نہ صرف صارف کی کل تعداد
• حسب ضرورت تھیمز اور پوشیدہ کروم ایمبیڈڈ رپورٹس کو آپ کی ایپلیکیشن کے مطابق محسوس کرتے ہیں۔

---

ایمبیڈنگ منظرنامے: صارفین بمقابلہ تنظیم

اپنے صارفین کے لیے سرایت کریں (ایپ کا ڈیٹا ہے)

"ایپ کا ڈیٹا مالک ہے" کا منظرنامہ SaaS ایپلیکیشنز کے لیے بنیادی استعمال کا معاملہ ہے۔ آپ کی ایپلیکیشن سروس پرنسپل یا ماسٹر یوزر اکاؤنٹ کا استعمال کرتے ہوئے پاور BI کے ساتھ تصدیق کرتی ہے، ایمبیڈ ٹوکن تیار کرتی ہے، اور ایمبیڈڈ رپورٹ آپ کے آخری صارفین کو پیش کرتی ہے۔ آپ کے صارفین کبھی بھی Power BI کے ساتھ براہ راست تعامل نہیں کرتے ہیں اور انہیں Power BI لائسنس کی ضرورت نہیں ہے۔

فن تعمیر کا بہاؤ:

1. آپ کا صارف آپ کے تصدیقی نظام کا استعمال کرتے ہوئے آپ کی درخواست میں لاگ ان ہوتا ہے۔
2. آپ کی ایپلیکیشن کا بیک اینڈ پاور BI REST API کو کال کرتا ہے تاکہ ایک ایمبیڈ ٹوکن تیار کیا جا سکے، جو اس گاہک کے لیے مخصوص رپورٹ، ڈیٹاسیٹ، اور RLS رول تک محدود ہے۔
3. بیک اینڈ ایمبیڈ ٹوکن اور ایمبیڈ یو آر ایل کو فرنٹ اینڈ پر لوٹاتا ہے۔
4. فرنٹ اینڈ پاور BI JavaScript SDK کو ایمبیڈ ٹوکن کے ساتھ شروع کرتا ہے اور رپورٹ کو ایک نامزد کنٹینر عنصر میں پیش کرتا ہے۔
5. ایمبیڈ ٹوکن قابل ترتیب مدت (پہلے سے طے شدہ 1 گھنٹہ) کے بعد ختم ہو جاتا ہے، اور آپ کی ایپلیکیشن اسے شفاف طریقے سے تازہ کر دیتی ہے۔

اہم خصوصیات:

• صارفین کو پاور BI پرو یا پریمیم فی صارف لائسنس کی ضرورت نہیں ہے۔
• تمام صلاحیت کے اخراجات فیبرک/ایمبیڈڈ SKUs کے ذریعے آپ (درخواست فراہم کنندہ) برداشت کرتے ہیں۔
• RLS اور پروگرامی فلٹرنگ کے ذریعے صارفین جو کچھ دیکھتے ہیں اس پر آپ کا مکمل کنٹرول ہے۔
• توثیق مکمل طور پر آپ کی درخواست کے تصدیقی نظام کے اندر ہے۔
• ایمبیڈ ٹوکن مخصوص نمونے تک محدود، وقتی رسائی فراہم کرتے ہیں۔

یہ وہ ماڈل ہے جو ISVs، SaaS پلیٹ فارمز، اور اندرونی پورٹلز کے ذریعے استعمال کیا جاتا ہے جہاں تجزیاتی صارف کو یہ معلوم نہیں ہونا چاہیے کہ پاور BI بنیادی ٹیکنالوجی ہے۔

اپنی تنظیم کے لیے سرایت کریں (صارف کا ڈیٹا)

"صارف کے پاس ڈیٹا" کا منظر نامہ پاور BI مواد کو اندرونی ایپلی کیشنز میں سرایت کرنے کے لیے ہے جہاں صارفین کے پاس پہلے سے پاور BI لائسنس (پرو یا پی پی یو) موجود ہیں۔ ایمبیڈڈ تجربہ صارف کی اپنی پاور BI شناخت اور اجازتوں کا استعمال کرتا ہے۔

فن تعمیر کا بہاؤ:

1. صارف آپ کی درخواست کے ذریعے Azure AD کے ساتھ تصدیق کرتا ہے۔
2. آپ کی درخواست صارف کی جانب سے OAuth 2.0 کا استعمال کرتے ہوئے بہاؤ کی جانب سے ایک رسائی ٹوکن حاصل کرتی ہے۔
3. ایپلیکیشن ایمبیڈ کنفیگریشن حاصل کرنے کے لیے صارف کے ٹوکن کے ساتھ Power BI REST API کو کال کرتی ہے۔
4. رپورٹ صارف کی پاور BI کی مکمل اجازتوں کے ساتھ پیش کی جاتی ہے۔

اہم خصوصیات:

• ہر صارف کے پاس پاور BI پرو یا پریمیم فی صارف لائسنس ہونا ضروری ہے۔
• صارفین اپنی پاور BI اجازتوں اور RLS اسائنمنٹس پر مبنی مواد دیکھتے ہیں۔
• کسی اضافی فیبرک/ایمبیڈڈ صلاحیت کی ضرورت نہیں ہے (صارف کا پرو/پی پی یو لائسنس مختص استعمال کرتا ہے)
• ایپلیکیشن ڈویلپر کے لیے کم کنٹرول، صارف کے لیے زیادہ خودمختاری
• آسان فن تعمیر لیکن زیادہ فی صارف لائسنسنگ لاگت

یہ ماڈل عام طور پر انٹرانیٹ پورٹلز، شیئرپوائنٹ انضمام، اور اندرونی ایپلی کیشنز کے لیے استعمال ہوتا ہے جہاں صارفین کے پاس پہلے سے پاور BI لائسنس موجود ہیں اور انہیں اپنی موجودہ رسائی کی اجازتیں برقرار رکھنی چاہئیں۔

منظرناموں کے درمیان انتخاب کرنا

بیرونی صارفین کو نشانہ بنانے والی زیادہ تر SaaS ایپلیکیشنز کے لیے، "ایپ ڈیٹا کا مالک ہے" صحیح انتخاب ہے۔ اس گائیڈ کا بقیہ حصہ بنیادی طور پر اس منظر نامے پر مرکوز ہے۔

---

توثیق: سروس پرنسپل بمقابلہ ماسٹر صارف

سروس پرنسپل توثیق

سروس پرنسپل Azure AD ایپلیکیشن کی شناخت ہے جس پر پاور BI پروگرام کے مطابق وسائل تک رسائی کے لیے بھروسہ کرتا ہے۔ پروڈکشن ایمبیڈڈ ایپلی کیشنز کے لیے یہ تجویز کردہ توثیق کا طریقہ ہے۔

سیٹ اپ کی ضروریات:

1. Azure AD میں درخواست رجسٹر کریں۔
2. درخواست کے لیے کلائنٹ کا راز یا سرٹیفکیٹ بنائیں۔
3. ایک Azure AD سیکیورٹی گروپ بنائیں اور اس میں سروس پرنسپل کو شامل کریں۔
4. پاور BI ایڈمن پورٹل میں، ٹیننٹ سیٹنگز > ڈویلپر سیٹنگز کے تحت سیکیورٹی گروپ کے لیے سروس پرنسپل رسائی کو فعال کریں۔
5. سروس کو آپ کے ایمبیڈڈ مواد پر مشتمل مخصوص پاور BI ورک اسپیس تک بنیادی رسائی فراہم کریں۔

فائدے:

• کسی مخصوص صارف اکاؤنٹ پر کوئی انحصار نہیں (ناکامی کے ایک نقطہ کو ختم کرتا ہے)
• کلائنٹ کے راز اور سرٹیفکیٹ بغیر سروس میں رکاوٹ کے گھمائے جا سکتے ہیں۔
• سروس پرنسپلز کو مخصوص کام کی جگہوں تک محدود کیا جا سکتا ہے (کم سے کم استحقاق)
• Azure کی میزبانی شدہ ایپلی کیشنز میں Azure AD کے زیر انتظام شناخت کے ساتھ کام کرتا ہے۔
• اعلی سیکورٹی کے لیے سرٹیفکیٹ پر مبنی توثیق کی حمایت کرتا ہے۔

حدود:

• "My Workspace" (ذاتی ورک اسپیس) تک رسائی حاصل نہیں کر سکتے
• کچھ ایڈمن APIs کو کال نہیں کر سکتے
• کچھ جدید خصوصیات کے لیے Azure AD Premium کی ضرورت ہے۔
• ابتدائی سیٹ اپ ماسٹر صارف سے زیادہ پیچیدہ ہے۔

ماسٹر یوزر کی توثیق

ایک ماسٹر صارف پاور BI پرو یا PPU لائسنس کے ساتھ ایک باقاعدہ Azure AD صارف اکاؤنٹ ہے جسے آپ کی درخواست Power BI کے ساتھ تصدیق کرنے کے لیے استعمال کرتی ہے۔ ایپلیکیشن ایمبیڈ ٹوکن بنانے کے لیے اس صارف کے بطور لاگ ان ہوتی ہے۔

فائدے:

• آسان ابتدائی سیٹ اپ (ایک صارف بنائیں، لائسنس تفویض کریں، ورک اسپیس تک رسائی فراہم کریں)
• ایڈمن APIs سمیت پاور BI کی تمام خصوصیات تک رسائی حاصل کر سکتے ہیں۔
• Azure AD درخواست کے اندراج کی ضرورت نہیں ہے۔

نقصانات:

• ناکامی کا واحد نقطہ: اگر صارف کا اکاؤنٹ مقفل ہے، پاس ورڈ ختم ہوجاتا ہے، یا MFA متحرک ہوجاتا ہے، تو آپ کی ایپلیکیشن تجزیات تک رسائی کھو دیتی ہے۔
• مشروط رسائی کی پالیسیوں کا استعمال نہیں کر سکتا جن کے لیے انٹرایکٹو سائن ان کی ضرورت ہوتی ہے۔
• پاس ورڈ کی گردش کے لیے ایپلیکیشن اپ ڈیٹ کی ضرورت ہے۔
• مشین کے عمل کے لیے انسانی اکاؤنٹس کا استعمال نہ کرنے کے سیکیورٹی کے بہترین عمل کی خلاف ورزی کرتا ہے۔
• صارف اکاؤنٹ کے لیے لائسنس کی قیمت

تجویز: تمام پروڈکشن تعیناتیوں کے لیے سروس پرنسپل توثیق کا استعمال کریں۔ ماسٹر صارف اکاؤنٹس تصور کے ثبوت اور ترقی کے ماحول کے لیے قابل قبول ہیں جہاں سادگی قابل اعتبار سے زیادہ اہمیت رکھتی ہے۔

ٹوکن جنریشن اور مینجمنٹ

تصدیق کے طریقہ کار سے قطع نظر، آپ کی ایپلیکیشن Power BI REST API کے ذریعے ایمبیڈ ٹوکنز تیار کرتی ہے۔ ٹوکن ایمبیڈڈ سیشن کی اجازتوں کو شامل کرتا ہے۔

** ایمبیڈ ٹوکن تحفظات:**

• ٹوکن لائف ٹائم: ڈیفالٹ 1 گھنٹہ ہے، 24 گھنٹے تک کنفیگر کیا جا سکتا ہے۔ مختصر زندگی زیادہ محفوظ ہوتی ہے لیکن زیادہ بار بار ریفریش کی ضرورت ہوتی ہے۔
• ٹوکن اسکوپ: ہر ٹوکن کا دائرہ مخصوص رپورٹس، ڈیٹاسیٹس اور ورک اسپیس تک ہے۔ ممکنہ حد تک تنگ دائرہ پیدا کریں۔
• RLS شناخت: قطار کی سطح کی سیکیورٹی استعمال کرتے وقت، RLS شناخت (صارف کا نام اور کردار) ٹوکن میں سرایت کر دی جاتی ہے۔ اس طرح آپ کرایہ دار کی تنہائی کو یقینی بناتے ہیں۔
• ٹوکن ریفریش: آپ کے فرنٹ اینڈ کو ٹوکن کی میعاد ختم ہونے کی نگرانی کرنی چاہیے اور اس کے ختم ہونے سے پہلے نئے ٹوکن کی درخواست کرنی چاہیے۔ JavaScript SDK اس کے لیے واقعات فراہم کرتا ہے۔

ٹوکن جنریشن کی مثال کا بہاؤ:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken
{
    "datasets": [{"id": "dataset-guid"}],
    "reports": [{"id": "report-guid"}],
    "identities": [{
        "username": "[email protected]",
        "roles": ["TenantRole"],
        "datasets": ["dataset-guid"]
    }]
}

جواب میں ایمبیڈ ٹوکن اور میعاد ختم ہونے کا ٹائم اسٹیمپ شامل ہے۔ آپ کا بیک اینڈ اس ٹوکن (میعاد ختم ہونے کا احترام کرتے ہوئے) کیش کرتا ہے اور اسے تصدیق شدہ فرنٹ اینڈ کی درخواستوں پر پیش کرتا ہے۔

---

ملٹی ٹیننٹ رو لیول سیکیورٹی

کیوں RLS ایمبیڈڈ کے لیے اہم ہے۔

کثیر کرایہ دار SaaS ایپلیکیشن میں، متعدد صارفین کا ڈیٹا اکثر ایک ہی Power BI ڈیٹاسیٹ میں رہتا ہے۔ قطار کی سطح کی سیکیورٹی کے بغیر، ایک ایمبیڈ ٹوکن ڈیٹاسیٹ میں موجود تمام ڈیٹا تک رسائی فراہم کرتا ہے۔ RLS اس بات کو یقینی بناتا ہے کہ ہر صارف صرف اپنا ڈیٹا دیکھتا ہے، حالانکہ بنیادی ڈیٹا سیٹ کا اشتراک کیا گیا ہے۔

RLS کثیر کرایہ دار ایمبیڈڈ منظرناموں کے لیے اختیاری نہیں ہے۔ کرایہ داروں کی تنہائی میں ناکامی ڈیٹا کی خلاف ورزی ہے۔ RLS کو بنیادی حفاظتی کنٹرول کے طور پر ڈیزائن کریں، نہ کہ سوچ سمجھ کر۔

جامد RLS

Static RLS Power BI ڈیسک ٹاپ میں DAX اظہار کا استعمال کرتے ہوئے فکسڈ فلٹر کے اصولوں کی وضاحت کرتا ہے۔ ہر کردار میں ٹیبل فلٹرز کا ایک سیٹ ہوتا ہے جو اس بات کو محدود کرتا ہے کہ کون سی قطار نظر آتی ہے۔

مثال:

صارفین کی میز پر اس فلٹر کے ساتھ ایک "TenantRole":

[TenantId] = USERNAME()

ایمبیڈ ٹوکن تیار کرتے وقت، آپ کی ایپلیکیشن USERNAME() ویلیو کو موجودہ کرایہ دار کے شناخت کنندہ پر سیٹ کرتی ہے۔ DAX فلٹر تمام سوالات کو قطاروں تک محدود کرتا ہے جہاں TenantId مماثل ہے۔

سٹیٹک RLS سادہ اور کارآمد ہے کرایہ داروں کی سیدھی تنہائی کے لیے۔ یہ اچھی طرح سے کام کرتا ہے جب:

• کرایہ دار کی تنہائی ایک واحد کالم (TenantId) پر مبنی ہے جو تعلقات کے ذریعے پھیلتی ہے۔
• تمام کرایہ دار ایک ہی رپورٹ کا ڈھانچہ دیکھتے ہیں، صرف ان کے ڈیٹا میں فلٹر کیا گیا ہے۔
• RLS کرداروں کی تعداد چھوٹی اور مستحکم ہے۔

متحرک RLS

Dynamic RLS DAX اظہارات کا استعمال کرتا ہے جو صارف کی شناخت کی بنیاد پر استفسار کے وقت جانچتے ہیں۔ یہ ہر کرایہ دار کے لیے الگ الگ کردار بنائے بغیر سیکیورٹی کے مزید پیچیدہ منظرناموں کو قابل بناتا ہے۔

عام متحرک RLS پیٹرن:

USERPRINCIPALNAME() پیٹرن:

[Email] = USERPRINCIPALNAME()

ایمبیڈ ٹوکن موثر شناخت کے صارف نام کو صارف کے ای میل پر سیٹ کرتا ہے۔ فلٹر سیکیورٹی میپنگ ٹیبل میں ای میل کالم سے ملتا ہے۔

سیکیورٹی ٹیبل پیٹرن: صارفین کو اس ڈیٹا تک میپنگ کرنے کے لیے ایک وقف شدہ سیکیورٹی ٹیبل بنائیں جس تک وہ رسائی حاصل کر سکتے ہیں:

RLS فلٹرز لگائیں جو اس سیکورٹی ٹیبل میں شامل ہوتے ہیں تعلقات کے ذریعے آپ کی فیکٹ ٹیبل میں۔ یہ پیٹرن کرایہ دار کے اندر صارف کی سطح کی اجازتوں کی حمایت کرتا ہے، نہ صرف کرایہ دار کی سطح کی تنہائی۔

RLS ٹیسٹنگ اور توثیق

قبل از تعیناتی ٹیسٹنگ:

1. پاور BI ڈیسک ٹاپ میں، نمونہ صارف ناموں کے ساتھ ہر RLS کردار کو جانچنے کے لیے "View As" کا استعمال کریں۔
2. تصدیق کریں کہ میزوں کے درمیان کراس فلٹرنگ RLS کی حدود کا احترام کرتی ہے۔
3. ٹیسٹ ایج کیسز: مماثل قطاروں والے صارفین (خالی رپورٹیں دیکھیں، غلطیاں نہیں)، متعدد کرداروں والے صارفین، اور فلٹر کالموں میں کالعدم اقدار۔
4. تصدیق کریں کہ ALL() یا REMOVEFILTERS() کا استعمال کرتے ہوئے DAX اقدامات RLS کو نظرانداز نہیں کرتے ہیں (انہیں نہیں کرنا چاہیے، لیکن تصدیق کرنی چاہیے)۔

پروڈکشن کی توثیق:

• اپنی تعیناتی پائپ لائن کے حصے کے طور پر RLS ٹیسٹنگ کو خودکار بنائیں
• ٹیسٹ کرایہ دار کی شناخت کے لیے ایمبیڈ ٹوکنز بنائیں اور استفسار کے نتائج متوقع ڈیٹا سے مماثل ہیں۔
• صلاحیت میٹرکس میں RLS بائی پاس کی کوششوں کے لیے مانیٹر کریں (غیر معمولی استفسار کے نمونے، غیر متوقع ڈیٹا والیوم)
• RLS کنفیگریشنز کے سہ ماہی سیکورٹی جائزے کا انعقاد کریں۔

---

صلاحیت کا سائز اور فیبرک SKUs

سمجھنے کی صلاحیت

پاور BI ایمبیڈڈ کو وقف صلاحیت کی ضرورت ہے --- آپ کے ایمبیڈڈ کام کے بوجھ کے لیے محفوظ وسائل کی گنتی کریں۔ صلاحیت کی پیمائش کیپسٹی یونٹس (CUs) میں کی جاتی ہے، جو رپورٹس پیش کرنے، استفسارات کو انجام دینے، اور ڈیٹاسیٹس کو تازہ کرنے کے لیے دستیاب پروسیسنگ پاور کا تعین کرتی ہے۔

صلاحیت فی صارف نہیں ہے۔ یہ کمپیوٹ کا ایک مشترکہ پول ہے جس سے آپ کے تمام ایمبیڈڈ سیشن حاصل کرتے ہیں۔ اس کا مطلب ہے کہ قیمتوں کا تعین ہم آہنگی اور استفسار کی پیچیدگی کے ساتھ ہوتا ہے، نہ کہ صارف کی کل تعداد کے ساتھ۔

فیبرک F SKU کے اختیارات

Microsoft Fabric F SKUs پاور BI ایمبیڈڈ صلاحیت کے لیے موجودہ قیمتوں کا ماڈل ہیں۔ انہوں نے لیگیسی A SKUs کو ایک زیادہ لچکدار، توقف کے قابل ماڈل سے بدل دیا۔

| SKU | CUs | زیادہ سے زیادہ میموری (GB) | سمورتی سوالات | کے لیے بہترین | |------|------|------|---------| | F2 | 2 | 3 | ~5 | ترقی اور جانچ | | F4 | 4 | 3 | ~10 | چھوٹے پیمانے پر پائلٹ | | F8 | 8 | 6 | 25 | چھوٹی پیداوار ( 100 ایک ساتھ صارفین تک) | | F16 | 16 | 12 | 50 | درمیانی پیداوار ( 100-300 ہم وقت صارفین) | | F32 | 32 | 24 | ~100 | بڑی پیداوار (~300-800 ہم وقت صارفین) | | F64 | 64 | 55 | ~200 | انٹرپرائز (~800-2000 ہم وقت صارفین) | | F128 | 128 | 110 | ~400+ | اعلی پیمانے پر انٹرپرائز |

اہم نوٹ:

• ایک ساتھ استعمال کنندگان کا مطلب کل صارفین نہیں ہے۔ اس کا مطلب ہے کہ صارفین اسی لمحے فعال طور پر استفسار کر رہے ہیں۔ ایک عام تناسب یہ ہے کہ کل صارفین کا 5-10% کسی بھی وقت ایک ساتھ ہوتے ہیں۔
• یہ اندازاً رہنمائی کے نمبر ہیں۔ اصل صلاحیت کافی حد تک استفسار کی پیچیدگی، ماڈل سائز، اور فی رپورٹ کے تصور کی گنتی پر منحصر ہے۔
• استعمال میں نہ ہونے پر F SKUs کو موقوف کیا جا سکتا ہے (پرانی P SKUs کے برعکس)، جو ترقی اور موسمی کام کے بوجھ کے لیے قیمتی ہے۔
• F64 اور اس سے اوپر میں پاور BI پریمیم خصوصیات (صفحہ بندی رپورٹس، AI، تعیناتی پائپ لائنز) بغیر کسی اضافی لائسنس کی قیمت کے شامل ہیں۔

صلاحیت کے سائز کا طریقہ کار

مرحلہ 1: ایک ساتھ استعمال کنندگان کا اندازہ لگائیں۔

کنکرنٹ یوزرز = کُل صارفین x چوٹی کنکرنسی ریشو

کاروباری اوقات کے دوران رسائی حاصل کرنے والے SaaS تجزیاتی ڈیش بورڈز کے لیے: 5-10% کنکرنسی ریشو۔ آپریشنل ڈیش بورڈز کے لیے دن بھر اکثر چیک کیا جاتا ہے: 15-25% کنکرنسی ریشو۔ ایونٹ سے چلنے والے ڈیش بورڈز کے لیے (ریئل ٹائم مانیٹرنگ، الرٹس): 30-50% کنکرنسی ریشو۔

مرحلہ 2: استفسار کی پیچیدگی کا اندازہ لگائیں۔

سادہ رپورٹس (5-10 بصری، بنیادی جمع، واحد حقائق کی میز): 1x بیس لائن۔ درمیانی رپورٹس (10-20 بصری، وقت کی ذہانت، متعدد حقائق کی میزیں): 2-3x بیس لائن۔ پیچیدہ رپورٹس (20+ بصری، پیچیدہ DAX، بڑے ڈیٹا سیٹس، کراس سورس سوالات): 4-6x بیس لائن۔

مرحلہ 3: مطلوبہ صلاحیت کا حساب لگائیں۔

اس SKU کے ساتھ شروع کریں جو اوپر دیے گئے جدول سے آپ کے ہم آہنگ صارف تخمینہ سے میل کھاتا ہے۔ اپنے پیچیدگی کے عنصر سے ضرب کریں۔ اگر نتیجہ SKU کی سمورتی استفسار کی گنجائش سے زیادہ ہے، تو اگلے درجے پر جائیں۔

مرحلہ 4: لوڈ ٹیسٹنگ کے ساتھ توثیق کریں۔

نظریاتی سائز بندی ایک نقطہ آغاز ہے۔ پروڈکشن شروع کرنے سے پہلے، حقیقت پسندانہ ڈیٹا والیوم، استفسار کے نمونوں، اور ہم آہنگی کی سطحوں کے ساتھ لوڈ ٹیسٹنگ کروائیں۔ مائیکروسافٹ اس مقصد کے لیے پاور BI ایمبیڈڈ صلاحیت لوڈ ٹیسٹنگ ٹول فراہم کرتا ہے۔

مرحلہ 5: ترقی کا منصوبہ بنائیں۔

اگلے 6-12 مہینوں میں ترقی کو ایڈجسٹ کرنے کے لیے اپنی موجودہ چوٹی کے اوپر 30-50% ہیڈ روم شامل کریں۔ F SKUs کو ڈاؤن ٹائم کے بغیر اپ گریڈ کیا جا سکتا ہے، تاکہ آپ بتدریج صحیح سائز کر سکیں۔

لاگت کو بہتر بنانے کی حکمت عملی

• **غیر کام کے اوقات کے دوران ترقیاتی صلاحیتوں کو روک دیں۔ F SKUs کو فعال ہونے پر فی سیکنڈ بل کیا جاتا ہے، جب موقوف کیا جاتا ہے تو مفت۔ Azure Automation یا Logic Apps کے ساتھ خودکار توقف/دوبارہ شروع کرنے سے ترقیاتی اخراجات 60-70% تک کم ہو سکتے ہیں۔

• گنجائش بڑھانے سے پہلے ماڈلز کو بہتر بنائیں۔ F8 پر ایک اچھی طرح سے آپٹمائزڈ ماڈل اکثر F32 پر ناقص اصلاح شدہ ماڈل کو پیچھے چھوڑ دیتا ہے۔ کارکردگی کے مسائل پر حساب لگانے سے پہلے ماڈل کی اصلاح میں سرمایہ کاری کریں۔

• بڑے ڈیٹا سیٹس کے لیے جمع کرنے کی میزیں استعمال کریں۔ عام گرانولیریٹیز (روزانہ، ہفتہ وار، ماہانہ) پر ڈیٹا کو پہلے سے جمع کرنا سمری لیول ویژولز کے لیے استفسار کی پروسیسنگ کو 80-90% تک کم کرتا ہے جبکہ تفصیل کے لیے ڈرل ڈاؤن کی صلاحیت کو محفوظ رکھتا ہے۔

• پاور BI REST API کے ذریعے **رپورٹ لیول کیشنگ کو نافذ کریں۔ کبھی کبھار ڈیٹا اپ ڈیٹس والے ڈیش بورڈز کے لیے، کیش شدہ نتائج فی صارف سیشن کی صلاحیت کی کھپت کو کم کرتے ہیں۔

• **مختلف کام کے بوجھ کے لیے الگ صلاحیتوں پر غور کریں۔ انٹرایکٹو سوالات سے ریفریش آپریشنز کو الگ کرنا ریفریش اسپائکس کو صارف کے تجربے کو کم کرنے سے روکتا ہے۔ یہ خاص طور پر اہم ہے اگر آپ کے پاس بڑے ڈیٹا سیٹس ہیں جو کاروباری اوقات کے دوران ریفریش ہوتے ہیں۔

---

JavaScript SDK انٹیگریشن

بنیادی ایمبیڈنگ

Power BI JavaScript SDK (powerbi-client) آپ کی ویب ایپلیکیشن میں Power BI مواد کو سرایت اور کنٹرول کرنے کے لیے پروگرامیٹک انٹرفیس فراہم کرتا ہے۔

انسٹالیشن:

npm install powerbi-client

بنیادی ایمبیڈ فلو:

import * as pbi from 'powerbi-client';

const powerbi = new pbi.service.Service(
    pbi.factories.hpmFactory,
    pbi.factories.wpmpFactory,
    pbi.factories.routerFactory
);

const embedConfig = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: embedToken,
    tokenType: pbi.models.TokenType.Embed,
    settings: {
        panes: {
            filters: { visible: false },
            pageNavigation: { visible: true }
        },
        background: pbi.models.BackgroundType.Transparent,
        layoutType: pbi.models.LayoutType.Custom,
        customLayout: {
            displayOption: pbi.models.DisplayOption.FitToWidth
        }
    }
};

const reportContainer = document.getElementById('report-container');
const report = powerbi.embed(reportContainer, embedConfig);

پروگرامیٹک کنٹرول

SDK ایمبیڈڈ رپورٹ پر وسیع پروگرامیٹک کنٹرول کو ظاہر کرتا ہے:

فلٹرز لگانا:

const filter = {
    $schema: "http://powerbi.com/product/schema#basic",
    target: {
        table: "Sales",
        column: "Region"
    },
    operator: "In",
    values: ["North", "South"],
    filterType: pbi.models.FilterType.BasicFilter
};

await report.setFilters([filter]);

** واقعات کی گرفتاری:**

report.on('loaded', function() {
    console.log('Report loaded successfully');
});

report.on('dataSelected', function(event) {
    const data = event.detail;
    // Handle user selection — navigate to detail page, update other UI, etc.
});

report.on('pageChanged', function(event) {
    const pageName = event.detail.newPage.displayName;
    // Track page navigation in your analytics
});

ٹوکن ریفریش:

report.on('tokenExpired', async function() {
    const newToken = await fetchNewEmbedToken();
    await report.setAccessToken(newToken);
});

نیویگیشن کنٹرول:

// Navigate to a specific page
const pages = await report.getPages();
const targetPage = pages.find(p => p.displayName === 'Revenue Analysis');
await targetPage.setActive();

// Set a specific slicer value
const visuals = await targetPage.getVisuals();
const slicer = visuals.find(v => v.type === 'slicer');
await slicer.setSlicerState({
    filters: [{
        $schema: "http://powerbi.com/product/schema#basic",
        target: { table: "Date", column: "Year" },
        operator: "In",
        values: [2026],
        filterType: pbi.models.FilterType.BasicFilter
    }]
});

کارکردگی کے لیے مرحلہ وار رینڈرنگ

بہت سے بصریوں کے ساتھ پیچیدہ رپورٹس کے لیے، مرحلہ وار رینڈرنگ مندرجہ بالا مواد کو پہلے پیش کر کے سمجھی گئی کارکردگی کو بہتر بناتی ہے:

const embedConfig = {
    // ... standard config
    settings: {
        // ... other settings
        commands: [{
            visualRendered: {
                phase: 1,
                visualNames: ['revenue-kpi', 'trend-chart', 'summary-table']
            }
        }]
    }
};

report.on('visualRendered', function(event) {
    if (event.detail.phase === 1) {
        // Hide loading spinner, show report
        document.getElementById('loading').style.display = 'none';
    }
});

---

حسب ضرورت تھیمز اور برانڈنگ

حسب ضرورت تھیمز کیوں اہم ہیں۔

ڈیفالٹ پاور BI بصری مائیکروسافٹ کا رنگ پیلیٹ اور اسٹائل استعمال کرتا ہے۔ سرایت شدہ سیاق و سباق میں، یہ آپ کی درخواست کے ساتھ بصری عدم مطابقت پیدا کرتا ہے۔ حسب ضرورت تھیمز ایمبیڈڈ اینالیٹکس کو آپ کے پروڈکٹ کے ڈیزائن سسٹم کے ساتھ سیدھ میں لاتے ہیں، جس سے تجربے کو بولٹ کرنے کی بجائے مقامی محسوس ہوتا ہے۔

تھیم JSON ڈھانچہ

پاور BI تھیمز کو JSON فائلوں کے طور پر بیان کیا گیا ہے جس میں رنگوں، فونٹس، بصری ڈیفالٹس، اور عنصر کی اسٹائلنگ پر کنٹرول ہے:

{
    "name": "MyApp Theme",
    "dataColors": [
        "#2563EB", "#7C3AED", "#059669", "#D97706",
        "#DC2626", "#0891B2", "#4F46E5", "#65A30D"
    ],
    "background": "#FFFFFF",
    "foreground": "#1E293B",
    "tableAccent": "#2563EB",
    "textClasses": {
        "callout": {
            "fontSize": 28,
            "fontFace": "Inter, sans-serif",
            "color": "#0F172A"
        },
        "title": {
            "fontSize": 14,
            "fontFace": "Inter, sans-serif",
            "color": "#1E293B"
        },
        "header": {
            "fontSize": 12,
            "fontFace": "Inter, sans-serif",
            "color": "#475569"
        },
        "label": {
            "fontSize": 11,
            "fontFace": "Inter, sans-serif",
            "color": "#64748B"
        }
    },
    "visualStyles": {
        "*": {
            "*": {
                "border": [{
                    "color": {"solid": {"color": "#E2E8F0"}},
                    "radius": 8
                }],
                "background": [{
                    "color": {"solid": {"color": "#FFFFFF"}},
                    "transparency": 0
                }]
            }
        }
    }
}

تھیمز کو پروگرام کے لحاظ سے لاگو کرنا

تھیمز کو ایمبیڈ وقت پر لاگو کیا جا سکتا ہے یا متحرک طور پر تبدیل کیا جا سکتا ہے (ڈارک موڈ سپورٹ کے لیے مفید):

// Apply theme at embed time
const embedConfig = {
    // ... standard config
    theme: { themeJson: customThemeJson }
};

// Switch theme dynamically (e.g., light/dark mode toggle)
await report.applyTheme({ themeJson: darkThemeJson });

پاور BI کروم کو چھپا رہا ہے۔

مکمل طور پر مقامی ظاہری شکل کے لیے، پاور BI کے بلٹ ان UI عناصر کو چھپائیں اور انہیں اپنے ایپلیکیشن کنٹرولز سے تبدیل کریں:

const settings = {
    panes: {
        filters: { visible: false },      // Hide filter pane
        pageNavigation: { visible: false } // Hide page tabs
    },
    bars: {
        actionBar: { visible: false },     // Hide action bar
        statusBar: { visible: false }      // Hide status bar
    },
    background: pbi.models.BackgroundType.Transparent,
    visualRenderedEvents: true
};

پھر اپنی درخواست کے UI فریم ورک میں حسب ضرورت نیویگیشن، فلٹرنگ، اور ایکسپورٹ کنٹرولز بنائیں۔ جب صارفین آپ کے حسب ضرورت کنٹرولز کے ساتھ تعامل کرتے ہیں تو پروگرام کے مطابق فلٹرز لگانے، صفحات تبدیل کرنے اور برآمدات کو متحرک کرنے کے لیے JavaScript SDK کا استعمال کریں۔

اس نقطہ نظر کے لیے مزید ترقی کی کوشش کی ضرورت ہے لیکن ایک ہموار تجربہ پیدا کرتا ہے جہاں صارف آپ کی ایپلیکیشن کی مقامی خصوصیات اور ایمبیڈڈ Power BI مواد کے درمیان فرق نہیں کر سکتے۔

---

ایمبیڈڈ کے لیے کارکردگی کی اصلاح

فرنٹ اینڈ پرفارمنس

• ** SDK کو سست لوڈ کریں۔** Power BI JavaScript SDK تقریباً 300KB ہے۔ اسے متضاد طور پر لوڈ کریں اور صرف اس صورت میں جب صارف تجزیاتی صفحہ پر تشریف لے جائے۔
• **ایمبیڈ ٹوکن پہلے سے لوڈ کریں۔ ** اس سے پہلے کہ صارف رپورٹ کی درخواست کرے ایمبیڈ ٹوکنز بنائیں۔ اگر آپ کی درخواست کو معلوم ہے کہ صارف ممکنہ طور پر تجزیات (نیویگیشن پیٹرن کی بنیاد پر) دیکھے گا، تو صفحہ کی منتقلی کے دوران ٹوکن کو پہلے سے لوڈ کریں۔
• بوٹسٹریپ ایمبیڈنگ کا استعمال کریں۔ SDK بوٹسٹریپ پیٹرن کو سپورٹ کرتا ہے جو ایمبیڈ ٹوکن کے دستیاب ہونے سے پہلے iframe کو شروع کرتا ہے، جس سے بوجھ کا وقت 200-500ms تک کم ہوجاتا ہے۔

// Bootstrap first (fast — creates iframe immediately)
const report = powerbi.bootstrap(container, { type: 'report' });

// Load later when token is available
const embedConfig = { /* full config */ };
report.load(embedConfig);

• رپورٹ کیشنگ کو لاگو کریں۔ ایک بار رپورٹ لوڈ ہونے کے بعد، iframe اسے میموری میں برقرار رکھتا ہے۔ اگر صارف تشریف لے جاتا ہے اور واپس آتا ہے، تو دوبارہ سرایت کرنے کے بجائے موجودہ iframe کو دوبارہ استعمال کریں۔ اس سے ایک ہی سیشن کے اندر واپسی کے دوروں کے لیے لوڈ ٹائم مکمل طور پر ختم ہو جاتا ہے۔

بیک اینڈ پرفارمنس

• کیشے ایمبیڈ ٹوکنز۔ ایمبیڈ ٹوکن اپنی پوری زندگی کے لیے درست ہیں (پہلے سے طے شدہ 1 گھنٹہ)۔ انہیں ریڈیس یا ان میموری میں کیش کریں اور اسی رپورٹ/شناختی امتزاج کے لیے درخواستوں میں دوبارہ استعمال کریں۔
• بیچ ٹوکن جنریشن۔ اگر صارف کے ڈیش بورڈ میں متعدد ایمبیڈڈ رپورٹس ہیں، تو جنریٹ ٹوکن اینڈ پوائنٹ کی کثیر وسائل کی صلاحیت کا استعمال کرتے ہوئے ایک ہی API کال میں تمام ایمبیڈ ٹوکنز بنائیں۔
• API کی شرح کی حدوں کی نگرانی کریں۔ Power BI REST API میں فی سروس پرنسپل کی شرح کی حد ہوتی ہے۔ 429 جوابات کی نگرانی کریں اور ایکسپونینشل بیک آف کو لاگو کریں۔ اعلی درجے کی ایپلی کیشنز کے لیے، متعدد سروس پرنسپلز پر بوجھ تقسیم کریں۔

رپورٹ ڈیزائن برائے ایمبیڈڈ

ایمبیڈڈ استعمال کے لیے تیار کردہ رپورٹس کو بصری پیچیدگی پر کارکردگی کو ترجیح دینی چاہیے:

• بصری کو 8-12 فی صفحہ تک محدود کریں (ہر بصری ایک الگ سوال پیدا کرتا ہے)
• جب ممکن ہو تو DirectQuery کے بجائے امپورٹ موڈ استعمال کریں (10-100x تیز)
• مناسب گرانولریٹی پر پہلے سے جمع ڈیٹا
• لینڈنگ پیجز پر پیچیدہ DAX اقدامات سے گریز کریں (ان کو ڈرل تھرو تفصیلات کے لیے محفوظ کریں)
• متحرک حسابات کے بجائے پہلے سے گنتی شدہ نظاروں کے لیے بک مارکس کا استعمال کریں۔
• رپورٹ کے لوڈ اوقات کو آپ کی متوقع ہم آہنگی کی سطح پر جانچیں، نہ کہ صرف واحد صارف

ایمبیڈڈ اینالیٹکس کو نافذ کرنے والی تنظیموں کے لیے، ECOSIRE پہلے دن سے بہترین کارکردگی کو یقینی بنانے کے لیے آرکیٹیکچر کنسلٹنگ اینڈ ڈیولپمنٹ سروسز فراہم کرتا ہے۔

---

ایمبیڈڈ کے لیے حفاظتی تحفظات

ٹوکن سیکیورٹی

ایمبیڈ ٹوکنز پاور BI مواد تک رسائی فراہم کرتے ہیں۔ ان کے ساتھ حساس اسناد کے طور پر سلوک کریں:

• کلائنٹ سائڈ سورس کوڈ یا URL پیرامیٹرز میں ایمبیڈ ٹوکن کو کبھی بھی ظاہر نہ کریں۔
• سرور کی طرف ٹوکنز بنائیں اور انہیں تصدیق شدہ API اینڈ پوائنٹس کے ذریعے فراہم کریں۔
• مختصر ترین عملی ٹوکن لائف ٹائم استعمال کریں (زیادہ تر ایپلیکیشنز کے لیے پہلے سے طے شدہ 1 گھنٹہ مناسب ہے)
• طویل المدت ٹوکن بنانے کے بجائے ٹوکن ریفریش منطق کو لاگو کریں۔
• بے ضابطگیوں کے لیے ٹوکن جنریشن پیٹرن کی نگرانی کریں (غیر معمولی حجم، غیر متوقع رپورٹ IDs)

کرایہ دار کی تنہائی کی توثیق

کثیر کرایہ دار کی درخواستوں کے لیے، کرایہ دار کی تنہائی کو مسلسل درست کریں:

• خودکار ٹیسٹ جو کرایہ دار A کے لیے ایمبیڈ ٹوکن تیار کرتے ہیں اور یہ تصدیق کرتے ہیں کہ کرایہ دار B کا ڈیٹا قابل رسائی نہیں ہے۔
• کراس کرایہ دار ڈیٹا تک رسائی کی کوششوں کا پتہ لگانے کے لیے لاگنگ کا سوال
• باقاعدہ آر ایل ایس کنفیگریشن آڈٹ (آر ایل ایس رولز کو پاور BI ڈیسک ٹاپ میں تبدیل کیا جا سکتا ہے اور اتفاقی طور پر کمزور کیا جا سکتا ہے)
• RLS فلٹر کی غلطیوں پر انتباہ (جو غلط کنفیگریشن کی نشاندہی کر سکتا ہے)

نیٹ ورک سیکیورٹی

• Azure AD مشروط رسائی کا استعمال کرتے ہوئے معلوم IP رینجز تک Power BI REST API رسائی کو محدود کریں۔
• آن پریمیسس ڈیٹا ذرائع سے گیٹ وے کنکشن کے لیے پرائیویٹ اینڈ پوائنٹس کا استعمال کریں۔
• تمام API کالز کو ٹریک کرنے اور ٹوکن جنریشن کو ایمبیڈ کرنے کے لیے پاور BI ایڈمن پورٹل میں آڈٹ لاگنگ کو فعال کریں۔
• اپنی ایپلیکیشن کے ڈومین میں iframe ایمبیڈنگ کو محدود کرنے کے لیے مواد کی حفاظتی پالیسی کے ہیڈر لاگو کریں

---

اکثر پوچھے گئے سوالات

10,000 صارفین کے ساتھ SaaS ایپلیکیشن کے لیے Power BI ایمبیڈڈ کی قیمت کتنی ہے؟

لاگت کا انحصار ہم آہنگی صارفین پر ہے، نہ کہ کل صارفین پر۔ اگر آپ کے 10,000 صارفین میں سے 5% عروج پر ہیں (500 ہم وقت استعمال کنندگان)، تو آپ کو تقریباً 8,200 ڈالر فی مہینہ کے حساب سے F32 صلاحیت کی ضرورت ہوگی (جیسی ادائیگی کریں)۔ ریزرویشن (1 سال کی وابستگی) کے ساتھ، یہ تقریباً $5,500 فی مہینہ تک گر جاتا ہے۔ رپورٹ کی پیچیدگی، ڈیٹاسیٹ کے سائز اور استعمال کے نمونوں کی بنیاد پر آپ کی اصل قیمت زیادہ یا کم ہو سکتی ہے۔ پائلٹ کے لیے F8 کے ساتھ شروع کریں، حقیقت پسندانہ ہم آہنگی کے ساتھ ٹیسٹ لوڈ کریں، اور اصل پیمائش کی بنیاد پر پیمانہ کریں۔

کیا میں Azure کے بغیر Power BI ایمبیڈڈ استعمال کرسکتا ہوں؟

Power BI ایمبیڈڈ کو Azure AD کی تصدیق کے لیے اور Azure کے ذریعے فراہم کردہ فیبرک/ایمبیڈڈ صلاحیت کی ضرورت ہوتی ہے۔ آپ کی درخواست خود کہیں بھی ہوسٹ کی جا سکتی ہے (AWS, GCP، آن پریمیسس)، لیکن Power BI وسائل Azure میں ہونے چاہئیں۔ سروس پرنسپل یا ماسٹر یوزر اکاؤنٹ Azure AD میں ہونا چاہیے، اور صلاحیت Azure ریسورس ہونی چاہیے۔ ایسی تنظیموں کے لیے جن کا کوئی موجودہ Azure فوٹ پرنٹ نہیں ہے، سیٹ اپ تقریباً 2-4 گھنٹے Azure کنفیگریشن کا کام اور کم از کم جاری Azure مینجمنٹ کو اپنی صلاحیت سے آگے بڑھاتا ہے۔

Power BI ایمبیڈڈ A SKUs، EM SKUs، اور Fabric F SKUs میں کیا فرق ہے؟

A SKUs اصل پاور BI ایمبیڈڈ صلاحیت تھی، جو Azure کے ذریعے فراہم کی گئی تھی۔ EM SKUs Office 365 کے ساتھ اندرونی ایمبیڈنگ کے لیے ایک لائسنسنگ آپشن تھے۔ دونوں کو Fabric F SKUs نے تبدیل کر دیا ہے، جو پاور BI اور فیبرک کے تمام کام کے بوجھ کے لیے ایک متحد صلاحیت کا ماڈل فراہم کرتے ہیں۔ F SKUs فی سیکنڈ بلنگ، موقوف/دوبارہ شروع کرنے کی صلاحیت، اور قیمتوں کا آسان ڈھانچہ پیش کرتے ہیں۔ نئے نفاذ کے لیے، خصوصی طور پر F SKUs استعمال کریں۔ موجودہ A SKU صارفین کو بہتر قیمتوں اور صلاحیتوں کے لیے F SKUs میں منتقلی کا منصوبہ بنانا چاہیے۔

کیا صارفین ایمبیڈڈ رپورٹس سے ڈیٹا ایکسپورٹ کرسکتے ہیں؟

ہاں، لیکن آپ اسے ایمبیڈ کی ترتیبات کے ذریعے کنٹرول کرتے ہیں۔ JavaScript SDK آپ کو فی رپورٹ ایکسپورٹ صلاحیتوں (Export to Excel, PDF, PowerPoint) کو فعال یا غیر فعال کرنے کی اجازت دیتا ہے۔ آپ ایکسپورٹ API کے ذریعے اپنی مرضی کے مطابق برآمدی فعالیت کو بھی نافذ کر سکتے ہیں، جو آپ کو فارمیٹ، لاگو فلٹرز، اور آڈٹ لاگنگ پر زیادہ کنٹرول فراہم کرتا ہے۔ حساس ڈیٹا کے لیے، بلٹ ان ایکسپورٹ کو غیر فعال کریں اور اپنا ایکسپورٹ میکنزم فراہم کریں جو اضافی اجازت کی جانچ اور واٹر مارکنگ کا اطلاق کرتا ہے۔

میں ایمبیڈڈ منظر نامے میں رپورٹ کی ترقی کو کیسے ہینڈل کروں؟

رپورٹ ڈویلپمنٹ معیاری پاور BI ورک فلو کی پیروی کرتی ہے: پاور BI ڈیسک ٹاپ میں رپورٹس بنائیں، ترقیاتی ورک اسپیس پر شائع کریں، نمونہ ایمبیڈ ٹوکن کے ساتھ ٹیسٹ کریں، تعیناتی پائپ لائنوں کے ذریعے پیداوار کو فروغ دیں۔ اہم فرق یہ ہے کہ ایمبیڈڈ رپورٹس کو RLS رویے، ہم آہنگی کے تحت کارکردگی، اسکرین کے سائز میں جوابی ترتیب، اور آپ کی درخواست کے UI کے ساتھ تعامل کے لیے اضافی جانچ کی ضرورت ہوتی ہے۔ ایک CI/CD پائپ لائن قائم کریں جس میں ہر رپورٹ کی تعیناتی کے حصے کے طور پر خودکار RLS توثیق اور کارکردگی ریگریشن ٹیسٹنگ شامل ہو۔