TryCatchのハナシ(延長戦)~反省会とTerminate Workflowを使ってみる~

はじめに

①この記事はUiPathブログ発信チャレンジ2022サマーの1日目の記事です。
(〃▽〃)ﾎﾟｯ
翌日以降も続々とUiPath記事が登場しますので、ぜひ投稿&閲覧&LGTMをしてくださいね！
参加方法は以下のブログを参照ください。
https://note.com/shumpei_w/n/n19383ce5abb1

②今回紹介するUiPathの情報は以下の通りです。
■Community Edition 2022.4

③この内容は、2022/7/1時点の情報です。
(将来バージョンやライセンス等の事情で内容が変更になる可能性があります)

UiPath女子部LTについて反省会

前回、私はあるイベントでLT登壇しました。¹

それは以下のイベントです。(アーカイブもあるのでぜひ見てくださいね)
UiPath Friends Women's Community vol.6 ～「井」の中におさまらないのがカエル女子。失敗談をバネに飛び出そう！～
https://www.youtube.com/watch?v=N8Mh1L9ahXk

登壇してよかった？点は以下の通り

　・とりあえず時間ギリギリ(オーバーせず)終了できた
　・以前から発表のご要望があったので、実現できた

しかし、以下の問題点が見つかった。

　・みんなの知りたい内容、自分と参加者のニーズの相違(マーケティング不足？)
　・5分で盛り込みすぎたε≡≡ﾍ( ´Д`)ﾉ　発表時間が足りない...？
　・思ったよりウケが悪い？(疑惑)

本当は「Orchestratorのライセンス周り」のハナシとか、実践でためになる？情報がいいのかな。
次回はどのテーマにしようかと悩んでおります。はい。

思ったこと

そもそもですが。。。
「私は、Try Catchマスターになれたのか？？？」
TryCatchは確かに安定したロボット作りには重要なものです。
「エラーは、ただ投げていいもんじゃない」

なので、延長戦をこのブログでやります。

Try Catch！！！

おさらいとして、TryCatchアクティビティとはどういうものなのでしょうか。

Try：実際に動かすフローを配置
Catch：エラー発生時、エラーの内容によってどんな動作をしてほしいかのフローを配置
Finally：TryでもCatchでもフローが最後まで進んだ後、やってほしい作業のフローを配置

ざっくり説明していますが、エラーを捕まえて次にこうしてほしいアクションを実行するためのモノがTryCatchになります。
当然、TryCatchがなければ画面が停止したままで何もエラー検知できず、気が付くと顔が真っ青...ということが
起こるわけです。
(それは、I〇E〇の青いドーナツのように(コラΣ（・□・；))
上記のような大げさではなくても、安定稼働の為にこのアクティビティは必須ですね。

ThrowとRethrow

LTの中でも発表していますが、ThrowとRethrowは同じエラーを投げるアクティビティです。
2つのアクティビティはどのように違うのでしょうか。
(下記はLT登壇時にざっくり説明したものです)

まずThrowは、エラーの際に「じゃこのエラー時はこういう風に対応しましょ」というものをワークフローに示します。

一方、Rethrowは(よく子xamlに)Main側のCatchにエラーを投げたいときに使います。

では、LT登壇時に紹介できなかったあるアクティビティについて触れたいと思います。

Terminate Workflowって何？

これまでどこの現場でも一度も使用したソースを見たこともない、私は使ったことがないアクティビティがこれ。

プロパティを覗いてみる。

このアクティビティはTry CatchやThrow,Rethrowと同じカテゴリ(エラーハンドリング)に存在するアクティビティなのですが、
使っている現場、これまで見たことがない。
どうやって使うのか実験してみましょう。

Terminate Workflowってどんな時に使うんだ？

もっと深堀してみましょう。

エラーを対処するアクティビティなのですが、どんな感じで使うのでしょうか？
ということで、以下簡単なフローを作ってみました。
このフローでは、変数straaa(文字型)に「私はUiPathが大好きです」という情報を格納し、その後If条件で変数straaaに「AWS」の単語が含まれているかを調べます。
あればそれはそれでOK、なければCatchにエラーを投げます。
(今回のケースでは、エラーになりますね)

Catch内のフロー&Terminate Workflowのプロパティは以下のとおりです。

上記のフローを実行してみると、以下のポップアップが出現しロボットが止まりました。

ログを覗くと以下のようになります。

TerminateWorkflowアクティビティの時点でロボットは停止し、後続処理にあるログ「Terminateを調べる END」は出力されずに終了しました。
一見便利そうに見えますが。。。

なんでなかなか使われないのだろう？

先ほどの例のように、Terminate Workflowアクティビティを使うとその時点で停止します。
その場で止めてしまう=後続処理をしないということになるので、Try Catchアクティビティでいうとその後のFinallyでの処理やENDのログも出てこないことになります。

通常、エラーが発生すると以下の対処を行うと思います。(下記は一例です)
　・スクリーンショットを撮影し、エラー時点の状況を抑える
　・メールを送信(「異常終了しました」とかそういう感じ)
　・エラーになったものはとりあえず初期化、再実行する(Webサイトであればいったん閉じてまた開くとか)
　・エラーになったものは仕方がないので、処理結果には失敗とかで処理して次のデータを処理する
　・その場で強制終了(あとは手動でがんばれ)

上記の理由からエラーを検知して最後まできちんと処理を終了する必要が出てくる仕様の場合は、採用しづらいのかと思います。

もしTerminate Workflowアクティビティを使いたいなら、
・設計時に強制的に停止して問題はないのか(その企業で使用禁止アクティビティに設定していないか、使用して問題ないのか)、
　 その現場でエラー時のフォロー体制は十分なのか
・Terminate Workflowアクティビティに進む前に、メール送信やスクリーンショットの撮影等、必要な動作を実行するように実装
・強制的に止めた場合、その後のフォローはどうするのか

等の事前検討や対応が必要なのだと思います。

まとめ

Terminate Workflowアクティビティは便利そうな印象があったのですが、そういえばどの現場でも実装した人はいなかったし
自分も実装したことがない為よくわからない状態でした。
もし利用される場合は、所属先の現場で使用しても問題がないか、止めた場合のリカバリーやフォロー等についてよく確認しましょう。
(使用する場合は、自己責任でお願いします)

それでは、ごきげんよう！

1. ライトニングトークのこと。5分等短時間でプレゼン等を発表します。
   皆様もぜひやってみましょう(宣伝じゃないですよ。Σ(･ω･ﾉ)ﾉ！)。 ↩