Connecting Autodesk Fusion 360 to SAP Using the Autodesk Forge Data API

STEFAN SCHAARSCHMIDT: Hello, and welcome to this presentation. Thank you for the interest in the topic we want to cover today. The idea for this class stems from our participation in the Forge data beta program. And in this case study presentation, we would like to share our experience and also the results of our journey.

My name is Stefan Schaarschmidt. I am a development manager at CIDEON and based in Germany. I studied computer science long time ago, and I am still very interested in technology and have seen some changes over time, including Autodesk software or SAP.

The company I'm working for, CIDEON Software and Services, we are Autodesk partner for a long time. We are actually one of the biggest in Europe, platinum partner even. And we provide consulting, implementation, training, software development. And we are based in Germany and Austria. And while our customer base is cross industry, we have a certain emphasis on mechanical engineering and plant design.

What's interesting about us, and maybe a little bit different and unique, is that we are also a SAP partner for a long time. We provide the official CAD integrations for some of the CAD systems on SAPs price list. For example, the Inventor SAP integration or the AutoCAD SAP integration. And we have integration customers worldwide.

So the integration use cases I want to present today, the first one is Fusion 360 data integrated with SAP. This is the main case study. We will cover what our motivation was our journey, our involvement in the beta program. It will be a bit technical but not too much. And of course, we conclude with a little demo.

As for the second case, the SAP configuration within the Forge viewer, well, we were a little bit overexcited to include the second one in our class, but we were eager to show it. And however, it fits quite well, both the general topic of integrations and also the best of two worlds approach, as well as the topic of using Forge for ERP integrations. Let's call it our bonus content.

Let's go for the first one, Fusion 360 and SAP. So let's start with a bit of motivation here. So CAD is great. CAD is the best, of course. In CAD, the products of tomorrow are being created, or the urgent changes for today's project. But at some point in time, you encounter questions like the one here on this slide.

So things like, OK, if I have all my manufacturing controlled by the ERP system, could I please have the full BOM from CAD available there? And could it please be correct and complete?

Or there are scenarios like, when I'm pre-ordering some parts way ahead of manufacturing, then maybe I could create a BOM right now, even if the design is not complete yet. And then I would update it later without the user having a hard manual side-by-side comparison and check out the differences.

And of course, there are follow-up processes in SAP, which rely on the data coming from on the CAD side. And this could be things like plant maintenance or spare part orders or things like that.

But on the other hand, if you are the CAD engineer, then you also want to know things from the ERP side, like having a really serious cost calculation which is relying on a lot of information stored on the ERP side. Or if you want to know if I have this CAD part, what's the price or availability for this? Maybe I should use a different one.

So not all of these questions are directly answered by an integration, but exchanging CAD data with an ERP system is really important for those.

So our answer for these kind of questions are integrations. So there are basically two types of integrations. One is CAD direct integrations, like our Inventor SAP integration. In this scenario, the integration sits right within the CAD system. And in this scenario, SAP is also the PDM system. So you would check in and check out CAD files, and so on. But of course, you would also create ERP data, like bill of materials.

Or you have PDM integrations, like our Vault SAP integration, where , of course, Vault is the PDM system, and the integration sits right within Vault. And here the most important things are the exchange of item data and bill of materials but also some document management functionality, like providing neutral file formats and things like that. And CAD files in this scenario would not necessarily be in SAP.

So the cloud business is growing, and it's growing since a long time. And Autodesk started offering cloud solutions a long time ago. Just think of things like AutoCAD Web or BIM360, now Autodesk Construction Cloud. Fusion 360, Fusion Manage, Rendering Services, or the sharing services from our favorite on-premise CAD systems.

And the same is true for SAP. They started offering cloud solutions also a while ago. And the one we are interested in here is the S/4HANA public cloud, which is basically an SAP system which is centrally hosted by SAP. It's a software as-a-service solution, and it would be web based instead of the old Windows GUI.

So this was the situation we encountered some years ago, and we were thinking, OK, in this scenario, how does an integration fit in this one? And so we looked closer at Fusion 360 since it is a 3D system, and it's in our genes to-- if there is a CAD system, we want to integrate it, of course. And what are the properties interesting for us?

