Processing Universal data exchange in XML format. Appearance and features of the use of universal data exchange

Processing "Universal Data Exchange in XML format" assigned to download and unload data to a file from arbitrary configurationimplemented on the 1C platform: Enterprise 8.

Operating procedure

When applied managed form Processing has two work order:
1. On the client. When this mode is applied, the rule files and downloadable data will be transferred from the client to the server, and the download file is transmitted from the server to the client. Ways to these files on the client are required to be specified in the opening window directly before execution.
2. On the server. IN this variant Files will not be transferred to the client and the path to them is required to be specified on the server.
Note: File external processing And the exchange protocol files are always required to be on the server, regardless of operation mode.

Processing has four bookmarks

Disload data

To unload data, it is required to determine the name of the file to which the data is unloaded and specify the exchange rules file. Exchange rules for any configurations have the ability to be configured in a special configuration "Data Conversion, Revision 2".

To unload documents and records of independent periodic information registers, it is required to determine the interval
- "start date" and "Completion Date." The resulting file with unloaded data has the ability to be compressed.

On the "Data Upload Rules" panel, it is permissible to specify those types of objects that are required to be unloaded, configure selection for sampling objects, or determine the data exchange node for which you want to upload data.

In the "Details of Uploading" panel, it is permissible to determine the additional details of data unloading.

On the "Comment" panel, it is permissible to write an arbitrary text-comment included in the exchange file.

To make data download, it is required to determine the name of the file from which the data will occur.

It is possible to configure download data in the transaction. This requires to take the "Use transactions" flag and determine the number of items in one transaction when loading.

"Load data in the exchange option (exchanged. Drive \u003d truth)" - if the checkbox is set, then the loading of objects will be performed with a specified lighting feature. This means that when writing objects to the database, all platform and applied checks will be disabled. The exceptions make up documents that are recorded in the embodiment or cancellation. Conducting and canceling the implementation of the document is always made without the installation mode assignment, i.e. Checks will be made.

Additional settings

The panel is designed for detailed uploading and downloading data.

"Debugging Order" - check box for setting the exchange debug mode. If this check box is set, the data exchange mechanism will not be stopped when any or error occurs. The exchange will be completed to the end with the output of debug messages to the exchange protocol file. This order It is advised to apply when debugging the exchange rules.

"Displays information messages to the message window" - if the checkbox is set, the message exchange protocol will be displayed in the message window.

"Number of processed objects to update status" - props is designed to calculate the number of processed elements Before editing the line of the download state / unloading

"Data Upload Settings" - Allow the number of elements of the data processed in one transaction when you upload data, unload and process only those objects to which there are access rights, configure the type of fixation entry for unloaded objects through the exchange plans.

"Use an optimized data sharing format (V8 - V8, a processing version not lower than 2.0.18)" - the optimized format of the exchange message suggests the presence of the "information function" node in the message header in which information about data types is unloaded. This allows you to speed up the data loading mechanism.

"Use transactions when unloading for sharing plans" - the checkbox sets the procedure for applying transactions when you upload data when selecting adjustments on the exchange plans nodes. If the checkbox is set, then the data unloading will be made in the transaction.

"Number of elements in the transaction" - sets the maximum number of data elements that are placed in the message within the boundaries of a single database transaction. If the contents of the parameter is identically 0 (default content), then all data is placed within the boundaries of one transaction. This order is recommended, as it guarantees the consistency of the data placed in the message. However, when creating a message in a multi-user version, there are the ability to be interlocking conflicts in which the data is placed in a message and transactions performed by other users. To reduce the likelihood of such conflicts, it is permissible to determine the contents of this parameter, different from the default value. The smaller the contents of the parameter, the less likelihood of the conflict of locks, but above the probability of the room into the message of inconsistent data.

"Unload objects to which there are permissions" - if the checkbox is set, then the sample of objects information base will be made taking into account the rights of access this user programs. This involves the application of the literal "allowed" in the text of the query for sampling data.

"Machine to delete invalid characters from lines to write in XML" - if the checkbox is set, then when writing data to the exchange message, invalid characters will be deleted. Symbols are analyzed to the ratio of XML 1.0 Recommendation.

"Editing fixation for exchange nodes after unloading" - the field sets the procedure for working with the registration of data adjustments after the data unloading is completed. Valid values:

* Do not delete registration - after unloading the data, the fixation of the adjustments on the node will not be removed.

* It is completely removed to register for the exchange node - after discrusting the data, the fixation of the adjustments on the node will be completely removed.

* Remove registration only for unloaded metadata - After you unload the data, fixing the adjustments on the node will be removed only for metadata objects that were set to unloading.

"Exchange Protocol" - Allows you to configure the output of information messages to the messaging window, maintain and write to a separate exchange protocol file.

"File name, exchange protocol" - file name for displaying the data exchange protocol.

"Download Protocol (for COM connections)" - name of the file to display the data exchange protocol in the database when exchanging through the COM connection. Note: The path to the file must be available from the computer on which the base receiver is defined.

