Universal data exchange. Data exchange property Distributed infobase

1C Data Conversion Tutorial (Edition 2) Optimization

Data Upload Rules

1. The order of the rules for uploading data

It is recommended to arrange data unloading rules in such a way that the links of dependent objects are from bottom to top. that is, the very first should be the rules for unloading data, the objects of which do not refer to anyone, then there should be rules for unloading objects referring to the first group, etc.

Example: You need to unload two directories Users and Individuals... Directory Users has the requisite Phys. person - link to the directory Individuals. That is, the Users directory refers to the Individuals directory. The recommended sequence of unloading rules in this case: Individuals, users.

2. Select data for upload with one request

If there is no transfer in the conversion rule tabular sections and movements, as well as in the events before unloading there are no direct calls to the unloaded object, it is recommended to use the "Select data for unloading by one request" mode in the data unloading rule. This mode will allow one request to receive all the data of a certain type being unloaded, rather than building separate queries for unloading each object.

Object Conversion Rules

3. Use quick search while loading

This mode of unloading and loading is recommended for those rules for converting objects that unload reference types, the total number of which is relatively small (up to about 1000 elements), to which there are many references in other objects.

Example: Directory Users. Almost all documents have a link to this directory and the number of directory elements does not exceed 1000.

4. Do not unload property objects by reference

The mode allows for the object conversion rule not to unload all the elements to which there are links. If the mode is set, then during unloading the object itself and information for finding all its links will be unloaded, but full information about dependent items will not be unloaded. This optimization can speed up the upload and download of data by several times.

5. Do not remember the unloaded objects

For the rules for converting non-reference objects (registers), you need to check the "Do not remember the unloaded objects" checkbox, since you cannot refer to the register lines, so there is no point in remembering those register lines that were unloaded. For referenced objects, this flag is usually needed in order to optimize repeated access to unload the same object.

6. Do not make general event handlers for all objects

It is not recommended to use common event handlers before unloading and loading data for all objects. The unloading and loading processors do not know what will be performed in these handlers, so some optimizations (for example, when loading, writing only changed objects) will not work. If there is a need to use the same algorithms for data processing during unloading and loading, then it is recommended to create a new Algorithm, and call it in the events of the required objects.

Generic XML Data Interchange Processing

7. Use an optimized format for data exchange

8. Download data in exchange mode

Allows you to avoid unnecessary checks at the stage of data loading

9. Write only changed objects

Allows to write only changed objects to the infobase. If the object has not been changed, then it will not be overwritten when loaded from the exchange file.

10. Optimized object recording

The mode allows you to sharply reduce the number of calls in the infobase for recording objects.

11. Write registers by record sets

The mode allows changes to registers to be written by recordsets rather than by record managers.

12. Communication via COM

For V8-V8 exchange, if the infobases of the source and destination are inside the same local network, it is recommended to use the exchange via COM - connection. You just need to have Universal Data Exchange processing in the receiver configuration.

