في سلسلة من المقالات ، سنتحدث نحن ، فريق تطوير Gems ، عن العمل مع "Gosuslugi" على الجانب الآخر من الشاشة وكيفية ترتيب التفاعل الفعال للهيئات الحكومية مع البوابة.
المخطط العام للتفاعل من خلال SMEV
المشاركون التفاعل
تخيل أن "Gosuslugi" عبارة عن متجر يعرض خدمات للمواطنين والمنظمات. يتم إرسال طلب "المشتري" للحصول على الخدمة إلى السلطات المختصة من خلال نظام التفاعل الإلكتروني بين الإدارات (SMEV). يقوم النظام بنقل الرسائل بين البوابة والدائرة.
يتم تنفيذ العمل من خلال SMEV باستخدام بروتوكول SOAP (بروتوكول الوصول إلى الكائنات البسيط - بروتوكول بسيط للوصول إلى الكائنات).
ينقسم المشاركون في التفاعل ، كما في المتجر ، إلى موردين ومستهلكين. المورد هو نظام معلومات (IS) يوفر المعلومات عند الطلب ، والمستهلك هو نظام يطلب المعلومات.
يمكن لداعش واحد ونفسه أن يتصرف في دورين في وقت واحد. على سبيل المثال ، في عملية تقديم خدمة ، تحتاج إلى إخطار البوابة الإلكترونية بتغيير في حالتها. في هذه الحالة ، يلعب مورد خدمات المعلومات دور المستهلك - فهو يقوم بتبادل المعلومات حسب الحالات.
أنواع المعلومات
يتبادل المشاركون البيانات من خلال أنواع المعلومات ( بروتوكولات التبادل ) - قواعد تشكيل حزم البيانات لإرسالها من مشارك إلى آخر.
خير مثال على نوع المعلومات هو التعداد السكاني لعموم روسيا لعام 2020 . يتم إرسال بيانات التعداد إلى السلطات التنفيذية الاتحادية في شكل إلكتروني. في البيانات الواردة ، هناك هيكل واضح للمعلومات: الاسم والجنس وتاريخ الميلاد والجنسية والحالة الاجتماعية. أيضًا ، في إطار نوع المعلومات ، يتم وصف الاستجابة التي يجب تلقيها في حالة نجاح معالجة الطلب.
اعتبارًا من يونيو 2020 ، تم تسجيل أكثر من 1000 صناعي (عامل) و 2000 نوع اختبار في SMEV.
يتم تبادل البيانات في بيئة صناعية لجميع أنواع المعلومات من خلال قنوات اتصال آمنة. جميع البيانات المرسلة مصحوبة بتوقيع رقمي إلكتروني ، بمساعدة SMEV يحدد المشاركين في التفاعل.
يتم إرسال البيانات عبر SOAP ، حيث تكون كل رسالة عبارة عن بنية متداخلة:
وتنقسم أنواع المعلومات إلى مجموعتين - بسيطة و عالمية . ضع في اعتبارك مخطط تبادل البيانات لنوع بسيط من المعلومات:
يوضح الرسم التخطيطي أنه يتم عرض بيانات النموذج مباشرة في مغلفات تبادل البيانات. لهذا السبب ، يظهر قيد: من الضروري تطوير هيكل كتلة البيانات والطلب / الاستجابة لكل نوع من أنواع المعلومات.
يمكن تمثيل التبادل بنوع عالمي من المعلومات على النحو التالي:
للوهلة الأولى ، قد يبدو المخطط أكثر تعقيدًا ، لكنه يوضح اختلافًا جوهريًا ، مما يبسط في النهاية التفاعل بين المشاركين في النوع الشامل للمعلومات (UDS). يتم إرسال بيانات النموذج المحدد في مرفق بمظروف SMEV ، ويتم إرسال علامات UMC ، التي تسمح بتحديد نوع المعلومات ، مباشرة في المظروف ولها نفس الهيكل لأي طائرة:
- رقم طلب البوابة والمعلومات التي تسمح بتحديد الخدمة ؛
- الوحدة المستهدفة التي يتقدم إليها المستخدم للحصول على الخدمة.
يتم تجميع بيانات النموذج التي يملأها مستخدم البوابة الإلكترونية في مرفق بالرسالة الرئيسية.
وبالتالي ، يمكنك إضفاء الطابع الرسمي على تقديم أي خدمة تقريبًا دون الحاجة إلى المرور عبر التسجيل الصعب لنوع جديد من المعلومات.
قوائم انتظار الرسائل وعملية الاتصال
أثناء الاتصال ، يتم وضع الرسائل في قوائم انتظار الطلبات الواردة وقوائم انتظار الاستجابة الواردة . في جوهرها ، قوائم الانتظار هي حاويات تحتوي على رسائل حسب نوع المعلومات.
يحدث التفاعل مع قوائم الانتظار باستخدام طلبات خاصة. تم وصفها بمزيد من التفصيل في المبادئ التوجيهية للعمل مع SMEV. نلاحظ فقط أنه بفضل قوائم الانتظار ، يصبح تبادل البيانات غير المتزامن ممكنًا: يمكن للمستهلك ترك طلب لتلقي المعلومات ، ويمكن للمورد نشر رد.
تذكر: لالتقاط رسالة من قائمة الانتظار ، يجب عليك تأكيد الاستلام من خلال طلب Ack. خلاف ذلك ، سوف يعتبر SMEV أن الرسالة لم يتم تسليمها وسيعيدها إلى قائمة الانتظار بعد 15 دقيقة من الاسترداد.
يمكن أن يتلقى كل طلب إما استجابة ناجحة أو غير ناجحة.
دعونا نتخيل أنفسنا في دور مزود المعلومات: عند الطلب ، نصدر للمستخدم خطة تخطيط مدينة لقطعة أرض ، وداخل إدارتنا هناك عدة أقسام إقليمية ، بعضها لا يقدم مثل هذه الخدمة على الإطلاق. لنفترض أن مستخدم البوابة الإلكترونية ، عند تكوين تطبيق لخدمة ما ، أشار إلى قسم فرعي لا يوفر الخدمة. يمكن أن ينشأ هذا الموقف لسببين:
- كان هناك تناقض بين البيانات المرجعية على البوابة والمورد ؛
- المطابقة المطلوبة ببساطة غير متوفرة في إعدادات نظام المورد.
في كلتا الحالتين ، يجب على الموفر الاستجابة للطلب حتى يتمكن الطرف المتلقي من فهم فشل الطلب وربما اتخاذ إجراء. يتم الرد على هذا الطلب في حزمة بيانات خاصة مع معلومات حول سبب الرفض.
تفترض الاستجابة الناجحة سيناريو تكون فيه نتيجة الخدمة عبارة عن مجموعة من الملفات (وهو أمر شائع جدًا). قبل إرسال النتيجة ، من الضروري تحميل الملفات إلى وحدة تخزين ملفات SMEV على أساس خادم FTP. يجب أن يتم تسجيل أسماء الملفات والمجموعات الاختبارية الخاصة بها في الحزمة التي يتم إرسالها عبر SOAP. وبالتالي ، هناك عمليتان لنقل البيانات يجب ربطهما بسياق مشترك - معلومات الملف.
في الممارسة العملية ، هناك حالات عندما يكون SMEV ، أثناء التفاعل ، في وضع الخدمة ، وتتضح أن طلبات المشارك فاشلة وتتطلب إعادة الإرسال. يجب تسجيل الفشل وإعادة تقديم الطلب.
صياغة المشكلة
مع الأخذ في الاعتبار الميزات المذكورة أعلاه ، كان على فريقنا ضمان تكامل IS الخاص بالعميل مع "Gosuslugi" بنوع عالمي من المعلومات . نظام معلومات العميل - IAS "Gradostroystvo" . بمساعدتها ، يمكن لمستخدمي الإدارات المسؤولة عن توفير الخدمات جمع حزم من المستندات وإنشاء نتائج لمزيد من الإرسال إلى البوابة عبر SMEV.
لذا ، لا يمكن استبعاد SMEV ، كما في القول عن كلمات الأغنية ، من حل مشكلة التكامل مع بوابة الخدمات العامة. لكن هذا للأفضل: بفضل النظام ، يتمتع جميع المشاركين ببيئة تفاعل عالمية. يتيح لك ذلك الاعتماد على معيار معين وعدم إعادة اختراع العجلة.
في المقالات التالية ، سننظر في كيفية تنظيم معالجة البيانات استنادًا إلى بيانات المستخدم باستخدام محرك أتمتة عمليات الأعمال Workflow Core ، إلى جانب مزود المعلومات.