It’s that time again! As our 4.1 release nears completion, it’s time to start posting about our new features. One of the new features we’re testing currently is a new automation stack implementation. As our platform has evolved, we have begun to use our automation engine in new and more complicated environments. Previously, most of our environments were single-threaded automations of applications on the user desktop. Now, our platform is being used on the server to automate back-office requests, process messages and expose applications as web services. In this new environment, it quickly became clearly that our automation engine needed a proper stack to ensure that our automations remained thread safe.

If you’re not familiar with OpenSpan, one of your first questions might be how the heck don’t you already have a stack? To explain that, I need to go under the hood for a little bit. Looking at the automation your first instinct would be to assume that OpenSpan is a visual programming language that generates source code. For example, the automation below could be expressed in a C# class as:

private string varString;private void Setup(){   btnSubmit.Click += delegate   {      varString = txtPhone.Text;      webBrowser.Navigate(txtUrl.Text);   };}

Pretty straightforward, right? How about this automation? In this case we’ve made one of the links asynchronous indicating that the next step should be performed on a new thread.

private string varString;private void Setup(){   btnSubmit.Click += delegate   {      varString = txtPhone.Text;      NavigateDelegate navDel = delegate(string url)      {         webBrowser.Navigate(url);      };      navDel.BeginInvoke(txtUrl.Text, null, null);   };}

Now it’s starting to get more complicated. Every time we need to execute an asynchronous link we would need to generate a delegate type. I’m using anonymous methods which makes it easier, but it’s still pretty difficult. How about this automation? We have two execution threads from different events converging on a single block. Easy to express in OpenSpan, but we would need to use another method or delegate in C#.

private string varString;private void Setup(){   btnSubmit.Click += delegate { NextStep(); };   webForm.Submitting += delegate(object sender, CancelEventArgs e)   {      NextStep();   };}

private void NextStep(){   varString = txtPhone.Text;   NavigateDelegate navDel = delegate(string url)   {      webBrowser.Navigate(url);   };   navDel.BeginInvoke(txtUrl.Text, null, null);}

Even more complicated, and I haven’t even added entry points to the automation. So what can we conclude from this exercise? As you might have guessed, OpenSpan does not generate source code. Instead, we model execution flow using a serialized object graph. This gives us greater flexibility to express logical concepts such as branches, joins, etc. without the limitations of traditional syntax. However, because we do not generate code we are unable to rely on the existing thread stack to manage our local variables for us. Thus, prior to 4.1, we simply didn’t have a stack at all.

So, how does the new stack work? For the most part, it works like the normal thread stack we all know and love. When an automation is entered, all of the local variables and components are allocated and pushed onto the automation stack. So far so good, right? But what about those pesky asynchronous links? In OpenSpan it’s perfectly legal to have two links on different threads in the same automation updating variables.

So what should we do here? In a traditional thread stack model, each asynchronous link gets it’s own stack. OpenSpan, however, makes creating new threads absurdly easy. Thus, it’s easy to create a number of parallel threads to accomplish tasks such as updating three or four application simultaneously. Should we allocate new variables and components every time we execute a new asynchronous link? Should we initialize them to their original defaults or should we initialize them to their current values?

As you probably guessed, the correct answer is none of the above. The new automation stack is not a thread stack. Local components and variables are allocated on a per automation basis not on a per thread basis. Thus, each of those asynchronous links in the example above are actually updating the same variable. This approach preserves the ease of threading OpenSpan traditionally provides, while adding the additional safety of stack-based variables.

Now that I’ve explained how the new automation stack works, I’ll cover some of the common questions I’ve been asked about this feature.

What if I want my variables to be available to all automations?
No problem. OpenSpan automations now have a global and a local tray. Components in the global tray behave just like they did in previous versions of OpenSpan. They can be updated from any automation at any time. Components in the local tray can only be used on that automation and are not exposed to other automations.

When are local and global components created?
Global components are created when the project is started and can be used in any automation. Local components are only created when an automation is run. Local components can only be used in the automation that contains them.

