Overview

The demand for software customization (modification for specific user needs) is as old as the first invented software. It is virtually impossible to write an application that suits the specific needs of all users. Thus, adding the option to customize an application without developer assistance is an idea whose time has come. And it shines in business applications because business processes can significantly differ even in enterprises that belong within the same field of business.

Customization of source code

There are several customization strategies. If an application is delivered with its source code, the most obvious solution is editing the code. However, this can significantly impact future updates because merging the altered application with its new version obtained from a vendor can often be difficult, especially if the application is heavily customized.

Plug-ins

Plug-ins provide a safer strategy. An application provides a fixed set of interfaces to plug-ins and you can register plug-ins within the application. As long as the interfaces do not change, plug-ins developed for earlier application versions can work in conjunction with the later ones. However, changes implemented in new application versions might affect the plug-in behavior. Plug-ins are widely used in many software variations: office and business software, development environments (such as Visual Studio or Eclipse), graphics and audio editor applications, and so forth.

Event subscriptions

Another customization strategy is based on event subscriptions. Every time a specific event occurs in an application, various code written in a widely used or proprietary programming language is executed. Events come in a variety of types, for example: opening a window, opening an image (for graphical editors), processing an order (for business applications).

Subscriptions can be implemented as an option to add custom scripts, such as Visual Basic for Application (VBA) scripts. In particular, the script execution can be tied to application events. VBA is a robust and flexible customization tool, it is used in Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS, and other products.

Customizations in 1C:Enterprise solutions: the basics

1C:Enterprise supports multiple customization strategies. Since 1C:Enterprise applications are delivered with their source code, customization of source code comes first.

Customization of source code in 1C:Enterprise applications

When a customer changes the source code, they should remember that the vendor also changes that code and releases new application versions with new features and bugfixes. To keep their changes, the customer must merge the application that they modified with the new release.

Our team focused a great amount of attention on this problem and created the delivery and support tool that helps you to merge the changes. Before we highlight the details, let me briefly explain 1C:Enterprise application architecture.

1C:Enterprise applications (configurations) store their source code and metadata in the database, and this database also stores the application data (document posting records, catalogs, documents, etc.). In other words, the code and the data are stored in the same place. A database that stores the application configuration and the application data is called an information base (infobase).

At the development stage the configuration vendor decides which configuration objects (catalogs, documents, and so forth) can be changed by customers.

Customization options specified by vendor

Customers can use this tool to override the customization options defined by vendor. For example, they can fully disable vendor support for an object if they want to maintain it themselves from now on. They also have the option to prohibit editing an object even if the vendor allows its customization in order to prevent accidental changes.

Customization options specified by customer

When a customer changes something in a standard configuration, two configurations are created in the infobase:

1. Original vendor configuration
2. Current configuration with customer customization

Then a vendor releases a new application version. It can be delivered as a full distribution kit or a package that only includes the changed objects. This adds a third configuration and the customer faces the merging of all three:

1. Original vendor configuration
2. Current customer configuration (the original vendor configuration with customer customizations)
3. New vendor configuration

It is clear that some of the objects changed by the vendor can be updated automatically. They include:

• Objects not changed by customer
• Objects with simple changes made by customer (for example, with new attributes added)

However, objects that are changed both by vendor and customer require manual merging. The 1C:Enterprise platform provides a powerful tool for merging not only 1C:Enterprise script modules but also object data (metadata, forms, reports, etc.). Still, even with the help of this tool, merging can be tricky.

External reports and data processors

External reports and external data processors provide another customization option, which turns out to be relatively safe in scenarios with application updates. As their names imply, both of these object types (external reports and external data processors) are external to applications, they are stored in separate files and they are loaded into applications when their execution begins. Therefore, they do not interfere with updates. However, in scenarios where some object attributes processed by the report or data processor are removed or deleted, the report or data processor must be updated as well.

External reports and data processors are effectively plug-ins. They work well for the development of custom reports and for running specific operations on application data (such as data exchange with other systems), but they do not cover all possible customization scenarios. If a customer wants to add an algorithm that is executed when a document is posted, an external data processor cannot help and the customer must edit the source code in the document module.

Customization of cloud applications

With the development of 1cFresh (Cloud technology) customization came to a higher level. Cloud application users that work for different companies can access a single infobase (a single application instance) while being able to view only data related to their respective companies. Source code customization is not acceptable in this instance, because each company requires the customizations made specifically for its needs and does not need the customizations made for its “neighbors”.

In the Cloud, only external report and data processor customizations are acceptable, however, as we mentioned before, they do not cover all possible customization scenarios.

Configuration extensions

Due to the aforementioned scenarios, we felt the need to create a new customization tool satisfying the following requirements:

1. Easy migration of customized applications to new versions while avoiding manual merging as much as possible
2. The option to use customizations if certain conditions are met (for example, in the context of a specific company)
3. Reduced risk of application malfunctions after migration to new versions
4. The option to disable customizations to keep applications operational in the event of customization malfunction
   

A tool that satisfies all of the requirements would come in handy, not only in Cloud solutions, but also, in on-premise application deployments that require unique customization.

We developed such a tool and named it configuration extensions. It combines the features of two approaches to customization: plug-ins and event subscriptions.

Extensions provide a way to separate configuration changes from the configuration itself. An extension is actually a configuration that stores the changed objects. Just like a regular configuration, it features an object tree. You can manage extension configurations in Designer just like you manage regular configurations.