"Add data to exchange protocol" - if the checkbox is set, then the contents of the exchange protocol file is saved if the protocol file is already available.

"Output to the information messaging protocol" - if the checkbox is set, then informative messages will be displayed in the exchange protocol, except for messaging error messages.

"Open exchange protocol files after execution of operations" - if the checkbox is set, then after execution of data exchange, the exchange protocol files will be equipped with an automatic.

Delete data

The panel is needed only for the developers of the exchange rules. Allows you to delete any objects from the information base.

Debugging and downloading data

Processing Allows you to debug event handlers and generate debugging module from file-rules or data file.

Turning on the debugging handler setting mode is performed on the "Data Upload" panel by installing the flag "order of debugging handlers". Accordingly, on the "Data Loading" panel, turn on the load debug mode is performed by installing the flag "order of debugging handlers".

After appointing the folder debug mode, the debug setting button will be available. After clicking on this button, the Settings window will appear.

Adjusting the debugging of handlers is made in four steps:

Step 1: Select Algorithm Debug Mode

In the first step, it is necessary to decide on algorithms debug mode:

* Without debugging algorithms

* Cause meroenisms as procedures

* Enter the code of algorithms at the place of call

The first order is conveniently used when we thoroughly know that the error in the handler is not associated with the code of which or algorithm. In this embodiment, the code of algorithms is not unloaded into the debug module. Mechanisms are made in the context of the Operator "Run ()" and their code is not available for debugging.

The second procedure is required to apply in those situations where the error is located in the algorithm code. During the task of this regime, mehehenis will be unloaded as certain procedures. In a moment of call, the algorithm from what or handler is to appeal to the relate processing procedure. This procedure is convenient to apply when the global variable "details" is used to transfer props in mehlinisms. Restrictions on the application of this mode is that when debugging in the algorithm, the local variables of the handler from which it opens are not available.

The third order of debugging is used, as in the second case, when debugging the code of algorithms and in those situations under which the second procedure for debugging is not suitable. During the task of this regime, mehehenisms will be unloaded as an integrated code in handlers. Those. Instead of the algorithm call operator, the full code of the algorithm is inserted taking into account nested algorithms. In this embodiment, there are no restrictions on the use of local variables of the handler, while there is a limitation when debugging algorithms with a recursive call.

Step 2: Creating a debug module

In the second step, it is required to upload handlers by pressing the button "To form a unload debug module (download). Formed handlers and mehelinisms will be displayed in a separate reading window. The contents of the debug module are required to be refined to the clipboard by pressing the "Copy to the clipboard" button.

Step 3: Creating External Processing

This step requires to start the configurator and make newly created external processing. The processing module requires to insert the contents of the clipboard (debug module) and save the processing under any name.

Step 4: Connecting External Processing

At the fourth, completing step, it is necessary to define the name of the external processing file in the input field. At the same time, 1C makes the time to create (update) the processing file. If the processing has an earlier version than the debug module file version, a warning will be displayed and the setup form will not be closed.

Note: The ability to debug a global conversion handler "After downloading the exchange rules" is not supported.

Arbitrary configurations implemented on the 1C platform: Enterprise 8.

Operating procedure

When applying a managed form, processing has two operating order:
1. On the client. When this mode is applied, the rule files and downloadable data will be transferred from the client to the server, and the download file is transmitted from the server to the client. Ways to these files on the client are required to be specified in the opening window directly before execution.
2. On the server. In this embodiment, the files will not be transferred to the client and the paths need to be specified on the server.
Note: External processing file and exchange protocol files are always required to be on the server, regardless of the operation mode.

Processing has four bookmarks

Disload data

To unload data, it is required to determine the name of the file to which the data is unloaded and specify the exchange rules file. Exchange rules for any configurations have the ability to be configured in a special configuration "Data Conversion, Revision 2".

To unload documents and records of independent periodic information registers, it is required to determine the interval
- "start date" and "Completion Date." The resulting file with unloaded data has the ability to be compressed.

On the "Data Upload Rules" panel, it is permissible to specify those types of objects that are required to be unloaded, configure selection for sampling objects, or determine the data exchange node for which you want to upload data.

In the "Details of Uploading" panel, it is permissible to determine the additional details of data unloading.

On the "Comment" panel, it is permissible to write an arbitrary text-comment included in the exchange file.

To make data download, it is required to determine the name of the file from which the data will occur.

It is possible to configure download data in the transaction. This requires to take the "Use transactions" flag and determine the number of items in one transaction when loading.

"Load data in the exchange option (exchanged. Drive \u003d truth)" - if the checkbox is set, then the loading of objects will be performed with a specified lighting feature. This means that when writing objects to the database, all platform and applied checks will be disabled. The exceptions make up documents that are recorded in the embodiment or cancellation. Conducting and canceling the implementation of the document is always made without the installation mode assignment, i.e. Checks will be made.

Additional settings

The panel is designed for detailed uploading and downloading data.

