Supersonic Services Web Automation System

Web Automation

Supersonic Services business required their staff to constantly monitor the internet for potential government offered job opportunities. This required a lot of manpower and was an overall inefficient process. They came to MVI and asked them if there was anything that could be done to somehow automate this process. MVI consulted with them over several weeks to learn their business and devise a plan on how to accomplish their goals.

Once a plan was created, MVI spent months developing a suite of scripts and applications that all worked together as one to automatically produce the same results which before had to be done by a person physically browsing the internet. These tools were written mainly in VB6 and used an MS-SQL back end to house retrieved information. They were written in a way that allowed Supersonic Services to constantly adjust and modify their parameters to adapt to changes on the government websites and/or changes to their business.

The applications themselves would crawl the internet using what’s called a web-browser control in combination with send key events.  This practically simulated a person using the internet.  Once all of the appropriate keystrokes were programmed, the application acted the same way that a person would and would navigate the government websites and retrieve and save information.

The main advantage of this is that it could be programmed to look for specific types of jobs using keyword and location matches and could also automatically make bids on the jobs for them. This system allowed Supersonic Services to accomplish their goal of saving time, manpower, and ultimately money to make them a more efficient and more profitable entity.

What is XML?

The following points explain the purpose of XML:

• XML stands for eXtensible Markup Language.
• XML is a markup language much like HTML.
• XML was designed to describe data.
• XML tags are not predefined. You must define your own tags.
• XML uses a DTD (Document Type Definition) to describe the data.
• XML with a DTD is designed to be self-describing.

It is important to understand that XML is not a replacement for HTML. The main purpose of HTML is to Format the Data that is presented through Browser. For Displaying data on Handheld Devices WML is used. The purpose of XML is not to Format the Data to be displayed. It’s mostly used to store and transfer data and to describe the data. It is a device or Language independent and can be used for Transmitting Data to any device. The Parser (Or the Program which is capable of understanding the Tags and returning the Text in a Valid Format) on the corresponding Device will help in displaying the data in the required format.

You can define your own tags in the XML file. The way these tags will be interpreted will depend on the program, which is going to get this XML file. The data embedded within these tags will be used according to logic implemented in the secondary program, which is going to get this XML as Feed.

In many ways, the Java language has become the programming language of choice for XML. There are now complete toolchains for creating, manipulating, transforming, and parsing XML documents.

But while many Java developers use XML daily, Sun has lagged behind the industry in incorporating XML into the Java platform. Because the Java 2 platform went gold before XML had made its mark as a key technology for everything from business-to-business integration to Web site content streamlining, Sun has been using the JSR process to grandfather in existing XML APIs that have gained wide acceptability.

The most significant addition to date has been the inclusion of JAXP, the Java API for XML Parsing, which includes three packages:

• org.w3c.dom, the Java implementation of the W3C’s recommendation for a standard programmatic Document Object Model for XML.
• org.xml.sax, the event-driven Simple API for XML parsing.
• javax.xml.parsers, a factory implementation that allows application developers to configure and obtain a particular parser implementation.

Though the inclusion of these packages is a good thing for Java developers, it merely represents a formal nod to existing API standards, and not a giant leap forward in providing elegant Java-XML interoperability. What the core Java platform has lacked is an intuitive interface for manipulating XML documents as Java objects.

Enter JDOM. The brainchild of two well-known Java developers and authors, Brett McLaughlin and Jason Hunter, JDOM was inaugurated as an open-source project under an Apache-like license in early 2000. It has grown to include contributions and incorporate feedback and bug fixes from a wide base of Java developers and aims to build a complete Java platform-based solution for accessing, manipulating, and outputting XML data from Java code.

It’s the API, dummy: Where JDOM Fits

JDOM can be used as an alternative to the org.w3c.dom package for programmatically manipulating XML documents.  It’s not a drop-in replacement, and, in fact, JDOM and DOM can happily coexist.  In addition, JDOM is not concerned with parsing XML from text input, although it provides wrapper classes that take much of the work out of configuring and running a parser implementation. JDOM builds on the strengths of existing APIs to build, as the project home page states, “a better mousetrap.”

