1s extensions de configuration de débogage. Extensions de configuration. Module de formulaire géré et gestionnaires d'événements dans les extensions de configuration

Le mécanisme d'extension de configuration est un mécanisme particulier conçu pour affiner une configuration extensible sans modifier cette configuration (y compris sans la retirer du support).

Lors de l'examen du mécanisme d'extension de configuration, les termes suivants seront utilisés :

Configuration extensible– la configuration principale de l'infobase pour laquelle l'extension est appliquée ou pour laquelle l'extension est en cours de développement.
Extension de configuration– un ensemble d'objets de configuration connectés à la configuration extensible et contenant un ensemble d'objets ajoutés à la configuration extensible. Une extension peut inclure à la fois les objets de configuration extensibles et des objets qui ne sont pas présents dans la configuration étendue.
propre objet– un objet de configuration autonome qui peut se trouver à la fois dans une configuration extensible et dans une extension (rapport, traitement ou sous-système).
Objet emprunté– objet propre ajouté à l'extension de configuration.
Objet extensible– objet propre, dont les paramètres (propriétés, formulaires, etc.) ont été modifiés dans l'objet emprunté.
Objet d'extension est un objet emprunté qui a été modifié par rapport à l'objet extensible. Avoir uniquement des propriétés contrôlées dans un objet emprunté ne fait pas de l'objet emprunté un extendeur.
Objet de résultat est son propre objet plus l'union de tous les objets d'extension (s'il y a plus d'une extension). S'il n'y a pas d'objets d'extension pour le propre objet, il devient le résultat "inchangé". Ceux. dans la configuration avec laquelle l'utilisateur travaille, tous les objets sont des objets de résultat, quels que soient la présence et le nombre d'extensions installées.
Extension de propriété– propriété de l'objet emprunté qui modifie la propriété de même nom de l'objet étendu.
propriété contrôlée– propriété de l'objet emprunté dont la valeur est vérifiée lorsque l'extension est connectée à la configuration étendue. Si, lors de la connexion d'une extension (en mode 1C:Enterprise), la valeur d'une propriété contrôlée dans l'extension ne correspond pas à la valeur de la même propriété dans la configuration en cours d'extension, l'extension ne sera pas connectée.
Propriété modifiable– propriété de l'objet emprunté, dont la valeur dans l'objet résultant sera obtenue à partir de l'extension.

Une propriété d'un objet emprunté ne peut pas être contrôlée et modifiée en même temps.

L'objectif principal de l'extension de configuration est d'affiner la solution appliquée lors de la mise en œuvre (ou dans le "cloud") aux besoins du client. Dans le même temps, la configuration finalisée n'a pas besoin d'être retirée du support. Par conséquent, il est facile de mettre à jour une solution d'application typique qui est sous support, avec la nécessité d'effectuer des améliorations. Lors du développement d'une extension, vous devez comprendre certaines caractéristiques du fonctionnement de l'extension de configuration. Ainsi, une configuration extensible peut être modifiée à tout moment, par exemple suite à une mise à jour. Dans le même temps, le développeur de l'extension ne peut en aucune manière influencer la possibilité ou l'impossibilité de la mise à jour. Vous devez également tenir compte du fait que plusieurs extensions peuvent fonctionner dans le système et que l'auteur de chaque extension ne sait (généralement) pas comment fonctionne l'autre extension.

