Ways of integration with 1C
What are the most important requirements for business applications? One of the most important are the following tasks:
How the first task is solved in 1C was briefly described in the “Customization and Support” section of this article ; we will return to this interesting topic in a future article. Today we will talk about the second task, about integration.
Integration tasks may be different. To solve one, a simple interactive data exchange is enough - for example, to transfer a list of employees to a bank for processing payroll plastic cards. For more complex tasks, a fully automated data exchange may be necessary, possibly with reference to the business logic of the external system. There are tasks of a specialized nature, such as integration with external equipment (for example, trade equipment, mobile scanners, etc.) or with legacy or highly specialized systems (for example, with RFID tag recognition systems). It is extremely important for each task to choose the most appropriate integration mechanism.
There are various approaches to the implementation of integration with 1C applications, which one to choose depends on the requirements of the task.
')
Suppose we are faced with the task of bidirectional data exchange between the application 1C and an arbitrary application. For example, we need to synchronize the list of goods (Reference Nomenclature) between the application 1C and an arbitrary application.
To solve this problem, you can write an extension that unloads the Nomenclature reference book into a file of a specific format (text, XML, JSON, ...) and can read this format.
The platform implements the mechanism of serialization of application objects in XML either directly, using global context methods Write XML / Reading XML, or using an auxiliary XDTO object (XML Data Transfer Objects).
Any object in the 1C: Enterprise system can be serialized into an XML representation and vice versa.
This function will return the representation of the object as XML:
This is how export of the Nomenclature to XML directory using XDTO will look like:
By a simple rework of the code, we export the reference in JSON. Items will be written to the array; For a change, here’s the English version of the syntax:
Then it remains only to transfer data to the end user. The 1C: Enterprise platform supports the main Internet protocols HTTP, FTP, POP3, SMTP, IMAP, including their secure versions. You can also use HTTP and / or Web services to transfer data.
1C applications can implement their HTTP and web services, as well as call HTTP and web services implemented by third-party applications.
Starting from version 8.3.5, the 1C: Enterprise platform can automatically form a REST interface for the entire application solution. Any configuration object (directory, document, register information, etc.) can be made available to obtain and modify data through the REST interface. The platform uses the OData protocol version 3.0 as an access protocol. Publishing OData services is done from the Administrator -> Publish to Web Server menu in the Configurator, the "Publish standard OData interface" checkbox should be marked. The atom / XML and JSON formats are supported. After the application is published on the web server, third-party systems can access it via the REST interface using HTTP requests. To work with the 1C application via the OData protocol, programming on the 1C side is not required.
So, a URL like http: // <server> / <configuration> /odata/standard.odata/Catalog_Name will return us the contents of the catalog Nomenclature in XML format - a collection of entry elements (the message header is omitted for brevity):
Adding the string “? $ Format = application / json” to the URL, we get the contents of the Nomenclature catalog in JSON format (URL of the form http: // <server> / <configuration> /odata/standard.odata/Catalog_Nomenclature?$format=application / json ):
In some cases, sharing data through external data sources may be the best solution. External data sources are a 1C configuration application object that allows you to interact with any ODBC-compatible database, both read and write. External data sources are available on both Windows and Linux.
The data exchange mechanism is intended both for creating geographically distributed systems based on 1C: Enterprise, and for organizing data exchange with other information systems that are not based on 1C: Enterprise.
This mechanism is actively used in 1C implementations, and the range of tasks solved with its help is very wide. This includes the exchange of data between 1C applications installed in the branches of the organization, the exchange between the 1C application and the online store site, and the exchange of data between the 1C server application and the mobile client (created using the 1C: Enterprise mobile platform), and much more.
One of the key concepts in the data exchange mechanism is the exchange plan. The exchange plan is a special type of object of the 1C application platform that determines, in particular, the composition of the data that will participate in the exchange (which directories, documents, registers, etc.). The exchange plan also contains information about the participants of the exchange (the so-called exchange nodes).
The second component of the data exchange mechanism is the change registration mechanism. This mechanism automatically tracks changes in the system data that must be transferred to end users in the framework of the exchange plan. Using this mechanism, the platform tracks changes that have occurred since the last synchronization and minimizes the amount of data transmitted during the next synchronization session.
Data exchange takes place using XML messages of a specific structure. The message contains data that has changed since the last synchronization with the node, and some service information. The message structure supports message numbering and allows you to receive confirmations from the receiving node about receiving messages. This confirmation is contained in each message coming from the recipient node, in the form of the number of the last received message. The numbering of messages allows the platform to understand which data has already been successfully transmitted to the receiving node, and to avoid retransmission by transmitting only data modified since the sending node received the last message with a receipt of data received by the receiving node. With such a scheme of work guaranteed delivery is guaranteed even with unreliable transmission channels and loss of messages.
In a number of cases, when solving integration problems, one has to face specific requirements, for example, interaction protocols, data formats that are not provided for in the 1C: Enterprise platform. For such a range of tasks, the platform provides the technology of external components , which allows you to create dynamically connected modules that extend the functionality of 1C: Enterprise.
A typical example of a task with similar requirements can be the integration of an 1C application solution with trading equipment, ranging from scales to cash registers and barcode scanners. External components can be connected both on the server side of 1C: Enterprise, and on the client side (including, among other things, the web client, as well as the next version of the 1C: Enterprise mobile platform ). The technology of external components provides a fairly simple and understandable software (C ++) interface for interacting with the 1C: Enterprise platform, which the developer must implement.
The possibilities offered by the use of external components are quite wide. You can implement interaction using a specific data exchange protocol with external devices and systems, embed specific data processing algorithms and data formats, etc.
Integration mechanisms are available in the platform that are not recommended for use in new solutions; they are left out of backward compatibility considerations, as well as in case the other party cannot work with more modern protocols. One of them is working with DBF files (supported in the embedded language using the XBase object).
Another outdated integration mechanism is the use of COM technology (available only on the Windows platform). The 1C: Enterprise platform provides two integration methods for Windows using COM technology: Automation server and External connection. They are very similar, but one of the principal differences is that in the case of an Automation server, a full-fledged 1C: Enterprise 8 client application is launched, and in the case of an external connection, a relatively small in-process COM server is launched. That is, if you work through the Automation server, you can enable the functionality of the client application, perform actions similar to the user's interactive actions. When using an external connection, you can only use business logic functions, and they can be performed both on the client side of the connection, where an out-of-process COM server is created, and to call the business logic on the 1C: Enterprise server side.
COM technology can also be used to access external systems from an application code on the 1C: Enterprise platform. In this case, the application 1C acts as a COM client. But it should be recalled that these mechanisms will work only if the 1C server operates in the Windows environment.
In a number of 1C configurations (list below), based on the platform data exchange mechanism described above, a ready-made data exchange mechanism with external applications is implemented that does not require changing the source code of configurations (preparation for data exchange is done in the settings of application solutions):
For data exchange, the EnterpriseData format is based on XML. The format is business-oriented — the data structures described in it correspond to business entities (documents and reference book elements) presented in 1C programs, for example: a certificate of completion, a cash receipt, a contractor, a nomenclature, etc.
Data exchange between the application 1C and a third-party application can occur:
In the case of sharing via a web service, a third-party application will initiate a data exchange session by calling the appropriate web methods of the 1C application. In other cases, the initiator of the exchange session will be the 1C application (by placing the data file in the appropriate directory or sending the data file to the configured mailing address).
Also on the 1C side, it is configured how often the synchronization will occur (for options with file exchange via the directory and email):
1C applications keep records of sent and received synchronization messages and expect the same from third-party applications. This allows you to use the message numbering mechanism, described above in the “Data exchange mechanism” section.
During synchronization, 1C applications transmit only information about changes that have occurred to business entities since the last synchronization (in order to minimize the amount of information transmitted). During the first synchronization, the 1C application will upload all business entities (for example, elements of the nomenclature reference book) in the EnterpriseData format into an XML file (since all of them are “new” for the external application). The third-party application should process the information from the XML file that came from 1C and place the next synchronization session into a file sent to 1C in a special XML section, informing that the message from 1C for a specific number was successfully received. The message-receipt is a signal to application 1C that all business entities have been successfully processed by an external application and that information about them is no longer needed. In addition to the receipt, an XML file from a third-party application may also contain data for synchronization by the application (for example, documents for the sale of goods and services).
After receiving the receipt message, the application 1C marks all changes sent in the previous message as successfully synchronized. Only unsynchronized changes in business entities (creation of new entities, modification and deletion of existing ones) will be sent to the external application during the next synchronization session.
When transferring data from an external application to the application 1C, the picture is reversed. The external application must fill out the receipt section in the XML file accordingly and place the business data for synchronization on its part in the EnterpriseData format.
For cases of simple integration, when it is enough just to transfer information from a third-party application to the 1C application and the return data transfer from the 1C application to the third-party application is not required (for example, integration of an online store that transfers sales information to 1C: Accounting), there is a simplified option to work through the web service (without handshaking), which does not require settings on the side of application 1C.
There is a typical solution “1C: Data Conversion”, which uses platform mechanisms for converting and exchanging data between typical 1C configurations, but can also be used for integration with third-party applications.
The “Client Bank” standard, developed by 1C specialists more than 10 years ago, actually became the industry standard in Russia. The next step in this direction is the DirectBank technology, which allows you to send payment documents to the bank and receive bank statements directly from the 1C: Enterprise system programs by pressing a single button in the 1C program; it does not require the installation and launch of additional programs on the client computer.
There is also a data exchange standard for payroll projects .
Mention should be made of the exchange protocol between the 1C: Enterprise system and the site , the CommerceML standard for the exchange of commercial information (developed jointly with Microsoft, Intel, Price.ru and other companies), the standard for the exchange of data on acquiring operations .
- The ease of changing / adapting the logic of the application to changing business problems.
- Easy integration with other applications.
How the first task is solved in 1C was briefly described in the “Customization and Support” section of this article ; we will return to this interesting topic in a future article. Today we will talk about the second task, about integration.
Integration tasks
Integration tasks may be different. To solve one, a simple interactive data exchange is enough - for example, to transfer a list of employees to a bank for processing payroll plastic cards. For more complex tasks, a fully automated data exchange may be necessary, possibly with reference to the business logic of the external system. There are tasks of a specialized nature, such as integration with external equipment (for example, trade equipment, mobile scanners, etc.) or with legacy or highly specialized systems (for example, with RFID tag recognition systems). It is extremely important for each task to choose the most appropriate integration mechanism.
Integration with 1C
There are various approaches to the implementation of integration with 1C applications, which one to choose depends on the requirements of the task.
')
- The implementation, based on the integration mechanisms provided by the platform, of its own specialized API on the 1C side (for example, a set of Web or HTTP services that third-party applications will exchange data with the 1C application). The advantage of this approach is the resilience of the API to the implementation change on the 1C side of the application. Feature of the approach - it is required to change the source code of the standard solution 1C, which can potentially require effort when merging source codes when switching to a new version of the configuration. In this case, new progressive functionality can come to the rescue - configuration extensions . Extensions are, in essence, a plug-in mechanism that allows you to create add-ons for applied solutions without changing the applied solutions themselves. The removal of the integration API into the configuration extension will allow you to avoid difficulties when merging configurations when switching to a new version of a typical solution.
- Using platform integration mechanisms that provide access to the application object model from the outside and do not require application refinement or extension creation. Plus this approach - no need to change the application 1C. Minus - if the application 1C was finalized, then you may need to refine the integrated application. An example of such an approach is the use of the OData protocol implemented on the side of the 1C: Enterprise platform (more about it below) for integration.
- The use of ready-made application protocols implemented in standard solutions 1C. Many typical solutions from 1C and partners implement, based on the integration mechanisms provided by the platform, their own application protocols, focused on specific tasks. When using these mechanisms, writing code on the side of application 1C is not required, since we use the standard capabilities of the application solution. On the 1C side of the application, we just need to make certain settings.
Integration mechanisms in the 1C: Enterprise platform
Import / Export Files
Suppose we are faced with the task of bidirectional data exchange between the application 1C and an arbitrary application. For example, we need to synchronize the list of goods (Reference Nomenclature) between the application 1C and an arbitrary application.
To solve this problem, you can write an extension that unloads the Nomenclature reference book into a file of a specific format (text, XML, JSON, ...) and can read this format.
The platform implements the mechanism of serialization of application objects in XML either directly, using global context methods Write XML / Reading XML, or using an auxiliary XDTO object (XML Data Transfer Objects).
Any object in the 1C: Enterprise system can be serialized into an XML representation and vice versa.
This function will return the representation of the object as XML:
__XML() XML = XML(); XML.(); XML(XML, ); XML.(); This is how export of the Nomenclature to XML directory using XDTO will look like:
& XML() XDTO = XDTO; XML = XML(); XML.("C:\Data\.xml", "UTF-8"); XML.XML(); XML.(""); = ..(); .() = .(); XDTO.XML(XML, , XML.); ; XML.(); XML.(); By a simple rework of the code, we export the reference in JSON. Items will be written to the array; For a change, here’s the English version of the syntax:
&AtServer Procedure ExportJSONOnServer() NewXDTOSerializer = XDTOSerializer; NewJSONWriter = New JSONWriter(); NewJSONWriter.OpenFile("C:\Data\.json", "UTF-8"); NewJSONWriter.WriteStartObject(); NewJSONWriter.WritePropertyName(""); NewJSONWriter.WriteStartArray(); Selection = Catalogs..Select(); While Selection.Next() Do NomenclatureObject = Selection.GetObject(); NewJSONWriter.WriteStartObject(); NewJSONWriter.WritePropertyName(""); NewXDTOSerializer.WriteJSON(NewJSONWriter, NomenclatureObject, XMLTypeAssignment.Implicit); NewJSONWriter.WriteEndObject(); EndDo; NewJSONWriter.WriteEndArray(); NewJSONWriter.WriteEndObject(); NewJSONWriter.Close(); EndProcedure Then it remains only to transfer data to the end user. The 1C: Enterprise platform supports the main Internet protocols HTTP, FTP, POP3, SMTP, IMAP, including their secure versions. You can also use HTTP and / or Web services to transfer data.
HTTP and web services
1C applications can implement their HTTP and web services, as well as call HTTP and web services implemented by third-party applications.
REST interface and OData protocol
Starting from version 8.3.5, the 1C: Enterprise platform can automatically form a REST interface for the entire application solution. Any configuration object (directory, document, register information, etc.) can be made available to obtain and modify data through the REST interface. The platform uses the OData protocol version 3.0 as an access protocol. Publishing OData services is done from the Administrator -> Publish to Web Server menu in the Configurator, the "Publish standard OData interface" checkbox should be marked. The atom / XML and JSON formats are supported. After the application is published on the web server, third-party systems can access it via the REST interface using HTTP requests. To work with the 1C application via the OData protocol, programming on the 1C side is not required.
So, a URL like http: // <server> / <configuration> /odata/standard.odata/Catalog_Name will return us the contents of the catalog Nomenclature in XML format - a collection of entry elements (the message header is omitted for brevity):
<entry> <id>http://server/Config/odata/standard.odata/Catalog_(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')</id> <category term="StandardODATA.Catalog_" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/> <title type="text"/> <updated>2016-06-06T16:42:17</updated> <author/> <summary/> <link rel="edit" href="Catalog_(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')" title="edit-link"/> <content type="application/xml"> <m:properties xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> <d:Ref_Key>35d1f6e4-289b-11e6-8ba4-e03f49b16074</d:Ref_Key> <d:DataVersion>AAAAAgAAAAA=</d:DataVersion> <d:DeletionMark>false</d:DeletionMark> <d:Code>000000001</d:Code> <d:Description> Mitsubishi</d:Description> <d:> 2,5 , : /</d:> </m:properties> </content> </entry> <entry> <id>http://server/Config/odata/standard.odata/Catalog_(guid'35d1f6e5-289b-11e6-8ba4-e03f49b16074')</id> <category term="StandardODATA.Catalog_" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/> ... Adding the string “? $ Format = application / json” to the URL, we get the contents of the Nomenclature catalog in JSON format (URL of the form http: // <server> / <configuration> /odata/standard.odata/Catalog_Nomenclature?$format=application / json ):
{ "odata.metadata": "http://server/Config/odata/standard.odata/$metadata#Catalog_", "value": [{ "Ref_Key": "35d1f6e4-289b-11e6-8ba4-e03f49b16074", "DataVersion": "AAAAAgAAAAA=", "DeletionMark": false, "Code": "000000001", "Description": " Mitsubishi", "": " 2,5 , : /" },{ "Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074", "DataVersion": "AAAAAwAAAAA=", "DeletionMark": false, "Code": "000000002", "Description": " Daikin", "": " 3 , : /" }, … External data sources
In some cases, sharing data through external data sources may be the best solution. External data sources are a 1C configuration application object that allows you to interact with any ODBC-compatible database, both read and write. External data sources are available on both Windows and Linux.
Data exchange mechanism
The data exchange mechanism is intended both for creating geographically distributed systems based on 1C: Enterprise, and for organizing data exchange with other information systems that are not based on 1C: Enterprise.
This mechanism is actively used in 1C implementations, and the range of tasks solved with its help is very wide. This includes the exchange of data between 1C applications installed in the branches of the organization, the exchange between the 1C application and the online store site, and the exchange of data between the 1C server application and the mobile client (created using the 1C: Enterprise mobile platform), and much more.
One of the key concepts in the data exchange mechanism is the exchange plan. The exchange plan is a special type of object of the 1C application platform that determines, in particular, the composition of the data that will participate in the exchange (which directories, documents, registers, etc.). The exchange plan also contains information about the participants of the exchange (the so-called exchange nodes).
The second component of the data exchange mechanism is the change registration mechanism. This mechanism automatically tracks changes in the system data that must be transferred to end users in the framework of the exchange plan. Using this mechanism, the platform tracks changes that have occurred since the last synchronization and minimizes the amount of data transmitted during the next synchronization session.
Data exchange takes place using XML messages of a specific structure. The message contains data that has changed since the last synchronization with the node, and some service information. The message structure supports message numbering and allows you to receive confirmations from the receiving node about receiving messages. This confirmation is contained in each message coming from the recipient node, in the form of the number of the last received message. The numbering of messages allows the platform to understand which data has already been successfully transmitted to the receiving node, and to avoid retransmission by transmitting only data modified since the sending node received the last message with a receipt of data received by the receiving node. With such a scheme of work guaranteed delivery is guaranteed even with unreliable transmission channels and loss of messages.
External components
In a number of cases, when solving integration problems, one has to face specific requirements, for example, interaction protocols, data formats that are not provided for in the 1C: Enterprise platform. For such a range of tasks, the platform provides the technology of external components , which allows you to create dynamically connected modules that extend the functionality of 1C: Enterprise.
A typical example of a task with similar requirements can be the integration of an 1C application solution with trading equipment, ranging from scales to cash registers and barcode scanners. External components can be connected both on the server side of 1C: Enterprise, and on the client side (including, among other things, the web client, as well as the next version of the 1C: Enterprise mobile platform ). The technology of external components provides a fairly simple and understandable software (C ++) interface for interacting with the 1C: Enterprise platform, which the developer must implement.
The possibilities offered by the use of external components are quite wide. You can implement interaction using a specific data exchange protocol with external devices and systems, embed specific data processing algorithms and data formats, etc.
Outdated integration mechanisms
Integration mechanisms are available in the platform that are not recommended for use in new solutions; they are left out of backward compatibility considerations, as well as in case the other party cannot work with more modern protocols. One of them is working with DBF files (supported in the embedded language using the XBase object).
Another outdated integration mechanism is the use of COM technology (available only on the Windows platform). The 1C: Enterprise platform provides two integration methods for Windows using COM technology: Automation server and External connection. They are very similar, but one of the principal differences is that in the case of an Automation server, a full-fledged 1C: Enterprise 8 client application is launched, and in the case of an external connection, a relatively small in-process COM server is launched. That is, if you work through the Automation server, you can enable the functionality of the client application, perform actions similar to the user's interactive actions. When using an external connection, you can only use business logic functions, and they can be performed both on the client side of the connection, where an out-of-process COM server is created, and to call the business logic on the 1C: Enterprise server side.
COM technology can also be used to access external systems from an application code on the 1C: Enterprise platform. In this case, the application 1C acts as a COM client. But it should be recalled that these mechanisms will work only if the 1C server operates in the Windows environment.
Integration mechanisms implemented in typical configurations
EnterpriseData format
In a number of 1C configurations (list below), based on the platform data exchange mechanism described above, a ready-made data exchange mechanism with external applications is implemented that does not require changing the source code of configurations (preparation for data exchange is done in the settings of application solutions):
- "1C: ERP Enterprise Management 2.0"
- "Integrated Automation 2"
- "Enterprise Accounting", edition 3.0
- "Accounting Enterprise Corp." edition 3.0
- "Retail", edition 2.0
- Basic Trading Management, edition 11
- “Trade Management”, edition 11
- “Salary and personnel management of KORP”, edition 3
For data exchange, the EnterpriseData format is based on XML. The format is business-oriented — the data structures described in it correspond to business entities (documents and reference book elements) presented in 1C programs, for example: a certificate of completion, a cash receipt, a contractor, a nomenclature, etc.
Data exchange between the application 1C and a third-party application can occur:
- through the selected file directory
- via FTP directory
- through a web service deployed on the side of application 1C. The data file is passed as a parameter to the web methods.
- via email
In the case of sharing via a web service, a third-party application will initiate a data exchange session by calling the appropriate web methods of the 1C application. In other cases, the initiator of the exchange session will be the 1C application (by placing the data file in the appropriate directory or sending the data file to the configured mailing address).
Also on the 1C side, it is configured how often the synchronization will occur (for options with file exchange via the directory and email):
- according to the schedule (with the specified frequency)
- manually; the user will have to manually start synchronization every time he needs it
Message handshaking
1C applications keep records of sent and received synchronization messages and expect the same from third-party applications. This allows you to use the message numbering mechanism, described above in the “Data exchange mechanism” section.
During synchronization, 1C applications transmit only information about changes that have occurred to business entities since the last synchronization (in order to minimize the amount of information transmitted). During the first synchronization, the 1C application will upload all business entities (for example, elements of the nomenclature reference book) in the EnterpriseData format into an XML file (since all of them are “new” for the external application). The third-party application should process the information from the XML file that came from 1C and place the next synchronization session into a file sent to 1C in a special XML section, informing that the message from 1C for a specific number was successfully received. The message-receipt is a signal to application 1C that all business entities have been successfully processed by an external application and that information about them is no longer needed. In addition to the receipt, an XML file from a third-party application may also contain data for synchronization by the application (for example, documents for the sale of goods and services).
After receiving the receipt message, the application 1C marks all changes sent in the previous message as successfully synchronized. Only unsynchronized changes in business entities (creation of new entities, modification and deletion of existing ones) will be sent to the external application during the next synchronization session.
When transferring data from an external application to the application 1C, the picture is reversed. The external application must fill out the receipt section in the XML file accordingly and place the business data for synchronization on its part in the EnterpriseData format.
Simplified data exchange without handshaking
For cases of simple integration, when it is enough just to transfer information from a third-party application to the 1C application and the return data transfer from the 1C application to the third-party application is not required (for example, integration of an online store that transfers sales information to 1C: Accounting), there is a simplified option to work through the web service (without handshaking), which does not require settings on the side of application 1C.
Specialized integration solutions
There is a typical solution “1C: Data Conversion”, which uses platform mechanisms for converting and exchanging data between typical 1C configurations, but can also be used for integration with third-party applications.
Integration with banking solutions
The “Client Bank” standard, developed by 1C specialists more than 10 years ago, actually became the industry standard in Russia. The next step in this direction is the DirectBank technology, which allows you to send payment documents to the bank and receive bank statements directly from the 1C: Enterprise system programs by pressing a single button in the 1C program; it does not require the installation and launch of additional programs on the client computer.
There is also a data exchange standard for payroll projects .
Other
Mention should be made of the exchange protocol between the 1C: Enterprise system and the site , the CommerceML standard for the exchange of commercial information (developed jointly with Microsoft, Intel, Price.ru and other companies), the standard for the exchange of data on acquiring operations .
Source: https://habr.com/ru/post/308420/
All Articles