We have implemented a completely new mechanism to adopt solutions for specific customer – mechanism of extensions.

Why extensions are good?

The extensions provide new strategy to change standard configurations. The use of this new strategy will significantly facilitate maintenance of standard solutions which you want to adopt for the needs of specific deployment, specific customer.

How this process looks like now? There is a standard configuration. It is completely maintained by vendor. It means that you cannot change it. A vendor releases periodically the new (advanced) versions of this configuration. In this situation the update of old configuration version to a new version is performed completely automatically. It is convenient and does not require from the customer any special skills and knowledge.

But the customer often wants to add something or change something in the standard configuration «as he sees fit». For this, a maintenance mode is changed, configuration is moved from the complete support. The partner who performs a deployment or the customer IT specialists make in it all the necessary changes. From this time, a complete automatic update of standard configuration to a new version released by vendor becomes impossible.
Now to update configuration, you need a developer. Moreover, if the changes made by the will of the customer were significant, then a specialist who performs the configuration update may require considerable time. And he may often need a well knowledge of both standard configuration and implemented modifications.

The strategy provided by the extensions is as follows. If you want to change a standard configuration, you do not touch the configuration by itself. All the changes you make in the extension which is, in fact, also a configuration.

In the 1С:Enterprise mode you simply connect your extension to the standard configuration. The platform automatically combines in the 1С:Enterprise mode your extension with standard configuration. As a result, the customer operates with the standard configuration changed according to his wishes.

When the vendor releases a new version of standard configuration, an automatic update is performed since the mode of standard configuration support was not changed. It remained to be completely supported by the vendor. And when launching the updated applications solution, the platform will automatically combine the changed standard configuration with your extension again. And the customer will continue to work with the standard solution changed according to his wishes.

When extensions should be used?

The mechanism of extensions is tempting for its versatility. Therefore, it is important to understand which problems it is designed to solve.

Firstly, the extensions are indispensable when the application solution operates in the mode of data separation. For example, in the service model. One of the consumers wants to have a couple of additional reports. While the other consumers want to work with unchanged standard configuration.

Then it is for this consumer, you can develop an extension in which you can implement all his wishes. The consumer will connect this extension and will work with the changed configuration. While no changes will be made for other consumers. Because all the extensions are connected and launched in the section of the current values of the delimiters.

Another situation is modification of standard configuration for specific customer during his deployment. Or modifications of standard configuration that perform the customer IT specialists themselves. If all these modifications will be made in the extension, then the standard configuration will remain in complete support that will significantly facilitate its further maintenance.

There is a temptation to use the extensions for production of replicated application solutions, however, you should not do it. Firstly, because the extensions were not designed for these tasks. And secondly, because the other platform mechanisms, for example, the mechanisms of distribution and support know nothing about extensions.

If to go deeper in the history of the emergence of extensions, surely, we have seen before, we see right now that the configurations become for difficult. We see that an additional support is required on the different development levels: library, module, industry, etc. We had been analyzed all these tasks and came to the conclusion that the priority at this time is an adoption of configurations to the customer wishes during the deployments.

It is for this task, we have created a mechanism of extensions. Of course, you can see in it the different features from other listed development directions. But they are not the main purpose and should not confuse you.

What can be changed using the extensions right now?

It is done not a lot as yet of what we are planning to do. Of course, a mechanism will be developed. But everything what has been done may be useful in many cases of deployments. Now:

• You can change the manageable forms existing in the standard configuration;
• You can add new subsystems. You can change a composition of subsystems existing in the standard configuration;
• You can change the roles of standard configuration by adding to them the objects created in the extension;
• You can change the command interface of standard configuration (main section, subsystems);
• You can add new reports and data processors.

In the future, we are planning to increase gradually the functionality of extensions and will be glad to get your opinion on what functionality is the most needed with light modifications.

How is the extension organized?

The extensions is very similar to the usual configuration. It is also represented as an object tree. To work with extension, the same methods of operation are used as with a usual configuration.

An important feature of extension is a presence of imported objects. You can import any object of standard configuration using a context menu command:

The imported objects are not always needed. It is better to explain everything on the «household» example if to draw an analogy with a dinner at the restaurant.

The first situation when you need the imported objects.

You used to have a dinner at the same restaurant. You always order a steak and tea. For example, because they are very good at this restaurant. Or for any other reason. It does not matter. It is only important what you a going to eat only them and nothing more.

Then the restaurant is a standard information base. You are an extension. The restaurant menu is a extensible standard configuration. Steak and tea are the imported objects. You have imported them (remembered that they are in the menu).

How is an extension connected to the configuration and work? You go to a restaurant and ask for the menu. You see in the menu that there are steak and tea. That is, you set a correspondence between the imported objects and the standard configuration objects. Of course, you set a correspondence by the names :). The waiter brings for you steak and tea and you eat them. That is, an extension is connected and works.

A week later, you come, but the restaurant menu has changed (The standard configuration has been updated). However, there are still steak and tea in the menu. You need just them. The waiter brings them for you and you eat them. That is, the extension continues to work with updated standard configuration.

One more week later, you go to the restaurant and see that steak and tea have disappeared from the menu. You stand up and go away (a message on extension connection error). Because you wanted to eat just them. And you know nothing about other dishes (objects). The developer did not teach you how to eat properly snails and lobsters.

Another situation when you can do without the imported objects.

You go t he restaurant, but you are not interested in the presence of specific dishes. Because you are not going to eat them in any case. You just want to take a picture of them. And you can take a picture of any dish. Then you simply connect to the configuration and say: bring me all the snacks you nave in the menu (receive a collection of documents from metadata). I will re-conduct them (take a picture).

