Configファイルの使い方について

日本 フォーラム
1

Configファイルの使い方について御意見をお聞かせいただければ幸いです。

UiPath Academyの初級・中級コースでConfigファイルについて言及されているので
すべてのロボット共通のConfigファイルを１つサーバーに置いております。
（弊社ではattendedロボット使用。OCを導入しておりません。）
Configファイルは、ロボット毎に１つずつ用意するのが正解でしょうか？それともすべてのロボット共通のファイルを用意するのが正解でしょうか？

また、OCを導入するとConfigファイルの内容をすべてアセットに設定できるので
Configファイルが必要なくなるのでしょうか？

2

こんにちは。
自問自答も込めて書きますので、ちょっと変な書き方になっていたらすみません。

Configファイルについては「それに何を記述するか」でどう扱うべきかが変わってくると思いますので、絶対的な正解はないかなと考えます。
なので以下の内容もあくまで一例として参考程度に考えて頂ければ。

前提として、私のスタイルではConfigファイルには「そのプロジェクトで使用する定数的な値」を記載しています。
（OpenApplicationで起動するプログラムのパスとか、Excel読み込むときのファイル名、シート名、範囲とか、リトライスコープの試行回数・間隔とか、OpenBorwserで開くサイトのURLとか、エラー発生時に保存するスクショの保存先パスとか、例外スローの時に出力するエラーメッセージとか・・）
あとはテスト実行がしやすいようにテストモードのフラグなんかも書いてますね。

なので、プロジェクトごとにConfig.xlsxを用意してプロジェクトフォルダ内に保存、Configの読込時のパスは相対パスで指定するようにして、
パブリッシュ時に一緒に移動するように作り込んでいます。

で、ひるがえって、@196006 様はどんな内容をConfigに記述されているでしょうか。
もしすべてのロボットで共通の設定にしたい、かつ動的に変更したいような内容を記述しているようであれば、ロボット共通のConfigファイルをひとつ用意してサーバ上に置くのは「アリ」だと思います。（内容次第でセキュリティの概念はまた別途考えないといけませんが）
そしてそれはOCを導入したらロボットで共通の値を持つアセットに置き換えることができると思います。
逆に、「そのロボットしか参照しない内容」とか「そのプロジェクト専用の設定」とかを記述しているようでしたら、ロボットごと、プロジェクトごとにConfigファイルを用意してやった方がいいかもしれません。
そしてその場合、OC導入時には、
ロボットごとに固有の参照値であればロボットごとに値を設定したアセットに置き換えられそうですが、
プロジェクトごとの固有値については全てアセットに置き換えるのは現実的ではないかな？とも思います。

・・とこんな感じでどうでしょうか。（識者の方の見解も聞いてみたいところですね）

2 Likes
3

私も同意見です。

ただ、共有サーバに置いた場合、ネットワークスローダウン、ネットワーク断となった場合にロボットが動かなくなる可能性も否めないので、プロセスの中に格納しています。

CONFIG.xlsxの内容は、半固定的なものに限定しています。
例えば、月ごとにフォルダが変わるって場合には、CONFIG.xlsxの中身をいちいち書き換えていくのは平気です！ってプロジェクトでしたら、書き換えてもらうようにすればいいですが、いちいち書き換えるの大変！というのでしたら、ロボット側のロジックを正とし、業務側でのフォルダ命名規約を変えていくケースもあります（BPMの一環？）

他の方は別の意見をお持ちかもしれません。 rfuさんのおっしゃる「絶対的な正解」はありませんので。。。

1 Like
4

rfu様
いつもご指導ありがとうございます。
とても参考になりました。
もう少し厳密に使っていく必要があると思いました。
当方では、Configファイルにファイルパス等ほぼ何でもブッコんでいる感じです。
動的に変更したくなるか否かの判断が難しい。。。というか動的にしておけばどうにだってなるといった感じです。（汗）

2 Likes
5

ハナッチ様
いつもご指導ありがとうございます。
プロセスの中に格納も考える必要がありそうです。
とても参考になりました。

6

ロボット共通で持たせたくなりそうな値としては、例えばうーん・・
・多数のワークフロー（プロジェクト）で参照している社内ポータルサイトのURL→たまにレイアウト変更でURLが変わるかもしれない
・各ロボット共通で持たせたい、リトライスコープの回数・リトライ間隔のデフォルト設定値→一斉に変更したい時にConfig一か所直せばいいので便利
・ワークフローのエラー時に飛ばすメールの宛先→ちょこちょこ変わりそう、かつ一斉に変更したくなりそう
とかですかね、ポンとは思いつかなくてすみません。（必ずしも動的に変更したいものである必要はないかもしれません）

あ、ちなみにConfigファイルの扱いについて、
私の言っている「プロジェクトフォルダ内に保存して相対パスで指定」と
HANACCHI 様の言っている「プロセスの中に格納」は同じニュアンスだと思いますので、
念のため補足まで。
（要するに.nupkg化した時にその中に格納されるようにして、実行時にはその、nupkg内に格納されたConfigを参照するようにするって感じですね）