To understand why there is a need for an alternative API, consider the design constraints.  Language independent. The DOM wasn’t designed with the Java language in mind.  While this approach keeps a very similar API between different languages, it also makes the API more cumbersome for programmers who are used to the Java language’s idioms.  For example, while the Java language has a String class built into the language, the DOM specification defines its own Text class.

Strict hierarchies.  The DOM’s API follows directly from the XML specification itself. In XML, everything’s a node, so you find a Node-based interface in the DOM that almost everything extends and a host of methods that return Node.  It’s elegant from a polymorphism point of view, but as explained above, it’s difficult and cumbersome to work with in the Java language, where explicit downcasts from Node to the leaf types lead to long-winded and less understandable code.

Interface driven. The public DOM API consists of interfaces only (the one exception, appropriately enough, is an Exception class).  The W3C isn’t interested in providing implementations, just in defining interfaces, which makes sense.  But it also means that using the API as a Java programmer imposes a degree of separation when creating XML objects, as the W3C standards make heavy use of generic factory classes and similar flexible but less direct patterns.  For certain uses where XML documents are built only by a parser, and never by application-level code, this is irrelevant.  But as XML use becomes more widespread, not all problems continue to look so parser-driven, and application developers need a convenient way to construct XML objects programmatically.

To the programmer, these constraints mean a heavy (both in terms of memory use and interface size) and unwieldy API that can be hard to learn and frustrating to use.  In contrast, JDOM was formulated as a lightweight API that, first and foremost, is Java-centric.  It does away with the above awkwardness by turning the DOM’s principles on their head:

JDOM is Java platform specific.  The API uses the Java language’s built-in String support wherever possible, so that text values are always available as Strings.  It also makes use of the Java 2 platform collection classes, like List and Iterate, providing a rich environment for programmers familiar with the Java language.

No hierarchies.  In JDOM, an XML element is an instance of Element, an XML attribute is an instance of Attribute, and an XML document itself is an instance of Document.  Because all of these represent different concepts in XML, they are always referenced as their own types, never as an amorphous “node.”

The class is driven. Because JDOM objects are direct instances of classes like Document, Element, and Attribute, creating one is as easy as using the new operator in the Java language. It also means that there are no factory interfaces to configure — JDOM is ready to use straight out of the jar.

JDOM makes use of standard Java coding patterns.  Where possible, it uses the Java new operator instead of complex factory patterns, making object manipulation easy, even for the novice user.

IVR, XML Vision: Hype or Reality?

The answer is a little of both. MVI launched money-saving, self-service customer applications based on standards such as XML and VoiceXML that reduce the load on your agents.  You’ve integrated your software with computer telephone integration (CTI) so that back-end database information on customers is available to agents in the form of screen pops.

Customers reach your contact center any way they wish — voice call, email, chat and real-time collaboration over the Web.  The customer experience is consistent across all media, and each interaction is immediately reported so updated information is available right away.  The contact center blends resources, and manages and reports on all contacts via a common application suite.

This contact center is possible with today’s technologies, but full-blown implementations are still few and far between. However, experts are confident that Vo IP-based, multi-channel contact centers are the future of customer relations, so it’s important to start planning.

The next-generation contact center requires two fundamental architectural shifts.  In the network infrastructure, you need to shift from the TDM PBX world to VoIP.  And in the applications infrastructure, you need to migrate call routing and reporting, traditionally handled by automatic call distributors (ACD), from closed switching systems to open, industry-standard servers.

Open Architecture

Open architecture offers the promise of infrastructure-agnostic applications.  Routing, reporting and management functions can run on a server that talks to the switching infrastructure.  Open applications can seamlessly route voice calls, e-mail, and Web-based contacts, and they can connect online customers with contact center agents via chat, escorted browsing or collaborative form completion.  Switch vendors offering open architecture contact center products include Cisco and Nortel.

The idea is that once contact-center applications are freed from single-vendor proprietary systems, customers would be able to select best-of-breed products.  This open architecture would attract a larger pool of application developers, leading to new capabilities, lower costs and improved integration.

