Methods of Integration with 1C

What are the key requirements for business applications? Some of the most important include the following tasks:

• Ease of changing/adapting the application's operation logic to changing business tasks.
• Ease of integration with other applications.

The way the first task is addressed in 1C was briefly described in the section ‘Customization and Support’ of this article; we will return to this interesting topic in one of our future articles. Today, however, we will discuss the second task, integration.

Integration Tasks

Integration tasks can vary. For some, a simple interactive data exchange is sufficient — for example, sending a list of employees to the bank for processing payroll plastic cards. For more complex tasks, a fully automated data exchange may be necessary, possibly involving interaction with the business logic of an external system. There are tasks with a specialized nature, such as integration with external hardware (e.g., trade equipment, mobile scanners, etc.) or with legacy or niche systems (e.g., RFID tag recognition systems). It is crucial to select the most suitable integration mechanism for each task.

Integration Opportunities with 1C

There are various approaches to implementing integration with 1C applications; which one to choose depends on the requirements of the task.

1. Implementation based on integration mechanisms, provided by the platform, or its own specialized API on the 1C application side (e.g., a set of Web or HTTP services that third-party applications will call to exchange data with the 1C application). The advantage of this approach is the API's resilience to changes in the implementation on the 1C application side. A characteristic of this approach is that it requires changing the source code of the standard 1C solution, which may potentially require effort when merging source codes upon transitioning to a new version of the configuration. In this case, new progressive functionality may come to the rescue - configuration extensionsExtensions are essentially plugin mechanisms that allow for the creation of add-ons for application solutions without altering the original applications. Moving the integration API to the configuration extension will prevent complications when merging configurations during an upgrade to a new version of the standard solution.
2. Utilizing the integration mechanisms of the platform, which provide external access to the application's object model and do not require modifications to the application or the creation of an extension. The advantage of this approach is that there is no need to change the 1C application. The downside is that if the 1C application has been modified, it may require adjustments in the integrated application. An example of this approach is using the OData protocol for integration, implemented on the 1C:Enterprise platform (more details below).
3. Using готовые application protocols implemented in 1C standard solutions. Many standard solutions from 1C and its partners create their own application protocols based on the integration mechanisms provided by the platform, tailored to specific tasks. When using these mechanisms, no coding is required on the 1C application side, as we utilize the built-in capabilities of the application solution. On the 1C application side, we only need to make certain configurations.

Integration mechanisms in the 1C:Enterprise platform

File import/export

Suppose we have a task of bidirectional data exchange between the 1C application and an arbitrary application. For example, we need to synchronize the product list (the Nomenclature reference) between the 1C application and an arbitrary application.

To tackle this task, we can write an extension that exports the Nomenclature reference to a file in a specific format (text, XML, JSON, etc.) and is capable of reading this format.

The platform implements a mechanism for serializing application objects to XML both directly, via the global context methods WriteXML/ReadXML, and using a helper object XDTO (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 object's representation in XML format:

Function Object_In_XML(Object)
    XMLRecord = New XMLRecord();
    XMLRecord.SetString();
    WriteXML(XMLRecord, Object);
    Return XMLRecord.Close();
EndFunction

This is how the export of the Catalog Nomenclature to XML using XDTO would look:

&OnServer
Procedure ExportXMLOnServer()
	NewXDTOSerializer = XDTOSerializer;
	NewXMLRecord = New XMLRecord();
	NewXMLRecord.OpenFile("C:DataNomenclature.xml", "UTF-8");
	
	NewXMLRecord.WriteXMLAnnouncement();
	NewXMLRecord.WriteStartElement("CatalogNomenclature");
	
	Selection = Catalogs.Nomenclature.Select();
	
	While Selection.Next() Loop
		NomenclatureObject = Selection.GetObject();
		NewXDTOSerializer.WriteXML(NewXMLRecord, NomenclatureObject, XMLTypeAssignment.Explicit);
	EndLoop;
	
	NewXMLRecord.WriteEndElement();
	NewXMLRecord.Close();
EndProcedure

By slightly modifying the code, we export the catalog to JSON. The products will be recorded in an array; for variety, here’s an English syntax variant:

&AtServer
Procedure ExportJSONOnServer()
	NewXDTOSerializer = XDTOSerializer;
	NewJSONWriter = New JSONWriter();
	NewJSONWriter.OpenFile("C:DataNomenclature.json", "UTF-8");
	
	NewJSONWriter.WriteStartObject();
	NewJSONWriter.WritePropertyName("CatalogNomenclature");
	NewJSONWriter.WriteStartArray();
	
	Selection = Catalogs.Nomenclature.Select();
	
	While Selection.Next() Do
		NomenclatureObject = Selection.GetObject();
		
		NewJSONWriter.WriteStartObject();
		
		NewJSONWriter.WritePropertyName("Nomenclature");
		NewXDTOSerializer.WriteJSON(NewJSONWriter, NomenclatureObject, XMLTypeAssignment.Implicit);
		
		NewJSONWriter.WriteEndObject();
	EndDo;
	
	NewJSONWriter.WriteEndArray();
	NewJSONWriter.WriteEndObject();
	NewJSONWriter.Close();
EndProcedure

Next, we just need to transfer the data to the end consumer. The 1C:Enterprise platform supports the main internet protocols HTTP, FTP, POP3, SMTP, IMAP, including their secure versions. Data can also be transmitted using HTTP and/or Web services.

HTTP and web services

1C applications can implement their own 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 generate a REST interface for the entire application solution. Any configuration object (catalog, document, information register, etc.) can be made available for data retrieval and modification through the REST interface. The platform uses the protocol OData version 3.0. Publishing OData services is done from the Configuration menu "Administration -> Publishing on the Web Server"; the checkbox "Publish standard OData interface" must be checked. Formats atom/XML and JSON are supported. Once the application is published on the web server, external systems can access it via the REST interface using HTTP requests. No programming on the 1C side is required to work with the application via the OData protocol.

Thus, a URL of the form http:////odata/standard.odata/Catalog_Products will return the contents of the Products catalog in XML format — a collection of entry elements (the message header is omitted for brevity):

http://server/Config/odata/standard.odata/Catalog_Products(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')