تجاوز واجهة المستخدم: عندما تحتاج مسارات البيانات لديك إلى واجهات برمجة تطبيقات مخصصة

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Moving Beyond the UI: When Your Data Pipeline Needs Custom APIs

مرحبًا بكم مجددًا في المدونة المرافقة للبودكاست! تناولنا في حلقاتنا الأخيرة مطولًا هياكل التحليلات، أما اليوم فنتعمق في مرحلة انتقالية يواجهها كل فريق بيانات ينمو عاجلًا أم آجلًا. إن كنتم قد شعرتم يومًا بأنكم محاصرون بقيود موصلات البيانات القياسية، أو وجدتم أنفسكم تنزّلون التقارير يدويًا فقط لتبقوا الأمور تعمل، فهذه المشاركة موجهة لكم. وللاستماع إلى الحوار الصوتي الكامل حول هذا الموضوع، لا تفوتوا الحلقة ذات الصلة Extend Microsoft Fabric with Custom APIs and Power BI Models.

عندما تبدأ المؤسسات عملها، يبدو تحميل البيانات عبر واجهة المستخدم نعمةً حقيقية. تنقر على بضعة أزرار، وتسجّل الدخول ببيانات اعتمادك، وتُعدّ موصل SaaS قياسيًا، وفجأة تمتلئ لوحات المعلومات بالبيانات. لكن مع توسّع المؤسسة، تتحول مسارات الواجهة المريحة هذه بسرعة إلى اختناقات جامدة. فجأة تجد نفسك أمام أنظمة ERP قديمة، وتطبيقات ويب داخلية، وتدفقات إنترنت الأشياء التي لا تستطيع الموصلات القياسية الوصول إليها أصلًا. إن تجاوز واجهة المستخدم ليس مجرد طموح تقني، بل ضرورة معمارية لضمان أن تبقى مسارات بياناتك موثوقة وآمنة وفورية فعلًا.

الخلاصة السريعة

النهج القائم على الواجهة أولًا ينجح… إلى أن تحتاج إلى مصادر غير مدعومة، أو منطق مخصص، أو أتمتة قائمة على الأحداث.
استخدم واجهات برمجة التطبيقات المخصصة لربط الأنظمة؛ واستخدم نماذج Power BI لتوحيد المنطق والأمان.
صمّم للمصادقة للتطبيق فقط، والحد الأدنى من الصلاحيات، والمراقبة، والنماذج الخاضعة للحوكمة.
ضمّن الرؤى في Teams/SharePoint/التطبيقات لتصل التحليلات إلى المستخدمين حيث يعملون.

متى تتجاوز واجهة المستخدم (محفزات واضحة)

عمليات نقل متكررة لملفات CSV والبريد الإلكتروني وExcel للإبقاء على التقارير قائمة.
نقاط عمياء في الموصلات (أنظمة ERP القديمة، والتطبيقات المخصصة، وتدفقات إنترنت الأشياء).
"لماذا عمر هذا الرقم يومان؟" (تحديث دفعي متأخر، ولا توجد خطافات أحداث).
قواعد أعمال معقدة تمتد عبر أنظمة متعددة ولا تكفي Power Query وحدها لتطبيقها.
مخاوف الامتثال والتدقيق الناتجة عن العمليات الموازية غير الرسمية.

البنى المعمارية المرجعية

1) شبه فوري عبر واجهة برمجة التطبيقات ← Lakehouse ← Power BI

النظام المصدر ← واجهة برمجة تطبيقات مخصصة (للتطبيق فقط) ← دالة استيعاب (Azure Functions/Logic Apps) ← Delta/Parquet في Lakehouse ← نموذج Power BI (التحديث التزايدي/الهجين).
الاستخدام: مؤشرات الأداء التشغيلية، والتحديث كل ساعة، والحجم الكبير للبيانات.

2) خطافات ويب قائمة على الأحداث

خطافات ويب من المصدر ← مستقبِل واجهة برمجة التطبيقات (يتحقق من الرمز المميز، ويضع الأحداث في قائمة الانتظار) ← معالج التدفق (إثراء البيانات وإزالة التكرار) ← جدول Delta وذاكرة تخزين مؤقت لـ KQL ← جدول Power BI من نوع DirectQuery/هجين.
الاستخدام: التنبيهات، ولوحات معلومات الاستثناءات، والعمليات الحية.

