1C:Enterprise 8.3. Practical Developer’s Guide. Lesson 24 (6:10). Data exchange. Understanding data exchange

Understanding data exchange

The data exchange feature of 1C:Enterprise is used to exchange data stored in the database with other software systems.

These can be other 1C:Enterprise infobases (and the configurations of participating infobases do not have to be identical), as well as non-1C:Enterprise systems.

Such a flexibility in data exchange is possible because data exchange tools available in 1C:Enterprise can be used in various combinations. Besides, data exchange format is based on the XML language, which is a generally accepted method of data presentation.

The data exchange features include:

  • Exchange plans
  • XML serialization
  • Tools for reading and writing XML documents

Generally speaking, the interaction between these three components can be visualized as shown in fig. 24.1.

Lesson 24 (6:10). Data exchange / Understanding data exchange
Fig. 24.1. Interaction between data exchange features

Using exchange plans, you can get information regarding which data items have been changed and which data exchange node they need to be sent to.

This is possible because exchange plans include a tool that records changes. Data changes are transferred using messages, and exchange plans also support this messaging infrastructure.

XML serialization enables conversion of a 1C:Enterprise object into an XML-formatted data sequence. XML serialization also provides the backward conversion of an XML-formatted data sequence into a 1C:Enterprise object, provided that a matching 1C:Enterprise data type is available.

Reading or writing XML documents is performed using the XML read/write functions of 1C:Enterprise script.

When implementing a data exchange algorithm, a developer can use these features either all together or in various combinations. In each specific case a developer decides which features they want to use.

In the example provided in this book you will use all the three features. So before you proceed to writing the script, let us take a closer look at each of them.

Understanding exchange plans

To implement exchange of any data with any system, you need to somehow identify the entities that will participate in the exchange in that system, and then define an exchange list for each of the entities. This is what the Exchange plan configuration object is used for.

Much like catalog data items are represented by catalog items, exchange plan data items are represented by exchange plan nodes.

Each node represents an exchange participant included in the exchange plan, and each exchange plan contains a predefined node, which represents this infobase.

A single configuration can include multiple exchange plans. Each exchange plan defines a set of data to be exchanged within the context of that plan, as well as the exchange scenario itself.

Multiple exchange plans may be needed when various nodes exchange different sets of data, or when the exchange scenarios for some nodes differ from the exchange scenarios for other nodes.

Learn more! For details on the structure of 1C:Enterprise script objects related to exchange plans, see section Developer quick reference. Exchange plans.

The following entities can participate in data exchange:

  • Database objects: catalog items, documents, and so on
  • Nonobject data: register record sets, sequence record sets, and constants
  • A special 1C:Enterprise script object: ObjectDeletion

We will subsequently refer to these data structure items as exchange objects.

A developer can determine the content of each exchange plan by specifying the configuration objects whose data participates in data exchange under this plan.

When you define a data set for an exchange plan, you can specify the AutoRecord property for each object type. It defines how the exchange plan tracks data changes.

Exchange plans track data changes using the change registration feature.

This feature is based on the fact that each of the exchange objects has a DataExchange property, which lets you specify the nodes for which changes to that object are recorded. All changes of an exchange object ultimately boil down to writing or deleting that object. The change registration feature analyzes the writing and deletion of exchange objects and generates change registration records based on the data exchange parameters stored in each exchange object. Note that the DataExchange property is not stored in the database, but is used only while a data exchange object is being written.

So the AutoRecord property, which is set together with the exchange plan data set, means that the data exchange parameters are generated by the change registration feature based on the exchange plan data.

You have the option to modify automatically generated exchange parameters. This is done using the BeforeWrite and BeforeDelete event handlers of the objects that participate in exchanges. You can modify the list of target nodes (the nodes for which changes are recorded) within the handlers.

You can also disable automatic change registration. If you do, you have to generate data exchange parameters from scratch using 1C:Enterprise script tools. This could theoretically be done in any script segment, but to make the configuration easier to understand, it is better to consistently use the BeforeWrite and BeforeDelete event handlers for this purpose, so that the script that generates data exchange parameters is concentrated in straightforward locations instead of being scattered throughout the configuration.

So, now you know that when exchange objects are written or deleted, an exchange plan generates change registration records. These records are stored in change registration tables, a separate table is maintained for each exchange object.

When an exchange object is modified, the number of records generated in the change registration table is equal to the number of target nodes specified in the data exchange parameters of that exchange object. Each of the generated records includes a link to its target node. Change registration tables are only created for a metadata object if the object is included in at least one of the exchange plans.

Besides a link to the exchange node for which changes are recorded, each record in the change registration table contains the number of the message that initally passed the change to that node. Before the initial message is passed, the field value is Null.

From the exchange plan perspective, a message is a basic unit of data exchange. Therefore, one of the most important components of an exchange plan (aside from the change registration services) is the message infrastructure.

Since exchange plan messages are transferred from one node to another within an exchange plan, each message is explicitly associated with an exchange plan and has a unique number, a single sender, and a single recipient. The message infrastructure provides message numbering, so that change registration records can store the numbers of the messages that initially transferred such changes.

The message infrastructure also supports sending message delivery confirmations from target nodes. A confirmation is included in each message coming from a target node as a number of the last received message.

Subsequently, by analyzing the number of the last received message and the numbers of the messages stored in the change registration records, the developer can delete change registration records whose delivery is confirmed.

XML serialization

The XML serialization term describes a feature that enables conversion of a 1C:Enterprise object into an XML-formatted data sequence. XML serialization also provides the backward conversion of an XML-formatted data sequence into a 1C:Enterprise object, provided that a matching 1C:Enterprise data type is available.

The thing to understand is that each exchange object, which exists as a single object within 1C:Enterprise, is actually comprised of various types of interconnected data.

For example, in addition to its code and description, a catalog item might contain a certain number of attributes of various types and a certain number of tabular sections, which in turn contain a certain number of attributes of various types.

Through XML serialization the entire body of data is represented as an XML-formatted data sequence.

Through backward conversion, the object is reassembled, provided that a matching data type is available in 1C:Enterprise.

Reading and writing XML documents

In contrast to XML serialization, the tools for reading and writing XML documents allow you to work with XML data on a basic level, without mapping that data to 1C:Enterpise objects.

Specifically, they allow you to open XML files for reading, read data from these files, create new XML files, and write data to these files.

Leave a Reply

Your email address will not be published.

 

1C:Enterprise Developer's Community