Quantcast
Channel: dictionaryタグが付けられた新着記事 - Qiita
Viewing all articles
Browse latest Browse all 99

UiPath 引数に関する考察

$
0
0
この記事は RPAコミュニティアドベントカレンダー2021の 25日目 の記事でもあります。 皆もすなるQiitaといふものを、儂もしてみむとてするなり。 と言う訳で、こん**は!はなっち!です。 今回は、ちょっとしたやってみた!系の内容です。 UiPathで共通的な機能は、個別のXAMLファイルを作成し、それを「ワークフロー ファイルを呼び出し」アクティビティを使って、実現させます。その際に、入力属性の引数に、呼び出し側の値を設定し、出力属性の引数に呼び出し側で受け取る変数を設定します。 この例では、Int型、String型、Object型、DataTable型、Dictionary型(辞書型)を引数に指定し、呼び出し先に渡しています。呼び出し先では、入力属性の引数で渡された変数に設定されている値を基に、処理をします。出力属性がないので、呼び出し側が受け取るものはないですね。 引数が「入力」属性であると言う事は、呼び出し側の変数の値は、「ワークフロー ファイルを呼び出し」アクティビティに指定されたxaml中で値を変更したとしても、変わりません。 と思っていたのですが、実はそうでもないんですね。 実験してみました。今回、Dictionary型(辞書型)を引数に加えてみたのは、他の人が作ったロボットを見たときに、よくある"CONFIG.xlsxから辞書型に変換しそれをロボで使う"変数以外に、String,ObjectのDictionary型を用意し、そこに引数を格納する、って方法に遭遇したからです。こうする事で陽に変数を指定しなくても、このDictionary型の変数にキーとその変数を格納してあげれば、仕様が変わって引数の変更があっても、引数タブでの改修は不要になるのですね。 では簡単なロジック紹介。 1)呼び出し元で、各属性の変数を用意、値を設定する。 2)呼び出し先で、入力属性として渡されてきた値を加工する。 3)呼び出し先で処理され、返ってきたら、入力属性である値がどうなっているか評価する。 ※DataTableには、2列2行のデータ行を追加してあります。 ※Dictionaryには、キーとして、"I","S","D"をキー挿入してあります。 変数 処理前の呼び出し元での値 呼び出し先での処理 処理後の呼び出し元の値 備考 Int型 10 2乗(=100) 10 CType(Int型 ^ 2, Int32) String型 KOZAKI 左右入替え(=IKAZOK) KOZAKI String.join(String.Empty, String型.Reverse) Object型 123 1加算 123 CInt(Object型) + 1 DataTable型 HAJIME "FUJITSU"設定 FUJITSU Dt.Rows(1).Item(1)に設定 Dictionary型(Int) 10 1加算 11 CInt(Dictionary型("I").ToString) + 1 Dictionary型(String) KOZAKI "+ADD"連結 KOZAKI+ADD Dictionary型("S").ToString & "+" & "ADD" Dictionary型(DataTable) HAJIME "****"設定 "****" 左辺:CType(Dictionary型("D"), DataTable).rows(1).Item(1) このような結果になりました。すなわち、DataTable型、Dictionary型は、入力属性として指定されていても、、「ワークフロー ファイルを呼び出し」アクティビティに指定されたxaml中で値を変更してしまうと、そのまま値が反映されてしまうのですね。 一度、中の人に訊いた事があるのですが、例えば巨大なDataTableをxamlに渡した時、入力属性の変数情報を退避しなければならず、そうなるとメモリ圧迫につながるのを嫌ったため...との事でした。 Dictionary型(String, Object)の中にInt型を格納して、そこに処理を加えた場合は、キーを指定して得た値は一旦仮の変数に格納され、それに対して処理し、その処理結果をキーに対応する領域に格納したためでしょうねぇ。 おわりに いかがでした? ▼呼び出し元からしてみれば、入力属性の引数の値が勝手に書き換わってしまうのだったらそんなxamlは使わないよ!ってな事になりかねません。 ▼ですので、呼ばれる側は、入力属性の引数の値は保証してあげたいですね。 ▼とは言え、中の人が言うようにメモリ圧迫につながるのだったら、呼び出し側もこの事実を意識して、UiPathロボを作っていく他なさそうですね。利用者責任。なんだかつれない対応ですね(^^♪ 今回も読んでいただきありがとうございました! 是非UiPathでのロボ開発の一助になればと思っています。 ありがとうございました!

Viewing all articles
Browse latest Browse all 99

Trending Articles