Transaction Based Processing

8/2/2019 Transaction Based Processing

http://slidepdf.com/reader/full/transaction-based-processing 1/8

Transaction-Based Processing:

A New Approach to

Mainframe and Midrange Access

for IVR and Call Center

Application Development

CRITICAL SUCCESS FACTORS

E X E C U T I V E W H I T E P A P E R




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

efficient access to corporate data stored on mainframe and

midrange computers (hosts).

According to current market estimates, over 70% of criticalcorporate information remains available only through main-

frame and midrange connections. What this means for devel-

opers of IVR and Call Center applications is clear: Successful

implementation depends on fast, reliable host links. The tradi-

tional 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 pro-gramming environments. Also, mainframe and midrange

system programmers are the most expensive.

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 entireset of host interactions and encapsulate them into a single

transaction that can be used from most development environ-

ments 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 bal-

ance." This one statement involves multiple interactions with

the host application. These interactions might include recogni-

tion of the introductory host screen, entering account number,selection of account balance, reading of results, and return to

the host introductory screen.

T

2

Figure 1: How Transaction-BasedProcessing Works

Host

Screen Screen Screen Screen Screen

Transactions

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.




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 prod-

ucts 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 trans-

actions 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 trans-

action 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 individ-

ual 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 subse-

quent calls can use them. Transaction Processor handles all

of these issues at run time.

3

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.

Figure 2: Reduce Complexity with Transactions

Screens Transactions

Run transaction ("get_account_balance")




Adding Value at Each

Project Phase

here are typically six key stages involved in

specifying, quoting, and delivering IVR and Call

Center applications:

1. Creating the Quote

2. Designing the Solution

3. Developing the Application

4. Testing

5. Deploying the Solution

6. Providing Responsive Support

Creating the Quote

To quickly and accurately create a quote, the project manag-

er needs to fully understand the complexity of the host appli-

cations required to access data. Frequently, the screens are dif-

ficult to obtain due to the cost of sending someone on site,

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

Using Transaction Designer, there are now several alternatives:

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.

Figure 3 shows Transaction Designer in Record Mode. In this

mode, all screens and keystrokes are automatically saved in a

file for later use when creating a transaction. In this Figure,

the 3270 host session Login Screen is present.

T

4

Figure 3: Transaction Designerin 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.



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, dynami-

cally allocates a session to a transaction, releases the ses-

sion 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 struc-

ture 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 transac-

tions. 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 Designer’s easy-to-use interface for con-

structing transactions. Transaction Designer provides tools to

design a transaction by selecting the set of screens to com-

pose 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 dis-

played. 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 trans-

action map or list of input and output fields and rules for use

by any application developer allowing for more effective use

of precious resources.


5

Figure 4: TransactionDesigner Palette

Transactions are created with

Transaction Designer using pre-

recorded screen sets. The GUI

shows the current screen, high-

lights 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.



Testing

When host access is available, Transaction Designer allows

the transactions to be tested independ-

ently from the application. Pre-testing

the transactions significantly reduces

debugging and testing time. IVR devel-

opers 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.

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-

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

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

decade.

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 sup-

port team can quickly compare the

recording of the original screens to the

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 applica-

tion uses the same transaction (e.g. "get account bal-

ance"), no changes are required in the actual application

screens.


6

“

”

Cleo Communications’

new 3270/5250

products, Transaction

Designer and

Transaction Processor,

provide developers

portable solutions for

Windows, Linux, and

Unix that reduce project

schedules by 35%.




he implementation of IVR and Call Center solu-

tions is a rapidly growing market requiring cost-

effective tools to solve the access requirements

for legacy data on IBM mainframe and midrange systems.

The ROI from changing from legacy development techniques

to Transaction-Based Processing is significant. Transaction-

Based Processing can reduce project time up to 35%.

Focusing on high level transactions, a wider range of pro-

grammers 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.

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 mod-

ern 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 thou-

sands of installations, Cleo delivers on the promise of high-

reliability and outstanding technical service.

7

Summary:

Reduce Complex Development, Increase ROI

T

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

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

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

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

Deploying the Solution: Ensure a smooth deploymentwith the availability of Cleo’s experienced technical staff.

Providing Responsive Support: Resolve issues fasterwith transaction debugging tools.

Transaction-Based Processing Aids in Every Step of Development



C L E O C O M M U N I C A T I O N S

1 8 0 L I T T L E L A K E D R I V E

ANN ARBOR , M ICHIGAN 48103P H O N E . 7 3 4 . 9 1 3 . 6 9 5 0

F A X . 7 3 4 . 9 1 3 . 8 1 2 5

4 2 0 3 G A L L E R I A D R I V E

R O C K F O R D , I L L I N O I S 6 1 1 1 1

P H O N E . 8 1 5 . 6 5 4 . 8 1 1 0

F A X . 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.

Documents

Transaction Based Processing