1s debugging configuration extensions. Configuration extensions. Managed Form Module and Event Handlers in Configuration Extensions

Windows 10

The configuration extension mechanism is a special mechanism designed to refine an extensible configuration without changing this configuration (including without removing it from support).

When considering the configuration extension mechanism, the following terms will be used:

  • Expandable Configuration– the main configuration of the infobase for which the extension is applied or for which the extension is being developed.
  • Configuration extension– a set of configuration objects connected to the extensible configuration and containing a set of objects added to the extensible configuration. An extension can include both the extendable configuration objects and objects that are not present in the extended configuration.
  • own object– a self-contained configuration object that can be located both in an extensible configuration and in an extension (report, processing, or subsystem).
  • Borrowed object– own object added to the configuration extension.
  • Expandable object– own object, for which any parameters (properties, forms, etc.) have been changed in the borrowed object.
  • Extension object is a borrowed object that has been modified relative to the extendable object. Having only controlled properties in a borrowed object does not make the borrowed object an extender.
  • Result object is its own object plus the union of all extending objects (if there is more than one extension). If there are no extending objects for the own object, it becomes the resulting "unchanged". Those. in the configuration the user is working with, all objects are result objects, regardless of the presence and number of installed extensions.
  • Extending property– property of the borrowed object that changes the property of the same name of the extended object.
  • controlled property– property of the borrowed object, the value of which is checked when the extension is connected to the extended configuration. If, when connecting an extension (in 1C:Enterprise mode), the value of a controlled property in the extension does not match the value of the same property in the configuration being extended, the extension will not be connected.
  • Modifiable property– property of the borrowed object, the value of which in the resulting object will be obtained from the extension.

A property of a borrowed object cannot be controlled and modified at the same time.

The main purpose of the configuration extension is to refine the applied solution during implementation (or in the "cloud") to the needs of the client. At the same time, the finalized configuration does not need to be removed from support. As a result, it is easy to update a typical application solution that is under support, with the need to perform improvements. When developing an extension, you should understand some features of the functioning of the configuration extension. Thus, an extensible configuration can be changed at any time, for example, as a result of an update. At the same time, the extension developer cannot influence the possibility or impossibility of updating in any way. You should also consider the fact that more than one extension can function in the system and the author of each extension (generally) does not know how the other extension functions.

The extension is created in the configurator, stored in the infobase and can be saved to a file. There is no need to use the configurator to add (connect) an extension saved to a file to the application solution of a specific client. You can connect the extension using a special standard function (All functions - Standard - Manage configuration extensions). You can also connect the extension using the application solution toolkit, which uses the programming interface provided by the platform. Attaching an extension (either interactively or from a built-in language) is possible either in insecure mode or when the security profile under which the session is running allows access to the plug-in extension.

Expandable objects can be:

  • Managed forms;
  • Roles;
  • Subsystems;
  • Settings of the initial page (desktop) of the applied solution;
  • General modules;
  • Object modules for all types of objects;
  • Manager modules for all types of objects;
  • session module;
  • Managed application module;
  • External connection module;
  • command modules.

The following can be used as custom extension objects:

  • Subsystems;
  • Processing;
  • Reports;
  • Requisites, tabular parts and details of tabular parts in borrowed processing and reports;
  • Roles;
  • XDTO packages;
  • Web services;
  • HTTP services;
  • WS links;
  • General layouts;
  • General commands;
  • Shared modules (except global server and privileged shared modules);
  • Command groups;
  • General pictures;
  • Forms, layouts and commands of borrowed objects:
  • Exchange plans;
  • selection criteria;
  • Storage settings;
  • directories;
  • Documents;
  • Journals of documents;
  • Enumerations;
  • Reports;
  • processing;
  • Information registers;
  • Accumulation registers;
  • accounting registers;
  • Calculation registers;
  • Plans of types of characteristics;
  • Charts of accounts;
  • Plans for types of calculation;
  • Business processes;
  • tasks;
  • Tables of external data sources;
  • Cubes of external data sources;
  • Dimension tables of external data sources.

