Connecting Autodesk Fusion 360 to SAP Using the Fusion Data API

STEFAN SCHAARSCHMIDT: Hello, and welcome to my class, Connecting Autodesk Fusion 360 to SAP Using Diffusion Data API. First things first, the API was quite recently renamed to Manufacturing Data Model API, so this should be our new title. And I think this name change of the API reflects two things and not to Autodesk industry cloud strategy, as well as the fact that the API might expand beyond Fusion 360's data.

Anyway, what we want to talk about is a case study on how we wanted to create an SAP ERP integration for Fusion 360, our journey to get there, and the results of it. So I am quite aware that there are different type of audience interested in this presentation. There might be CAD or SAP managers looking for an actual Fusion 360 SAP integration, or there might be IT managers looking for the visibility of an ERP integration and create one themselves for this CAD system. And also there might be developers curious about our experience. So I hope I have something for each of you. And, yeah, since this is a case study, our journey is part of the presentation.

My name is Stefan Schaarschmidt. I was a long time development manager for CIDEON. And now I'm the Vice President of Development and Customer Support. I'm based close to Dresden here in Germany. I studied computer science a long time ago. And I have a long time experience with CAD, and SAP, and also the integrations in between. I'm still quite interested in technology. And, yeah, I've seen quite some changes over time.

CIDEON Software & Services, the company I'm working for, is an Autodesk partner for over 25 years. It's actually one of the biggest in Europe, platinum partner, even. And we provide consulting, implementation services, training, project solutions, or individual software development. We are based in Germany and Austria. And our customer base is pretty much cross-industry, but we have a certain emphasis on mechanical engineering and plant design.

What's probably a pretty unique combination is that we are also an SAP implementation partner for over 20 years. We provide some of the CAD integrations for SAP on their price list. And this way, we have integration customers worldwide.

So let's start with Fusion 360 and SAP. So let's start with some motivation on the slide. I mean, CAD is the greatest thing. There, you can be creative. The products of tomorrow are developed there and all the urgent changes for today's project.

But at some point in time, questions like the one here on this slide will come up. So I have an ERP system which is controlling all my manufacturing process. And I really want to have the full bill of material available here. And of course, it should be as correct and complete as possible.

Sometimes I need to pre-order some of the parts. And I could create a bill of material right now even if the design is not completed yet. And then later, I would update it without any tedious manual side-by-side comparison between the two systems. And of course, I have downstream processes like plant maintenance, or spare part orders, which all rely on data which were originally brought over from CAD.

Also, if I'm looking for a really serious cost calculation, I need to do it on the LP side with all the specific information like country information, customer, or the other conditions. And this is using information from the CAD side as well.

And the other way around, if I'm a CAD engineer, maybe I want to know what's the actual price or availability of this part and maybe I should decide to use a different one in my design here. So these questions are not all directly answered by an integration, but exchanging CAD data with an ERP system is really paramount to answer them.

So our answer to that, our integrations, we have a long history of on-prem integrations. And basically we can say we have two types of integrations. There are the CAD direct integrations like our Inventor SAP integration. And in this case, the integration sits right within the CAD system. And SAP is also a PDM system, so the CAD files would be stored on the SAP site, check in, check out, or the access management would be done through SAP. And of course, things like the bill of materials and so on would also be used here.

On the other hand, we have PDM integrations, like our Vault SAP integration where the CAD data would be stored within Vault and then the integration would sit within Vault, either on the front-end side or the backend side, and exchange data with SAP. In this case, we would not necessarily store SAP files-- not necessarily store CAD files on the side, but we would create bill of materials and all the things we need in order to do so.

So this was our long-term business on-prem. And at some point in time, we had to realize that all the cloud topic is growing. And if we just look at Autodesk and think just about some few of us from Autodesk on the cloud business side, then we see a long list like AutoCAD map, all the BIM functionality and the Autodesk Construction Cloud, Fusion 360, the one we are interested here, Fusion Manage Upchain, all the rendering service or the generative design services which use the computing power of the cloud, or the sharing services from AutoCAD Inventor, Revit, all of your favorite on-prem systems.

And at the other end, we have e-vendors, of course, also for cloud solutions. And in the case of SAP, their are public cloud offering is called S/4HANA Public Cloud. And this is basically an SAP system centrally hosted by SAP. It's provided as a software as a service. And the user would no longer use the old Windows SAPGUI, but a web-based UI instead.

So this means we had to really rethink our approach and think how does an integration fit into this scenario. Both sites are web-based, cloud-based, and obviously we need some kind of different integration. We started by analyzing the requirements that Fusion 360. And it has some nice features like it has just one CAD version so you don't have to deal with that.

The CAD data is stored in the cloud. And it has a built-in document management system. So we have access management, search, versions, milestones, and so on. And therefore, basically what we are dealing here with is a PDM integration.

OK, so the main requirements would be transferring the bill of materials into the ERP system, including all the necessary data. And also we make the SAP information accessible to the CAD engineer for a specific CAD component. That's also an important part of it.

