高級別框架

從通用(和未知流程)框架開始，確保您以一致和結構化的方式處理任何流程?？蚣軒椭鷱母呒壱晥D開始，然后深入了解每個流程的具體細節(jié)。

機器人企業(yè)框架模板 建議對重復過程進行靈活的高層概述，并包含本指南中描述的一組良好的實踐，并且可以很容易地用作使用 UiPath 進行 RPA 開發(fā)的堅實起點。該模板構建在狀態(tài)機結構上。

它是如何運作的：

• 機器人從配置文件和 Orchestrator 資源中加載設置，并將它們保存在要跨工作流共享的字典中。
• 機器人獲取所需的憑據(jù)并登錄到所有應用程序中。
• 如果遇到任何錯誤，則重試幾次，然后成功或中止。
• 機器人檢查輸入隊列或其他輸入源以啟動新事務。
• 如果沒有(更多的)輸入數(shù)據(jù)可用，則將工作流配置為等待和重試，或者結束流程。執(zhí)行用于處理事務數(shù)據(jù)的UI交互。
• 如果事務處理成功，則更新事務狀態(tài)，機器人繼續(xù)進行下一個事務。
• 如果遇到任何驗證錯誤，事務狀態(tài)被更新，機器人移動到下一個事務。
• 如果遇到任何異常，機器人會重新嘗試處理事務幾次(如果配置的話)，或者將項目標記為失敗并重新啟動。
  -如果配置了郵件，最后則可以發(fā)送一封帶有進程狀態(tài)的電子郵件。

用于基于事務的流程（例如 處理 Excel 文件中的所有發(fā)票 ），沒有通過 Orchestrator 執(zhí)行，則可以構建本地隊列（使用 .net 的 enqueue/ dequeue 方法）。

然后，高級別流程(異常處理、重試、恢復)的流程可以很容易地重復執(zhí)行，這比將整個流程分組在一個 For Each Row 循環(huán)下面更容易。

所有的 REFrameWork 文件和文檔可以在 這里 找到。

設計原則

在較小的工作流中分解流程對于良好的項目設計至關重要。 專用工作流允許對組件進行獨立測試，同時通過開發(fā)單獨的文件來鼓勵團隊協(xié)作。
明智地選擇布局類型(流程圖和序列)。通常，流程的邏輯停留在流程圖中，而導航和數(shù)據(jù)處理則以順序進行。
通過在序列中開發(fā)復雜的邏輯，您最終將得到一個由容器和決策塊組成的迷宮，非常難以跟蹤和更新。
相反，流程圖中的UI交互使構建和維護變得更加困難。

項目相關的文件（例如郵件模板）可以被組織在本地文件夾或者共享磁盤中

注意
如果放置在項目文件夾中，則在部署過程中(以及項目工作流)在 lib/net 45 文件夾中的所有機器人機器上復制它們。

這些文件夾也可以存儲在共享驅(qū)動器上，所以所有的機器人都連接到同一個唯一的源。這樣，業(yè)務用戶可以完全檢查和維護與流程相關的文件，而不需要 RPA 團隊的支持。但是，決策(共享或本地文件夾)很復雜，應該考慮到與進程和環(huán)境有關的各個方面：文件的大小、更改的頻率、編輯同一文件的并發(fā)性、安全策略等。

源代碼控制

為了方便地管理項目版本控制和共享更多開發(fā)人員的工作，我們建議使用版本控制系統(tǒng)。UiPath Studio 是直接與 TFS 和 SVN 集成的。您可以在 這里 找到一個說明連接步驟和功能的教程。

源代碼控制相關設置

為了避免在工作流中硬編碼外部設置(如文件路徑、URL等)，我們建議將它們保存在.config文件(.xlsx、.xml或.json)中，或者作為 Orchestrator 的資源(如果它們經(jīng)常更改)。

一般來說，最終的解決方案應該是可擴展的，以便在不需要開發(fā)人員干預的情況下允許輸入數(shù)據(jù)的變化。
例如，允許客戶進行某種類型的交易的列表、接收通知的人的電子郵件等應該存儲在外部文件中(如excel)，在這些文件中，業(yè)務人員或其他部門可以直接修改它們(添加/刪除/更新)。

對于任何重復的過程，主循環(huán)中的所有工作流調(diào)用都應該使用隔離選項來標記，以防止?jié)撛诘臋C器人崩潰(例如內(nèi)存不足)。

憑證

不應直接將憑據(jù)存儲在工作流中，而應從更安全的地方(如本地 windows憑據(jù)存儲區(qū) 或 Orchestrator 資源)加載憑據(jù)。您可以通過 GetCredential 活動 在工作流中使用它們。

錯誤處理

