因為咱們公司用的主要是uipath的產品，因此博主接下來對於這章會針對uipath的相關套件展開討論。

orchestrator，是uipath的一個產品，其主要功能是robot排程，角色許可權控制，流程管理，robot版本管理，config配置，佇列管理等功能。

這樣子看起來orchestrator非常強大，他已經集成了傳統行業database（資料庫），mq（佇列管理），oa（流程開發）等系統可以做的事情了。那是否我們做開發的時候直接呼叫orchestrator就行呢？

博主這裡針對於orchestrator有以下3個觀點：

1. 化整為零or化零為整

雖然說orchestrator是uipath的標準產品，在uipath的官網上也有很多實施orchestrator的解決方案。但是一旦一個系統他的功能整合越多，風險其實是越大的（穩定性以及可擴充套件性）。因此在開發的過程中，我們得找個節中點，博主這裡其實推薦我們只用orchestrator的排程功能以及流程管理即可。

2. attended vs unattended

uipath他的license產品主要分為這兩類，其核心的不同點在於可以schedule or 不可以schedule。但是一般來說，咱們開發robot，企業首先會試水地使用attended的robot（便宜啊），然後這個時候咱們是沒有用orchestrator的佇列以及解決方案的。但是，一旦企業開始領略到RPA的重要性後（明智啊），就會開始採用orchestrator的模式，那麼咱們之前做的robot不是需要重新修改了？這個人天，企業會負責麼（天真啊）。因此，博主認為，如果只採用orchestrator的schedule模組，那麼會大大降低軟體的耦合性，可以說，如果從attended到unattended，咱們只需要deploy就好了，完全不需要修改任何程式碼，很好地完成