Autodesk Data Exchange: Connect to Your Data

DENIS GRIGOR: Hi, everyone. Welcome to Autodesk Data Exchange Connected Data Presentation. My name is Denis. And along with Greg Henry, I will be presenting this at AU live. But this is a recording specially designed for you in order to gather everything and be prepared for AU or if you cannot make to AU, this will be of a good benefit. However, from this perspective, apart from the safe harbor statement, which we usually do because we will be talking about the technology in progress, and some plans, and things like that-- and of course, you should not make any business decision based on that one.

Another warning is that this recording is two months before-- is taken two months before AU so a lot of things might be changed because the technology we will discuss today is still in beta and a lot of things might change. A lot of things might improve. So if I'm talking about weaknesses, this is the weaknesses at this date in September. By AU, let's hope a lot of weaknesses will be solved, or mitigated, or things like that.

So keep in mind that this presentation might be outdated by the day that you are looking at. However, I will update the slides so along with this video, you will have also the slides. I will update the slides in order to make sure that it will match the changes, especially when it comes to code snippets and things like that. And also in hands out, I will also put as much information and even put marks that this changed from the presentation so you can come benefit from it.

So in this presentation, we will look at the big picture about the data, datacentric approach, and we will see a lot of things. It actually will be a high overview because I'm pretty sure that during them you will see a specialized presentation about different technologies, about different models and things like that. But this one is presented-- well, I took it as a kind of-- I put it here just in order to explain you what is the place of data exchange in all these kind of big picture.

And of course, with this big picture, we will talk about the kind of industry challenges, and data platform strategy, and actually what is kind of the technology that is there, but also where actually the data exchange is set into all these kind of picture. What is the role? And you will see that it's kind of interesting and quite important. Then we will look at data exchange under the hood. In order to use at maximum any technology, you must understand the concept used. You must understand how it's actually structured under the hood.

Of course, you can limit to just use the API or things like that. But if you understand how it is organized, you can make most of it. So this is what we will talk in the second part. And the third part we will talk about tools to connect your data. So we'll be talking about the API, about the SDK plans, why historically we use some technology and things like that, and of course, we will be a lot of live demos and a lot of code snippets. So I hope that you will find it interesting. But again, before going into the meat of the data exchange, let's look at the big picture.

And of course, these kind of datacentric paradigms didn't came out of nowhere. It came based on problems. And we can distinct kind of three types of challenges you may say. Of course, the main thing is that the collaboration across industries is fragmented but not only across industries. Even inside any industry, the collaboration is very, very fragmented. And even if we take the Autodesk itself, there is a fragmentation within and their problem with tools and ecosystem even within the same company.

And this is, by the way, the thing that we try to solve, we at Autodesk, we try to solve, because first problem is that this diversity of ecosystem and tools, even inside in the industry, even inside a company, creates challenges in sharing the data across different apps, kind of different parts of the things. And we will see it later.

For instance, let's say that you want to share some doors from Revit into a 3ds Max or vice versa. Well, the door in Revit, it's parametric geometry. In 3ds Max, this is just a mesh. So it's a collection of vertices and connected through edges. So you see it's the very same data but, depending on the product, it requires a different approach. And this is one challenge but it's not enough because we also have the cross-company workflows.

So imagine that you want to share the very same door with let's say a provider or vendor without sharing the entire Revit file. So you need a subset. You need to share just the subset of it but also to put it in context so it's not a door or how to say in void. It's a door in a wall. It has certain properties and things like that that you also would like to share. So this is basically sharing a subset of the model itself.

And of course, the third one, which could be kind of outlined, is the increasing project complexity. And this comes-- well, a good illustration is actually the versioning of the file. So yes, we have version one of a project. Then we want to modify something. And we have the version two. And then we want to share something with someone. Which version we will share? Version one, version two?

So we see this is kind of-- when the project is just starting, it's very simple. But when the project aggregates a lot of hours of work, then it becomes kind of complicated. Because you will end up with different versions with different, I'm going to say, settings, different needs, and things like that. And every kind of version is specialized to a certain thing.