2 Likes
7

rfu様
ご指導ありがとうございます。
補足いただいたところ、とても参考になりました。
最近、REFrameworkとアカデミの上級コースを見ていると（まだまだ理解に及ばないのですが。。。）やはりプロセス内に格納されておりました。
このあたりは絶対的な正解はなく、どのような運用したいか・どう扱うべきか・何を記述するか
を考えればよいというのがよく分かりました。
イメージができたので理解が進みました。

1 Like
8

Configファイルは、ロボット毎に１つずつ用意するのが正解でしょうか？それともすべてのロボット共通のファイルを用意するのが正解でしょうか？

設定ファイルはロボット毎に変える方が多いと思います。
理由）「すべてのロボット共通のファイル」にすると、設定ファイルが肥大化してしまう。共通項をまとめるのが大変

設定ファイルはプロセス内に格納されておりました。

格納しないケースもあります。
理由）設定ファイルだけを変更したい時がある（パブリッシュして再パッケージングしたくない）
その場合、設定ファイルのパスだけをコードまたは設定ファイルに記載します。（Configファイルをパッケージファイルに含めません）
但し、パスは決まってしまうので、パス変更＝パブリッシュして再パッケージングになります。これを回避したければ、パスをレジストリに埋め込むなどの小細工が必要になります。（後述しますが、OCならアセットに書きます）

OCを導入するとConfigファイルの内容をすべてアセットに設定できるので、Configファイルが必要なくなるのでしょうか？

アセットに全て記述するのは手間なので、設定ファイルのパスをアセットに持たせることもあります。（Configファイルをパッケージファイルに含めません）

Configファイルにファイルパス等ほぼ何でもブッコんでいる感じです。動的に変更したくなるか否かの判断が難しい。。。というか動的にしておけばどうにだってなるといった感じです。（汗）

固定なのかどうかの判断は人によって変わるので、明確なルールは持たず、設定ファイルに記載したいものを書いています。

・この値は将来変わるかも → 設定ファイルへ
・この値は環境によって変わるかも → 設定ファイルへ
・この値を設定ファイルに持たせると、テストしやすそう → 設定ファイルへ
・この値は多分変わらないけど、固定値をコードに埋め込むのは嫌だ → 設定ファイルへ

絶対的な正解はなく、どのような運用したいか・どう扱うべきか・何を記述するかを考えればよいというのがよく分かりました。

作りながら、設定ファイルの項目は増えていく気がします。
「設定ファイルを見ると処理内容がだいたい分かる」という、素晴らしい設定ファイルも稀にありますが、あんまり考えすぎると開発スピードが落ちるので、バランスが難しいですよね。

4 Likes
9

shinji様
いつもご指導ありがとうございます。
貴重なご意見ありがとうございます。
とても参考になりました。
当方ではテスト環境と本番環境を切り替えるのに割と入出力パス等を１つのConfigファイルに入れている感じです。といえども、ロボットが増えると１つのConfigファイルが肥大化するのも良くないなぁとも
思います。バランスを取る必要があると感じました。

10

色んなスタイルがわかって良いトピックですね。
ちなみに私のスタイルはこんな感じです。

・nupkgに取り込まれるConfigファイルと、ローカルディスクに配置するConfigファイルを用意（ローカルディスクのConfigファイルの位置はnupkgに記述）
・InitAllSettings.xaml を改変し、両方のConfigファイルを読み込む
・nupkg側のConfigには、エンドユーザに改変されたくない定数を記載
（ものによりますが、読み込みフォルダのパスや管理者メールアドレスなどかな？）
・ローカルディスク側のConfigには、エンドユーザの改変を許可する定数を記載
（メールの件名や本文のテンプレート、Excelで作成したマスタファイルの名前など？）
ロボット固有の設定が必要な場合はこちらに記載（過去事例では必要性はそれほどなかったけど・・・）

試していませんけど、nupkg側の設定をローカル側の設定で上書き出来るようにすると
自由度が上がったりするのかしらね？

1 Like
11

nupkg側の設定をローカル側の設定で上書き出来るようにすると
自由度が上がったりするのかしらね？

似たようなことをしたことありますが、便利でした。

＜やりかた＞
・所定の場所に、設定ファイル.xlsxと同じ名前でJsonファイルを置く（例：設定ファイル.json）
・先に設定ファイル.xlsxを読み取る
・Jsonファイルがあれば、設定ファイルの値を上書きする（なければスルー）

＜メリット＞
・設定ファイル.xlsxをテスト用に変えなくて良い
例）テスト時のメール送信先は自分にしておこう-> jsonに自分のメアドを書いておく

「設定ファイルのオーバーライド」的な使用パターンですね。

1 Like
12

yukino様
いつもご指導ありがとうございます。
うまく設定すればかなり可能性が広がると感じました。
早速参考にさせていただきます。

1 Like
13

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.