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進行解釋說明。參數和變量也是如此。