最近在跟客戶國外的CoE導入local的流程時，被要求許多統一的 Naming Convention，天真的我以為把process都命名完就可以submit了，被國外秒退件...叫我補上相關的 Object Naming, 汗顏之餘不禁開始思考說Oject的本質。

對一個developer而言，當面對一個新工具的時候最想知道的就是其程式設計的基本單位。

在流程設計層面，BluePrism (BP) 的最基礎單位就是 Objects，一個 Object 綁定一個 application 應用程式，而一個 Object 中有多個 Action，也就是在該應用程式中做的動作，例如登入、填入欄位、按確認鍵、等等

Process 是 Object 的上層單位，可以引用並串聯Objects來組合成一個完整的跨應用程式流程。Process也是排程工具Scheduler唯一可執行的單位。

因此已執行面來說，Control Room -> Scheduler -> Processes -> Object -> Object Actions。

在流程設計完成後，首先著手盤點與建置的就是 Objects 和其 Actions。在這些都完成後就可以開始編制流程。
一個 Object Action 是可以包括同一 Object 中其他的 Action 組成一個全新的 Process 也是用來串聯 Object Actions 而且是跨 Object。

到底在甚麼狀況下應該把小流程建置於 Objects Action 中，又甚麼狀況下應該將小流程建置在 Process 中？

其實就跟其他程式設計的 best practice 一樣，重點就在重用 (reuse)。若是瀏覽至會計系統中的報表頁面是一個會被多個流程所使用的動作。最好就是將這個小流程建成會計系統這個 Object 中的一個 Action。

試想若是不將瀏覽至報表頁面這個小流程模組化，而當三個流程都有將其分別設計於其大流程中，改天當會計系統的瀏覽順序稍有改動時， RPA 的程式員就得分別去三個流程中找出該小流程，並分別修改。

最可怕的是，公司已經設立了多個 RPA 自動化流程，而大家都以不清楚每個流程的細部時，IT 就只能等著程式出錯才知道前端程式介面改變對個別 RPA 流程的影響。若是該流程以包覆在 Object Action 中就可以改一處動全身，減少錯誤又有效率。