Customization in 1C

About customization in general

The need for customization of software, i.e. its changes to the needs of a particular user appeared, probably, simultaneously with the software itself. It is difficult to write a program that will satisfy everyone, and therefore it is a good idea to lay in it the possibility of change without involving the program manufacturer. Especially when it comes to business applications, because business processes even in the same areas may differ in different organizations.

Change source code

There are different customization strategies. If the application comes in source code, then the most obvious approach is to rewrite the source code to fit your needs. And the most obvious problem in this case is the transition to a new version of the application, since it entails merging the source codes of the client-modified version and the new version from the supplier. This can be a nontrivial task, especially if the code on the client side is highly customizable.

Plugins

A safer strategy is plugins. The original 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, the plugins written for the previous version will continue to work in the new version (provided that the interfaces remain unchanged). The behavior of plug-ins in the new version may differ from the behavior of 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 (subscription) to events in the application and execute custom code in a well-known or proprietary language during these events. Events can be of various types - opening a window, loading an image (for a graphic editor), order processing (for a business system).

One of the variations of this approach is to embed 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 means of customization; It is built into Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS, and other products.

Customization in the solutions "1C": the beginning

The 1C: Enterprise platform implements different customization strategies. Since 1C application solutions are supplied in source codes, naturally, one of the most obvious scenarios is a change in the source code.

Change the source code of applications 1C

When a client changes the source code of a 1C solution to fit his needs, he needs to remember that the application provider is also not inactive and releases new versions, adding functionality and correcting errors. So that when installing the new version of the application, the changes made to the needs of the client are not lost, you need to somehow merge the modified previous version of the application and the new version.

Naturally, we in 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 device solutions "1C".

Source codes and metadata of the applied solution “1C” (configurations) are stored in the database, in the same one in which the data of the application itself (wiring, data of reference books and documents, etc.), i.e. the program is stored with the data. A database with a configuration (and application data) in the terminology of 1C is called an information database (abbreviated as infobase).

During the development process, the configuration provider determines which configuration objects (directories, documents, etc.) the client can change, and which not.



Setting up delivery on the supplier

The client, on his own side, using this mechanism, can also determine the rules for supporting objects of the embedded configuration of the supplier — for example, he can refuse the supplier’s support of a specific object if he takes responsibility for further modification of this object. And, on the contrary, it is possible to prohibit the editing of the object by its “own” configuration (even if the supplier allows it) in order to insure against accidental change.



Configuring client side support

When a client starts changing something in a typical configuration, two configurations are created in the info database:

1. Original supplier configuration.
2. The current configuration is changed on the client side.

And here the supplier releases a new version. It can be supplied as a complete application, or as a service pack with modified objects. When switching 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. Old configuration from supplier.
2. The current configuration of the client (the old configuration from the supplier plus the changes made in it by the client).
3. New configuration from the supplier.

It is clear that in some cases the objects changed by the supplier can be updated automatically:

• Objects not modified by the client.
• Simple changes to objects on the client (for example, adding additional details to the object).

In the case when the object was changed both on the client side and in the new version from the supplier, manual intervention is necessary. We have a powerful comparison and merging mechanism not only for code modules, but also for models (metadata, forms, reports ...), but even with this mechanism, the combination of configurations can be a non-trivial task.

External reports and processing

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

External reports and processing are essentially plugins. They are well suited for “custom” reports and specific operations on data (for example, to import information from other systems), but, of course, not all customization scenarios are covered. If the client needs to add a specific code that must be executed when the document is being carried out, external processing cannot be done here - the source code of the document module must be edited.

Cloud customization

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 an application solution from different organizations can physically work with one information base (i.e., with one application instance), but at the same time, thanks to the data separation mechanism, they see only the data of their organization . Customization through changing the source code here becomes unacceptable - each organization needs its own customization, and no customization of the “neighbors” on the infobase is necessary at all.

In the “cloud” for customization, only the use of external reports and processing is applicable, but, as mentioned above, external reports and processing cover far from all the scenarios that users need.

Configuration extensions

So, we needed to come up with a customization mechanism that would satisfy the following requirements:

1. It would allow to easily update the customized solution to the new version, avoiding the manual work of combining configurations.
2. Allowed to include customization under certain conditions (for example, if we work in the context of a certain organization).
3. Reduced the likelihood of loss of customization performance when upgrading to the new version of the original configuration.
4. Had the ability to disable customization in case of problems to preserve the health of the application.

