Messaging API サンプル(非推奨）

Messaging API サンプルは、WebLogic Integration Messaging API の使用方法を示します。特に、Messaging API で使用できる 2 つのメッセージ配信メカニズムと、WebLogic Integration B2B のロジック プラグイン機能を例示しています。

この章では、以下のトピックを取り上げます。

• Messaging API サンプルの概要

• Messaging API サンプルを実行する前に

• Messaging API サンプルの実行

注意: Messaging API サンプルは WebLogic Integration Messaging API に基づいていますが、この API は、このリリースの WebLogic Integration から非推奨になっています。WebLogic Integration Messaging API に代わる機能については、『WebLogic Integration リリース ノート』を参照してください。

 

---

Messaging API サンプルの概要

WebLogic Integration では、ビジネス メッセージを送信する 2 通りの方法をサポートしています。

1. WebLogic Integration Studio で作成されるアプリケーション ワークフローを使用する方法。アプリケーション ワークフローには、ビジネス メッセージを送信するアクションが含まれます。RosettaNet 2.0 Security サンプルおよび Channel Master サンプルは、ビジネス メッセージを送信するワークフロー アプリケーション例です。

2. ビジネス メッセージを送信するために WebLogic Integration Messaging API を呼び出す Java アプリケーションを使用する方法。

このサンプルは、2 つ目の方法を使用します。

WebLogic Integration Messaging API では、2 つのメッセージ配信メカニズムをサポートしています。

• 同期−送信側アプリケーションは、公開されたメッセージが宛先に配信されるまで待機します。メッセージング システムは、メッセージ公開処理の結果が判明した後、アプリケーションに制御を返します。アプリケーションは、タイムアウトが発生するか、処理ステータスが判明するかのどちらかが起こるまで待機します。

• 遅延同期−メッセージ公開後に、制御がアプリケーションに返されます。アプリケーションには XOCPMessageToken オブジェクトが返されます。アプリケーションは後でそのオブジェクトにアクセスしてメッセージ配信のステータスをチェックできます。

このサンプルでは、同期および遅延同期の双方のメッセージ配信メカニズムの使い方を例示しています。

Messaging API サンプルには、ビジネス メッセージを送信する 3 社のトレーディング パートナ（Partner1、Partner2、および Partner3）が含まれます。Messaging API サンプルには、4 つの Java ソース コード ファイル（MdmTp1Servlet.java、MdmTp2Servlet.java、MdmTp2Servlet.java、および WaiterPlugin.java）が含まれます。

ファイル	含まれるソース コード
MdmTp1Servlet.java	Partner1 トレーディング パートナ
MdmTp2Servlet.java	Partner2 トレーディング パートナ
MdmTp3Servlet.java	Partner3 トレーディング パートナ
WaiterPlugIn.java	ハブ フィルタ ロジック プラグイン

 

WaiterPlugIn.java コードの詳細については、実行フローのトレースを参照してください。

Messaging API サンプルを実行する前に

Messaging API サンプルを実行する前に、次の手順を実行します。

1. サンプルの実行前の作業に記載の手順に従います。

2. サンプル WebLogic Server への接続が妨げられないようにブラウザのプロキシ設定を確認します。Web ブラウザ コンフィグレーションの要件の詳細については、『WebLogic Integration の起動、停止およびカスタマイズ』の「WebLogic Integration 管理ツールと設計ツール」の「Web ブラウザ コンフィグレーションの要件」を参照してください。

 

---

Messaging API サンプルの実行

Messaging API サンプルを実行するには、次の手順を実行します。

1. WLI_HOME（WebLogic Integrationをインストールしたディレクトリ）に移動します。

   cd WLI_HOME

   • Windows の例

     WebLogic Platform を c:¥bea ディレクトリにインストールした場合は、WLI_HOME のパスは、c:¥bea¥weblogic700¥integration となります。

   • UNIX の例

     WebLogic Platform を /home/me/bea ディレクトリにインストールした場合は、WLI_HOME のパスは、/home/me/bea/weblogic700/integration となります。

2. WebLogic Integration の上位レベルの環境変数を設定するには、お使いのプラットフォームに合った setenv スクリプトを実行します。

   • Windows の場合

     setEnv

   • UNIX の場合

     . setenv.sh

3. プラットフォームに合わせて適切な手順を実行し、RunSamples スクリプトを起動します。

   • Windows:

     [スタート｜プログラム｜BEA WebLogic Platform 7.0｜WebLogic Integration 7.0｜Integration Examples｜Start Server and Launch Examples (with dataloader)] を選択します。

   • UNIX:

     a) PATH 環境変数に、Netscape 実行ファイル（netscape）が格納されたディレクトリが含まれていることを確認します。

     b) RunSamples スクリプトを実行します。

     cd $SAMPLES_HOME/integration/samples/bin
     RunSamples

   警告: UNIX システムの場合、netscape 実行ファイルが入ったディレクトリが PATH 環境変数に含まれている必要があります。環境変数に含まれていない場合は、RunSamples スクリプトの実行時にサンプル起動ページが表示されません。サンプル起動ページは、現在 RunSamples スクリプトが実行されているマシンで Netscape ブラウザを起動して、次の URL を入力すると起動されます。
   http://localhost:7001/index.html