So this is the one thing that basically, we want to or we strive to solve and taking a little steps in order to do that. So let's look at the schematic overview. We have here-- as discussed, we have a file, a design. We have two versions of it-- so, again, the problem with versioning, the problem of sharing this version.

So we have a Revit file, and we want to share it with another company. So it's a challenge, the cross-company challenge. You have the security problem. You have a lot of barriers. And moreover, it's not the same application.

So it's Inventor. So you not only have to share the data, you have to share it in such a way that it could be consumed by the company and the product that the company's used. So as you can see here, there are a lot of challenges just moving the data, keeping track of the versions and things like that. This is a pain.

And, of course, the train of thoughts is the following. We have the file. Now, having this file, what is actually the idea of this file? The file-based approach or file-based sharing is a problem because, again, of the versioning. And you cannot share the subset of files and things also.

So the very first step is to identify the valuable bits of the data and basically decompose this data into something atomic. But data, again, they don't exist just in void or in the limbo. They exist connected with the file. They also are connecting between them. So

A very good approach is just to put it in the cloud, where actually, we keep track not only about these bits of data but also version of these bits of data and the relationship between them. And now having this kind of approach, where everything is in one place and there is a relationship and things like that, then these bits of data could be shared individually. You don't have to share the entire file. You don't have to share the entire model. You just can share subgraph, so only the bits that is needed.

So this kind of data model is the main idea. And this is why I told you that during the AU, this will be the main theme. So the idea is to build the data models for design-make industries, so specific industries. So it will be like manufacture, architecture, and construction and multimedia entertainment.

And the need for that is because you cannot use a silver bullet. You cannot just use one-- well, like in Tolkien, one ring to rule them all-- or at least, not yet.

Now imagine that in multimedia entertainment, any model, let's say, they are more interested in mesh, texture, rendering properties, and so so forth. While in case of Revit, it is not interesting in mesh, textures, and things like that. It's more interested in model and properties. And the model is parametric in this case. It's not a mesh.

Pretty the same thing is in manufacture. But there, you also have additional information, like tool paths and things like that. So you see it's something like-- it's specific. However, here comes the Data Exchange. So the Data Exchange is the tool that will be used in order to assure the interoperability between these models. And not only that, because actually, the Data Exchange will be used in order to access these models.

So as you can see here, it's between models and also to access the model from the different count application. If we go back to the initial picture, the challenge that we have-- so we have version 1, version 2. We have different companies and different product and things like that.

This is the idea that if we switch to this model, where actually, everything is granular, kept in the cloud-- and moreover, everything is versioned. There so there is no problem to share a version 1 with one customer with one product and share the version 2 with another product.

And moreover, later, we will see that if-- let's say that I have a model of version 2, and I shared a sub-version of it. And then later, this model is updated. The customer-- or, let's say, the consumer of the data-- can automatically get the latest version of that subset of the data. But we will see this in practice.

However, the main idea is the following, to standardize collaboration with source data in the cloud. So it should be a standard approach, how to store data, how to access data. And the most important is how to share subset of data. And we will see later that this is possible because of the data structure.

Before going into meat of the thing, of course, we have to understand the concepts and understand the structure. The concepts are needed because we will be using them all over the place. And they are not difficult. But there is a requirement to understand them, only because for you to make sense about what we will discuss next.

So as you can see here, it's actually just six concepts, very simple-- collection, space, assets, relationships, snapshots, and revision. Collection itself is-- let's say it's something like the environment where, actually, this model exist. At least, for now, the collection is the project that you have on ACC. So it means that the collection ID will be the very same for any exchange that you will have in the same project.

A space here is one to one with the model itself. So the space is just sort of container of what exists in this model or this graph. Relationship by itself-- well, actually, the assets by themselves are the nodes that will store the properties or keep track of the properties. We will see later, for instance, a wall will be an asset. A door will be an asset and. Door and a wall will be linked through relationships.

And each asset will have some properties. But also, relationship can hold properties. So this is like contains a type of relationship. Or it associates type, things like that.

Snapshot and revision, this basically comes together. And this is something like-- well, snapshot itself is something like capturing the state of the graph. So if you have version 1, it will be one graph.