Among the controlled properties, it is worth highlighting:

  • The composition of the exchange plan;
  • Predefined elements for directories, charts of types of characteristics, charts of accounts and plans of types of calculations.

Working with extensions is not supported in the basic versions of application solutions.

The need for software customization, i.e. its changes to the needs of a particular user appeared, probably, simultaneously with the software itself. It's hard to write a program that will satisfy everyone, so it's a good idea to allow changes to be made without involving the program's producer. Especially when it comes to business applications, because. business processes even in the same areas can differ in different organizations.

Changing the source code

There are different customization strategies. If the application is supplied in source codes, then the most obvious approach is to rewrite the source code to suit your needs. And the most obvious problem in this case is the transition to a new version of the application, because. it entails merging the source codes of the client-side modified version and the new version from the vendor. And this can be a non-trivial task, especially if the client-side code is highly customized.

Plugins

A safer strategy in this regard is plugins. The source application provides the plugin with a fixed set of interfaces, as well as the ability to register itself with the application. When a new version of the application is released, plugins written for the previous version will continue to work in the new version (provided that the interfaces remain unchanged). The behavior of plugins in the new version may differ from the behavior in the previous version if the software vendor has changed the behavior of the application. The concept of plug-ins is used in a wide variety of software classes - office and business software, development environments (Visual Studio, Eclipse, ...), graphic and sound editors, etc.

Subscriptions

Another customization technology is the ability to subscribe to events in the application and execute custom code in a well-known or proprietary language during these events. Events can be of very different types - opening a window, loading an image (for a graphical editor), processing an order (for a business system).

One variation of this approach is to build the ability to execute custom scripts in languages ​​like Visual Basic for Application (VBA) into the main program. Custom code can, in particular, be executed in response to application events. The same VBA proved to be a very powerful and flexible customization tool; it is built into Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS, and other products.

Customizations in 1C solutions: the beginning

The 1C:Enterprise platform implements various customization strategies. Since 1C applied solutions are supplied in source codes, naturally, one of the most obvious scenarios is changing the source code.

Changing the source code of 1C applications

When a client changes the source code of a 1C solution to suit his needs, he must remember that the application provider is also not idle and releases new versions, adding functionality and fixing bugs. So that when installing a new version of the application, changes made to the needs of the client are not lost, you need to somehow merge (merge) the changed previous version of the application and the new version.

Naturally, we at 1C paid great attention to this task and developed a delivery and support mechanism that facilitates its solution. Before telling how it works, a couple of details about the internal structure of 1C solutions.

The source codes and metadata of the 1C application solution (configuration) are stored in the database, in the same one that contains the data of the application itself (postings, data of directories and documents, etc.), i.e. the program is stored along with the data. A database with a configuration (and application data) in 1C terminology is called an infobase (abbreviated as an infobase).

During the development process, the configuration provider determines which configuration objects (reference books, documents, etc.) the client can change and which cannot.

Setting up delivery on the supplier side

The client on its side, using this mechanism, can also determine the rules for supporting objects of the implemented configuration of the provider - for example, it can refuse support by the provider of a particular object if it takes responsibility for further modification of this object. Or, on the contrary, you can prohibit editing the object of "your" configuration (even if the supplier allows it) in order to insure against accidental changes.

Setting up client-side support

When a client starts to change something in a typical configuration, two configurations are created in the infobase:

  1. Original vendor configuration.
  2. The current configuration as modified on the client side.
And now the supplier releases a new version. It may be supplied as a complete application, or as a service pack with modified objects. When migrating to a new version, we have 3 configurations on the client side, on the basis of which the so-called three-way merging of configurations is carried out:
  1. The old configuration from the vendor.
  2. The current configuration of the client (the old configuration from the vendor plus changes made to it by the client).
  3. New configuration from vendor.
It is clear that in some cases, objects modified by the provider can be updated automatically:
  • Objects not modified by the client.
  • Simple changes to objects on the client side (for example, adding additional attributes to the object).
