تكامل نظام معلومات الطلاب هو ما يتيح لموقع الجامعة عرض كتالوج المقررات والجداول الدراسية ومتطلبات البرامج دون الحاجة إلى إعادة كتابتها من جديد. البيانات موجودة في Banner أو PeopleSoft أو Workday أو نظام داخلي؛ ويقوم دروبال بقراءتها وتنسيقها ونشرها. في هذا المقال نستعرض الأنماط الثلاثة التي يمكن أن يتبعها التكامل، وكيف تعرض كل منصة من المنصات الرئيسية بياناتها، وأي نظام ينبغي أن يملك ماذا، ونقاط الفشل التي يجب التخطيط لها قبل أول تبديل للفصل الدراسي.
تتوقف معظم الشروحات حول هذا الموضوع عند جملة واحدة: دروبال يتكامل مع أنظمة معلومات الطلاب. هذا صحيح لكنه غير مفيد كثيرًا. الأسئلة التي يواجهها فريق الويب فعليًا مختلفة. هل تُنسخ بيانات المقررات إلى دروبال أم تُقرأ مباشرة؟ ماذا يحدث عندما يُلغي مكتب التسجيل شعبة دراسية في منتصف الفصل؟ أين يوجد النص التسويقي لبرنامج ما إذا كان الوصف الرسمي موجودًا في نظام معلومات الطلاب؟ أي النظامين هو الصحيح عندما يتعارضان؟ فيما يلي نتناول هذه الأسئلة مع المنصات التي تعتمدها معظم الجامعات.
ما الذي يفعله تكامل نظام معلومات الطلاب فعليًا على موقع الجامعة
نظام معلومات الطلاب هو النظام المرجعي للمؤسسة فيما يخص البيانات الأكاديمية. فهو يحتفظ بكتالوج المقررات، وجدول الحصص، ومتطلبات البرامج والدرجات العلمية، والتسجيل، والدرجات، والسجلات الأكاديمية، والتقويم الأكاديمي. لا ينبغي لأي شيء على الموقع العام أن يتعارض معه.
أما الموقع الإلكتروني، فهو المكان الذي تُشاهَد فيه معظم هذه البيانات فعليًا. الطلاب المحتملون يقرؤون صفحات البرامج. الطلاب الحاليون يتحققون من مواعيد انعقاد الشعب الدراسية. المرشدون الأكاديميون يبحثون عن المتطلبات السابقة. وعندما يتباعد الموقع عن نظام معلومات الطلاب، يكون الموقع هو المخطئ، والأشخاص الذين يلاحظون ذلك هم آخر من تريد الجامعة إزعاجهم.
التكامل يزيل الحاجة إلى إعادة الكتابة بين النظامين. من الناحية العملية، يغطي قائمة قصيرة نسبيًا من أنواع البيانات، ومن المفيد تسميتها لأن كل نوع يتصرف بشكل مختلف:
- كتالوج المقررات: رموز المقررات، وعناوينها، وعدد الساعات المعتمدة، والأوصاف، والمتطلبات السابقة. يتغير بضع مرات في السنة، مرتبط بسنة الكتالوج.
- جدول الحصص: الشعب الدراسية، ومواعيد الانعقاد، والقاعات، والمحاضرون، وعدد المقاعد. يتغير يوميًا خلال فترة التسجيل.
- البرامج والمتطلبات: الدرجات العلمية، والتخصصات الفرعية، والقواعد التي تربط المقررات بها. يتغير نادرًا لكن بموافقة رسمية.
- التقويم الأكاديمي والفصول الدراسية: رموز الفصول الدراسية، ومواعيد الإضافة والحذف، والعطلات. عنصر صغير وثابت، ويُشار إليه من كل شيء آخر.
- السجلات الخاصة بالطالب: جدول طالب معين، والحجوزات على ملفه، وتقدمه نحو الدرجة العلمية. بيانات شخصية، لا تُعرض إلا لذلك الطالب بعد المصادقة على هويته.
الأنواع الأربعة الأولى هي بيانات مؤسسية ويمكن أن تظهر على الصفحات العامة. أما النوع الأخير فهو بيانات شخصية ويخضع لقواعد مختلفة، سنعود إليها لاحقًا.
ثلاثة أنماط للتكامل ومتى يناسب كل منها
يكاد يكون كل تكامل بين دروبال ونظام معلومات الطلاب واحدًا من ثلاثة أنماط، واختيار النمط الخاطئ هو المصدر الأكثر شيوعًا للمشاكل لاحقًا. العوامل الحاسمة هي مدى تكرار تغير البيانات، وعدد الأشخاص الذين يقرؤونها، وما إذا كانت تخص فردًا معينًا.
الاستيراد المجدوَل لصفحات الكتالوج والبرامج
يقوم نظام معلومات الطلاب بتصدير بيانات المقررات والبرامج وفق جدول زمني، عادةً كل ليلة، ويستوردها دروبال إلى محتوى عادي: نوع محتوى للمقرر، ونوع محتوى للبرنامج، ومصطلحات تصنيفية للمواد والفصول الدراسية. تتولى واجهة برمجة التطبيقات Migrate API المدمجة في نواة دروبال هذه المهمة، مع وحدتي Migrate Plus وMigrate Tools المساهمتين اللتين تضيفان مصادر JSON وXML وCSV والأدوات اللازمة لتشغيل عمليات الاستيراد والتراجع عنها. وتُعدّ وحدة Feeds البديل الأقل تعقيدًا في البرمجة للتغذيات الأبسط.
بمجرد استيرادها، تتصرف البيانات مثل أي محتوى آخر في دروبال؛ فهي قابلة للبحث، والتخزين المؤقت، والترجمة، ويمكن الإشارة إليها من صفحات أخرى. يمكن للمحررين إضافة حقول لا يملكها نظام معلومات الطلاب، مثل ملخص تسويقي أو صورة رئيسية أو شهادات، دون المساس بالسجل الرسمي. بنت جامعة داندي (Dundee) صفحات مقرراتها بهذه الطريقة ككيانات مخصّصة، وفهرستها باستخدام Search API إلى جانب بيانات الأشخاص والكليات، وأطلقت قسم مقررات المرحلة الجامعية الأولى كإصدارها الأول في يوليو 2019.
يناسب هذا النمط البيانات التي تتغير وفق دورة معروفة ويقرؤها عدد كبير من الأشخاص. ولا يناسب أي شيء يتغير كل ساعة، لأن الاستيراد الليلي سيكون دائمًا متأخرًا عن الواقع.
القراءة المباشرة لبيانات التوافر والجداول
هنا لا يُنسخ شيء. يستعلم دروبال من واجهة برمجة تطبيقات نظام معلومات الطلاب عند طلب الصفحة ويعرض النتيجة. وحدة External Entities مصممة خصيصًا لهذا الغرض: فهي تُعرّف نوع كيان يكون تخزينه نقطة نهاية REST بعيدة بدلًا من قاعدة بيانات دروبال، بحيث لا تزال البيانات البعيدة قابلة للاستخدام مع Views وأنماط العرض ومنسقات الحقول. وتقدم وحدة Views Remote Data مسارًا أخف عندما يكون المطلوب مجرد قائمة عرض.
القراءة المباشرة هي الإجابة الصحيحة لعدد المقاعد، وحالة الشعبة الدراسية، وأي شيء آخر تكون فيه القيمة القديمة مضللة. لكنها تحمّل تكلفتين: كل مشاهدة للصفحة تصبح استدعاءً لواجهة برمجة التطبيقات ما لم تُخزَّن مؤقتًا بعناية، ويصبح وقت تشغيل الموقع مرتبطًا بوقت تشغيل واجهة برمجة تطبيقات نظام معلومات الطلاب. التخزين المؤقت القصير بمدة صلاحية محددة، ورسالة احتياطية سلسة عند تعذّر الوصول إلى واجهة برمجة التطبيقات، ليسا إضافتين اختياريتين. فبدونهما، يوقِف أول يوم تسجيل الموقعَ بالكامل مع نظام معلومات الطلاب.
عمليات البحث الموثّقة لبيانات الطالب الخاصة
يغطي النمط الثالث بوابة الطالب: جدولي، وحجوزاتي، ومراجعة تقدمي نحو الدرجة العلمية. تُجلب البيانات عند الطلب للشخص المسجَّل دخوله، وتُعرض مرة واحدة، ولا تُخزَّن في دروبال إطلاقًا. تأتي الهوية من نظام تسجيل الدخول الموحد الخاص بالحرم الجامعي؛ ومعرّف الطالب من تلك الجلسة هو ما يُبنى عليه استعلام نظام معلومات الطلاب.
يعتمد هذا النمط على حل مسألة الهوية أولًا، لأن المعرّف الخاطئ يُعيد سجل طالب آخر. لقد تناولنا الخيارات في تكامل تسجيل الدخول الموحد مع SAML وShibboleth وLDAP وCAS. وبمجرد وضع ذلك، يكون استدعاء نظام معلومات الطلاب نفسه عادةً طلبًا واحدًا موجّهًا إلى نقطة نهاية خاصة بالشخص أو الطالب، يُنفَّذ من جهة الخادم باستخدام بيانات اعتماد واجهة برمجة التطبيقات الخاصة بالمؤسسة، ولا يُكشف أي منها للمتصفح مطلقًا.
تقرر بعض الجامعات أن هذه الطبقة يجب أن تكون ضمن منتج الخدمة الذاتية الخاص بمزوّد نظام معلومات الطلاب نفسه بدلًا من موقع دروبال، فتكتفي بالربط إليه. وهذا خيار مشروع، وغالبًا ما يكون الأقل تكلفة. يُثبت دروبال جدارته في البوابة عندما ترغب المؤسسة في دمج بيانات نظام معلومات الطلاب مع المحتوى والأخبار والفعاليات والخدمات التي لا علم لنظام معلومات الطلاب بها.
ربط دروبال بالمنصات الرئيسية
يعرض كل مزوّد بياناته بطريقة مختلفة، وهذه الاختلافات هي ما يحدد أي نمط يكون عمليًا.
Ellucian Banner وColleague عبر Ethos
المسار الموصى به من Ellucian للتكامل مع أطراف ثالثة هو Ethos، وهو طبقة موحّدة من نوع REST وJSON تعلو كلًا من Banner وColleague. تقدّم Ethos نموذج بيانات مشتركًا، بحيث يكون للمقرر أو الشعبة الدراسية أو الشخص الشكل نفسه أيًا كان المنتج الذي يعمل تحتها، ويحمل كل سجل معرّفًا فريدًا عالميًا (GUID) بدلًا من معرّف خاص بالمنتج. تُستضاف Ethos إقليميًا، بنقاط نهاية منفصلة للولايات المتحدة وكندا وأوروبا وآسيا والمحيط الهادئ، وهو أمر مهم للمؤسسات التي لديها متطلبات إقامة البيانات.
بالنسبة لدروبال، يعني هذا أن مجموعة واحدة من تعريفات الموارد تعمل مع كل من حرم Banner وColleague الجامعية، وأن وحدة External Entities يمكنها ربط بيانات JSON من Ethos بالحقول باستخدام أداة الربط JSONPath الخاصة بها. يُمنح الوصول لكل مورد وكل حقل على جانب Ellucian، لذا فإن المهمة الأولى للمشروع عادةً ما تكون الاتفاق مع مكتب التسجيل حول الموارد التي يحتاجها الموقع، وليس كتابة الشيفرة البرمجية. أما حرم Banner القديمة التي لا تستخدم Ethos فلا تزال تعرض واجهات برمجة تطبيقات مباشرة وطرق عرض لقاعدة البيانات؛ وهي تعمل، لكن كل تكامل يصبح خاصًا بذلك الحرم الجامعي.
PeopleSoft Campus Solutions
يعرض Campus Solutions من Oracle البيانات عبر Integration Broker، وهي طبقة المراسلة وخدمات الويب الخاصة بها، باستخدام REST أو SOAP. تأتي بيانات كتالوج المقررات والجدول من وحدة Student Records، والمفهوم الذي يوقع معظم القائمين على التكامل في الخطأ هو التأريخ الفعّال (effective dating): فليس للمقرر وصف واحد، بل تاريخ من الأوصاف، كل منها ساري المفعول اعتبارًا من تاريخ معين، ويتعين على الاستعلام أن يطلب الوصف الصحيح لسنة الكتالوج المعروضة.
لهذا السبب يناسب الاستيراد المجدوَل بيانات كتالوج PeopleSoft بشكل جيد. يمكن للاستيراد أن يحل الصفوف ذات التأريخ الفعّال مرة واحدة، كل ليلة، ويخزّن النسخة الحالية. أما القيام بهذا الحل في كل طلب مباشر فهو مضيعة للموارد. وتظل القراءة المباشرة هي النمط الصحيح لتوافر الشعب الدراسية، حيث تكون القيمة رقمًا حاليًا واحدًا.
Workday Student
يعرض Workday خدمات ويب من نوع REST وSOAP، كما يوفر، للمستخرجات على طراز التقارير، تقارير مخصّصة يمكن نشرها كتغذيات بيانات. من الناحية العملية، يُبنى العديد من تكاملات Workday Student على تغذيات التقارير هذه: يُعرّف مكتب التسجيل تقريرًا يحتوي بالضبط على حقول المقررات والشعب الدراسية التي يُسمح للموقع برؤيتها، ويستهلكها دروبال وفق جدول زمني. يحافظ هذا النهج على وضوح عقد البيانات ويضع التحكم في ما يخرج من نظام معلومات الطلاب بيد من يملكه.
يختلف نموذج Workday للفصول والفترات الأكاديمية عن نموذجَي Banner وPeopleSoft، لذا فإن ربط الحقول يستحق جلسة تصميم خاصة به بدلًا من افتراضه انطلاقًا من مشروع سابق.
الأنظمة الداخلية والإقليمية
تُشغّل العديد من الجامعات نظامها الخاص، أو منصة وطنية، أو منتج مزوّد إقليمي. النمط لا يتغير؛ ما يتغير هو وسيلة النقل فقط. إذا كان للنظام واجهة برمجة تطبيقات، يمكن لوحدة External Entities أو لإضافة مصدر migrate مخصّصة استهلاكها. وإذا كان بإمكانه فقط إنتاج ملفات، فإن إسقاط دوري لملفات CSV أو XML على موقع SFTP واستيرادها عبر Migrate يُعدّ تكاملًا محترمًا تمامًا، وغالبًا ما يكون أكثر موثوقية من واجهة برمجة تطبيقات هشّة. الهدف هو الاتفاق على عقد البيانات والجدول الزمني، ثم الحفاظ على استقرار كليهما.
أي نظام يملك البيانات
القرار الأهم في المشروع ليس تقنيًا؛ إنه بيان بشأن من يملك أي حقول.
يملك نظام معلومات الطلاب كل ما هو أكاديمي ورسمي: رموز المقررات، والعناوين، والساعات المعتمدة، والمتطلبات السابقة، والمتطلبات العامة، ومواعيد الانعقاد، وتواريخ الفصول الدراسية. لا يقوم دروبال بتعديل أي من ذلك أبدًا؛ بل يعرضه فقط. إذا كان وصف مقرر على الموقع خاطئًا، فإن الإصلاح يتم في نظام معلومات الطلاب وينتقل تلقائيًا في الاستيراد التالي.
يملك دروبال كل ما لم يُصمَّم نظام معلومات الطلاب أصلًا للاحتفاظ به: السرد التسويقي للبرنامج، واقتباسات أعضاء هيئة التدريس، ونتائج التوظيف، والصور، ودعوات اتخاذ الإجراء، والترجمات، وبيانات تحسين محركات البحث الوصفية. تعيش هذه الحقول على جانب دروبال، مرتبطة بالسجل المستورد لكنها مخزّنة بمعزل عنه، بحيث لا يطغى الاستيراد أبدًا على عمل المحرر.
تدوين هذا في جدول يربط كل حقل بمالكه، بالاتفاق بين مكتب التسجيل وفريق الويب قبل بدء البناء، يمنع أكثر خلافين شيوعًا لاحقًا: محرر غيّر قيمة الساعات المعتمدة على الموقع ثم وجدها استُبدلت بين عشية وضحاها، ومسؤول تسجيل لا يفهم لماذا لا يزال مقرر ألغاه يظهر على صفحة مقصودة بناها أحدهم يدويًا.
الكتابة العكسية من دروبال إلى نظام معلومات الطلاب، حيث ينشئ نموذج ويب سجلًا في نظام معلومات الطلاب أو يعدّله، ممكنة عبر Ethos وIntegration Broker، لكنها تنتمي إلى فئة مخاطر مختلفة. توجّه معظم المؤسسات إجراءات التقديم والتسجيل عبر منتجات مزوّد نظام معلومات الطلاب نفسه أو عبر نظام إدارة علاقات القبول (CRM)، وتُبقي الموقع للقراءة فقط بالنسبة لنظام معلومات الطلاب. هذا هو الخيار الافتراضي المعقول.
خصوصية الطالب في طبقة التكامل: FERPA وGDPR
في اللحظة التي يلمس فيها التكامل سجلات خاصة بطالب معين، يصبح تعاملًا مع بيانات خاضعة للتنظيم. في الولايات المتحدة، يميّز قانون FERPA بين السجلات التعليمية، التي تتطلب موافقة للإفصاح عنها، ومعلومات الدليل مثل الاسم والبرنامج، التي يجوز للمؤسسة الإفصاح عنها ما لم يكن الطالب قد اختار عدم ذلك. وفي الاتحاد الأوروبي والمملكة المتحدة، تنطبق اللائحة العامة لحماية البيانات (GDPR) على أي بيانات شخصية، وتحكم مبادئ تحديد الغرض وتقليل البيانات مقدار ما يجوز للموقع جلبه منها.
ثلاث قواعد تُبقي تكامل دروبال متوافقًا مع كلا النظامين:
- البيانات المؤسسية على الصفحات العامة، والبيانات الشخصية فقط خلف المصادقة. الكتالوجات والجداول بيانات مؤسسية. أما جدول الطالب الخاص فهو بيانات شخصية.
- جلب البيانات الشخصية عند الطلب وعدم تخزينها. لهذا السبب وُجد نمط البحث الموثَّق. لا ينبغي أن يستقر أي سجل طالب في جدول من جداول دروبال أو في ذاكرة تخزين مؤقت لصفحة يمكن أن يصل إليها مستخدم آخر.
- طلب الحقول التي تستخدمها الصفحة فقط. تتيح كل من Ethos وتغذيات تقارير Workday للمؤسسة تحديد نطاق الوصول لكل حقل. وتحديد هذا النطاق بدقة هو أرخص وسيلة رقابة امتثال متاحة.
تسجيل أي حساب نظام جلب ماذا ومتى يُغلق الحلقة لأغراض التدقيق. لقد تناولنا الالتزامات الأوسع في تحقيق الامتثال للائحة GDPR مع دروبال؛ وطبقة التكامل هي حيث يتجسّد كثير منها بشكل ملموس.
ما الذي يتعطل في الواقع العملي وكيف تخطط له
نادرًا ما تفشل التكاملات يوم الإطلاق. بل تفشل عند أول حدث لم يتوقعه التصميم. هذه هي الحالات المتكررة.
- تبديل الفصل الدراسي. يفتح نظام معلومات الطلاب فصلًا دراسيًا جديدًا بينما لا يزال الموقع يعرض القديم على أنه الحالي. اجعل نمذجة الفصول الدراسية صريحة في دروبال، واستمد مفهوم "الفصل الحالي" من تقويم نظام معلومات الطلاب، لا من تاريخ مكتوب في الشيفرة البرمجية.
- المقررات الملغاة والمدمجة. يختفي مقرر من التصدير لكن صفحته في دروبال، بروابطها الواردة وترتيبها في نتائج البحث، لا تزال مباشرة. قرر مسبقًا ما إذا كان الاستيراد سيلغي نشرها، أو يؤرشفها مع إشعار، أو يعيد توجيهها إلى بديلها.
- التغييرات ذات التأريخ الفعّال. يظهر وصف ساري المفعول اعتبارًا من سنة الكتالوج القادمة على صفحة السنة الحالية لأن الاستعلام لم يُصفَّ حسب التاريخ. هذه مشكلة كلاسيكية في PeopleSoft لكن المفهوم موجود في كل مكان.
- إبطال التخزين المؤقت. تُخزَّن بيانات القراءة المباشرة مؤقتًا لأغراض الأداء، ثم يبقى عدد المقاعد صفرًا لمدة ساعة بعد فتح المقاعد فعليًا. حدد مدة الصلاحية لكل نوع بيانات، وقصّرها خلال فترات التسجيل.
- حدود واجهة برمجة التطبيقات وانقطاعها. عنصر واجهة في الصفحة الرئيسية يستدعي نظام معلومات الطلاب مع كل طلب سيستنفد حد المعدل في أول صباح مزدحم. خزّن مؤقتًا بشكل مكثف، وتدهور بسلاسة، ولا تسمح أبدًا لانقطاع نظام معلومات الطلاب بأن ينتج صفحة فارغة.
- تعارض المعرّفات. تستخدم هوية تسجيل الدخول الموحد معرّفًا واحدًا ويستخدم نظام معلومات الطلاب معرّفًا آخر. اتفق على الربط قبل بناء البوابة، واختبره بحسابات حقيقية بما في ذلك حالات خاصة مثل الموظفين الذين هم أيضًا طلاب.
لا شيء من هذا غريب أو نادر. دليل تشغيلي من صفحة واحدة يغطي هذه الحالات، مكتوب قبل الإطلاق، يساوي أكثر من معظم الشيفرة البرمجية.
إلى أي مدى ينبغي أن يذهب التكامل؟
ليست كل جامعة بحاجة إلى الأنماط الثلاثة، وبناء وظائف بوابة لا يستخدمها أحد هو طريقة شائعة للإنفاق الزائد.
الموقع على مستوى الكتيّب التعريفي يحتاج فقط إلى صفحات البرامج، ويمكن صيانتها يدويًا إذا كانت قائمة البرامج قصيرة وثابتة. أما الموقع على مستوى الكتالوج فيحتاج إلى الاستيراد المجدوَل؛ وهناك تكمن معظم القيمة بالنسبة لمعظم المؤسسات، لأنه يزيل إعادة الكتابة عبر مئات الصفحات. ويضيف الموقع على مستوى البوابة عمليات البحث الموثّقة، ولا يستحق ذلك إلا عندما ترغب المؤسسة في باب أمامي واحد يجمع بين بيانات نظام معلومات الطلاب وكل ما ينشره الحرم الجامعي من محتوى آخر. الفرق في التكلفة بين المستويات كبير، وتحليل التكلفة الإجمالية للملكية للأنظمة مفتوحة المصدر مقابل المرخَّصة يوضح كيفية موازنة جهد التنفيذ مقابل التوفير في الترخيص.
من المفيد أيضًا توضيح ما لا يمثله تكامل نظام معلومات الطلاب. فهو ليس تكامل نظام إدارة التعلم. يسجّل نظام معلومات الطلاب أن الطالب مسجَّل في شعبة دراسية؛ بينما يقدّم نظام إدارة التعلم تلك الشعبة فعليًا. ينقل التكاملان بيانات مختلفة، عادةً عبر واجهات برمجة تطبيقات مختلفة، ومن الأفضل تحديد نطاقهما كمشروعين منفصلين حتى عندما يصادف إطلاقهما الفصل الدراسي نفسه.
التخطيط لأول تكامل لك
العمل التقني في تكامل نظام معلومات الطلاب أصغر مما يبدو عليه. الجزء الأكبر هو الاتفاق: أي الحقول يجوز للموقع قراءتها، وأي نظام يملك كل واحد منها، وكم مرة يتحدث كل نوع بيانات، وماذا يحدث عند تبديل الفصل الدراسي. الجامعات التي تحسم هذه الأسئلة مع مكتب التسجيل أولًا تميل إلى بناء التكامل مرة واحدة فقط. أما الجامعات التي تبدأ من وثائق واجهة برمجة التطبيقات فتميل إلى بنائه مرتين.
منصات دروبال التي بناها فريق Drupal4edu في Drupart لمؤسسات مثل جامعة صابانجي، وجامعة الشرق الأوسط التقنية (METU)، وجامعة يلدز التقنية، مصممة حول طبقة التكامل هذه بالتحديد، حيث يقرأ الموقع من أنظمة السجل الخاصة بالمؤسسة بدلًا من تكرارها. يمكنك قراءة المزيد عن نهجنا على صفحة دروبال للتعليم.
أسئلة متكررة حول تكامل دروبال مع أنظمة معلومات الطلاب
هل يمكن لدروبال أن يتكامل مع Ellucian Banner؟
نعم. المسار الحالي هو Ellucian Ethos، وهي طبقة REST وJSON تعرض بيانات Banner وColleague في نموذج موحد بمعرّفات GUID. يقرأ دروبال موارد Ethos إما وفق جدول زمني، باستخدام Migrate API لاستيراد المقررات والبرامج كمحتوى، أو مباشرة، باستخدام وحدة External Entities لعرض السجلات البعيدة دون تخزينها. يُحدَّد نطاق الوصول لكل مورد وكل حقل على جانب Ellucian، بحيث يتحكم مكتب التسجيل بدقة في البيانات التي يمكن للموقع رؤيتها. ولا تزال حرم Banner القديمة التي لا تستخدم Ethos قابلة للتكامل عبر واجهات برمجة تطبيقات مباشرة أو طرق عرض لقاعدة البيانات، لكن كل تكامل من هذا النوع يكون خاصًا بذلك الحرم الجامعي.
هل يخزّن دروبال بيانات الطلاب عند تكامله مع نظام معلومات الطلاب؟
فقط إذا صُمّم التكامل على هذا النحو، وبالنسبة للبيانات الشخصية لا ينبغي أن يكون كذلك. عادةً ما تُستورَد البيانات المؤسسية مثل كتالوجات المقررات والجداول الدراسية إلى دروبال حتى يمكن البحث فيها وتخزينها مؤقتًا وإثراؤها بمحتوى تسويقي. أما السجلات الخاصة بالطالب، مثل جدوله أو حجوزاته، فينبغي جلبها عند الطلب للطالب المصادَق على هويته، وعرضها، ثم التخلص منها. لا حاجة لأن يستقر أي سجل طالب في جدول دروبال أو في ذاكرة تخزين مؤقت مشتركة للصفحات، وإبقاؤه بعيدًا عن كليهما هو أبسط طريقة لتحقيق الامتثال لكل من FERPA وGDPR في آن واحد.
كم مرة ينبغي أن تتزامن بيانات المقررات بين نظام معلومات الطلاب والموقع الإلكتروني؟
يعتمد ذلك على نوع البيانات. تتغير بيانات كتالوج المقررات والبرامج بضع مرات في السنة، ويكون الاستيراد الليلي أكثر من كافٍ؛ وتشغّله بعض المؤسسات أسبوعيًا. أما بيانات جدول الحصص فتتغير يوميًا خلال فترة التسجيل، لذا يلزم إما استيراد أكثر تكرارًا أو قراءة مباشرة بتخزين مؤقت قصير. وينبغي قراءة أعداد المقاعد وحالة الشعب الدراسية مباشرة خلال فترات التسجيل. الوعد بمزامنة فورية لكل شيء هو خطأ: فهو يكلف الأداء والموثوقية ولا يجني شيئًا لبيانات لا تتغير إلا مع التقويم الأكاديمي.
ما الفرق بين تكامل نظام معلومات الطلاب وتكامل نظام إدارة التعلم؟
إنهما ينقلان بيانات مختلفة. نظام معلومات الطلاب هو النظام المرجعي للتسجيل والمقررات والسجل الأكاديمي. أما نظام إدارة التعلم، مثل Moodle أو Canvas، فهو حيث يحدث التدريس فعليًا: المواد، والواجبات، والدرجات قيد التقدم. يجلب تكامل نظام معلومات الطلاب بيانات الكتالوج والجدول والتسجيل إلى الموقع. أما تكامل نظام إدارة التعلم فيتعلق عادةً بتسجيل الدخول الموحد وربط الطلاب من الموقع بمساحة مقرراتهم. نصف جانب نظام إدارة التعلم في تكامل Moodle ودروبال. من الأفضل تحديد نطاق المشروعين بشكل منفصل حتى عندما يتشاركان تاريخ الإطلاق نفسه.
هل تكامل دروبال مع نظام معلومات الطلاب متوافق مع FERPA؟
الامتثال خاصية تخص التصميم بأكمله، وليس أي برنامج بمفرده. يمكن بناء تكامل دروبال بحيث يفي بالتزامات FERPA من خلال إبقاء السجلات التعليمية خلف المصادقة، وجلبها عند الطلب بدلًا من تخزينها، وطلب الحقول التي تستخدمها الصفحة فقط، وتسجيل أي حساب نظام وصل إلى ماذا. أما معلومات الدليل مثل قوائم المقررات وأسماء المحاضرين فيجوز أن تظهر علنًا ما لم تنص سياسة المؤسسة أو اختيار الطالب عدم ذلك على خلاف ذلك. مكتب التسجيل، وليس فريق الويب، هو من يقرر أي الحقول تندرج تحت أي فئة، وينبغي توثيق ذلك القرار قبل بناء التكامل.