Extended selective recommendation and deployment in low-code scenarios

By extending the recommendation system and machine learning model, the challenges of determining extension options and generating code in cloud-based applications have been solved, enabling efficient and accurate extension recommendations and development, while reducing the technical requirements and costs for developers.

CN115292473BActive Publication Date: 2026-06-19SAP SE

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
SAP SE
Filing Date
2021-10-15
Publication Date
2026-06-19

AI Technical Summary

Technical Problem

In cloud-based applications, users often struggle to effectively identify and extend database tables to meet specific needs, and a lack of knowledge about the underlying infrastructure leads to impractical or inaccurate determination of extension options and code generation.

Method used

By extending the recommendation system, scanning application data to identify potential extension points, using an extension generator to generate and validate field extensions, providing automated data input, and combining machine learning models to generate and validate extension code, accuracy and effectiveness are ensured.

Benefits of technology

It achieves seamless and efficient extended recommendations, reduces the knowledge requirements for extended development, improves the accuracy and applicability of extended features, and reduces subsequent lifecycle costs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115292473B_ABST
    Figure CN115292473B_ABST
Patent Text Reader

Abstract

The implementation includes: querying metadata of data objects to define a subset of data objects, each data object in the subset including a common text field and / or attachment field, and for each data object in the subset, processing historical data of the data objects to identify a set of data types, the historical data being stored in fields of a table in the database system; providing a recommendation for a first extension corresponding to a first data type; and receiving user input indicating acceptance of the recommendation for the first extension, and in response thereto, automatically providing executable extension code to add field extensions to the table and modify the user interface (UI) for input of values ​​corresponding to the first data type; and / or executing the extension code to deploy the extension and modify the UI.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to computer-implemented methods, systems, and non-transitory computer-readable storage media. Background Technology

[0002] Software systems can be provided by software vendors to enable businesses to operate. Software systems can include various applications that provide the functionality for performing business operations. Software vendors typically provide software systems as off-premise applications running in a cloud computing environment, which may be referred to as cloud-based applications (e.g., applications provided in the so-called "Software as a Service" (SaaS) paradigm). In some cases, software systems may include database systems or operate in association with database systems. Applications can be provided in an application layer that overlays on and enables interaction with the database system (e.g., reading, writing, and manipulating data). In general, database systems provide storage, organization, and analysis of large volumes of data.

[0003] In some cases, software vendors seek to provide software applications with certain levels of configuration, enabling users (e.g., enterprises) to customize the vendor-supplied software (e.g., adding custom code, modifying existing code, using application programming interfaces (APIs) that are not declared as "release stable") and / or data objects. For example, a software vendor might provide standard data objects in the deployed software system, which could populate data stored in one or more database tables within a database system with which the application interacts. In other cases, users seek to extend data objects, and thus extend the underlying database tables, to customize data objects to meet their specific needs. This could, for example, include adding and / or removing one or more fields from a table. Summary of the Invention

[0004] Implementations of this disclosure relate to an extension recommendation system for recommending extensions to an application. More specifically, implementations of this disclosure relate to an extension recommendation system that scans application data to identify potential extension points and selectively invokes a set of extension generators to enhance data objects with correctly typed field extensions. In some implementations, the extension recommendation system provides extension plugins for automated data input. In some implementations, the extension recommendation system enables the generated extensions to be implemented in a supervised mode to verify their usefulness until sufficient confidence has been established, and enables subsequent activation for automated full system execution.

[0005] In some implementations, the actions include: querying metadata of data objects in a set of data objects to determine the presence of one or more general text fields and attachment fields to define a subset of data objects, each data object in the subset including one or more of the general text fields and attachment fields; and for each data object in the subset, processing historical data of the data objects to identify a set of data types, the historical data being stored in fields of tables in the database system; providing a recommendation for a first extension corresponding to a first data type in the set of data types; and receiving user input indicating acceptance of the recommendation for the first extension, and in response, automatically providing extension code executable to add the field extension to the table and modify the input of the application for values ​​corresponding to the first data type; and executing the extension code to deploy the extension and modify the UI. Other implementations of these aspects include corresponding systems, devices, and computer programs configured to perform actions of methods coded on a computer storage device.

[0006] These and other implementations may each optionally include one or more of the following features: the action further includes: in response to receiving user input indicating acceptance of a recommendation for a first extension, determining a default value for selective presentation in the UI for a first data type; determining a default value including one or more of the following: providing a default value from historical data and extracting a default value from one or more additional files; determining the default value includes launching a machine learning ML platform to provide an ML model trained to generate the default value; the action further includes: determining the frequency of data values ​​in a field of a table corresponding to the first data type, wherein, in response to determining that the frequency at least meets a threshold frequency, the recommendation for a first extension corresponding to the first data type in the set of data types is performed; the action further includes: determining the frequency of data values ​​in historical data corresponding to a second data type, and in response to determining that the frequency fails to meet the threshold frequency, determining to abandon the recommendation for a second extension corresponding to the second data type; and the action further includes: determining the accuracy associated with the first extension based on one or more of the frequency of use of the first extension and acceptance of a default value for the first extension, and selectively prompting the user based on the accuracy to either update or remove the first extension.

[0007] This disclosure also provides a computer-readable storage medium coupled to one or more processors and having instructions stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform operations according to an implementation of the methods provided herein.

[0008] This disclosure further provides a system for implementing the methods provided herein. The system includes one or more processors and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform operations according to the implementation of the methods provided herein.

[0009] It will be understood that the methods according to this disclosure may include any combination of the aspects and features described herein. That is, the methods according to this disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of aspects and features provided.

[0010] Details of one or more implementations of this disclosure are set forth in the accompanying drawings and the following description. Other features and advantages of this disclosure will become apparent from the specification, the drawings, and the claims. Attached Figure Description

[0011] Figure 1 An example architecture is shown that can be used to implement the present disclosure.

[0012] Figure 2 An example conceptual architecture based on the implementation of this disclosure is shown.

[0013] Figure 3 Example processing that can be performed according to an implementation of this disclosure is shown.

[0014] Figure 4 This is a schematic diagram of an example computer system that can be used to implement the present disclosure.

[0015] The same reference numerals in each figure indicate the same element. Detailed Implementation

[0016] Implementations of this disclosure relate to an extension recommendation system for recommending extensions to an application. More specifically, implementations of this disclosure relate to an extension recommendation system that scans application data to identify potential extension points and selectively invokes a set of extension generators to extend augmented data objects with correctly categorized fields. In some implementations, the extension recommendation system provides extension plugins for automated data input. In some implementations, the extension recommendation system enables the generated extensions to be executed in supervised mode to verify their usefulness until sufficient confidence has been established, and enables subsequent activation for automated full system execution.