Now, imagine that you're removing the door or adding another window. We'll see later. It means that, actually, it will be added something and modified something. So, for instance, if you're adding a new window on the wall, the wall will be modified, and the window will appear. However, keep in mind one thing. Let's say that we are removing a window from the wall.

Yes, it will be marked as removed. But the graph itself will not delete this node. We will not delete these assets. And this is the interesting thing, is that, actually, version 1 from version 2, it's actually a snapshot of the graph at state 1 and snapshot of the graph at state 2. So no matter what kind of deletion, modification you do and things like that, you will always have the picture how it was before and how it is now.

Because the history is tracked through all these kind of nodes. If the asset is modified beyond recognition, it will just be copied. And the relationship will be marked as removed in the subsequent version or things like that. Again, we will see it in more detail.

To reiterate again, let's look at this schematically. So each model is a graph. Each node here is an asset. And all these assets basically are related.

And if we look at a very schematic house-- so in this case, this is the graph that it's related to this kind of model. And each element here, bit-- wall, bit, window, door, and things like that-- is actually not only exist as a node but also as a relationship between them.

So, of course, there is a relationship between a window and a door or a window and a wall, a window, a door, and a wall and, of course, relationship between walls and roof, and so so forth. So a lot of relationship is here.

And this is basically like a web of related data. And as you can see right now, if we change, let's say, moving the door in the wall, this will not change the graph. This will change the properties of the wall. Because the wall will have that socket for the door. The door, the asset will be the same. Just the properties of the wall will change.

However, if we add another door or another window, this is additional node, additional relationship and so so forth-- if you are deleting, the very same approach. And as you can see here, this kind of granular approach allows you to basically access only the elements or share only the elements that you need.

So, for instance, let's say the roofing company needs access only to roof, only to roof geometry, only to roof properties and things like that. They should not care about what is the position of the window or things like that. They are just interested in the roof itself, the geometry and things like that.

Also, we could be interested only in windows for different statistics or for walls in order to compute-- I don't know-- the hitting index and things like that. We, again, can share only subset of the data because these are the nodes. So we're basically sharing only the nodes that we need and the properties that we need. And if there is a relationship, that is also included in these things-- also, the relationship.

And again, these things can be changed and shared and things like that and the versions and used by third-party developers and things like that. So now let's switch to the user-side demo. Because the Data Exchange itself is basically two parts.

The first is user approach to create exchanges. And the second part is the API or developer approach in order to access these data. And let us switch to ACC. I prepared here some models.

Right upfront, you can see that the Revit files, of course, will have their own icon. And the Data Exchange-- or Exchanges, what we called-- will have their own file. Now, keep in mind one thing.

In context of ACC, if you place here a Revit file, you can see the size and things like that. But when exchange is created, it will have size 0. Because this is basically not the exchange itself. This is a pointer to exchange. So imagine that this is a pointer to the graph that exists there. And, well, you need an entry point. And this is why it is available here as a file.

And the workflow is very simple. So let's take an example. So I have the Revit file here, and I have different views here. So let's say that I'm interested in sharing only this part of the model instead of sharing the entire model, which could be huge and contain a lot of data, maybe even property data and things like that.

And I'm interested just in stairs, so why should I share the entire model? And the thing is that I can easily create the stairs. And as you can see here, automatically, you can see the number of objects. It will include the geometry, and you include the properties. And it will include the 3D view. 3D view's basically these kind of-- the viewable.

And I can create an exchange. Now, one thing to keep in mind is that if we will create, you will see that this is version 1 of it. However, the office building is version 2. Now, the question is that, well, actually, how come?

It's very simple. The exchange itself starts with its own versioning. And, for instance, I have here other two exchanges. And I can see that if this is exchange matched with the Revit version, it means that this exchange was created using the version 1 of the Revit file. And when the version 2 appear, so the Revit file was updated, the exchange automatically updated itself.

So now we'll update the Revit file and make it version 3. All these, which are version 1, will be automatically updated to version 2. And this one will be automatically updated to version 3.

And here it is, our stairs central model, should load. Or the variable is not yet ready. So exchange is there. But the viewable, I see that it's not yet. However, it doesn't matter.

