LIVE DATA FORM VIEWING AND UPDATING SYSTEM

Abstract

A live data form system is provided that includes a client that executes a browser that receives one or more user requests to view or update a live data form being stored remotely. The live data form includes a plurality of data blocks having information that defines the live data form. The browser issues a first message with respect to viewing or updating the live data form. A server receives the first message and executes a first routine that analyzes the contents of the first message and formulates one or more query statements associated with a data block to be executed by one or more remote databases. When the one or more remote databases finish performing the one or more query statements, the server issues a second message to the browser that includes the results of the one or more query statements executed by the one or more remote databases via the client to either view or update the live data form.

Description

PRIORITY INFORMATION

This application claims priority from provisional application Ser. No. 61/392,252 filed Oct. 12, 2010, which is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

The invention is related to field of network applications, and in particular to a live data form viewing and updating process.

Traditional document management, requiring extensive use of locally attached scanning devices, file servers, databases, and the like, has long been rooted in the technology of yesterday: namely, Windows-based client/server technology. A new era of computing is currently being ushered in; one that revolves around portability, cross platform support, and a new and growing installed base of mobile devices driven by Google, the resurgent Apple Inc. and others. Leveraging this new and increasingly adopted technology environment requires redesigning and, in many cases, reinventing wheels that no longer fit. Unfortunately, the enterprise document management space is largely tied to legacy client/server architecture. While most vendors offer a lightweight web client with limited functionality—to present a veneer of modernity—the bulk of the underlying technology is built on traditional Windows-based client server architecture. As Java technology continues to evolve and consume a greater percentage of development projects worldwide, more and more leading software companies are leveraging its portability and multi-platform capabilities to prepare for the next-generation Internet. The next generation Internet is one based on portability, open standards, and mobile device support. The ability to provide full document management functionality in the absence of traditional client/server technology while supporting any web browser on any platform along with a wide range of mobile devices presents a number of unique challenges.

SUMMARY OF THE INVENTION

According to one aspect of the invention, there is provided a live data form system. The live data form includes a client that executes a browser that receives one or more user requests to view or update a live data form being stored remotely. The live data form includes a plurality of data blocks having information that defines the live data form. The browser issues a first message with respect to viewing or updating the live data form. A server receives the first message and executes a first routine that analyzes the contents of the first message and formulates one or more query statements associated with a data block to be executed by one or more remote databases. When the one or more remote databases finish performing the one or more query statements, the server issues a second message to the browser that includes the results of the one or more query statements executed by the one or more remote databases via the client to either view or update the live data form.

According to another aspect of the invention, there is provided a method of viewing and updating a live data form. The method includes executing a browser on a client that receives one or more user requests to view or update the live data form being stored remotely. The live data form include a plurality of data blocks that includes information that defines the live data form. The browser issues a first message with respect to viewing or updating the live data form. Also, the method includes receiving the first message and executing a first routine on a server that analyzes the contents of the first message and formulates one or more query statements, and performing the one or more query statements by one or more remote databases. Furthermore, the method includes issuing a second message by the server to the browser that includes the results of the one or more query statements executed by the one or more remote databases via the client to either view or update the live data form.

According to another aspect of the invention, there is provided a computer readable medium for storing a program being executed on a computer system. The programs performs a method of viewing and updating a live data form. The method includes executing a browser on a client that receives one or more user requests to view or update the live data form being stored remotely. The live data form includes a plurality of data blocks that include information that defines the live data form. The browser issues a first message with respect to viewing or updating the live data form. Also, the method includes receiving the first message and executing a first routine on a server that analyzes the contents of the first message and formulates one or more query statements, and performing the one or more query statements by one or more remote databases. Furthermore, the method includes issuing a second message by the server to the browser that includes the results of the one or more query statements executed by the one or more remote databases via the client to either view or update the live data form.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram illustrating the live data form system used in accordance with the invention; and

FIG. 2 is a process flow illustrating the steps in displaying one or more images in accordance with the invention; and

