حول عميل الويب 1C

إحدى الميزات الرائعة لتقنية 1C:Enterprise هي أن حل التطبيق، الذي تم تطويره باستخدام تقنية النماذج المُدارة، يمكن إطلاقه في عميل رفيع (قابل للتنفيذ) لأنظمة Windows وLinux وMacOS X وكعميل ويب لـ 5 متصفحات - Chrome وInternet Explorer وFirefox وSafari وEdge وكل هذا دون تغيير الكود المصدري للتطبيق. علاوة على ذلك، يبدو التطبيق خارجيًا في جهاز العميل الرقيق وفي المتصفح متطابقًا تقريبًا.
ابحث عن 10 اختلافات (صورتان تحت القطع):

نافذة العميل الرقيقة على Linux:

نفس النافذة في عميل الويب (في متصفح Chrome):

لماذا قمنا بإنشاء عميل ويب؟ وبعبارة مثيرة للشفقة إلى حد ما، فقد حدد لنا الوقت مثل هذه المهمة. لقد كان العمل عبر الإنترنت منذ فترة طويلة شرطًا أساسيًا لتطبيقات الأعمال. أولاً، أضفنا القدرة على العمل عبر الإنترنت لعميلنا الرقيق (بالمناسبة، توقف بعض منافسينا عند هذا؛ بينما تخلى آخرون، على العكس من ذلك، عن العميل الرقيق واقتصروا على تنفيذ عميل الويب). قررنا أن نمنح مستخدمينا الفرصة لاختيار خيار العميل الذي يناسبهم بشكل أفضل.

كانت إضافة الإمكانات المستندة إلى الويب إلى العميل الرقيق مشروعًا كبيرًا مع تغيير كامل في بنية خادم العميل. يعد إنشاء عميل ويب مشروعًا جديدًا تمامًا، يبدأ من الصفر.

صياغة المشكلة

لذا، متطلبات المشروع: يجب على عميل الويب أن يفعل نفس الشيء الذي يفعله العميل الرقيق، وهي:

1. عرض واجهة المستخدم
2. تنفيذ كود العميل المكتوب بلغة 1C

يتم وصف واجهة المستخدم في 1C في محرر مرئي، ولكن بشكل تصريحي، بدون ترتيب العناصر بكسل تلو الآخر؛ يتم استخدام حوالي ثلاثين نوعًا من عناصر الواجهة - الأزرار، وحقول الإدخال (النص، والأرقام، والتاريخ/الوقت)، والقوائم، والجداول، والرسوم البيانية، وما إلى ذلك.

يمكن أن يحتوي رمز العميل بلغة 1C على مكالمات الخادم والعمل مع الموارد المحلية (الملفات وما إلى ذلك) والطباعة وغير ذلك الكثير.

يستخدم كل من العميل الرقيق (عند العمل عبر الويب) وعميل الويب نفس مجموعة خدمات الويب للتواصل مع خادم تطبيقات 1C. تختلف تطبيقات العميل بالطبع - فالعميل الرقيق مكتوب بلغة C++، وعميل الويب مكتوب بلغة JavaScript.

القليل من التاريخ

بدأ مشروع عميل الويب في عام 2006، بفريق مكون من (في المتوسط) 5 أشخاص. في مراحل معينة من المشروع، شارك المطورون في تنفيذ وظائف محددة (وثيقة جدول البيانات، والرسوم البيانية، وما إلى ذلك)؛ كقاعدة عامة، كان هؤلاء هم نفس المطورين الذين قاموا بهذه الوظيفة في العميل الرقيق. أولئك. أعاد المطورون كتابة المكونات في JavaScript التي قاموا بإنشائها مسبقًا في C++.

منذ البداية، رفضنا فكرة أي تحويل تلقائي (ولو جزئي) لكود العميل الرقيق C++ إلى عميل الويب JavaScript بسبب الاختلافات المفاهيمية القوية بين اللغتين؛ تمت كتابة عميل الويب بلغة JavaScript من البداية.

في التكرارات الأولى للمشروع، قام عميل الويب بتحويل كود العميل بلغة 1C المضمنة مباشرة إلى JavaScript. يعمل العميل الرقيق بشكل مختلف - يتم تجميع التعليمات البرمجية الموجودة في لغة 1C المضمنة في رمز بايت، ثم يتم تفسير هذا الرمز الثانوي على العميل. بعد ذلك، بدأ عميل الويب في فعل الشيء نفسه - أولا، أعطى زيادة في الأداء، وثانيا، جعل من الممكن توحيد بنية العملاء الرفيعين والويب.

