Process Dispatch Frameworkとは？

  フレームワーク

Process Dispatch Frameworkとは、リアルタイムにプロセスを稼働させるためのフレームワークのことです。

今までプロセスを稼働させるパターンとして多かったのは、セッション実行、スケジュール実行だと思います。

ただ、セッション実行だといちいちリソースにドラッグ＆ドロップしないといけないので面倒。スケジュール実行は、予め設定したスケジュールの時間になるまで待たないとプロセスが開始されません。

いずれにしても、「動かしたいときに、自動的に動かせない」といった課題があります。
そして、BPのユーザー会やコミュニティの話を聞く限り、いわゆる「即時実行」のニーズは結構高い。

海外では、Process Dispatch Frameworkを用いたプロセスの開発が主流になりつつあるようです。
なので、今回はその「即時実行」を実現する仕組みを、日本語版BPにも導入してみようと思います。

仕組み

そもそも、Process Dispatch Frameworkはどうやって即時実行を実現しているのか。仕組みから見てみましょう。

以下の図は、Process Dispatch Frameworkをダウンロードしたときに付属しているPDFから抜粋したものです。

複雑そうに見えますが、整理すると

  1. SOAPリクエストをBPに送り、プロセス実行指示を出す。
  2. Process Dispatcherオブジェクトが実行指示を受け、AutomateC経由で、即時実行したいプロセスを実行する。
    正常に実行が完了したら、ワークキューにキューデータを投入。
    実行したいプロセスが存在しない場合など、SOAP Requestがそもそも通らない状況だった場合は、キューには何もデータを入れず、失敗した旨を返して終了。
    プロセスはあったけど、そのプロセス内で異常終了した場合、ワークキューにデータは投入されるが、キューステータスは「失敗しました」として登録される。
  3. （下の図）Dispatched Process Monitorは2.で登録されたワークキューの状態を絶えず監視します。（1分に1回など、スケジュールをぐるぐる回す）
    もし、pending（保留中）状態のキューがあれば、キューステータスを確認する。ステータスが「COMPLETED」なら、そのキューを完了マークする。
    「失敗しました」など、その他のステータスの場合は、そのキューを「延期」する。デフォルトの設定だと10分延期。

といった流れになります。分かりにくいですね（笑）
順を追ってやっていきましょう。

導入方法

まずはProcess Dispatch Frameworkをダウンロードします。
https://digitalexchange.blueprism.com/dx/entry/9648/solution/process-dispatch-framework

ダウンロードしたら、BPにインポートします。
これで準備OKです。

準備

SoapUIをインストールする

まずは、SOAPリクエストを送るためのツールである「SoapUI」をインストールします。「Download SoapUI Open Source」をクリックしてください。

https://www.soapui.org/downloads/soapui/

インストール手順は割愛しますが、特に特別な設定はありません。（たぶん）

オブジェクトを公開する

SOAPリクエストを受け付けるオブジェクトである「Process Dispatcher」を公開します。

システムタブ　→　オブジェクト　→　公開をクリックし、
右側にある「ビジネスオブジェクトを公開」をクリックします。

Process Dispatch Frameworkフォルダの「Utility – Process Dispatcher」を選択し、次へボタンをクリック。

ビジネスオブジェクトの公開名はデフォルトのままとします。
完了ボタンをクリック。

すると、「Webサービスとして公開されたビジネスオブジェクト」欄に、新しくオブジェクトが表示されているのが分かるかと思います。

これで、「Utility – Process Dispatcher」オブジェクトがSOAPリクエストを受け付けられる状態になりました。

認証情報を定義する

認証情報を定義します。認証情報を設定するにはBP Server経由でBPのDBに接続する必要があります。（その設定方法については今回は割愛します）

今回は「BP admin」という認証情報を新規作成します。

ユーザー名、パスワードにはBPログイン時に使っているものを入力します。
アクセス権は一旦全ユーザー、プロセス、リソースに付与しておきましょう。

リソースプールを設定する

プロセスを稼働させるリソースプールの設定をします。

今回は自端末の中でポートを分けてランタイムリソースを起動させている前提で、8182～8185を１つのプールに設定します。
プール名は「DispatchedProcessPool」とします。

自端末に複数のランタイムリソースを起動する方法、プールの設定方法についてはこの記事では割愛します。

Process Dispatcherを微修正する

残念ながら、Process Dispatcherオブジェクトは日本語版BPに対応していません

一部日本語版BPに対応させるための微修正が必要です。

Run Processアクションの修正

1．Success?ステージの修正

修正前：StartsWith(Upper([Output]), “STARTED PROCESS”)
修正後：Left([Output], 8) = “開始済みプロセス”

2．Get Session IDステージの修正

修正前：Mid([Output], InStr([Output], “Session:”) + 8, 36)
修正後：Mid([Output], InStr([Output], “セッション：”) + 6, 36)

Get Process Statusアクションの修正

3．Error?ステージの修正

修正前：StartsWith(Upper([Output]), “ERROR:”) OR InStr(Upper([Output]), “STATUS:”) = 0
修正後：StartsWith([Output], “エラー”) OR InStr([Output], “ステータス”) = 0

4．Get Statusステージの修正