In the case when the object has been changed both on the client side and in the new version from the supplier, manual intervention is necessary. We have a powerful comparison and union mechanism not only for code modules, but also for models (metadata, forms, reports…), but even with this mechanism, combining configurations can be a non-trivial task.

External reports and processing

Another customization mechanism that is relatively safe from the point of view of switching to new versions is the mechanism of external reports and processing. As the name implies, both types of objects - external reports and external processing - are external to the application solution, are stored in separate files and loaded into the application solution at the time of execution. Thus, the transition process to the new version does not affect them at all. But if in the new version the details of an object were deleted or renamed, and the processing or report refers to them, the report or processing will not work on the new version without alteration.

External reports and processing are essentially plugins. They are well suited for "custom" reports and specific data operations (for example, for importing information from other systems), but, of course, they do not cover all customization scenarios. If the client needs to add specific code that should be executed when posting the document, external processing is indispensable here - you need to edit the source code of the document module.

Cloud Customizations

With the advent of 1cFresh cloud technology, the task of customization has reached a new level. The fact is that in the "cloud" users of the applied solution from different organizations can physically work with one infobase (i.e. with one instance of the application), but at the same time, thanks to the data sharing mechanism, they see only the data of their organization . Customization through changing the source code becomes unacceptable here - each organization needs its own customizations, and customizations of "neighbors" in the infobase are completely unnecessary.

In the "cloud" for customization, only the use of external reports and processing is applicable, but, as mentioned above, external reports and processing do not cover all the scenarios that users need.

Configuration Extensions

So, we had to come up with a customization mechanism that would satisfy the following requirements:
  1. Would make it easy to update a customized solution to a new version, avoiding the manual work of merging configurations.
  2. Allowed to enable customization under certain conditions (for example, if we work in the context of a particular organization).
  3. Reduced the likelihood of customization losing its functionality when switching to a new version of the original configuration.
  4. Had the ability to disable customization in case of problems to keep the application working.
Such a mechanism, in addition to being used in cloud solutions, would greatly facilitate life when switching to a new version on the implementation of standard configurations where customizations are needed.
We came up with such a mechanism and called it extensions . This mechanism, in a sense, combines two approaches to customization - the ideology of plugins and the subscription mechanism.

Extensions are a way to keep configuration changes separate from the configuration itself. The extension is, in fact, itself a separate configuration containing modified objects. It, like the configuration, is represented as a tree of objects. To work with the extension, the same methods of work are used as with the usual configuration:

If we want to use an object from the main configuration in the extension (for example, add a new form to an existing document in the main configuration), we first need to borrow the object into our extension using the “Add to extension” command. Immediately after adding an object to the extension, it is "empty" in the tree of extension objects - it has only those properties that are in the main configuration. You can also borrow an existing form from the main configuration and, for example, add a new button to it that performs some specific action. It is not yet possible to add new attributes to objects in extensions, but we are working on it.

Basic configuration and extension with borrowed document InvoiceIssued

The extension also has an analogue of event subscription - the ability to process events of objects of the extensible configuration, for example, record processing. You can specify exactly how our code will be called in the extension:

Before the standard procedure for writing a document, we can call our code, which, for example, will check whether the field of the employee responsible for the document is filled in, and if not, it will write the current user into this field:

&After("BeforeWrite") Procedure ExtendAndromeda_BeforeWrite(Cancel,WriteMode, PostMode) If (ThisObject.Owner = Catalogs.Users.NullReference()) Then ThisObject.Owner = ModuleUsers.GetCurrentUser(); EndIf; EndProcedure
In the new version of the configuration, the implementation of the document entry may change, but our code in the extension will still run before the standard document entry code and do its job.

At runtime, a typical configuration and extensions (there may be several) “add up”, resulting in a new, customized configuration, with which the end user works.

Order of execution of extensions

When developing extensions, keep in mind that the platform does not guarantee that extensions will run in the same order when adding multiple extensions to a configuration. We deliberately abandoned the explicit setting of the order of execution of extensions, because this, in our opinion, complicates the setup and ultimately introduces more problems than it solves.

