Every day, EVERY DAY, when I was at work I would have to copy and paste between multiple applications. And not just once or twice but over and over throughout the day. And it was always the same, first names, last names, addresses, phone numbers, etc. And even though I had gotten very good at it and could Ctrl-C, Ctrl-V and tab or mouse my way through with the best of them, I just new that they time it was taking must really add up, especially when multiplied out by all my co-workers who had to go through the same thing. I would always wonder, ‘why am I still doing this’ and ‘can there not be a way for me not to have to do this anymore’? I think it became one of those tasks at work that I, along with my co-workers and millions and millions of others I am sure, was resigned to doing.

So why was it like this? Why did I have to accept the fact that my SAP applications couldn’t talk, so to speak, to my Salesforce ones or my company’s custom built or legacy applications for that matter? I think two reasons contributed to this more than anything else. First, copying and pasting had become a natural flow of keystrokes or mouse clicks that I was just willing to accept as part of what I had to do. To me it was just an extension of typing. Second, and perhaps the biggest reason, is that I didn’t think getting rid of task like copying and pasting was even possible.

The first reason makes sense. I, like most of us, learned a task the way I learned it and then as it became more and more repetitive, I just became better and better at it to the point where even though I still had to do it, I was so fast at it, I didn’t really care about doing it or look at it as a real hindrance to my job performance. So copying and pasting of basic information between applications had just become an accepted part of the process. I could also look at the fact that copying and pasting the information rather than having to re-type it all from one application to another was in itself a significant process improvement. Now the second the reason, regarding it being even possible to eliminate the need to copy and paste all together, I guess it’s one of those things where I thought to myself, someone has probably figured this out, but it probably takes a lot of custom coding and wouldn’t be easy to implement especially not when dealing with multiple systems and even some that were custom built. Something like that just wouldn’t really seem a high priority for most IT departments who support multiple users of multiple applications.

It wasn’t until I came to OpenSpan that I found the way that there was an easy solution for this common task that affects millions of users on a daily basis. OpenSpan’s software has eliminated the need to copy and paste between applications has been solved and the solution itself can be implemented in under 5 minutes. Better still, once rolled out to all users who work with multiple applications and need to copy and paste information between them, it can really save a tremendous amount of time. To really grasp the amount of time it can save, imagine what solution like this could mean for a 600 seat call center or a bank with 50 branches. The more opportunities at the user level to eliminate copying and pasting, the more time is saved and the more productive your employees can become. To see just how easy it is, watch our short video demonstration using the OpenSpan technology and then register on our community site and try it yourself.

I spent this week onsite in Baltimore helping a customer architect some automation scenarios where the goal of this exercise was not only to reduce the average handling time of the contact center agents but also make them more productive and provide better customer service.

One of the issues we identified during the discovery phase of this project was the lack of ability of the users to recognize customers with flagged accounts or important alerts to need to be reviewed when get in touch with the contact center.

The current system provides a black triangle image close to the right corner of the screen while the account information is on the left corner. Ha! Don’t get me wrong but who in the world designed a condition like that?
Something that has to be brought to the agent’s attention in black on a gray background. Nah! It’s not gonna work.

Frankly, now I understand why these agents were not able to check that alert and keep that in mind during the call or take action according to the information provided there. They couldn’t see it. Agents working all day long taking calls and in front of their computers with the exact same applications all day start not recognizing small changes. It’s a fact! You gotta do something better and give them a better experience if you want to have a better customer service.

So, we fixed that issue… and more than that… We didn’t change a line of code on their systems.
OpenSpan has a very nice capability to recognize when a control (button, image, textbox, dropbox, etc) is created, changed, clicked or whatever happens with it.
OpenSpan also has a method called ShowToolTip which works for Windows and Web applications.
The quick solution to the issue described here was to combine these two OpenSpan capabilities.
To give you some details, when the agent was getting the account information for the call we setup an event “listening” for the alert image creation on the screen. As soon as we recognize that condition we then read the Outer HTML property of that image because that would be the text displayed on our tooltip and finally display the tooltip for 10 seconds. In a non-intrusive way we brought the agent’s attention to where we needed so they could see the alert without clicking on anything and kept working on their call without any interruption.
What colors we decided to use??? Well, we decided to do it in OpenSpan Orange-like and since we were in Baltimore why not to say that was an Orioles sponsored tool tip.