"Debugging Order" - check box for setting the exchange debug mode. If this check box is set, the data exchange mechanism will not be stopped when any or error occurs. The exchange will be completed to the end with the output of debug messages to the exchange protocol file. This procedure is advised to apply when debugging the exchange rules.

"Displays information messages to the message window" - if the checkbox is set, the message exchange protocol will be displayed in the message window.

"Number of processed objects to update status" - props is designed to calculate the number of processed elements Before editing the line of the download state / unloading

"Data Upload Settings" - Allow the number of elements of the data processed in one transaction when you upload data, unload and process only those objects to which there are access rights, configure the type of fixation entry for unloaded objects through the exchange plans.

"Use an optimized data sharing format (V8 - V8, a processing version not lower than 2.0.18)" - the optimized format of the exchange message suggests the presence of the "information function" node in the message header in which information about data types is unloaded. This allows you to speed up the data loading mechanism.

"Use transactions when unloading for sharing plans" - the checkbox sets the procedure for applying transactions when you upload data when selecting adjustments on the exchange plans nodes. If the checkbox is set, then the data unloading will be made in the transaction.

"Number of elements in the transaction" - sets the maximum number of data elements that are placed in the message within the boundaries of a single database transaction. If the contents of the parameter is identically 0 (default content), then all data is placed within the boundaries of one transaction. This order is recommended, as it guarantees the consistency of the data placed in the message. However, when creating a message in a multi-user version, there are the ability to be interlocking conflicts in which the data is placed in a message and transactions performed by other users. To reduce the likelihood of such conflicts, it is permissible to determine the contents of this parameter, different from the default value. The smaller the contents of the parameter, the less likelihood of the conflict of locks, but above the probability of the room into the message of inconsistent data.

"Unload objects to which there are access rights" - if the checkbox is set, then the selection of information base objects will be made in mind the rights of access of this user program. This involves the application of the literal "allowed" in the text of the query for sampling data.

"Machine to delete invalid characters from lines to write in XML" - if the checkbox is set, then when writing data to the exchange message, invalid characters will be deleted. Symbols are analyzed to the ratio of XML 1.0 Recommendation.

"Editing fixation for exchange nodes after unloading" - the field sets the procedure for working with the registration of data adjustments after the data unloading is completed. Valid values:

* Do not delete registration - after unloading the data, the fixation of the adjustments on the node will not be removed.

* It is completely removed to register for the exchange node - after discrusting the data, the fixation of the adjustments on the node will be completely removed.

* Remove registration only for unloaded metadata - After you unload the data, fixing the adjustments on the node will be removed only for metadata objects that were set to unloading.

"Exchange Protocol" - Allows you to configure the output of information messages to the messaging window, maintain and write to a separate exchange protocol file.

"File name, exchange protocol" - file name for displaying the data exchange protocol.

"Download Protocol (for COM connections)" - name of the file to display the data exchange protocol in the database when exchanging through the COM connection. Note: The path to the file must be available from the computer on which the base receiver is defined.

"Add data to exchange protocol" - if the checkbox is set, then the contents of the exchange protocol file is saved if the protocol file is already available.

"Output to the information messaging protocol" - if the checkbox is set, then informative messages will be displayed in the exchange protocol, except for messaging error messages.

"Open exchange protocol files after execution of operations" - if the checkbox is set, then after execution of data exchange, the exchange protocol files will be equipped with an automatic.

Delete data

The panel is needed only for the developers of the exchange rules. Allows you to delete any objects from the information base.

Debugging and downloading data

Processing Allows you to debug event handlers and generate debugging module from file-rules or data file.

Turning on the debugging handler setting mode is performed on the "Data Upload" panel by installing the flag "order of debugging handlers". Accordingly, on the "Data Loading" panel, turn on the load debug mode is performed by installing the flag "order of debugging handlers".

After appointing the folder debug mode, the debug setting button will be available. After clicking on this button, the Settings window will appear.

Adjusting the debugging of handlers is made in four steps:

Step 1: Select Algorithm Debug Mode

In the first step, it is necessary to decide on algorithms debug mode:

* Without debugging algorithms

* Cause meroenisms as procedures

* Enter the code of algorithms at the place of call

The first order is conveniently used when we thoroughly know that the error in the handler is not associated with the code of which or algorithm. In this embodiment, the code of algorithms is not unloaded into the debug module. Mechanisms are made in the context of the Operator "Run ()" and their code is not available for debugging.

The second procedure is required to apply in those situations where the error is located in the algorithm code. During the task of this regime, mehehenis will be unloaded as certain procedures. In a moment of call, the algorithm from what or handler is to appeal to the relate processing procedure. This procedure is convenient to apply when the global variable "details" is used to transfer props in mehlinisms. Restrictions on the application of this mode is that when debugging in the algorithm, the local variables of the handler from which it opens are not available.

The third order of debugging is used, as in the second case, when debugging the code of algorithms and in those situations under which the second procedure for debugging is not suitable. During the task of this regime, mehehenisms will be unloaded as an integrated code in handlers. Those. Instead of the algorithm call operator, the full code of the algorithm is inserted taking into account nested algorithms. In this embodiment, there are no restrictions on the use of local variables of the handler, while there is a limitation when debugging algorithms with a recursive call.

