US20080235611A1 - Computer-Implemented Systems And Methods For Analyzing Product Configuration And Data - Google Patents

Abstract

Computer-implemented systems and methods are provided for analyzing configuration data associated with a plurality of software applications. For example a system and method can be configured to receive configuration data about the software applications, wherein the configuration data about the software applications includes configuration items that have relationships with other configuration items. An interface display screen is provided to the user, wherein the user interface display screen is configured to display an evaluation of the retrieved configuration data.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• This application claims priority to and the benefit of U.S. Application Ser. No. 60/919,830, (entitled “Computer-Implemented Systems And Methods For Analyzing Product Configuration And Data” and filed on Mar. 23, 2007), of which the entire disclosure (including any and all figures) is incorporated herein by reference.
TECHNICAL FIELD
• This document relates generally to computer system administration and more particularly to analysis of configuration settings and data.
BACKGROUND
• Modern computer applications are complex systems that may use multiple operating systems, have multiple program components and multiple types of users, each with unique access requirements. System Administrators face a difficult task when attempting to initialize and maintain application uptime and optimization for users. Troubleshooting and optimizing complex computer systems becomes exponentially more difficult as the size of the user base and complexity of their computer needs increases as each product could contain hundreds of configuration settings.
• FIG. 1 is a block diagram depicting a typical prior art manual administration process. Thismanual administration process130 begins with an administrator selecting a set ofsystem behaviors134 desired for capture and analysis instep1 of the process. Once a set ofsystem behaviors134 has been identified, the administrator must then compile a list of data required foranalysis136 of the set of identifiedsystem behaviors134 depicted asstep2.Step3 of the process involves the collection of the data catalogued in the list of data required foranalysis136. This collection step requires manual examination of configuration data from a variety of sources depending upon thesystem behaviors134 selected for analysis.
• In this example, a first source for data can includelocal software applications138 and their associatedconfiguration data140. This data could be accessed through thesoftware application138 or through data files external to the running application. Data required foranalysis136 could also be housed in one ormore data repositories142. These data repositories could be stored locally or remotely.Configuration data148 also may be stored in remote software application instances or in remote data repositories and could be accessed remotely throughservers150. When all data appearing in the list of data required for analysis has been collected, the administrator must analyze the collected data and transform the data to a form useful for the administrator's needs atstep4 of the process. Finally,step5 of the process entails display of the analyzedresults152.
• A weakness of this method is that all tasks fall to the administrator and many of which are manually intensive. For example, as the number of integrated products grow and/or the number of configuration settings increases, the usefulness of this approach diminishes because of the increased complexity in analyzing multiple applications and components through this approach.
SUMMARY
• In accordance with the teachings provided herein, systems and methods for analyzing configuration data associated with a plurality of software applications are provided. For example a system and method can be configured to receive configuration data about the software applications, wherein the configuration data about the software applications includes configuration items that have relationships with other configuration items, and wherein the configuration data about the software applications includes two configuration items that have a relationship. An interface display screen is provided to the user, wherein the user interface display screen is configured to display an evaluation of the retrieved configuration data based upon an evaluation of the relationship between the two configuration items.
• As another example, systems and methods for analyzing configuration data with a plurality of software applications are provided which include software instructions for retrieving configuration data about the software applications. The configuration data is retrieved from the computer location on which their respectively associated software applications are located. The configuration data about the software applications includes configuration items that have relationships with other configuration items, and the configuration data about the software applications includes two configuration items that have a many-to-many relationship between the two configuration items. The systems and methods include interface displaying software instructions for providing a user interface display screen, wherein the user interface display screen is configured to display an evaluation of the retrieved configuration data based upon an evaluation of the many-to-many relationship between the two configuration items.
• As yet another example, a computer-implemented graphical user interface is provided. This user interface contains a first display area for displaying one or more entities that have relationships to other entities. It also includes a second display area for displaying a second set of entities that have relationships to other entities, wherein at least one entity in the first display area has a many-to-many relationship with at least one entity in the second display area.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a block diagram depicting a typical manual administration process.
• FIG. 2 is a block diagram depicting an example system configuration.
• FIGS. 3-5 are block diagrams depicting the flow of data from disparate environments to a configuration settings analysis system.
• FIGS. 6 and 7 are block diagrams depicting exemplary relationships among rules and entities in many-to-many configuration relationship analysis.
• FIGS. 8 and 9 are block diagrams depicting user interfaces for configuration analysis.
• FIG. 10 is a block diagram depicting a configuration settings analysis system utilizing a search engine.
• FIG. 11 is a block diagram depicting use of historical configuration data to aid analysis.
• FIG. 12 is a block diagram depicting remote capture and analysis capabilities.
• FIG. 13 is a block diagram depicting dynamic test diagnostic capabilities.
• FIG. 14. depicts a functional entity relationship diagram.
• FIG. 15 depicts an overview of one embodiment of the method of the present disclosure.
• FIG. 16 depicts a flow chart according to one embodiment of the method of the present disclosure.
• FIGS. 17 and 18 are examples of configuration files.
• FIGS. 19A and 19B depict a user interface for performing configuration file analysis.
• FIGS. 20A-21B depict a configuration check results summary screen and detail screen, respectively.
• FIG. 22 depicts a configuration check data value listing screen.
• FIGS. 23A-24B depict a many-to-many relationship display and selection display, respectively.
• FIGS. 25A and 25B depict a test design and modification display.
• FIG. 26 depicts a test customization display.
• FIGS. 27-28B depict additional test design and modification displays.
• FIG. 29 depicts a batch mode display.
• FIG. 30 depicts a batch mode test group selection display.
• FIG. 31 depicts a test results comparison display.
• FIG. 32 depicts types of task data.
• FIGS. 33-35 depict examples of object data, single test data, and group test data, respectively.
• FIGS. 36 and 37 depict task processing using a search engine and a remote file search agent, respectively.
• FIGS. 38,39, and40 depict a group test results analysis display, a single test results analysis display, and a single data source data value display, respectively.
• FIG. 41 depicts a utility model hierarchy.
• FIG. 42-44 depict an example of an object, an example of a rule, and an example of a model, respectively.
• FIGS. 45 and 46 depict a run model selection display and a model results display, respectively.
• FIGS. 47 and 48 depict a rule details display and an object details display, respectively.
• FIGS. 49A-52 depict a remote data capture and analysis example.
• FIGS. 53 and 54 depict batch mode XML input and batch mode XML output, respectively.
• FIGS. 55 and 56 depict a rule manager display and a model manager display respectively.
DETAILED DESCRIPTION
• FIG. 2 depicts at30 an environment whereinusers32 can accesssystem34 in order to analyze the configuration settings of different software applications. Thesystem34 links or joins different software application environments, thereby allowing for a decrease in time required to gather configuration data across applications. This joining of environments also allows the user (e.g., an administrator, etc.) to have data values automatically compared across software applications. Any test which does not meet the conditions specified by the test is automatically flagged as a potential problem. Accordingly, thesystem34 insulates the user from the visual noise of data not considered important to the test question being asked, and allows the user to focus on the settings considered salient to the test at hand.
• A user can interact with a configurationsettings analysis system34 in a number of ways such as throughnetwork36 and server(s)38. Aserver38 accessible through the network(s)36 can host thesystem34. It should be noted that configurationsettings analysis system34 utilizes the server(s)38 andnetwork36 to enable access to remote data sources such as those housed onremote data stores40 as well asremote environments42. In this setup, the configurationsettings analysis system34 receives data about the software applications auser32 wishes to analyze. These software applications may reside locally with the configurationsettings analysis system34 or they may reside in different and disparate computer environments. The retrieved configuration data items can also have relationships with other configuration items, such as one-to-one relationships, many-to-many relationships, etc.
• Once the configurationsettings analysis system34 retrieves the sought after configuration data, a user interface display screen is provided to the user to display an evaluation of the retrieved configuration data based upon an evaluation of the relationship(s) between the configuration items.
• FIG. 3 is a block diagram depicting the flow of data betweencomputer environments42 and a configurationsettings analysis system34. Anenvironment42 contains a collection of configuration settings for theentities48 operating within itsenvironment42. This collection of configuration settings is used by the configurationsettings analysis system34 for its configuration analysis. Configuration settings for anenvironment46 can be made up of data items from a wide range ofentities48 such as configuration data of local applications, properties of active objects present in an environment, data stores housed within an environment, data sources from other disparate environments linked through the environment, as well as others. The data provided to the configurationsettings analysis system34 is then analyzed according to a set of selectedrules50 in order foranalysis52 of the relationships. The result of theanalysis52 is the generation ofconfiguration diagnostics54.
• FIG. 4 illustrates that theenvironments42 which supply configuration settings to the configurationsettings analysis system34 may operate indisparate environments56 with respect to each other. These environments could be local or remote to the configurationsettings analysis system34 and could span a wide range of applications or a distributed single application.FIG. 5 further illustrates that this set ofdisparate environments56 may differ because of hardware environment disparity or software environment disparity. Hardware environment disparity could include multiple architectures operating on any number of computing machines. Software environment disparity could include applications produced by different software manufacturers utilizing different computer languages, data structures, and protocols.
• A configurationsettings analysis system34 can evaluate the configurations of unrelated applications produced by different software manufacturers as well as being capable of dynamically expanding to cover new products. This expansion is not limited by machine type or tier and is capable of operating across multiple architectures.
• FIG. 6 illustrates several of the different types of relationships that can be analyzed by the configurationrelationship analysis system52. For example, a rule introduced to the configurationsettings analysis system34 from the set of selectedrules50 may require that certain data be contained within certain entities from certain environments.
• While the entities are associated with the rules, the entities may also have relationships amongst themselves. These relationships could be many-to-many, one-to-one, one-to-many, many-to-one, etc. The configuration relationship analysis is capable of taking these relationships into consideration such as handling many-to-many relationships throughsoftware code52. As depicted inFIG. 7,software code52 can further include (or have access to)relationship analysis code58 which examines the rules introduced from the set of selectedrules50 in context of entities that have many-to-many relationships58. This allows comparison of many unique data relationships which may be useful in system configuration diagnostic analysis. In this example embodiment, anenvironment42 may store configuration settings in anobject metadata repository60 for access by the configurationsettings analysis system34.
• FIG. 8 depicts auser interface62 capable of visually displaying the evaluation of the relationships analyzed by the configuration relationshipanalysis software code52. Theuser interface62 can also be capable of displaying relationship evaluations between data stored in separate lists. Additionally, theuser interface62 is capable of visually displaying the evaluation of many-to-many relationships. For example, upon selection of an item from one list, theuser interface62 displays the evaluation of each data in the second list based upon the value of the selected item and displaying those evaluations to the user. This allows the user to rapidly compare many unique data relationships, while isolating them from the manual tasks of identifying the data items to be gathered, gathering the data item values, and manually comparing the values.
• FIG. 9 depicts theuser interface62 having a multiple windowevaluation display capability64. Theuser display62 is capable of displaying multiple tests by opening aseparate evaluation window64 for each test. When a user evaluates a test by selecting a data value within an evaluation window, all of the other evaluation windows dynamically begin a re-evaluation of their data and present new evaluation results based on the re-evaluation across themultiple evaluation windows64.
• FIG. 10 illustrates the configurationsettings analysis system34 retrieving data required for analysis through use of asearch engine66. Thesearch engine66 may be an adaptive search engine which is capable of registering and releasing access classes. Each access class is capable of accessing certain data, such as data from currently active objects in a remote environment, from a local data repository of program configuration settings, or many other sources. The ability to register and unregister these access classes enables the configurationsettings analysis system34 to dynamically expand or contract its searching operations to more efficiently access the data required for its analysis.
• FIG. 11 illustrates that in addition to comparison of data captured during runtime, current configuration data may be compared to previously captured past execution results. This is accomplished by executing a run time configuration settings analysis as described previously to deriveconfiguration diagnostics54. These diagnostics can then be compared to historical data that is archived in a configuration analysisresults data store68. As shown inFIG. 11, comparisons can be made to one set of capturedconfiguration diagnostics70 or to a plurality ofsuch configuration diagnostics70. This allows a comparison of previous configuration captures which were taken during a period of successful operation and comparing those configuration settings to current configuration settings (which may be experiencing configuration problems because of a recent upgrade). The ability to make comparison to past data captures may also be useful in identifying trends and making forecasts of future system performance.
• FIG. 12 illustrates that a remote results capture andtransmission system72 for allowing data to be captured and then sent for remote analysis. The configuration analysis results that are seen at the remote location would be identical to what would be seen if the analysis were completed at the data source site.
• FIG. 13 illustrates that the configurationsettings analysis system34 can also be configured to execute dynamic test-based diagnostics of live systems as shown at80. For example, the configurationsettings analysis system34 is capable of changing the tests performed and the criteria for tests performed at any time such as while the applications to be tested are running. These changes could be requested by the administrator or by updates from an external facility. This allows the configurationsettings analysis system34 to be customized by an administrator to meet their specific system requirements rather than being limited to a generic set of tests and test groups.
• FIG. 14 depicts a process flow for examining, testing, and comparing configuration settings and data (hereafter referred to collectively as ‘data’ unless the context provides otherwise) across multiple independent software applications. A user (e.g., an administrator)134 selects from a list of pre-defined test groups. The administrator is a skilled person that can install, configure, and administer complex software systems comprised of independent software applications but is not required to have any detailed knowledge of the code under test. The administrator selects a test group to be executed atstep1. A test within a test group could be a comparison between two configuration settings, or between a configuration setting and an expected value. A configuration settings analysis system communicates with software applications specified by each test and retrieves the data required to evaluate the test atstep2. The configuration settings analysis system evaluates each test according to the items and actions specified within that test. Results from the test are moved to a graphical user interface where the results are displayed to the administrator atstep3.
• The configuration settings analysis system is capable of analyzing disparate software application environments, thereby allowing for a significant decrease in time required to gather configuration data across applications. This analysis of environments also allows the administrator to have data values automatically compared across software applications. Any test which does not meet the conditions specified by the test is automatically flagged as a potential problem. The system can insulate the administrator from the visual noise of data not considered important to the test question being asked, thereby allowing the user to focus on the settings considered salient to the test at hand. This provides a mechanism which focuses the administrator's attention to anomalous configuration data values within complex integrated systems, extracts and displays all information related to the anomalies (across products), provides a process to gather additional information to aid in identifying the cause of any anomalies (as opposed to simply identifying a system symptom), and provides suggestions on how to correct any anomalies.
• FIG. 15 depicts another operational scenario for analyzing configuration data. Withinadministration environment100, the test design andmodification tool102 allows an administrator to design and modify a list of high level actions that are used to control the execution of the disclosed methods within theprogram environment110 of the configuration settings analysis system. Through the use of thetool102, an administrator maintains a list of all tests and groups of tests that are available within theprogram environment104. Each test is comprised of two data values to be retrieved, a relationship indicator which describes how the data values should be related, and messages that discuss the results. The test design andmodification tool102 allows the administrator to create tests which are comprised of only data that the disclosed system is capable of retrieving, thus the administrator is not required to have any knowledge (or at least a detailed knowledge) of the code.
• Within theprogram environment110, the system reads a set of tests (called the test group), and uses the test group to drive the tasks to be performed. For each test specified, the program independently retrieves the values required by the test and produces a result. Each result represents one test and consists of both the data required by the test, as well as an indicator of whether the required data meets the test's expected relationship state.
• Within thetest result environment116, the administrator reviews the test group results using the program's test results graphical user interface display, which displays each test along with an indicator of the results status. In addition to displaying the title and results of each test, the program can allow an administrator to examine the details of each individual test. This capability identifies for the administrator the name and data value of all data items retrieved as well as the type of relationship expected to exist between the data items, and providing the administrator with an interpretation of the results.
• The environmental separation of the role played by theprogram environment110 and theenvironments100 and116 results in a robust, reusable, easily maintainable, and cost effective configuration setting and data exploration system. This is because integrated software environments are comprised of independently operating software applications. The system requires that each software application has the ability to communicate with specific other software applications within the system. The configuration settings for each software application are unique to each particular software application, and correct operation of a software application may require the setting of hundreds of configuration settings. In order for a software application to communicate with another software application, configuration settings on both of the software applications are set to a value that is logically related.
• In contrast to the example shown in the operational scenario ofFIG. 15, previous approaches would have involved the administrator manually checking the values of the data, manually comparing the values, and manually analyzing whether the data values allow each software application to communicate with another application. However, as the operational scenario ofFIG. 15 illustrates, the configuration settings analysis system can be configured as disclosed herein to automate the gathering of that data, automates the analysis of the data, and focuses the administrator's attention on settings that may be causing problems within the system.
• It should be understood that terms such as “administrator” refer to the role or function of an administrator, including installation, deployment, maintenance, updating, etc. As an illustration, one or more individuals can be used to fulfill the role of an administrator for a particular system. Moreover, while the separated environments allow for the different roles to operate in an insulated fashion, the same person could fulfill two or more of the roles when utilizing the separated environments.
• FIG. 16 illustrates another operational scenario which can include the following steps (whose numbers below correspond to the step numbers shown onFIG. 16):
• • 1. The administrator selects a test group to execute, a batch group to execute, or a list of batch results to examine. If a test group or a batch group of tests is selected, then the list of tests in the chosen group(s) is (are) passed to the program.
  • 2. The program compiles a list of all the data that is to be retrieved to execute all of the tests in the selected test group.
  • 3. The list of data required to execute the selected test group is gathered by parsing an XML document which contains the specific details of all possible tests.
  • 4. The collated list of test specifics is then used as a controller to gather the details for each piece of data that is required.
  • 5. A controller passes the specifics of each piece of data to be retrieved into a retrieval mechanism. The controller does this for all of the required pieces of data.
  • 6. Depending on the location and type of the data, data values are retrieved from one of two retrieval mechanisms;
    • 6A. A search engine which can retrieve data by talking to individual software applications, or reading their configuration files.
    • 6B. A remote agent which can read software application configurations on a remote machine.
  • The search engines retrieves all data values of the type specified, so if a configuration setting occurs in multiple places, it retrieves all of the available values.
  • 7. All retrieved data values are compiled into a list.
  • 8. The compiled list of data values is supplied to a comparator. The comparator retrieves a test from the list of tests to be evaluated, retrieves the data values that are required by the test and compares the data values against each other to see if they meet the specified relationship type.
  • 9. The test results are displayed showing the list of tests executed with an indicator for each test indicating if the test ‘passed’, ‘failed’, ‘more information available by examining the test individually’, or ‘no evaluation performed as this test is for informational purposes only’. The indicator is the decision of an evaluation of all the data values that were returned for a specific test and so is a general indicator of the test results.
  • 10. An administrator may choose to examine an individual test in more detail.
  • 11. If the administrator chooses to view more details about a specific test, all of the information on each data item is displayed in a separate list. Each data item in a list consists of the data source name, data name, data value, and an evaluation indicator. If the administrator selects a specific data item from one list, then all of the items in the other list are compared against the specific data value from the data item that the administrator selected. The comparison results are then displayed in the evaluation indicator location for all of the data items evaluated. A discussion of the evaluation results, what the evaluation is attempting to evaluate, and if an evaluation does not resolve as expected what are some measures that can be taken to fix it is also displayed.
  • 12. An administrator may choose to examine an individual data item in more detail.
  • 13. If an administrator chooses to examine an individual data item in more detail, the list of all data values is retrieved (as shown at13A). From the list of all data values retrieved, the program compiles a list of the data names and data values that are specific to the selected data item. The program then displays the list of all of the data names, and the data values that have been retrieved.
  • 14. The administrator has the ability to create, modify or delete existing tests from the list of available tests (See step3). The administrator also has the ability to create, modify, or delete test groups.
