Die Plattform „1C:Enterprise“ – was steckt dahinter?

Hallo, Habra!
In diesem Artikel beginnen wir mit der Beschreibung, wie die Plattform aufgebaut ist „1C:Enterprise 8“ und welche Technologien bei ihrer Entwicklung verwendet werden.

Warum halten wir das für interessant? Erstens, weil die Plattform „1C:Enterprise 8“ eine große (über 10 Millionen Zeilen Code) Anwendung in C++ (Client, Server usw.), JavaScript (Web-Client) und seit Kurzem auch Java. Große Projekte sind interessant, auch wegen ihrer Größe, denn Probleme, die in kleinen Codebasen unauffällig sind, treten in solchen Projekten deutlich hervor. Zweitens ist „1C:Enterprise“ ein reproduzierbares, „Box“-Produkt, und es gibt nicht viele Artikel über solche Entwicklungen auf dem Habr. Und außerdem ist es immer interessant zu erfahren, wie es in anderen Teams und Firmen läuft.

Also, fangen wir an. In diesem Artikel geben wir einen Überblick über einige Technologien, die in der Plattform verwendet werden, und skizzieren die Landschaft, ohne tief in die Implementierung einzutauchen. Denn für viele Mechanismen würde eine detaillierte Beschreibung einen eigenen Artikel erfordern, und für einige sogar ein ganzes Buch!
Zunächst sollten wir uns mit den grundlegenden Dingen befassen – was ist die Plattform „1C:Enterprise“ und aus welchen Komponenten besteht sie? Die Antwort auf diese Frage ist nicht so einfach, denn mit dem Begriff „Plattform“ (aus Gründen der Kürze werden wir sie so nennen) bezeichnet man sowohl die Entwicklungsumgebung für Geschäftsanwendungen als auch die Ausführungsumgebung und die Administrationsmittel. Man kann grob folgende Teile unterscheiden:

• Servercluster
• „Dünner“ Client, der sich über HTTP und ein eigenes binäres Protokoll mit dem Server verbinden kann
• Client für die Arbeit in einer zwei- schichtigen Architektur mit einer auf der Festplatte oder im Netzwerkordner gespeicherten Datenbank
• Web-Client
• Administrationsmittel für den Anwendungsserver
• Entwicklungsumgebung (bekannt als Konfigurator)
• Ausführungsumgebung für iOS, Android und Windows Phone (mobile Plattform 1C)

Alle diese Teile, mit Ausnahme des Web-Clients, sind in C++ geschrieben. Darüber hinaus gibt es einen neu angekündigten Konfigurator der neuen Generation, der in Java geschrieben ist.

Native Anwendungen

Für die Entwicklung nativer Anwendungen wird C++03 verwendet. Unter Windows wird Microsoft Visual C++ 12 (Profil kompatibel mit Windows XP) als Compiler eingesetzt, während unter Linux und Android gcc 4.8 und für iOS clang 5.0 verwendet wird. Die Standardbibliothek ist für alle Betriebssysteme und Compiler einheitlich – STLPort. Diese Lösung verringert die Wahrscheinlichkeit von fehlerhaften Implementierungen, die spezifisch für STL sind. Derzeit planen wir den Übergang zur STL-Implementierung, die mit CLang geliefert wird, da STLPort seine Entwicklung eingestellt hat und nicht mit dem aktivierten C++11-Unterstützungsmodus in gcc kompatibel ist.
Der Code-Bestand des Servers beträgt dabei 99 % und des Clients 95 %. Darüber hinaus verwendet sogar die mobile Plattform denselben C++-Code wie die "große", obwohl der Grad der Vereinheitlichung dort etwas geringer ist.
Wie die meisten C++-Benutzer beanspruchen wir nicht, 100 % der Funktionen der Sprache und ihrer Bibliotheken zu nutzen. So verwenden wir praktisch kein Boost, und von den Spracheigenschaften nutzen wir die dynamische Typumwandlung nicht. Dabei setzen wir aktiv Folgendes ein:

• STL (insbesondere Strings, Container und Algorithmen)
• mehrfache Vererbung, einschließlich mehrfacher Vererbung von Implementierungen
• Templates
• Ausnahmen
• intelligente Zeiger (eigene Implementierung)

Durch die Verwendung mehrerer Vererbung von Schnittstellen (vollständig abstrakte Klassen) wird ein komponentenbasierter Ansatz möglich, über den später gesprochen wird.

Komponenten

Um Modularität zu gewährleisten, wird die gesamte Funktionalität in Komponenten unterteilt, die dynamische Bibliotheken repräsentieren (*.dll unter Windows, *.so unter Linux). Insgesamt gibt es mehr als 150 Komponenten; hier sind einige davon beschrieben:

backend
Enthält die "Engine" der Metadaten der Plattform

