Seamless Integration of Onshape and Odoo
zSYNC bridges the gap between product design and business operations by enabling a smooth, real-time connection between Onshape (cloud-native CAD) and Odoo (comprehensive ERP system). This integration transforms how teams collaborate across departments – from engineering to purchasing, production, and sales.
Key Features and Benefits:
Real-Time Data Sync
Automatic synchronisation of parts, assemblies, and BOMs from Onshape to Odoo – no manual exports or data entry required.Error Reduction
Minimises human error by eliminating duplicate data handling and keeping engineering data consistent across systems.Faster Time-to-Market
Streamlined workflows mean that design changes in Onshape are instantly reflected in Odoo, speeding up procurement and production.Improved Cross-Team Collaboration
Sales, procurement, and manufacturing always work with the latest product data, enabling better planning and decision-making.Cloud-Native & Scalable
Built for modern teams – works entirely in the cloud, just like Onshape and Odoo, with minimal setup and maintenance.
zSYNC Solution
Bill of Material documents are hosted in the Onshape database and made available via authenticated HTTP API. They are imported, via an automatic zSYNC pipeline, alongside the referenced products and assemblies, into the local Odoo system.
The created zSYNC pipeline opens an API session with Onshape, fetches all the required documents, fetches BOM descriptions, maps the Onshape data structure to the Odoo data structure, and automatically creates all of the new entities.
Step by Step
Step 1: Get Session Cookie
Since this in an authenticated API, step one is to request a session cookie by logging into the API with a email and password. The password is stored in the environment variables instead of directly into the pipeline.
To do this Web worker is used. It’s configured to make a a HTTP POST request to the required endpoint. The email and password are sent as part of the request body and the response headers contain the required cookie. We’ll need that for the next workers.
To make the cookie available throughout the whole pipeline, it’s extracted from the response headers stored in the instance environment and made available only for that particular pipeline instance.
Step 2: Get Documents, Versions and Elements
Because of this API’s design, there are several sub-steps to fetching BOM information. First, document Ids, then the related versions, and finally the connected element Ids. The results of all three are used to request the BOM descriptions themselves.
You’ll see that every request has the session cookie added as a request header, for authentication and that the final request filters all the data down to just the three required Id attributes.
2a. Get Documents
2b. Get Document Versions
2c. Get Document Version Elements
Step 3: Get BOMs
Now we get to the request which fetched the BOM information itself. Note how the API path is built: it referenced all three fields which we defined in the previous worker: the document Id, version and element Id.
Again, this API is authenticated using the session cookie requested earlier.
Step 4: Map BOMs
Here we get to a step that’s completely zSYNC specific. The data from that was retrieved from the BOM API isn’t exactly the right format to create Odoo objects from. It needs to be mapped to the correct shape.
What happens in this worker is:
The data structure gets changed
The data attributes get renamed
Step 5: Create Products and BOMs
Finally, the prepared BOMs and the associated Products are created in the running Odoo database.
The mrp.bom
objects are created by definition, because the model has been specified, and the products are created to satisfy the defined one2many relations for those BOMs.
Allowing both inserts and updates means that new BOMs or Products will be created, and existing ones will be updated.