In our previous post we spoke about our findings on the Data Management API, during our week in Munich at the Autodesk Forge Accelerator event. Here we like to share our findings on the Design Automation API, formerly known as AutoCAD I/O.
The Design Automation API allows you to process your CAD files, with custom code, without the need of the according CAD application. At the moment just AutoCAD, but as the API has been renamed from AutoCAD I/O to Design Automation, it lets presume that further applications such as Inventor, Revit and probably more will be supported soon. As an example, if you like to transform your CAD file into PDF, or replace the title block, or even do extensive geometrical operations, you can do this with the Design Automation API. To put is simple, it’s an AutoCAD (actually AutoCAD Core Console) in the cloud, without a user interface.
In order to use the Design Automation API, you need obviously either an Autodesk developer account in order to create your own application, or you allow a 3rd party application to run under your Autodesk account. Anyway, the way the Design Automation API works is pretty simple.
You define a so called activity where you define the input arguments, for instance the DWG file that should be processed, and maybe also some additional arguments like an additional template or supporting files. Also you define the output arguments, like the resulting DWG file. Additionally, you define your AppPackage, which contains your source code, which could be in .Net, ARX or Lisp, that will do the actual operation.
Let’s suppose you have a ton of legacy AutoCAD files and you want to update them all by replacing the title block with a new one, maybe adjust the layers, line styles, etc. Your input arguments might be the given legacy DWG file and additional DWG or DWT/DWS as templates. Your output argument will be the processed DWG file, and your AppPackage will be the special code for doing the clean-up.
So, the activity is something you define once, and then, for each DWG file you will process a so called work item against the activity. The work item is the actual job that will be executed and based on the selected activity, it will require the input arguments and send back the result to the output argument.
Now, both the input and output arguments are URLs, therefore the files must be in the cloud, either on A360, DropBox, OneDrive, Amazon S3 (Simple Storage Service), etc., or you might open a connection to your files through your firewall. The files will be not saved by the Design Automation API. They will be just processed and neither stored or cached or the like. Therefore, the operation is quite secure.
We played a while with the Data Management API and wanted to see how stable and reliable it works. We tried to process an empty file, a corrupted DWG file (we deliberately removed some bytes from the DWG file), a picture renamed as DWG, a real DWG named with a different extension, a DWG with X-Refs but did not uploaded the X-Refs, tried timeouts and some other dirty things. The Design Automation API always came back with a solid and descriptive error message. Well done!!!
We wanted to know, in case where we need to process thousands and thousands of files, can we rely on this thing? Do we get back meaningful error-messages so that we can point the customer to the problematic files with a clear problem description? So far the answer is yes! This is impressive, as the same type of task on the desktop would be a mess. We would need to deal with crashed, dialogs, and the like, and processing more then one file at once, would mean to deal with parallelisation. With Design Automation, all this comes for free.
Btw, if you wonder whether just single DWG files or also DWG files with X-Refs and OLE-references can be processed, the answer is of course yes! There is either the possibility to send eTransfer DWG files to the Design Automation API, where all the referenced objects are either zipped or embedded, or the input arguments of the activity can also accept a sort of list of files.
In terms of processing lots of file, there is a so called quota that limits the amount of files you can process (5 per minute) and the execution time (5 min.). While the amount of files processed per minute can be increased on demand, the execution time cannot, which makes sense, as any complex operation should be doable in less than 5 min. To better understand the number of files per minute, this is related to a user. So, let’s take the example of before where we want to process thousands of files. If this happen under one user account, then 5/min. is the limit. But if we have, let’s say 10 users under which we let the app will run, then each user will have the 5/min. limitation, which results in processing 50 files per minute. If you want to know more about the quote, you can check out this link: https://developer.autodesk.com/en/docs/design-automation/v2/overview/quotas/
The documentation states something about “no rollover”, which means that if you process just 3 files per minute, then you cannot process the spared 2 files in the next minute, or if you purchased a certain amount of credits for processing a certain amount of files and you don’t consume the credits, those will be not refunded or taken over to the next month or payment period. The pricing is still under evaluation, so this might change over time, or maybe not, let’s see. However, if you have a file processing while reaching the quota limit, the file will be still processed.
Besides the limitation in amount and time, there are other security limitation, to ensure that the application runs smooth and not affect or infect other files. The Design Automation API runs as so called “sandboxed”. It means that each session is independent from another and it’s limited in his capabilities. For example, the code you’ve submitted via the AppPackage, cannot access the underlying operation system, or start additional applications, or access the internet. Therefore, your AppPackage must contain all you need for executing the code and cannot download additional stuff or run code outside of the Design Automation API. We did not had too much time, but of course we tried to jailbreak, without success. Actually, we had the pleasure to meet a very cool Autodesk guy, Tekno Tandean, which is responsible for security for the AutoCAD I/O and we had a very interesting conversation about how security works with the Design Automation API, and we can just say that Autodesk is taking this very seriously and so far they did a great job!!!
We also had the pleasure to meet Krithika Prabhu, senior product manager for AutoCAD I/O. She is very interested to enhance the AutoCAD I/O feature set. At the moment there is a standard AppPackage for creating a PDF. So, creating an activity for that is super simple. However, Krithika looks to further opportunities to provide simple functions for typical scenarios in order to make it very simple for us developer to get started with this API and get more done with less. I’m sure we are just scratching the surface and more cool stuff will come quite soon.
Our take away is that compared to the Data Management API, the Design Automation API looks way more mature, which is obvious as this API is around for more than 2 years. It’s well documented with a lot of sample, and it’s really fun working with. We have been able to get the API working in very short time. We can see already a lot of scenarios where this API can be used, either for mass file operations, creating simplified workflows, such as one click configurations, custom conversion in other formats, and much more. While we are investigating which products we can create for you, in case you have any need in the area of AutoCAD and his verticals, let’s have a chat, as this stuff is pretty cool!