本文轉自：https://www.jianshu.com/p/53d0d33a1a35
版本說明:
Uipath V2018.3.2,BluePrism V6.3,Automation Anywhere 11.2
Uipath (UP)
新建
UP的產品思路是從易於開發者安裝和使用開始，本質是以自建工程起步的單機版開發工具，盡管目前版本的名字已經從NewProject改名成NewProcess ，但本質上每個人新建的還是一個工程文件。
熟悉Visio Studio 等任何一款軟件開發工具的朋友就會對工程的概念很熟悉 ， 如果有人在CSDN上分享成果，大家更想要的肯定是完整的開發工程包。
特點：單機本地工程文件，流程項目協同/版本控制，開發者權限/審計，代碼安全等需要額外的管理方法和工具才可以實現 ； 但最大優勢是，安裝部署簡便，再加上Uipath的大市場戰略，所以國內知道UP，玩UP的人數量上是最多的。
流程設計
UP的設計器畫面總給人一種無法看清流程全貌的感覺。
由於產品的歷史原因和用戶習慣使然，UP設計器還是主要在Main窗體里面套各種Sequence (序列，方框框)為主。
假設有如下需求已經通過Visio畫出流程圖，在UP中的實現參見下圖：
如果不展開結構，似乎我們只看到了 Do While 和 If判斷，那么我們就展開結構。
展開后的流程看起來累不累？
熟悉UP的玩家說，“還好啊” 。但問題是，這個需求如此簡單，流程設計邏輯就看起來那么煩人了，那復雜的長流程+很多邏輯分支的情況呢 ？
為了解決Sequence的很多缺點，UP推出了 FlowChart Activity。
UP推出FlowChart Activity 就是想以畫布設計的方式部分解決流程設計的缺點
但從FlowChart只是UP的一個Activity組件就大概能明白目前UP對FlowChart的定位。我不確定未來UP是否會強化FlowChart組件，讓其成為內置默認設計框架，而Sequence 變成一個Activity 。 如果到了那一天， UP或許更加強大了。 （還有一個很重要原因想必是很多UP玩家習慣了 Sequence，而不願意去適應FlowChart）
元素抓取
一款RPA工具是否強大，跟能抓到什么級別的元素還是蠻正相關的。不得不承認UP的元素抓取工具還是蠻強的。 點擊 Indicate Element后 ，UP首先是以智能識別模式根據鼠標移動的位置自行判斷元素類型和適配的方式。
如果是抓網頁，默認會選擇HTML方式去分析。有一些特殊情況可以考慮 UIA方式，實在無法識別就用區域模式去靠圖片識別。
測試題是： mail.qq.com 點擊- 賬號密碼登陸按鈕
UP可以抓到，Selector結構如下
這個測試其實不難，只是拋磚引玉 ，不妨在考慮下以下場景：
SAP/Oralce EBS /用友ERP 元素抓取能力如何
特殊網頁數據Table抓取能力如何，控件怎么處理
特殊的Java開發程序抓取能力如何
甚至Mainframe程序是否可以讀到模擬器中信息
某一項流程能不能被完美自動化，往往是由能否順利抓取到元素，讀取元素信息所決定的。
可復用性
流程設計的基礎模塊功能可復用性的高低，是否可以方便其他人拿來就用，直接決定了項目開發效率和周期。
UP通過Add Folder 可以將一些通用性Library xaml文件導入到系統中（嚴格的講只是被系統認到，並沒有導入到系統的概念）。識別后也可以通過類似操作Activity的方式去調用這些共用。
但這些單獨的文件，在項目協同，傳參等方面還是有一些問題的。
BluePrism(BP)
新建
區別於UP，BP的設計思路一開始就是定位企業級甚至金融級的RPA平台。
所以在已經部署有RPA的環境中，你想新建一個自動化Robot ，對不起你得先有賬號。每一個開發都是經過認證並且行為可追溯的。
BP通過新建Process ，來定義流程。 Process流程可以有很多Page頁，便於梳理流程結構 ；Process可以調用Object實現基礎功能模塊 ；Process也可以調用Process。
流程設計
BP的設計畫布更讓有人設計的感覺。
BP的流程設計主要有兩個維度：
第一個維度是Object ,
Object用來搞定跟各種第三方系統打交道的模型。Object 中有一個重要模塊叫 Applicaiton Modeller ，通過這個適配器BP會協助開發者幫助建立BP與應用系統聯系。
第二個維度是Process ，
只有Process才是可以被Publish發布到Control Room，以“正規”的方式去執行流程任務。 而Object僅僅可以在設計器Studio中運行 。
回到之前那個樣例，如果在BP中實現設計，參見如下圖
不得不佩服BP把設計器Studio做的非常好 。
很多場合如果是用BP流程設計開發，可以直接貼到項目的各種設計文檔中。
元素抓取
BP的元素抓取能力非常強，而且支持很多模式，混合使用各種不同模式可以有更佳的效果。
HTML Mode
Win32 Mode
UI Automation Mode
Accessibility Mode
Region Mode
BP可以輕松抓取賬號密碼登陸這個Tab Bar ，而且能對元素進行深入分析，勾選匹配項。
BP應該是目前唯一一家可以對市場上主流的Mainframe模擬器進行解析，讀模擬器中數據，直接寫數據到模擬器中。
可復用性
BP VBO（Visiual Business Object 可視化業務對象）可以極大的提高流程開發的效率。 在面對比較復雜的流程的時候，可以分別由不同的開發人員設計不同的VBO對接不同系統 ，如果是在同一個開發平台 ，其他人可以直接在系統中調用別人已經開發好的VBO對象。如果不在同一個項目，也可以通過將VBO導出成XML文件的方式與別人共享。
BP項目在設計階段，如何合理的設計不同的Object VBO對象，對項目進程會有較大的影響。
Automation Anywhere(AA)
新建
與BP類似，AA也是企業級部署的RPA平台。
沒有單機運行的設計器，要部署了完整的整套系統才可以登陸AA平台。AA在對外宣傳的時候號稱有非常強的高可用性系統架構，由於是設計器專題這些也就不展開了。
AA新建Workbench，就是基於Task的維度。
流程設計
AA流程的核心是TASK，通過設計編寫TASK來完成特定業務流程，或者再通過Workflow去調用TASK。當然TASK本身也可以調用TASK。
TASK里面利用很多很多Commands或者MetaBots，來組成具體的任務流。
AA的Task當中的流程設計界面長這個樣子：
說實話，這樣的流程設計界面太技術了，對普通人太不友好了。簡直比網頁源代碼更復雜，不是嗎？如果別人想讀懂這個Task的內容，簡直比直接讀腳本代碼更復雜。 #學AA好比新學一門語言
AA的WorkFlow 當中有部分可視化設計的功能，但是，實在是太局限了。 一共只有四個組件，一個Start ,一個End，一個IF,一個執行Task 。 所以Task才是AA的核心。
元素抓取
元素抓取AA似乎也沒有另外兩家的強。
AA有三種拾取模式，Object對象模式， Coordinates坐標模式， Image 圖片模式。
有RPA實踐經驗的人一般會優先選擇對象模式， 坐標模式很容易因為客戶端分辨率（窗口是否最大化）等問題而導致失誤。 但AA的對象模式較弱，無法識別“賬號密碼登陸”，也不支持切換諸如HTML/UIA/CS等其它對象適配方式。
並無法識別mail.qq.com的測試，AA只能識別到整個區域，並無法識別“賬號密碼登陸”按鈕。
另外客觀的吐槽幾點（如有任何不對的地方，歡迎大哥指正）：
AA內置的Mouse Command 的四個方法全部是基於坐標去做點擊的
（無法適應窗體移動，或者最大化，分辨率一改就不靈）
AA很多復雜操作必須用到一個叫 Object Clone 組件。Object Clone組件很強，集合了很多功能，但是無論名稱，還是定位總感覺怪怪的。 就好比之前做了很多組件發現不好用，后來一口氣做了一個很強的Object Clone組件，里面有包含了太多的功能，名字也取的隨意。
三種選擇模式，各類操作動作（鼠標點擊啥的，很多）
AA抓元素這個動作不舒服，需要按着鼠標移動到你想要檢測的元素然后松開鼠標。其實不光是因為不順手 ，還因為，比如如果你想切換不同的偵察元素模式，BP&UP 均可以通過按F? 來切換，但AA不行啊，因為一直保持鼠標左鍵按着。
可復用性
AA關於復用性的設計全部在MetaBot當中體現。
MetaBot 類似於 BP的VBO，但還是有一些區別。其實嚴格的講，MetaBot更像帶Input Output的 BP的可重用Process ， 因為MetaBot的感覺更像一個可復用子流程的感覺，而BP的VBO有很多基礎共用組件的屬性。
AA的Commands 通俗的講就是組件，並不支持自定義導入或者導出 ，所有新能力的獲取就得等廠家的新版本，或者索性通過外部的腳本。 而UP&BP 都能通過一些方法實現自定義組件並且復用的能力。
這也是為什么 UP 可以做Uipath GO平台，BP可以做 Blue Prism DX平台的原因，而AA卻不可以的原因。
總結：
由於時間和精力關系，本文只是挑了4個與設計器關系較高的角度分析了這三款RPA軟件的差異。但還有很多其它指標都會影響RPA工具，比如軟件系統架構，管理后台，安全性，工作隊列，部門流程權限等等。下回或許可以從 RPA后台&安全的切入點再進行深入分析 。
講了這么多外國的軟件，春節前打算做一期國產RPA工具的分析，希望可以獲得各位國產廠商老師的支持 。
作者：RPA虛擬員工轉型之路
鏈接：https://www.jianshu.com/p/53d0d33a1a35
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。