If we add several extensions to the configuration, each of which has the processing of holding the same document with the “&After” directive, then all handlers will be executed, but the platform does not guarantee that the order of their execution will always be the same. This must be taken into account when developing extensions.

If there is a handler for the same event in several extensions with the "&Instead" directive, only one handler will be executed, and it is impossible to say in advance which one. This should be kept in mind and monitored so that no more than one extension to the configuration has a “&Instead” handler for the same object / event.

Form customization in extensions

We can borrow the form of an object from the configuration (for example, the form of a document) into our extension. At the same time, in the visual form editor in the extension, we will see the form the same as in the main configuration. And in the form code editor, the extension will be empty - all the code for the form is still contained only in the main configuration.

You can add a new button (or even several) to the form. If several extensions add their own buttons to the same form, all of them will be present on the final form during execution.

But it is not recommended to remove standard elements from the form - this can break the code existing in the original configuration (if it accesses the form elements). If there is such a need, it is better to make elements invisible through the “Visibility” property.

It should be taken into account that a 1C:Enterprise application is not just code in a programming language. Most of the application is described in the form of declarative models. Moreover, different types of models are used for different tasks (forms, reports, rights, ....). For each type of model, we select our own customization method in extensions, which provides the most convenient change for typical cases.

Benefits of extensions

Extensions are ideologically distinct from the delivery and support mechanism. In the mechanism of delivery and support, the developer edits the configuration of the supplier as he wants, as if he were just finalizing his configuration, and then (when updating) he figured out how to synchronize conflicting changes. In extensions, the developer immediately initially develops the extension in terms of the added functionality. The extension is stored by the system exactly as an add-on and the system takes care of the most secure update.

Ease of transition to a new version of the configuration

When a vendor releases a new version of the generic configuration, an automatic update is performed because the generic configuration's support mode has not changed - it remains at full vendor support. And when you launch an updated application solution, the platform will again automatically combine the changed standard configuration with the extension. And the client will continue to work with a standard solution modified to suit his needs.

Sometimes, however, after updating the version of the standard configuration, it may be necessary to adapt the extension to the new version, for example, if the objects or attributes of the objects involved in the extension are renamed in the new version. A little more about this below, in the "Early notification of errors" section.

Changes are separate

The first obvious advantage of extensions is that all customizations made for the client are separate from the typical configuration, and now there is no need to compare the changed configuration with the typical one in order to understand what exactly has been changed.

It has already been mentioned that in order to use an object from the main configuration in the extension, it must be borrowed into the extension from the main configuration. Thus, something like a reference to an object from the main configuration appears in the extension.

At the same time, there is a way to understand which borrowed objects in the configuration are really changed, and which ones are borrowed in read-only mode - for example, for use in reports. In the tree of extension objects there is a filter button "Changed and added in the extension", after pressing which only borrowed objects modified in this extension and new objects created in this extension remain in the tree.

Early error notification

Suppose we borrowed the Contracts directory from the main configuration into the extension to use it in the report. In the meantime, a new version of the standard configuration has been released, in which the Contracts directory has been renamed Contracts. Naturally, after the transition to the new version, our report in the extension will not work. If we used the old customization technology - an external report, then the error would occur only at the moment the report was executed. In the case of extensions, we have the opportunity to check the correctness of the extensions in design-time after updating the version of the typical configuration, and fix any problems before users start working.

This is especially true in implementations where many extensions are used in one infobase, and the configuration version is updated centrally (for example, in cloud implementations, where different organizations using the same configuration but working in different data areas can use different sets of extensions). The administrator can update the version of the typical configuration on a test base and check the correctness of all user extensions relative to the new version. In case of problems, it will report them to the owners of the extensions, and the transition of the working base to the new version of the typical configuration will be done only when all extensions are brought into line with the new version of the configuration.

What's next?

