Plateforme « 1C: Entreprise » — qu'y a-t-il sous le capot ?

Salut, Habr !
Dans cet article, nous allons parler de la manière dont la plateforme fonctionne en interne 1C:Enterprise 8 et des technologies utilisées dans son développement.

Plateforme « 1C: Entreprise » — qu'y a-t-il sous le capot ?

Pourquoi pensons-nous que c'est intéressant ? Tout d'abord, parce que la plateforme 1C:Enterprise 8 est une grande application (plus de 10 millions de lignes de code) écrite en C++ (client, serveur, etc.), JavaScript (client web), et, depuis peu encore, en Java. Les grands projets sont intéressants ne serait-ce que par leur ampleur, car des questions qui passent inaperçues dans une petite base de code se posent de façon criante dans de tels projets. Deuxièmement, 1C:Enterprise est un produit standardisé, et il existe très peu d'articles sur de tels développements sur Habr. De plus, il est toujours fascinant de découvrir comment d'autres équipes et entreprises vivent leur expérience.

Alors, commençons. Dans cet article, nous donnerons un aperçu de certaines des technologies utilisées dans la plateforme, en décrivant le paysage sans plonger profondément dans les implémentations. En effet, pour de nombreux mécanismes, une explication détaillée nécessiterait un article à part entière, et pour certains, un livre entier !
Tout d'abord, il est nécessaire de définir les choses de base : qu'est-ce que la plateforme 1C:Enterprise et de quels composants elle se compose. La réponse à cette question n'est pas si simple, car le terme "Plateforme" (nous l'appellerons ainsi pour faire court) englobe à la fois un outil de développement d'applications métier, un environnement d'exécution et des outils d'administration. On peut grossièrement distinguer les composants suivants :

  • un cluster de serveurs
  • un client "léger" capable de se connecter au serveur via http et son propre protocole binaire
  • un client pour fonctionner dans une architecture à deux niveaux avec une base de données placée sur un disque dur ou un dossier réseau
  • un client web
  • des outils d'administration pour le serveur d'applications
  • un environnement de développement (appelé Configurateur)
  • un environnement d'exécution pour iOS, Android et Windows Phone (plateforme mobile 1C)

Toutes ces parties, à l'exception du client web, sont écrites en C++. De plus, il existe un Configurateur de nouvelle génération, écrit en Java.

Applications natives

Pour le développement d'applications natives, nous utilisons C++03. Sous Windows, nous employons Microsoft Visual C++ 12 (profil compatible avec Windows XP), et sous Linux et Android, gcc 4.8, tandis que pour iOS, nous utilisons clang 5.0. La bibliothèque standard utilisée est la même pour tous les systèmes d'exploitation et compilateurs — STLPort. Ce choix permet de réduire la probabilité d'erreurs spécifiques à l'implémentation de STL. Nous prévoyons actuellement de passer à l'implémentation de STL fournie avec CLang, car STLPort a cessé son développement et n'est pas compatible avec le mode de support C++11 activé dans gcc.
La base de code du serveur est commune à 99%, celle du client à 95%. De plus, même la plateforme mobile utilise le même code C++ que la version 'grande', bien que le pourcentage d'unification soit un peu plus faible.
Comme la plupart des utilisateurs de C++, nous ne prétendons pas utiliser 100% des capacités du langage et de ses bibliothèques. Ainsi, nous n'utilisons pratiquement pas Boost, et parmi les fonctionnalités du langage — le casting dynamique. Cela dit, nous utilisons activement :

  • STL (en particulier, les chaînes, les conteneurs et les algorithmes)
  • l'héritage multiple, y compris l'héritage multiple d'implémentation
  • les modèles
  • les exceptions
  • les pointeurs intelligents (implémentation interne)

L'utilisation de l'héritage multiple d'interfaces (classes complètement abstraites) permet de créer un modèle de composant, dont nous parlerons ci-dessous.

Composants

Pour assurer la modularité, toutes les fonctionnalités sont divisées en composants, qui sont des bibliothèques dynamiques (*.dll sous Windows, *.so sous Linux). Il y a plus de cent cinquante composants, en voici quelques descriptions :

backend
Contient le 'moteur' des métadonnées de la plateforme

