DriveWorks provides a fantastic suite of tools that allows us to create user interfaces where we can capture complete, accurate, manufacturable information which can be used to generate designs and outputs. But there are cases when the front end of a configurator may already exist or our input information is coming from somewhere other than a user entering into a form. Don’t worry, DriveWorks provides functionality to help in this situation as well as in the form of Autopilot Connectors. Let’s take a look at the situations that connectors are designed to address and the steps required to implement them.
DriveWorks Autopilot provides a mechanism where a DriveWorks component checks every few seconds to see if any tasks need to be performed. A few checkboxes in the settings let you know that these tasks could be processing a specification transition or automatic state, generating SOLIDWORKS models and drawings, or serving up 3D preview models. A look inside the Autopilot dashboard reveals that DriveWorks also checks for emails, triggered actions, and can also be set to watch for specifications to be imported. A peek inside the API documentation will further uncover the fact that Autopilot can do whatever you want it to do on that polling interval.
Having Autopilot perform tasks automatically was historically the most popular reason to use the API until the folks at the DriveWorks development team added the connectors that we were writing as core functionality in the product. Connectors are available in three flavors, but they all serve the same purpose. A connector watches a source and tries to use any information that reaches that source to create and process a new specification. Folder Watcher connectors check a specified Windows folder for files. Database connectors query a database table for new records. And Web Service connectors listen to a web port for incoming http requests.
In all of these cases, the information sent to the connector requires complete information in a very specific format. Folder Watcher connectors look for eXtensible Markup Language (XML) or tab delimited files in the format used in the Autopilot Import Specifications functionality. Database connectors require certain columns to be mapped out when you define the connector. Web Service connectors require that the incoming http requests conform to a specific JSON format linking constants and controls to their values.
With these three tools in our arsenal, we can utilize other tools that may already exist in our enterprise to create and process DriveWorks specifications. Existing home-built web sites can be used to send their information in any of the three formats or even to utilize the DriveWorks Live Integration Theme to interact with DriveWorks behind the scenes. Most enterprise systems like ERP, MRP or Sales Force Automation systems will have the functionality to leverage Autopilot connectors. And even DriveWorks can be used to send specifications to DriveWorks Autopilot Connectors.
This last one may seem a bit counter-intuitive, but there are a few scenarios where having DriveWorks generate specifications for import can be rather handy. The first of these situations arises when you want to use one DriveWorks project to generate a number of DriveWorks specifications. One great example of this is for testing. If you have 40 use cases where you know a given set of inputs should generate a known set of outputs, it is a very good practice to rerun those use cases every time that you update your implementation. By sending only the inputs, you are guaranteed to use the latest ruleset to properly test the system. Every time that you update your implementation, a few mouse-clicks can launch a complete set of test cases.
Another example is when a single order or input can result in a number of products. Rather than having a user enter in 14 sets of inputs, a DriveWorks project can be used to import the values and create separate specifications for each product in the list. This can certainly be accomplished directly with a connector, but there’s one catch mentioned above. And that is that connectors have very specific input format requirements.
Before connectors were added to DriveWorks as standard functionalities, importing a number of specification inputs was a very common use for DriveWorks the API. To achieve this level of automation, we would write ConnectorsAndTranslators. Technically, connectors and translators were two components, but they were always written together to the point that they became a single word and concept. When defining a database connector in Autopilot, you are provided an interface to map columns in the table to the inputs in DriveWorks, but neither folder watcher nor web service connectors have any type of configuration.
In the majority of cases where we’re receiving inputs for multiple products, we are receiving files from Microsoft Excel or some other delimited file. In these cases, we need a tool to translate and reformat the information provided into the DriveWorks required formats. This was previously done with the translator half of our plugin