FIG. 3A-3B are process flows illustrating the steps for the live data form updating process.

DETAILED DESCRIPTION OF THE INVENTION

The invention provides a live data form that is a unique, configurable data form that allows multiple data fields from multiple disparate databases to be aggregated into a single, seamless form within the browser. The invention allows a user to update the various data blocks used within the form without expanding or requiring any manual control. The invention also updates the respective contents of the data blocks in their respective databases that is stored remotely.

The invention is implemented in a platform independent framework, which allows the invention to run on various operating system platforms. The invention can be implemented using platform independent computer languages, such as Java or the like. This allows the invention to be used freely in various operating system platforms without limiting the functionalities of the invention. Moreover, the browser used in accordance with the invention can use run code from the platform independent computer languages to operate the objectives of the invention. In addition, the invention can operate on both conventional computer systems as well as mobile devices and tablets.

FIG. 1 is a schematic diagram illustrating the live data form system 2 used in accordance with the invention. The live data form system 2 includes a user working on a computer system 3 that is executing a browser 4. The computer system 3 includes a processor, a portable storage, and processor storage medium. The browser 4 displays a number of images and information for which the user 4 discerns. Also, the browser 4 includes the ability to retrieve information over the Internet and facilitate communications with other computer systems, such as a server 8. The communication protocols, such as TCP/IP or the like, are used by the browser 6 to communicate with the server 8 and other computer systems used in a network.

The system 2 requires a user to be authenticated to a server 8. In this case, the user provides their authentication information, such as username and/or password, and the browser 4 creates a request 20, which the computer system 3 sends to the server 8. The message 20 includes authentication information and form information. When the server 8 receives the message 20, it initiates a form engine 10 to analyze the authentication information and determine if the user is given privileges to access the requested form. If is determined the user cannot have access to the form 6, the user's ability to view and access the form is disabled. Otherwise, the form engine 10 provides the form 6 and all associated component retrieved from either the metadata store 12 and/or document repository 14 to server 8. The server 8 packages the information provided by the form engine 10 into a message 22 to be sent to the browser 4 via the computer system 3. The live data form 6 used in accordance with the invention includes a custom collection of data of autonomous data blocks 7 where each block 7 is an assortment of one or more customized SQL statements needed to perform a query, insert, or update operations associated with each data block 7.

The invention requires that a search query be executed using the embedded search and index query operation described in U.S. patent application Ser. No. (Nolij 9372), which is incorporated in its entirety herein. When a search result is provided, a list of folders is provided to the user. Once a folder is selected the browser 4 automatically refreshes the contents of the folder by having the browser 4 pass a key value, in this case a unique ID associated with the folder to the server 8. The folder contents represent documents contained within the folder. Each form 6 built using the form engine 10 can be configured to refresh based on either a folder or document selection, but not both. If configured for folder refresh, then once the server 8 receives the key value from the browser 4, the server 8 initiates the form engine 10. If configured for document refresh, then the form 6 waits for a document to be selected. Once a document is selected, the browser 4 passes the unique ID associated with the document to the server 8, which initiates the form engine 10. The form engine 10 starts up a parsing loop that goes through each data block 7 associated with the form 6. The form 6 can have a selective number of data blocks 7 and a parsing loop is specifically designed to extract the first data block 7 and continue monitoring for additional data blocks 7. Once the loop extracts a data block 7, a determination is made as to whether there are embedded variables. The embedded variable can include a number of variables such as folder ID, document ID, and user ID as well as other references to any fields located on any data blocks 7 on the form 6.

The form engine 10 parses all the variables and replaces each variable with a corresponding value. Using this information, the form engine 10 formulates SQL statements used in querying either the metadata store 12 or document repository 14. Note the metadata store 12 and the document repository 14 are database structures that store and classify information. Before a query is executed, all targeted databases 12, 14 are identified and connections are established between the server 8 and the databases 12, 14. The form engine 10 executes SQL statements associated with a current data block 7. The results of the execution of the SQL statement are added to a Data Transfer Object (DTO) package 26 for delivery to the browser 6. The DTO is a design pattern used to transfer data back to the browser 4. The form engine 10 continues onto the next data block 7 until all data blocks 7 have been parsed and the associated SQL statement executed using a parsing loop.

