كيف تُعدّ سير عمل لنقل Revit Cloud Worksharing باستخدام APS وMCP؟

ما الذي ستتعلمه في هذا الدليل؟

يشرح هذا الدليل كيفية التفكير في سير عمل لنقل Revit Cloud Worksharing (RCW) عبر خادم Model Context Protocol (MCP) يتصل بـ APS. يعرض مثال Autodesk كيف يحوّل عميل MCP طلبًا بلغة طبيعية إلى استدعاءات للأدوات، وكيف ينظم الخادم عمليات APS، فيما تنفذ أتمتة Revit عملية نقل النموذج. الخطوات هنا مخصصة لفهم البنية النموذجية، وليست وصفة إعداد جاهزة للإنتاج أو قابلة للتطبيق مباشرة على كل مشروع.

والتمييز المهم هو أن عميل الذكاء الاصطناعي ينسق قرار النقل واستدعاءات الأدوات، بينما تنفذ جهة Design Automation for Revit العملية الفعلية على النموذج باستخدام Revit API. أما خادم MCP فيدير العمليات والتفويض بين الجانبين.

المتطلبات وإمكانية الوصول

يوسّع مثال Autodesk خادم MCP مبنيًا على Node.js ليشمل وظائف APS. يجب ربط خادم MCP بعميل متوافق، وأن يكون قادرًا على الوصول إلى بيانات APS التي تضم النموذج المصدر والمشروع المستهدف. كما يجب إعداد محرك Revit المناسب لعملية النقل وأنشطة الأتمتة اللازمة لتشغيل أتمتة Revit. لا يحدد المصدر إصدارًا معينًا من Node.js أو معلومات عن الأسعار، لذا لا ينبغي افتراض إصدار أو تكلفة هنا.

يعتمد اختيار المصادقة على مكان تشغيل الخادم وعلى الجهة التي تعود إليها البيانات الجاري التعامل معها. في خادم يبدأه عميل مكتبي محلي عبر STDIO، قد لا تكون هناك حاجة إلى مصادقة منفصلة على مستوى العميل والخادم. وعلى جانب APS، يمكن استخدام 3-legged OAuth (3LO) أو PKCE لتنفيذ العمليات نيابة عن المستخدم، أو في حالات مثل العمليات المحلية التي لا يمكن فيها تخزين سرّ. أما الأعمال التي تتطلب هوية تطبيق مشتركة على مستوى الخادم، فيمكن النظر في 2-legged OAuth (2LO) أو Secure Service Account (SSA) مُنح صلاحية الوصول. تجدر الإشارة إلى أن واجهات API لا تقبل جميع أنواع المصادقة.

تخطيط سير عمل النقل خطوة بخطوة

1. حدّد سيناريو الاستخدام والعميل. حسم أولًا ما إذا كان العمل سيتم بصلاحيات المستخدم نفسه أم بهوية أتمتة مشتركة. ثم اختر ما إذا كان خادم MCP سيعمل كعملية محلية أم سيُتاح عن بُعد عبر HTTP. يتناول دليل Autodesk استخدام STDIO محليًا وStreamable HTTP للسيناريوهات البعيدة ومتعددة المستخدمين. وعند إتاحة الخادم عبر HTTP، ينبغي تصميم المصادقة بين العميل والخادم بشكل مستقل عن مصادقة APS.

2. اختر طريقة مصادقة APS بما يتوافق مع الصلاحيات المطلوبة. للوصول إلى بيانات المستخدم الشخصية، يُنظر في 3LO أو PKCE المعتمدين على تسجيل دخول المستخدم. ويمكن استخدام 2LO لموارد التطبيق نفسه، لكن هذه الطريقة قد لا تكفي لاستدعاءات API التي تتطلب سياق مستخدم. وإذا كان على الأتمتة الوصول إلى بيانات المشروع من دون الحاجة إلى تسجيل دخول المستخدم باستمرار، فيمكن دراسة SSA مُصرّح له بالوصول إلى المراكز والمشروعات المستهدفة. لا تخلط بين رمز الوصول المستخدم بين الخادم والعميل ورمز APS؛ فلكل منهما غرض مختلف.

3. افصل مهام أدوات MCP. يتيح الخادم في مثال Autodesk استكشاف المشروعات والمجلدات باستخدام أدوات إدارة البيانات المتاحة؛ ويساعد الحقل extensionType في محتوى المجلد على التمييز بين نماذج RCW. أما أداة migrate-rcw-model المضافة للنقل، فتستقبل النموذج المصدر والمشروع والمجلد المستهدفين وإصدار Revit المستهدف. وباستخدام هذه المعلومات، تجهّز الأداة مهمة APS Automation وترسلها. يساعد الفصل بين الاستكشاف وإجراء النقل الذي يغيّر البيانات على توضيح العملية التي سيبدأها العميل.

