工作队列（Work Queue）

工作队列（Work Queue）

工作队列是一种企业级任务管理协同机制。在RPA领域，工作队列通常指将以业务视角出发的单一工作任务放入工作队列池，再按需执行的过程。这些单一工作任务，往往是指每一笔工单，每一笔业务数据，或每一条数据记录等。

机器人资源池（Robot Resource Pool）

机器人资源池一般指可以投入到实际流程执行的机器人Agent集合。机器人资源池一般也会包含有动态机器人调度功能，但是前提必须是多个机器人Agent都包含有某一个流程的前提环境和权限。

注意：工作队列与机器人资源池是两个不同维度的概念。

机器人资源池：

1）初始功能：指配置了一批相同环境的机器人Agent ，流程执行的时候挑选其中一个空闲机器人执行流程。

2）进阶功能：执行某一个流程的时候发现1号机器人失败了，那么让2号机器人从头开始重新执行这个流程。（至于1号机器人失败前做了多少工作，哪些应该被重做是没有概念的）

工作队列中的颗粒度更细，是基于一笔笔具体的工作。

工作队列的应用包含两部分

第一部分-将工作放入队列

第二部分-从队列拿工作

从工作队列拿工作一般分为两类

【单机器人读取：】

单机器人读取工作队列的原因有以下几点：

一、为了精确追踪业务指标：某一笔交易从什么时候开始被机器人执行、什么时候结束的、结果是如何？

二、为了标记流程中间过程步骤状态：流程第一步，成功还是失败；第二步，成功还是失败；第三步，成功还是失败；如果流程重做，已经操作过了的步骤是否还可以被重复覆盖执行？（这部分的逻辑会在流程设计中体现）

【多机器人协同读取：】

多机器人协同读取最大优势：

一、业务分流：不论业务增长有多快，都可以轻松扩展机器人资源，避免重负荷工作全部由单一机器人实现。多个机器人读取最新的工作任务，或者根据TAG标签挑选符合要求的工作任务。

二、多机器人协同：某一个机器人出现意外，不影响整体任务作业；可以按需及时动态增删工作流程的工作机器人数量。

三、中间过程标记。不论是哪个机器人处理的某笔业务，该笔业务前三步已经被执行过了，那么下一个接手该工作的机器人就可以直接跳至第四步去执行。

四、时间窗口/业务笔数等特殊需要：某业务只能在特定的时间窗口执行，需要在那个时间窗口部署多个机器人。

工作队列业务报表：

【场景举例1：】

试想下面这个场景，一条流水单的多项金额需要对账（需要确认金额数字对不对。）第一项金额是XXX总计金额，需要去登陆系统A的查询界面，通过查询后，计算查询结果的总计金额，确认这个查询的总计金额是否和流水单中的XXX总计金额一致。第二项到第六项金额需要登陆系统B，进入每周报告页面下载该流水单的财务报表，抓取财务报表中的5个指定部分的数字来比较是否一致。第七项金额需要登陆系统C。如果账目都对，最后需要登陆系统D，新建单据，把这7项数据录入进去。

假设说，机器人从工作队列中获取了这条流水单的单号，它成功的从本地系统中查询出流水单的7个金额，成功的去系统A中比较完数据，又成功的在系统B中比较完数据。但是由于系统C出故障处于维护阶段，登陆不进去了。那么后面的流程都走不下去，就直接报Exception了。后面每条流水单不是都会在做系统C的时候报错吗？所有的数据就这样一天全部浪费，付之东流水了吗？答案是否定的。

在机器人的每次抛出错误时，会和前一次抛出的错误做比较，如果相同类型错误重复出现达到一定次数时，机器人自动停止，不再做操作，等待一段时间间隔重试，或者发送人工介入请求，等待人工确认修复。如果系统C只是短暂的无法登陆，后面的数据能正常登陆时，这个错误数据会清 0。

在系统C修复后，上一次错误的数据还需要重新抓取放入队列里吗？不用，某些重跑一次可以修改的异常，Work Queue不需要重新获取input数据放入队列，会判断异常类型，自动进行强制Retry。

Uipath的Work Queue会强制Retry ApplicationException的Case，BusinessException不会Retry（是否Retry，Retry次数在创建队列时自己设置，创建完后不可修改）。BluePrism的Work Queue由于状态可以自由配置，什么状态要Retry，Retry多少次，什么时候Retry，都可以自己设计，Work Queue即使创建完了，也可以自由修改，比较灵活。

问题来了，Retry后，我还要再去系统A和系统B中做一次重复的动作吗？假如去系统A和系统B分别需要10分钟，20分钟这不是浪费时间吗？在Blue Prism的WorkQueue里，答案是否！Blue Prism的WorkQueue可以直接跳过系统A和系统B，直接从系统C开始做。因为标记了中间过程，看下图。

机器人在获取该条工作的时候，会通过状态（status）判断应该从哪个步骤开始执行。Work Queue可以执行一个步骤标记一个步骤状态，以免重复工作。Uipath的Work Queue是没有这个功能的，只能标记总完成状态和Exception状态。

还是会有人坚持就是不用Work Queue，可以使用多台机器人分别批量执行不就行了吗？

【场景举例2：】

假设现在有300条数据，需要3个机器人同时分别执行5个小时才可以完成，每人做100条数据。先把100条数据分别分配给3个机器人，3小时之后，其中一个机器人发生故障（另外两个机器人正常），还剩40条数据没有处理。

如果选择Work Queue工作队列机制，其中一台出问题，剩下的40条会分配给另外两个机器人继续做。当面对更多数据，上万条甚至百万条的时候，如果没有Work Queue做管理协调，很难保障同时在工作的100个机器人都不会出现意外。在人工来不及排查的情况下，Work Queue可以让状态好的机器人，或者备用机器人立刻启动继续执行工作任务。业务数据滞留不做，这对“大厂”来说，会有多少损失呢？

由此可见，为什么要用Work Queue，突然让我想起了团结的力量大，Work Queue就像是一根让大家团结起来一起工作的纽带。