We consider the development of extensions to be one of the main directions in the development of customization tools in the 1C:Enterprise platform. The extensions, originally conceived to facilitate customization in the cloud service, were designed to facilitate customization situations in non-cloud implementations as well.

While in extensions, you can not customize everything you want. For example, it is not yet possible to create new application objects (directories, documents, etc.) and it is impossible to add new attributes to existing application objects. We are working on this (and on other features too), and in almost every new version of the 1C:Enterprise platform we add new features to extensions: Add tags

Turned out to be very relevant :)

Ok, let's make this weekend useful too.

So, today another topic of “applied operation 1C”:

Extension mechanism in platform 8.3.6

What are we talking about?

In platform 8.3.6, a new mechanism was implemented - extension mechanism that facilitates the adaptation of the application solution for a specific customer.

When using extensions configuration is finalized in a new entity– configuration extension:

  • The extension, in fact, is also a configuration, but with some restrictions
  • The prepared extension can be connected to the customer's working database in user mode
  • The most important - the finalized configuration does not need to be removed from support, i.e. it remains standard, unchanged
  • Updating the modified configuration can be performed automatically by the user

Thus, the customer as a result receives possibility of improvement configuration and at the same time simple automatic update.

So that you can deal with this in more detail, we publish a few more videos + PDF on extensions.

So let's go:

Assigning configuration extensions

The video covers the new configuration extensions mechanism introduced in the 8.3.6 platform. It is intended for refinement, adaptation of solutions during implementation. At the same time, the customer receives a simple automatic configuration update and the ability to make improvements.

Objects that can be modified in an extension

This video discusses the existing limitations of the extension mechanism. Currently, only a limited number of objects can be used in extensions.

Working with extensions in the configurator

This video covers the development of extensions in the configurator. The extension is a configuration, although somewhat limited. Working with the extension is also performed in the tree of metadata objects. The resulting extension can be saved to a file on disk.

Borrowing objects

This video looks at borrowing basic configuration objects into an extension. This is the main mechanism needed to carry out the development of the extension itself. It also talks about controlled properties, the value of which is checked when the extension is connected.

Creating Your Own Objects in the Configuration Extension

This video shows how you can create your own objects in the extension. The list of such objects is still limited - these are reports, processing and subsystems. The development of such objects in the extension is carried out by analogy with the main configuration.

Working with extensions in user mode

This video shows how to connect the prepared extension to the customer's working base. In this case, the connection can be made from the user mode without accessing the configurator.

Working with Managed Forms in Configuration Extensions

This video walks you through how to work with managed forms in the extension. It is noted that the original form is not automatically synchronized with the extension. Explains how the system generates the resulting appearance of the form in the presence of an extension.

Managed Form Module and Event Handlers in Configuration Extensions

This video walks you through how to work with event handlers in Managed Configuration Extension Forms.

The order of execution of event handlers in the main configuration and in the extension is demonstrated.

Having studied the experience of using previous versions of the program, and taking into account the fact that no matter how universal and comprehensive a particular solution is, in the end, in 90% of cases, it needs to be finalized for the end user. The developers of version 8 of the 1C program implemented several fundamentally new solutions to minimize the need to change standard configuration mechanisms:

  • Literally from the first versions of the program, the elements of many directories have the opportunity to create additional properties and categories using the corresponding plan of characteristic types and information register;
  • Additional printed forms and forms for filling in tabular parts, as well as additional reports and processing can now be called from the corresponding directory;
  • Processing of standard procedures of objects is carried out not by making changes to the module, but by subscribing to events;
  • And, finally, from platform version 8.3.6, configuration extensions appeared in 1C.

What are 1C configuration extensions, how to work with them, restrictions on use - this is the range of issues that we will try to reveal in our article.

A bit of theory

Prior to the advent of the extension mechanism, the process of updating generic configurations was largely dependent on whether the configuration was maintained or changed. In the latter case, the developer had to:

  1. Compare typical and existing metadata structure;
  2. In case of a significant difference between typical elements, follow the correct update;
  3. Make appropriate changes after the update.

