Eines der schönen Features der 1C:Enterprise-Technologie ist, dass die Anwendungslösung, die mithilfe der Managed-Forms-Technologie entwickelt wurde, sowohl in einem Thin (ausführbaren) Client für Windows, Linux, MacOS X als auch als Web-Client für 5 Browser gestartet werden kann – Chrome, Internet Explorer, Firefox, Safari, Edge und das alles, ohne den Quellcode der Anwendung zu ändern. Darüber hinaus funktionieren und sehen die Anwendungen im Thin Client und im Browser äußerlich nahezu identisch.
Finden Sie 10 Unterschiede (2 Bilder unter dem Schnitt):
Thin-Client-Fenster unter Linux:
Das gleiche Fenster im Webclient (im Chrome-Browser):
Warum haben wir einen Web-Client erstellt? Um es etwas pathetisch auszudrücken: Die Zeit hat uns vor eine solche Aufgabe gestellt. Das Arbeiten über das Internet ist seit langem eine Voraussetzung für Geschäftsanwendungen. Erstens haben wir für unseren Thin Client die Möglichkeit hinzugefügt, über das Internet zu arbeiten (einige unserer Konkurrenten haben übrigens damit aufgehört; andere hingegen haben den Thin Client aufgegeben und sich auf die Implementierung eines Webclients beschränkt). Wir haben uns entschieden, unseren Benutzern die Möglichkeit zu geben, die Client-Option auszuwählen, die am besten zu ihnen passt.
Das Hinzufügen webbasierter Funktionen zum Thin Client war ein großes Projekt mit einer kompletten Änderung der Client-Server-Architektur. Das Erstellen eines Webclients ist ein völlig neues Projekt, das bei Null beginnt.
Formulierung des Problems
Also die Projektanforderungen: Der Webclient muss das Gleiche tun wie der Thin Client, nämlich:
- Benutzeroberfläche anzeigen
- Führen Sie Client-Code aus, der in der 1C-Sprache geschrieben ist
Die Benutzeroberfläche in 1C wird in einem visuellen Editor beschrieben, jedoch deklarativ, ohne pixelweise Anordnung der Elemente; Es werden etwa drei Dutzend Arten von Oberflächenelementen verwendet – Schaltflächen, Eingabefelder (Text, numerisch, Datum/Uhrzeit), Listen, Tabellen, Grafiken usw.
Clientcode in der 1C-Sprache kann Serveraufrufe, Arbeiten mit lokalen Ressourcen (Dateien usw.), Drucken und vieles mehr enthalten.
Sowohl der Thin Client (bei der Arbeit über das Web) als auch der Webclient nutzen für die Kommunikation mit dem 1C-Anwendungsserver die gleichen Webdienste. Client-Implementierungen sind natürlich unterschiedlich – der Thin Client ist in C++ geschrieben, der Web-Client ist in JavaScript geschrieben.
Ein wenig Geschichte
Das Web-Client-Projekt startete 2006 mit einem Team von (durchschnittlich) 5 Personen. In bestimmten Phasen des Projekts waren Entwickler beteiligt, um bestimmte Funktionen (Tabellenkalkulationsdokumente, Diagramme usw.) zu implementieren. In der Regel handelte es sich dabei um dieselben Entwickler, die diese Funktionalität im Thin Client realisiert haben. Diese. Entwickler haben Komponenten in JavaScript neu geschrieben, die sie zuvor in C++ erstellt hatten.
Aufgrund der starken konzeptionellen Unterschiede zwischen den beiden Sprachen lehnten wir von Anfang an die Idee einer automatischen (auch teilweisen) Konvertierung von C++-Thin-Client-Code in einen JavaScript-Webclient ab; Der Webclient wurde von Grund auf in JavaScript geschrieben.
In den ersten Iterationen des Projekts konvertierte der Webclient Clientcode in der integrierten 1C-Sprache direkt in JavaScript. Der Thin Client verhält sich anders – der Code in der integrierten 1C-Sprache wird in Bytecode kompiliert und dieser Bytecode wird dann auf dem Client interpretiert. Anschließend begann der Web-Client, dasselbe zu tun – erstens führte er zu einer Leistungssteigerung und zweitens ermöglichte er eine Vereinheitlichung der Architektur von Thin- und Web-Clients.
Die erste Version der 1C:Enterprise-Plattform mit Web-Client-Unterstützung wurde 2009 veröffentlicht. Der damalige Webclient unterstützte zwei Browser – Internet Explorer und Firefox. Die ursprünglichen Pläne beinhalteten die Unterstützung von Opera, aber aufgrund unüberwindbarer Probleme zu diesem Zeitpunkt mit den Handlern für das Schließen von Anwendungen in Opera (es war nicht möglich, mit 2-prozentiger Sicherheit zu verfolgen, dass die Anwendung geschlossen wurde, und in diesem Moment den Trennvorgang von durchzuführen). der 100C-Anwendungsserver) aus diesen Plänen musste aufgegeben werden.
Projektstruktur
Insgesamt verfügt die 1C:Enterprise-Plattform über 4 in JavaScript geschriebene Projekte:
- WebTools – gemeinsam genutzte Bibliotheken, die von anderen Projekten verwendet werden (wir schließen auch ein). ).
- Bedienelement (in JavaScript sowohl im Thin Client als auch im Web Client implementiert)
- Bedienelement (in JavaScript sowohl im Thin Client als auch im Web Client implementiert)
- Web-Client
Die Struktur jedes Projekts ähnelt der Struktur von Java-Projekten (oder .NET-Projekten – je nachdem, was näher ist); Wir haben Namespaces und jeder Namespace befindet sich in einem separaten Ordner. Im Ordner befinden sich Dateien und Namespace-Klassen. Das Web-Client-Projekt enthält etwa 1000 Dateien.
Strukturell gliedert sich der Webclient im Wesentlichen in folgende Subsysteme:
- Verwaltete Client-Anwendungsschnittstelle
- Allgemeine Anwendungsoberfläche (Systemmenüs, Bedienfelder)
- Schnittstelle verwalteter Formulare, darunter unter anderem etwa 30 Steuerelemente (Schaltflächen, verschiedene Arten von Eingabefeldern – Text, Zahlen, Datum/Uhrzeit usw., Tabellen, Listen, Grafiken usw.)
- Objektmodell, das Entwicklern auf dem Client zur Verfügung steht (insgesamt über 400 Typen: verwaltetes Schnittstellenobjektmodell, Datenlayouteinstellungen, bedingtes Styling usw.)
- Interpreter der integrierten 1C-Sprache
- Browsererweiterungen (werden für Funktionen verwendet, die in JavaScript nicht unterstützt werden)
- Arbeiten mit Kryptographie
- Arbeiten mit Dateien
- Technologie externer Komponenten, die den Einsatz sowohl in Thin- als auch in Web-Clients ermöglicht
Entwicklungsfunktionen
Es ist nicht einfach, alle oben genannten Punkte in JavaScript zu implementieren. Der 1C-Webclient ist vielleicht eine der größten in JavaScript geschriebenen clientseitigen Anwendungen – etwa 450.000 Zeilen. Wir verwenden aktiv einen objektorientierten Ansatz im Web-Client-Code, der die Arbeit mit einem so großen Projekt vereinfacht.
Um die Größe des Client-Codes zu minimieren, verwendeten wir zunächst unseren eigenen Obfuscator und begannen mit der Plattformversion 8.3.6 (Oktober 2014). . Die Auswirkung der Nutzung in Zahlen – die Größe des Web-Client-Frameworks nach der Verschleierung:
- Eigener Obfuscator – 1556 kb
- Google-Closure-Compiler – 1073 KB
Mithilfe des Google Closure Compilers konnten wir die Leistung des Webclients im Vergleich zu unserem eigenen Obfuscator um 30 % verbessern. Darüber hinaus ist der von der Anwendung verbrauchte Speicher um 15–25 % gesunken (je nach Browser).
Der Google Closure Compiler funktioniert sehr gut mit objektorientiertem Code, sodass seine Effizienz für den Webclient so hoch wie möglich ist. Der Closure Compiler tut ein paar gute Dinge für uns:
- Statische Typprüfung in der Projekterstellungsphase (stellt sicher, dass wir den Code mit JSDoc-Annotationen abdecken). Das Ergebnis ist eine statische Typisierung, die der Typisierung in C++ sehr nahe kommt. Dies trägt dazu bei, einen relativ großen Prozentsatz an Fehlern in der Phase der Projektkompilierung zu erkennen.
- Reduzierung der Codegröße durch Verschleierung
- Eine Reihe von Optimierungen des ausgeführten Codes, beispielsweise:
- Inline-Funktionsersetzungen. Das Aufrufen einer Funktion in JavaScript ist ein ziemlich kostspieliger Vorgang, und Inline-Ersetzungen häufig verwendeter kleiner Methoden beschleunigen den Code erheblich.
- Zählen von Konstanten zur Kompilierungszeit. Wenn ein Ausdruck von einer Konstante abhängt, wird der tatsächliche Wert der Konstante darin eingesetzt
Wir verwenden WebStorm als unsere Web-Client-Entwicklungsumgebung.
Für die Codeanalyse verwenden wir , wo wir statische Code-Analysatoren integrieren. Mithilfe von Analysegeräten überwachen wir die Verschlechterung der Qualität des JavaScript-Quellcodes und versuchen, diese zu verhindern.
Welche Probleme haben/lösen wir?
Bei der Umsetzung des Projekts sind wir auf eine Reihe interessanter Probleme gestoßen, die wir lösen mussten.
Tauschen Sie Daten mit dem Server und zwischen Windows aus
Es gibt Situationen, in denen die Verschleierung des Quellcodes den Betrieb des Systems beeinträchtigen kann. Code außerhalb des ausführbaren Codes des Webclients kann aufgrund der Verschleierung Funktions- und Parameternamen haben, die von denen abweichen, die unser ausführbarer Code erwartet. Der externe Code für uns ist:
- Code, der vom Server in Form von Datenstrukturen kommt
- Code für ein anderes Anwendungsfenster
Um eine Verschleierung bei der Interaktion mit dem Server zu vermeiden, verwenden wir das @expose-Tag:
/**
* @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;
}Und um eine Verschleierung bei der Interaktion mit anderen Fenstern zu vermeiden, verwenden wir sogenannte exportierte Schnittstellen (Schnittstellen, in denen alle Methoden exportiert werden).
/**
* Экспортируемый интерфейс контрола 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 (){}Wir haben Virtual DOM verwendet, bevor es zum Mainstream wurde)
Wie alle Entwickler, die sich mit komplexen Web-UIs befassen, wurde uns schnell klar, dass das DOM für die Arbeit mit dynamischen Benutzeroberflächen schlecht geeignet ist. Fast sofort wurde ein Analogon von Virtual DOM implementiert, um die Arbeit mit der Benutzeroberfläche zu optimieren. Während der Ereignisverarbeitung werden alle DOM-Änderungen im Speicher gespeichert und erst wenn alle Vorgänge abgeschlossen sind, werden die akkumulierten Änderungen auf den DOM-Baum angewendet.
Optimierung des Webclients
Damit unser Webclient schneller arbeitet, versuchen wir, die Standardbrowserfunktionen (CSS usw.) maximal zu nutzen. Daher wird das Formularbefehlsfeld (das sich auf fast jedem Formular der Anwendung befindet) ausschließlich mit Browser-Tools gerendert, wobei ein dynamisches Layout auf CSS-Basis verwendet wird.
Testing
Für Funktions- und Leistungstests verwenden wir ein proprietäres Tool (geschrieben in Java und C++) sowie eine darauf aufbauende Testsuite .
Unser Tool ist universell – es ermöglicht Ihnen, fast jedes Fensterprogramm zu testen und eignet sich daher sowohl zum Testen eines Thin Clients als auch eines Webclients. Das Tool zeichnet die Aktionen des Benutzers, der die 1C-Anwendungslösung gestartet hat, in einer Skriptdatei auf. Gleichzeitig werden Bilder des Arbeitsbereichs des Bildschirms – Standards – aufgezeichnet. Bei der Überwachung neuer Versionen des Webclients werden Skripte ohne Benutzerbeteiligung abgespielt. In Fällen, in denen der Screenshot in keinem Schritt mit dem Referenzbildschirm übereinstimmt, gilt der Test als fehlgeschlagen. Anschließend führt ein Qualitätsspezialist eine Untersuchung durch, um festzustellen, ob es sich um einen Fehler oder eine geplante Änderung des Systemverhaltens handelt. Bei geplantem Verhalten werden die Standards automatisch durch neue ersetzt.
Das Tool misst außerdem die Anwendungsleistung mit einer Genauigkeit von bis zu 25 Millisekunden. In einigen Fällen führen wir Teile des Skripts in einer Schleife durch (z. B. durch mehrmaliges Wiederholen der Auftragseingabe), um die Verschlechterung der Ausführungszeit im Laufe der Zeit zu analysieren. Die Ergebnisse aller Messungen werden zur Analyse in einem Protokoll aufgezeichnet.
Unser Testtool und unsere getestete Anwendung
Unser Tool und Selenium ergänzen sich; Wenn beispielsweise eine Schaltfläche auf einem der Bildschirme ihre Position geändert hat, kann Selenium dies möglicherweise nicht verfolgen, aber unser Tool wird es bemerken, weil vergleicht den Screenshot pixelweise mit dem Standard. Das Tool ist auch in der Lage, Probleme bei der Verarbeitung von Tastatur- oder Mauseingaben zu verfolgen, da es genau diese reproduziert.
Tests beider Tools (unserem und Selenium) führen typische Arbeitsszenarien unserer Anwendungslösungen durch. Tests werden automatisch nach dem täglichen Build der 1C:Enterprise-Plattform gestartet. Wenn Skripte langsamer sind (im Vergleich zum vorherigen Build), untersuchen und beheben wir die Ursache der Verlangsamung. Unser Kriterium ist einfach: Der neue Build sollte nicht langsamer arbeiten als der vorherige.
Entwickler verwenden verschiedene Tools, um Verlangsamungsvorfälle zu untersuchen. hauptsächlich genutzt Produktionsfirma . Protokolle der Ausführung des problematischen Vorgangs auf den vorherigen und neuen Builds werden aufgezeichnet und anschließend analysiert. Gleichzeitig ist die Ausführungszeit einzelner Operationen (in Millisekunden) möglicherweise kein entscheidender Faktor – Dienstprozesse wie die Garbage Collection werden regelmäßig im Browser gestartet, sie können sich mit der Ausführungszeit von Funktionen überschneiden und das Bild verzerren. Relevantere Parameter wären in diesem Fall die Anzahl der ausgeführten JavaScript-Anweisungen, die Anzahl der atomaren Operationen im DOM usw. Wenn in einer neuen Version die Anzahl der Anweisungen/Operationen im selben Skript zugenommen hat, bedeutet dies fast immer einen Leistungsabfall, der korrigiert werden muss.
Einer der Gründe für den Leistungsabfall kann auch sein, dass der Google Closure Compiler aus irgendeinem Grund nicht in der Lage war, die Funktion inline zu ersetzen (z. B. weil die Funktion rekursiv oder virtuell ist). In diesem Fall versuchen wir, die Situation zu korrigieren, indem wir den Quellcode neu schreiben.
Browsererweiterungen
Wenn eine Anwendungslösung Funktionalität benötigt, die in JavaScript nicht verfügbar ist, verwenden wir Browsererweiterungen:
- mit Dateien arbeiten
- für die Arbeit mit Kryptographie
- arbeiten mit
Unsere Erweiterungen bestehen aus zwei Teilen. Der erste Teil ist eine sogenannte Browser-Erweiterung (normalerweise in JavaScript geschriebene Erweiterungen für Chrome und Firefox), die mit dem zweiten Teil interagiert – einer binären Erweiterung, die die von uns benötigte Funktionalität implementiert. Es sollte erwähnt werden, dass wir 3 Versionen von Binärerweiterungen schreiben – für Windows, Linux und MacOS. Die binäre Erweiterung wird als Teil der 1C:Enterprise-Plattform geliefert und befindet sich auf dem 1C-Anwendungsserver. Beim ersten Aufruf von einem Web-Client wird es auf den Client-Rechner heruntergeladen und im Browser installiert.
Bei der Ausführung in Safari nutzen unsere Erweiterungen NPAPI; bei der Ausführung im Internet Explorer nutzen sie die ActiveX-Technologie. unterstützt noch keine Erweiterungen, daher funktioniert der darin enthaltene Webclient mit Einschränkungen.
Weiterentwicklung der
Zu den Aufgaben des Web-Client-Entwicklungsteams gehört die Weiterentwicklung der Funktionalität. Die Funktionalität des Web-Clients sollte mit der Funktionalität des Thin Clients identisch sein; alle neuen Funktionen werden gleichzeitig sowohl im Thin- als auch im Web-Client implementiert.
Weitere Aufgaben umfassen die Entwicklung der Architektur, Refactoring sowie die Verbesserung von Leistung und Zuverlässigkeit. Eine der Richtungen ist beispielsweise die weitere Entwicklung hin zu einem asynchronen Arbeitsmodell. Ein Teil der Funktionalität des Webclients basiert derzeit auf einem synchronen Interaktionsmodell mit dem Server. Das asynchrone Modell wird jetzt in Browsern immer relevanter (und nicht nur in Browsern), und dies zwingt uns dazu, den Webclient zu modifizieren, indem wir synchrone Aufrufe durch asynchrone ersetzen (und den Code entsprechend umgestalten). Der schrittweise Übergang zu einem asynchronen Modell erklärt sich aus der Notwendigkeit, freigegebene Lösungen und deren schrittweise Anpassung zu unterstützen.
Source: habr.com