EXECUTIVE WHITE PAPER

C R I T I C A L S U C C E S S FA C T O R S

Transaction-Based Processing:
A New Approach to Mainframe and Midrange Access for IVR and Call Center Application Development

C R I T I C A L S U C C E S S FA C T O R S

The Mainframe Remains Key

Programmers Move to Transaction-Based Processing to Speed Application Development

oday's typical Interactive Voice Response (IVR) and Call Center applications not only demand speed, reliability, and portability, they must also provide

The combination of scarce technical skills and high-cost development is a strong motivation to adopt a new solution for accessing host data. Developers of IVR and Call Center applications can address these challenges with an approach called Transaction-Based Processing. This new approach allows a developer to capture an entire set of host interactions and encapsulate them into a single transaction that can be used from most development environments including Voice XML, Visual Basic, Java, and .NET. Figure 1 shows how this single transaction can replace many API calls, thus simplifying 3270 and 5250 host access. Consider a typical banking transaction: "get account balance." This one statement involves multiple interactions with the host application. These interactions might include recognition of the introductory host screen, entering account number, selection of account balance, reading of results, and return to the host introductory screen.

efficient access to corporate data stored on mainframe and midrange computers (hosts). According to current market estimates, over 70% of critical corporate information remains available only through mainframe and midrange connections. What this means for developers of IVR and Call Center applications is clear: Successful implementation depends on fast, reliable host links. The traditional application developer uses either error-prone screen scraping or difficult API programming (e.g. HLLAPI, CPIC, LU 6.2) to access host data. Today, these programming skills are in short supply as emphasis has shifted from legacy methods to modern programming environments. Also, mainframe and midrange system programmers are the most expensive.

Figure 1: How Transaction-Based Processing Works

Host

Screen

Screen

Screen

Screen

Screen

Transaction-Based Processing allows a developer to capture an entire set of host interactions and encapsulate them into a single transaction. In this example, a single transaction replaces many API calls, thus simplifying host access.

Transactions

C R I T I C A L S U C C E S S FA C T O R S

Traditionally, each of these interactions was coded and managed separately with multiple calls to an API interface to get each screen. Transaction-Based Processing eliminates the individual screen interactions with a single transaction call. Figure 2 shows a call flow diagram with individual screens and the simplification when using transactions. The Transaction-Based Processing approach is the basis for two new products from Cleo Communications: Transaction Designer and Transaction Processor. Together, these products allow developers to build portable solutions for Windows, Linux and Unix that can reduce project schedules by up to 35%. This results in reduced development costs, shorter delivery times and satisfied customers. Transaction Designer is a Windows-based tool that enables the developer to access a host application, automatically record screens and keystrokes, and combine these into transactions using an easy-to-use graphical user interface (GUI). Because of its ease of use, developers can construct complete transaction sets in a few hours rather than the several days required when using API interfaces. Transaction Designer also provides the ability to test the transaction as soon as it's created. The immediate testing of a newly designed transaction gives instant verification of a correct design and significantly reduces testing time.

Once a set of transactions is created, it is published in XML format as a transaction set for later use by Transaction Processor. Although the transactions are created on Windows, the published XML transactions may be run on practically any operating system - Windows, Linux or Unix. Transaction Processor runs on the target application system and manages all communications sessions with the host while executing individual transactions. Transaction Processor makes the initial host connection, pools all sessions, manages the pool of sessions, restarts hung sessions, executes individual transactions, and, in general, manages all issues required to keep communications flowing to and from the host. Here is an example: When accessing the host, a typical application may have several hundred connections that need to be shared among the incoming calls. In the real world, these connections sometimes get "hung" when talking to the host and need error recovery and restarting so subsequent calls can use them. Transaction Processor handles all of these issues at run time.

Figure 2: Reduce Complexity with Transactions Screens Transactions

Run transaction ("get_account_balance")

A design flow that addresses the issues at the "transaction" level is easy to construct and implement because the designer does not need host programming experience. In this example, the complex call flow required for a Get Account Balance is replaced by a simple statement.

C R I T I C A L S U C C E S S FA C T O R S

Adding Value at Each Project Phase

T
4. Testing

here are typically six key stages involved in specifying, quoting, and delivering IVR and Call Center applications:

lack of remote access, and/or host security requirements.

Using Transaction Designer, there are now several alternatives:

1. Creating the Quote 2. Designing the Solution 3. Developing the Application

The customer can capture the screens and send them to you, Your technical support or systems engineer can record
the screen onsite, or

Your developers can remotely record the screens.

5. Deploying the Solution 6. Providing Responsive Support Figure 3 shows Transaction Designer in Record Mode. In this mode, all screens and keystrokes are automatically saved in a Creating the Quote To quickly and accurately create a quote, the project manager needs to fully understand the complexity of the host applications required to access data. Frequently, the screens are difficult to obtain due to the cost of sending someone on site, file for later use when creating a transaction. In this Figure, the 3270 host session Login Screen is present.

Figure 3: Transaction Designer in Record Mode

In Record mode, all screens and keystrokes are automatically saved in a file for later use when creating a transaction. In this example, the 3270 host session Login Screen is present. Our experience has shown that by making it easier to record this detailed information, an accurate project quote can be completed in a few hours instead of days.

C R I T I C A L S U C C E S S FA C T O R S

Figure 4: Transaction Designer Palette

Transactions are created with Transaction Designer using prerecorded screen sets. The GUI shows the current screen, highlights selected fields, shows the row and columns of all selected fields, allows a screen to be used in multiple transactions, and displays currently defined transactions and recorded screens.

