みなさんは、UiPathでロボットを用意するときにデバッグモードを使っていますか？
私がロボットを作る際には必ずデバッグモードを内部に組み込みます。たとえば、次の図のようにフロー条件分岐をかませてダミーのデータを読ませてから進むのか、受け取った本番のデータを使って処理を進めるのかを切り替えたりします。
ダミーデータは、引数で受け取るはずの値の分だけすべて用意します。
デバッグモードというと、通常では呼び出せない関数やプロパティが呼び出せたり、より多くの詳細なログを出力するイメージもありますが、UiPathにおいても同じ発想でログの数を増やしてみてもいいかもしれないですね。
ただ、アプリケーションなどの開発とは異なり、UiPathでは通常時であれデバッグモードであれ出力しておくべき内容にあまり差異がないように思うので、個人的にはダミーデータを読ませるか読ませないか以外について差は作らないようにしています。
デバッグモード用のフラグ変数
デバッグモードかどうかを切り替える変数は、変数ではなく引数として管理します。そして、初期値はFalseです。
このxamlファイルを直接編集するとき、ダミーデータを読ませるような場合には手動でこちらをTrueにし、作業が完了したときには必ずFalseに戻します（命名規則はUiPathのワークフローデザインを参照しています）。
初期値がFalseである理由は、単純に他のxamlファイルからinvoke（ワークフローファイルの呼び出し）する際、いちいちin_IsDebugModeをFalseにするのは面倒だからです。
デバッグモード（ダミーデータ読み込み）を用意するメリット
1つのプロジェクトを複数人で開発するとき、invokeするためのxamlファイル単位で分担作業をしているような状況で、本番に使うためのファイルが用意できないときに重宝します。
汎用的なxamlファイルを作っておいて、別のプロジェクトで流用するようなケースでも役立ちます。
いったんすべてのxamlファイルを組み合わせてみて、デバッグモードをTrueにして走らせることで、本番のリソースがない状態でもロジックがうまくいっているのかを検証することができます。
ただし、組織内でxamlファイルを作るときのデバッグ用のフラグ変数をin_IsDebugModeで共通化させておくことが重要です。また、invokeするときには必ず呼び出し元で定義されているデバッグモード変数を受け渡すように設計しておく必要があります。そうしておけば大元のxamlのフラグ変数を変えるだけで全体のデバッグモードを切り替えがうまくいきます。
まとめ
1日だけ空いているのを見て勢いでアドベントカレンダーに登録したものの、普段やっているのはUiPathとJavaScriptでこまごまとしたWeb開発を行うことがほとんどなので、UiPathに特化した内容が書けませんでした。。。
同僚のほうがよっぽど優れたUiPathの活用方法を知っているので、来年はぜひ同僚に書いてもらいたいと思います笑
お粗末様でした…。