xamlファイルのファイル容量とUIPATHでの編集に関して

日本 フォーラム
1

UIPATHにてWFを開発している中でxamlファイルの容量とその編集に関してお聞きしたいことがあります。

本来はWFは処理のまとまりでxamlファイルを分けるべきと考えています。

しかし、多様な処理を１つのxamlファイルに記載した場合、処理は問題なく動作しますが、UIPATHでのxamlファイルの編集に難を示しています。
具体的には、xamlファイルが5mb近くに肥大化した場合です。
xamlファイルをuipath上で開いたり編集した場合、UIPATHの反応が鈍くなったり応答なしになることがあります。
PCスペックはwindows10 pro 64bit インテルcore i5(2.1Ghz)、メモリ8gbです。

処理は分割してinvoke wfで変数を取り込むようにすればよいのですが、uipathにおけるxamlファイルが適正に処理できるファイルの大きさはどれくらいが妥当なのかご教示いただきたく思います。

1 Like
2

参考までに、UiPath社の方から聞いた話ですが200Activitiesを超えたあたりから動作が遅くなるようです。(1xaml200activities以下推奨）バイト数については触れていませんでした・・。
動作が遅いXamlは編集や閲覧をしないActivitiesで折り畳み可能なものは折りたたんでしまえば多少メモリが確保でき動作が軽くなるようです。

3 Likes
3

ありがとうございます。
１つのxamlファイルの中で利用するアクティビティの総数と考えてよいでしょうか。
ご教示お願いします。

4

1つのXaml内で利用するActivities数の総数となります。

1 Like
5

ありがとうございます。
基本的な質問で申し訳ございません。
200Activitiesを超えたあたりからということは、
log messageやtype into もアクティビティとの認識ですがそれも含め、概算でご指摘の程度のアクティビティの数を考慮し、wfの作り方を考えればよいとことになるのでしょうか。

6

DisplayNameの変更やAnnotationsの追加ができるDisplayWindowに配置されているActivitiesの総数です。
（指摘されているlog message・type intoや、ExcelApplicationScpe等で意図せず配置されるSequence等も含みます。）

1 Like
7

ある程度のケースバイケースとは思いますが、容量で言うなら数百kbぐらいまでが無難かな、と思います。（入れ子が深くなるとそれでも重く感じることもあります）

WFの単位は業務プロセスという意味の処理ではなく、たとえば「ブラウザを開いて特定の値を取得する」とか「Excelに値を書き出す」ぐらいの粒度でわけるほうが、業務内容の変更に柔軟に対応できると思いますよ。

2 Likes
8

いつもありがとうございます。

400kbのwfですが定義した変数が多く、UIPATHでの編集が遅くなったことがあります。
変数に関しても制限らしきものはあるのでしょうか。

9

変数に関しては、数と言うより中身ですね。
当たり前ですが、10kb分のテキストをメモリに読むのと、100kb分のテキストをメモリに読むのでは、使用量が10倍ぐらい違います。
（どちらも文字列型であれば、変数として「１つ」である点は変わらないです）

データの種類にも当然、依存しますが、大量のExcelファイルを一度に読んだりすると、かなり重くなることはあり得るかと。

1 Like
10

ありがとうございます。

間違っているかもしれませんが、自分の認識では当初はuipathの編集は単純にxamlファイルを作成するものと考えていました。

色々、ご教示いただき、UIPATHの編集では、アクテビティ・読み込みファイル・変数等を関連する内容を読み込んで文法チェックしてxamlファイルを作成するのではという考えに至りました。
そのため編集時に操作が重くなる現象が出てしまうということです。

つまりWFを作成する際は、ファイル・変数・アクテビティとともにwfの作成単位を考えていかないと編集もさることながら、メンテナンス性も考慮すべきということになるのでしょうか。

素人考えですが。

11

RPAのメリットとして、ワークフローのある程度の修正や追加、調節であればプログラマーでなくともできる、という点があります。
言い換えると、メンテナンス性をあまり考慮しない（作成した人がメンテナンスするのが前提）であれば、実はRPAツールを使う意味もそこまでなくて、専用のシステムを開発するほうが短期的なROIは享受できたりもします。

数年スパンで見て「エンジニアでなくとも、ビジネスの変化にあわせて現場の人が調節できる」ことにより維持コストを下げたり、業務プロセスの改善にあわせて変更できることがRPAのメリットですので、メンテナンス性は非常に重要だと思いますよ。

4 Likes