Quelles sont les exigences les plus importantes pour les applications métier ? Certaines des tâches les plus importantes sont les suivantes :
- Facilité de modification/adaptation de la logique d’application à l’évolution des tâches métier.
- Intégration facile avec d'autres applications.
La façon dont la première tâche est résolue dans 1C a été brièvement décrite dans la section « Personnalisation et support » ; Nous reviendrons sur ce sujet intéressant dans un prochain article. Aujourd'hui, nous parlerons de la deuxième tâche, l'intégration.
Tâches d'intégration
Les tâches d'intégration peuvent être différentes. Pour résoudre certains problèmes, un simple échange de données interactif suffit - par exemple, pour transférer une liste d'employés à une banque pour l'émission de cartes plastifiées de salaire. Pour des tâches plus complexes, un échange de données entièrement automatisé peut être nécessaire, éventuellement en référence à la logique métier d'un système externe. Il existe des tâches de nature spécialisée, telles que l'intégration avec des équipements externes (par exemple, des équipements de vente au détail, des scanners mobiles, etc.) ou avec des systèmes existants ou hautement spécialisés (par exemple, avec des systèmes de reconnaissance d'étiquettes RFID). Il est extrêmement important de sélectionner le mécanisme d'intégration le plus approprié pour chaque tâche.
Options d'intégration avec 1C
Il existe différentes approches pour mettre en œuvre l'intégration avec les applications 1C ; celle à choisir dépend des exigences de la tâche.
- Basé sur la mise en œuvre fourni par la plateforme, sa propre API spécialisée côté application 1C (par exemple, un ensemble de services Web ou HTTP qui appelleront 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 changements de mise en œuvre côté application 1C. La particularité de l'approche est qu'il est nécessaire de modifier le code source d'une solution 1C standard, 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 à la rescousse : . Les extensions sont essentiellement un mécanisme de plug-in qui vous permet de créer des ajouts aux solutions d'application sans modifier les solutions d'application elles-mêmes. Déplacer l'API d'intégration dans l'extension de configuration vous permettra d'éviter les difficultés lors de la fusion des configurations lors du passage à une nouvelle version d'une solution standard.
- Utiliser des mécanismes d'intégration de plateforme qui fournissent un accès externe au modèle objet de l'application et ne nécessitent pas de modification de l'application ni de création d'extension. L'avantage de cette approche est qu'il n'est pas nécessaire de modifier l'application 1C. Moins - si l'application 1C a été améliorée, des améliorations peuvent être nécessaires dans l'application intégrée. Un exemple de cette approche est l'utilisation du protocole d'intégration OData, implémenté du côté de la plateforme 1C:Enterprise (plus d'informations ci-dessous).
- Utilisation de protocoles d'application prêts à l'emploi implémentés dans des solutions 1C standards. De nombreuses solutions standards de 1C et de partenaires implémentent leurs propres protocoles d'application, axés sur des tâches spécifiques, basés sur les mécanismes d'intégration fournis par la plateforme. Lors de l'utilisation de ces mécanismes, il n'est pas nécessaire d'écrire du code côté application 1C, car Nous utilisons les capacités standards de la solution applicative. Du côté de l'application 1C, il suffit d'effectuer certains réglages.
Mécanismes d'intégration dans la plateforme 1C:Enterprise
Importer/exporter des fichiers
Supposons que nous soyons confrontés à la tâche d'échange de données bidirectionnel entre une application 1C et une application arbitraire. Par exemple, nous devons synchroniser une liste de produits (répertoire Nomenclature) entre l'application 1C et une application arbitraire.
Pour résoudre ce problème, vous pouvez écrire une extension qui télécharge le répertoire Nomenclature dans un fichier d'un certain format (texte, XML, JSON, ...) et peut lire ce format.
La plateforme implémente un mécanisme de sérialisation des objets d'application en XML à la fois directement, via les méthodes de contexte global WriteXML/ReadXML, et en utilisant l'objet auxiliaire XDTO (XML Data Transfer Objects).
Tout objet du système 1C:Enterprise peut être sérialisé en une représentation XML et vice versa.
Cette fonction renverra une représentation XML de l'objet :
Функция Объект_В_XML(Объект)
ЗаписьXML = Новый ЗаписьXML();
ЗаписьXML.УстановитьСтроку();
ЗаписатьXML(ЗаписьXML, Объект);
Возврат ЗаписьXML.Закрыть();
КонецФункции
Voici à quoi ressemblera l’exportation du répertoire Nomenclature au format XML à l’aide de XDTO :
&НаСервере
Процедура ЭкспортXMLНаСервере()
НовыйСериализаторXDTO = СериализаторXDTO;
НоваяЗаписьXML = Новый ЗаписьXML();
НоваяЗаписьXML.ОткрытьФайл("C:DataНоменклатура.xml", "UTF-8");
НоваяЗаписьXML.ЗаписатьОбъявлениеXML();
НоваяЗаписьXML.ЗаписатьНачалоЭлемента("СправочникНоменклатура");
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектНоменклатура = Выборка.ПолучитьОбъект();
НовыйСериализаторXDTO.ЗаписатьXML(НоваяЗаписьXML, ОбъектНоменклатура, НазначениеТипаXML.Явное);
КонецЦикла;
НоваяЗаписьXML.ЗаписатьКонецЭлемента();
НоваяЗаписьXML.Закрыть();
КонецПроцедуры
En modifiant simplement le code, nous exportons le répertoire en JSON. Les produits seront écrits dans un tableau ; Pour varier, voici la version anglaise de la syntaxe :
&AtServer
Procedure ExportJSONOnServer()
NewXDTOSerializer = XDTOSerializer;
NewJSONWriter = New JSONWriter();
NewJSONWriter.OpenFile("C:DataНоменклатура.json", "UTF-8");
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("СправочникНоменклатура");
NewJSONWriter.WriteStartArray();
Selection = Catalogs.Номенклатура.Select();
While Selection.Next() Do
NomenclatureObject = Selection.GetObject();
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("Номенклатура");
NewXDTOSerializer.WriteJSON(NewJSONWriter, NomenclatureObject, XMLTypeAssignment.Implicit);
NewJSONWriter.WriteEndObject();
EndDo;
NewJSONWriter.WriteEndArray();
NewJSONWriter.WriteEndObject();
NewJSONWriter.Close();
EndProcedure
Il ne reste plus qu’à transférer les données au consommateur final. La plateforme 1C:Enterprise prend en charge les principaux protocoles Internet HTTP, FTP, POP3, SMTP, IMAP, y compris leurs versions sécurisées. Vous pouvez également utiliser des services HTTP et/ou Web pour transférer des données.
Services HTTP et Web
Les applications 1C peuvent implémenter leurs propres services HTTP et Web, ainsi qu'appeler des services HTTP et Web implémentés par des applications tierces.
Interface REST et protocole OData
A partir de la version 8.3.5, la plateforme 1C:Enterprise peut automatiquement pour l'ensemble de la solution applicative. Tout objet de configuration (répertoire, document, registre d'informations, etc.) peut être mis à disposition pour recevoir et modifier des données via l'interface REST. La plateforme utilise le protocole comme protocole d'accès version 3.0. La publication des services OData s'effectue depuis le menu du Configurateur « Administration -> Publication sur un serveur web », la case « Publier l'interface OData standard » doit être cochée. Les formats Atom/XML et JSON sont pris en charge. Une fois la solution d'application publiée sur le serveur Web, les 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 côté 1C n'est requise.
Donc, une URL comme http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура nous renverra le contenu du catalogue Nomenclature au format XML - une collection d'éléments d'entrée (le titre du message est omis par souci de concision) :
<entry>
<id>http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')</id>
<category term="StandardODATA.Catalog_Номенклатура" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
<title type="text"/>
<updated>2016-06-06T16:42:17</updated>
<author/>
<summary/>
<link rel="edit" href="Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')" title="edit-link"/>
<content type="application/xml">
<m:properties >
<d:Ref_Key>35d1f6e4-289b-11e6-8ba4-e03f49b16074</d:Ref_Key>
<d:DataVersion>AAAAAgAAAAA=</d:DataVersion>
<d:DeletionMark>false</d:DeletionMark>
<d:Code>000000001</d:Code>
<d:Description>Кондиционер Mitsubishi</d:Description>
<d:Описание>Мощность 2,5 кВт, режимы работы: тепло/холод</d:Описание>
</m:properties>
</content>
</entry>
<entry>
<id>http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e5-289b-11e6-8ba4-e03f49b16074')</id>
<category term="StandardODATA.Catalog_Номенклатура" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
...
En ajoutant la chaîne « ?$format=application/json » à l'URL, on obtient le contenu du catalogue Nomenclature au format JSON (URL de la forme http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура?$format=application/json ):
{
"odata.metadata": "http://server/Config/odata/standard.odata/$metadata#Catalog_Номенклатура",
"value": [{
"Ref_Key": "35d1f6e4-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAgAAAAA=",
"DeletionMark": false,
"Code": "000000001",
"Description": "Кондиционер Mitsubishi",
"Описание": "Мощность 2,5 кВт, режимы работы: тепло/холод"
},{
"Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAwAAAAA=",
"DeletionMark": false,
"Code": "000000002",
"Description": "Кондиционер Daikin",
"Описание": "Мощность 3 кВт, режимы работы: тепло/холод"
}, …
Sources de données externes
Dans certains cas, l'échange de données via peut-être la meilleure solution. Les sources de données externes sont un objet de configuration d'application 1C qui vous permet d'interagir avec n'importe quelle base de données compatible ODBC, tant en lecture qu'en écriture. Les sources de données externes sont disponibles sous Windows et Linux.
Mécanisme d'échange de données
est destiné à la fois à créer des systèmes géographiquement répartis basés sur 1C:Enterprise, et à organiser l'échange de données avec d'autres systèmes d'information non basés sur 1C:Enterprise.
Ce mécanisme est activement utilisé dans les implémentations 1C et l'éventail des tâches résolues avec son aide est très large. Cela inclut l'échange de données entre les applications 1C installées dans les succursales de l'organisation, l'échange entre l'application 1C et le site Web de la boutique en ligne, et l'échange de données entre l'application serveur 1C et le client mobile (créé à l'aide de la plate-forme mobile 1C:Enterprise), et bien d'autres. plus.
L'un des concepts clés du mécanisme d'échange de données est le plan d'échange. Un plan d'échange est un type particulier d'objet de la plateforme applicative 1C, qui détermine notamment la composition des données qui participeront à l'échange (quels annuaires, documents, registres, etc.). Le plan d'échange contient également des informations sur les participants à l'échange (appelés nœuds d'échange).
Le deuxième élément du mécanisme d’échange de données est le mécanisme d’enregistrement des modifications. Ce mécanisme surveille automatiquement le système pour détecter les modifications des données qui doivent être transférées aux utilisateurs finaux dans le cadre du plan d'échange. Grâce à ce mécanisme, la plateforme suit les changements survenus depuis la dernière synchronisation et vous permet de minimiser la quantité de données transférées lors de la prochaine session de synchronisation.
L'échange de données s'effectue à l'aide de messages XML d'une certaine structure. Le message contient des données modifiées depuis la dernière synchronisation avec le nœud et certaines informations de service. La structure des messages prend en charge la numérotation des messages et vous permet de recevoir une confirmation du nœud destinataire indiquant que les messages ont été reçus. Cette confirmation est contenue dans chaque message provenant du noeud récepteur, sous la forme du numéro du dernier message reçu. La numérotation des messages permet à la plateforme de comprendre quelles données ont déjà été transmises avec succès au nœud de réception et d'éviter la retransmission en transmettant uniquement les données qui ont changé depuis que le nœud d'envoi a reçu le dernier message avec un récépissé pour les données reçues par le nœud de réception. Ce système d'exploitation garantit une livraison garantie même en cas de canaux de transmission peu fiables et de perte de messages.
Composants externes
Dans un certain nombre de cas, lors de la résolution de problèmes d'intégration, il faut faire face à des exigences spécifiques, par exemple des protocoles d'interaction, des formats de données, qui ne sont pas prévus dans la plateforme 1C:Enterprise. Pour une telle gamme de tâches, la plateforme fournit , qui vous permet de créer dynamiquement des modules de plug-in qui étendent les fonctionnalités de 1C:Enterprise.
Un exemple typique de tâche avec des exigences similaires serait l'intégration d'une solution d'application 1C avec des équipements de vente au détail, allant des balances aux caisses enregistreuses et aux lecteurs de codes-barres. Les composants externes peuvent être connectés à la fois côté serveur 1C:Enterprise et côté client (y compris, mais sans s'y limiter, le client Web, ainsi que 1C : Entreprise). La technologie des composants externes fournit une interface logicielle (C++) assez simple et compréhensible pour l'interaction des composants avec la plateforme 1C:Enterprise, qui doit être implémentée par le développeur.
Les possibilités qui s'ouvrent lors de l'utilisation de composants externes sont très larges. Vous pouvez mettre en œuvre une interaction à l'aide d'un protocole d'échange de données spécifique avec des appareils et des systèmes externes, intégrer des algorithmes spécifiques pour le traitement des données et des formats de données, etc.
Mécanismes d’intégration obsolètes
La plateforme fournit des mécanismes d'intégration dont l'utilisation n'est pas recommandée dans les nouvelles solutions ; ils sont laissés pour des raisons de compatibilité descendante, et également au cas où l'autre partie ne pourrait pas travailler avec des protocoles plus modernes. L'un d'eux fonctionne avec des fichiers au format DBF (pris en charge dans le langage intégré utilisant l'objet XBase).
Un autre mécanisme d'intégration existant est l'utilisation de la technologie COM (disponible uniquement sur la plateforme Windows). La plateforme 1C:Enterprise propose deux méthodes d'intégration pour Windows utilisant la technologie COM : Serveur d'automatisation et Connexion externe. Ils sont très similaires, mais l'une des différences fondamentales est que dans le cas du serveur Automation, une application client 1C:Enterprise 8 à part entière est lancée, et dans le cas d'une connexion externe, un COM en cours relativement petit le serveur est lancé. Autrement dit, si vous travaillez via le serveur Automation, vous pouvez utiliser les fonctionnalités de l'application client et effectuer des actions similaires aux actions interactives de l'utilisateur. Lorsque vous utilisez une connexion externe, vous ne pouvez utiliser que des fonctions de logique métier, et elles peuvent être exécutées à la fois du côté client de la connexion, où un serveur COM en cours est créé, et vous pouvez appeler la logique métier sur le serveur 1C:Enterprise. côté.
La technologie COM peut également être utilisée pour accéder à des systèmes externes à partir du code d'application sur la plateforme 1C:Enterprise. Dans ce cas, l'application 1C fait office de client COM. Mais il faut rappeler que ces mécanismes ne fonctionneront que si le serveur 1C fonctionne dans un environnement Windows.
Mécanismes d'intégration implémentés dans les configurations standards
Format de données d'entreprise
Dans un certain nombre de configurations 1C (liste ci-dessous), basée sur le mécanisme d'échange de données de la plateforme décrit ci-dessus, un mécanisme prêt à l'emploi d'échange de données avec des applications externes est implémenté, qui ne nécessite pas de modification du code source des configurations (préparation des données l’échange se fait dans les paramètres des solutions applicatives) :
- "1C: Gestion d'entreprise ERP 2.0"
- "Automatisation complexe 2"
- "Comptabilité d'entreprise", édition 3.0
- "Comptabilité d'une entreprise CORP", édition 3.0
- "Commerce de détail", édition 2.0
- "Gestion du commerce de base", édition 11
- Gestion du commerce, édition 11
- « Salaires et gestion du personnel CORP », édition 3
Le format utilisé pour l'échange de données est , basé sur XML. Le format est orienté métier - les structures de données qui y sont décrites correspondent à des entités commerciales (documents et éléments d'annuaire) présentées dans les programmes 1C, par exemple : acte d'achèvement, ordre d'encaissement, contrepartie, article, etc.
L'échange de données entre l'application 1C et une application tierce peut avoir lieu :
- via un répertoire de fichiers dédié
- via le répertoire FTP
- via un service web déployé côté application 1C. Le fichier de données est passé en paramètre aux méthodes web
- par email
Dans le cas d'un échange via un service web, une application tierce initiera une session d'échange de données en appelant les méthodes web correspondantes de l'application 1C. Dans les autres cas, l'initiateur de la session d'échange sera l'application 1C (en plaçant le fichier de données dans le répertoire approprié ou en envoyant le fichier de données à l'adresse email configurée).
Également du côté 1C, vous pouvez configurer la fréquence à laquelle la synchronisation aura lieu (pour les options avec échange de fichiers via un répertoire et un e-mail) :
- selon horaire (avec une fréquence précisée)
- manuellement; l'utilisateur devra démarrer manuellement la synchronisation à chaque fois qu'il en aura besoin
Accusé de réception des messages
Les applications 1C conservent des enregistrements des messages de synchronisation envoyés et reçus et attendent la même chose des applications tierces. Cela permet d'utiliser le mécanisme de numérotation des messages décrit ci-dessus dans la section « Mécanisme d'échange de données ».
Lors de la synchronisation, les applications 1C transmettent uniquement des informations sur les changements survenus dans les entités commerciales depuis la dernière synchronisation (afin de minimiser la quantité d'informations transférées). Lors de la première synchronisation, l'application 1C téléchargera toutes les entités commerciales (par exemple, les éléments du répertoire des articles) au format EnterpriseData dans un fichier XML (puisqu'elles sont toutes « nouvelles » pour l'application externe). L'application tierce doit traiter les informations du fichier XML reçu de 1C et, lors de la prochaine session de synchronisation, placer dans le fichier envoyé à 1C, dans une section XML spéciale, les informations indiquant que le message de 1C avec un certain numéro a été réussi. reçu. Le message de réception est un signal à l'application 1C que toutes les entités commerciales ont été traitées avec succès par l'application externe et qu'il n'est plus nécessaire de transmettre des informations à leur sujet. En plus du reçu, un fichier XML provenant d'une application tierce peut également contenir des données à synchroniser par l'application (par exemple, des documents de vente de biens et de services).
Après avoir reçu le message de réception, l'application 1C marque toutes les modifications transmises dans le message précédent comme synchronisées avec succès. Seules les modifications non synchronisées des entités métier (création de nouvelles entités, modification et suppression d'entités existantes) seront envoyées à l'application externe lors de la prochaine session de synchronisation.
Lors du transfert de données d'une application externe vers l'application 1C, l'image est inversée. L'application externe doit remplir en conséquence la section de réception du fichier XML et placer de sa part les données métiers à synchroniser au format EnterpriseData.
Échange de données simplifié sans poignée de main
Pour les cas d'intégration simple, lorsqu'il suffit de transférer uniquement des informations d'une application tierce vers l'application 1C et que le transfert inverse des données de l'application 1C vers une application tierce n'est pas requis (par exemple, l'intégration d'un magasin qui transfère les informations de vente vers 1C : Comptabilité), il existe une option simplifiée de travail via un service web (sans accusé de réception), qui ne nécessite pas de paramétrage du côté de l'application 1C.
Solutions d'intégration personnalisées
Il existe une solution standard « 1C : Conversion de données », qui utilise des mécanismes de plate-forme pour convertir et échanger des données entre des configurations 1C standard, mais peut également être utilisée pour l'intégration avec des applications tierces.
Intégration avec les solutions bancaires
Norme , développé par des spécialistes 1C il y a plus de 10 ans, est en fait devenu un standard de l'industrie en Russie. La prochaine étape dans cette direction est la technologie , qui vous permet d'envoyer des documents de paiement à la banque et de recevoir des relevés de la banque directement depuis les programmes du système 1C:Enterprise en appuyant sur un bouton du programme 1C ; cela ne nécessite pas l'installation et l'exécution de programmes supplémentaires sur l'ordinateur client.
Il y a aussi .
autre
À noter , norme d'échange d'informations commerciales (développé conjointement avec Microsoft, Intel, Price.ru et d'autres sociétés), .
Source: habr.com