Such a mechanism, besides being used in cloud solutions, would greatly simplify life when switching to a new version on implementations of typical configurations where customization is necessary.
We invented such a mechanism and named its extensions . In a sense, this mechanism combines two approaches to customization - the ideology of plug-ins and the subscription mechanism.

Extensions are a way to keep configuration changes separate from the configuration itself. The extension, in fact, is itself a separate configuration containing modified objects. It, like the configuration, is represented as a tree of objects. For 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 to our extension through the “Add to Extension” command. Immediately after adding an object to an 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 already existing form from the main configuration and, for example, add a new button to it that performs a specific action. It is not possible to add new details to the objects in the extensions, but we are working on it.



Basic configuration and extension with a borrowed document Invoice Invoiced

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



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

&("")  _(, , )  (. = ..())  . = .(); ;  

In the new version of the configuration, the implementation of the document record may change, but our code in the extension will still be executed before the standard document record code and do its work.

At runtime, the typical configuration and extensions (there may be several of them) are "added up", resulting in a new, customized configuration, with which the end user works.

Extension order

When developing extensions, it should be remembered that the platform does not guarantee the same order of extensions when adding several extensions to the configuration. We deliberately refused to explicitly specify the order in which the extensions are executed, since this, in our opinion, complicates tuning and ultimately introduces more problems than it solves.

If we have several extensions added to the configuration, each of which has processing processing of the same document with the “& After” directive, then all the handlers will be executed, but the platform does not guarantee that the order of their execution will always be the same. This must be considered 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 which one cannot be said in advance. This should be remembered and monitored, so that to the configuration of no more than one extension have an “& Instead” handler for the same object / event.

Customization of forms in extensions

We can borrow in our extension the shape of the object from the configuration (for example, the form of the document). In this case, in the visual form editor in the extension, we will see the form the same as in the main configuration. And in the code editor of the form in the extension will be empty - all the code for the form so far is contained only in the main configuration.

On the form, you can add a new button (or even several). In case 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 - it can break the code existing in the original configuration (if it refers to the elements of the form). If there is such a need, it is better to make the elements invisible through the “Visibility” property.

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

Advantages of extensions

Extensions have an ideological difference from the supply and support mechanism. In the delivery and support mechanism, the developer corrects the configuration of the supplier, as he wants, as if he is simply modifying his configuration, and then (when updating) he deals with how to synchronize conflicting changes. In extensions, the developer immediately initially develops the extension itself - in terms of the added functionality. The extension is stored by the system precisely as an add-on and the system takes care of the safest update.

Easy transition to the new version of the configuration

When a vendor releases a new version of a typical configuration, an automatic update is performed, since the mode of support for a typical configuration has not changed - it remained at the full support of the supplier. And when you launch the updated application solution, the platform will again automatically merge the modified sample configuration with the extension. And the client will continue to work with the typical solution that has been changed for his needs.

Sometimes, after updating the version of a typical configuration, it may be necessary to adapt the extension to a new version, for example, if the new version renames the objects or details of the objects involved in the extension. A little more about this below, in the "Early Error Reporting" section.

The 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 it is not necessary to compare the modified 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, in the extension appears something like a link to an object from the main configuration.

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

Early error reporting

Suppose we borrowed the Contracts directory extension from the main configuration for use in the report. In the meantime, a new version of the standard configuration was released, in which the Contracts directory was renamed to 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 of the report execution. In the case of extensions, we have the opportunity to check the correctness of extensions in the design-time after updating the version of a typical configuration, and fix all the problems before users start working.

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

What's next?

We consider the development of extensions to be one of the main directions for the development of customization tools in the 1C: Enterprise platform. Extensions, originally conceived to facilitate customization in the cloud service, were designed to facilitate both customization and non-cloud implementations.

While in extensions you can otkastomizirovat not everything that you want. For example, while it is impossible to create new application objects (directories, documents, etc.) and it is not possible to add new details 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 the extensions:

• Web and HTTP services in extensions (version 8.3.7).
• Add your own objects in extensions - common commands, layouts and pictures, as well as forms of borrowed application objects, their commands and layouts (version 8.3.8, link ).
• Development of the extension mechanism (adding roles in extensions - version 8.3.9).
• Expansion of modules (version 8.3.9).