Step 2: Creating a debug module

In the second step, it is required to upload handlers by pressing the button "To form a unload debug module (download). Formed handlers and mehelinisms will be displayed in a separate reading window. The contents of the debug module are required to be refined to the clipboard by pressing the "Copy to the clipboard" button.

Step 3: Creating External Processing

This step requires to start the configurator and make newly created external processing. The processing module requires to insert the contents of the clipboard (debug module) and save the processing under any name.

Step 4: Connecting External Processing

At the fourth, completing step, it is necessary to define the name of the external processing file in the input field. At the same time, 1C makes the time to create (update) the processing file. If the processing has an earlier version than the debug module file version, a warning will be displayed and the setup form will not be closed.

Note: The ability to debug a global conversion handler "After downloading the exchange rules" is not supported.

Processing "Universal Data Exchange in XML format" is intended for downloading and unloading data to a file from any configuration implemented on 1C platform: Enterprise 8

Processing has four bookmarks

Disload data

To unload data, you must specify the name of the file to which the data is unloaded and select the exchange rules file. Exchange rules for any configurations can be configured in a specialized configuration "Data Conversion, Edition 2".

To unload documents and records of independent periodic information registers, you must specify the period - "start date" and "end date". The resulting file with unloaded data can be compressed.

On the "Data Unloading Rules" tab, you can select those types of objects to be unloaded, configure selection for sampling objects, or specify the data exchange node for which you want to upload data.

On the Upload Settings tab, you can specify additional data unloading parameters.

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

To load data, you must specify the name of the file from which the data will be downloaded.

It is possible to configure download data in the transaction. To do this, we need to take the "Use Transactions" checkbox and specify the number of items in one transaction when loading.

Additional settings

The bookmark is used for fine upload and download data.

"Debugging Mode" - checkbox Specifies the upload and loading mode

"The number of object processed to update the status" - the parameter is used to determine the number of processed items before changing the line load / unload status

"Data Unload Settings" - allow you to determine the number of items being processed in one transaction when you upload data, unload and process only those objects to which there are access rights, configure the type of registration change for unloaded objects through the exchange plans

"Exchange Protocol" - Allows you to configure the output of information messages to the message window, maintain and write to a separate exchange protocol file.

Delete data

The tab is only needed for the developers of the exchange rules. Allows you to delete arbitrary objects from the information base.

Debugging and downloading data

Processing Allows you to debug event handlers and generate debugging module from file-rules or data file.

Turning on the debugging handler setting mode is made on the "Data Upload" tab by setting the "Unload handler mode". Accordingly, on the "Loading Data" tab, turn on the load debug mode is made by setting the Load Processing Mode.

After setting the handler debug mode, the debug setting button will be available. By clicking on this button the setup window opens.

Setting up the folder debugs is performed in four steps:

Step 1: Select Algorithm Debug Mode

In the first step, it is necessary to decide on the algorithm debug mode:

Without debugging algorithm




Call algorithms as procedures




Enter the code of algorithms at the call

The first mode is convenient to use when we know exactly that the error in the handler is not associated with the code of any algorithm. In this mode, the code of algorithms is not unloaded into the debug module. Algorithms are performed in the context of the operator "Run ()" and their code is not available for debugging.

The second mode must be used in cases where the error is in the code of the algorithm. When installing this mode, the algorithms will be unloaded as separate procedures. At the moment of calling the algorithm from a processor, an appeal to the corresponding processing procedure occurs. This mode is convenient to use when the global variable "Parameters" is used to transmit parameters to the algorithms. Restrictions on the use of this mode is that when debugging in the algorithm, local variables of the handler from which it is called is not available.

The third debug mode is used, as in the second case, when debugging the code of algorithms and in cases where the second debug mode is not suitable. When installing this mode, the algorithms will be unloaded as an integrated code in handlers. Those. Instead of the algorithm call operator, the full code of the algorithm is inserted taking into account nested algorithms. In this mode, there are no restrictions on the use of local variables of the handler, but there is a limit when debugging algorithms with a recursive call.

Step 2: Forming a debug module

In the second step, it is necessary to unload handlers by pressing the "Generate upload debugging module". The formed handlers and algorithms will be displayed in a separate window for viewing. The contents of the debug module must be copied to the clipboard by pressing the "Copy to the clipboard" button.

Step 3: Creating External Processing

At this step, you must start the configurator and create a new external processing. In the processing module you must insert the contents of the clipboard (debug module) and save the processing under any name.

Step 4: Connecting External Processing

At the fourth, completing step, you need to specify the name of the external processing file in the input field. At the same time, the program checks the time to create (update) processing file. If the processing has an earlier version than the debug module file version, a warning will be displayed and the setup form will not be closed.

Note: The ability to debug a global conversion handler "After downloading the exchange rules" is not supported.

Printing (Ctrl + P)

