R017---RPA从业者的"内心董事会"

缘起

RPA项目上最近一直有个比较挠头的现象：由于前序子流程，没有及时更新其完成状态，导致后续子流程没有接续执行。

原因分析

RPA的流程一长，免不了逻辑考虑不周或者某个流程涉及的内容发生了结构变化，导致程序未能按预想的流程运行，断在某个你事先不能猜到的地方。

为了解决这种问题，UiPath提供有Try Catch机制，合理利用可以解决大部分此类问题。

但是问题没有这么简单，因为随着流程的增多，我们需要流程运行结果反馈的机制，以便我们知道每一步运行正常，这就导致前序子流程没有更新状态表的情况，导致后续流程卡壳，浪费了机器人的工作时间。

"内心董事会"

中午跟昂昂聊天时，说起这个问题，触发大脑内部进行了一个短暂的董事会：

当大脑听到我给昂昂说这个问题时，爱幻想的董事A慢条斯理地说：如果有一种能把这种问题通过程序查询出来，并及时解决掉这个问题，是否有可能？

听到此话，擅长逻辑思维的董事B迅速提出个问题：这个现象的逻辑是什么？并尝试回答：根据主程序的设计，同时只允许运行一个子流程，当主流程运行某个子流程时，不可能去寻找后续子流程运行；如果出现寻找新的子流程的情况，说明前序流程已经完成（无论对错），也就是，前序子流程应该是完成状态，而不是运行中，所以，目前这个现象是一种错误，需要通过一种检查机制，在主程序开始寻找后续子流程运行前，检查其状态表是否更新完成，如果因为某个未知异常，导致没有执行状态更新程序，检查机制应该给前序流程补上这个操作，而且要让监察人员知道是主程序后续补救了这个操作，而不是程序正常执行完成，从而开发/维护人员会对此类问题进行bug排查，让程序更具“鲁棒性”。

听完董事B的分析，董事C表示赞同，并尝试用更简化的语言和逻辑，跟外界说明这个分析是对的，以便外部也确认这种逻辑是否合理，经过2个靠谱的确认，决定在每个子流程完成后，增加该检查机制，董事C对解决方案进行了拍板，并把此事交给了董事D。

董事D拿着方案，如获至宝，飞做电脑前，三下五除二，搞定。

董事E开始测试检查机制的正确性，可能是D太兴奋，程序还是出了点bug，经过修正，大功告成！

一直没说话的董事F看到事情的来龙去脉、今生来世，默默写了一篇《RPA从业者的"内心董事会"》，用于纪念这个从现象，到头脑风暴，到逻辑分析，到解决方案等一系列过程的短篇小说；董事F写完后，心里想，这能否成为RPA从业者的睡前故事呢？！但愿听了的人能做个好梦，把他的棘手问题，得以更好的处理。

总结

如同《R015---RPA中的多机器人如何协作？》一文中，机器人领取任务后，需要确认检查一遍一样，这里也增加了一个检查机制。

看完这个睡前故事，董事G陷入深深的思考：逻辑问题的解决，是不是都需要一个检查机制来验证呢？

我去，睡不着了，这是哪门子的睡前故事，简直是逻辑推理的侦探小说，烧脑...

（正文结束）

附1：关于本公众号

微信公众号ID：RPA-UiPath-BPC-EDU

微信公众号名称：柴班说

欢迎您的关注和阅读，希望这篇文章能为您带来帮助。

欢迎转载与分享，也请注明出处。

如果您有需要了解的关于RPA、UiPath、BPC的其他内容，也可以给我留言或发邮件（chaijw@126.com）

识别下面的二维码，或者直接搜"柴班说"，或者RPA-UiPath-BPC-EDU，可以关注本公众号。

我们的RPA公众号

微信公众号ID：RPA2018

微信公众号名称：RPA流程自动化机器人

如果您有需要了解的关于RPA的内容，也可以给该公众号留言或发邮件 （rrenzixu@126.com）。

识别以下二维码，可以关注RPA公众号。

本文作者

微信号：chaijw

识别右侧二维码

可以与作者进行更为深入的交流。