Proper Integration of 1C with Other Systems

The storage system in any 1C application is built as a complex, multi-layered database. It defines data relationships and dependencies, and their links to objects at a high level of abstraction. However, in our experience, companies very rarely use 1C in the same form and configuration that is initially delivered to the user out of the box.

Each company customizes its systems to fit its own business processes, organizational structure, products, and so on.

As a result, the data structure becomes even more specific and unique.

As long as all of this runs inside a single system, there are no problems.

But if you need to integrate 1C with other systems, the specifics of how information is stored make the task more complex.

This determines which development team will build and revise the integration and which system will bear the load.

- in EnterpriseData (XML-based), while Axapta, for example, also uses XML, but in plain form.

Which exact data needs to be pulled and sent?

As a rule, the receiving system does not need everything everywhere all at once, only specific fields or records for a certain time period.

You need to identify which fields they are, separate them from the overall data set, and route them into the appropriate receiver slots.

If the color reference list in 1C:Retail does not yet contain the value "red," it will be impossible to save such data.

All of this must be taken into account at the initial integration development stage. 1C regularly releases updates and refreshes its product code.

The data structure you built your integration for may become outdated after any update.

Field names will change, some fields will split into two or merge into one. And all integrations related to 1C will have to be reworked to match the new conditions.

Changes can also happen on the side of the second system involved in the data exchange, and the integration will have to be changed again.

The first, and in practice the preferable, option for implementing direct integrations is to use the universal OData protocol (short for open data protocol). 1C products, in particular 1C:Enterprise version 8.3.5 and later, come with built-in OData support, an open web protocol for querying, adding, deleting, and updating data. OData allows resource operations through HTTP requests and returns responses in XML and JSON formats.

This is a universal protocol used not only by 1C but also by other systems.

As a result, the systems in the environment will more easily understand the received data.

To use the OData protocol, you need to enable support for it in the 1C settings.

After that, the system will automatically create a REST interface for data exchange between 1C and other systems. The integration can then be connected to it, and data export and import can be configured.

If the system is older than version 8.3.5 (for example, 8.2), you will not be able to use the universal OData protocol.

You will have to build an API and integration for each connected system.

Building APIs is the standard way to set up communication between two systems.

But it is worth remembering that APIs are written by people.

And the people involved were different, with different experience and different ways of thinking.

Each of them is written with its own logic, operates according to its own logic, and in the future must be further developed, yes, again according to its own logic.

After every 1C update, your team will have to separately adapt each API to the latest changes and the API's internal logic. Best case, the same specialist who developed the API will do it, since it will be easier for them to reconstruct their own reasoning when writing the code. Worst case, from a time perspective, it will be a completely new specialist who uses different approaches to API development.

The “wild zoo” problem can be addressed by imposing strict API design standards, though in practice that does not always work, or by artificially reducing the number of integrations.

We saw an example of such a reduction in one of our projects.

To reduce the “wild zoo” in the 1C source system, the system where supplier product data was stored, the company's developers implemented a chained integration. Bitrix collected stock, pricing, product, and similar data from other systems and sent it to the 1C source system. The 1C source system then passed all product data to the 1C system responsible for offline retail.

A part of the initial information flowed from it into 1C, which was responsible for the online storefront. On the one hand, this reduced the number of integrations overall. On the other hand, each additional link made the landscape more vulnerable and created more room for errors and data loss.

Any failure in the integration or in an intermediate system caused information to get stuck and not reach the next stages.

An ESB cannot be called a magic bullet for integrating 1C with anything. First, the integrations still need to be designed properly by separating domains and information flows. Second, to create a connection between 1C and the ESB, you will have to develop a separate API for each entity or use the same OData protocol.

Most often, 1C exchanges not one or two, but five or even ten data flows with each system. And the real data exchange scheme is a bit more complex than a simple web.

We do not recommend funneling the entire data set through a single connector and a single stream when integrating via ESB.

Moreover, we strongly do not recommend doing this, because it increases the integration load by tens of times and proportionally raises the risk of failures.

Accounting for system performance The ESB logic can be configured to set data export and import speeds for target systems based on their performance and daily load patterns. For example, if your CRM can handle 100 transactions per minute during the day and 500 at night, the ESB will take that logic into account and will not overload your systems.

Timely error detection As a rule,

In one of our recent projects for an international company in e-commerce and retail, the KT.Team team set up integrations for several 1C systems: ERP, OMS, UMP, CMS.

We implemented an integration bus and built 13 connectors for seven data streams: one connector receives orders from OMS; one connector passes order data to ERP; two connectors handle order status exchange between OMS and ERP; one connector sends order data to the rewards calculation service; two connectors send user data to the rewards calculation service; four connectors handle user currency and country data; two connectors are needed for warehouse filtering.

A separate connector is configured for each entity, or several if the logic requires it.

This makes it possible to transfer data between systems in a more controlled way.

If you have already looked into the topic, the first and most logical answer may be 1C:Shina.

A product from the same family is indeed easy to integrate with 1C:ERP Enterprise Management