We have brought about a brand new method of adapting applications for specific consumers: the extensions method.
What’s good about extensions?
Extensions offer a different strategy than the already existing one, which involves a change in standard configurations. The use of this new strategy will substantially facilitate the support of standard solutions adapted to the needs of a specific deployment, or a specific customer.
What is the structure of this process as of right now? Here’s a standard configuration. It is in full support of the vendor. This means it can’t be modified. From time to time, the vendor releases new (improved) versions of this configuration. In such a situation, updating the old configuration version to a new version is fully completed automatically. This is convenient and does not require any special skills or knowledge on the part of the customer.
But oftentimes the customer will want to add or change something in the standard configuration to "tailor it for themselves". To do so, the support mode will have to change and the configuration will no longer be fully supported. Our partner completing the deployment, or the customer’s own IT specialists, will make the necessary changes to it. After that, a full, automatic update of the standard configuration to a new version released by the vendor becomes impossible.
At this moment, updating the configuration will call for the involvement of a specialist. In addition, if the changes made based on the will of the customer were significant, then significant time expenditures may be required from the specialist completing the configuration update as well. And oftentimes, a very high level of knowledge may be required both for the standard configuration itself and for making corrections.
The strategy of using extensions is described in the following way. If you intend to change the standard configuration, do not touch the configuration itself. Complete all changes in the extension, which, essentially, is a configuration as well.
In 1C:Enterprise mode, you just connect your extension to the standard configuration. The platform automatically, in 1C:Enterprise mode, combines your extension with the standard configuration. As a result, the customer works with the standard solution modified according to their needs.
When the vendor releases a new version of the standard configuration, an automatic update is performed, as far as the standard configuration support mode has not changed. It has remained in full support of the vendor. And when the updated application launches, the platform automatically combines the modified standard configuration with your extension once again. And the customer continues operating with the standard solution modified according to their preferences.
When do you need to use the extensions?
The extensions method is enticing with all of its universality. For this reason, it is important to completely understand what kind of tasks it is designed to fulfill.
First of all, the extensions are irreplaceable when the application is operating in data separation mode—for instance, in SaaS mode. One of the subscribers wants to have a couple of additional reports. Meanwhile, the rest of the customers want to operate with the unchanged standard configuration.
In this case, you can develop an extension specifically for that customer, where you can bring all of their desires to fruition. The customer will attach this extension and work with the modified configuration. Meanwhile, for the rest of the customers, no changes will take place because all the extensions are attached and launched according to the current separator values.
Another situation is fine-tuning the standard configuration tailored for a specific customer for deployment at their location or, as well, fine-tuning the standard configuration performed by the customers’ IT specialists on their own for their own use. If all of this fine-tuning is performed in the extension, then the standard configuration will remain fully supported, which significantly facilitates its continued support.
You may be tempted to use the extensions for creating mass-produced applications; however, this is not a good idea. First of all, the extensions are not designed for tasks such as these and, second of all, other platform features, for instance, delivery and support functionality, don’t know anything about extensions.
If you take a glance back into history at the advent of extensions, then, without a doubt, we have seen and we see now that configurations are becoming ever more complex. We see that additional support is called for at various levels of development: library, module, industry support, and so on. We have analyzed all of these tasks and come to the conclusion that what is the highest priority at the current time is the adaptation of configurations to the customers’ needs during the deployment.
It is specifically for these tasks that we created the extension functionality. Of course, various characteristics and other listed development trends can be observed in it. But they are not its primary purpose and shouldn’t trip you up.
What can you change using extensions right now?
So far, not a lot of what’s planned to be done has been completed. The extensions, of course, will be developed further. But what has been already done may prove useful in many deployment cases. Right now you can:
- Modify the managed forms existing in a standard configuration
- Add new subsystems or change the contents of the subsystems within a standard configuration
- Modify standard configuration roles by adding objects created in an extension into them
- Modify the command interface of a standard configuration (of the main section, subsystems)
- Add new reports and data processors
How is the extension designed?
An extension is very similar to a regular configuration. It is also represented in the form of an object tree. To work with an extension, the same practices are used as for regular configurations.
A significant feature of an extension is that it contains adopted objects. Any standard configuration object can be adopted using a command in the context menu:
Adopted objects are not always necessary. It’s best explained using an "everyday" example, with the analogy of a restaurant dinner.
The first situation is when adopted objects are necessary.
You have gotten used to dining regularly in the same restaurant. You always order a steak and some tea when you go there. Let’s say that they’re really good at this particular restaurant—or for any other reason. It doesn’t matter. The only thing that matters is that this is what you be having, not anything else.
In this case, the restaurant is a standard infobase and you are an extension. The restaurant menu is the standard configuration. The steak and the tea, meanwhile, are adopted objects. You have adopted them (you have learned that they are on the menu).
How does the extension connect to the configuration and work? You come to the restaurant and ask for the menu. On the menu, you see that they have steak and tea there. In other words, you establish accordance between the adopted objected and standard configuration objects. Naturally, you establish accordance based on the names
. You are brought the steak and tea and you have them, which means that the extension is attached and works.In a week, you come back again, but this time the restaurant’s menu has changed (the standard configuration has been updated). However, they still have steak and tea on the menu and that’s exactly what you want. They bring them to you. You consume them. In other words, the extension continues to work with an updated standard configuration.
Then, another week later, you come to the restaurant once again, and you see that the steak and the tea have disappeared off of the menu. You get up and you leave (extension connection error message) because that was exactly what you wanted to have. And you have no idea about any other dishes (objects). The developer didn’t teach you how to eat snail and lobster correctly.
It’s a completely different situation when you can get by without any adopted objects.
You go to the restaurant, but you’re not interested in the specific dishes they have because you’re not going to eat any of it anyway. You’re only there to take pictures of it. And you have the ability to take pictures of any dish you want. In that case, you just connect to the configuration and say: bring all of the snacks you have on the menu (you receive a collection of documents from metadata). I’m going to repost (photograph) them.
Speaking in more mundane terms used by developers, you would say that objects need to be adopted:
- When they are necessary for a visual construction. For instance, you expand a form and add a form attribute like CatalogCurrencies.Ref. Then, of course, you will have to adopt the Currencies catalog in order to be sure that the attribute still exists in the catalog while attaching the extension to the standard configuration.
- When they are necessary for a script to work. For example, in an extension script, you call the Importer attribute of the Products catalog. Then, this attribute also needs to be adopted in order to be sure that such an attribute still exists in the Products catalog while attaching the extension.
You have created an extension in Designer. After it is debugged and tested, you can save the extension to the *.cfe file.
You can transmit this file to the customer. The customer will independently upload it to their infobase in the 1C:Enterprise mode using the standard function Manage configuration extensions.
Operating with extensions is available from 1C:Enterprise script, so in the application you will be able to create your own data processor that will load the extensions. In order to keep regular users from messing up with the extensions, we have added a new right: Configuration extension administration.
When you load an extension from a file, it is stored in the infobase. Note that it is stored in accordance with the current session separator values.
In order for the extension to "start working", the session will need to be restarted. When the session begins, all of the extensions stored in the infobase and matching the current separator values will be attached immediately before the SessionParametersSetting call event.
As a result, while operating in data separation mode, the extension will be applied only for users of that specific subscriber. And if the data separation isn’t used, then the extension will work for all of the infobase users.
When connecting the extensions, as we said, it is controlled that the adopted objects exist in the standard configuration. A comparison of the objects takes place based on their names.
In addition to that, more flexible control is possible as well. You can not only control the existence of the objects itself, but also the condition of their individual properties. In other words, if we look back on the analogy with the restaurant and the steak, it might not only be important to you that they have a cooked steak, but also that they can cook it rare, "with blood".
Heading back to the extension, normally it doesn’t control the properties of the adopted objects. But if there is a necessity for it, you can make certain properties controllable. For example, it is important for your algorithm that there not only exists a BankAccounts catalog but also that its code has a String type.
Then, if in the standard configuration the vendor changes the type of code of this catalog to Number, your extension will determine that during the attachment and return an error.
An interesting aspect relates to renaming standard configuration objects. For example, you come to the restaurant and on the menu instead of saying Steak it says Beef. In this case, while connecting to the configuration, the extension doesn’t find the Products catalog because the vendor renamed it to Goods.
Now that situation no longer poses a problem to you. And you don’t need to "heave over" the entire code of the extension in order to write Goods instead of Products. The algorithm that changes module code after renaming configuration objects and the refactoring algorithm do all the work. Thus, all you have to do is just change the name of the adopted object to Goods and the rest of the changes in the extension either will be made by the platform itself or with just a minimal effort on your part.
The operation of extensions
We can talk for quite a while about the features of various object extensions and about the features of how the extensions themselves operate. But we are limited by the bounds of an overview article and thus will only be able to touch on the key and most demonstrative aspects of it.
The main "attraction" of extensions isn’t, of course, that you can add something to the standard configuration that it doesn’t have in it. But rather, that you can change in an extension what standard configuration already has in it. In other words, you can change the properties of adopted objects.
The main concept used during the cooperation of a configuration and an extension can be described in the following way. In locations where they "don’t intersect", the extension complements the configuration. And in places where they do "intersect", the extension is applied.
You can see this in greater detail in the example of the managed forms. You can adopt a form from the main configuration and edit it in the extension without any limitations. Two different strategic combinations are used for the visual part of the form and its module.
The visual portion of the form is fixed in the extension during its adoption. In the 1C:Enterprise mode, the modifications for each form element are analyzed relative to this condition in the standard configuration as well as in the extension.
If there aren’t any changes or they are only in the standard configuration, the value from the standard configuration is applied. In all other cases, the value from the extension is applied.
Thus, if you’ve added a new command to the form in the extension, you will see it along with the rest of the form commands. And if you have changed the title of an existing group, you will see your title even if the vendor changes the group title in the standard configuration.
Another approach is used for form modules. For the adopted form in an extension, a new module is created with its own handlers of all the events. In 1C:Enterprise mode, both form modules (from the standard configuration and the extension) are combined in one context. For this reason, each extension has its own prefix that is added to the handlers of all the events in the form module in order to avoid overlapping of the handlers from the standard configuration. After that, the event and command handlers are called sequentially and synchronously: at first, the handler from the extension, then—from the standard configuration. You can change this sequence or you can totally prohibit the execution of a handler from the standard configuration.
In fact, as far as the cooperation of the configuration and extension in the 1C:Enterprise mode are concerned, they exist in a single namespace. This concerns not only separate modules but also the metadata trees themselves. So there is no possibility of determining in 1C:Enterprise mode whether this object is "native" for the standard configuration or if it arose from the extension.
For the rest of the objects that you can use in the extension, everything looks much simpler.
In the extension, you can create your own subsystems. By using the adopted objects, you can expand the existing subsystems: add objects and subsystems that already exist in the standard configuration or those that you have created in the extension. You cannot delete something from an existing subsystem.
You can expand the roles only by adding objects created in the extension. You cannot delete anything from the existing role. This also applies to the command interface.
An extension is almost a configuration
We said in the beginning that an extension is similar to an ordinary configuration. For this reason, in conclusion, I would like to say a few words about how integrated extensions are with the other platform features.
An extension (just as a regular configuration) has a main configuration and a database configuration. The configuration comparison and merging work with extensions in the same way as with regular configurations.
You can export an extension to a file (of course, with a different *.cfe extension) and load it from the file. Extensions can be exported to/imported from XML files.
Global interface text search, replacement, and editing methods also work with extensions.
New command-line options have come about for working with extensions as well as events in the event log.
In the 1C:Enteprise script, the primary object for working with extensions is ConfigurationExtensionsManager.