The final component of the live form viewing process includes the server 8 providing the DTO results 26 to the browser 4 for further processing. Once the browser 6 receives the DTO results 26, the browser 4 retrieves all data values and populates the live data form 6 using the retrieved results. The live data form 6 is a unique and configurable form that permits a plurality of fields from one or more databases to be combined into a single form viewable within the browser 4.

The invention allows information within the live data form 7 to be updated without exhausting or extremely expanding resources. Before any update process can be initiated, the live data form 6 must be refreshed. The invention allows one or more data blocks 7 to be updated. These updated data blocks 7 are enabled for data entry when the form engine 10 checks through all the data blocks 7 looking for any sign of update logic using a parsing loop. This means at least one block can be configured with save capabilities, such as a SQL insert and/or update logic, where the update logic is set as true.

When it is determined there is no update logic, all top level form save controls are disabled. Otherwise, those data blocks 7 that have update logic are enabled for data entry and any top-level form save controls are enabled in the browser 4. Also, one or more data blocks 7 can be edited and/or updated prior to the enabled form save controls being enabled. When the one or more fields are updated in the data blocks 7, this triggers the save process within the browser 4.

Before the server 8 evaluates and processes any form changes, the browser 4 loops and parses all form data blocks 7, tracking the changes found using a parsing loop. The browser 4 checks for further available data blocks 7 at each loop pass. The data block field values are packaged for possible SQL reference and uses, given each data block 7 can reference any field values on the form 6. The browser 4 determines at each data block 7 having field level editing if changes were made. And when changes are found, the data block 7 is flagged for later inclusion in the form engine 10 update loop process. Once the data block 7 is flagged or when there are no changes, all field IDs and data from the data block 7 are collected by the browser 4 in the loop. The collected information is added to a DTO request package 25 to be sent to the server 8 for further processing.

The loop process continues until all data blocks 7 have been processed and added into a DTO request package 25. The browser 4 sends the DTO request package 25 to the server 8. When the server 8 receives the DTO request package 25, the server 8 prepares for processing the data blocks 7 added to the DTO request package 25. The server 8 examines all the data blocks 7 with the save option configured. Only those data blocks field values having embedded save logic are evaluated in the loop executed by the form engine 10. If is determined that there is no save option within a current data block 7, the form engine 10 continues on to the next data block 7. Otherwise, the current data block 7 does include save logic and the form engine 10 checks to see if substitutions are necessary. Substitutions apply to all embedded variable and external field references. The form engine 10 carries out the substitutions and creates the finished SQL statement(s) for execution.

Afterwards, the server 8 establishes a connection with the remote database 12, 14 for the current data block 7. Given each data block 7 is an autonomous data object that can connect to any external SQL database, this allows the form to join, query, and/or update any number and type of external databases through a simple and seamless interface. When the connection is established between the server 8 and remote database(s) 12, 14, the server pass all SQL statements using messages 16, 18 to the target database 12, 14 for execution. The server 8 collects the results of SQL statement and adds them to a DTO results package 26 to be sent to the browser 4. The form engine 10 continues the data block parsing loop until all data blocks 7 have been evaluated. Once the form engine 10 is complete performing the parsing loop, the DTO results package 26 is sent to the browser 4. When the browser 4 receives the DTO results package 26, the browser 4 updates all forms fields with new or updated data.