For example, a Swedish financial services company servicing 3 million customers and handling 44 million calls per year (85% of them automated), has deployed a framework to transform its contact center operation, improve the customer experience, and save more than $1.5 million per year.

By migrating from the ACD applications on its Nortel switch to a server-based software to manage not only phone calls but also other media. The IP Contact Center routes contacts and integrates with information systems and databases. And rolling the system out to additional sites would be relatively quick once the initial infrastructure was in place.

Customers have the choice of which channel they want to use to reach the company and the software funnels customers to the best available and qualified of 1,000 agents in 14 centers, considering language, product/service and customer type.

Limitations, Opportunities

With an open architecture, users theoretically can mix and match products from various vendors,  but that point has not been reached yet.  For example, switch infrastructure vendors offer specialized applications that are tuned to their own products or they promote the pre-integrated capabilities of their server applications tying together ACD, interactive voice response (IVR) and CTI functionality.  So the world is not as “open” as it might seem.

On the plus side, customers can use standard interfaces to make integration easier.  For example, APIs, such as TAPI and JTAPI link switches to servers.  Full Spectrum and CTI solutions integrate with pre-built adapters, such as the MVI software. These allow for integration with a top-tier software package, in hours or days, rather than weeks or months. Similar connectors integrate IVR systems and reporting tools.

Other tools further the goals of openness for ease of integration, interoperability and portability. Standardized yet flexible data schemas and data access provided through SQL, Open Database Connectivity (ODBC) and XML are examples. The architecture frameworks of Java 2 Platform Enterprise Edition, NET and Common Object Request Broker Architecture also are becoming prevalent in contact-center applications today.

Vendors have been responsive to customers’ need for easy integration by offering an increasing number of connectors.  Many leverage standard tools, such as ODBC; XML; and extraction, transformation and loading (ETL) applications.  Faster and easier integration of the diverse elements in a center is critical to enabling efficient and effective resource management.

Most vendors seeking to integrate with software solutions have, or will have, connectors to the top four products.  For these vendors, there likely is a full-blown product.  For others, it is an open hook — a software development kit (SDK) or API that can be written more readily. Full Spectrum and CTI integration now are tackling the thin client architecture, which most packages also are migrating to.

The cable companies wanted to route contacts on open issues to the last agent who handled it, if possible, and pops the trouble ticket on the screen.  MVI integrated 60 agent desktops in one weekend, avoiding a large systems integration effort.

Voice Self-Service

Open architecture also applies to interactive voice response, where one server runs the speech processing for a natural-language user interface, and another runs the standard Voice XML code of the core application.  Both are communicating with standard voice processing cards.

IVR vendors are supporting the VXML standard; most are or will soon be Version 2.0-compliant. This architectural change has huge potential to open the previously small pool of developers and enable portability of applications while leveraging the Web infrastructure and common data.

However, Version 2.0 of the VXML standard needs significant extensions to support customer contact applications.  CTI-based call control, screen pops and integrated reporting are examples of functions that require capabilities beyond the standard.  So a standards-compliant application might not be portable across platforms.

Many vendors generate VXML code from their proprietary graphical user interface as an option, easing the migration for those with in-house programming expertise on their current platform (but this code is not portable to a different platform if it includes any extensions).  They will work to promote the development of the VXML as well as Call Control XML standards.  They also will comply with and support Speech Application Language Tags.

Ready, Set, Implement?

So what’s holding users back from implementing open application architectures?  Some products aren’t mature; VXML, for example, is just being used by early adopters.  Some interfaces aren’t truly open.  Not enough “canned” interfaces exist, partly because they are vendor-specific, not standards-based.  It can be hard to integrate solution elements, potentially resulting in significant system integration costs.  The products don’t plug and play the way they’re marketed.  Not many have done it before them.

Maintenance and ongoing management costs can be high; for example, an upgrade or new release in one element can have a ripple effect to other elements for upgrades and testing.  As a customer, you must evaluate potential costs and trade-offs in integration, problem resolution, upgrades and the like.  Your strategic approach to vendor and product selection needs to consider the tradeoffs of integrating best-of-breed products vs. buying a suite of products from one vendor.

Click here to learn about XML vs. Corba.