修正前：Mid([Output], InStr([Output], “Status:”) + 7, (Len([Output]) – InStr([Output], “Status:”) + 7))
修正後：Mid([AutomateC 出力], InStr([AutomateC 出力], “ステータス：”) + 6, (Len([AutomateC 出力]) – InStr([AutomateC 出力], “ステータス：”) + 6))

即時実行したいプロセスを用意する

即時実行したいプロセスを用意します。

今回は「dispatchテスト」というプロセスを作ります。
中身は何でも良いのですが、今回は代入ステージのみ用意したシンプルなものにします。

作り終わったら、「このプロセスをコントロールルームに公開」にチェックを入れておきましょう。

SoapUIでプロジェクトを作る

SoapUIでSOAPリクエストを投げるための準備をします。

リクエストを投げるためには投げる相手が必要です。先ほど公開した「Utility 　Process Dispatcher」オブジェクトがその相手になるわけですね。

ここでは、リクエストの投げるための準備をしましょう。

またSoapUIの画面に戻り、画面右上の「SOAP」ボタンをクリックします。
すると、New SOAP Projectというウインドウが開くはずです。

Project NameとInitial WSDLの２つの入力が求められているようです。
順番は前後しますが、Initial WSDLから入力しましょう。でも何を入れたらいいのか…？？

http://[自分の端末のマシン名（ランタイムリソースの名前）]:[ポート番号（デフォルトは8181]/ws/

上記URLを自分の環境に合わせて作り、試しにブラウザでアクセスしてみましょう。こんな画面が出るはずです。

今回公開した「Utility Process Dispatcher」（公開オブジェクト名）が表示されていることが分かります。リンクをクリックしてみましょう。

XMLで書かれたAPI定義です。
Utility Process Dispatcherオブジェクト内の各アクションに対して、リクエストを投げるために必要な入力パラメータなどが定義されています。

つまり、「オブジェクトを公開する」とは
オブジェクトのAPI定義をXMLでWeb上に公開する、ということですね。

それはさておき、SoapUIのInitial WSDLに入れるパラメータですが、
以下画面のURLをそのまま貼り付けます。
今回の例だと、

http://[自分の端末のマシン名（ランタイムリソースの名前）]:[ポート番号（デフォルトは8181]/ws/UtilityProcessDispatcher?wsdl

となります。

Initial WSDLに貼り付けると、自動的にProject Nameが設定されます。
今回はちょっと修正して、「UtilityProcessDispatcher」にしておきましょう。

すると、画面左側に「UtilityProcessDispatcher」というプロジェクトが作られていることが分かります。

今回は、RunProcessというアクションをSOAPリクエスト経由で起動してみます。
このProcess Dispatch Frameworkの起点は、このRun Processアクションへのリクエスト送信となります。

項目名パラメータ
bpInstanceauto
UseSSOFalse
BPCredentialNameBP admin
ProcessNamedispatchテスト
ProcessParameters–
CallbackInfo–
ResourcePoolNameDispatchedProcessPool

また、プロジェクト欄の下にある「Request Properties」にも設定が必要です。

項目名パラメータ
Username（BPログイン時のユーザー名）
Password（BPログイン時のパスワード）

動かしてみる

Process Dispatcherを動かす

では、いよいよプロセスをSOAPリクエスト経由で動かしてみます。

SoapUIの「Request 1」ウインドウに表示されている実行ボタンをクリックします。

正常にオブジェクトにリクエストが渡れば、以下のような結果が返ってくるはずです。

セッションIDと、プロセスを実行したランタイムリソース名が分かりますね。

BPの画面を見てみましょう。
コントロールタブを開き、セッション管理画面を表示します。

確かに「dispatchテスト」プロセスが実行されたことが分かりますね。

ワークキューを見てみましょう。
Dispatched Processesというキューがあるかと思いますので、中身を見てみます。

SOAPリクエストを投げて返ってきた結果に、セッションIDがあったと思いますが、そのセッションIDと同値のキューデータが入っていますね。

これらのキューデータに対して、Dispatched Process Monitorプロセスが定期的に監視しているわけです。

Dispatched Process Monitorを動かす

本来はスケジュール実行なのですが、今回はデバッグ実行でDispatched Process Monitorプロセスを動かしてみます。

※一部日本語訳している部分があります

プロセスの実行完了後、改めてキューデータを確認してみましょう。

「dispatchテスト」プロセスが正常終了しているので、キューも完了マークされています。
もし「dispatchテスト」プロセスが異常終了した場合は、キューが延期されます。

まとめ

仕組み自体はそれほど難しくはないのですが、動かすまでの準備が色々とあり、戸惑うかもしれません。

今回はSoapUIでSOAPリクエストを投げましたが、SlackやTeamsなどから投げられれば、一気に即時実行が身近になるかと思います。

また、即時実行したいプロセスが何らかの理由でエラーになった場合、キューを「延期」すると説明しました。延期したキューから対象のプロセスを再稼働させるのは手動？という疑問が解決していません。

アクティブキューとか使えるのかな？と思いつつ、引き続き調べてみたいと思います。

Process Dispatch Frameworkの日本語版もあります。
より分かりやすく再構築されたフレームワークですので、こちらについても別記事で解説します。

遅延実行（タスクを溜め込み、順次処理する）フレームワークもあります☆

LEAVE A COMMENT

CAPTCHA