accnt
Objekte, die von Anwendungsentwicklern zur Erstellung der Buchhaltung (Kontenpläne und Buchhaltungsregister) verwendet werden

bsl
Engine zur Ausführung der eingebetteten Sprache

nuke
Eigene Implementierung eines Speicher-Allocators

dbeng8
Engine einer Dateibasierten Datenbank. Eine einfache Datei-Server-Datenbankmaschine, die auf ISAM basiert und auch einen einfachen SQL-Prozessor enthält

wbase
Enthält grundlegende Klassen und Funktionen zur Implementierung von Benutzeroberflächen in Windows – Fensterklassen, Zugriff auf GDI usw.

Die Aufteilung in mehrere Komponenten ist aus mehreren Blickwinkeln vorteilhaft:

• Die Aufteilung fördert ein besseres Design, insbesondere eine bessere Isolation des Codes.
• Aus der Komponentensammlung können verschiedene Lieferoptionen flexibel zusammengestellt werden:
  • Zum Beispiel enthält die Installation des Thin Clients wbase, aber keinen Backend
  • während auf dem Server wbase hingegen nicht vorhanden sein wird
  • Beide Varianten werden natürlich nuke und bsl enthalten

Alle benötigten Komponenten für diese Startoption werden beim Programmstart geladen. Dies ist insbesondere notwendig für die Registrierung von SCOM-Klassen, über die wir später sprechen werden.

SCOM

Für eine niedrigere Dekomposition wird das SCOM-System verwendet - ähnlich in der Ideologie wie die ATL-Bibliothek. Für diejenigen, die nicht mit ATL gearbeitet haben, hier eine kurze Aufzählung der Hauptfunktionen und -merkmale.
Für eine speziell gestaltete SCOM-Klasse:

• Stellt Fabrikmethoden bereit, die es ermöglichen, eine Klasse aus einer anderen Komponente zu erstellen, nur indem man ihren Namen kennt (ohne die Implementierung preiszugeben)
• Bietet eine Infrastruktur für intelligente Zeiger mit Referenzzählung. Die Lebensdauer der SCOM-Klasse muss nicht manuell überwacht werden
• Ermöglicht zu erkennen, ob ein Objekt ein bestimmtes Interface implementiert und automatisch den Zeiger auf das Objekt in einen Zeiger auf das Interface zu konvertieren
• Ein Dienstobjekt zu erstellen, das immer über die Methode get_service verfügbar ist, usw.

Zum Beispiel kann in der Komponente json.dll eine Klasse für das Lesen von JSON (zum Beispiel JSONStreamReader) beschrieben werden.
Klassen, Instanzen können aus anderen Komponenten erstellt werden, müssen jedoch in der SCOM-Maschine registriert werden:

SCOM_CLASS_ENTRY(JSONStreamReader)

Dieses Makro beschreibt eine spezielle statische Registrierklasse, dessen Konstruktor beim Laden der Komponente in den Speicher aufgerufen wird.
Danach kann eine Instanz in einer anderen Komponente erstellt werden:

IJSONStreamReaderPtr jsonReader = create_instance(SCOM_CLSIDOF(JSONStreamReader));

Für die Unterstützung von Diensten bietet SCOM eine zusätzliche, recht komplexe Infrastruktur. Zentral darin ist das Konzept des SCOM-Prozesses, der als Container für gestartete Dienste dient (also die Rolle des Service Locators erfüllt) und auch Bindungen an lokalisiert Ressourcen enthält. Der SCOM-Prozess wird an den OS-Thread gebunden. Dadurch können innerhalb der Anwendung die Dienste folgendermaßen abgerufen werden:

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

Darüber hinaus ermöglicht das Umschalten von logischen (SCOM) Prozessen, die mit dem Stream verbunden sind, nahezu unabhängige Anwendungsumgebungen im Hinblick auf den Informationsraum, die innerhalb eines einzigen Streams ausgeführt werden. So funktioniert unser schlanker Client, der mit einer Dateidatenbank arbeitet – innerhalb eines Prozesses des Betriebssystems gibt es zwei SCOM-Prozesse, einer ist mit dem Client verbunden, der andere mit dem Server. Dieser Ansatz ermöglicht die Vereinheitlichung des Codes, der sowohl mit der lokalen Dateidatenbank als auch in der "echten" Client-Server-Variante funktioniert. Der Preis für diese Einheitlichkeit sind zusätzliche Kosten, aber die Praxis zeigt, dass sie gerechtfertigt sind.

Auf der Grundlage des Komponentenmodells SCOM sind sowohl die Geschäftslogik als auch der Benutzeroberflächenbereich von 1C:Unternehmen umgesetzt.

Benutzeroberfläche