تم إصدار الإصدار الأول من منصة 1C:Enterprise مع دعم عميل الويب في عام 2009. كان عميل الويب في ذلك الوقت يدعم متصفحين - Internet Explorer وFirefox. تضمنت الخطط الأصلية دعمًا لـ Opera، ولكن بسبب مشاكل لا يمكن التغلب عليها في ذلك الوقت مع معالجات إغلاق التطبيق في Opera (لم يكن من الممكن التتبع بنسبة 2٪ أن التطبيق كان مغلقًا، وفي تلك اللحظة تنفيذ إجراء قطع الاتصال من خادم التطبيق 100C) من هذه الخطط.

هيكل المشروع

في المجمل، تحتوي منصة 1C:Enterprise على 4 مشاريع مكتوبة بلغة JavaScript:

1. WebTools - المكتبات المشتركة التي تستخدمها المشاريع الأخرى (نقوم أيضًا بتضمين مكتبة جوجل الختامية).
2. عنصر التحكم تنسيق المستند (يتم تنفيذه في JavaScript في كل من العميل الرقيق وعميل الويب)
3. عنصر التحكم مخطط (يتم تنفيذه في JavaScript في كل من العميل الرقيق وعميل الويب)
4. العميل على شبكة الإنترنت

تشبه بنية كل مشروع بنية مشاريع Java (أو مشاريع .NET - أيهما أقرب)؛ لدينا مساحات أسماء، وكل مساحة اسم موجودة في مجلد منفصل. يوجد داخل المجلد ملفات وفئات مساحة الاسم. يوجد حوالي 1000 ملف في مشروع عميل الويب.

من الناحية الهيكلية، ينقسم عميل الويب إلى حد كبير إلى الأنظمة الفرعية التالية:

• واجهة تطبيق العميل المُدارة
  • واجهة التطبيق العامة (قوائم النظام واللوحات)
  • واجهة النماذج المُدارة، بما في ذلك، من بين أمور أخرى، حوالي 30 عنصر تحكم (أزرار، وأنواع مختلفة من حقول الإدخال - النص، والأرقام، والتاريخ/الوقت، وما إلى ذلك، والجداول، والقوائم، والرسوم البيانية، وما إلى ذلك)

• نموذج الكائن متاح للمطورين على العميل (أكثر من 400 نوع إجمالاً: نموذج كائن الواجهة المُدارة، وإعدادات تخطيط البيانات، والتصميم الشرطي، وما إلى ذلك)
• مترجم للغة 1C المدمجة
• ملحقات المتصفح (تُستخدم للوظائف غير المدعومة في JavaScript)
  • العمل مع التشفير
  • العمل مع الملفات
  • تكنولوجيا المكونات الخارجية، مما يسمح باستخدامها في كل من الأجهزة العميلة والويب

ميزات التطوير

إن تنفيذ كل ما سبق في JavaScript ليس بالأمر السهل. ربما يكون عميل الويب 1C أحد أكبر التطبيقات من جانب العميل المكتوبة بلغة JavaScript - حوالي 450.000 سطر. نحن نستخدم بنشاط نهجًا موجهًا للكائنات في كود عميل الويب، مما يبسط العمل مع مثل هذا المشروع الكبير.

لتقليل حجم رمز العميل، استخدمنا أولاً أداة التعتيم الخاصة بنا، وبدءًا من إصدار النظام الأساسي 8.3.6 (أكتوبر 2014) بدأنا في استخدامه مترجم إغلاق جوجل. تأثير الاستخدام بالأرقام – حجم إطار عمل عميل الويب بعد التشويش:

• أداة التعتيم الخاصة – 1556 كيلو بايت
• مترجم إغلاق جوجل – 1073 كيلو بايت

ساعدنا استخدام Google Closure Compiler على تحسين أداء عميل الويب بنسبة 30% مقارنةً بأداة التعتيم الخاصة بنا. بالإضافة إلى ذلك، انخفض مقدار الذاكرة التي يستهلكها التطبيق بنسبة 15-25% (حسب المتصفح).

يعمل Google Closure Compiler بشكل جيد جدًا مع التعليمات البرمجية الموجهة للكائنات، لذا فإن كفاءته لعميل الويب تكون عالية قدر الإمكان. يقوم برنامج Closure Compiler ببعض الأشياء الجيدة لنا:

• التحقق من النوع الثابت في مرحلة إنشاء المشروع (يضمن أننا نغطي الكود بتعليقات JSDoc التوضيحية). والنتيجة هي كتابة ثابتة، قريبة جدًا من مستوى الكتابة بلغة C++. يساعد هذا في اكتشاف نسبة كبيرة إلى حد ما من الأخطاء في مرحلة تجميع المشروع.
• تقليل حجم الكود من خلال التشويش
• عدد من التحسينات على التعليمات البرمجية المنفذة، على سبيل المثال، مثل:
  • بدائل الوظائف المضمنة. يعد استدعاء دالة في JavaScript عملية مكلفة إلى حد ما، كما أن الاستبدالات المضمنة للطرق الصغيرة المستخدمة بشكل متكرر تعمل على تسريع التعليمات البرمجية بشكل كبير.
  • حساب الثوابت في وقت الترجمة. إذا كان التعبير يعتمد على ثابت، فسيتم استبدال القيمة الفعلية للثابت فيه

نحن نستخدم WebStorm كبيئة تطوير عميل الويب لدينا.

لتحليل الكود نستخدم سونار كيوب، حيث نقوم بدمج محللي التعليمات البرمجية الثابتة. باستخدام أدوات التحليل، نقوم بمراقبة تدهور جودة كود مصدر JavaScript ونحاول منعه.

ما هي المشاكل التي قمنا بحلها/التي نقوم بحلها؟

أثناء تنفيذ المشروع، واجهنا عددًا من المشكلات المثيرة للاهتمام التي كان علينا حلها.

تبادل البيانات مع الخادم وبين النوافذ

هناك حالات يمكن أن يتداخل فيها تشويش التعليمات البرمجية المصدر مع تشغيل النظام. قد تحتوي التعليمات البرمجية الخارجية للتعليمات البرمجية القابلة للتنفيذ لعميل الويب، بسبب التشويش، على أسماء وظائف ومعلمات تختلف عن تلك التي تتوقعها التعليمات البرمجية القابلة للتنفيذ الخاصة بنا. الكود الخارجي بالنسبة لنا هو:

• التعليمات البرمجية القادمة من الخادم في شكل هياكل البيانات
• رمز لنافذة تطبيق أخرى

لتجنب التشويش عند التفاعل مع الخادم، نستخدم علامة @expose:

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

ولتجنب التشويش عند التفاعل مع النوافذ الأخرى، نستخدم ما يسمى بالواجهات المصدرة (الواجهات التي يتم تصدير جميع الأساليب فيها).

