Om webbklienten 1C

En av de trevliga egenskaperna med teknologin 1C:Enterprise är att applikationslösningen, som utvecklats med hjälp av tekniken för hanterade formulär, kan köras både i en tunn (exekveringsbar) klient på Windows, Linux, MacOS X och som webbklient i fem webbläsare - Chrome, Internet Explorer, Firefox, Safari, Edge, och allt detta - utan att ändra källkoden för applikationen. Dessutom fungerar och ser applikationen i den tunna klienten och i webbläsaren praktiskt taget identiskt ut.
Hitta 10 skillnader (under bilden 2 bilder):

Fönstret för den tunna klienten på Linux:

Samma fönster i webbklienten (i webbläsaren Chrome):

Varför skapade vi en webbklient? För att säga det lite pompöst, ställde tiden en sådan uppgift för oss. Det har länge varit nödvändigt att arbeta via Internet för affärsapplikationer. Till en början tillade vi möjligheten att arbeta via Internet för vår tunna klient (vissa av våra konkurrenter, för övrigt, stannade där; andra, tvärtom, övergav den tunna klienten och begränsade sig till att implementera webbklienten). Vi bestämde oss för att ge våra användare möjlighet att välja den klientversion som passar dem bäst.

Att lägga till möjligheten att arbeta via Internet för den tunna klienten var ett stort projekt med en fullständig förändring av arkitekturen för klient-server interaktion. Skapandet av webbklienten var en helt ny projekt som började från grunden.

Uppgiftsställande

Så, kraven för projektet: webbklienten ska göra samma sak som den tunna klienten, nämligen:

1. Visa användargränssnittet
2. Köra klientkod skriven i 1C-språket

Användargränssnittet i 1C beskrivs i en visuell redigerare, men deklarativt, utan pixel-mässig placering av element; cirka tre dussin typer av gränselement används - knappar, inmatningsfält (text, siffra, datum/tid), listor, tabeller, diagram osv.

Klientkoden i 1C-språket kan innehålla serveranrop, arbete med lokala resurser (filer etc.), utskrift och mycket mer.

Både den tunna klienten (vid arbete via webben) och webbklienten använder samma uppsättning webbservrar för kommunikation med 1C:s applikationsserver. Implementeringen hos klienterna är naturligtvis olika - den tunna klienten är skriven i C++, webbklienten - i JavaScript.

Lite historia

Projektet med att skapa en webbkund påbörjades 2006 och involverade i genomsnitt ett team på 5 personer. Vid olika skeden av projektet anlitades utvecklare för att implementera specifik funktionalitet (tabeller, diagram etc.); som regel var det samma utvecklare som hade skapat denna funktionalitet för den tunna klienten. Det vill säga, utvecklarna skrev om komponenter på JavaScript som de tidigare hade skapat i C++.

Redan från början avfärdade vi idén om någon form av automatisk (även partiell) konvertering av C++-koden från den tunna klienten till JavaScript-webbkunden med hänvisning till de stora konceptuella skillnaderna mellan de två språken; webbkunden skrevs i JavaScript från grunden.

I de första iterationerna av projektet konverterade webbkunden klientkoden i det inbyggda språket 1C direkt till JavaScript. Den tunna klienten fungerar annorlunda – koden i det inbyggda språket 1C kompileras till bytekod, och denna bytekod tolkas sedan på klienten. Senare började även webbkunden göra likadant – först och främst gav det en prestandaförbättring, för det andra möjliggjorde det en enhetlig arkitektur för den tunna och webbkunden.

Den första versionen av plattformen 1C:Enterprise med stöd för webbkunden släpptes 2009. Vid det tillfället stödde webbkunden två webbläsare – Internet Explorer och Firefox. I de ursprungliga planerna fanns stöd för Opera, men på grund av oöverkomliga problem med händelsehanterare för stängning av applikationen i Opera (vi kunde inte med 100% säkerhet spåra att applikationen stängdes, och vid den tiden utföra proceduren för att koppla ifrån 1C-applikationsservern) var vi tvungna att ge upp dessa planer.

Projektstruktur

Det finns totalt 4 projekt inom plattformen 1C:Enterprise som är skrivna i JavaScript:

1. WebTools – allmänna bibliotek som används av de övriga projekten (här inkluderas också Google Closure Library).
2. Kontrollelement FormateradDokument (implementerad i både JavaScript och i den tunna klienten och webbkunden)
3. Kontrollelement Schemaläggare (implementerad i både JavaScript och i den tunna klienten och webbkunden)
4. Webbkund

Strukturen för varje projekt påminner om strukturen för Java-projekt (eller .NET-projekt – vad som känns närmare); vi har namnrymder, där varje namnrymd ligger i en egen mapp. Inuti mappen ligger filer och klasser under namnrymden. I webbkundens projekt finns det cirka 1000 filer.

Strukturmässigt delas webbkunden grovt upp i följande delsystem:

• Hantera gränssnittet för kundapplikationen
  • Det gemensamma applikationsgränssnittet (systemmenyer, paneler)
  • Gränssnitt för hanterade formulär med cirka 30 kontrollobjekt (knappar, olika typer av inmatningsfält – text, numeriska, datum/tid m.m., tabeller, listor, diagram, osv.)

• Objektmodellen som är tillgänglig för utvecklare på klienten (över 400 typer: objektmodellen för det hanterade gränssnittet, datalayoutinställningar, villkorlig formatering, osv.)
• Tolk för det inbyggda språket 1C
• Webbläsartillägg (används för funktionalitet som inte stöds av JavaScript)
  • Arbete med kryptografi
  • Arbete med filer
  • Teknik för externa komponenter som gör det möjligt att använda dem både i tunn och webklient

Utvecklingsfunktioner

Att implementera allt ovanstående i JavaScript är en utmaning. Kanske är webklienten 1C ett av de största klientbaserade programmen skrivna i JavaScript – cirka 450.000 rader. Vi använder aktivt objektorienterad programmering i koden för webklienten, vilket förenklar arbetet med ett så stort projekt.

För att minimera storleken på klientkoden använde vi först vår egen obfuskator, men från och med version 8.3.6 (oktober 2014) började vi använda Google Closure Compiler. Effekten av användningen i siffror – storleken på ramverket för webklienten efter obfuskering:

• Egen obfuskator – 1556 kB
• Google Closure Compiler – 1073 kB

Användningen av Google Closure Compiler har hjälpt oss att öka prestandan för webklienten med 30 % jämfört med vår egen obfuskator. Dessutom minskade minnesanvändningen för applikationen med 15-25 % (beroende på webbläsare).

Google Closure Compiler fungerar mycket bra med objektorienterad kod, vilket maximerar dess effektivitet för webklienten. Closure Compiler gör flera bra saker för oss:

• Statisk typkontroll vid byggfasen av projektet (garanteras genom att vi täcker koden med JSDoc-annoteringar). Slutresultatet blir statisk typning som är mycket nära den i C++. Detta hjälper till att fånga en stor andel av felen i projektets kompilering.
• Minskning av kodens storlek genom obfuskering
• En rad optimeringar av den körda koden, såsom:
  • inline-inbäddningar av funktioner. Funktionanrop i JavaScript är en ganska kostsam operation, och inline-inbäddningar av ofta använda små metoder påskyndar kodens arbete avsevärt.
  • Beräkning av konstanter vid kompilering. Om uttrycket beror på en konstant, kommer det faktiska värdet på konstanten att infogas.

Som utvecklingsmiljö för webbkunden använder vi WebStorm.

För kodanalys använder vi SonarQube, dit vi integrerar statiska kodanalysatorer. Med hjälp av analysatorerna övervakar vi nedgången av kvaliteten på källkoden i JavaScript och försöker undvika det.

Vilka uppgifter har vi löst/löser?

Under genomförandet av projektet stötte vi på en rad intressanta uppgifter som vi var tvungna att lösa.

Datakommunikation med servern och mellan fönster

Det finns situationer där obfuscering av källkoden kan störa systemets funktion. Koden som är extern i förhållande till den körbara koden för webbkunden kan på grund av obfusceringen ha funktions- och parameter-namn som skiljer sig från de som vår körbara kod förväntar sig. Den externa koden för oss är:

• Koden som kommer från servern i form av datatyper
• Koden från ett annat applikationsfönster

För att undvika obfuscering vid interaktion med servern använder vi taggen @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;
}

Och för att undvika obfuscering vid interaktion med andra fönster använder vi så kallade exporterade gränssnitt (gränssnitt där alla metoder är exporterade).

