WO2022164645A1 - Génération de code automatisée pour logiciel informatique - Google Patents

Génération de code automatisée pour logiciel informatique Download PDF

Info

Publication number
WO2022164645A1
WO2022164645A1 PCT/US2022/012387 US2022012387W WO2022164645A1 WO 2022164645 A1 WO2022164645 A1 WO 2022164645A1 US 2022012387 W US2022012387 W US 2022012387W WO 2022164645 A1 WO2022164645 A1 WO 2022164645A1
Authority
WO
WIPO (PCT)
Prior art keywords
rule
query
script
rules
data
Prior art date
Application number
PCT/US2022/012387
Other languages
English (en)
Inventor
Kiran Kumar Govindaraju BANGALORE
Ashis Kumar Roy
Original Assignee
Microsoft Technology Licensing, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/317,550 external-priority patent/US20220245153A1/en
Application filed by Microsoft Technology Licensing, Llc filed Critical Microsoft Technology Licensing, Llc
Publication of WO2022164645A1 publication Critical patent/WO2022164645A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2423—Interactive query statement specification based on a database schema
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2428—Query predicate definition using graphical user interfaces, including menus and forms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques

Definitions

  • Figure 1 shows a block diagram of an automatic rule generation and evaluation system implemented in accordance with the examples disclosed herein.
  • Figure 2 shows a block diagram of a graphical model generator in accordance with examples detailed herein.
  • Figure 3 shows a block diagram of a query generator in accordance with the examples detailed herein.
  • Figure 4 shows a flowchart that details a method of rule generation and evaluation in accordance with the examples disclosed herein.
  • Figure 5 shows a flowchart that details a method of generating a query from a graphical model in accordance with some examples.
  • Figure 6 shows a flowchart that details a method for topological sorting of vertices based on Kahn’s procedure in accordance with some examples disclosed herein.
  • Figure 7 shows some example database tables used for rule generation in a partner competency program in accordance with the examples disclosed herein.
  • FIG. 8A shows some example queries and corresponding Directed Acyclic Graphs (DAGs) in accordance with the examples disclosed herein.
  • DAGs Directed Acyclic Graphs
  • Figure 8B shows an overall DAG that represents the JavaScript Object Notation (JSON) scripts generated per user input and an example ordering of nodes in accordance with the examples disclosed herein.
  • JSON JavaScript Object Notation
  • Figure 9 shows a spanning tree generated using the overall DAG in accordance with the examples disclosed herein.
  • Figures 10A-B show examples JSON scripts for generating a data source query and a rule query.
  • Figures 11A-B show examples of a data source script and a data source query generated from the data source script.
  • Figure 12 shows machine-readable instructions for scalable rule evaluation in accordance with the examples disclosed herein.
  • Figure 13 shows a flowchart that details a method of scalable rule evaluation in accordance with the examples disclosed herein.
  • Figure 14 shows a further example block diagram for scalable rule evaluation, according to examples.
  • Figure 15 shows a program User Interface (UI) that displays a list of existing programs in accordance with the examples disclosed herein.
  • UI User Interface
  • Figure 16 shows a program configuration UI provided in accordance with the examples disclosed herein.
  • Figure 17 shows a results UI provided in accordance with the examples disclosed herein.
  • Figure 18 shows a rules evaluation UI provided in accordance with an embodiment of the present disclosure.
  • Examples are discussed herein for an automatic rule generation and evaluation system that can automatically generate code for rules that may be specified from received user input, such as user input entered in a UI.
  • Scripts are generated based on the user input, and one or more of the scripts are used to generate a graphical model, such as a DAG, which specifies relationships between multiple data sources. Queries are automatically generated from the graphical model, which when executed against any compatible datastore, produces result sets for the rules.
  • the scripts that are generated based on user input may be JSON scripts, and the queries that are generated may be Structured Query Language (SQL) queries for a SQL compatible data store.
  • SQL Structured Query Language
  • scripts and queries may also be generated.
  • XML Extensible Markup Language
  • YAML a recursive acronym for "YAML Ain't Markup Language”
  • another type of script may be generated that can be parsed and used as input to create the graphical models.
  • a script is computer readable and can be parsed by a computer to execute an instruction specified by the script.
  • the script may also be human readable, such as including text that can be read and understood by a human.
  • query types other than SQL may be generated that are supported by the data store. For example, for a AzureTM datalike, the system may output a query in the KustoTM query language. The system can generate queries in a query language applicable to the chosen data store.
  • a company with multiple business groups allows the business groups to identify and evaluate potential, external partner companies that can provide particular services for particular business groups.
  • Each business group can sponsor an individual, partner, membership program to seek partners that can provide the desired services for the business group based on a particular expertise.
  • Potential partner companies for a business group can apply to become part of the partner membership program for the business group, and then the potential partner companies are evaluated as to whether they can be admitted to the partner membership program for the business group based on requirements created by the business group.
  • partner evaluation software to automate the evaluation of the potential partner companies based on the requirements.
  • the creation of a new partner membership program or modification to an existing partner membership program requires an in-depth analysis of the new requirements (criteria that the partners need to fulfill to attain a competency and membership) and the benefits (the cost of the items provided as part of the program).
  • the engineering team has to determine how to implement the new requirements, which may include analyzing various data sources and dashboards to determine the changes that need to be made in the code. For example, from a code standpoint, every time a new requirement for a partner membership program is to be implemented in the partner evaluation software, the required code changes may necessitate about 3-4 weeks of engineering/ coding work.
  • finalizing the new requirement may require 2-3 man-months of work, because the new requirement needs to be tested, and if the results are unsatisfactory, then the new requirement needs to be further modified until the results are found to be satisfactory.
  • the automatic rule evaluation and generation system enables automatic code generation, including generating and executing queries.
  • the automatic rule evaluation and generation system receives a new requirement, including rules for the new requirement, via a UI from a user of the business group, and also receives a selection of data sources for applying the rule.
  • the system generates a script from the user input, and generates queries on the fly based on the rules and the script, and executes the queries to generate a result set of data from data sources that are relevant to the rules.
  • the result set for example, includes potential partners that are determined to qualify for the partner membership program based on the new requirement.
  • the system provides for a low coding/no coding solution for code generation that can be utilized by a nonprogrammer, such as a user of the business group that needs to implement new requirements in the partner evaluation software for the partner membership program.
  • a nonprogrammer such as a user of the business group that needs to implement new requirements in the partner evaluation software for the partner membership program.
  • the automated code changes allow the business user to test new requirements on-the-fly to determine whether a new requirement impacts the number of potential partners affected by the new requirement.
  • the automatic rule generation and evaluation system allow nonprogrammer users to perform what-if analysis according to new requirements.
  • the automatic rule generation and evaluation system allows the business user to: design a program and analyze the impact on entities affected by the program such as the number of partners who would qualify for a particular competency or advanced specialization and the associated cost; establish workflow towards approval from relevant approvers across the business group; and take the program to production with little or no engineering involvement. Accordingly, the automatic rule generation and evaluation system is significantly faster in execution and improves efficiency in the process to create or update rules coded in software with minimal or no involvement from the engineering team.
  • FIG. 1 shows a block diagram of an automatic rule generation and evaluation system 100 implemented in accordance with the examples disclosed herein.
  • the automatic rule generation and evaluation system 100 is discussed below with reference to the example use-case regarding the partner evaluation software for the partner membership program for illustration purposes only, and can be used for automatic rule generation and implementation in other use cases.
  • the overall architecture of the automatic rule generation and evaluation system 100 includes data preparation, rule generation, and user interaction.
  • the data preparation and processing include preparing raw data (e.g., cleaning, filling in missing values, processing outliers, deduplication, etc.,) and injecting the processed data into a central database 150.
  • a user 190 can effect changes by creating new rules or editing existing rules via the automatic rule generation and evaluation system 100.
  • the automatic rule generation and evaluation system 100 includes a rules workbench UI 110, a script generator 102, a graphical model generator 104, and a query processor 106.
  • the automatic rule generation and evaluation system 100 can also be coupled to a local data store 170 for storing and accessing data used in the rule generation and evaluation processes.
  • the user 190 can create and enter user input 192 with the requirements via the rules workbench UI 110.
  • the relevant partner data is gathered from the various external partner data sources, e.g., one or more of the plurality of data sources 120, based on the user requirements, and stored in the central database 150.
  • the plurality of data sources 120 and the central database 150 can be configured to store structured data.
  • the plurality of data sources 120 and the central database 150 can include relational database management systems (RDBMS) wherein the data can be retrieved and manipulated using a query language specific to the RDBMS, such as SQL.
  • RDBMS relational database management systems
  • the rules workbench UI 110 can display data (e.g., qualifying partners) from one or more of the plurality of data sources 120, the central database 150, and the distributed data cache 152 based on the user requirements.
  • the rules workbench UI 110 enables rule generation so that users responsible for building new programs can iteratively build the rules for designing anew competency or advanced specialization program, measure the impact of the rules and the thresholds chosen on a real-time basis, and publish the rules once completed.
  • the user 190 may enter partner membership program attributes via input/output (I/O) screens of the rules workbench UI 110.
  • Examples of the partner membership program attributes entered by the user 190 may include one or more of program name, program description, requirements for partners to qualify for the partner membership program, and relevant data sources (e.g., the plurality of data sources 120) for applying rules determined from the requirements.
  • the user 190 can also add new entities and new requirements for a given competency through the rules workbench UI 110. Adding requirements enables the user to alter rules and one or more underlying data sources of the plurality of data sources 120.
  • the script generator 102 When the user accesses one or more I/O screens of the rules workbench UI 110 to enter requirements and identify data sources as part of the user input 192, the script generator 102 generates a script 122 corresponding to user input 192.
  • the user input 192 may be entered according to user experience (UX) flows of the rules workbench UI 110.
  • the script 122 can be generated based on templates that are populated with data from the user input 192. For example, as the user 190 enters rule-based information and data source information via different I/O screens of the rules workbench UI 110, then script 122 is produced based on populating the entered information into code templates. The populated code templates form the script 122.
  • the script 122 may include a rule script comprised of rules determined from the user-entered requirements and a data source script comprised of information for data sources of the plurality of data sources 120 that are selected in the user input 192.
  • the rule script and the data source script can be provided as a single script or as separate scripts.
  • the data source script can have an id, an array of data sources selected from the plurality of data sources 120, the central database 150, or the database cache 152, the particular data fields selected for data retrieval or data manipulation, an array of relations, also referred to as relationships, between the selected data sources, and join and/or union criteria for aggregating the selected data sources.
  • a relation exists between two tables when one of them has a foreign key that references the primary key of the other table.
  • the data source script of the script 122 produced by the script generator 102 is accessed by the graphical model generator 104 to generate a graphical model 142 of the script 122.
  • the graphical model can include structures with nodes/vertices and edges/arcs, such as a DAG. Each edge of the DAG is directed from one vertex to another, such that the edges do not form a closed loop.
  • a directed graph is a DAG if and only if it can be topologically ordered, by arranging the vertices as a linear ordering that is consistent with all edge directions.
  • Each node in the graphical model 142 can correspond to a data source such as a database table, a view or other data structure derived from another data source, etc.
  • Edges between the vertices can represent one or more of relationships, unions and joins between the data sources.
  • the graphical model 142 is provided to the query processor 106 which includes a query generator 166 and a query tester 168.
  • the query generator 166 automatically generates one or more queries 162 corresponding to the graphical model 142 and the script 122.
  • the one or more queries 162 can include a rule query and a data source query.
  • the rule query and the data source query can be comprised of a single query or multiple queries.
  • the rule query includes rules identified from parsing the rule script of the script 122 to identify requirements, such as conditions, that are populated into the rule query.
  • the data source query is generated from the graphical model 142 as is further discussed below.
  • the query tester 168 is configured for executing the queries 162.
  • the data source query is executed to generate a dataset by aggregating the data sources identified from the data source script, and the rule query is executed on the dataset to produce a result set 164 which displays results obtained from retrieving the data and applying the rules to the retrieved data.
  • the result set can be displayed via one or more of the I/O screens of the rules workbench UI 110. If the user is satisfied with the results, the user may finalize and publish the rules from the rule query, so the rules are used going forward to determine qualified partners. If the user is not satisfied with the rules, the user can provide further rule changes to produce different results.
  • the user 190 may change the rules to loosen the criteria so that more partners meet the criteria and may be inducted into the partner membership program. Therefore, the user can test the rules on the actual data sources before finalizing and publishing the rules to the partner membership program.
  • Some example requirements for which rules can be generated by the user 190 by employing the automatic rule generation and evaluation system 100 include a competency requirement such as a requirement that a partner should be ‘Gold’ in Cloud Platform competency, a certification requirement which may require that at least five individuals associated with a given partner should have certifications for a security engineer, a solution architect, , etc.
  • a performance requirement that the partner must have may include at least $X per month of customer revenue from Windows Virtual Desktop (WVD) Native workloads aggregated from at least one or more customers.
  • WVD Windows Virtual Desktop
  • the requirements may further include a notification requirement so that partners who have not been notified during the last 30 days are evaluated.
  • the central database 150 there can be six different data source categories within the central database 150, which can include: a competency category, a certification category, an assessment category, a revenue category, a partner notification category, and a partner overrides category.
  • the aforementioned data can be imported into the central database 150 periodically. These sets of data can have the added advantage of providing the same aggregates at various points along the competency evaluation process where they are referenced. Rules pertaining to the above conditions are generated and when published, become part of the partner evaluation software for partner evaluation, and the results of the evaluation can be provided to the partners through a partner user interface on a computing device.
  • the rules workbench UI 110 communicates with the central database 150 to generate the queries 162 that along with other metadata about the program like name, area, activation data, etc., goes into the cache 152.
  • the automatic rule generation and evaluation system 100 allows the user 190 to save the current rules as a draft or publish the rule to production. Runtime evaluation of the rules can happen from data stored in the cache 152 providing a boost in performance. The configuration, generation, and execution of the queries 162 can occur either in the central database 150 or on the cache 152. The user 190 can execute multiple iterations of the rules and as the user 190 changes a requirement, the rules workbench UI 110 can show the user 190 the effect of the change in real-time, e.g., within minutes. The impact of the change could be the total number of partners that qualified given the ruleset and more details around which rules contributed to the total number of failures.
  • This real-time feedback mechanism greatly helps the user 190 to tweak the rules and the associated threshold values and be more confident about the impact before publishing the rules to be deployed to production.
  • the user 190 gets one consolidated result including an impact of the requirements i.e., the result set 164.
  • This allows the user 190 to make as many rule changes as needed until a result set pertaining to the rules that satisfies the user 190 is generated thereby allowing the user to make data-driven decisions on what the requirements should be.
  • the rule(s) pertaining to Gold/Silver partner qualification can be changed to adjust the number of partners that will qualify for the Gold/Silver program when the ruleset goes into production.
  • the queries 162 are employed by an automated ruleimplementation process (e.g., a scheduled chron job) to execute an evaluation process on a predefined schedule for all the partner membership programs.
  • the detailed results generated from applying the rules to the data from the plurality of data sources 120 can be stored in the central database 150 so that an I/O screen of the rules workbench UI 110 can present the result sets to users.
  • the automatic rule generation and evaluation system 100 can be coupled to or include an approval processing system for obtaining approval for the new rules and/or the new program before implementation.
  • the ruleset can be stored and run periodically (e.g., nightly) against the partner data to pre-enable partners as their data is accessed by a partner program management system which may include the automatic rule generation and evaluation system 100 as a component.
  • a partner program management system which may include the automatic rule generation and evaluation system 100 as a component.
  • FIG. 2 shows a block diagram of the graphical model generator 104 in accordance with examples detailed herein.
  • the graphical model generator 104 includes a script processor 202, a node identifier 204, and an edge identifier 206.
  • the script processor 202 accesses the script 122 and processes the script 122 via parsing, tokenizing, and keyword and symbol identification.
  • the script 122 e.g., data source script
  • the script 122 is processed to identify data sources and to determine how to combine relevant data from the data sources, such as through unions and joins of tables, to generate a dataset for applying the rules also specified in the script 122 (e.g., the rule script).
  • FIG. 3 shows a block diagram of the query generator 166 in accordance with the examples detailed herein.
  • the query generator 166 includes a topological sorter 302, a spanning tree builder 304, and a query builder 306.
  • the spanning-tree builder 304 grows a spanning tree, by visiting each node or vertex in the graphical model 142, e.g., the DAG, while honoring the adjacency relationships between the vertices.
  • the graphical model 142 for example is built from the data source script of the script 122 and may be a DAG.
  • a linear ordering of the vertices is generated such that for every directed edge u-v from vertex u to vertex v, u comes before v in the ordering assuming that the DAG is represented as G(V, E) where Kis the collection of vertices in the graph and E is collection of all the directed edges.
  • the topological sorter 302 implements techniques such as Kahn’s algorithm for the topological sort.
  • the spanningtree builder 304 generates the spanning tree from the topologically sorted vertices. The spanning-tree generation process returns an edge whose tree endpoint was discovered earliest (or least recently).
  • BFS Breadth First Search
  • the query builder 306 processes the graphical model 142 sequentially from the bottom and generates the query statements for each vertex at each leaf layer to output one or more of the queries 162, such as the data source query.
  • FIG. 4 shows a flowchart 400 that details a method of rule generation and evaluation in accordance with the examples disclosed herein.
  • the method begins at 402 wherein a UI, e.g., a UI in the rules workbench UI 110, is displayed to the user 190 for receiving the user input 192 regarding new rules, which may include modifications to existing rules, and selection of data sources for applying the rules.
  • the rules workbench UI 110 can be connected to the plurality of data sources 120, thereby giving the user the ability to select the data sources (e.g., the databases, the tables, and/or the columns) for processing the rules.
  • the rules workbench UI 110 also includes mechanisms that enable the user 190 to define new entities such as new partner membership programs and attributes for the new entities.
  • the user input 192 regarding rules for adding a new entity or updating an existing entity is received via the rules workbench UI 110.
  • the user input 192 can be received by the user selections of one or more of the plurality of data sources 120 to be used for implementing the changes (e.g., adding new entities, or updating existing entities) and the rules about specific data elements such as attributes of the entities.
  • the script 122 corresponding to the user input 192 is generated.
  • the rules workbench UI 110 can be configured to automatically generate the script 122 (e.g., the rule script and data source script) corresponding to the user input 192.
  • the script 122 enables generating queries on the fly to implement the user changes.
  • the queries can include definitions for new data elements for one or more of the plurality of data sources 120 (e.g., Data Definition Language (DDL) queries).
  • the queries may also enable manipulating existing data elements (i. e. , Data Manipulation Language (DML)) such as making updates to rows and/or columns, linking data elements via joins, unions, relationships, etc.
  • DDL Data Definition Language
  • DML Data Manipulation Language
  • the graphical model 142 representing the script 122 is generated at 408.
  • the graphical model 142 can include nodes representative of one or more of the plurality of data sources 120 included in the script 122 based on the user input 192 and edges, representing relationships, joins, unions, etc., between the user-selected data sources.
  • the relationships are identified from the script 122 while the joins or unions may be identified from the metadata associated with the data sources accessed by the script 122.
  • the queries 162 are automatically built from the graphical model 142 and the script 122 at 410.
  • the data source query is generated from the graphical model 142 such as described with respect to figures 3 and 5- 6, and the rule query is generated from rules specified in the rule script of the script 122.
  • the DDL queries may be part of the data source query and can represent attributes related to a new program.
  • the DML queries can be part of the rule query and may include updates to rules to be implemented for an existing program such as changing thresholds, etc.
  • a data set is retrieved by executing the data source query, and at 414 the rule query is executed on the data set to retrieve the result set 164.
  • the result set 164 thus retrieved may be stored in the cache 152 and may be displayed at 416 in real-time. It may be noted that the on-the-fly generation of the script 122 and the graphical model 142 enables the automatic rule generation and evaluation system 100 to display the result set 164 in realtime.
  • the on-the-fly generation of the script 122, the graphical model 142, and the queries 162 speeds up the process of implementing new rules/rule updates by providing the results of the rule changes in real-time so that if the user is not satisfied with a new rule or rule update, then the user can change the rules until a satisfactory result is obtained. For example, if further user input is received for additional rule changes, then the steps detailed above are repeated to automatically generate a further script corresponding to the further user input, generate further graphical models representing the further script, and automatically build one or more further queries from the further graphical models so that the further queries include the rules generated per the further user input. A further output generated in response to the further changes to the rules is displayed.
  • the automatic rule generation and evaluation system 100 enables users to test the results of implementing new rules and/or rule changes prior to finalizing and uploading the rules/rule updates to the central database 150.
  • FIG. 5 shows a flowchart that details a method of generating the query 162, such as the data query, from the graphical model 142 in accordance with some examples.
  • the method begins at 502 wherein data from the script 122 for the creation of graphical model 142 is accessed.
  • the process is aborted and the method terminates on the end block. If no cycles are detected at 506, then the vertices are topologically sorted at 508 using, for example, Kahn’s algorithm. This enables identifying the starting vertex in the graph for sequential processing.
  • a layer of the graphical model 142 is selected.
  • the layer is not a leaf layer
  • all the nodes in the layer are topologically sorted at 516, the relations, joins, and/or unions are processed at 518, and the method moves to 520 to create the query statement for each of the nodes in the layer.
  • the method moves to 522 to select the next layer for query statement generation all the way to the root of the spanning tree.
  • FIG. 6 shows a flowchart 600 that details a method for the topological sorting of nodes in the spanning tree based on Kahn’s procedure in accordance with some examples disclosed herein.
  • the steps of the method 600 may be performed for step 506 discussed above.
  • the method 600 begins at 602 wherein the number of incoming edges (i.e., the indegree) is computed for each node.
  • the nodes with the number of incoming edges or the in-degree equal to zero are identified and added to a queue at 604.
  • a node is removed from the queue.
  • the count of the visited nodes is incremented by one at 608.
  • the in-degree is decreased by one at 610 for all the neighboring nodes of the node removed from the queue.
  • the neighboring nodes with in-degree zero are also added to the queue.
  • the count of visited nodes equals the number of nodes in the graph. If yes, the topologically sorted nodes are output at 620 and the method terminates on the end block. If it is determined at 618 that the count of visited nodes is not equal to the number of nodes in the graph, it is determined at 618 that the nodes cannot be topologically sorted and the method terminates on the end block.
  • Figure 7 shows some example database tables 700 and their columns.
  • One or more of the database tables 700 and columns of the database tables 700 may be selected as part of the user input 192 and used to generate the data source script, the graphical model 142 and the data source query.
  • the database tables 700 include data for which rules from the user input 192 can be applied for a partner membership program.
  • the database tables 700 includes a [pi], [Trainingcompletions] table 702, a [pi].[ModemAzureUsagWithvOrg] table 704, a [mpn], [PC Acitv eCompetencies] table 706, an [pi].[ASPNotification] table 708 and a [pi] . [PartnerOverride] table 710.
  • the rules workbench UI 110 is configured to generate the corresponding scripts to manipulate one or more of the plurality of data sources 120 to respond to the user requirements, e.g., rules.
  • the various data fields can be retrieved from the example tables 700 based on the requirements entered by the user in the rules workbench UI 110. New columns can be added or new rows may be appended to the tables in a database by generating the queries 162 on the fly from the script 122 generated in response to the user requirements and of course, subject to the approval of the appropriate responsible party.
  • FIG. 8A shows example queries and the corresponding graphical models generated from the user input in accordance with the examples disclosed herein.
  • the graphical models 804 and 824 illustrated are DAGs.
  • performance data for partners can be fetched from the [pi].[ModemAzureUsageWithvOrg] table 704 with an automatically- generated nested query 802. If individual query segments are treated as nodes in graph 804, then, the outer node 2 derives all its data and aggregations out of the projection list of node 1. Further, both competency and assessment data nodes are fairly straightforward with independent nodes 3 and 4 corresponding to the queries 806 and 808.
  • Certification data collection is more complex where node 5 representing query segment 810 is used by both node 7 and node 6 so that the outer query segments 812 and 814 derive their data and aggregations out of the query segment 810.
  • one or more of the data sources i.e. , data retrieval statements for the tables 702, 704, etc.
  • DAG directed acyclic graph
  • Edges between the vertices represent the relationships between the data sources.
  • the relationships across the levels are fully contained, however, implicit relationships within a level are derived out of their join or union metadata.
  • the goal of the rule evaluation process or the program management process is to traverse each node, respect the order of creation and build the final query to be executed against /the central database 150.
  • One or more of the example query statements shown in figure 8A that are generated from corresponding graphical models include rules (e.g., data filters) in the data source query.
  • query 806 includes data filters that require a competency in cloud platform and a competency level of gold.
  • Queries 808 and 810 includes data filters that require certain skills. It should be understood that additional rules may be provided in a rule query which is applied to data sets generated from executing the data source queries shown in figure 8A.
  • Figure 8B shows a DAG 850 generated from a data source script that is created from user input received via the rules workbench UI 110.
  • 860 shows a topological sorting of the nodes in accordance with the examples disclosed herein.
  • the input for generating the DAG 850 is a JSON script.
  • Each JSON script for generating a data source query may have an id, an array of data sources, an array of relationships between the vertices, and an array of join and/or union criteria between the vertices at the same level.
  • the DAG 850 not only includes the various nodes but also the relationships between the different nodes generated per one or more of the metadata included in tables 700 and the user input received via the rules workbench UI 110.
  • the arrows from nodes 2 to 3, 4, 7, 8, and 9 can represent table joins generated from table metadata and user input while the arrows from node 10 to each of the nodes 2, 3, 4, 7, 8, and 9 represent relationships that are automatically generated based on the user input and the script generated therefrom.
  • the nodes in the DAG 850 are sorted as shown in 860, and the nodes are traversed starting at the leaf nodes until the root node 10 is reached. SQL statements are generated from traversing the nodes, and once the root node 10 is reached, the final SQL query is completed. The rules qualifying a partner are applied to the data output generated by executing the final SQL query.
  • Figure 9 shows a spanning tree 900 generated in accordance with the examples disclosed herein.
  • the spanning tree 900 is grown for the DAG 850.
  • a spanning tree for a graph G(V, E) is a subgraph with (v-1) edges and visits every vertex in the graph.
  • the edges and vertices of T are called tree edges and tree vertices while the edges and vertices not in T are called non-tree edges and non-tree vertices.
  • a frontier edge for a given tree T is a non-tree edge with one endpoint in T called its tree endpoint and another endpoint not in T called its non-tree endpoint.
  • the tree edges of the tree T are shown in bold, the tree vertices are black and the non-tree vertices are white.
  • the frontier edges for T appearing in dashed lines are edges a, b, c and d.
  • the subgraph of G formed by adding edge c to tree T is a tree. It may be noted that as we add c to the tree, the set of eligible frontier edges need to be updated via a tree-growing process the steps of which are detailed below:
  • the spanning tree generation as detailed above returns an edge whose tree endpoint was discovered earliest (least recently).
  • the vertex discovery has to ‘fan out’ from the start vertex yielding the shortest path length from the start vertex to every other vertex in the graph to yield a tree similar to the DAG 850.
  • the nodes can be traversed bottoms-up while the nodes at the same level can be connected by creating a sub-graph for the nodes at the same level and then executing a topological sort to determine the order of evaluation.
  • FIG 10A shows an example snippet 1000 of a JSON script that is provided as input for the DAG processing.
  • the JSON script 1000 is a data source script used to generate a data source query.
  • the JSON script 1000 includes an id 1002, an array of data sources 1004, an array of relationships 1006 between the vertices, and an array of join criteria 1008 between the vertices at the same level.
  • the details of each of the data sources 1004, the relationships 1006, and the joins/unions 1008 are provided in the tabular forms herein.
  • FIG. 10B shows an example JSON snippet 1050 with rules.
  • the JSON script 1050 is a rule script used to generate a rule query.
  • the JSON script 1050 includes rules provided via the rules workbench UI 110.
  • An advantage of splitting up the data source query generation and the rule query generation and application process is to ensure higher performance when only the threshold values for rules are being changed by the user. Secondly, this separation ensures that applications can take advantage of either or both the steps.
  • Rule sets are inherently hierarchical. At the lowest level, there are individual rules. Referring to the partner membership program example, a partner needs to be evaluated on each of these rules.
  • the JSON script 1050 includes individual rules or conditions 1052 to be satisfied by each entity being validated/selected for a program, e.g., each partner being selected for a competency program.
  • the overall rule 1054 combines the individual rules in a generic expression tree to assess the entities as a result set, e.g., the partners’ qualification for the program.
  • the expressions for each rule can be any valid query statement comprising logical and arithmetic operators without writing any additional code. If the rule expression includes custom functions, then the custom functions can be implemented directly at the data store layer.
  • the automatic rule generation and evaluation system 100 when implemented in the realm of partner services, therefore, has the capability of providing rich metrics on the number of partners qualified under an individual rule both at an aggregate level and each partner level. This helps the partners to track how far they are from achieving the next milestone for their competencies or advanced specializations. Below are some example characteristics of conditions and rules that can be generated by the automatic rule generation and evaluation system 100.
  • Condition Encodes a specific expression and persists the results after evaluation.
  • Figures 11 A-B show further examples of a portion of a data source script 1100 and a portion of a data source query 1150 generated from the data source script 1100.
  • the data source script 1100 shown in figure 11 A is a JSON script generated based on user input. For example, the user selects data sources, such as tables and/or columns from tables, and information for the selected tables and columns is populated in section 1101. The information may include data source id, location, table name, row filters, etc. Based on the selected data sources, relations are determined and populated in section 1102. The relations may be predetermined for various tables.
  • the relations may be a one-to-one between tables that include selected columns, e.g., each record in table 8 relates to one, and only one, record in table 3.
  • the tables may be related through a primary key and a foreign key, and the tables may need to be aggregated to obtain the desired data.
  • Section 1103 shows examples of joins and unions.
  • An inner join returns records that have matching values in both tables.
  • a left outer j oin returns all records from the left table, and the matched records from the right table.
  • the union combines rows from selected tables.
  • the system determines whether to use joins or unions to combine data from tables based on the user input. For example, if the user input requires matching rows between two tables then an inner join is generated in the script.
  • a left outer join may be used to combine columns even if some of the data is missing from matching rows.
  • Figure 1 IB shows a portion of a data source query 1150 generated from the data source script 1100.
  • a DAG is represented by sections 1102 and 1103 of the data source script 1100.
  • the DAG is sorted and traversed as is discussed above. As each layer of the DAG is traversed, a corresponding SQL statement is generated, which concludes in generating the data source query 1150.
  • Figures 12-14 respectively illustrate, an example block diagram 1200, a flowchart of an example method 1300, and a further example block diagram 1400 for automatic rule generation and evaluation, according to examples.
  • the block diagram 1200, the method 1300, and the block diagram 1400 may be implemented in the automatic rule generation and evaluation system 100 described above with reference to Figure 1 by way of example and not of limitation.
  • the block diagram 1200, the method 1300, and the block diagram 1400 may be practiced in other apparatus.
  • Figure 12 shows the hardware for the scalable rule generation and evaluation system 100 that may execute the instructions of the block diagram 1200.
  • the hardware may include a processor 1202, and a memory 1204 storing machine-readable instructions that when executed by the processor 1202 cause the processor to perform the instructions of block diagram 1200.
  • the memory 1204 may represent a non-transitory computer-readable medium.
  • Figure 14 may represent a non- transitory computer-readable medium 1404 (or the data store 170) having stored thereon machine-readable instructions to provide for the rule generation and evaluation according to an example.
  • the machine-readable instructions when executed, cause a processor 1402 to perform the instructions of block diagram 1400 also shown in Figure 14.
  • the processor 1202 of Figure 12 and/or the processor 1402 of Figure 14 may include a single or multiple processors or other hardware processing circuit, to execute the methods, functions, and other processes described herein. These methods, functions, and other processes may be embodied as machine-readable instructions stored on a computer- readable medium, which may be non-transitory (e.g., the non-transitory computer-readable medium 1404 of Figure 14), such as hardware storage devices (e.g., RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), hard drives, and flash memory).
  • the memory 1204 may include a RAM, where the machine-readable instructions and data for a processor may reside during runtime.
  • the memory 1204 may include instructions 1206 that cause the processor 1202 to receive via the rules workbench UI 110, the user input 192 to implemented in software, whereby the user input specifies a rule and a plurality of data sources for applying the rule.
  • the rule may be pertaining to conditions for a partner membership program that is to be coded in the partner evaluation software and the plurality of data sources may be tables or columns of tables pertaining to the conditions and partner requirements.
  • the processor 1202 may fetch, decode, and execute the instructions 1208 to automatically generate the script 122 corresponding to the user input 192.
  • the script 122 may include a rule script and a data source script as is discussed above.
  • a script template may be populated with conditions of the rule received via the the rules workbench UI 110 to generate the rule script
  • the data source script may be populated based on selected data sources, metadata for the selected data sources, predetermined relations between the data sources, and user input that represents how the data sources are to be combined, such as through joins or unions.
  • the processor 1202 may fetch, decode, and execute the instructions 1210 to generate a model representing at least a portion of the script 122. For example, a DAG is generated from the data source script.
  • the processor 1202 may fetch, decode, and execute the instructions 1212 to automatically build a query, such as a data source query and a rule query.
  • the rule query may be populated with conditions and thresholds that are in the rule script.
  • the data source query is generated from the data source script as is discussed above.
  • Figure 13 may represent an example method for rule evaluation and the steps of the method.
  • the method includes receiving via the rules workbench UI 110, the user input 192 regarding a rule pertaining and a plurality of data sources 120.
  • the method includes automatically generating the script 122 corresponding to the user input 192, which may include a rule script and a data source script.
  • the method includes generating a model, such as graphical model 142, representing the script 122. For example, a DAG is represented in the data source script.
  • the method includes generating a data source query from the model.
  • the method includes executing the data source query to generate a data set.
  • the method includes generating a rule query from the rule script. Conditions from the rule script may be populated in the rule query.
  • the method includes executing the rule query on the data set generated at 1310.
  • the method includes outputting a result set comprised of results of executing the rule query on the data set.
  • the result set may be displayed on a UI of the rules workbench UI 110.
  • the non- transitory computer-readable medium 1404 may include instructions 1406 which the processor 1402 may fetch, decode, and execute to receive via the rules workbench UI 110, user input regarding an update to a rule and a plurality of data sources.
  • the update may be a changed condition for meeting a partner requirement in a partner membership program.
  • the processor 1402 may fetch, decode, and execute the instructions 1408 to automatically generate the script 122, such as a rule script and a data source script, corresponding to the user input 192.
  • the script 122 such as a rule script and a data source script
  • the processor 1402 may fetch, decode, and execute the instructions 1410 to generate a model, such as the graphical model 142, representing the script 122, such as the data source script.
  • the processor 1402 may fetch, decode, and execute the instructions 1412 to automatically build the queries 162 from the model and the script. For example, a data source query is built by sorting and traversing the model, and a rule query is built from the rule script.
  • the processor 1402 may fetch, decode, and execute the instructions 1414 to output the result set 164 obtained by executing the queries 162.
  • the data source query is executed to generate a data set by aggregating the plurality of data sources based on user input
  • the rule query is executed on the data set to generate the result set 164, which may be displayed on a UI of the rules workbench UI 110.
  • Figures 15-19 show the various I/O screens or UIs of the rules workbench UI 110 that are provided by the automatic rule generation and evaluation system 100 in accordance with the examples disclosed herein.
  • Figure 15 shows a program UI 1500 that displays a list of existing programs 1502 in addition to providing a new program UI element 1504 that enables the user to add new partner membership programs. Activation of the new program UI element 1504 or selection of one of the programs from the list of existing programs 1502 may trigger the automatic rule generation and evaluation system 100 to execute a process as detailed above in Figure 12.
  • FIG. 16 shows a program configuration screen 1600 provided in accordance with the examples disclosed herein.
  • the program configuration screen 1600 enables the user to enter requirements associated with a role/category 1602.
  • Various assessments can be selected via the drop-down box 1604 which can be populated with choices from one of the plurality of data sources 120.
  • the program configuration screen 1600 also permits the selection of a relation type 1606 via another drop-down box so that more than one assessment can associated with a given role. Therefore, multiple qualifications either singly or plurally can be associated with the given role.
  • an assessment can be selected from the drop-down box 1604 with a relation type 1606 ‘and’ along with the add button 1608 which can display another drop-down box populated with the choices from the drop-down box 1604 to permit plural selections.
  • Figure 17 shows a results UI 1700 that not only allows the user to configure requirements (i. e. , rules) for a program but also provides the results 1702 that are generated from the user input as detailed above. For example, the results 1702 show that 53,481 partners are qualified per the current eligibility criteria. If the user 190 is satisfied with this result, the user 190 may finalize the rules for use on the competency platform. However, if the user is not satisfied, the user can provide further input to generate another intermediate result set which may be finalized depending on the user’s satisfaction or which may be further altered via the generation of new rules to be applied to the data.
  • requirements i. e. , rules
  • Figure 18 shows a rules evaluation UI 1800 that not only allows the user to configure requirements such as a UI element 1802 for selecting existing data sources /adding data sources but also includes rule-modifying elements such as a threshold selector 1804, etc.
  • the rules evaluation UI 1800 not only provides the initial results 1702 but also provides the results 1806 generated by applying new rules on the data from the data sources selected using the UI element 1802.
  • a rule regarding a threshold to be applied can be automatically generated by selecting a threshold by moving the threshold selector 1804.
  • a SQL query corresponding to the threshold rule is automatically generated as detailed herein and applied to the data from the selected data source thereby producing the results 1806.
  • the rules evaluation UI 1800 displays result sets obtained by applying two different rules to the data from the selected data sources.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un système de génération et d'évaluation automatiques de règles permet à un utilisateur de générer des règles et d'évaluer les règles même au fur et à mesure que les règles sont générées. L'utilisateur utilise une interface utilisateur (IU) de banc d'essai de règles pour fournir une entrée concernant les règles à mettre en œuvre sur des données obtenues auprès d'une pluralité de sources de données. L'IU de banc d'essai de règles génère des scripts à partir de l'entrée utilisateur. Les scripts sont utilisés pour construire un modèle et générer des requêtes. L'affichage d'ensembles de résultats obtenus à partir de l'exécution des requêtes permet à l'utilisateur d'évaluer les règles en temps réel. Si l'utilisateur est satisfait, l'utilisateur peut finaliser les règles, sinon l'utilisateur peut encore modifier les règles, et les étapes de modification de règles et d'évaluation de règles peuvent être itérées jusqu'à ce que les règles soient finalisées.