3) استعلامات موحدة دون تخزين البيانات

بوابة واجهة برمجة التطبيقات (مع تحديد معدل الطلبات) ← Fabric Dataflows Gen2 / Power BI DirectQuery ← نموذج دلالي (مقاييس خاضعة للحوكمة).
الاستخدام: الأنظمة الحساسة، ومجموعات النتائج الصغيرة، والامتثال الصارم.

مخطط الأمان والمنصة (ابدأ به أولًا)

الهوية: Azure AD للتطبيق فقط (مبدأ الخدمة) أو الهوية المُدارة للحوسبة؛ دون بيانات اعتماد مشتركة للمستخدمين.
الأذونات: حدّد النطاق بمساحات عمل أو مواقع أو واجهات برمجة تطبيقات محددة؛ وتجنّب النطاقات على مستوى المستأجر.
الأسرار: خزّنها في Key Vault؛ وفضّل مصادقة الشهادات على الأسرار العميلة؛ ودوّرها وأنشئ تنبيهات لها.
الشبكة: نقاط نهاية خاصة / مسارات خروج معتمدة؛ واستخدم TLS 1.2 أو أحدث فقط.
حدود المعدل والمرونة: أعد المحاولة مع التراجع التدريجي ومفاتيح idempotency؛ واستخدم قواطع الدائرة لأعطال المصادر العليا.
المراقبة: سجلات مركزية (App Insights/Kusto)، ومعرّفات الارتباط (correlation IDs)، والإشارات الذهبية الأربع (زمن الاستجابة/حركة المرور/الأخطاء/التشبع).
حوكمة البيانات: تصنيف المعلومات الشخصية (PII)، وتسميات الحساسية، وRLS/OLS في النموذج، وتفعيل تتبع المصدر وتحليل الأثر.

نمط المصادقة الأدنى (Python + MSAL)

from msal import ConfidentialClientApplication
import requests, json

TENANT = "contoso.onmicrosoft.com"
CLIENT_ID = "<app-id>"
AUTH = f"https://login.microsoftonline.com/{TENANT}"
SCOPE = ["https://analysis.windows.net/powerbi/api/.default"]
# or Graph: ["https://graph.microsoft.com/.default"]

app = ConfidentialClientApplication(
 CLIENT_ID,
 authority=AUTH,
 client_credential={"private_key": open("cert.pem").read(), "thumbprint": "<thumb>"}
)

token = app.acquire_token_for_client(scopes=SCOPE)
hdr = {"Authorization": f"Bearer {token['access_token']}"}

# Example: list Power BI groups
r = requests.get("https://api.powerbi.com/v1.0/myorg/groups", headers=hdr, timeout=30)
print(r.status_code, r.json())

أنماط نماذج Power BI القابلة للتوسع

Import + Incremental Refresh لجداول الوقائع الكبيرة (مقسّمة حسب التاريخ).
الجداول الهجينة (بيانات البث المباشر الحديثة + البيانات التاريخية) لتحقيق زمن استجابة قريب من الفوري.
DirectQuery للمصادر الخاضعة للتنظيم؛ وخزّن الأبعاد الصغيرة مؤقتاً باستخدام وضع التخزين المزدوج (Dual).
النموذج الدلالي كعقد: ضع منطق الأعمال في المقاييس لا في التقارير؛ واستخدم مجموعات الحسابات لتطبيق الذكاء الزمني؛ وأدر تعريفات مؤشرات الأداء الرئيسية من مكان مركزي.
RLS/OLS للأمان؛ واختبر تركيبات الأدوار؛ ووثّق من يرى ماذا.

تنسيق التحديث: استخدم REST API والكيانات الخدمية (Service Principals) لربط عمليات التحديث بعد وصول البيانات؛ ونبّه عند الإخفاقات؛ ووزّع تحديث النماذج الثقيلة زمنياً.

التضمين حيث يجري العمل

Teams: علامة تبويب تطبيق Power BI، وبطاقات تكيفية (Adaptive Cards) للتنبيهات، وروابط عميقة مع عوامل التصفية.
SharePoint/البوابة: مكونات ويب مؤمّنة مع بقاء أمان مستوى الصف سليماً.
تطبيقات الأعمال (LOB): Power BI Embed (App Owns Data) مع كيان خدمي؛ وخزّن الرموز المميزة (Tokens) على الخادم؛ وطبّق RLS.