[0017] The implementation may include the following actions: querying metadata of data objects in a set of data objects to determine the existence of one or more of a common text field and an attachment field to define a subset of data objects, each data object in the subset including one or more of the common text field and attachment field; and for each data object in the subset, processing historical data of the data object to identify a set of data types, the historical data being stored in fields of a table in the database system; providing a recommendation for a first extension corresponding to a first data type in the set of data types; and receiving user input indicating acceptance of the recommendation for the first extension, and in response, automatically providing executable extension code to add field extensions to the table and modify the user interface (UI) of the application for inputs corresponding to the first data type; and executing the extension code to deploy the extension and modify the UI.

[0018] As used herein, the terms low-code and no-code generally refer to software development platforms and / or tools targeted at users with little or no development experience (e.g., referred to as casual developers, or low-code (no-code) developers). Another target of such platforms and / or tools may include more experienced developers with shorter development times (e.g., low-code (no-code) enables developers to develop faster). Here, low-code may refer to development requiring some level of coding experience, while no-code may refer to development without any programming experience. In the context of implementations of this disclosure, low-code (no-code) extension developers generally refer to developers of extensions for applications with limited development experience and / or limited time for development. While this disclosure refers to low-code developers and / or no-code developers, it is to be understood that implementations of this disclosure may be implemented for the benefit of more advanced developers and / or developers with more time to develop application extensions.

[0019] As used herein, the term "key user" generally refers to a user who is aware of the specific behavior within the application and / or the processes performed by the application. For example, a key user may have extensive knowledge of the processes (e.g., those performed entirely or partially by the software) and / or the impact of changes to those processes on the operations of the enterprise. Therefore, in the context of this disclosure, key users play a significant role in estimating and / or implementing extensions to the application. However, in some cases, key users may have little or no development experience and thus may be considered civilian developers or low-code (no-code) developers.

[0020] To provide further context for the implementation of this disclosure, and as described above, the software system may be provided by a software vendor to enable an enterprise to operate it. The software system may include various applications that provide functionality for the execution of enterprise operations. Software vendors typically provide the software system as an externally deployed application running in a cloud computing environment, which may be referred to as a cloud-based application (e.g., an application provided in the so-called "Software as a Service" (SaaS) paradigm). In some cases, the software system may include a database system or operate in association with a database system. Applications may be provided in an application layer that is overlaid on the database system and enables interaction with the database system (e.g., reading data, writing data, manipulating data). In general, database systems provide storage, organization, and analysis of large volumes of data.

[0021] In some cases, software vendors seek to provide software applications with certain levels of configuration, enabling users (e.g., enterprises) to customize the vendor-supplied software (e.g., adding custom code, modifying existing code, using application programming interfaces (APIs) that are not declared as "version stable"), and / or data objects. For example, a software vendor might provide standard data objects in the deployed software system that populate data in one or more database tables within the database system with which the application interacts. In other cases, customers seek to extend data objects, and thus extend the underlying database tables to specify data objects that meet their particular needs. This could include, for example, adding and / or removing one or more fields from a table.

[0022] In recent years, low-code / no-code and mission-critical scalability have become increasingly important for cloud-based applications (i.e., SaaS-delivered) because they allow non-developers to tailor applications more closely to their individual needs than configuration alone would make it possible. For example, mission-critical users may have little or no programming or development experience. In the context of this disclosure, low-code / no-code simplifies the process of creating extensions. Overall, mission-critical scalability and low-code / no-code leverage stable interfaces and extension points to reduce subsequent lifecycle costs during the deployment of code (e.g., new code, modified code).

[0023] When enterprises adopt cloud-based applications, they seek to identify extensions to the application to tailor it to their specific needs. Furthermore, for extensions, enterprises seek to determine whether an extension is useful to the entire set of users or only to a subset of users within the enterprise. Similarly, low-code / no-code tools are feature-rich offerings with numerous functionalities provided through services and libraries. This can require a learning curve, especially as offerings grow continuously. Therefore, civilian developers (e.g., low-code / no-code developers) must know which extensions can be built and implemented to fully leverage cloud-based applications. In some cases, civilian developers are not supported in identifying the need (or options) for extensions (e.g., determining whether an extension is beneficial to a single user or broadly helpful in terms of features), and / or identifying where and how to integrate existing services (e.g., machine learning) into the extension.

[0024] Given the above context, implementations of this disclosure provide an extension recommendation system that scans application data to identify potential extension points and selectively invokes a set of extension generators to extend augmented data objects with correctly categorized fields. In some implementations, the extension recommendation system provides extension plugins for automated data input. In some implementations, the extension recommendation system enables low-code extension developers to execute generated extensions in a user-supervised mode to verify their usefulness until sufficient confidence has been established, and to perform subsequent activations for automated full system execution.

[0025] As described in further detail here, the extension recommendation system analyzes usage and processing data of cloud-based applications to identify a set of extension options. This set of extension options is presented to users (e.g., civilian developers) for permission. In some examples, the extension recommendation system enables users to fine-tune extensions (e.g., change the user interface (UI) label of a field extension). Because the extension options are based on data analysis, the presented options can be accompanied by statistics on their potential usefulness based on historical data. In this way, the extension recommendation system of this disclosure provides users with information about extensions that would otherwise be unavailable. The collected statistics on usage and relevance guide users more towards managing and optimizing extensions rather than on requirements engineering. In some implementations, the extension recommendation system can proactively generate extension code that enables automated processing. For example, templates can be used to generate code, where a template is selected for a specific extension case and specific values ​​within the template. Templates can be provided for artifacts (e.g., views, UI definitions) of each specific type of programming model. In some examples, the generated extension programming is tested and validated in a controlled manner before being activated for general use (e.g., by a product used by multiple users).

[0026] Therefore, and as described in further detail herein, the implementations of this disclosure address the following example problems, as well as others not explicitly mentioned herein. In one example, a single user may want an extension, but first, the user will have to format the need for the extension, and then determine whether the extension is only useful to that single user or more broadly useful to other users. That is, an extension that is only beneficial to a single user may not be an extension that should be implemented. The implementations of this disclosure enable this estimation in a seamless and efficient manner. In another example, limited knowledge about the underlying infrastructure of a cloud-based application creates a barrier for users to determine which extensions are feasible. In some cases, the underlying infrastructure of a cloud-based application is more robust than the user may know or even expect (e.g., infrastructure employing intelligent machine learning (ML) performance). The implementations of this disclosure address this problem, enabling extension developers to fully utilize the available possibilities.

[0027] In another example, it may be impractical for the user (extension developer) to determine which types of extensions are possible. For example, the user might not know that extensions are possible for processing or the UI. The implementation disclosed herein addresses this problem by informing extension developers of the types of extensions available for an application. In yet another example, in instances where extensions are available, the user (e.g., a lay developer) might not be able to generate the code required to implement the extension. The implementation disclosed herein also addresses this problem by generating code based on information gathered using ML performance. This further reduces the knowledge required to build useful application extensions and works toward the ultimate goal of not exposing any (generated) code to lay developers, making it appear as if it were no-code experience.

[0028] The implementation references of this disclosure include, in further detail, non-limiting examples of extending database tables with field extensions. For example, data can be analyzed, and it can be determined that specific information about a customer (e.g., website address) is frequently entered in a free text field of a table. The type of information can be determined, and extension recommendations can be made to extend the table to include columns specific to that information. However, it is considered that the implementation of this disclosure can be implemented for any suitable type of extension.

