メッセージが失われていないかの確認

ご使用のブローカー・ドメインを通してフローするメッセージを保護することは重要です。 これは、アプリケーション生成メッセージおよびコンポーネント間通信で内部的に使用されるメッセージの両方に当てはまります。 コンポーネント間で内部的に使用されるメッセージでは、必ず WebSphere MQ プロトコルが使用されます。アプリケーション・メッセージでは、サポートされるすべてのトランスポート・プロトコルを使用できます。

アプリケーション・メッセージおよび内部メッセージが WebSphere MQ を通過する際に、以下の二つの技法でメッセージの損失を防ぎます。

これらのオプションを使用する方法については、WebSphere MQシステム管理ガイド を参照してください。

内部メッセージ

WebSphere Message Broker コンポーネントは、WebSphere MQ メッセージを使用して、 ブローカー・プロセスとサブシステム、および構成マネージャーユーザー・ネーム・サーバーの間でイベントやデータの通信を行います。コンポーネントは WebSphere MQ 機能を活用して、 メッセージが失われることがないようにします。内部メッセージの損失を防ぐために、 何か付加的なステップを実行して WebSphere MQWebSphere Message Broker を構成する必要はありません。

アプリケーション・メッセージ

アプリケーション・メッセージの送達が非常に重要である場合は、 使用されるアプリケーション・プログラムとメッセージ・フローを、 決してメッセージが失われないように設計する必要があります。 使用される技法は、アプリケーションによって使用されるプロトコルによって異なります。

WebSphere MQ Enterprise Transport および WebSphere MQ Mobile Transport
組み込み入力ノード (WebSphere MQ または WebSphere MQ Everyplace プロトコルを通過してメッセージを受信する) を使用する場合、 以下のガイドラインおよび勧告を活用できます。
  • 持続メッセージの使用

    WebSphere MQ メッセージング製品は、メッセージ持続性を提供します。 システム内のメッセージの長時間持続を定義し、メッセージの保全性を保証します。非持続メッセージは、システムまたはキュー・マネージャーの障害イベントの際に失われます。 持続メッセージは、障害が発生した場合に、必ず回復します。

    次の方法で、メッセージ持続性を制御することができます。
    • ご使用のアプリケーションを、MQI または AMI を使用してメッセージをキューに入れて、 メッセージが持続であることを示すようにプログラムします。
    • メッセージ持続をデフォルト設定にして、入力キューを定義します。
    • 持続メッセージを処理する出力ノードを構成します。
    • ご使用のサブスクライバー・アプリケーションが、メッセージ持続を要求するようにプログラムします。

    入力ノードが入力キューからメッセージを読み取る場合、 デフォルトのアクションは、WebSphere MQ メッセージ・ヘッダー (MQMD) で定義された持続性を使用します。 この持続性は、メッセージを作成するアプリケーションか、 または入力キューのデフォルトの持続性のいずれかによって設定されます。メッセージはこの持続性を、後続のメッセージ処理ノードで変更されるのでない限り、メッセージ・フロー全体で保存します。

    出力ノードでメッセージ・フローが終了する際に、 それぞれのメッセージの持続性値を指定変更することができます。 このノードには、それが出力キューに置かれる際に、必須値またはデフォルト値のいずれかとして、 それぞれのメッセージのメッセージ持続性を指定することのできるプロパティーがあります。 デフォルトを指定した場合は、メッセージの書き込み先であるキューに定義された持続性値を、 メッセージは採用します。

    メッセージが Publication ノードを通過する場合、サブスクライバーに送られたメッセージの持続性は、 サブスクライバーの登録オプションによって決定されます。 サブスクライバーが持続メッセージの配信を要求しており、 明示または暗黙 (継承された) ACL によってそれを行う許可がサブスクライバーに付与されている場合には、 既存の持続性プロパティーに関係なく、メッセージは持続的に配信されます。 また、要求された非持続メッセージの配信がユーザーにある場合には、 既存の持続性プロパティーに関係なく、メッセージは非持続的に配信されます。

    メッセージ・フローによって新しいメッセージが作成される場合は (例えば、Compute ノードにおいて)、 着信メッセージの MQMD の持続性が、新しいメッセージの MQMD の持続性としてコピーされます。

  • 同期点制御下でのメッセージ処理

    メッセージ・フローのデフォルトのアクションは、 ブローカーによって制御されるトランザクションの同期点の下で着信メッセージを処理します。 このため、何らかの理由で処理に失敗したメッセージは、 ブローカーによってバックアウトされることになります。 このメッセージは同期点の下で受信されたため、 失敗したメッセージは入力キュー上に復元され、もう一度処理できるようになります。 処理が失敗した場合には、このメッセージ・フローに適切なエラー処理プロシージャー (メッセージ・フローを構成した仕方、またはブローカーのいずれかによって定義される) が実行されます。

    入力ノード処理の詳細については、入力ノードにあるエラーの管理を参照してください。

WebSphere MQ Telemetry Transport
MQIsdp プロトコルを通過して telemetry 装置からメッセージを受信する、 組み込み入力ノード SCADAInput を使用する場合、このプロトコルには、キューの概念がありません。 ノードが listen するポート番号を指定することで、クライアントは SCADAInput ノードに接続されます。 メッセージは、clientId を使用してクライアントに送信されます。ただし、SCADA のサブスクリプション・メッセージ内に、 可能な限り高い QoS (Quality of Service: サービス品質) を指定できます。 これは持続性とよく似ており、次のように定義されています。
  • QoS0 非持続。
  • QoS1: 持続性はあるが、1 回より多く送達される可能性がある
  • QoS2: 必ず 1 回限り送達される

持続性のある SCADA メッセージがパブリッシュされる場合は、 クライアントが受け入れることのできる、最も高いレベルに格下げされます。 これは、状況によっては、メッセージが非持続になる場合もあることを意味します。

WebSphere MQ Real-time TransportWebSphere MQ Multicast TransportWebSphere MQ Web Services Transport
JMS および multicast アプリケーションからのメッセージを受信する、 組み込み入力ノード Real-timeInput および Real-timeOptimizedFlow を使用している場合、 または Web サービス・アプリケーションからのメッセージを受信する HTTP Input および HTTPRequest ノードを使用している場合には、 メッセージ損失からの保護を提供する機能は使用できません。 ただし、メッセージ・フローが独自のエラーを処理するように構成することによって、 リカバリー手順を提供することができます。
その他のトランスポートおよびプロトコル
別のトランスポート・プロトコルからメッセージを受信する、 独自のユーザー定義入力ノードを作成した場合、 そのトランスポート・プロトコルによって提供されているサポートを活用するか、 または独自のリカバリー手順を用意しなければなりません。
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ac00420_