RPA之家（）是中国具有影响力的RPA垂直交流社区，社区汇聚了RPA领域的各类从业人员。其中包括RPA开发工程师、售前工程师、业务分析师、架构师、运维工程师、项目管理、项目负责人、企业高管、HR等多种角色。社区提供了各种丰富的教程、资讯、文章、问答、招聘、活动、项目等供大家一起交流和成长。

PA（Robotic Process ，机器人流程自动化）是当今IT界的热门话题，当前最大的两个参与者是UiPath和微软。

对这两款RPA产品，我们进行了相关验证的实践和评测。 本文从产品的组件、系统架构、流程开发、培训和支持、License等方面进行解读。

1 组件

UiPath

UiPath平台由三个集成组件组成：UiPath Studio、UiPath Robot和。

Power

Power 是一个SaaS级的多功能工作流引擎，与微软CDS、数据连接器、AI Builder结合为工作流自动化构建无数可能。

2 系统架构

UiPath

UiPath本地版是CS架构，客户端+IIS Web服务器+SQL Server。、Studio和Robots相对独立。

用于管理Studio、Robots及Robot所在的Machine，配置流程至Robot上，监控流程运行情况。

Studio用于开发和调试流程，并通过HTTPS协议发布流程到中。

Robots用于执行流程，通过HTTPS协议连接到上。

UiPath官方也提供端到端的自动化云平台，或用户将部署到公有云或者私有云上。Studio和Robots通过HTTPS协议连接到云平台。

Power

Power 是一项用于开发和调试自动化工作流的联机服务，集成于微软的Power 平台。该平台根植于微软智能云，以 Azure为基础，无缝衔接CDS、人工智能、DevOps等云服务，可以支持和扩展 365、 365等。云和本地数据之间的自动化通过构建自定义数据网关来实现。

3 流程开发

UiPath

UiPath的流程没有像Power 那样细分，大致可分为“有人参与的业务流程”和“无人参与的业务流程”，按约定的业务规则一步步处理，最终取得预期业务成果。无人参与的流程可按计划设置启动时间和重复周期。两种流程中都可嵌入UI流。

UiPath的开发通过事件驱动，每个操作都有独立的。对于简单的流程，按照流程的逻辑和规则，直接拖拽需要的累加即可。对于需要捕获的元素，先选择动作事件，再进行元素捕获。对于复杂的流程，则需要编写代码。

UiPath依赖于的语法，开发人员需要熟悉相关语法和类库。在Studio中可以通过invoke code的形式直接编写和运行VB的代码，也可以将DLL文件打包成.nupkg包引入到项目中。扩展支持调用VBA、、Python、Power Shell等。

复杂的流程建议使用UiPath官方提供的，该框架中有严谨的日志的记录和异常机制处理。

在复用性上，UiPath可将通用的流程提炼成，供项目调用。也可以通过自定义的形式，生成可复用的package。还可以将可复用的组件发布成Library。

Power

Power 提供了5个类型的“流”：

每一种“流”都由触发器和一系列的标准操作组成。触发器为流程中的特定事件，一旦事件发生，则流程启动。Power 针对300多个应用程序预设了多种触发事件及触发后的一系列标准操作。官方暂未提供的连接器需要自定义。日常简单的工作流程，使用拖拽的方式累加标准操作即可完成，对于复杂或数据处理量大的业务流则可能需要借助其他工具，例如，遇到Excel中大量的数据处理，Power 运行速度就会比较慢且调试不方便。使用人员依旧需要一定的编程理念。对于使用其他语言编写的脚本，目前还没有找到可直接调用的方法。

Power 针对不同的工作场景官方都有提供流程模板，可直接拿来修改后使用。

4 培训和支持

UiPath

UiPath提供官方培训学院，有完善课程体系和视频教学，并提供完整的在线文档和官方论坛。

此外，UiPath会不定期的提供demo演示和最佳实践的动手培训。

Power

Power 有官方文档和官方论坛，但并没有完整的类似UiPath从无到有培训用户如何使用Power 的课程教学体系。培训文档也更适用于熟悉微软产品开发的技术人员，对不熟悉微软产品的使用者而言，上手有一定困难。

5 许可证

UiPath

UiPath的三个组件的License都是按年收取费用。

Power

Power 有两种计划：

6 试用/免费版

UiPath

UiPath提供不限期限的社区版和60天的企业试用版。

Power

Power 的试用期为 90 天，或申请开发者计划。（当前专业版以上系统免费使用）

两种RPA工具各有千秋，并且都在不断更新进步中。

UiPath

UiPath旨在允许最终业务用户对自己的流程进行编码和自动化，所以UiPath学习曲线是平缓的，适合没有编程经验的人按部就班地学习，其封装好的按照流程运行过程堆叠，界面直观，让初学者易于理解。但是，当流程机器人需要处理的工作越加繁杂时，没有编程经验的使用者会觉得UiPath变得难以驾驭，而有编程经验的开发人员则会觉得UiPath笨重。尤其是当有大项目时，一层套一层的容器使得导航到特定过程变得繁琐。必须指出的是，UiPath在财务和HR等人工操作较为复杂且重复率高的领域，其效率确实能为企业节省很多时间和人工上的成本。

