With Exalate - it is possible to setup a synchronization between a public and a private instance without opening firewall ports.
- Public means that the Instance is accessible from the private network.
- Private means that the Instance is behind the firewall and is not accessible (is on a private network) from the public instance.
The main difference between private and public connection types is whether the HTTP/HTTPS requests are initiated from one side or from both sides.
In the private-public connection all communication over TCP/IP is initiated from the private side. In this case, the public side never sends HTTP requests. It only answers requests sent from the instance, located behind the firewall. It might take a couple extra seconds before synchronization continues.
The private instance (one behind the firewall) requests for any changes either every 20 seconds, or whenever there are changes to sync towards the public instance. This explains the delay in sync in case that there are no changes in the private to push to the public. This parameter can be adapted, but 20 seconds seems to be an acceptable delay.
For better performance, we recommend to configure one connection. You can add multiple conditions to the Sync Rules to cover all the affected projects.
In the public-public connection requests are initiated from both sides.
Exalate has the set of messages (supported by private-public communication).
The table below details the messages that are sent between the nodes
| message | when performed | how public instance sends it | how private instance sends it |
|---|---|---|---|
| node info | instance is saved / connection is tested | private instance requests public's node info, the public instance responds to it | is sent via the email when you set up private/public sync |
| sync request | something was changed on an issue, which is under sync | private instance periodically polls, whether the public instance has any sync requests | private instance sends sync requests directly |
| sync response | synchronization has been processed by the receiving side | private instance periodically polls, whether the public instance has any sync responses | private instance sends sync responses directly |
| sync error response | synchronization failed on the receiving side due to the sending side's mistake | private instance periodically polls, whether the public instance has any sync error responses | private instance sends sync error responses directly |
| blob request | an attachment was added to an issue, which is under sync | private instance periodically polls, whether the public instance has any attachments to be sent | private instance sends blob requests directly |
| blob response | an attachment has been received by receiving side | private instance periodically polls, whether the public instance received an attachment being synced | private instance sends blob responses directly |
| blob error response | synchronization of an attachment failed on receiving side due to sending side's mistake | private instance periodically polls, whether the public instance had any problems with receiving an attachment | private instance sends blob error responses directly |
Switching an existing connection from public/public to public/private (or reverse) needs
- An update of the database on both sides
- All synchronisation transactions fully handled (queues are empty)
In case of need - please reach out to our support (here)
1 Comment
Svitlana Magamedova
ok, done https://docs.exalate.com/pages/viewpage.action?pageId=19632146