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

($