All this greatly complicated the update process, increasing the development time and, often, deprived the organization of the opportunity to update typical modules of expensive software.

The extension mechanism allows you to modify many of its elements without removing the standard configuration from support. In fact, the developer, based on a typical solution, creates his own configuration, which is a shell for a typical solution. In this case, the process of updating the typical part occurs automatically, while when launched by the end user, the platform combines both solutions for the user.

Situations where extensions can be used

Like any other tool, the extension mechanism has a number of characteristics and limitations that determine the scope of their use:

  • Extensions can work with managed forms;
  • The mechanism supports changing and adding existing subsystems;
  • Before the release of platform 8.3.8, it was only possible to change existing roles in the extension, after the update they allowed adding new ones, restricting access even to the objects of the main database;
  • The existing mechanism allows you to change the command interface of subsystems and the main configuration section at will;
  • Also, this toolkit allows you to add processing and reports without making changes to the database structure;
  • In the platform version 8.3.9.718, the mechanism for diagnosing the compatibility of the extension and the main configuration has been significantly redesigned.

From the above, it becomes clear that:

  1. When working with regular forms, the functionality of extensions is significantly limited;
  2. Although the process of updating the main configuration has been facilitated, the possibility of using a specific extension (including as a circulation solution) can be seriously limited both by changes in the original structure and by several extensions used in parallel;
  3. It is advisable to use this mechanism in cases where there is a need to differentiate the appearance and functionality used by different users, or when a standard configuration that is under support is being finalized on its own.

Let's move on to practice. As an initial base, we will use the configuration "Salary and personnel management" version 3.1.3.223, the work will be carried out on the platform 8.3.10.2561, the work mode is file.

Create an extension

In the configurator, enter the menu Configuration->Configuration extensions, a form will open (Fig.1).

This is where you can create a new extension. Click the "Add" button. Here is the window of the new extension (Fig. 2)

Fig.2

Consider its elements:

  • Name - unlike other configuration elements, it is not created according to system standards, i.e. may start with a digit or symbol, may contain a space;
  • Synonym - just like for other metadata elements, it contains an expression-representation of an object;
  • Prefix - allows you to identify event handlers in the form module, since the main configuration form module and the extension form module are combined when the platform works in a common context (by default, the extension is processed first, that is, handlers with a prefix, then the main handlers);
  • Appointment.

The list of the "Destination" field consists of three values, we will describe them in the order of execution:

  1. Correction - extensions of this purpose are created to correct minor inaccuracies and errors in borrowed objects;
  2. Adaptation – the default value, extensions of this type are designed to adjust standard objects to the requirements of a particular user (if the extension was created in a version of the program below 8.3.9, after updating the platform it will have exactly this purpose);
  3. Addition - they bring a completely new functionality to the standard solution.

Launching an extension

Double click on the extension name in the window from Fig.1, opens the extension window (Fig.3)


As you can see, it is a tree similar to the main configuration tree. And here one question arises, in what cases should an object be borrowed?

It is necessary to borrow only those objects (dictionaries, documents, details, etc.) that will be used in the form extension, or in the code of its module, and without borrowing which an error may occur in the extension operation.

That is, if our development requires the "TIN" attribute of the "Individuals" directory, if it is used in the form module, we must borrow it from the main database. In this case, each time the extension is launched, a check will be made for the presence of this attribute in the main configuration reference book and for the correspondence of the data type in the source database and in the extension.

If after the update or during the development of new functionality there is an inconsistency between the extension and configuration data types or some other errors, the system will inform the user about this (Fig. 4)

The window in the lower right corner indicates a non-standard situation when connecting the extension, double-clicking on it opens detailed information. In this case, we simply changed the value type of the TIN attribute from the “String” value to the “Boolean” value for the borrowed object, but the reverse situation happens much more often - when updating a standard product leads to a change or elimination of the main database attribute.

Having worked out and tested the extension on a copy of the base, it can be uploaded to a separate file; for this, in the window (Fig. 5), you must click the "Configuration" button, select the "Save to file" item. Unlike regular configuration files that have the cf extension, the configuration add-on file will have a *.cfe mask.

