7.4.4. Configurations and extensions

Save the configuration or the extension of the configuration to a file. To save the extension configuration you need correctly specify the -Extension parameter.

Load the configuration or the extension of the configuration from a file. To load the extension configuration you need correctly specify the -Extension parameter. If the extension does not exist in the infobase at the time of load, it is created with the specified name. If the extension specified in the -Extension parameter is connected to the configuration repository, it cannot be loaded.

Merge the current configuration/extension with the configuration/extension file (using the settings file).

The following parameters are available:

• <cf or cfe file name>. A name of the file with the configuration (CF file)/extension (CFE file) to be merged.
• -Settings <settings file name>. Allows you to specify the configuration merging settings file name.
• -EnableSupport. Put the configuration on the support, if possible to merge with the support. The support rules in this case should be specified in the settings file.
• -DisableSupport. Do not put on support even if it is possible.
• -IncludeObjectsByUnresolvedRefs. If merge settings contain the objects that are not included in the list of merged ones and absent not in the main configuration, but referenced from objects included in the list, then such objects are also marked for merging, and an attempt is made to continue the merging. Attempts are made until there are objects referencing the objects that are not included, or until the complete configuration is selected. Similar to Mark All for Merging button in the window with unresolved references, repeating of attempts only.
• -ClearUnresolvedRefs. References to objects that are not included in the list of objects to be merged are cleared. Similar to Continue button in the window with unresolved references.
• -Extension <Extension name>. A name of the extension to merge with.
• -force. Perform merging if there are:
  • Warnings of deleted objects referenced in the objects not included in the merging (such objects will be excluded from the merging).
  • Settings applying warnings.

    The merging will be interrupted in the above cases, unless specified.

If the -EnableSupport or -DisableSupport parameter is specified together with the -Extension parameter, merging will be terminated with an error. If support is available for the configuration and the -EnableSupport or -DisableSupport parameter is not specified, merging will be terminated with an error. If support is unavailable for the configuration but the -EnableSupport or -DisableSupport parameter is specified, merging will also be terminated with an error.

If there is a possibility to put the configuration on support, and the -EnableSupport parameter is specified, but there is no SupportRules element in the settings file, then the following support rules are set:

• New vendor objects:
  • Objects with vendor rule Changes allowed. Set the support rule Vendor object is not editable.
  • Objects with vendor rule Changes not recommended. Set the support rule Vendor object is not editable.
• Duplicate objects or objects with merge rule Get from new vendor configuration:
  • Objects with vendor rule Changes allowed. Set the support rule Vendor object is not editable.
  • Objects with vendor rule Changes not recommended. Set the support rule Vendor object is not editable.
• Modified objects with a rule other than Get from new vendor configuration:
  • Objects with vendor rule Changes allowed. Set the support rule Vendor object can be edited and are still supported.
  • Objects with vendor rule Changes not recommended. Set the support rule Vendor object can be edited and are still supported.

If unresolved links are detected in objects from the merged (second) configuration, and the -IncludeObjectsByUnresolvedRefs or -ClearUnresolvedRefs parameters are not specified, then the merge is aborted. For each object the list of properties of objects with unresolved links and the list of objects not included on these links are stored in the utility message file.

The warnings are written in the utility message file regardless the value of the -force parameter.

Compare two configurations and generate a file with a comparison report.

The following parameters are available:

• -FirstConfigurationType. The type of the first configuration to compare. The parameter can take values:
  • MainConfiguration. Main configuration.
  • DBConfiguration. Database configuration.
  • VendorConfiguration. Vendor configuration.
  • ExtensionConfiguration. Configuration extension.
  • ExtensionDBConfiguration. Configuration extension from database.
  • ConfigurationRepository. Configuration from a repository.
  • ExtensionConfigurationRepository. Configuration extension from an extension repository.
  • File. Path to the configuration file or configuration extension file.
• -FirstName <additional ID>. Name of the first configuration. The parameter can take the following values (depending on the value of the /FirstConfigurationType parameter):
  • VendorConfiguration. Vendor configuration name.
  • ExtensionConfiguration. Extension configuration name.
  • ExtensionDBConfiguration. Extension configuration name (from database).

    For the other values of the /FirstConfigurationType parameter this parameter is not applicable.