If to describe all of this with a barren style of developers, it will turn out that the objects should be imported:

• When they are required for visual construction. For example, you extend a form and add the form attribute with a type CatalogCustomers.Reference. Then, of course, you must import the catalog Customers to be sure on connection to the standard configuration that this catalog is still presented in it.
• When they are required for code execution. For example, you addressed in the extension code to the catalog attribute Items - Vendor. Then this attribute must be also imported to be sure on connection that this attribute is still presented in the catalog Items of standard configuration.

Extension connection

You create an extension in the Designer. Once it is debugged and tested, you can detach it by saving extension in the file *.cfe.

You can give this file to the customer. The customer will load it himself in his information base in the 1С:Enterprise mode using the standard function Configuration extension manager.

You can work with extensions from the script, so you can create in the application solution your own data processor which will load the extensions. In order that the extensions were not «amused» by one and all, we have added a new right - Configuration extension administration.

When an extension is loaded from file, it is saved in the information base. Moreover, it is saved in the section of current values of delimiters used in the current session.

In order that extension began to «work», a session must be restarted. At the start of the session, immediately before calling an event SessionParametersSetting, all the extensions will be connected which are stored in the information base and correspond to the current values of this session delimiters.

As a result, while working in the data separation mode, the extension will be used only for the users of this specific consumer. And if data separation is not used, the extension will operate for all the users of information base.

When the extension is connected, as we already said, the presence of imported objects in the standard configuration is controlled. Comparison of the objects is performed by the names.

An addition, more thin control is available. You can control not only the fact of object presence, but also the state of their individual properties. That is, if you remember the restaurant and steak, it can be important for you not only the presence of somehow cooked steak, but just the fact that it is cooked here «rare».

Returning to extension, it does not control by default the properties of imported objects. But if necessary, you can make some properties controllable. For example, it is important for your algorithm that there was not only a catalog Employee, but also the fact that its code has a type String.

Then if the vendor will change in the standard configuration a type of this catalog to the Number, you extension will determine that during connection and will produce an error.

An interesting point is associated with renaming of standard configuration objects. For example, you came to the restaurant, and in the menu it is written Steak instead of Beesteak. That is, while connecting to the configuration, the extension does not find in it the catalog Employee, because the vendor has renamed it to the Users.

Now this situation is not a problem for you. And you do not need «sift through» the entire extension code in order to write Users instead of Employee. The mechanism of module code modification when renaming configuration objects and the refactor mechanism are working. Therefore, it is enough for you to change only the name of imported object to the Users and all the rest changes in the extension the platform will make itself. Of with your minimal help.

Extension operation

We can tell quite a lot of time about the features of extensions for different objects, about the features of extension operation. But we are limited to the review article, therefore, we will discuss only the key and most revealing moments.

The main «charm» of extensions is, of course, not in the fact that it is possible to add to the standard configuration something it does not have. But in the fact that you can change in the extension something that is already presented in the standard configuration. That is, you can change the properties of imported objects.

The basic concept used in the joint operation of configuration and extension can be described as follows. The extension complements the configuration in those places where they «do not cross». In those places where they «cross» the extension is used.

You can see that in more details in the example of manageable forms. You can import the form from the standard configuration and edit it in the extension without limitations. For the visual part of the form and for its module two different combination strategies are used.

A visual part of the form is set in the extension at the moment of its import. And in the 1С:Enterprise mode for each form item the changes are analyzed relative to this state in the standard configuration and in the extension.

If there were no changes or they were only in the standard configuration, the value from the standard configuration is applied. In other cases, the value from extension is applied.

Thus, if you have added in the extension a new command for the form – you will see it together with other form commands. And if you have change the header of existing group, then you will see your header even if the header of this group in the standard configuration will be changed by the vendor.

Another approach is used for the form modules. For the imported form in the extension its own module is created with its own handlers of all events. In the 1С:Enterprise mode both form modules (from standard configuration and from extension) are combined in a single context. For this reason, each extension has its own prefix which is added to the handlers of all events in the form module. In order to avoid any coincidence with the handlers from standard configuration. After that, the handlers of events and commands are called successively and synchronously. The first is a handler from the extension. Then from the standard configuration. You can change this sequence or completely disable an execution of the handler from standard configuration.

In general, with regard to the joint work of configuration and extension in the 1С:Enterprise mode, they exist in the common namespace. This applies to not only the individual modules, but the metadata trees too. Therefore, it is impossible in the 1С:Enterprise mode to determine whether this object is a «native» for the standard configuration or it has appeared from the extension.

In regard to the other objects that you can use in the extension, everything looks much easier for them.

You can create in the extension your own subsystems. Using the imported objects, you can expand the existing subsystems: add the objects and subsystems to them that already exist in the standard configuration or those that you have created in the extension. You cannot remove something from the existing subsystem.

You can expand the roles only by adding to them the objects created in the extension. You also cannot remove something from the existing role. The same applies to the command interface.

Extension is almost configuration

We said at the beginning that the extension is similar to the usual configuration. Therefore, in conclusion we want to say several word about how strong the extensions are integrated with the other platform mechanisms.

The extension (like a usual configuration) has the basic configuration and the database configuration. The mechanism of comparison and merging of configurations works with extensions like with usual configurations.

You can upload the extension in file (albeit with another extension *.cfe) and load from file. The extensions can be uploaded / loaded in XML.

The mechanisms of interface text global search, replace and editing also work with extensions.

New parameters of command line have appeared to work with extensions, as well as new events in the event log.

The main script object to work with extensions is ConfigurationExtensionsManager.