【IDM】MSMQ を使って確実なユーザー登録を行うその8 ～ MSMQトリガーのクセを理解する

さてもう一息ですね。第8回です。

＃これまでの投稿一覧はこの投稿の最下段に書いておきます。

前回作成したスクリプトをキューのルールとして登録する前に、MSMQ運用に必要な知識について書いておきます。知識というよりも、クセですね。

具体的には、何らかの原因によってスタックしてしまったメッセージを処理する方法です。これを知らないと、MSMQトリガーの運用は、結構困ります。

-----

MSMQトリガーに何らかの問題が発生したためルールが実行されなかったとします。

この場合、メッセージはスクリプトによって処理されず、いつまでも以下のような状態でキューに残ってしまう可能性があります。

例えば、スクリプトに不備があり、メッセージの送信が正常に行われなかった、などといったことが考えられます。

赤でくくった部分に注目してください。testuser001 ～ testuser020 までのユーザーが Inputキューに登録されていることがわかります。

この状態で、MSMQが正常に戻った、もしくはスクリプトの不備修正が完了したとします。つまり、トリガーが正常に動作する状態になったと仮定します。

ここに新たなメッセージが5件（testuser021 - 025）入ってきました。さて、どうなるでしょう？？？

Receive の処理を理解していればわかりますよね。以下のように、古いものから処理され、後から入ってきたキューは後回しにされます。

このことから、「新しいメッセージが入ってこない限りトリガーが起動しない」ということが容易に想像できます。

＃古いメッセージから処理するかどうかは、環境設定およびスクリプトの作り方次第です。
＃今回はReceiveを使用したので古いものから順番に処理されています。

これでは困るのでなんとかしたい。そんなときは、サービス一覧にある Message Queue Triggers サービスを再起動すれば、最も古いメッセージから順番にルールが実行されます。

ここで覚えておいていただきたいのは、Message Queue Triggers サービスは Message Queue サービスとは分離されているので、停止してもメッセージが一時的に受け取れなくなるといった弊害は発生しません。

これを知っていると、例えば、「実際の登録は明日の午前0時に開始したい」なんてことが実現できます。つまり、事前に Message Queue Triggers サービス停止した状態でメッセージを登録しておき、午前0時に起動してあげればよいわけです。

もう一つ、スタックしたメッセージを処理する方法として、スクリプトを手動で実行するという手も考えられます。

まとめると、以下の通りです。

スタックしたメッセージを処理するには、

新しいメッセージを登録してトリガーを起動する

Message Queue Triggers サービスを再起動する

メッセージを処理するスクリプトを手動で実行する

のいずれかを実行する必要があります。

是非とも覚えておいてください。

----

これまでの投稿は以下の通りです。

【IDM】MSMQ を使って確実なユーザー登録を行う その8 ～ MSMQトリガーのクセを理解する