The claims department for Western Reserve Group (WRG) in Wooster, Ohio, knew it needed to update its existing claims system, but deciding which route to take wasn't so easy.

Kludgy system calls for change

WRG's existing system is an extensive inventory of legacy applications and data on CICS VSE and Notes/Domino. The old system provided much of the functionality adjusters needed, but it also had many limitations:

• First, the legacy CICS application didn't provide the flexibility and extensibility to support the workflow and processing requirements that the claims department needed.
• Second, the functionality in the Notes/Domino applications had been independently developed incrementally through the years as adjusters needed it, which resulted in applications that were kludgy, cumbersome to maintain, and very difficult to enhance.

To combat these limitations, WRG developed supplemental programs and databases in Notes/Domino to provide the needed functionality. Unfortunately, this compounded the duplication of CICS data in Notes/Domino. WRG wrote interfaces to synchronize data, but eventually the applications became too cumbersome to maintain.

Working around the system's shortfalls

From a user standpoint, claims adjusters had to jump between platforms and applications to find all the data they needed. For example, adjusters and customer service representatives knew if they were in a Domino database and needed to know the limits of a policy, they had to toggle to a green screen and get that data from CICS. "We wanted to present all of the functionality needed, and we didn't want users to have to care about where it came from," said Wayne Schmidt, the manager of Infrastructure and Technology (IT) for WRG.

Researching options and refining scope

The claims and IT departments began jointly researching new systems offered by major third-party application providers in the insurance industry. After looking at many different claims processing applications, WRG adjusted its scope. "We decided we weren't ready to go through the pain of a complete new system migration," said Schmidt. The pain of rewriting all the legacy business logic in the various Notes/Domino and CICS systems, coupled with the disruption of a new system implementation and rollout, outweighed the potential benefits of a new system.

From this initial research, design objectives evolved that led to a three-to-five year strategy to automate the claims system. The strategy consisted of the following set of goals:

• Maintain all of the functionality of the current system.
• Provide incremental improvements and enhancements to the core processes.
• Provide a common user interface for all data with consistent navigation and presentation standards (move away from thick client and toward browser-based applications).
• Provide seamless data integration to back-end systems.
• Provide a solution within 12 to 18 months that can support the business for 3 to 5 years.

Integrating disparate systems into one solution

For WRG's IT department, meeting these goals meant finding a way to leverage existing business logic and data. "We knew we had to maintain the functionality of Notes/Domino and just do a better job of integrating the CICS components," said Schmidt.

Because WRG had applications and data on multiple platforms, the crucial requirement became finding a way to integrate that data into one solution. WRG looked at several systems to accomplish this. The company began by looking at MQseries, but rejected it because of its cost and limited VSE functionality.

WRG then turned to Lotus Enterprise Integrator (LEI). WRG quickly found that LEI provided only marginal improvements in functionality over existing interfaces and did not have Java connectors for VSE CICS data.

Finally, WRG investigated IBM's CICS Transaction Gateway (CTG). CTG is a set of client and server software components that incorporates the facilities of the CICS Universal Client (CUC) and allows a Java application to invoke services in a CICS region.

After working with CTG, WRG began to better understand its requirements and began investigating a portal solution. The company quickly narrowed its choices to Microsoft SharePoint and IBM WebSphere Portal Express (WPE). After careful consideration, the IBM solution won. "We chose WebSphere Portal Express because of the Domino integration, the inventory of 'canned' portlet applications that are packaged with the product, and because of the tightly coupled portlet integration that it provided," said Schmidt.

Getting CICS data to WebSphere Portal Express

Integrating CICS data using WPE meant passing it to a Java servlet on a distributed Web server. WRG developed a prototype to pass the CICS data to the servlets in WPE using CTG. The prototype proved the solution was technically feasible. Unfortunately, it also proved that CTG was a less than optimal solution.

"The biggest downside with CTG was that it required a middle tier and required you to run an SNA connection. We've spent a lot of time migrating to IP and didn't want to step backwards and support an SNA application server," said Schmidt.

WebTek provides a solution

WRG then looked at replacements for CTG. After discarding eXtreme Vista by OpenConnect, primarily because of its inability to support programmatic access to CICS data, WRG found its solution with H&W's WebTek.

WebTek is a collection of tools for CICS and Java developers that work with IBM's CICS Web Support (CWS) to provide a direct HTTP connection to CICS applications and data. Unlike CTG, WebTek doesn't require additional servers, gateways, or protocols. WebTek improves the functionality of CWS by providing a variety of development and connectivity tools.

Pipeline provides Java connectivity

The WebTek tool of most interest to WRG was Pipeline for Java. Pipeline for Java is a set of Java classes that developers can drop into IBM WebSphere Studio Application Developer (WSAD) or any other integrated development environment (IDE), where they can quickly begin adding functionality to any Java program to allow connectivity with CICS applications. The classes provide methods for requesting and receiving data from CICS applications, managing variables for session and state management, and controlling signon/signoff facilities to leverage mainframe security.

