על לקוח האינטרנט של 1C

אחד המאפיינים הנחמדים של טכנולוגיית 1C:Enterprise הוא שניתן להשיק את פתרון האפליקציות, שפותח באמצעות טכנולוגיית טפסים מנוהלים, הן בלקוח דק (ניתן להרצה) עבור Windows, Linux, MacOS X, והן כלקוח אינטרנט עבור 5 דפדפנים - Chrome, Internet Explorer, Firefox, Safari, Edge, וכל זה מבלי לשנות את קוד המקור של האפליקציה. יתרה מכך, חיצונית האפליקציה בקליינט הדק ובדפדפן מתפקדת ונראית כמעט זהה.
מצא 10 הבדלים (2 תמונות מתחת לחיתוך):

חלון לקוח דק בלינוקס:

אותו חלון בלקוח האינטרנט (בדפדפן Chrome):

למה יצרנו לקוח אינטרנט? אם לומר זאת בצורה קצת פתטית, הזמן הציב לנו משימה כזו. עבודה דרך האינטרנט היא מזמן תנאי מוקדם ליישומים עסקיים. ראשית, הוספנו את היכולת לעבוד דרך האינטרנט עבור ה-Thin Client שלנו (חלק מהמתחרים שלנו, אגב, עצרו בכך; אחרים, להיפך, נטשו את ה-Thin Client והגבילו עצמם ליישום לקוח אינטרנט). החלטנו לתת למשתמשים שלנו את האפשרות לבחור את אפשרות הלקוח המתאימה להם ביותר.

הוספת יכולות מבוססות אינטרנט ללקוח הדק הייתה פרויקט גדול עם שינוי מוחלט בארכיטקטורת שרת-לקוח. יצירת לקוח אינטרנט הוא פרויקט חדש לחלוטין, שמתחיל מאפס.

הצהרת הבעיה

אז, דרישות הפרויקט: לקוח האינטרנט חייב לעשות את אותו הדבר כמו הלקוח הדק, כלומר:

1. הצגת ממשק משתמש
2. בצע קוד לקוח שנכתב בשפת 1C

ממשק המשתמש ב-1C מתואר בעורך ויזואלי, אך באופן הצהרתי, ללא סידור פיקסל-אחר-פיקסל של אלמנטים; כשלושה תריסר סוגי רכיבי ממשק משמשים - כפתורים, שדות קלט (טקסט, מספרי, תאריך/שעה), רשימות, טבלאות, גרפים וכו'.