As can be seen from the above figure, you can load new functionality from the same window, or from the main program window.

To connect the extension in 1C.Enterprise mode, the user must have the "All functions" mode enabled and the program must be logged in with Administrator rights.

The way to connect the refinement is as follows: All functions->Standard->Manage configuration extensions. The opening window is shown in Fig.6

Fig.6

Clicking on the "Add" button opens a file selection dialog in which you need to select our upload. If the processing is checked (Fig. 7) and the extension contains an error, the connection of the functionality will be canceled and the program will report an exception.

Fig.7

In order for our functionality to work after successful addition, the program must be restarted.

Borrowing objects and the order of firing modules

In order to trace the sequence of execution of the handlers, we will enable the ability to change our configuration and add a new processing to it, the functionality of which will consist of only one thing - it will report that it was launched from the main configuration, the code in Fig. 8.

Fig.8

Let's add this processing to the extension.

For this:

  • Right-click to activate the context menu of the processing form (Fig. 9);

Fig.9

  • Select the item "Add to extension";
  • The processing itself and a duplicate of its form will appear in the additional configuration tree;
  • Having opened the form, we find that the command that causes the message is also there, only it has not been assigned a handler;
  • Adding a command action brings up a dialog box (Fig. 10) in which, in addition to the main directives of the command execution site, there is also a Call Type group.

Fig.10

We have three types of call for the given procedure;

  • Call before – the execution of the extension code will be launched before the main configuration is completed;
  • Call after - the modified procedure will become the second number;
  • Call instead - the procedure from the main configuration will not be executed at all.

Let's leave the call type in the "Call after" position and add the procedure "Ext1_NotifyAfter(Command)" (Fig.11).

Fig.11

The result of starting our processing will be sequentially reported two phrases (Fig. 12), that is, an additional configuration message will be displayed after the main message. If we chose "Instead", we would not see the first line at all.

Fig.12

Starting from version 8.3.9.1818, the functionality of the program included a mechanism for changing standard modules, as well as adding custom modules. And here the developers faced a very specific task: how to determine in what order the borrowed procedures and functions should be executed not only in relation to the main configuration, but also in relation to the extensions already included in the configuration.

Annotation mechanism

Imagine a situation when several extensions are connected to one configuration, that is, the window for selecting them in the configurator looks like (Fig. 13)

Fig.13

When adding each new extension, the system independently builds the order of their execution.

The order of execution of additional modules is set based not only on the time the module was added (later added, later executed), but also based on the purpose of the revision (“Execution” will always come before “Adaptation”).

In addition, the sequence of execution of the procedures of the added modules can be controlled using annotations:

  • &Before("ProcedureName");
  • &After("ProcedureName");
  • &Instead("ProcedureName").

As you can see, their set is similar to what was demonstrated in the previous section, and the functionality is similar.

Since the borrowed module and the donor module are in the same namespace, no additional definitions for type variables and methods are needed in this case.

The situation with functions is somewhat different than with procedures. The fact is that the execution of a typical procedure can be, as it were, edged with an extension code, that is, you can insert some actions before the procedure code, some algorithms after, but for functions this will not work. If the main function is executed after the extension code, the return value of the replacing function will not be received, but if before the modified algorithm, the value of the main function will not be received and the &After annotation will work as &Instead.

To eliminate this "injustice", the ContinueCall() method was created.

Generally speaking, using the "Instead" annotation is a bit incorrect, although it is sometimes necessary. Using it, we largely limit the functionality that can be significantly changed and improved in standard configurations.

Making changes to the object module

The event subscription mechanism greatly facilitated the work of developers, but there was one serious BUT.

But to use it, you often had to create your own common module, which would store the procedures for processing certain actions with data. At present, the use of extensions has made it possible to largely revise this functionality.