WRG had found what it needed. "Our biggest bonus with the WebTek Pipeline was it gave us true programmatic access. With Pipeline's JAR file and class libraries we didn't have to rely on the 3270 data stream," said Schmidt.

Creating Web-aware CICS applications

With Pipeline for Java giving WRG's Java developers a way to request and receive CICS data from WebSphere, WRG's CICS programmers turned to IBM's CWS, the 3270 Bridge, and additional WebTek tools for assistance in sending CICS data out.

For most of its CICS applications, WRG used the EXEC CICS Web commands provided with CWS to allow CICS applications to receive requests from Java servlets in WPE and respond with CICS data wrapped in XML. The CICS applications were modified to generate XML - WRG's standard for passing data - and the data was passed using Pipeline. WRG used the 3270 Bridge to quickly Web-enable its only agent-accessed application: a Notice of Loss (NOL) application accessed from the WRG extranet. (See sidebar.)

How WRG did it

For WRG, it was important to minimize the amount of custom programming and application design on CICS. To address this concern, the company developed an external system to make the process as streamlined and systematic as possible.

Components of the external system

The system's two major components were designed to be generic enough to allow reuse by many different CICS applications and speed the development process by allowing developers to reuse code and minimize the amount of change in each application.

Referred to as the data dictionary, the first component is a Java application/API managed by a Notes/Domino application. The Java application maps client-side variables to CICS (and other data source) variables. It also externalizes all metadata for these variables and has facilities to associate format, validity, and actions with data elements.

A Domino application automatically generates the dictionary component as an XML file. A Java class then loads and caches the XML in memory when an application is started. During the life of the application process, the dictionary is used several times:

When a custom JSP tag is evaluated for rendering	The dictionary generates a specific HTML tag (that is, 'SELECT', 'INPUT', or 'RADIO', based on the element data type), attributes such as minimum and maximum length, the default value, valid options, and JavaScript events.
Before an HTML form is submitted	The dictionary generates JavaScript that formats all elements. For example, if the dictionary entry states that an element is a date using the format "mm/dd/yyyy," and the user enters a date in the format "yyyy-mm-dd," the data is reformatted as "mm/dd/yyyy" before being submitted to the server.
After initial formatting	The dictionary generates JavaScript that validates data against rules in the dictionary.
When a form is submitted	The dictionary reformats the data so that CICS will accept it. Using a generic routine and the dictionary's variable mappings, name-value pairs are created so that the name in the pair is the CICS variable name that is mapped to the variable name from the form submission.
When an XML response is received from CICS	Mappings and rules in the dictionary parse the XML.

The dictionary also automatically generates the XML document templates required in the Web-enabled CICS programs.

The second component is actually a group of CICS command-level interface programs designed to perform Web sends and receives. Existing CICS claims applications were modified to call these programs rather than perform BMS map sends and receives. When receiving a request from a Java servlet, the first interface program receives the XML datastream from the servlet and provides it to the claims application in CICS as it would receive it from a BMS map. When the CICS application sends a response, a second interface program takes the data that would normally be sent in a map and creates an XML datastream that it sends back to the Java program via WebTek Pipeline. A third interface program handles the COMMAREA and interfaces with WRG's security system to return such fields as termid and opid, which are not presently supported in CWS for VSE.

Managing URLs with WebTek

To manage URLs, WRG turned to the WebTek URL Control Table (UCT). The UCT provides secure access to Web-aware CICS applications by replacing each application's resource components with a single name, known as a mnemonic. The mnemonic becomes part of the URL called by the Java servlet. The UCT allows developers to customize access for each application.

Dealing with differences in the platforms

WRG's Java programmers dealt with many issues foreign to them as they began accessing legacy CICS applications and data. "The most difficult part of this is that we're in the objects world in Java and we've got this very nice precise MVC (model view control) model of how to design and implement an application, but we're challenged with these old CICS applications that have presentation and business logic intertwined, as well as codified data (business logic represented within data)," said Schmidt. WRG struggled through undocumented business logic within legacy applications. "Some things are just known by the people using the application. So when you are trying to work through Web-enabling existing applications, it's difficult to identify all the business logic," said Schmidt.

Keeping track of the session

WRG also had to deal with the transactional nature of CICS. Web-enabling CICS applications means finding a way to keep track of sessions in CICS. WebTek assisted by providing facilities for state and session management. "If we didn't have WebTek Pipeline to handle the stateful connection for us, we'd have to do a lot of mainframe programming," said Schmidt.

The future

WRG successfully provided an innovative solution to an otherwise painful situation and is meeting the goals outlined in its overall strategy.

Using an iterative development approach. WRG first went into production with the internal claims applications, and then followed this with the NOL application for agents.

WebTek and Pipeline for Java proved key in WRG's efforts to provide a new system for its agents and claims department, and they continue to be an integral part of WRG's solution by providing true programmatic access to CICS, crucial state and session management controls, and URL management facilities.