PCT/US2022/012387 2021-01-29 2022-01-13 Génération de code automatisée pour logiciel informatique WO2022164645A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
IN202141003978 2021-01-29
IN202141003978 2021-01-29
US17/317,550 US20220245153A1 (en) 2021-01-29 2021-05-11 Automated code generation for computer software
US17/317,550 2021-05-11

Publications (1)

Publication Number Publication Date
WO2022164645A1 true WO2022164645A1 (fr) 2022-08-04

Family

ID=80447919

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/012387 WO2022164645A1 (fr) 2021-01-29 2022-01-13 Génération de code automatisée pour logiciel informatique

Country Status (1)

Country Link
WO (1) WO2022164645A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050120027A1 (en) * 2001-12-24 2005-06-02 Koninklijke Philips Electronics N.V. Method and device for presenting, managing and exploiting graphical queries in data management systems
US20140074888A1 (en) * 2012-09-10 2014-03-13 Jordan Potter Search around visual queries

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050120027A1 (en) * 2001-12-24 2005-06-02 Koninklijke Philips Electronics N.V. Method and device for presenting, managing and exploiting graphical queries in data management systems
US20140074888A1 (en) * 2012-09-10 2014-03-13 Jordan Potter Search around visual queries

Similar Documents

Publication Publication Date Title
US11100153B2 (en) Dynamic process model optimization in domains
CN110300963B (zh) 大规模数据储存库中的数据管理系统
CN110168515B (zh) 用于分析数据关系以支持查询执行的系统
Lu et al. On managing business processes variants
US8336024B2 (en) Extracting ontological information from software design data
US6954749B2 (en) Methods and apparatus for identifying related nodes in a directed graph having named arcs
US9519862B2 (en) Domains for knowledge-based data quality solution
US7840896B2 (en) Definition and instantiation of metric based business logic reports
US20050182739A1 (en) Implementing data quality using rule based and knowledge engineering
US8973012B2 (en) Composing analytic solutions
US20220245153A1 (en) Automated code generation for computer software
Tannock et al. Data-driven simulation of the supply-chain—Insights from the aerospace sector
Ferreira et al. Using logical decision trees to discover the cause of process delays from event logs
KR102213627B1 (ko) 분석 소프트웨어 관리 시스템 및 분석 소프트웨어 관리 방법
Marin-Castro et al. An end-to-end approach and tool for BPMN process discovery
US11694091B2 (en) Creation of scope definitions
US10901987B2 (en) Dynamic automatic generation of database views
Yavuz Iterated beam search for the combined car sequencing and level scheduling problem
Macioł An application of rule-based tool in attributive logic for business rules modeling
Dixit et al. Fast incremental conformance analysis for interactive process discovery
WO2022164645A1 (fr) Génération de code automatisée pour logiciel informatique
Ke et al. PBWA: A Provenance‐Based What‐If Analysis Approach for Data Mining Processes
US20130218893A1 (en) Executing in-database data mining processes
US10229379B2 (en) Checklist function integrated with process flow model
JP2010128870A (ja) データ処理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22703748

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22703748

Country of ref document: EP

Kind code of ref document: A1