Interacting with Others
There are two things the PLM world realized these last few years:
- The information stored in relationships is at least as important as the objects themselves
- PLM is a lot about integrating systems.
We have discussed and we will continue to discuss the first topic thanks to our use of Graph Databases, but let's talk about integration today.
Integrating systems together in an enterprise PLM framework is key for the following reasons:
- There is not a fully integrated system that covers the whole PLM scope.
- PLM cannot live on its own it has to interact with ERP
- PLM also has to interact with external resources, or other PLMs…
Therefore, today you need to interact and the only option that makes sense is using webservices.
Web services is the main way you make systems communicate to each others. We have past the era of exchanging flat files (well I think we are still doing it a lot). Web is everywhere, most of our exchanges are done over http communications and most applications are capable or rely on an infrastructure capable of exchanging over web services.
REST stands for Representational State Transfer. Created in 2000 it relies on HTTP requests and is based on a few principles that made it quickly adopted by the IT industry and even more with the growing usage of SaaS applications. We have not built REST and sometimes a great video is much better than us writing about it. So let's check this great presentation about REST.
Here is another one from the well know tech youtube channel Traversy Media
At Ganister, we did not re-invent the wheel. We know that in the PLM industry, customers need stability, they need to trust the system they are investing in. When building Ganister, to answer these expectations from the industry, some of our core strategy guidelines were :
- use the most widely used technology when it works for our use-case.
- look for advanced new technologies only when it makes PLM significantly better.
We have built an API using recent but robust and proven technology (if you are technical, here is the technology we use : ExpressJs)
Building an API is not just defining a service we want to expose, developing it and documenting it. The whole Ganister application relies on this API. It needs to serve a large range of needs from defining a new type of node, creating a new user, designing a new form, to resolving a bill of material, launching a support bill of material report summarizing support levels in a fielded product.
We don't just develop an API and write a few lines of documentation hidden somewhere. We wanted to make the API documentation up to date and as easy as possible to read and test. Yes test ! You don't have to write any program code, you just go to the API documentation, use the login service and start using secured features.
The documentation is based on well adopted standard: Open API.
Enterprise Service Bus can actually read this type of standard to accelerate the integration.
Users and security
When extending Ganister by adding new nodetypes, you can still have easy integrations thanks to our node-level APIs.
The API also covers the capability to extend or read the datamodel of your Ganister instance.
Being very flexible is great. Allowing to play with the model or with nodes without knowing what customers will build is a very agile feature. But there are basics that need to be addressed with a correct level of API. Why should we use nodes and edges in a request when what we want is a Bill Of Materials. Therefore we have added PLM ready API end-point.
We standardized as much as possible our API. The following models represent data-structures which are re-used in many API endpoints.
We will cover the versioning of our application in a futur blog post. Just for your information we use the Semantic Versioning 2.0 system.