Méthodes d'intégration avec 1C

Quelles sont les exigences les plus importantes pour les applications métier ? Parmi les plus essentielles figurent les tâches suivantes :

• La facilité de modification / adaptation de la logique de fonctionnement de l'application aux défis commerciaux changeants.
• La simplicité d'intégration avec d'autres applications.

La manière dont la première tâche est résolue dans 1C a été brièvement décrite dans la section « Personnalisation et support » de cet article; nous reviendrons sur ce sujet intéressant dans l'un de nos prochains articles. Aujourd'hui, nous parlerons de la seconde tâche, celle de l'intégration.

Tâches d'intégration

Les tâches d'intégration peuvent varier. Pour certaines d'entre elles, un simple échange de données interactif suffit, par exemple, pour transmettre à la banque une liste d'employés pour l'émission de cartes de paie. Pour des tâches plus complexes, un échange de données entièrement automatisé peut être nécessaire, éventuellement en s'appuyant sur la logique commerciale d'un système externe. Il existe des tâches de nature spécialisée, comme l'intégration avec des équipements externes (par exemple, équipements de vente, scanners mobiles, etc.) ou avec des systèmes hérités ou spécialisés (comme des systèmes de reconnaissance de codes RFID). Il est crucial de choisir le mécanisme d'intégration le plus approprié pour chaque tâche.

Possibilités d'intégration avec 1C

Différentes approches existent pour réaliser l'intégration avec les applications 1C, le choix de l'une d'entre elles dépend des exigences de la tâche.

