Patent Application
20170004490
The present disclosure generally relates to systems and methods for use in managing data definitions within applications such as, for example, payment transaction applications, and the like.
This section provides background information related to the present disclosure which is not necessarily prior art.
A variety of data transfers occur within a payment network to permit transactions for the purchase of products and services. Applications involved in the handling of such transactions typically store transaction data in a variety of different locations in one or more forms, whereby the transaction data is appended to mass storage of data. In order for the data to be properly incorporated into the mass storage of data, forms of the transaction data delivered from the applications must be consistent with a predefined standard applied in connection with the mass storage.
The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure.
Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.
Exemplary embodiments will now be described more fully with reference to the accompanying drawings. The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.
As applications are developed, different programs and/or computer code segments, etc. (broadly, applications) are developed to generate and/or compile data related to particular operations (e.g., payment transactions, etc.) associated with the applications. The form in which the data is generated is defined by the applications, i.e., via data definitions. For example, data definitions may define data structures (e.g., tables, etc.), in which different data related to payment transactions, or other operations, is arranged, for example, into columns and rows. Further, the data structures may have other considerations such as, for example, nomenclature of columns, table names, class words for the columns of the tables (and maintaining such class words for the columns), table content, key validations, index validations, etc. As described herein, when the data structure is defined by an application, the data structure will be validated against standard definitions (so that, subsequently, it can be consistently processed as desired, for example, in connection with other data structures, etc.) and, if not in compliance, a report will be generated with all the violations so that the data structure can be fixed, updated, etc. before proceeding further in the development of the corresponding application and/or production release of the application.
The systems and methods herein provide for managing data definitions defined by applications, as the applications are developed, i.e., in pre-production applications. By testing the data structures of the pre-production applications, as the applications are developed incrementally (broadly, regularly, or occasionally), the data definitions of the applications may be altered and/or adjusted, during the development process, to conform to standard data definitions. In this manner, the development process results in production applications in which the data definitions therein are consistent with the standard data definitions. As such, the systems and methods herein can help reduce the potential of applications to have errant data definitions, whereby the applications must either be reworked, or implemented with the errant data definitions.
The system 100 generally includes a development part 102 and an implementation part 104, in which various applications (e.g., payment transaction applications, etc.) are implemented.
The development part 102 of the system 100 includes a development environment 106, in which applications, including computer code segments, modules, etc., can be developed (e.g., pre-production applications, etc.). The development environment 106, in general, provides an environment in which one or more applications may be developed based on one or more existing application components (or modules), or as original components (or modules). The development environment 106 permits stand-in data, and/or data structures, to be setup or available, so that the applications can link to the data, or the data structures, whereby particular functions or processes in the applications may be executed (during development) with the data, or data structures, mimicking the data, or data structures, as present in the post-production or deployed (or live) environment. In various aspects, some application components (or modules) will be available to some developers but not others, depending on need, authorization, application type, etc.
In various embodiments, the development environment 106 provides management of coding, revision control, centralized development (e.g., cloud development, etc.), and ease of collaboration among multiple users. Generally, when an application is to be developed, a project is created in the development environment 106, through which one or more users can participate in developing the application. While one development environment 106 is shown in the system 100 of
As shown in
The conformance engine 108, as described more with reference to
With continued reference to
In the illustrated system 100, the merchant 110, the acquirer 112, the payment network 114, and the issuer 116 of the implementation part 104 are coupled together via a network 118. In addition, the development environment 106 and the conformance engine 108 of the development part 102 are each coupled to the network 118. The network 118 may include, without limitation, a wired and/or wireless network, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, and/or another suitable public and/or private network capable of supporting communication among two or more of the illustrated components of the system 100, or any combination thereof.
Generally in the implementation part 104 of the system 100, when a consumer desires to purchase products (e.g., goods, services, etc.) from the merchant 110, the consumer presents payment account information to the merchant 110 in connection with the transaction. The merchant 110, the acquirer 112, the payment network 114, and the issuer 116 then cooperate, in response to the consumer, to complete the transaction using the consumer's payment account. As part of the payment transaction, the merchant 110 reads the payment account information from the consumer and communicates, via the network 118, an authorization request to the payment network 114, via the acquirer 112 (associated with the merchant 110), to process the transaction (e.g., using the MasterCard® interchange, etc.). The authorization request includes various details of the transaction (e.g., transaction data, etc.) to help facilitate processing the authorization request. The payment network 114, in turn, communicates the authorization request to the issuer 116 (associated with the consumer's payment account). The issuer 116 then provides an authorization response (e.g., authorizing or declining the request) to the payment network 114, which is provided back through the acquirer 112 to the merchant 110. The transaction with the consumer is then completed, or not, by the merchant 110, depending on the authorization response.
For the above transaction, transaction data is generated as part of the interactions among the merchant 110, the acquirer 112, the payment network 114, and the issuer 116. The transaction data may be used, for example, to clear and settle the transaction, provide for accrual of reward points to the consumer, at point of sale (POS) terminals, etc. In addition, the transaction data may include, without limitation, a payment account number (PAN) for the consumer's payment account involved in the transaction, a payment amount for the products involved in the transaction, identifiers for the products involved in the transaction, descriptions of the products involved in the transaction, a listing of products involved in the transaction, a merchant name for the merchant 110 involved in the transaction, a merchant identification number (MID) for the merchant 110, a merchant category code (MCC) assigned to the merchant 110 (e.g., by the payment network 114 or by another payment network, based on a type of product and/or service normally provided by the merchant 110, etc.), a date and/or time of the transaction, a location of the transaction, etc.
The transaction data is stored in one or more different components of the system 100, and transferred therebetween. In particular in the above transaction, applications, in place at the merchant 110, acquirer 112, payment network 114, and issuer 116 (and potentially others), capture and compile the transaction data related to the transactions. The transaction data may then be stored in memory associated with one or more of the different components of the system 100. In connection with storing and/or transferring the transaction data, the transaction data is often subject to automated processes and/or incorporation with other transaction data, and/or other data. It is therefore preferred to provide the transaction data according to one or more standard data definitions, whereby proper integration and/or recognition of the transaction data is made more efficient during such storage or transfer.
It should be appreciated that each of the components/entities illustrated in the system 100 of
For illustration, the system 100 is described below with reference to an exemplary computing device 200, as illustrated in
As shown in
In the exemplary embodiment, computing device 200 also includes a display device 206 that is coupled to the processor 202. Display device 206 outputs to a user 212 by, for example, displaying and/or otherwise outputting information related to the performance of system 100 and/or method 300. Display device 206 may include, without limitation, a cathode ray tube (CRT), a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, and/or an “electronic ink” display. In some embodiments, display device 206 includes multiple devices. It should be further appreciated that various interfaces (e.g., graphical user interfaces (GUI), webpages, etc.) may be displayed at computing device 200. The computing device 200 also includes an input device 208 that receives input from the user 212. The input device 208 is coupled to the processor 202 and may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), card reader, swipe reader, touchscreen, and/or an audio input device.
The computing device 200 further includes a network interface 210 coupled to the processor 202, which permits communication with one or more networks. The network interface 210 may include, without limitation, a wired network adapter, a wireless network adapter, a mobile telecommunications adapter, or other device capable of communicating to one or more different networks.
The computing device 200, as used herein, performs one or more functions, which may be described in computer executable instructions stored on memory 204 (e.g., a computer readable storage media, etc.), and executable by one or more processors 202. The computer readable storage media is a non-transitory computer readable media. By way of example, and without limitation, such computer readable storage media can include RAM, Read-only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media.
Referring again to
Next, the conformance engine 108 identifies each data definition (likely multiple such definitions) defined in the application and compares it to various standard data definitions accessible in library database 120. In various embodiments, the library database 120 is generated by one or more entities associated with the data to be compiled from the applications. In
Also as part of operating on the application, the conformance engine 108 (or a user thereof) identifies a last date of invocation for the conformance engine 108 (if any) of the application so that only newly created data definitions in the application are evaluated. The conformance engine 108 may further identify standard data definitions (e.g., a subset based on the type of application, etc.). For example, when an application is related to clearing and settling transactions, standard data definitions may be different than standard data definition employed when the application is a consumer-based application. However, some standard data definitions (e.g., standard abbreviations, etc.) may be uniform regardless of the type of application to be evaluated.
The conformance engine 108 then compares the data definitions from the target application, to the standard data definitions. And, the conformance engine 108 generates a report for the application based on the comparison. This will be described in more detail hereinafter in connection with method 300.
As shown in
Separately, the conformance engine 108 identifies a target application (e.g., a pre-production application, etc.) at 302, from the development environment 106, to be evaluated. This may include receiving a request, from the development environment 106 (e.g., via a user developing an application in the development environment 106, etc.), to evaluate an application. Or, the conformance engine 108 may monitor the development environment 106, and evaluate some or all pre-production applications associated therewith (e.g., continuously, at predefined intervals, or according to one or more schedules, etc.).
In connection with identifying the target application from the development environment 106, the conformance engine 108 also determines what (if any) data definitions from the identified application are to be evaluated for conformity against the standard data definitions. This may be based on a last date of invocation for the conformance engine 108 for the application (e.g., as specified by the user developing the application, as calculated by the conformance engine 108 from logs, etc.), so that only new or revised data definitions in the application are evaluated. In one or more embodiments, the conformance engine 108 identifies all data definitions, included in the application, for example, to ensure or test whether prior violations of the standard data definitions have been resolved.
Next in the method 300, as shown in
Upon completion of the comparison at 306, the conformance engine 108 generates a report, at 308. The report identifies (e.g., flags, etc.) discrepancies between the data definitions in the identified application and the standard data definitions from the database 120. The report is delivered, by the conformance engine 108, to one or more users associated with the application (e.g., a developer assigned to the application, etc.).
As an example, when a data definition of the identified application includes a table and the table name has abbreviations that deviate from the corresponding data definitions, the conformance engine 108 identifies, in the report, each of the errant abbreviations. As another example, when a data definition of the identified application includes a table having multiple columns with various abbreviations included in each of the columns and when several of the abbreviations deviate from deviations of corresponding data definitions, the conformance engine 108 identifies, in the report, each of the errant abbreviations.
With further reference to
As 310, the conformance engine 108 determines if the each of the different tables from the target application includes a primary key. In so doing, the conformance engine 108 identifies if a primary key is assigned to the table based on whether or not the table includes a constraint name having a “PK” suffix. If a primary key is not present in the table, the conformance engine 108 identifies the violation and generates a flag (which is included in the report generated at 308). In Table 1, an example report section identifies that one table, i.e., TEMP_TRGT table from the target application, does not include a primary key.
The conformance engine 108 further compares names of each of the tables from the target application to standard abbreviations included in the library of standard data definitions (in database 120, for example), at 312. When the table names include parts which are inconsistent with the standard abbreviations, the conformance engine 108 identifies a violation, and indicates it by a flag in the generated report (at 308). Table 2 illustrates an example report section related to the comparison of the table names to the standard abbreviations. As shown in the table, the report indicates (or flags) that the terms, for example, TEMPLATE and DISPLAY (among others) are not standard abbreviations in the library, while the term ASSOC is a standard abbreviation in the library. Also in the table, in this example, the terms TYPE and USER are not identified (or flagged) as errant abbreviations, as these words are considered standard abbreviations in the library (i.e., the terms TYPE and USER are the standard abbreviations for TYPE and USER).
The conformance engine 108 also compares the column names of each of the tables from the target application to standard names and/or abbreviations included in the library of standard data definitions (in database 120, for example), at 314. The standard abbreviations may be the same, or different from, the standard abbreviations employed at 312. In this comparison, when the column names violate the standard names and/or abbreviations, the conformance engine 108 again generates a flag indicating the violation, and includes the flag in the report, as generated as 308. Table 3 illustrates an example report section having a number of exemplary flags for column name violations.
After evaluating the column names, the conformance engine 108, in this example, compares class names of the columns of the tables from the target application to a listing of standard class names, at 316. As above, when the table includes a class name, which is not a standard class name, the conformance engine 108 generates a report, at 308, that includes a flag indicative of the violation. Table 4 illustrates an example report section, wherein the conformance engine 108 identified the use of the non-standard “DESCR” class name (among others), for example, as a violation.
With continued reference to
At 320, the conformance engine 108 also optionally checks names of foreign keys of the tables from the target application, at 318, to confirm their conformance to a foreign key naming convention. In particular, the conformance engine 108 determines, for each table, if the foreign key includes the table name with the suffix “FK.” When the foreign key is improper (e.g., does not include the suffix “FK”, etc.), the conformance engine 108 generates a flag indicating the violation, and includes the flag in the report generated at 308. Table 6 illustrates an example report section, where the conformance engine 108 determines that the foreign key for the table “SETTING” (among others), for example, is improper in view of the foreign key naming convention.
Likewise, at 322, the conformance engine 108 may further check names of alternate keys and/or unique keys of the tables from the target application, to confirm their conformance to a corresponding key naming convention (e.g., an alternate key naming convention identified by the suffix “AK”, etc.). As with the primary and foreign keys, the report generated by the conformance engine 108, at 308, includes flags for any violation of the particular key naming convention.
With still further reference to
In addition to the naming parameters of the tables (broadly, the data definitions) from the target application, as described above, the conformance engine 108 also checks (or determines), in some aspects of the method 300, if appropriate constraints exist in the tables (e.g., whether or not particular columns or cells of the table are properly constrained when a switch is indicated, etc.). Here, the conformance engine 108 does not, so much, review content of the tables, but instead reviews restrictions (or constraints) on the tables, for example, on columns of the tables defined as switches. When the conformance engine 108 identifies that a constraint, for example, for a column of a table with restricted “Y” or “N” values, is missing, the conformance engine 108 flags the table/column as a violation (because, when a development team imposes the constraint on the switch column, if the data contains other values outside of the “Y” or “N” values, the constraint cannot be defined). In the example report section of Table 8, the conformance engine 108 identified an errant constraint associated with a column.
Still further, in some aspects of the method 300, the conformance engine 108 compares various additional parameters of the tables from the target application. For example, as illustrated in the example report section of Table 9, the conformance engine 108 may check columns of the tables in a primary key with a number datatype, but without a sequence number or with a different naming convention. Violations are then identified by the conformance engine 108 in the report section (see Table 9), when generating the report at 308.
It should be appreciated that a variety of different comparisons may be made, by the conformance engine 108, in other embodiments, to ensure that data definitions from applications are consistent with one or more standard data definitions. Different parameters of the data definitions may be compared to different standard data definition criteria, for example, in different orders. For example, certain parameters of data definitions may be compared, during evaluations by the conformance engine 108 at one time, with the same or different parameters of the data definitions being evaluated at a different time. In addition, it should be appreciated that, in multiple embodiments, the type and extent of the parameters of the data definitions evaluated may be based on the type of applications, the type of data generated by the applications, and/or the expected use of the data from the applications. For example, when data from an application drives financial transaction, such as in
Further, as indicated above, the conformance engine 108 may limit the data definitions evaluated based on a temporal constraint imposed by the user (e.g., the developer associated with the application, etc.), or automatically. For example, a temporal constraint may limit the evaluation to just data definitions, which were created or revised, since a last invocation of the conformance engine 108. When the application is evaluated for revisions after a particular date, for example, the generated report may include an entry, which reflects the data from which the revisions are included the test, such as shown in Table 10.
In this manner, the data definitions in one or more applications are evaluated during the pre-production, i.e., the development stage, of the applications. In so doing, violations of standard data definitions are identified and reported to one or more users (e.g., developers of the applications, etc.), whereby the users may readily change the non-standard data definitions, as desired, to conform to one or more standard data definitions. When the applications, after being subjected to the systems and methods herein, are delivered, i.e., post-production, it is substantially likely that the data definitions associated therewith will conform with standard data definitions.
In some exemplary embodiments, a software development system is provided (e.g., via one or more computing device, etc.) configured to support one or more of the operation described in connection with method 300. For example, in one exemplary embodiment, such a system is configured to (e.g., via one or more processors, etc.), among other operations, identify at least one data definition defined in a pre-production application, compare the at least one data definition to standard data definition criteria, and generate a report for the pre-production application based on the comparison where the report includes at least one flag when at least one discrepancy exists between the data definition in the pre-production application and the standard data definition criteria.
It should be appreciated that one or more aspects of the present disclosure transform a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods, and/or processes described herein.
As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one or more of the following operations alone, or in combination in any desired order: (a) identifying an application to be tested where the application includes a pre-production code-segment and at least one data definition; (b) comparing the at least one data definition of the application to standard data definitions in a library of standard data definitions; (c) generating a report where the report includes a flag when at least one discrepancy is identified by the computing device between the at least one data definition in the application and the standard data definitions; (d) selecting a subset of multiple data definitions based on a temporal criteria; and (e) confirming a restriction of a data type.
Example embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art. Numerous specific details are set forth such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail. In addition, advantages and improvements that may be achieved with one or more exemplary embodiments disclosed herein may provide all or none of the above mentioned advantages and improvements, and still fall within the scope of the present disclosure.
The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “including,” and “having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.
The foregoing description of the embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.