Power

Power 是公用的云服务，只需一个 Web 浏览器和电子邮件地址即可使用，但目前来看也只适用Azure云平台。Power 注重与自己的业务工具（如Office 365、、、Power BI、Teams等）以及组织中使用的工具（如、Workday等）的集成，需要有账号，因此，现有的培训更适合熟悉微软产品或开发的用户。但Power 确实是一个功能强大的工具。其丰富的数据连接器为微软RPA搭建了一个自动化工作流的生态系统，原生的AI智能和Azure大数据分析支持，使得微软RPA更加智能化。Power 支持移动设备，可在智能手机上一键触发工作流，极大提高了企业员工的工作效率。

针对两款产品的特性，在搜集HR、财务、行政等领域一些需要人工重复操作且耗时久的业务场景，开发了相应的流程并实现。

根据我们目前的经验来看，针对类似文件备份、收到邮件推送通知、自动审核工作流等一些不繁杂且与、one drive等微软相关产品结合的场景，微软的Power 是一个很好的选择。

而如果针对需要部署多个有复杂业务逻辑或需处理大批量数据的流程，那么UiPath因开发的灵活性会更加合适。

当然，企业最终在选择RPA工具进行自动化之前，还需要根据自身的情况、产品的定位、流程自动化的层级等多方面因素进行考虑。

如何构建你自己的 Git 服务器

创建自己的Git服务共享非常简单, 在许多情况下值得去创建这样一个Git服务。它不仅保证你随时可以访问你的代码，它的无限制数据存储、持续集成跟部署同时为个人Git管理打开了一道Git延伸与拓展的大门。

假如你知道如何使用Git和SSH，那么你已经知道如何创建一个Git服务器了。设计Git的方式，你创建或者克隆一个仓库时，你已经创建了一半服务器。使能SSH访问仓库，并且任何访问你仓库的人都可以使用你的回购协议作为一个新克隆的基础。

但是，会有一个小特设。有些计划你可以构建关于同样数量的精心设计的Git服务器，但是可以具有更好扩展性。

首先是：识别你的用户，包括闲杂与未来的。假如你是唯一用户，那么无需任何改变，但是如果你邀请国外的贡献者了，那么你应该为开发者搭建一个贡献共享系统平台。

假定你有一个可用的服务器（如果不是，Git无法解决这个问题，但是运行在 Pi 3 的CentOS将会是一个良好开端），第一步是采用SSH键值授权登录，它比密码登录更加强大，因为它能免疫于蛮力攻击，并且可以避免用户尽可能简单地删除它们的键值。

在你启用了SSH密钥认证之后，就创建一个 gituser用户。这是一个提供给所有通过了认证的用户的共享用户账号:

$su-c''

然后切换到这个用户，并使用合适的权限创建一个~/.ssh 框架。这非常重要，因为如果权限设置太过于随意，你自己针对SSH的防护默认就会失效。

$su-gituser

$mkdir.ssh&&.ssh

$touch.ssh/

$.ssh/

文件里面有所有你赋予其权限操作你的Git工程的开发者的SSH公共密钥。你的开发者必须创建属于他们自己的SSH密钥并将其中的公共密钥发送给你。要把这些公共密钥复制到gituser的文件中去。例如，对于一个叫做Bob的开发者，可以运行这些命令：

$cat~/path/to/id_rsa.bob.pub>>\

/home/gituser/.ssh/

当开发者Bob持有能匹配他发送给你的公共密钥的私有密钥时，他就能以gituser访问服务器。

不过，你并不会真的想让你的开发者访问到服务器，即使只是以gituser用户来进行访问。你想要的是让他们只能访问到Git资源库。因为这个原因，Git提供了一个受限的shell，恰如其分的将其称为 git-shell、以root用户运行下面的这些命令可以将git-shell添加到你的系统中，并使其成为gituser用户的默认shell：

#grepgit-shell/etc/shells||su-c\

"echo`-shell`>>/etc/shells"

#su-c'usermod-sgit-'

现在gituser只能使用SSH来向Git资源库进行推送和拉取操作，而不能访问到一个登陆shell。你应该将你自己加入gituser对应的用户组，在我们的示例服务器中它还是gituser。

例如：

#usermod-a-

剩下的唯一一个步骤就是创建一个Git资源库。因为不会有人在服务器上跟它进行直接交互（也就是说你不会通过SSH连上服务器然后直接在资源库中进行操作）, 这使其成为了一个基础的资源库。如果你想要把服务器上的资源库用起来，就要将其从它所在的地方克隆到自己的home目录中去。

严格来说，你并不用使其成为一个基础资源库，它还是可以作为一个普通的资源库来操作的。不过，一个基础资源库是没有*工作树（working tree）* (也就是说，不会有分支会处在”“状态)。这很重要，因为远程用户不会被允许向一个活动分支进行推送 (你是不会想在一个”dev“分支工作时突然有人将变更推送到你的工作空间的?)。因为基础资源库不能有活动分支，那就不会有问题发生了。

