La définition de la fonction procédure 1c est attendue. Extension de modules. Préparation de rapports externes et traitement pour publication dans le modèle de service

Aujourd'hui, nous voulons vous parler de l'utilisation de rapports et de traitements supplémentaires, et en particulier des extensions de configuration dans le modèle de service. Les technologies ne s'arrêtent pas là, la maintenance des bases de données 1C dans le cloud devient un service de plus en plus attractif. Ce que vous devez savoir pour que les fonctionnalités nécessaires à votre entreprise soient implémentées dans une base de données louée, et à quoi ressemble ce processus du côté du fournisseur de services - vous pouvez le découvrir sous la coupe.

Que sont les rapports externes et le traitement ?

Selon la fonctionnalité de traitement, ils sont divisés en ceux qui peuvent modifier les données et ceux qui analysent simplement les informations et affichent le résultat sous une forme conviviale (rapports). Afin de ne pas modifier les mises en page standard pour l'impression des documents, des formulaires d'impression externes sont en cours de développement. De plus, le traitement externe peut être effectué selon un calendrier donné sur le serveur d'application 1C - ce sont des tâches planifiées.

Plusieurs dizaines de traitements ont été développés dans le Bouton, permettant à nos comptables d'utiliser la « magie pratique ». Par exemple, pour analyser l'exactitude de la comptabilité dans le bouton, le rapport externe «Bases de données d'audit automatique» est utilisé. Des tableaux faciles à lire affichent une analyse de 120 critères pour les soldes et les chiffres d'affaires des comptes, la conformité des données des déclarations fiscales et des informations comptables, l'analyse des immobilisations, etc.

Un exemple d'imprimé externe « contrat de prêt » selon le formulaire développé par nos avocats. Il existe des cas où un entrepreneur contracte un prêt sans intérêt auprès de son entreprise en tant que particulier, ou inversement, transfère ses propres fonds à l'entreprise, il est alors possible d'imprimer immédiatement le contrat.

Un formulaire s'ouvrira pour remplir les informations requises :

Et le formulaire imprimé du contrat s'affiche :

Les traitements planifiés (tâches planifiées) permettent par exemple de corriger un extrait. Le bouton a des intégrations avec les principales banques et des robots spéciaux téléchargent le relevé directement sur 1C. Grâce à la technologie d'apprentissage automatique, le pourcentage d'erreurs lors du paiement a été réduit à 3 %. Mais comme toujours, il existe des exceptions, par exemple, les clients qui utilisent un système d'agence pour la vente de biens, dans ce cas les règles de réalisation d'un relevé bancaire sont individuelles. Afin de ne pas reprogrammer le robot pour un cas particulier, avant l'avènement des extensions de configuration, une tâche planifiée était utilisée pour corriger l'instruction du robot une fois toutes les 10 minutes.

Que sont les extensions de configuration ?

Le mécanisme suppose trois types d'utilisation, qui sont en fait indiqués dans le champ "Objectif" lors de la création d'une extension :

L'élément central de la technologie est Gestionnaire de services, il stocke toutes les informations sur les abonnés, les utilisateurs, les applications, les infobases et les connexions entre eux, avec son aide, le traitement externe et les extensions de configuration sont gérés.

Tous les fichiers avec traitement sont chargés dans un répertoire spécial du gestionnaire de services. Mais avant de télécharger un fichier dans un répertoire, c'est-à-dire de « le publier dans un service », il doit être préparé d'une manière spéciale.

Préparation de rapports externes et traitement pour publication dans le modèle de service

Le module objet doit avoir des procédures et des fonctions pour définir les paramètres d'enregistrement.

