PARUS 8 data in chat through its WEB API integration service
Connect PARUS 8 to the AI agent through its WEB API integration service: the agent calls the declared exchange functions, reads refusal codes and joins the data.
How the agent works with ПАРУС 8
The agent reaches PARUS 8 through the application server called the WEB API integration service — the Node service installed next to the database. The connection takes two fields: the address of the application server and the root of the exchange service, and every function path is resolved relative to that root. Liveness is checked against the root itself: it answers with an HTML page carrying the application server version and the service name for any method, so connecting needs no development work on your side.
The set of functions differs per installation, and this is the main difference from a cloud service. The application server has no routes of its own: at startup it reads the directories of the database itself — Exchange services define the URL root, Service functions define the address, the HTTP method and the before and after handlers. That list is never published outwards, so the agent does not guess paths: it asks you for the export from the PARUS settings and works from it.
Refusals always arrive the same way: HTTP 500 with a text body of the form ERR_CODE plus a message, which means the status code carries no meaning at all. The agent parses the prefix and separates what has to be separated: ERR_UNAUTH is the PL/SQL handler denying permissions, which no change of login will fix, ERR_DB_SERVER is a handler error inside the database, ERR_APP_SERVER_BEFORE and ERR_OBJECT_BAD_INTERFACE mean a malformed request. Retrying after those is pointless, and the agent does not retry.
The shape of a successful response is defined by your own handler rather than by the vendor: one function returns JSON, the next one XML or arbitrary text, and the agent never assumes JSON in advance. It also respects the real ceilings: the application server keeps ten database connections by default and accepts messages up to ten megabytes, so heavy handlers hit the database rather than HTTP. Functions whose address starts with an at sign serve static files and are skipped in the list.
Integration scenarios
A query through a declared function
The agent calls a function of the exchange service — stock, counterparties, accounts — and lays the answer out as a table instead of asking the admin for a manual export.
An inventory of exchange functions
The agent collects the list of functions from you (code, address, method) and keeps it for the conversation, so paths are never guessed and 404s stop happening.
A liveness check of the application server
The agent pings the root of the exchange service and tells you whether the application server is alive and whether the 404 is its own, before you start looking for a permission problem.
Reading refusals from the PL/SQL handler
The agent reads the ERR_ code out of the response body and names the cause: denied permissions, a handler error in the database or a malformed request.
Registering a document from the chat
If the service has a writing function declared, the agent shows the body of the request it is about to send and sends it only after your confirmation.
PARUS next to your other systems
The agent puts a PARUS query next to bank, marketplace or mail data and shows the discrepancies in one picture, with no intermediate exports.
ПАРУС 8 examples
Разобрал 24 функции: 17 читающих и 7 пишущих.
- 3 строки пропустил — адрес начинается с @, это раздача статики, а не функция обмена
- У 5 строк метод не проставлен, читаю их как GET
Дальше зову функцию её кодом. Каталога путей у сервиса обмена нет: состав функций задаётся в самой базе Паруса и у каждой инсталляции свой, поэтому адрес я не угадываю — 404 здесь означает «такой функции не объявлено», а не опечатку.
По функции DEBTS_BY_AGENT — 8,42 млн ₽ долга по 63 контрагентам.
- Свыше 90 дней висит 2,13 млн ₽, и это 14 контрагентов
- Ответ пришёл XML, а не JSON: форму ответа задаёт обработчик функции, поэтому я разбираю все три и не жду одну
Пустой таблицей отказ не покажу: строк не пришло — это ошибка разбора, а не «долгов нет». Регистрировать документы этой же функцией не буду — пишущий вызов сначала показывает тело будущего запроса и уходит только после вашего «да».
How to connect
Before you connect
- A deployed WEB API integration service application server
- An exchange service with a URL root in the PARUS directories
- Declared service functions: address, method, handler in the database
- Network access to the application server from our side
- 1
Deploy the WEB API integration service
The WEB API integration service application server is installed next to the PARUS 8 database and carries the exchange: without it no request reaches the database.
- 2
Create an exchange service and its root
In the Exchange services directory create a service and set its URL root — that root is what you enter in the second field when connecting.
- 3
Declare the service functions
In the Service functions directory set the address, method and database handler per operation. An undeclared address does not exist for the server: it answers 404.
- 4
Open the service root in a browser
Open the application server address together with the service root: a live exchange answers with a page carrying the application server version and the service name.
FAQ
With two fields: the address of the WEB API integration service application server and the root of the exchange service from the Exchange services directory. No login or password is needed here — the application server does not authenticate incoming requests.
Because there is nowhere else to take it from: the list lives in the PARUS database and is never exposed. A 404 means that no such function is declared rather than a typo in the path, so guessing is useless.
Only through the exchange functions your administrator declared for writing. The agent shows the body of the request in advance and sends it after an explicit confirmation.
Talk to your PARUS administrator: permissions are checked by the PL/SQL handler of that specific exchange function, not by the application server. Changing the login and password in the connection card has no effect on this refusal.