/**
 * Экспортируемый интерфейс контрола DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 * Перемещает выделение на 1 вперед или назад
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 * Перемещает выделение в начало или конец
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

لقد استخدمنا Virtual DOM قبل أن يصبح سائدًا)

مثل جميع المطورين الذين يتعاملون مع واجهات مستخدم الويب المعقدة، أدركنا بسرعة أن DOM غير مناسب للعمل مع واجهات المستخدم الديناميكية. على الفور تقريبًا، تم تنفيذ نظير Virtual DOM لتحسين العمل مع واجهة المستخدم. أثناء معالجة الأحداث، يتم تخزين جميع تغييرات DOM في الذاكرة، وفقط عند اكتمال جميع العمليات، يتم تطبيق التغييرات المتراكمة على شجرة DOM.

تحسين عميل الويب

لجعل عميل الويب الخاص بنا يعمل بشكل أسرع، نحاول استخدام إمكانيات المتصفح القياسية (CSS، وما إلى ذلك) إلى أقصى حد. وبالتالي، يتم عرض لوحة أوامر النموذج (الموجودة في كل نموذج من أشكال التطبيق تقريبًا) حصريًا باستخدام أدوات المتصفح، باستخدام التخطيط الديناميكي المستند إلى CSS.

تجريب

بالنسبة للاختبارات الوظيفية واختبارات الأداء، نستخدم أداتنا الخاصة (المكتوبة بلغة Java وC++)، بالإضافة إلى مجموعة من الاختبارات المبنية على الأساس عنصر السيلينيوم.

أداتنا عالمية - فهي تسمح لك باختبار أي برنامج مثبت عليه إطارات تقريبًا، وبالتالي فهي مناسبة لاختبار كل من العميل الرقيق وعميل الويب. تسجل الأداة تصرفات المستخدم الذي أطلق حل تطبيق 1C في ملف نصي. وفي الوقت نفسه، يتم تسجيل صور منطقة عمل الشاشة – المعايير. عند مراقبة الإصدارات الجديدة من عميل الويب، يتم تشغيل البرامج النصية دون مشاركة المستخدم. في الحالات التي لا تتطابق فيها لقطة الشاشة مع المرجع في أي خطوة، يعتبر الاختبار فاشلاً، وبعد ذلك يقوم متخصص الجودة بإجراء تحقيق لتحديد ما إذا كان هذا خطأ أو تغيير مخطط له في سلوك النظام. في حالة السلوك المخطط، يتم استبدال المعايير تلقائيًا بمعايير جديدة.

تقوم الأداة أيضًا بقياس أداء التطبيق بدقة تصل إلى 25 مللي ثانية. في بعض الحالات، نقوم بتكرار أجزاء من البرنامج النصي (على سبيل المثال، تكرار إدخال الأمر عدة مرات) لتحليل تدهور وقت التنفيذ بمرور الوقت. يتم تسجيل نتائج جميع القياسات في سجل للتحليل.

أداة الاختبار والتطبيق لدينا قيد الاختبار

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

تُجري الاختبارات على كلا الأداتين (أداتنا وسيلينيوم) سيناريوهات عمل نموذجية من حلول التطبيقات الخاصة بنا. يتم إطلاق الاختبارات تلقائيًا بعد الإنشاء اليومي لمنصة 1C:Enterprise. إذا كانت البرامج النصية أبطأ (مقارنة بالإصدار السابق)، فإننا نقوم بالتحقيق في سبب التباطؤ وحله. معيارنا بسيط - يجب ألا يعمل التصميم الجديد بشكل أبطأ من الإصدار السابق.

يستخدم المطورون أدوات مختلفة للتحقيق في حوادث التباطؤ؛ تستخدم بشكل رئيسي إصدار Dynatrace AJAX شركة إنتاج DynaTrace. يتم تسجيل سجلات تنفيذ العملية الإشكالية على الإصدارات السابقة والجديدة، ثم يتم تحليل السجلات. في الوقت نفسه، قد لا يكون وقت تنفيذ العمليات الفردية (بالمللي ثانية) عاملا حاسما - يتم تشغيل عمليات الخدمة مثل جمع البيانات المهملة بشكل دوري في المتصفح، ويمكن أن تتداخل مع وقت تنفيذ الوظائف وتشويه الصورة. المعلمات الأكثر صلة في هذه الحالة ستكون عدد تعليمات JavaScript المنفذة، وعدد العمليات الذرية على DOM، وما إلى ذلك. إذا زاد عدد التعليمات/العمليات في نفس البرنامج النصي في إصدار جديد، فهذا يعني دائمًا انخفاضًا في الأداء يجب تصحيحه.

أيضًا، قد يكون أحد أسباب انخفاض الأداء هو أن Google Closure Compiler لسبب ما لم يتمكن من إجراء استبدال مضمن للوظيفة (على سبيل المثال، لأن الوظيفة متكررة أو افتراضية). في هذه الحالة، نحاول تصحيح الوضع عن طريق إعادة كتابة الكود المصدري.

ملحقات المتصفح

عندما يحتاج حل التطبيق إلى وظيفة غير متوفرة في JavaScript، فإننا نستخدم ملحقات المتصفح:

• للعمل مع الملفات
• للعمل مع التشفير
• يعمل مع المكونات الخارجية

ملحقاتنا تتكون من جزأين. الجزء الأول هو ما يسمى بامتداد المتصفح (عادةً امتدادات لمتصفح Chrome وFirefox مكتوبة بلغة JavaScript)، والتي تتفاعل مع الجزء الثاني - وهو امتداد ثنائي ينفذ الوظيفة التي نحتاجها. تجدر الإشارة إلى أننا نكتب 3 إصدارات من الامتدادات الثنائية - لأنظمة التشغيل Windows وLinux وMacOS. يتم توفير الامتداد الثنائي كجزء من النظام الأساسي 1C:Enterprise ويقع على خادم التطبيقات 1C. عند استدعائه لأول مرة من عميل ويب، يتم تنزيله إلى جهاز الكمبيوتر العميل وتثبيته في المتصفح.

عند التشغيل في Safari، تستخدم ملحقاتنا NPAPI، وعند التشغيل في Internet Explorer، فإنها تستخدم تقنية ActiveX. مايكروسوفت الحافة لا يدعم الامتدادات بعد، لذلك يعمل عميل الويب فيه مع القيود.

مزيد من التطوير

إحدى مهام فريق تطوير عميل الويب هي التطوير الإضافي للوظائف. يجب أن تكون وظيفة عميل الويب مماثلة لوظيفة العميل الرقيق، حيث يتم تنفيذ جميع الوظائف الجديدة في وقت واحد في كل من عملاء الويب والعملاء الرقيقين.

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

المصدر: www.habr.com