Also, the data blocks 7 of the form 6 can initially be created by a user using the browser 4. In this case, the user can initiate a save of the new created form 6 and its respective data blocks 7. When this occurs, the browser 4 uses the parsing loop to parse all data blocks in the form 6 and package the information into a DTO request package 24 to be sent to the server for storage in either of the database(s) 12, 14. When the server 8 receives the DTO request package 24, it processes the contents and sends them to the form engine 10 for further processing. The form engine 10 using its parsing loop retrieves all the respective data block information and then formulates SQL queries that saves the data block information in either the metadata store 12 or document repository 14. The server 8 establishes connection with either of the databases 12, 14 to execute the SQL queries.

The live data form 6 is a novel and configurable data form that allows multiple data fields from multiple disparate databases to be aggregated into a single, seamless form within a browser 4. FIG. 2 is a process flow illustrating the steps for the live data form viewing process.

Before the data form 6 can be accessed, a user must log in as shown in step 31. This first level of authentication only controls access to the browser 4 at a top level. Subsequent permissions are evaluated to determine if the connected user is allowed to use the live data form and to what degree, as shown in step 32. If use of the live data form is not granted, the ability to access and even view the form 6 is disabled. If, however, the user is allowed to use the data form 6, as shown in step 33, then the browser 4 proceeds to download the assigned form components and render the full form 6, as shown in step 34.

Unlike traditional rigid data forms, each live data form 6 is a custom collection of autonomous data blocks where each data block 7 is a collection of one or more custom SQL statements as needed to perform the defined query, insert, or update tasks associated with each data block 7.

As a pre-requisite to using the data form 6, a search query must be executed using the embedded search and index query interface, as described in U.S. patent application Ser. No. 13/247,536 (Nolij 9372), which is incorporated in its entirety herein, and at least one folder must be returned from the search. The live data form 6 automatically refreshes when one of the displayed folders or folder documents is selected, as shown in step 35, and the first step in the refresh process is for the browser 4 to pass key value data—typically a unique ID—associated with the selected folder or document to the server 8 to be used in the refresh process, as shown in step 36.

After the server 8 receives the key value data from the browser 4, it initiates a parsing loop through all data blocks 7 associated with the current form 6, as shown in step 37. Each form 6 can contain any number of data blocks 7, so the loop is configured to retrieve the first available data block 7, the continue monitoring for additional data blocks 7, as shown in step 38. Once the parsing loop has a data block 7, it first checks for embedded variables, as shown in step 39. Form data blocks 7 can include a number of embedded variables including folder ID, document ID, and end user ID as well as references to any fields located on any data blocks 7 on the form 7. The form engine 10 parses all variables, as shown in step 40, replacing each variable with a corresponding value. It then constructs finished SQL statements in preparation for execution, as shown in step 41.

Prior to running any SQL, a target database is identified and an appropriate connection is opened to that database, as shown in step 42. Once a database connection is opened for the current data block, the loop processor executes all SQL statements against the connected database, as shown in step 43. Upon completion of the SQL execution, the results of the SQL statement(s) are added to a Data Transfer Object (DTO) result package 22 for delivery back to the browser 4, as shown in step 44. A Data Transfer Object is a design pattern used to transfer data between the server 8 and the browser 4. After processing the SQL results, the loop processor moves onto the next data block until all data blocks have been parsed and the associated SQL executed.

The final piece of the live data form viewing process involves the server returning the full DTO results package to the originating browser 4, as shown in step 45. The browser 4 then loops through the DTO package 22, extracts all data values, as shown in step 46, and populates the live data form 6 with the extracted data, as shown in step 47.

As described herein, the inventive live data form 6 is a unique, configurable data form that allows multiple data fields from multiple disparate databases to be aggregated into a single, seamless form within the browser 4. Prior to performing any updates within the live data form 6, the form 6 must be refreshed as described in FIG. 2. FIG. 3A-3B are process flows 50, 80 illustrating the steps for the live data form updating process.

As mentioned above, the form 6 must be refreshed prior to any data updates being carried out. As such, the live data form viewing process must be completed, as shown in step 51 of FIG. 3A. Depending on the form configuration, anywhere from none to some or even all of the data blocks 7 may allow updating. Those data blocks 7 that allow updating are enabled for data entry when the browser 4 performs a parsing loop through all data blocks 7 looking for the presence of update logic, as shown in step 52. At least one data block 7 must be configured with a save capability—meaning SQL insert and/or update logic—for the update logic check to be true.