It is locally installed, but it is just one CAD version because it auto updates. And its whole CAD data is in the cloud. It's interesting. And also, it has the document management built right in. So access management, searches, versions, milestones would all be provided by Fusion itself.

So stemming from that, we have basically the requirements of a PDM integration. And this would be, OK, we need to transfer the bill of materials and including all the data necessary up to this point, meaning item data. And also we want to make SAP information accessible for specific components. So if I have a CAD component here, I want to know something from the SAP side.

And again, just like we say with a normal PDM integration, we also have some optional document management requirements, like, if in the follow up processes you need a STEP file, and we can provide that or previews. Or maybe, if you have a CAD document and on the SAP side you have the SAP document, and maybe this could indicate if the CAD document was released on the CAD side.

So for an integration, there is a certain functionality necessary for certain tasks we need to provide in order to enable this. So things like assigning an SAP item to a Fusion 360 component or creating an SAP item using the CAD information from a component.

And of course, without re-entering this information manually because, if you re-enter information, you are losing. You're losing fun your're losing quality, and of course, you're losing time. And this is also true for the reused CAD components. These need to be recognized in order to avoid a double creation of SAP information.

And then, of course, we want to create and especially update SAP bill of material from the CAD structures. And we want to display SAP data for a selected component.

So how did we approach it? We looked for a technology platform. So obviously, it needed to be web based and a software-as-a-service solution. And we decided to go with the SAP business technology platform to host our solution.

So this is a platform-as-a-service solution from SAP, which is nice to host your application in if you are interested in connecting to SAP because it provides a lot of functionality in this area.

And on the Fusion 360 side, we did not want to have front-end modules because, if you are in a cloud scenario, it does not make sense at all to have a local installed integration if your partners are sitting both in the cloud. So what we wanted to do is using the Forge APIs to access the data which is stored in Autodesk service and go from there.

So what we did, it's still some years back. We were checking out the Forge APIs which were available back then. One was the data management API, and this works very well to access the hub and projects and folders, finding versions of models. But of course, it's not meant to display the contents of the CAD models.

Also, we looked at the model derivative API. This is meant for neutral file creation as well as delivering some metadata on the way. And this even includes structures. However, this is not designed for tracking of changes or recognition of re-used parts.

So if you have a different model version with a slight change, it's not completely sure if this component is the same like the last one or a slightly different. And also, we gave the design automation API a very short look. This is a powerful automation tool for AutoCAD, Inventor, Revit, 3ds Max.

And you can basically use a background CAD system in order to access information or change the information. But it's not available for Fusion 360 and, to be honest, a background CAD action would have been too expensive anyway, time wise, for the kind of integrations we had in mind.

So what we did is we created a proof of concept, a demo implementation using the first two APIs. And then we were seeking conversation with Autodesk.

So Autodesk started working on Forge data some years ago, and we were very interested in this topic and followed closely. And we even participated in earlier initiatives called HFDM. And last year, Autodesk started a new beta program for Forge data.

And we were invited for the Forge data Vanguard team. And since our use case fit it quite well, and well, and also, Autodesk was aware of that. So we participated in this private beta. And this was a very good experience.

So the first task we had to do is understanding the underlying data model. So this was very interesting for me as a software architect. How would you model a data model in order to host all the CAD data from the different CAD systems of Autodesk and maybe future enhancements, and so on? And the answer was something called an entity component system.

And while we do not want to go too much into detail, I can give a very simple explanation. Basically, it means I split up the information into really, really small parts, and then I use different types of connections, of relationships in order to model the CAD data you want to store in there.

And the API was modeled relatively close to this model. And we looked at the API, and it took us a little bit longer than usual to get into it. But the data was there. And it was sometimes a little bit like a puzzle piece. And then we had feedback sessions with Autodesk, and these were really good discussions. Autodesk was very, very interested in feedback from the participants in this beta.

And the feedback we gave is, well, this would solve our needs, and the data is there. However, it seemed like a steep learning curve. And I even would think that, if somebody who is not programming all the time, like maybe a CAD administrator, you would have a hard time.

