Several alternative options for integrating the site with 1C
On Habré there were several articles about the integration of the Site with 1C. I offer two new options.
In the 1C: Enterprise 8.x platform, a data exchange mechanism with any other 1C is implemented. The 1C: Enterprise database objects are exported to the xml-format by the platform. To register changes in exchange objects, use the configuration object “Exchange Plan”. The Exchange Plan contains information about the nodes between which the exchange takes place. For each node exchange is the numbering of messages exchange.
To ensure delivery of messages to the Site, 1C repeats sending data until it receives confirmation from the Site in the form of a received message number. Only after this exchange is considered successfully completed.
')
In the exchange always participate 2 files. Conditionally call:
1) Message_Site_1C.xml - file sent from the Site to 1C.
2) Message_1C_Site.xml - file sent from 1C to the Site.
Their structures are similar. Let's see an example of these files. Commenting only interesting tags to us.
As soon as any exchanging object is created or changed on the Website, we fix it in a certain registration table with the corresponding number of the current sent message (file Message_Site_1C.xml). In our example, 73086. After receiving the Message_1C_Site.xml file from 1C, we extract the number of the last message received from the Site from there. In our example, 73082. Next, we check. If the number of our current sent message (73086) is greater than the number of the last received message registered in 1C (73082), then all objects in messages with numbers up to 73082 have already been received. Remove them from the queue to send. And objects with message numbers greater than 72083 will be re-sent in the following messages until we receive a response from 1C.
On the part of 1C, a similar process occurs.
Disadvantages of this approach:
The standard 1C exchange does not notify the Site of errors during file processing, which does not allow the Site to send raw objects to 1C again.
For example, they sent in 1C 15 orders in message No. 200. The message was registered in 1C as successfully received. Of the 15 orders, only 12 were successfully processed, and 3 unsuccessful ones just disappear. There is also no exchange history, you have to save a huge archive of XML files. In the case of error analysis it is very difficult to find the necessary information.
Inflexible codes. Every time when a PHP programmer or a 1C programmer makes the slightest change (for example, adds a new tag), you have to manually write a new tag handler, then write queries to the database. This is extremely difficult and boring work, as well as a strong link to the cron on the side of the Site. You have to constantly check the FTP server for the presence of exchange files.
The exchange is based on the use of the XDTO package. XDTO-package is a template that describes the structure of the objects of exchange. In order to add a new 1C configuration object to the exchange, it is enough to create an object with the same name in the XDTO scheme and add properties to it that are identical to the details of the 1C object. Registration of changes in objects is made using the register information. This allows exchanging not at the level of messages, as in the standard exchange, but at the level of individual objects of exchange. During the export process, 1C objects are converted to XDTO objects, uploaded to xml-format and sent to the Site.
The scheme of interaction between the Site and 1C
For convenience, an XML-Mapper was created on the Site:
XML-Mapper provides developers with the opportunity to describe the gateway and minimally program it. We implemented it using the ini file. Ini file plays the role of data mapper. It establishes a correspondence between logical objects on the Site with their XML templates for exchange with 1C. The ini file also describes the data import / export actions for each tag.
A simple example ini mapper.
[Counterparties: mapper]
; General description of the object
object.name = Counterparties; Object name in XML template
object.class = buyerDomain; The corresponding class on the site
object.id = Link; Tag where ID field (GUID)
object.domain = 1; Flag whether an object is a logical entity on the Site
; Detail Mapper
object.tag [] = ID; XML tag name
object.imp [] = setTransactionStatusId; Import action
object.exp [] = getTransactionStatusId; Export action
object.guid [] = 0; Is this tag a GUID
object.tag [] = Change Time
object.imp [] =
object.exp [] = getCurrentTime
object.guid [] = 0
object.tag [] = Link
object.imp [] = setGuid
object.exp [] = getGuid
object.guid [] = 1
object.tag [] = Mark Deletion
object.imp [] = disable
object.exp [] = getEnable
object.guid [] = 0
object.tag [] = Name
object.imp [] = setName
object.exp [] = getName
object.guid [] = 0
object.tag [] = TIN
object.imp [] = setINN
object.exp [] = getINN
object.guid [] = 0
object.tag [] = PPC
object.imp [] = setKPP
object.exp [] = getKPP
object.guid [] = 0
object.tag [] = Head Counterparty
object.imp [] = setHolding
object.exp [] = getHolding
object.guid [] = 1
PS
The handwritten exchange has already shown its effectiveness on 5 projects. It is convenient to configure, it is not necessary to program a lot and tedious in 1C.
1. Integration with the Site based on the standard exchange between the two 1C.
In the 1C: Enterprise 8.x platform, a data exchange mechanism with any other 1C is implemented. The 1C: Enterprise database objects are exported to the xml-format by the platform. To register changes in exchange objects, use the configuration object “Exchange Plan”. The Exchange Plan contains information about the nodes between which the exchange takes place. For each node exchange is the numbering of messages exchange.
To ensure delivery of messages to the Site, 1C repeats sending data until it receives confirmation from the Site in the form of a received message number. Only after this exchange is considered successfully completed.
')
In the exchange always participate 2 files. Conditionally call:
1) Message_Site_1C.xml - file sent from the Site to 1C.
2) Message_1C_Site.xml - file sent from 1C to the Site.
Their structures are similar. Let's see an example of these files. Commenting only interesting tags to us.
As soon as any exchanging object is created or changed on the Website, we fix it in a certain registration table with the corresponding number of the current sent message (file Message_Site_1C.xml). In our example, 73086. After receiving the Message_1C_Site.xml file from 1C, we extract the number of the last message received from the Site from there. In our example, 73082. Next, we check. If the number of our current sent message (73086) is greater than the number of the last received message registered in 1C (73082), then all objects in messages with numbers up to 73082 have already been received. Remove them from the queue to send. And objects with message numbers greater than 72083 will be re-sent in the following messages until we receive a response from 1C.
On the part of 1C, a similar process occurs.
Disadvantages of this approach:
The standard 1C exchange does not notify the Site of errors during file processing, which does not allow the Site to send raw objects to 1C again.
For example, they sent in 1C 15 orders in message No. 200. The message was registered in 1C as successfully received. Of the 15 orders, only 12 were successfully processed, and 3 unsuccessful ones just disappear. There is also no exchange history, you have to save a huge archive of XML files. In the case of error analysis it is very difficult to find the necessary information.
Inflexible codes. Every time when a PHP programmer or a 1C programmer makes the slightest change (for example, adds a new tag), you have to manually write a new tag handler, then write queries to the database. This is extremely difficult and boring work, as well as a strong link to the cron on the side of the Site. You have to constantly check the FTP server for the presence of exchange files.
2. Development of exchange in 1C customizable without programming.
The exchange is based on the use of the XDTO package. XDTO-package is a template that describes the structure of the objects of exchange. In order to add a new 1C configuration object to the exchange, it is enough to create an object with the same name in the XDTO scheme and add properties to it that are identical to the details of the 1C object. Registration of changes in objects is made using the register information. This allows exchanging not at the level of messages, as in the standard exchange, but at the level of individual objects of exchange. During the export process, 1C objects are converted to XDTO objects, uploaded to xml-format and sent to the Site.
The scheme of interaction between the Site and 1C
For convenience, an XML-Mapper was created on the Site:
XML-Mapper provides developers with the opportunity to describe the gateway and minimally program it. We implemented it using the ini file. Ini file plays the role of data mapper. It establishes a correspondence between logical objects on the Site with their XML templates for exchange with 1C. The ini file also describes the data import / export actions for each tag.
A simple example ini mapper.
[Counterparties: mapper]
; General description of the object
object.name = Counterparties; Object name in XML template
object.class = buyerDomain; The corresponding class on the site
object.id = Link; Tag where ID field (GUID)
object.domain = 1; Flag whether an object is a logical entity on the Site
; Detail Mapper
object.tag [] = ID; XML tag name
object.imp [] = setTransactionStatusId; Import action
object.exp [] = getTransactionStatusId; Export action
object.guid [] = 0; Is this tag a GUID
object.tag [] = Change Time
object.imp [] =
object.exp [] = getCurrentTime
object.guid [] = 0
object.tag [] = Link
object.imp [] = setGuid
object.exp [] = getGuid
object.guid [] = 1
object.tag [] = Mark Deletion
object.imp [] = disable
object.exp [] = getEnable
object.guid [] = 0
object.tag [] = Name
object.imp [] = setName
object.exp [] = getName
object.guid [] = 0
object.tag [] = TIN
object.imp [] = setINN
object.exp [] = getINN
object.guid [] = 0
object.tag [] = PPC
object.imp [] = setKPP
object.exp [] = getKPP
object.guid [] = 0
object.tag [] = Head Counterparty
object.imp [] = setHolding
object.exp [] = getHolding
object.guid [] = 1
PS
The handwritten exchange has already shown its effectiveness on 5 projects. It is convenient to configure, it is not necessary to program a lot and tedious in 1C.
Source: https://habr.com/ru/post/140901/
All Articles