accnt
Objets que les développeurs d'applications utilisent pour construire la comptabilité (plans de comptes et registres comptables)

bsl
Moteur d'exécution du langage intégré

nuke
Implémentation interne d'un allocateur de mémoire

dbeng8
Moteur de base de données fichier. Simple machine serveur de fichiers de base de données, basé sur ISAM, incluant également un processeur SQL simple

wbase
Contient des classes de base et des fonctions pour la mise en œuvre d'interfaces utilisateur Windows — classes de fenêtres, accès à GDI, etc.

La séparation en plusieurs composants est bénéfique de plusieurs points de vue :

  • La séparation favorise une meilleure conception, notamment une meilleure isolation du code
  • À partir de l'ensemble des composants, il est possible de rassembler différentes options de livraison :
    • Par exemple, l'installation d'un client léger contiendra wbase, mais ne comprendra pas backend
    • et sur le serveur wbase, à l'inverse, ne sera pas présent
    • les deux options contiendront bien sûr nuke et bsl

Tous les composants nécessaires pour cette option de lancement sont chargés au démarrage du programme. Cela est notamment nécessaire pour l'enregistrement des classes SCOM, dont nous parlerons plus bas.

SCOM

Pour la décomposition à un niveau inférieur, nous utilisons le système SCOM - similaire, par son idéologie, à la bibliothèque ATL. Pour ceux qui n'ont pas travaillé avec ATL, voici un aperçu des principales fonctionnalités et caractéristiques.
Pour une classe SCOM spécialement conçue :

  • Fournit des méthodes de fabrique permettant de créer une classe à partir d'un autre composant en ne connaissant que son nom (sans révéler l'implémentation)
  • Fournit une infrastructure de pointeurs intelligents avec comptage de références. Il n'est pas nécessaire de suivre manuellement la durée de vie de la classe SCOM
  • Permet de savoir si un objet implémente une interface spécifique et de convertir automatiquement le pointeur sur l'objet en pointeur sur l'interface
  • Créer un objet de service, toujours accessible via la méthode get_service, etc.

Par exemple, on peut décrire dans le composant json.dll une classe pour lire du JSON (par exemple, JSONStreamReader).
Les classes, les instances peuvent être créées à partir d'autres composants, il faut les enregistrer dans la machine SCOM :

SCOM_CLASS_ENTRY(JSONStreamReader)

Ce macro décrira une classe statique de registre spéciale, dont le constructeur sera appelé lors du chargement du composant en mémoire.
Après cela, on peut créer son instance dans un autre composant :

IJSONStreamReaderPtr jsonReader = create_instance(SCOM_CLSIDOF(JSONStreamReader));

Pour le soutien des services, SCOM propose une infrastructure supplémentaire, assez complexe. Le concept central est le processus SCOM, qui sert de conteneur pour les services en cours d'exécution (c'est-à-dire qui joue le rôle de Service Locator), et contient également une liaison avec les ressources localisables. Le processus SCOM est lié au thread du système d'exploitation. Grâce à cela, à l'intérieur de l'application, on peut obtenir des services comme ceci :

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

De plus, en basculant les processus logiques (SCOM) liés à un flux, on peut obtenir des applications pratiquement indépendantes du point de vue de l'espace d'information, s'exécutant dans le cadre d'un même flux. C'est ainsi que notre client léger fonctionne, opérant avec une base de données fichier — à l'intérieur d'un même processus OS se trouvent deux processus SCOM, l'un lié au client et l'autre au serveur. Cette approche permet d'unifier l'écriture de code qui fonctionnera aussi bien sur une base de données locale que dans une version « réelle » client-serveur. Le prix de cette uniformité est des frais généraux, mais la pratique montre qu'ils en valent la peine.

Sur la base du modèle de composants SCOM, la logique métier et la partie interface de 1C: Enterprise sont mises en œuvre.

Interface utilisateur

À propos des interfaces. Nous n'utilisons pas les contrôles standard de Windows, nos éléments de contrôle sont réalisés directement sur l'API Windows. Pour la version Linux, une couche a été créée fonctionnant via la bibliothèque wxWidgets.
La bibliothèque d'éléments de contrôle est indépendante des autres parties de « 1C: Enterprise » et est utilisée par nous également dans plusieurs petites utilitaires internes.