So some weeks later, Autodesk came and said, OK, would you like to try a GraphQL-based API, and it would have all the familiar CAD objects and terminology and structure? And we said, sure. We want to try it, yeah. So what does it mean?

GraphQL-based means, OK, GraphQL is basically a technology which helps you to get information by detailing the fields you want to have, and you're getting back exactly the fields you want to have. And you can also include subcomponents, and these subcomponents would then also be included in the answer.

And this is very, very convenient, and it reduces the number of calls. And it's a nice technology. And actually, we did not have experience before with that, and the learning curve is really easy.

And on the other hand, the CAD terminology, it means simply that you would have requests which start with, for example, your component. And this component would be in a certain version, and it would contain occurrences and component versions in it. And this all makes it very easy and convenient to use this API and also a joy to use.

So we decided to go on and use this API in order to enhance our proof of concept and make something out of it which we can actually use as a product. And this is basically our story.

We were able to create an integration of the kind we wanted. And we can access data from Fusion 360, and we can also access the data from the SAP side, of course, and from a web-based integration. And we can present, enrich, and transfer this data. And I would say let's have a short demo.

So we start with Fusion 360, and we have a model in here. And this model consists of components, external ones, and internal ones. And we want to create a bill of material out of it in the end.

So the first thing we will do is log on to both sides, both the SAP side and the Forge side because both sides have their own access management, of course.

And then, we can navigate the hubs, the projects, the folders, everything the user can access. And interesting enough, this kind of navigation is also featured by the Fusion data API.

So finally, we will arrive at our model, and then we can dive right into it and see the components it consists of. And we can also see that some of the components are reused, and they were used in a different model as well. And this means they were already linked with SAP information.

So now, let's create an SAP product for the bike frame. And of course, we will use the information which is already coming from the CAD side. And after that, we will create a document info record. In this case, it simply contains a preview. But as I said, this also could be a STEP file, for example.

So now, the user can always access this information from the SAP side. And we do this, for once, we want to prove that the data is there, of course, but also to show, OK, this is quite easy to access the product sheet and all the information which might then be later added from the ERP side as well.

OK, and then, we have a lot of components which do not have a product link yet, and therefore, we do a mass creation in order to spare some time. And after we have done that, we are ready to create a bill of material.

So we do that, and in the beginning, this product does not have a bill of material, of course. We just create it. But we will do so. And it's very good practice to use a SAP change number to connect this with the creation of bill of material to track the changes. And we can do this right from the integration as well. Either select one which already exists or create a new one.

And then, we start the BOM creation. We can have a last check. We can see, OK, the component quantities are there, and they are correct. And then it's been created. And of course, again, we will have a look to see what was transferred and also as an example on how the CAD user can then later see additional bill of material information, which is being added on the ERP side.

So for now, we can see the components which we have transferred and all the different quantities. And these were all, in the end, provided by the Fusion data API.

So the place where an integration shines even more is, if I have a change process. And so I'm starting a change process from CAD, and I say, OK, I want to change these covers, these ABS covers into aluminum ones.

I save the file, and when I'm back in the integration, I can see that there is a newer version now. And if I'm diving into that, then I can see all the components, of course. And this includes the new one which was exchanged.

OK, so let's start our update of the bill of material. And again, to track all the changes on the SAP side, we are creating a change number or using one which is already there.

And if we are changing, then we can see the integration is very clear about which component was exchanged. The ABS one is being deleted or removed, and the other one added.

And finally, as a last step, just have to check on the SAP side, of course, to see everything is there.

So this concludes our first case study. We could see that the Fusion data API was able to provide the information which was missing before. And we are able to create an integration, which helps creating bill of materials and all the other things which are needed. And I think then we can go on to our bonus scenario.

So SAP configuration within the Forge viewer. So there are quite some configurators based on the Forge viewer. And they usually look like this. You have some selection fields with some predefined lists. So you can select what you want to include into the assembly.

Then you trigger the generation. And usually, you would use the design automation API in order to create a CAD assembly, and then maybe use Model Derivative in order to download the SVF in order to display it in the viewer, or to download a STEP file to be used later, or even provide the CAD model which was created in the backend.