Sincerely, Vladimir Milkin(teacher and developer

Automated systems management in most cases consists of separate databases and often have a geographically distributed structure. At the same time, correctly implemented data exchange is a necessary condition for effective work such systems.

At the same time, the initial exchange setup may require a number of actions, not only in terms of programming, but also consulting, even if we are dealing with homogeneous sources, as is the case with products on the 1C: Enterprise platform. Why setting up 1C exchange (or, as it is also called, data synchronization in 1C 8.3) can become the most time-consuming and expensive task of an integration project, we will consider in this article.

Data exchange in the 1C environment allows:

• Eliminate double entry of documents;
• Automate related business processes;
• Optimize communication between distributed units;
• Promptly update the data for the work of specialists from different departments;
• "Delineate" different types accounting. *

* In the case when the data of one type of accounting differ significantly from another, it is necessary to ensure the confidentiality of information and "delimit" information flows... For example, the exchange of data between 1C UT and 1C Accounting does not require uploading management data to the routine accounting database, i.e. synchronization in 1C will be incomplete here.

If you imagine standard process implementation of primary data exchange, when at least one of its objects is a 1C product, then the following stages can be distinguished:

• Coordination of the composition of the exchange;
• Definition of transport (exchange protocols);
• Setting rules;
• Scheduling.

Revealing the composition of exchange 1C

The objects of exchange can be conditionally divided into “source” and “receiver”. Moreover, they can perform two roles at the same time, which will be called - bilateral exchange. Determination of the source and destination occurs in a logical way, depending on the need or on functionality system. *

* For example, when integrating "WA: Financier" - a solution for financial accounting and treasury process management, developed on the basis of "1C: Enterprise", WiseAdvice experts recommend it as a master system. This is due to the availability of control tools to comply with the rules of the application policy, and, accordingly, to ensure the effectiveness of the solution.

Further, based on the received and recorded requirements from the users, a list of data for exchange is created, their volume, requirements for the exchange frequency are determined, the process of working with errors and processing of exceptional situations (collisions) is prescribed.

At the same stage, depending on the fleet of existing systems and the structure of the enterprise, the exchange format is determined:

Distributed information base

• RIB implies an exchange between identical configurations 1C databases, with a clear master-slave management structure for each exchange pair. As an element of the technological platform, the RIB, in addition to data, can transfer changes to the configuration and administrative information of the database (but only from the master to the subordinate).

Universal data exchange in 1C

• A mechanism that allows you to configure the exchange of 1C databases, both with configurations on the 1C: Enterprise platform, and with third-party development systems. The exchange is carried out by converting data into a universal xml-format in accordance with the "Exchange plans".

EnterpriseData

• The latest development of 1C, designed to implement data exchange in xml format between products created on the 1C: Enterprise platform with any automation systems. Using EnterpriseData simplifies the exchange-related enhancements. Earlier when logged into the system new configuration it was necessary to implement a mechanism for importing and exporting data, both for it and for existing systems. Now systems supporting EnterpriseData do not need any modifications, having only one "entry-exit" point.

Definition of transport (exchange protocols)

For the system based on the 1C: Enterprise 8 platform, a wide range of opportunities is provided for organizing an exchange with any information resources by means of generally accepted universal standards (xml, text files, Excel, ADO connection, etc.). Therefore, when defining a transport for exchange data, one should proceed from the capabilities of a third-party system database.

Synchronization of directories

The main principle of effective synchronization of directories is the presence of one entry point. But if it comes on working with reference books that were historically filled in according to different rules, it is necessary to clearly define the synchronization fields to bring the exchange to a “common denominator”. *

* At this stage, it may be necessary to carry out work on the normalization of the reference data on the side of the data source. Depending on the state of the reference books and their size, the process of matching elements, recognizing, detecting errors and duplicates, as well as filling in missing fields and assigning synchronization fields, may require the work of a whole group of experts, both from the integrator (owner of the standardization method of reference data) and from the customer's side.

Setting rules

The ability to display data from source systems in receivers depends on correctly specified exchange rules. The rules, presented in the xml format, regulate the correspondence of the key attributes of the source-destination objects. The 1C: Data Conversion solution is designed to automate the creation of rules for the implementation of both a one-time exchange and a permanent one.

Ensures no data loss when exchanging the Exchange Plan. This component any configuration on the 1C: Enterprise platform, which fully describes the procedure for exchanging 1C: data composition (documents with "identification" details) and nodes (information bases of receivers and transmitters), as well as RIB activation for selected exchange directions.

Any change in the data entered in the Exchange Plan is recorded and receives a sign of “change”. Until the changed data match each other in the transmitter-receiver nodes, the flag will not be cleared, and the system will send control messages to both nodes. After unloading the data and confirming their full correspondence in both systems, the sign is reset.

Exchange schedule in 1C

To automate the regular exchange, the frequency of data upload is set. The exchange frequency depends on the need and technical capabilities. Also, configurations on the 1C: Enterprise platform allow you to set up data exchange when an event occurs.

Having considered the standard exchange implementation process, let's pay attention to the factors that will require improvements at different stages:

• Non-typical, highly modified database configurations;
• Different versions 1C: Enterprise platforms;
• Not updated for a long time, not current versions configuration;
• Objects of exchange that have previously undergone modifications;
• The need for non-standard exchange rules;
• A very different set and composition of requisites in the available reference books.

Since even standard actions for the implementation of the primary data exchange require expert knowledge, they are recommended to be carried out with the participation of 1C specialists. Only after completing all the above steps should you proceed to setting up the exchange in the configuration. Let's consider the integration of databases using the example of "1C: UPP" and "1C: Retail" (according to the same scheme, exchange with "1C: UT" is configured). Also, the typical synchronization includes the exchange of the SCP - the SCP, which is typical for large-scale automation systems at the largest industrial enterprises.

In the "Service" submenu, select "Data exchange with products on the platform ..." (the choice of direct exchange with "Retail" often threatens with errors at the level of COM objects). Let's pay attention to the service message "This feature is not available".

To solve this problem, you must select "Communication settings"

... and tick the box. Next, we ignore the error message.

In the data synchronization settings, select "Create an exchange with" Retail "...

Before configuring the settings for connecting through a local or network directory, make sure that there is enough space on the disk for the directory. Although, as a rule, it does not take more than 30-50 MB, in exceptional cases it may require up to 600 MB. You can create the required directory directly from the configurator.

When connecting via a network directory, the offers to configure the connection via an FTP address and via e-mail ignored by clicking "Next".

In the settings, manually put down the prefixes - legend bases (as a rule, BP, UPP, RO), set the rules and the start date of data upload. The prefix will be indicated in the name of the documents to indicate the base in which they were created. If the unloading rules are not edited, the data will be unloaded by default for all available parameters.

We create an exchange settings file for "Retail" so as not to repeat our actions. If you need to immediately send data immediately after setting up synchronization, check the box.

To automate the exchange process, you need to set up a schedule.

Retail menu.

Check the box and select "Synchronization".

We make the "reverse" setting by choosing Manufacturing Enterprise Management.

Load the settings file created in the SCP.

We put a tick, the system picks up the address automatically.

We act in the same way as in the SCP.

Verification data comparison (Manual data comparison is recommended to be performed on preparatory stage since this work can become the most time consuming in the process of implementing the exchange). The mapping window is opened by double-clicking the mouse.

In case of an error in synchronization, "Details ..." will be replaced by "Never ...".

"In detail ..." opens a registration log with updated information on the exchange.

Ready.

What is Data Exchange.Download = True, how to use Data Exchange.Download.

Data Exchange.Downloading is an attribute of any object in the 1C enterprise system. It allows you to indicate when recording an object that it is necessary to disable any checks (including checks at the 1C platform level). This was done in order to avoid conflicts when exchanging data.

If you are developing your own configuration, in all data validation checks (for example, the BeforeWrite procedure), add the following line in the first line:

Get 267 1C video tutorials for free:

This is good practice among 1C developers.

Recording control in standard 1C processing

If you have ever used the standard ones (for example, Find and replace values, Batch processing, Universal data exchange, etc.), you probably noticed a setting that is usually called "Write control". This setting is just responsible for enabling / disabling the "Data Exchange.Download" attribute.

How to set the Data Sharing mode Download

It is very convenient to use this attribute in program code to disable all checks. For example, this attribute is required if you need to record an object, but it has blank required details. It can also be used as a way to increase the speed of bulk data processing - if you disable all checks, the system writes the object faster.

If you, in any typical configuration, make a global search for the word Data exchange, you will see a lot of links to it. And in common modules, and in modules of directories, documents, registers, etc. Let's consider what this property is and what it is used for.

Short review

If you open the branch in the syntax helper Applied objects, you may find that many of them: ReferenceObject, DocumentObject, for registers Record Set etc. there is a property Data exchange.

The type of this object: Data Exchange Options, which in turn contains three properties

Sender

Recipients

These properties are used in the exchange process between nodes. distributed infobase... In the property Sender a link to the node in which the object was changed is stored. Recipients contains a set of exchange plan nodes to which changes will be uploaded. If you need any non-standard actions when exchanging data between the bases and the sender, and the composition of the set of nodes can be changed programmatically. But on the third property - I want to dwell in more detail.

Data Exchange Property.Loading

If this property set to True, this indicates that an object is being written, received through the communication mechanisms. This assumes that the object contains correct data and the 1C platform performs the minimum number of checks. But very often, when writing an object, many programmatic checks are made in the predefined procedures of the object module. And this code is also executed when writing an object received from an exchange file. And in this case, errors can occur, for example, due to the fact that the data being checked has simply not been written yet.

Therefore, very often you can find the following code in object modules:

Procedure Before Recording (Refusal) If Data Exchange Refund; EndIf; // Here's the code with data validation End of Procedure

This avoids unnecessary checks when exchanging data between databases. Of course, if any code must be executed in any case, it must be placed before checking the property. This point must be taken into account when designing new metadata objects, if you have a distributed database and a new object participates in the exchange.

On the other hand, the presence of such a code allows the developer to illegally bypass data validation when program recording object, because the property is writable too. For example, using the following code:

New Product = Directories. Products. CreateElement (); New product. Name = "Test recording"; New product. Data Exchange Truth; New product. Write ();

And in some exceptional situations it can really help as a stopgap measure. But you shouldn't abuse it.

Last modified: 01.09.2015

Select clarification:

Universal data exchange is intended for loading and unloading data into a file in XML format between different 1C configurations according to the configured exchange rules.

Nomenclature, barcodes, fixed assets, etc. will be loaded from standard configurations 1C to the Cleverence base: Property accounting, and vice versa, from the Cleverence: Property accounting base, inventory, nomenclature, divisions, etc. will be uploaded to the client's working base.

Working hours

Processing has two modes of operation:

On the client. When using this mode, the rules and upload data files are transferred from the client to the server, and the upload data file is transferred from the server to the client. The paths to these files located on the client must be specified in the dialog box immediately before performing the action.

On server. In this mode, files are not transferred to the client and the paths to them must be specified on the server.

File external processing and the files of the exchange protocols must always be on the server, regardless of the operating mode.

Uploading data

Data upload order:

1. select the exchange rules - indicate XML file exchange rules, for each 1C configuration its own rules (they will gradually be added to the Cleverence assembly: Property accounting);
2. read the exchange rules;
3. after reading, the unloaded data will be filled in, you can specify which objects will be unloaded;
4. select the XML file (you can create an empty file - specify the name of the file and it will be created automatically), into which the data or the receiver information base will be loaded;
5. unloading data.

Uploading to an exchange file.

We indicate the name of the file into which the data will be downloaded. The resulting file with the uploaded data can be compressed.

Connecting and uploading data to the IS receiver.

Select the type of infobase:

• On the this computer or on a computer in the local network;
• On the 1C: Enterprise server.

We select the 1C platform and the information base directory for connection.

On the "Data to be exported" tab, you can select the types of objects that should be unloaded, set up filters for selecting objects, or specify a data exchange node for which you want to unload data.

On the tab "Upload parameters" you can specify Extra options unloading data.

On the "Comment" tab, you can write an arbitrary comment text to be included in the exchange file.

To load data, you must specify the name of the file from which the data will be loaded, if a password for compression was entered during unloading, then you need to specify it for unpacking.

• "Use transactions" - the ability to configure the loading of data in a transaction (a transaction is a logically linked, indivisible sequence of actions). To do this, you must select the "Use transactions" checkbox and specify the number of items in one transaction when loading.
• "Load data in exchange mode" (Data Exchange.Loading = True) - if the flag is set, then the loading of objects will be performed with the set sign of loading. This means that all platform and application checks are disabled when objects are written to the database. An exception is made for documents that are recorded in the mode of posting or cancellation of posting. Posting and canceling posting of a document is always performed without setting the loading mode, i.e. checks will be performed.
• "Write only changed objects to the infobase" - if the flag is set, then only changed objects are written to the infobase. If the object has not been changed, then it will not be overwritten when loaded from the exchange file.
• "Download objects by reference without marking deletion."
• "Optimized recording of objects" - if the flag is set, then the mode is turned on, which allows to sharply reduce the number of calls in the infobase for recording objects.
• "Write registers by record sets" - if the flag is set, then the mode is enabled, which allows writing changes in registers by sets of records, and not by record managers.
• "Truncate lines on the right" - if the flag is set, then spaces on the right are truncated when loading lines.
• "Configuring automatic data loading" - allows you to configure the use of automatic loading (use, do not use, ask a question before performing the operation).

"Debug boot handlers mode" is recommended use only for developers!

Additional settings

The bookmark is used for detailed customization upload and download data.

• "Debug mode" - a flag for setting the exchange debug mode. If this flag is set, then the communication process will not be stopped if any error occurs. The exchange will complete to the end with the output of debug messages to the exchange protocol file. It is recommended to use this mode when debugging exchange rules.
• "Output of information messages to the message window" - if the flag is set, then the protocol of the data exchange process will be displayed in the message window.
• "The number of processed objects to update the status" - the parameter is used to determine the number of processed items before changing the line status of loading / unloading
• "Data upload settings" - allow you to define the number of items processed in one transaction when uploading data, upload and process only those objects for which you have access rights, configure the type of registration change for unloaded objects through exchange plans.
• “Use the optimized format for data exchange (V8 - V8, processing version not lower than 2.0.18)” - the optimized format of the exchange message assumes the presence of the “InformationOnDataTypes” node in the message header, into which information about data types is uploaded. This allows you to speed up the data loading process.
• "Use transactions when uploading for exchange plans" - the flag determines the mode of using transactions (a transaction is a logically linked, indivisible sequence of actions) when uploading data when selecting changes on the nodes of exchange plans. If the flag is set, the data upload will be performed in a transaction.
• "The number of items in a transaction" - determines maximum number data items that fit into a message as part of a single database transaction. If the parameter value is 0 (default value), then all data is placed within one transaction. This mode is recommended as it guarantees the consistency of the data placed in the message. However, when creating a message in multi-user mode, there may be lock conflicts between the transaction in which data is placed in the message and transactions performed by other users. To reduce the likelihood of such conflicts, you can set this parameter to a value other than the default. The lower the value of the parameter, the less the likelihood of a lock conflict, but the higher the likelihood of placing inconsistent data in the message.
• "Unload objects for which you have access rights" - if the checkbox is set, the selection of infobase objects will be performed taking into account the access rights of the current user of the program. This involves using the ALLOWED literal in the request body to retrieve data.
• "Automatically remove invalid characters from strings for writing to XML" - if the flag is set, then when writing data to an exchange message, invalid characters will be removed. Symbols are checked against the XML 1.0 recommendation.
• "Registration changes for exchange nodes after unloading" - the field defines the mode of operation with registration of data changes after the completion of data upload.
  Possible values:
  Do not delete registration - after uploading the data, the registration of changes on the node will not be deleted.
  Completely delete the registration for the exchange node - after the data is uploaded, the registration of changes on the node will be completely deleted.
  Delete registration only for uploaded metadata - after uploading data, registration of changes on the node will be deleted only for metadata objects that were specified for upload.
• "Exchange protocol" - allows you to configure the output of information messages in the message window, maintaining and writing to separate file exchange protocol.
• "File name, exchange protocol" - the name of the file to display the protocol of the data exchange process.
• "Download protocol (for COM - connection)" - the name of the file for outputting the protocol of the data exchange process in the receiver base when exchanging via the COM connection. Important: the path to the file must be accessible from the computer on which the target base is installed.
• "Append data to the exchange protocol" - if the flag is set, then the contents of the exchange protocol file are saved if the protocol file already exists.
• "Outputting information messages to the protocol" - if the flag is set, then informative messages will be output to the exchange protocol, in addition to messages about exchange errors.
• "Open exchange protocol files after operations are completed" - if the flag is set, then after the data exchange is completed, the exchange protocol files will be automatically opened for viewing.

Deleting data

Bookmark needed only for developers exchange rules. Allows you to delete arbitrary objects from the infobase.