ワークキューの使用について

[NarihitoShinon1]

​お世話になっております。岡三情報システムです。

ROMに従ってソリューション設計を行うにあたり
プロセスとプロセスで連携するワークキューの数について悩んでおります。

今考えている設計ではプロセスとプロセスを繋ぐワークキューは
1つずつにしようと思っておりますが、
先日内部レビューを行った際に分けてもよいのではないかという意見があり
悩んでいる次第でございます。

添付資料を参考にBPのROMに従うとどちらが正しいのか皆さんのお知恵を頂ければ幸いです。

以上です。よろしくお願いします。

------------------------------
Narihito Shinonaga
------------------------------

[HidetoshiSuzuki]

資料を拝見して、自分の解釈が正しいか自信が無いのですが
プロセスA～FやプロセスA1～F1はあくまで同じプロセスで、複数端末で（or 順番に異なるキューアイテムを）実行している状態を表していると捉えてよいでしょうか？
（そしてプロセス●A～●Cと、プロセス▲A～▲Cがまたそれぞれ同じプロセス）

この前提ですと「現在」の案の場合はWorkQueueAの登録時にタグ「●」や「▲」を付けて
タグフィルターで●と▲がそれぞれのタスクを取得していくイメージになりますよね。（キーフィルターを使う手も無くは無いですが）
一方「別案」の場合はタグで分別する代わりにキュー自体を分けてしまうことになります。

私見ですが、この選択に絶対の正解はありませんので、その業務の性質や将来的拡張を具体的に考えて決めるしかないかと思います。。。
私であれば例えば以下を考慮します。

・●と▲にそれぞれ同一キー項目のレコードが追加される可能性があるか
　→（まあキー項目の設計次第ですがプロセスの性質から見て妥当なキー項目を設定するとして）
　　キューのキー項目は（リトライを除き）キュー単位で重複しないよう作成するのが妥当です。
　　もし重複する可能性があるなら、分けた方が良いでしょう。

・パターン「●」と「▲」以外が追加されていく可能性があるか
　→まずこのパターンがどんどん増えていくような性質なら、それごとにキューを作るのは煩雑ですので1キューのタグで分けるでしょう。
　　また「パターン■を増やしたけど▲の亜種なのでプロセス▲がどちらもアイテム取得し、途中で場合分けすることにした」
　　みたいなことがありえそうなら、1キューのタグになっている方が拡張しやすいですね。

・「▲」と「●」のキュー実行結果や統計情報を後からまとめて参照するようなプロセスを作成する可能性があるか
　→結果や統計情報を更に別のプロセスから参照する場合、対象キュー自体が複数だとそれを参照する側のプロセス側で
　　キュー名マスタの管理やループ処理が必要になり、若干面倒です。1キューにする気がします。


またもし最初の前提が違う（プロセスAとプロセスBが別のプロセス）ようですと、根本的にかなり特殊なケースです。
ワークキューには基本的に同種のタスクを集めますので、登録側に経路が色々あったとしても取得側プロセスの種類自体が多数になることはあまりありません。
もう少し詳しく業務内容を知らないと、そもそもベストプラクティスに沿っていないのか、沿ってはいるが業務自体が特殊なのか判断できません。

------------------------------
Hidetoshi Suzuki
Nissho Electronics
Asia/Tokyo
------------------------------

[ykoike]

東芝ＩＴサービス　小池です。

ＲＯＭは見てないので（笑）なんとも言えませんが、ワークキューを設計する際には
以下のドキュメントを参照しています。

（Advanced Work Queue Guide）
https://portal.blueprism.com/system/files/documents/Blue%20Prism%20-%20Advanced%20Work%20Queues%20Guide%20%286.2.1%29%28EN%29_1.pdf

７．Design Exampleに、大きく３つの分類で例が記載されていて、この分類とタグ利用などの組み合わせで、キュー設計をしています。
キューが多いとキューメンテ用プロセスのおもりが面倒になるので、私はできるだけキューは統合するようにしています。
ただ、業務や組織で分けざるを得ない側面もあるので、それなりにキューは増えますが…

------------------------------
Yasuyuki Koike
Specialist
Toshiba IT-Services.corp
Asia/Tokyo
------------------------------

[NarihitoShinon1]

鈴木様

わかりにくい資料から読み取って頂き、
また、ご回答くださりありがとうございます。

前提としてはどちらかというとプロセスA~FとA1~F1についてはそれぞれ
違うプロセスになります。

プロセスA~Fは後続のプロセス●または▲で実施する作業のインプットとなる
情報を収集するプロセスです。ただ、システムの仕様上​、収集するルートが異なるため
A~FやA1~F1を分割した次第でございます。

ただ、ご教授頂いた3つの観点でキューの設計をしていらっしゃるということは
大変参考になりました。

おっしゃられている通り、業務内容を詳しくお話しできないと
難しい話だとは思いましたが、私たち自身WQの扱いになれておらず
すがる思いで起票し、ご回答いただけたことに感銘しております。
ありがとうございます。

もう少し、キューについて勉強して設計してみようと思います。

------------------------------
Narihito Shinonaga
------------------------------

[NarihitoShinon1]

小池様

ご回答くださりありがとうございます。

また、資料の解説もありがとうございます。

私どももキューの数が増えるとメンテナンスの負荷が上がってしまうのではないか
と思い、統合した次第です。

業務の観点でももう少し、考えてみようと思います。​

------------------------------
Narihito Shinonaga
------------------------------