4. تحقق من المتطلبات المسبقة واطلب موافقة المستخدم. تتضمن آلية المثال الأداة check-migrator-setup للتحقق من محركات Revit وأنشطة الأتمتة المُعدّة. وتشير Autodesk إلى أن إرشادات سير العمل يمكن أن توجه المساعد للتحقق من المتطلبات المسبقة وطلب موافقة المستخدم قبل النقل. لا ترسل مهمة النقل قبل تحديد المشروع والمجلد المستهدفين وإصدار Revit؛ وتحقق من هذه الخيارات بما يتوافق مع طلب المستخدم.

5. اجعل المهمة غير المتزامنة قابلة للمتابعة. قد يستغرق النقل بضع دقائق، لذا فإن إرجاع الأداة لمعرّف المهمة لا يعني اكتمالها. تسترجع get-migration-status في المثال حالة المهمة ومعلومات الخطأ، بينما تطلب cancel-migration إلغاء المهام المعلّقة. وفي العملاء المتوافقين الذين يستخدمون MCP Apps، يمكن للوحة الحالة عرض المهام النشطة وعمليات النقل المكتملة وتفاصيل الأخطاء وخيارات الإلغاء. ينبغي التعامل مع هذه الطبقة على نحو منفصل عن الأداة التي تبدأ مهمة النقل.

6. اختبر سير العمل بأمان وعلى نطاق محدود. ابدأ بالتحقق من إمكانية عرض النماذج المتاحة ومن نجاح فحص الإعداد. ثم، بعد موافقة المستخدم، أرسل نموذجًا واحدًا إلى المشروع المستهدف وتحقق من أن معرّف المهمة وحالتها ومعلومات الخطأ تظهر كما هو متوقع. لا تسلّم رموز APS إلى العميل، ولا تمرر رمز العميل مباشرة إلى APS. وإذا كان خادم MCP بعيدًا، فحدّد أيضًا الجهات المسموح لها بالوصول إليه؛ فهذه الطبقة مختلفة عن الطبقة التي تحدد هوية APS المستخدمة في تنفيذ العمليات.

أهمية ذلك لسير عمل العمارة والتصور

يمكن لمكاتب العمارة التي تعمل على عدة مشروعات Revit أو نماذج RCW الاستفادة من فكرة بدء النقل بلغة طبيعية ومتابعة تقدمه ضمن العميل نفسه. وبالنسبة إلى المطورين، تقدم أدوات MCP مثالًا على ربط أتمتة APS الحالية بعملاء متوافقين مختلفين. لكنها لا تحل تلقائيًا تنسيق BIM أو تحليل تبعيات النموذج.

لا تتضمن المصادر معلومات عن تكاليف الأجهزة أو التراخيص. لذا، ينبغي قبل اتخاذ القرار التحقق بشكل مستقل من وصول المؤسسة إلى APS، وإعداد أتمتة Revit المختار، وتوافق طريقة المصادقة مع أذونات المشروع. وعلى وجه الخصوص، لا ينبغي للفرق التي تعمل على نماذج مرتبطة افتراض أن النماذج ذات الصلة ستُنقل مع النموذج.

أخطاء شائعة وخطوات تالية

أهم القيود أن المثال يركز على نماذج RCW منفردة: فهو لا ينقل علاقات النماذج المرتبطة تلقائيًا ولا يصلح الروابط في المشروع المستهدف. وتتطلب المشروعات التي تضم نماذج مرتبطة تحليل التبعيات والفحص المسبق والتنسيق بشكل منفصل؛ ويعرض المصدر هذه الإمكانات على أنها إضافات محتملة مستقبلًا.

ومن أخطاء التصميم الشائعة أيضًا اعتبار المصادقة بين عميل MCP والخادم هي نفسها المصادقة اللازمة للوصول إلى APS. حدّد أولًا الطرف الذي يتحقق من هوية كل جهة في كل طبقة. ثم راجع الأدوات والصلاحيات وموافقة المستخدم في ضوء هذا التمييز. عند بدء التنفيذ التقني، استخدم مستودع أمثلة Autodesk وأمثلة المصادقة الخاصة بـ APS MCP نقطةَ انطلاق، مع استيفاء متطلبات الأمان والنماذج المرتبطة بصورة مستقلة في بيئة الإنتاج.

المصدر والترخيص

اقتبس المحتوى من أدلة Autodesk Platform Services: “Bringing Revit Cloud Worksharing Migration to AI Assistants with APS and MCP” و“Building Custom MCP Servers with Autodesk Platform Services” و“Authentication Patterns for APS MCP Servers”. وقد وُضعت حالة الترخيص في سجلات المصادر المقدمة على أنها serbest، لكن لم يُذكر اسم ترخيص مفتوح محدد؛ لذلك لم يُوصف المحتوى بأنه منشور بموجب ترخيص مثل CC BY.