AI Agent integration with 1C: OData, HTTP services and secure choice

The short answer is: what to choose to integrate an AI agent with 1C

They don't connect "AI" to 1C as a magical add-on. A specific AI agent is connected to specific operations: read the balance, find a document, create a draft application, send a notification to the responsible person, and return the result of the report. And the integration method depends on the set of operations.

OnceHTTP servicesmessage queues or 1C:Bus

If you need a prototype to read the reference information, OData can be a quick start. When it comes to operational operation, document creation, reports, and managed business operations, the correct answer is almost always proprietary HTTP services. For large landscapes where multiple systems exchange events and a response is not needed immediately, a third option appears: message queuing, integration bus, and asynchronous processing.

An important caveat:secure contract

scenarios

What does an agent do in 1C anyway

An AI agent in conjunction with 1C is not needed to "think instead of accounting." His task is to shorten the path from a human request to correct action in the system. """"The employee asks in the familiar interface: "what is the status of the customer's order?", "is there an item in stock?", "create a purchase order for these items." The AI agent parses the intent, accesses 1C through an authorized interface, and returns a response or draft of the operation.

Typical operations are divided into several groups. The first is reading: balances, order status, mutual settlements, details of the counterparty, the status of the document. The second is the search: for example, to find the latest implementation for a client, a document by amount and date, a contract by description. The third is the creation of drafts: an application, a customer's order, an incoming document, and contacting customer service. In financial and accounting scenarios, such a document must remain unverified until a person confirms it.

There are also operations that look like integration with 1C, but in fact they are not. The answer to the question "how to make a refund from the buyer" more often refers to the knowledge base, regulations and instructions of the company. The agent can respond to the documentation without access to the combat base. But "show the last refund for this client" already requires access to 1C data.

The key principle:

Method 1. OData

OData in 1C is a standard REST-like interface for the platform. It is available starting from version 8.3.5, is published on the Apache or IIS web server and supports OData version 3.0. For an external service, it looks attractive: there is a standard interface, you can get metadata, read reference books and documents, filter, create and modify objects.

Set the composition of the Standarddata interface

Remote AccessData

$metadata

But OData has fundamental limitations. It does not provide regular reports, commands and arbitrary methods, routine tasks, a list of users and their management, and a registration log. The request "give me the balance sheet" via OData is not solved directly. You can download the register data and try to calculate it on the agent's AI side, but this is risky: the numbers may differ from what 1C shows. It is more reliable to make an HTTP service that returns the result of a regular report or prepared processing.

OData's main risk in integrating with an AI agent is that it provides access to data objects rather than business operations. An agent creating a document directly through OData can bypass part of the application logic, which in a typical configuration lives in forms, handlers, fill checks and procedures. On the 1C user's screen, the operation would not have passed verification, and the external client had already recorded the object. That is why OData is appropriate as a fast way of reading and prototyping, but poorly suited as the main channel for responsible operations.

Method 2. HTTP services

/agent/hs/v1/order-status/agent/hs/v1/create-request/agent/hs/v1/report-balancethe normal integration architecture

create-request

The second reason is pre—write validation. The service code can check the input data before creating the document: whether the counterparty exists, whether the contract is completed, whether the warehouse is available, whether the limit has not been exceeded, and whether the VAT rate is correct. ""If there is not enough data, the service returns a meaningful error in JSON: for example, "the contract for the counterparty was not found" or "you need to specify the shipping warehouse." The agent understands this error and asks a clarifying question to the user, rather than writing down an incomplete object.

The third reason is limited rights. The service user does not need to be given wide access to configuration objects. He is given a role that is only necessary to perform specific methods. In an ideal scheme, reading the order status, receiving a report, and creating a draft work from different roles or at least go through different methods with different audits.

The fourth reason is the resistance to updates. In typical configurations, the internal structure of objects, props, and movements may vary. When integrating via OData, this breaks the external contour: the agent was waiting for one field, but after the update it changed or began to be filled in differently. With an HTTP service, you can save the external contract, and fix the implementation inside. This is fundamental for a business: integration must survive 1C updates without rewriting the agent's logic.

request and response format in JSON/v1/idempotence

It is HTTP services that provide the correct line of responsibility. The agent formulates the intent, collects the missing data, and invokes the method. 1C checks the business rules, creates an object, or returns an understandable error. The person confirms the critical actions. This architecture looks less fast at the start than OData, but it is much cheaper to maintain.

Method 3. Message queue and 1C:Bus

Message queues and an integration bus are needed where a response is not required immediately or where multiple systems are involved in the process. For example, the AI agent accepted the client's request, set the task to calculate the availability of the product, 1C processed it later, CRM received the final status, and the user saw the notification in the messenger. This is no longer a simple synchronous "question—answer" request, but an event-driven integration.

RabbitMQ SourceRabbitMQ Assignment

DeliveryMode = 2Durable = True

Deceived.Download = True

Starting with the 8.3.27 platform, a full-time WebSocket client has appeared. 1C positions it, among other things, for integration with telephony, electronic signature services and message brokers, including RabbitMQ and ZeroMQ. For an AI agent, this means the ability to keep a constant connection and receive events without constant polling. Before designing such a contour, it is worth checking the release status and limitations of a specific version of the platform at the implementation date.

A queue and a bus are rarely needed for the first prototype. But if an AI agent has to work in conjunction with "CRM + 1C + warehouse + telephony + messengers", an asynchronous loop quickly becomes not a luxury, but a way to maintain manageability.

Comparison: What to choose

If we reduce the options to a practical choice, we get a simple logic: OData — for a quick start and careful reading, HTTP services - for industrial integration, queue and bus — for complex processes and multiple systems. The table below shows the differences not in terms of "fashion", but in terms of operation.

The prototype can be done on OData, it is better to build operation on HTTP services.

financial scenarios

Why can't you go to the database directly?

The query "let the agent just read the SQL" sounds regularly. It is clear: it seems that direct access to the database is faster, easier and cheaper. But for 1C, this is almost always a bad idea, especially if the integration needs to live longer than the first release.

_Document123_VT456

The second problem is totals and registers. 1C does not calculate metrics as an arbitrary SQL query for a single table. The platform takes into account movements, cross-sections, periods, settings, rights, and report features. A direct query to the movement table does not have to give the same number as the regular report. And for the user, the truth is precisely the 1C report, not the agent's calculation.

The third problem is rights. Access restrictions in 1C are implemented by the platform, including record-level restrictions. Direct access to the DBMS does not see these rules. The agent can receive data that a specific user in the 1C interface should not see. For companies with personal data, trade secrets, and financial information, this is no longer a technical detail, but a security risk.

1C counts and records, the agent only requests an authorized operation through a supported interface

Secure connection template

Secure integration does not begin with the choice of a library, but with the boundary of rights. The agent should not have access "just in case". If he answers questions about the leftovers, he does not need the rights to create an implementation. If he creates a draft application, he does not need the rights to conduct and modify closed documents.

The working template looks like this: a separate service user for the agent, a separate role with minimal rights, HTTPS, IP address restriction on the web server or firewall, logging of requests and responses on the agent's side, registration log on the 1C side. The first circuit for debugging is a test copy of the database, not a combat system.

The draft rule is especially important for writing. The agent can prepare an unverified document, fill in the details, attach a comment and hand it over to the responsible person. The document is carried out by a person or a separate approved process. For transactions with money, liabilities and warehouse, this is not reinsurance, but a normal accounting requirement.

request_id

CONTRACT_NOT_FOUND

And one more principle: the relevance of the data must be explicit. If the balances are updated by a routine assignment once a day, the agent is required to report the time of relevance. Otherwise, he will confidently respond with yesterday's numbers, and the user will perceive this as an error of the entire system.

What breaks down in practice

The most common failure is updating the standard configuration. Integration, tied to an internal data structure or wide OData access, suddenly stops finding the right field or receives data in a different form. The HTTP service is easier to support in such a situation: the external contract remains the same, only the implementation inside 1C changes.

an architectural rule

The third problem is duplicate documents. The query hung up, the user clicked again, the orchestrator tried again, and two identical requests appeared in the database. This is a classic integration failure that is prevented by idempotence and a foreign key operation.

The fourth problem is slow responses. A heavy report via a synchronous HTTP service may run into a timeout. In such cases, it is better to do an asynchronous scenario: the agent sets a task, 1C calculates the result, then the agent receives a notification or periodically checks the status. The user sees an honest answer: "the report is being generated, I will send the result when it is ready."

The fifth problem is rights. Everything went well on the test data, but in battle the method fell because the service user did not have enough access to one of the banking details, warehouse or organization. Therefore, the test set should cover different types of counterparties, organizations, warehouses, contracts, currencies, and document states. One happy scenario does not prove that integration is ready.

Finally, the user expectation breaks down. They think that the agent "sees everything in 1C in real time," although some of the data is updated regularly or comes from another system with a delay. This is solved by transparency: responses need to show the source and time of the data's relevance, and in critical scenarios, a link to a document or report in 1C.

What to do next

list of operations

If the operation only reads background information and is needed to test a hypothesis, you can start with OData. If an operation creates a document, starts a calculation, returns a report, or affects the company's obligations, it is better to design an HTTP service. If the process is long, event-driven, and affects multiple systems, it's worth adding a message queue or integration bus.

Автор Антон Амосов

Поделиться Скопировано!