AU Class
AU Class
class - AU

Harness the Power of the Manufacturing Data Model API: A Comprehensive Guide to Enabling Cloud-Based Workflows and Automation

Partager ce cours
Rechercher des mots-clés dans les vidéos, les diapositives des présentations et les supports de cours :

Description

With the Manufacturing Data Model API, you can read, write, and extend your design model through cloud-based workflows—all without the need for desktop authoring applications like Autodesk Fusion software. You can access granular, transparent data via GraphQL APIs, and programmatically access manufacturing information to achieve a variety of cloud-based automations and workflows more efficiently than with REST APIs.

Principaux enseignements

  • Learn about Manufacturing Data Model V2.0 and what you can do with the granular data and most common use cases and workflows.
  • Explore the latest features released or in beta with sample graphQL queries showcasing how to use the APIs.
  • Learn where to find API developer docs, how to use the interactive query explorer, and what's on the API road map.

Intervenants

  • Aditi Khedkar
    Aditi Khedkar is a Senior Product Manager on the Autodesk Platform services-Product Data organization. She leads the Manufacturing Data Model. As a Platform Product Manager, she is excited to drive the future of data granularity and interoperability that enable customers automate and collaboration through cloud data models. On a personal front, Aditi enjoys hiking and traveling.
  • Avatar de Kevin Vandecar
    Kevin Vandecar
    Kevin Vandecar is a Developer Advocate Engineer and also the manager for the Autodesk Platform Services Media & Entertainment and Manufacturing Workgroups. His specialty is 3ds Max software customization and programming areas, including the Autodesk Platform Services Design Automation for 3ds Max service. Most recently he has been working with the Autodesk Platform Services Data initiatives, including Data Exchange API and Fusion Data API.
Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • subtitles off, selected
      Transcript

      ADITI KHEDKAR: Welcome to the class, harness the power of manufacturing data model APIs, a comprehensive guide to enabling cloud-based workflows and automation. Let's start with a quick round of introductions. So my name is Aditi. I'm a product manager on the Autodesk Platform Services team, and I lead the efforts on the manufacturing data model and APIs and co-presenting.

      With me is Kevin Vandecar, senior manager on the Autodesk Platform Services, developer advocacy team. So starting out with a quick safe harbor statement essentially stating please do not make any purchasing decisions solely relying on the statements made during this presentation. Kindly read it. Absorb it at your convenience. And let's get started right into the presentation.

      So this class is going to cover a quick recap of the Autodesk data strategy. We'll start out with a quick introduction of GraphQL as a technology, what are the developer tools that work alongside GraphQL, and then we'll get into a detailed deep dive, where you'll learn about the manufacturing data model, what you can do with granular data, what type of data is available, along with some detailed example queries.

      And then we'll move on to some common use cases and workflows unlocked using these APIs that our customers are already leveraging. And then we'll move on to where you can find the developer documentation to summarize all of the resources available for you. And we'll conclude with our public facing roadmap and how to get in touch with us.

      So let's get right into it, starting out with the Autodesk data strategy. So over the years, we've seen three key trends emerging and accelerating. Our customers need more automation, whether it's to increase productivity, improve efficiency, or just faster time to market.

      And there's also a need for increased collaboration not just within organizations, but also across disciplines. And we're seeing a trend towards industry convergence across AEC manufacturing, and media and entertainment. But at the foundation of all of these trends lies data.

      So to respond to these challenges, our data strategy is focusing on three key areas. Data granularity, data interoperability, and data accessibility. And this presentation will focus on the first pillar, which is data granularity. So just to level set some of the challenges of today. Today files are still the smallest unit of collaboration.

      But as you all know, file-based collaboration is painful, especially as files are moving from different products to different organizations. There's a patchwork of standards, and this results in challenges like needing translations, or the fact that multiple disciplines are not able to work on the same design simultaneously. And this leads to a lot of teams maintaining multiple versions of the same file leading to mistakes.

      And lastly, this is making exchange of data across organizational boundaries rather difficult due to IP concerns. So it's clear that we need better design to make data management, one that puts together a standardized way of describing data that allows for real-time, or close to real-time, access to this data and ensures that all of the access controls are in place and honored so that the right data is available to the right people at the right time.

      To solve for these challenges, at Autodesk, our vision is to standardize and streamline the way data is structured, managed, and utilized within the Autodesk ecosystem of products and services, through the Autodesk data models, and democratize access to design and make data that's typically trapped within files so that our customers, such as yourselves, can deliver better, cheaper products to the market much faster.

      So just imagine a world where data and workflows come together across the entire product lifecycle. So within the Autodesk data model, we're building a data model dedicated to manufacturing that becomes a connected source of manufacturing data across the entire organization and external supply chains, allowing for data to move between desktop products like Fusion, as well as third party applications like SAP.

      The manufacturing data model represents granular design and manufacturing data in the cloud. And this data is now easily accessible through our Autodesk platform service APIs, and specifically, the manufacturing data model API. So I'm going to hand it over now to Kevin to cover a deep dive into the manufacturing data model APIs, starting out with the developer tools.

      KEVIN VANDECAR: All right. Thanks, Aditi. Yeah, so I'm going to share the developer tools and the approach on how you would use these APIs. So to start, I just want to point out that manufacturing data model API is built with GraphQL technology.

      So when you look at the left screen here, first of all, because we've implemented GraphQL in a very structured way for accessing your data, you can basically see how the data itself is structured, similar to how the product organizes its own data. So in this case, we're working with Fusion data.

      And you can see how things components and part numbers and even the Manage extension line up with the user interface in the GraphQL system and in Fusion. So why did we choose GraphQL? So first of all, this is an open-source technology that was created by Meta, the Facebook people, and they have open sourced it for the industry.

      And there's a lot of industry, companies using GraphQL already. And it is very easy to learn and very human friendly. So the queries are very natural. And like we mentioned, it aligns with the data within the product itself. And to address the granular promise which Aditi mentioned earlier, you can really request and create only the data you want and need.

      So it's very powerful in that way as opposed to something like Model Derivative, if you're used to our other API services. Model Derivative being a REST API, you basically get back everything when you query a model. And most of the time you don't need all that data. So this promise of granular data really shines with GraphQL.

      And then from an efficiency perspective, fewer calls as compared to REST. So you can create a very specific query, make the call, and get the data you want in a single call. You can even stack up multiple queries in the same call. So very powerful environment.

      So we're going to take a look at a couple of the tools that you will use to learn and become familiar with our environment. So this first tool is called the GraphQL-- GraphiQL Explorer. So GraphiQL is also an open source tool that we've taken and deployed against our data model.

      Now, the first thing you're going to notice is you need to log in so you're accessing your own data. So this would be data coming from Fusion and your Fusion Teams instance. And you basically can use this tool to execute queries and get back data and explore how your data is structured.

      You can use other tools as well. So if you're already familiar with some other tools like Postman or Insomnia, it works very much like those tools provide the support for REST APIs. You can make the same kind of queries within those tools. And I also want to mention Visual Studio Code.

      I don't have direct experience with this, but I did do a search. And even Visual Studio Code came back with 50 results of GraphQL-oriented extensions. So you can see that the industry has really embraced this technology. Within the GraphiQL Explorer, there's a lot of available information. So not only do you execute your queries, but it also helps you to learn the system.

      So there's Documentation pane on the left. There's a History pane as well. So you can actually open that up, and you can go back to queries that you made before. So in this particular example, you can see I called the Git model hierarchy multiple times. And you can see that history. I changed the query each time I called it. And you can go back to those states.

      The query window itself also has some helpers. So basically, as you're typing within an objects field area, a pop-up will show you what's available, what other fields you can query on. So in this example, typing something pops up the name as one option.

      And then you can also hover over each one of these fields, and it will give you documentation as well. And then I also want to mention the Voyager tool. So within the GraphiQL Explorer, we have a button in the upper left that you can click that will take you to this directly, but it is a separate tool. And you can use any of our schemas within this tool to learn them.

      So even AC data model and the Data exchange data model. When you arrive into the Voyager, it has a complete navigational aspect to it. So you can pan and zoom and move around. In this case, I've got the component version object up, and you can see on the left, in this central dialog, all the fields that you can query on.

      And then on the right, it shows you the object type. So because we are in a very strictly typed system, the schema defines those types. And this tool will help you to learn it. And then also notice that there is documentation here as well. So very powerful way to learn our schemas.

      And then finally, I want to mention, how do you actually execute your query code in a real web app or an application environment? So on the left, you'll see the GraphiQL Explorer again, and the query is listed there.

      And on the right is a JavaScript application. This is one of our samples. And you can see the query is identical. So the only thing you have to do is understand your existing environment, it could be .NET, JavaScript, whatever you like to code in.

      And as long as you can call the REST API endpoint, that GraphQL provides, that we provide to you, you call that endpoint with your query. And so it makes it very, very easy to adapt your queries into existing code base and even create new apps in environments that you're familiar with.

      OK, so we're going to transition into showing some of these queries. So we'll go into the deep dive now. So first of all, I just want to mention the developer documentation. So we just went to general availability for version 2, and the documentation set has been fully updated.

      I want to point out that V1 of this API is going to be deprecated. So you have until March of 2025 to migrate over to V2. We would really encourage you to do it sooner than later so you can ask questions. And the real thing is to take advantage of much richer environments. So lots more-- a lot more capability in V2.

      All right, so let's get started. So I have a demo that I'm going to show how to get started with the documentation, and we'll walk through the queries that are available for the data management layer. All right. To start our demo section, I'd just like to show the documentation. To get to it, the very first thing you're going to do is go to the aps.autodesk.com website.

      This is where all the platform services information is detailed. There is a documentation link here. I just want to point out, real quick, that all Autodesk documentation for APIs is now linked here. So if you're interested in other APIs, it's all in one place now.

      We have filters for the Cloud, or desktop APIs. There's some industry keywords and stuff. But the easiest thing I suggest is just search if you the name of the API you're going to work with. And today, obviously, we're working with manufacturing data model API.

      So I come over here, and this is the landing page. And this has some high-level information. But most of this will bring you directly into the documentation anyway. But the one thing I want to point out is the public roadmap.

      So as you get going with the manufacturing data model, if you want to see where we are, you can go to the roadmap, and you can check the status of various features and so forth. So that's kind of a cool feature. Let's go back to the Docs. I'm going to just go into the developer's guide. And that's going to take me to the overview.

      As we mentioned, if we went back up, you'll see that version 1 has been deprecated. We talked about that before. So version 2 is the default documentation now. So I suggest, if you're just getting started, read through this. Even if you've started with V1, we have a migration guide.

      And a lot of the demos that we're going to run today come directly from the step-by-step tutorials. If you haven't done anything in APS, before you run the tutorials, you'll have to go to this link, and it will talk about how to get set up, even in APS, so that you can register an app, get access to the APIs, and start working.

      Now, most of the tools-- the tutorials and the tools and things that we provide here are going to be executed through a couple of external tools. So first of all, the Manufacturing Data Model explorer is the most important thing here. So I'm going to show that here.

      So the first few queries that we're going to demonstrate have to do with data management. Now if you've worked with the Autodesk Platform Services before, formally called Forge, you might be familiar with data management already. We have a REST-- a set of REST APIs that handles data management as well.

      And the way the data is structured in our systems is that at the top level there's hubs, there's projects in a hub, and you drill down into folders and the actual designs. So we need to start at the top level to get the hubs. And we're working with our own data. And that's an important point to note here.

      When you first land on this page, it's going to ask you to log in. And you can see I'm logged in here, and it's going to now default to the version 2 API. So just make sure it's showing V2 API. If you use the Explorer before you potentially could still have a cache set and this could default to V1.

      So just make sure either you clear your cache or whatever and you start with V2 because these are the general availability APIs now. And again, this is my data. So these are going to be my hubs, my projects, and so forth. So I execute the top level, and I get the hubs that are available to me.

      Now, this is the main hub that I want to work with. So I'm going to use that ID to come over here. And I'm going to execute another query called get projects, OK? So this data is kind of linked one-for-one to the actual data that you would see in the user interface, for example.

      So if I come over here to my Fusion Teams, the project I'm going to be working with today is the manufacturing data model project here. And when I come over here, you'll see all of those projects that were listed on the other page. And you will find right here manufacturing data model, OK?

      And that's the ID I'm going to use for the next step. So I'll move over here to get project contents. And put in the ID for that project, and you're going to see the data within that project. OK. And there are certain things here. So now that we've gotten down into some interesting data, I just want to call out how queries are structured.

      The GraphQL piece is very well formed, so everything starts with either a query or a mutation. And most of the time when you're reading data, it's going to, of course, be query. And then you'll have something like a function name, and then within that you'll have the preformed terms that are used by the Autodesk information model GraphQL system.

      So for the manufacturing data model, these types are all part of that. And the common things, like folders and results and pagination, things that make sense across all the data models are reused. And so if you're interested in using AEC data model or Data exchange, you'll find these same query structures are present.

      All right. Now, let's take a look at the data that comes back. So first of all, results is an Autodesk term. It's part of our GraphQL implementation. And you'll find the interesting data is usually blocked inside of results. And this is how you query and get just the granular data you want.

      So whatever types you put in here is going to be returned. So for example, if I didn't want the ID, I could remove that, run it again, and it's just going to give me names. And let's just take a look at that real quick. So I'll execute it without the ID now, and you'll see it's basically the same information. But there is still an ID here because it's specified in a couple of different places.

      So the ID that I had up here, let's just-- whoops, I'll just put that back. You'll see after type name. There is an ID, OK? So that's how it works in terms of formatting and organizing. You can list these things as you want. You can use aliases to group the data into blocks if you want, and other GraphQL features, OK?

      So when we move over here to the data itself, you'll see we have the type name. So this is the type of this object. It's a design item. And if I scroll down, you'll see we also have some folders. And here's the folders. So if I wanted to go into folders, what I can do is I can get the ID of that. I only have one.

      So if we looked at this project, let's just go in there. You'll see that I only have one. And that's why here it's just one. And the name is miscellaneous. OK. So I'm going to take that folder. I'm going to move to the next query. And let's just make this a little bit bigger. Sorry for that

      And put in the folder ID. But we also need the hub ID so that it can get the complete details there. So let's do that. And now we run that. And now what you're looking at is the contents of that folder. So if I go over here and I open up that folder, you'll see those are the things-- those are the projects that I have there, or the design items, I should say. Sorry, design items.

      All right. So very structured way of getting access to the data that you're interested in working with. Now, we're going to get down into a specific design item. And so it doesn't happen to be in this folder, so I'm going to go back up to the project contents because it's at the top level.

      And the item I want is this two-ton jack. And I need its ID, so I'm going to take this ID. And I'm jumping over to get properties. And what we're going to do is just get some top-level information about that design. OK. So we've got some basics here, and this is really the steps that you need to take just to drill down to get access to your Fusion model data.

      Now while we're in this data management area, I just want to point out a couple of tips here. So complexity of your queries are important. And certain queries, for example, do take up a lot of resources. And when you execute those on your data-- and it really depends on your data. It's not so much about the query itself, but how much data that it's going to find behind it-- so you might get this type of error.

      And the way to handle this is use pagination, OK? So this query was supposed to get folder items by project, with passing in the project ID. So let's take a look at a different query that's very similar, doing the same thing but using pagination. So I'm going to switch over here. And you'll see this query now takes pagination as an input, OK?

      And in the variables section, there's the pagination. And I've set the limit to be 5, so that's going to be five items. OK, so now I can execute basically exactly the same query, but I've limited it to 5. Now, what you'll notice is the cursor comes back with this big long ID, which is basically telling the system that when you pass this back in want to get the next set of results.

      So we can run this query again. And instead of cursor being null, we put in that ID. And it has to be as a string. And now notice that design item, two-ton jack, reciprocating saw. So I've got the top five items there. And I execute it again. And now I'm getting the next items.

      OK, so this is the version 2. This one's the one that I happen to be working with. And now cursor, instead of having that big long ID is saying null. And that's because you've reached the end of all the items. So over here you got the error.

      And you probably just want to get in the habit of using pagination with reasonable limits so that when you're getting data back, it's a reasonable amount of data to deal with at a time. All right. To start-- So let's move on to some other queries.

      So model hierarchy has been something that was requested when we were going through version 1. And basically, being able to get that hierarchy in a single query. So this hierarchy of your model is really the source of truth of your CAD model. And it leads to bill of materials type functionality as well. So let's take a look at that.

      All right. As we said at the end of the last demo, we've drilled down through the data management. And we've gotten to the design that we want to work with, this two-ton jack underscore two. So I need this ID for that as a component version to do the get model hierarchy query. So I'm going to go ahead and execute this.

      And you'll see, basically, all the components within that design singled out with each one of its parents. OK, so it, it basically is creating the Bill of material type behavior that you would see over here in Fusion itself, and the Fusion Teams. So all the components, everything is parented in this particular one under the two ton Jack with a couple of things that's got some additional layers, OK?

      So when we come back over here, that's how it's structured, right? Everything is parented to the two-ton jack. Now, depending on what you're going to use this for, you may not even need things like the ID. And this is where the idea of getting just the data you need-- the granular data that you need.

      Let's say we just take the ID out, and we run it again. And now you have a little bit easier to read because the IDs may not be important to you. So you can see all of the components, their names, and you know what their parent is. All right, as we said--

      OK, so moving on to some more interesting data. So next, we're going to take a look at the component properties. We're going to also look at thumbnail derivatives. And derivatives mean, basically, some output file types, in this case. So we support STEP, OBJ, and STL at this point. And then we'll also look at physical properties.

      All right. The next part of the demo is to get component version information. Now, I'm going to start here with the get model hierarchy. And I'm going to look for the handle. So I'm just using the search within GraphQL. Here's my handle, and that's component version ID.

      So I'm going to come over here, and I'm going to paste it in this query. And you can see this is the component version. It has quite a bit of data that it's going to output. And we'll just execute that. And notice that the thumbnail is listed here. There's a status, a signed URL, and how long it exists, for when does it expire. OK.

      So first of all, here's the component version information. And it was the handle. It's also the part number and various information there. Now, I also want to point out that we asked for the thumbnail, and it came back very quickly and just said status success and gave me a signed URL. And that is the-- let's see if I can get this to show-- that is the thumbnail for that handle. And that's exactly what I wanted.

      Now, why did it already exist? I didn't have to wait for it to be generated. Well, that's because from Fusion Teams, I generated a bill of materials to show that model hierarchy in the previous demo. And so the thumbnail is already there, which is very cool. And it can just basically grab the thumbnail from the system, and give it to you.

      Now the URL itself is timed. So these are signed URLs and for security reasons, they really shouldn't be cached or used in a database or anything. What you should do is actually get the thumbnail, and then periodically check if things have been updated and update as you need to.

      So now, let's get a thumbnail that hasn't been generated. So I did go ahead and modify this model before. So I had 44 components before and now I have 46. So I added two things. Whoops! So I'm going to do a search here for floor.

      And what I did was I basically created a new component called floor mat. OK, so I'm going to take that one, and I'm going to come over to get component version. And I'm going to execute the same query. And you're going to see a little different behavior here. OK, so instead of giving me back the thumbnail, it says pending.

      And that's because I haven't generated a new bill of materials. But from the API, I'd like to get the thumbnail for that updated component or that new component. And so I can ask for it. But now because it's processing, I have to do what's called a polling technique.

      And polling just basically means you execute the query every few seconds until the status comes back successful. And then now you can see I've got the floor mat. OK, so I had to execute this twice in order for it to finish processing.

      Now it was just a convenient step to put this thumbnail with the component version. And that shows how you can combine queries together and ask for things all at the same time. But if all you really wanted to do was get the thumbnail, you could also just have a query to get the thumbnail. And in this case, I think it's a different item. So it's the filler plug.

      So very flexible system. And again, if it wasn't existing, you would get back a different status, and you would need to pull until that job is done. Now, in this next demo, I'm going to show how to get some derivatives. So just calling the query get geometry.

      And you'll see the way the query is formed that there's derivative input, output format. And this is where you would specify what type of output you want. So in this case, I'm going to get step, which is BREP. And, yes, I want to generate it. I had executed this before just to test it, and this was the filler plug that I asked for.

      I'm going to go back to the model hierarchy. And I'm going to search for the side component. So side member right. I'll take this component ID, I'm going to go back to my query and my component version. And I'm going to execute that. So again, because this is a generative process, and you're requesting it to be generated for you, you're going to have to do polling again.

      So we see the status is in progress. And we don't have any real data about it yet, except that it's a STEP format. OK, so I did some polling. And I'll just run it one more time, and you'll see that it is now successful. And here is the URL for that file. Now, again, these URLs are timed, so just make sure you use it within the amount of time.

      And I'm going to go ahead and download this. So 0008b. I'm going to save that. And I just happen to have 3ds Max running here as a way to show that STEP component. So I'm going to open that up. And need to go to that file folder. And there's that 008 that I just exported. And I'll just say import, and there's that geometry. OK, so nice STEP file format.

      All right, now let's move on to physical properties. So basically, again, there's quite a bit of data here. And you can see in the query this is where the term granular gets really important because you can really ask for what you want. So in this case, we're going to get as much as we can.

      So we're getting mass, volume, area, density, bounding box. And when you execute this-- this is also a generative process. And so status is here. And you're going to see status-- where is it? right here, completed. So it was already generated, which is great.

      And so now I have all of my physical properties. There's the mass, the volume, the area, density bounding box, which is length, width, and height. OK, so very cool to get that back. All right. The next part of the-- OK, we're going to also look at some additional data that you can get.

      So we also support the Manage Extension properties. So within Fusion, Manage Extension is an add-on. And if you have that component present, it's going to help with life cycle information. It kind of overlaps a little bit with the Fusion Manage product.

      So even Fusion Manage can update some of this data. So that life cycle data is available to you. So let's take a look at a demo there. All right. We're going to look at the Manage Extension properties now. So very similar component version ID. We can execute that.

      And now we're getting life cycle information. OK, so working, item number. And remember, this is part of the Fusion Manage extension, which overlaps some functionality with the Fusion Manage service. All right. OK, and we'll also take a look at the project admin APIs.

      So this is the first time you're going to see a mutation. So we'll talk a little bit about that. And it basically allows you to also administrate your projects in an automated fashion. All right. Now, we're going to show some of the project admin features, just going to demo a couple of things here just to show how it works.

      First thing to notice is that this has now becomes a mutation. And the difference between a query and a mutation is that you're actually creating data with a mutation. You're actually changing the data model. So that's why there's a different name for this type of operation.

      We also need some input. We need the hub ID and the name. And if I go all the way back to our original query, you'll see the hub that I've been working in is mine Kevin Vandecar, and it ends in 6b8. OK, so that's the hub that I need to use.

      I'm going to go, whoops, all the way back over here to create a folder-level project. And this is the name, so I'm just going to go ahead and execute that. And you're going to get some confirmation back as to how it worked. OK, so basically, when you get back this data, it was successful. All right.

      And this is the ID of the new project. And this is the name of the new project. So let's go over here to Fusion Teams and just see how that worked. So I'm going to need to refresh this browser. And it's loading up that. Let's just go up to the top here. And there you can see my test project, triple a test project. So it worked.

      OK, now that we know that the project exists, and we looked at it and made sure, I'm going to take this new ID. And I'm going to add some project members. I'm basically adding myself, my personal email address here. And you need the project ID. So you saw me copy that from this newly created project. And I'm going to add to that.

      Now, if the project doesn't exist-- I did execute this before with a bogus information just to show that can get an error. So you have to pay attention to some of these things. But now that I have the right project ID, it should succeed and everything looks good.

      And basically, this email address will receive an invite to that project. And if we go over here and check this and we open up that project and we look at members and permissions, now you can see that Kevin, in the meantime .com, was invited to it. OK, and I just have this lowest level, which is called viewer permissions. All right now--

      And just a couple more features. So custom properties is now also in general availability. And with custom properties, what it allows you to do is augment the data model with custom data, of course. So there's two aspects to this. And the first one is the developer environment.

      So you, as the developer, you could be a commercial developer maybe in house, but you want to have some common properties across all your projects, in your developer environment, you're going to create the property set. And this is basically the properties with the names and the types of those properties in a collection.

      And then that collection will get linked to a hub, and then the data will inherit those properties and have specific values. OK, so a single collection could be referenced by many hubs as well. So you have a lot of flexibility there. And then finally, I want to point out a feature that was added, as well, to the V2, Configured Designs.

      So this is a feature within Fusion itself, and it basically allows you to configure your components with different types of output, or different configurations of the assemblies and parts. So I encourage, if you're not familiar with it, to look at the product documentation, this will be in the handout. But also look at the API docs and how Configured Designs work.

      So basically from the API perspective, it's the same structure. So for example, we do a component version query. And then there's this flag for is configuration. And so you can basically check and get additional information about the component, and whether it's a configured design or not. And with that, I'll switch over to Aditi, and let her continue.

      ADITI KHEDKAR: Great. Thanks, Kevin. So you heard a lot from Kevin in terms of the details on the extent of granular data that's available through our APIs. As we continue our journey, though, from connecting our entire software portfolio to the data model, already our customers today, are realizing great outcomes from the connected data.

      So using the APIs to extract, transform, and integrate their design and make data from Fusion and build custom cloud powered workflows that automate processes, connect applications, and integrate with enterprise systems is already resulting in improved collaboration, faster time to market and cost savings and much more.

      So I want to just walk you through a couple of demos that some of our customers have built on top of the manufacturing data model APIs. So here's one partner, OpenBOM, that's taking advantage of our manufacturing data model APIs. And using the APIs, they can access a designs part list and properties, as Kevin mentioned.

      And this really enables them to automate the bill of materials and seamless navigation into the part hierarchy within a model. So most times creating a bill of materials is an often repetitive and manual task. And now, through the APIs, this can be automated pretty seamlessly. And this really enables faster purchasing, procurement, or manufacturing decisions downstream.

      In addition to automating the bill of materials through custom properties, that Kevin just talked about, OpenBOM has now been able to add supplemental information like supplier name or surface data back into the design, which allows Fusion users to see this information within Fusion experiences.

      Here's another example of a partner named Prototek that's using the manufacturing data model capabilities, again, to pull the entire model hierarchy of the design into their web application. And then using the component properties that you just saw, like mass, volume, density, material, they've leveraged this data to analyze a design's carbon footprint and water use for sustainability analysis of the design. And not just that, but write it back again to the data model is custom properties.

      And this is really accelerated decision making and sustainability goals by integrating sustainability into early stage product designs so that you can build designs with better, sustainable outcomes. So, I know you heard a lot. We don't expect you to remember all of this.

      But I just wanted to summarize on where you can find all of these resources. Kevin touched on it right at the beginning, but there are two places that you can start out, so I highly recommend, if you're very new to the manufacturing data model, you can start out by looking at our solution landing page, so on our Developer portal under Solutions.

      Manufacturing data model will take you to the Solutions landing page. And this has a good set of resources in terms of customer success stories. What's the benefits of manufacturing data model? It's got a link to our public-facing roadmap. And this is a good place to also stay in touch, and on top of what are the upcoming data events that we have, or any upcoming releases that have happened, as well as links to our blog post.

      And once you're ready to deep dive into building your applications, or just want to tinker around with the APIs, head right into the developer documentation. And as Kevin mentioned, this has a ton of data, ton of information, like step-by-step tutorials to get you started.

      It's got the Query explorer for you to at least use it as a sandbox environment on your own data to get you started. And once you're ready to actually implement your applications, there's also sample codes that you can just plug and play within your code to jumpstart your development.

      Again, really quick reminder, we are now generally available with version 2 of our APIs. This is the latest version. It comes with a host of new features and improvements that you just heard. So I highly recommend, if you're just starting out, start out with version 2 of our APIs.

      And any existing customers using version 1 of our APIs, again, I highly recommend that you migrate over to version 2 of our APIs as we will be deprecating those and ending support by March next year. So definitely move over to V2 ASAP.

      And as Kevin mentioned, we have our public-facing roadmap that helps you keep track of our plans, what gets implemented, what improvements we're considering. So it's a really useful place for you to keep an eye out on what we've planned now, next, and later. It also gives you an opportunity to upvote on features that are most important to you. So it helps us understand what we should be building first versus next.

      And it also gives you an opportunity to tell us what features you're interested in that you're not seeing on the roadmap. So it helps us plan those features as well. And if you would like to get in touch with us, there's a few different ways to get in touch with our teams. So you can head on to aps.autodesk.com, get help.

      And three different ways to get in touch, you can either use Stack Overflow, a really great place for asking technical questions you might have. If you want to schedule a meeting with one of our team members, just go through the Schedule a meeting link.

      And if you'd rather just get in touch with us through a form, you can use the Contact US form and reach out to us. So with that, I think we'd like to say thank you for listening. And I'm looking forward to seeing what you're going to build with the manufacturing data model APIs.