Die Plattform „1C: Unternehmenssoftware“ — was steckt dahinter?

Hallo, Habr!
In diesem Artikel beginnen wir mit der Erzählung darüber, wie die interne Struktur aussieht der Plattform „1C:Enterprise 8“ und welche Technologien bei ihrer Entwicklung verwendet werden.

Die Plattform „1C: Unternehmenssoftware“ — was steckt dahinter?

Warum halten wir das für interessant? Erstens, weil die Plattform „1C:Enterprise 8“ eine große Anwendung (über 10 Millionen Codezeilen) in C++ (Client, Server usw.), JavaScript (Web-Client) ist, und seit kurzem auch Java. Große Projekte sind allein aufgrund ihres Umfangs interessant, denn Fragen, die in kleinen Codebasen unbemerkt bleiben, treten in solchen Projekten deutlich zutage. Zweitens ist „1C:Enterprise“ ein skalierbares, „Boxed“-Produkt, und es gibt nur wenige Artikel über solche Entwicklungen auf Habré. Außerdem ist es immer spannend zu erfahren, wie es in anderen Teams und Firmen läuft.

Lassen Sie uns also beginnen. In diesem Artikel geben wir einen Überblick über einige Technologien, die in der Plattform verwendet werden, und skizzieren die Landschaft, ohne dabei tief in die Implementierung einzutauchen. Denn viele Mechanismen würden einen detaillierten Bericht erfordern, der eine eigene Artikelreihe oder sogar ein ganzes Buch nach sich ziehen könnte!
Zunächst einmal sollte man die Grundlagen klären – was ist die Plattform „1C:Unternehmen“ und aus welchen Komponenten besteht sie? Die Antwort auf diese Frage ist nicht ganz einfach, denn unter dem Begriff „Plattform“ (zum Nennen abgekürzt) versteht man sowohl ein Entwicklungswerkzeug für Geschäftsanwendungen, als auch eine Ausführungsumgebung und Verwaltungswerkzeuge. Grob unterteilen lassen sich folgende Bestandteile:

  • Servercluster
  • ein „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-Tier-Architektur mit einer Datenbank, die auf der Festplatte oder in einem Netzwerkordner gespeichert ist
  • Web-Client
  • Verwaltungsmittel für den Anwendungsserver
  • Entwicklungsumgebung (bekannt als Konfigurator)
  • Laufzeitumgebung 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 kürzlich angekündigte Konfigurator der nächsten Generation, geschrieben in Java.

Native Anwendungen

Für die Entwicklung nativer Anwendungen wird C++03 verwendet. Unter Windows kommt als Compiler Microsoft Visual C++ 12 (Profil kompatibel mit Windows XP) zum Einsatz, während unter Linux und Android gcc 4.8 und für iOS clang 5.0 verwendet werden. Die Standardbibliothek ist für alle Betriebssysteme und Compiler einheitlich — STLPort. Diese Lösung reduziert die Wahrscheinlichkeit von fehlerhaften Implementierungen, die spezifisch für STL sind. Derzeit planen wir den Übergang zu der STL-Implementierung von CLang, da STLPort nicht mehr weiterentwickelt wird und nicht mit dem unterstützten Modus für C++11 in gcc kompatibel ist.
Der Code-Basis des Servers beträgt dabei 99 % gemeinsame Nutzung, beim Client sind es 95 %. Darüber hinaus verwendet sogar die mobile Plattform denselben C++-Code wie die „große“, auch wenn dort der Grad der Vereinheitlichung etwas niedriger ist.
Wie die meisten C++-Nutzer beanspruchen wir nicht, 100 % der Funktionen der Sprache und ihrer Bibliotheken zu nutzen. So verwenden wir praktisch kein Boost, und von den Sprachmöglichkeiten setzen wir dynamisches Typcasting kaum ein. Gleichzeitig wenden wir aktiv an:

  • STL (insbesondere Strings, Container und Algorithmen)
  • mehrfaches Vererben, einschließlich mehrfacher Implementierungsvererbung
  • Templates
  • Ausnahmen
  • intelligente Zeiger (eigene Implementierung)

Durch den Einsatz von mehrfacher Schnittstellenerbschaft (vollständig abstrakte Klassen) wird ein komponentenbasiertes Modell möglich, über das wir später sprechen werden.

Komponenten

Um die Modularität zu gewährleisten, wurde die gesamte Funktionalität in Komponenten unterteilt, die dynamischen Bibliotheken entsprechen (*.dll unter Windows, *.so unter Linux). Es gibt insgesamt mehr als anderthalb Hundert Komponenten; hier sind Beschreibungen einiger davon:

backend
Enthält die Metadaten-Engine der Plattform

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

bsl
Engine für die Ausführung der eingebetteten Sprache