So we had some customer requirements, which were going a little bit further than that. And these were, model once, configure anywhere. Basically, it means, OK, re-use your configuration which you already have instead of creating a new one.

Also, we wanted to try out a better user experience as intuitive as possible. So we wanted to make configuration by interacting directly with the graphics. And ideally, we wanted to have an immediate graphical response. So instead of generating an assembly in the backend and then coming back with the view file, we wanted to try to assemble the parts right in the viewer.

And also, we want to support the whole scenario right at the source of the CAD data. In our case, this was Inventor, and we wanted to test and verify all the configuration right in CAD so there would be no media breaks for testing.

So model once configure anywhere, if I'm looking at the bottom part, the SAP system, there is a strong configuration module right within the system. And it's being used in many of the processes within SAP.

So it would be nice to use exactly this information for processes which run outside SAP as well. And fortunately, this is available now. The SAP has provided a variant configuration and pricing web services running on the cloud platform, which can be used in order to have commerce solutions or sales solutions. Or for us, it was interesting to also create custom solutions.

So we had our first solution component. We had a configurator, and in the case of our customers, it was already in heavy use. And they were using it to create structures but without the graphics so far.

So for the viewer side, naturally, we looked at Forge viewer. And since we did not just have one completed SVF to load, we needed to somehow assemble the parts right within the viewer. This is an interesting task because, if you are looking at the two models in the top right corner, it becomes quite clear that the placement of components in the assembly depends on the placement and size of other components.

So if the component is a little bit bigger, then all of a sudden the neighboring components would then be pushed a little bit further away, and so on. So the idea was we would want to use component combination, having fixed components, put them together. And so, obviously, we needed some kind of a connection point system to stick them together.

And so we checked Forge viewer and looked at the API and said, OK, can we use it? And the prerequisites were can it load several models instead of just one SVF file? Yes. OK, very good.

Can be placed in the 3D space of the viewer? Yes, we can. Does it maybe even have a built-in constraint logic? Well, we didn't find any, so we had to do about it ourselves. And SVF is the viewable format, so we have to provide SVF files, so we have to convert our source Inventor files into SVF, of course.

So then let's go to the source, and the components our models would consist of in the end were created by normal inventor functionality. That's clear. But then we added a UI in order to support component creation for the model. So we wanted to define the named connection points. And then we wanted to test the logic.

So we implemented it like in inventor so Inventor would get access to the configuration service. And you would select from the options, and then Inventor would calculate our model. And it was, therefore, being used as a test environment for logical and graphical configuration.

So the component files would then be uploaded and converted to SVF. And of course, we need to store the viewables and meta information where the viewer could access them in the end.

So the final application logic in the viewer would then be OK to user interacts right with the component. And then the configuration system would deliver exactly the options which are available right now in the current state of the product configuration. Just think of, if you are using a car configurator, if you are choosing an entertainment system, some options turn on. Some other options to turn on, and some other options turn off. And this is the case here as well.

And after the user has selected this option, then the metadata would be recalculated. Components would be added or removed from the viewer as needed. And then the components would be placed according to the connection point logic. And I would say let's have a look at how this works.

So our model is a valve. It's a configurable valve, and let's jump right in. So the user can interact with the components, and if he selects, for example, a different set of screws, then they will be loaded. Or if he wants to find out what a blind plate is, then he can do so.

And to his surprise, he will find out, OK, it's not a for a valve but only the replacement part. So then do something useful and go back and configure a useful valve. And here we are.

And then after the valve is assembled, we can then go to the components and select their different options, like a different cable, and so on.

OK, so I think this is just enough to understand the logic of this. So at this point in time, in a live demo, we would go in to a Q&A session with a, hopefully, lively discussion. So therefore, I'm providing some contact information in order to have the chance to contact us and have some interesting conversations, be it about the technology, be it about the product. I am very interested in that.

So we have seen our two scenarios, and I hope you enjoyed the presentation and got something valuable out of it. And again, I'm very interested in continuing the conversation. So thank you very much for your interest, and goodbye for now.