Abstract:
A system for managing requests for setting up computer test environments includes a setup request database storing the test environment setup requests and a request management module which provides a standardized user interface screen to submit the requests. If the request submitted by a user does not contain all of the required information necessary to set up the test environment, the user is prompted to provide the missing information, thereby minimizing a subsequent exchange of communications due to missing information.

Description:
FIELD OF THE INVENTION 
     The present invention relates to a data processing system, and more particularly a system for managing computer environment setup requests. 
     BACKGROUND OF THE INVENTION 
     A large transaction processing system such as VisaNet™, processes over one hundred million financial transactions (e.g., credit card transactions) per day. Typically, the processing system runs on a platform which may include one or more mainframe computers. In complex cases, the processing system runs under several interconnected computer platforms that are located in multiple locations for redundancy and workload sharing. 
     Making software modifications or enhancements to a live or production computer system requires careful planning. Typically, a set of software modification projects are grouped into an install plan which has a projected install date. On the install date, all of the modification projects in the install plan are released into the production system at the same time. 
     Each software modification project typically adds or modifies a particular feature. An example of a software modification project may be a feature to add a new transaction type such that the computer system can handle prepaid card transactions in addition to credit/debit card transactions. 
     Each software modification project is assigned a number such as a request tracking number (RTN) for tracking purposes. Once software changes related to a particular RTN are made, they are turned over to a software tester. 
     The tester creates a set of test cases (e.g., test prepaid card transactions) to run against the modified software. The test cases should include different types of transactions to include all of the expected scenarios that may be encountered in the real world. For example, one test case may be a purchase transaction scenario from an overseas POS terminal using a prepaid card issued by issuer A while another test case may be a chargeback transaction scenario from a domestic POS terminal using a prepaid card issued by issuer B. 
     Next, the tester needs to create a test environment in a test computer system so that the production system is not affected in any way. The test environment typically includes copies of all production applications that are needed, modified applications and test cases. In the case of a mainframe using job control language (JCL) that communicates with the operating system of the mainframe, the test environment comprises a tester controlled library containing copies of production JCL, production procedures (PROCS), modified programs or applications, test JCL programs, test parameter files used by the test JCL programs, and test data files. 
     In the case of a JCL mainframe environment, the test environment is specified using a schedule of jobs that instructs the mainframe to load, copy and execute certain applications and procedures, among other things. 
     Typically, the tester would need to set up a series of different test environments to fully test each software modification project. Each time the tester requires the setup of a new test environment, the request is sent to an information technology (IT) department that manages computer resources. 
     Conventionally, the testers request generation and regeneration of test environments through email. Because there are no standard formats to follow in submitting the request, testers often forget to include all of the parameters that are needed to set up the test environments. This has caused a needless exchange of back and forth communications just to complete the required setup parameters. Another disadvantage of the conventional method is that if a manager wants to see a report such as how many environment setup requests were submitted for a particular software modification project or for a full install plan, the preparation of the report becomes a gargantuan task to go through all of the email exchanges with the testers. Also, the manually prepared report may be inaccurate as some email requests may have been deleted or overlooked. 
     Therefore, it is desirable to provide a system and method for more efficiently and more accurately managing computer environment setup requests so as to eliminate incomplete environment setup requests. It is also desirable to provide such a system with a reporting capability to allow managers to easily track the submitted environment setup requests. 
     SUMMARY OF THE INVENTION 
     According to one aspect of the present invention, a system for managing computer environment setup requests is provided. The system includes a setup request database storing the computer environment setup requests. Each setup request includes environment setup parameters for running a computer job. A request management module running in a computer determines whether the environment setup parameters received from a user includes all required information. If not, the management module requests additional information from the user. This feature thereby minimizes subsequent exchanges of communications due to missing information in the original request. 
     Moreover, the setup request database storing the computer environment setup requests allows a manager to automatically generate various types of reports in real-time to more accurately monitor the test environment setup requests. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an exemplary test environment setup request management system. 
         FIG. 2  illustrates a block diagram of a server computer that stores and executes an environment setup request management module. 
         FIG. 3  illustrates a menu map through which a user navigates the request management module of  FIG. 2 . 
         FIG. 4  is a screen shot of a web page for submitting a test environment setup request. 
         FIG. 5  is a screen shot of a query web page for submitting selection criteria to retrieve test environment setup request records. 
         FIG. 6  is a screen shot of a web page for displaying selected test environment setup request records. 
         FIG. 7  is a screen shot of a web page for displaying a single test environment setup request record. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     For purposes of this application, the terms “code”, “program”, “application”, “module”, “software code”, “software module” and “software program” are used interchangeably to mean software instructions that are executable by a processor. The words “data” and “criteria” are used to refer to either a single item or multiple items of information. 
     An exemplary block diagram of a test environment setup request management system  10  is shown in  FIG. 1 . The management system  10  contains a server  12  and a setup request database  14  in communication with the server. The system  10  can be accessed by software testers to submit new test environment setup requests and any manager interested in tracking the submitted setup requests. In the embodiment shown, the setup request database  14  is a relational database using MS SQL Server from Microsoft Corporation of Redmond, Wash. although any type of a database management system can be used. 
     The system  10  is connected to a computer network  4  through a communication link  6 . In the embodiment shown, the network  4  may be a private network such as an Intranet, private network such as an Internet, or a combination of private and public networks. 
     Referring now to  FIG. 2 , the server  12  of the present invention centrally manages submissions of test environment setup requests. In one embodiment, the software code being tested in the test environment relates to code for a processing system that processes financial transactions involving financial presentation devices (e.g., credit cards and debit cards) that are presentable to providers of goods or services. The server  12  includes a multitasking, real-time software technology that can concurrently handle multiple users. 
     The server  12  is connected to the communication link  6  through an I/O interface  22 , which receives information from and sends information over the communication link  6  to the computers  8  of various users. The server  12  of  FIG. 2  includes dynamic memory storage  24  (e.g., DRAM), processor (CPU)  26 , program storage  28 , and permanent data storage  30  (e.g., disk drive), all commonly connected to each other through a bus  32 . The program storage  28  stores, among others, a request management module  34  for managing requests for setting up new computer test environments. Any of the software programs in the program storage  28  and data from the data storage  30  are transferred to the memory  24  as needed and is executed by the CPU  26 . In the embodiment shown, the request management module  34  is written in Active Server Pages (ASP) language. 
     The server  12  can be any computer such as a personal computer, minicomputer, workstation or mainframe, or a combination thereof. While the server  12  is shown, for illustration purposes, as a single computer unit, the system may comprise a group/farm of computers which can be scaled depending on the processing load and database size. 
       FIG. 3  illustrates a menu map through which a user navigates the request management module  34 . Upon execution of the request management module  34 , the submit request web page  36  is displayed at the user&#39;s computer  8  through which a request for a test environment setup is submitted. Advantageously, error checking is performed to make sure that all of the required fields are populated and that those populated fields are in correct format. A query web page  38  is used to specify selection criteria to retrieve one or more test environment setup request records. Selected fields of the retrieved setup request records are displayed in a query result web page  40  which includes a clickable link for each setup request record. Clicking on one of the links displays a record view web page  42  for the selected record. Through the web page  42 , the request management module  34  allows the user to replicate all of the displayed fields into a new submit request page  36 . Advantageously, this replication feature allows the user to search for a similar environment setup request that has been previously submitted in order to save typing time and reduce possible errors. A more detailed description of all of the web pages  36 - 42  will now be discussed. 
     Referring to  FIG. 4 , when the request management module  34  is executed by the processor  26 , the submit request (setup request) web page  36  is the initial page displayed on the user&#39;s computer  8  which provides a standardized user interface screen to submit a request. The submit request page  36  includes required parameter fields and optional parameter fields. Each required parameter field is distinguishable from the optional parameter fields. In the embodiment shown, an asterisk (“*”) is displayed next to the required field name. As shown in  FIG. 4 , the required fields are “Title”, “Environment”, “Owner”, “Required By”, “RTN”, “Cost Center”, “Install date”, “Install Description”, “CPD”, “Config”, “MVV Config”, “Subscriber”, “Pilot”, and “Currency”. 
     “Title” means the title of the setup request being submitted. As described in the background section, “RTN” stands for request tracking number which is a number assigned to a particular software modification project. Once the software changes related to a particular RTN are made, they are turned over to a software tester. 
     “Install date” refers to the date the RTN is to be released to the production system. “Install Description” is a description of the install which can be specified in a pull down menu. The choices are “business release”, “maintenance”, “emergency”, “non-business” and “others”. “Environment” refers to the test environment that needs to be created or regenerated based on the submitted setup request. The environment can be specified by the user using a pull-down menu. 
     “Owner” refers to the person who will handle the particular RTN. “Required By” is the date by which the test environment setup request should be completed. “Cost Center” is an identifier identifying the business unit that is responsible for the cost of providing the software modification project (RTN). 
     “CPD” stands for central processing date. This date specifies the latest date that any test transaction data can have. For example, in a credit card processing system, the test transaction data are credit card transactions and the date of any credit card transaction in the test data cannot be later than the central processing date. 
     “Config” contains card issuer information data used by various systems in a card transaction processing system to determine how to collect, deliver and settle issuer data. “MVV Config” is used by the card transaction processing system to identify a merchant entity. “Subscriber” refers to set-up details. “Pilot” is similar to “Subscriber” and contains issuer parameter set-ups. “Currency” refers to a currency file that contains all the currencies and their equivalent conversion rates to different currencies for a year. 
     The remaining fields on page  36  are optional fields. “Additional Email” can be used to specify additional emails to which a confirmation email of a submitted request is to be sent. “GL Account” has general ledger information. “UBF” refers to universal billing information. “Binkeys (for VCMS)” refers to a bin file that is used to override the issuer list for testing purposes. 
     “Library Concat” is used to specify up to five libraries chosen from a set of ten QA (quality assurance) libraries. If the field “Stage” is checked, that means the testing should be done using only what is in the production system. 
     Similarly, “Tablebase Concat” can be used to specify up to five table bases from a set of eight existing table bases. 
     The “Special Instructions” field is used to insert user comments and instructions to the IT department receiving the setup request. 
     Below the “Additional Email:” field, there are four fields that can be checked: “CTE Execution”, “CTE-IOA”, “VCMS” and “Freeze Libs”. CTE stands for a group within an IT department called central testing environment. If the “CTE Execution” field is checked, that means the user would like CTE to execute the test environment. If the “CTE IOA” field is checked, however, the user would like CTE to just create the schedule of jobs. “VCMS” stands for Visanet certification member system. If this field is checked, the user would like to use the library of a member bank (e.g., card issuer bank). If “Freeze Libs” is checked, that means the user would like to use a backup copy of whatever is in production. 
     In the “Applications” field, there are 13 input fields that can be checked. These are application programs that need to be added in the test environment if their corresponding boxes are checked. For example, “RSI” and “VSS” respectively stand for Real-time Settlement Interface program and Visanet Settlement System program. 
     The “Special Instructions” comment field allows the user to provide special instructions to the administrator who will be preparing the test environment. 
     Once the submit request page  36  has been filled in, an “Add Record” link  44  is used to add the submit request to the setup request database  14 . Once the Add Record link  44  is clicked by the user, the request management module  34  performs error checking to ensure that all of the fields are in correct format. For example, if the year in the date format for the “Install Date” field is in the wrong format of “Dec. 5, 2010”, the request management module  34  generates an error message along with a prompt to correct the erroneous format. 
     Prior to adding the submit request in the setup request database  14 , the request management module  34  also checks to ensure that all of the required fields are populated. In the embodiment shown, the module  34  ensures that all of the fields with an asterisk are populated. If not, an error message is generated and the user is prompted to input the missing required field. Such error checking ensures that the initial submission of a request for environment setup is sufficient for an administrator to set up the test environment without going back to the user for more information. 
     Once all of the parameters in the displayed fields are determined to be correctly populated and all of the required parameters are determined to be populated, the request management module  34  adds the setup request record to the setup request database  14 . Then, the module  34  sends a confirmation email to the requester submitting the test environment setup request and to any other email addresses specified in the “Additional Email” field. 
     On the submit request web page  36 , clicking on a query link  46  generates the query web page  38  as shown in  FIG. 5 . The query web page  38  allows a user to specify selection criteria to retrieve selected setup records from the database  14 . In the embodiment shown, the setup request records can be search by, for example, a requester of the setup request, owner of the setup request, install date related to the setup request, RTN and the like. Of course, multiple search criteria can be used to narrow the selection. In the embodiment shown, the user has requested retrieval of all setup requests that have been submitted but not yet completed. 
     Clicking on a submit button  50  at the bottom of the query page  38  submits the query to the request management module  34 . The module  34  retrieves selected setup request records from the setup request database  14  and generates the query result web page  40  as shown in  FIG. 6 . In the query result page  40  shown, the request management module  34  has retrieved three setup request records that matched the selection criteria of  FIG. 5 . Each row represents one retrieved setup request record and includes “#” (an internal number assigned to the request when added to the database  14 ), title, status, environment and owner. Although only six fields are displayed due to the display screen&#39;s horizontal size limitation, the request management module  34  can be programmed to display any number of fields in the database record. 
     The field displaying the internally assigned request number is also a link  52 . Upon selecting and clicking on one of the links  52 , the request management module  34  generates the record view web page  42  for the selected setup request record as shown in  FIG. 7 . In the embodiment shown, the user has selected the link for record number  3129 . The web page  42  shows all of the fields of the selected record. 
     The Record View web page  42  contains a replicate button  54 . Upon clicking of the button  54 , the request management module  34  goes back to displaying the submit request web page  36  and populates all of the displayed fields with those from the Record View web page  42 . This replicate feature allows the user to search for a similar environment setup request that has been submitted in the past and let the request management module  34  replicate the fields in a new setup request page. Advantageously, this feature saves the time it takes to manually enter all of the field parameters and reduces possible typing errors. 
     In any of the web pages  36 - 42 , the user can go to the query page  38  and submit request page  36  by clicking on the respective links  46  and  48 . 
     The foregoing specific embodiments represent just some of the ways of practicing the present invention. Many other embodiments are possible within the spirit of the invention. Accordingly, the scope of the invention is not limited to the foregoing specification, but instead is given by the appended claims along with their full range of equivalents.