Veuillez noter que le paramètre important est "Version". Si vous apportez des modifications à un traitement déjà téléchargé dans le répertoire du gestionnaire de services, veillez à modifier le numéro de version, sinon le gestionnaire de services refusera de télécharger le fichier. Lors de l'élaboration d'un rapport ou d'un traitement, il faut tenir compte du fait que les utilisateurs travaillent dans le modèle de service via un client Web (un bon article sur le blog 1C). Si le traitement contient des formulaires, ils doivent fonctionner dans le client Web sous tous les navigateurs Web pris en charge par la plate-forme technologique 1C: Enterprise 8.

Selon les normes du service 1cfresh.com, un rapport ou un traitement supplémentaire doit être entièrement fonctionnel lorsqu'il est exécuté en mode sans échec, c'est-à-dire qu'il doit fonctionner sans accéder à des objets externes pour la configuration.

Un rapport ou un traitement supplémentaire doit être préparé pour être téléchargé sur le service en tant que kit de livraison. Le kit de livraison est une archive (fichier zip) contenant :

• rapport complémentaire ou dossier de traitement ;
• xml du manifeste, qui contient des méta-informations supplémentaires requises par le gestionnaire de service pour publier un rapport ou un processus supplémentaire dans le service.

Installation de rapports supplémentaires et traitement dans le modèle de service

Un abonné au service est un groupe d'utilisateurs unis selon un principe. Par conséquent, les infobases disponibles pour un certain groupe d'utilisateurs sont appelées applications d'abonné.