nuke
Eigene Implementierung eines Speichermanagers

dbeng8
Dateibase-Engine. Ein einfacher Datei-Server-Datenbankmaschine, die auf ISAM basiert und auch einen einfachen SQL-Prozessor umfasst.

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

Die Aufteilung in mehrere Komponenten ist aus mehreren Perspektiven nützlich:

  • Die Trennung fördert eine bessere Gestaltung, insbesondere eine verbesserte Isolierung des Codes.
  • Aus dem Komponenten-Set lassen sich flexibel verschiedene Liefervarianten zusammensetzen:
    • So wird beispielsweise die Installation eines Thin Clients wbase enthalten, aber kein Backend.
    • Auf dem Server hingegen wird wbase nicht enthalten sein.
    • Beide Varianten werden natürlich nuke und bsl enthalten.

Alle für diese Startvariante benötigten Komponenten werden beim Programmstart geladen. Dies ist insbesondere für die Registrierung von SCOM-Klassen erforderlich, die hier behandelt werden.

SCOM

Für die Dekomposition auf einer niedrigeren Ebene wird das SCOM-System verwendet – ideologisch ähnlich der ATL-Bibliothek. Für diejenigen, die mit ATL nicht gearbeitet haben, sind hier die wichtigsten Funktionen und Merkmale aufgeführt.
Für speziell gestaltete SCOM-Klassen:

  • Bietet Fabrikmethoden, die es ermöglichen, eine Klasse aus einer anderen Komponente zu erstellen, indem nur deren Name bekannt ist (ohne Implementierungsdetails preiszugeben).
  • Stellt die Infrastruktur für intelligente Zeiger mit Referenzzählung zur Verfügung. Es ist nicht erforderlich, die Lebensdauer der SCOM-Klasse manuell zu überwachen.
  • Erlaubt die Überprüfung, ob ein Objekt ein bestimmtes Interface implementiert, und wandelt den Zeiger auf das Objekt automatisch in einen Zeiger auf das Interface um.
  • Ein Objekt-Service erstellen, der jederzeit über die Methode get_service zugänglich ist usw.

Zum Beispiel kann in der Komponente json.dll eine Klasse zum Lesen von JSON (z. B. JSONStreamReader) beschrieben werden.
Klassen und Instanzen können aus anderen Komponenten erstellt werden; diese müssen in der SCOM-Maschine registriert werden:

SCOM_CLASS_ENTRY(JSONStreamReader)

Dieses Makro beschreibt eine spezielle statische Registrierungs-Klasse, deren Konstruktor beim Laden der Komponente in den Arbeitsspeicher aufgerufen wird.
Danach kann in einer anderen Komponente eine Instanz davon erstellt werden:

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

Zur Unterstützung der Dienste bietet SCOM eine zusätzliche, ziemlich komplexe Infrastruktur. Zentral in dieser ist das Konzept des SCOM-Prozesses, der als Container für die ausgeführten Dienste fungiert (d.h. als Service Locator) und auch die Bindung an lokalisierten Ressourcen enthält. Der SCOM-Prozess ist an den OS-Thread gebunden. Dadurch können innerhalb der Anwendung die Dienste wie folgt abgerufen werden:

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

Darüber hinaus können durch das Umschalten von logischen (SCOM) Prozessen, die an den Datenfluss gebunden sind, praktisch unabhängige Anwendungen im Hinblick auf den Informationsraum erzeugt werden, die innerhalb eines einzigen Flusses ausgeführt werden. So funktioniert unser schlanker Client, der mit einer Dateidatenbank arbeitet - innerhalb eines Betriebssystemprozesses befinden sich zwei SCOM-Prozesse, einer ist mit dem Client verbunden und der andere mit dem Server. Dieser Ansatz ermöglicht eine Vereinheitlichung der Codeerstellung, die sowohl mit der lokalen Dateidatenbank als auch in einer echten Client-Server-Umgebung funktioniert. Der Preis für diese Einheitlichkeit sind die Betriebskosten, aber die Praxis zeigt, dass sie es wert sind.

Die Geschäftslogik und der Interface-Bereich von 1C: Enterprise basieren auf dem komponentenbasierten Modell von SCOM.

Benutzeroberfläche

Apropos Interfaces. Wir verwenden keine Standard-Controls von Windows; unsere Steuerelemente sind direkt über die Windows API implementiert. Für die Linux-Version wurde eine Schicht entwickelt, die über die wxWidgets-Bibliothek arbeitet.
Die Bibliothek der Steuerelemente ist unabhängig von anderen Teilen von 1C: Enterprise und wird von uns auch in mehreren kleinen internen Tools verwendet.