Exchange via universal format

Subsystem "Data Exchange" Libraries of standard subsystems contains 4 options (technologies) of information exchange between various information bases:

• distributed information bases (RIB);
• data exchange through universal format;
• data exchange according to the exchange rules (exchange rules are created using the configuration "Data Conversion", revision 2.1);
• data exchange without exchange rules.

This article examines the technology of data exchange through universal format Enterprisedata.. This technology Available in the "Library of Standard Subsystems", starting from version 2.3.1.62. released in early 2016. On the this moment, Last edition of the BSP 2.3 (for use with the "1C: Enterprise 8.3" platform, not lower than version 8.3.8.1652 with a disconnected compatibility mode) has a release 2.3.6.17.

Fig. 1 Latest Releases BSP 2.3

Among the delivery files of the 1c application solutions, there is a text file "Library version", where the BSP version is written on the basis of the application, for example, based on Application Solution of UT 11.3.3.231, BSP 2.3.5.65.

Note that for use with the platform "1C: Enterprise 8.3" not lower than version 8.3.10.2168 With a disconnected compatibility mode released BSP 2.4.

Description of Enterprisedata format

What is EnterprisedAdata format?

This is a format that allows you to describe the object of the information base (counterparty, invoicing, etc.) or report the fact of deleting this object. It is expected that the configuration obtained the file in enterprisedata formatwill respond accordingly - it will create new objects and delete those that are marked as deleted. It is intended to exchange information between the configurations of UT, RT, UNF, BP. Also, the format can be used to exchange information with any other information systems: It does not depend on the features of his own software Or the structures of information bases that participate in the exchange and does not contain explicit limitations of use.

EnterprisedAdata format version

The format data is stored in XDTO - Packages in the branches General database configurations, as shown in Fig. 2.

Fig.2 xDTO - Enterprisedata data format packages

In fig. 2 It can be seen that there are several xDTO packets. it different versions format. The version number of the format consists of X.Y.Z, where X.Y - version, Z is a minor version. Minor version increases in the event of error correction and other changes, under which: the performance of data conversion logic based on previous version format (save the backward compatibility of current data transfer algorithms through the format); Support for new format capabilities for the conversion logic is voluntary. An example of such changes may be a correction of the error, changes in the properties of format objects, adding properties, the use of which is not required when converting data. In other cases, the Major version increases when the format is changed: X - in the case of global restructuring, y - in other cases.
The format describes the presentation of objects (documents or reference items) in the form of XML files. Version 1.0.1 contains a description of 94 objects from various fields (finance, production, purchases and sales, warehouse operations). Type names are usually clearly understood and do not need additional explanations: for example, "Document. Assistrates" or "Directory. Contractors". As you can see, the description of the types of documents begins with the prefix "Document", the directory element - from the prefix "Handbook.". Read more Description of the format you can see
The latest version 1.3, however, is most often used version 1.0. There is no big difference between the versions. Format Enterprisedataexchange_1_0_1_1 Used when exchanging through a web service.
Note What together with the data package Enterprisedata is used ExchangeMessage. When creating conversion rules. This package contains the type of object Additionalinfo,which can have any type of value and is used when creating a conversion rule between configuration objects. which are absent in the data format. Exactly due to Additionalinfo, You can adapt and configure the exchange rules without changing the format data in XDTO packets.

Fig. 3 XDTO-PackageMessage Structure

How to share data in EnterprisedAdata format?

EnterprisedAdata data exchange with configuration is sharing files. In response to received from external app File configuration processs it and create a file-answer. File sharing can occur:

• via a selected file catalog,
• through the ftp directory,
• through a web service deployed on the side of the information base. The data file is transmitted as a web method parameter.

Note. For bilateral data exchange between third-party applications and configuration on the side of the information base, a number of settings must be made - a third-party application must be registered in the information base, the exchange channel must be defined for it (through a file or FTP directory) and the like. But for cases of simple integration, when it is enough to transmit information from third-party application The information base and return data from the information base in the third partner is not required (for example, the integration of an online store that transmits sales information to "1C: Accounting"), there is a simplified version of work through a web service that does not require settings on the side.

When exchanging using configuration exchange plans during synchronization, only information about changes occurring since the last synchronization (to minimize the amount of transmitted information). With the first synchronization, the configuration will unload all objects in Enterprisedata format to an XML file (since all of them are "new" for a third-party application).

The next step is for third-party application - it should process information from the XML file and at the next synchronization session to put in the section information that message from configuration for certain number Successfully accepted (place in the ReceivedNo field number received from the configuration of the message). The receipt message is to configure the signal that all objects are successfully processed by an external application and you no longer need to transmit information about them. In addition to the receipt, the XML file from the third-party application may also contain data for synchronization (in the section ).

After receiving the receipt message, the configuration marks all the changes transmitted in the previous message as successfully synchronized. Only incomprehensive changes in objects (creating new, changing and deleting existing) will be sent to the external application at the next synchronization session.

