RPA method fusing service function

Abstract

The invention relates to the technical field of data processing, and discloses an RPA method fusing a service function, which comprises the following steps: extracting a service semantic association relationship between tasks based on a task topological structure; dividing the task into a real-time response task and a periodic summarization task according to a business semantic association relationship, and identifying an asynchronous task containing external data interaction waiting; determining a starting constraint rule set of a subsequent task corresponding to the real-time response task in combination with historical execution node information of the real-time response task; determining a scheduling trigger condition of the asynchronous task by using the data availability prediction model; determining a data dependency relationship between the subsequent task and the asynchronous task, and adjusting a task scheduling sequence in combination with a starting constraint rule of the subsequent task and a scheduling trigger condition of the asynchronous task; according to the method, accurate dynamic scheduling of the RPA task based on business semantics and data availability is realized, and the task execution stability and the scheduling efficiency are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically, to a method of RPA that integrates business functions. Background Technology

[0002] With the accelerated advancement of enterprise digital transformation, various industries are gradually introducing Robotic Process Automation (RPA) technology to achieve intelligent and automated operation of business processes. However, in practical applications, it has been found that current RPA solutions are generally based on static configuration or simple task triggering order to organize task execution sequences, lacking in-depth exploration of the inherent logical relationships of business processes and the characteristics of data flow between tasks. Especially when facing complex business scenarios such as real-time response tasks, periodic summary tasks, and asynchronous data arrival, it is easy to generate timing deviations between the task scheduling order and the actual data generation, leading to task execution delays or even failures, reducing the stability and execution efficiency of automated processes.

[0003] Furthermore, existing technologies fail to effectively utilize the vast amounts of operational data accumulated from historical business systems to identify and construct accurate task topology relationships. They also lack dynamic methods for predicting task data availability, making it difficult for task scheduling strategies to dynamically adapt to actual business operational needs. This results in situations where subsequent tasks are started blindly before data is fully prepared, or task execution nodes remain idle while waiting for data to arrive. Therefore, existing RPA process scheduling solutions urgently need a more intelligent dynamic scheduling method. This method should deeply analyze the true business semantics and data dependencies between tasks, accurately predict the actual arrival time of asynchronous data, and dynamically adjust the task startup order to effectively improve the adaptability and operational efficiency of RPA systems in complex business scenarios. Summary of the Invention

[0004] To overcome the above-mentioned deficiencies of the prior art, embodiments of the present invention provide an RPA method that integrates business functions.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A method for integrating business functions in RPA, the method comprising:

[0007] A task topology is constructed based on the historical task execution logs of the business system, and the business semantic relationships between tasks are extracted based on the task topology.

[0008] Based on the business semantic relationship, tasks are divided into real-time response tasks and periodic summary tasks, and asynchronous tasks that include external data interaction waiting are identified; the set of start constraint rules for the corresponding subsequent tasks is determined by combining the historical execution node information of the real-time response tasks.

[0009] A data availability prediction model is established based on the generation pattern of the historical data of the asynchronous task, and the scheduling triggering conditions of the asynchronous task are determined using the data availability prediction model.

[0010] The data dependency between the subsequent task and the asynchronous task is determined, and the task scheduling order is adjusted in combination with the start constraint rules of the subsequent task and the scheduling trigger conditions of the asynchronous task to eliminate the timing deviation between the generation of asynchronous business data and the task execution node.

[0011] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0012] This invention constructs a task topology based on historical task execution logs and divides real-time response tasks and periodic summary tasks based on business semantic relationships. It deeply explores the real business connections between tasks, breaking through the limitations of existing RPA scheduling that statically configures task sequences based solely on time order. This makes task scheduling more in line with actual business needs and improves the stability and accuracy of process execution.

[0013] This invention constructs an asynchronous task data availability prediction model, which can accurately predict the actual arrival time of asynchronous data. This avoids the situation in traditional scheduling schemes where tasks wait or start blindly before data arrives due to asynchronous data arrival, thereby effectively reducing task execution delays and significantly improving task scheduling efficiency and the reliability of automated execution.

[0014] This invention dynamically adjusts the task scheduling order by combining task initiation constraint rules and asynchronous task scheduling trigger conditions, effectively eliminating the timing deviation between task execution nodes and data generation, realizing adaptive scheduling of RPA processes, and further improving the smoothness of system operation and the real-time response capability of business processing. Attached Figure Description

[0015] Figure 1 The flowchart illustrates an RPA method for integrating business functions provided by this invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Example 1

[0018] Please see Figure 1As shown in the figure, this embodiment discloses a method for RPA that integrates business functions, the method including:

[0019] S101: Construct a task topology structure based on the historical task execution logs of the business system, and extract the business semantic relationships between tasks based on the task topology structure;

[0020] In practice, this process is used to extract real business relationships between tasks from long-running business systems, rather than forming a linear sequential relationship based solely on task triggering time. Its core lies in the structured modeling of the relationship between "task-data-business semantics".

[0021] Specifically, the step of constructing the task topology structure based on the historical task execution logs of the business system includes:

[0022] Extract the task identifier, task start and end time, task data source, and task data destination from the historical task execution log of the business system;

[0023] It should be understood that the historical task execution logs are a collection of structured log data generated by the business system during automated operation, and this log data contains at least the following four types of information:

[0024] First, there is the task identifier, which uniquely identifies a business task instance that can be scheduled and executed by RPA. The task identifier corresponds one-to-one with a specific business function, such as account information query, asset freezing, case review, approval and signing.

[0025] Second, the task execution start and end time, which describes the actual execution interval of the task in the business system. This information is used to reflect the relative execution order and potential concurrency relationships between tasks.

[0026] Third, the task data source, which describes the data input source that the current task depends on during execution. This source is a specific upstream task identifier or an external system interface identifier.

[0027] Fourth is the destination of task data, which describes the target to which the data generated after the current task is completed is transmitted. This target is a specific downstream task identifier or an external system interface identifier.

[0028] It is understandable that the source and destination of task data together constitute the data flow relationship within the business system, used to depict whether there is a real data dependency between tasks, rather than just a temporal adjacency relationship.

[0029] Based on the source and destination of the task data, an initial task topology graph is constructed with the task identifier as the node and the data flow direction as the directed connection relationship.

[0030] Specifically, each extracted task identifier is mapped to a node in the task topology graph, and the transmission relationship of task data from source to destination is mapped to a directed connection relationship between nodes.

[0031] It should be understood that if the data source of a task is the task identifier of another task, a directed connection is established in the topology graph from the data source task to the current task; if the data source is an external system interface, the interface is regarded as a boundary node in the topology graph, which is only used to describe the direction of data entering or leaving the system and does not participate in subsequent task semantic clustering.

[0032] For example, in the court's business system, if the data destination of the account information query task is the asset freezing task, then a directed connection relationship of "account information query task → asset freezing task" is formed in the initial task topology graph; if the data destination of the case review task is the case approval and signing task, then a directed connection relationship of "case review task → case approval and signing task" is formed.

[0033] In this way, an initial task topology map that reflects the historical data flow relationship is formed.

[0034] Based on the task identifier and its data flow relationship, the redundant connection relationship in the initial task topology graph is eliminated to obtain a simplified task topology graph.

[0035] It should be noted that, due to the possibility of duplicate records, parallel writes, or system backfilling in the historical logs, the initial task topology graph may contain both direct connections and indirect connections formed through intermediate tasks. Such direct connections do not have independent meaning at the business semantic level and therefore need to be resolved.

[0036] The process of eliminating redundant connections in the initial task topology graph based on the task identifier and its data flow relationship includes:

[0037] Calculate the length of the indirect connection path formed between task nodes through multi-level data flow;

[0038] Specifically, the indirect connection path length is defined as the number of intermediate task nodes contained in the path from the starting task node to the target task node, and the path contains at least one intermediate task node.

[0039] It is understandable that when task A points to task B and task B points to task C, an indirect connection path is formed between task A and task C, and the path length is 1.

[0040] If a task node has both a direct data flow connection and an indirect connection path with the same direction, delete the direct data flow connection.

[0041] Specifically, when there is a direct connection between task node A and task node C, and there is also a directed path from task node A to task node C via one or more intermediate task nodes, and the data flow direction of the two paths is consistent, the direct connection between task node A and task node C is deleted, and only the indirect connection path is retained.

[0042] For example, if the initial task topology graph contains both "account information query task → asset freeze task" and "account information query task → intermediate task → asset freeze task", then delete the former and keep the latter.

[0043] Perform connectivity verification on the task topology graph after deleting the direct data flow connection, and output the task topology graph where redundant connection relationships have been resolved.

[0044] Specifically, connectivity verification is used to check whether the original data reachability relationships still hold after the deletion of direct connections. If it is still possible to reach the target task node that is reachable in the initial task topology graph from any task node along the existing directed connections, then connectivity is considered to be maintained and the deletion operation takes effect; if there is an unreachable situation, the corresponding deletion operation is revoked.

[0045] Semantic similarity clustering is performed on the task nodes on the structurally reduced task topology graph to generate a semantic topology structure that represents the business semantic relationship.

[0046] In practice, the task nodes in the simplified task topology graph are clustered at the business semantic level to extract the business semantic relationships between tasks.

[0047] Specifically, the first step is to extract the business function description text corresponding to each task node. This text comes from the definition information of the task function in the business system and is used to describe the specific business behavior undertaken by the task in the business process.

[0048] Subsequently, the business function description text is semantically vectorized to obtain the semantic feature vectors corresponding to the task nodes. These semantic vectors are used to characterize the positional relationship of tasks within the business semantic space.

[0049] Furthermore, based on the similarity calculation results of the semantic feature vectors between task nodes, task nodes whose similarity meets the preset clustering conditions are grouped into the same semantic cluster. These clustering conditions are given in the form of numerical thresholds to limit the degree of semantic similarity, and the thresholds are fixed before implementation.

[0050] Finally, the original single task node is replaced by a set of tasks after semantic clustering, and a semantic topology structure with semantic clustering nodes as the basic unit is constructed based on the data flow relationship in the task topology graph after structural reduction, so as to represent the relationship between tasks at the business level.

[0051] S102: Based on the business semantic relationship, the tasks are divided into real-time response tasks and periodic summary tasks, and asynchronous tasks containing external data interaction waiting are identified; the set of start constraint rules for the corresponding subsequent tasks is determined by combining the historical execution node information of the real-time response tasks.

[0052] In practical implementation, this section is used to functionally differentiate the task operation characteristics based on the obtained business semantic associations, and further form startup constraint rules that can be directly executed by the scheduling system, so that subsequent scheduling no longer depends on manual configuration or static rules.

[0053] Specifically, the step of determining the set of start-up constraint rules for the corresponding subsequent tasks by combining the historical execution node information of the real-time response task includes:

[0054] Extract the start timestamp of the real-time response task and the running status of the corresponding execution node from the historical task execution log;

[0055] It should be noted that real-time response tasks refer to task types that have a close causal relationship with preceding tasks in terms of business semantics, and enter the executable state immediately after the preceding task is completed. These tasks do not depend on a fixed time window for triggering. Periodic summary tasks refer to task types that are aimed at statistics, summarization, approval, and archiving in terms of business semantics, and are triggered at a preset time point. Asynchronous tasks refer to task types whose execution depends on data returned by external systems, and the return time of this data has historically exhibited a non-fixed distribution characteristic.

[0056] In some specific embodiments, task type classification is accomplished using the following rules:

[0057] If, in the historical execution record, the time difference between the start time and the completion time of the preceding task is concentrated across multiple execution cycles and is not bound to a fixed time point, then the task is marked as a real-time response task.

[0058] If the start times of a task in the historical execution record are concentrated at the same time point within the same day or week, then the task is marked as a periodic summary task.

[0059] If a task's start time in the historical execution record is always later than the arrival time of certain external data, and that external data originates from an external system interface, then the task is marked as an asynchronous task.

[0060] Based on this, the start timestamp of the real-time response task and its corresponding execution node running status are extracted from the historical task execution log. The execution node running status is used to characterize whether the computing node carrying the task is in a schedulable state when the task starts. The running status includes at least two values: "executable state" and "occupied state".

[0061] Based on the startup timestamp and the running status of the execution node, construct a node dependency matrix between the real-time response task execution node and the subsequent task startup node;

[0062] Understandably, the node dependency matrix is ​​used to describe the stable startup relationship formed between real-time response tasks and their subsequent tasks during historical operation. In essence, it is a startup dependency modeling result with execution nodes as the dimension.

[0063] The process of constructing a node dependency matrix between the real-time response task execution node and the subsequent task initiation node includes:

[0064] Extract all start timestamp pairs of the real-time response task and the corresponding subsequent task during the historical execution process;

[0065] Specifically, for each pair of real-time response tasks and subsequent tasks that have a business semantic relationship, the start timestamp pair within the same business process instance is extracted from the historical task execution log. This timestamp pair consists of the start timestamp of the real-time response task and the start timestamp of the subsequent task.

[0066] For example, in the court's business system, if the account information query task and the asset freezing task appear multiple times in the same case processing flow, then a set of start timestamp pairs will be formed in each case process for subsequent statistical analysis.

[0067] The startup time offset relationship between the real-time response task and the subsequent tasks is calculated based on the startup timestamp.

[0068] Specifically, the startup time offset relationship is obtained by calculating the time difference for each pair of startup timestamps. This time difference is the startup timestamp of the subsequent task minus the startup timestamp of the real-time response task. The result is a positive value, which is used to characterize the startup lag of the subsequent task relative to the real-time response task.

[0069] In some specific embodiments, the start time offset results of the same pair of tasks in multiple historical processes are aggregated to form a set of start time offset samples, which are used to reflect the historical start pattern of the task.

[0070] Based on the startup time offset relationship and the running state of the execution node, a node dependency matrix is ​​formed to describe the startup dependencies of the task nodes;

[0071] Specifically, the node dependency matrix uses the real-time response task execution node as the row index and the subsequent task initiation node as the column index. Each element in the matrix is ​​used to represent whether the initiation of the subsequent task depends on the completion of the real-time response task and whether the corresponding execution node is in an executable state under the corresponding node combination.

[0072] In some specific embodiments, the matrix elements are determined by the following three types of information:

[0073] First, the concentrated interval of historical start-up time offset samples;

[0074] Second, it provides real-time feedback on the distribution of the running status of task execution nodes at startup.

[0075] Third, is there a record in the historical process of whether subsequent tasks were attempted to be started without waiting for the completion of the preceding tasks?

[0076] If the historical record shows that a subsequent task is only started when the real-time response task is completed and its execution node is in an executable state, then it is marked as having a startup dependency in the node dependency matrix; if the historical record shows that the constraint does not exist, then it is marked as not having a startup dependency.

[0077] Based on the node dependency matrix, identify the start order conditions of the subsequent tasks and the running status conditions of the preceding nodes, and generate a set of start constraint rules for the subsequent tasks.

[0078] Specifically, for task combinations marked as having startup dependencies in the node dependency matrix, the corresponding startup order conditions and node running state conditions are extracted as startup constraint rules for subsequent tasks.

[0079] The startup order condition is used to limit subsequent tasks to only be allowed to enter the scheduling candidate queue after the corresponding real-time response task is completed; the node running status condition is used to limit the execution node of the corresponding real-time response task to be in an executable state when a subsequent task is started.

[0080] In one specific embodiment, the generated startup constraint rules for the asset freezing task include:

[0081] The asset freeze task can only be initiated after the account information query task has been completed.

[0082] The asset freeze task can only be initiated if the execution node where the account information query task is located is in an executable state.

[0083] S103: Establish a data availability prediction model based on the generation pattern of the asynchronous task's historical data, and use the data availability prediction model to determine the scheduling triggering conditions of the asynchronous task;

[0084] Specifically, this section addresses the issue of inconsistent data availability times for asynchronous tasks by analyzing and predicting historical data arrival times to achieve precise scheduling.

[0085] Specifically, a data availability prediction model is established based on the generation patterns of the historical data of the asynchronous tasks, including:

[0086] Extract the generation time and corresponding task start execution time of the asynchronous task's historical data;

[0087] It should be understood that the asynchronous task is a task that needs to wait for specific data to be returned from an external system during execution, and the arrival time of this data is not fixed. The generation time of historical data refers to the specific point in time when the data from the external system actually arrives at the business system; the start execution time of the corresponding task refers to the specific point in time when the asynchronous task actually starts execution in the historical record.

[0088] For example, in the court's business system, the task of receiving bank account data feedback is a typical asynchronous task, and its historical records are shown in Table 1 below:

[0089] Table 1: Example Table of Asynchronous Task Historical Data

[0090] Data generation date Data generation time Task start execution time 2024-01-10 09:30:15 09:31:00 2024-01-11 09:45:20 09:46:05 2024-01-12 09:40:30 09:41:10

[0091] The above data extraction process generates the historical timestamp data required for subsequent model training.

[0092] Calculate the temporal distribution relationship between the time of business data generation and the time of corresponding task execution, and obtain the historical temporal feature sequence between data generation and task execution;

[0093] The calculation of the temporal distribution relationship between the time of business data generation and the time of corresponding task execution includes:

[0094] Obtain the time difference sequence between the time of generation of the asynchronous task business data and the time of start execution of the corresponding task within each historical task execution cycle;

[0095] Specifically, each element in the above time difference sequence is obtained through the following calculation:

[0096] Time difference (seconds) = Task start execution time - Data generation time

[0097] For example, based on the historical data of the aforementioned court business system, the time difference sequence is as follows:

[0098] First time: 09:31:00 − 09:30:15 = 45 seconds;

[0099] Second time: 09:46:05 − 09:45:20 = 45 seconds;

[0100] Third time: 09:41:10 − 09:40:30 = 40 seconds.

[0101] The probability density distribution of the time difference sequence is calculated using a kernel density estimation algorithm to generate probability density curves for business data generation and task execution.

[0102] Specifically, the kernel density estimation (KDE) algorithm uses a Gaussian kernel function, and the specific calculation formula is as follows:

[0103]

[0104] In the formula: 𝑥 represents the specific time difference to be estimated; The specific value n in the historical time difference sequence is the total number of historical samples (e.g., n=3); h is the kernel density estimation bandwidth parameter, for example, set to 5 seconds.

[0105] It is understandable that the value of the bandwidth parameter h directly affects the smoothness of the probability density curve. The smaller the value of h, the closer the curve is to the original data distribution characteristics.

[0106] Extract the statistical features of the probability density curve to form the historical time-series feature sequence between the time when the business data is generated and the time when the task is started and executed;

[0107] Specifically, the statistical characteristics include the following:

[0108] Mean: Represents the average waiting time of historical time difference series values;

[0109] Median: Represents the waiting time at the center of the historical time difference sequence after numerical sorting;

[0110] Variance: Used to describe the degree of fluctuation in historical waiting time;

[0111] Peak position: The specific time difference where the probability density value is the largest on the probability density curve, representing the most frequent waiting time in history.

[0112] For example, the specific statistical characteristics of the historical data calculated by the above-mentioned court business system are as follows: mean: 43.3 seconds, median: 45 seconds, variance: 5.56 seconds², peak position: 45 seconds.

[0113] The above four statistical features form a historical time series feature sequence, providing a unified input format for the model.

[0114] The historical time-series feature sequence is input into a long short-term memory network for training, and the output is the data availability prediction model used to describe the generation rules of business data.

[0115] Specifically, the Long Short-Term Memory (LSTM) network used in this embodiment has the following parameter configuration:

[0116] Number of input layer neurons: 4 (corresponding to four features: mean, median, variance, and peak position); Number of hidden layers: 2; Number of hidden neurons per layer: 32; Activation function: tanh function; Number of output layer neurons: 1 (specifically for predicting the actual available waiting time of asynchronous data); Optimizer: Adam algorithm; Loss function: Mean Squared Error (MSE), with a target of less than 1 second².

[0117] It is understandable that each historical sample input to the model is a sequence of historical time-series features, and the label of the sample is the actual waiting time of the asynchronous task in that historical record. The training process stops when the loss function is less than the above objective.

[0118] For example, using the aforementioned historical data from the court's business system as the training set, the specific input and output examples are as follows:

[0119] Input: [43.3 seconds (mean), 45 seconds (median), 5.56 seconds² (variance), 45 seconds (peak position)];

[0120] Output: [Actual waiting time, e.g., 45 seconds].

[0121] After the model is trained, before each subsequent asynchronous task is started, the model is input based on the current historical time series feature sequence, and the model outputs the specific waiting time for the predicted asynchronous task data, which is used to determine the actual available time of the data.

[0122] S104: Determine the data dependency relationship between the subsequent task and the asynchronous task, and adjust the task scheduling order in combination with the start constraint rules of the subsequent task and the scheduling trigger conditions of the asynchronous task to eliminate the timing deviation between the asynchronous business data generation and the task execution node.

[0123] Specifically, this implementation ensures that the data required for subsequent task startup is complete and available, thereby preventing task execution failure due to incomplete data.

[0124] Specifically, adjusting the task scheduling order by combining the startup constraint rules of the subsequent tasks and the scheduling trigger conditions of the asynchronous tasks includes:

[0125] Extract asynchronous task nodes and subsequent task nodes from the current task scheduling order, and verify the data dependency relationship between them based on the business semantic association relationship;

[0126] It is understandable that data dependency specifically refers to the situation where subsequent task startup and execution require data output from asynchronous tasks as input. The specific criteria for judgment are:

[0127] When subsequent tasks consistently need to wait for and use data generated by asynchronous tasks throughout the historical execution process, confirm that a data dependency exists.

[0128] If subsequent tasks start and execute without using data from asynchronous tasks, it is confirmed that there is no data dependency.

[0129] For example, in the court's business system, the "asset freezing task" is a subsequent task, while the "bank feedback account data task" is an asynchronous task. Since the asset freezing task always needs to wait for and use the account data fed back by the bank before it can be started, it is determined that there is a data dependency between the two.

[0130] Based on the data dependencies, the startup constraints of the subsequent tasks, and the scheduling triggering conditions of the asynchronous tasks, identify the initial scheduling sequence that has the risk of timing deviation.

[0131] The identification of initial scheduling sequences with potential timing deviation risks includes:

[0132] Establish a timing constraint matrix for task execution for the asynchronous task and the subsequent task;

[0133] Specifically, each element in the timing constraint matrix is ​​determined by the historical time difference between the actual arrival time of the asynchronous task data and the actual start time of the subsequent task, where each element records the historical time difference value of the task pair in a specific execution instance.

[0134] For example, the historical data of the court's business system is shown in Table 2 below:

[0135] Table 2: Example of Historical Data from the Court Business System

[0136] Asynchronous task data arrival time Subsequent mission start time Time difference (seconds) 09:30:00 09:32:00 120 10:00:00 10:01:30 90

[0137] The above data forms a time series constraint matrix (as shown in Table 3 below):

[0138] Table 3: Example Table of Temporal Constraint Matrices

[0139] Asynchronous tasks Follow-up tasks The shortest time difference in history (seconds) The longest time difference in history (seconds) Bank feedback account data task asset freezing task 90 120

[0140] .

[0141] Based on the timing constraint matrix, potential time-conflicting task pairs that satisfy the startup constraint rules but do not satisfy the scheduling triggering conditions are identified.

[0142] Specifically, the logic for determining the potentially time-conflicting task pair is as follows:

[0143] If the start constraint rules of subsequent tasks are met, but the asynchronous task data has not yet arrived or is not yet fully available according to the prediction results of the data availability prediction model, this situation is marked as a potential timing conflict.

[0144] For example, the starting constraint rule for the asset freezing task in the court's business system is "starting 70 seconds after the completion of the account information query task". However, the data availability prediction model predicts that the actual data availability time for the bank's feedback account data task is 120 seconds after the completion of the account information query task. Therefore, between 70 seconds and 120 seconds, although the starting condition for the asset freezing task is met, the data is not yet available, thus creating a potential timing conflict.

[0145] Extract all the potential time-conflicting task pairs, construct a time-conflicting task set, and determine the initial task scheduling sequence containing the set as the initial scheduling sequence with the risk of time deviation.

[0146] Specifically, in this initial scheduling sequence, any task pairs identified as having potential timing conflicts will be explicitly marked as having a risk of timing deviation and will require special attention during scheduling.

[0147] For example, the initial scheduling sequence of the court's business system determines that the set of tasks with time-series conflicts includes a set of task pairs (bank feedback account data task, asset freezing task), and the specific initial task scheduling sequence is shown in Table 4 below:

[0148] Table 4: Example Table of Initial Task Scheduling Sequences

[0149] Task order Task Name Is there a risk of timing deviation? 1 Account information query task no 2 asset freezing task Yes (there is a risk of deviation).

[0150] .

[0151] The initial scheduling sequence is adjusted using a local topology sorting algorithm, and the task scheduling sequence after local topology rearrangement is output.

[0152] Specifically, this operation is used to eliminate potential timing conflicts identified in the initial scheduling sequence, thereby ensuring that task initiation and data generation are perfectly synchronized. The implementation of the local topology sorting algorithm includes the following specific operations:

[0153] Based on the actual availability time of asynchronous task data output by the data availability prediction model, the specific start time of subsequent tasks is adjusted.

[0154] Specifically, by using a data availability prediction model to predict the actual time when asynchronous task data is ready, the start time of subsequent tasks, which was originally determined based on start constraint rules, is adjusted to the specific time after the asynchronous task data is fully available.

[0155] For example, in a court business system:

[0156] The original plan for the asset freeze task was to start the process "immediately 70 seconds after the account information query task is completed";

[0157] The data availability prediction model predicts that the actual time when the bank's account data will be available is: "120 seconds after the account information query task is completed";

[0158] Therefore, the start time of the asset freeze task was adjusted from the original 70 seconds to 120 seconds to ensure that the account data required for the asset freeze task to start is complete and available.

[0159] Update the startup order relationship between tasks based on the adjusted startup times of subsequent tasks as described above.

[0160] Specifically, based on the specific adjustments made at the start times of subsequent tasks, the specific start order of tasks in the entire task scheduling sequence is updated to ensure that the actual order of task start-ups is consistent with data availability requirements.

[0161] For example, the change in the task startup order of the court's business system before and after the adjustment is as follows: The startup order before the adjustment was:

[0162] First: Account information query task completed;

[0163] Second: The asset freeze task will be initiated after 70 seconds (potential conflict exists).

[0164] The adjusted startup order is as follows:

[0165] First: Account information query task completed;

[0166] Second: The asset freeze task will be initiated after 120 seconds (no potential conflicts).

[0167] Output the final task scheduling sequence after local topology sorting.

[0168] Specifically, the final task scheduling sequence explicitly gives the actual start time of each task, so that the subsequent RPA system can directly refer to it when executing task scheduling without secondary manual intervention or correction.

[0169] For example, the adjusted task scheduling sequence of the court's business system is shown in Table 4 below:

[0170] Table 4: Example of Adjusted Task Scheduling Sequence

[0171] Task startup order Task Name actual start time of the task 1 Account information query task 2024-03-01 09:00:00 2 asset freezing task 2024-03-01 09:02:00 (120 seconds later)

[0172] .

[0173] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters, weights, and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0174] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0175] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for integrating business functions in RPA, characterized in that, The method includes: A task topology is constructed based on the historical task execution logs of the business system, and the business semantic relationships between tasks are extracted based on the task topology. Based on the business semantic relationship, tasks are divided into real-time response tasks and periodic summary tasks, and asynchronous tasks that include external data interaction waiting are identified; the set of start constraint rules for the corresponding subsequent tasks is determined by combining the historical execution node information of the real-time response tasks. A data availability prediction model is established based on the generation pattern of the historical data of the asynchronous task, and the scheduling triggering conditions of the asynchronous task are determined using the data availability prediction model. The data dependency between the subsequent task and the asynchronous task is determined, and the task scheduling order is adjusted in combination with the start constraint rules of the subsequent task and the scheduling trigger conditions of the asynchronous task to eliminate the timing deviation between the generation of asynchronous business data and the task execution node.

2. The RPA method for integrating business functions according to claim 1, characterized in that, The step of constructing a task topology structure based on the historical task execution logs of the business system includes: Extract the task identifier, task start and end time, task data source, and task data destination from the historical task execution log of the business system; Based on the source and destination of the task data, an initial task topology graph is constructed with the task identifier as the node and the data flow direction as the directed connection relationship. Based on the task identifier and its data flow relationship, the redundant connection relationship in the initial task topology graph is eliminated to obtain a simplified task topology graph. Semantic similarity clustering is performed on the task nodes on the simplified task topology graph to generate a semantic topology structure that represents the semantic relationship of the business.

3. The RPA method for integrating business functions according to claim 2, characterized in that, in, Based on the task identifier and its data flow relationship, redundant connections in the initial task topology graph are eliminated, including: Calculate the length of the indirect connection path formed between task nodes through multi-level data flow; If a task node has both a direct data flow connection and an indirect connection path with the same direction, delete the direct data flow connection. Perform connectivity verification on the task topology graph after deleting the direct data flow connections, and output a task topology graph where redundant connections have been resolved.

4. The RPA method for integrating business functions according to claim 3, characterized in that, The step of determining the set of start constraint rules for the corresponding subsequent tasks by combining the historical execution node information of the real-time response task includes: Extract the start timestamp of the real-time response task and the running status of the corresponding execution node from the historical task execution log; Based on the startup timestamp and the running status of the execution node, construct a node dependency matrix between the real-time response task execution node and the subsequent task startup node; Based on the node dependency matrix, the startup order conditions of the subsequent tasks and the running status conditions of the preceding nodes are identified, and a set of startup constraint rules for the subsequent tasks is generated.

5. The RPA method for integrating business functions according to claim 4, characterized in that, Constructing a node dependency matrix between the real-time response task execution node and the subsequent task initiation node includes: Extract all start timestamp pairs of the real-time response task and the corresponding subsequent task during the historical execution process; The startup time offset relationship between the real-time response task and the subsequent tasks is calculated based on the startup timestamp. Based on the startup time offset relationship and the running status of the execution node, a node dependency matrix is ​​formed to describe the startup dependencies of the task nodes.

6. The RPA method for integrating business functions according to claim 5, characterized in that, A data availability prediction model is established based on the generation patterns of the historical data of the asynchronous tasks, including: Extract the generation time and corresponding task start execution time of the asynchronous task's historical data; Calculate the temporal distribution relationship between the time of business data generation and the time of corresponding task execution, and obtain the historical temporal feature sequence between data generation and task execution; The historical time-series feature sequence is input into a long short-term memory network for training, and the output is a data availability prediction model that describes the generation pattern of business data.

7. The RPA method for integrating business functions according to claim 6, characterized in that, Calculate the temporal distribution relationship between the time of business data generation and the time of corresponding task startup and execution, including: Obtain the time difference sequence between the time of generation of the asynchronous task business data and the time of start execution of the corresponding task within each historical task execution cycle; The probability density distribution of the time difference sequence is calculated using a kernel density estimation algorithm to generate probability density curves for business data generation and task execution. The statistical features of the probability density curve are extracted to form the historical time-series feature sequence between the time when the business data is generated and the time when the task is started and executed.

8. The RPA method for integrating business functions according to claim 7, characterized in that, Adjusting the task scheduling order by combining the startup constraints of the subsequent tasks and the scheduling trigger conditions of the asynchronous tasks includes: Extract asynchronous task nodes and subsequent task nodes from the current task scheduling order, and verify the data dependency relationship between them based on the business semantic association relationship; Based on the data dependencies, the startup constraints of the subsequent tasks, and the scheduling triggering conditions of the asynchronous tasks, identify the initial scheduling sequence that has the risk of timing deviation. The initial scheduling sequence is adjusted using a local topology sorting algorithm, and the task scheduling sequence after local topology rearrangement is output.

9. The RPA method for integrating business functions according to claim 8, characterized in that, The identification of initial scheduling sequences with timing deviation risks includes: Establish a timing constraint matrix for task execution for the asynchronous task and the subsequent task; Based on the timing constraint matrix, potential time-conflicting task pairs that satisfy the startup constraint rules but do not satisfy the scheduling triggering conditions are identified. Extract all potential time-conflicting task pairs, construct a time-conflicting task set, and determine the initial task scheduling sequence containing the set as the initial scheduling sequence with time deviation risk.

Images