Designing the Solution Transaction Processor simplifies design by providing full session management for the host connections. Transaction Processor assigns all sessions to one or more pools, dynamically allocates a session to a transaction, releases the session at the end of a transaction, parks the transaction at a specified "screen," and performs automatic error recovery for hung sessions. This eliminates complex design and implementation details from the project. Using Transaction-Based Processing, the designer can structure the workflow around the transactions to be accomplished rather than detailing how the data will be exchanged with the host. For example, as mentioned previously, a typical banking IVR system is concerned with account balance and check details. As Figure 2 shows, a design flow that addresses the issues at the "transaction" level is easy to construct and implement because the designer does not need to detail the host interactions. Also, the use of transactions allows organizations to easily replicate their core application to many customers. Once an application is created, only the transactions need to be tailored to a specific customer's host system, the rest of the application remains unchanged. Each new opportunity is really only a set of modest changes. Companies using Transaction-Based Processing are able to create portable applications, which have a significant impact on the company's bottom line.

Developing the Application In the development phase, there are two steps in providing access to the host. The first is the creation of a set of transactions. The second is the actual inclusion of these transactions into the application. As mentioned earlier, transactions are created with Transaction Designer using pre-recorded screens. Figure 4 shows Transaction Designers easy-to-use interface for constructing transactions. Transaction Designer provides tools to design a transaction by selecting the set of screens to compose a transaction, selecting the inputs and outputs for the transaction via highlighting the fields, and naming and storing the transactions. Also, as fields are selected, their location and size are displayed. Finally, a transaction map can be generated that shows the screens and input and output fields used in the transactions. This is a powerful development and debugging tool that enables the programmer to see the details of the transactions. In addition, Transaction Designer creates a transaction map or list of input and output fields and rules for use by any application developer allowing for more effective use of precious resources.

C R I T I C A L S U C C E S S FA C T O R S

Testing When host access is available, Transaction Designer allows the transactions to be tested independently from the application. Pre-testing the transactions significantly reduces debugging and testing time. IVR developers will soon be able to simulate host access for full product testing prior to going onsite. An additional software tool, called Transaction Simulator, will provide this capability. It is scheduled for release from Cleo Communications in mid 2004.

enced supplier of IVR communications tools. Cleo, for exam-

ple, has focused on connectivity for IVR systems for over a decade.

Cleo Communications new 3270/5250 Designer and products, Transaction

Providing Responsive Support Applications accessing legacy host data are subject to the changing host environment. It is common that IVR or Call Center applications will fail for no apparent reason. Of course, the reason is frequently an unpublished change in the host applications running on the host or network changes. Transaction Designer's debugging tools facilitate quick response to these changes. For example, a technical support team can quickly compare the recording of the original screens to the

Transaction Processor, provide developers portable solutions for Windows, Linux, and Unix that reduce project schedules by 35%.

Deploying the Solution During the final installation stages, expert technical support can be required to help the IVR development

team iron out difficult network issues. In such cases, it becomes important for developers to work with an experi-

current screens to find changes. Once the changes are found, the transaction tools can be used to design and test the transaction modifications before inserting them into commercial operation. Finally, since the complete application uses the same transaction (e.g. "get account balance"), no changes are required in the actual application screens.

C R I T I C A L S U C C E S S FA C T O R S

Summary:
Reduce Complex Development, Increase ROI

he implementation of IVR and Call Center solutions is a rapidly growing market requiring costeffective tools to solve the access requirements

For over ten years, Cleo Communications has been the leader in the mainframe and midrange communications. We enable today's developers to leverage legacy data into modern applications with confidence and ease. Our 3270 SNA and TN3270/5250 products are used in over 98% of Avaya IVR and Call Center applications. With experience in thousands of installations, Cleo delivers on the promise of highreliability and outstanding technical service.

for legacy data on IBM mainframe and midrange systems. The ROI from changing from legacy development techniques to Transaction-Based Processing is significant. TransactionBased Processing can reduce project time up to 35%. Focusing on high level transactions, a wider range of programmers can be assigned to development. This savings in labor, combined with reduced ongoing support costs, and increased customer satisfaction allows the investment to quickly pay for itself.

Transaction-Based Processing Aids in Every Step of Development

Creating the Quote: Create accurate quotes quickly using the actual screens recorded with Transaction Designer.

Designing the Solution: Speed design process with transaction sets and eliminate detailed API diagrams.

Developing the Application: Reduce development time using built-in session management.

Testing: Reduce time to acceptance and eliminate issues with pre-tested transactions.

Deploying the Solution: Ensure a smooth deployment with the availability of Cleos experienced technical staff.

Providing Responsive Support: Resolve issues faster with transaction debugging tools.

C L E O C O M M U N I C AT I O N S 180 LITTLE LAKE DRIVE ANN ARBOR, MICHIGAN 48103 PHONE.734.913.6950 F AX. 7 3 4 . 9 1 3 . 8 1 2 5 4203 GALLERIA DRIVE ROCKFORD, ILLINOIS 61111 PHONE.815.654.8110 F AX. 8 1 5 . 6 5 4 . 8 2 9 4 1 . 8 0 0 . 3 1 5 . 3 8 4 9
W W W . C L E O . C O M

2004, Cleo Communications. All rights reserved. Printed in USA. Cleo is a registered trademark of Cleo Communications. All other company, brand, or product names are or may be trademarks of their respective holders.