• -FirstFile. Path to the configuration file (.cf) or to the extension configuration file (.cfe). This parameter makes sense only if the /FirstConfigurationType parameter has value File.
• -FirstVersion. Version of the configuration repository. This parameter makes sense only if the /FirstConfigurationType parameter has value ConfigurationRepository or ExtensionConfigurationRepository.
• -SecondConfigurationType <configuration type>. Type of the second configuration to compare. The parameter values are fully equivalent to the parameter values /FirstConfigurationType.
• -SecondName <additional ID>. Name of the second configuration. Completely the same as for /FirstName.
• -SecondFile. Path to the configuration file (.cf) or to the extension configuration file (.cfe). Completely the same as for /FirstFile.
• -SecondVersion. Version of the configuration repository. Completely the same as for /FirstVersion.
• -MappingRule <rule>. Object mapping rule (if the configurations are not related).
  • ByObjectName. By object name. Used by default.
  • ByObjectIDs. By object IDs.
• -Objects <file name>. Path to a file with the list of objects to be involved in the operation. If the file is specified, the operation involves the objects specified in the file only. Otherwise, the operation involves the complete configuration.
• -IncludeChangedObjects. Include changed subordinate objects in the report.
• -IncludeDeletedObjects. Include deleted subordinate objects in the report.
• -IncludeAddedObjects. Include added subordinate objects in the report.
• –ReportType <report type>. Type of the comparison report:
  • Brief. Brief report.
  • Full. Full report.
• -ReportFormat <format type>. Describes the format of the report file:
  • txt. Text document.
  • mxl. Spreadsheet document.
• -ReportFile <file name>. Specifies the file name for the comparison report.$$$.

Update the database configuration. Before restructuring, the mobile client signature is verified. Displayed diagnostic messages are considered warnings by default and do not lock database configuration update.

It should be understood that the background update mechanism is not related to selection of the restructuring mechanism. If a background update is indicated, selection of the restructuring mechanism option (-v1|-v2) will be ignored.

The following parameters are available:

• -Dynamic<mode>. Shows whether dynamic update is performed. <mode> can take the following values:
  • . Explicitly prohibits dynamic update.
  • +. Allows dynamic update. First the system attempts to perform a normal update. If the attempt fails, the system attempts to perform a dynamic update. The dynamic update is also allowed if the –Dynamic+ parameter is not specified or if the -Dynamic parameter is specified without the mode.
• -BackgroundStart. Starts the background database configuration update and exits. If, in addition, the –Dynamic or –Dynamic+ parameter is specified, the system attempts to perform the dynamic update first. If this attempt fails, the background update is started.
• -BackgroundCancel. Cancel a running background database configuration update.
• -BackgroundFinish. Completes a background database configuration update (performs the change acceptance phase). An attempt to lock the database exclusively and perform the final phase is made. When the –Visible flag is specified, if it is impossible to complete the background update (go to the change acceptance phase) then the dialog box is displayed with the Cancel, Retry, End Sessions and Retry buttons. If the flag is not specified, the execution fails.
• -BackgroundSuspend. Pause a background database configuration update.
• -BackgroundResume. Resume a paused background database configuration update.
• -WarningsAsErrors. Treat all warnings as errors.
• -Server. Update is performed on the server (makes sense only in the client-server configuration). If this parameter is specified for a background update, the following rules apply:
  • The refreshing phase of the update is always performed on the server.
  • The processing phase and the change acceptance phase of the update can be performed both on the client and on the server.
  • The option to start a background update on the client and complete it on the server, or vice versa, is available.
  • The optimized restructuring mechanism is not used (the -v2 command is ignored if one is specified).
• -v1|-v2. Defines the restructuring mechanism in use. If the restructuring mechanism version (-v1 or -v2) is not specified, then the restructuring mechanism of the version specified in the conf.cfg file (on the client application side) will be used. Otherwise use the version specified in the command line. If an optimized restructuring mechanism is specified, but the use of this mechanism conflicts with other parameters, the usual restructuring mechanism will be used.
• -Extension <extension name>. The specified extension is updated.

Selection of the restructuring mechanism used is as follows:

• If the command line contains an explicit indication of the restructuring mechanism used, the specified mechanism will be used.
• If the command line does not indicate the restructuring mechanism used, the restructuring mechanism specified by the UpdateDBCfg parameter of the conf.cfg file (on the client application side) will be used.
• In any case, the –Server command indicates that the restructuring will be executed on the server. This command does not affect the selection of the restructuring mechanism used.

You can use /UpdateDBCfg after the following options:

• /LoadCfg
• /UpdateCfg
• /ConfigurationRepositoryUpdateCfg
• /LoadConfigFiles
• /LoadConfigFromFiles
• /MobileAppUpdatePublication
• /MobileAppWriteFile
• /MobileClientDigiSign
• /MobileClientWriteFile

Save to a file the database configuration or the configuration of the extension saved to the database. To save the extension configuration you need correctly specify the -Extension parameter.

Displays the name of the main configuration (if no one parameter is specified) or the name(s) of the extension(s). The following parameters are available:

• -Extension. Displays the name of the specified extension.
• -AllExtensions. Displays the names of all extensions.

Revert to database configuration.

If the -Extension parameter is specified, the configuration saved in the database for the specified extension is restored.

Deletes the extension with the specified name. If you specify the –AllExtensions option, all extensions are deleted. This command can't be used without parameters.

Dumps some properties of configuration objects (modules, templates, images, access rights and reference information) to files. The following directories and parameters are available:

• <dump directory>. The directory that stores property files.
• -Module. Upload modules.
• -Template. Upload templates
• -Help. Upload help topics.
• -AllWritable. Upload only properties of writable objects.
• -Picture. Upload common pictures.
• -Right. Upload rights.
• –Extension. Process the extension with the specified name.

Restores some properties of configuration objects (modules, templates, images, access rights and reference information) from files. The following directories and parameters are available:

• <load directory>. The directory that stores property files.
• -Module. Load modules.
• -Template. Load templates.
• -Help. Load help topics.
• -AllWritable. Load only properties of writable objects.
• -Picture. Load common pictures.
• -Right. Load rights.
• –Extension. Process the extension with the specified name. If the extension is bound to a repository, the objects to be loaded must be locked in that repository.

If the batch mode command is executed successfully, it returns code 0. Otherwise, it returns code 1 (and 101 if the data contains errors).

Uploads configuration to files. The following parameters are available:

• -Format. Defines the format of upload configuration files:
  • Plain. Linear format.
  • Hierarchical. Hierarchical format. Used by default.
• –Extension. Uploads the specified extension.
• –AllExtensions. Uploads all extensions, does not upload main configuration. Each extension is uploaded to a directory with corresponding name.
• -update. Indicates that it is necessary to update previous unload, that is, upload only objects with versions differ from the versions of previously uploaded objects.

  Version file (ConfigDumpInfo.xml) is taken from current dump directory. If the current version of the upload format does not match the version of the version file format or if the version file is not found, an error is generated. After upload complete the version file is updated.

  It is possible to add the following parameters:

  • -force. If the current version of the upload format does not match the version of the format in the version file, a full upload is performed.
  • -configDumpInfoForChanges. If before upload, the current upload directory is not empty, an error is generated. Matching the current version of the upload format to the version of the upload format in the version file is not checked. Upload generates new version file. The file specified in the -configDumpInfoForChanges parameter is not updated.
• -force. Perform full upload if attempt to update the upload reveals the mismatch between the current version of the upload format and the version of the format stored in the version file (ConfigDumpInfo.xml). Used in combination with the -update parameter only. Otherwise, it is ignored.
• -getChanges <file name>. The specified file contains the list of changes in the current configuration regarding the upload and, accordingly, the file of the version which directory is indicated by the parameter of the command /DumpConfigToFiles. For this parameter the file name is required.

  Can be used with the –configDumpInfoForChanges parameter. In this case the changes are determined relative to the version file (ConfigDumpInfo.xml) specified in this parameter. If the file version is not found when using the -configDumpInfoForChanges parameter an error is generated.

• -configDumpInfoForChanges <file name>. Specifies the version file (ConfigDumpInfo.xml) to check changes. This parameter requires the full file name.

  This parameter can be used only with the parameters -update and -getChanges.

• -listFile <file name>. Specifies file with the list of objects unloaded regardless of their update status. For this parameter the file name is required.

  Objects from the list are uploaded completely, except the subordinate objects that are treated as separate objects of development. To upload such subordinate objects, they should be explicitly indicated in the list.

  If an object from the list has subordinate objects that are not separate development objects but have external properties, then the external properties of these objects are also dumped.

  In the file containing the names of the objects to be exported, you can specify the Configuration identifier, which is the equivalent of the configuration root. If the Configuration identifier is present in the file, which is not followed by the name of the root configuration object, then during exporting this identifier will be equivalent to the full name of the configuration root object, i.e., an entry of the Configuration.Help type is equivalent to the Configuration.ConfigurationName.Help entry.

  You can use both names containing the Configuration identifier and the full name of the root configuration object at the same time. If you want to export two external properties of the root configuration object, for example, Help and Splash, then in the file with the object list you can specify the following lines:

Configuration.Help
Configuration.ConfigurationName.Splash

This parameter can't be used with other parameters.

• -configDumpInfoOnly. Specifying this parameter leads to the fact that only the version file (ConfigDumpInfo.xml) is generated during dumping. If the -format parameter will be specified in the command line, the version file will be generated for the specified export format. By default, a version file is generated for the hierarchical export format.

  This parameter can only be combined with the -format parameter. Combination with other parameters is not allowed.

