最近经常被问到，如何构建更加具有弹性Resilience和稳定性Robust的RPA代码？由于RPA机器人大多是依据过程化的脚本来执行的，任何流程的流程变动，规则变动，界面变动都有可能会影响到原来机器人的代码，这就是为什么开发者如此关心此类问题的原因。
首先解释一下什么是“弹性Resilience”和“稳定性Robust”。
- 应用程序或软件系统的弹性Resilience是指不通过修改程序代码或者非常少量的修改代码就能适应不同业务场景以及业务需求变化。
- 应用程序或软件系统的稳定性Robust，也被称为鲁棒性，也是健壮和强壮的意思。是指在出现环境异常和危险的情况下，RPA代码仍旧可以运行，不会出现崩溃和退出的现象，并且下次调用该机器人仍旧可以执行。
在RPA项目中，通常有两个维度来解决弹性和稳定性的问题。一是RPA产品的能力，二是自动化流程的设计，三是自动化流程的变更维护。
RPA产品的能力
在AAE 11.3.x中提供了Error Handling这个Command，用于处理各种异常情况，相当于编程中的try catch。用Begin和End的方式，捕获中间代码可能产生的异常。
基于这个异常，可以实现各种相应的处理手段，例如是继续还是停止这个任务，是否截取错误发生时的界面，可以运行另一个任务来做补救处理，也可以记录日志，保存这条错误信息，可以发送邮件通知相关人员，或者记录到某个变量里，作为后续的一个标志位或者数值进行传递，也可以设置这个任务执行的状态。
在A2019中的Error Handling命令，直接采用了Try Catch的方法。可以捕捉Try中执行步骤的异常，捕捉异常以后执行Catch中的内容，例如记录日志，抓取屏幕等任何动作，在执行完Try Catch后，最终执行Finally中的步骤，例如关闭窗口，清除进程之类的工作。
自动化流程的设计
为了保持代码的弹性和稳定性，在设计层面也考虑很多内容。
1. 通过配置文件读取动态的配置信息。为了保障机器人在不同环境和不同条件下的使用，用户可通过配置文件来初始化很多环境变量，例如目录结构、环境信息、状态值等。在机器人运行的开始，先读取这个配置文件后，再进行后续的业务处理。例如将变量存在xml文件中，然后Bot主任务调用的第一个子任务就是读取环境变量。
2. 通过Bot调用结构的设计实现Bot的共享和复用。一个Bot的设计行数通常不能超过150行，否则难以修改和维护。为了能够避免机器人代码的重复开发，需要将相同的处理结构封装成子任务流程，供其他流程来调用。这样，一旦修改了该子任务，就相当于调整了所有调用该子任务的主流程。
3. 通过专门的检查机器人完成对流程输入文件的检查，避免在执行过程中发现异常。一是检查输入文件是否存在，二是检查输入文件的格式是否满足要求，三是检查输入文件的数据是否具有逻辑上的一致性，如开始日期必须小于终止日期等这样的规则判断。由于只是检查输入文件，并不会影响到真正的业务处理环节，就可以避免在业务处理各种异常情况。
4. 执行初始或清理任务，保证机器人环境的稳定性。在任务执行的开始时，例如需要清理剪贴板，清理之前循环中的变量值，关闭已经打开的浏览器等等。在任务执行完成以后，需要关闭已经打开的程序，关闭浏览器，杀死进程等。
5. 通过机器人设计框架规范Bot的开发。机器人设计框架既包含变量的命名规范，记录日志，代码注释等常规的机器人编码要求，也包括规范机器人的整个处理过程，例如1.读取配置文件；2.检查输入文件；3.清理机器人执行环境；4.正常的业务流程处理；5.异常情况处理；6.清理程序和环境。
6. 利用高可用的部署方式解决机器人自身可能出现的问题。例如RPA平台中的某个机器人自身发生了运行错误，中断自动化处理流程。那么RPA平台可以采用负载均衡和机器人动态控制机制，将自动化任务分配给其他没有问题的机器人来处理。即便是整个RPA平台出现了问题，也可以通过高可用（High Availability，HA）和灾备机制（Disaster Recovery，DR）来解决这类异常问题。
如何保证机器人在某次异常中断后，下次启动时仍可以正常的继续执行？
如果是要完整的回答这个问题，还是较为复杂的，因为其中涉及到的业务场景非常多，但主要还是从机器人的设计角度着眼考虑。
1）如果中断的那个步骤，是可以重复执行的，就无关紧要了。例如由于网页没打开，导致的机器人执行异常。下次机器人执行时，继续完成打开动作就好了。
2）如果机器人处理的是多行数据，在执行到某行出错时，就需要保证下次启动时必须从出错的这行重新启动，而不能从第一行再开始执行。这就要求利用Error Handling捕捉到这个处理异常，通过设置标志位或记录日志的方式记录下这个出错的位置。而下次机器人启动时，应首先读取到这个标志位再来运行。
3）如果机器人处理后一个子任务出错，而需要回滚前一个任务时，就需要利用Error Handling捕捉到这个处理异常后，调用一个补偿任务，反向处理前一个任务。
也许还有更多的可能处理方式，但这都需要结合业务场景和业务逻辑。很多业务流程本身是无法反复处理的，就像人犯了错误以后，有些过失是可以弥补的，有些却不能，其实机器人模拟人的操作过程，原理也是一样的。
不管是产品功能也好，还是设计方法也好，可以被避免的永远是已知的异常情况，对于未知的异常情况，机器人是无能为力的。同时需要机器人的管理人员做好心态上的调整。业务用户也需要有一定的同理心去理解这种现象，就像一个新员工刚刚入职接受一份新的工作时，总会有些磕磕绊绊，手忙脚乱的现象也是正常的。但是经过一段时间的学习之后（对于问题的修复），新员工就会随着经验的积累（自动化程序的健壮性）逐步减少工作中的错误。机器人也是同样的道理。
对于这些未知的需求变化或未知的异常情况，只能通过后续的机器人运维工作来不断弥补。
自动化流程的变更维护
除去机器人自身代码的bug以外，机器人的变更维护主要分为三种情况，一种是遇到了从未考虑到的异常情况。二是业务规则和处理流程发生了变更。三是所操作的载体发生了变化，比如需要自动化处理的用户界面。
第一种情况，需要通过采集运行日志和截屏获取异常发生的原因，通过修复代码，增加分支判断条件，新的异常处理能力的方式来解决这类问题。
第二种情况，最好在设计之初，就考虑那些可能变化的业务规则，将其设计成参数或变量，通过配置文件来保存，直接让业务用户修改配置文件即可。对于那些没有放入配置文件的变量，可以将其单独定义一个独立的机器人，并教会业务人员自己去维护。这样的代码维护方式既保证了整体机器人程序的稳定性，又保证业务上的灵活性。
第三种情况，当页面变化时，首先需要找到操作该页面的所有机器人流程，再分析其对该页面做出了何种自动化操作，以判断页面修改是否会影响原流程的处理。当了解到影响步骤时，就需要重新抓取界面对象，在对该流程完成回归性测试。
综上所述，构建更具弹性和稳定性的RPA机器人，需要从产品、设计和维护等方面多管齐下，在实施和运行过程中充分吸取经验教训，参考行业内的最佳实践，才能打造出一支强有力的机器人队伍。
