A method for implementing a unified process hub

Abstract

The application provides an implementation method of a unified process center, to solve the technical problems of difficult operation and high cost of the existing unified process center scheme. The method comprises: analyzing and abstracting the current problem to determine that the characteristics of the query data are tables scattered in different databases; designing a query algorithm according to the abstracted problem; wherein the query algorithm comprises a global query algorithm and a three-time query algorithm; determining the query list type and the general query condition, and unifying the result set model and the arrangement rule; and constructing the unified process center based on the query algorithm and in combination with the current problem. The method solves the unified query problem of different workflow engines, can query all workflow engine data with one query condition, supports page query and will not cause query errors and performance problems with the increase of the number of pages, provides the least query list, and provides the best user operation experience.

Description

Technical Field

[0001] This application relates to the field of office system development technology, and in particular to a method for implementing a unified process center. Background Technology

[0002] When a company has multiple workflow engines, users need to view and process workflows across multiple systems, which greatly reduces the user experience and processing efficiency. Therefore, a unified workflow center is established to bring together workflows from various systems on a single page for access and processing via a single point of contact.

[0003] To establish a unified process center, there are currently two main solutions in the industry. The first is to abandon or shield the system's own workflow engine, using a single third-party workflow engine through system integration. This centralizes processes from various systems under a single workflow engine, achieving a unified process center. This approach is generally suitable for systems without their own workflow engine or with few workflow definitions. The second is to aggregate processes from different systems into a single page using different tabs or front-end components, achieving unified process access. Solution one requires significant modification and integration costs, increasing system dependency, reducing system stability, and causing considerable inconvenience for maintenance and troubleshooting, resulting in extremely high overall costs. Solution two, while maintaining the independence of process engines and significantly reducing implementation difficulty and workload by only integrating query functionality, still fails to achieve a truly unified process list because the query list remains categorized by system and page. Furthermore, since users experience different processes under different workflow engines, a consistent and adaptive query experience cannot be provided to different users. The number of process query lists continues to increase with the number of workflow engines, resulting in a poor overall user experience. Summary of the Invention

[0004] This application provides a method for implementing a unified process center, which solves the technical problems of difficult operation and high cost of existing unified process center establishment schemes.

[0005] This application proposes a solution that, while maintaining the independence of each workflow engine, defines a unified process result set model and sorting rules. By connecting only to queries, it uses a global query algorithm and a self-developed three-stage query algorithm to merge the results of different workflow engines into a unified result set for display. An adaptive unified process center can be achieved through a single query list.

[0006] This application provides a method for implementing a unified process center, the method comprising the following steps: Step S1: Analyzing and abstracting the current problem to determine that the characteristics of the query data are tables scattered across different databases; Step S2: Designing a query algorithm based on the abstract problem; wherein, the query algorithm includes a global query algorithm and a three-dimensional query algorithm; Step S3: Determining the query list type and general query conditions, and unifying the result set model and arrangement rules; Step S4: Based on the query algorithm and combined with the current problem, constructing a unified process center.

[0007] In one implementation of this application, the global query algorithm includes: querying each data source separately; merging, sorting, and truncating the query results.

[0008] In one implementation of this application, the three-query algorithm includes: calculating the average database offset; querying the total data volume of each data source; traversing each data source, marking the actual database offset and redundant database offset of each data source; accumulating the redundant database offsets and calculating the average redundant database offset; distributing the average redundant database offset to non-redundant data sources to obtain the final offset of each data source; querying each data source based on the page size and the final database offset; calculating the maximum and minimum values ​​of the sorting field of the returned results; querying each data source based on the maximum and minimum values; traversing each data source and accumulating to obtain the global offset; and merging, sorting, and truncating the query results.

[0009] In one implementation of this application, the query type includes: pending processes, completed processes, completed processes, user-initiated processes, and all processes.

[0010] In one implementation of this application, the general query conditions include: current user unique identifier, process title, process engine type, process creator unique identifier, creator unique department identifier, initiation time start, initiation time end, unique process definition identifier, and unique process instance identifier.

[0011] In one implementation of this application, the unified result set model includes: a unique process definition identifier, a unique process instance identifier, a unique process task identifier, a process engine type, a process title, the current node of the process, the current operator of the process, a unique identifier of the process creator, a process creation time, a task receiving time, a task operation time, and a sorting field value.

[0012] In one implementation of this application, the sorting rule is to digitize the sorting time field, such as converting the time into a unique UNIX timestamp.

[0013] In one implementation of this application, step S4 specifically involves: parsing the query conditions; determining that the query conditions are for a single process engine query, and if so, directly performing a paginated query on the corresponding process engine and returning the result; determining that the query conditions are not for a single process engine query, but for a homepage query; querying the number of instances of each process engine in parallel, and determining that if a single engine has data, directly performing a paginated query on the corresponding process engine and returning the result; otherwise, performing a query based on a global query algorithm and returning the result; if the query conditions are not for a single process engine query, and not for a homepage query, executing a three-step query algorithm, starting with the first query; determining whether a single engine has data, and if so, directly performing a paginated query on the corresponding process engine and returning the result; otherwise, performing a second query and a third query and returning the result.

[0014] The unified process center implementation method provided in this application has the following beneficial effects:

[0015] (1) It solves the problem of unified query for different workflow engines. It can query data from all workflow engines with a single query condition. It supports pagination and will not cause query errors or performance issues as the number of pages increases. It provides the minimum number of query lists and offers the best user experience.

[0016] (2) The adaptive problem has been solved. The front-end page can be fully adaptively displayed according to the data of the entire user process engine.

[0017] (3) It solves the problem of scalability, mainly in two parts: First, when a new process engine needs to be incorporated into the unified process center, it can be achieved by simply connecting to the backend interface without changing the front end; Second, it supports the reuse of algorithms to implement other query lists of the unified process center.

[0018] (4) It can serve as a standard solution to address database sharding queries that are inconsistent with other data models or have irregular data distribution. As long as a common result set and a unified sorting rule can be extracted, the algorithm of this invention can be implemented. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 A flowchart illustrating an implementation method for a unified process center provided in this application embodiment;

[0021] Figure 2 A schematic diagram illustrating the setup of the unified process center for this application;

[0022] Figure 3 This is an example diagram of the global query algorithm in this application;

[0023] Figure 4 This is a schematic diagram of the three-query algorithm of this application;

[0024] Figure 5 This is a flowchart illustrating the implementation process of the unified process center in this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] This application provides a method for implementing a unified process center, addressing the technical problems of operational difficulties and high costs associated with existing unified process center solutions. On one hand, it resolves the system dependency issue in existing Solution 1, maximizing the stability and scalability of the unified process center while significantly reducing costs and maintenance complexity. On the other hand, while maintaining a nearly identical workload and difficulty in integration as Solution 2, it achieves a unified, adaptive query list for all process engines, ensuring user operation is comparable to that of a single process engine, greatly enhancing the user experience. The technical solution proposed in this application will be described in detail below with reference to the accompanying drawings.

[0027] Figure 1 A flowchart illustrating a method for implementing a unified process center, as provided in this application embodiment. Figure 1 As shown, the method mainly includes the following steps:

[0028] Step S1: Analyze and abstract the current problem to determine that the characteristics of the query data are tables scattered across different databases.

[0029] Currently, the company has multiple systems with built-in workflow engines running different workflow definitions. These workflow engines include those developed by vendors, those based on open-source technologies, and those developed by different teams within the company based on open-source technologies. Although the query lists of each workflow engine are largely the same, because these workflows are scattered across different departments and systems, users need to log in to different systems to query and process them, which greatly affects the user experience and processing efficiency. To achieve a unified process center, the initial design was to unify the workflow operation entry points of various systems by adding different query components within the portal system.

[0030] While this approach unifies the entry point for workflow operations, it doesn't fundamentally merge the workflows of different systems. The number of query lists continues to increase with the addition of workflow engines. Furthermore, the uncertainty of workflow permissions and quantities for different users across different systems significantly increases the difficulty of adapting the front-end page. Merging components can partially address these front-end issues. This approach solves the front-end page expansion problem, but it still doesn't reduce the number of query lists, and the user experience remains largely unimproved.

[0031] The goal of this application is to achieve unified querying across workflow engines using a single list, minimizing the number of query lists while supporting adaptive front-end pages. Furthermore, it can serve as a universal solution for continuous integration with various system workflow engines without requiring changes to the front-end. Therefore, the overall implementation approach treats each system and workflow engine as a completely equal backend data source. A unified process center module is added between users and each system to merge the query lists from each system's workflow engines, while also supporting paginated queries under a unified sorting rule. A schematic diagram of the unified process center setup in this application is shown below. Figure 2 As shown.

[0032] In this embodiment, through analysis of the current problem, it is determined that the characteristics of the queried data are: the data is scattered across different tables in different databases, with different table structures and data storage methods; some databases contain data for different users, while others do not; some data can be obtained directly through database queries, while others can only be obtained through API queries. Although the data distribution is completely irregular, they can all be uniformly regarded as different data sources. Therefore, the essence of the problem is determined to be database sharding and table partitioning queries due to inconsistent data models and irregular data distribution. Due to the large amount of data, pagination queries also need to be supported.

[0033] Step S2: Design a query algorithm based on the abstract problem; wherein the query algorithm includes a global query algorithm and a three-dimensional query algorithm.

[0034] In this embodiment of the application, in order to fully guarantee performance and control complexity, based on the characteristics of pagination query, when the query page number is small, because the final result set data volume is small, the simplest way is to query all workflow engines once, summarize the results, sort them uniformly, and obtain the result set, that is, to use a global query algorithm.

[0035] In this embodiment, the global query algorithm includes: querying each data source separately (since the data distribution is irregular and the result set is uncertain about which data source it belongs to, each time it is necessary to query data up to the maximum page number * page size starting from the first page to ensure the accuracy of the query in extreme cases, such as when the result set falls into a single data source); merging, sorting, and truncating the query results (merging the query results and sorting them uniformly, then truncating them according to the pagination rules to obtain the final result set).

[0036] Example diagram of global query algorithm as follows Figure 3 As shown, suppose the query retrieves 24 sorted positive integers, namely [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24]. Assuming a page size of 3, if you need to query the second page of data, you would return [4, 5, 6]. If it's a single data source, you can simply use `limt 3offset 3`. Assuming there are 3 data sources randomly distributing the 24 positive integers, as shown in the table below:

[0037]

[0038] For ease of understanding, the data from each data source has been sorted. Since it is impossible to determine which data source the result set will fall into, and considering various extreme cases, such as a data source having no value or insufficient value, or the result falling into only one data source, we need to start from the first page and query the data with a maximum of page size * page number, i.e., limit 6offset0, to get the sorted result set [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, 18, 21]. Then, we retrieve the data from the second page, which is [4, 5, 6].

[0039] The advantages of this algorithm are simple querying and accurate data. The disadvantages are that each data source returns more data, and the data volume increases exponentially with increasing page numbers, leading to a sharp drop in performance. Therefore, it is suitable for situations with small page numbers, such as querying the first page. To address this issue, a three-query algorithm was developed to solve the performance and query accuracy problems when page numbers are large.

[0040] In this embodiment, the three-query algorithm includes: calculating the average database offset and querying the total amount of data in each data source; traversing each data source and marking the actual and redundant database offsets in each data source; accumulating the redundant database offsets and calculating the average redundant database offset; distributing the average redundant database offset to non-redundant data sources to obtain the final offset of each data source; querying each data source based on the page size and the final database offset; calculating the maximum and minimum values ​​of the sorting field of the returned results; querying each data source based on the maximum and minimum values; traversing each data source and accumulating the global offset; and merging, sorting, and truncating the query results.

[0041] A diagram of the three-query algorithm is shown below. Figure 4 As shown. To explain how the three-query algorithm is implemented, construct the following scenario, assuming a total of 25 positive integers, i.e., [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26]. Assuming a page size of 4, querying the data for page 5, i.e., returning [17, 18, 19, 20], the query results for a single data source are shown in the table below:

[0042]

[0043] At this point, we define a concept called "global offset," which is the offset after all data is aggregated. Here, it is the global offset's page size * (page number - 1) = 16. Note: The offset is calculated starting from 0.

[0044] Assuming the data is randomly distributed across N data sources, to illustrate how to obtain the same result set, we define another concept: "database sharding offset," which is the offset of each data source query. An example is provided below. Assuming the data is evenly distributed and there are 3 data sources, the database sharding offset is the global offset divided by the number of data sources, rounded down. That is, database sharding offset = 16 / 3 = 5. The query results are shown in the table below:

[0045]

[0046] At this point, based on the obtained result set (16-25), after merging and sorting, the result can be extracted from the actual global offset (global offset - sum(database offset), i.e., 16 - (3*5) = 1), resulting in [17, 18, 19, 20]. However, the actual data is irregularly distributed. Three data sources are used to cover various data distribution patterns, with each data source corresponding to a different data distribution, as shown in the table below:

[0047]

[0048] At this point, the database offset is 5. Data source 1 has sufficient data (data volume greater than the database offset, i.e., >5). Data source 2 has data volume less than or equal to the database offset and greater than the page size, i.e., >4 and <=5. Data source 3 has data volume less than or equal to the page size, 4. Specifically:

[0049] (1) Calculate the average database offset assuming sufficient data from each data source. As mentioned above, the value here is 5.

[0050] (2) Query the total amount of data from each data source, i.e., the first query. Because the data is irregularly distributed, it is necessary to adjust the actual offset of each database based on the amount of data from each data source; otherwise, an error of insufficient data from the data source will occur during the second query.

[0051] (3) Traverse each data source and mark the actual database offset and the excess database offset for each data source. If the data source has no data, there is no need to query again, and the excess offset is the database offset 5; if the database offset is greater than or equal to the data volume of the data source, it means that the data volume of the database is insufficient and the database offset needs to be reduced. At this time, continue to judge. If the data volume of the data source is less than or equal to the page size, it means that the query needs to start from the offset 0, that is, data source 3, and the excess database offset is the database offset 5; if the data volume of the data source is greater than the page size and less than or equal to the database offset, that is, data source 2, then the actual database offset is the total number of data pages, that is, 4-3=1, and the excess database offset is the actual database offset = 5-1=4.

[0052] (4) Accumulate the excess database offset. In this example, 5 + 4 = 9.

[0053] (5) Calculate the excess average database offset. Excess database offset / number of data sources with sufficient data (only data source 1), in this example, it is 9 / 1 = 9.

[0054] (6) The excess database offset is evenly distributed among data sources with sufficient data to obtain the final offset of each data source. In this example, data source 1 is 5 + 9 = 14, data source 2 is 1, and data source 3 is 0.

[0055] (7) Perform a second query based on the page size and database offset, resulting in the area marked in light gray in the diagram. Because there is an error in calculating the average database offset, the page size here needs to be adjusted to include this error value to prevent insufficient final query results. In this example, it is 4 + (16 - 14 - 1 - 0) = 5. The query results are shown in the table below:

[0056]

[0057] (8) Obtain the maximum and minimum values ​​in the result set of the second query. That is, the minimum value is 6 and the maximum value is 25.

[0058] (9) Perform a third query based on the maximum and minimum values. To prevent returning too much data, limit the number of records returned to a maximum of page size * page number, i.e., a maximum of 20 records. The query results are shown in the table below:

[0059]

[0060] (10) Sum the final offsets of each database shard to obtain the global final offset and the offset of each database shard. The final offset of each database shard is the database offset minus the amount of data that the third query added compared to the minimum value of the second query, i.e., 10 more records were added to data source 1 (marked in dark gray), so the actual final offset is 14 - 10 = 4. Data source 2 and data source 3 did not increase, so their actual final offsets are 1 and 0 respectively. The global final offset = 4 + 1 + 0 = 5.

[0061] (11) Merge, sort, and truncate the query results to obtain [6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]. Since the global offset is 16 and the actual offset of the result set is 5, we start truncating the data of the page size from 16-5=11 to obtain the final result, which is [17, 18, 19, 20].

[0062] Step S3: Determine the query list type and general query conditions, and unify the result set model and arrangement rules.

[0063] In this embodiment, by analyzing the current status of workflow display lists in various systems, the unified workflow center is determined to mainly include the following five query types: 1. Pending Workflows: These are workflow tasks to be processed, including approval tasks, submission tasks, forwarding tasks, copy tasks, transfer tasks, and proxy tasks, etc., returned as a list by task. 2. Completed Workflows: These are all workflows processed by the user, including non-countersigning tasks and various pending tasks. When a workflow instance corresponds to multiple tasks, the most recently processed task is retrieved, and the query is performed by workflow instance. 3. Completed Workflows: These are all archived workflows processed by the user, including non-countersigning tasks and various pending tasks, queried by workflow instance. 4. Workflows Initiated by the User: These are all workflows initiated by the user, queried by workflow instance. 5. All Workflows: These are all workflows the user has participated in, including pending workflows and completed workflows, queried by workflow instance.

[0064] In this embodiment of the application, by analyzing the design and application of the workflow engines of various systems, common query conditions were extracted, as shown in the table below:

[0065]

[0066] Table 1, the general query condition table, standardizes the result set model for all queries, as shown in the table below.

[0067] flowld String Process definition unique identifier instanceld String Unique identifier for process instance taskld String Unique Task Identifier type String Process engine types, such as BPM, OA, ITSM, ETSM, etc. title String Process Title currentNode String The current node name in the process, multiple nodes separated by commas. currentOperator String The current operator in the process, multiple operators separated by commas. Creator String Process creator's name createTime String Process creation time receiveTime String Task Receive Time operationTime String Task operation time inteval String Sort time fields digitized, for example, converted to UNIX timestamps.

[0068] Table 2 Result Set Model

[0069] A unified sorting rule was established for paginated queries: for different queries, the sorting time field is digitized, for example, converted to a UNIX timestamp, and then uniformly sorted in descending order (the larger the number, the more recent the time). Furthermore, different categories were defined for different query lists: the sorting time field for pending processes is the task creation time; for completed processes, it is the time of the most recent operation on the process instance; for finished processes, it is the process archiving time; and for all processes and those initiated by me, it is the process initiation time.

[0070] Step S4: Based on the query algorithm and the current problem, construct a unified process center.

[0071] In this embodiment, the query conditions are parsed; if the query condition is a single process engine query, then the corresponding process engine pagination query is performed and the result is returned; if the query condition is not a single process engine query but a homepage query, the number of each process engine instance is queried in parallel. If a single engine has data, then the corresponding process engine pagination query is performed and the result is returned; otherwise, a global query algorithm is used to perform the query and the result is returned; if the query condition is not a homepage query, then a three-query algorithm is executed, starting with the first query; if a single engine has data, then the corresponding process engine pagination query is performed and the result is returned; otherwise, a second and third query are performed and the result is returned. Specifically, the implementation process diagram of the unified process center is as follows. Figure 5 As shown.

[0072] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0073] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0074] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for implementing a unified process center, characterized in that, The method includes the following steps: Step S1: Analyze and abstract the current problem to determine that the characteristics of the query data are tables scattered across different databases; Step S2: Design a query algorithm based on the abstract problem; wherein, the query algorithm includes a global query algorithm and a three-stage query algorithm; the three-stage query algorithm includes: calculating the average database offset; querying the total amount of data in each data source; traversing each data source, marking the actual database offset and redundant database offset of each data source; accumulating the redundant database offset; calculating the redundant average database offset; distributing the redundant average database offset to the non-redundant data sources, thereby obtaining the final offset of each data source; querying each data source according to the page size and the final database offset; calculating the maximum and minimum values ​​of the sorting field of the returned results; querying each data source according to the maximum and minimum values ​​of the sorting field; traversing each data source and accumulating to obtain the global offset; merging, sorting, and truncating the query results; Step S3: Determine the query list type and general query conditions, and unify the result set model and sorting rules; Step S4: Based on the query algorithm and the current problem, construct a unified process center, specifically: parse the query conditions; determine if the query condition is a single process engine query, and if so, directly perform a paginated query on the corresponding process engine and return the result; determine if the query condition is not a single process engine query and is a homepage query, query the number of instances of each process engine in parallel, and if a single engine has data, directly perform a paginated query on the corresponding process engine and return the result; otherwise, perform a query based on the global query algorithm and return the result; determine if the query condition is not a single process engine query and is not a homepage query, then execute a three-step query algorithm: start the first query, determine if a single engine has data, and if so, directly perform a paginated query on the corresponding process engine and return the result; otherwise, execute the second and third queries and return the result.

2. The method for implementing a unified process center according to claim 1, characterized in that, The global query algorithm includes: Query each data source separately; Merge, sort, and truncate the results of each query.

3. The method for implementing a unified process center according to claim 1, characterized in that, The query list types include: pending processes, completed processes, finished processes, user-initiated processes, and all processes.

4. The method for implementing a unified process center according to claim 1, characterized in that, The general query conditions include: current user unique identifier, process title, process engine type, process creator unique identifier, creator's unique department identifier, start time of initiation, end time of initiation, unique process definition identifier, and unique process instance identifier.

5. The method for implementing a unified process center according to claim 1, characterized in that, The unified result set model includes: unique process definition identifier, unique process instance identifier, unique process task identifier, process engine type, process title, current process node, current process operator, unique identifier of process creator, process creation time, task receipt time, task operation time, and sorting field value.

6. The method for implementing a unified process center according to claim 1, characterized in that, The sorting rule is to digitize the sorting time field, specifically by converting the time into a unique UNIX timestamp.

Images