Those of you who are new to DriveWorks or new to the use of Specification Macros (“spec macros” as Glen Smith is keen to tell us all the cool kids call them) will not notice anything out of the ordinary when you first see the spec macros form in DriveWorks 16. I mean, you’re seeing it for the first time. But those seasoned veterans who have spent time pulling tasks from the toolbox are bound to be taken aback when seeing spec tasks in DriveWorks 16.

The massive overhaul of the new specification task designer is due to the massive overhaul of the specification macro functionality. The difference can be summed up in three concepts: flow, reaction and timers.

I must admit that I’m not in love with the interface itself (I’m sure those details will get ironed out as everything is fine tuned), but a huge departure was required as specification macros switch from being a linear stack of tasks to a full-on flow model. Unlike specification flow which is based on states that are acted upon with transitions or actions, spec macros now allow processes to flow from task to task in any direction, even allowing multiple paths into and out of a single task. This allows for “parallel” task streams and very robust branching.

Conditions No Longer Belong to a Task

Gone is the concept of the task condition. With the new flow model, conditions no longer belong to a task, but are rather an entity unto themselves. Much like decisions in form navigation, conditions are placed into the flow and have an Input node, a Passed node and a Failed node. Interestingly enough, they also have an Output node so a parallel route can exit regardless of the condition result. But the ability of new spec macros to react is no longer limited to just conditions.

In many cases, the conditions that we would put on a spec task are strictly to test the outcome of the previous task. In DriveWorks 16, every specification task has three result output nodes that are triggered based on success, warning, or error. You can very simply attach additional tasks to handle any errors.

Spec Tasks Provide Output Values

But even that isn’t all that DriveWorks 16 spec tasks provide in terms of reactivity. Specification tasks can now provide output values. If you look at any specification task that I have written, you will always see at least one output constant that receives information back from the task. This may be as simple as a message for success or failure (we don’t need that anymore), or it could be a return value. With DriveWorks 16, tasks can now return those values right within the task flow. The user interface has you drag green nodes to setup the process flow from task to task. In addition, black nodes representing return and input values can be dragged to form connections. A specification task to delete rows in a simple table, for example, will return the number of rows that were deleted. The node for this output value can be dragged to connect it to the input for a task to drive a control value or to a field in a condition. When you make this connection, however, it is important to note that the connection will provide the value, so you will no longer have the ability to write a rule for that input.

The Timer

I know, I know, there’s so much new stuff that you want to go get started. But there’s one more new feature that I have to mention. And that is the timer. A timer is really more of a polling scheduler in that it will run a macro based on a time interval that you provide as an input. This means that you can have a macro fire every three seconds. If that macro starts with a condition, then you have basically just created a triggered event that will check every three seconds to see if it needs to run. Just as an Autopilot connector will run every time that your Autopilot checks the queue, your timer will run its macro based on the interval that you provide. A timer interval count input allows you to tell the timer how many times to run the macro. And a property called Stay On Schedule lets your timer know if it should wait for the macro to complete before starting to count the next interval (yes, this is a more robust alternative to looping). The implications of timers in DriveWorks are massive. Your DriveWorks specification no longer has to sit in a specification flow bucket waiting for someone to act. Your entire implementation can now be alive and breathing on its own. OK, that’s actually a bit creepy.

The bottom line is that specification macros are no longer a simple checklist of steps to run at the push of a button or when changing forms. When you put timers and flow and this reactivity together, specification macros are now a full-fledged programming language with no code.

So how are you implementing or going to implement specification macros in DriveWorks 16? No, I mean it. I’m asking you. We want to hear your ideas at driveworks@razorleaf.com!

The post What is THAT Thing?? DriveWorks 16 Specification Macros appeared first on Razorleaf.