Cornell University: Putting a New Face on a Familiar System

Click here to receive your FREE subscription to Campus Technology

Home > Cornell University: Putting a New Face on a Familiar System

Features

Cornell University: Putting a New Face on a Familiar System

2/27/2003

Keeping the business logic of APPS in place was an important requirement of the project—only the interface was to change. The Office for Purchasing Services maintained their customer-driven approach by convening focus groups to determine the user requirements for the new Web interface. With the customer requirements well understood, development began, first creating the user interface, and then integrating its logic with the functions of the legacy APPS system.

This integration was accomplished using a Web-to-host technique termed screen mapping. Creating a bridge between the Web and legacy environments, custom scripts direct the data from the new, intuitive user screens to the appropriate fields in the underlying APPS system. The data flows in both directions—APPS data flows to the user screens as seamlessly as it flows from them—enabling Cornell to realize the full benefits of the Web environment while keeping all of its existing data and business logic in place. Cornell's new, easy-to-use purchasing system was deployed without touching a single line of code on the underlying mainframe system or disturbing any of the existing business logic.

Matching the Business Flow
At Cornell, each of the university's departments is responsible for initiating and approving its own purchase requisitions in a process that involves three functional roles in the APPS system: a "preparer," an "editor," and an "approver." The preparer d'es the initial data entry for the requisition, the editor reviews the request, and the department's approver approves and releases each requisition.

Before the new Web interface was in place, a person without APPS access would have to work with an authorized preparer to enter a request into the system. Each department handled this differently—via telephone, in person, using paper requisition forms, or through independently maintained shadow systems. Those that completed large quantities of purchasing requests had even developed their own systems for tracking. The request would then be routed through the ranks of editor and approver within the APPS system

With the new application, Cornell developed a "Requisition WebForm" that anyone with Web access can use to initiate a purchase request directly. Completely Web-based and separate from the APPS system, implementing the WebForm did not require any changes to Cornell's strict security and authorization standards.

The new online requests can be initiated from scratch, with the requestor filling-in the online form, or the requester can simply browse the online catalogs of Cornell's "Preferred Suppliers" and point and click their way to building the purchase requisition. To simplify ongoing and repetitive purchase requirements, users can save partially completed requisitions to use as templates for repeat purchases.

Once the requester completes the initial purchase requisition, it's saved on the Web server. The application uses Java servlets to send an e-mail to the appropriate person to approve the request, indicating that a purchase request has been generated that requires their review.