When transferring data from an external application to the configuration, the picture changes to the opposite. The application must fill in the section accordingly, and in the section Place objects for synchronization in Enterprisedata format.

The configuration after processing the file will form an XML file that will contain a receipt and new data for synchronization from the configuration side (if there are such from the last synchronization session).

In more detail about the exchange of data with applied solutions on the 1C: Enterprise platform in Enterprisedata format you can see

General Module "Exchange Manager via Universal Format".

Procedures and functions that fully describe the rules for unloading data from the information base in the exchange format and the rules for downloading data from the exchange format to the information base are developed in the general module - the exchange manager module through a universal format.

Fig. 4 Structure of the exchange manager module through universal format

The module is created automatically using the "Data Conversion" configuration, Edition 3.0, based on configured exchange rules or manually in the configurator.

The module consists of several large partitions, each of which contains its group of procedures and functions.

1. Comment. The first line of the module contains a comment with the name of the conversion. This line is necessary to identify the module when using the command in the program "Data Conversion" program, edition 3.0., For example. // Conversion UE2.2.3 from 01.06.2017 19:51:50
2. Conversion procedures. Contains predefined procedures that are performed at different stages of data synchronization: before conversion, after conversion, before deferred filling.
3. Data processing rules (under). Contains procedures and functions that describe data processing rules.
4. Rules for converting objects (PKO). Contains procedures and functions that describe the rules for converting objects, as well as the rules for converting the properties of these objects.
5. Rules for converting predefined data (PCPD). Contains a procedure that fills the rules for converting predefined data.
6. Algorithms. Contains arbitrary algorithms that are called from other rules (Under or PKO).
7. Parameters. Contains the logic of filling the conversion parameters.
8. General purpose. Contains procedures and functions that are widely used in the rules and algorithms.

The following describes the parameters of procedures and functions that are used in several types of manager module procedures.

Component exchange. Type - Structure. Contains the parameters and exchange rules initialized as part of the exchange session.

Direction transfer. Type - String. Either "sending" or "getting".

Intelligence Type - directory object or Document object.

Conversion Event Procedures

There are three predefined procedures that are called during the conversion process:

• Confired. Called before performing data synchronization. Usually in this procedure is the initialization logic of various conversion parameters, filling the default values, etc. Parameters: Component exchange.
• Pomvertation. Called after performing data synchronization, but before performing a deferred fill. Parameters: Component exchange.
• Admitted Filling. Called before performing a deferred fill. Here you can position the sorting logic or adjustment of the table of objects subject to deferred filling. Parameters: Component exchange.

Procedures under

Failure-making treated. The export procedure in which the logic is located to fill the data processing rules. Contains calls for other procedures that add a rule of processing a specific object to the rules table (see below procedures. Add space). Parameters: Direction Movement, Ruined rules

Add_<ИмяПОД>. A set of procedures that fill the table under the rules for specific objects. The number of such procedures corresponds to the number of sub-conversion under this conversion in the program "Data Conversion" program, edition 3.0. Parameters: Ruined rules (Table of values \u200b\u200binitialized as part of the exchange session).

UNDER_<ИмяПОД>_Rooting. The procedure contains the text of the handler Sugagare For a specific under. The handler is designed to implement the conversion logic at the level of objects. For example, assign a specific PPC subject to a specific object depending on the content of the object. Parameters:

• Intelligenceor DataXDTO (Depending on the direction of exchange):
• when sending - an object ( Directory object,Document object);
• upon receipt - a structure with a description of the XDTO object.
• Empty. A type - Structure. The key contains a string named PKO, and the type value Boolean (True - PKO is used, False - PKO is not used).
• Component exchange.

UNDER_<ИмяПОД>_Selected. The function contains the text of the handler Gaplier. The handler is designed to implement an arbitrary algorithm for sampling objects subject to unloading. Return value: An array of objects subject to unloading. The array can contain both references to the objects of the information base and the structure with data for unloading. Parameters: Component exchange.

PKO procedures

FILLAGRAVLY CONCREDITTIVE BEACHES. Export procedure in which the logic of filling the rules of conversion of objects is located. Contains calls for other procedures that add a rule conversion conversion rule to the rules table (see below procedures. Edko). Parameters: Direction Movement, RulesKonvertation (Table of values \u200b\u200binitialized as part of the exchange session).

Add<ИмяПКО>. A set of procedures that fill the PKO Table by Rules for specific objects. The number of such procedures corresponds to the number of PCOs provided for this conversion in the "Data Conversion" program, edition 3.0. Parameters: RulesKonvertation (Table of values \u200b\u200binitialized as part of the exchange session).

PKO_<ИмяПКО>_Repotsed. The procedure contains the text of the handler Runifying For a specific PKO. The handler is used when unloading data. Designed to implement the logic of the data conversion contained in the object of the information base, in the description of the XDTO object. Parameters:

• Intelligence. A type - Directory object, Document object. Processed object information base.
• DataXDTO. A type - Structure. Designed to access the XDTO object.
• Component exchange.
• Stillload. A type - Array. Contains references to unloaded objects with respect to nesting.