1. Mise en œuvre basée sur les mécanismes d'intégration, fournis par la plateforme, ou un API spécialisé de l'application 1C (par exemple, un ensemble de services Web ou HTTP qui appellent des applications tierces pour échanger des données avec l'application 1C). L'avantage de cette approche est la résistance de l'API aux modifications de l'implémentation du côté de l'application 1C. La particularité de cette approche est qu'il est nécessaire de modifier le code source de la solution standard 1C, ce qui peut potentiellement nécessiter des efforts lors de la fusion des codes sources lors du passage à une nouvelle version de la configuration. Dans ce cas, une nouvelle fonctionnalité progressive peut venir à l'aide — les extensions de configuration. Les extensions sont essentiellement un mécanisme de plugins qui permet de créer des ajouts aux solutions applicatives sans modifier les solutions elles-mêmes. L'extraction de l'API d'intégration dans l'extension de configuration évitera les complications lors de la fusion des configurations lors de la mise à jour vers une nouvelle version de la solution standard.
2. Utilisation des mécanismes d'intégration de la plateforme, qui permettent l'accès externe au modèle d'objet de l'application sans nécessiter de modification de l'application ou de création d'une extension. L'avantage de cette approche est qu'il n'est pas nécessaire de modifier l'application 1C. L'inconvénient est que si l'application 1C a été modifiée, des ajustements peuvent être nécessaires dans l'application intégrée. Un exemple de cette approche est l'utilisation du protocole OData pour l'intégration, implémenté du côté de la plateforme 1C:Entreprise (plus de détails ci-dessous).
3. Utilisation des protocoles d'application prêts à l'emploi, implémentés dans les solutions standard 1C. De nombreuses solutions standard de 1C et de partenaires mettent en œuvre leurs propres protocoles d'application basés sur les mécanismes d'intégration fournis par la plateforme, orientés vers des tâches spécifiques. L'utilisation de ces mécanismes ne nécessite pas d'écrire du code du côté de l'application 1C, car nous utilisons les fonctionnalités standard de la solution applicative. Du côté de l'application 1C, nous n'avons besoin que d'effectuer certaines configurations.

Mécanismes d'intégration dans la plateforme 1C:Entreprise

Import/export de fichiers

Supposons que nous ayons la tâche d'échange bidirectionnel de données entre l'application 1C et une application quelconque. Par exemple, nous devons synchroniser la liste des produits (répertoire Nomenclature) entre l'application 1C et une application aléatoire.

Pour résoudre ce problème, il est possible d'écrire une extension qui exporte le répertoire Nomenclature dans un fichier d'un format spécifique (texte, XML, JSON, …) et est capable de lire ce format.

La plateforme a mis en œuvre un mécanisme de sérialisation d'objets applicatifs en XML, à la fois directement, via les méthodes du contexte global ÉcrireXML/LireXML, et à l'aide de l'objet auxiliaire XDTO (XML Data Transfer Objects).

Tout objet dans le système 1C:Entreprise peut être sérialisé en représentation XML et vice versa.

Cette fonction retournera la représentation de l'objet sous forme de XML:

Fonction Objet_En_XML(Objet)
    EnregistrementXML = Nouveau EnregistrementXML();
    EnregistrementXML.DefinirChaine();
    EcrireXML(EnregistrementXML, Objet);
    Retourner EnregistrementXML.Fermer();
FinFonction

C'est ainsi qu'apparaîtra l'exportation du répertoire Nomenclature en XML à l'aide de XDTO :

&SurLeServeur
Procédure ExporterXMLSurLeServeur()
	NouveauSérialiseurXDTO  = SérialiseurXDTO;
	NouvelleEnregistrementXML = Nouveau EnregistrementXML();
	NouvelleEnregistrementXML.OuvrirFichier("C:DataNomenclature.xml", "UTF-8");
	
	NouvelleEnregistrementXML.EcrireDéclarationXML();
	NouvelleEnregistrementXML.EcrireDébutÉlément("RépertoireNomenclature");
	
	Sélection = Répertoires.Nomenclature.Sélectionner();
	
	TantQue Sélection.Suivant() Faire 
		ObjetNomenclature = Sélection.ObtenirObjet();
		NouveauSérialiseurXDTO.EcrireXML(NouvelleEnregistrementXML, ObjetNomenclature, TypeAssignationXML.Explicite);
	FinFaire;
	
	NouvelleEnregistrementXML.EcrireFinÉlément();
	NouvelleEnregistrementXML.Fermer();
FinProcédure

Par une simple modification du code, nous exportons le répertoire en JSON. Les produits seront enregistrés dans un tableau ; pour varier, présentons la version anglaise de la syntaxe :

&SurLeServeur
Procédure ExporterJSONSurLeServeur()
	NouveauSérialiseurXDTO  = SérialiseurXDTO;
	NouveauÉcrivainJSON = Nouveau ÉcrivainJSON();
	NouveauÉcrivainJSON.OuvrirFichier("C:DataNomenclature.json", "UTF-8");
	
	NouveauÉcrivainJSON.EcrireDébutObjet();
	NouveauÉcrivainJSON.EcrireNomPropriété("RépertoireNomenclature");
	NouveauÉcrivainJSON.EcrireDébutTableau();
	
	Sélection = Catalogues.Nomenclature.Sélectionner();
	
	TantQue Sélection.Suivant() Faire 
		ObjetNomenclature = Sélection.ObtenirObjet();
		
		NouveauÉcrivainJSON.EcrireDébutObjet();
		
		NouveauÉcrivainJSON.EcrireNomPropriété("Nomenclature");
		NouveauSérialiseurXDTO.EcrireJSON(NouveauÉcrivainJSON, ObjetNomenclature, TypeAssignationXML.Implicite);
		
		NouveauÉcrivainJSON.EcrireFinObjet();
	FinFaire;
	
	NouveauÉcrivainJSON.EcrireFinTableau();
	NouveauÉcrivainJSON.EcrireFinObjet();
	NouveauÉcrivainJSON.Fermer();
FinProcédure

Il ne reste plus qu'à transmettre les données au consommateur final. La plateforme 1C:Entreprise prend en charge les principaux protocoles Internet HTTP, FTP, POP3, SMTP, IMAP, y compris leurs versions sécurisées. On peut également utiliser HTTP et/ou des services Web pour le transfert de données.

HTTP et services Web

Les applications 1C peuvent implémenter leurs propres services HTTP et Web, ainsi que solliciter des services HTTP et Web fournis par des applications tierces.

Interface REST et protocole OData

À partir de la version 8.3.5, la plateforme 1C:Entreprise peut automatiquement générer une interface REST pour l'ensemble de la solution applicative. Tout objet de configuration (répertoire, document, registre d'informations, etc.) peut être rendu accessible pour l'obtention et la modification des données via l'interface REST. La plateforme utilise le protocole d'accès OData version 3.0. La publication des services OData se fait depuis le menu du configurateur « Administration -> Publication sur le serveur web », la case « Publier l'interface standard OData » doit être cochée. Les formats atom/XML et JSON sont pris en charge. Une fois que la solution applicative est publiée sur le serveur web, des systèmes tiers peuvent y accéder via l'interface REST à l'aide de requêtes HTTP. Pour travailler avec l'application 1C via le protocole OData, aucune programmation du côté 1C n'est requise.

Ainsi, une URL de type http:////odata/standard.odata/Catalog_Номенклатура nous renverra le contenu du catalogue Nomenclature au format XML — une collection d'éléments entry (l'en-tête du message est omis pour plus de concision) :

http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')