你可以将资源库放到任何你想要放置的地方, 只要你想赋予权限的用户和组也能访问到它就行了。你不会想将目录存储到一个用户的home目录的，因为这里的权限相当地严格, 而是要放在一个通用共享的位置，例如/optor/usr/local/share.

以root用户创建一个基础资源库:

#gitinit--bare/opt/jupiter.git

#chown-:gituser/opt/jupiter.git

#chmod-R770/opt/jupiter.git

现在任何已gituser认证的、或者是位于gituser分组的用户都可以读取和写入jupiter.git资源库。你可以在自己本机上试试看：

$:/opt/jupiter..clone

'jupiter.clone'...

Warning:.

记住：开发有必须让他们的公共SSH密钥导入gituser用户的文件, 或者是拥有服务器上面的账户（就像你一样), 那样的话他们就必须是gituser组的成员。

Git钩子

运行你自己的Git服务器带来的一个好处是它提供了Git钩子。Git托管服务有时也提供了一个类似钩子的接口，但那并不是真正的可以访问文件系统的Git钩子。一个Git钩子是一个脚本，它在Git进程中的某个时刻执行。在一个仓库（）接受一个提交（commit）之前，或者收到一个提交之后，或者接收一个推送（push）之前，或者收到一个推送之后等时刻执行一个钩子。

这个系统很简单：任何可执行的脚本都存放在.git/hooks目录中，使用标准的命名方案，并且在某个指定的时刻执行。脚本执行的时间由名字来决定；pre-push脚本在推送之前执行，post-receive脚本在收到一个提交之后执行，诸如此类。它基本上属于自文档（self-）。

可以使用任何语言编写钩子脚本；如果你能在你的系统上运行某种语言的hello world脚本，那么你就可以使用那门语言来编写Git钩子脚本。默认情况下，Git附带了一些范例，但没有启用。

想要运行一个脚本吗？使用起来很简单。如果你还没有Git仓库的话，首先创建一个。

$

$

$gitinit.

然后编写一个"hello world" Git钩子。由于在工作中我为了传统支持而使用tcsh，所以我坚持使用它作为我的脚本语言，但你可以自由地选用你喜爱的语言（Bash、Python、Ruby、Perl、Rust、Swift、Go）：

$echo"#\!/bin/tcsh">.git/hooks/post-commit

$echo"echo'POST-D'">\

~/jupiter/.git/hooks/post-commit

$chmod+x~/jupiter/.git/hooks/post-commit

现在进行测试：

$echo"">foo.txt

$.txt

$-m''

!POST-D

[master(root-commit)c8678e0]

,(+)

.txt

这就是你的第一个可以正常运行的Git钩子。

著名的推送到web 钩子

一个流行的Git钩子用法是自动推送改变部分到工作生产中的web服务器目录。这是一个伟大构建FTP的方式，保留开发环节的全版本控制，并且整合、自动化发布内容。

如果正确执行，它将会工作运行良好，在某一种程度来说，一直应该做的是考虑如何网络发布。它是不错的。我不知道最初是谁想出这主意的，但是我第一次是从EMacs和来自IBM公司的Git-mentor、Bill Von Hagen那里听到的。他的文章仍然是对这个过程起决定性作用的介绍：Git 改变分布式Web开发规则。

Git变量

每个Git钩子获取一组不同的Git动作触发它的相关变量。你可能会用到这些变量，也可能用不到。这取决于你所写的作品。如果你想要的是一个普通的邮件来通知你，有人推了东西。那么你不需要细节，也不需要脚本，因为你可以套用现有的样板。如果你想在邮件里浏览别人提交的信息和作者，那么对你的脚本要求更高。

Git钩子并不是用户直接运行的，所以要理解透如何获取这些混乱却重要的信息。事实上，一个Git钩子脚本与其他任何脚本类似，像BASH、Python、C++或者其他脚本一样的方式接受来自stdin的参数。不同的是，我们不会提供自己入参，所以使用它时要弄清楚你想要的是什么（参数）。

编写一个Git钩子之前，可以进入到你的项目目录.git/hooks查看Git提供的范例。例如，下面是pre-push.sample文件的注释部分：

#$1--

#$2--

#.

#

#:

并非所有的范例写的都那么清晰，文档对于什么钩子需要什么变量的说明还有些不足（除非你要阅读Git的源代码），不过若有疑问，你可以通过trials of other users进行更多地了解，或者编写一个简单的脚本，输出$1、$2、$3等。

分支检测范例

我发现在实际的生产中对钩子最常见的需求是针对受影响的分支触发特定的事件。下面这个例子演示了如何解决这样的任务。

首先，Git钩子本身不是版本控制。也就是说，Git不会跟踪它自己的钩子，因为Git钩子是Git的组成部分而不是你的仓库的一部分。因此，Git钩子在监视提交和推送的同时，可能对你的Git服务器上的远程仓库最有意义，而不是作为你的本地仓库的一部分。

我们来编写一个基于post-receive运行的钩子（即，收到一个提交之后）。第一步是识别分支名字：

#!/bin/tcsh

($