When are local and global components destroyed?
Global components are destroyed when the project is stopped. Local components are destroyed when all the threads in the automation have completed.

When should I use a local component?
Local components are appropriate when the component in question does not need to be accessed from other automations or when an automation can be run simultaneously on multiple threads. Local components are recreated every time an automation is run and thus will not maintain state across multiple runs. For instance, you could not create a local variable to keep track of the number of times an automation is run. Every time the automation runs the counter variable would be recreated and initialized to zero.

What happens when I upgrade my old automations?
Variables and components from old automations will automatically be placed in the global tray during the upgrade process. Thus, your old automations will continue to function as they did before. To take advantage of the automation stack, you can easily make any global components local by right-click and selected the “Make Local” menu item.

Over the next few weeks I’ll be writing some articles to spotlight new features in our 3.2 release. For many of our users, the most exciting new feature is debugging. For the first time, you now have the ability to debug OpenSpan automations in real time using paradigms familiar to users of Visual Studio, Eclipse and other IDEs such as breakpoints, step functions, and watch, call stack and thread windows.

Breakpoints

The essence of debugging is giving the developer the ability to stop execution and examine the state of an application. Stopping execution is referred to as breaking. By breaking execution a developer can find flaws in his logic, scenarios he did not anticipate, or invalid data. The most convenient way to break execution is a breakpoint. A breakpoint is simply a way of telling an application to “stop when you get here.” When the application is run, the debugger will break execution when the breakpoint is reached.

To set a breakpoint in an OpenSpan automation, simply highlight a link, right click and select “Toggle Breakpoint.” A red dot will now appear on the link indicating that a breakpoint has been set. If you right click on an existing breakpoint, you can select “Disable” to temporarily prevent the debugger from breaking when the breakpoint is reached, or “Delete” to remove the breakpoint entirely.

When a breakpoint is reached within an automation, the executing link will become a dashed, animated line. The blocks on either side of the link will also be outlined. The executed block will have a solid blue outline whereas the executing block will have a dotted blue outline.
You can view all of the breakpoints you have set within a project in the “Breakpoints” window. The Breakpoints window lists each breakpoint by automation. You can double-click on a breakpoint to go to that automation. You can also enable or disable a breakpoint using the checkbox next to it. If you right-click on an automation, you can also enable, disable or delete all breakpoints within that automation.

Step Functions

Once a breakpoint has been reached, you can begin “stepping” through an automation. By using the step functions, “Step Over” or “Step Into”, you can walk through your logic at your own pace. The “Step Over” function moves the automation to the next yellow execution link. The “Step Into” function moves the automation to the next blue data link, or if there are no blue data links, to the next yellow execution link. Once you have finished stepping through your automation, you can select “Continue” to resume execution until your next breakpoint is reached. The “Step Over”, “Step Into” and “Continue” options are available within the “Debug” menu and toolbar, but most developers simply use the F10, F11 and F5 keys respectively.

Watch Windows

When debugging, you can view the value of any property by hovering over its data port in the automation. If you want to “watch” how a property value changes while you step through your automation, you can right-click on the property and select “Add Watch.” The property will now be displayed in the “Watch Window.” Anytime the property changes, the watch window will update to reflect the new value. The watch window can display properties utilized in any automation, even ones that are not open or executing. OpenSpan studio also provides a special type of watch window called the “Locals” window. The “Locals” window will automatically display all of the properties in the currently executing automation.

Call Stack and Threads Windows

In addition to the “Watch” and “Locals” windows, OpenSpan Studio provides the “Call Stack” and “Threads” windows to help debug automations. The “Call Stack” window shows the previously executed blocks within an automation. This allows you to see what path was executed within your automation to get to your breakpoint. The “Threads” window shows all of the currently executing automation threads. This allows you to debug complicated multi-thread scenarios within your project.

Future Directions

With the 3.2 release, OpenSpan has for the first time provided automation developers with integrated debugging. We are already discussing additional debugging features for our future releases such as runtime match rule debugging. Let me know what other debugging features you would like to see.