L'extension est créée dans le configurateur, stockée dans l'infobase et peut être enregistrée dans un fichier. Il n'est pas nécessaire d'utiliser le configurateur pour ajouter (connecter) une extension enregistrée dans un fichier à la solution applicative d'un client spécifique. Vous pouvez connecter l'extension à l'aide d'une fonction standard spéciale (Toutes les fonctions - Standard - Gérer les extensions de configuration). Vous pouvez également connecter l'extension à l'aide de la boîte à outils de la solution d'application, qui utilise l'interface de programmation fournie par la plate-forme. Attacher une extension (de manière interactive ou à partir d'un langage intégré) est possible soit en mode non sécurisé, soit lorsque le profil de sécurité sous lequel la session s'exécute autorise l'accès à l'extension du plug-in.

Les objets extensibles peuvent être :

Formulaires gérés ;
Les rôles;
sous-systèmes ;
Paramètres de la page initiale (bureau) de la solution appliquée ;
Modules généraux ;
Modules d'objets pour tous types d'objets ;
Modules de gestion pour tous types d'objets ;
module de session ;
Module d'application géré ;
Module de connexion externe ;
module de commande.

Les objets suivants peuvent être utilisés comme objets d'extension personnalisés :

sous-systèmes ;
Traitement;
Rapports;
Exigences, parties tabulaires et détails des parties tabulaires dans les traitements et rapports empruntés ;
Les rôles;
forfaits XDTO ;
Services Web;
services HTTP ;
liens WS ;
Dispositions générales ;
Commandes générales ;
Modules partagés (à l'exception du serveur global et des modules partagés privilégiés) ;
Groupes de commandement ;
photos générales ;
Formes, mises en page et commandes des objets empruntés :
Forfaits d'échange ;
les critères de sélection;
Paramètres de stockage ;
répertoires;
Document ;
Journaux de documents;
Énumérations ;
Rapports;
traitement;
Registres d'informations ;
Registres d'accumulation ;
registres comptables;
Registres de calcul ;
Plans de types de caractéristiques;
Plans de comptes ;
Plans pour les types de calcul ;
Processus d'affaires;
Tâches;
Tableaux de sources de données externes ;
Cubes de sources de données externes ;
Tableaux de dimension des sources de données externes.

Parmi les propriétés contrôlées, il convient de souligner :

La composition du plan d'échange ;
Éléments prédéfinis pour les répertoires, les plans de types de caractéristiques, les plans de comptes et les plans de types de calculs.

L'utilisation d'extensions n'est pas prise en charge dans les versions de base des solutions d'application.

Le besoin de personnalisation du logiciel, c'est-à-dire ses changements aux besoins d'un utilisateur particulier sont apparus, probablement, simultanément avec le logiciel lui-même. Il est difficile d'écrire un programme qui satisfera tout le monde, c'est donc une bonne idée de permettre que des modifications soient apportées sans impliquer le producteur du programme. Surtout quand il s'agit d'applications d'entreprise, parce que. les processus métier, même dans les mêmes domaines, peuvent différer d'une organisation à l'autre.

Modification du code source

Il existe différentes stratégies de personnalisation. Si l'application est fournie en code source, l'approche la plus évidente consiste à réécrire le code source en fonction de vos besoins. Et le problème le plus évident dans ce cas est la transition vers une nouvelle version de l'application, car. cela implique la fusion des codes sources de la version modifiée côté client et de la nouvelle version du fournisseur. Et cela peut être une tâche non triviale, surtout si le code côté client est hautement personnalisé.

Plugins

Une stratégie plus sûre à cet égard est les plugins. L'application source fournit au plug-in un ensemble fixe d'interfaces, ainsi que la possibilité de s'enregistrer auprès de l'application. Lorsqu'une nouvelle version de l'application est publiée, les plugins écrits pour la version précédente continueront de fonctionner dans la nouvelle version (à condition que les interfaces restent inchangées). Le comportement des plug-ins dans la nouvelle version peut différer du comportement de la version précédente si le fournisseur du logiciel a modifié le comportement de l'application. Le concept de plug-ins est utilisé dans une grande variété de classes de logiciels - logiciels bureautiques et métiers, environnements de développement (Visual Studio, Eclipse, ...), éditeurs graphiques et sonores, etc.

Abonnements

Une autre technologie de personnalisation est la possibilité de s'abonner à des événements dans l'application et d'exécuter du code personnalisé dans un langage bien connu ou propriétaire pendant ces événements. Les événements peuvent être de types très différents - ouverture d'une fenêtre, chargement d'une image (pour un éditeur graphique), traitement d'une commande (pour un système métier).

Une variante de cette approche consiste à intégrer la capacité d'exécuter des scripts personnalisés dans des langages tels que Visual Basic for Application (VBA) dans le programme principal. Du code personnalisé peut notamment être exécuté en réponse à des événements applicatifs. Le même VBA s'est avéré être un outil de personnalisation très puissant et flexible ; il est intégré à Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS et d'autres produits.

Personnalisations dans les solutions 1C : le début

La plate-forme 1C:Enterprise met en œuvre diverses stratégies de personnalisation. Étant donné que les solutions appliquées 1C sont fournies dans les codes sources, l'un des scénarios les plus évidents consiste naturellement à modifier le code source.

Modification du code source des applications 1C

Lorsqu'un client modifie le code source d'une solution 1C pour l'adapter à ses besoins, il doit se rappeler que le fournisseur d'application n'est pas non plus inactif et publie de nouvelles versions, ajoutant des fonctionnalités et corrigeant des bogues. Pour que lors de l'installation d'une nouvelle version de l'application, les modifications apportées aux besoins du client ne soient pas perdues, vous devez en quelque sorte fusionner (fusionner) la version précédente modifiée de l'application et la nouvelle version.

Naturellement, chez 1C, nous avons accordé une grande attention à cette tâche et développé un mécanisme de livraison et de support qui facilite sa solution. Avant de dire comment cela fonctionne, quelques détails sur la structure interne des solutions 1C.

Les codes sources et les métadonnées de la solution applicative 1C (configuration) sont stockés dans la base de données, dans celle-là même qui contient les données de l'application elle-même (affichages, données des répertoires et documents, etc.), c'est-à-dire le programme est stocké avec les données. Une base de données avec une configuration (et des données d'application) dans la terminologie 1C est appelée une infobase (abrégé en infobase).

Au cours du processus de développement, le fournisseur de configuration détermine quels objets de configuration (ouvrages de référence, documents, etc.) le client peut modifier et lesquels ne le peuvent pas.

Mise en place de la livraison côté fournisseur

Le client de son côté, en utilisant ce mécanisme, peut également déterminer les règles de prise en charge des objets de la configuration implémentée du fournisseur - par exemple, il peut refuser la prise en charge par le fournisseur d'un objet particulier s'il prend la responsabilité d'une modification ultérieure de cet objet . Ou, au contraire, vous pouvez interdire la modification de l'objet de "votre" configuration (même si le fournisseur l'autorise) afin de vous assurer contre les modifications accidentelles.

Configuration de la prise en charge côté client

Lorsqu'un client commence à modifier quelque chose dans une configuration typique, deux configurations sont créées dans l'infobase :

Configuration du fournisseur d'origine.
La configuration actuelle telle que modifiée côté client.

Et maintenant, le fournisseur publie une nouvelle version. Il peut être fourni sous forme d'application complète, ou sous forme de service pack avec des objets modifiés. Lors de la migration vers une nouvelle version, nous avons 3 configurations côté client, sur la base desquelles s'effectue la fusion dite à trois voies des configurations :

L'ancienne configuration du fournisseur.
La configuration actuelle du client (l'ancienne configuration du fournisseur plus les modifications apportées par le client).
Nouvelle configuration du fournisseur.

Il est clair que dans certains cas, les objets modifiés par le fournisseur peuvent être mis à jour automatiquement :

Objets non modifiés par le client.
Modifications simples des objets côté client (par exemple, ajout d'attributs supplémentaires à l'objet).

Dans le cas où l'objet a été modifié à la fois côté client et dans la nouvelle version du fournisseur, une intervention manuelle est nécessaire. Nous avons un puissant mécanisme de comparaison et d'union non seulement pour les modules de code, mais aussi pour les modèles (métadonnées, formulaires, rapports…), mais même avec ce mécanisme, combiner des configurations peut être une tâche non triviale.

Rapports et traitement externes

Un autre mécanisme de personnalisation relativement sûr du point de vue du passage à de nouvelles versions est le mécanisme de rapports et de traitement externes. Comme leur nom l'indique, les deux types d'objets - rapports externes et traitement externe - sont externes à la solution d'application, sont stockés dans des fichiers séparés et chargés dans la solution d'application au moment de l'exécution. Ainsi, le processus de transition vers la nouvelle version ne les affecte pas du tout. Mais si dans la nouvelle version les détails d'un objet ont été supprimés ou renommés, et que le traitement ou le rapport y fait référence, le rapport ou le traitement ne fonctionnera pas sur la nouvelle version sans modification.

Les rapports et traitements externes sont essentiellement des plugins. Ils sont bien adaptés aux rapports "personnalisés" et aux opérations de données spécifiques (par exemple, pour importer des informations à partir d'autres systèmes), mais, bien sûr, ils ne couvrent pas tous les scénarios de personnalisation. Si le client a besoin d'ajouter un code spécifique qui doit être exécuté lors de la publication du document, un traitement externe est ici indispensable - vous devez modifier le code source du module de document.

Personnalisations du cloud

Avec l'avènement de la technologie cloud 1cFresh, la tâche de personnalisation a atteint un nouveau niveau. Le fait est que dans le "cloud", les utilisateurs de la solution appliquée de différentes organisations peuvent physiquement travailler avec une infobase (c'est-à-dire avec une instance de l'application), mais en même temps, grâce au mécanisme de partage de données, ils ne voient que le données de leur organisation. La personnalisation en modifiant le code source devient ici inacceptable - chaque organisation a besoin de ses propres personnalisations, et les personnalisations des "voisins" dans l'infobase sont totalement inutiles.

Dans le "cloud" pour la personnalisation, seule l'utilisation de rapports et de traitements externes est applicable, mais, comme mentionné ci-dessus, les rapports et les traitements externes ne couvrent pas tous les scénarios dont les utilisateurs ont besoin.

Extensions de configuration

Nous avons donc dû proposer un mécanisme de personnalisation qui répondrait aux exigences suivantes :

Faciliterait la mise à jour d'une solution personnalisée vers une nouvelle version, en évitant le travail manuel de fusion des configurations.
Autorisé à activer la personnalisation sous certaines conditions (par exemple, si nous travaillons dans le cadre d'une organisation particulière).
Réduction de la probabilité que la personnalisation perde sa fonctionnalité lors du passage à une nouvelle version de la configuration d'origine.
Avait la possibilité de désactiver la personnalisation en cas de problème pour que l'application continue de fonctionner.

Un tel mécanisme, en plus d'être utilisé dans les solutions cloud, faciliterait grandement la vie lors du passage à une nouvelle version sur la mise en place de configurations standards où des personnalisations sont nécessaires.
Nous avons proposé un tel mécanisme et l'avons appelé extensions . Ce mécanisme, en un sens, combine deux approches de personnalisation - l'idéologie des plugins et le mécanisme d'abonnement.

Les extensions sont un moyen de séparer les changements de configuration de la configuration elle-même. L'extension est, en fait, elle-même une configuration séparée contenant des objets modifiés. Comme la configuration, elle est représentée sous la forme d'un arbre d'objets. Pour travailler avec l'extension, on utilise les mêmes méthodes de travail qu'avec la configuration habituelle :

Si nous voulons utiliser un objet de la configuration principale dans l'extension (par exemple, ajouter un nouveau formulaire à un document existant dans la configuration principale), nous devons d'abord emprunter l'objet dans notre extension à l'aide de la commande "Ajouter à l'extension" . Immédiatement après avoir ajouté un objet à l'extension, il est "vide" dans l'arborescence des objets d'extension - il n'a que les propriétés qui se trouvent dans la configuration principale. Vous pouvez également emprunter un formulaire existant de la configuration principale et, par exemple, y ajouter un nouveau bouton qui effectue une action spécifique. Il n'est pas encore possible d'ajouter de nouveaux attributs aux objets dans les extensions, mais nous y travaillons.

Configuration de base et extension avec document emprunté InvoiceIssued

L'extension a également un analogue de l'abonnement aux événements - la capacité de traiter les événements des objets de la configuration extensible, par exemple, le traitement des enregistrements. Vous pouvez spécifier exactement comment notre code sera appelé dans l'extension :

Avant la procédure standard d'écriture d'un document, on peut appeler notre code, qui va par exemple vérifier si le champ de l'employé responsable du document est renseigné, et sinon, il va écrire l'utilisateur courant dans ce champ :

&After("BeforeWrite") Procedure ExtendAndromeda_BeforeWrite(Cancel,WriteMode, PostMode) If (ThisObject.Owner = Catalogs.Users.NullReference()) Then ThisObject.Owner = ModuleUsers.GetCurrentUser(); Fin si; FinProcédure
Dans la nouvelle version de la configuration, l'implémentation de l'entrée de document peut changer, mais notre code dans l'extension s'exécutera toujours avant le code d'entrée de document standard et fera son travail.

Au moment de l'exécution, une configuration typique et des extensions (il peut y en avoir plusieurs) « s'additionnent », résultant en une nouvelle configuration personnalisée, avec laquelle l'utilisateur final travaille.

Ordre d'exécution des extensions

Lors du développement d'extensions, gardez à l'esprit que la plate-forme ne garantit pas que les extensions s'exécuteront dans le même ordre lors de l'ajout de plusieurs extensions à une configuration. Nous avons délibérément abandonné le paramétrage explicite de l'ordre d'exécution des extensions, car ceci, à notre avis, complique la configuration et introduit finalement plus de problèmes qu'il n'en résout.

Si nous ajoutons plusieurs extensions à la configuration, dont chacune a le traitement de tenir le même document avec la directive "&After", alors tous les gestionnaires seront exécutés, mais la plateforme ne garantit pas que l'ordre de leur exécution sera toujours le même. Ceci doit être pris en compte lors du développement d'extensions.

S'il existe un gestionnaire pour le même événement dans plusieurs extensions avec la directive "&Instead", un seul gestionnaire sera exécuté, et il est impossible de dire à l'avance lequel. Ceci doit être gardé à l'esprit et surveillé afin que pas plus d'une extension de la configuration ait un gestionnaire "&Instead" pour le même objet/événement.

Personnalisation du formulaire dans les extensions

Nous pouvons emprunter la forme d'un objet de la configuration (par exemple, la forme d'un document) dans notre extension. En même temps, dans l'éditeur de formulaire visuel de l'extension, nous verrons le même formulaire que dans la configuration principale. Et dans l'éditeur de code de formulaire, l'extension sera vide - tout le code du formulaire est toujours contenu uniquement dans la configuration principale.

Vous pouvez ajouter un nouveau bouton (ou même plusieurs) au formulaire. Si plusieurs extensions ajoutent leurs propres boutons au même formulaire, tous seront présents sur le formulaire final lors de l'exécution.

Mais il n'est pas recommandé de supprimer les éléments standard du formulaire - cela peut casser le code existant dans la configuration d'origine (s'il accède aux éléments du formulaire). S'il y a un tel besoin, il est préférable de rendre les éléments invisibles grâce à la propriété "Visibilité".

Il faut tenir compte du fait qu'une application 1C:Enterprise n'est pas simplement du code dans un langage de programmation. La majeure partie de l'application est décrite sous la forme de modèles déclaratifs. De plus, différents types de modèles sont utilisés pour différentes tâches (formulaires, rapports, droits, ....). Pour chaque type de modèle, nous sélectionnons notre propre méthode de personnalisation dans les extensions, qui fournit le changement le plus pratique pour les cas typiques.

Avantages des extensions

Les extensions sont idéologiquement distinctes du mécanisme de livraison et de soutien. Dans le mécanisme de livraison et de support, le développeur édite la configuration du fournisseur comme il le souhaite, comme s'il venait de finaliser sa configuration, puis (lors de la mise à jour) il a compris comment synchroniser les modifications conflictuelles. Dans les extensions, le développeur développe immédiatement l'extension en termes de fonctionnalités ajoutées. L'extension est stockée par le système exactement comme un add-on et le système se charge de la mise à jour la plus sécurisée.

Facilité de transition vers une nouvelle version de la configuration

Lorsqu'un fournisseur publie une nouvelle version de la configuration générique, une mise à jour automatique est effectuée car le mode de prise en charge de la configuration générique n'a pas changé - il reste au support complet du fournisseur. Et lorsque vous lancez une solution d'application mise à jour, la plate-forme combinera à nouveau automatiquement la configuration standard modifiée avec l'extension. Et le client continuera à travailler avec une solution standard modifiée en fonction de ses besoins.

Parfois, cependant, après la mise à jour de la version de la configuration standard, il peut être nécessaire d'adapter l'extension à la nouvelle version, par exemple si les objets ou les attributs des objets concernés par l'extension sont renommés dans la nouvelle version. Un peu plus à ce sujet ci-dessous, dans la section "Notification précoce des erreurs".

Les modifications sont séparées

Le premier avantage évident des extensions est que toutes les personnalisations faites pour le client sont séparées de la configuration typique, et maintenant il n'est plus nécessaire de comparer la configuration modifiée avec la configuration typique afin de comprendre exactement ce qui a été changé.

Il a déjà été mentionné que pour utiliser un objet de la configuration principale dans l'extension, il doit être emprunté dans l'extension à partir de la configuration principale. Ainsi, quelque chose comme une référence à un objet de la configuration principale apparaît dans l'extension.

En même temps, il existe un moyen de comprendre quels objets empruntés dans la configuration sont réellement modifiés et lesquels sont empruntés en mode lecture seule - par exemple, pour une utilisation dans des rapports. Dans l'arborescence des objets d'extension, il y a un bouton de filtre "Modifié et ajouté dans l'extension", après avoir appuyé sur lequel seuls les objets empruntés modifiés dans cette extension et les nouveaux objets créés dans cette extension restent dans l'arbre.

Notification d'erreur précoce

Supposons que nous empruntions le répertoire Contracts de la configuration principale dans l'extension pour l'utiliser dans le rapport. Entre-temps, une nouvelle version de la configuration standard a été publiée, dans laquelle le répertoire Contracts a été renommé Contracts. Naturellement, après la transition vers la nouvelle version, notre rapport dans l'extension ne fonctionnera pas. Si nous utilisions l'ancienne technologie de personnalisation - un rapport externe, l'erreur ne se produirait qu'au moment de l'exécution du rapport. Dans le cas des extensions, nous avons la possibilité de vérifier l'exactitude des extensions au moment de la conception après la mise à jour de la version de la configuration typique et de résoudre tout problème avant que les utilisateurs ne commencent à travailler.

Cela est particulièrement vrai dans les implémentations où de nombreuses extensions sont utilisées dans une infobase et la version de configuration est mise à jour de manière centralisée (par exemple, dans les implémentations cloud, où différentes organisations utilisant la même configuration mais travaillant dans différentes zones de données peuvent utiliser différents ensembles d'extensions) . L'administrateur peut mettre à jour la version de la configuration type sur une base de test et vérifier l'exactitude de toutes les extensions utilisateur par rapport à la nouvelle version. En cas de problèmes, il les signalera aux propriétaires des extensions, et la transition de la base de travail vers la nouvelle version de la configuration type ne se fera que lorsque toutes les extensions seront mises en conformité avec la nouvelle version de la configuration.

Et après?

Nous considérons le développement d'extensions comme l'une des principales directions dans le développement d'outils de personnalisation dans la plate-forme 1C:Enterprise. Les extensions, conçues à l'origine pour faciliter la personnalisation dans le service cloud, ont également été conçues pour faciliter les situations de personnalisation dans les implémentations non cloud.

Alors que dans les extensions, vous ne pouvez pas personnaliser tout ce que vous voulez. Par exemple, il n'est pas encore possible de créer de nouveaux objets applicatifs (répertoires, documents, etc.) et il est impossible d'ajouter de nouveaux attributs à des objets applicatifs existants. Nous travaillons là-dessus (et sur d'autres fonctionnalités également), et dans presque toutes les nouvelles versions de la plate-forme 1C:Enterprise, nous ajoutons de nouvelles fonctionnalités aux extensions : Ajouter des balises

S'est avéré très pertinent :)

Ok, rendons ce week-end utile aussi.

Donc, aujourd'hui un autre sujet de "l'opération appliquée 1C":

Mécanisme d'extension dans la plate-forme 8.3.6

De quoi parle-t-on?

Dans la plate-forme 8.3.6, un nouveau mécanisme a été implémenté - mécanisme d'extension qui facilite l'adaptation de la solution applicative pour un client spécifique.

Lors de l'utilisation d'extensions la configuration est finalisée dans une nouvelle entité– extension de configuration :

L'extension, en fait, est aussi une configuration, mais avec quelques restrictions
L'extension préparée peut être connectée à la base de données de travail du client en mode utilisateur
Le plus important - la configuration finalisée n'a pas besoin d'être retirée du support, c'est à dire. il reste standard, inchangé
Mise à jour de la configuration modifiée peut être exécuté automatiquement par l'utilisateur

Ainsi, le client reçoit en conséquence possibilité d'amélioration configuration et en même temps mise à jour automatique simple.

Afin que vous puissiez traiter cela plus en détail, nous publions quelques vidéos + PDF supplémentaires sur les extensions.

Alors allons-y:

Affectation d'extensions de configuration

La vidéo couvre le nouveau mécanisme d'extensions de configuration introduit dans la plate-forme 8.3.6. Il est destiné au raffinement, à l'adaptation des solutions lors de la mise en œuvre. Dans le même temps, le client reçoit une simple mise à jour automatique de la configuration et la possibilité d'apporter des améliorations.

Objets pouvant être modifiés dans une extension

Cette vidéo traite des limitations existantes du mécanisme d'extension. Actuellement, seul un nombre limité d'objets peuvent être utilisés dans les extensions.

Travailler avec des extensions dans le configurateur

Cette vidéo couvre le développement des extensions dans le configurateur. L'extension est une configuration, bien que quelque peu limitée. L'utilisation de l'extension s'effectue également dans l'arborescence des objets de métadonnées. L'extension résultante peut être enregistrée dans un fichier sur le disque.

Emprunter des objets

Cette vidéo examine l'emprunt d'objets de configuration de base dans une extension. C'est le principal mécanisme nécessaire pour mener à bien le développement de l'extension elle-même. Il parle également des propriétés contrôlées, dont la valeur est vérifiée lorsque l'extension est connectée.

Création de vos propres objets dans l'extension de configuration

Cette vidéo montre comment vous pouvez créer vos propres objets dans l'extension. La liste de ces objets est encore limitée - il s'agit de rapports, de traitement et de sous-systèmes. Le développement de tels objets dans l'extension s'effectue par analogie avec la configuration principale.

Utilisation des extensions en mode utilisateur

Cette vidéo montre comment connecter l'extension préparée à la base de travail du client. Dans ce cas, la connexion peut se faire depuis le mode utilisateur sans accéder au configurateur.

Utilisation des formulaires gérés dans les extensions de configuration

Cette vidéo vous explique comment utiliser les formulaires gérés dans l'extension. Il est à noter que le formulaire d'origine n'est pas automatiquement synchronisé avec l'extension. Explique comment le système génère l'apparence résultante du formulaire en présence d'une extension.

Module de formulaire géré et gestionnaires d'événements dans les extensions de configuration

Cette vidéo vous explique comment utiliser les gestionnaires d'événements dans les formulaires d'extension de configuration gérée.

L'ordre d'exécution des gestionnaires d'événements dans la configuration principale et dans l'extension est démontré.

Après avoir étudié l'expérience d'utilisation des versions précédentes du programme et en tenant compte du fait que, quelle que soit l'universalité et l'exhaustivité d'une solution particulière, au final, dans 90% des cas, elle doit être finalisée pour l'utilisateur final. Les développeurs de la version 8 du programme 1C ont mis en œuvre plusieurs solutions fondamentalement nouvelles pour minimiser la nécessité de modifier les mécanismes de configuration standard :

Littéralement à partir des premières versions du programme, les éléments de nombreux répertoires ont la possibilité de créer des propriétés et des catégories supplémentaires en utilisant le plan correspondant de types de caractéristiques et le registre d'informations ;
Des formulaires imprimés supplémentaires et des formulaires pour remplir des parties tabulaires, ainsi que des rapports et des traitements supplémentaires peuvent désormais être appelés à partir du répertoire correspondant ;
Le traitement des procédures standard des objets s'effectue non pas en apportant des modifications au module, mais en s'abonnant à des événements ;
Et, enfin, à partir de la version 8.3.6 de la plateforme, des extensions de configuration sont apparues en 1C.

Que sont les extensions de configuration 1C, comment les utiliser, les limites d'utilisation - c'est la gamme de problèmes que nous essaierons de révéler dans notre article.

Un peu de théorie

Avant l'avènement du mécanisme d'extension, le processus de mise à jour des configurations génériques dépendait en grande partie du maintien ou de la modification de la configuration. Dans ce dernier cas, le développeur devait :

Comparez la structure de métadonnées typique et existante ;
En cas de différence significative entre des éléments typiques, suivez la mise à jour correcte ;
Effectuez les modifications appropriées après la mise à jour.

Tout cela a grandement compliqué le processus de mise à jour, augmentant le temps de développement et, souvent, privé l'organisation de la possibilité de mettre à jour des modules typiques de logiciels coûteux.

Le mécanisme d'extension vous permet de modifier bon nombre de ses éléments sans supprimer la configuration standard du support. En fait, le développeur, à partir d'une solution type, crée sa propre configuration, qui est un shell pour une solution type. Dans ce cas, le processus de mise à jour de la pièce type se produit automatiquement, tandis que lorsqu'il est lancé par l'utilisateur final, la plate-forme combine les deux solutions pour l'utilisateur.

Situations où les extensions peuvent être utilisées

Comme tout autre outil, le mécanisme d'extension présente un certain nombre de caractéristiques et de limites qui déterminent la portée de son utilisation :

Les extensions peuvent fonctionner avec des formulaires gérés ;
Le mécanisme prend en charge la modification et l'ajout de sous-systèmes existants ;
Avant la sortie de la plate-forme 8.3.8, il n'était possible de modifier que les rôles existants dans l'extension, après la mise à jour, ils permettaient d'en ajouter de nouveaux, restreignant l'accès même aux objets de la base de données principale ;
Le mécanisme existant vous permet de modifier à volonté l'interface de commande des sous-systèmes et la section de configuration principale ;
En outre, cette boîte à outils vous permet d'ajouter des traitements et des rapports sans apporter de modifications à la structure de la base de données ;
Dans la version 8.3.9.718 de la plateforme, le mécanisme de diagnostic de la compatibilité de l'extension et de la configuration principale a été considérablement repensé.

De ce qui précède, il ressort clairement que :

Lorsque vous travaillez avec des formulaires réguliers, la fonctionnalité des extensions est considérablement limitée ;
Bien que le processus de mise à jour de la configuration principale ait été facilité, la possibilité d'utiliser une extension spécifique (y compris comme solution de circulation) peut être sérieusement limitée à la fois par des modifications de la structure d'origine et par plusieurs extensions utilisées en parallèle ;
Il est conseillé d'utiliser ce mécanisme dans les cas où il est nécessaire de différencier l'apparence et les fonctionnalités utilisées par différents utilisateurs, ou lorsqu'une configuration standard en cours de support est en cours de finalisation.

Passons à la pratique. Comme base initiale, nous utiliserons la configuration "Gestion des salaires et du personnel" version 3.1.3.223, le travail s'effectuera sur la plateforme 8.3.10.2561, le mode de travail est fichier.

Créer une extension

Dans le configurateur, entrez dans le menu Configuration->Extensions de configuration, un formulaire s'ouvrira (Fig.1).

C'est ici que vous pouvez créer une nouvelle extension. Cliquez sur le bouton "Ajouter". Voici la fenêtre de la nouvelle extension (Fig. 2)

Fig.2

Considérez ses éléments:

Nom - contrairement aux autres éléments de configuration, il n'est pas créé selon les normes du système, c'est-à-dire peut commencer par un chiffre ou un symbole, peut contenir un espace ;
Synonyme - comme pour les autres éléments de métadonnées, il contient une expression-représentation d'un objet ;
Préfixe - vous permet d'identifier les gestionnaires d'événements dans le module de formulaire, car le module de formulaire de configuration principal et le module de formulaire d'extension sont combinés lorsque la plate-forme fonctionne dans un contexte commun (par défaut, l'extension est traitée en premier, c'est-à-dire les gestionnaires avec un préfixe, puis les gestionnaires principaux) ;
Rendez-vous.

La liste du champ "Destination" est constituée de trois valeurs, nous allons les décrire dans l'ordre d'exécution :

Correction - des extensions de cet objectif sont créées pour corriger les inexactitudes et erreurs mineures dans les objets empruntés ;
Adaptation - la valeur par défaut, les extensions de ce type sont conçues pour ajuster les objets standard aux exigences d'un utilisateur particulier (si l'extension a été créée dans une version du programme inférieure à 8.3.9, après la mise à jour de la plate-forme, elle aura exactement ce but );
Ajout - ils apportent une toute nouvelle fonctionnalité à la solution standard.

Lancer une extension

Double-cliquez sur le nom de l'extension dans la fenêtre de la Fig.1, ouvre la fenêtre de l'extension (Fig.3)

Comme vous pouvez le voir, il s'agit d'un arbre similaire à l'arbre de configuration principal. Et ici une question se pose, dans quels cas faut-il emprunter un objet ?

Il est nécessaire d'emprunter uniquement les objets (dictionnaires, documents, détails, etc.) qui seront utilisés dans l'extension du formulaire, ou dans le code de son module, et sans emprunter lesquels une erreur peut survenir dans l'opération d'extension.

C'est-à-dire que si notre développement nécessite l'attribut "TIN" de l'annuaire "Particuliers", s'il est utilisé dans le module formulaire, nous devons l'emprunter à la base de données principale. Dans ce cas, à chaque lancement de l'extension, on vérifiera la présence de cet attribut dans le référentiel de configuration principal et la correspondance du type de données dans la base source et dans l'extension.

Si après la mise à jour ou pendant le développement de nouvelles fonctionnalités, il y a une incohérence entre les types de données d'extension et de configuration ou d'autres erreurs, le système en informera l'utilisateur (Fig. 4)

La fenêtre dans le coin inférieur droit indique une situation non standard lors de la connexion de l'extension, un double-clic dessus ouvre des informations détaillées. Dans ce cas, nous avons simplement changé le type de valeur de l'attribut TIN de la valeur "String" à la valeur "Boolean" pour l'objet emprunté, mais la situation inverse se produit beaucoup plus souvent - lorsque la mise à jour d'un produit standard entraîne un changement ou suppression de l'attribut principal de la base de données.

Après avoir élaboré et testé l'extension sur une copie de la base, elle peut être téléchargée dans un fichier séparé; pour cela, dans la fenêtre (Fig. 5), vous devez cliquer sur le bouton "Configuration", sélectionner "Enregistrer dans un fichier " article. Contrairement aux fichiers de configuration ordinaires qui ont l'extension cf, le fichier complémentaire de configuration aura un masque *.cfe.

Comme le montre la figure ci-dessus, vous pouvez charger de nouvelles fonctionnalités à partir de la même fenêtre ou à partir de la fenêtre principale du programme.

Pour connecter l'extension en mode 1C.Enterprise, l'utilisateur doit avoir activé le mode "Toutes les fonctions" et le programme doit être connecté avec des droits d'administrateur.

La manière de connecter le raffinement est la suivante : Toutes les fonctions->Standard->Gérer les extensions de configuration. La fenêtre d'ouverture est illustrée à la Fig.6

Fig.6

Cliquer sur le bouton "Ajouter" ouvre une boîte de dialogue de sélection de fichier dans laquelle vous devez sélectionner notre téléchargement. Si le traitement est coché (Fig. 7) et que l'extension contient une erreur, la connexion de la fonctionnalité sera annulée et le programme signalera une exception.

Fig.7

Pour que notre fonctionnalité fonctionne après un ajout réussi, le programme doit être redémarré.

Emprunter des objets et l'ordre des modules de tir

Afin de tracer la séquence d'exécution des gestionnaires, nous allons activer la possibilité de modifier notre configuration et d'y ajouter un nouveau traitement, dont la fonctionnalité consistera en une seule chose - il signalera qu'il a été lancé depuis le principal configuration, le code de la Fig. 8.

Fig.8

Ajoutons ce traitement à l'extension.

Pour ça:

Cliquer avec le bouton droit pour activer le menu contextuel du formulaire de traitement (Fig. 9) ;

Fig.9

Sélectionnez l'élément "Ajouter à l'extension" ;
Le traitement lui-même et un duplicata de sa forme apparaîtront dans l'arborescence de configuration supplémentaire ;
Après avoir ouvert le formulaire, nous constatons que la commande à l'origine du message est également présente, mais aucun gestionnaire ne lui a été attribué.
L'ajout d'une action de commande fait apparaître une boîte de dialogue (Fig. 10) dans laquelle, outre les directives principales du site d'exécution de la commande, se trouve également un groupe Type d'appel.

Fig.10

Nous avons trois types d'appel pour la procédure donnée ;

Appeler avant – l'exécution du code d'extension sera lancée avant que la configuration principale ne soit terminée ;
Appeler après - la procédure modifiée deviendra le deuxième numéro ;
Appelez à la place - la procédure de la configuration principale ne sera pas exécutée du tout.

Laissons le type d'appel dans la position "Call after" et ajoutons la procédure "Ext1_NotifyAfter(Command)" (Fig.11).

Fig.11

Le résultat du démarrage de notre traitement sera séquentiellement signalé deux phrases (Fig. 12), c'est-à-dire qu'un message de configuration supplémentaire sera affiché après le message principal. Si nous choisissions "Au lieu de cela", nous ne verrions pas du tout la première ligne.

Fig.12

À partir de la version 8.3.9.1818, la fonctionnalité du programme comprenait un mécanisme de modification des modules standard, ainsi que l'ajout de modules personnalisés. Et ici, les développeurs ont dû faire face à une tâche très spécifique: comment déterminer dans quel ordre les procédures et fonctions empruntées doivent être exécutées non seulement par rapport à la configuration principale, mais également par rapport aux extensions déjà incluses dans la configuration.

Mécanisme d'annotation

Imaginez une situation où plusieurs extensions sont connectées à une configuration, c'est-à-dire que la fenêtre pour les sélectionner dans le configurateur ressemble à (Fig. 13)

Fig.13

Lors de l'ajout de chaque nouvelle extension, le système construit indépendamment l'ordre de leur exécution.

L'ordre d'exécution des modules supplémentaires est défini en fonction non seulement de l'heure à laquelle le module a été ajouté (plus tard ajouté, plus tard exécuté), mais également en fonction de l'objectif de la révision ("Exécution" viendra toujours avant "Adaptation").

De plus, la séquence d'exécution des procédures des modules ajoutés peut être contrôlée à l'aide d'annotations :

&Avant("NomProcédure");
&Après("NomProcédure");
&Au lieu("NomProcédure").

Comme vous pouvez le voir, leur ensemble est similaire à ce qui a été démontré dans la section précédente, et la fonctionnalité est similaire.

Étant donné que le module emprunté et le module donneur se trouvent dans le même espace de noms, aucune définition supplémentaire pour les variables de type et les méthodes n'est nécessaire dans ce cas.

La situation des fonctions est quelque peu différente de celle des procédures. Le fait est que l'exécution d'une procédure typique peut être, pour ainsi dire, bordée d'un code d'extension, c'est-à-dire que vous pouvez insérer certaines actions avant le code de la procédure, certains algorithmes après, mais pour les fonctions, cela ne fonctionnera pas. Si la fonction principale est exécutée après le code d'extension, la valeur de retour de la fonction de remplacement ne sera pas reçue, mais si avant l'algorithme modifié, la valeur de la fonction principale ne sera pas reçue et l'annotation &After fonctionnera comme &À la place.

Pour éliminer cette "injustice", la méthode ContinueCall() a été créée.

De manière générale, l'utilisation de l'annotation "Au lieu de cela" est un peu incorrecte, bien qu'elle soit parfois nécessaire. En l'utilisant, nous limitons largement les fonctionnalités qui peuvent être considérablement modifiées et améliorées dans les configurations standard.

Apporter des modifications au module d'objet

Le mécanisme d'abonnement aux événements a grandement facilité le travail des développeurs, mais il y avait un sérieux MAIS.

Mais pour l'utiliser, il fallait souvent créer son propre module commun, qui stockerait les procédures de traitement de certaines actions avec des données. A l'heure actuelle, l'utilisation d'extensions a permis de revoir largement cette fonctionnalité.

Supposons que, dans le processus de travail, nous devions ajouter un traitement pour le document standard « Emploi » lors de sa rédaction. Auparavant, nous allions aux abonnements et agissons à partir de là, maintenant nous pouvons ajouter ce document à l'extension :

Sélectionnons "Embauche" dans le configurateur et ajoutons-le à notre extension depuis son menu contextuel (au fait, ce mécanisme a une combinaison de raccourcis clavier Alt + Maj + F2);
Après avoir sélectionné l'addition appropriée, nous obtiendrons une image, comme sur la Fig.14 ;

Fig.14

Nous nous intéresserons à l'élément «Module d'objet» surligné en jaune, ouvrez-le en activant d'abord la coche correspondante (Fig. 15);

Fig.15

Nous allons obtenir une feuille propre du module de programme, faites attention au panneau supérieur, ou plutôt à l'élément illustré à la Fig. 16, dans la liste déroulante, il y a des événements qui peuvent être traités pour cet objet;

Fig.16

Essayons d'afficher le numéro du document dans le message lorsqu'il est rédigé en sélectionnant l'événement approprié ;
Nous recevrons un formulaire de sélection du type d'appel (Fig.17), déterminez quand le numéro sera affiché ;

Fig.17

Le code de procédure est illustré à la Fig.18 ;

Fig.18

Dans certains cas, en raison de la case à cocher "Mode sans échec" cochée, l'extension se connecte avec une erreur.

Petite annonce

Dans un avenir proche, 1C prévoit de publier la plate-forme 8.3.11, dans laquelle ils ont annoncé la possibilité d'ajouter la leur :

Document ;
répertoires;
Forfaits d'échange ;
registres d'informations.

Il devrait également être possible d'ajouter des détails et des parties tabulaires. Dans le même temps, les développeurs ont pris en compte la possibilité de modifier les solutions standard, ce qui peut entraîner une défaillance du fonctionnement de l'extension.

Les données saisies dans l'extension ne seront pas perdues, et tant que le problème de compatibilité ne sera pas résolu, le répertoire de configuration principal modifié par l'extension ne sera pas disponible en écriture.

Dans cet article, je vous propose de réfléchir à ce qu'est une "extension de configuration", comment ajouter une extension ou la désactiver. A partir de la version 1C Le 8.3.6.1977, un nouveau mécanisme a été introduit dans la plate-forme - les extensions de configuration. Tout d'abord, un peu de théorie.

Les extensions dans 1C ressemblent à des configurations parallèles qui sont automatiquement fusionnées avec la configuration principale du fournisseur. De plus, dans les extensions, vous pouvez ajouter à la fois vos propres objets et emprunter des objets de la configuration principale.

A quoi servent les extensions ?

Tout d'abord, des extensions sont créées pour faciliter les modifications du programme. Autrement dit, si les utilisateurs demandent à ajouter des fonctionnalités, avant l'avènement des extensions, les programmeurs devaient supprimer la configuration du support complet et modifier la configuration typique.

La suppression du support complet entraîne un certain nombre d'inconvénients :

la possibilité de mise à jour automatique disparaît, ce qui entraîne au moins une augmentation du temps de ;
un spécialiste hautement qualifié au service du programme est requis ;
si des modifications ont été apportées aux objets standard d'une configuration typique, ils peuvent disparaître lors de la mise à jour, c'est-à-dire qu'ils peuvent être remplacés à nouveau par des objets standard du fournisseur.

Lors de l'utilisation d'extensions, lors de modifications, le programmeur ne touchera pas à la configuration standard. Toutes les modifications seront apportées à l'aide d'extensions, qui (comme je l'ai écrit ci-dessus) sont également des configurations. Ainsi, la configuration principale restera au support complet.

Après la mise à jour de la configuration principale, s'il y a des modifications dans la nouvelle version avec un objet qui a été précédemment modifié par l'extension, les modifications seront toujours prises à partir de l'extension. Autrement dit, les extensions ont priorité sur la configuration principale.

Vidéo - extensions en 1C en 45 minutes

Obtenez gratuitement 267 leçons vidéo 1C :

Un exemple d'ajout d'une extension à 1C

Pour montrer ce qu'est une extension, mieux vaut donner un exemple de sa création dans le configurateur 1C.

Dans le configurateur, allez dans le menu "Configuration" et sélectionnez l'item "Extensions de configuration". Une fenêtre s'ouvrira avec une liste d'extensions (le cas échéant). Cliquez sur le bouton "Ajouter" et ajoutez une nouvelle extension. Vous pouvez maintenant ouvrir la configuration de l'extension :

Comme vous pouvez le voir, la configuration de l'extension a exactement la même structure que la principale. Seulement il est d'abord complètement pur, sans objets.

J'ai récemment écrit un article sur la façon de créer le vôtre. En utilisant son exemple, je veux le rendre en ligne en utilisant une extension.

En traitement, j'ai un champ avec un lien vers le répertoire "Organisations". C'est pourquoi j'ai besoin de ce guide. Mais nous n'allons pas créer un nouvel annuaire des Organisations, d'autant plus que la plateforme ne le permettra pas. Vous ne pouvez pas avoir d'objets dans la configuration d'extension qui portent le même nom que des objets dans la configuration principale.

Nous allons donc emprunter le répertoire à la configuration principale :

Maintenant, nous allons faire un clic droit sur "Traitement" et sélectionner "Insérer un traitement externe, rapport ..." Ainsi, nous allons ajouter un nouveau traitement à la configuration de l'extension. Si vous utilisez mon traitement, renommez-le immédiatement, car la configuration principale a déjà un traitement portant ce nom.

Eh bien, la touche finale. Je souhaite que mes traitements soient répercutés dans le menu "Administration". Pour ce faire, nous emprunterons le sous-système de la configuration principale du même nom. N'oubliez pas d'indiquer dans le traitement qu'il appartient à ce sous-système.

Voici la structure que j'ai obtenue :

Voyons ce que nous avons. Nous mettons à jour la configuration de la base de données et exécutons le programme en mode 1C: Enterprise, et allons dans le menu "Administration". Oui, j'ai failli oublier, la configuration de l'extension doit être fermée, sinon le programme ne démarrera pas :