UiPath Developer Community 第9回ワークショップ 覚え書き「Error Handling」や「Floating Robot」。

[UiPath Developer Community 第9回ワークショップ](https://www.uipath.com/ja/resources/knowledge-base/tag/japan-developer-community) で聞いてきた内容の覚え書き。。

行ってきました、第9回。今回は先着であっという間でした。次回からは広い会場で行いたいと思います、とのことでしたー。。

今回の話は

- Graceful error handling 
- New feature from 2018.4: Citrix native automation
- New feature from 2018.3: Floating robots (Attended)
 
でライトニングトークはなし。。なんとなくコンテンツ的には徐々に弾切れ感？ありでしたかね、、。


### Graceful error handling

「Graceful error handling」はエラーハンドリングのBest Practiceってはなし。

具体的には、


- アプリ例外(たぶんシステム例外って文脈)とビジネス例外(業務例外)をわけて、処理しましょう
- アプリ例外は、Retryアクティビティなどでリトライして、それでもダメならシステム管理者に通知
- ビジネス例外はリトライに意味がないので、そのままビジネスユーザに通知

うん、ですよねってかんじです。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/73777/99770d41-c1e1-3ae4-7013-3eacee81a57c.png)


さらに通知の方法は、

- Attended Robo は、アプリ例外時はシステム管理者へはメール通知、ビジネス例外時はビジネスユーザへMessageBoxで通知
- Unattended Roboは、どちらにもメール通知
- Unattended Robo がOrchestratorのQueue機能をつかってる場合は、
 - アプリ例外時はトランザクションのStatusを「Appllcationで失敗」とするとOrchestratorのAlert機能でエラー検知して、システム管理者とビジネスユーザに通知される
 - ビジネス例外時はトランザクションのStatusを「Businessで失敗」として(たぶんRoboが自分で) ビジネスユーザにメールで通知

ってしましょう、というはなしでした。なるほどー。。

コレは「Unattended Robo がOrchestratorのQueueアリ」パタンの例。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/73777/de42dc5f-f350-0ec6-dc92-75496e87aae9.png)



ちなみにOrchestratorのAlertやQueue機能は

- [アラートについて](https://orchestrator.uipath.com/lang-ja/v2018.3/docs/about-alerts)
- [ビジネス例外とアプリケーション例外](https://orchestrator.uipath.com/lang-ja/v2018.3/docs/business-exception-vs-application-exception)

このへんに説明がかいてあります。


### New feature from 2018.4: Citrix native automation
リモデとかCitrix ってコンポーネントを認識できないので、画像のOCRでやるしかなかったのだけど、Citrixの場合はオブジェクトとして認識できるようになりますよって話。
うーん、つかってないからなんとも。。RDP(リモデ)が認識できるようになったの？っておもったけど違うようですorz

うん、認識してる！
![image.png](https://qiita-image-store.s3.amazonaws.com/0/73777/b77a4aa9-b8a0-94dd-1a1b-e4de5a88b75e.png)



### New feature from 2018.3: Floating robots (Attended)

コレは待望の機能。
まず、2018.2.xまでのOrchestratorまでは、Robotのデータ構造が「Machine(PC)」と「Robot(ロボ
)」が非正規化された冗長なテーブル構造だったんですが、ちゃんと正規化されました。

非正規化された構造だと、Namedユーザが任意の端末でロボを動かしたい場合、PCごとに自分のロボを作らないといけなかったんですが、、つまり、N人の人間がM台のPCでロボを作る場合「NxMのロボット登録」が必要だったわけです。
それが正規化されたので「ロボット登録がN人分+テンプレート1台」でよくなったよ、というはなし。

ロボット画面で自分のWindowsアカウントを登録すればいいっていうイメージです。


OrchestratorのRobot画面では「フローティングロボット」を作成し、Windowsアカウントを設定しておきます(通常のロボはPCとWindowsアカウント両方入れていました)。またOrchestratorのMachine画面で「マシンテンプレート」を作成し、マシンキーを払い出しておきます。

あとは接続するPC上で、ロボットのタスクトレイからマシンキーのみを設定すればOKとなります。PC名って概念がなくなりました。
本来こうあるべきじゃんね、って構成になっただけといえばそうなんですが、実運用してる身からするとこれはかなり嬉しい機能。。
運用負荷めっちゃ減ると思います。


めんどくさかったときの図
![image.png](https://qiita-image-store.s3.amazonaws.com/0/73777/7c37a077-acf2-a135-c78f-ef6eec0f4690.png)

**-- 2019/06/25追記 --**
2018.3くらいから？AttendedのライセンスにはNamed User とConcurrent User のふたつになりました(参考:[Robot/Studioのライセンシングについて](https://qiita.com/masatomix/items/c7948dd9470abfaa4a79#%E5%82%99%E5%BF%98%E3%83%A1%E3%83%A2))が、このFloating Robotは、Concurrent User ライセンスと相性が悪いです。

[フローティングロボットの機能と利点](https://www.uipath.com/ja/resources/knowledge-base/floating-robot-function) をみると、「フローティングロボットは同一ユーザーで複数端末で同時に使用することはできません」とあります。通常Named Userは、一つの端末であるドメインユーザのロボが使用中の場合、他の端末ではロボが使用できないようになっているのですが、Concurrent Userは同時利用の幅(?)の範囲内で、同じドメインユーザでロボを利用可能です。しかしながら、フローティングロボットを作成した場合は、上記の制約により複数端末で同じドメインユーザがロボを使用できなくなっています(実際、ライセンスを取得できませんでした)

うーん、一長一短ですね。。Concurrentの場合はいままで通り固定的にロボを作成した方が良さそうってことですかね。
**-- 2019/06/25追記 ここまで --**

### さいごに

恒例のお弁当とノベルティ。お弁当は、究極の海苔弁といわれる [刷毛じょうゆ 海苔弁 山登り](http://www.bento-smiles.com/ )。いつもありがとうございます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/73777/37c6af2b-4f47-f47b-dc01-78b3d2621123.png)


おつかれさまでした。。



### リンク

- [第8回ワークショップ 覚え書き「カスタムアクティビティの、デバッガによるデバッグ方法について」](https://qiita.com/masatomix/items/d38226f52cff23454db4)
- [第7回ワークショップ 覚え書き「カスタム入力アクティビティ」](https://qiita.com/masatomix/items/2d6ac698ce14dd1e3324)
- [第6回ワークショップ 覚え書き「出現するタイミングが不定のポップアップを処理する」](https://qiita.com/masatomix/items/72422148ea8353662eb1)