1、服務器變量
▲
在 8.0 以前，機器人和服務器之間的主要關係是調度、管理，在 9.0 中，我們增加了服務器對機器人的輔助能力：服務器變量。
顧名思義，這個變量是存儲在服務器，而不是存儲在機器人裏面的，是一個持久化的變量。
首先，這個變量只能在服務端定義，不能在客戶端定義和聲明
– 你可以定義一個 key-value 來標記這個變量
– 你可以保存密碼類型的變量
– 你可以實際用一個變量保存一堆變量
然後變量值寫成{'key1': 'value1', 'key2': 'value2'}
– 你可以限定誰能訪問這個變量
從 studio、機器人訪問這個變量
– 你可以獲取這個變量
– 你也可以設置這個變量 所有機器人都可以共享一些參數了，是不是很棒？
2、服務器共享任務數據
▲
在現實的 RPA 案例中，經常會出現，早上運行個程序，收取一個郵件，附件是一個 excel，這個 excel 裏面包含了所有今天要做的工作，這時候，如果是單機機器人，那很簡單，他當場順序開始處理任務，如果我擁有一個多臺服務器的 robot farm，問題複雜化了，第一，我們需要所有機器人能訪問到這套數據，第二，某個機器人開始處理一條數據的時候，其他人不再獲取這條數據，爲了適應這種需求，我們推出了服務器共享任務數據，這套輔助功能的主要特點包括：
支持服務器數據共享，所有機器人均可按權限訪問
支持一個空間保存多條數據
支持數據狀態，以保證機器人分配和共享時能有條不紊
我們首先關注一下數據的狀態，具體如下：
空間中數據一旦加入，會進入 pending 狀態，數據有過期時間（deadline），過期後轉爲 waittimeout；只有 pending、retried 未達上限的數據會被彈出（pop），彈出後則進入 running；任務成功，數據進入 successed；任務失敗，原來是 pending 的數據如果有設置重試次數則進入 retried 狀態，如果沒有重試數據進入 failed，原來是 retried 的數據則會嘗試次數 +1，如果嘗試次數到達上限，則會進入 failed 狀態；如果客戶端刪除數據，進入 deleted 狀態
我們來看看從零開始，如何在服務器上共享任務數據：
首先我們需要在服務器的任務數據模塊中，增加任務數據空間
我們是靠空間名字來訪問數據的，也是靠空間來設置權限的，比如我們設置了空間task1
和服務器變量不同，空間裏的任務數據是不能在服務器端定義的，只能在機器人裏面定義
前面舉出的例子中，有個機器人每天負責收郵件並讀取 excel，讀取到的 excel 每條數據作爲一條，放到到空間task1裏面，這個機器人的任務就完成了。
注意一下，新增數據的級別有Normal, High, Low的。優先級高的數據，會被優先處理。
新加入的數據，處於pending狀態。
正常對數據的使用是 POP 數據
數據一旦被 POP，就由pending轉爲running。
當然，你也可以直接改變數據狀態，比如標記爲 running 失敗，這樣其他機器人會重新得到這條數據並進行處理。
我們根據任務數據共享情況，假設了一套常見流程，也支持底層接口，直接利用這些狀態訪問和使用你的數據。
在服務器上，你可以從空間管理或者搜索引擎中，查看現有數據的情況
瞭解我們產品的同學知道，我們通過這個可以很方便的製作出各種可視化報表以及各種 dashboard