Plattform „1C: Enterprise“ – was steckt unter der Haube?

Hey Habr!
In diesem Artikel beginnen wir mit der Geschichte darüber, wie es im Inneren funktioniert Plattform „1C:Enterprise 8“ und welche Technologien bei seiner Entwicklung zum Einsatz kommen.

Plattform „1C: Enterprise“ – was steckt unter der Haube?

Warum halten wir das für interessant? Erstens, weil die 1C:Enterprise 8-Plattform eine große (mehr als 10 Millionen Codezeilen) Anwendung in C++ (Client, Server usw.), JavaScript (Webclient) und neuerdings auch And ist Javac. Große Projekte können zumindest aufgrund ihres Umfangs interessant sein, da in solchen Projekten Probleme, die in einer kleinen Codebasis unsichtbar sind, mit voller Wucht zum Vorschein kommen. Zweitens ist „1C:Enterprise“ ein reproduzierbares „Box“-Produkt, und auf Habré gibt es nur sehr wenige Artikel über solche Entwicklungen. Es ist auch immer interessant zu erfahren, wie das Leben in anderen Teams und Unternehmen ist.

Also lasst uns anfangen. In diesem Artikel geben wir einen Überblick über einige der Technologien, die in der Plattform verwendet werden, und skizzieren die Landschaft, ohne tief in die Implementierung einzutauchen. Tatsächlich würde eine detaillierte Geschichte für viele Mechanismen einen separaten Artikel und für einige ein ganzes Buch erfordern!
Zunächst lohnt es sich, sich über die grundlegenden Dinge zu entscheiden – was die 1C:Enterprise-Plattform ist und aus welchen Komponenten sie besteht. Die Antwort auf diese Frage ist nicht so einfach, denn der Begriff „Plattform“ (der Kürze halber nennen wir ihn so) bezieht sich auf ein Mittel zur Entwicklung von Geschäftsanwendungen, eine Laufzeitumgebung und Verwaltungstools. Folgende Komponenten lassen sich grob unterscheiden:

  • Servercluster
  • „Thin“-Client, der über http und sein eigenes Binärprotokoll eine Verbindung zum Server herstellen kann
  • Client zum Arbeiten in einer zweistufigen Architektur mit einer Datenbank auf einer Festplatte oder einem Netzwerkordner
  • Web-Client
  • Verwaltungstools für Anwendungsserver
  • Entwicklungsumgebung (bekannt als Konfigurator)
  • Laufzeitumgebung für iOS, Android und Windows Phone (mobile Plattform 1C)

Alle diese Teile, mit Ausnahme des Webclients, sind in C++ geschrieben. Hinzu kommt die kürzlich angekündigte Konfigurator der neuen Generation, geschrieben in Java.

Native Apps

C++03 wird zur Entwicklung nativer Anwendungen verwendet. Für Windows wird Microsoft Visual C++ 12 (ein mit Windows XP kompatibles Profil) als Compiler verwendet, für Linux und Android - gcc 4.8, für iOS - clang 5.0. Die verwendete Standardbibliothek ist für alle Betriebssysteme und Compiler gleich – STLPort. Diese Lösung verringert die Wahrscheinlichkeit von STL-implementierungsspezifischen Fehlern. Wir planen derzeit die Migration auf die mit CLang gelieferte STL-Implementierung, da STLPort eingestellt wurde und nicht mit dem C++11-aktivierten Modus von gcc kompatibel ist.
Die Codebasis des Servers ist zu 99 % gemeinsam, die des Clients zu 95 %. Darüber hinaus verwendet sogar die mobile Plattform denselben C++-Code wie die „große“, obwohl der Prozentsatz der Vereinheitlichung dort etwas geringer ist.
Wie die meisten C++-Benutzer erheben wir nicht den Anspruch, die Fähigkeiten der Sprache und ihrer Bibliotheken zu 100 % zu nutzen. Daher verwenden wir Boost praktisch nicht und eine der Sprachfunktionen ist die dynamische Typumwandlung. Gleichzeitig nutzen wir aktiv:

  • STL (insbesondere Strings, Container und Algorithmen)
  • Mehrfachvererbung, inkl. Mehrfachimplementierungsvererbung
  • Vorlagen
  • und Abzüge
  • Intelligente Zeiger (benutzerdefinierte Implementierung)

Durch die Verwendung der Mehrfachvererbung von Schnittstellen (vollständig abstrakte Klassen) wird ein Komponentenmodell möglich, auf das weiter unten eingegangen wird.

Komponenten

Um die Modularität zu gewährleisten, ist die gesamte Funktionalität in Komponenten unterteilt, bei denen es sich um dynamische Bibliotheken (*.dll für Windows, *.so für Linux) handelt. Insgesamt gibt es mehr als einhundertfünfzig Komponenten; hier finden Sie Beschreibungen einiger davon:

Backend
Enthält die Plattform-Metadaten-Engine

Konto
Objekte, die Anwendungsentwickler zum Erstellen von Buchhaltungsunterlagen (Kontenpläne und Buchhaltungsregister) verwenden

bsl
Eingebettete Sprachausführungs-Engine

Atombombe
Benutzerdefinierte Implementierung des Speicherzuweisers

dbeng8
Dateidatenbank-Engine. Eine einfache Dateiserver-Datenbank-Engine auf Basis von ISAM, die auch einen einfachen SQL-Prozessor enthält

wbase
Enthält die Basisklassen und Funktionen zur Implementierung der Windows-Benutzeroberfläche – Fensterklassen, GDI-Zugriff usw.

Die Aufteilung in mehrere Komponenten ist aus mehreren Gesichtspunkten sinnvoll:

  • Die Trennung fördert ein besseres Design, insbesondere eine bessere Code-Isolation
  • Aus einem Komponentensatz können Sie flexibel verschiedene Liefermöglichkeiten zusammenstellen:
    • Beispielsweise enthält eine Thin-Client-Installation WBase, aber kein Backend
    • Auf dem WBase-Server hingegen wird dies nicht der Fall sein
    • Beide Optionen enthalten natürlich Nuke und BSL

Alle für diese Startoption erforderlichen Komponenten werden beim Programmstart geladen. Dies ist insbesondere für die Registrierung von SCOM-Kursen erforderlich, auf die weiter unten eingegangen wird.

SCOM

Für die Zerlegung auf einer niedrigeren Ebene wird das SCOM-System verwendet, eine Bibliothek, die in ihrer Ideologie ATL ähnelt. Für diejenigen, die noch nicht mit ATL gearbeitet haben, listen wir kurz die wichtigsten Funktionen und Merkmale auf.
Für eine speziell entwickelte SCOM-Klasse:

  • Stellt Factory-Methoden bereit, mit denen Sie eine Klasse aus einer anderen Komponente erstellen können, indem Sie nur deren Namen kennen (ohne die Implementierung preiszugeben).
  • Stellt eine Referenzzähl-Smart-Pointer-Infrastruktur bereit. Die Lebensdauer der SCOM-Klasse muss nicht manuell überwacht werden
  • Ermöglicht Ihnen herauszufinden, ob ein Objekt eine bestimmte Schnittstelle implementiert, und einen Zeiger auf das Objekt automatisch in einen Zeiger auf die Schnittstelle umzuwandeln
  • Erstellen Sie ein Serviceobjekt, auf das immer über die Methode get_service usw. zugegriffen werden kann.

Sie können beispielsweise eine Klasse zum Lesen von JSON (z. B. JSONStreamReader) in der Komponente json.dll beschreiben.
Klassen und Instanzen können aus anderen Komponenten erstellt werden; sie müssen auf der SCOM-Maschine registriert werden:

SCOM_CLASS_ENTRY(JSONStreamReader)

Dieses Makro beschreibt eine spezielle statische Rekorderklasse, deren Konstruktor aufgerufen wird, wenn die Komponente in den Speicher geladen wird.
Danach können Sie eine Instanz davon in einer anderen Komponente erstellen:

IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));

Zur Unterstützung der Dienste bietet SCOM eine zusätzliche, recht komplexe Infrastruktur an. Im Mittelpunkt steht das Konzept eines SCOM-Prozesses, der als Container für die Ausführung von Diensten dient (d. h. die Rolle des Service Locator spielt) und auch eine Bindung an lokalisierte Ressourcen enthält. Der SCOM-Prozess ist an den Betriebssystem-Thread gebunden. Dank dessen können Sie innerhalb der Anwendung Dienste wie diese erhalten:

SCOM_Process* process = core::current_process();
if (process)
         return get_service<IMyService>(process);

Darüber hinaus können Sie durch das Umschalten logischer (SCOM) Prozesse, die an einen Thread gebunden sind, Anwendungen erhalten, die aus Sicht des Informationsraums praktisch unabhängig sind und innerhalb desselben Threads ausgeführt werden. So funktioniert unser Thin Client mit einer Dateidatenbank: Innerhalb eines Betriebssystemprozesses gibt es zwei SCOM-Prozesse, einen mit dem Client und einen mit dem Server. Dieser Ansatz ermöglicht es uns, das Schreiben von Code zu vereinheitlichen, der sowohl in der lokalen Dateidatenbank als auch in der „echten“ Client-Server-Version funktioniert. Der Preis für eine solche Einheitlichkeit ist zwar hoch, aber die Praxis zeigt, dass es sich lohnt.

Basierend auf dem SCOM-Komponentenmodell werden sowohl die Geschäftslogik als auch der Schnittstellenteil von 1C: Enterprise implementiert.

Benutzeroberfläche

Übrigens zu Schnittstellen. Wir verwenden keine Standard-Windows-Steuerelemente; unsere Steuerelemente werden direkt auf der Windows-API implementiert. Für die Linux-Version wurde eine Ebene erstellt, die über die wxWidgets-Bibliothek funktioniert.
Die Steuerelementbibliothek ist nicht von anderen Teilen von 1C:Enterprise abhängig und wird von uns in mehreren anderen kleinen internen Dienstprogrammen verwendet.