/**
 * Экспортируемый интерфейс контрола 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 (){}

Vi använde Virtual DOM innan det blev mainstream)

Som alla utvecklare som arbetar med komplexa webb-UI insåg vi snabbt att DOM är dåligt lämpad för att arbeta med dynamiska användargränssnitt. Nästan omedelbart implementerade vi en kopia av Virtual DOM för att optimera arbetet med UI. Under händelsebehandlingen sparas alla ändringar av DOM i minnet och först efter att alla operationer har slutförts tillämpas de samlade ändringarna på DOM-trädet.

Optimering av webbkundens arbete

För att vår webbkund ska fungera snabbare försöker vi utnyttja webbläsarens inbyggda funktioner så mycket som möjligt (CSS osv.). Således ritas kommandopanelen för formuläret (som är placerad på nästan varje formulär i applikationen) enbart med hjälp av webbläsarens medel, med dynamisk layout baserad på CSS.

Testning

För funktionell testning och prestandatestning använder vi ett in-house verktyg (skapat i Java och C++), samt en testuppsättning baserad på Selenium.

Vårt verktyg är mångsidigt – det möjliggör testning av praktiskt taget alla skrivbordsprogram, vilket gör det lämpligt för både tunn klient och webbklient. Verktyget registrerar användarens åtgärder som startar tillämpningen "1C" i en skriptfil. Samtidigt registreras bilder av skrivbordets arbetsområde – referenser. När nya versioner av webbklienten kontrolleras, körs skripten utan användarens medverkan. Vid avvikelser mellan skärmdumpen och referensen vid något steg anses testet ha misslyckats, och en kvalitetspecialist genomför en utredning – om det är ett fel eller en planerad förändring av systemets beteende. Vid planerat beteende ersätts referenserna automatiskt med nya.

Verktyget mäter också applikationernas prestanda med en noggrannhet på 25 millisekunder. I vissa fall slussar vi delar av skriptet (till exempel upprepar vi beställningsinmatningen flera gånger) för att analysera tidsdegradering över tid. Resultaten av alla mätningar loggas för analys.

Vårt testverktyg och den testade applikationen

Vårt verktyg och Selenium kompletterar varandra; till exempel kan Selenium ha svårt att spåra om en knapp på en av skärmarna har ändrat sin plats – men vårt verktyg kommer att märka det, eftersom det gör en pixel-för-pixel-jämförelse av skärmdumpen med referensen. Dessutom kan verktyget spåra problem med hantering av inmatning från tangentbord eller mus, eftersom det just reproducerar dessa.

Tester på båda verktygen (vårt och Selenium) kör typiska arbetsflöden från våra applikationer. Tester startas automatiskt efter den dagliga byggningen av plattformen "1C:Enterprise". Vid försämrad prestanda i skripten (jämfört med föregående byggnad) genomför vi en utredning för att fastställa orsaken till nedgången. Vår kriterium är enkel – den nya byggnaden ska inte vara långsammare än den föregående.

För att utreda incidenter av prestandaförsämringar använder utvecklarna olika verktyg; främst används Dynatrace AJAX Edition företaget DynaTrace. Loggfiler för problematiska operationer spelas in på både den tidigare och den nya versionen, och loggarna analyseras. I detta fall kan tiden för enskilda operationer (i millisekunder) vara mindre avgörande faktorer – i webbläsaren körs ibland tjänsteprocesser som skräpning, som kan påverka tiden för funktionsanrop och förvränga bilden. Mer relevanta parametrar i det här fallet är antalet utförda JavaScript-instruktioner och antalet atomära operationer på DOM, osv. Om antalet instruktioner/operationer i samma scenario i den nya versionen ökar – innebär det nästan alltid en försämring av prestandan som måste åtgärdas.

En annan anledning till prestandaförsämringen kan vara att Google Closure Compiler av någon anledning inte kunde utföra inline-substitution av en funktion (till exempel för att funktionen är rekursiv eller virtuell). I detta fall försöker vi åtgärda situationen genom att skriva om koden.

webbläsartillägg

Om den applikationslösning behöver funktionalitet som inte finns i JavaScript, använder vi webbläsartillägg:

• för filhantering
• för kryptografi
• arbete med externa komponenter

Våra tillägg består av två delar. Den första delen är det som kallas ett webbläsartillägg (som vanligtvis är skrivna i JavaScript för Chrome och Firefox) som interagerar med den andra delen - ett binärt tillägg som implementerar den funktionalitet vi behöver. Det bör nämnas att vi skriver tre versioner av binära tillägg – för Windows, Linux och MacOS. Det binära tillägget ingår i plattformen 1C:Enterprise och finns på 1C-applikationsservern. Vid första anropet från webbklienten laddas det ner till klientdatorn och installeras i webbläsaren.

Vid arbete i Safari använder våra tillägg NPAPI, medan de i Internet Explorer använder ActiveX-teknologin. Microsoft Edge stöder ännu inte tillägg, så webbklienten fungerar med begränsningar.

Vidare utveckling

En av uppgiftgrupperna för teamet som utvecklar webbklienten är att vidareutveckla funktionaliteten. Funktionaliteten i webbklienten ska vara identisk med funktionaliteten i den tunna klienten; all ny funktionalitet implementeras samtidigt både i den tunna och i webbklienten.

Andra uppgifter är att utveckla arkitekturen, refaktorisera, samt förbättra prestanda och tillförlitlighet. Ett exempel på detta är att vi rör oss mot en asynkron arbetsmodell. Delar av funktionaliteten i webbklienten är för närvarande byggda på en synkron interaktionsmodell med servern. Den asynkrona modellen blir nu mer relevant i webbläsare (och inte bara i webbläsare), och detta tvingar oss att modifiera webbklienten genom att ersätta synkrona anrop med asynkrona (och göra motsvarande refaktorisering av koden). Den gradvisa övergången till den asynkrona modellen förklaras av behovet att stödja tidigare lanserade lösningar och deras gradvisa anpassning.

Källa: habr.com