What I want to [INAUDIBLE] about that is that in Revit file-- let's take a view that actually changed from the version 1 to version 2. So when looking at the Revit file, we can see-- here, let me put the very same thing. OK, so I need the version 1 of it.

OK, and I need to-- not this one-- I need south. And I will. Compare so, here you will have highlighted what actually changed from this one or which element actually changed, so this one and this one. But the main problem with what we have here is that, first of all, it's very hard to understand.

Yeah. So, for instance, this one was modified. modified from what to what? So I need the properties, what actually changed. Well, the volume changed, the area changed and so so forth. This was an addition. So this allows me-- this diff tool show me the difference, illustrated things, but not the properties that I might be interested in.

And we will see that Data Exchange actually allows you not only to identify the elements that were modified, added, or removed but also, it will allow you to show share the properties. And this is the main benefit, is that an exchange will contain this information. First of all, it's because we have different versions.

OK. I see that the geometry for this one is not yet there. But as I told you, I've already prepared for this video this example. And we have version 1, and we have the version 2 of it. And we can see the difference.

And then as a developer, we will see how we can access different-- this very exchange in order to get the properties to identify the elements that changed and things like that, which will allow us to do that, not graphically by clicking something, but by using the API, so basically, creating a headless approach that will-- let's say that you can have a workflow anytime when a Revit file is updated and you know the exchange is updated.

Let's say you can use the webhooks API in order to subscribe these changes and automatically prepare a report that will show you only what changed between version and 2 of the exchange that you need, so basically, the part that you need, exactly like in this case. So, for instance, if we were to update the model from version 1 to version 2-- as we saw, the only difference is adding a wall to some kind of south wing. The stairs will not be affected.

So from this perspective, yes, there will be a new version. But if you look through tools, developer tools, at what changed between version 1 and version 2, it will say like nothing. It just keeping track that the model was updated. So as you can see here, it's quite neat. This is, again, the user approach.

Now, next, we will look at what is actually the tools that you have at your service in order to access this programmatically. Again, this is very useful, especially when you want to implement something like headless approach, with reports automatically generated created in a pipeline and things like that. But before going into the tools, a very important thing to understand is basically the workflow.

Well, I cannot say that it's very important. Because anyway, this is abstracted by the tools themselves. But you just have to understand when someone says something like, OK, I created an exchange. I added a properties and things like that, but I cannot see them. Well, this is because you didn't basically publish the exchange.

So this is exactly like for any developer who knows version control, something like you can do anything that you want there. But unless you commit and push the changes, they will not appear in the remote repo-- exactly the very same thing.

So when we will talk about the writing and creating exchanges, keep in mind that it will require a publish step. That is important. And, of course, when it comes to getting the exchange or using the exchanges, it's just straightforward, use the exchange.

So now, what we have, as a developer, at our service? Well, let's say that historically, there were three tools-- REST API-- well, I would rather say that it was, at the beginning, just the REST API.

But the REST API was very difficult, difficult to use, yes. It's because it was giving you a huge JSON that was trying to mimic this graph approach. And it was daunting because-- imagine that it will have assets. It will have relationships. And each asset and relationship will have components. And each component will hold different type of properties and things like that. So it was very intimidating.

It was very powerful because you basically can download the entire graph and process on the client side. But this was the main problem, is that it was not consumable directly. It required a lot of post-processing at client level. And this is why the next step came, the GraphQL implementation.

So imagine that GraphQL is basically the very same REST API, is based on very same REST API. But it's doing the post-processing for you and allows you to use filtering to get only the fields that you need. Again, we will see that later in the hands-on experience, which is very neat.

Someone might say that it's a bit [INAUDIBLE]. For instance, I like it. Someone might say that, no, if I were to implement this kind of overlayer, I would do it other way and things like that. This is the only drawback that I saw. But actually, it's not the only one. We will see it later.

And, of course, the GraphQL approach also is very good from consuming point of view because it's language agnostic. So it means that you have GraphQL, the SDKs for Python, for Java, for different languages. So it's very simple. But I will show you that even from this perspective, it's not a big deal. You can even consume it from terminal.