Suppose, in the process of work, we needed to add some processing for the standard document “Employment” when writing it. Previously, we would go to subscriptions and act from there, now we can add this document to the extension:

  • Let's select "Hiring" in the configurator and add it to our extension from its context menu (by the way, this mechanism has a combination of hot keys Alt + Shift + F2);
  • After selecting the appropriate addition, we will get a picture, as in Fig.14;

Fig.14

  • We will be interested in the element “Object module” highlighted in yellow, open it by first activating the corresponding checkmark (Fig. 15);

Fig.15

  • We will get a blank sheet of the program module, pay attention to the top panel, or rather, to the element shown in Fig. 16, in the drop-down list there are events that can be processed for this object;

Fig.16

  • Let's try to display the document number in the message when it is written by selecting the appropriate event;
  • We will receive a call type selection form (Fig.17), determine when the number will be displayed;

Fig.17

  • The procedure code is shown in Fig.18;

Fig.18

In some cases, due to the checked "Safe Mode" checkbox, the extension connects with an error.

Small announcement

In the near future, 1C plans to release platform 8.3.11, in which they announced the possibility of adding their own:

  • Documents;
  • directories;
  • Exchange plans;
  • information registers.

It should also be possible to add details and tabular parts. At the same time, the developers took into account the possibility of changing standard solutions, which may lead to a failure in the operation of the extension.

The data entered into the extension will not be lost, and until the compatibility problem is resolved, the main configuration directory modified by the extension will not be available for writing.

In this article, I propose to consider what a "configuration extension" is, how to add an extension or disable it. Starting from version 1C On 8.3.6.1977 a new mechanism was introduced in the platform - configuration extensions. First, a little theory.

Extensions in 1C are something like parallel configurations that are automatically merged with the main vendor configuration. Moreover, in extensions, you can add both your own objects and borrow objects from the main configuration.

What are extensions for?

First of all, extensions are created to make it easier to make changes to the program. That is, if users ask to add some functionality, then before the advent of extensions, programmers had to remove the configuration from full support and change the typical configuration.

Removing from full support entails a number of inconveniences:

  • the possibility of automatic updating disappears, which leads at least to an increase in the time for ;
  • a highly qualified specialist serving the program is required;
  • if changes were made to standard objects of a typical configuration, then during the update they may disappear, that is, they can be replaced again with standard ones from the supplier.

When using extensions, when making changes, the programmer will not touch the standard configuration. All changes will be made using extensions, which (as I wrote above) are also configurations. Thus, the main configuration will remain at full support.

After updating the main configuration, if there are any changes in the new release with an object that was previously modified by the extension, then the changes will still be taken from the extension. That is, extensions take precedence over the main configuration.

Video - extensions in 1C in 45 minutes

Get 267 1C video lessons for free:

An example of adding an extension to 1C

To show what an extension is, it is better to give an example of its creation in the 1C configurator.

In the configurator, go to the "Configuration" menu and select the "Configuration extensions" item. A window will open with a list of extensions (if any). Click the "Add" button and add a new extension. Now you can open the extension configuration:

As you can see, the extension configuration has exactly the same structure as the main one. Only it is initially completely pure, without objects.

I recently wrote an article on how to make your own. Using her example, I want to make it inline using an extension.

In processing, I have a field with a link to the "Organizations" directory. That's why I need this guide. But we will not create a new Organizations directory, especially since the platform will not allow it. You cannot have objects in the extension configuration that have the same name as objects in the main configuration.

Therefore, we will borrow the directory from the main configuration:

Now we will right-click on "Processing" and select "Insert external processing, report ..." Thus, we will add a new processing to the extension configuration. If you use my processing, then immediately rename it, since the main configuration already has a processing with that name.

Well, the final touch. I want my processing to be reflected in the "Administration" menu. To do this, we will borrow the subsystem of the main configuration of the same name. Do not forget to indicate in the processing that it belongs to this subsystem.

This is the structure I got:

Let's see what we got. We update the database configuration and run the program in 1C: Enterprise mode, and go to the "Administration" menu. Yes, I almost forgot, the extension configuration must be closed, otherwise the program will not start:

Liked the article? Share with friends:
You may also be interested