Integrating 1C through a bus: methods and security

1C configurations almost never work out of the box: every company customizes catalogs, documents, and processing tools for its own processes, so the data structure in each 1C system is unique.

At the same time, 1C releases updates regularly: fields are renamed, and directories are split and merged.

The rule follows: any integration tied to the internal structure of a specific configuration breaks with the next update.

The architect's job is to choose an interface that survives releases and a transport layer that does not multiply point-to-point links.

Below are three ways to expose data from 1C and the rule for how to combine them.

1C:Enterprise starting with version 8.3.5 can expose a standard REST interface over OData: read, create, update, and delete data via HTTP requests, with responses in XML or JSON.

The interface is enabled in the web server publication settings - no code is needed on the 1C side, so this is the fastest way to connect 1C to a bus or external system.

Speed is OData's strength and also its risk: by default, it is easy to expose more externally than the task requires.

Access rights must be configured; this is not optional.

For large volumes and offline scenarios, 1C has built-in exchange plans and scheduled exchange (EnterpriseData format, data conversion rules).

This is how directories and documents are synchronized between 1C nodes and how data sets are exported on schedule: overnight item master sync, transfer of documents for a period.

The limitation is symmetrical: this is a batch mechanism.

For real-time events - order status, stock reservation - it is not suitable; here you need OData or HTTP services on top of the bus.