PKO_<ИмяПКО>_ConvertencyXDTO. The procedure contains the text of the handler ReconfiguredXDTO For a specific PKO. The handler is used when loading data. Designed to implement arbitrary XDTO data conversion logic. Parameters:

• DataXDTO. A type - Structure. Properties of the XDTO object, pre-processing to simplify access to them.
• Received. A type - Directory object, Document object. An object of the information base formed by converting XDTO data. Not recorded in the information base.
• Component exchange.

PKO_<ИмяПКО>_Pextogenous. The procedure contains the text of the handler Front publishing For a specific PKO. The handler is used when loading data. It is intended to implement the additional logic that must be performed before writing an object in the information base. For example, you need to download changes to the existing data of IB or you should download them as new data. Parameters:

• Received. A type - Directory object, Document object. The data element formed by XDTO data conversion.

Is recorded in case these data are for the information base new (parameter Intelligence Contains value Undefined).

Otherwise Received replace themselves Intelligence (All properties from Received Torn B. Intelligence).

If the standard IB data is not required to be obtained, you should register your transfer logic, after which set the parameter Received value Undefined:

• Intelligence. A type - Directory object, Document object. An information base data element corresponding to the data obtained. If the corresponding data is not found, contains Undefined.
• Converting. A type - Table of values. Contains the rules for converting the properties of the current object, initialized as part of the exchange session.
• Component exchange.

PCPD procedures

FILLER THE RIGHT CONCREDITATIONSPEDDENINDENDED. Export procedure in which the logic of filling the rules for converting predefined data is located. Parameters: Direction Movement, RulesKonvertation (Table of values \u200b\u200binitialized as part of the exchange session).

Algorithms

In the "Data Conversion" program, the editorial board 3.0 is the ability to create arbitrary algorithms, which are caused from PCPD handlers. The name, parameters and content of algorithms are determined when developing rules.

Parameters

Failure parameters. Export procedure in which the structure is filling with the conversion parameters. Parameters: Parameasures (a type - Structure).

General Purpose Procedures and Functions

Performer ProcessorModulesAir. Parameters: NameProcessure (line), Parameters (structure). An export procedure that is intended to call the unservatory procedure of the module, the name and parameters of which are obtained on the input. Allows you to call a procedure or row function without using the method Perform.

Perform funque. Parameters: NameProcessure (line), Parameters (structure). Function, appointment similarly PerformingProcessorModulesamer. The difference is that it causes a function and returns its value.

Processing Universal Data Exchange in XML format (Universal Changeable SML Processing)

Handling "Universal Data Data In XML format" is designed to download and unload data to a file from any configuration implemented on the 1C platform: Enterprise 8.

Operating mode
When using a managed form, processing has two mode of operation:
1. On the client. When using this mode, the rules and downloadable files are transmitted from the client to the server, and the download file is transmitted from the server to the client. Ways to these files on the client must be specified in the dialog box immediately before performing action.
2. On the server. In this mode, files are not transmitted to the client and the path to them must be specified on the server.
Note: External processing file and exchange protocol files must always be on the server, regardless of operation mode.

Download Universal Data Exchange in XML format - Jump files can only registered user!

Processing has four bookmarks

Disload data
To unload data, you must specify the name of the file to which the data is unloaded and select the exchange rules file. Exchange rules for any configurations can be configured in a specialized configuration "Data Conversion, Edition 2".

To unload documents and records of independent periodic information registers, you must specify the period - "start date" and "end date". The resulting file with unloaded data can be compressed.

On the "Data Unloading Rules" tab, you can select those types of objects to be unloaded, configure selection for sampling objects, or specify the data exchange node for which you want to upload data.

On the Upload Settings tab, you can specify additional data unloading parameters.

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

It is possible to configure download data in the transaction. To do this, we need to take the "Use Transactions" checkbox and specify the number of items in one transaction when loading.

"Download data in exchange mode (exchanged. Drive \u003d truth)" - if the flag is set, then the object load will be executed with the installed download. This means that when writing objects to the database, all platform and applied checks will be disabled. The exceptions make up documents that are recorded in the mode of conducting or canceling. Conducting and canceling the document is always performed without installing the download mode, i.e. Checks will be performed.

Additional settings
The tab serves to detailed uploading and downloading data.

"Debugging Mode" - a flag for setting the exchange modes. If this flag is set, the data exchange process will not be stopped when any error occurs. The exchange will be completed to the end with the output of debug messages to the exchange protocol file. This mode is recommended to be used when debugging the exchange rules.

"Without information messages to the message window" - if the flag is set, the message exchange process will be displayed in the message window.

"The number of object processed to update the status" - the parameter is used to determine the number of processed items before changing the line load / unload status

"Data Upload Settings" - allow you to determine the number of elements of the data being processed in one transaction when you upload data, unload and process only those objects to which there are access rights, configure the type of registration change for unloaded objects through the exchange plans.

"Use an optimized data sharing format (V8 - V8, a processing version not lower than 2.0.18)" - the optimized format of the exchange message suggests the presence of the "information function" node in the message header in which information about data types is unloaded. This allows you to speed up the data loading process.

"Use transactions when unloading for sharing plans" - the flag determines the mode of use of transactions when unloading data when changing changes on the nodes of the exchange plans. If the flag is set, the data unloading will be executed in the transaction.

"The number of elements in the transaction" determines the maximum number of data items that are placed in the message within a single database transaction. If the parameter value is 0 (default value), all data is placed within a single transaction. This mode is recommended, as it guarantees the consistency of the data placed in the message. But when creating a message in multiplayer mode, blocking conflicts between a transaction can be placed in a message and transactions performed by other users. To reduce the likelihood of such conflicts, you can specify the value of this parameter, different from the default value. Than less value The parameter, the less likelihood of the blocking conflict, but above the probability of placing into the message of inconsistent data.

"Unload objects to which there are access rights" - if the flag is set, then the selection of information base objects will be performed taking into account the access rights current user programs. This involves the use of literal "allowed" in the text of the query for sampling data.

"Automatically delete invalid characters from rows for writing to XML" - if the flag is set, then when writing data to the exchange message, invalid characters will be deleted. Symbols are checked for compliance with XML 1.0 Recommendation.

"Changes to register for unloading unloading nodes" - the field determines the mode of operation with the registration of data changes after the upload is completed. Possible values:

Do not delete registration - after you upload data, the registration of changes to the node will not be removed.
Fully delete registration for the exchange node - after you upload data, the registration of changes to the node will be completely removed.
Delete registration only for unloaded metadata - After you unload the data, the change in the node will be deleted only for metadata objects that were specified to the unloading.

"Exchange Protocol" - Allows you to configure the output of information messages to the message window, maintain and write to a separate exchange protocol file.

"File Name, Exchange Protocol" - file name to output the data exchange protocol.

"Download Protocol (for COM connections)" - the file name for outputting the data exchange protocol in the database when exchanging through the COM connection. Important: The path to the file must be available from the computer on which the base receiver is installed.

"Add data to the exchange protocol" - if the flag is set, the contents of the exchange protocol file is saved if the protocol file already exists.

"Output to the Information Message Protocol" - if the flag is set, you will be displayed in the exchange protocol, in addition to messaging error messages.

"Open exchange protocol files after performing operations" - if the flag is set, then after making data exchange, the exchange protocol files will be automatically open to view.

Delete data
The tab is only needed for the developers of the exchange rules. Allows you to delete arbitrary objects from the information base.

Debugging and downloading data
Processing Allows you to debug event handlers and generate debugging module from file-rules or data file.

Turning on the debugging handler setting mode is made on the "Data Upload" tab by setting the "Unload handler mode". Accordingly, on the "Loading Data" tab, turn on the load debug mode is made by setting the Load Processing Mode.

After setting the handler debug mode, the debug setting button will be available. By clicking on this button the setup window opens.

Setting up the folder debugs is performed in four steps:

Step 1: Select Algorithm Debug Mode

In the first step, it is necessary to decide on the algorithm debug mode:

Without debugging algorithm
Call algorithms as procedures
Enter the code of algorithms at the call

The first mode is convenient to use when we know exactly that the error in the handler is not associated with the code of any algorithm. In this mode, the code of algorithms is not unloaded into the debug module. Algorithms are performed in the context of the operator "Run ()" and their code is not available for debugging.

The second mode must be used in cases where the error is in the code of the algorithm. When installing this mode, the algorithms will be unloaded as separate procedures. At the moment of calling the algorithm from a processor, an appeal to the corresponding processing procedure occurs. This mode is convenient to use when the global variable "Parameters" is used to transmit parameters to the algorithms. Restrictions on the use of this mode is that when debugging in the algorithm, local variables of the handler from which it is called is not available.

The third debug mode is used, as in the second case, when debugging the code of algorithms and in cases where the second debug mode is not suitable. When installing this mode, the algorithms will be unloaded as an integrated code in handlers. Those. Instead of the algorithm call operator, the full code of the algorithm is inserted taking into account nested algorithms. In this mode, there are no restrictions on the use of local variables of the handler, but there is a limit when debugging algorithms with a recursive call.

Step 2: Forming a debug module

In the second step, it is necessary to unload handlers by pressing the "Generate upload debugging module". The formed handlers and algorithms will be displayed in a separate window for viewing. The contents of the debug module must be copied to the clipboard by pressing the "Copy to the clipboard" button.

Step 3: Creating External Processing

At this step, you must start the configurator and create a new external processing. In the processing module you must insert the contents of the clipboard (debug module) and save the processing under any name.

Step 4: Connecting External Processing

At the fourth, completing step, you need to specify the name of the external processing file in the input field. At the same time, the program checks the time to create (update) processing file. If the processing has an earlier version than the debug module file version, a warning will be displayed and the setup form will not be closed.

Note: The ability to debug a global conversion handler "After downloading the exchange rules" is not supported.