This module is used to create a bridge between Odoo and other AI systems
like n8n.
Right now, there are 2 different approaches for AI integration with
Odoo:
- Make everything inside Odoo.
- Make it using other tools and integrate Odoo with these tools.
IMO, it would be better to make use of option 2 for different reasons:
- Odoo server is intended as a transactional system. AI systems requires
other kind of characteristics
- Everything changes too fast. I am not confident that Odoo can keep the
pace in this topic
- There are OSS tools that fills the gap perfectly and are created just
for this topic.
Anyway, OCA is open to everyone and we don’t intend to force an
opinionated way of doing. For this reason, we have this module, that can
be used as Bridge with AI systems.
As an administrator access AI Bridge\AI Bridge.
Create a new bridge. Define the name, model, url and configuration.
In order to improve the view of the AI configuration, use groups and
domain to set better filters.
On the external system, you will receive a POST payload. The data
included will be the following:
- _odoo: Standard data to identify the Odoo Database
- _model: Model of the related object
- _id: Id of the related object
- _response_url: Url to call with the response in case of async calls
Adds a new item called record with all the fields.
Adds all the fields directly on the payload. It will be removed on 17.0.
The new system allows asynchronous and synchronous calls. Asynchronous
calls makes sense when the task to be processed don’t need to be
immediate. For example, reviewing an invoice and leave a comment with
the result. The same would happen with a chat message. We expect that
the system will leave time to the AI to answer and Odoo’s user can do
other things.
Meanwhile, Synchronous calls will froze odoo system and wait for an
answer. This makes sense when we expect some feedback from odoo user. It
makes sense, when we open an action for example.
In the synchronous call, the result is processed when the AI system
answers on the webhook. On the other hand, it will be processed
automatically on the synchronous call.
With the answers of the system we expect to do something about it. We
have the following options:
In this case, the result will do nothing
We will post a message on the original thread of the system. The thread
is computed by a function, so it can be overriden in future modules. It
expects the keyword arguments of the message_post function.
It expects to launch an action on the user interface. It only makes
sense on synchronous calls.
It expects an action item with the following parameters:
- action: xmlid of the action
- context: Context to pass to the action (not required)
- res_id: Id of the resource (not required)
Bugs are tracked on GitHub Issues.
In case of trouble, please check there if your issue has already been reported.
If you spotted it first, help us to smash it by providing a detailed and welcomed
feedback.
Do not contact contributors directly about support or help with technical issues.