4. RunSamples スクリプトのコンフィグレーション セクションが実行済みであることが検知されると、次のプロンプトが表示されます。

   The WebLogic Integration repository has already been
   created and populated, possibly from a previous run
   of this RunSamples script. Do you want to destroy all the
   current data in the repository and create and populate the
   WebLogic Integration repository, again? Y for Yes, N for No

   この質問に N と入力すると、リポジトリの作成および格納を行う手順が省略され、WebLogic Server のサンプル インスタンスを起動する手順のみが実行されます。

   この質問に Y と入力すると、リポジトリの作成および格納が改めて行われ、その後で WebLogic Server のサンプル インスタンスを起動する手順が実行されます。Y と入力した場合、その時点でリポジトリに格納されている全データが破棄され、リポジトリにサンプル データが再ロードされます。現在のサンプル データが変更または削除され、新規または未変更のサンプル データをリポジトリに格納する場合にのみ、Y を入力してください。

   これで、RunSamples スクリプトは WebLogic Server のインスタンスをバックグラウンド プロセスとして開始し、サンプル起動ページが表示されます。

   
    

5. サンプル起動ページの左ペインで、[サンプル アプリケーション] の下の [Messaging API] のリンクをクリックします。Messaging API サンプルのオプション メニューは、右ペインに表示されています。

   
    

必要に応じて、3 つのオプションをすべて表示できるようにブラウザの画面をサイズ変更してください。

6. 1 つ目のオプション（[Partner3 スポークを参加させる]）をクリックします。このオプションについてのメッセージが表示されるまで待機し、次のステップに進んでください。

7. 2 つ目のオプション（[Partner2 スポークを参加させる]）をクリックします。このオプションについてのメッセージが表示されるまで待機し、次のステップに進んでください。

8. 3 つ目のオプション（[Partner1 スポークを参加させてリクエストを送信]）をクリックします。

   Messaging API サンプルが正常に実行されると、右ペインの下部に次の出力結果が表示されます。

Partner1 process flow: 
Starting XOCPAppplication... done. 
Creating conversation : verifierConversation:1.0:
requestor_Partner1_1001029696695_341001029696695...done.
send string for Message 1 = FIRST MESSAGE
Sending message 1 using synchronous deferred delivery method to Partner 2
Sending a second message before checking for acknowledgment on the first
send string for Message 2 = SECOND MESSAGE
Sending message 2 using synchronous delivery method to Partner 3
success status for message 2
Waiting for Message 2 response... done.
Processing reply for Message 2:
Received string for Message 2 = partner3 -- second message
Verification for Message 2 SUCCESS

Doing something else... done
Waiting acknowledgment for Message 1... Acknowledgment received
Success status for message 1
Waiting for Message 1 response... done
Processing reply:
Received string for Message 1 = partner2 -- first message
Verification for Message 1 SUCCESS

Terminating conversation:verifierConversation:1.0:
requestor_Partner1_1001029696695_341001029696695
success
Shutting down session... done.

9. このとき、さらに多くの B2B サンプルを実行する場合は、サンプル起動ページを開いた状態で、WebLogic Server のサンプル インスタンスの実行を続行します。

   この時点で、これ以上 B2B サンプルを実行しない場合は、各プラットフォームに合わせて適切な手順を実行し、WebLogic Server の現在のインスタンスをシャットダウンします。

   • Windows:

     cd %SAMPLES_HOME%¥config¥integration¥samples
     stopWebLogic

   • UNIX:

     cd $SAMPLES_HOME/config/integration/samples
     stopWebLogic

実行フローのトレース

以下は、Messaging API サンプルの実行フローをトレースする手順です。

1. RunSamples スクリプトが起動され、次の結果が得られます。

   1. WebLogic Server のサンプル インスタンスが開始されます。

   2. ブラウザが開き、サンプル起動ページが表示されます。

   3. サンプル起動ページで [Messaging API] リンクをクリックすると、[Messaging API] サンプル ページが表示されます。このページには、[Partner3 スポークを参加させる]、[Partner2 スポークを参加させる]、および [Partner1 スポークを参加させてリクエストを送信] の 3 つのオプションが表示されます。

2. [Partner3 スポークを参加させる] オプションを選択すると、次の結果が得られます。

   1. HTTP 要求が MdmTp3 サーブレットにポストされます。

   2. MdmTp3 は、MdmTp3Servlet.java から doPost メソッドを呼び出します。

   3. doPost メソッドは、トレーディング パートナ Partner3 の XOCPApplication を起動します。

3. [Partner2 スポークを参加させる] オプションが選択されると、次の結果が得られます。

   1. HTTP 要求が MdmTp2 サーブレットにポストされます。

   2. MdmTp2 は、MdmTp2Servlet.java から doPost メソッドを呼び出します。

   3. doPost メソッドは、トレーディング パートナ Partner2 の XOCPApplication を起動します。

