Configuration delivery and support concept

Purpose

Let us consider a typical scenario: a vendor releases a standard configuration. A customer buys the configuration and customizes it for their needs. Then a vendor releases a new version and the customer wants to integrate their customizations with the vendor changes. Manual integration would be very time-consuming because it requires creating a list of changes and then replicating them to the latest configuration version. Replicating the vendor changes to the customer configuration is also inefficient. The configuration delivery and support feature mostly automate this process, leaving some of the decisions to the customer.

Generic update scenario

The following table summarizes the update options available for each metadata object. 

Customer

Vendor

Update rule

1 Changed Unchanged Get from customer configuration
2 Changed Changed ?
3 Unchanged Unchanged Get from customer configuration
4 Unchanged Changed Get from vendor configuration

Note that scenarios 1, 3, and 4 seldom require modifications of their update rules. Scenario 2 is more complicated because automatic rule selection makes no sense, but the platform can find all of the changed object properties, leaving the final choice of the update rule to the customer.

Update scenario implementation in 1C:Enterprise

Generic concepts

In 1C:Enterprise any configuration can be based on one or several supported vendor configurations. You can use a configuration created using the Configuration - Distribute configuration - Create distribution package and configuration update file command as a vendor configuration. This command creates a .cf configuration file. Note that files created using the Configuration - Save configuration to file command cannot be used as vendor configurations. To convert a vendor configuration to an Infobase file (.1cd) or an Infobase dump file (.dt), load the .cf file created as described above to your Infobase (which can be empty) using the following command: Configuration - Load configuration from file. Then you can use the standard platform tools to create a .dt file. 

There are two ways to add vendor support to your configuration:

  1. Start with a configuration created as described above and customize it whenever you need. Your custom configuration will be based on the supported vendor configuration. Alternatively, you can use the following commands: Configuration - Load configuration from file and Administration - Restore Infobase.
  2. Start with a customized configuration and run the Configuration - Compare and merge with configuration from file command. Select a vendor configuration for comparison, and if your configuration is not yet based on this vendor configuration, you are prompted to add vendor support.

Two support modes are available:

  1. The original vendor configuration is never changed. This mode is only available for the first method of adding support, and new vendor configurations have this mode by default. Changes of configuration objects are not allowed and new objects cannot be added to the configuration.
  2. The configuration is supported and configuration changes are allowed. To switch to this mode, open the support settings using the Configuration - Support - Support options command and click the Enable modification button.

You can update your configuration using files of the new version of the vendor configuration, or using .cfu configuration update files. You can update any configuration version using .cf files (including downgrade to an earlier version). During the creation of an update file, a vendor specifies configuration versions that can be updated using this file. Configuration versions that are not specified explicitly, both earlier and later ones, cannot be updated with .cfu files because update files only include the differences between specific configuration versions.

Example:

If the latest configuration version is 4 and the update is created for version 2, you cannot use it to update version 1 and version 3. This limitation is necessary for the correct processing of changes that negate each other. If a vendor increased the length of a string attribute in version 3 and reverted to the original length in version 4, this change is not included in the update from version 2 to version 4 because the string length is the same in both versions. If this update file is applied to version 3, the string length will not be reverted, which is incorrect.

Configuration update files have a small size because they only store the changes and because they use data compression. They are optimized for downloading through low-bandwidth channels but they provide less update flexibility than .cf files. The rest of the update process is identical for both .cfu and .cf files.

Figure 1. Interaction between customer and vendor configurations

Updating configurations

If a customer configuration includes a supported configuration with no customization allowed, the update is a strict and fully automated process. The user runs the ConfigurationSupport - Update configuration command and confirms the update, and then the configuration is updated.

If a customer switched the configuration to the mode where changes are allowed, the configuration is updated using the standard configuration comparison and merging feature, which in this case provides additional functionality: three configurations are involved. These include the customer configuration, the previous vendor configuration (which is stored in the customer configuration) and the new vendor configuration. 1C:Enterprise analyzes the changes automatically and assigns the update rules according to Table 1. If a property was changed by both vendor and customer (scenario 2 in Table 1), 1C:Enterprise cannot determine the update rule and leaves the decision to the customer. Such properties are marked in bold. You can select the Show only properties that were changed twice checkbox to view only the properties that require manual selection of update rules. After the merging, the vendor configuration stored in the customer configuration is updated to the new version.

Modification of update algorithm using support rules

The customer can modify the update algorithm by setting support rules for each metadata object. They might need it if they want to make all further object modifications themselves and they are no longer interested in new object versions provided by the vendor. In particular, this scenario can be used if they want to delete the object from their configuration. Three metadata object support rules are available:

  • Vendor object changes not allowed. The vendor object cannot be customized. The main purpose of this rule is described below but you can also use it to prevent accidental object changes. During the update, objects having this rule are replaced with their new versions from the vendor configuration.
  • Vendor object changes allowed w/o breaking support. It is the default rule. It utilizes the update algorithm described above.
  • Support cancelled for vendor object. The object is never updated. If you want to delete an object, you have to set this support rule first.

The following table extends Table 1 with metadata object support rules.

Table 2. Default update rules.

  Customer Vendor Support rule Update rule
1 Changed Unchanged Any Get from customer configuration
2 Changed Changed Vendor object changes not allowed No update
Vendor object changes allowed w/o breaking support Get from vendor configuration
Support cancelled for vendor object Get from customer configuration
3 Unchanged Unchanged Any Get from customer configuration
4 Unchanged Changed Vendor object changes not allowed Get from vendor configuration
Vendor object changes allowed w/o breaking support Get from vendor configuration
Support cancelled for vendor object Get from customer configuration

Restricting customization using delivery rules

A vendor can restrict customization of their configurations using delivery rules for individual metadata objects. This feature is designed to prevent modifications that change the configuration logic to the point when further support no longer makes sense. The following delivery rules are available:

  • Changes allowed
  • Changes not recommended
  • Changes not allowed

The following figure describes the support rules (both default and available to customers) that match various delivery rules.

Figure 2. Correspondence between delivery and support rules

Next page: Configurations based on several supported vendor configurations


Be the first to know tips & tricks on business application development!

A confirmation e-mail has been sent to the e-mail address you provided .

Click the link in the e-mail to confirm and activate the subscription.