What are the most important requirements for business applications? Some of the most important tasks are:
- Ease of changing / adapting the application logic to changing business tasks.
- Ease of integration with other applications.
How the first task is solved in 1C was briefly described in the "Customization and Support" section. ; 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 can be different. To solve some, a simple interactive data exchange is enough - for example, to transfer a list of employees to the bank for issuing payroll plastic cards. For more complex tasks, fully automated data exchange may be necessary, possibly with reference to the business logic of an external system. There are tasks that are specialized in nature, such as integration with external equipment (for example, vending equipment, mobile scanners, etc.) or with legacy or highly specialized systems (for example, RFID recognition systems). It is extremely important for each task to choose the most appropriate integration mechanism.
Possibilities of integration with 1C
There are various approaches to implementing integration with 1C applications, which one to choose depends on the requirements of the task.
- Implementation based provided by the platform, its own specialized API on the side of the 1C application (for example, a set of Web or HTTP services that will call third-party applications to exchange data with the 1C application). The advantage of this approach is the resistance of the API to changes in the implementation on the side of the 1C application. A feature of the approach is that it is required to change the source code of a typical 1C solution, which may potentially require efforts when merging source codes when switching to a new version of the configuration. In this case, a new progressive functionality can come to the rescue − . Extensions are, in fact, a plugin mechanism that allows you to create additions to application solutions without changing the application solutions themselves. Removing the integration API to the configuration extension will allow you to avoid difficulties when merging configurations when switching to a new version of a standard solution.
- Using platform integration mechanisms that provide external access to the application object model and do not require application development or extension creation. The advantage of this approach is that there is no need to change the 1C application. Minus - if the 1C application has been finalized, then improvements may be required in the integrated application. An example of such an approach is the use of the OData protocol for integration, implemented on the side of the 1C:Enterprise platform (more about it below).
- Use of ready-made application protocols implemented in standard 1C solutions. Many standard solutions from 1C and partners implement their own task-oriented application protocols based on the integration mechanisms provided by the platform. When using these mechanisms, it is not required to write code on the side of the 1C application, because we use the standard capabilities of the applied solution. On the side of the 1C application, we only 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 a 1C application and an arbitrary application. For example, we need to synchronize the list of goods (Nomenclature directory) between the 1C application and an arbitrary application.
To solve such a problem, you can write an extension that unloads the Nomenclature reference book into a file of a certain format (text, XML, JSON, ...) and can read this format.
The platform implements a mechanism for serializing application objects to XML both directly, through the global context methods WriteXML/ReadXML, and with the help of 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 an XML representation of the object:
Функция Объект_В_XML(Объект)
ЗаписьXML = Новый ЗаписьXML();
ЗаписьXML.УстановитьСтроку();
ЗаписатьXML(ЗаписьXML, Объект);
Возврат ЗаписьXML.Закрыть();
КонецФункции
this is how the export of the Nomenclature reference book to XML 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 modification of the code, we export the directory to JSON. Products will be written to an array; For a change, here is 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 the 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 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 for the entire application solution. Any configuration object (reference book, document, information register, etc.) can be made available for receiving and modifying data via the REST interface. The platform uses the protocol as an access protocol. version 3.0. Publishing OData services is performed from the Configurator menu "Administration -> Publishing to a web server", the checkbox "Publish standard OData interface" must be checked. Atom/XML and JSON formats are supported. After the applied solution is published on the web server, third-party systems can access it through the REST interface using HTTP requests. To work with the 1C application through the OData protocol, programming on the 1C side is not required.
So, the URL of the form http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура will return the contents of the Nomenclature directory in XML format - a collection of entry elements (the message title 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 >
<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 directory in JSON format (URL like http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура?$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, communication through may be the best solution. External data sources is a 1C configuration application object that allows you to interact with any ODBC-compatible database both for reading and writing. External data sources are available on both Windows and Linux.
Data exchange mechanism
is intended both for creating geographically distributed systems based on 1C:Enterprise and for organizing data exchange with other information systems 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, and the exchange between the 1C application and the website of the online store, 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. An exchange plan is a special type of 1C application platform object, which 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 exchange participants (the so-called exchange nodes).
The second component of the data exchange mechanism is the change registration mechanism. This mechanism automatically keeps track in the system of data changes that must be transferred to end users as part of the exchange plan. Using this mechanism, the platform keeps track of changes that have occurred since the last synchronization and allows you to minimize the amount of data transferred during the next synchronization session.
Data is exchanged using XML messages of a certain 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 confirmation from the receiving node about the receipt of messages. Such an acknowledgment is contained in each message coming from the receiving node, in the form of the number of the last received message. Message numbering allows the platform to understand what data has already been successfully transmitted to the receiving node and avoid retransmission by transmitting only data that has changed since the sending node received the last message with a receipt of data received by the receiving node. With this scheme of work, guaranteed delivery is ensured even with unreliable transmission channels and loss of messages.
External Components
In some cases, when solving integration problems, one has to deal with 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 , which allows you to create dynamically connected modules that extend the functionality of 1C:Enterprise.
A typical example of a task with similar requirements is the integration of a 1C application solution with commercial equipment, from scales to cash registers and barcode scanners. External components can be connected both on the 1C:Enterprise server side and on the client side (including, but not limited to, the web client, as well as 1C:Enterprise). The technology of external components provides for a fairly simple and understandable programming (C++) interface for the interaction of a component with the 1C:Enterprise platform, which must be implemented by the developer.
The possibilities that open up when using external components are very wide. You can implement interaction using a specific data exchange protocol with external devices and systems, build in specific data processing algorithms and data formats, etc.
Legacy Integration Mechanisms
Integration mechanisms are available in the platform, which are not recommended for use in new solutions; they are left for reasons of backward compatibility, and also in case the other party cannot work with more modern protocols. One of them is working with DBF format files (supported in the XNUMXC:Enterprise language using the XBase object).
Another legacy integration mechanism is the use of COM technology (only available 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 fundamental 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, in the case of working through the Automation server, you can use the functionality of the client application, perform actions similar to interactive user actions. When using an external connection, you can use only business logic functions, and they can be executed both on the client side of the connection, where an in-process COM server is created, and to call business logic on the 1C:Enterprise server side.
Also, COM technology can be used to access external systems from the application code on the 1C:Enterprise platform. In this case, the 1C application acts as a COM client. But it should be recalled that these mechanisms will only work if the 1C server operates in a Windows environment.
Integration mechanisms implemented in typical configurations
EnterpriseData Format
In a number of 1C configurations (the list below), based on the platform data exchange mechanism described above, a ready-made mechanism for data exchange with external applications is implemented that does not require changes in the configuration source code (preparation for data exchange is done in the settings of application solutions):
- "1C:ERP Enterprise Management 2.0"
- "Integrated Automation 2"
- "Accounting of the enterprise", edition 3.0
- "Accounting department of the enterprise KORP", edition 3.0
- "Retail", edition 2.0
- "Basic trade management", edition 11
- "Trade Management", edition 11
- "Salary and personnel management CORP", edition 3
The format used for data exchange is , based on XML. The format is business-oriented - the data structures described in it correspond to business entities (documents and directory elements) presented in 1C programs, for example: act of work performed, cash receipt order, counterparty, nomenclature, etc.
Data exchange between the 1C application and a third-party application can occur:
- through a dedicated file directory
- via FTP directory
- through a web service deployed on the side of the 1C application. Data file is passed as parameter of web methods
- via email
In the case of an exchange through 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 exchange session will be initiated by the 1C application (by placing the data file in the appropriate directory or sending the data file to the configured postal address).
Also, on the 1C side, it is configured how often synchronization will occur (for options with file exchange via catalog and e-mail):
- according to the schedule (with a given frequency)
- manually; the user will have to manually start the synchronization every time he needs it
Message acknowledgment
1C applications keep a record 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 (to minimize the amount of information transferred). During the first synchronization, the 1C application will upload all business entities (for example, items reference book items) in the EnterpriseData format to an XML file (since they are all “new” for an external application). A third-party application must process the information from the XML file that came from 1C and, at the next synchronization session, place in the file sent to 1C, in a special XML section, information that a message from 1C with a certain number was successfully received. The receipt message is a signal for the 1C application that all business entities have been successfully processed by an external application and information about them no longer needs to be transmitted. In addition to the receipt, the XML file from a third-party application can also contain data for synchronization from the application (for example, documents for the sale of goods and services).
After receiving the receipt message, the 1C application marks all the changes transmitted 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 data is transferred from an external application to the 1C application, the picture changes to the opposite. The external application must fill in the receipt section in the XML file appropriately and place the business data for synchronization from its side in the EnterpriseData format.
Simplified data exchange without handshaking
For cases of simple integration, when it is enough only to transfer information from a third-party application to a 1C application and a reverse transfer of data from a 1C application to a third-party application is not required (for example, integration of an online store that transmits sales information to 1C: Accounting), there is a simplified a variant of working through a web service (without handshaking), which does not require settings on the side of the 1C application.
Specialized Integration Solutions
There is a standard 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
Standard , developed by 1C specialists more than 10 years ago, has actually become the industry standard in Russia. The next step in this direction is technology , which allows you to send payment documents to the bank and receive bank statements directly from the programs of the 1C:Enterprise system by pressing a single button in the 1C program; it does not require installation and launch of additional programs on the client computer.
There are also .
Other
Worth a mention , commercial information exchange standard (developed jointly with Microsoft, Intel, Price.ru and other companies), .
Source: habr.com