CN112379993A - Robot process automation processing system, method and device - Google Patents
Robot process automation processing system, method and device Download PDFInfo
- Publication number
- CN112379993A CN112379993A CN202011422087.3A CN202011422087A CN112379993A CN 112379993 A CN112379993 A CN 112379993A CN 202011422087 A CN202011422087 A CN 202011422087A CN 112379993 A CN112379993 A CN 112379993A
- Authority
- CN
- China
- Prior art keywords
- subtask
- state code
- state
- execution
- thread
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 125
- 238000012545 processing Methods 0.000 title claims abstract description 43
- 238000004801 process automation Methods 0.000 title claims abstract description 40
- 230000008569 process Effects 0.000 claims description 80
- 238000003860 storage Methods 0.000 claims description 25
- 238000004590 computer program Methods 0.000 claims description 20
- 230000006870 function Effects 0.000 description 15
- 238000003672 processing method Methods 0.000 description 14
- 238000005516 engineering process Methods 0.000 description 10
- 239000003795 chemical substances by application Substances 0.000 description 8
- 230000006872 improvement Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 230000036541 health Effects 0.000 description 4
- 230000007774 longterm Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 241000282414 Homo sapiens Species 0.000 description 2
- 238000013473 artificial intelligence Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000004140 cleaning Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000010801 machine learning Methods 0.000 description 2
- 238000012015 optical character recognition Methods 0.000 description 2
- 230000000750 progressive effect Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- BUGBHKTXTAQXES-UHFFFAOYSA-N Selenium Chemical compound [Se] BUGBHKTXTAQXES-UHFFFAOYSA-N 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000005094 computer simulation Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 229910052711 selenium Inorganic materials 0.000 description 1
- 239000011669 selenium Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The embodiment of the specification provides a robot process automation processing system, method and device. The system comprises a main thread and a daemon thread; the main thread is used for splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; sending the state code to the daemon thread; and the daemon thread is used for receiving the state code sent by the main thread, and running a cleaning program under the condition that the next state code is not received within preset time so as to finish the task execution flow, improve the processing efficiency of the robot flow automation fault and quickly release the invalid occupied resources.
Description
Technical Field
The embodiment of the specification relates to the technical field of computers, in particular to a robot process automation processing system, method and device.
Background
Robotic Process Automation (RPA) is an automated software tool that provides another way to automate a user's manual Process by mimicking the user's manual operation at a computer. In a narrow sense, RPA is a generic term for such technologies or products that achieve process automation through some automated means; broadly speaking, RPA can be considered as a set of automated solutions to solve production problems by computer simulation of manual operations. The RPA has the characteristics of small influence on the existing system of an enterprise, basically no coding, short implementation period, friendliness to non-technical service personnel and the like. The RPA can not only simulate human beings, but also utilize and fuse the prior technologies such as rule engine, optical character recognition, voice recognition, machine learning, artificial intelligence and the like to realize the aim of process automation.
When an RPA process is executed at the robot agent, the RPA robot should successfully execute all processes in an ideal situation when the environment is ready and all software required by the robot has been installed. However, in reality, a certain fault occurs in the machine where the agent end is located, and if the fault cannot be found and processed in time, the RPA robot is stuck in the current step and cannot continue to execute. In current treatment methods, most RPA robots treat by giving each step a timeout. For example, the click button element required in the step is not captured within 10 seconds, that is, the step is judged to be wrong, and a corresponding error handling mechanism is operated.
In the current processing method, control and operation are realized by depending on an interface provided by the technology, and for some cold door technologies, a proper timeout processing mechanism may not be available, and faults cannot be found and processed in time, so that the RPA robot card cannot be continuously executed in the current step.
Disclosure of Invention
An object of the embodiments of the present disclosure is to provide a system, a method, and a device for robot process automation processing, so as to improve the processing efficiency of robot process automation failures and quickly release inefficiently occupied resources.
In order to solve the above problem, an embodiment of the present specification provides a robot process automation processing system, where the system includes a main thread and a daemon thread; the main thread is used for splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; sending the state code to the daemon thread; and the daemon thread is used for receiving the state code sent by the main thread and running a cleaning program under the condition that the next state code is not received within preset time so as to finish the task execution process.
In order to solve the above problem, an embodiment of the present specification further provides a robot process automation processing method, where the method includes: splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
In order to solve the above problem, an embodiment of the present specification further provides a robot process automation processing apparatus, where the apparatus includes: the splitting module is used for splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; the generating module is used for sequentially executing the plurality of subtasks and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and the sending module is used for sending the state code to a daemon thread so that the daemon thread can receive the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
In order to solve the above problem, an embodiment of the present specification further provides an electronic device, including: a memory for storing a computer program; a processor for executing the computer program to implement: splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
To solve the above problem, embodiments of the present specification further provide a computer-readable storage medium having stored thereon computer instructions, which when executed, implement: splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
In order to solve the above problem, an embodiment of the present specification further provides a robot process automation processing method, where the method includes: receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
In order to solve the above problem, an embodiment of the present specification further provides a robot process automation processing apparatus, where the apparatus includes: the receiving module is used for receiving the state code sent by the main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and the cleaning program running module is used for running the cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
In order to solve the above problem, an embodiment of the present specification further provides an electronic device, including: a memory for storing a computer program; a processor for executing the computer program to implement: receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
To solve the above problem, embodiments of the present specification further provide a computer-readable storage medium having stored thereon computer instructions, which when executed, implement: receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
As can be seen from the technical solutions provided in the embodiments of the present specification, an acquired task may be split into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time. According to the method provided by the embodiment of the specification, in the automatic process of the robot process, the health condition of the main thread can be continuously monitored by using the daemon thread without depending on a judgment method provided by an interface of the robot, and whether the process is dead or not can be judged more timely, so that the processing efficiency of the robot process automatic fault is improved, and the invalid occupied resources are quickly released.
Drawings
In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the specification, and other drawings can be obtained by those skilled in the art without creative efforts.
Fig. 1 is a flowchart illustrating the operation of a robot process automation system according to an embodiment of the present disclosure;
FIG. 2 is a flow chart of a method for automating the processes of various robots in accordance with an embodiment of the present disclosure;
FIG. 3 is a flow chart of a method for automating the processes of various robots in accordance with an embodiment of the present disclosure;
fig. 4 is a functional structure diagram of an electronic device according to an embodiment of the present disclosure;
fig. 5 is a functional structure diagram of an automated robot process processing apparatus according to an embodiment of the present disclosure;
fig. 6 is a functional configuration diagram of an automated robot process processing apparatus according to an embodiment of the present disclosure.
Detailed Description
The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without any creative effort shall fall within the protection scope of the present specification.
The RPA has the characteristics of small influence on the existing system of an enterprise, basically no coding, short implementation period, friendliness to non-technical service personnel and the like. The RPA can not only simulate human beings, but also utilize and fuse the prior technologies such as rule engine, optical character recognition, voice recognition, machine learning, artificial intelligence and the like to realize the aim of process automation. RPA can be applied to any industry, to any business scenario, for example: applied to the financial field, RPA is a financial robot; the method is applied to the field of tax, namely an RPA (remote procedure administration) tax robot; the robot is applied to the HR field, and the RPA is the HR robot.
The RPA is a piece of software, not a physical robot. The RPA can record the operation behaviors of the employee, including keyboard entry, mouse movement and clicking, triggering and calling Windows system operations (such as folder and file operations), and triggering and calling various application programs (such as web page operations, e-mails, Word/Excel operations, etc.), and the RPA software is not required to record these operations and abstract these operations to become objects that can be understood and processed by the computer, and the way in which the RPA software records these behavior operations is generally called Capture (Capture). After capturing all operations of the mouse, the keyboard, the system and the application program, the RPA software automatically executes the objects in a computer according to the appointed rule.
In the RPA software, the software for executing the RPA flow script is usually installed on a machine that needs to execute the flow script, and the machine may be called a robot agent. The robot agent may be an electronic device having a logical operation function, and the electronic device may be a client or a server. The client can be a desktop computer, a tablet computer, a notebook computer, a mobile phone, a workstation and the like. Of course, the client is not limited to the electronic device with certain entities, and may also be software running in the electronic device. It may also be program software formed by program development, which may be run in the above-mentioned electronic device.
When an RPA process is executed at the robot agent, the RPA robot should successfully execute all processes in an ideal situation when the environment is ready and all software required by the robot has been installed. In reality, however, a machine where the agent end is located may have a certain fault, for example, a memory overflow of a long-time-use Windows system due to an incomplete fragment recovery mechanism, a process crash of an RPA-operated APP due to an incorrect dependent packet version, and the like. In this case, if the fault cannot be found and handled in time, the RPA robot is stuck at the current step and cannot continue to execute the process.
In current treatment methods, most RPA robots treat by giving each step a timeout. For example, the click button element required in the step is not captured within 10 seconds, that is, the step is judged to be wrong, and a corresponding error handling mechanism is operated. This method can cover about 80% of error handling, but still has some disadvantages, mainly as follows: relying on the interface provided by the technology itself. Windows interface, Java, browser can be controlled and operated by UIautomation, Java Access Bridge (hereinafter abbreviated as JAB), Selenium and other tools. But for cold door technologies such as Flash and the like, a proper overtime processing mechanism may not be available; processes that crash cannot be handled reasonably. For example, when the Java component is controlled by using the JAB, if there is no response to a Java crash, sending a past request by using the JAB will not result in a response, will not trigger a timeout determination, and will only die with the crash of the process.
Considering that if the agent end of the robot starts working, the agent end process starts two threads at the same time, one is a main thread for executing tasks, the other is a daemon thread, the main thread sends a state code to the daemon thread once after executing an action, so that the daemon thread determines the state of the main thread for executing the tasks according to the state code, and when the state is abnormal, the main thread is stopped in time and cleaned, thereby the problem of untimely fault response caused by a judgment method provided by an interface of the robot in the prior art is solved, the processing efficiency of the robot flow automation fault is improved, and the resources occupied by invalidation are released rapidly. Based on this, the embodiments of the present specification provide a robot process automation processing method, apparatus, and storage medium.
Referring to fig. 1, an embodiment of the present disclosure provides a robot process automation system. The robotic process automation processing system may include a main thread 110 and a daemon thread 120.
In some embodiments, the robotic process automation processing system supports multi-threading (multi-threading) processing, i.e., in one robotic process automation, multiple program fragments can be run independently at the same time.
In some embodiments, the main thread 110 may be configured to split the retrieved task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to the daemon thread.
In some embodiments, the main thread 110 may split the acquired task into a plurality of subtasks, so that an expected execution time of each subtask is smaller than a preset value. For example, for the task "open excel", create a Sheet tab, fill in the Sheet a1 lattice, 'Hello World', save exit. The "may include a plurality of business operations, which are four business operations, that is," open excel "," create a Sheet tab "," fill Hello World' "in a Sheet a1 of the Sheet, and" save exit ", respectively, and the main thread 110 may split the task into a plurality of subtasks based on an expected execution time of each business operation. For example, the task may be split into four subtasks, which are "open excel", "create a Sheet tab", "fill in" Hello World' "in a1 lattice of the Sheet, and" save exit ", respectively. Of course, the subtask may include only one business operation, or may include a plurality of business operations. The expected execution time of each sub-task should not be too long, i.e. the expected execution time of each sub-task is kept smaller than a preset value. Wherein, the preset value can be any value in 0-30 seconds. Of course, the preset value may also be other values, such as 30-50 seconds, 0-50 seconds, and the like, and may be set according to actual situations.
In some embodiments, the main thread 110 may execute one sub-task at a time, and execute the next sub-task after the previous sub-task is executed. The main thread 110 may sequentially execute the plurality of subtasks, and after each subtask is executed, a status code may be generated, where the status code may represent that the status of the subtask is an executed status. The status code may be a string of numbers, letters, or a combination of numbers and letters.
In some embodiments, after generating the status code, the main thread 110 may send the status code to the daemon thread 120. Specifically, after the main thread 110 sends the state code to the daemon thread 120, the next sub-task may be executed without waiting for the reply of the daemon thread 120 until all the sub-tasks are executed.
In some embodiments, the main thread 110 may further determine whether there is an unexecuted subtask after the execution of each subtask is completed; executing a next unexecuted subtask under the condition that the unexecuted subtask exists, and generating a next state code after the next unexecuted subtask is executed; sending the next state code to the daemon thread; and running a cleaning program under the condition that no unexecuted subtask exists, and ending the task execution flow. Specifically, if there are still unexecuted subtasks, the above steps are continuously executed in a loop. After the main thread 110 executes all the subtasks, the process can be ended and the corresponding ending work can be executed. The method mainly runs a cleaning program to clean the related processes and end the current process so as to cater to the next RPA process.
In some embodiments, if the sub-task executed by the main thread 110 is the first sub-task, a task execution notification may be further sent to the daemon thread 120 when the first sub-task starts to be executed, so as to notify the daemon thread 110 that the first sub-task has started to be executed.
In some embodiments, the daemon thread 120 may be configured to start timing after receiving the task execution notification, and run a cleaning program when the status code sent by the main thread is not received within a preset time, so as to end a task execution process.
In some embodiments, the daemon thread 120 may be configured to receive the status code sent by the main thread, and run a cleaning program in a case that a next status code is not received within a preset time, so as to end a task execution process. Specifically, the daemon thread 120 may start timing after receiving the status code, and if the status code is received within a preset time, the main thread 110 is considered to be still working normally, and if the status code is not received within the preset time, the task that the main thread 110 has a problem occurs, does not need to continue waiting, directly enters corresponding ending work, runs a cleaning program, cleans up a related process, and ends the current process to cater for the next RPA process. It can be seen that the daemon thread 120 mainly works to listen whether the status code transmitted from the main thread 110 is received within a preset time. The preset time can be freely set, but is not too short so as to avoid false alarm; it should not be too long to prevent long-term death. The preset time may be any value of 0 to 30 seconds. Of course, the preset time may also be other values, such as 30-50 seconds, 0-50 seconds, etc., and may be set according to actual situations.
In some embodiments, the main thread 110 mainly works to normally execute each subtask in the flow, and after executing each subtask, the main thread sends a status code. In order to further improve the efficiency of processing a robot flow automation failure and reduce the delay of sending and receiving a status code, the main thread 110 and the daemon thread 120 may be threads in the same process, so that the sending object of the status code is another thread in the same process. Because the threads in the process share resources, the sending and receiving speed of the state codes can be completed almost instantly, the processing efficiency of the robot process automation faults is improved, and the sending and receiving delay of the state codes is reduced.
In the robot process automation processing system provided in the embodiment of the present description, a main thread may be used to split an acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; sending the state code to the daemon thread; the daemon thread may be configured to receive the state code sent by the main thread, and run a cleaning program when a next state code is not received within a preset time, so as to end a task execution process. The system provided by the embodiment of the description can continuously monitor the health condition of the main thread by using the daemon thread without depending on a judgment method provided by an interface of the system in the process of automatically processing the robot flow, and judge whether the flow is dead or not in time, so that the processing efficiency of the robot flow automatic fault is improved, and the invalid occupied resources are quickly released.
Please refer to fig. 2. The embodiment of the description also provides a robot process automation processing method. In the embodiment of the present specification, a main body for executing the robot flow automation processing method may be an electronic device having a logical operation function, and the electronic device may be a server. The server supports multi-threaded processing and may have a network communication unit, a processor, a memory, and the like. The server may also be a distributed server, which may be a system with multiple processors, memory, network communication modules, etc. operating in coordination. Alternatively, the server may also be a server cluster formed by several servers. From the perspective of the main thread, the method may include the following steps.
S210: splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation.
In some embodiments, the splitting the acquired task into a plurality of subtasks includes splitting the acquired task into a plurality of subtasks, and an expected execution time of each subtask is smaller than a preset value. For example, for the task "open excel", create a Sheet tab, fill in the Sheet a1 lattice, 'Hello World', save exit. The method comprises the following steps that a plurality of business operations are respectively 'opening excel', 'creating a Sheet tab', 'filling Hello World' in an A1 lattice of the Sheet, and 'saving and quitting', and a main thread in a server can split a task into a plurality of subtasks based on the expected execution time of each business operation. For example, the task may be split into four subtasks, which are "open excel", "create a Sheet tab", "fill in" Hello World' "in a1 lattice of the Sheet, and" save exit ", respectively. Of course, the subtask may include only one business operation, or may include a plurality of business operations. The expected execution time of each sub-task should not be too long, i.e. the expected execution time of each sub-task is kept smaller than a preset value. Wherein, the preset value can be any value in 0-30 seconds. Of course, the preset value may also be other values, such as 30-50 seconds, 0-50 seconds, and the like, and may be set according to actual situations.
S220: and executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed.
In some embodiments, the main thread in the server may execute one subtask each time, and execute the next subtask after the last subtask is executed. The server may sequentially execute the plurality of subtasks, and after each subtask is executed, a status code may be generated, where the status code may characterize the state of the subtask as an executed state. The status code may be a string of numbers, letters, or a combination of numbers and letters.
In some embodiments, the process of the main thread executing the subtasks may include: after the execution of each subtask is finished, judging whether an unexecuted subtask exists or not; and when the next unexecuted subtask is executed, executing the next unexecuted subtask, and after the next unexecuted subtask is executed, generating a next state code. Specifically, if there are still unexecuted subtasks, the above steps are continuously executed in a loop. And after the server executes all the subtasks, the server can end the flow and run corresponding ending work. The method mainly runs a cleaning program to clean the related processes and end the current flow
S230: and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
In some embodiments, if the subtask executed by the main thread is the first subtask, a task execution notification may be sent to the daemon thread when the first subtask starts to be executed, so as to notify the daemon thread that the first subtask starts to be executed, so that the daemon thread starts to count time after receiving the task execution notification, and runs a cleaning program to end the task execution flow when a status code is not received within a preset time.
In some embodiments, the daemon thread may be configured to receive a status code sent by the main thread, and run a cleaning program when a next status code is not received within a preset time, so as to end a task execution process. Specifically, the daemon thread may start timing after receiving the state code, and if the state code is received within a preset time, the main thread is considered to be still working normally, and if the state code is not received within the preset time, the main thread is considered to have a problem, and the main thread directly enters corresponding ending work without continuing to wait, runs a cleaning program, cleans a related process, and ends the current process to cater for the next RPA process. Therefore, the main work of the daemon thread is to monitor whether the state code transmitted by the server is received within preset time. The preset time can be freely set, but is not too short so as to avoid false alarm; it should not be too long to prevent long-term death. The preset time may be any value of 0 to 30 seconds. Of course, the preset time may also be other values, such as 30-50 seconds, 0-50 seconds, etc., and may be set according to actual situations.
In some embodiments, the main thread mainly works to normally execute each subtask in the flow, and after each subtask is executed, the main thread sends a status code once. In order to further improve the processing efficiency of robot process automation faults and reduce the delay of sending and receiving the state codes, the main thread and the daemon thread can be threads in the same process, so that the sending object of the state codes is another thread in the same process. Because the threads in the process share resources, the sending and receiving speed of the state codes can be completed almost instantly, the processing efficiency of the robot process automation faults is improved, and the sending and receiving delay of the state codes is reduced.
According to the robot process automation processing method provided by the embodiment of the specification, the acquired task can be divided into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time. According to the method provided by the embodiment of the specification, in the automatic process of the robot process, the health condition of the main thread can be continuously monitored by using the daemon thread without depending on a judgment method provided by an interface of the robot, and whether the process is dead or not can be judged more timely, so that the processing efficiency of the robot process automatic fault is improved, and the invalid occupied resources are quickly released.
Please refer to fig. 3. The embodiment of the description also provides a robot process automation processing method. In the embodiment of the present specification, a main body for executing the robot flow automation processing method may be an electronic device having a logical operation function, and the electronic device may be a server. The server supports multi-threaded processing and may have a network communication unit, a processor, a memory, and the like. The server may also be a distributed server, which may be a system with multiple processors, memory, network communication modules, etc. operating in coordination. Alternatively, the server may also be a server cluster formed by several servers. From the perspective of a daemon thread, the method may comprise the following steps.
S310: receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask includes at least one business operation.
In some embodiments, a daemon thread in the server may receive the status code from the main thread. The state code is generated by the main thread according to the following mode: the main thread divides the acquired task into a plurality of subtasks; each subtask includes at least one business operation; and executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed.
Specifically, the main thread may split the acquired task into a plurality of subtasks, including splitting the acquired task into a plurality of subtasks, so that the expected execution time of each subtask is smaller than a preset value. For example, for the task "open excel", create a Sheet tab, fill in the Sheet a1 lattice, 'Hello World', save exit. The method comprises the following steps that a plurality of business operations are respectively 'opening excel', 'creating a Sheet tab', 'filling Hello World' in an A1 lattice of the Sheet, and 'saving and quitting', and a main thread in a server can split a task into a plurality of subtasks based on the expected execution time of each business operation. For example, the task may be split into four subtasks, which are "open excel", "create a Sheet tab", "fill in" HelloWorld' "and" save exit "in the a1 lattice of the Sheet. Of course, the subtask may include only one business operation, or may include a plurality of business operations. The expected execution time of each sub-task should not be too long, i.e. the expected execution time of each sub-task is kept smaller than a preset value. Wherein, the preset value can be any value in 0-30 seconds. Of course, the preset value may also be other values, such as 30-50 seconds, 0-50 seconds, and the like, and may be set according to actual situations.
The main thread can execute one subtask every time, and after the last subtask is executed, the next subtask is executed. The server may sequentially execute the plurality of subtasks, and after each subtask is executed, a status code may be generated, where the status code may characterize the state of the subtask as an executed state. The status code may be a string of numbers, letters, or a combination of numbers and letters.
S320: and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
In some embodiments, the daemon thread may run a cleaning program in a case that a next state code is not received within a preset time, so as to end the task execution flow. Specifically, the daemon thread may start timing after receiving the state code, and if the state code is received within a preset time, the main thread is considered to be still working normally, and if the state code is not received within the preset time, the main thread is considered to have a problem, and the main thread directly enters corresponding ending work without continuing to wait, runs a cleaning program, cleans a related process, and ends the current process to cater for the next RPA process. Therefore, the main work of the daemon thread is to monitor whether the state code transmitted by the server is received within preset time. The preset time can be freely set, but is not too short so as to avoid false alarm; it should not be too long to prevent long-term death. The preset time may be any value of 0 to 30 seconds. Of course, the preset time may also be other values, such as 30-50 seconds, 0-50 seconds, etc., and may be set according to actual situations.
In some embodiments, the daemon thread can also receive a task execution notification sent by a main thread; the task execution notification is sent by the main thread when the first subtask starts to execute; and starting timing after receiving the task execution notification, and running a cleaning program under the condition that the state code sent by the main thread is not received within the preset time so as to finish the task execution flow.
In some embodiments, the main thread mainly works to normally execute each subtask in the flow, and after each subtask is executed, the main thread sends a status code once. In order to further improve the processing efficiency of robot process automation faults and reduce the delay of sending and receiving the state codes, the main thread and the daemon thread can be threads in the same process, so that the sending object of the state codes is another thread in the same process. Because the threads in the process share resources, the sending and receiving speed of the state codes can be completed almost instantly, the processing efficiency of the robot process automation faults is improved, and the sending and receiving delay of the state codes is reduced.
The robot process automation processing method provided by the embodiment of the specification can receive the state code sent by the main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow. According to the method provided by the embodiment of the specification, in the automatic process of the robot process, the health condition of the main thread can be continuously monitored by using the daemon thread without depending on a judgment method provided by an interface of the robot, and whether the process is dead or not can be judged more timely, so that the processing efficiency of the robot process automatic fault is improved, and the invalid occupied resources are quickly released.
Fig. 4 is a functional structure diagram of an electronic device according to an embodiment of the present disclosure, where the electronic device may include a memory and a processor.
In some embodiments, the memory may be used to store the computer programs and/or modules, and the processor may implement various functions of the robot process automation processing method by running or executing the computer programs and/or modules stored in the memory and calling data stored in the memory. The memory can mainly comprise a program storage area and a data storage area, wherein the program storage area can store an operating system and an application program required by at least one function; the storage data area may store data created according to the use of the user terminal. In addition, the memory may include high speed random access memory, and may also include non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), at least one magnetic disk storage device, a Flash memory device, or other volatile solid state storage device.
The Processor may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an APPlication Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The processor may execute the computer instructions to perform the steps of: splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
In the embodiments of the present description, the functions and effects specifically realized by the electronic device may be explained in comparison with other embodiments, and are not described herein again.
Fig. 5 is a functional structure diagram of a robot process automation processing apparatus according to an embodiment of the present disclosure, and the apparatus may specifically include the following structural modules.
A splitting module 510, configured to split the acquired task into a plurality of subtasks; each subtask includes at least one business operation;
a generating module 520, configured to execute the multiple subtasks in sequence, and generate a status code indicating that the status of each subtask is completed after the execution of each subtask is completed;
a sending module 530, configured to send the state code to a daemon thread, so that the daemon thread receives the state code, runs a cleaning program under the condition that a next state code is not received within a preset time, and ends a task execution flow.
The embodiments of the present specification also provide a computer readable storage medium of a robot process automation processing method, where the computer readable storage medium stores computer program instructions, and when the computer program instructions are executed, the computer program instructions implement: splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
In the embodiments of the present specification, the storage medium includes, but is not limited to, a Random Access Memory (RAM), a Read-Only Memory (ROM), a Cache (Cache), a Hard Disk Drive (HDD), or a Memory Card (Memory Card). The memory may be used for storing the computer programs and/or modules, and the memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function, and the like; the storage data area may store data created according to the use of the user terminal, and the like. In addition, the memory may include high speed random access memory, and may also include non-volatile memory. In the embodiments of the present description, the functions and effects specifically realized by the program instructions stored in the computer-readable storage medium may be explained in contrast to other embodiments, and are not described herein again.
Fig. 4 is a functional structure diagram of an electronic device according to an embodiment of the present disclosure, where the electronic device may include a memory and a processor.
In some embodiments, the memory may be used to store the computer programs and/or modules, and the processor may implement various functions of the robot process automation processing method by running or executing the computer programs and/or modules stored in the memory and calling data stored in the memory. The memory can mainly comprise a program storage area and a data storage area, wherein the program storage area can store an operating system and an application program required by at least one function; the storage data area may store data created according to the use of the user terminal. In addition, the memory may include high speed random access memory, and may also include non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), at least one magnetic disk storage device, a Flash memory device, or other volatile solid state storage device.
The Processor may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an APPlication Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The processor may execute the computer instructions to perform the steps of: receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
In the embodiments of the present description, the functions and effects specifically realized by the electronic device may be explained in comparison with other embodiments, and are not described herein again.
Fig. 6 is a functional structure diagram of a robot process automation processing apparatus according to an embodiment of the present disclosure, and the apparatus may specifically include the following structural modules.
A receiving module 610, configured to receive a status code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation;
a cleaning program running module 620, configured to run the cleaning program when the next status code is not received within a preset time, so as to end the task execution flow.
The embodiments of the present specification also provide a computer readable storage medium of a robot process automation processing method, where the computer readable storage medium stores computer program instructions, and when the computer program instructions are executed, the computer program instructions implement: receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
In the embodiments of the present specification, the storage medium includes, but is not limited to, a Random Access Memory (RAM), a Read-Only Memory (ROM), a Cache (Cache), a Hard Disk Drive (HDD), or a Memory Card (Memory Card). The memory may be used for storing the computer programs and/or modules, and the memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function, and the like; the storage data area may store data created according to the use of the user terminal, and the like. In addition, the memory may include high speed random access memory, and may also include non-volatile memory. In the embodiments of the present description, the functions and effects specifically realized by the program instructions stored in the computer-readable storage medium may be explained in contrast to other embodiments, and are not described herein again.
It should be noted that the data cleaning method, the data cleaning device, and the electronic device provided in the embodiments of the present specification relate to the field of computer technologies, and may be applied to the field of finance for processing data in a computer use process, and may also be applied to any field other than the field of finance.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and the same or similar parts in each embodiment may be referred to each other, and each embodiment focuses on differences from other embodiments. In particular, as for the apparatus embodiment and the apparatus embodiment, since they are substantially similar to the method embodiment, the description is relatively simple, and reference may be made to some descriptions of the method embodiment for relevant points.
After reading this specification, persons skilled in the art will appreciate that any combination of some or all of the embodiments set forth herein, without inventive faculty, is within the scope of the disclosure and protection of this specification.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Lola, HDL, laspam, hardbyscript Description Language (vhigh Description Language), and so on, which are currently used by Hardware compiler-software (Hardware Description Language). It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
From the above description of the embodiments, it is clear to those skilled in the art that the present specification can be implemented by software plus a necessary general hardware platform. Based on such understanding, the technical solutions of the present specification may be essentially or partially implemented in the form of software products, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and include instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The description is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
While the specification has been described with examples, those skilled in the art will appreciate that there are numerous variations and permutations of the specification that do not depart from the spirit of the specification, and it is intended that the appended claims include such variations and modifications that do not depart from the spirit of the specification.
Claims (21)
1. A robot process automation processing system is characterized in that the system comprises a main thread and a daemon thread;
the main thread is used for splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; sending the state code to the daemon thread;
and the daemon thread is used for receiving the state code sent by the main thread and running a cleaning program under the condition that the next state code is not received within preset time so as to finish the task execution process.
2. The system of claim 1, wherein the main thread and the daemon thread are threads in the same process.
3. The system of claim 1, wherein the splitting the obtained task into a plurality of subtasks comprises:
and splitting the acquired task into a plurality of subtasks, so that the expected execution time of each subtask is smaller than a preset value.
4. The system of claim 3, wherein the predetermined value is any value from 0 to 30 seconds.
5. The system of claim 1, wherein the main thread is further configured to send a task execution notification to the daemon thread when a first subtask begins execution;
the daemon process is also used for starting timing after receiving the task execution notification, and running a cleaning program under the condition that the state code sent by the main thread is not received within the preset time so as to finish the task execution process.
6. The system of claim 1, wherein the status code is a string of characters consisting of numbers, letters, or a combination of numbers and letters.
7. The system of claim 1, wherein the main thread is further configured to, after completion of execution of each subtask, determine whether there is an unexecuted subtask;
executing a next unexecuted subtask under the condition that the unexecuted subtask exists, and generating a next state code after the next unexecuted subtask is executed; and sending the next state code to the daemon thread.
8. The system of claim 7, wherein in the absence of an unexecuted subtask, the cleaning program is run to end the task execution flow.
9. The system of claim 1, wherein the preset time is any value of 0-30 seconds.
10. A method for automated processing of a robotic process, the method comprising:
splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation;
executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed;
and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
11. The method of claim 10, further comprising:
and when the first subtask starts to execute, sending a task execution notice to the daemon thread so that the daemon thread starts to time after receiving the task execution notice, and running a cleaning program to finish a task execution process under the condition that a state code is not received within preset time.
12. The method of claim 10, further comprising:
after the execution of each subtask is finished, judging whether an unexecuted subtask exists or not;
executing a next unexecuted subtask under the condition that the unexecuted subtask exists, and generating a next state code after the next unexecuted subtask is executed; and sending the next state code to the daemon thread.
13. The method of claim 12, wherein in the absence of an unexecuted subtask, running a cleaning program ends the task execution flow.
14. A robotic process automation processing device, the device comprising:
the splitting module is used for splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation;
the generating module is used for sequentially executing the plurality of subtasks and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed;
and the sending module is used for sending the state code to a daemon thread so that the daemon thread can receive the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
15. An electronic device, comprising:
a memory for storing a computer program;
a processor for executing the computer program to implement: splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
16. A computer readable storage medium having computer instructions stored thereon that when executed perform: splitting the acquired task into a plurality of subtasks; each subtask includes at least one business operation; executing the plurality of subtasks in sequence, and generating a state code which represents that the state of each subtask is the executed state after the execution of each subtask is completed; and sending the state code to a daemon thread so that the daemon thread receives the state code, and running a cleaning program to finish a task execution process under the condition that the next state code is not received within preset time.
17. A method for automated processing of a robotic process, the method comprising:
receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation;
and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
18. The method of claim 17, further comprising:
receiving a task execution notice sent by a main thread; the task execution notification is sent by the main thread when the first subtask starts to execute;
and starting timing after receiving the task execution notification, and running a cleaning program under the condition that the state code sent by the main thread is not received within the preset time so as to finish the task execution flow.
19. A robotic process automation processing device, the device comprising:
the receiving module is used for receiving the state code sent by the main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation;
and the cleaning program running module is used for running the cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
20. An electronic device, comprising:
a memory for storing a computer program;
a processor for executing the computer program to implement: receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
21. A computer readable storage medium having computer instructions stored thereon that when executed perform: receiving a state code sent by a main thread; the state code is used for representing the state of the subtask as being completed after execution; the state code is generated after the execution of each subtask is completed; wherein each subtask comprises at least one business operation; and running a cleaning program under the condition that the next state code is not received within the preset time so as to finish the task execution flow.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011422087.3A CN112379993A (en) | 2020-12-08 | 2020-12-08 | Robot process automation processing system, method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011422087.3A CN112379993A (en) | 2020-12-08 | 2020-12-08 | Robot process automation processing system, method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112379993A true CN112379993A (en) | 2021-02-19 |
Family
ID=74589509
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011422087.3A Pending CN112379993A (en) | 2020-12-08 | 2020-12-08 | Robot process automation processing system, method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112379993A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112990727A (en) * | 2021-03-26 | 2021-06-18 | 中国人民财产保险股份有限公司深圳市分公司 | Robot task execution control method, device, system and medium |
| CN113312129A (en) * | 2021-05-24 | 2021-08-27 | 华南理工大学 | Software operation process automation robot method, system, device and medium |
| CN116579749A (en) * | 2023-07-13 | 2023-08-11 | 浙江保融科技股份有限公司 | Method and device for running auditing flow based on RPA robot |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140019980A1 (en) * | 2012-07-10 | 2014-01-16 | Sap Ag | Thread Scheduling and Control Framework |
| CN109558237A (en) * | 2017-09-27 | 2019-04-02 | 北京国双科技有限公司 | A kind of task status management method and device |
| CN111352715A (en) * | 2020-03-03 | 2020-06-30 | 浪潮通用软件有限公司 | Method, system, terminal and storage medium for destroying flash thread |
| CN111385296A (en) * | 2020-03-04 | 2020-07-07 | 深信服科技股份有限公司 | Business process restarting method, device, storage medium and system |
| CN112035230A (en) * | 2020-09-01 | 2020-12-04 | 中国银行股份有限公司 | Method and device for generating task scheduling file and storage medium |
| CN112035258A (en) * | 2020-08-31 | 2020-12-04 | 中国平安财产保险股份有限公司 | Data processing method, device, electronic equipment and medium |
-
2020
- 2020-12-08 CN CN202011422087.3A patent/CN112379993A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140019980A1 (en) * | 2012-07-10 | 2014-01-16 | Sap Ag | Thread Scheduling and Control Framework |
| CN109558237A (en) * | 2017-09-27 | 2019-04-02 | 北京国双科技有限公司 | A kind of task status management method and device |
| CN111352715A (en) * | 2020-03-03 | 2020-06-30 | 浪潮通用软件有限公司 | Method, system, terminal and storage medium for destroying flash thread |
| CN111385296A (en) * | 2020-03-04 | 2020-07-07 | 深信服科技股份有限公司 | Business process restarting method, device, storage medium and system |
| CN112035258A (en) * | 2020-08-31 | 2020-12-04 | 中国平安财产保险股份有限公司 | Data processing method, device, electronic equipment and medium |
| CN112035230A (en) * | 2020-09-01 | 2020-12-04 | 中国银行股份有限公司 | Method and device for generating task scheduling file and storage medium |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112990727A (en) * | 2021-03-26 | 2021-06-18 | 中国人民财产保险股份有限公司深圳市分公司 | Robot task execution control method, device, system and medium |
| CN113312129A (en) * | 2021-05-24 | 2021-08-27 | 华南理工大学 | Software operation process automation robot method, system, device and medium |
| CN116579749A (en) * | 2023-07-13 | 2023-08-11 | 浙江保融科技股份有限公司 | Method and device for running auditing flow based on RPA robot |
| CN116579749B (en) * | 2023-07-13 | 2023-11-14 | 浙江保融科技股份有限公司 | Method and device for running auditing flow based on RPA robot |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112379993A (en) | Robot process automation processing system, method and device | |
| CN107392611B (en) | Method and device for sending transaction information and consensus verification | |
| CA2246270C (en) | Debugging multiple related processes simultaneously | |
| US20070074168A1 (en) | Automated step type determination | |
| US20160378879A1 (en) | Determining web page processing state | |
| CN109656773B (en) | Processing framework based on IOS application abnormal crash | |
| CN111930472B (en) | Code debugging method and device, electronic equipment and storage medium | |
| CN110162344B (en) | Isolation current limiting method and device, computer equipment and readable storage medium | |
| CN110990132A (en) | Asynchronous task processing method and device, computer equipment and storage medium | |
| US9824229B2 (en) | Controller with enhanced reliability | |
| CN112650676A (en) | Software testing method, device, equipment and storage medium | |
| CN114880159A (en) | Data processing method, device, equipment and storage medium | |
| US8694961B2 (en) | Thread-agile execution of dynamic programming language programs | |
| JP4627636B2 (en) | Mechanism for making asynchronous components an application framework agnostic | |
| CN111221744B (en) | Data acquisition method and device and electronic equipment | |
| CN113760491A (en) | Task scheduling system, method, equipment and storage medium | |
| CN110990179A (en) | Task processing method, device and equipment | |
| US20180373512A1 (en) | Method and device for simulating synchronous blocking in asynchronous environment, storage medium, server and terminal | |
| US8522256B2 (en) | Hosting non-messaging workflows in a messaging host | |
| CN111881025A (en) | Automatic test task scheduling method, device and system | |
| US10303513B2 (en) | Durable program execution | |
| CN111949475A (en) | Method and system for achieving distributed task scheduling based on zookeeper shell | |
| CN110955539A (en) | Process quitting method and device, electronic equipment and machine-readable storage medium | |
| CN111563000A (en) | File generation method, intelligent terminal and storage medium | |
| Heinze et al. | Fault-tolerant complex event processing using customizable state machine-based operators |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |