Handing jobs to DriveWorks Autopilot from another system

To let an ERP, website, or cloud API start DriveWorks jobs without a person filling in a form, have it write rows to a database table and point the Autopilot Database Connector at that table. The connector only writes a status back, so have the specification report details to the other system itself with the Send HTTP Request task, which does run on Autopilot.

The pattern

Another system knows an order is ready. DriveWorks needs to generate models, drawings, and documents for it. Nobody should have to open a form.

The other system writes a row to a jobs table: which project to run and the input values.
DriveWorks Autopilot watches that table through its Database Connector, picks up new rows, and starts a specification for each.
The specification generates its outputs and reports back to the other system.

The project behind this can be form-less. Its inputs arrive as constants or control values, and a person never sees it.

What the Database Connector needs

From the DriveWorks documentation for Connectors - Database:

Connection. SQL Server directly, or any database through ODBC.
An ID field (mandatory). The row's identity.
A Process State field (mandatory). DriveWorks reads it to decide whether a row needs processing and writes its progress back to the same field. The default values are New, Processing, Complete, and Failed.
Input fields. Each one passes its value to a Constant or Control with the matching name in the project. This is how column values become specification inputs.
Optional fields for the project name, a transition to run after the data is passed to a new specification, an operation to run on an existing specification, and a specification name or ID when a row should modify an existing specification instead of creating one.
A scan interval, in seconds, for how often the table is checked.

One warning from the docs worth taking literally: for the Specification Id field, an Int data type "will cause the connector to fail", and nvarchar is recommended. The simplest way to stay clear of it is to make every column the connector binds to a text column, as in the table below.

A minimal jobs table:

CREATE TABLE dw_jobs (
  job_id        nvarchar(64)  NOT NULL PRIMARY KEY,
  process_state nvarchar(32)  NOT NULL DEFAULT 'New',
  project_name  nvarchar(128) NOT NULL,
  -- one column per input; the name must match a Constant or Control
  OrderNumber   nvarchar(64),
  Width         nvarchar(32),
  Height        nvarchar(32),
  created_at    datetime2     NOT NULL DEFAULT SYSUTCDATETIME()
);

The gap: it only writes back a state

The connector updates the Process State field and nothing else. Failed tells you a job failed. It does not tell you why, and Complete does not tell you where the drawings went.

Close the gap from inside the specification:

Send HTTP Request. A released specification can POST its status, error text, output paths, and bill of materials to the other system's API. I have confirmed this task runs on Autopilot on its own, with no helper program. The documentation is cautious about where the task's response outputs can be used, so test the exact flow you plan to rely on.
Write to the database. The same specification can update extra columns on its own row, or insert into a results table, when the other system would rather poll than receive a call.

Either way, give every job a correlation ID (the job_id above), pass it in as an input, and send it back with every report.

Resolve the inputs before the row is written

The cleanest version of this pattern has the calling system write fully resolved values: every option decided, every dimension final. The DriveWorks project then only has to generate.

If half the rules live in the web app and half in DriveWorks, every change has to be made twice and tested twice. Pick one side to own the product logic.

Throughput and order

An Autopilot finishes the job it has before taking the next one. More Autopilot machines add throughput, and DriveWorks Pro supports spreading generation across several. If order matters (drawings before the email that attaches them), design it into the specification flow instead of relying on the order rows were inserted.

Other ways in

The Database Connector is one of several Autopilot connectors:

A watched folder. Drop an XML file naming the project, the operation, and the inputs. This is the route I used to trigger a BOM upload from a SOLIDWORKS macro.
The web service connector, when the caller would rather make a request than write to a table.
DriveWorks Live's REST API, when the caller is a web application and a user is present.

DriveWorks documents the full list under Autopilot Connectors.

Common questions

Can DriveWorks Autopilot start specifications from a database?

Yes. The Autopilot Database Connector watches a SQL Server or ODBC table, starts a specification for each row whose Process State is New, and passes column values to Constants or Controls with matching names.

What columns does the DriveWorks Database Connector require?

An ID field and a Process State field are mandatory. Input fields carry the values for the specification. Optional fields name the project, a transition, an operation, or an existing specification to modify.

Why does the DriveWorks Database Connector fail with an integer column?

The DriveWorks documentation states that an Int data type on the Specification Id field causes the connector to fail, and recommends nvarchar. Using text columns for every field the connector binds to avoids the problem.

Does the Database Connector write error messages back to the table?

No. It only updates the Process State field, with New, Processing, Complete, or Failed by default. To return error text or output paths, have the specification send them with the Send HTTP Request task or write them to the database itself.

Can DriveWorks Autopilot call a web API?

Yes. The Send HTTP Request task runs on Autopilot, so a released specification can POST status and data to an outside API without a helper program.