However, on the document side, there are some optional requirements like providing neutral file formats for all the follow-up processes on the SAP side like your typical STEP file or STL file. This might also be something simple like previews, or also information from the CAD site like maybe an indicator, whether or not this CAD document is actually released on the side of the CAD system.

So our task list was basically, OK, we need to be able to assign SAP items to Fusion 360 components. We need to create new SAP items using information from CAD without any re-entering of information. And very important, for reused CAD components, like in different CAD design version or in a different CAD design, we need to recognize that there's already a SAP link in order to really reuse this information. Then using the CAD structures, we will create and update bill of materials and make the SAP data available.

OK, so our journey looked like this. We started by looking on what would be the technology platform for it. So it was quite clear that it would need to be web-based and a software as a service solution. Because if both of the other partners are cloud-based and our software is a service, then it does not make sense to have an on-premise integration kind of thing.

As a technology platform, we were looking at the SAP Business Technology Platform. This is a platform, a service offering from the SAP side. And we did not only choose it because we are a SAP partner but also because it provides a lot of useful technologies, especially all around the SAP system like using the identity provider of the SAP system to provide really safe connections into SAP, safe and trusted. It provides functionality like single sign-on or the propagation of users between the different systems.

On the Fusion 360 side, since we were starting with a web application, we wanted not to use front-end modules. So we would not use Fusions locally by devs in C++ and then Python API available locally, but we wanted really to tap into the information on the Autodesk Cloud. And to do so, we would obviously use the Forge APIs, which are now called the Autodesk Platform Services.

So we started by checking out the original Forge APIs, the ones which were available back then. So the first one was the data management API. And this is an API which helps you to explore projects and folders, find models and their versions. But it basically stops at the file end or the design end, so the content of the CAD models would not be part of that one.

In the Model Derivative API, the main task of that one is a new tool file creation as well as delivering some of the metadata of a model including some structures. However, what this is not designed for is the tracking of changes or the recognition of reused parts in a different model. So if you would encounter the same component in a different design by using the Model Derivative API, you wouldn't necessarily recognize it.

Also, we had a quick look at the Design Automation API, which is a really powerful automation tool for AutoCAD Inventor Revit 3D Max, which allows you to run basically a dark CAD session on Autodesk's servers. However, this is not available for Fusion 360. And to be honest, a background CAD action would be way too expensive or slow anyway just to get some information out of the model.

So what we did, it was a proof of concept or demo implementation and then we started to seek conversation with Autodesk. So [INAUDIBLE] started working on a Forge data quite some years ago. And we were very interested on that from the beginning. We even participated in an earlier, I guess today we would say, technology prototype called HFDM.

But two years ago, Autodesk started a new beta program for Forge Data. And our use case fitted quite well, and Autodesk was actually aware of that. And so we were asked to join the Forge Data Vanguard team. So this was basically a group of people who try out this new API and give feedback and check if it's nice to use and if it provides everything we are looking for.

So the first task was understanding the underlying data model. And this was something I was quite interested in because the main idea was not only provide data from Fusion 360 but be able to store information from many different CAD systems with a lot of different information in it. And the idea of Autodesk CAD was basically to split the information into really small parts and then use different types of relationships in order to model the connections between them.

So in our head, we had to basically map this new and slightly complicated model to our Fusion 360 model. And in the end, we were able to access it. We found the data we needed. However, and this was feedback we were giving to Autodesk, we found that the learning curve is quite a bit steep. And we could imagine that if somebody is not using it all the time, it might maybe a little bit-- yeah, it might have a hard time to work with it.

So what auditors did is basically provide an additional or an API which was way easier to use and which was based on GraphQL. And it was also using all the familiar CAD object terminology and structure.

So for example, you would really have a component and then you could look what versions would be available. And then to see what's inside, you would see the occurrences, and those occurrences would then point to a component in a certain version. And GraphQL itself is also a really nice technology that was something like at this point in time, we did not encounter yet. And we were pleasantly surprised how nice of an API that is.

So Autodesk provides a nice web tool in order to play around with the GraphQL APIs. However, if you are using Postman or Insomnia, then you can actually use those because GraphQL is pretty nicely supported there. And I would say let's have a little look into it to see why I think it's really cute and helpful.

So first of all, we have one endpoint. This endpoint is answering all the requests. And basically, I'm sending a request for a specific type of information, for example, the list of the apps I have access to. And I also say what information should it return, actually. And so I'm sending it and I'm getting back my list.

And as you can see, every time I change my request, I am really well-supported by all the available fields or substructures which I can request. So now I just edit the ID in order to have it for additional calls. And I can even drill down and say, OK, give me all the projects from all the apps I have access to, and so I'm getting that.

What you can see here that there is a slight danger that you might be tempted to try to get too much information at once to overreach with your request. So what you can do is also filtering information. For example, we know the name of one of the apps I'm interested in and get the projects only of that one, and so it does.

