【UiPath Apps】マスタデータはどう扱えばよいか

# はじめに
この記事はUiPathブログ発信チャレンジ2023サマーの27日目の記事です。

https://note.com/shumpei_w/n/nd082bdf28853

----
UiPath Appsで業務アプリケーションを作る際に、よく悩むのはマスタデータの取り扱いです。
例えば、社員マスタ、取引先マスタ、商品マスタなど、社内に持つ様々なマスタデータを参照するケースは多いと思います。

![Apps_実行1.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/89445/d535984b-5c38-a85d-09ca-55b0652fa208.gif)

Appsでマスタデータを扱うには主に2通りの実現方法があります。

1. Data Servcieにマスタデータを載せる（社内システムのマスタデータと同期する）
2. 都度Robotを動かし、社内システムからデータを取得する

この2つの方法について、メリデメを整理してみます。


# 使うもの
※クラウド環境は2023年7月時点のもの
Automation Cloud(Apps, Data Service) Enterprise版


# 方式
## 1. Data Servcieにマスタデータを載せる（社内システムのマスタデータと同期する）
Data Servcieはノーコードで作成できるデータエンティティサービスです。データベースのテーブルのようなものを簡単に作れるサービスだと思っていただいて良いかと思います。
Data Servcieに格納したデータは、Appsはもちろん、Robotからも呼び出すことができます。
Data Serviceと社内システム（マスタデータの源泉）のデータ同期を行うために別途、連携バッチを用意する必要があります。
![方式1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/89445/abb7415b-647c-58a3-1361-330fe4c00f47.png)


## 2. 都度Robotを動かし、社内システムからデータを取得する
UiPathサービス上にマスタデータを持たず、Appsで必要な時に必要なデータを適宜、社内システムから取得します。Orchestrator、Unattended（Cloud Robotでも可）を使うことになります。
方式1と比べ連携バッチを必要としないので、UiPathユーザなら気軽に始められる方式となります。
![方式2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/89445/3a7d59b0-6b39-7e91-61c3-a2ae47bf9b77.png)


# 評価
以下の評価軸で整理します。評価はあくまで主観です。ご参考程度でお願いします。

1. 実装の難易度：簡単に実装可能か
2. 実行時の挙動：動作の安定性と実行速度
3. データの鮮度：常に最新データにアクセス可能か
4. 運用のコスト：ライセンスや運用のコスト

| 方式 | 実装難易度 | 実行の安定性・速度 | データ鮮度 | 運用コスト |
|:--|:--|:--|:--|:--|
| 1.Data Service | △ | ○ | △ | △ |
| 2.Robot | ○ | × | ○ | △ |


## 1. 実装の難易度：簡単に実装可能か
| 方式 | 評価 | コメント |
|:--|:--|:--|
| 1.Data Service | △ | データ取得方法が簡単だが、凝りすぎると嵌る |
| 2.Robot | ○ | いつものように自由に実装できる |

Appsはローコードで誰でも実装できるようにデザインされていますが、複雑な処理をしたい場合は、それ相応の実装が必要です。例えば、Data Serviceのエンティティ検索をする場合、Filter関数を使って検索機能を実現できますが、検索項目が増えるほど関数の式が長くなり、複雑さが増します。感覚的にはExcelと同じで、数式を神のように複雑に組み込んだアプリケーションは壊れたとき直しにくいです。
![式1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/89445/8d5d8cf5-1fbf-4f96-9d6c-e475cf9a8fd1.png)

:::note info
Apps内で使用される式は完全な形でのコピペができません。長い式を1つ1つ打ち込まなくてはならず、かなり辛い作業となります。
:::

## 2. 実行時の挙動：動作の安定性と実行速度
| 方式 | 評価 | コメント |
|:--|:--|:--|
| 1.Data Service | ○ | 早いし、安定して動く |
| 2.Robot | × | 遅い。さらにUI自動化の場合は安定性を高める実装が必要 |