在運行自動化過程時可能會發(fā)生兩種類型的異常：某種程度上可預測的或完全出乎意料的?；谶@種區(qū)別，有兩種處理異常的方法，要么通過在工作流中自動執(zhí)行的顯式操作，要么通過將問題升級到人工操作員。

異常傳播可以通過在TRY/CATCH塊中放置易受攻擊的代碼來控制，在這些塊中，情況可以適當?shù)靥幚?。在最高級別，主流程圖必須定義廣泛的糾正措施，以解決所有一般異常并確保系統(tǒng)完整性。

上下文處理程序為機器人適應各種情況提供了更大的靈活性，它們應該用于實現(xiàn)可供選擇的技術、清除或定制用戶/日志消息。利用異常的垂直傳播機制，通過將處理程序向上移動一些級別，從而避免捕獲部分中的重復處理程序，其中處理程序可能涵蓋單個位置的所有異常。

應該在異常消息中提供足夠的詳細信息，讓人理解它并采取必要的操作。異常消息和源是必不可少的。異常對象的源屬性指示失敗活動的名稱(在調(diào)用的工作流中)。同樣，命名是至關重要的，因為錯誤的命名沒有給出崩潰組件的明確指示。

正如你如下看到的那樣，選擇不對調(diào)用的活動改名，使奔潰時輸出的異常源提示信息毫無意義。例如 (Invoke Workflow File > Invoke Workflow File > Invoke Workflow File > Type Into 這樣的信息并不能準確地告訴你發(fā)生了什么情況).

沒有提示信息的流程圖

代碼重用

在開發(fā)時，我們通常需要在多個工作流/項目中自動化相同的步驟，因此創(chuàng)建包含小部分正在發(fā)生的自動化的工作流并將它們添加到庫中應該是一種常見的做法。

沒有通用的方法告訴你如何分割任何給定的過程。

然而，業(yè)務邏輯與自動化組件的分離是一個很好的原則，它有助于構建一個可以有效重用的代碼。

例子

假設流程的部分需要讀取客戶的信息，然后基于該信息和內(nèi)部業(yè)務規(guī)則來更新客戶的詳細信息

獲取客戶信息 和 修改客戶信息 應該是兩個不同的自動化組件，完全不知道任何過程。邏輯(僅在過去12個月的總量大于100 k時才更新客戶類型)應與自動化分離。

這兩個組件可以在以后使用，分別在同一個項目中使用，或者在不同的項目中使用，具有不同的邏輯。如果需要，可以通過參數(shù)將特定的數(shù)據(jù)發(fā)送給這些組件。

不應從 獲取客戶信息 中調(diào)用 修改客戶信息 ，因為這使得測試、處理異常和重用變得更加困難。

代碼重用例子

推薦:
分別使用 修改信息 和 獲取信息 組件。

當操作之間的分離不那么明顯時，將現(xiàn)有代碼從一個工作流復制到另一個工作流(或從一個項目到另一個項目)也能一個很好地表明您應該為代碼構建一個單獨的組件(工作流)，并在需要時調(diào)用它。

可重用組件存儲在哪里

將現(xiàn)有代碼從庫拖放到工作流中比從頭開始重新創(chuàng)建代碼更容易。處理數(shù)據(jù)(排序、過濾)或文本(拆分、regex模式)是可以添加到 示例庫 中的示例。

請注意，一旦代碼被添加到工作流中，它就會變成靜態(tài)的，所以如果您在庫中更新工作流，它將不會反映在現(xiàn)有的活動流程中。

普通(可重用)組件(如應用導航、登錄、初始化)更好地分別存儲和維護，在 網(wǎng)絡共享驅(qū)動器 上。從該驅(qū)動器，它們可以被不同的機器人，從不同的進程。這種方法最大的優(yōu)點是，任何在主組件中所做的更改都會立即反映在使用它的所有進程中。

怎樣檢驗自動化程序的質(zhì)量

• 模塊化:

  • 將關注點與專用工作流分離，允許細粒度開發(fā)和測試；在項目之間提取和共享可重用組件或工作流。

• 可維護性:

  • 良好的結構和發(fā)展標準。

• 可讀性:

  • 標準化的程序結構，鼓勵明確的發(fā)展做法；
  • 工作流文件、活動、參數(shù)和變量的有意義名稱。

• 靈活性:

  • 將環(huán)境設置存放在外部配置文件中或者 Orchestrator 示例，使在測試和生產(chǎn)環(huán)境中運行自動化變得容易。

• 可靠性:

  • 異常處理和錯誤報告；
  • 實時執(zhí)行進度更新。

• 可擴展:

  • 為新用例的合并做好準備。

官網(wǎng)原文鏈接

返回目錄

UiPath 常見問題及解決辦法匯總

更多 UiPath 相關的資訊，請關注公眾號：流程自動化機器人教程
由于簡書禁止直接在文章中插入公眾號二維碼，請點擊 這里 了解添加該公眾號的細節(jié)。