Incremental export of configurations to XML files

This feature is implemented in 1C:Enterprise version

We continue to develop the mechanism for export/import of configurations to/from XML files. In one of the previous versions of 1C:Enterprise, we implemented partial import of configurations from XML files. Now we have completed the reverse operation – partial (incremental) export of configurations.

As a result of these two changes, group development of large configurations should become easier and faster.

Modification of export logic

The main change is that when you export a configuration to XML files, the ConfigDumpInfo.xml utility file (the version file) is now generated (or updated). It is stored in the export directory alongside the rest of XML files and contains information about the export format, export version, as well as about the versions of all the objects that were exported.

Now, after analyzing this file, the platform knows exactly, which versions of which objects are included in the previously exported files. Based on this information, it exports only those objects that were changed in relation to the already exported ones.

In practice, it looks like this.

If the configuration is exported for the first time (or if there is no version file in the export directory), then full export takes place and the version file is generated.

If there is already a version file in the export catalog, then only configuration changes with respect to the version file are exported and the version file is updated.

For example, a fragment of a version file may look as follows:
<ConfigDumpInfo format="Hierarchical" version="2.1">
   <Metadata name="CommonAttribute.DataAreaMainData"
      configVersion="0x230b7fe18c916f0cf161734d63ba5cfc6bda9cfc" />
   <Metadata name="Role.SystemAdministrator.Rights"
      configVersion="0xf543960146ba71301564ab0331f5f4a754fd450" />

Usage scenarios

An interesting point is that partial exporting of a configuration into XML files provides you right away with several new features that were not available previously or were difficult to implement.

Optimization of 1C:Enterprise Development Tools

This feature does not require any effort on your part, because is implemented at the level of the platform. Of course, we will primarily use incremental export to XML files in the new development environment. This should speed up the work with large configurations, for which this environment is intended. The fact that it is now possible to export only changed objects should accelerate operations for getting changes from the infobase.

Interactive exporting

This scenario lets you periodically save a configuration as XML files during the development process. It used to be that for large configurations, this scenario was not feasible in practice, because every time, the entire configuration was exported. And it could take a long time.

Now you will need to export the entire configuration only the first time. Then you modify the configuration and at some point simply call the export dialog box, specify the directory, and click OK. As a result, only those changes to the configuration that you have made since the last time you exported the configuration to XML files will be exported.

Automatic updating of previously exported data

This is a variation of the previous scenario when the changes you made during the day are automatically exported to XML files. Here you will need to write a script that runs at the end of a working day and executes, for example, the following command:
1cv8.exe config /DumpConfigToFiles C:\xml –update
As a result, only those changes (-update) that were made since the previous export, i.e. during the day, will be saved to the export directory (C:\xml).

update is a new parameter, which allows you to update previously exported data, i.e. export only those files whose versions are different from the versions in the export directory.

Automatic modification or verification of configurations

There are a variety of tasks when exporting a configuration to XML files is used to automatically validate your configuration, or to perform scheduled actions not related to application logic. This can be, for example, an automated configuration check for compliance with the standards of development adopted in your company. Or automatic modification of roles for new objects.

What these tasks have in common is that the configuration must first be exported to XML files. And sometimes it also needs to be imported back. Here, of course, incremental configuration export will allow you to save a significant amount of time in the export-processing-import chain.

Control of configuration changes

This scenario is useful when multiple developers simultaneously work on the same configuration. There is also a set of XML files in the export directory, which is the reference state of the configuration. The task is to save the information about the changes that occurred every time the configuration is changed. In this case, a developer can run a command like this:
1cv8.exe config /DumpConfigToFiles C:\xml -getChanges C:\diff.txt

As a result, a file (C:\diff.txt) will be created that contains the configuration changes (-getChanges) in respect to the reference set of XML files (C:\xml). If there are no changes, the diff.txt file will be empty.

getChanges is a new parameter, which allows you to transfer to the specified file the changes of the current configuration in respect to the set of XML files whose directory is specified before this parameter.

Working with version control systems

One more group development scenario assumes that the set of XML files is stored in an external version control system, with which all developers work.

Then a developer, by making changes in the configuration of the local infobase, can perform the following steps:

  • Get updates (Update) of the configuration files from the version control system (if any).
  • Export the changed objects from the local infobase by using, for example, the following command:
    1cv8.exe config /DumpConfigToFiles C:\xml -update
  • Commit the changes (Commit) to the version control system.

After that, other developers will be able to update (Update) their copies of the configuration files.

Generating configuration patches

And finally, the last scenario for using partial configuration export into XML files allows you to create so-called "patches" from XML configuration files.

For example, there is a configuration that is stored and distributed as a set of XML files. It is known that this configuration does not change a lot. At some point, errors in the configuration were identified.

Then before fixing errors, you save the set of XML files corresponding to this state of the configuration as a reference set. After this, you fix the errors and export only the changes related to the corrected errors. For example, by using the following command:
1cv8.exe config /DumpConfigToFiles C:\xml_patch -update –configDumpInfoForChanges C:\xml_source\ConfigDumpInfo.xml   

Here C:\xml_source\ConfigDumpInfo.xml is a version file of the reference configuration, and C:\xml_patch is the directory where only those XML files that fix the detected errors will be exported.

configDumpInfoForChanges is a new parameter, which allows you to specify a certain version file, starting with which the changes began to be implemented.

If you wish to not only export files, but also to get a list of changed objects included in your patch, you need to run the following command:
1cv8.exe config /DumpConfigToFiles C:\xml_patch -update –configDumpInfoForChanges C:\xml_source\ConfigDumpInfo.xml -getChanges C:\diff.txt    

Then the information on the changes will be saved to the C:\diff.txt file.