当然ですが、Robotを使う場合は動作が遅くなります。Cloud Robot Serverlessを使うと速くはなりますが、それでも20～30秒はかかってしまうかと思います（Serverless＝クロスプラットフォームなので使える場面は限られます）。
また、Robotを動かす場合は、なるべくエラーを出さないように考慮する必要があります。RPAでは発生率1%未満の偶発的エラーをどうしても完全に防ぐことができないので、エラー時の処理を考慮する必要があります。

:::note info
非同期処理でRobotを呼び出すことができるので、使いどころを工夫すれば体感的に遅く感じさせない作りにするこも可能かと思います。
:::

## 3. データの鮮度：常に最新データにアクセス可能か
| 方式 | 評価 | コメント |
|:--|:--|:--|
| 1.Data Service | △ | データ同期の仕組みが必須で、これが結構面倒 |
| 2.Robot | ○ | データ同期は不要で常に最新データを取得できる |

Data Serviceを利用する場合は、社内にあるマスタデータと同期する仕組みを構築する必要があります。社員マスタのように1日1回の同期で済むものもあれば、常に最新データを使用する必要のあるマスタは、1日に複数回またはリアルタイムでの同期が必要になるケースもあります。また、洗替なのか差分更新なのか方式も検討する必要があります。
Data Service上のデータを追加・更新・削除するにはAPIを利用します。APIには呼び出し回数の制限あり、この制限内に収まるように連携バッチを構成する必要があります。
また、データ同期が失敗すると業務影響が出やすいので、連携バッチの運用監視もセットで検討する必要があるかと思います。

（折角、Appsはローコードで手が出しやすいのに、連携バッチを作んないといけないなんて、、、これじゃあハードル上がるなぁ）

:::note info
Data ServiceのAPIは、Data Serviceユニット（ライセンス）1単位につき、1日10,000回呼び出すことが可能です（Enterprise版）。
また、APIはバルク処理に対応していて、1回のAPI呼び出して最大1,000レコードの追加・更新・削除が可能です。
:::

## 4. 運用のコスト：ライセンスや運用のコスト
| 方式 | 評価 | コメント |
|:--|:--|:--|
| 1.Data Service | △ | 別途ライセンスが必要、さらにデータ連携バッチの保守が必要 |
| 2.Robot | △ | OC,Robot以外のライセンスは不要だが、Robotの保守は必要 |

Data Serviceを使用するためには、別途ライセンス「Data Serviceユニット」を購入する必要があります。
Data Serviceユニット1単位につき、データストレージが1GB、ファイルストレージが5GB付与されます（Enterprise版）。

:::note info
Automation Cloudのライセンス管理画面では、使用中のデータのバイト数を確認することができません。　←ここは強く改善をしてほしいポイントの1つ
データストレージ1GBで保存可能なレコード数の目安を求めたくて、フィード数13のエンティティに大量のデータを投入してみましたが、500,000件を超えたあたりで断念しました。。。（バルクAPIで1,000レコード×500回の繰り返し）それなりに大量データを保有しても問題なさそうです。
![ライセンス1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/89445/3b8b605a-fc28-6783-f250-8b2ea6abba08.png)
:::


# おわりに
いかがでしょうか。両方式とも長所・短所があり、どっちにするか悩むかと思います。マスタデータの量、更新頻度、Appsでの待機時間などを鑑み、両方式のどちらかを採用して（または組み合わせて）ほしいと考えています。

個人的はApps上からRobotを介さず直接APIコールできるように改善してほしいです。そうなれば、APIを公開している社内システムに対してAppsからAPIコールすることができ、マスタデータをUiPath上に持たなくても、オンデマンドに取得可能になって利便性が向上します。
（APIを持たないレガシーな社内システムや、APIを持っていてもAppsから直接アクセスできない場合は引き続き上記2案になりますね）