# Communication between Tryton servers

**URL:** https://discuss.tryton.org/t/communication-between-tryton-servers/4735
**Category:** Ideas
**Created:** [October 28, 2021, 11:52am UTC](https://discuss.tryton.org/t/communication-between-tryton-servers/4735 "2021-10-28T11:52:29Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![2cadz](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/2cadz/32/130_2.png) [@2cadz](https://discuss.tryton.org/u/2cadz)
#### Post date: [October 28, 2021, 11:52am UTC](https://discuss.tryton.org/t/communication-between-tryton-servers/4735/1 "2021-10-28T11:52:29Z")

</div>

I reflected a way to communicate several Tryton servers between them (to start, at least 2 Tryton servers “clients” to a “main” server). To synchronize a list of products for example, or make that the confirmation of a purchase order, automatically create a sales order on the “main” server. I think I’m going to use Celery with rabbitmq.  
Has anyone ever thought about the question?

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 28, 2021, 12:18pm UTC](https://discuss.tryton.org/t/communication-between-tryton-servers/4735/2 "2021-10-28T12:18:58Z")

</div>

Yes it should be based on EDI standard messages ([EDI Integration](https://discuss.tryton.org/t/edi-integration/1612))  
And probably the simpler transfer protocol should be SMTP because it is available almost everywhere.

---

<div class="post-metadata">

### Author: ![SISalp](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/sisalp/32/200_2.png) [@SISalp](https://discuss.tryton.org/u/SISalp)
#### Post date: [October 28, 2021, 8:41pm UTC](https://discuss.tryton.org/t/communication-between-tryton-servers/4735/3 "2021-10-28T20:41:52Z")

</div>

I think it could be a game changer if there is no compatibility constraint between the servers.

---

<div class="post-metadata">

### Author: ![edbo](https://discuss-cdn.tryton.org/letter_avatar_proxy/v4/letter/e/f14d63/32.png) [@edbo](https://discuss.tryton.org/u/edbo)
#### Post date: [October 29, 2021, 9:17am UTC](https://discuss.tryton.org/t/communication-between-tryton-servers/4735/4 "2021-10-29T09:17:36Z")

</div>

You can also look at creating a special worker. The data to be synced can be put into the queue and is then processed by the worker, which act as a client to the “main server”.

See also [Task Queue — Tryton server](https://docs.tryton.org/projects/server/en/latest/topics/task_queue.html)

I’m doing something similar but then the other way around, sending notifications to special clients. What I did was creating a new Python script with two threads. One thread checks the queue for data to be processed. If so, it will process the data, but also put the result in an internal queue so the second thread can pick that data and send it to the clients.

---

<div class="post-metadata">

### Author: ![2cadz](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/2cadz/32/130_2.png) [@2cadz](https://discuss.tryton.org/u/2cadz)
#### Post date: [October 29, 2021, 10:14am UTC](https://discuss.tryton.org/t/communication-between-tryton-servers/4735/5 "2021-10-29T10:14:53Z")

</div>

> [@ced](#):
>
> Yes it should be based on EDI standard messages ([EDI Integration](https://discuss.tryton.org/t/edi-integration/1612))

Thanks i will see this

> [@ced](#):
>
> And probably the simpler transfer protocol should be SMTP because it is available almost everywhere.

Yes, this is an advantage, however its biggest disadvantage is that there is no guarantee of distribution.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [October 29, 2021, 10:50am UTC](https://discuss.tryton.org/t/communication-between-tryton-servers/4735/6 "2021-10-29T10:50:38Z")

</div>

> [@2cadz](#):
>
> however its biggest disadvantage is that there is no guarantee of distribution

Like any other system. But you have notification about failure.

Also if you control both sides, you can ensure that it is working.

But any way the protocol is just a detail and should be exchangeable with any other like sftp, web API etc.