• FIGS. 17-22 provide another illustration contrasting previous approaches and several of the features disclosed herein.FIGS. 17 and 18 employ a traditional manual administration paradigm, where an administrator manually locates the needed configuration source, visually searches the configuration settings, retrieves the appropriate values, and manually compares the values between sources to ensure that the values are set appropriately. It is further noted inFIG. 17 that the repository host name is set to “D15664.” InFIG. 18, the repository server name is set to “D15665.” For this example, these two settings require the same data value in order for the two pieces of software to communicate properly with each other. This problem would produce unexpected results in a system, and the cause would be difficult to identify through the traditional manual administration paradigm.
• In contrast,FIGS. 19-22 illustrate that the cause would automatically be detected by a system configured with at least several of the features disclosed herein.FIGS. 19A and 19B illustrate that an administrator has selected (as indicated by position “1” in the figure) a group of tests related to the software being configured or tested. Following the selection of the test group, the system automatically gathers the required data values for all tests in that test group. In this example, each test within a test group is comprised of two sets of data values. The sets of data values are then compared using the comparison type specified by each test. The results of testing each set of data values are then combined to give a general evaluation of the test.
• An example of this general evaluation is shown in the display screen ofFIGS. 20A and 20B. With reference toFIGS. 20A and 20B, the evaluation results are presented with an evaluation indicator, wherein an ‘X’ symbol represents failure, a check symbol represents pass, and a triangle symbol represents ‘more information’.
• InFIGS. 20A and 20B, each test has a number next to it. For example, test number “9” retrieves the configuration data and executes a comparison of the configuration settings presented inFIGS. 17 and 18. As explained above, the values of the repository host in the configuration file presented inFIG. 17 and the value of the server tag inFIG. 18 have to match in order for the two pieces of software to communicate with each other properly. From the results of the execution shown inFIGS. 20A and 20B, test number “9” is automatically indicated as a test failure by presenting an ‘X’ (at position1) instead of a check. This visually signals the administrator that the settings do not meet the test requirements and may be anomalous. Further information is available by selecting the specific test wished to be examined.
• FIGS. 21A and 21B depict when examining the test in further detail, that the administrator is now presented with both of the values that were retrieved (position1), and an indicator that shows the results of the comparison (position2), the name of the data (position3), the name of the property (position4), the location from which the property was retrieved (position5), and a discussion of the results of the test (position6).
• FIG. 22 depicts further details of individual data values made available through selection inFIGS. 21A and 21B. In this example, the administrator can see the name of the data item is Login.config atposition1. The names of the data that has been retrieved is atposition2, and the values of the data is located atposition3. As can be readily seen by this example, an administrator does not have to be burdened to manually execute many tests in order to fully exercise a question that they are attempting to answer.
• FIGS. 23A and 23B illustrate an exemplary embodiment of a display for analyzing entities having many-to-many relationships. All data that has been retrieved for a specific test is displayed simultaneously in two lists. The administrator can select a specific value from the data settings in either list, and all of the data values in the other list are evaluated against the selected data. Evaluation indicators are displayed for matching values (position2). This feature allows for visual presentation and evaluation of data that occurs not only in many-to-many types of relationships, but also for other types of relationships, such as one-to-one, one-to-many, etc. This allows rapid examination of data that occurs in multiple isolated locations, and provides an efficient system for displaying and evaluating data that occurs in complex relationships.
• FIGS. 24A and 24B illustrate that if a data item is selected from either list (which in this case is the second list), and no data items from the first list evaluate successfully, then evaluation indicators showing failure are displayed. This allows the administrator to quickly evaluate and explore a very large number of data items, their values, and their relationships to other data items.
• FIGS. 25A and 25B illustrate allowing the administrator to select a test to edit or create a new test.Regions1 and2 in the figure allow filtering of the displayed tests by object and property type respectively. Columns permit viewing and sorting of ID numbers, test names, and test descriptions respectively. The ‘Open’ and ‘New’ buttons inRegion6 allows for opening of an existing test or creation of a new Test.
• Upon opening of an existing test or creation of a new test, a test customization display is presented to the administrator. This display allows entry of a name and description for the rule (inregions2 and3 respectively). It also permits specification of which objects are being evaluated in the test being edited or created (region4) and specification of the properties for each object being evaluated in the test. The display can be configured such that only properties available for the selected object are displayed.Region6 allows specification of the relationship type for the test being edited or created, andregion7 specifies how the evaluation results should be displayed for the test being created.Regions8 and9 allow the administrator to specify messages that should be displayed when the test passes or fails.
• A test design and modification display can also be provided for allowing the administrator to create test groups. For example, the administrator could group tests according to the software applications upon which they wish to perform tests. The administrator could also group tests to explore specific system behaviors, anomalies, or logged messages. The administrator could also group tests so that the information is distributed across a number of different location is brought together for ease of exploration.
• FIG. 26 depicts a test customization display which gives an administrator the capability of editing existing tests, or creating new tests. This provides the administrator with the capability of customizing tests to suit their own particular system requirements. The following provides a description of the various regions on the display:
• • Region1: ID number of the test being edited or created.
  • Region2: Name of the test being edited or created.
  • Region3: Description of the test being edited or created.
  • Region4: Specification of which objects are being evaluated in the test being edited or created.
  • Region5: Specification of which properties for each object are being evaluated in the test being edited or created. Only the properties available for the selected Objects are available.
  • Region6: Specification of the relationship type for the test being edited or created.
  • Region7: Specification of how the evaluation results should be displayed for the test being edited or created.
  • Region8: Specification of a message to be displayed to the user in if the evaluation of the test being edited or created should pass.
  • Region9: Specification of a message to be displayed to the user if the evaluation of the test being edited or created should fail.