[0029] Figure 1 An example architecture 100 according to an implementation of this disclosure is shown. In the illustrated example, example architecture 100 includes a client device 102, a network 106, and a server system 104. Server system 104 includes one or more server devices and a database 108 (e.g., processor, memory). In the illustrated example, a user 112 interacts with client device 102.

[0030] In some examples, client device 102 may communicate with server system 104 via network 106. In some examples, client device 102 includes any suitable type of computing device such as a desktop computer, laptop computer, handheld computer, tablet computer, personal digital assistant (PDA), cellular phone, network device, camera, smartphone, enhanced general packet radio service (EGPRS) mobile phone, media player, navigation device, email device, game console, or any two or more suitable combinations of these devices or other data processing devices. In some implementations, network 106 may include a large computer network connecting any number of communication devices, mobile computing devices, fixed computing devices, and server systems, such as a local area network (LAN), wide area network (WAN), Internet, cellular network, telephone network (e.g., PSTN), or suitable combinations thereof.

[0031] In some implementations, server system 104 includes at least one server and at least one data storage device. Figure 1 In the example, server system 104 is intended to represent various forms of servers, including but not limited to, web servers, application servers, proxy servers, network servers, and / or server pools. In general, the server system receives requests for application services and provides such services to any number of client devices (e.g., client device 102 on network 106). According to an implementation of this disclosure, and as described above, server system 104 can host an extended recommendation system. As described in further detail herein, the extended recommendation system scans application data to identify potential extension points and selectively invokes a set of extension generators to enhance data objects with correctly categorized field extensions.

[0032] Figure 2 An example conceptual architecture 200 according to an implementation of this disclosure is shown. In the example shown, the example conceptual architecture 200 includes a cloud-based system 202 and an extended recommendation system 204. Figure 2 In the example, the example conceptual architecture 200 also includes an ML platform 206.

[0033] Cloud-based system 202 includes application 210 that interacts with database 212. For example, application 210 executes on a server (e.g., an application server) and interacts with database 212. The application includes application modules 210a and 210b. Although... Figure 2 The example illustrates two application modules, and it is considered that an implementation of this disclosure can be implemented as an application with any suitable number of application modules. In some examples, each application module 210a, 210b provides the corresponding functionality of application 210. Figure 2In some examples, the extended recommender system 204 includes a collection of extended orchestrators 220, data storage 222, and extended generators 224a, 224b. In some examples, the extended recommender system 204 includes an extended recommender engine (ERE) 220'. Figure 2 In the example, ERE 220' is provided within the extended orchestrator 220.

[0034] According to an implementation of this disclosure, and as described in further detail herein, the 'ERE 220' identifier can be used for extensions of application 210 (e.g., any extension that can be used for application modules 210a, 210b). In some implementations, one or more estimation data in extension generators 224a, 224b are used to select an extension generation process (e.g., an algorithm) based on the estimation and generate extensions. In some examples, a set of extension options and related statistics (e.g., how frequently they are used) can be presented to the user, who can then determine whether to generate an extension. In some examples, an editor can be provided to enable users to create their own queries, which can be embedded in one or more extension generators 224a, 224b. In some implementations, extension orchestrator 220 orchestrates the deployment of generated extensions and collects statistics on the use of extensions within application 210. In some examples, extension orchestrator 220 presents extension statistics to the user, who can then decide whether to save or modify an extension. In some examples, extension orchestrator 220 collects statistics on the use of all generated extensions and estimates the accuracy of each. If the accuracy drops below a threshold, the extension orchestrator 220 can trigger the extension generator to create a new version of the extension. In some examples, the extension orchestrator can send statistics to the seller (i.e., the seller providing application 210). Developers of the code that executes as the extension generator can improve and / or add queries to the extension generator.

[0035] In further detail, ERE 220' is configured to execute queries to determine the working set for each of the extended generators 224a, 224b. That is, for example, ERE 220' queries data store 222 to determine the working set. In some examples, the working set includes a collection of data objects (DOs) (also known as business objects (BOs)) and a collection of extended generators. The combination of DOs and extended generators can be a relatively large working set, providing broad coverage of application 210 as a whole. In some examples, to optimize and minimize resource consumption, ERE 220', for example, identifies all instances across application 210 (i.e., instances of application 210 used by other enterprises), which / which DOs have the most instances, and / or which / which input UIs of each DO are most frequently invoked. In this way, DOs can be ranked (e.g., based on the number of instances and / or the frequency of input UI invocation), and the top X (e.g., the top 10) DOs can be initially addressed. In some examples, ERE 220' includes persistence that stores which extended generator has been called for which DO, so that the ERE will not be rerun unplanned (only when accuracy degrades, a new version is applied, or a user triggers a run). In some implementations, ERE 220' is configured with read-only access to the application database and metadata store.

[0036] In some implementations, each extension generator 224a, 224b can be an extension generator of its own type. Example types of extension generators may include, but are not limited to, field extension generators, default value suggestion generators for structured data sources, and default value suggestion generators for unstructured data sources. For field extension generators, DOs with common text fields are identified. This is done by reading the metadata of the DO, and, for example, when "comment" is included in the metadata description of a DO field, the DO is a candidate for further analysis, and therefore the identified DO with a text field is added to the working set. For example, Module = Field Extension Generator, DO = "Business Partner", Field = "Comment". As another example, Module = Field Extension Generator, DO = "Purchase Order", Field = "Note". For default value suggestion generators using attachments, which are described in further detail here, all DOs with attachments are candidates. The relevant field is the field that is rendered on the UI to create an instance of the relevant DO. For example, Module = Default Value Suggestion Generator with Attachments, DO = "Shipping Order", Field = <all input fields in the "Creating Shipping Order" UI> such as "Business Partner Name", "Address", etc.

[0037] Regarding field extensions, one or more field extensions are identified from historical Data Objects (DOs) (e.g., DOs used by various businesses). In some examples, each field extension is suggested to the user for acceptance or rejection. In some examples, the field extension suggestions may also indicate the suggested field type and input validation, and provide examples of historical data in the current field and associated statistics (e.g., how frequently the value occurs in the field). In some examples, the user may be asked for the name of the field extension (e.g., which can be used for UI text). In response to the user accepting the field extension, the field extension is added to the corresponding table in the database, and the UI that receives data values ​​via it is revised to include the corresponding input field and validation logic. In some examples, the application executes for some time and analysis of the field extensions is performed. For example, the analysis may be used to determine whether the field extension is being used by the user as expected. As another example, the analysis may be used to determine whether a previously used free text field no longer contains that type of data (e.g., a field extension was generated for an email address, but the user continues to put email addresses in the comment field, indicating that the user is not using the field extension). In some examples, the confidence level of the field extension is presented to the user. The user may be asked whether to migrate historical data from free text fields to field extensions. If the user consents, data from the free text field is copied or migrated to that field extension (for example, the email address in the comment field is copied / migrated to the field extension).