קוד לקוח בשפת 1C יכול להכיל קריאות לשרת, עבודה עם משאבים מקומיים (קבצים וכו'), הדפסה ועוד הרבה יותר.

גם הלקוח הדק (כשעובדים דרך האינטרנט) וגם הלקוח האינטרנט משתמשים באותה סט של שירותי אינטרנט כדי לתקשר עם שרת היישומים 1C. הטמעות של לקוח, כמובן, שונות - הלקוח הדק כתוב ב-C++, לקוח האינטרנט כתוב ב-JavaScript.

קצת היסטוריה

פרויקט לקוח האינטרנט החל בשנת 2006, עם צוות של (בממוצע) 5 אנשים. בשלבים מסוימים של הפרויקט, מפתחים היו מעורבים ביישום פונקציונליות ספציפית (מסמך גיליון אלקטרוני, דיאגרמות וכו'); ככלל, אלה היו אותם מפתחים שעשו את הפונקציונליות הזו בלקוח הדק. הָהֵן. מפתחים כתבו מחדש רכיבים ב-JavaScript שיצרו בעבר ב-C++.

כבר מההתחלה, דחינו את הרעיון של כל המרה אוטומטית (אפילו חלקית) של קוד לקוח דק C++ ללקוח אינטרנט JavaScript בשל ההבדלים הרעיוניים החזקים בין שתי השפות; לקוח האינטרנט נכתב ב-JavaScript מאפס.

באיטרציות הראשונות של הפרויקט, לקוח האינטרנט המיר את קוד הלקוח בשפת 1C המובנית ישירות ל-JavaScript. הלקוח הדק פועל אחרת - הקוד בשפת 1C המובנית מקומפלט לתוך bytecode, ואז בייטקוד זה מתפרש על הלקוח. לאחר מכן, לקוח האינטרנט החל לעשות את אותו הדבר - ראשית, הוא נתן רווח ביצועים, ושנית, הוא איפשר לאחד את הארכיטקטורה של לקוחות הדקים והאינטרנט.

הגרסה הראשונה של פלטפורמת 1C:Enterprise עם תמיכה בלקוח אינטרנט שוחררה ב-2009. לקוח האינטרנט באותה תקופה תמך בשני דפדפנים - Internet Explorer ו-Firefox. התוכניות המקוריות כללו תמיכה ב-Opera, אך עקב בעיות בלתי פתירות באותה תקופה עם מטפלי סגירת אפליקציות ב-Opera (לא ניתן היה לעקוב בוודאות של 2% שהאפליקציה נסגרת, ובאותו רגע לבצע את הליך הניתוק מה- שרת יישומי 100C) מהתוכניות הללו נאלץ לנטוש.

מבנה הפרויקט

בסך הכל, לפלטפורמת 1C:Enterprise יש 4 פרויקטים שנכתבו ב-JavaScript:

1. WebTools - ספריות משותפות המשמשות פרויקטים אחרים (אנחנו כוללים גם ספריית הסגירה של גוגל).
2. לִשְׁלוֹט FormattedDocument (מיושם ב-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 עובד טוב מאוד עם קוד מונחה עצמים, כך שהיעילות שלו עבור לקוח האינטרנט גבוהה ככל האפשר. מהדר סגירה עושה לנו כמה דברים טובים:

• בדיקת סוג סטטית בשלב בניית הפרויקט (מבטיחה שאנו מכסים את הקוד עם הערות JSDoc). התוצאה היא הקלדה סטטית, קרובה מאוד ברמה להקלדה ב-C++. זה עוזר לתפוס אחוז גדול למדי של שגיאות בשלב הידור הפרויקט.
• צמצום גודל הקוד באמצעות ערפול
• מספר אופטימיזציות של הקוד המבוצע, למשל, כגון:
  • החלפות פונקציות מוטבעות. קריאה לפונקציה ב-JavaScript היא פעולה יקרה למדי, והחלפות מוטבעות של שיטות קטנות בשימוש תכוף מאיצות משמעותית את הקוד.
  • ספירת קבועים בזמן הידור. אם ביטוי תלוי בקבוע, הערך האמיתי של הקבוע יוחלף בו

אנו משתמשים ב-WebStorm כסביבת פיתוח לקוח האינטרנט שלנו.

לניתוח קוד אנו משתמשים soundQube, שבו אנו משלבים מנתחי קוד סטטיים. באמצעות מנתחים, אנו עוקבים אחר ירידה באיכות קוד המקור של 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, אנו משתמשים בתוספי דפדפן:

• לעבודה עם קבצים
• לעבודה עם קריפטוגרפיה
• לעבוד עם רכיבים חיצוניים

ההרחבות שלנו מורכבות משני חלקים. החלק הראשון הוא מה שנקרא הרחבת דפדפן (בדרך כלל הרחבות לכרום ופיירפוקס כתובות ב-JavaScript), המתקשרות עם החלק השני – הרחבה בינארית המיישמת את הפונקציונליות הדרושה לנו. יש להזכיר שאנו כותבים 3 גרסאות של הרחבות בינאריות - עבור Windows, Linux ו-MacOS. ההרחבה הבינארית מסופקת כחלק מפלטפורמת 1C:Enterprise וממוקמת בשרת היישומים 1C. כאשר קוראים לו בפעם הראשונה מלקוח אינטרנט, הוא מוריד למחשב הלקוח ומותקן בדפדפן.

כאשר פועלים ב-Safari, התוספים שלנו משתמשים ב-NPAPI; כאשר הם פועלים ב-Internet Explorer, הם משתמשים בטכנולוגיית ActiveX. אדג מיקרוסופט עדיין לא תומך בהרחבות, כך שלקוח האינטרנט בו עובד עם הגבלות.

פיתוח עתידי

אחת המשימות של צוות הפיתוח של לקוחות אינטרנט היא המשך פיתוח הפונקציונליות. הפונקציונליות של לקוח האינטרנט צריכה להיות זהה לפונקציונליות של הלקוח הדק; כל הפונקציונליות החדשה מיושמת בו-זמנית הן בלקוחות הדק והן בלקוחות האינטרנט.

משימות אחרות כוללות פיתוח הארכיטקטורה, עיבוד מחדש, שיפור ביצועים ואמינות. לדוגמה, אחד הכיוונים הוא תנועה נוספת לעבר מודל עבודה אסינכרוני. חלק מהפונקציונליות של לקוח האינטרנט בנויה כיום על מודל סינכרוני של אינטראקציה עם השרת. המודל האסינכרוני הופך כעת לרלוונטי יותר בדפדפנים (ולא רק בדפדפנים), וזה מאלץ אותנו לשנות את לקוח האינטרנט על ידי החלפת שיחות סינכרוניות באסינכרוניות (ולפירוק מחדש של הקוד בהתאם). המעבר ההדרגתי למודל אסינכרוני מוסבר בצורך לתמוך בפתרונות שפורסמו ובהתאמתם ההדרגתית.

מקור: www.habr.com