If you want to use an object from the main configuration in your extension (for example, add a form to a document that is available in the main configuration), you must adopt the object to the extension by clicking
Add to extension menu item. The added object is initially “empty”, it only has the properties that are available in the main configuration. However, you can adopt its form from the main configuration and then alter it (for example, add a button that executes some new action). Currently, you cannot add attributes to extension objects, however, be assured that we are working on it.

Main configuration and extension with adopted document Budget

Extensions also have a feature similar to event subscriptions: you can handle events of the configuration being extended. For example, you can handle the event of writing an object. You can specify the call type for each extension event handler:

The following fragment is executed before the standard document writing procedure. It verifies whether the field storing the person responsible for the document is empty. If it is empty, it writes the current user to that field.

&After("BeforeWrite")
Procedure ExtensionForAndromedaLtd_BeforeWrite(Cancel, WriteMode, PostingMode)
    If(ThisObject.Responsible = Catalogs.Users.EmptyRef()) Then
     ThisObject.Responsible = ModuleUsers.GetGurrentUser();
    EndIf;
EndProcedure

Even if the implementation of writing the document changes in the next code, the extension code will be executed before the document writing code.

At run time the standard configuration and all its extensions (it can have more than one) are combined to form a customized configuration. End users work with this customized configuration.

Extension execution order

When developing multiple extensions for your configuration, remember that the platform does not guarantee any specific order of extension execution. We deliberately refrained from specifying the extension order explicitly because it complicates extension setup and adds more problems than it solves.

If your configuration has multiple extensions, each including a posting handler for a specific document with &After directive, the platform executes all of the extension handlers every time the document is posted, however, their execution order might vary.

If each of the extensions includes a posting handler with &Around directive, only one of these handlers is executed and you cannot specifically tell which one. You must remember that and ensure that only one of the extensions features the &Around handler for each event.

Using extensions for form customization

You can adopt a main configuration form (for example, a document form) to a configuration extension. Initially, the form looks the same in the visual editors of the main configuration and extension. However, the module of the extension form is empty because the original form code belongs to the main configuration.

You can add one or more buttons to the form. You can add buttons in several extensions and all of these buttons will be present in the resulting form.

We recommend that you do not delete standard form items in extensions because this can lead to errors in the original configuration code (if the original code accesses these form items). Instead, use the Visibility property to hide unwanted items.

Note that a 1C:Enterprise application is more than just code. The better half of any application is described using declarative models. The objects types used in specific applications vary depending on the tasks they solve: forms, reports, rights, and so forth. Extensions offer optimal customization scenarios for specific models.

Extension advantages

There is a fundamental difference between the extensions and the delivery and support tool. The delivery and support tool allows customers to edit the vendor configuration at their own discretion and then resolve the merge conflicts during the update. Extensions allow customers to develop literal extensions (functionality that is added to the main configuration). Extensions are treated like add-ons and the system ensures the safety of the update.

Easy migration to new configuration versions

When a vendor releases a new version, standard configurations are updated automatically because their support settings remain unchanged (they still have full vendor support enabled). Then, when a customer runs the updated application, the platform automatically merges the updated configuration with its extensions, providing the customer with the application that is both updated and customized.

In some cases, adapting extensions to new versions of standard configurations is necessary. This can happen when the developers of the original configuration rename some objects or their attributes that are modified by extensions. For more information, see “Early error reporting” below.

Changes are stored separately

The main extension advantage comes from storing customer-specific customizations separate from the main configuration. Customers do not have to compare the changed configuration with the standard one to find out what has been changed.

As we mentioned before, to use a main configuration object in an extension users must adopt it from the main configuration. This creates a sort of reference to the main configuration object in the extension.

Users have the option to verify which adopted objects are changed and which ones are adopted as read-only ones (users may need read-only objects to build reports). The configuration tree of the extension has a button for filtering by objects added or changed in the extension. Clicking this button hides the read-only objects.

Early error reporting

Imagine that you adopted the Contracts catalog from the main configuration to use it in a report. In a new application release, the catalog is renamed to Agreements. Of course, the report will no longer work. With the old customization tool, you would learn that only when you attempted to generate a report. However, you can validate the extensions before you run the application, and this gives you time to correct errors before you migrate your users to the new application version.

This comes in really handy in deployments where an update is applied to a single infobase with multiple extensions (for example, in Cloud deployments where different companies that occupy different data areas of a single configuration use different sets of extensions). Administrators can update the configuration on a test infobase first to verify that all customer-specific extensions work correctly. If they encounter any issues, they inform the extension owners and delay the application update until all of the issues are resolved.

What’s next?

We believe that extension design is a crucial sector in development of 1C:Enterprise customization tools. Initially designed to facilitate customization of Cloud services, extensions also simplify the update of on-premise systems.

The current implementation of extensions has some limitations. For example, you cannot create applied objects (such as catalogs or documents) in extensions, and you cannot add new object attributes. We’re working on that and we keep adding new extension functionality in each 1C:Enterprise release:

• Extension of web services and HTTP services in version 8.3.7
• Adding objects to extensions (common commands, templates, pictures, as well as forms, commands, and templates of adopted objects) in version 8.3.8
• Adding roles to extensions and extension of modules in version 8.3.9