【いきなりStudio６】ワークフロー ファイルを呼び出しでガチろう～ガチラーは、Main.xamlに最低限のアクティビティしか組まない( ´∀｀ )
さてと、前回
で、
ロボットとの対話のガチり（ガチな方での遊び）かた
については、触れたので、今回は、
オブジェクト指向言語の醍醐味にして、
StudioとStudioXの最大の違い＝Studioの真骨頂
である
ワークフローを呼び出すアクティビティ
について触れてく💃
では早速、本題( ´∀｀ ）
ワークフローを呼び出すアクティビティ
ま、知識面では、
を見てもらうとわかるとおり、単純に
ワークフローファイルを呼び出すだけ
な簡単なアクティビティ
なんで、
操作としては、
なんだけど、
呼び出すワークフローファイル
を設定してないので
エラー( ´∀｀ )
（実務での考え方を交えながら）ワークフローファイルを追加してく
ただ動けばいいやな人だと、まずは単純に
で追加しちゃおうとするんだけど、
ファイルってことはどこかのフォルダに格納した方が管理しやすい
ので～～～
右クリック＞追加＞フォルダー…の順番でクリック
ここでポイント①：フォルダ名やファイル名は、アッパーケースで書く
これは前回まででゆーた話なんだけど、日本語名でフォルダ名やファイル名は書けなくはないんだけど、Orchestrator上にパブリッシュした後で、そのソースを改修なんかでダウンロードしたときに、
日本語名だと文字化けして涙目( ；∀；)
なんてことになるので、
フォルダ名やファイル名は英語で書くのが基本
で、英語で書くにしても、
一般的なキャメルケースに従うのが基本
でそのキャメルケースなんだけど、どっかの市販の参考書みたいな感じで、最初のうちから、動かしてもないのにそんないっぱい書かれてもうえ～～～っ('Д')ってなっちゃうと思うので、
【キャメルケースの基本】
アッパーケース（大文字始まり）：ファイル名、フォルダ名、引数名
ロワーケース（小文字始まり）：変数名、関数名
くらいなイメージで、UiPathなら十分
とここで恒例の四方山話なんだが、
一歩前へ：じゃあ定数（ロボットの処理中に値が変わらない数）は？って人もいそうなんだが
ま、定数に関しては、UiPath自体が開発環境として、定数の管理みたいな機能を設けていないんだけど、それには理由があって、
定数なんざ、
（今後の記事で紹介する）
Configファイル内でパラメータ化
してくので、
わざわざStudioの中でこれが定数ですよと明示する書き方をしなくてOK
職場によりけりなんだけど、定数については、
わざわざ、ハンガリアン記法におけるスネーク記法で、
TEXT_EXCEL_NAME
みたいな書き方を混在させるような職場もあったんだけど、そんなCOBOLとかFORTRANみたいなメインフレームの時代でもないのに、今時、
スネーク記法＝単語の間を_で繋いでく書き方
なんざ
面倒くさくて仕方ない
オブジェクト指向言語で、他から引っ張ってこれる👉再利用出来る＝【オブジェクト指向言語の醍醐味】
のに、
わざわざやるわけないだろ( ´∀｀ )
いつの時代の開発環境とかプログラミング作法で止まってんの❓👀💦
ってなるし、最新の開発環境とかプログラミング言語に触れていないか習熟していない組織だと、未だに、バカのひとつ覚えみたいに、
スネーク記法をVBAでもGoogleAppsScriptの環境でも使いたがる人がいる
から、変数名とか、引数名、定数名の打ち方をみるだけで
その職場や人の程度が一発で分かるんだよねえ( ´∀｀ )
あ、この会社は十中八九、すっげえ面倒くさいコードの打ち方とかソースの組み込み方をやってんね👀💦
って感じで( ´∀｀ )で、実際、オブジェクト指向言語の醍醐味でStudioの真骨頂でもある、
ワークフローの呼び出し
＝ソースの再利用
を理解してないから、ワークフロー単位で分けて、使いたいときに呼び出せばいいような似通った処理を、すっげえ長いソースの中で、
すげえ長い、アクティビティ繋げただけ処理を違う箇所で使ってる
Configファイルに外出しすればいい変数や引数の値をベタ打ち（＝ハードコーディング）
て感じでね( ´∀｀ )ま、変数や引数については、出てきたときに今後の記事でまた色々な考え方には触れるので、ここではとりあえず
キャメルケースって考え方を知ってもらえれば、充分
じゃ、操作の続きを～～～
ここで左上の新規をクリックして
名前：RobotMain
場所：C:\Users\USER\OneDrive\デスクトップ\GachiriRobot\RobotOriginalて感じで設定して、作成ボタンをクリック
画面が開いた💃
で、上のMainタブをクリックして
これで、ワークフローを開くボタンをクリックすると、
ここまでで、Mainに戻って、保存しておこう( ´∀｀ )
とここで、さっきから
オブジェクト指向言語
ってゆーてるけど、そもそもオブジェクト指向言語って何？って人も居ると思うので、
ここでポイント②：オブジェクトって何？
一般的にゆーと、
オブジェクト＝対象
って意味なんだけど、それだとイメージが湧かないと思うので、今やってるのは、フォルダ名の指定も、
フォルダを指定することでロボットが
そこを見に行ったり、処理を加えたりする
対象物＝オブジェクト
☞まあ、ロボットで言えば、
各部品
ってイメージかなあ( ´∀｀ )
※ACCESSを社内研修で講義するときには、よくテーブルにしろ、クエリにしろ、フォームにしろ、レポートにしろ、まずは、
オブジェクト＝部品
ってイメージしてもらえればOKて話してみんなそれで理解していったし。
ロボットでも、ワークフローにしろ、アクティビティにしろ、プロジェクトにしろ、
何かしらロボットの中の部品（パーツ）をアクティビティで組み込む
その各パーツが組み合わさって色々な処理を行う＝ロボット全体の機能を作る
その各機能が取り扱う処理対象＝オブジェクト
ってだけだから( ´∀｀ )で、その醍醐味を見せる準備と前置きの説明も済んだところで、
オブジェクト指向言語の醍醐味を加味したUiPathStudioの真骨頂をちょっと今から見せてくね～～～
前回やったメッセージをログアクティビティを追加して
Mainに戻って、実行すると、
なんだけど、別にワークフローってファイル＝パーツを呼び出してるだけなので、さっきと同じ要領で、
実行すると、
しっかりRobotMain2で実行出来たのが確認出来た。
要は、ロボットが処理する部品を組み替えてるだけ
Main.xamlの呼び出し元のファイルを変更しただけ
☞Main.xaml自体は、アクティビティを何も追加したり変更したりしてない
つまり、Main.xamlには、
その組織全体で使うロボット共通する最低限のアクティビティを組むだけ
＝ロボット全体の作法とか取り決めに従うだけ
☞それ以外のロボット個別の機能はRobotMainを組みかえればいいだけ
例えば、Main.xamlに必要ならば、後は
エラーが起きたときに呼び出し元から渡される値をログに書く機能
処理結果をメールで実行者に通知する機能
なんかを追加する程度なんだけど、、、
エラーが起きたときに呼び出し元から渡される値をログに書く機能☜別にOrchestratorのジョブログで確認するし、下手なログファイルへの出力は、処理結果の不一致で却って混乱を招くので不要
処理結果をメールで実行者に通知する機能☜Microsoftなど各社のメールアカウントの管理が厳しくなり、無人のPCへのメールアカウント追加は制御され始めているので使えなくなる
があるので、実は結局、
Main.xamlには、シンプルでやる
☞Main.xamlは、基本触らない
のがガチラーの作法なんだよね～～～
ここでポイント③：Main.xamlはロボットの一番外側
「動けばいいや」ってだけな人だとここまでの例と反対で、ワークフローの呼び出しをせずに、
やってることは同じなのに、改修しないといけないときに、
改修する箇所が増えて面倒くさいでしょ👀💦❓
冗長に、全部同じような処理を組んでも、
「それを全部初めて見て一瞬で理解して、バグもなく、完璧に改修が出来るのがプロ！」
なんて思ってる人は、各人とか各職場の好き好きなんでどうぞご自由に( ´∀｀ )それで困るのは自分たちなので～～～
ま、オイラならそんな職場は二度とご免なのでお断るけどね( ´∀｀ )
ここまで見てきて分かると思うけど、結局、
ロボットなんて機能を理解してればある程度、誰でも自由に組めてそれなりに動くものなのに、こーいった作法とか考え方を理解してないから
それをわざわざ難しくしてるのは、
その人（とか組織）自身
なんだよね( ´∀｀ )つまり、Main.xamlは、ロボットの外見で人型だったり、犬型だったりで、
一番外側から見えるロボットの外観＝最低限の機能（頭と手足がある程度）
そのロボットの中身＝RobotMainワークフロー以降の階層で行う
んだよね。実際、Aiboにしろガンダムにしろドラえもんにしろ
ロボットの心臓部分を外から見えるところに曝け出してるロボットを見たことある人いるかしら( ´∀｀ )❓
っていえば、
Main.xamlに安易に、いきなりアクティビティを直接組んでることが、
如何に頭の悪そうなロボットを作ろうとしてるか分かるでしょ( ´∀｀ )
☞RobotMain以降でも、処理単位で、ワークフローを作って、呼び出せばだけだからね( ´∀｀ )
と、ここで処理単位って言葉出てきたんで、
ここでポイント④：処理単位＝マクロかミクロかではなく、メゾ（メゾスコッピック）
ま、最近、2000年代前半から
YesかNoか
勝ち組か負け組か
みたいな
対立軸思考
でしか物事を考えない人が増えて、
処理単位
って言葉を出すとすぐに、
ミクロかマクロか
みたいな捉え方をする人が多いんだけど、経済学や統計学の
マクロ経済学、ミクロ経済学
マクロ統計、ミクロ統計
から来てるのかなと思うけど、その経済学や統計学も、実は、
量子力学における
極大反応（マクロ）、極小反応（ミクロ）
から取ってきてるだけで、それを経済学なんかに引用してきてた人達すら、
量子力学の格言：マクロとミクロだけを見てると、全体を把握できない
☞メゾスコピック（中間）を見よ
を知らなかったりするからねえ( ´∀｀ )。どのプログラミング言語や開発も同じで、
あたりでCODECOMPLETEでも書いてるとおり、ひとつの家を作るとして、
家全体＝マクロだと大きすぎる
家を構成する扉であれば、ネジ・蝶番、台所なら流し台、シンクといった部品単位＝ミクロだと小さすぎる
から、
家の構成要素単位
（＝扉なら扉、キッチンならキッチンって単位）
☞メゾスコピック
で処理とか工程を分けるでしょ👀❓それと同じで
ロボットの処理単位
何かのフォルダを確認する、なければ作る
何かのファイルを確認する、なければ作る
何かのサイトにログインをする、ログインできないときはエラー
何かのサイトの表データを取得する、取得できないときはエラー
取得した結果をに書き込む…
てな感じで
ちょうど良い単位の処理をワークフロー単位で小分けにしてく
使いたいときに、ワークフローを呼び出す
☞共通する処理を二回組まない
それを実際にロボットにやっていけば良いだけ
☞シンプルイズビューティフル
【ビール片手にUiPath StudioX 】シリーズから読んでくれてる人だと、これまでの記事＝StudioXのソースの組み方の最大の矛盾点に気づいてるとは思うんだけど、
StudioXで作ったソース
で、思いっきり、
今までソースをMain.xamlで組んでたじゃねえか(# ﾟДﾟ)
話が違うぞ。舐めとんのか（#^ω^）
なんだが、ま、これには理由があって
実はStudioXの
開発者
に✓を入れると出てくるし、StudioXでも使えなくはない機能なんだけど、、、
でも書いた通り、StudioXの機能として
参照を検索がない☞管理が面倒くさい
のと、結構後付けで使えるように追加された機能なんで、
中途半端になる
から、
【UiPath StudioXの遊びかた】編では
一切使っていない
んだよねえ( ´∀｀ )てか、そこまで高度なことをやりたいなら、
（初心者向けではなく、
ちょっとしたロボットを作るって意味の）
簡易版＝StudioX
でやるよりも、
標準的な機能がちゃんと充実してる
標準＝Studio
でやった方がいいからねえ( ´∀｀ )
あくまでも、（やり始めたばかりか否かにかかわらず）UiPathの開発は、
ロボットを作り込む＝ガチる ： Studio
（ガチりではない、ちょっとした）簡易的なロボットを作る程度 ： StudioX
なんだよね。
なんかで当初は本当に、
最低限の機能（変数すらない）
から始めたんだろうけど、後付けで使えるアクティビティを追加していった結果、
使えるアクティビティについては、
もはやStudioと遜色ない
にも関わらず、
よく調べもしない人が、
数年前の触れ込みを未だに信じ込んで、
StudioXは今でも簡単で初心者向け
だと勘違いしてる
↓
初心者向けの社内研修なんかで使う
↓
付いていけない人や脱落者が増える
↓
こんな無料記事でも
参考にしてくれる人がいる
↓
学びの裾野が広がる
からねえ🧐
オイラは、プログラミングやったことがない人が、いきなり変数や引数、オブジェクト指向プログラミングなんて言われてすぐに理解できるとは思わんが？
変数を理解せずに、Excel行の繰り返し処理なんて簡単に使いこなせるんだろうか？
どこが初心者向けなの？🧐
さてと最後に、オイラが忘れないうちに、これは近いうちにちょいとコラム（ちょいコラ）で、独立させようかなと思ってるけど、今後の記事でも大事なので、StudioXの時に書いてた
と似てるけど、Studio用の考え方を、、、
もう一歩前へ：Studio開発での原則
最初から、今後の改修を意識しながら新規でも開発する＝作法を身に付ける
再利用を意識して、シンプルなソースを組む＝シンプルイズビューティフル
ロボットは安全にこかす＝「ロボは止めても、事故は起こすな」（TryCatchは極力使わない。安全にエラーを起こさせる）
小さく作って、大きく動かす（どんな大きなロボットも紐解いていけば、小さなワークフローの固まり）
コードは極力書かない（ローコードツールなのにコードを書いている時点で、設計がうまく行ってない危険信号）てか、コードで済ますなら、こんなGUIは要らない。
まとめ
ワークフローを呼び出すアクティビティを使えば、以上で見てきた通り、
オブジェクト指向言語の醍醐味＝再利用
をふんだんに使った
ロボット開発が出来る
☞冗長なソースを組まないで済む。
ま、逆にそれを意識しないで、「動けばいいや」で
ノーパソ以外のディスプレイを使ってる時点で、再利用での組み方が出来てないから、
どっちみち同じ
お金とか他の便利な機材に最初から依存してる時点で
知恵は身に着かないからねえ( ´∀｀ )
オイラなんて、この記事ですら
で書いてるとおり、10年以上前にソフマップでリユース品で買うた
４GB（UiPathを使う最低要件）
のLenovoのノーパソで、UiPathの画面なんざ
画面でやってるけど、
全然苦に感じないもん。
ま、内容としては以上かな( ´∀｀ )
（StudioXの記事でやってた恒例の）ソース・リファクタリング
後は、それぞれ前回の要領で
アクティビティ名と注釈を追加
して、ソース・リファクタリング後～～～
■Main
■RobotMain
とまあ、今回はめっちゃシンプルで簡単な操作なのに、、、
各アクティビティを覚えるよりも、実は、そこに通底する考え方や作法を
知る
使う
身に付ける
を盛り込みながら書いたからまたまた、長文に💦ま、序盤で触れるこの
考え方や原則が如何に今後大事か
をこれからの記事で紹介してくや( ´∀｀ )
さてと、次回は
いよいよ、Configファイルを読み込ます設定の入り口
変数と引数の設定方法
に入ってく💃
ここも今後すっげえ重要だから、また長文になるだろうなあ( ´∀｀ )
ではまた、次回
この記事が気に入ったらサポートをしてみませんか？