Les applications peuvent avoir différentes configurations 1C (Comptabilité d'entreprise, Gestion de la paie et du personnel, Gestion de notre entreprise, etc.), qui peuvent être utilisées dans le modèle de service. Un rapport ou un traitement supplémentaire ne peut être installé que dans les applications de l'abonné spécifié lors du téléchargement du fichier.

Voici à quoi ressemble le formulaire de propriétés du rapport supplémentaire avec les versions. Sur le lien hypertexte "Installer / Désinstaller", nous entrons dans la liste des applications et sélectionnons les bases de données nécessaires.

Une fois le traitement chargé et l'application sélectionnée, le gestionnaire de services appelle l'adresse de l'application et donne la commande pour l'installer dans l'infobase.

Nous commençons le traitement selon le calendrier

Le traitement qui sera programmé n'a pas de formulaire. Toute la logique est écrite dans le module objet et ressemble à ceci.

Lors de la préparation de l'ensemble de livraison, nous fixons le calendrier. Désormais, notre traitement sera effectué toutes les heures.

En savoir plus sur les extensions de configuration

Par exemple, nous avons écrit ci-dessus sur les opérations de routine pour corriger les documents des robots lancés toutes les 10 minutes. Vous pouvez maintenant utiliser l'extension pour redéfinir le fonctionnement des modules. Ainsi, nous pouvons immédiatement, lors de l'enregistrement ou de la publication d'un document, effectuer les actions nécessaires. C'est beaucoup plus optimal, car la file d'attente des travaux dans la base de données n'est pas encombrée d'actions toutes les 10 minutes, et plus rapide, puisque les modifications sont apportées immédiatement.

Préparer une nouvelle extension est assez simple. Regardons le processus de création d'extensions avec des exemples spécifiques.
Selon l'expérience professionnelle, le leader des demandes d'ajustements est le formulaire imprimé TORG-12. Par exemple, nous devons faire une extension pour pouvoir imprimer un bon de livraison dans une devise (par défaut, il ne peut être généré qu'en roubles).
Ouvrir le menu → Configuration → Extensions de configuration
Créez une nouvelle extension avec l'affectation "Adaptation".

L'extension ressemble à un arbre de configuration familier, mais sans objets pour le moment. Tout d'abord, ajoutons une nouvelle mise en page TORG-12, dans laquelle nous avons inséré des colonnes avec des montants en devise.

Étant donné que la lettre de voiture est imprimée à partir du document "Vente de biens et services", ajoutons ce document à notre extension à partir de la configuration principale et apportons les modifications nécessaires au module de gestion. Pour cela dans menu contextuel mise en œuvre, sélectionnez "ajouter à l'extension".

Vous pouvez maintenant modifier le module du gestionnaire d'implémentation. Nous devons ajouter un nouveau formulaire à la liste des imprimables et remplir les montants en devises.

Pour modifier les procédures typiques, nous utilisons l'annotation &After, nous avons également besoin de quelques-unes de nos fonctions et d'une procédure.

Examinons de plus près les annotations. Dans les extensions, vous pouvez utiliser : &Before, &After, &Instead (très prudemment). Le principe de fonctionnement est simple : on veut que nos algorithmes de l'extension soient exécutés en premier, mettre l'annotation &Before et indiquer entre parenthèses le nom de la procédure issue de la configuration type. Si le module typique fonctionne en premier, puis le nôtre, nous utilisons &After.

Les annotations &Before et &After ne peuvent pas être appliquées aux fonctions. Par conséquent, si nous devons modifier l'algorithme d'une fonction à partir de la configuration principale, nous utilisons le &Au lieu de l'annotation.

L'annotation &Instead doit être utilisée le moins possible, car elle remplace complètement l'exécution d'une procédure et d'une fonction de la configuration principale par une procédure/fonction d'extension. Avec cette méthode d'interception, la procédure / fonction de la configuration principale cessera généralement d'être exécutée pendant l'installation de l'extension, même la mise à jour des versions n'aidera pas.

Conclusion

Vous pouvez utiliser plusieurs extensions pour la même zone de données.
Pour les spécificités de 1C Fresh en mode partage de données (une configuration, plusieurs zones indépendantes), la méthode d'extension est une excellente porte de sortie.

Implémenté dans la version 8.3.9.1818.

En bref, maintenant, à l'aide d'extensions, vous pouvez modifier les modules de la configuration typique et ajouter vos propres modules.

Et plus en détail, vous pouvez modifier n'importe quel module, à l'exception des modules de formulaires ordinaires :

• Modules généraux ;
• Modules objets (module objet, module gestionnaire...) pour tous types d'objets ;
• module de session ;
• Module d'application géré ;
• Module de connexion externe ;
• Modules de commande ;
• Modules de formulaire ;
• etc.

Inutile de dire que vous avez peut-être modifié des modules de formulaires gérés par le passé, mais nous avons maintenant apporté quelques modifications au processus.

Interception
Vous pouvez intercepter n'importe laquelle des méthodes de configuration génériques, les encadrer par les vôtres ou même les remplacer entièrement.

Propres gestionnaires
Vous pouvez ajouter vos propres gestionnaires d'événements de configuration personnalisés. Si, par exemple, ils ne sont pas affectés dans une configuration typique.

Modules propres
Vous pouvez créer vos propres modules partagés dans l'extension.

Appeler
Et enfin, vous pouvez appeler n'importe quelle méthode de configuration de type dans votre extension.

Lorsque vous empruntez et étendez un module de configuration générique, votre module d'extension sera dans le même espace de noms que le module générique. Par conséquent, dans un module d'extension, vous pouvez accéder directement à toutes les variables et méthodes du module générique.

Si vous êtes dans un autre module qui existe dans une extension, alors vos propres variables et méthodes exportées du module d'extension seront à votre disposition. Parce qu'ils sont ajoutés au contexte public résultant du module générique.

Interception d'appel de méthode

La tâche d'intercepter les appels, dans la grande majorité des cas, est d'entourer l'appel d'une méthode générique de quelques pré- et/ou post-actions. Dans le même temps, nous n'avons pas exclu l'option de chevaucher complètement l'appel d'une méthode typique et avons implémenté une telle possibilité.

Vous décrivez complètement la nécessité d'intercepter telle ou telle méthode de type dans le module d'extension. Pour ce faire, nous avons introduit un nouvel élément structurel dans le langage intégré - l'annotation. Avec une annotation placée avant une définition de méthode, vous spécifiez quelle méthode de type la procédure/fonction intercepte, et de quelle manière. Par exemple:

L'annotation &Before("Procedure1") signifie que la procédure générique nommée Procedure1 est interceptée. Le nom de l'annotation Before signifie que votre procédure hook Extend_Proc1() sera exécutée en premier, puis la Procedure1() générique sera exécutée.

Annotation et recto

Une annotation portant ce nom signifie que votre intercepteur sera exécuté avant que la méthode générique ne commence à s'exécuter.

Dans le diagramme, les modules de type et d'extension sont représentés par des rectangles et la flèche montre la séquence d'exécution du langage intégré.

Annotation &Après

Cette annotation signifie que votre intercepteur sera exécuté après l'exécution de la méthode de type.

Annotation &Au lieu de cela

Cette annotation implémente simplement la possibilité d'un chevauchement complet d'une méthode typique. Autrement dit, la méthode générique ne sera pas exécutée du tout. Au lieu de cela, seul votre intercepteur sera exécuté.

Vous pouvez installer l'une des combinaisons d'intercepteurs suivantes dans votre extension pour le même exemple de procédure :

• &De face;
• &Après;
• &À la place de;
• &Avant et après.

La dernière combinaison d'intercepteurs (&Avant et &Après) sera exécutée comme suit :

Si vous interceptez une fonction générique et non une procédure, vous ne pouvez utiliser que le & au lieu de l'intercepteur.

Appel d'une méthode superposée avec &Au lieu d'une annotation

Il y a des injustices. Vous pouvez couvrir ou encadrer la procédure. Et la fonction - seulement bloquer complètement.

Pour se débarrasser de cette injustice, nous avons implémenté une nouvelle méthode dans le langage intégré - Continuer l'appel (). Si vous appelez cette méthode dans votre fonction d'intercepteur, la fonction que vous avez remplacée sera exécutée, après quoi l'exécution du code reviendra à votre intercepteur :

Dans le langage intégré, une telle fonction d'intercepteur pourrait ressembler à ceci :

Votre fonction d'intercepteur est donc divisée en deux parties. La partie exécutée avant l'exécution de la fonction de type et la partie exécutée après le type.

Vous pouvez utiliser la méthode ContinueCall() non seulement lors du chevauchement de fonctions, mais également lors du chevauchement de procédures. Dans ce cas, le résultat de son application aura le même sens que lors de l'utilisation d'une paire d'intercepteurs &Before et &After. La seule différence est que dans ce cas votre partie "avant" et votre partie "après" existeront dans le même contexte. Dans certaines situations, cela peut être pratique. Dans le 1er langage, une telle procédure d'intercepteur pourrait ressembler à ceci :

Quel est le meilleur, &Avant, &Après ou &Au lieu de ?

Lorsque vous remplacez les méthodes de configuration génériques, il est toujours bon de garder deux choses à l'esprit :

• Après avoir écrit votre extension, la configuration par défaut changera ;
• Votre objectif est d'ajouter votre fonctionnalité, et non d'abandonner définitivement ce qui est et ce qui sera dans la configuration typique.

De ce point de vue, l'utilisation des intercepteurs &Before et &After est la plus préférable. Parce qu'avec eux, la méthode de type interceptée sera toujours exécutée, sans aucune condition. Et si les développeurs de la configuration typique apportent ultérieurement des modifications à cette méthode, ces modifications fonctionneront certainement lors de l'utilisation de votre extension.

Il est également parfaitement acceptable d'utiliser la méthode &Au lieu de la méthode ContinueCall(). Cependant, ici, vous avez la possibilité et la tentation d'appeler la méthode générique pas toujours, mais en fonction de certaines de vos propres conditions. Cela doit être abordé avec prudence et rappelez-vous qu'au moment où vous refusez d'appeler une méthode générique, vous refusez d'appeler non seulement la méthode qui est dans la configuration maintenant, mais également toutes ses variantes qui apparaîtront dans le futur. Et à l'avenir, par exemple, des changements importants et utiles pourraient y apparaître.

Et, enfin, l'option la plus "mauvaise" est le chevauchement complet de la méthode typique avec l'intercepteur &Instead. Dans ce cas, le gestionnaire de type ne sera certainement pas exécuté ni maintenant ni dans les versions futures. Autrement dit, vous assumez l'entière responsabilité du travail des futures versions de la configuration, sur votre extension. Il existe certainement des situations où une telle couverture complète est nécessaire, mais nous vous invitons à aborder son utilisation avec beaucoup de prudence et de prudence.

Séquence d'appels lors de l'interception de méthodes

Ici, avant de raconter, il faut faire une petite explication. Une caractéristique importante, pourrait-on dire, « idéologique », des extensions est leur autonomie. Autrement dit, les extensions doivent être conçues de manière à ne pas dépendre les unes des autres.

Mais lorsque l'application est en cours d'exécution, naturellement et évidemment, il y a une certaine séquence d'appels d'extensions connectées. Cette séquence est connue et nous allons maintenant en parler. Mais nous n'allons pas vous en parler pour que vous créiez des extensions interdépendantes sur sa base, ou des extensions qui impliquent une seule séquence de connexion codée en dur. Et pour que vous puissiez analyser les problèmes qui surviennent et déboguer le code du programme.

Lorsque vous connectez des extensions à une configuration typique, un « secteur en couches » se forme. En bas de ce graphique se trouve la configuration par défaut et en haut se trouve la dernière extension branchée.

Aussi bien dans le configurateur qu'en mode 1C:Enterprise, le dernier poste connecté est le dernier de la liste.

Ainsi, dans cet exemple, Type est en bas, Extension2 est en haut et Extension1 est entre les deux. Chaque expansion suivante intercepte (étend) ce qui se trouve en dessous.

Lorsque la plate-forme rencontre des hooks définis dans des extensions, le processus d'intégration va de haut en bas de ce secteur, selon les annotations des hooks. Aussi loin qu'il peut aller. Après cela, il revient au sommet, s'il y a des intercepteurs, et revient à la configuration typique.

Exemple 1

Par exemple, si la même méthode de type est interceptée (encadrée) dans deux extensions, alors la séquence des gestionnaires d'appel sera la suivante :

• Le hook de Extension2 sera appelé en premier car il est au-dessus. Ce sera l'intercepteur &Before car il a cette annotation ;
• Le crochet de Extension1 sera alors appelé, car c'est le suivant dans le gâteau. Ce sera à nouveau &Avant, car il a une telle annotation ;
• Après cela, la méthode générique sera appelée car il n'y a plus d'intercepteurs pour empêcher son exécution ;
• Ensuite, dans l'ordre inverse du camembert, le hook &After de l'Extension1 et le hook &After de l'Extension2 seront appelés.

Dans cet exemple, la fonctionnalité suivante peut être bien comprise : si une exception non gérée se produit dans l'un des intercepteurs, alors toute la chaîne est interrompue et l'exception continue à se propager.

Exemple 2

Si la méthode ContinueCall() est utilisée dans les intercepteurs, alors le même principe de « tarte » s'applique.

• Le crochet de l'Extension3 sera appelé en premier car il est au-dessus. Ce sera un intercepteur &Au lieu de cela, car il a une telle annotation ;
• Lorsque vous essayez d'appeler une méthode générique, le « gâteau » restant sera analysé. Il sera analysé exactement de la même manière que décrit dans l'exemple précédent ;
• En conséquence, l'exécution du code reviendra à l'intercepteur &Au lieu de et, une fois terminé, à la configuration typique.

Exemple 3

Un point important à comprendre est le fait que lorsque vous surchargez en utilisant l'annotation &Instead, en fait, non seulement l'appel à la méthode principale est remplacé, mais aussi les intercepteurs ci-dessous dans le « secteur ».

Dans cet exemple, seul l'intercepteur &Au lieu de Extension2 sera exécuté. Parce qu'elle remplace la méthode générique, c'est-à-dire toute la "tarte" qui se trouve en dessous.

Exemple 4

Il s'agit en fait d'une variation sur le thème du deuxième exemple, mais lorsqu'il y a une extension sous l'extension du haut, elle « jette » également l'appel de la procédure standard vers le bas.

En fait, il visualise juste une fois de plus le fait que l'appel d'une méthode générique s'applique à l'ensemble du "tarte" sous l'extension. C'est pourquoi après avoir appelé l'intercepteur de l'Extension2, l'intercepteur de l'Extension1 sera appelé. Parce que dans la "tarte" restante, c'est lui qui remplace l'appel d'une méthode typique, que vous voulez "atteindre" Extension2.

Interception des gestionnaires d'événements et de leurs propres gestionnaires dans les modules d'objets, les gestionnaires, etc.

L'interception de toutes les méthodes dans ces modules se fait exactement comme décrit au début. Cependant, si la procédure hookée est un gestionnaire d'événements, il y a quelques particularités. Ces fonctionnalités sont dues au fait que dans ces modules, tous les gestionnaires d'événements ont des noms fixes.

Tout d'abord, le nom de l'événement est spécifié comme le nom de la méthode interceptée. Par exemple, BeforeWrite :

Deuxièmement, la présence d'un gestionnaire générique pour cet événement est facultative. S'il n'y a pas de gestionnaire de type, votre intercepteur sera appelé. Grâce à cette fonctionnalité, vous pouvez affecter vos propres gestionnaires aux événements qui ne sont pas traités dans une configuration typique.

Étant donné que les gestionnaires d'événements dans les modules d'objets ont des noms fixes et que la liste des annotations est connue, nous avons implémenté un petit "service" pour vous. Lorsque vous créez un gestionnaire dans l'extension, une boîte de dialogue s'ouvre dans laquelle vous pouvez sélectionner le type d'appel. Après cela, un stub d'une procédure d'intercepteur est créé dans le module.

Intercepter les gestionnaires d'événements et les gestionnaires personnalisés dans les modules de formulaire

L'interception de toutes les méthodes de ces modules est également effectuée de la même manière que celle décrite au début. Cependant, même ici, il existe des fonctionnalités associées à l'interception des gestionnaires d'événements. Ces fonctionnalités sont liées au fait que dans ces modules, tous les gestionnaires d'événements sont assignables et n'ont pas de noms fixes. Comme vous le savez probablement, pour que la plateforme comprenne comment gérer tel ou tel événement, dans le configurateur, dans le panneau des propriétés, il doit y avoir un lien d'une procédure spécifique à un événement spécifique.

C'est pour cette raison, et uniquement lors de l'interception de gestionnaires d'événements sur un formulaire, que vous devez utiliser la palette des propriétés au lieu des annotations. Bien que toutes les autres méthodes de module qui ne soient pas des gestionnaires d'événements, vous pouvez les intercepter à l'aide d'annotations.

En externe, l'écouteur d'événement dans le module de formulaire ressemble à ceci :

Autrement dit, l'annotation n'est pas utilisée et le type d'intercepteur est indiqué dans la palette des propriétés. Cela se fait tout simplement. Lorsque vous créez un gestionnaire dans l'extension en cliquant sur le bouton de la loupe, une boîte de dialogue s'ouvre. Il permet, en plus du contexte, de préciser le type d'intercepteur (Avant, Après ou A la place).

Après avoir créé un modèle de procédure, une icône indiquant le type d'interception apparaît à côté du nom de l'intercepteur dans la palette des propriétés.

Si vous remplacez le gestionnaire de type (au lieu de), alors ce sera juste un point.

Si vous créez un crochet Avant ou Après, ce sera un point à côté de la barre verticale. L'emplacement du point, avant ou après le tiret, indique le type d'intercepteur. Et en plus de cela, un deuxième champ (vide) à côté de cet événement apparaît dans la palette des propriétés. Avec lui, vous pouvez définir un intercepteur de paire, s'il est nécessaire d'encadrer un gestionnaire typique avec une paire Avant - Après.

Les crochets d'événement définis de cette manière fonctionneront même s'il n'y a pas de gestionnaire par défaut pour cet événement. C'est ainsi que vous pouvez affecter vos propres gestionnaires aux événements de formulaire qui ne sont pas gérés dans la configuration par défaut.

En parlant de modules de formulaire, une dernière petite remarque doit être faite. Nous avons légèrement modifié le comportement des modules qui étendent les modules de formulaire qui existaient auparavant. Afin qu'il corresponde au comportement des autres modules et assure la stabilité du code du programme.

Auparavant, tous les modules étendant le module de formulaire et le module de formulaire lui-même se trouvaient dans le même espace de noms. Ainsi, il était possible d'appeler depuis l'extension supérieure non seulement les méthodes de la configuration typique, mais également les méthodes des extensions situées en dessous. Maintenant, nous avons fermé cette "échappatoire", et les méthodes des extensions ci-dessous ne sont plus disponibles. Désormais, vous ne pouvez accéder qu'aux méthodes contenues dans le module de type que vous étendez.

Modules généraux

Dans l'extension, vous pouvez créer n'importe quel module partagé personnalisé. Il n'y a que deux restrictions :

• Il n'est pas nécessaire qu'ils soient des serveurs mondiaux ;
• Ils n'ont pas à être privilégiés.

Lorsque vous étendez un module de configuration générique commun, il existe également des restrictions similaires :

• Vous ne pouvez pas emprunter de modules de serveur global ;
• Le code de votre extension ne fonctionnera qu'en mode non privilégié (sauf autorisation contraire dans le profil de sécurité).

L'opération d'emprunt du module serveur global elle-même n'est pas interdite dans l'arborescence de configuration, mais vous obtiendrez une erreur lors de l'étape de mise à jour de la configuration de la base de données et la mise à jour ne sera pas effectuée.

Les méthodes serveur ne sont pas toujours étendues

Le fait que votre extension soit connectée avec succès à une configuration typique ne signifie pas que tous les crochets qui se trouvent dans votre extension seront appliqués et commenceront à s'exécuter. Il y a quelques fonctionnalités de sécurité ici.

Si la solution appliquée fonctionne dans version du fichier soit en version client-serveur sans profils de sécurité, puis lors de la connexion de votre extension :

• Dans le mode d'exécution normal du langage intégré, toutes les méthodes de la solution standard seront étendues, à la fois client et serveur ;
• En mode d'exécution sécurisé du langage 1C:Enterprise, seules les méthodes client et les gestionnaires de formulaire serveur seront étendus. L'extension ne sera pas appliquée à d'autres procédures/fonctions serveur.

Lorsque la solution appliquée fonctionne dans la version client-serveur et lors de la connexion de l'extension, un profil de sécurité spécifique est spécifié, ou l'infobase se voit attribuer les profils des mode sans échec, alors la partie "serveur" de l'extension sera appliquée comme spécifié dans le profil correspondant.

Le plus simple d'entre eux est la case à cocher pour développer tous les modules du groupe Accès complet autorisé. Il "d'un seul coup" permet l'expansion du contexte serveur.

Il existe également un paramétrage plus précis grâce aux champs Disponible pour les modules d'extension et Indisponible pour les modules d'extension. Nous supposons que vous les utiliserez de la manière suivante :

• Si vous n'avez pas autorisé l'accès complet aux extensions, dans le champ Modules disponibles pour l'extension, vous répertoriez les noms des modules pour lesquels l'extension de contexte de serveur est acceptable et non dangereuse ;
• Si vous avez autorisé l'accès complet aux extensions, dans le champ Modules indisponibles pour l'extension, vous répertoriez certains modules dans lesquels vous n'avez toujours pas besoin d'autoriser les extensions de contexte de serveur.

Le principal problème du travail avec les extensions est une évaluation biaisée du nombre d'améliorations à venir par les développeurs/implémenteurs. Partant du message "oui, nous n'avons que quelques boutons à modifier sur le formulaire", le travail avec les extensions commence. Le nombre d'améliorations augmente, les extensions continuent d'être utilisées sur la base du message "nous utilisons déjà des extensions, continuons à travers elles".

Ensuite, il est nécessaire d'ajouter de nouvelles entités à la base de données, d'élargir la structure des entités existantes. Ou changer le principe de fonctionnement de n'importe quel sous-système typique. Travailler avec des extensions devient de plus en plus difficile voire impossible. La configuration inclut la possibilité de changer et de commencer le raffinement "soft" ou "hard" de la configuration typique, selon les qualifications des développeurs.

C'est le moment auquel arrive le zoo des technologies. L'hétérogénéité déjà présente dans système d'entreprise, se frotte joyeusement les mains, réalisant qu'elle a gagné un si bon tremplin de clarté et de simplicité.

Bien sûr, à ce stade, vous pouvez vous débarrasser de l'un des animaux du zoo technologique et transférer correctement toutes les modifications apportées à la configuration. Après tout, vous devrez encore "soigner" deux animaux - à la fois des extensions et des améliorations dans la configuration la plus typique. Nettoyez après eux, nourrissez-les, réconciliez-vous en quelque sorte les uns avec les autres afin qu'ils ne cassent rien dans le processus de travail ensemble, ajoutez une ligne de plus à la liste des exigences pour les développeurs dans les postes vacants de Headhunter.

Eh bien, c'est comme ça qu'il faut faire. Mais l'hétérogénéité sait que les gens sont paresseux, ils ont peur de toucher à ce qui fonctionne d'une manière ou d'une autre, ils « n'ont toujours pas le temps », et les autorités ne sont pas en mesure d'évaluer la nécessité d'une refactorisation à ce stade, ce qui est essentiel pour abandonner une technologie inutile. . Les améliorations apportées aux modifications apportées par le biais d'extensions continuent d'être apportées par le biais d'extensions. Améliorations apportées à la configuration - continuent d'être apportées à la configuration. Le principal ennemi de l'architecture logicielle d'entreprise est fermement ancré dans le pied capturé.

En général, mieux vaut bien réfléchir avant de se lancer dans l'utilisation d'une technologie hautement spécialisée. S'il y a un risque que la structure des objets doive être modifiée ou que de nouveaux objets de base de données soient ajoutés, il est nécessaire de commencer le débogage souvent et sans problème, il y a des gens qui comprennent comment changer initialement la configuration sans problème pour les mises à jour ultérieures, alors il vaut mieux décider immédiatement de ne pas produire de zoo. Personne n'a enlevé les modules redéfinissables, la modification programmatique des formulaires et les abonnements aux événements. Si l'entreprise est petite et qu'il est important pour les employés que la configuration soit mise à jour avec un seul bouton maintenant et toujours à l'avenir, il n'y aura certainement pas de changements majeurs (vraiment sûr ?), Alors il n'y aura pas de zoo avec des extensions.

Et bien sûr pour les petits plugins, les extensions ont du bon. Il existe des exemples de bonne utilisation sur IP lorsque des extensions sont publiées au lieu d'un fichier cf avec une instruction de comparaison-combinaison. Mais il s'agit là encore d'un domaine spécifique, et pour une utilisation permanente pratique, mieux vaut transférer la fonctionnalité dans la configuration afin que le lancement en mode entreprise ne soit pas ralenti.

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
• La chose la plus importante - 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 Facile mise à jour automatique .

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 une extension préparée à base de travail 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 le résultat apparence formulaires s'il y a 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é.