APPLICATION INTEGRATION TESTING
Application testing is disclosed. A definition of a test to be performed on a subject application is received in a generic form not specific to the subject application. The test is performed by exchanging data with the subject application, as required to perform the test, using a test connector application associated with the subject application to do at least one of (1) convert an input data to be supplied to the subject application during the test from a generic data format not specific to the subject application into an application-specific data format associated with the subject application, if the application-specific data format is different than the generic data format and (2) normalize an output data received from the subject application in the application-specific data format into the generic data format not specific to the subject application, if the application-specific data format is different than the generic data format.
Latest MATADOR TECHNOLOGIES CORP. Patents:
This application is a continuation of co-pending U.S. patent application Ser. No. 12/217,088, entitled APPLICATION INTEGRATION TESTING filed Jun. 30, 2008 which is incorporated herein by reference for all purposes, which is a continuation of U.S. patent application Ser. No. 10/943,778, now U.S. Pat. No. 7,421,621, entitled APPLICATION INTEGRATION TESTING filed Sep. 17, 2004 which is incorporated herein by reference for all purposes, which claims priority to U.S. Provisional Patent Application No. 60/504,403 entitled APPLICATION INTEGRATION TESTING SYSTEM filed Sep. 19, 2003 which is incorporated herein by reference for all purposes.
FIELD OF THE INVENTIONThe present invention relates generally to computers. More specifically, application integration testing is disclosed.
BACKGROUND OF THE INVENTIONIntegrating disparate software systems often creates difficulties and costs due to complexities in infrastructure. At an enterprise level, integrating software systems requires quality assurance (QA) testing, which is becoming increasingly complex. The increasing complexity of software systems requires that QA test systems and software also have greater capabilities than predecessor applications.
For businesses, testing data systems requires thorough QA testing of integrated systems to ensure that data is properly routed between endpoints on the overall system. As legacy systems may often require integration with newer software systems, effective QA software must be able to test multiple processes and applications of varying types. Conventional QA integration testing software is often superficial as the complexity with testing integrated data systems often covers only the input and output of data for particular graphical user interfaces (GUI). For example, conventional QA integration testing software packages that are designed to be cross-platform compatible are often only capable of testing for the proper input and output of data from system GUIs. Conventional QA integration testing software is typically designed for GUI testing or testing only one particular component application of an overall larger system. Thorough testing of integrated software systems requires in-depth testing and evaluation across the entire platform and its individual and disparate components. This process can be costly if conventional QA integration testing software is used, and may be cost prohibitive if extensive custom coding is required. Moreover, for cost reasons typical testing software systems at present provide only single component coverage via software tools, missing major portions of integrated systems, or is done manually with very marginal coverage.
A large part of the costs associated with conventional QA integration testing software are due to the labor-intensive nature of development and integration. Although conventional “off-the-shelf” packages are produced by many software testing companies, specific integration testing with a particular system requires custom coding. Custom coding, in turn, requires platform-specific knowledge as well as testing application-specific knowledge that, when combined, requires significant labor and time costs.
Thus, what is needed is a solution for thoroughly testing integrated software packages that may be composed of disparate systems. There is a need for a solution for testing integrated software systems that automates manual labor intensive parts of testing. Further, there is a need for a solution for testing integrated software systems without incurring significant custom coding or labor costs.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
External environment setup/tear down module 108 provides the initial setup of the testing environment for system 100 with regard to external applications not directly associated with the test, such as by disabling alarms or other features associated with information technology resource monitoring and/or management applications such as Tivoli or OpenView. External environment setup/tear down module 108 also provides for tear down and “clean up” of the external test environment after testing has been completed, such as by reactivating previously-disabled alarms and/or other features. Component call module 110 provides communication capabilities for system 100 to call external (e.g., user-specific) components that are executed subject to rules or policies specified by, for example, a test designer or administrator.
Data is exchanged between system 100 and a subject application via test connector application 104, in this embodiment. In general, various data formats may be used including XML, HTML, or other common data type formats. In one embodiment, one or more custom data type formats may be defined. In one embodiment, a plug-in is used to define a custom data type. Test connector application 104 communicates with test connectors or adapters that are designed to provide a communication interface with various software types, packages, and platforms (e.g., SAP, PeopleSoft, Oracle, Vitria, Tivoli, file systems, FTP, etc.).
In one embodiment, a test connector application 104 (and/or one or more instances of the same connector) is provided for each subject application (and/or instance thereof) with which the system 100 will be required to communicate to perform a test and perform the job of communicating with the application. The connector application 104 understands the low level API/protocol to communicate with the subject application with which it is associated and interface with QA engine 102 and/or other components of system 100 in a standardized, non-application-specific way. In one embodiment, test connector application 104 communicates with QA engine 102 asynchronously using XML messages. In one embodiment, each test connector application 104 comprises a set of custom rules to interface with a given enterprise application. In one embodiment, the custom rules are configured for the following actions: connection properties; the publish properties; the subscriber properties to use; conditions and duration to determine dynamically the behavior for when to connect/disconnect (e.g., how long a test connector communicates with an external application to publish or poll/subscribe for data); application specific setup rules to set up the state of an enterprise application; and application specific tear down rules to clean up the state of an enterprise application. In one embodiment, test connector application 104 provides a data capture module. This data capture module has the functionality to extract data from an external application, which may be use for replaying as inputs or for data comparisons. In one such embodiment data capture module 106 is an integral part of test connector application 104.
In one embodiment, there are three different types of test connector application 104: source connectors, target connectors, and source-target connectors. Source connectors have the functionality of sending data to an application. In general, these types of connectors are used to be the source of inputs into a test. Target connectors have the functionality of retrieving data from an application. The actual process of how the data is retrieved is specific to the application. The purpose of this type of connector is to gather the outputs from an application and send them to QA engine 102 for analysis. Source-target connectors provide the combined logic of a source and target connector. This type of connector is associated with applications that are synchronous, like Web Services over HTTP.
In one embodiment, test connector application 104 is configured to capture baseline data. In one embodiment, test connector application 104 is configured to expose application-specific rules associated with an application involved in a test. For instance, in one embodiment a database test connector is configured to expose application-specific rules such as how long results should be polled for, how many records are expected, poll rate, etc. In one embodiment, an FTP test connector is configured to expose FTP-specific information such as files/directories to delete in a remote FTP server; how long to poll; how long to wait before polling; poll rate; how many files to be downloaded (optional); rules to consider when a file to be downloaded is done (how long should the size/date of the file be fixed before it is considered complete); when a file to be downloaded is always changing, how long to wait before downloading the file once it is initially found; etc. Using test connectors developed for specific software packages, connector application 104 provides sampled and normalized data to system 100. Data can be normalized to XML depending on the test application or left in its original format, to perform integrated QA testing. Data may be gathered from a variety of sources including application programming interfaces (APIs), web services, databases (e.g., Oracle), or other platform enterprise applications (e.g., SAP, PeopleSoft, etc.). Depending on the application with which a connector is associated, data may be received and/or provided by the test connector application in the form of XML or other data, a file, and/or a message or even multi-part (complex) format, a data type with many parts of other data types. In one embodiment, QA engine 102 communicates with test connector application 104 via XML messaging. Data capture module 106 is configured to capture baseline data. In one embodiment, data capture module 106 captures data based on a user-defined test case and obtains the data designated by the user from locations specified by the user.
In one embodiment, test connector application 104 conforms to a standard promulgated by a competent authority or body to specify a format to be used to create standard and/or custom (e.g., plug-in) test connector applications. In one embodiment, the system 100 comprises a workflow or “business process management” engine. In one embodiment, the system 100 is implemented in a J2EE application server.
In one embodiment, system 100 comprises a graphical user interface (GUI), not shown in
In this example, QA engine 200 provides logic capabilities for various functions performed by application integration testing system 100. In one embodiment, correlator 202 correlates runtime data from an integrated application undergoing testing with corresponding baseline data. In one embodiment, this correlation is performed by normalizing the runtime data to a common format (e.g., XML) and applying a predefined correlation rule or process to identify the corresponding baseline data. Correlation may be based on data fields configured as part of the control parameters for system 100 (e.g., “date,” “time,” “number,” “type,” etc.). In one embodiment, a test engineer or other user or process provides an identification of or path to the baseline data corresponding to an element of runtime data, e.g., using an XPATH expression. In one embodiment, correlator 202 may be configured to assume data is provided as output at runtime in the same sequence as it was provided when the baseline data was captured, and correlation is based on this assumption. In some embodiments, QA engine 202 may perform one or more tests or operations that do not involve or require comparison to baseline data. In one such embodiment, QA engine 200 may be configured to validate runtime data against one or more applicable validation rules, as described more fully below. In an embodiment, test, or operation in which a comparison to baseline data is not required or performed, correlator 202 plays no role.
In one embodiment, test analyzer 204 provides a comparison feature of baseline data to run-time output data to ensure proper operation of an integrated application undergoing testing. In one embodiment, test analyzer 204 may be configured to compare only selected data fields or elements so as to ignore differences that would not indicate an error, such as different time stamps. In an embodiment, test, or operation in which analysis other than comparison to baseline data is involved, test analyzer 204 may be configured to validate runtime data by applying one or more applicable validation rules. In one embodiment, validation rules may be applied to runtime data using a validator module not shown in
Internal test environment module 208 provides several capabilities that enable testing to occur by performing tasks required to set up with respect to the application to be tested the initial conditions required for testing and/or to clean up with respect to the tested application after testing. For example, removal of persistent XML data associated with an application to be tested prior to testing may be performed by internal testing environment module 208 in order to ensure that inaccurate test results do not occur.
In order to provide accurate and thorough testing of various software cases (e.g., one input to one output, one input to many output, many inputs to one output, many inputs to many outputs), filter module 210 is provided in addition to correlator module 202. An inclusion filter 212 ensures that the proper data inputs are provided to QA engine 200. Likewise, exclusion filter 214 ensures that unnecessary outputs are not used by QA engine 200. In one embodiment, correlator module 202 provides the matching capabilities to determine which runtime output goes with which baseline output in order to be compared. In one embodiment, this ensures that runtime outputs are correlated with the correct corresponding baseline data for comparison, even if the runtime outputs arrive in different order from test run to test run for the same input, such as may occur, for example, in asynchronous enterprise applications, like MQ, JMS, VITRIA, TIBCO and other message based systems. External communication between QA engine 200 and an integrated application undergoing testing may be provided by channel queue 216, which retrieves data from the integrated application via sampler/mediator 218.
In some embodiments, QA Engine 200 works with applications that generate data in the form of messages (e.g., JMS, Web Services, IBM Message Queue), as well as XML, EDI, ASCII, binary data, and other data. Additionally, QA engine 200 works with applications that generate files as output or use files as input data. In one embodiment, test analyzer 204, correlator 202, and filter module 210 (including inclusion filter 212 and exclusion filter 214) include logic for handling different data formats, in order to ensure proper handling of tested applications that are not able to generate XML output. In other words, testing flexibility is included in these components in order to handle data that is not XML and allow QA engine 200 to operate. In one embodiment, test analyzer 204 comprises several comparison engines. In one such embodiment, test analyzer 204 comprises the following comparison engines: XML Compare, ASCII Compare, Binary Compare, EDI Compare, JMS Compare, and Message Compare. In one embodiment, additional custom data type comparison modules (e.g., plug-ins) may be included in QA engine 200 to support additional custom rules for comparing and/or validating a given data type. Like specific data type comparison/validation engines, such additional custom data type comparison modules include counterparts for correlation and filtering, which in one embodiment also are added for custom data types via a plug-in or other mechanism. In some embodiments, it is not necessary to convert ASCII, binary or other forms of data in order for QA engine 200 to operate. QA Engine 200 can use ASCII, binary, or other forms of data for base comparisons, but data in ASCII, binary, or other forms may be limited in terms of the fidelity of the comparison/validation. ASCII, binary, or other forms of data may be in any format, and QA engine can determine differences between runtime data in a variety of formats and corresponding baseline data. In some embodiments, custom data type plug-in objects may enable special comparison, correlations, filtering, transformation (e.g., decryption), and other functions using ASCII data, binary data, and/or data in custom (non-standard) data type formats. However, if data is output in a standard data type format (e.g., in one embodiment, XML, ASCII, EDI, or JMS), then no custom plug-in is necessary for the operation of QA engine 200. In one embodiment, a custom data type plug-in is required only to enable processing of many inputs to many outputs or one input to many outputs test case, where the data arrives asynchronously and/or is known to vary in order from test run to test run. In one embodiment, a custom data type plug-in is required if the data is not of a standard type and the fidelity of the comparison/validation rules is required to go down to the field level. In such an embodiment, the data must be converted, e.g., using a custom data type plug-in, to and from XML and/or another form in which such field level analysis may be performed with the required fidelity.
In one embodiment, data may be of a complex data type. For example, in some cases complex data types may include metadata and/or multiple parts, one or more of which may comprise data of different types. In one embodiment, a complex data type may be a standard complex data type that the QA engine 200 is configured to recognize and process, e.g., by parsing the complex data to extract the component parts required for processing. In one embodiment, custom complex data types may be defined, including without limitation by defining custom comparison, correlation, filtering, and/or transformation plug-ins for such custom complex data types.
QA engine 200 provides capabilities for designing tests in an enterprise integrated environment. Unlike conventional QA techniques, QA engine 200 is not restricted in the number of enterprise applications that can be used to design, implement, perform, or analyze a test. N number of applications may be operated upon by QA engine 200 and system 100.
In one embodiment, QA Engine 200 is configured to perform functional testing of various components, regardless of system design, in order to determine whether the business functionality provided is executing properly. QA engine 200 also determines in one embodiment when a system change that results in an error (e.g., operation, environment, configuration, etc.) occurs in an application. If so, QA engine 200 can provide a test result summary that precisely determines where the error began and its location in the tested applications involved in an integrated test.
In one embodiment, QA Engine is designed and may be configured to handle one or more of various types of QA tests, including, but not limited to the following:
a. Regressional QA. By recording a baseline data set for input and outputs, system 100 can performed tests using the baseline input and compare test results (i.e., outputs generated at test run time) against the baseline outputs. Baseline data can be referenced from the test definition (e.g., an XML configuration file or other specified file) or in a manner independent of location (e.g., file system, database, LDAP server, etc.).
b. Functional QA. Allow the test designer to apply n number of validation rules to validate the runtime output data from an application being tested. In one embodiment, the validation rules that can be applied against one or more fields; can be any of the following: permitted/expected range of values; list of permitted/expected values; regular expression; mathematical operator-defined (e.g., greater than X, less than Y, not equal to Z); stream validation using text search engines like Lucene; date validation rules for any fields (including in one embodiment date range, date operation, date in a list of known dates, and user-defined date rules with relative date parameters, e.g., a rule requiring that the value of a particular date field be equal to the current day's date whenever the test is run); or custom JAVA class (or similar) to validate a specific field or set of fields.
c. Performance Testing. If a specific time frame has been provided in which to execute a test, system 100 and QA engine 200 ensure that a functional QA test is completed within a specified time frame. In one embodiment, if a specified time frame is exceeded, a failure is noted, and the test is either continued to completion or is stopped based on a user's preference, rule, or policy, as defined in the test definition. In other embodiments, other criteria may be used to indicate successful or failed test results.
d. Stress Test. QA engine 200 can run a functional QA test n number of times and, for every run, apply rules or policies specified for functional QA testing.
e. Robustness Testing. These types of tests include those tests where the test objective is to determine how a particular application or an integrated set of applications respond to different types of inputs. Given a baseline input or set of inputs, a test designer, using QA engine 200 and system 100, can vary any of the inputs into system 100, prior to running tests. The following types of input changes are examples of what a test designer, user, or administrator may define in a test (or test project comprising multiple tests) in one embodiment:
-
- i. Change the value of an input parameter between a min and max value, incrementing with value n, for a given variable type.
- ii. Change the value of an input parameter with a set of values, where the test designer selects particular values (e.g., gold, platinum, silver, etc.).
- iii. Change the value of an input parameter by QA engine 200 generating a random value, between a min and max value for a given variable type.
- iv. Change the value of an input by varying with values from data located in a designated file/database table.
- v. Change the value of an input by specifying a custom java class, which will provide a list of values.
f. Test Chaining In a group of tests in which an input required to be provided for a one test is dependent dynamically on the value of a test runtime output generated by another test, the system may be configured to run the tests sequentially and update the dynamically dependent input prior to running the test with which the input is associated.
g. Test Include. A specified location (e.g., file directory, database) may be searched for test-associated files (e.g., test definition files, test projects comprising multiple test nodes, etc.) that satisfy specified criteria (e.g., all test projects in a particular directory; all test projects within a directory that satisfy a specified regular expression, all test projects that appear on a provided list of test projects, etc.).
The above paragraphs a-g describe examples of various types of tests that can be performed in one embodiment, but in other embodiments other tests not listed above may be performed. In one embodiment, the user defines the tests to be performed by system 100 via one or more XML or other configuration file, referred to in one embodiment as a “test project” configuration file. In this manner, the system can perform tests throughout an integrated set of applications without writing any custom code (e.g., plug-in) in java, c, c++, perl, etc.
In the examples shown in
In one embodiment, a test may involve two or more integrated enterprise applications. In such an embodiment, a separate application-specific test connector application (and/or instance thereof) is used to communicate with each subject application involved in the test. In one embodiment, if an error and/or test failure occurs (e.g., runtime output data does not match corresponding baseline date, or runtime output data does not satisfy an applicable validation rule), the error is categorized base on the subject application that caused the error (e.g., the subject application that generate test runtime output data that failed a comparison to baseline and/or application of a validation rule). In one embodiment, this categorization is made by associating the error with the application-specific test connector application used to communicate with the subject application associated with the error. In one embodiment, certain failures may be categorized in a manner not specific to any one subject application, such as failure of the overall test to be completed within a prescribed time in a performance test.
In one embodiment, an “error” associated with a subject application and/or test connector application may be associated with one or more “failures”, where a “failure” is a single “fail” event, such as an actual difference between a field in the baseline and runtime output, failure to satisfy a particular validation rule, etc. This approach enables a person analyzing the results to know what failures are grouped together within a given error and more quickly localize and analyze all the problems with a given set of test runtime output data.
In some cases, an error may not have any failures associated with it, such as when a connection cannot be established to a particular subject application. In one embodiment, the test can be configured to stop running after a single failure event, e.g., where a test designer only cares to know that at least one comparison or validation failed and does not need to know whether others also would have occurred had the test continued to run.
In the example shown in
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
Claims
1. A method of testing an application, comprising:
- receiving a definition of a test to be performed on a subject application; and
- performing the test;
- wherein performing the test comprises exchanging data with the subject application, as required to perform the test, using a test connector application associated with the subject application to do at least one of (1) convert an input data to be supplied to the subject application during the test from a generic data format not specific to the subject application into an application-specific data format associated with the subject application, if the application-specific data format is different than the generic data format and (2) normalize an output data received from the subject application in the application-specific data format into the generic data format not specific to the subject application, if the application-specific data format is different than the generic data format.
2. A method as recited in claim 1, wherein the subject application comprises two or more integrated subject applications and performing the test comprises using a separate test connector application specific to each of at least a subset of said two or more integrated subject applications to do with respect to the integrated subject application with which it is associated at least one of (1) convert an input data to be supplied to the subject application during the test from a generic data format not specific to the subject application into an application-specific data format associated with the subject application, if the application-specific data format is different than the generic data format and (2) normalize a test runtime output data received from the subject application in the application-specific data format into the generic data format not specific to the subject application, if the application-specific data format is different than the generic data format.
3. A method as recited in claim 1, wherein performing the test comprises correlating a test runtime output data received during the test with a corresponding baseline data associated with the test.
4. A method as recited in claim 1, wherein performing the test comprises comparing a test runtime output data received during the test to a corresponding baseline data associated with the test.
5. A method as recited in claim 1, wherein performing the test comprises comparing a test runtime output data received during the test to a corresponding baseline data associated with the test and taking responsive action if it is determined the test runtime output data is different than the corresponding baseline data.
6. A method as recited in claim 1, further comprising generating a set of baseline data associated with the test by running a baseline iteration of the test using a predefined test case and capturing one or more elements of baseline data generated during the baseline iteration of the test.
7. A method as recited in claim 1, further comprising deriving a validation rule associated with the test by performing a baseline iteration of the test using a predefined test case, capturing one or more elements of baseline data generated during the baseline iteration of the test, and deriving the validation rule based at least in part on at least a subset of the one or more elements of captured baseline data.
8. A method as recited in claim 1, wherein the test connector application is one of a plurality of test connector applications, each specific to a corresponding subject application for which testing is supported.
9. A method as recited in claim 1, wherein the test connector application is selected from a plurality of connector applications, each specific to a corresponding subject application for which testing is supported.
10. A method as recited in claim 1, wherein the test comprises a first test, the subject application comprises a first subject application, the definition comprises a first definition, and the method further comprises:
- receiving in the generic form a second definition of a second test to be performed on a second subject application; and
- receiving an update rule defining a dynamic dependency between a dependent input to be supplied to the second application as part of the second test and a corresponding output generated by the first subject application when the first test is run and requiring that the value of the dependent input be updated based at least in part on the value of the corresponding output at a time subsequent to the corresponding output being generated during the running of the first test and prior to the dependent input being provided to the second subject application during the running of the second test.
11. A method as recited in claim 10, wherein performing the test comprises doing in the order listed:
- performing the first test;
- updating the dependent input based on the value of the corresponding output as generated during the running of the first test; and
- performing the second test
12. A method as recited in claim 1, wherein performing the test comprises automatically setting a testing environment associated with the test to an initial condition associated with the test.
13. A method as recited in claim 1, wherein performing the test comprises automatically cleaning up a testing environment associated with the test to restore the testing environment at least in part to a condition in which it was prior to the test being run.
14. A method as recited in claim 1, wherein the application-specific data format comprises a complex data format.
15. A method as recited in claim 1, wherein the application-specific data format comprises a custom complex data format.
16. A method as recited in claim 1, further comprising:
- receiving, in the event the subject application fails one or more aspects of the test, one or more failure notifications, each associated with a failure event; and
- associating related ones of said one or more failure notifications, if any, together and assigning an error identification to each associated group of failure notifications and to each individual failure notification that is not associated with any other failure notification.
17. A method as recited in claim 16, wherein the test involves a plurality of subject applications, each of which having an application-specific test connector application associated with it, and further comprising associating each error identification that is specific to a particular subject application with a subject application associated with the failure notification(s) associated with the error identification.
18. A method as recited in claim 17, wherein associating each error identification with a subject application comprises associating each error identification with an application-specific test connector application associated with the failure notification(s) associated with the error identification.
19. A system for testing an application, comprising:
- a processor configured to: receive a definition of a test to be performed on a subject application; and perform the test; and
- a memory configured to store the definition;
- wherein performing the test comprises exchanging data with the subject application, as required to perform the test, using a connector application associated with the subject application to do at least one of (1) convert an input data to be supplied to the subject application during the test from a generic data format not specific to the subject application into an application-specific data format associated with the subject application, if the application-specific data format is different than the generic data format and (2) normalize an output data received from the subject application in the application-specific data format into the generic data format not specific to the subject application, if the application-specific data format is different than the generic data format.
20. A computer program product for testing an application, the computer program product being embodied in a computer readable storage medium and comprising computer instructions for:
- receiving a definition of a test to be performed on a subject application; and
- performing the test;
- wherein performing the test comprises exchanging data with the subject application, as required to perform the test, using a test connector application associated with the subject application to do at least one of (1) convert an input data to be supplied to the subject application during the test from a generic data format not specific to the subject application into an application-specific data format associated with the subject application, if the application-specific data format is different than the generic data format and (2) normalize an output data received from the subject application in the application-specific data format into the generic data format not specific to the subject application, if the application-specific data format is different than the generic data format.
Type: Application
Filed: Dec 21, 2011
Publication Date: Jun 28, 2012
Applicant: MATADOR TECHNOLOGIES CORP. (Kirkland, WA)
Inventor: Gustavo Zambrana (Mission Viejo, CA)
Application Number: 13/333,806
International Classification: G06F 11/28 (20060101);