Solibri Connector Technical Information (How it works?)
The synchronization process steps between Solibri and BIM Track are:
- Update Solibri issues from BIM Track issues.
- Then update BIM Track issues from Solibri.
There is no way for Solibri to detect if an issue and / or viewpoint was deleted in BIM Track. Basically, what they are doing is getting the whole list of issues (from BIM Track), then add the missing info to Solibri. Then they update the issue properties in Solibri that are both in BIM Track and Solibri.
Then the same process is applied the other way around. For every issue in Solibri, it is pushed to BIM Track.
Now due to the way BCF Rest API is designed, there are a few important caveats;
In BCF, viewpoints are defined as _immutable_ (immutable means that it cannot be changed. Instead, new viewpoints should be created. It is the way the standard is defined: https://github.com/BuildingSMART/BCF-API#452-post-viewpoint-service).
Updating an issue is not very straightforward. In fact, several API calls needs to be performed to complete update. From our end we have no way of detecting that many requests are the same operation, so there will be as many "update" activities logged than the number of requests sent to BIM Track.
Here’s a few examples of request type:
- Update issue properties
- For every comment:
If it does not exist in BIM Track --> create the comment
If it exists in BIM Track --> update the comment
- For every viewpoint:
If the viewpoint does not exist in BIM Track create viewpoint
Because viewpoints are immutable, whatever operation made in Solibri (that is, updating the camera, selected elements, coloring, etc), a new viewpoint will be created BUT, the old viewpoint will NOT be deleted from BIM Track.
We limit the number of issues returned to 100 to avoid overwhelming our servers. As a side effect, if the client does not provide paging information, they will only get the 100 first issues. This process is being reviewed at the moment as we are looking to improve that aspect.