If update logic is not found, as shown in step 53, then any top level form save controls are disabled, as shown in step 54. If update logic is found, then those individual data blocks 7 are enabled for data entry and any top level form save controls are enabled in the browser 4, as shown in step 55. Prior to the now-enabled form save controls to be available for use, one or more data block fields must be edited and/or updated, as shown in step 56. Once one or more fields are updated, the user selection within the browser 4 of the appropriate form save control triggers the form save process, as shown in step 57.

Prior to the server 8 evaluating and processing any form 6 changes, the browser 6 must loop and parse all form data blocks 7, noting any changes, as shown in step 58. At each loop pass, the browser 4 checks for mare available data blocks 7, as shown in step 59. Since each data block 7 can reference any field values on the form, all data block field values must be packaged for possible SQL reference and use. At each data block 7 with field level editing enabled, the browser 4 checks if any changes were made, as shown in step 60, and if so, flags that data block 7 for later inclusion in the form engine 10 parsing loop, as shown in step 61. After the data block 7 is flagged, or in cases where changes were not made, the browser 4 collects all field IDs (identifiers uniquely identifying each field on the form) and data from the data block 7 now being processed in the loop, as shown in step 62. Once collected, all field IDs and data from the current data block 7 are added to a DTO request package 25 to be delivered to the server 8 for processing, as shown in step 63.

The loop through all data blocks 7 continues using the parsing loop until all data blocks 7 have been processed, flagged (if appropriate), and added to the DTO request package 25. Once the DTO request package 25 build is completed, the browser 4 submits the DTO request package 25 to the server 8 for processing, as shown in step 64. The server 8 receives the DTO request package 25, as shown in step 65, and prepares the DTO package 25 for execution, as shown in step 66 of FIG. 3B.

Once on the server 8, the DTO package 25 is evaluated and all data blocks 7 with the save option configured are processed. Although all form data block field values are passed to the server 8, only those data blocks 7 with embedded save logic are evaluated in the form engine 10 parsing loop, as shown in step 67. As the loop selects each data block 7, a check is made for the configured save option, as shown in step 68. If the save option is not detected, the current data block 7 is skipped and the form engine 10 moves on to the next data block 7. If the current data block 7 does contain save logic, then the form engine 10 checks to see if any substitutions are necessary, as shown in step 69. Substitutions apply to all embedded variables and external field references. The form engine 10 performs any required substitutions, as shown in step 70, and then constructs the finished SQL statement(s) for execution, as shown in step 71.

Once the finished SQL statements are ready for execution, the server 8 opens the proper remote database connection as needed for the current data block 7, as shown in step 72. Since each data block 7 is an autonomous data object, capable of connecting to virtually any external SQL database, each data form 6 is therefore able to join, query, and update any number and type of external databases through a single, seamless interface. Once the connection is established, the server 8 passes all SQL statements to the target database(s) 12, 14 for execution, as shown in step 73. As each SQL statement is executed, the results of the SQL execution are collected and added to the DTO results package 26 for delivery back to the browser 4, as shown in step 74.

The form engine 10 continues the data block parsing loop by checking for more data blocks 7, as shown in step 75. If more data blocks are found, the process repeats until all data blocks 7 have been evaluated. Upon loop completion, the server 8 returns the completed DTO results package 26 to the originating browser 4, as shown in step 76, which the browser 4 uses to refresh all form fields with new or updated data, as shown in step 77.

The invention provides a live data form having configurable arrangement permitting multiple data fields from multiple disparate databases to be aggregated into a single, seamless form within a browser. The invention allows a user to update the various data blocks used within the form without expanding or requiring any manual control. The invention also updates the respective contents of the data blocks in their respective databases that is stored remotely. The invention is configurable to operate in mobile systems as well as conventional computer systems that are connected on a network.

Although the present invention has been shown and described with respect to several preferred embodiments thereof, various changes, omissions and additions to the form and detail thereof, may be made therein, without departing from the spirit and scope of the invention.

Claims

1. A live data form system comprising:

a client that executes a browser that receives one or more user requests to view or update a live data form being stored remotely, the live data form includes a plurality of data blocks that include information that defines the live data form, the browser issues a first message with respect to viewing or updating the live data form; and

a server that receives the first message and executes a first routine that analyzes the contents of the first message and formulates one or more query statements associated with a data block to be executed by one or more remote databases, when the one or more remote databases finish performing the one or more query statements, the server issues a second message to the browser that includes the results of the one or more query statements executed by the one or more remote databases via the client to either view or update the live data form.

2. The live data form system of claim 1, wherein the one or more remote databases comprise a metadata store or a document repository.

3. The live data form system of claim 1, the server prepares a DTO request to be associated with the second message.

4. The live data form system of claim 3, wherein the server establishes remote connection with the one or more remote databases.

5. The live data form system of claim 4, wherein the first routine parses the first message to formulate the one or more query statements.

6. The live data form system of claim 1, wherein the first routine determines whether the data block needs to be updated by determining if a save logic is stored in the data block.

7. The live data form system of claim 6, wherein the first message comprises a DTO package sent to the server.

8. The live data form system of claim 1, wherein the data block comprises an autonomous data object capable of connecting to any remote database.

9. A method of viewing and updating a live data form comprising:

executing a browser on a client that receives one or more user requests to view or update the live data form being stored remotely, the live data form includes a plurality of data blocks that include information that defines the live data form, the browser issues a first message with respect to viewing or updating the live data form;

receiving the first message and executing a first routine on a server that analyzes the contents of the first message and formulates one or query statements;

performing the one or more query statements by one or more remote databases; and

issuing a second message by the server to the browser that includes the results of the one or more query statements executed by the one or more remote databases via the client to either view or update the live data form.

10. The method of claim 1, wherein the one or more remote databases comprise a metadata store or a document repository.

11. The method of claim 1, the server prepares a DTO request to be associated with the second message.

12. The method of claim 3, wherein the server establishes remote connection with the one or more remote databases.

13. The method of claim 4, wherein the first routine parses the first message to formulate the one or more query statements.

14. The method of claim 1, wherein the first routine determines whether the data block needs to be updated by determining if a save logic is stored in the data block.

15. The method of claim 6, wherein the first message comprises a DTO package sent to the server.

16. The method of claim 1, wherein the data block comprises an autonomous data object capable of connecting to any remote database.

17. A computer readable medium for storing a program being executed on a computer system, the programs performs a method of viewing and updating a live data form comprising:

executing a browser on a client that receives one or more user requests to view or update a live data form being stored remotely, the live data form includes a plurality of data blocks that include information that defines the live data form, the browser issues a first message with respect to viewing or updating the live data form;

receiving the first message and executing a first routine on a server that analyzes the contents of the first message and formulates one or more query statements;

performing the one or more query statements by one or more remote databases; and

issuing a second message by the server to the browser that includes the results of the one or more query statements executed by the one or more remote databases via the client to either view or update the live data form.

18. The computer readable medium of claim 17, wherein the one or more remote databases comprise a metadata store or a document repository.

19. The computer readable medium of claim 17, the server prepares a DTO request to be associated with the second message.

20. The computer readable medium of claim 19, wherein the server establishes remote connection with the one or more remote databases.

21. The computer readable medium of claim 20, wherein the first routine parses the first message to formulate the one or more query statements.

22. The computer readable medium of claim 17, wherein the first routine determines whether the data block needs to be updated by determining if a save logic is stored in the data block.

23. The computer readable medium of claim 22, wherein the first message comprises a DTO package sent to the server.

24. The computer readable medium of claim 17, wherein the data block comprises an autonomous data object capable of connecting to any remote database.