Im Laufe der Jahre hat sich das Aussehen der Steuerelemente von 1C:Enterprise verändert, jedoch gab es nur einmal eine grundlegende Änderung der Prinzipien, und zwar 2009 mit der Veröffentlichung von Version 8.2 und der Einführung der "verwalteten Formulare". Neben der Änderung des Designs hat sich das Prinzip der Formanordnung grundlegend geändert — die pixelgenaue Positionierung der Elemente wurde zugunsten der Flow-Anordnung aufgegeben. Darüber hinaus arbeiten die Steuerelemente im neuen Modell nicht direkt mit Domainobjekten, sondern mit speziellen DTOs (Data Transfer Objects).
Diese Änderungen ermöglichten die Schaffung eines Webclients für "1C:Enterprise", der die C++-Logik der Steuerelemente in JavaScript nachbildet. Wir bemühen uns, die funktionale Äquivalenz zwischen dem schlanken und dem Webclient aufrechtzuerhalten. Wenn dies nicht möglich ist, zum Beispiel aufgrund von Einschränkungen der verfügbaren JavaScript-APIs (wie beispielsweise stark eingeschränkten Dateioperationen), setzen wir häufig die benötigte Funktionalität mithilfe von Browsererweiterungen um, 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 verwalteten Formulare eingesetzt, um die Benutzeroberfläche mobiler Anwendungen auf der 1C-Plattform zu erstellen. Auf mobilen Geräten erfolgt das Rendering der Steuerelemente mit den für das Betriebssystem typischen Technologien, während für die Logik der Formularlayout und die Reaktion der Benutzeroberfläche derselbe Code verwendet wird wie auf der »großen« Plattform »1C:Enterprise«.

Die Plattform „1C: Unternehmenssoftware“ — was steckt dahinter?
1C-Schnittstelle unter Linux

Die Plattform „1C: Unternehmenssoftware“ — was steckt dahinter?
1C-Schnittstelle auf mobilen Geräten

1C-Schnittstelle auf anderen Plattformen Die Plattform „1C: Unternehmenssoftware“ — was steckt dahinter?
1C-Schnittstelle unter Windows

Die Plattform „1C: Unternehmenssoftware“ — was steckt dahinter?
1C-Schnittstelle – Web-Client

Open Source

Obwohl wir keine standardisierten C++-Entwicklerbibliotheken für Windows (MFC, Steuerelemente aus WinAPI) verwenden, schreiben wir nicht alle Komponenten selbst. Bereits die Bibliothek wxWidgets, und außerdem nutzen wir:

  • cURL für die Arbeit mit HTTP und FTP.
  • OpenSSL für die Arbeit mit Kryptografie und TLS-Verbindungen
  • libxml2 und libxslt zum Parsen von XML
  • libetpan für die Arbeit mit E-Mail-Protokollen (POP3, SMTP, IMAP)
  • mimetic zum Parsen von E-Mail-Nachrichten
  • sqllite zum Speichern von Benutzerprotokollen
  • ICU für die Internationalisierung

Die Liste könnte noch fortgesetzt werden.
Außerdem verwenden wir stark modifizierte Versionen von Google Test und Google Mock bei der Entwicklung von Unit-Tests.
Die Bibliotheken mussten angepasst werden, um mit dem SCOM-Modell der Komponentenorganisation kompatibel zu sein.
Die Verbreitung von 1C macht die Plattform zu einem hervorragenden Prüfstand für die verwendeten Bibliotheken. Die Vielfalt der Nutzer und Szenarien deckt schnell Fehler selbst in den am wenigsten genutzten Teilen des Codes auf. Wir beheben diese und versuchen, sie an die Autoren der Bibliotheken zurückzugeben. Die Erfahrungen mit der Zusammenarbeit sind sehr unterschiedlich.
Die Entwickler cURL und libetpan reagieren schnell auf Pull-Requests, jedoch ist der Patch, zum Beispiel, in OpenSSL uns ist es nicht gelungen, ihn zurückzugeben.

Fazit

Im Artikel haben wir einige grundlegende Aspekte der Entwicklung der Plattform „1C: Unternehmen“ angesprochen. Im Rahmen dieses Artikels haben wir nur einige interessante Aspekte behandelt, die wir für erwähnenswert halten.
Eine allgemeine Beschreibung der verschiedenen Mechanismen der Plattform finden Sie hier.
Welche Themen würden Sie in den nächsten Artikeln interessieren?

Wie ist die mobile 1C-Plattform umgesetzt?
Eine Beschreibung des internen Aufbaus des Webclients?
Oder sind Sie vielleicht am Auswahlprozess von Features für neue Releases sowie deren Entwicklung und Testung interessiert?

Schreiben Sie in die Kommentare!

Quelle: habr.com

Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server 🔥 Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server | ProHoster