Descripción
Aprendizajes clave
- Learn how to structure Inventor models for use by Autodesk Forge.
- Learn about the external interface and logic that must be developed to use Autodesk Forge effectively.
- Learn about reference material available from Autodesk to start development of a configurator.
- Learn about the components required for a complete configuration solution, from quotation to production.
Oradores
RYAN SMALL: Welcome to Autodesk University 2022 and this session titled Web-Based Product Configuration Using Autodesk Forge Design Automation for Inventor. This class is a case study, so we will not be diving too deep into technical details. But we'll point those that are technical to the appropriate resources. In this class, we will be sharing with you from our experience of building a product configurator on Forge using Inventor Design Automation.
Let's review the learning objectives for this class. Firstly, we want to talk about some of the considerations for preparing your Inventor models to be used in Forge and specifically in vendor design automation. We want to talk about some of the user interface, the web UI components and logic that you need to develop and incorporate into your solution to use Forge effectively. We'll talk about some of the reference material available from Autodesk to help you get started in developing a configurator. And we'll talk about the components required for a complete configurator solution.
So just a little bit about SolidCAD. So we are an Autodesk platinum partner. We've been a reseller for 25 years. We are based in Canada. We have 11 locations across the country and 150 or so staff spread across those locations. We are a Forge Certified Systems Integrator. We are Autodesk's largest reseller partner in Canada, and we're one of Autodesk's largest resellers in North America.
So just a little bit about myself. My name is Ryan Small. I've been 22 years with SolidCAD, 23 years in industry. So almost the entire tenure of my life in the workforce has been here at SolidCAD. I did do a year as a full time AutoLISP programmer many years ago. I do have extensive experience with the Autodesk manufacturing products, primarily in Venture and Vault. I've actually worked with Vault from before it was an Autodesk technology as SolidCAD was a partner for [INAUDIBLE] Innovations that originally developed it. I've had a number of different roles here at SolidCAD, but presently today my official title is I'm Director of Software Development. Joining me today is my colleague Don Boresky.
DON BORESKY: Thanks, Ryan. Yeah, my background is a pretty unique mix of technical expertise and business development in the software industry. The last 15 years, I've been in the Autodesk reseller channel, and prior to that, I worked with a variety of manufacturing and retail ERP systems. And while my formal education is very technical, I've always had a passion for viewing technology through the lens of business improvement, and that fits really well with my current role where I lead the business development efforts for SolidCAD's Configuration Solutions.
RYAN SMALL: Thanks, Don. So as a company, we've had a long history of doing CAD-based development, add ins for products like Inventor or AutoCAD, Revit, et cetera. We decided a couple of years ago actually at Autodesk University 2019 that we were going to embark on the development of our own product configurator which really for us reflected our first product-based development. In the course of building that configurator, there's a number of things that we learned, some mistakes that we made, and so we're here to share really from that expertise to help you avoid some of those same pitfalls and hopefully help you in your path of building your own configurator.
So why did we develop a configurator? So as a company here at SolidCAD, we have had a long history of working with customers doing product configuration on the desktop. We were actually a reseller for Logimetrix which was the company that developed the technology that is-- we now know today as iLogic which, of course, is native to Inventor.
So in those course-- in the course of all of those years doing configuration on the desktop and working with customers to implement iLogic to help them to have configurable based design on the desktop, one of the questions that would often come to the surface in many cases is how do I move this configuration beyond the desktop so that people who are not designers, engineers, they have the ability to go ahead and do product configuration without having the knowledge of those CAD tools?
There are, of course, other configurator products on the market. But one of the realities of many configurator solutions that are out there is that they require you to redo your design intelligence. So for companies that have made an investment into iLogic and Inventor, the fact that you've got to rebuild a lot of that stuff is not very appealing to somebody looking to move into a configurator.
We also had some uncertainty about the future of Autodesk Configurator 360. We had seen over the course of time Autodesk invest in and divest of other configurator technologies-- Intent which was their flagship ETO product, Configurator One which we were actually a reseller for a couple of years. And so there was a little bit of uncertainty, and it did seem when we were really serious about building our own configurator that there was less fanfare, if you will, around Configurator 360 which made us a little bit uncertain.
And of course, we had-- many of us here that were part of this had also seen many years ago Mechanical Desktop come and go. So we wanted to essentially go and build our own solution. We did. We did-- about five or six months after starting development, we did panic a little bit when Autodesk announced that C360 was being retired in favor of Forge because obviously, the development resources that we have at SolidCAD are much smaller by comparison to Autodesk. But Autodesk determined that Forge was really a platform. They weren't going to, at that point anyways, be part of the configurator product business, and so that kind of paved the way for us to continue to go forward in developing our own configurator.
So Autodesk Forge is broken down into a number of different APIs, or we might just call them services. And there's certainly more than what are encapsulated on this slide. However, if you are looking to build a configurator using Inventor Design Automation on Forge, these four services really probably represent the cornerstone of your configurator solution.
First and foremost is the Design Automation API. This is really Inventor running in the cloud. Now, there are other design automation APIs. There's AutoCAD, Revit and 3ds Max. Obviously, for the purpose of this class, we're going to be focusing on Inventor. Next is the Viewer API. This allows you the ability to view your file inside your web browser, and the file that you're viewing is a file that is a standard graphic format. So you're not needing any add ins or extensions in order to view that.
The Data Management API or service is really where you're storing your data on the cloud. So more than likely, your configurator is going to make use of Inventor assets-- parts, assemblies, drawings, et cetera. Now, they've got to reside somewhere, so you can pass them into the Design Automation API. That place they're likely going to reside is in the data management service. That's your storage bucket for your data.
And then you've got the Model Derivative service, and Model Derivative handles the conversion of your CAD data into something that is displayed in the viewer that we talked about. So that's handling translation of Autodesk formats like Inventor and AutoCAD, some third party formats, as well as some generic formats-- STEP and SAT and that sort of thing. Now, as much as these four services do represent the cornerstone of a configurator solution and certainly represented the four services that we initially utilized, we subsequently abandoned the use of Model Derivative API, and let's talk about why that was the case.
So just to quickly recap, the Model Derivative Service is the component of Forge that's handling the conversion of your input file into SVF or scalable vector format which is a graphic file that you are going to display in the Forge viewer and ultimately on your website page. The problem that we ran into and actually spun our wheels on for quite some time has to do with an issue around suppression. So in Inventor on the desktop, you can mark components as suppressed which essentially unloads them from memory and from the display.
And likewise, if you're building a iLogic-based design in Inventor, very common for users to employ that same methodology that you're going to turn on and off or suppress or unsuppress components based on the design requirements of the inputs you're specifying. The problem we ran into with Model Derivative is that when you send your Inventor file into Model Derivative to say I want to get this translated into SVF so I can display it in the viewer, it doesn't understand the concept of suppression. So the net result of that is that you end up with a resultant file that has all of the components displayed which means that you're no longer seeing an as-configured model.
So if you look down here in the lower left of the slide, you can see kind of showing the two different paths. So if the valve on the left represents the configured model, when you pass that through the Model Derivative to say I want to prepare this to display in the viewer, you can see that all of the valve options are being shown. Why? Because Model Derivative does not understand suppression. So we were able to actually work with Autodesk to help determine an alternative solution which was to actually do the translation to SVF directly from Inventor. And the net result of that is we are able to have a model being displayed in the viewer that reflects our configuration model.
There is another thing to consider even if you're not potentially dealing with suppression in Inventor. You may also want to think about doing the translation via Inventor Design Automation anyways just for the purpose of reducing some of your Forge cloud credit costs, simply because there is a cost to Model Derivative. It's one of the services you are paying for. Each time you do a translation, you are incurring some costs. So you may be very off further ahead by paying those costs towards the translation time in Inventor or Design Automation as opposed to paying the conversion costs via Model Derivative. So definitely something you're going to want to consider.
So when we started down the path of building a configurator, as I mentioned, this was back in Autodesk University 2019 where our management team gathered together, actually, one of the tables outside the exhibitor hall. My development team was given a fairly limited runway to develop a working proof of concept. So what that meant was that at the time, we moved forward with our configurator based on the technologies that we knew. In retrospect, maybe weren't the best technologies kind of long term.
So what that ended up meaning was over the course of time, after we built that proof of concept and we continue to build on that foundation of code, we got to a point where we actually kind of painted ourselves into a bit of a little corner. And we said, OK, to make this product more viable, we need to fix some of the core foundation of the product. So we actually ended up doing two fairly major code overhauls where, in both cases, we went through swapping out existing technologies for other technologies that were more suited to where we wanted to go.
So thinking about what we would have done differently, if we could go back in time, I think I would say if after we develop that proof of concept and we were able to sort of convince our management this was a path to continue down on, I think at that point, I would have said, OK, we did the rapid prototype. We used what we knew, but let's take a step back and build a more solid plan, determine what are the right languages and technologies or frameworks to build on that are going to be scalable for the future?
Do we need to bring in some different resources to augment because maybe we didn't have the staffing on that we needed for the right technologies that we thought were suitable to move forward. And maybe that meant possibly even abandoning all of our rapid prototype code and starting new from that foundation. So if you're in a position where you're able to establish a plan from day one, definitely think about what's the right scalable technologies, what's the resources. If you do find yourself in a similar situation where you have to come up with a proof of concept, maybe it makes sense to start with what you know, but maybe that's not the right path for the future kind of big picture.
In thinking about expertise and skill set, just be aware you're going to have to obviously have expertise in a few different areas. Obviously, you're going to have to have web development expertise and of course, expertise with Inventor. Now, one of the things I'll maybe just caution is that if you are competent with iLogic, I mean, if you're the iLogic power user, just be aware that there's still a learning curve for you to move to Inventor Design Automation and Forge.
iLogic is a great on ramp to configuration, but with it targeting maybe a non-programmer, but when you do get into Inventor Design Automation or Forge in general, it is kind of working more on the basis of the fact that you are a developer. And so you just need to kind of be aware of that. Obviously, you're going to have to have familiarity with Forge. That's probably stating the obvious. But it is a new set of services you've got to be able to wrap your head around. There's documentation and tutorials, et cetera. We'll talk about some of those resources later.
You may, depending on your solution, and again, this is really a question of scalability footprint of your solution where you're going with configurator for. You may or you may not need to have a DevOps or infrastructure resource. Maybe this is somebody who's an expert in technologies like Amazon Web Services or Microsoft Azure. Again, just depending on your scalability, that's something you're going to want to consider as part of your solution.
So I know thinking about us with our configurator, we have people who are experts on the web development side, experts on the Inventor side, and then experts on Amazon Web Services, so-- kind of filling all those pieces. So just some things to think about as far as resources. One last comment I'll make on this slide. If you're looking to build a solution as a configurator solution, if you're already experienced in .NET, especially if you're coming from Inventor already, I would probably be inclined to try to do as much as I can in the .NET space just so that you're kind of working in one language.
In our case, we're not. We are, obviously, a team of multiple people, but it's something I would at least consider if you're a .NET developer today and you know Inventor. And the reason for that is the fact that when you deal with your Inventor add in, you're going to be writing it and .NET anyways, so it might make sense just to keep everything under one technical space.
So thinking about your configurator solution, and to be honest, this is something we sort of learned the hard way in a couple of cases. You're going to want to think about engaging with your end users and probably involving them early in the process and depending on your solution, possibly as an ongoing. It's important that you work with your end users to really validate your workflow. Developers, especially if you are a developer or if you've worked with a developer, sometimes think how to move forward and implement something that might not be the best for especially somebody who's not technical.
So you definitely want to think about engaging your end users, making them part of the process so that you're sure that it's going to be as easy to use product as possible. This becomes really important if your solution, if your configurator solution is going to be public facing where you might not have the ability to train the people who are going to be using your configurator. So you really want to think this through.
As I mentioned, we sort of learned this ourselves through just some experiences. So we actually had two different scenarios that come to mind. So the first thing we did was when we built our configurator, and I'll show the video here to sort of illustrate the before and after of how we made the changes, we were getting feedback almost immediately from end users that they didn't know what to do in step two. You'll see when I play the video that the essence of our configurator is you specify your inputs, and you would go ahead and generate a model that users would then scratch their head saying, well, what's the next step?
To us as developers, it was obvious. Oh, you go over here and click this tab. To the end user who had never seen the solution before, they scratched their head. The other thing we ended up doing as well is when we-- in our configurator, we had combined initially two different actions together, those actions being the generation of the model, which you see in the viewer, as well as the resultant downloads like the quote document, the PDF of that configuration, some of the DMG files, et cetera. We combined all of that into one option or one activity.
The net result was is that it was just introducing a little bit of a performance, some negative performance, because a lot of times users were, in many cases, they just wanted to validate visually, first of all, whether this was the right design that they wanted before initiating the process of creating the downloads. And interestingly, as we've looked at customer analytics, we can actually see and we track it in our logs the fact that, yes, indeed. Customers many, many times over will run a configuration multiple times, and then they'll say, yes, this is actually the reflective of the design. So we ended up separating those two tests.
So let me go ahead and play the video. I'll show you-- which I'll show you the before and after. So let me go ahead and click on play here. So this is our solution initially before we made the changes. So the user would go in. They'd specify their configuration options, and we would go ahead and click Generate. So again, as I mentioned, we were combining together the creation of the file for the viewer which we're going to display on screen and the downloads. And so we'll just wait here for a sec. You'll see there, obviously, is a little bit of a delay. When we see the app, you'll see this process much quicker as we've sort of separated the tasks.
But the users after they did the model wouldn't know to go and click this tab. So they didn't know what step two was, and step two is really the heart of all of the good data that you're getting out-- your quote, your downloads, et cetera. So what we did is we changed it. So same as before, we go specify our product input options. We click Generate Model, which is now very specific that, hey, we're creating the model. We're not worrying about creating all the downloads. This allows users to quickly determine is this what I want.
If in fact, it is, they initiate the second task of creating the downloads. And as we'll see here in a minute, when the downloads are created, we just automatically flip over to the Downloads tab. So the user no longer has to scratch their head saying, well, what's the next step here? So it's almost complete. There we go. We've auto activated. So it really made the end user experience a lot more clear and again, especially because our solution was targeting people that we weren't going to be able to train.
So since the expectation or likelihood is that you're going to be looking at implementing a configurator on Forge from the basis of Inventor data or using Inventor data as your input, be aware that you are likely going to have to do some tweaking, if you will, to your Inventor designs for a couple of reasons. One is the fact that you need to make sure that your designs are able to be modified without blowing up. If you change a constraint value in a design and that causes constraint errors, that's not a good candidate yet to take it to design automation.
As well, you need to think about what the range of configurability is. So perhaps when you modeled a plate, you created a square. You created a circle, and then you ended up having a hole in the plate by virtue of just not selecting the circle input. Well, that's a problem if in your configuration you need to turn off the hole feature. So that may mean you have to actually put the hole as a separate feature in your design so that you can have something to turn on or off.
So you need to just be thinking about what-- how appropriate are these designs to be able to move forward into Inventor Design Automation? The key thing is Inventor Design Automation, really like Inventor on the desktop. It can only modify a design to the degree that you can do it manually. So if you can't pick and click in Inventor and get that design to work correctly without causing problems, it's not going to work in iLogic on the desktop. It's not going to work in Inventor Design Automation. So you want to make sure those data sets are pretty clean.
The other thing is, there are some specific Inventor Design Automation things that you do need to think about. The link is there. I'm not going to go to the link because the link is fairly technical. We're trying to keep things fairly high level here. So especially somebody who's a developer, you're going to want to go check some of those details out because it does get into the weeds a little bit. But one that's very simple and straightforward to explain and is key is that interactivity is not allowed in Inventor Design Automation on Forge.
So things like message boxes, input boxes, they will cause issues. They'll cause the Inventor Design Automation activity to fail. So you need to think about that. So in many cases, like I'll show in the video here-- I'll just go ahead and hit play-- this is a simple rule in iLogic that's basically, say, telling the user if they haven't put the right length value in or they've gone to high that we're going to show a message box. That's fine on the desktop, but it's not any good in Inventor Design Animation.
So as the video simply shows here I'll play, sometimes this is just as simple as going, selecting those lines in the iLogic editor, and just commenting those lines out. So you can still have your rule. You just need to make sure you suppress or comment those lines of code just so that you're not going to get into any issues when you get into Design Automation.
So let's just talk a little bit about the Forge workflow here, and this is obviously specific around the idea of Inventor Design Automation. So you're going to have your web UI. That's where the user is going to pick their configuration options, essentially the parameters, what their selections are. You're going to package that data up. You're going to send it over to Forge, and you're basically sending to Forge your parameter options from your UI as well as, of course, your Inventor model.
That's going to be processed by Inventor Design Automation. It's going to essentially take the input parameters, pump those into the Inventor model, and essentially leave you with a model that reflects your configuration. Now, from here, it's going to obviously produce the result, and the result is going to be a configured model which you're going to display likely in the Forge viewer. So you get that visualization file, and maybe you're also including as part of your output some additional downloads.
Now, with that workflow in mind, the key thing that you need to realize is Inventor Design Automation is not interactive. So if you have familiarity with iLogic in Inventor or even if you happen to have experience with Configurator 360 in the past, it's very different because we're not dealing with interactivity in Design Automation. So there are a couple key things that you need to then be aware of and think about in your configurator solution.
So the first one is you need to possibly, again, depending on your models, you need to implement some logic via the user interface, especially if you've already got some of that logic in your model that may not transfer well. So I'll go ahead and play the video and just talk through this. You'll see pretty clearly what I'm driving at. So let me go ahead and hit play. So this is a simple iLogic model in Inventor. It's got two parameters, width and length.
They're both dropdown parameters, but what happens is that the way this model works is that my length parameter is restricted based on the value of my width. So if width is one to five, my length can only be one to five. But if it's greater than five, I can have a length of one through 10. And that's easily implemented through just a simple iLogic rule that says if the width is less than or equal to five, these are the options for length. Otherwise, these are the options.
Because Inventor Design Automation is not interactive, you need to make sure you account for that logic via your UI. So one of the things that we ended up having to build into our solution is the ability to let users essentially clone a parameter and then control the visibility of that parameter using display conditions. So in this case, I've duplicated length. We just have a little UI bug we've got to sort out which is that the new parameter that we copy always gets added to the top. So I'm just going to reorder this so my two links are beside each other.
So we're going to go to the length. You'll see here always on is disabled. That gives us access to a display condition. So this is basically controlling when this parameter gets shown in our interface. So we're going to say that if the width is less than or equal to five, we want the parameter be shown, and these are the available length options that are available.
We're going to go to the other length parameter which, again, is duplicate parameter. We're going to turn always on off, and we'll set another display condition. This one is a display condition that is greater than or equal to six because this now has a wider range of options. So I'm just going to go ahead and add in some additional parameter values here just to add in the list of parameter options. I'm entering the value in twice because the value on the left is what you're displaying to the user and the interface, and the value on the right is what's actually being passed as the parameter.
So you could, for example, on the left, if you want to actually write the word and then the number on the right. So we'll go ahead and save our parameter. So again, just to recap, we've got one width parameter, one-- or pardon me, two length parameters. Width is always on because obviously, that needs to be there. But in our two length parameters, which are identical to each other in terms of the parameter name, however, are different because in both cases they have different input options to select which are tied to the selection of our width.
So if we go ahead and save all that, we'll jump over the configurator. Here we are with width. So again, you see the input option we've selected. You can see the lengths are one to five. Makes sense. Our width is only one. If we jump to a value of six, we're dynamically turning on and off parameters. We now have the option one through 10. We jump to five, and we're back to a limited set of parameters.
The other thing you're going to want to do is make sure that you're providing users feedback. When you send your activity to Design Automation in order to configure the model and produce the outputs, there's going to be a delay there while the Inventor instance spins up, and your data is passed over and executed and such. So because of that and because it's not directly interactive, you need to make sure that you're incorporating feedback to your end users. Let them know what's going on. Keep them engaged within the process.
So you see here, I'll go ahead and click play here on this video. So same as before, we're going to go set our parameter options as desired, and we'll go and click on Generate here in just one moment. And as soon as we go ahead on it, on Generate, you'll see there we are giving the users live, dynamic feedback letting them know exactly where we are. Just, again, keeps them engaged, lets them know we're working on this, and that they're not refreshing their browser or wondering what's happening. So definitely a couple of things you're going to want to consider with incorporating into a solution, just this whole idea of Inventor Design Automation not being interactive.
Now, this may apply to a limited set of people, but it's something worth considering. And this is the idea whether or not you want to go with a single or multi-tenant infrastructure. So let's maybe just sort of clarify what this is, what's meant by this. So if you are a single tenant infrastructure, what that means is that each client or customer has their own Forge application. So there's kind of that layer of isolation inherently defined.
On the other hand, if you have a multi-tenant application, then you may have multiple clients, multiple users, potentially multiple companies. They're accessing the same Forge application. So what are some of the considerations, or what's the sort of pros and cons to consider when you're trying to make a decision? So if you go with single tenant, you're going to have to have a bigger investment in infrastructure.
Why? Because you need to be able to scale up your solution and bring other tenants online. And that's going to require creation of new websites and that sort of thing deployment, of your code, et cetera. There is some benefit to single tenant. You are reducing your downtime risk because each client or company, they're kind of running in isolation through containerization. So if you have a virtual server for customer A and it goes down, that virtual server for customer B would stay operational.
One of the downsides, though, of single tenant is that you're going to have to leverage and/or write custom code to handle the deployment of your code to those tenants, both your web code and your Inventor Design Automation plugin. Now, I can speak from experience, this is something we didn't do for a while until we got to a point where it just became extremely time consuming for us to go ahead and update customers. And it actually was pretty quick that we ran into just a lot of headache because supporting multiple Inventor versions, needing different code for those Inventor versions across different customers would mean that it could take hours for us to update the code either on the web side or on the Inventor add in side.
So if you are looking at dealing with a larger number of tenants or even a smaller number where you think, hey, there's some concern here about the frequency of pushing things out and getting them updated, it's something you're going to want to think about. On our side, we use Amazon's AWS CodePipeline to push out our web code, and we actually wrote a custom tool to push out the Inventor add in. So when we make changes to our configurator, we can very quickly push those-- push that code out across all our tenants fairly easily.
There is some benefit if you do need to track Forge costs on a per customer basis, single tenant is helpful because you're going to be creating one Forge app for every customer. So it's very easy to go into the dashboard and determine what those costs are. If we look at the other side of the coin, multi-tenant, you've got one code base. So even if you are doing your code updates manually, which would probably be the case, you're only updating it once. So it's pretty straightforward.
It is a single point of failure. So if that app goes down or the server goes down, essentially everybody's locked out until it's operational again. If you do need to track Forge costs because you can't rely on the Forge dashboard reporting, you'd have to write some code to track those costs. So client A is logged in. They're running a job. These are the Forge credit usage, so you incorporate that into your own dashboard.
And lastly, you may need to implement security or segregation via code. So a classic example would be if you have a product configurator that you've built that you're making your products that you manufacture available online. Maybe you've got a distributor network, and certain distributors can only configure certain products. Or maybe certain configurators or certain distributors, pardon me, have different pricing structures available just because of the volume that they sell. You would obviously have to make sure that you implement that via code to make sure the distributors are only seeing their respective data.
So we spent some time walking through some of the challenges that we ran into, try to help you avoid running into the same pitfalls. What we want to do is kind show you the-- really, just the essence of what our configurator solution is that we ended up building that encapsulates all of these ideas. And with that, I'm going to go ahead and turn it over to Don.
DON BORESKY: Thanks, Ryan. I'm going to take a look at Variant from the perspective of our approach to the market and clients. When we started the Variant project, we decided to focus on some key target characteristics that we thought were underserved. And first, we decided to focus on the configure-to-order space versus engineered order, and this enabled us to develop a pretty light application that effectively leverages Forge.
We also focused on organizations whose products can be configured in one model using iLogic. Not to say the products have to be simplistic, and as you can see from the examples I've included on the slide on the right, the products can be quite complex. And lastly, we focused on organizations with the discipline to manage configurations but didn't want to invest in traditional configurator solutions. There's lots of very capable configuration systems out there, but they've typically been very expensive and difficult to implement. We wanted to make Variant different on both fronts.
So this focus has created a unique value proposition for the organizations that we work with. By leveraging Forge, our clients are able to use their existing iLogic code rather than rebuild product rules in a separate sales-focused system. By using Forge and AWS, we're able to maintain an entirely web-based infrastructure enabling clients to extend configuration to whoever and wherever they want on virtually any device. And by hiding all the complexities of Forge and AWS behind one simple annual subscription, we keep the implementation uniquely easy to manage and scale up.
To bring all this together, I'll take a quick tour of one of our client's implementations of Variant. Vent-A-Hood is an 80-year-old innovator in the kitchen range hood industry. You might recognize them as one of the early adopters and signature accounts for Autodesk Configurator 360. Vent-A-Hood's public facing Build-A-Hood configurator is now driven by SolidCAD Variant. Now, because Vent-A-Hood products can be specific to regions, we start by picking the area that we're in, and this provides access to all the configurable hoods. Each of these is an iLogic-driven Inventor model.
Let's take a look at the JCH/A1. When we pick the model, the website links to the Variant tenant for that configuration. Now, as mentioned, all the configuration parameters and valid options are directly drawn from the Inventor model and displayed on the left. Let's pick a width, and we'll grab a CSM or CFM, sorry. I kind of like the stainless steel finish, and we'll take the option for a couple of bands. And we see that additional parameters to define the details of the bands are now added. As Ryan referred to earlier, Variant in this case has been configured to prompt for band details only when the number of bands is not zero.
So I'll select the band style and whether or not there are bands on the duct cover and the band finish. And once we've defined the options we want, we hit Generate Model. Variant and Forge now do their thing. Variant packages up the selected parameters, sends them to Forge to generate the configuration. Because the model is already uploaded to Forge as part of the initial setup process, only the parameters themselves need to be passed.
Forge applies the parameters to the model and sends back the result. And while Forge is doing its thing, as Ryan mentioned earlier, we're providing feedback so users know the process is running, and they can stay engaged. When it's done, the updated configuration is displayed in the Forge viewer. If further changes are needed, we can update the parameter selections and rerun Generate Model as often as we need. But when you have the result you're looking for, we hit Generate Downloads.
Forge is then reengaged to generate the additional documents and files related to the configuration in this case. Now, Vent-A-Hood has given their users the options to download a couple of different model formats, 3D and 2D DWGs, PDF drawing, and request a quote for the configuration. While Vent-A-Hood isn't using it, Variant also has options for additional downloads such as the configured Inventor model and an actual priced out quote document. Ryan, that covers the highlights, so back over to you.
RYAN SMALL: OK, great. Thanks, Don. So in wrapping up, where do you go next? So this is probably going to depend on your role. So if you're a developer, I would probably start with the Forge Developer Portal at forge.autodesk.com. This is really the primary resource for documentation tutorials and support. You may also want to consider participating in one of the Forge accelerators. So these are in-person events where you are working closely with Autodesk experts and Forge to help build out your solution.
And I will actually state, when we were in the early days of building out our configurator, we did actually participate in the week-long Forge accelerator. So we are-- we're testaments, I guess, if you will, to going down that path. You're also going to want to be aware of the Autodesk Sample Application. There's two links there. The first link takes you to the live version which is just the ability to essentially use the demo of that configurator. But the second link is to the source code, so you can go to GitHub and grab that code. It will get you pointed in the right direction with a pretty decent foundation of code.
If you're an executive or manager, you're going to want to make sure you think about securing the right resources. Possibly that's having developers on staff. Maybe you need to augment with some external partners, some web development companies, some system integrators for Forge. You need to make sure that you've got the right expertise at the table to be able to develop a solution. And of course, you may want to evaluate whether or not you want to build your own. Certainly, if you are, I would recommend using the source code that's available in GitHub or other products in the marketplace for product configuration.
If you have any questions, we'd love for you to reach out. You can see the respective emails for myself and for Don. So please don't hesitate. Send us an email. We'd love to hear from you. And with that, thank you very much.
Downloads
Etiquetas
Producto | |
Sectores | |
Temas |