4. [Partner1 スポークを参加させてリクエストを送信] オプションを選択すると、次の結果が得られます。

   1. HTTP 要求が MdmTp1 サーブレットにポストされます。

   2. MdmTp1 は、MdmTp1Servlet.java から doPost メソッドを呼び出します。

   3. doPost メソッドは、トレーディング パートナ Partner1 の XOCPApplication を起動します。

   4. doPost は 1 つ目のメッセージを送信し、3 つのトレーディング パートナ（Partner1、Partner2、および Partner3）間の一連のメッセージをトリガします。このサンプルの 3 つのトレーディング パートナはすべて、VerifierHubChannel 配信チャネルの使用と verifierConversation 会話への参加のために、WebLogic Integration リポジトリに登録します。Partner1 は、要求側のロールでリポジトリに登録されます。Partner2 および Partner3 は応答側のロールで登録されます。

   次の図は、これらのビジネス メッセージの送受信が最も行われやすいタスク順序を示します。正確なタスク順序はタイミングに関係しており、Java 仮想マシンのスレッドのスケジューリングに応じて異なります。

   図5-1 トレーディング パートナ間のメッセージの流れを示す会話図

   
    

   次のタスク順序では、図5-1 内の対応する文字で示される各手順の詳細について説明します。

   1. Partner1 は Partner2 へテキスト FIRST MESSAGE を伴うメッセージを送信します。このメッセージは、遅延同期送信されます。したがって、Partner1 は Partner2 からの返信を待機もブロックもせず、引き続きタスクの実行を行います。

      メッセージの、ブロックを行わないという局面は、Partner1 のオブジェクト ライフラインによって、会話図（図5-1）に示されています。Partner1 が初めてアクティブになったとき、Partner1 のライフラインは、破線（非アクティブ状態を示す）表示から細い長方形（アクティブ状態を示す）の表示に変化します。ライフラインは、Partner1 が最初のメッセージを送信した後も、引き続きアクティブです。アクティブであるため、Partner1 は、次の手順で示すように、別のメッセージの送信など、他のタスクを実行できます。

      このサンプルで送信されるメッセージはすべて、ハブ経由でルーティングされます。WaiterPlugIn というロジック プラグインがハブのフィルタ チェーンに追加されています。ハブを経由してメッセージがルーティングされると、WaiterPlugIn クラスの process メソッドが実行されます。process メソッドは、送信されるメッセージの対象となる受信側をチェックします。対象となる受信側が Partner2 の場合、process は 15 秒間スリープします。それ以外の場合は、直ちにメッセージを送信します。図5-1 に示す例では、Partner1 から Partner2 へ送信された 1 つ目のメッセージは、15 秒間遅延されます。

   2. 1 つ目のメッセージがまだ処理されている間に、Partner1 はテキスト SECOND MESSAGE と共に 2 つ目のメッセージを Partner3 へ送信します。このメッセージは、同期送信されます。したがって、Partner1 は Partner3 が返るまでブロックまたは待機してからでなければ、他のタスクを処理できません。

   3. 図5-1 で、この Partner1 のブロックがどのように表現されているかに注意してください。2 つ目のメッセージが同期しているため、Partner1 のライフラインは、Partner1 が 2 つ目のメッセージを送信後に、細い長方形（アクティブ状態を示す）の表示から破線（非アクティブ状態を示す）表示に変化します。非アクティブ状態への変化は、メッセージが送信され、Partner3 によって確認応答があるまでPartner1 は、再びアクティブになって他のタスクを実行できるようにならないということです。

      このサンプルの 2 つ目のメッセージと、すべての応答メッセージは、ハブを経由してルーティングされます。このハブで、WaiterPlugIn の process メソッドがメッセージに対して実行されます。宛先が Partner2 ではないため、これらのメッセージは各々、遅延することなくハブを通過します。これらのメッセージの、ハブ フィルタ ロジック プラグインを介してのルーティングは、図5-1 には示されていません。

   4. 1 つ目のメッセージはハブで 15 秒間遅延されたあと、Partner2 にルーティングされます。

   5. Partner3 への同期送信が完了すると、Partner1 に制御が返されます。この時点で Partner1 は再びアクティブになります。これは図5-1 において、ライフラインの表示が破線（非アクティブ状態を表す）から細い長方形（アクティブ状態を表す）に変化することによって示されます。

   6. Partner1 は、1 つ目のメッセージが Partner2 によって受信されたことを検証します。

   7. Partner3 は、2 つ目のメッセージのテキストを取得し、それを小文字に変換して、プレフィクス partner 3-- を付加します。その後、修正したメッセージを Partner1 に返します。

   8. Partner2 は、1 つ目のメッセージのテキストを取得し、それを小文字に変換して、プレフィクス partner 2-- を付加します。その後、修正したメッセージを Partner1 に返します。

5. 結果は、Partner1 によって HTML のページに表示されます。この手順は、図5-1 には示されていません。