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

Hé Habr !
Dans cet article, nous commencerons l'histoire de la façon dont cela fonctionne à l'intérieur plateforme "1C:Entreprise 8" et quelles technologies sont 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 ? D'abord parce que la plateforme 1C:Enterprise 8 est une application volumineuse (plus de 10 millions de lignes de code) en C++ (client, serveur, etc.), JavaScript (client web) et, plus récemment, Et Java. Les grands projets peuvent être intéressants au moins en raison de leur ampleur, car des problèmes invisibles dans une petite base de code se posent pleinement dans de tels projets. Deuxièmement, « 1C:Enterprise » est un produit « en boîte » réplicable, et il existe très peu d’articles sur de tels développements sur Habré. C’est aussi toujours intéressant de savoir comment se passe la vie dans les autres équipes et entreprises.

Alors, commençons. Dans cet article, nous donnerons un aperçu de certaines des technologies utilisées dans la plateforme et décrirons le paysage, sans approfondir la mise en œuvre. En effet, pour de nombreux mécanismes, une histoire détaillée nécessiterait un article à part, et pour certains, un livre entier !
Pour commencer, il convient de décider des éléments de base : ce qu'est la plate-forme 1C:Enterprise et de quels composants elle se compose. La réponse à cette question n'est pas si simple, car le terme « Plateforme » (par souci de concision, nous l'appellerons ainsi) fait référence à un moyen de développement d'applications métier, d'un environnement d'exécution et d'outils d'administration. On peut distinguer grossièrement les composants suivants :

  • cluster de serveurs
  • client « léger » capable de se connecter au serveur via http et son propre protocole binaire
  • client pour travailler dans une architecture à deux niveaux avec une base de données située sur un disque dur ou un dossier réseau
  • client Web
  • outils d'administration de serveur d'applications
  • environnement de développement (appelé Configurateur)
  • 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 y a le récent annoncé Configurateur nouvelle génération, écrit en Java.

Applications natives

C++03 est utilisé pour développer des applications natives. Pour Windows, Microsoft Visual C++ 12 (un profil compatible avec Windows XP) est utilisé comme compilateur, et pour Linux et Android - gcc 4.8, pour iOS - clang 5.0. La bibliothèque standard utilisée est la même pour tous les systèmes d'exploitation et compilateurs - STLPort. Cette solution réduit la probabilité d'erreurs spécifiques à l'implémentation STL. Nous prévoyons actuellement de migrer vers l'implémentation STL fournie avec CLang, car STLPort a été abandonné et est incompatible avec le mode activé C++11 de gcc.
La base de code du serveur est commune à 99 %, celle du client à 95 %. De plus, même la plate-forme mobile utilise le même code C++ que la « grande », bien que le pourcentage d'unification y soit légèrement inférieur.
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 l'une des fonctionnalités du langage est la conversion de type dynamique. Parallèlement, nous utilisons activement :

  • STL (en particulier les chaînes, les conteneurs et les algorithmes)
  • héritage multiple, incl. héritage d'implémentations multiples
  • Modèles
  • exceptions
  • pointeurs intelligents (implémentation personnalisée)

En utilisant l'héritage multiple d'interfaces (classes complètement abstraites), un modèle de composant devient possible, qui sera discuté ci-dessous.

Composants

Pour garantir la modularité, toutes les fonctionnalités sont divisées en composants, qui sont des bibliothèques dynamiques (*.dll pour Windows, *.so pour Linux). Il y a plus de cent cinquante composants au total ; voici la description de certains d'entre eux :

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

compte
Objets que les développeurs d'applications utilisent pour construire des documents comptables (plans comptables et registres comptables)

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

nuke
Implémentation personnalisée de l'allocateur de mémoire

dbeng8
Moteur de base de données de fichiers. Un moteur de base de données de serveur de fichiers simple basé sur ISAM, qui comprend également un simple processeur SQL

wbase
Contient les classes et fonctions de base pour implémenter l'interface utilisateur Windows - classes de fenêtres, accès GDI, etc.

La division en plusieurs composants est utile à plusieurs points de vue :

  • La séparation favorise une meilleure conception, en particulier une meilleure isolation du code
  • À partir d'un ensemble de composants, vous pouvez assembler de manière flexible différentes options de livraison :
    • Par exemple, une installation de client léger contiendra wbase, mais n'aura pas de backend
    • mais sur le serveur wbase, au contraire, ce ne sera pas
    • les deux options contiendront bien sûr nuke et bsl

Tous les composants requis pour cette option de lancement sont chargés au démarrage du programme. Ceci est particulièrement nécessaire pour l'enregistrement des classes SCOM, qui sera discuté ci-dessous.

SCOM

Pour la décomposition à un niveau inférieur, le système SCOM est utilisé, une bibliothèque d'idéologie similaire à ATL. Pour ceux qui n'ont pas travaillé avec ATL, nous énumérons brièvement les principales capacités et fonctionnalités.
Pour une classe SCOM spécialement conçue :

  • Fournit des méthodes d'usine qui vous permettent 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 pointeur intelligent de comptage de références. La durée de vie de la classe SCOM n'a pas besoin d'être surveillée manuellement
  • Permet de savoir si un objet implémente une interface spécifique et de convertir automatiquement un pointeur vers l'objet en pointeur vers l'interface
  • Créez un objet de service toujours accessible via la méthode get_service, etc.

Par exemple, vous pouvez décrire une classe de lecture de JSON (par exemple, JSONStreamReader) dans le composant json.dll.
Les classes et instances peuvent être créées à partir d'autres composants ; elles doivent être enregistrées sur la machine SCOM :

SCOM_CLASS_ENTRY(JSONStreamReader)

Cette macro décrira une classe spéciale d'enregistreur statique, dont le constructeur sera appelé lors du chargement du composant en mémoire.
Après cela, vous pouvez en créer une instance dans un autre composant :

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

Pour supporter les services, SCOM propose une infrastructure supplémentaire assez complexe. Au cœur de celui-ci se trouve le concept d'un processus SCOM, qui sert de conteneur pour l'exécution des services (c'est-à-dire joue le rôle de localisateur de services) et contient également une liaison aux ressources localisées. Le processus SCOM est lié au thread du système d'exploitation. Grâce à cela, à l'intérieur de l'application, vous pouvez recevoir des services comme celui-ci :

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

De plus, en commutant les processus logiques (SCOM) liés à un thread, vous pouvez obtenir des applications pratiquement indépendantes du point de vue de l'espace d'informations, s'exécutant au sein du même thread. C'est ainsi que notre client léger fonctionne avec une base de données de fichiers : dans un processus du système d'exploitation, il existe deux processus SCOM, l'un associé au client et le second au serveur. Cette approche nous permet d'unifier l'écriture de code qui fonctionnera à la fois sur la base de données de fichiers locale et dans la « vraie » version client-serveur. Le prix d’une telle uniformité est élevé, mais la pratique montre que cela en vaut la peine.

Sur la base du modèle de composant SCOM, la logique métier et la partie interface de 1C : Entreprise sont implémentées.

Expérience d'interface utilisateur

À propos, à propos des interfaces. Nous n'utilisons pas de contrôles Windows standard ; nos contrôles sont implémentés directement sur l'API Windows. Pour la version Linux, une couche a été créée qui fonctionne via la bibliothèque wxWidgets.
La bibliothèque de contrôles ne dépend pas d'autres parties de 1C:Enterprise et est utilisée par nous dans plusieurs autres petits utilitaires internes.

Au fil des années de développement de 1C:Enterprise, l'apparence des contrôles a changé, mais un changement sérieux de principes ne s'est produit qu'une seule fois, en 2009, avec la sortie de la version 8.2 et l'avènement des « formulaires gérés ». En plus de changer l'apparence, le principe de disposition des formulaires a fondamentalement changé : le positionnement pixel par pixel des éléments a été rejeté au profit d'une disposition fluide des éléments. De plus, dans le nouveau modèle, les contrôles ne fonctionnent pas directement avec les objets de domaine, mais avec des DTO spéciaux (Objets de transfert de données).
Ces modifications ont permis de créer un client Web 1C:Enterprise qui réplique la logique C++ des contrôles JavaScript. Nous essayons de maintenir une équivalence fonctionnelle entre les clients légers et web. Dans les cas où cela n'est pas possible, par exemple en raison des limitations de l'API JavaScript disponible (par exemple, la capacité de travailler avec des fichiers est très limitée), nous implémentons souvent les fonctionnalités nécessaires à l'aide d'extensions de navigateur écrites en C++. Nous prenons actuellement en charge 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 une interface pour les applications mobiles sur la plateforme 1C. Sur les appareils mobiles, le rendu des contrôles est implémenté à l'aide de technologies natives du système d'exploitation, mais pour la logique de présentation du formulaire et la réponse de l'interface, le même code est utilisé que dans la « grande » plateforme 1C:Enterprise.

Plateforme « 1C : Entreprise » : qu'y a-t-il sous le capot ?
Interface 1C sur système d'exploitation Linux

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

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

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

Open source

Bien que nous n'utilisons pas de bibliothèques standards pour les développeurs C++ sous Windows (MFC, contrôles de WinAPI), nous n'écrivons pas nous-mêmes tous les composants. La bibliothèque a déjà été évoquée 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 l'analyse XML
  • libertpan pour travailler avec les protocoles de messagerie (POP3, SMTP, IMAP)
  • mimétique analyser les messages électroniques
  • SQLite pour stocker les journaux des utilisateurs
  • ICU pour l'internationalisation

La liste continue.
De plus, nous utilisons une version hautement modifiée Tester Google и Google Mock lors du développement de tests unitaires.
Les bibliothèques nécessitaient une adaptation pour être compatibles avec le modèle d'organisation des composants SCOM.
La prévalence de 1C fait de la plate-forme un excellent test de force pour les bibliothèques qui y sont utilisées. Une variété d'utilisateurs et de scénarios révèle rapidement des erreurs, même dans les zones de code les plus rarement utilisées. Nous les corrigeons nous-mêmes et essayons de les restituer aux auteurs de la bibliothèque. L’expérience de l’interaction s’avère très différente.
Développeurs cURL и libertpan répondre rapidement aux pull-requests, mais le patch, par exemple, dans OpenSSL Nous n'avons jamais réussi à le rendre.

Conclusion

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

Comment la plateforme mobile 1C est-elle mise en œuvre ?
Description de la structure interne du client web ?
Ou peut-être êtes-vous intéressé par le processus de sélection des fonctionnalités des nouvelles versions, de développement et de test ?

Écrivez dans les commentaires!

Source: habr.com

Ajouter un commentaire