Go to Qiita Advent Calendar 2024 Top
LoginSignup
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

RPA (Robotic Process Automation)Advent Calendar 2021Day 15
@irohamaru(irohamaru)

Blue Prismでファイルトリガー実行を実現してみる

Last updated at Posted at 2021-12-15

#1. 今回やりたいこと
所定のフォルダにファイルが配置されたら起動するロボットを作りたい。
いわゆる、ファイルトリガーで起動するロボットですね。

後で再掲しますが、こんな感じで実現しました。

#2. 前提

  • Blue PrismというRPA製品を使います。バージョンは6.10.1
    • UiPathやAutomation Anywhereには標準機能でトリガー実行できる仕組みがありますが、Blue Prismにはありません。あったらごめんなさい。
  • 2つの業務を1台の端末で実行するものとします。
  • 2業務とも、所定フォルダに任意のExcelファイルが配置されたことをトリガーにして実行されるものとする。

2.1 なぜトリガー実行？

RPAのロボットを実行させる方法として、パッと思いつくのは

  • 手動実行
    • ボタンを押したら実行される。利用者のデスクトップで実行する場合はこの形式が多い。
  • スケジュール実行
    • 複数のプロセス（他のRPA製品では「シナリオ」とも言います）を順次実行するスケジュールを組み、一定の時間間隔で回し続ける。

Blue Prismを使う上で手動実行させるプロセスを作ることは稀だと思われるのでスルーします。
Blue Prismにおいてはスケジュール実行でRPAを運用するのが基本です。

スケジュール実行のメリットは完全自動でプロセスが動き続けるため、人手が介在することがなく、運用コストがかからないことです。（もちろんエラー発生時のリカバリ対応などは必要です）
ただ、例えば1分おきにスケジュールを回し続けるような運用にしていると、セッションログが溜まりまくってDBの容量を圧迫してしまいます。
プロセスが業務を行っていればまだ良いのですが、空振りし続けた分もログが溜まっていくのは何とかしたいものです。

また、Blue Prismでは本番稼働している最大同時実行数＝必要なライセンス数となっており、
前述したようなスケジュールで、1台のランタイムリソース（プロセスが稼働する端末。以下、RRと表記）を1つの業務が占有してしまうことで、ライセンスを食いつぶしてしまいます。

つまり、必要なときだけ自動でプロセスが稼働する仕組みがあればライセンスを節約することができます。
その仕組みを実現する方法がトリガー実行というわけです。

#3. 構成
image.png

各業務ごとにフォルダ監視プロセスをバックグラウンドで実行可能なプロセスとし、1台のRRで2業務の監視プロセスを常に稼働させます。
プロセスをバックグラウンド実行可能にするためには、プロセスで使っている全てのオブジェクトの実行モードがバックグラウンドである必要があります。

所定のフォルダへのファイル配置を検知したら、AutomateC.exeを用いてコマンドラインで業務処理プロセスを実行します。

後ほど触れますが、監視プロセスと業務処理プロセスを分けたのは、監視プロセスをバックグラウンドで実行したいためです。
業務処理プロセスは、システムを画面操作する処理がメインなのでフォアグラウンドで実行させます。
そのため、監視プロセス内でサブプロセスとして業務処理プロセスを呼び出す仕様としてしまうとフォアグラウンドでしか実行できなくなってしまい、複数の業務の監視プロセスが1台のRRでマルチに稼働できなくなってしまいます。

業務処理プロセスの構成は、メインとサブに分けています。
メインプロセスから業務処理を行うサブプロセスを順次実行する仕組みとしました。
この理由については後ほど触れます。

#4. 実装
###4.1 フォルダ監視プロセス
image.png
image.png

時系列で処理を追っていくと、

1. RRの端末名を取得する。
2. 未処理フォルダにファイルが存在するかチェックする。
3. ファイルが存在する場合、環境ロックをかけてRRを占有し、他の業務処理プロセスは実行不可にする。
   環境ロック名は1.で取得した端末名とする。
4. 業務処理プロセス実行ページにて、コマンドラインで業務処理プロセスを呼び出す。
呼び出してからプロセスが実行されるまでに若干ライムラグがあるため、5秒程度Waitを挟み、プロセスが実行される前に環境ロック解除されることを防ぐ。
5. 環境ロックを解除し、RRの占有を解く。
6. 次の監視まで15秒Wait。
以降1～6をループ。

###4.2 業務処理プロセス
image.png

業務を行うプロセスを順に繋いでいるだけなので、説明は割愛します。

##5. ポイント
各プロセスの実装におけるポイントです。

###5.1 コマンド設定
image.png

コマンドラインオプションについては↓を参照してください。
Blue Prism 6.10 コマンドラインオプション

特定のRRに対してプロセスを実行するためのコマンドは以下のようになります。

/C AutomateC.exe /run {$実行プロセス名} /resource {$RR名} /port {$ポート番号} /user {$BPログインユーザー名} {$BPログインパスワード}

監視プロセスの冒頭で{$…}の中を埋めてコマンドを完成させます。
**{$BPログインパスワード}**にはパスワード型のデータアイテムを代入しており、代入後にパスワードが丸見えになってしまっていますが、「プロセス実行コマンド」自体をパスワード型にしてしまっても、コマンドラインでの実行はできました。
気になる人はコマンドをパスワード型にしておくと良いでしょう。

###5.2 ファイルの存在チェック
image.png
今回はExcelファイルであることを前提としているので、Get Filesの入力：Patterns CSVのパラメータは*.xlsxとしています。
取得したExcelファイルの数が>0であれば、業務処理プロセスを呼び出す処理へ遷移することにします。

###5.3 環境ロック
Excelファイルが存在していたら業務処理プロセスを実行させるわけですが、実行前にRRを占有するために環境ロックという機能を使います。
環境ロックとは、他のセッション（＝RRに割り当てられているプロセス）のアクセスをロックする仕組みです。
例えば、特定のプロセスでExcelファイルへの書き込みを行う処理があったとして、それを3台のRRで同時にファイルにアクセスしてしまうと2台は書き込みができずエラーとなってしまいます。
このような時に環境ロックを使い、

  1. 書き込み前にロックをかける。他のセッションはロック照会⇒ロックがかかっていたら指定した時間だけ待機。
  2. 書き込みが終わったらロックを解除する。
  3. 順番待ちしていた他のセッションがロックをかける。

…といった具合に、ファイルへのアクセスを制御することができます。

image.png

この機能を活用して、AutomateCからの業務処理プロセス実行指示が完了するまでRRを占有する仕組みを作ります。
ロックをかけるには名前を指定する必要があるのですが、名前はRR名が分かりやすいでしょう。
そのRR名でロックがかかっていないか照会し、かかっていなければロックをかけます。

image.png
image.png

ロックをかけることに無事成功したらトークンが返されます。
このトークンはロックを解除するときに使います。

###5.4 業務処理プロセスのコマンドライン実行
image.png
image.png

ここが一番のポイントかと思います。

コマンドラインを使ってコマンドを実行するためにはUtility - EnvironmentオブジェクトのStart Processアクションを使います。
ただ、このアクションではコマンドの実行結果が返却されないため、プロセスが正しくキックできたかどうかを判別することができません。
例えばRRが他のセッションで使われている場合は、同RRにてプロセスを実行させることができずエラーとなります。（※）
※実行中のプロセスの実行モードがバックグラウンドであれば、バックグラウンド or フォアグラウンドのプロセスは並行して実行することができます。実行モードについては↓を参照してください。

オブジェクトの実行モード（フォア / バック / 排他）

コマンドの実行結果が返却されるように、Start Processをベースに別のアクションを作ることにします。
余談ですが、アクションを自作するときはオブジェクトを複製し、拡張用のオブジェクトを用意することをおすすめします。
今回は**プロセス実行（ExitCode返却）**というアクションを自作しました。

image.png

If Arguments<>"" Then
  Dim proc1 As System.Diagnostics.Process = System.Diagnostics.Process.Start(Application, Arguments)
  proc1.WaitForExit()
  ReturnCode = proc1.ExitCode.ToString()
Else
  Dim proc2 As System.Diagnostics.Process = System.Diagnostics.Process.Start(Application)
  proc2.WaitForExit()
  ReturnCode = proc2.ExitCode.ToString()
End If

コマンドの実行結果はReturnCodeとして返却されます。
ReturnCodeが0のときはコマンド実行成功。1のときはエラーすなわちプロセスが実行されなかったことになります。
image.png

今回の場合はロジックを簡易にするため、プロセスのキックに失敗した場合はロックを解除する処理に遷移する以外は特に何も処理を入れていません。
他のセッションによってRRが占有されていて待ち状態になることは多々あると想定されるため、例外のログも出力しないようにし、無駄なセッションログは出力しないようにしました。
監視プロセス全体としても、ログの制御は全体的にエラーのみもしくは無効にしています。

image.png

キックに成功した場合もロック解除の処理に遷移しますが、キックしてからプロセスが実行されるまでに若干タイムラグがあるため、実行されないうちにロックが解除されないように5秒ほどWaitを入れています。

###5.5 環境ロック解除＆スリープ
image.png

業務処理プロセスが実行されたことが確認できた後、環境ロックを解除します。
解除したら、再び所定フォルダへのファイル配置を監視する処理に戻ります。
すぐに監視に戻っても良いのですが、15秒程度Waitを入れています。
秒刻みでファイルが投入される業務はあまりないと思うので、もっと監視間隔を空けても良いかもしれません。

###5.6 業務処理プロセス
image.png

顧客管理システムへの入力業務を例とし、業務を構成するプロセスが2つあるものとします。

今回は1つのメインプロセスから2つのサブプロセス（業務を実行するプロセス）を呼ぶ構成としていますが、Blue Prismのベストプラクティスではサブプロセスの呼び出しはあまり推奨されていません。

image.png
引用元：Blue Prism 開発ベストプラクティス 第３回

なのでできれば避けたかった手法なのですが、他業務の割込みなしに1業務を完遂するためにこのような構成にしました。

image.png

例えば、Aという業務を行うために作業a1, a2を行う必要があるとし、作業a, bとも1プロセスで完結するものとします。（プロセスa1,a2とする）
プロセスa1⇒プロセスa2の順で作業を行うとすると、a1が完了してa2が実行されるまでに数秒でもRRがアイドル状態（＝プロセスが稼働していない状態）があると、他の業務のプロセスが割り込む可能性があります。そうなると、業務Aが作業a2を残して終わってしまうことになります。

そのため、業務が複数の作業で構成される場合はすべての作業が終わるまで、他の業務が割り込まない仕組みとしなければなりません。
その仕組みとして、メインプロセスからのサブプロセスを呼び出す手法をとったというわけです。

この方法がベストというわけではなく、例えば前述した環境ロックを応用して1業務を完遂するまでRRをロックする仕組みが作れるかもしれません。（筆者は未検証です。。。）
良い方法があればコメントお願いします。

#6. で、うまく動くの？
一応うまく動くようです。

#7. 最後に
一応トリガー実行は実現できました。
ただ、業務処理プロセスの構成はもっと考えたいですし、運用時のリカバリがしやすい仕組みかと言われると？かもしれません。参考になれば幸いです。

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?