A new release of the platform 8.3.11 has been released, which allows you to add and modify metadata objects through an extension. Can we really implement any improvements now without removing the configuration from support? Is it worth promising mountains of gold to a client without any consequences?
First of all, you need to be aware of the limitations that extensions have.
Restriction on created objects
Currently you can create:
- Reference books
- Documentation
- Information registers
- Exchange Plans
You can add details to:
- Reference books
- Documentation
What do we end up with? Not all types of metadata objects can be added. The most common and popular, but still not all. In addition, new dimensions and resources cannot be added to information registers. You can only create a completely new ledger.
The functionality of extensions depends on the compatibility mode of the configuration to which the extension is applied.
Compatibility mode 8.3.8- you can only change the forms of objects and their modules, add your own reports and processing.
Compatibility mode 8.3.10- you can change common modules, object and manager modules, roles, use "Before", "After", "Instead" directives for any modules.
Compatibility mode "Do not use"- you can use all the functionality of extensions, including adding new objects.
At the moment, typical UT 11.3 has compatibility mode 8.3.8. In UT 11.4 compatibility mode 8.3.10, that is, for example, for UT, most of the functionality of extensions is not available, including the creation of metadata objects.
It would seem that this begs the question: why not just unsupport the root, set the compatibility mode to "Do not use" and safely use the extensions? When you change the compatibility mode, the behavior of forms, query results, i.e. behavior of the system as a whole. We strongly recommend that you do not change the compatibility mode without first testing it. But it is obvious that it is possible to test completely (or at least in part of the documents used) an entire application solution. Therefore, this option should not be used.
When connecting an extension to a typical configuration, borrowing typical objects, the extension controls the compatibility mode of the main configuration and the types of borrowed objects and their details. If the controlled properties do not match, the extension is disabled and does not work until the cause is eliminated. That is, with a major update, there is a high probability that at least one of the controlled properties will change and the extension will lose its functionality.
In addition, if the improvements are significant, many procedures and functions of the standard configuration have been replaced, it will be necessary to carefully control them and, if necessary, bring them into line with the standard configuration, retaining the changes made earlier.
In the cases above, you still need the help of a programmer and, possibly, significant time for revision (but still less than when updating a configuration that has been removed from support).
conclusions
- The new release of the platform gave new opportunities for using extensions, it became possible to add metadata objects, but despite this, the functionality has certain limitations.
- The compatibility mode of the configuration to which the extension is applied severely limits the scope of the extension, and it is not recommended to change the compatibility mode.
- Large updates still require the attention of the developer, as there is a high probability of changes in controlled properties.
Hi all!
The wonderful configuration of 1C "BIT: Medical Center Management" up to release 2.0.28.3 in the logic of its work has a couple of annoying inaccuracies that do not allow you to thoroughly enjoy its use.
I give here two options for resolving these difficulties with the proviso that I personally prefer the one associated with changing the configuration - the old grandfather methods work as they should for the time being. And yes - this is my IMHO and it works.
Problem number 1. The prices for works are not put down in the document "Provision of services".
The violation in the logic of the program is as follows: the information register "Item Prices" has the dimension "Unit of Measurement", and the tabular section "Works" of the above document does not have any such suitable attribute so that when filling out the line of this tabular section, it can be easily and freely substituted inquiries for prices. Further, the function "GetPrice" of the general module "Pricing" contains the lines:
If ValueFilled(Unit) Then FilterStructure.Insert("Unit",Unit); Otherwise Selection Structure.Insert("Unit of Measurement",Catalogs.Units of Measurement.EmptyReference()); EndIf;
Here, in my opinion, an extremely wrong decision was applied: under normal conditions, empty references cannot appear in the "Unit of Measurement" dimension of the "Item Prices" register. Rather, there will be links to the elements of the "Units of Measurement" reference book from the details of the "Unit of Goods" of the corresponding nomenclatures. Let's use them instead:
If ValueFilled(Unit) Then FilterStructure.Insert("Unit",Unit); Otherwise If ValueType(Nomenclature) = Type("CatalogReference.Nomenclature") Then Selection Structure.Insert("Unit of Measurement",Nomenclature.Unit of Goods); EndIf; EndIf;
Solution options:
a) directly changing the configuration code;
b) creating an extension: we put the problematic function "instead of" the original one, change the code.
Problem number 2. External printables with use type "ClientMethodCall" do not quite work.
First, the external processing form must be named "Form1". Yes. Exactly.
Secondly, the module of the processing object must contain a function:
FunctionStartModeClient() Export Return True; EndFunctions
It also needs to be.
Thirdly, and what is most unpleasant, the configuration in the opening form does not pass a link to the document from which this form is opened ... And, as a result, the external printing form does not know what to print.
Solution options:
a) add lines:
after line
Form = GetForm("ExternalProcessing."+Res+".Form.Form1");
in the function "PrintExternalFormWithCheckModeClient" of the general module "PrintDocumentsClient"
b) move the whole thing into an extension.
Difficulties in using extensions.
At the moment we use the platform 8.3.10.2505.
The configuration in question has the "Version 8.3.6" compatibility mode. Not in vain, of course.
The main task is to borrow a certain function of a common module into an extension in "instead" mode and, changing a few lines there, ensure that the modified code is executed during the configuration process.
This is where the pitfalls begin:
- directive &Instead("GetPrice"), supported by the 8.3.10 platform, does not allow using compatibility mode;
- the "SetExecutionEventHandlers" method from the 8.3.6 platform causes a storm from the 8.3.10 platform like: "Redefining properties of borrowed objects in extensions is not allowed in compatibility mode 8.3.8 and below".
It looks like you need to set the configuration compatibility mode to "Do not use" in order to use extensions. However, this solution introduces a number of additional problems and "unsolvable" situations in our configuration. Basically, the methods begin to limp when and before closing the forms and the system itself. They are partially solved using the methods from the document Transferring configurations to the 1C:Enterprise 8.3 platform without compatibility mode with version 8.2, located on the 1C ITS website. Why partially - because not all server calls can be converted to client ones and not all can be abandoned. Details - in the attached extension "Shutdown".
There are three extensions in the list of files that solve problems with the external printing form, prices and errors when closing forms and applications in the 1C configuration: "BIT: Medical Center Management" release 2.0.28.3.
Implemented in version 8.3.6.1977.
We have implemented a fundamentally new mechanism for adapting applied solutions to a specific consumer - the extension mechanism.
Why are extensions good?
Extensions offer a different strategy than the existing one for changing typical configurations. Using this new strategy will greatly facilitate the maintenance of standard solutions that you want to adapt to the needs of a specific implementation, a specific customer.
What does this process look like now? There is a typical configuration. It is under full vendor support. This means that it cannot be changed. Periodically, the vendor releases new (improved) versions of this configuration. In such a situation, updating the old version of the configuration to the new version is performed completely automatically. It is convenient and does not require any special skills or knowledge from the customer.
But often the customer wants to add something or change something in a typical configuration “for himself”. To do this, the support mode is changed, the configuration is removed from full support. The implementation partner or the customer's own IT specialists make the necessary changes to it. From this point on, a fully automatic update of the typical configuration to the new version released by the supplier becomes impossible.
Now, updating the configuration requires the participation of a specialist. Moreover, if the changes made at the will of the customer were significant, then the specialist performing the configuration update may also require significant time. And often very good knowledge of both the typical configuration itself and the modifications made may be required.
The strategy offered by the extensions is as follows. If you want to change the typical configuration, you don't touch the configuration itself. All changes you make in the extension, which, in fact, is also a configuration.
In 1C:Enterprise mode, you simply connect your extension to the standard configuration. The platform automatically, in 1C:Enterprise mode, combines your extension with a typical configuration. As a result, the customer works with a modified, according to his wishes, standard solution.
When a vendor releases a new version of the common configuration, an automatic update is performed because the type configuration support mode has not changed. She remained at the full support of the supplier. And when you launch an updated application solution, the platform will again automatically merge the changed typical configuration with your extension. And the customer will continue to work with a modified, according to his wishes, standard solution.
When should you use extensions?
The extension mechanism is tempting due to its versatility. Therefore, it is important to have a correct idea of what tasks it is intended to solve.
Firstly, extensions are indispensable when the applied solution works in data sharing mode. For example, in the service model. One of the subscribers wants to have a couple of additional reports. While other subscribers want to work with an unchanged standard configuration.
Then it is for this subscriber that you can develop an extension in which to realize all his wishes. The subscriber will connect this extension to himself and will work with the changed configuration. While for other subscribers no changes will occur. Because all extensions are connected and launched in the context of the current separator values.
Another situation is the completion of a typical configuration for a specific customer at his implementation. Or improvements to the standard configuration, which are performed for themselves by the customer's IT specialists on their own. If all these improvements are made in the extension, then the typical configuration will remain fully supported, which will greatly simplify its further maintenance.
There is a temptation to use extensions to create replicated application solutions, but you should not do this. Firstly, because the extensions were not designed for such tasks. And secondly, because other platform mechanisms, such as delivery and support mechanisms, do not know anything about extensions.
If you look a little into the history of the emergence of extensions, then, of course, we have seen before, and we see now, that configurations are becoming more complex. We see that additional support is needed at different levels of development: library, modular and industry, etc. We analyzed all these tasks and came to the conclusion that the highest priority at the moment is the adaptation of configurations to the wishes of users during implementations.
It is for this task that we created the extension mechanism. Of course, in it you can notice different features of the other listed areas of development. But they are not its main purpose and should not confuse you.
What can be changed already now with the help of extensions?
So far, not much has been done of what is planned to be done. The mechanism, of course, will evolve. But what has already been done can be useful in many cases in implementations. Now:
- Can be changed managed forms, existing in a typical configuration;
- You can add new subsystems. You can change the composition of subsystems available in a typical configuration;
- Can be changed roles a typical configuration by adding objects created in the extension to them;
- Can be changed command interface typical configuration (main partition, subsystems);
- You can add new reports And processing.
In the future, we plan to gradually increase the functionality of the extensions and will be happy to get your opinion on which functionality is most in demand for implementations with minor modifications.
How is the extension structured?
The extension is very similar to the normal configuration. It is also represented as a tree of objects. To work with the extension, the same methods of work are used as with the usual configuration.
An important feature of the extension is the presence borrowed objects. You can borrow any object of a typical configuration using the context menu command:
Borrowed objects are not always needed. The best way to explain this is with a “household” example, if we draw an analogy with lunch in a restaurant.
The first situation is when borrowed objects are needed.
You are used to having lunch at the same restaurant. You always order steak and tea. For example, because they are very good in this restaurant. Or for some other reason. It doesn't matter. The only important thing is that you are going to eat them, and nothing else.
Then the restaurant is a typical information base. You are an extension. The restaurant menu is an extensible standard configuration. Beefsteak and tea are borrowed objects. You borrowed them (remember they are on the menu).
How does the extension connect to the configuration and work? You go to a restaurant and ask for a menu. On the menu you see that there is a steak and tea. That is, you establish a correspondence between borrowed objects and objects of a typical configuration. Naturally, you match by name :). They bring you a steak and tea, you eat them. That is, the extension is connected and working.
A week later you come, but the restaurant menu has changed (the standard configuration has been updated). However, the menu still includes steak and tea. They are exactly what you need. They bring them to you, you eat them. That is, the extension continues to work with the updated typical configuration.
A week later, you come to a restaurant and see that the steak and tea have disappeared from the menu. You get up and leave (extension connection error message). Because you wanted them. And you have no idea about other dishes (objects). The developer did not teach you how to eat snails or lobsters properly.
Another situation where you can do without borrowed objects.
You go to a restaurant, but you are not interested in the availability of specific dishes. Because you're not going to eat them anyway. You only want to photograph them. And you know how to photograph any dish. Then you just hook into the config and say bring whatever snacks you have on the menu (get the collection of documents from the metadata). I will send them (take pictures).
If you describe this in the dry language of developers, it turns out that you need to borrow objects:
- When they are needed for visual design. For example, you extend a form and add form props like ReferenceCurrency.Link. Then of course you should borrow a handbook Currencies, so that when connecting to a typical configuration, you can be sure that such a directory still exists in it.
- When they are needed for the code to work. For example, in the extension code, you refer to the reference attribute Nomenclature - Importer. Then this attribute must also be borrowed in order to be sure when connecting that in the typical configuration such an attribute still exists in the directory Nomenclature.
Connecting an extension
You create an extension in the configurator. After it is debugged and tested, you can reject it by saving the extension to a *.cfe file.
You can send this file to the customer. The customer will independently upload it to his infobase in 1C:Enterprise mode using the standard function Managing configuration extensions.
Working with extensions is available from the built-in language, so in the applied solution you can create your own processing that will load extensions. To prevent everyone from “playing around” with extensions, we added a new right - Administering configuration extensions.
When loading an extension from a file, it is stored in the infobase. Moreover, it is saved in the context of the current values of the separators used in this session.
For the extension to "work", the session must be restarted. At session start, just before the event is called SettingSessionParameters, all extensions stored in the infobase and corresponding to the current session delimiter values will be included.
As a result, when working in data sharing mode, the extension will be applied only to users of this particular subscriber. And if data separation is not used, then the extension will work for all users of the infobase.
When connecting an extension, as we have already said, it is controlled that there are borrowed objects in a typical configuration. Objects are matched by name.
In addition, finer control is also possible. You can control not only the very existence of objects, but also the state of their individual properties. That is, if you think about a restaurant and a steak, it may be important for you not just the presence of a somehow cooked steak, but precisely the fact that here it is cooked uncooked, “with blood”.
Returning to the extension, by default it does not control the properties of borrowed objects. But if you need to, you can make some properties controllable. For example, it is important for your algorithm that not only there is a directory Nomenclature, but also that its code is of type Line.
Then if in a typical configuration the supplier changes the code type of this directory to Number, your extension will detect this at connection time and report an error.
An interesting point is related to the renaming of typical configuration objects. For example, you came to a restaurant, and instead of the menu Steak written Steak. That is, when connecting to the configuration, the extension does not find a directory in it. Nomenclature, because the vendor renamed it to Goods.
Now this situation is not a problem for you. And you don't have to "shovel" all the extension code so that instead of Nomenclature write Goods. Works and. So you just need to change the name of the borrowed object to Goods, and the platform will make the rest of the changes in the extension itself. Or with your minimal help.
Expansion work
You can talk for a long time about the features of the extension of different objects, about the features of the work of the extensions themselves. But we are limited by the scope of the review article, so we will only touch on the key and most revealing points.
The main "charm" of extensions is, of course, not that you can add something to the typical configuration that is not in it. And the fact that in the extension you can change what is already in the typical configuration. That is, you can change the properties of borrowed objects.
The basic concept used when configuration and extension work together can be described as follows. In those places where they "do not intersect", the extension complements the configuration. In those places where they "intersect" - the extension is applied.
You can see this in more detail on the example of managed forms. You can borrow a form from the main configuration and edit it in the extension without restrictions. For the visual part of the form and for its module, two different merging strategies are used.
The visual part of the form is fixed in the extension at the moment it is borrowed. And in 1C:Enterprise mode, for each form element, 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 typical configuration, the value from the typical configuration is applied. Otherwise, the value from the extension is used.
Thus, if you 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 changed the title of an existing group, then you will see your title even if the vendor changes the title of this group in a typical configuration.
Form modules take a different approach. For a borrowed form, the extension creates its own module with its own handlers for all events. In 1C:Enterprise mode, both form modules (from the standard configuration and from the extension) are combined in one context. For this reason, each extension has its own prefix, which is added to the handlers of all events in the form module. So that there are no matches with handlers from the typical configuration. After that, event and command handlers are called sequentially and synchronously. First, the handler from the extension. Then from the typical configuration. You can change this sequence, or completely prohibit the execution of the handler from the typical configuration.
In general, with regard to the joint work of the configuration and extension in the 1C:Enterprise mode, they exist in a common namespace. This applies not only to individual modules, but also to the metadata trees themselves. Therefore, there is no way in 1C:Enterprise mode to determine whether this object is "native" for a typical configuration, or whether it came from an extension.
As for the rest of the objects that you can use in the extension, everything looks much simpler for them.
In the extension, you can create your own subsystems. Using borrowed objects, you can extend existing subsystems: add to them objects and subsystems that are already in the standard configuration, or those that you created in the extension. You cannot remove something from an existing subsystem.
You can only extend roles by adding objects created in the extension to them. You can't remove anything from an existing role either. The same applies to the command interface.
An extension is almost a configuration
We said at the beginning that an extension is similar to a regular configuration. Therefore, in conclusion, I would like to say a few words about how extensions are integrated with other platform mechanisms.
An extension (like a normal configuration) has a main configuration and a database configuration. The mechanism for comparing and merging configurations works with extensions in the same way as with regular configurations.
You can unload the extension to a file (however, with a different *.cfe extension), and load from a file. Extensions can be unloaded / loaded in XML.
Mechanisms of global search, replacement, editing interface texts also work with extensions.
There are new command line options for working with extensions, as well as new events in the log.
In the built-in language, the main object for working with extensions is Extension Manager Configuration.
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:
We have released a new release of the telephony panel for 1C.
- version 1.2.24.10 For ordinary applications
- version 1.4.26.17 For managed applications
In the release version for a managed application, it became possible to embed a telephony panel with minimal modifications basic configuration with expansion mechanism configuration.
Benefits of using the extension
The extension is very similar to the normal configuration. To work with it, the same methods of work are used as with the usual configuration. Extensions are created primarily to make it easier to make changes to the program. Now you don't have to insert "pieces of code" into certain modules and add new metadata objects, just add an extension to the configuration.
The great advantage of using extensions is automatic update main configuration. Now there is no need to change support settings for a typical configuration.
Features of embedding a telephony panel for 1C
Such features became available to extensions for the platform, starting from the version 8.3.9.1818 . Therefore, to take advantage of this, we disabled the compatibility mode for the extension, since the version 8.3.9 not yet supported. Accordingly, it becomes necessary to disable the compatibility mode for the main configuration, otherwise an error will occur: " The configuration extension compatibility mode is greater than the main configuration compatibility mode".
2) In the main configuration, we add the role MIKO_Softphone, for which we remove all rights.
When adding a new metadata object, in this case a role, it is necessary to update the directory Metadata Object Identifiers. When we added this role to the extension, the typical configurations ignored it, that is, when updating the MetadataObjectIdentifiers directory, the role did not appear in it. Because of this, the telephony panel settings profile mechanism did not work correctly, an error occurred: " Metadata object identifier not found for MIKO_Softphone role".
Moreover, this situation did not occur in all configurations, as in "Trade Management, 11.2.3.218" And "Integrated Automation, 2.0.3.222" there were no problems with the role when it was added to the extension itself. To provide some versatility in our solution and ensure smooth operation in most of the configurations we support, we decided to add the role MIKO_softphone into the main configuration and borrow it in the extension, and then implement the settings for this role in the extension.
A very important feature is the fact that if once you embed our extension, you want to embed the panel according to our old instructions, you must disable the extension and remove the MIKO_softphone role. If you want to use the extension again, you must first add the role, and then add the extension.
Summarizing
Even including the ability to change the main configuration and making minimal changes to the configuration, we have made the process of embedding a telephony panel much easier. Now you do not need to make changes to the modules of the managed application, add processing and subsystems to the configuration, or set up roles. The extension will do all this for you! We will continue to improve the process of embedding a telephony panel for 1C!
Instructions for embedding a telephony panel for 1C using the extension mechanism are located.
Ask your questions through the feedback form.
© 2019. MIKO LLC All Rights Reserved.
