DIGITAL WORKER MANAGEMENT SYSTEM
Examples of the disclosure provide a system and method for monitoring and controlling Robotic Process Automation (RPA) that may use digital worker robots (bots) having differing reporting and control schemes. A bot manager monitors and consolidates inputs from different types of bots, translates performance and control inputs, and passes data to databases or other applications. A standard data structure may be used, in some embodiments, to enable auditing, reporting, analytics, work intake, and work assignments, to seamlessly operate bots from multiple providers. Disclosed systems and methods may thus coordinate bots among numerous tasks, business units, regions and priorities, even when bots had been designed with inconsistent protocols, such as may occur when using multiple different third party development tools or sourcing bots from different RPA providers.
Robotic process automation (RPA) may use software robots (bots), possibly along with artificial intelligence (AI), for process automation. Whereas with traditional workflow automation, a software developer produces a list of actions to automate a task and interfaces to other systems using application programming interfaces (APIs) or dedicated scripting languages, with RPA systems, a bot may be trained by observing a user perform a task, perhaps in an application's graphical user interface (GUI). Once trained, a bot may then perform an automated process by repeating those tasks in a virtual workstation environment, interpreting a virtual screen display information and issuing mouse and keyboard commands to the application.
SUMMARYExamples of the disclosure provide systems and methods for monitoring and controlling robotic process automation (RPA) that may use digital worker robots (bots) having differing reporting and control schemes. A bot manager monitors and consolidates inputs from different types of bots, translates performance and control inputs, and passes data to databases or other applications. A standard data structure may be used, in some embodiments, to enable auditing, reporting, analytics, work intake, and work assignments, to seamlessly operate bots from multiple providers. Disclosed systems and methods may thus coordinate bots among numerous tasks, business units, regions and priorities, even when bots had been designed with inconsistent protocols, such as may occur when using multiple different third-party development tools or sourcing bots from different RPA providers.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Corresponding reference characters indicate corresponding parts throughout the drawings.
DETAILED DESCRIPTIONA more detailed understanding may be obtained from the following description, presented by way of example, in conjunction with the accompanying drawings. The entities, connections, arrangements, and the like that are depicted in, and in connection with the various figures, are presented by way of example and not by way of limitation. As such, any and all statements or other indications as to what a particular figure depicts, what a particular element or entity in a particular figure is or has, and any and all similar statements, that may in isolation and out of context be read as absolute and therefore limiting, may only properly be read as being constructively preceded by a clause such as “In at least some embodiments, . . . ” For brevity and clarity of presentation, this implied leading clause is not repeated ad nauseum.
Referring to the figures, examples of the disclosure enable systems and methods for monitoring and controlling robotic process automation (RPA) that may use digital worker robots (bots) having differing reporting and control schemes. A bot manager monitors and consolidates inputs from different types of worker bots (WBs), translates performance and control inputs, possibly into standard data structures, and passes data to databases or other applications. The standard data structure may be used, in some embodiments, to enable auditing, reporting, analytics, work intake, and work assignments, to seamlessly operate bots from multiple providers. Disclosed systems and methods may thus coordinate bots among numerous tasks, business units, regions and priorities, even when bots had been designed with inconsistent protocols, such as may occur when using multiple different third-party development tools or sourcing bots from different RPA providers.
In some examples, computing device 102 has at least one processor 104, a memory area 106, and at least one user interface component 108. Processor 104 includes any quantity of processing units, and may be programmed to execute computer-executable instructions (or logic) for implementing aspects of the disclosure. Executable instructions may be performed by the processor or by multiple processors within computing device 102, or performed by a processor external to computing device 102. In some examples, processor 102 is programmed to execute instructions or logic such as those illustrated in the figures (e.g.,
In some examples, processor 104 represents an implementation of analog techniques to perform the operations described herein. For example, the operations may be performed by an analog computing device and/or a digital computing device.
Computing device 104 further has one or more computer-readable media such as memory area 106. Memory area 106 includes any quantity of non-transitory computer-readable media associated with or accessible by the computing device. Memory area 106 may be internal to the computing device (as shown in
Memory area 106 stores, among other data, one or more applications comprising executable logic. The applications, when executed by the processor, operate to perform functionality on the computing device. Exemplary applications include bot integration functionality 120; bot reporting functionality 130; orchestration functionality 140; WB library 152; a virtual environment 154 (possibly using VDI); user interface component 108, which may include a graphical user interface (GUI); and logic for a communication module 112. Memory area 106 may also store data used in support of the disclosed operations, such as a work queue 150 and data sources 110. Data sources 110 may represent data stored locally within memory 106, data access points or other pointers indicating data stored remotely from computing device 102, or any combination of local and remote data.
In some examples, WB library 152 stores copies of bots that may be called (manifested as an instance) to process work tasks listed in work queue 150. Typically, a bot may run in a virtual workstation, provided by the functionality of virtual environment 154. Some examples of virtual environment 154 may provide a virtualized version of user interface component 108 with which a bot may interact. In some examples, WB library 152 additionally stores translation information that will permit translation from a standard or common task format into the format needed by a particular bot, and will also permit translation from the particular reporting format of a bot to a standard data format for storing and coordinating work among bots. Because of this translation capability, it may be possible for one bot to take as input the output of another bot's work, even if the bots do not have compatible protocols.
The various applications may communicate with counterpart applications or services such as web services accessible via a communication network 114. For example, the applications may represent downloaded client-side applications that correspond to server-side services executing in a cloud. Communication module 112 may also include hardware components, such as one or more of the following to provide data to and receive data from the communication network 114: a Bluetooth® communication module, a WiFi communication module, an infrared or other radio communication module, and global positioning system (GPS) hardware. Communication network 114 may include the internet, a private network, a wide area network (WAN), a local area network (LAN) or another type of network suitable for computing device 102 to communicate with other devices.
User interface component 108 may also include one or more of the following to provide data to the user 116 or receive data from user 116: speakers, a sound card, a camera, a microphone, a vibration motor, one or more accelerometers, a photoreceptive light sensor, a mouse, and a keyboard. User interface component 108 may also include a radio frequency identification (RFID) transmitter/receiver, a barcode scanner, or any other system that is suitable for output or input. Hardware components, executable logic or both may provide functionality.
In some examples, user interface component 108 includes a graphics card for displaying data to user 116 and receiving data from user 116. User interface component 108 may also include computer-executable instructions (e.g., a driver) for operating the graphics card. Further, user interface component 108 may include a display (e.g., a touch screen display or natural user interface) and/or computer-executable instructions (e.g., a driver) for operating the display. For example, user 116 may input commands or manipulate data by moving computing device 102 in a particular way. In another example, user 116 may input commands or manipulate data by providing a gesture detectable by user interface component 108, such as a touch or tap of a touch screen display or natural user interface. In some examples, some portions of user interface component 108 may be virtualized to operate within virtual environment 154 that runs bots from WB library 152.
In some examples, user 116 may interact with the system of computing device 102 via communications network 114 using interface 118. Interface 118 may be a user interface component of another computing device communicatively coupled to communication network 114, for example.
Exemplary Operating MethodsAn exemplary system may include hundreds of bots (WBs) operating on dozens of different processes, including robotic data entry, requiring differing translations. A single WB may be manifested within a VDI that is running RPA software. Bots may be defined (encoded) for specific processes, with different bots each having potentially unique protocols or formats for control and reposting. Some tasks may be shifted among different bots, but only among those that have the proper capabilities. Different tasks or processes may have different priority levels (e.g., critical, high, medium, and low), based on the expected impact to operations. Some bots may be configured to run only a single task or process, other bots may be configured to run multiple ones.
Unfortunately, different RPA bots from different providers or even bots developed using different tools (even if from the same provider) may use different protocols or formats, and not interact or function compatibly. Currently, different providers each build their own proprietary rapid automation (RA) software solutions that provide in-software process mapping, development and bot monitoring. However, as the industry continues to evolve and different proprietary RA solutions continue to emerge, if an RPA user partners with multiple providers, the result may be disjointed integration points for data visibility, checkpoint restarting, and bot performance monitoring (e.g., alerts and controls).
Thus, an integration management platform is needed to translate tasking, alerts, and reporting among bots and provide clear data, alerting and controls between other systems. Together, the disclosed bot integration functionality 120, bot reporting functionality 130, and orchestration functionality 140 can provide that needed functionality, and are able to manage digital workers (the WBs) by monitoring and consolidating inputs and outputs to/from different types of bots, translating performance and control inputs, passing data to databases or other applications, and acting on alerts.
Bot integration module 120, establishes an integration management platform to translate between bots (i.e. digital workers) and provide clear data, alerting and controls translation among multiple systems. In some examples, bot integration functionality 120 includes data management component 122, performance management component 124, and health monitor component 126. Bot reporting functionality 130 passes data to the appropriate databases or applications, and in some examples, may provide a standard data structure to enable auditing, reporting, analytics, work intake, work assignment to seamlessly operate bots having different protocols. Some examples of bot reporting functionality 130 include bot output 132, an alert manager 134, and a database 136 (which may include multiple databases having differing content and format). Orchestration functionality 140 takes in data input from the various bots and provides central management. Orchestration functionality 140 may be platform agnostic, and thus able to obtain data from multiple different systems that each maintains a unique protocol. In some examples, orchestration functionality 140 includes a rules engine 142, an event manager 144, and a bot manager 146.
In some examples, bot data management 122 accepts data inputs in the various formats of the different bot providers (and RA tools) and translates the data inputs into a standard format that will be sent to centralized databases for performance and controls reporting, such as possibly database 136. Translations from different bots may be different (i.e., different translations may be used) if different bots use different control/reporting formats or protocols. Standard sets of data may be collected from the bots (such as bot_ID and work time), translated, and stored in a centralized database, such as database 136. However, data management 122 may also accept and store process-specific or project-specific data points. Bot performance management 124 manages incoming work to keep the bots busy, such as by identifying idle bots and flagging them to bot management 122. In some examples, performance management 124 provides APIs so that work may be added to a work queue (such as work queue 150) from other systems. A form of “crawler” functionality may also be provided, within performance management 124 or another module, to identify idle resources and systems needing to assign work to a bot.
In some examples, bot integration functionality 120 will ping bots, perhaps at predetermined intervals or upon demand from user 116, to ensure up-time and performance monitoring. In the event that a bot is nonresponsive, health monitor 126 may send an alert to alert manager 134.
In some examples, bot output 132 hands-off completed work (by a digital worker, a.k.a. a WB) that is ready for a human worker to complete. A bot may only automate a component of an entire work task, leaving a final validation check or other further actions to be taken by a human worker. In some examples, bot alert manager 134 receives issued alerts from bot integration functionality 120 (specifically, health monitor 126). The alert is assigned a specific type, such as (1) down bot, (2) slow bot, (3) failed process, or another type. Based on the alert type, alert manager 134 prescribes an appropriate remedial action. In some event cases alert manager 134 may issue a systemic restart of the subject bot. If sufficiently severe events occur (such as a bot fails to restart), alert manager 134 will send a page out alert, indicating a request for support team intervention. Further details will be provided in the descriptions of
Database 136 is illustrated as a single database, but may include multiple databases, with differing content and format. As bot integration functionality 120 passes data from bots to databases, including database 136, it may optionally perform data translations. Some examples of database 136 may include a portion for controls (see bot controls logging database 214 in
In some examples, event manager 144 receives updates when a bot is about to begin a task (i.e., the bot is acknowledging receipt of the task instructions), when it has completed the task, and possibly at defined intervals while working on the task. Event manager 144 may include a configurable time interval specification which, if exceeded without an update from a bot, may result in the generation of an alert. In some examples, bot manager 146 provides an integration point to (1) monitor bot health, (2) consolidate/translate/standardize data formats, and (3) centralize reporting for bot performance. Bot manager 146 may use custom APIs for event calls to certain bots. In some examples, the translation data may be stored in bot library 152, although other storage locations are possible.
In some examples, rules engine 142 may be employed by orchestration functionality 140 to determine which task to assign to which bot. In addition to worker bots (WBs), there may also be boss bots that control the actions of the other bots, such as WBs. More detail is provided on boss bots in the description of
1. Process priority definitions:
-
- a. Critical;
- b. High;
- c. Medium; and
- d. Low.
2. Configurable time interval, T
3. Methods to create queue items: - a. Bot manager 146 may be configured to monitor database tables or work queue 150 for new work items.
- b. WBs may be assigned to collect queue items from user interface component 108.
3. A set of API may be available for an application or program to create new items in work queue 150.
4. Bot management rules: - a. Assign queue item by process priority. First-in-first-out (FIFO) applies within each priority:
- i. Critical items go to the top of the overall queue.
- ii. High priority items go in the second grouping.
- iii. Medium priority items go in the third grouping.
- iv. Low priority items go in the last grouping.
- b. Escalate queue items, based on exceeding T (the defined time interval):
- i. High priority items not completed by time T move to Critical priority.
- ii. Medium priority items not completed by time T move to High priority.
- iii. Low priority items not completed by time T move to Medium priority.
- c. Distribute work to WBs:
- i. When a WB finishes processing its current task, it becomes available for being assigned a new task.
- ii. Available WBs poll work queue 150 or bot manager 146 for the next task.
- iii. Bot manager 146 returns the highest ranked item in work queue 150 that the available WB is authorized to process based on the WB's operating environment.
- iv. If a new work task is not available, the available WB will check the queue at specified intervals (perhaps T, or a different time interval), until a new task is available.
Thus, bot integration module 202 contains the functionality to send each of bots 204a and 204b commands in the specific appropriate format, and to translate retrieved status updates and results into a standard format for reporting and storage. Bot integration module 202 is also in communication with work queue 150. Bot integration module 202 retrieves work items from work queue 150, to assign as tasks to one or more of bots 204a and 204b, as well as updates work queue 150 to indicate which tasks have been assigned, which tasks have changed priority, and perhaps also to add new tasks.
Bot integration module 202 is further in communication with an alert manager 208, which may be similar to alert manager 134 (of
Bot integration module 202 is in yet further communication with a bot controls logging database 214 and a bot performance database 218. As described previously, bot controls logging database 214 and a bot performance database 218 may be portions of database 136 (of
As indicated, bot controls logging database 214 is in communication with a controls dashboard 216, which may configure or define data storage requirements for bot controls logging database 214, as well as retrieve data for display to a user (such as perhaps user 116 of
As indicated in
An exemplary message sequence may be started by an incoming event 302 such as an invoice exception process. For example, some automated process matching systems used by an operator of an RPA system may match invoice items to received items, identifying invoice items or received items that have no match. The items lacking a match may be placed into an exception queue, and the RPA bot system automates the exception handling. The exception queue is passed into rules engine instance 304 (via incoming event 302). Rules engine instance 304 prioritizes the work, perhaps by ascertaining whether resolving the exception queue has a higher priority than other work that is already within the work queue (such as work queue 150 of
Bot manager 146 handles assignment constraints, such as whether certain bots should be assigned certain tasks. Certain bots may be assigned work tasks based on capabilities and priorities. Additionally, bot manager 146 may inform event manager 144 about the task assignment to WB 308, so that event manager 144 knows to expect a ping or update from WB 308. Upon successfully receiving an indication that WB 308 has begun the task, event manager 144 updates rules engine instance 304 to prevent duplicate assignment of the exception queue task to another WB.
Some possible variations of the process described for
As illustrated bot farm 412 comprises three bots 414, 416, and 418; bot farm 422 comprises three bots 424, 426, and 428; and bot farm 432 comprises three bots 434, 436, and 438. Any of bots 410, 414, 416, 418, 420, 424, 426, 428, 430, 434, 436, and 438 may be stored in WB library 150 (of
In some examples, an alert manager may include a set of response rules such as:
- 1. Evaluate the prioritization of the task assigned to the non-responsive WB.
- 2. Evaluate how many times a bot manager or bot boss (or other module) has tried to ping the WB without a response.
- 3. Analyze rules for restarting the WB.
- 4. If a restart is properly warranted, a Med Bot restarts the WB.
- a. If restart is successful:
- i. Clear alerts/alarms.
- ii. Done.
- a. If restart is not successful:
- i. Send page out alert.
- ii. Return the task to the work que for another WB to take up.
- iii. The returned task may be assigned a higher priority, based on elapsed time.
- iv. Done.
- a. If restart is successful:
In the illustration of
As a result of the missed update (or ping response), bot boss 502 sends a message that WB 506 is unresponsive to alert manager 134, possibly directly, or otherwise perhaps through an event manager or a health monitor. Although
If the med bot is successful (as determined in decision 612) the alert is cleared in box 614. If, however, the restart is unsuccessful, a page out alert is issued in box 616, the unfinished task is returned to the work queue in process box 618, and the prioritization of the task is evaluated in process box 620. The priority may be elevated (changed) to a higher category, or may remain within the same category, but with a FIFO priority based on the original timestamp of when it first entered the work queue, rather than a reentry timestamp. Method 600 then ends (for the restart failure case) with the bot manager entering process box 458 of method 450 (of
In some examples, the operations illustrated in
The disclosure is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the disclosure include, but are not limited to: personal computers, server computers, hand-held or laptop devices, tablet 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.
The disclosure 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, and so forth, which perform particular tasks or implement particular abstract data types. The disclosure 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 local and/or remote computer storage media including memory storage devices and/or computer storage devices. As used herein, computer storage devices refer to hardware devices.
With reference to
The computer 710 typically includes a variety of computer-readable media. Computer-readable media may be any available media that may be accessed by the computer 710 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or the like. Memory 731 and 732 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which may be used to store the desired information and which may be accessed by the computer 710. Computer storage media does not, however, include propagated signals. Rather, computer storage media excludes propagated signals. Any such computer storage media may be part of computer 710.
Communication media typically embodies computer-readable instructions, data structures, program modules or the like in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
The system memory 730 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 731 and random access memory (RAM) 732. A basic input/output system 733 (BIOS), containing the basic routines that help to transfer information between elements within computer 710, such as during start-up, is typically stored in ROM 731. RAM 732 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 720. By way of example, and not limitation,
The computer 710 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, described above and illustrated in
The computer 710 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 780. The remote computer 780 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 710, although only a memory storage device 781 has been illustrated in
When used in a LAN networking environment, the computer 710 is connected to the LAN 771 through a network interface or adapter 770. When used in a WAN networking environment, the computer 710 typically includes a modem 772 or other means for establishing communications over the WAN 773, such as the Internet. The modem 772, which may be internal or external, may be connected to the system bus 721 via the user input interface 760 or other appropriate mechanism. A wireless networking component such as comprising an interface and antenna may be coupled through a suitable device such as an access point or peer computer to a WAN or LAN. In a networked environment, program modules depicted relative to the computer 710, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
An exemplary method for managing RPA bots implemented on at least one processor may comprise: assigning a first task from a work queue to a first bot, using a first translation; assigning a second task from the work queue to a second bot, using a second translation different from the first translation; receiving data from the first bot; responsive to receiving data from the first bot, translating the received data from the first bot using a third translation different from the second translation; storing the translated data from the first bot on a non-transitory computer-readable medium; receiving data from the second bot; responsive to receiving data from the second bot, translating the received data from the second bot using a fourth translation different from the first and third translations; and storing the translated data from the second bot on the non-transitory computer-readable medium.
The method may further comprise monitoring health of the first and second bot; and responsive to detecting non-responsiveness of the first bot, sending a first alert. The method may further comprise responsive to detecting non-responsiveness of the first bot, attempting to restart the first bot. The method may further comprise determining whether the attempted restart of the first bot is successful; and responsive to determining that the attempted restart of the first bot is not successful, returning the first task to the work queue. The method may further comprise responsive to determining that the attempted restart of the first bot is not successful, determining whether the second bot is idle; and responsive to determining that the second bot is idle, assigning the first task to the second bot, using the second translation. The method may further comprise responsive to determining that the attempted restart of the first bot is not successful, sending a second alert; and changing a priority of the first task in the work queue. The method may further comprise determining whether the attempted restart of the first bot is successful; and responsive to determining that the attempted restart of the first bot is successful, clearing the first alert. The method may further comprise evaluating a priority of the first task; activating a med bot; and analyzing rules for restarting the first bot. Translating data received from a bot optionally comprises translating data into a standard format.
Another method for managing RPA bots implemented on at least one processor may comprise: assigning a first task from a work queue to a first bot, using a first translation; assigning a second task from the work queue to a second bot, using a second translation different from the first translation; receiving data from the first bot; responsive to receiving data from the first bot, translating the received data from the first bot into a standard format using a third translation different from the second translation; storing the translated data from the first bot on a non-transitory computer-readable medium; receiving data from the second bot; responsive to receiving data from the second bot, translating the received data from the second bot into the standard format using a fourth translation different from the first and third translations; storing the translated data from the second bot on the non-transitory computer-readable medium; monitoring health of the first and second bot; and responsive to detecting non-responsiveness of the first bot: sending a first alert; attempting to restart the first bot; determining whether the attempted restart of the first bot is successful; responsive to determining that the attempted restart of the first bot is successful, clearing the first alert; and responsive to determining that the attempted restart of the first bot is not successful: sending a second alert; returning the first task to the work queue; determining whether the second bot is idle; and responsive to determining that the second bot is idle, assigning the first task to the second bot, using the second translation.
A system for managing RPA bots implemented on at least one processor may comprise: a processor; and a non-transitory computer-readable medium storing instructions that are operative when executed by the processor, the instructions comprising logic for implementing any of the methods or processes disclosed herein.
Alternatively, or in addition to the other examples described herein, examples include any combination of the following:
-
- monitoring health of the first and second bot;
- responsive to detecting non-responsiveness of the first bot, sending a first alert;
- responsive to detecting non-responsiveness of the first bot, attempting to restart the first bot;
- determining whether the attempted restart of the first bot is successful;
- responsive to determining that the attempted restart of the first bot is not successful, returning the first task to the work queue;
- responsive to determining that the attempted restart of the first bot is not successful, determining whether the second bot is idle;
- responsive to determining that the second bot is idle, assigning the first task to the second bot, using the second translation;
- responsive to determining that the attempted restart of the first bot is not successful, sending a second alert;
- changing a priority of the first task in the work queue;
- responsive to determining that the attempted restart of the first bot is successful, clearing the first alert.
- evaluating a priority of the first task;
- activating a med bot;
- analyzing rules for restarting the first bot; and
- wherein translating data received from a bot comprises translating data into a standard format.
The examples illustrated and described herein as well as examples not specifically described herein but within the scope of aspects of the disclosure constitute an exemplary entity-specific value optimization environment. The order of execution or performance of the operations in examples of the disclosure illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and examples of the disclosure may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the disclosure.
When introducing elements of aspects of the disclosure or the examples thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. The term “exemplary” is intended to mean “an example of” The phrase “one or more of the following: A, B, and C” means “at least one of A and/or at least one of B and/or at least one of C.”
Having described aspects of the disclosure in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the disclosure as defined in the appended claims. As various changes could be made in the above constructions, products, and methods without departing from the scope of aspects of the disclosure, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
While the disclosure is susceptible to various modifications and alternative constructions, certain illustrated examples thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the disclosure to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the disclosure.
Claims
1. A system for managing robotic process automation (RPA) software robots (bots) implemented on at least one processor, the system comprising:
- a processor; and
- a non-transitory computer-readable medium storing instructions that are operative when executed by the processor, the instructions comprising logic for:
- assigning a first task from a work queue to a first bot, using a first translation;
- assigning a second task from the work queue to a second bot, using a second translation different from the first translation;
- receiving data from the first bot;
- responsive to receiving data from the first bot, translating the received data from the first bot using a third translation different from the second translation;
- storing the translated data from the first bot on the non-transitory computer-readable medium;
- receiving data from the second bot;
- responsive to receiving data from the second bot, translating the received data from the second bot using a fourth translation different from the first and third translations; and
- storing the translated data from the second bot on the non-transitory computer-readable medium.
2. The system of claim 1 wherein the instructions further comprise logic for:
- monitoring health of the first and second bot; and
- responsive to detecting non-responsiveness of the first bot, sending a first alert.
3. The system of claim 2 wherein the instructions further comprise logic for:
- responsive to detecting non-responsiveness of the first bot, attempting to restart the first bot.
4. The system of claim 3 wherein the instructions further comprise logic for:
- determining whether the attempted restart of the first bot is successful; and
- responsive to determining that the attempted restart of the first bot is not successful, returning the first task to the work queue.
5. The system of claim 4 wherein the instructions further comprise logic for:
- responsive to determining that the attempted restart of the first bot is not successful,
- determining whether the second bot is idle; and
- responsive to determining that the second bot is idle, assigning the first task to the second bot, using the second translation.
6. The system of claim 4 wherein the instructions further comprise logic for:
- responsive to determining that the attempted restart of the first bot is not successful, sending a second alert; and
- changing a priority of the first task in the work queue.
7. The system of claim 3 wherein the instructions further comprise logic for:
- determining whether the attempted restart of the first bot is successful; and
- responsive to determining that the attempted restart of the first bot is successful, clearing the first alert.
8. The system of claim 2 wherein the instructions further comprise logic for:
- evaluating a priority of the first task;
- activating a med bot; and
- analyzing rules for restarting the first bot.
9. The system of claim 1 wherein translating data received from a bot comprises translating data into a standard format.
10. A method for managing robotic process automation (RPA) software robots (bots) implemented on at least one processor, the method comprising:
- assigning a first task from a work queue to a first bot, using a first translation;
- assigning a second task from the work queue to a second bot, using a second translation different from the first translation;
- receiving data from the first bot;
- responsive to receiving data from the first bot, translating the received data from the first bot using a third translation different from the second translation;
- storing the translated data from the first bot on a non-transitory computer-readable medium;
- receiving data from the second bot;
- responsive to receiving data from the second bot, translating the received data from the second bot using a fourth translation different from the first and third translations; and
- storing the translated data from the second bot on the non-transitory computer-readable medium.
11. The method of claim 10 further comprising:
- monitoring health of the first and second bot; and
- responsive to detecting non-responsiveness of the first bot, sending a first alert.
12. The method of claim 11 further comprising:
- responsive to detecting non-responsiveness of the first bot, attempting to restart the first bot.
13. The method of claim 12 further comprising:
- determining whether the attempted restart of the first bot is successful; and
- responsive to determining that the attempted restart of the first bot is not successful, returning the first task to the work queue.
14. The method of claim 13 further comprising:
- responsive to determining that the attempted restart of the first bot is not successful,
- determining whether the second bot is idle; and
- responsive to determining that the second bot is idle, assigning the first task to the second bot, using the second translation.
15. The method of claim 13 further comprising:
- responsive to determining that the attempted restart of the first bot is not successful, sending a second alert; and
- changing a priority of the first task in the work queue.
16. The method of claim 12 further comprising:
- determining whether the attempted restart of the first bot is successful; and
- responsive to determining that the attempted restart of the first bot is successful, clearing the first alert.
17. The method of claim 11 further comprising:
- evaluating a priority of the first task;
- activating a med bot; and
- analyzing rules for restarting the first bot.
18. The method of claim 10 wherein translating data received from a bot comprises translating data into a standard format.
19. One or more computer storage devices having computer-executable instructions stored thereon for managing robotic process automation (RPA) software robots (bots), which, on execution by a computer, cause the computer to perform operations comprising:
- assigning a first task from a work queue to a first bot, using a first translation;
- assigning a second task from the work queue to a second bot, using a second translation different from the first translation;
- receiving data from the first bot;
- responsive to receiving data from the first bot, translating the received data from the first bot into a standard format using a third translation different from the second translation;
- storing the translated data from the first bot on a non-transitory computer-readable medium;
- receiving data from the second bot;
- responsive to receiving data from the second bot, translating the received data from the second bot into the standard format using a fourth translation different from the first and third translations;
- storing the translated data from the second bot on the non-transitory computer-readable medium;
- monitoring health of the first and second bot; and
- responsive to detecting non-responsiveness of the first bot: sending a first alert; attempting to restart the first bot; determining whether the attempted restart of the first bot is successful; responsive to determining that the attempted restart of the first bot is successful, clearing the first alert; and responsive to determining that the attempted restart of the first bot is not successful: sending a second alert; returning the first task to the work queue; determining whether the second bot is idle; and responsive to determining that the second bot is idle, assigning the first task to the second bot, using the second translation.
20. The one or more computer storage devices of claim 16, wherein the operations further comprise:
- evaluating a priority of the first task;
- activating a med bot; and
- analyzing rules for restarting the first bot.
Type: Application
Filed: Mar 29, 2019
Publication Date: Oct 3, 2019
Inventors: Chris Van Briggle (Bentonville, AR), Blake Hazelwood (Centerton, AR)
Application Number: 16/370,653