So this is where, actually, came the Data Exchange SDK. So the Data Exchange SDKs is kind of implementation, the SDK implementation of the REST API, plus a lot of additional things. The only drawback that I see so far is that it's available only as a C# SDK and Windows only because it is based on framework 4.8.

This is the only drawback that I see in the Data Exchange because it's limiting you to basically desktop. If you want to use in a cloud and things like that, yeah, you can use different things, like Docker and Windows instances and things like that. But you have to work very hard in order to do that.

What I can tell you is that the engineering team is working on that to make it something like Linux friendly. But again, I remind you about the safe harbor, I tell you what I know, but it doesn't mean that this will be fulfilled this year.

OK, so let us start with the very first one, the GraphQL approach of accessing this data. Well, here, the benefits of the GraphQL is that-- as I told you, it tried to bring a lot of sugar into the data.

So if you are consuming the data, you want it in certain form, you want kind of to be consistent and things like that, GraphQL itself allows you to do that. And the experience with this was very good. I mean the implementation of a GraphQL over the REST API or instead of REST API.

And this is why it's a technology that's worth learning. Because it will be widely used within Autodesk. So most probably, all API that are now available as a REST API will have a GraphQL approach. And actually, from this perspective, you must understand that-- for instance, in GraphQL, they had to implement a part of data management.

So the Data Management API right now is accessible only as a REST API. But Data Exchange team tried to make it consistent. So if you want to use GraphQL in order to access Data Exchanges, then in order to get to that Data Exchange itself-- or navigate, as we saw in ACC-- in order to do that, you also will require GraphQL instead of switching between REST and things like that.

And so they basically created a layer of Data Management API, a kind of GraphQL implementation. However, keep in mind, one thing is that, yes, it allows you to get the hubs, to get the projects, to get the folders and things like that. But that's it.

So it means that allows you to navigate up till exchanges and see the exchanges. It is not a replacement of Data Management API. Because it will not expose the Revit files. So, for instance, if you will use this API, show me everything that is in folder, it will show you only the exchanges. And you will see this when we will do a hands-on approach.

And the second warning is that the GraphQL part of data management doesn't contain all the information that you need. So, for instance, if we compare what you get from the hubs using Data Exchange, the Data Exchange GraphQL, Data Management QL part-- so, for instance, you can ask, like, give me hubs. And it will provide you-- this is the maximum information that you can get.

So, for instance, you get just name and ID. However, there, you see, in case of a REST, you're actually getting a lot of information. Plus, the very important one is the region. So in this case, I know it's US. What about [INAUDIBLE]? No idea.

So as you can see, it's still in development, and it's not a replacement of Data Management REST API. It's just kind of facilitating you tool to navigate. And let us look at the GraphQL demo. I will show you different approaches, and I will use different tools for that.

Well, first of all, let us switch back to documentation so you can easily navigate through the documentation. And then I will show you a tool that will help you to learn the GraphQL API part. OK. For that, I will switch to the browser. That should show me the tabs.

And here, I have the ACC. And as you can see, the path is the following. So I have a hub. I have the existing project. I have the project files. I have the folder that I prepared for AU. So this is the path that we have to traverse in order to get the exchange that we need. And we will be using this exchange because it has two versions, and it has some changes. And we'll play for that.

But let us go to the documentation. So if we look at the documentation itself-- we're interested in cloud 1 and exchange-- we see that we have the SDK and API. And we have the GraphQL API. And we have .NET SDK, and both of them are in better.

Again, a warning that by AU, a lot of things could be changed. A lot of things could be improved. So the weaknesses, the things that I'm talking about is just at the state of today, like, two months before that.

And here, we have a couple of tools. So the very first tool that we have is so-called Data Exchange GraphQL Explorer. It's a very nice tool because it allows you to basically navigate through all these kind of thing.

OK, so I have login-- I must log in. I am log in-- and GitHubs. So you see, this is the thing that I need in order to do. It's basically the hubs. And you have here, the documentation. And I'm interested in name and ID. And here, I have the results.

Now, if we look at the documentation of the GraphQL API, you will see here that there is an API reference. And we see basically the GraphQL endpoints and the queries. So these are the queries that are needed in order to understand.

And it might be daunting to learn everything like that because some of them have properties. We will see that it gets even more complicated when I want to use filters and things like that. So, for instance, very interesting-- hubs, results, name, id-- how do I know that there is a name and ID? And how do I know that it's only name and ID? And I can look it through documentation and figure out by myself that this is the fields that are important, look through examples and things like that.

But there is a nice way that I use myself to learn not only the Data Exchange GraphQL API, but any GraphQL API that you want. So this nice tool comes from-- well, I don't recall the name. But it's very nice. It also can be used as a learning tool of GraphQL itself.

But what we're interested is, basically, in this tool to show us the complexity of this API itself. And it has a very nice approach. So, for instance, we go to the schema. We go to Introspection. And we copy the introspection query. Now, what is that it's basically a query that will gather all these nodes and relationships and things like that and create the graph of all this relationship between the API calls.

And I'm using for, as my tool, the Postman-- could be used Insomnia, could be used anything that you want. And this is basically the thing that I'm calling. And I will get back a huge file. I have no idea what it does.

Well, it's interesting to look. But I think that it's more interesting to look at how it has interpreted this in this tool-- and, as you can see here, very nice tool in order to learn. I see automatically here, this is the entry points, so how, actually, I should construct my query.

And as you can see here, for instance, I have hubs, results, name, and things like that. How do I know about these things? Very simple. If I'm going to the hubs, I know that it will give me this page. So it will give me the results and the array of hubs.

Now, what is a hub? Well a, hub contains ID and the name. And it also contains projects. What is the project? Well, again, the project will be something-- and so so forth. So basically, I can navigate and construct these kind of query.

So if I will go back to this kind of tool that we don't need, I put it here in order to show you how I structured this API. If we look at documentation, there are different calls. But I structured them into two categories.

So the first one is navigation, so anything that I need in order to drill down to these exchanges. So what I need? Very simple. I can get the list of the hubs. OK, give me the list of the hubs. Once I have the needed hub, then I can use it in order to drill up the project and so so forth.

So this is basically the REST approach. So if you are familiar with the Data Management API, this is how you do. You make a call to get hubs. You make a call to get projects. You make a call to get folders and so so so forth.

What is nice with this tool-- and the hint we saw in this kind of node-- is that, actually, you can not only ask for ID and name, but you can make it more complex in one call. So it's basically something like, OK, give me not only ID and name, but give me the projects. And in projects, give me the name and ID, so basically, everything, for every project.

OK. Give me the ID. Let me update my token. Authentication of course, is important for every call that you make. And it requires you the [INAUDIBLE] authentication. So let me put it this way. And I want to put it as a token.

By the way, the Postman collection that is listed here-- so all the steps that I'm showing you-- they will be published online and in handouts. I will put the link to them so you can try by yourself. So again, going back to this one, the call will make, and I will get all the projects that I need, all-- well, basically, I will get all the hubs and the projects that I need.

So basically I can find that I need under this-- this is the environment that I'm using. Basically, this is the project that I have. And as you can see here, it basically kind of allows you to do a more complex thing in one query.

Now, keep in mind one thing, that this is based on REST API. So it means that-- well, it will have or it will require some time in order to get all the hubs and for each one to get all the projects and publish for you. So it's not something like a free performance or things like that. This is more a convenience.

Compared with the REST API is more-- I can say it's on par because it's optimized and things like that. But this solve saves you time for the call itself. And remember, I was telling you that there are libraries in order to get this call and things like that. So if you want to integrate this call in your project, well, a nice feature of this tool that I'm using is that you can say something like, OK, I need-- let's say in Go, this kind of thing-- well, not Go.

It's not a very good example. I think Python is better-- OK, using these library requests. And, of course, this is the token. So it means it will be in your environment variable and things like that. But this is the query. And as you can see here, is just a GET request using the URL and the payload. So under the hood, GraphQL is just a GET request but with the payload.

OK, now going back to navigation, once we have the hubs, of course, we look at the projects and do the very same thing. So the project itself has the own entry. If we go back again to this tool, we see that we can go through hub or we can go through projects if we already know the project ID or, at least, we know the Hub ID.

So in this case, I'm providing the Hub ID so I'm getting the projects that I need. And here comes the fun part, is that, starting this, you can also apply filters. So, for instance, I'm interested in projects. But I want to not only show me the ID and name, but I want the folders.

And in folders, I want the name, ID, and the inner folders and so so forth so I can go this long and go. But I'm interested only in this structure only for this project. So I can specify that, OK, don't give me for all projects of this hub but just for this very project.

And as you can see here, I have the project that I need. And these are the folders and the inner folders and so so forth for each one. Once I have the folder that I need-- so in our case, it was something like [INAUDIBLE] AU 2023.

OK, I can use another endpoint, so basically, go to the folder content and so so forth. So again, I can use the filtering thing and say like, OK, show me only the content of this kind of folders. Skip everything else. And here comes the things that we need. So it's basically the exchanges that we need.

And as you can see here, we get only the exchanges. We don't get the Revit files or things like that. So keep in mind that if you want to use this kind of API in order to create something like a tree, the path tree for files or things like that, you can do that up till folders. And after that, you have to rely on other tools if you're interested in Revit file. If you're interested in exchanges, of course, this is the kind of tool to go.

OK, so now if we have the thing that we need-- and we see that we are interested in this one. So we are interested in this ID. And here comes-- I will put EXCHANGE_ID. Here comes the second part. So we discussed about the very first part. It's just navigation, how to drill down to the exchange that we need.

And the second part is accessing the data. Of course, the very first call that we do is basically exchanges. And again, the things that-- how do I know the structure of this one? It's very simple. I'm going here, exchanges. What I can get here? I can get id, elements, name, versions, lineage, and things like that.

By the way, the lineage is used in order to track the versions. So as you can see here, so what I can get in the version-- id, createdOn, createdBy, and versionNumber. createdBy is an object. So let's see what this object has-- was id and firstName, lastName, and so so forth, so all the information that you need.

As you can see here, I say, OK, I don't need all this information, just need the first name to make sure that it was me who created that. And this is, by the way, the benefit of the GraphQL, is that instead of getting everything on this very exchange, I just get only the fields that I need.

So I don't need a createdBy or things like that, no problem. I will just delete and say, like, I need only the version number and createdOn. And that's it. So it will provide me only the information that I need without any kind of additional information and things like that.

And as you can see here, we have version 1 and version 2 of it. And here comes the fun. So, for instance, I want, of course, to do the very next query and say, OK, I'm interested in exchangeByVersions. So basically exchange versions.

And I can specify a filter. And the filter is basically a query saying something like, OK, show me from id, latest minus 1. What it means like that is, basically, show me the difference between last version and the previous version. And moreover, as I can see here, I'm also putting here the filter operation. So I'm interested only in this kind of field. I will take it out later, and you will see.

And here what, we have-- this is basically showing you what assets were modified between these very versions. And, for instance, this one is already enough for me in order to identify the element. So, for instance, if we look here-- let's say, like, this ID-- this name is 36 something.

OK. If I'm going back to this one and go to our exchange and look at this one, you will see that it will match the name. And all the properties that are here actually could be accessed. So height, thickness, and things like that could be accessed.

I just put it here, a filter, show me only the operation. But if I will remove this filter-- yeah, I can remove the entire thing. It will show me all the properties that these elements have.

So if I'm going back to this one, the INSERT operation, I can see the category doors. I can see the category family, type, name, source, and things like that. And here comes the useful properties-- volume, area, head height, and things like that.

However, here, it is interesting thing is that-- OK, now a question for you. Area, what is the units for this one? And let us look at the-- figure out by ourself this thing.

So when you look at the properties-- this is a property-- you can see that, actually, it also contains a property definition. That will have id, name, readOnly, description, specification, and units. OK, so let us complete it right now.

It will be here, the property definition. And since it's an object, then it will require something. And it will be like, well, I'm not interested in id. What I'm interested in-- name, description, and units. So it will be like name, description, and units.

And now I'm putting this query. And see if we go back to our thing that we have here-- OK, we have area, total surface area. And it is in square meters. Now, as a side tip, as a hint, I can tell you that I think it would be by you-- might not be by you-- not only that you can get the information, but also, here, you can specify the units that you want the results to be in.