Au fil des années, l'apparence des contrôles a changé dans 1C: Enterprise, mais un changement sérieux de principes n'est survenu qu'une fois, en 2009, avec la sortie de la version 8.2 et l'apparition de « formulaires gérés ». En plus de la modification de l'apparence, le principe de mise en page des formulaires a fondamentalement changé — le positionnement pixel par pixel des éléments a été remplacé par une mise en page en flux des éléments. De plus, dans le nouveau modèle, les éléments de contrôle ne travaillent pas directement avec les objets de domaine, mais avec des DTO spéciaux (Data Transfer Objects).
Ces changements ont permis de créer un client web « 1C: Enterprise », répliquant la logique des contrôles en C++ sur JavaScript. Nous nous efforçons de maintenir une équivalence fonctionnelle entre les clients léger et web. Dans les cas où cela n'est pas possible, par exemple en raison des limitations de l'API JavaScript disponible (par exemple, les capacités de travail avec des fichiers étant très limitées), nous mettons souvent en œuvre la fonctionnalité nécessaire à l'aide des extensions de navigateur, écrites en C++. Actuellement, nous supportons Internet Explorer et Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows et Linux) et Safari (MacOS).

De plus, la technologie des formulaires gérés est utilisée pour créer l'interface des applications mobiles sur la plateforme 1C. Sur les appareils mobiles, le rendu des contrôles est réalisé en utilisant des technologies « natives » à la plateforme, mais pour la logique de disposition des formulaires et la réactivité de l'interface, le même code est utilisé que sur la « grande » plateforme « 1C:Entreprise ».

Plateforme « 1C: Entreprise » — qu'y a-t-il sous le capot ?
Interface 1C sur OS Linux

Plateforme « 1C: Entreprise » — qu'y a-t-il sous le capot ?
Interface 1C sur appareil mobile

Interface 1C sur d'autres plateformes Plateforme « 1C: Entreprise » — qu'y a-t-il sous le capot ?
Interface 1C sur OS Windows

Plateforme « 1C: Entreprise » — qu'y a-t-il sous le capot ?
Interface 1C — client web

Open source

Bien que nous n'utilisions pas les bibliothèques standard pour les développeurs C++ sous Windows (MFC, contrôles WinAPI), tous les composants ne sont pas de notre propre création. La bibliothèque wxWidgets, et nous utilisons également :

  • cURL pour travailler avec HTTP et FTP.
  • OpenSSL pour travailler avec la cryptographie et établir des connexions TLS
  • libxml2 et libxslt pour analyser XML
  • libetpan pour travailler avec les protocoles de messagerie (POP3, SMTP, IMAP)
  • mimetic pour analyser les messages électroniques
  • sqllite pour stocker les journaux d'activité des utilisateurs
  • ICU pour l'internationalisation

La liste peut encore continuer.
De plus, nous utilisons des versions fortement modifiées de Google Test et Google Mock lors du développement de tests unitaires.
Les bibliothèques ont nécessité une adaptation pour être compatibles avec le modèle SCOM d'organisation des composants.
La popularité de 1C fait de la plateforme un excellent banc d'essai pour les bibliothèques utilisées. La diversité des utilisateurs et des scénarios détecte rapidement les erreurs même dans les parties de code les plus rarement utilisées. Nous les corrigeons en interne et essayons de les renvoyer aux auteurs des bibliothèques. L'expérience d'interaction varie beaucoup.
Développeurs cURL et libetpan répondent rapidement aux demandes de tirage, mais nous n'avons pas réussi à renvoyer un correctif, par exemple, dans OpenSSL .

Conclusion

Dans cet article, nous avons abordé quelques aspects principaux du développement de la plateforme « 1C: Entreprise ». Dans le cadre limité de l'article, nous avons touché uniquement à certains aspects intéressants à notre avis.
Une description générale des différents mécanismes de la plateforme peut être consultée ici.
Quels sujets vous intéresseraient dans les prochains articles ?

Comment la plateforme mobile 1C est-elle réalisée ?
Description de l'architecture interne du client web ?
Ou peut-être que le processus de sélection des fonctionnalités pour les nouvelles versions, le développement et le test vous intéresse ?

Faites-le nous savoir dans les commentaires !

Source : habr.com

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster