简介
RPA的执行除了无人值守的方式外在某些长链式的业务场景下还需要人员的介入，例如业务人员确认后方可进行后续操作。介于此，交互式RPA便应运而生，本文仅探讨交互式RPA的实现思路以及一些可行方案的简介，详细的落地方案不在本文讨论范围。
交互流程
- 正常流程：触发-校验-适配-执行-提交-反馈
- 交互流程一：触发-校验-适配-确认-执行-提交-反馈
- 交互流程二：触发-校验-适配-执行-确认-提交-反馈
- 交互流程三：触发-校验-适配-执行-确认-执行-确认-提交-反馈
交互式RPA本质上是实现人机交互，通过人的介入来更好的完成长链式任务。
人员介入后可进行外部业务逻辑处理，例如数据填写、数据确认、流程回退等等，业务人员的外部操作所产生的数据可以返回并转化为RPA的执行参数。涉及到数据相关的人机交互相当复杂，这里仅仅讨论简单的“确认”逻辑，不涉及数据交互。
针对RPA执行过程的确认可以通过表格/截图/视频的方式进行，或者借助短信、微信、钉钉、app等平台进行确认，确认的过程仅仅是动作的反馈不涉及业务数据交互。
脑洞大开
思路一：前段式确认
采用交互流程一的方式，在执行RPA前将提交数据进行校验和适配并以数据表格方式展示和确认
优点：效率高，节省服务器资源，RPA成功执行只需执行一遍
缺点：确认的成功率存在风险，可视化不友好，改造成本中等
思路二：一遍式确认-服务器单用户
采用交互流程二的方式，RPA仅被触发一遍，当执行到提交节点前时正在执行的RPA程序将暂时停止并等待人员确认，此时服务器仅支持单用户账户同时操作。
优点：执行一遍节省时间
缺点：服务器资源占用、RPA需要断点改造
思路三：一遍式确认-服务器多用户
采用交互流程二的方式，RPA仅被触发一遍，当执行到提交节点前时正在执行的RPA程序将暂时停止并等待人员确认，此时服务器可支持多用户账户同时操作。
优点：执行一遍节省时间，多用户提高服务器利用率
缺点：RPA需要断点改造，需要服务器配置
思路四：一遍式确认-浏览器多开隔离
采用交互流程二的方式，RPA仅被触发一遍，当执行到提交节点前时正在执行的RPA程序将暂时停止并等待人员确认，此时浏览器可支持多开并相互不影响。
优点：执行一遍节省时间，多开浏览器提高服务器利用率
缺点：RPA需要断点改造，浏览器多开和隔离技术难度大
思路五：两遍式确认-利用真实提交
采用交互流程二的方式，RPA执行两遍，第一遍执行到提交功能前结束，此时RPA资源释放、服务器资源释放并将执行视频反馈至操作人员，操作人员确认无误后将触发第二遍RPA程序，此时重新组织数据并提交。
优点：改造成本低，可靠性高，提交数据中途可变
缺点：流程耗时长，RPA无需改造，配套系统需要改造
思路六：两遍式确认-适配数据预留
采用交互流程二的方式，RPA执行两遍，第一遍执行到提交功能前结束，此时RPA资源释放、服务器资源释放并将执行视频反馈至操作人员，操作人员确认无误后将触发第二遍RPA程序，此时获取历史数据并重新提交，直接跳过数据的适配和校验。
优点：改造成本中等，可靠性高，耗时中等
缺点：系统改造成本中上
思路七：长链任务编排
采用交互流程三的方式，针对长链业务、多人员交互业务、个性化执行调度需求等可以采用长链任务编排的方案。该方案下将对长链任务为N段，每一段可单独成为独立业务执行调度，N段任务可进行自由编排。
特点：
- 灵活编排：可以针对不同分公司甚至不同业务人员进行个性化编排
- 权限控制：每一段RPA任务可自由组合编排
- 数据校验：每一段的数据入口和出口均可校验
- 数据控制：人机交互产生的数据可反馈至RPA端成为参数继续执行
- 消息通知：更加个性化的消息通知，钉钉、微信、短信、平台、邮件
- 业务确认：跟家多样化且灵活的确认方式，钉钉、平台
- 日志回滚：单节点出错可回滚至上一节点，根据日志可以自由还原操作流程
受限于服务器资源，其实现也必将考虑执行一遍和执行多遍等方式，具体如下：
一遍式单用户—不可取/资源占用严重
一遍式多用户—可取
多遍式单用户—可取/资源占用可接受
多遍式多用户—可取/资源占用少
版权声明：本文为博主原创文章，欢迎转载，转载请注明作者、原文超链接，感谢各位看官!!!
本文出自：monkeyGeek
座右铭：生于忧患，死于安乐
欢迎志同道合的朋友一起交流、探讨！
monkeyGeek