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.