OpenSpan was launched in 2005 and had won multiple awards by the close of 2007. The Atlanta-based company has global reach with upwards of half its revenue streaming in from nearly 50 countries outside of the US. The company offers two products: Desktop Analytics and Desktop Automation. My own newly-earned certification relates to the Automation product.
Desktop Automation
Openspan's "desktop automation" refers to the ability to define processes that automate tasks that would normally be performed manually. For example, with OpenSpan you could easily create an "automation" that opened a browser window, logged into a website, performed a search, copied the first three search results, opened a new browser tab, logged into GMail, composed a new email by pasting in the copied search results and then sent the email to a certain list of email recipients. This is pure magic if you've never used any kind of automation software before.
For those who have used automation software this may not sound so special. For instance, many software-test automation suites are capable of executing the same process I just described. What makes OpenSpan's software automation any different than the many software-test automation products available?
Visual Studio Integration
OpenSpan is heavily integrated into Microsoft Visual Studio. The standalone version of OpenSpan is actually a cut-down version of Visual Studio. You may optionally add OpenSpan as a plugin to an existing copy of Visual Studio.
Many validation testers will shrug and say "big deal" because Microsoft already offers a Visual Studio-based testing suite (in VS Ultimate and in VS Test Professional). The difference, however, is that OpenSpan is designed as a programmer's automation playground rather than a means to build collections of step-by-step test checklists that make up the core of the Microsoft test product. Test Suites test applications; OpenSpan creates applications. Although OpenSpan provides some elements for implementing unit tests, testing is not its primary concern.
Besides hooking into Windows events and executing code in the background, OpenSpan provides ready support for creating "toolbars" - Windows forms meant to act as control panels for other applications. In cases where manual data entry is absolutely required (keying in paper-based data into multiple disparate systems, for instance), a custom OpenSpan toolbar can be used to provide the means to enter data once and then automatically re-enter the data into multiple target applications. The target applications do not need to provide import mechanisms, APIs or even access to the underlying data stores -- the OpenSpan automation simply simulates manual key entry and mouse clicks as needed for each target application.
Finally, OpenSpan embraces a number of common Visual Studio features such as the ability to set breakpoints, jump to object references/definitions and the always-handy code autocomplete (IntelliSense).
The OpenSpan Runtime
Once an OpenSpan "automation" is created it can be deployed to one or more target systems and executed via the OpenSpan Runtime. This essentially runs the automation as a background process. The automation monitors and acts upon events in other Windows applications. There are rich logging features as well as ample opportunity for programmers to implement their own custom logging if desired. A deployed automation is an application in its own right and is meant to be used as such.
OpenSpan Limitations
Disconnected Systems: In cases where target applications reside on completely different systems/networks (such as secure government systems), OpenSpan cannot magically bridge the gap between disconnected networks. Not being able to connect to a system is still a pretty effective security measure.
Changing Systems: By far the biggest thorn in the side of any OpenSpan effort is the likelihood of target applications changing over time. If a target app's user interface and/or process flows are updated, any related OpenSpan automations will likely need to be updated as well. This means that an OpenSpan deployment is rarely ever considered "finished" as there will almost always be some level of ongoing maintenance work involved in keeping automations up to date with their associated target applications.
Another limitation more specific to OpenSpan is its ability to easily manage large automations. Although tasks can be broken into many small, easily-managed automations, data sharing between automations is often accomplished via global variables. Put together too many automations and you end up with a large mess of global variables with no good means of providing comments for each individual variable. Further, while you can import existing automations into new projects, you cannot import global variable definitions. These type of limitations mean that OpenSpan really fits in best when limiting itself to simply being the minimal "glue" needed to connect applications rather than in trying to provide complete, OpenSpan-only applications.
No comments:
Post a Comment