[0038] In more detail, the field expansion generator identifies opportunities for field expansion based on the analysis of the free text fields of a table. Example free text fields may include descriptions, comments, remarks, notes, etc. In some examples, the generated field expansion is a more specific field with a precise data type and a single usage pattern. This improves data quality and enables further expansion optimization processing by leveraging this additional metadata-enhanced object field. In some examples, ERE 220 reads the definition of each DO in the system and identifies those DOs that have one or more free text fields (e.g., a comment field). In some examples, this can be achieved by scanning for fields of a certain type (e.g., scanning DOs for fields defined by data elements whose names or short text names contain "comment"). This scan results in a list of DO types and corresponding free text fields that can be compared for matching. In some examples, the field expansion generator is invoked for each DO type for which the field expansion generator has not yet been invoked.

[0039] In more detail, the field extension generator is invoked with the DO name and the free text field name. The field extension generator reads the contents of the data store used for the field values ​​and applies one or more regular expressions (regex) to identify different value types. Example value types include, but are not limited to, email address, time, date, URL, mailing address, phone number, and VAT number. Examples of regular expressions are publicly available, and any suitable regular expression can be used in implementations of this disclosure. In some examples, regular expressions are used to parse field values ​​to determine whether the field content includes a certain / some value types that occur relatively frequently. For example, the frequency of a value type can be determined (e.g., the percentage of occurrence of a value type in the input of a free text field) and can be compared to a threshold frequency (e.g., at least 40% of fields include email addresses, at least 40% of fields include date-time). The field extension generator recommends creating specific types of field extensions (e.g., text fields, date-time fields) and may even recommend creating content validation parsers (with regular expressions already used to determine field types). Field and value types are suggested to civilian developers. If the extension developer accepts, the generator generates the field extension.

[0040] Regarding the default value suggestion generator used for structured data sources, here, data is passed from the UI and / or DOs and input fields are populated with default values. This avoids the inherent inefficiency and potential for errors associated with manual copy / paste. This can be implemented for fields defined by the seller, but also for field extensions implemented by various enterprises (i.e., other enterprises also using the cloud-based application). In some examples, any field extension is identified for a specific DO and / or for any DO associated with that specific DO (e.g., via foreign-key association). In some examples, for identified field extensions, default values ​​can be calculated from the historical data of the values. For example, and as described in further detail here, default values ​​can be calculated using an SQL query generator or by using ML.

[0041] In further detail, the default value suggestion generator for structured data sources reads prior DOs along the processing flow, or previous instances of DOs related to the same master DO. More specifically, the default value suggestion generator for structured data sources generates data filling rules that can be used to populate input fields with default values ​​proposed from the relevant DOs. In some examples, fields are filled with data from other DOs that may have been maintained by various users in other UIs. For example, and as described above, common object field data types are read directly from the relevant DOs, such as prior DOs along the processing flow. As another example, common object field data types are read from historical data of the same DO type. In some examples, ERE220' scans the UI definition of the input screen for fields, for example, with the code fetchDefaultValue (or a similar routine that defines a possible programming standard for the name of a programming language or development project). In some examples, ERE 220' determines the DO type (and field name) related to the UI input screen. In some examples, this results in a list of DO types and expected input fields that can be compared to fields of the relevant prior DOs for matching. In some examples, this results in a list of DO types and expected input fields, as well as DO instances that can be grouped together with the same master DO instance so that the grouped DO fields can be compared for a reference master DO for matching. In some examples, different default value suggestion generators are invoked, one for each DO type.

[0042] As mentioned above, the default value can be calculated by the SQL query builder. In some examples, a query template is provided for each DO and field. For example, the first query template (Q1) compares the data in the field to be populated (f1) with the data in the field to be used as the default input (f2), and the second query template (Q2) queries the contents of f2 when a certain key and set of attributes are given to prepopulate f1.

[0043] In a non-restricted example, consider two DOs related to three key fields k1, k2, k3 and expected fields f1, f2. The following example query returns a table with the key and expected fields, so they can be compared.

[0044]

[0045] Example Q1, which provides the number of equal and unequal values ​​that can serve as statistical indicators, can be:

[0046]

[0047]

[0048] Example Q2, which uses the choice f2 for a given key to pre-populate f1 (giving the most frequent value of f2), can be:

[0049]

[0050] More generally, the fields in a DO can be placeholders in a query template, and the actual set of fields in the DO generates the query template, which produces a set of query statements to analyze the content and then query the content. For example, an example Q1 that can be used as a statistical relevance indicator to count the number of equal and unequal values ​​can be provided as follows:

[0051]

[0052]

[0053] Example Q2, which uses f2 to pre-populate f1 for a given key (returns the most frequent value of f2 for a given key and WHERE clause), can be provided as follows:

[0054]

[0055] In some implementations, the first query template (Q1) for evaluating content is executed by the ERE, which generates statistical relevance indicators (e.g., the probability that two values ​​with the same key are equal). In some examples, for each field, the ERE executes a different query and selects the one with the highest relevance indicator. If the indicator is above a certain threshold (e.g., 90%), a second query template (Q2) for the input values ​​of the input field is selected and generated as a code module. The user is advised to activate this code module. If the user accepts, the code module is deployed by the ERE and configured for use by the UI to pre-populate the input values ​​of f1 read from f2. In some examples, the user's attention is directed to the newly suggested default values ​​(e.g., through highlighting) to encourage manual verification of correctness. This is monitored by logging how frequently the suggested values ​​are adopted or rewritten. In some examples, the accuracy of the default values ​​is determined. If the accuracy reaches a desired limit, highlighting the suggested defaults is stopped, indicating to the user that the default values ​​are now reliable. If the accuracy drops below a certain limit, the user is advised to adjust or deactivate the generated extension.