• FIG. 27 illustrates a test design and modification display which permits creation of new groups or editing of existing groups identified by group name and description. Upon creation of a new group or selection of a group for editing, a display would be presented to allow administrators to specify which tests are included in a test group. As shown inFIGS. 28A and 28B, the display can include a listing of all available tests on the left side (region1), the tests assigned to the current test group on the right side (region3), and controls for including or removing tests (region2).
• Tests and test groups can be run in a batch mode. As shown inFIG. 29, a batch mode program could have two subfolders that provide batch run capabilities.Folder1 allows an administrator to select a list of all of the test groups that they want to run. The second folder allows an administrator to view the results of batch executions. It also allows an administrator to read results files that are received from a remote location. When the administrator views these results files, the program behaves exactly as if the results are live. The interface that is used to present the batch results can be the same as the interface for display of live results. Each interface behaves the same and has the same capabilities. This gives the administrator the ability to check configurations, explore data, and do analysis on the systems from which they are physically isolated. It also provides the administrator with the ability to examine historical data configuration checks.FIG. 30 shows an exemplary interface for selecting tests and test groups for inclusion in the batch inputs folder.
• The batch capabilities also allow for longitudinal comparison of configurations and/or comparisons to be made between different computer/software systems. For example, if a computer/software system has begun having anomalous behaviors, the current configuration test results gathered via the batch mechanism can be compared to configuration test results that are known to have worked before an upgrade or at a specific time in the past. This provides the administrator with the ability to quickly identify changes that have taken place in the software configuration between the system operating in a normal state and in an anomalous state.
• This capability is illustrated in the display ofFIG. 31, wherein two sets of configuration results are compared. As shown atposition1, the result comparison display uses two configuration analysis results generated by the program. These results can be generated on different systems, at different times, or from different locations. As shown atposition2, each test and its accompanying results in this example are compared between the two configuration analysis results. A match indicator is displayed according to the results of this comparison. As shown atposition3, the match indicator is a Boolean indicator displaying whether the test results were the same or different between the configuration results.
• FIG. 32 illustrates that a configuration settings analysis system can be configured to use multiple different types of data, such as the following three types of data:
• • 1. Configuration data sources (known as objects) and the properties that can be retrieved from each source: This document contains a listing of the individual data sources that are available to the program, as well as all of the properties that the program can retrieve for each source.
  • 2. Tests: The ‘tests list’ is an XML listing of all individual tests available to the program. Each test is very specific. A test specifies the two pieces of data that are to be retrieved, as well as what type of relationship that data should have with each other. Only data sources and properties specified in the objects list (item1) can be included in this document.
  • 3. Tests are bound together in groups. A group is simply a listing of tests selected from the test list (item2) that can answer the specific question the administrator is attempting to answer.
    Collectively the three pieces of information are known as “Task Data.” Task data can be stored in a number of forms including in flat files, XML format, within databases, etc.
