What are the most essential requirements for business applications? The following tasks are among the most important ones:
- Ease of modification/adaptation of application logic for/to changing business objectives.
- Ease of integration with other applications.
Integration tasks
Integration tasks can be different. To solve some of them, all you need to do is just perform an interactive exchange of data - for example, to send a list of employees to a bank in order to process payroll cards. More complex tasks may require a fully automated data exchange, possibly involving the business logic of the external system. There are tasks that are specialized, such as integration with external equipment (for example, retail equipment, mobile scanners, etc.), or with legacy or highly specialized systems (for example, RFID tag recognition systems). It is essential to choose the most suitable integration method for each task.
Options for integration with 1C:Enterprise applications
There are various approaches to the implementation of integration with 1C:Enterprise applications, the choice of which depends on the requirements of a particular task.
- Implementation of a proprietary specialized API based on the provided by the platform (for example, a set of web or HTTP services that will launch third-party applications to exchange data with 1C:Enterprise application). The advantage of this approach is API stability in regards to implementation changes on the side of 1C:Enterprise application. This approach is peculiar in the sense that it requires to change the source code of the standard 1C:Enterprise-based solution, which can potentially require efforts when merging source codes for upgrading to a new version of the configuration. In this case, you may take advantage of a new progressive functionality - . Extensions are essentially a plug-in mechanism that allows you to create application add-ons, without changing the applications themselves. Moving the integration API to the configuration extension will allow you to avoid difficulties when merging configurations for upgrading to a new version of the standard solution.
- Using platform integration mechanisms that provide access to an object model of the application from outside and do not require adaptation of the application or creating of an extension. The advantage of this approach is that you do not need to modify the 1C:Enterprise application. The downside is that if the 1C:Enterprise application was modified, it may be necessary to adapt the application, which is being integrated. An example of this approach is the use of the OData protocol implemented on the side of 1C:Enterprise platform for the purposes of integration (read more about it below).
- Using ready application protocols that are implemented in standard 1C:Enterprise solutions. Many standard solutions from 1C Company and their partners implement their own task-oriented application protocols based on integration mechanisms provided by the platform. When using these mechanisms, it is not necessary to write the code on the side of 1C:Enterprise application, since we utilize the in-house capabilities of the application. We only need to comply with certain settings on the side of 1C:Enterprise application.
Integration mechanisms implemented in 1C:Enterprise platform
Importing/exporting filesLet us suppose we are faced with the challenge of a two-way exchange of data between a 1C:Enterprise application and an arbitrary application. For example, we need to synchronize a product list (Products catalog) between a 1C:Enterprise application and an arbitrary application.
To solve this task, you can write an extension that exports the Products catalog into a file of specific format (text, XML, JSON, etc.) and that is able to read this format.
The platform provides for the application object serialization mechanism in XML format both directly, using ReadXML and WriteXML global context methods, as well as with the help of XDTO subsidiary object (XML Data Transfer Objects).
Any object in 1C:Enterprise system can be serialized to XML format and vice versa.
This function returns the XML representation of an object:
Function Object_To_XML(Object) XMLWriter = New XMLWriter(); XMLWriter.SetString(); WriteXML(XMLWriter, Object); Return XMLWriter.Close(); EndFunction |
&AtServer
Procedure ExportToXMLAtServer()
NewXDTOSerializer = XDTOSerializer;
NewXMLWriter = New XMLWriter();
NewXMLWriter.OpenFile("C:\Data\Products.xml", "UTF-8");
NewXMLWriter.WriteXMLDeclaration();
NewXMLWriter.WriteStartElement("CatalogProducts");
Selection = Catalogs.Products.Select();
While Selection.Next() Do
ProductsObject = Selection.GetObject();
NewXDTOSerializer.WriteXML(NewXMLWriter, ProductsObject, XMLTypeAssignment.Explicit);
EndDo;
NewXMLWriter.WriteEndElement();
NewXMLWriter.Close();
EndProcedure
|
&AtServer
Procedure ExportJSONAtServer()
NewXDTOSerializer = XDTOSerializer;
NewJSONWriter = New JSONWriter();
NewJSONWriter.OpenFile("C:\Data\Ptoducts.json", "UTF-8");
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("CatalogProducts");
NewJSONWriter.WriteStartArray();
Selection = Catalogs.Products.Select();
While Selection.Next() Do
ProductsObject = Selection.GetObject();
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("Product");
NewXDTOSerializer.WriteJSON(NewJSONWriter, ProductObject, XMLTypeAssignment.Implicit);
NewJSONWriter.WriteEndObject();
EndDo;
NewJSONWriter.WriteEndArray();
NewJSONWriter.WriteEndObject();
NewJSONWriter.Close();
EndProcedure
|
HTTP and web services
1C:Enterprise applications can include proprietary implementations of 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, 1C:Enterprise platform can automatically for the entire application. For each configuration object (catalog, document, information register, etc.) you can allow modification based on data obtained via the REST interface. The platform uses version 3.0 of as its access protocol. To publish OData services, in Designer, on the Administration menu, click Publish to the web server and select the Publish standard OData interface checkbox. Atom/XML and JSON formats are supported. After the application is published to a web server, third-party systems can access it via the REST interface using HTTP requests. Programming on the side of the 1C:Enterprise application is not required for working with the 1C:Enterprise application via OData protocol.
Thus, the URL of the type http://<server>/<configuration>/odata/standard.odata/Catalog_Products will return the contents of the Products catalog in XML format - a collection of entry elements (header is omitted for brevity):
<entry> <id>http://server/Config/odata/standard.odata/Catalog_Products(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')</id> <category term="StandardODATA.Catalog_Products" 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_Products(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 AC</d:Description> <d:Full_Description>Power 2.5 kW, operating modes: heat/cold</d:Full_Description> </m:properties> </content> </entry> <entry> <id>http://server/Config/odata/standard.odata/Catalog_Products(guid'35d1f6e5-289b-11e6-8ba4-e03f49b16074')</id> <category term="StandardODATA.Catalog_Products" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/> ... |
{
"odata.metadata": "http://server/Config/odata/standard.odata/$metadata#Catalog_Products",
"value": [{
"Ref_Key": "35d1f6e4-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAgAAAAA=",
"DeletionMark": false,
"Code": "000000001",
"Description": "Mitsubishi AC",
"Full_Description": "Power 2.5 kW, operating modes: heat/cold"
},{
"Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAwAAAAA=",
"DeletionMark": false,
"Code": "000000002",
"Description": "Daikin AC",
"Full_Description": "Power 3 kW, operating modes: heat/cold"
}, …
|
External data sources
In some cases, exchanging data through external data sources may be the optimal solution. External data sources are applied objects of 1C:Enterprise configurations that allow you to interact with any ODBC-compatible database for the purposes of reading and writing. External data sources are available for both Windows and Linux.
Data exchange
A data exchange mechanism is intended for the creation of geographically distributed systems based on 1C:Enterprise, as well as for exchanging data with other information systems that are not based on 1C:Enterprise.
This mechanism is widely used for 1C:Enterprise integrations and the range of tasks that it can help accomplish is very extensive. It includes data exchange between 1C:Enterprise applications installed in branches of the organization, exchange between 1C:Enterprise application and an online store website, exchange of data between 1C:Enterprise server application and mobile client (created with 1C:Enterprise mobile platform), and much more.
One of the key concepts in the mechanism of data exchange is an exchange plan. An exchange plan is a special type of an applied object available in 1C:Enterprise platform that determines, in particular, the data, which will be included in the exchange (which catalogs, documents, registers, etc.). An exchange plan also contains information about participants of the exchange (so-called exchange plan nodes).
The second component of the data exchange mechanism is a change registration mechanism. This mechanism automatically tracks data changes in the system that should be transferred to end users according to the exchange plan. The platform uses this mechanism to track changes that occurred since the last synchronization and minimizes the amount of data transferred during the next synchronization session.
The data are exchanged using XML messages of a particular structure. The message contains data that changed since the last synchronization with the node, as well as some service information. The message structure supports the numbering of messages and allows the sender node to receive confirmations from the recipient node when a message is received. Such confirmation is included in each message coming from the recipient node as the number of the last received message. The numbering of messages allows the platform to determine, which data were already successfully transferred to the recipient node, and to avoid repeat transmission by only transferring the data that changed since the recipient node received the last message with a receipt confirmation. This operational procedure ensures guaranteed delivery even for unreliable transmission channels and for when messages are lost.
Add-ins
When completing some integration tasks, you can be faced with specific requirements, such as interaction protocols or data formats that are not available on 1C:Enterprise platform. For such tasks, the platform provides for , which allows you to create dynamically attached modules that extend the functionality of 1С:Enterprise.
A typical example of a task with such requirements is the integration of a 1C:Enterprise application with retail equipment, ranging from scales to cash registers and barcode scanners. Add-ins can be attached on the 1C:Enterprise server, as well as on the client (including a web client, as well as ). The add-in technology provides a fairly simple and intuitive programming (C++) interface of add-in interaction with 1C:Enterprise platform, which must be implemented by the developer.
Opportunities that become available when using add-ins are quite extensive. You can implement integration according to a specific protocol of data exchange with external devices and systems, incorporate specific data processing and format algorithms, etc.
Legacy integration mechanisms
The platform includes integration mechanisms that are not recommended for use in new solutions; they were left for the sake of backward compatibility, as well as for cases when the other party cannot work with more modern protocols. One of such cases is working with DBF files (supported in 1C:Enterprise script using the XBase object).
Another legacy integration mechanism is the usage of the COM technology (available only on the Windows platform). 1C:Enterprise platform provides for two ways of integration for Windows that use the COM technology: Automation server and external connection. They are very similar, but one of the main differences is that for the Automation server, full 1C:Enterprise client application is launched, and for external connection, a relatively small in-process COM server is initiated. If you are working via the Automation server, you can take advantage of the client application functionality to perform actions similar to the interactive actions of the user. When you use an external connection, you can only take advantage of the business logic functions, which can be implemented on the client-side of the connection, where the in-process COM server is created; you can also run business logic functions on the side of 1C:Enterprise server.
COM technology also can be used to connect to external systems from 1C:Enterprise application code. In this case, 1C:Enterprise application acts as a COM client. Please remember that these mechanisms will only work if the 1C:Enterprise server operates in the Windows environment.
Integration mechanisms in 1C:Enterprise applications
EnterpriseData format
Based on the above platform data exchange mechanism, you can implement a mechanism for data exchange with external applications that do not require any changes to the source code of configurations (preparations for the exchange are done in application settings). It uses EnterpriseData format based on XML. The format is business-oriented - data structures described in it correspond to business entities (documents and catalog items) available in 1C:Enterprise applications, for example, certificate of completion, cash receipt, counterparty, products, etc.
Exchange of data between 1C:Enterprise application and a third-party application can be implemented:
- Through a dedicated file directory.
- Through an FTP directory.
- Through a web service deployed on the side of 1C:Enterprise application. The data file is transferred as a web method parameter.
- Via email.
The synchronization period (for versions with file exchange through the directory and email) is also configured on the side of 1C:Enterprise application:
- Use schedule (with a specified period)
- Synchronize manually (the user must manually start synchronization whenever it is needed)
1C:Enterprise applications keep records of sent and received synchronization messages and expect the same from third-party applications. This allows you to involve the message numbering mechanism described above in the "Data exchange" section.
During synchronization, 1C:Enterprise applications only transfer information about changes that occurred to business entities since the last synchronization (to minimize the amount of transferred data). During the first synchronization, 1C:Enterprise application exports all business entities (such as product catalog items) in EnterpriseData format to an XML file (because they are all "new" for the external application). The third-party application must process information from the XML file that came from the 1C:Enterprise application and during the next synchronization session, place the information that the message from 1C:Enterprise application with the specific number was successfully accepted into the file sent to 1C:Enterprise application, in the special XML section. The receipt message is a signal for the 1C:Enterprise application, which means that all business entities are processed successfully by an external application and that information about them should no longer be transferred. In addition to the receipt, the XML file from a third-party application can also include data for synchronization that comes from the application side (for example, documents for sales of goods and services).
After receiving the receipt message, 1C:Enterprise application marks all changes that were transferred in the previous message as successfully synchronized. Only changes that were not synchronized in business entities (creation of new entities, changing or deleting existing ones) will be sent to the external application during the next synchronization session.
When data is transferred from the external application to the 1C:Enterprise application, the process is reversed. The external application must complete the receipt section in the XML file accordingly and place business data for synchronization on their side in EnterpriseData format.
Simplified data exchange without acknowledgment
For cases of simple integration, when it is enough only to transfer information from a third-party application to 1C:Enterprise application and when reverse data transfer from 1C:Enterprise application to a third-party application is not required (for example, integration of an online store sending sales information to an accounting application), there is a simplified version for working via a web service (without acknowledgment), which does not require configuration on the side of 1C:Enterprise application.