[0056] As mentioned above, default values ​​can be calculated using ML, for example, if an ML platform is provided (e.g., Figure 2The ML platform 206 is an example ML platform. Example ML platforms include AutoML (part of SAP Data Intelligence) provided by SAP AG in Walldorf, Germany. In some examples, the ML platform automates a pipeline of data preparation, feature engineering, feature selection, ML training, and hyperparameter tuning. According to an implementation of this disclosure, historical data from DOs and / or DOs associated with foreign key attributes (FKAs) are selected and fields for which the ML platform will suggest values. The ML platform processes the dataset to identify ML models in which training returns good accuracy (e.g., accuracy meeting a threshold). ML models can be used to provide default values. For example, the ML model is deployed in an infrastructure used for inference, and applications are configured and extended to invoke the ML model to obtain values ​​(e.g., such as...). Figure 2 As shown, application 210 (application module 210b) calls ML model 230 for data values.

[0057] In further detail, for input fields, the relevant attributes of the table fields are determined (e.g., determined by ERE 220'), either from the same table or other tables via FKA, and the history of the field (label) content and related fields (features) are read. As described herein, this can be performed using queries generated from, for example, SQL templates. An ML platform is invoked to process the dataset (e.g., such as...). Figure 2 As shown, the extended generator 224a calls the ML platform 206, which processes the dataset as training data from the ML model. If the ML platform provides an ML model with sufficient accuracy, the use of the ML model to generate default values ​​is proposed to the user (e.g., a civilian developer) to use the model to generate default values. If the user accepts, the extension is implemented and the default values ​​are provided by the ML model. In some examples, at least initially, attention can be directed to the proposed default values ​​(e.g., by highlighting) to encourage manual verification of correctness. How frequently the proposed default values ​​are adopted or rewritten can be monitored, and it can be used as a guide for the extended orchestrator (e.g., Figure 2 The extended orchestrator 220 reports the accuracy of its data. If the accuracy reaches a threshold accuracy (e.g., the default value is used at least 75% of the time), the highlighting of the recommended default value can be deactivated, indicating to the user that they can now rely on the recommended default value (however, the user can still override it). If the accuracy drops below the threshold accuracy, adjustments to the extension can be recommended to the user or the extension can be deactivated.

[0058] In some implementations, the generator is extended (e.g., Figure 2The extended generator 224a) at least partially coordinates ML activities. For example, the extended generator can identify input fields on the UI that have no computed default values, define a field "Input-Field", and can determine other key fields and input fields on the same UI, such as defining a set "Key + Attribute Field Set-1". In some examples, the extended generator can determine the table (e.g., based on FKA) related to the input field "Input Field" that defines "Table Input Field", and can determine fields related to "Input Field" in the same table as "Table Input Field" (e.g., those with the same keys) to define "Table - Key + Attribute Field Set-2". In some examples, the extended generator can determine the table related to "Key + Attribute Field Set-1" and determine additional fields at the table to define "Table - Key + Attribute Field Set-1". In some examples, the extended generator can read (e.g., by executing a query) existing (historical) values ​​of fields from tables associated with the set "table-key + attribute field set-1" and / or "table-key + attribute field set-2", the sets can be joined about common key values, giving "historical input field values", and can provide "historical input field values" as features and the values ​​for the field "table input field" as labels to the ML platform, calling the ML platform to run processing and determine the appropriate type of ML model and training pipeline for the ML model.

[0059] In some implementations, the extended generator can estimate the accuracy of the ML model to determine if it is accurate enough. For example, the ML platform can provide an accuracy score generated from the training process to the extended generator, which can then compare the accuracy score with a threshold accuracy. In some examples, if the ML model is accurate enough, the extended generator can generate code to: run data extraction (reading subsets of fields used by automatic ML from "table-key + attribute field set-1" and "table-key + attribute field set-2") and periodically train the ML model using the ML platform, deploy the ML model for application inference, and call the ML model from the application to pre-populate input fields.

[0060] In some examples, a default value suggestion generator for unstructured data sources is used to generate data extraction rules that can be used to populate DO fields with values ​​from unstructured data (e.g., scanned document images). In some examples, when the document is still uploaded as an attachment at the input screen (e.g., the document is a shipping invoice containing information about addresses, phone numbers, order numbers, dates, amounts, etc.), fields in the UI for which calculated default values ​​and default values ​​to be generated for the input screen are identified. In some examples, the document can be processed via a document text extraction ML algorithm to extract data, and input fields can be pre-populated with these values. In some examples, for example, the user is given the option to rewrite the values ​​if the detection is inaccurate. For some DOs (e.g., shipping invoices), this functionality can be provided as a hard-coded implementation by a standard solution. However, some DOs may lack this automation (e.g., because the attachment field itself is added as a field extension or some DO fields in the DO fields to be populated with extracted data are field extensions). In some examples, ERE 220 scans the definitions of all DOs and identifies those with document attachments. Attachments are analyzed based on their type (e.g., images are processed using Optical Character Recognition (OCR), and unstructured text is tokenized) to identify possible data values ​​that can be passed to DO fields. Using programming model artifacts, ERE 220' determines the UI input screen definition of the DO. Scanning the UI input screen definition for fields from DOs displayed along with attachment uploads limits the set of fields to those that are visible and modifiable on the UI. This produces a table of DOs whose fields are accessible via the UI and a list of document attachment fields with access paths to content in unstructured data that can be compared for matching.

[0061] In some implementations, a default value suggestion generator is provided for attached documents, suggesting default values ​​from the document's content. In some examples, a call is made with a DO name and a "Document Attachment" field name to identify the stored document (e.g., MS Word, Excel, PDF). In some examples, the document attachment field (which could also include user-extended document attachment fields) is provided in a table to store the document in the database.

[0062] In some implementations, historical data is extracted, which may include, but is not limited to, attached documents and attribute fields in tables written to by DO fields and UI. Document text extraction routines (e.g., ML services that detect text elements in a document) are performed on the documents to extract text data. In some examples, attached documents (e.g., PDFs, image files) may be processed first using Optical Character Recognition (OCR). In some examples, document patterns may be identified. For example, documents may be grouped (clustered) into groups of similar documents. In some examples, attributes are extracted from the documents, and the attributes are stored as a dataset with historical data using the relevant keys. For example, the extracted data provides item names and item values ​​(e.g., delivery note - nr, shipment quantity, etc.). In some examples, attribute matching is performed to determine which attribute field value in the table matches the attribute extracted from the document. For example, for each document cluster, it may be determined whether the attribute pair "extracted history <->" always matches the same extracted attribute (e.g., always matches the address "from" field, delivery note number, phone number, etc.).

[0063] In some examples, attribute matching is evaluated to determine the accuracy of the match. For attributes with sufficient accuracy (e.g., accuracy exceeding a threshold), an extension can be suggested to create default values ​​for the fields used for identification based on the document attachment. If accepted by the user (e.g., a civilian developer), an ML model is provided to extract attributes from the document (e.g., training using document clustering, if needed, via transfer learning). Further, code is provided in the UI (e.g., calls in the UI routine `fetchDefaultValue` for each field to retrieve default values), which is executed to invoke the ML service to scan the document, receive the extracted attributes, and pre-populate (empty) fields in the UI with the extracted attributes when the document is attached to the UI. Users interacting with the UI can accept or override the suggested data values.

[0064] As described above, extensions can be implemented, and user attention can be initially directed to the proposed default values ​​(e.g., through highlighting) to encourage manual verification of correctness. For example, for each UI element to which documentation is attached and whose input fields are pre-populated, it's possible to log whether suggested attributes are adopted or overridden, periodically determine the accuracy of proposed data values, and report the accuracy to the extension orchestrator. If the accuracy is sufficient, highlighting the proposed default values ​​can be deactivated to indicate that the proposed data values ​​are reliable. If the accuracy drops below a certain limit, adjustments to the generated extensions can be recommended or deactivated.

[0065] The implementation of this disclosure is illustrated with reference to non-restrictive example use cases. The first example use case involves adding field extensions to DOs associated with partner entities (e.g., a business's customers). The second example use case involves default values ​​for field extensions based on historical interactions with an entity (e.g., a business's customers). The third example use case involves pre-setting fields in event logs with values ​​from the relevant product register. The fourth example use case involves pre-setting material master data fields with values ​​extracted from attachments.

[0066] Regarding the first example use case, cloud-based applications can include input masks for "customer data" (or "business partners"). The input mask reflects persistence and has a set of fields for "name," "street," "region and town," "phone number," and "email address," as well as free-text fields where users can write additional information about the customer. For example, a UI can be provided that includes input elements (e.g., text boxes that allow users to enter text), each corresponding to one or more fields in the set of fields. In some cases, when there is no dedicated field for a particular piece of information, the user will enter that information in a free-text field. For example, because the set of fields lacks input for a website address (i.e., URL) or social network identifier (SNID), the user can type the website address and / or the customer's SNID in a free-text field. Because the website address and / or SNID are entered into a free-text field, it is difficult to utilize in business processes.

[0067] According to an implementation of this disclosure, an extended recommender system (e.g., ERE) scans the content of free text fields and determines that the free text fields contain website addresses at a first frequency and SNIDs at a second frequency. For example, the extended recommender system may use URL regular expressions and SNID regular expressions to scan the content of free text fields of a set of customer DOs to determine a first subset of customer DOs that each includes a URL in the corresponding free text field and a second subset of customer DOs that each includes a SNID in the corresponding free text field. In some examples, the first and second subsets overlap (e.g., some free text fields include both URLs and SNIDs). The first frequency is determined to represent the relative number of occurrences of URLs in the free text fields (e.g., the first frequency is the ratio (percentage) of the number of DOs in the first subset of DOs to the number of DOs in the set of DOs). The second frequency is determined to represent the relative number of occurrences of SNIDs in the free text fields (e.g., the second frequency is the ratio (percentage) of the number of DOs in the second subset of DOs to the number of DOs in the set of DOs).

[0068] In some examples, if the frequency meets or exceeds a threshold frequency (e.g., 20%), it can be determined that a field expansion should be added. Continuing with the unrestricted examples, it can be determined that a first frequency exceeds the threshold frequency and a second frequency does not exceed the threshold frequency. In response, the expanded recommender system provides a proposal to add the URL field to the "customer data" and provides input validation (e.g., checking URL conventions). The proposed field, type, and first frequency (estimated how frequently it will be used) are presented to the user (e.g., a civilian developer). In some examples, sample content (e.g., a website address determined based on a free text field) may also be presented to the user.

[0069] Users can accept or reject proposals. In some examples, if a user accepts a proposal, they can provide a label for a UI element, which will be created to enable data input. For example, an extended recommendation system can propose labels (e.g., URLs), and the user can accept the proposed labels or edit the labels (e.g., delete the URL and enter a customer website). Field extensions can be deployed for product use. For example, and as described herein, field extensions (e.g., URL fields) are added to the corresponding tables, and the UI is updated to include input elements (e.g., labeled as a customer website). After a certain period of time (e.g., weekdays, months) or periodically (e.g., every week, every month), the extended recommendation system can provide users with statistics, for example, regarding how frequently the number of URL inputs in the fields and / or free text fields has actually decreased.

[0070] In some examples, after the validation phase, automatic migration processing can be provided to automatically move data from the customer's DO from the free text field to the generated field extension. For example, after a predetermined period (e.g., weekday, month), the user can accept or reject continued use of the field extension. In some examples, if the user accepts, the URL in the customer's DO's free text field can be migrated to the field extension (e.g., copied from the free text field to the field extension, or deleted from the free text field). In some examples, if the user rejects continued use of the field extension, the URL entered into the field extension during the validation phase can be migrated to the free text field (e.g., copied from the field extension to the free text field), the field extension can be deleted from the table, and the UI is updated to remove the corresponding UI elements.

[0071] Regarding the second example use case, consider a Customer Relationship Management (CRM) system that has a "customer-request-ticket" populated when a customer makes an invocation. The scheduler populates the ticket with customer data (e.g., name, company) via a UI and adds a "subject" to assign it to the correct department for further processing. The concept of a company using the CRM system is to enable the assignment of "preferred processor" names to tickets. That is, identifying one or more users who should handle the ticket. The scheduler populates this by searching historical tickets, and when forwarding to the correct department, it can read from the ticket and directly assign the preferred processor.

[0072] In some examples, it can be determined whether to add a field extension (e.g., automatically by the extension recommendation system or manually by the user). In response to detecting the addition of a field extension, it can be determined whether to generate a default value. In response, the extension generator can execute a query to associate a customer with a processor. For example, the query could return data indicating that warrants for the same customer (which is a common master data object associated with those warrants) are processed by the same processor. For example, consider a query for historical data with the 10 most recent values ​​that matches a "preferred server" with a high percentage. In response, a default value for the field extension is calculated, generated, and presented to the user. For example, the user can adjust the historical data to "the 5 most recent" to focus only on the most recent values. The extension is then generated and deployed. After the extension is deployed, the scheduler only needs to populate the caller's name, company, and subject, while the system automatically pre-populates the preferred processor as the default value in the UI based on the company name. The scheduler can accept the default value or override it, as described in further detail here.

[0073] Regarding the third example use case, the company sells products through indirect channels but wants to build closer relationships with their end customers (e.g., for direct marketing campaigns). Therefore, the company creates an additional service for "product registration," through which end customers enter contact data and the serial number of the products they purchased. To incentivize registration, an extended warranty is granted to registered products. Upon successful registration, the product registration service stores the extended warranty expiry date in the product registration database for products with registered serial numbers.

[0074] When a product malfunctions, the end customer can create an incident report with the company, for example, by calling support. Support creates an incident record and enters the serial number of the product in question. Support also checks if the product is registered, and if so, copies the extended warranty expiration date from the product registration database to the corresponding "Warranty Expiration" field in the incident record (e.g., the field extension identified and added as described in the first example use case).

[0075] Because both product registration and incident logs share a common reference (product serial number), the default value generator can identify this correlation and suggest to users (e.g., civilian developers) to pre-set the warranty expiration date in newly created incident logs with the corresponding value from the product registration database, since these values ​​will obviously always match due to the initial manual processing. This allows for the automation of customization processes based on custom services and custom field extensions without actual development work, simply by analyzing repetitive user behavior and intelligently generating code that autonomously performs the necessary steps.

[0076] Regarding the fourth example use case, the materials management system has an input screen for creating new materials. Users (e.g., civilian developers) create field extensions for attachments, allowing documents from suppliers to be attached. During product use, detected documents can be attached. For example, it can be determined that the "Document Attachments" field contains PDF files. In response, the materials management system invokes a "Text Value Extraction Service" using existing documents and compares them with attributes in the system's Material Master Data Object (MM DO). It determines that a particular material supplier number and short material description can be extracted from the document and matched against the values ​​of fields in the MM DO. The system then generates code to integrate the Text Value Extraction Service when a new attachment is uploaded, populating the input fields. The generated extension is suggested to the user, who accepts the suggestion and optionally rearranges the order of fields in the UI for creating new materials, such that the attachment fields are ordered before the material supplier number and short material description. In this way, the user does not need to manually enter these fields and benefits from the generated extension.

[0077] Figure 3 Example processing 300 is shown that can be performed according to an implementation of this disclosure. In some examples, example processing 300 is provided using one or more computer-executable programs executed by one or more computing devices.

[0078] Data processing (302). For example, and as described herein, one or more fields of a database table can be analyzed to determine the presence of one or more data types. As described herein by way of example, an extended recommender system (e.g., ERE) scans the contents of free text fields and determines that the free text fields contain website addresses at a first frequency and SNIDs at a second frequency. For example, the extended recommender system may scan the contents of free text fields of a set of customer DOs, in addition to other regular expressions, using URL regular expressions and SNID regular expressions to determine a first subset of customer DOs that each includes a URL in the respective free text field and a second subset of customer DOs that each includes an SNID in the respective free text field.

[0079] Determine one or more frequencies (304). For example, and as described herein, the number of occurrences of values ​​of a data type in a field can be determined. As described herein by way of example, a first frequency is determined to represent the relative number of occurrences of a URL in a free text field (e.g., the first frequency is the ratio (percentage) of the number of DOs in a first subset of DOs to the number of DOs in a set of DOs), and a second frequency is determined to represent the relative number of occurrences of a SNID in a free text field (e.g., the second frequency is the ratio (percentage) of the number of DOs in a second subset of DOs to the number of DOs in a set of DOs).

[0080] Determine whether to recommend at least one extension (306). For example, and as described herein, if the frequency meets or exceeds a threshold frequency, it can be determined that a field extension for the corresponding data type should be recommended. If it is determined that no extension should be recommended, the example processing returns a 300 loop. If it is determined that at least one extension should be recommended, a recommendation is provided (308). As described herein by way of example, it can be determined that a first frequency exceeds a threshold frequency and a second frequency does not exceed a threshold frequency. In response, the extension recommendation system provides a proposal to add the URL field to "customer data" and provides input validation (e.g., checking URL conventions). The proposed field, type, and first frequency (estimated frequency of how frequently it will be used) are presented to the user (e.g., a civilian developer). In some examples, example content (e.g., a website address determined based on a free text field) may also be presented to the user.

[0081] Determine whether to accept the recommendation (310). For example, and as described herein, the user can accept or reject the proposal. If the recommendation is not accepted, the example process returns a 300 loop. If the recommendation is accepted, extension code is provided (312). For example, and as described herein, the user can provide labels for UI elements that will be created to enable input of data. For example, the extended recommendation system can suggest labels (e.g., URLs), and the user can accept the suggested labels or edit the labels (e.g., delete the URL and enter the customer's website).

[0082] Determine the default value (314). For example, and as described herein, the default value can be determined using one or more of the following: a default value proposal generator that transmits data from the relevant DO, an ML model deployment that generates the default value, and a default value proposal generator that extracts the default value from additional documents. Deploy the extension (316). For example, and as described herein, the extension code is executed to deploy the field extension and update the corresponding UI for product use. For example, and as described herein, the field extension (e.g., a URL field) is added to the corresponding table, and the UI is updated to include the input element (e.g., labeled as a customer website). In some examples, the default value is displayed in the UI when the user interacts with the application of the extension.

[0083] Determine if the accuracy of the extension is sufficient (318). For example, and as described herein, after a certain period of time (e.g., week, month) or periodically (e.g., weekly, monthly), the extended recommendation system may provide users with statistics such as how frequently the number of URL inputs in fields and / or free text fields has actually been reduced and / or whether default values ​​are being used / overridden. If the accuracy of the extension is insufficient, then update or remove the extended recommendations (320). If the accuracy of the extension is sufficient, then deactivate highlighting (322). For example, and as described herein, UI processing for highlighting default values ​​may be deactivated.

[0084] In some examples, after the validation phase, automatic migration processing can be provided to automatically move data from the customer's DO from the free text field to the generated field extension. For example, after a predetermined time period (e.g., weekday, month), the user can accept or reject continued use of the field extension. In some examples, if the user accepts, the URL in the customer's DO's free text field can be migrated to the field extension (e.g., copied from the free text field to the field extension, or deleted from the free text field). In some examples, if the user rejects continued use of the field extension, the URL entered into the field extension during the validation phase can be migrated to the free text field (e.g., copied from the field extension to the free text field), the field extension can be deleted from the table, and the UI is updated to remove the corresponding UI elements.

[0085] Now for reference Figure 4 A schematic diagram of an example computing system 400 is provided. System 400 can be used for operations described in association with the implementations described herein. For example, system 400 can include any or all of the server components discussed herein. System 400 includes a processor 410, memory 420, storage device 430, and input / output device 440. Components 410, 420, 430, and 440 are interconnected using a system bus 450. Processor 410 is capable of processing instructions for execution within system 400. In some implementations, processor 410 is a single-threaded processor. In some implementations, processor 410 is a multi-threaded processor. Processor 410 is capable of processing instructions stored on memory 420 or storage device 430 to display graphical information for a user interface on input / output device 440.

[0086] Memory 420 stores information within system 400. In some implementations, memory 420 is a computer-readable medium. In some implementations, memory 420 is a volatile memory cell. In some implementations, memory 420 is a non-volatile memory cell. Storage device 430 provides large-capacity storage for system 400. In some implementations, storage device 430 is a computer-readable medium. In some implementations, storage device 430 may be a floppy disk device, hard disk device, optical disk device, or magnetic tape device. Input / output device 440 provides input / output operations for system 400. In some implementations, input / output device 440 includes a keyboard and / or indicating devices. In some implementations, input / output device 440 includes a display unit for displaying a graphical user interface.

[0087] The described features can be implemented as digital electronic circuits, or as computer hardware, firmware, software, or a combination thereof. The device can be implemented as a computer program product tangibly embodied in an information carrier (e.g., in a machine-readable storage device for execution by a programmable processor), and the method steps can be executed by a programmable processor that executes instructions to perform the described implementation's functions by manipulating input data and generating output. The described features can advantageously be implemented as one or more computer programs executable on a programmable system, including at least one coupled programmable processor that receives and sends data and instructions from and to a data storage system, at least one input device, and at least one output device. A computer program is a collection of instructions that can be used directly or indirectly in a computer to perform an action or produce a result. Computer programs can be written in any programming language, including compiled or interpreted languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for a computing environment.

[0088] Suitable processors for executing instructions of a program include, for example, both general-purpose and special-purpose microprocessors, and a single processor or one of several processors in any type of computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. Computer components may include a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer may also include one or more large-scale storage devices for storing data files, or operatively coupled to communicate with one or more large-scale storage devices for storing data files; such devices include disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly representing computer program instructions and data include all forms of non-volatile memory, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by or included in an ASIC (Application-Specific Integrated Circuit).

[0089] To provide interaction with the user, the features can be implemented on a computer with a display device for displaying information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, and a keyboard and indicator device through which the user can provide input to the computer, such as a mouse or trackball.

[0090] Features can be implemented in a computer system, which may include back-end components such as data servers, or middleware components such as application servers or internet servers, or front-end components such as client computers with graphical user interfaces or internet browsers, or any combination thereof. The components of the system can be connected via any form or medium of digital data communication, such as a communication network. Examples of communication networks include LANs, WANs, and computers and networks that form the internet.

[0091] Computer systems can include clients and servers. Clients and servers are typically located far apart and interact via a network (such as the network described). The client-server relationship occurs through computer programs running on various computers and having client-server relationships with each other.

[0092] Furthermore, the logical flow shown in the figures does not require a specific or sequential order to achieve the desired result. Additionally, other steps may be provided, or steps may be removed from the described flow, and other components may be added to or removed from the described system. Therefore, other implementations are within the scope of the appended claims.

[0093] Several implementations of this disclosure have been described. However, it will be understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other implementations are within the scope of the appended claims.

Claims

1. A computer-implemented method for adding one or more field extensions to a table in a database and providing default values ​​to the field extensions in the database system, the method being executed by one or more processors and comprising: Query the metadata of data objects in a collection of data objects to determine the presence of one or more of the general text fields and attachment fields, thereby defining a subset of data objects, each of the data objects in the subset of data objects including one or more of the general text fields and attachment fields; and For each data object in a subset of data objects: The historical data of data objects is processed to identify a set of data types, and the historical data is stored in fields of tables in the database system. Determine the frequency of data values ​​in the table's fields that correspond to the first data type. In response to determining that the frequency at least satisfies a threshold frequency, a recommendation is provided for an extension of a first field corresponding to a first data type in the set of said data types, and Upon receiving an instruction to accept recommended user input that expands the first field, and in response, automatically: Provide executable extension code to add field extensions to tables and modify the user interface (UI) of the application for entering values ​​corresponding to the first data type, and Execute the extended code to deploy field extensions and modify the UI.

2. The method of claim 1, further comprising, in response to receiving an indication to accept recommended user input for expansion of the first field, determining a default value for selective presentation of the first data type in the UI.

3. The method of claim 2, wherein, Determining default values ​​includes providing default values ​​from historical data and extracting default values ​​from one or more additional documents.

4. The method of claim 1, wherein, Determining default values ​​involves launching a machine learning (ML) platform to provide an ML model that is trained to generate the default values.

5. The method of claim 1, further comprising: Determine the frequency of data values ​​within the historical data that correspond to the second data type; and In response to determining that the frequency fails to meet the threshold frequency, it is determined to abandon the recommendation to provide an extension to the second field corresponding to the second data type.

6. The method of claim 5, further comprising: The accuracy associated with the first field extension is determined based on one or more of the frequency of use of the first field extension and the acceptance of the default value of the first field extension; and Based on the accuracy of the information, the user may be selectively prompted to either update or remove the first extension.

7. A non-transitory computer-readable storage medium coupled to one or more processors and having instructions stored thereon, the instructions, when executed by the one or more processors, causing the one or more processors to perform operations for adding one or more field extensions to a table in a database and providing default values ​​to the field extensions in the database system, the operations comprising: Query the metadata of data objects in a collection of data objects to determine the presence of one or more of the general text fields and attachment fields, thereby defining a subset of data objects, each of the data objects in the subset of data objects including one or more of the general text fields and attachment fields; and For each data object in a subset of data objects: The historical data of data objects is processed to identify a set of data types, and the historical data is stored in fields of tables in the database system. Determine the frequency of data values ​​in the table's fields that correspond to the first data type. In response to determining that the frequency at least satisfies a threshold frequency, a recommendation is provided for an extension of a first field corresponding to a first data type in the set of data types, and Upon receiving an instruction to accept recommended user input that expands the first field, and in response, automatically: Provide executable extension code to add field extensions to tables and modify the user interface (UI) of the application for entering values ​​corresponding to the first data type, and Execute extension code to deploy field extensions and modify the UI.

8. The non-transitory computer-readable storage medium of claim 7, wherein, The operation further includes, in response to receiving an instruction to accept recommended user input for an extension of the first field, determining a default value for selective presentation of the first data type in the UI.

9. The non-transitory computer readable storage medium of any of claims 7 to 8, wherein, Determining default values ​​includes providing default values ​​from historical data and extracting default values ​​from one or more additional documents.

10. The non-transitory computer readable storage medium of any of claims 7 to 9, wherein, Determining default values ​​involves launching a machine learning (ML) platform to provide an ML model that is trained to generate the default values.

11. The non-transitory computer readable storage medium of any of claims 7 to 10, wherein, The operation also includes: Determine the frequency of data values ​​within historical data that correspond to the second data type; and In response to determining that the frequency fails to meet the threshold frequency, it is determined to abandon the recommendation to provide an extension to the second field corresponding to the second data type.

12. The non-transitory computer-readable storage medium as described in any one of claims 7 to 8, wherein, The operation also includes: The accuracy associated with the first field extension is determined based on one or more of the frequency of use of the first field extension and the acceptance of a default value for the first field extension; and Based on the accuracy stated, the user may be selectively prompted to either update or remove the first field extension.

13. A system comprising: Computing device; and A computer-readable storage device coupled to a computing device and having instructions stored thereon, said instructions, when executed by the computing device, causing the computing device to perform operations for adding one or more field extensions to a table in a database and providing default values ​​to the field extensions in the database system, said operations including: Query the metadata of data objects in a collection of data objects to determine the presence of one or more of the general text fields and attachment fields, thereby defining a subset of data objects, each of the data objects in the subset of data objects including one or more of the general text fields and attachment fields; and For each data object in a subset of data objects: The historical data of data objects is processed to identify a set of data types, and the historical data is stored in fields of tables in the database system. Determine the frequency of data values ​​in the table's fields that correspond to the first data type. In response to determining that the frequency at least satisfies a threshold frequency, a recommendation is provided for an extension of a first field corresponding to a first data type in the set of data types, and Upon receiving an instruction to accept recommended user input that expands the first field, and in response, automatically: Provide executable extension code to add field extensions to tables and modify the user interface (UI) of the application for entering values ​​corresponding to the first data type, and Execute extension code to deploy field extensions and modify the UI.

14. The system of claim 13, wherein, The operation further includes, in response to receiving an instruction to accept recommended user input for an extension of the first field, determining a default value for selective presentation of the first data type in the UI.

15. The system of claim 14, wherein, Determining default values ​​includes providing default values ​​from historical data and extracting default values ​​from one or more additional documents.

16. The system of claim 13, wherein, Determining default values ​​involves launching a machine learning (ML) platform to provide an ML model that is trained to generate the default values.

17. The system of claim 13, wherein, The operation also includes: Determine the frequency of data values ​​within historical data that correspond to the second data type; and In response to determining that the frequency fails to meet the threshold frequency, it is determined to abandon the recommendation to provide an extension to the second field corresponding to the second data type.