• With respect to the configuration data source contained in the task data, the configuration data sources can use objects to store configuration information.FIG. 33 depicts an example of a programmed object data type. This example contains an XML listing for an object named “ObjectSpawner”. The object contains the properties ‘application’, ‘description’, ‘name’, ‘type’, and ‘value’. The property tag contains information for retrieval by the configuration settings analysis system. Such properties contained within the property tags include: ‘Name’, ‘Port’, ‘Displayable Name’, ‘Servers started by object spawner’, ‘is object spawner running’, and ‘what machine hosts the object spawner’.
• FIG. 34 depicts an XML example of a single test. In the XML, the test is referred to as a rule. Rules are written based on properties of objects and relationships that exist between them. InFIG. 34, each test is composed of two referencing objects listed in the object data type list. Each object reference include the object name and the configuration setting name (property name) that is needed for the object. Two comment fields are included: a Passed Comment which discusses the results if the test evaluates successfully, and a Failed Comment which discusses the results if the test evaluates unsuccessfully. It should be understood that other types of comments can be used as well.
• FIG. 35 is an XML example of a test group. Each group has identifying information associated with it listed at the top and includes a list of tests (specified by the “<Inc_Rule ID=* />” tag) that are included in the test group.
• A filter can also be made available test groups. Using this filter and after an administrator has selected a test profile (e.g., a test model), the system reads and parses all test data and holds it in memory (or some other storage device). The system examines the data for each test group to determine if the test group meets the testing environment requirements set in the profile. This can be accomplished by examining the application, type, and version properties of each test group and comparing the test group's property values to the values specified in the profile. If a test group meets the requirements set in a profile, the test group is included in a display of the test groups available for execution (e.g., as discussed above with respect toFIGS. 19A and 19B).
• When an administrator selects a test profile or test model for execution, the data for each test in the selected model is read and a list is compiled which identifies all of the required objects and the properties required from each object. This is done to prevent duplication of execution because an object and its data may be used by more than one test in a test group. For each object in the list, the system attempts to retrieve the required data values for the specified settings. For each object that requires the system to communicate with a software application, repository, or host environment, the model asks the controller to retrieve the required objects. It accomplishes this by using either the type of object required or both the type of object and the name or specifying object ID of the specific object required. If the information is the type of object required, the system would retrieve pointers to all objects of the specified type. If the information is both the type of object and the ID of the object then the system retrieves pointers only to the objects of the specified type, which match the name or ID.
• Once the system has collected all objects required by the tests, the property values are retrieved. The system iterates through the list of objects sequentially, passing a pointer to each object, the name of the object's class, the object's value, the name of the property to be retrieved, the type of the property, and the potential value of the property to a search engine. This is accomplished by calling the fetchSingleObjectProperty (String classname, Object obj, String obj_value, String prop, String type, String value) method. Not all of the values passed in are required to retrieve each property value. The system receives the values returned by the search engine and passes them to their individual tests for storage.
• For each object that is a configuration file, the system locates and reads the specified configuration if it is available locally. If the required configuration file is not available locally, the system locates and reads the configuration file by using a remote agent that is installed on a web application server. The system receives the values returned by the search engine and passes them to their individual tests for storage.
• To facilitate the task of searching for the proper objects, a search engine as depicted inFIG. 36 can be used by a configuration settings analysis system. The search engine, which is designed to search for either specific data types or data from specific software applications to be dynamically registered and unregistered with the search engine. This allows the search engine to add capabilities in retrieving new types of data without having to change the search engine code. This also allows the search engine to select the code it will execute so that the executed code is specific to the types of searches to be performed. This reduces system overhead and reduces the amount of time required to execute a search. Thus, the search engine has the capability to change according to the tasks it needs to perform.
• When a new searching class is registered with the search engine, the class could be held in a hash table or map with the class as the key (e.g., through call such as the following: registered Searchers.put(Class,code)). The search engine then creates a map that contains pointers to all of the search methods within all of the registered search code that can be used to retrieve data. By holding these methods in a map, the system has very fast access to those methods, thereby reducing the time required to execute any method since the registered searching class does not have to locate the method for use. The methods that are stored in the method map are not limited by operating system, tier, machine architecture, or product. Each method may include the ability to access data values crossing any of these boundaries. Using the parameters passed into the search engine, the search engine attempts to identify which methods are most likely to successfully retrieve the required data values. The search engine then executes the identified methods. If the chosen methods do not successfully retrieve the needed data values, the search engine identifies all methods that can be successfully run using the fetchSingeObjectProperty method parameters, and begins a systematic search of these methods to retrieve the required data values. Once retrieved, the search engine passes the data values back.
• When the system is retrieving a data value for a test which requires data from a remote and otherwise inaccessible configuration file, the method calls a remote method (e.g. utilizing SOAP over HTTP) which will retrieve the data from the service agent's host. The agent's ability to perform this task is not limited by operating system, tier, or machine architecture. As an illustration,FIG. 37 depicts example task processing using a remote file search agent. The system first makes a connection with a web application server. The web application server then communicates with the remote file search web application. The remote file search web application receives the request to locate a list of specific configuration setting values from a list of specified configuration files. The remote file search web application searches the remote machine, locates any data meeting the specified requests, and returns the value to the remote file search web application. The data values gathered are then returned to the program.
• After all of the data values are retrieved, the program analyzes each individual test, and displays the results in a general display test results display. If an administrator wishes to examine the results of any individual test in more detail, they may select a test from the general test results display. This will open the specific test results display. An administrator is then able to examine all of the retrieved data for any particular instance of a data value by selecting the data value within the specific test results display. The program will then retrieve, from the model, all of the data names and data values that are related to the instance from the model. The retrieved data names and data values are then displayed in a table.
• In one example view which is shown inFIG. 38, a group test result analysis interface displays a listing of all of the tests just executed (region C), a test number indicator (region B), as well as an indicator of the test results (region D). The group test results are calculated by evaluating all of the data values that were returned to the program. If all of the data values evaluate successfully, then the global result indicates pass. If any of the data values evaluate unsuccessfully, then the group result indicates failure. The indicator can take one of several forms including ‘passed’, ‘failed’, ‘more information available by selecting this test’, and ‘information only—no evaluation was performed’. Also included is an area where an administrator can read a detailed description of any test selected (region E). This tool isolates the administrator from the program environment and gives the administrator the ability to identify data areas that may contain anomalous values. The administrator may elect to explore any individual test by choosing a single test.
• FIG. 39 shows a single test result analysis interface tool. This tool retrieves the data names and values from the model, which retrieves the specific test from the list of tests, and then retrieves the data values stored in the individual tests. The specific test result interface displays all of the data values retrieved for the test. It then provides the administrator with the ability to evaluate and compare the data values that have been retrieved. Each test is comprised of two types of data. The results for each type of data are displayed in separate tables (region F). The specific test result display shows all found instances of each of these data types within a table, with the different instances being displayed in a list format (region L). Each line of the list includes the name of the source for that particular instance (region G), as well as the data name (region I), the value of the data (region I), as well as an evaluation indicator (region J).
• The single test result analysis interface tool also includes an area (region K) that contains a discussion of how the two data tables are related, a discussion of the results, suggestions on how to fix the results if not as expected, and links to further information. The administrator exercises the analysis of the test by choosing a specific instance of data from either table. The tool automatically compares the data values between the chosen instance and all of the data values in the other table. It then places an evaluation indicator next to the data in the opposite table. This indicator has several potential values including ‘passed,’ ‘failed,’ and ‘information’. This isolates the administrator from the need to compare and analyze data values, and provides the administrator with a quick scan capability that focuses attention on anomalous data values.
• FIG. 40 illustrates another view all of the data values (region C) collected from a single data source (region B). This provides the administrator with the ability to immediately access a single compilation of data for a single configuration data source. This ability isolates the administrator from the software applications and documents that comprise the system.
• The objects used in the task data can be structured in many different ways, such as the manner shown inFIG. 41.FIG. 41 shows that a model is a test group that is comprised of a list of rules and other models. Within the model, objects are referenced by rules for specifying how configuration data is to be analyzed. An object can represent anything that information can be retrieved about; such as a workspace server, a library, a user, or a configuration file.
• FIGS. 42-48 provide an example of using a model within a configuration analysis scenario. In this example,FIG. 42 shows an object “IdentityGroup” that is defined with a value (“IdentityGroup”) and type (“SASObject”) which are used to instruct the system to retrieve all objects specific to the IdentityGroup type. These IdentityGroup Objects are then made available for inspection. The object also specifies property names (“Displayable Name,” “Name”, “Members,” and “Logins”) which are used to provide instructions to the system describing which specific property values the system should retrieve if asked to do so.
• FIG. 43 shows a rule being defined with a unique rule identifier (“108”), the name of the rule that is to be displayed on the interface (“Users belong to which Identity Groups”), and a description which in this example is the same as the displayable name. The rule specifies two objects (“person” and “IdentityGroup”) and the relationship (“AtLeastOneMatches”) that is to be used in analyzing the two objects.
• FIG. 44 shows a model being defined that uses the object and rule that were defined inFIGS. 42 and 43. The model has a name (“Users”), a type (“Explore”), and an application value (“SASManagementConsole”) which are used to assist the end user by providing uniquely identifiable and filterable descriptive variables as they decide which models they are interested in viewing. The model also specifies which rules are to be included in the model. Two rules are specified includingrule number108 which was defined above.
• FIG. 45 displays to an administrator a list of models that the administrator can select to form iteration analysis. The first column of the display lists the model names. The second column indicates the type of the model. The third column indicates the application. The administrator can filter the list of models based on the model type in order to hone in upon the specific types of models. For example, models can be filtered upon whether the model is a diagnostic only model, and explore only.
• As shown inFIG. 45, the administrator has selected the “Users” model. The administrator can click upon the show details button on the interface in order to show additional descriptive information about what the model covers. The administrator could also click upon the run model button in order to have the model execute.
• FIG. 46 shows the results from the execution of the “Users” model. The display ofFIG. 46 illustrates that the rules associated with the selected model have resulted in issues being identified as illustrated in the last column of the display. The administrator can click upon the show details button in order to view detailed diagnostic information associated with the identified issues.
• FIG. 47 provides an example of an interface providing details about application of the rule. In the example ofFIG. 47, details aboutrule number108 are provided in the interface. This rule is directed towards checking users or persons belonging to which identity groups. Accordingly, the upper left-hand portion of the interface contains user or “Person” information, and the upper right-hand portion of the interface contains identity group information.
• The administrator has selected the object “SAS Administrator” that is located in the upper left-hand portion of the interface. In response, an evaluation is performed based upon the selected object. The evaluation results are shown in the last column of the identity group portion of the interface. The administrator can select the refresh button to see if any evaluation results have changed since the time of the last evaluation administrator can also select the show details button in order to view additional information about the selected object.
• FIG. 48 is example of a window providing additional details about the selected object. In this example, the object “SAS Guest” have been selected, and the object details window provides values and other information associated with the selected object.
• FIGS. 49A-52 provided an example of deploying a new application. As shown inFIGS. 49A and 49B, an administrator selects the application to be deployed as indicated at position one on the figure. The administrator selects the interface item atposition2 in order to select the deploy action. The administrator selects the archive for this application atposition3, and clicks upon the target application button atposition4. As shown inFIG. 50, the administrator selects the server atposition5 on the interface, and clicks upon the continue button atposition6. As shown inFIG. 51, the name is entered atposition7, and the deploy operation is initiated upon the button indicated atposition8. The interface onFIG. 52 is a new profile Wizard for adding information about a new machine or application. In this example, the machine name is added along with the type of server it is. This provides an orderly deployment of an application or computer, wherein information about its configuration is automatically handled.
• A configuration settings analysis system can also be run from a command line, and produce output that can be viewed without being connected to a repository network. This can be useful in many different situations, such as technical support of remote systems, system administrators supporting multiple repositories, etc.FIGS. 53 and 54 respectively show XML input and XML output for use when the configuration settings analysis system is being run in batch mode. In such a mode, the configuration settings analysis system automatically receives the input data it needs to perform its configuration analysis automatically, and outputs the results in a data file for later examination.
• While examples have been used to disclose the invention, including the best mode, and also to enable any person skilled in the art to make and use the invention, the patentable scope of the invention is defined by claims, and may include other examples that occur to those skilled in the art. Accordingly the examples disclosed herein are to be considered non-limiting. As an illustration, the systems and methods may be implemented on various types of computer architectures, such as for example on a single general purpose computer or workstation, or on a networked system, or in a client-server configuration, or in an application service provider configuration.
• As another example, a system and method can include interfaces to assist the administrator in defining models, rules, batch mode input files, and other relevant items. As an illustration,FIG. 55 shows an interface wherein administrator can visually create a rule, andFIG. 56 shows an interface for visually creating a model.
• Further, it be understood that systems and methods disclosed herein are applicable to all situations involving configuration data analysis. For example, a system and method can be configured to analyze configuration settings associated with an initial installation of what Amore software applications over one or more computer environments.
• Additionally, the methods and systems described herein may be implemented on many different types of processing devices by program code comprising program instructions that are executable by the device processing subsystem. The software program instructions may include source code, object code, machine code, or any other stored data that is operable to cause a processing system to perform methods described herein.
• The systems' and methods' data (e.g., associations, mappings, etc.) may be stored and implemented in one or more different types of computer-implemented ways, such as different types of storage devices and programming constructs (e.g., data stores, RAM, ROM, Flash memory, flat files, databases, programming data structures, programming variables, IF-THEN (or similar type) statement constructs, etc.). It is noted that data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program.
• The systems and methods may be provided on many different types of computer-readable media including computer storage mechanisms (e.g., CD-ROM, diskette, RAM, flash memory, computer's hard drive, etc.) that contain instructions (e.g., software) for use in execution by a processor to perform the methods' operations and implement the systems described herein.
• The computer components, software modules, functions, data stores and data structures described herein may be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. It is also noted that a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code. The software components and/or functionality may be located on a single computer or distributed across multiple computers depending upon the situation at hand.
• It should be understood that as used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise. Finally, as used in the description herein and throughout the claims that follow, the meanings of “and” and “or” include both the conjunctive and disjunctive and may be used interchangeably unless the context expressly dictates otherwise; the phrase “exclusive or” may be used to indicate situation where only the disjunctive meaning may apply.

Claims (49)

1. A computer-implemented method for analyzing configuration data associated with a plurality of software applications, comprising:

retrieving configuration data about the software applications;

wherein the configuration data is retrieved from the computer location on which their respectively associated software application is located;

wherein the configuration data about the software applications includes configuration items that have relationships with other configuration items;

wherein the configuration data about the software applications includes two configuration items that have a many-to-many relationship between the two configuration items;

providing a user interface display screen;

wherein the user interface display screen is configured to display an evaluation of the retrieved configuration data based upon an evaluation of the many-to-many relationship between said two configuration items.

2. The method ofclaim 1, wherein the user interface display screen is configured to display relationship evaluations between configuration data stored in two separate lists;

wherein each list is populated by more than one configuration item;

wherein a user interface is provided to the user to allow the user to select a configuration item from a list, and have every configuration item in the other list evaluated based on the value of the selected configuration item.

3. The method ofclaim 2, wherein the selected configuration item from the list is one of the two configuration items having the many-to-many relationship with the other of the two configuration items;

wherein the evaluated configuration item in the other list is said other of the two configuration items having the many-to-many relationships.

4. The method ofclaim 2, wherein the evaluation of each configuration item in the other list is then automatically displayed to the user, thereby providing to the user a comparison of the relationships, while isolating the user from the manual tasks of manually comparing values associated with the relationships.

5. The method ofclaim 1, wherein the configuration items are software objects having classes and properties;

wherein a configuration test model includes rules and other configuration test models.

6. The method ofclaim 5, wherein the rules specify criteria for performing evaluations of the retrieved configuration data.

7. The method ofclaim 5, wherein the rules specify criteria for performing evaluations based upon the relationships of the retrieved configuration data.

8. The method ofclaim 5, wherein the configuration items includes configuration information about a workspace server, a library, a user, and a configuration file.

9. The method ofclaim 1 wherein one or more of the software applications resides in a different and disparate computer environment than the other software applications.

10. The method ofclaim 9, wherein the different and disparate computer environment is different with respect to server location.

11. The method ofclaim 9, wherein the different and disparate computer environment is disparate with respect to an environment characteristic selected from the group consisting of software manufacturer vendor source, machine type or tier, software or hardware architecture, software operating system.

12. The method ofclaim 1 further comprising:

storing past results of evaluations of the retrieved configuration data for evaluating how a machine's configuration settings have changed over time.

13. The method ofclaim 1 further comprising:

storing past results of evaluations of the retrieved configuration data for comparing the results between a properly configured setup against a similar configuration that is not operating properly.

14. The method ofclaim 1 further comprising:

capturing results of evaluations of the retrieved configuration data;

providing the captured results from the user to a third party;

wherein the captured results is provided to the third party for remote analysis of the captured results within the computer environment of the third party for local examination of the captured results by the third party.

15. The method ofclaim 14, wherein the captured results that the third party views on the third party's user interface are identical to the evaluations of the retrieved configuration data viewed by the user on the user interface display screen, thereby enabling technical support by dissemination of diagnostic evaluation results to remote locations which have to ability to view the results as if the results were local.

16. The method ofclaim 1 further comprising:

running multiple configuration evaluation tests by opening a separate results user interface window for each different test.

17. The method ofclaim 16 further comprising:

selecting a configuration item within one of the separate results user interface window;

wherein in response to said selecting, all of the other result windows dynamically perform a re-evaluation of their respectively displayed configuration data and present new evaluation results based on the re-evaluation.

18. The method ofclaim 17, wherein by said selecting of the configuration item, the data view is not changed with respect to the user interface windows.

19. The method ofclaim 18, wherein the performed re-evaluation comprises initiating a new evaluation process that results in new evaluation data occurring across separate results user interface windows.

20. The method ofclaim 1 further comprising:

providing a test group results display screen to the user, wherein the test group results display screen contains test group configuration evaluation results and displays each test group along with an indicator of the results status associated with each test group.

21. The method ofclaim 20 further comprising:

displaying details of results of a test group configuration evaluation in response to receiving a selection from the user of one of the test group configuration evaluation results.

22. The method ofclaim 21, wherein the displayed details of results includes identifies for the user the name and data value of the configuration items retrieved, as well as type of relationship expected to exist between the configuration items, and includes an interpretation of the results.

23. The method ofclaim 20, wherein at least one of the test groups group tests according to the software applications for which tests are to be performed upon, or group tests to explore specific system behaviors, anomalies, or logged messages, or group tests so that information that is distributed across a different and disparate computer environment is aggregated into one computer-based location.

24. The method ofclaim 1, wherein the software applications are in an operational and executing state when the configuration data is retrieved and evaluated.

25. The method ofclaim 24 further comprising:

receiving edits to configuration tests from a user;

wherein the tests indicate which of the configuration items are to be retrieved.

26. The method ofclaim 25, wherein the test configuration edits are generated by an administrator or by updating the configuration tests in an update facility, thereby providing for customization of the configuration tests within a different and disparate computer environment.

27. The method ofclaim 25, wherein the configuration tests are configured to be self-evaluating so that the configuration tests autonomously gather the configuration data and automatically determine configuration anomalies.

28. The method ofclaim 27, wherein the self-evaluating of the configuration tests obviates a requirement for directing direct the user to configuration data locations where the user can gather information or provide the user with a generic configuration data checklist.

29. The method ofclaim 28, wherein the configuration data checklist is generic with respect to type of computer environment.

30. The method ofclaim 25 wherein a first configuration test includes high level test actions, said method further comprising:

receiving a list of high level test actions for controlling execution of the first configuration test.

31. The method ofclaim 30, wherein the first configuration test specifies that at least two configuration data values to be retrieved;

wherein the at least two configuration data values include a relationship indicator which describes how the data values should be related and messages that discuss configuration evaluation test results.

32. The method ofclaim 1, wherein the configuration items are software objects having classes and properties;

wherein an adaptive search engine registers and releases classes that form criteria for specifying what configuration data is to be retrieved about the software application, thereby providing an ability to dynamically expand or contract searching to fit the configuration items to be retrieved.

33. The method ofclaim 32, wherein the objects required by a test are collected and the adaptive search engine retrieves the objects' property values.

34. The method ofclaim 33, wherein the adaptive search engine is provided with parameters about the objects;

wherein the parameters about the object includes object data selected from the group consisting of pointer to an object, name of an object's class, value of an object, name of the property to be retrieved, type of the property, potential value of the property, and combinations thereof.

35. The method ofclaim 34, wherein the adaptive search engine uses the parameters passed into the search engine to identify first methods to retrieve values for the configuration items;

wherein if the identified first methods do not successfully retrieve the values, the search engine identifies second methods by using fetch object property method parameters, and performs a search though use of the second methods to retrieve the values.

36. The method ofclaim 32, wherein when a new searching class is registered with the adaptive search engine, the new searching class is held in a hashtable with the new searching class as the key or a map with the new searching class as the key.

37. The method ofclaim 36, wherein the hashtable or the map contains pointers to search methods within registered search code is used to retrieve data.

38. The method ofclaim 1 further comprising:

receiving a configuration test group to execute,

wherein the configuration test group includes high level configuration test actions;

compiling a list of all of the configuration items that are to be retrieved in order to execute the tests in the received configuration test group;

wherein said retrieving step includes, based upon location and type of the configuration items that are to be retrieved, retrieving values of configuration items by:

(a) a search engine which retrieves data by communicating with the software applications or reading configuration files associated with the software applications, wherein the search engines retrieve all data values of a specified type such that if a configuration setting occurs in multiple computer locations, the search engine retrieves all of the available values;

(b) a remote agent which reads software application configuration files on a remote machine;

compiling into a list the data values that were retrieved by said retrieving step;

wherein the compiled list of data values is supplied to a comparator;

wherein the comparator retrieves a test from the list of tests to be evaluated, retrieves the data values that are required by the test and compares the data values against each other to determine if the compared data values satisfy the specified relationship type;

displaying the test results by showing the list of tests executed with an indicator for each test indicating if the test passed;

said providing step being performed in response to selection of one of the displayed test results.

39. The method ofclaim 1, wherein the evaluation of the retrieved configuration data based upon an evaluation of the many-to-many relationship between said two configuration items includes a determination if configuration settings involving said two configuration items are set to a value that allows for proper software functioning.

40. The method ofclaim 1, wherein the evaluation of the retrieved configuration data based upon an evaluation of the many-to-many relationship between said two configuration items includes a determination if configuration settings involving said two configuration items are set to a pre-determined value.

41. The method ofclaim 9, wherein the configuration data is stored in metadata repositories in the different and disparate computer environment.

42. The method ofclaim 1, wherein the configuration data is software application installation configuration data.

43. The method ofclaim 1, wherein the configuration data is post-installation production configuration data.

44. The method ofclaim 4 wherein the comparison includes a comparison of configuration evaluation results.

45. A computer-implemented system for analyzing configuration data associated with a plurality of software applications comprising:

software instructions for retrieving configuration data about the software applications;

wherein the configuration data is retrieved from the computer location on which their respectively associated software application is located;

wherein the configuration data about the software applications includes configuration items that have relationships with other configuration items;

wherein the configuration data about the software applications includes two configuration items that have a many-to-many relationship between the two configuration items;

interface displaying software instructions for providing a user interface display screen;

wherein the user interface display screen is configured to display an evaluation of the retrieved configuration data based upon an evaluation of the many-to-many relationship between said two configuration items.

46. A computer implemented method for analyzing configuration data associated with a plurality of software applications comprising:

retrieving configuration data about the software applications;

wherein the configuration data is retrieved from the computer location on which their respectively associated software application is located;

wherein the configuration data about the software applications includes configuration items that have relationships with other configuration items;

wherein the configuration items are software objects having classes and properties;

wherein an adaptive search engine registers and releases classes that form criteria for specifying what configuration data is to be retrieved about the software application, thereby providing an ability to dynamically expand or contract searching to fit the configuration items to be retrieved;

providing a user interface display screen;

wherein the user interface display screen is configured to display an evaluation of the retrieved configuration data.

47. A computer implemented system for analyzing configuration data associated with a plurality of software applications comprising:

software instructions for retrieving configuration data about the software applications;

wherein the configuration data is retrieved from the computer location on which their respectively associated software application is located;

wherein the configuration data about the software applications includes configuration items that have relationships with other configuration items;

wherein the configuration items are software objects having classes and properties;

wherein an adaptive search engine registers and releases classes that form criteria for specifying what configuration data is to be retrieved about the software application, thereby providing an ability to dynamically expand or contract searching to fit the configuration items to be retrieved;

interface displaying software instructions for providing a user interface display screen;

wherein the user interface display screen is configured to display an evaluation of the retrieved configuration data.

48. A computer-implemented graphical user interface comprising:

a first display area for displaying one or more entities that have relationships to other entities;

a second display area for displaying a second set of entities that have relationships to other entities;

wherein at least one entity in the first display area has a many-to-many relationship with at least one entity in the second display area.

49. A computer-implemented method for analyzing configuration data associated with a plurality of software applications, comprising:

retrieving configuration data about the software applications;

wherein the configuration data is retrieved from the computer location on which their respectively associated software application is located;

wherein the configuration data about the software applications includes configuration items that have relationships with other configuration items;

wherein the configuration data about the software applications includes two configuration items that have a many-to-many relationship between the two configuration items;

providing a user interface display screen;

wherein the user interface display screen is configured to display an evaluation of the retrieved configuration data based upon an evaluation of the many-to-many relationship between said two configuration items;

wherein the configuration items are software objects having classes and properties;

wherein a configuration test model includes rules and other configuration test models;

wherein the rules specify criteria for performing evaluations based upon the relationships of the retrieved configuration data.

Images