• -Server. Indicates that the configuration must be dumped to files on the 1C:Enterprise server side. In this case, the configuration will be dumped in multi-threaded mode (faster). The command has an optional parameter:
  • -JobsCount <count>. Allows you to specify the number of concurrent background jobs to dump the configuration to files on the server side.

    Default value: 0. In this case, the number of background jobs is defined by the platform automatically based on the number of CPU cores on the computer with 1C:Enterprise server cluster.

• -Archive <file name>. Allows you to dump the configuration to a ZIP archive file. This parameter can be used to perform the full dump, partial dump, to export only the current state file (the -configDumpInfoOnly parameter is specified) or all configuration extensions (the –AllExtensions parameter is specified).
• -ignoreUnresolvedReferences. When dumping a configuration, references to unobtainable objects, which were deleted in one of the earlier configuration versions, are not dumped.

  If you dump a configuration and decide to ignore references to unobtainable objects, you will observe the following behavior:

  • Unobtainable references to managed form commands are replaced with a default reference.
  • Unobtainable references to command groups in managed forms are not dumped.
  • Unobtainable paths to data in forms are not dumped.
  • Unobtainable references to predefined items are not dumped.
  • Unobtainable references in choice parameter links of metadata objects are not dumped.
  • Unobtainable references in type links of metadata objects are not dumped.
  • Unobtainable references to the subsystem command interface commands are not dumped.
  • Unobtainable references to command groups in the subsystem command interface are replaced with NavigationPanelOrdinary.

    If the subsystem command interface is cleared completely, the next loading of such XML file into the configuration will clear the external property in the corresponding metadata object. As a result, the external property file will be missing during the next dump to XML.

    The result of comparing the original configuration and the one loaded from XML files that was previously dumped to them with ignored references to unobtainable objects can contain configuration object changes, including changes without specific details.

See also:

• ConfigDumpInfo.xml file

Restores a configuration from files. Loading extensions to the main configuration (or vice versa) is not supported. When the configuration files are fully restored, the restore format (linear or hierarchical) is automatically determined. For partial loading, automatic format detection is not supported. Specify a format explicitly using the –Format parameter.

The following parameters are available:

• –Extension. Uploads the specified extension. If the extension does not exist, it is created. If the extension is bound to a repository it can't be fully loaded. If the loaded objects are locked in the extension configuration repository the load may be partial.
• –AllExtensions. The extensions are loaded from files. Each subdirectory in the specified directory is considered an extension. This parameter is incompatible with the –files and -listFile parameters.
• -files. Specifies which files should be loaded when the configuration is partially loaded from files. Each file can be specified with the full path or with the relative path for the load directory. The list of files must be enclosed in quotes; the file names must be separated by comma. This parameter is incompatible with the –AllExtensions parameter.
• -listFile. Specifies file with list of the loaded files. Files are listed there one file name per line, each name can be full path to the file or relative path from the download directory. Strings must be separated by a line break. Line break is supported in both Windows and Linux formats. - File is expected to be in UTF-8 encoding. Empty strings are not supported. If the string starts from REM it is skipped. This parameter is incompatible with the –AllExtensions parameter.
• -Format. Defines the format of upload configuration files:
  • Plain. Linear format.
  • Hierarchical. Hierarchical format. Used by default.

    This parameter can be used only with the -files or -listFile parameters.

• -updateConfigDumpInfo. Creates in the end of load the ConfigDumpInfo.xml version file corresponding to the loaded configuration. If a configuration is being loaded partially (the -files or -listFile parameter is present), updates the existing version file.
• -NoCheck. Specifies that integrity of the configuration to be loaded is not checked upon loading. It reduces the loading time if the command initiator is sure about configuration integrity.
• -Archive. Contains a name of a ZIP archive from which files will be loaded. To execute the command, specify either the load directory or this parameter. You cannot specify the load directory and this parameter at the same time.

If you specify the –files and –listFile parameters at the same time, the first specified parameter in the command line is used.

See also:

• ConfigDumpInfo.xml file

The command allows you to receive an ID of the current configuration metadata generation. This ID is updated every time the configuration is changed. It does not make sense to compare IDs received using this command in terms of "greater/less". It makes sense to compare such IDs in terms of "equal/not equal". It allows you to check whether the configuration has been changed since the last ID was received.

To get an ID, specify the /Out command in Designer startup command line. The ID will look as follows: 4d8d1d994cd4534c9accd32a5b44b35300000000. For an empty infobase, the ID will look as follows: 0000000000000000000000000000000000000000.

The following parameters are available:

• –Extension. Gets a metadata ID of the specified extension. If the parameter is not specified, an ID is received for the main configuration.