Übrigens, was die Schnittstellen angeht. Wir verwenden keine Standardsteuerelemente von Windows; unsere Steuerelemente sind direkt auf der Windows-API implementiert. Für die Linux-Version wurde eine Schicht entwickelt, die über die Bibliothek wxWidgets funktioniert.
Die Steuerungselementbibliothek ist unabhängig von anderen Teilen von "1C:Unternehmen" und wird von uns auch in mehreren kleinen internen Dienstprogrammen verwendet.

Im Laufe der Entwicklung von 1C:Unternehmen hat sich das Aussehen der Steuerelemente verändert, aber eine wesentliche Änderung der Prinzipien gab es nur einmal, im Jahr 2009, mit der Veröffentlichung von Version 8.2 und der Einführung "verwalteter Formen". Neben dem geänderten Aussehen hat sich das Grundprinzip der Formsetzung grundlegend geändert – es gab einen Verzicht auf die pixelgenaue Positionierung der Elemente zugunsten einer Flow-Anordnung. Darüber hinaus arbeiten in diesem neuen Modell die Steuerelemente nicht direkt mit Domänenobjekten, sondern mit speziellen DTO (Data Transfer Objects).
Diese Änderungen ermöglichten die Erstellung eines Web-Clients für "1C:Unternehmen", der die C++-Logik der Steuerelemente in JavaScript nachahmt. Wir bemühen uns, die funktionale Äquivalenz zwischen dem schlanken Client und dem Web-Client aufrechtzuerhalten. Wenn dies aufgrund von Einschränkungen des über JavaScript-API verfügbaren Zugriffs (zum Beispiel sind die Möglichkeiten zur Arbeit mit Dateien sehr eingeschränkt) nicht möglich ist, implementieren wir oft die notwendige Funktionalität mithilfe von Browsererweiterungen, die in C++ geschrieben sind. Derzeit unterstützen wir Internet Explorer und Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows und Linux) und Safari (MacOS).

Darüber hinaus wird die Technologie der gesteuerten Formate zur Erstellung von Benutzeroberflächen für mobile Anwendungen auf der 1C-Plattform verwendet. Auf mobilen Geräten erfolgt die Zeichnung der Steuerelemente mit „nativ“ für das Betriebssystem verwendeten Technologien, jedoch wird der gleiche Code, der auch auf der „großen“ Plattform „1C:Unternehmen“ verwendet wird, für die Logik der Formanordnung und die Reaktion der Benutzeroberfläche genutzt.

1C-Schnittstelle unter Linux

1C-Schnittstelle auf einem mobilen Gerät

1C-Schnittstelle auf anderen Plattformen
1C-Schnittstelle unter Windows

1C-Schnittstelle – Web-Client

Open Source

Obwohl wir keine für C++-Entwickler typischen Bibliotheken unter Windows (MFC, Steuerelemente aus WinAPI) verwenden, 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 die Einrichtung von TLS-Verbindungen
• libxml2 und libxslt für das Parsen von XML
• libetpan für die Arbeit mit E-Mail-Protokollen (POP3, SMTP, IMAP)
• mimetic für das Parsen von E-Mail-Nachrichten
• sqllite für die Speicherung von Benutzerprotokollen
• ICU für die Internationalisierung

Die Liste kann weiterhin fortgesetzt werden.
Darüber hinaus verwenden wir stark modifizierte Versionen von Google Test und Google Mock bei der Entwicklung von Unit-Tests.
Die Bibliotheken mussten angepasst werden, um mit der SCOM-Modellorganisation der Komponenten kompatibel zu sein.
Die Verbreitung von 1C macht die Plattform zu einem großartigen Test für die darin verwendeten Bibliotheken. Die Vielfalt der Benutzer und Szenarien bringt Fehler schnell ans Licht, selbst in den am wenigsten genutzten Codeabschnitten. Wir beheben sie bei uns und versuchen, sie den Bibliotheksautoren zurückzugeben. Die Erfahrungen sind sehr unterschiedlich.
Entwickler cURL und libetpan respondieren schnell auf Pull-Requests, aber den Patch zum Beispiel in OpenSSL konnten wir nicht zurückgeben.

Fazit

In dem Artikel haben wir einige grundlegende Aspekte der Entwicklung der Plattform „1C: Unternehmen“ angesprochen. Im Rahmen des Artikels haben wir nur einige interessante, unserer Meinung nach, Aspekte angesprochen.
Eine allgemeine Beschreibung der verschiedenen Mechanismen der Plattform kann angesehen werden hier.
Welche Themen wären für Sie in den nächsten Artikeln interessant?

Wie ist die mobile Plattform 1C implementiert?
Beschreibung der internen Struktur des Web-Clients?
Oder interessiert Sie vielleicht der Prozess der Auswahl von Funktionen für neue Releases, Entwicklung und Tests?

Hinterlassen Sie Ihre Kommentare!

Quelle: habr.com