Im Laufe der Jahre der Entwicklung von 1C:Enterprise hat sich das Erscheinungsbild der Steuerelemente geändert, aber eine ernsthafte Änderung der Prinzipien kam es nur einmal, im Jahr 2009, mit der Veröffentlichung von Version 8.2 und dem Aufkommen „verwalteter Formulare“. Neben der Änderung des Erscheinungsbilds hat sich auch das Prinzip des Formularlayouts grundlegend geändert – die pixelweise Positionierung von Elementen wurde zugunsten einer fließenden Anordnung von Elementen aufgegeben. Darüber hinaus funktionieren Kontrollen im neuen Modell nicht direkt mit Domänenobjekten, sondern mit speziellen DTOs (Datenübertragungsobjekte).
Diese Änderungen ermöglichten die Erstellung eines 1C:Enterprise-Webclients, der die C++-Logik von JavaScript-Steuerelementen repliziert. Wir versuchen, die funktionale Äquivalenz zwischen Thin- und Web-Clients aufrechtzuerhalten. In Fällen, in denen dies nicht möglich ist, beispielsweise aufgrund von Einschränkungen der verfügbaren JavaScript-API (z. B. ist die Fähigkeit, mit Dateien zu arbeiten, sehr eingeschränkt), implementieren wir die erforderliche Funktionalität häufig mithilfe von in C++ geschriebenen Browsererweiterungen. Wir unterstützen derzeit Internet Explorer und Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows und Linux) und Safari (MacOS).

Darüber hinaus wird mithilfe der Managed-Forms-Technologie eine Schnittstelle für mobile Anwendungen auf der 1C-Plattform erstellt. Auf mobilen Geräten wird die Darstellung von Steuerelementen mithilfe systemeigener Technologien implementiert. Für die Formularlayoutlogik und die Schnittstellenantwort wird jedoch derselbe Code wie in der „großen“ 1C:Enterprise-Plattform verwendet.

Plattform „1C: Enterprise“ – was steckt unter der Haube?
1C-Schnittstelle unter Linux-Betriebssystem

Plattform „1C: Enterprise“ – was steckt unter der Haube?
1C-Schnittstelle auf einem mobilen Gerät

1C-Schnittstelle auf anderen Plattformen Plattform „1C: Enterprise“ – was steckt unter der Haube?
1C-Schnittstelle unter Windows-Betriebssystem

Plattform „1C: Enterprise“ – was steckt unter der Haube?
Schnittstelle 1C - Webclient

Open Source

Obwohl wir keine Standardbibliotheken für C++-Entwickler unter Windows verwenden (MFC, Steuerelemente von WinAPI), schreiben wir nicht alle Komponenten selbst. Die Bibliothek wurde bereits erwähnt wxWidgets, und wir verwenden auch:

  • cURL für die Arbeit mit HTTP und FTP.
  • OpenSSL für die Arbeit mit Kryptographie und den Aufbau von TLS-Verbindungen
  • libxml2 und libxslt für XML-Parsing
  • libetpan zum Arbeiten mit Mailprotokollen (POP3, SMTP, IMAP)
  • Mimetikum um E-Mail-Nachrichten zu analysieren
  • sqllite zum Speichern von Benutzerprotokollen
  • ICU für die Internationalisierung

Die Liste geht weiter.
Darüber hinaus verwenden wir eine stark modifizierte Version Google-Test и Google-Mock bei der Entwicklung von Unit-Tests.
Die Bibliotheken mussten angepasst werden, um mit dem SCOM-Komponentenorganisationsmodell kompatibel zu sein.
Die Verbreitung von 1C macht die Plattform zu einem hervorragenden Leistungstest für die darin verwendeten Bibliotheken. Eine Vielzahl von Benutzern und Szenarien deckt schnell Fehler selbst in den am seltensten verwendeten Codebereichen auf. Wir korrigieren sie selbst und versuchen, sie den Bibliotheksautoren zurückzugeben. Die Erfahrung der Interaktion gestaltet sich sehr unterschiedlich.
Entwickler cURL и libetpan Reagieren Sie schnell auf Pull-Anfragen, aber der Patch ist beispielsweise nicht verfügbar OpenSSL Wir haben es nie geschafft, es zurückzugeben.

Abschluss

In dem Artikel haben wir mehrere Hauptaspekte der Entwicklung der 1C: Enterprise-Plattform angesprochen. Im begrenzten Umfang des Artikels haben wir unserer Meinung nach nur einige interessante Aspekte angesprochen.
Eine allgemeine Beschreibung der verschiedenen Plattformmechanismen finden Sie hier hier.
Welche Themen wären für Sie in zukünftigen Artikeln von Interesse?

Wie wird die mobile 1C-Plattform implementiert?
Beschreibung der internen Struktur des Webclients?
Oder interessieren Sie sich vielleicht für den Prozess der Auswahl von Funktionen für neue Versionen, der Entwicklung und des Tests?

Schreiben Sie in die Kommentare!

Source: habr.com

Kommentar hinzufügen