And so I can drill down even more. However, let's do a second request here. And this is the one I mentioned earlier, coming from the component. With a certain ID, we can ask for information, like the name or the idea, or the ID. Or we can say, OK, what are the actual components used in the most recent version and what are the referenced component versions? And if we do that, then basically we get the information we need for a bill of material because we already have the structure.

So let's go back to the integration. And as I said, we were basing it on the business technology platform. And this platform is providing all these little services in blue in the middle, like databases, or like the identity provider, or like a destination service which allows you to really reliably and trusted-- have a trusted connection to the SAP site.

The technology used to reach the SAP site is ODATA. And the nice thing is that these destination services allow both to reach cloud-based SAP systems as well as on-prem systems, if you need to do that. And on the other hand, we would use the Manufacturing Data Model API in order to access Autodesk's cloud data or Fusion 360. And last but not least, we would have a browser-based UI which is accessing this application.

OK, then let's have a look at the result, with a short demo of this solution. So we start Fusion 360. We can see actually that there is some-- there's a list of components. And this will in the end, end up in our bill of material. So we have some components which are external components, means they are reused. And nicely enough, as we can see later, they are already assigned to SAP.

So we have to sign in on both sides. And depending on the scenario, we can also use some single sign-on here. And, yeah, this is from our little API demo. This should be recognizable. We can see the apps I have access to. I'm choosing one of the apps and I see the projects. And I can drill down and can see all the folders in it all by using the API. And we can see in the end our design we are interested in.

So let's see what's inside. So we can see all the components in it. And if we go down, then we can even see that some of the components already have a link to SAP. But in order to have a bill of material, of course the other ones need one too.

So first, let's create a SAP product for the bike frame itself. This can be dark or interactive like here. And we can see that we take over the information from the CAD side. And according to my mapping, this information will end up on the SAP side. And we can also create a document if we, for example, want to transfer some preview or neutral file formats.

And after we have done so, we can have a quick look on the SAP side with an original SAP web screen. And of course in the demo, you do this to actually show the information came over, but also this is functionality which is really nice for the CAD engineer because he can actually see all this data which after it was initially created, it can be added on the SAP side. And we can even see the link to the document which we transferred.

And then we have some more components which need to be assigned. And in this case, we do a quick mass creation of SAP products. And here we are. And now we are prepared for the creation of a bill of material.

And if we do that, then we can see, of course, we just created it. There is no bill of material yet for it. And especially in the area of bill of materials, using change numbers is a really, really good custom in order to really track the changes on the ERP side quite well.

So we are using this change number. And when we get the last view on how the bill of material will look like, we can see all the quantities, we can see the components. And if we want to, we could do some last changes here. And then we have created it on the SAP side.

Again, yeah, bill of material screen is available to the CAD engineer. And here, we will use it in order to see how the quantities and the components and so on came over, and also the change number.

So basically, this is the easy part. The change is something which sometimes is not so easy. So I'll do a quick change on the CAD side. I'm exchanging two plastic covers into aluminum ones. And after I have saved the design, a new version gets created. The integration is picking up this version.

And if we look now into the content of this design version, then we can see new component exchange one, and the other one is gone. So if we are updating our bill of material now, and again, we will exchange numbers because we want to do it right so it's nicely documented why this change was being done.

And we can see everything stays the same except that one item is gone and the other one will be replacing it. Let's send it over to the SAP side. And a last look at the bill of material will conclude this demo. And of course we do now have our exchanged part in the bill of material.

OK, so we have seen that the new Manufacturing Data Model API is delivering enough information to create a working ERP integration. Of course, we do have more ideas for enhancing this integration, and Autodesk has ideas for enhancing the Manufacturing Data Model API, too.

And so there are things like-- I think it's kind of an open secret that Autodesk is working also on write-access to some manufacturing data model and we are looking at it. And contrary to what I said initially, we also decided to actually make this web application even available within Fusion 360 itself, so there is even a tighter integration.

OK, let's have a quick summary from a management perspective I mean, if you are looking for a sub-integration for Fusion 360, I think it was clear that there is one. And we are happy to talk with you if you want to go deeper with that one.

On the other hand, if you are looking to build your own integration, for example, for a different ERP system, then the technology is there and we might even help you with that. For developers, yeah, I mean, access from a web application to Fusion 360's cloud data is absolutely possible. I think this was quite clear and it's based on nice technologies.

One recommendation I can make is the Manufacturing Data Model API classes are a niche, which I believe is not available this year but in last year's up-and-running with Diffusion Data API. You can add a good starting point or from a development perspective.

One recommendation in general, talk to Autodesk if you have interesting technology questions. If you have a well-defined problem for a certain Autodesk technology, often there are Autodesk accelerators. And use those. They are really great. And finally, not to forget there are more data-related APIs coming up or exist right now, like the Data Exchange API. And, yeah, keep an eye out for all those new APIs on Autodesk's side.

So this is the point in the live presentation where we would go into a Q&A session and hopefully a really lively one. And if you want to follow up to this recording, then you can contact me and we can start a discussion like this.

So thank you very much for the interest in this class, for listening all the way through. And I hope I see you. Bye, bye.