حالات استخدام عملية لواجهات برمجة التطبيقات

تكامل ERP/الأنظمة القديمة: وحّد الحقول المخصصة عبر واجهة البرمجة؛ وانقلها إلى Lakehouse؛ ودمجها مع بيانات CRM للحصول على عرض موحد لصحة خط المعالجة.
المطابقات المالية: عتبات واجهة البرمجة ← تشغيل مهام Fabric ← كتابة جدول الفروقات ← تنبيه Teams وبطاقة في لوحة المعلومات.
القياسات التشغيلية/إنترنت الأشياء: Webhook ← قائمة انتظار ← بث إلى Delta؛ وجدول هجين للبطاقات الحية وتنبيهات اتفاقية مستوى الخدمة (SLA).

المزالق الشائعة والحلول

بيانات اعتماد قديمة ← انتقل إلى الشهادات أو الهوية المُدارة مع تدوير آلي.
أذونات واسعة أكثر من اللازم ← قيّدها بحسب مساحة العمل أو الموقع؛ واستخدم تسجيلات تطبيقات منفصلة لكل نطاق.
التقييد (Throttling) ← ترقيم الصفحات من جهة الخادم، وطلبات GET الشرطية (ETag)، وإعادة المحاولة مع التراجع التدريجي، ونقاط نهاية الدُفعات حيثما توفرت.
فشل التحديث الصامت ← نبضات صحة، وWebhooks للإخفاقات أو تنبيهات Teams، ولوحات SLO لمعدل نجاح التحديث ومدته.
المنطق داخل التقارير ← انقله إلى مقاييس النموذج ومجموعات الحسابات؛ وأدِر إصداراته واختبره.

خطة البداية لمدة 7 أيام

اليوم 1–2: سجّل التطبيق بصلاحيات التطبيق فقط (app-only)، وخزّن السر أو الشهادة في Key Vault، وحدد النطاقات بأقل قدر من الأذونات.
اليوم 3: ابنِ عميل API بسيطاً (لعرض الكيانات، وسحب التغييرات منذ آخر علامة مرجعية).
اليوم 4: انقل البيانات إلى Lakehouse (بتنسيق Delta)، وأضف مخططاً أساسياً وتقسيماً.
اليوم 5: أنشئ نموذجاً دلالياً يضم 3–5 مقاييس أساسية، وفعّل Incremental Refresh.
اليوم 6: نسّق التحديث عبر REST بعد التحميل، وأضف تنبيهات الإخفاق إلى Teams.
اليوم 7: ضمّن النتائج في قناة Teams، ونفّذ عرضاً مباشراً، وسجّل المراقبة من البداية حتى النهاية.

الأسئلة المتداولة السريعة

هل أحتاج إلى Fabric وPower BI Premium لهذا؟
يمكنك البدء بشكل محدود (Pro أو إثبات مفهوم)، لكن الزمن القريب من الفوري، والنماذج الكبيرة، أو الحوكمة المؤسسية تستفيد عادةً من سعات Premium أو Fabric.

دفعات أم وقت حقيقي؟
الخيار الافتراضي هو الدفعات + التحديث التزايدي؛ واستخدم Hybrid/DirectQuery فقط حيث يكون زمن الاستجابة مهماً ويستطيع المصدر تحمّل ذلك.

هل يمكنني تجنب تخزين البيانات (للامتثال)؟
استخدم DirectQuery مع واجهات برمجة تطبيقات معتمدة أو بوابات البيانات، وتوقّع مفاضلات في الأداء وفي تعقيد DAX.

مع بدء تخطيطكم لتطور البنية المعمارية بعيدًا عن العمليات اليدوية عبر واجهات المستخدم والموصلات الهشة، تذكّروا أن تصمّموا الأمان أولًا، وأن تبنوا نماذجكم الدلالية كعقود مؤسسية حقيقية. للاطلاع على تفاصيل أعمق حول هذه المفاهيم والاستراتيجيات التقنية والتطبيقات العملية، استمعوا إلى النقاش الكامل في البودكاست عبر الرابط Extend Microsoft Fabric with Custom APIs and Power BI Models. شكرًا لقراءتكم، وإلى لقاء جديد في بناء الحلول الأفضل!