It came out similar to this:

There are so many use cases for an implementation like that. From process guidance to bringing the agent’s attention to certain aspects and everything in between.

If you’re interested about the tooltip capability take a look on the OpenSpan Online Documentation available here.

On a recent PoC (Proof-of-Concept) I had to add items from two comboboxes to a Windows Form combobox. Here is a simple solution to that:

1. Highlight the combobox control in Object Explorer and click the Explore Component Properties button at the top of the Object Explorer.

2. You should see the list of properties available for the combobox control. Select the “Items” property and then select Configure Type to see Properties and Methods of the combobox.

3. Select the Methods you would like to use and then click OK. The methods you selected will appear in the Object Explorer. I’ve added Items.AddRange(Object[] items) to add an Array of items Commonly used methods are:

4. Then on my Automation I just added the AddRange method to be populated by the combobox from a Windows Application. Something similar to the following:

I just did the same thing for the other combobox items I wanted to add to my Windows Form combobox and ended up with all of them in one single control.

There are some cases during a project you’re constantly working with the same control and you want to change the default behavior when you drag and drop it from the Object Explorer. Well, here is what you have to do to change the default behavior in OpenSpan Studio (MS-Visual Studio plugin):

1. Select the control type you want and click Configure Type. Here is an example for a button.

2. The Button Control Configuration pops up and now you can select the property, event or method you want to be the default behavior. For the button control the “Click” event is the default behavior.

3. Select the new configuration you want to be the default behavior, right-click on it and then select Set As Default Member.

In the example above I’ve set the PerformClick method to be the default behavior.

The next time I drag and drop a button to the automation it will be the PerformClick method instead of the Click event.

OpenSpan Studio and its counterpart MS-Visual Studio plugin do a pretty good job when you have to integrate applications where you don’t have the source code available, service-enabled applications and/or exposed APIs. Having all the properties, events and methods graphically available make the development effort much easier than coding from scratch.

But, let’s say you’re an avid developer and feel pretty good handling code. Well, here is something you would really appreciate then. OpenSpan 4.5 has the capability of write automations directly in C#, VB or other .NET languages.

This is really powerful when you have the source code available and you want to drive your automations from a .NET-based application. Also, this approach would make the deployment sometimes simpler than the traditional approach.

Here is an example of code-based automation project:

1. Create a new .NET project. In this example we’ll be using a Visual C# project as the base project. Then, name it CodeBasedDemo.
2. You don’t the auto generated Form1.cs so feel free to remove it from your project.
3. In the same solution, create a new Empty OpenSpan project and name it CodeBasedOSDemo. Make sure you set the Solution field to Add to Solution instead of creating a new one.

4. Your solution should be similar to the following Solution Explorer image:

5. Now, it’s time to interrogate the required applications. We’re going to use a Windows-based application and a Web-based application for the purpose of the sample project. We’re not going to cover the interrogation process in details but feel free to take a look on the OpenSpan Online Help for more information. The OpenSpan Online Help is available at http://help.openspan.com/

6. After interrogating the two sample applications (MyCRM Windows-based application and the Web-based Fedex.com website) you should have something similar to the following in the Object Explorer panel:

Windows-based application

Web-based application

7. You’re now ready to dive into the code-based solution once everything we needed from the OpenSpan side is completed at this point. But before you start typing real code, make sure you import the right references to your .NET C# project. You may reference the same ones that OpenSpan automatically add when you interrogated the Windows and Web based applications.

8. Make sure you also add the CodeBasedOSDemo (the OpenSpan project) as a reference to your .NET C# project.
9. Right-click on your OpenSpan project and Build it to make all the necessary assemblies available to the parent project.
10. Open the Program.cs class file and create instances of the OpenSpan interrogated applications:

11. You’re ready to start interacting with the interrogated controls. Some of the possibilities like checking the state of checkboxes, making fields read-only, copying the required fields when the user take actions on any of the running applications, etc are listed on the commented code below:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

}
}
}


12. Set the CodeBasedDemo project as the startup project of your solution

13. When you finish coding your automations, copy the .dll files under the CodeBasedOSDemo\bin\Debug directory to CodeBasedDemo\bin\Debug
14. Build the solution and run it.

If you have any problems building the solution take a look on the first few lines of the exception as it can point you to probably missing libraries in your project.

The sample code for this tutorial is also available here: Code-Based Demo Source

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.