UiPath实践经验总结(二)

1.       UI操做容易受到各类意外的干扰，所以应该缩短UI操做阶段的整体时间。而为了缩短UI操做阶段的整体时间，应该将UI操做尽可能放在一块儿，将后台的各类操做尽可能放在UI操做的先后。例如，如今有一个Assign和两个Click须要执行，那么比较推荐的设计是Assign->Click->Click或者Click->Click->Assign，而不是Click->Assign->Click。集中的UI操做也会给人一种“机器人很是高效”的观感，留下较良好的印象。

2.       为了确保“增长一倍的投入就必须相应提升一倍的效率”，流程的整体设计要尽可能将问题转化为事务式（Transactional）处理的模式。这是什么意思呢？假设如今有一份Excel表格记录了宾客列表，机器人要读取这份列表，为每位宾客生成一份Word请柬，而后以邮件形式发送出去。有一种流程设计思路是这样的，机器人读取宾客列表ABC后，为A生成请柬->为B生成请柬->为C生成请柬->向A发送邮件->向B发送邮件->向C发送邮件。这种流程设计模式虽然逻辑上没有错，可是多机器人共同协做时分割工做负载相对比较困难，很难确保“增长N倍数量的机器人能够以相应提升N倍的处理能力”。所以，应该尽量的将流程设计为，机器人读取宾客列表ABC后，为A生成请柬->向A发送邮件->为B生成请柬->向B发送邮件->为C生成请柬->向C发送邮件。能够看到在这个例子中，一个事务包含“生成一个请柬”和“相应地发送一封邮件”两个操做。只有事务中的操做所有成功，才能够断定事务成功。不然事务中的任何一个操做失败，即认定事务失败。事务失败能够停止运行，也能够跳过失败的事务，继续运行下一个事务。当增长机器人数量时，只需经过简单地分配事务，便可达到充分利用机器人效能的目的。

3.       凡是须要人工输入的环节，就必定会出错，所以绝对不能信任人工输入的数据。那么对于人工输入的问题，有几种办法能够提升稳定性。

a.       对人工输入进行严格约束和校验，拒毫不符合要求的数据。（不推荐，但有时候不得不这么干）

b.       设计时加入必定的弹性以实现容错的能力。

c.       减小人工输入的环节，减小人工输入的数据量。

d.       设法尽量地为人工输入进行辅助，好比弹出相关提示，给出格式示例等等。

4.       当须要处理文件关系时，有几种办法能够在文件之间体现关联：

a.       用某种命名规则来确保文件关联。好比说，有一个Excel文件为叫小明_总成绩.xlsx，而另外一个Excel文件为小明_语文成绩.xlsx，这里文件的命名规则是“学生姓名_科目成绩.xlsx”，那么能够认为小明_总成绩.xlsx和小明_语言成绩.xlsx是相关的文件。

b.       创建一个表格用于存储文件关系。这样文件能够经过这张表来查找，不须要特别指定命名规则。好比

学生姓名	总成绩文件	语文成绩文件
小明	AAA.xlsx	BBB.xlsx
小红	CCC.xlsx	DDD.xlsx

5.       UiPath Studio项目目录里的文件在每次发布到UiPath Robot时都会相应地新建，所以须要持久化存储的数据（好比配置文件）不该该存储在UiPath Studio项目目录里。建议用Get Environment Folder(UiPath.Core.Activities.GetEnvironmentFolder)存储在某个系统自带的文件夹下（推荐保存到MyDocuments）。

6.       机器人每每须要可以自动登陆各类系统，而各类系统每每须要凭据（用户名+密码）才能登陆。能够将登陆凭据保存在Windows自带的凭据管理器，而后用Get Secure Credential(UiPath.Credentials.Activities.GetSecureCredential)去读取。须要输入密码时不要用Type Into，必须用Type Secure Text。采用Get Secure Credential + Type Secure Text的组合，机器人能够作到全程不接触密码明文，相对安全。

7.       使用Get Text或者Get Attribute从网页上获取的原始内容应该用Log Message保存到日志里以便于查错。

8.       在Excel中填入URL会被自动转化为超连接，可是若是UiPath须要读取这个URL，那么须要移除这个超连接，不然会报错。

9.       注意生产环境与开发、测试环境的差别，容易致使意想不到的异常。也所以，大致上，开发流程所需的时间≈调整稳定性所需的时间≈迁移到新环境测试调整所需的时间。任何环境因素的变化都须要从新测试以确保稳定性。

10.   加入源代码管理的时候，UiPath Studio里项目目录.screenshots下的内容也必须所有加入源码管理。

11.   每次运行都须要保存一个配置文件的副本，以备查错。

12.   若是须要创建自定义日志，流程运行的最初步骤将已存在的"C:\Users\你的用户名\AppData\Local\UiPath\Logs\日期_Execution.log"文件改掉名字，而后在运行中用Log Message记日志。UiPath会自动建立新的日志文件，而后在运行的最后将这个日志文件复制出来便可。经过这种方式能够简化自定义日志的工做，并且必要时能够改变日志级别以获取更多信息用于查错。

13.   流程较长时，能够分割为多个阶段来开发，每一个阶段流程用一个.xaml文件来处理。分割的原则大致上是，给定机器人一个文件A，机器人通过阶段性的UI或者后台处理，必定能够产生文件B。那么只须要将A的完整路径做为这个.xaml文件的输入参数，而将B的完整路径做为输出参数，便可很方便地开发调试这个流程。当有多人一块儿协做开发同一个流程时，只要这样分割为多个小流程，而且详细约定好中间文件的各项内容，就能够同时进行。这种方式也称为“面向接口编程”。

14.   当RPA项目团队有多人开发时，每人负责一个流程的组织模式有可能形成每一个流程都赶不完的局面。不如将单个流程划分红更小的流程，一块儿协同进行一个流程的开发，这样团队在预期的时间内能够完成尽量多的流程，而不是制造大量完成度良莠不齐的流程。特别是，团队成员能够不须要了解流程的全貌，只了解流程的局部便可，实现流水线式的开发管理。而对流程掌握最全面的成员，能够少承担一些开发工做，但须要负责不断地进行集成测试，由这我的来负责交付完整的UiPath Project。

15.   编辑Selector时，要善用相对Selector和部分Selector，例如Anchor Base，Element Scope，Find Relative Element， Get Ancestor。

16.   开发的最初不该该加入任何Try Catch，以便在测试中发现会产生Exception的位置，以及Exception的类型，并进行相应地处理。即便逻辑实现确实须要加入Try Catch，也切忌直接Catch System.Exception，防止预期外Exception类型没法在Catch中正确处理。但最后必定要在最外层套一个Try Catch，以处理预期外的Exception。

17.   Get Text获取的数据是UiPath.Core.GenericValue类型，须要输出为特定格式字符串的时候，能够尝试使用Format Value（UiPath.Core.Activities.FormatValue）。

18.   目前大多数RPA的使用场景只是数据处理领域ETL工做的变种，所以能够尽可能参考ETL的设计思想和有益经验。

19.   每一个Activity都必须命名，必要时还须加上Annotation进行解释说明。参数和变量也是如此。