DataPowerチュートリアル

wedmeedが共同執筆した資料

私たちのプロジェクトがベトナムで始まった2017年、私たちは新しいIBM DataPowerに出会いました。 IBM DataPowerは、クライアントとバックエンド間のゲートウェイ製品であり、通過するメッセージ（以下、要求と呼びます）のフィルタリング、ルーティング、強化、またはその他の変換のために設計されています。 すぐに学ぶ必要があり、ビルドする時間がありませんでしたので、私たちはそれに慣れることに招待されました。その後、モスクワの同僚との長い時間のSkype会議があり、彼はこの製品の知識と経験を私たちに伝えました。

自習は、ドキュメントの学習とインターネットからのトレーニングビデオの視聴に基づいていました。ここでは、キャッチを待っていました。 ロシア語で情報を見つけることができませんでした。 ちなみに、当時の私の英語の知識は最高レベルではなく、それが私の最初のプロジェクトであり、おそらくこれらの要因が私の人生を複雑にしました。 これにより、この製品に出会い、その基本をすばやく理解しようとしている初心者開発者向けに、ロシア語で可能な限り簡単な方法でトレーニング記事を作成しました。 この記事では、ドキュメントを読むことから解放されるわけではありませんが、「それがどのように機能するか」を理解する初期段階での生活が楽になります。

また、実際に与えられた構造は実際のプロジェクトに近いため、それをベースとして使用し、要件を拡張および補完することができます。 結論として、「理論」のセクションでは、既に実装されているプロジェクトについていくつかの言葉と、注意を払う価値のあるいくつかの機能について説明します。

パート1. Docker Toolboxを使用したDataPowerのインストール

Docker Toolboxアプリをインストールして実行します。 起動直後に、DataPowerが将来利用できるようになるマシンのIPアドレスが表示されます。

イメージを開始するには、仮想マシンのいくつかの設定（バージョンIDG.2018.4.1.0に関連）を変更して再起動する必要があります。

1. 次のコマンドでドッカーマシンを停止します。
   
   
   
   

   docker-machine stop
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

2. システム->マザーボード->メインメモリ：最小4096Mb。
   
   
3. システム->プロセッサー：少なくとも2。
   
   
4. ディスプレイ->画面->ビデオメモリ：少なくとも128Mb。
   
   
5. 次のコマンドを使用して、Dockerマシンを起動します。
   
   
   
   

    docker-machine start
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   ご注意 docker-machine envを再起動するように求められたら、次を実行します。
   
   
   
   

    docker-machine env
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

6. 次に、IBM DataPowerイメージを圧縮する必要があります。
   
   
   
   

    docker pull ibmcom/datapower
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

7. 次に、次のコマンドでdockerコンテナーを起動します。
   
   
   
   

    docker run -it \ -v $PWD/config:/drouter/config \ -v $PWD/local:/drouter/local \ -e DATAPOWER_ACCEPT_LICENSE=true \ -e DATAPOWER_INTERACTIVE=true \ -p 9090:9090 \ -p 3630:3630 \ -p 9022:22 \ -p 7170:7170 \ --name idg \ ibmcom/datapower
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

8. コマンドを完了したら、Enterを押して、ユーザー名とパスワードとしてadmin / adminを入力します
   
   
9. Web管理インターフェイスを開始するには、次のコマンドを使用します。
   
   
   
   

    co
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   そして
   
   
   
   

    web-mgmt 0 9090
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

10. これらすべてのステップの後、ブラウザでhttps://192.168.99.100:9090/を実行します
    
    

パート2.ドメイン

2.1。 理論

DataPowerのドメインにより、管理ツールと開発ツールを分離し、セキュリティを提供できます。

インストール後、アプリケーションドメインを作成できるデフォルトドメインのみが存在します。 各ドメインには、独自のパラメーター構成があります。

一部の一般的なリソースとパラメーターは、デフォルトドメインでのみ定義できます。これらには、ネットワークインターフェイス、ユーザーとアクセス制御、アプリケーションドメインなどが含まれます。

アプリケーションドメインは、リクエスト処理サービスの開発セクションです。 ここで定義されたサービスは、別のアプリケーションドメインと共有できません。 DataPowerを完全に再起動することなく、アプリケーションドメインを個別に個別に再起動できます。

ドメインを作成、再起動、リセット、一時停止、更新、または削除できます。 すべての管理機能に関する詳細情報は、公式ドキュメントに記載されています。

完成したプロジェクトについて少し。 3つのドメインを使用しました。

• default-共有リソースとパラメーターを含むデフォルトドメイン。
• トランク-要求の処理に必要なすべてを含むメインドメイン。
• 設定-設定とセキュリティドメイン、ローカルファイルには、サービスルーティングルールとセキュリティ設定に関する情報が含まれています。

より単純な展開パスの検索に関連して、すべての設定を別のドメインに転送する必要が生じました。 多くのプロジェクトと同様に、dev、test、prod環境は分離されており、設定を別の構成ドメインに削除することで、環境設定を失うリスクなしに、エクスポート/インポートを通じて他の環境のdev環境からすべてのメインドメインをインストールできるようになりました

2.2。 練習する

• 検索フィールドに「ドメイン」と入力し、「アプリケーションドメイン」を選択して「追加」をクリックします
  
  
• ここで、ドメイン名、コメント（必要な場合）を指定し、監査とログを有効にする必要があります。 フィールドに入力して、変更を適用します
  
  
• 同様に、別のドメイン「トランク」を追加します
• 変更の確認に移動
  
  
• ドメイン構成を保存します
  
  
• 作成されたオブジェクトのステータスを確認するには、ステータス->メイン->オブジェクトステータスのナビゲーションツリーでデフォルトドメインに移動します。
  
  
• 表示方法の選択：タイプ
  
  
• リストでアプリケーションドメインを見つけて、オブジェクトのステータスを確認します。各オブジェクトを保存し、オンにして、アップ状態にする必要があります。 その場合、次の章に進みます。

パート3.キューマネージャー

キュー・マネージャーはIBM DataPowerの必須コンポーネントではありませんが、MQの例により、この製品の全能力を示すことができます。 IBMのMQを使用します。 第6章で説明したテスト中に、ローカルキューマネージャーにメッセージを送信する必要があります。 この記事では、rfhutilユーティリティを使用してこれを行いますが、利用可能な任意の方法を使用できます。 テストのために、MQキューマネージャーを使用して、DPからローカルキューマネージャーへの接続を作成する必要があります。

3.1。 理論

キューマネージャは、ゲートウェイとリモートキューマネージャ間のデータ交換を提供します。

MQキューマネージャグループを構成することもできます。これにより、システムのフォールトトレランスが向上します。 これは、たとえば、クライアントを作業キューマネージャーのセットのいずれかに接続する場合や、場合によっては公式ドキュメントに記載されている場合に便利です。

プロジェクトの経験から、注目すべき機能は1つだけです。一度は、特にキューマネージャーのグループを使用して、DataPowerを使用して負荷分散を実装しようとしましたが、実際にはそのような機会は見つかりませんでした。 別の解決策は、キューマネージャーのクラスターを作成することです。

3.2。 練習する

3.2.1。 準備する

1. WebSphere MQをインストールします。
2. ポート3630でアクセス可能なローカルLOCAL_DP_QMキューマネージャーを作成します。
3. DP.SVRCONNチャネルを構成します。
   
   
   
   

   チャネルを作成するとき、次のコマンドが役立つ場合があります。

   
   
   
   
   
   
   

    strmqm LOCAL_DP_QM /*  mq*/ runmqsc LOCAL_DP_QM /*   mq*/ DEFINE CHANNEL (DP.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('evlasenko') /* */ SET CHLAUTH('DP.SVRCONN') TYPE(USERMAP) CLNTUSER('evlasenko') USERSRC(channel) ADDRESS('*') ACTION(ADD) /*      */ SET CHLAUTH(DP.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody') /*   */ ALTER LISTENER (SYSTEM.DEFAULT.LISTENER.TCP) TRPTYPE(TCP) PORT(3630) control(QMGR) /*    3630*/ ALTER AUTHINFO (SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) /* */ REFRESH SECURITY TYPE(CONNAUTH) /*  */ endmqm LOCAL_DP_QM /*  mq*/ strmqm LOCAL_DP_QM /*  mq*/ END
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
4. キューDP.IIB.REQINおよびDP.IIB.RESINを作成します
5. チャネルが作成されたユーザーの名前でrfhutilを実行します。 （接続する）キューマネージャー名の行に、次のように記述します。
   
   
   
   

    DP.SVRCONN/TCT/127.0.0.1(3630)
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
6. キュー名のリストをロードしてみてください;メッセージウィンドウにエラーが表示されないはずです。 チャネルへの接続が確認されました。
   
   

3.2.2。 IBM MQキューマネージャーの作成

1. トランクドメインに移動します。
2. 検索ボックスに「MQ」と入力し、「IBM MQキューマネージャー」を選択して、「追加」をクリックします。
3. 名前（TEST_QM）、キューマネージャーのホスト名、キューマネージャーの名前とチャネル名、およびタイムアウトを指定する必要があります。 変更を構成して保存します。
   
   
   
   

ドメインのステータスをチェックするのと同じ方法で、キューマネージャオブジェクトのステータスをチェックします。 これを行うには、トランクドメインから[オブジェクトの状態]と[表示方法：]フィルターを選択します。 「IBM MQキューマネージャー」セクションで、適切なオブジェクトを見つけて、そのステータスを確認します。

パート4.マルチプロトコルゲートウェイ

4.1。 理論

マルチプロトコルゲートウェイ（MPG）は、さまざまなプロトコルを使用してクライアントから要求を受信し、さまざまなプロトコルを使用して異なるサーバーに転送できるようにするマルチプロトコルゲートウェイです。 クライアントが使用するプロトコルは、リモートアクセスサーバーが使用するプロトコルと一致しない場合があります。

メインのMPG設定では、次のコンポーネントを定義できます。

• XMLマネージャー-スタイルシート（xsl、xslt）のコンパイルとキャッシュ、ドキュメントのキャッシュを制御します。
• ポリシー-ルールで構成されます。各ルールは、ゲートウェイを通過するメッセージに適用される一連のアクションを定義します。
• 前面と背面の設定（URLの設定、受信メッセージと送信メッセージのタイプ、タイムアウトなど）。

プロジェクトに関するいくつかの言葉：

このプロジェクトでは、4つのマルチプロトコルゲートウェイ（ルーティング、異なるエンドシステム用の2つの変換、および設定ドメインからファイルを受信するための追加のゲートウェイ）を使用します。 以下の図は、一般的な相互作用スキームを示しています。

MPGの量は、ソリューション全体のアーキテクチャによって異なる場合があります。 今回のケースでは、DataPowerは統合バス（IIB）とマイクロサービスに直面しますが、これらはインターフェース（json / httpとxml / mq）に大きな違いがあるため、特定のバックエンドごとに変換MPGを作成し、それに応じて名前を付けることが決定されました。 すべてのクライアントでjson / httpを使用しているため、MPGのルーティングは1つです。 主なMPGは、要求、応答、エラーの3つのメッセージ処理ルールで構成されています。 各ルールは、変換、ロギング、ルーティングなどの必要なアクションで構成されます。

機能から-ポリシーでConvertQueryParamToXMLアクションを使用する場合は、InputConversionに注意してください。 デフォルトエンコーディングをJSONに設定してGETリクエストを送信しようとすると、指定した変換がメッセージに行われておらず、その痕跡も見つからないことに驚くでしょう。 この機能は、GET要求用の別のルールの作成を克服するのに役立ちます。

4.2。 練習する

4.2.1。 準備する

リンクhttps://github.com/EvgenyaVlasenko/IBM_DataPower.gitで作業に必要なすべてのファイルを見つけることができます。

4.2.1.1。 ドメイントランク

1. トランクドメインに移動します。
2. コントロールパネルで、[ファイル管理]を選択します。
3. ローカルディレクトリで、次のディレクトリ構造を作成し、それに対応するファイルを配置します（各ファイルには、実行する機能の簡単な説明と、この記事の後半で詳しく説明します）。
   
   
   
   

4.2.1.2。 ドメイン設定

1. 設定ドメインに移動します。
2. コントロールパネルで、[ファイル管理]を選択します。
3. ローカルディレクトリで、次のディレクトリ構造を作成し、適切なファイルをその中に配置します（ファイルには簡単な説明も含まれています）。
   
   
   
   

4.2.2。 GetFileMPGを作成する

最初に、設定ドメインからファイルを返す単純なヘルパーMPGを作成します。

1. 設定ドメインに移動します。
2. コントロールパネルで、[マルチプロトコルゲートウェイ]を選択し、[作成]をクリックします。
3. 名前（GetFileMPG）、説明（オプション）、およびバックエンドタイプ（動的）を指定します。 実際、バックエンドへの呼び出しはなく、ファイルのみがローカルシステムから返されるため、この例では、任意のタイプのバックエンドを指定できます。
   
   
   
   
4. 要求と応答のタイプを指定します。 型を明示的に指定すると、インラインチェックの回数が減ります。 パススルータイプを指定すると、ルールを作成しないようにできます（この場合、応答を変換します）。 要求タイプもパススルーを指定すると、メッセージを処理することはできなくなります。 このオプションは適切ではないため、非XMLを使用してリクエストのタイプを制限します。
   
   
   
   
   
   
5. [+]をクリックしてHTTPハンドラーを選択し、新しいフロントサイドプロトコルを作成します。
   
   
   
   
   
   
6. ここで、名前、IPアドレス、ポート、および許可されたメソッドのリストを指定する必要があります。 IPアドレスに注意してください。 0.0.0.0を指定すると、誰でもこのゲートウェイにアクセスできます。 127.0.0.1の場合-同じDataPower内の他のゲートウェイのみ。 設定にはセキュリティパラメータがあるため、2番目のオプションを使用します。 フィールドに入力して[適用]をクリックすると、プロトコルが自動的にゲートウェイに追加されます。
   
   
   
   
   
   
7. [+]をクリックして、新しいポリシーを追加します。
   
   
   
   
   
   
8. ポリシー名「GetFilePolicy」を入力します。
   
   
9. 新しいルールを作成し、ルールの名前と方向を入力します。 実際にはバックエンドがなく、目的のファイルのみが返されるため、1つのルール（クライアントからサーバー）のみが存在します。
   
   
   
   
   
   
10. 一致アクションをダブルクリックして構成し、既存のルールを選択して変更を適用します。 Getリクエストのみを受信する機能に制限を設定することはイデオロギー的に正しいでしょうが、トレーニングタスクのフレームワーク内で、既存のものを選択できます。
    
    
11. 別のアクション-GatewayScriptをルールにドラッグして設定し、追加します。 変換として、準備されたファイルが使用されます。ローカル：///ファイルシステムでは、着信要求のURIから名前でファイルを検索し、メッセージ本文に配置します。 操作の結果は、ルールの出力バッファーに直接転送されます。 変更を保存します。
    
    
    
    
    
    
12. 最終的なポリシーの結果は次のようになります。
    
    
    
    
    
    
13. MPGの作成が完了したら、変更を保存します。
    
    
14. ドメインとキューマネージャーのステータスをチェックするのと同様に、オブジェクトステータスを使用して、作成の成功を確認できます。 これを行うには、[オブジェクトの状態]を選択し、[設定]ドメインの[サービスのフィルター]フィルターを選択します。 「マルチプロトコルゲートウェイ」セクションで、対応するオブジェクトを検索し、そのステータスを確認します。
    
    
15. ipで保護しているため、外部からこのMPGを呼び出すことはできません。 ipを一時的に127.0.0.1から0.0.0.0に変更し、ポートを7171から7170に一時的に変更して、次のクエリを実行します。
    
    
    
    

     curl -vv -k "http://192.168.99.100:7170/trunk/route/routeRules.xml"
          
          
    
            
            
            
          
    
        
            
            
            
          
          
    
            
            
            
          
    
        
         

    
    
    
16. 次の答えが得られるはずです。
    
    
    
    
    
    
17. 再度、IPとポートを元の127.0.0.1:7171に変更します。
    
    

4.2.3。 RoutingMPGの作成

RoutingMPGを作成します。 入力要求とルーティングルールに基づいて、彼は要求をどこに、どのパラメーターで送信するかを決定します。

1. トランクドメインに移動します。
2. 次の値を使用して、セクション4.2.2のパラグラフ2〜10に従って新しいマルチプロトコルゲートウェイを作成します。
   
   
   • 3-名前：RoutingMPG、バックエンドタイプ：動的（必要に応じて異なるMPGに要求をルーティングする可能性のため）。
   • 4-Rq：非XML、Rs：非XML。
   • 6-名前：RoutingHTTP_FSH、ip：0.0.0.0、ポート：7170、Getメソッド。
   • 8-名前：RoutingPolicy。
   • 9-名前：RoutingPolicy_rule_req、方向：クライアントからサーバー。
   
   
   
3. リクエストをルーティングするアクションをもう1つ追加しますこれを行うには、「ルート」アクションをルールにドラッグし、ダブルクリックして設定し、フィールドに入力して変更を適用します。 route.xslファイルは、以前に作成したGetFileMPGを介して設定ドメインからルーティング設定ファイルを受け取ります。 その後、URIに基づいて、この操作に必要な設定が既にファイルから選択されています。 それらの一部はルーティングに使用され、一部は他のMPGで使用するためにヘッダーに追加されます。 入力パラメータと出力パラメータは、メッセージ本文のみを処理する方法を決定し、ヘッダーと変数には一切影響しません。 したがって：nullからの入力-メッセージ本文からの情報はルーティングに使用されないため。 出力はnullです-変換の結果はサービス情報の変更のみであるためです。
   
   
   
   
   
   
4. 同様に、さらに2つのルールを作成し、すべての変更を保存します。
   
   
   • 方向：サーバークライアント、名前：RoutingPolicy_rule_resp;
     
     変換：入力INPUT、出力NULL、変換ファイルローカル：///RoutingMPG/transform/resp.xslt。 resp.xsltファイルは、変換MPG応答のhttpステータスを受け取り、RoutingMPG応答に明示的に設定します。 これを行わないと、変換MPGでエラーが発生した場合でも、デフォルトコードは200に設定されます。
     
     
   • 方向：エラー、名前：RoutingPolicy_rule_error;
     
     変換：入力INPUT、出力PIPE（ドキュメントによると、INPUTとOUTPUTとして2つの隣接するアクションノード間でPIPEを使用すると、追加の処理が不要になり、使用メモリ量が削減されます）、変換ファイルはローカルです：///RoutingMPG/transform/errors.xsl errors.xslファイルは、変換MPGからの応答からエラーコードとテキストを受け取り、クライアントが期待する形式でJSONエラーメッセージを生成します。
     
     
   
   
   
5. 最終的なポリシーの結果は次のようになります。
   
   
   
   
   
   
6. MPGの作成が完了したら、変更を保存します。
   
   
7. たとえば、curlユーティリティを使用して、次のクエリを実行します。
   
   
   
   

    curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage"
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
8. 次のエラーが表示された場合、すべてが正しく行われています。 このエラーは、メッセージが正常に受信および処理されたが、バックエンド（この場合はIIBMPG）を呼び出そうとして失敗したことを意味します。 次のステップに進みます。
   
   
   
   
   
   

4.2.4。 IIBMPGの作成

次のステップは、変換MPGを作成することです。 外部システムがJSON要求形式で、内部システムがXMLであるとします。 内部システムが理解できるように、入力メッセージを変換する必要があります。 これは、必ずしもメッセージ全体の単純な変換ではないことに注意してください。 多くの場合、完全に再設計された構造で、切り捨てられたメッセージまたは拡張されたメッセージを伝達する必要があります。

1. トランクドメインに移動します。
2. 次の値を使用して、セクション4.2.2のパラグラフ2〜10に従って新しいマルチプロトコルゲートウェイを作成します。
   
   
   • 3-名前：IIBMPG、バックエンドタイプ：動的
   • 4-Rq：JSON、Rs：XML
   • 6-名前：IIBHTTP_FSH、ip：127.0.0.1（同じDataPowerからの要求のみ）、ポート：7172、+ Getメソッド
   • 8-名前：IIBPolicy
   • 9-名前：IIBPolicy_rule_req、方向：クライアントからサーバー
   
   
   
3. 説明を追加します。 要求ヘッダーのX-DP-Transform-Nameに基づいて、IIBRuleRoute.xslファイルはローカルから///IIB/route/IIBRouteRules.xmlファイルを受信し、このサービスの要求変換、応答、およびエラーファイルの名前を受け取り、それらの値を対応するコンテキスト変数に設定しますvar：//コンテキスト/ IIB / reqTransform、var：//コンテキスト/ IIB / ansTransform、var：//コンテキスト/ IIB / errTransform。 ヘッダーの他の値（url、uri、expire、timeout）もコンテキスト変数に配置されます。
   
   
   
   
   
   
4. [詳細設定]をルールにドラッグし、リストから[クエリパラメータをXMLに変換]を選択して、別のアクションを追加します。 名前（cmnJSONParseCNVM）と必要なタイプ（JSON）を指定して、新しい入力変換マップを追加する必要があります。
   
   
   
   
   
   
   
   
   
   
5. 標準変換の後に変換を追加して構成します。 この場合、前の変換で設定された変数は、変換ファイルを示すために使用されます。 これは、変換が普遍的であり、ファイル自体が入力メッセージに応じて「オンザフライ」で置換されるように行われます。 メッセージ本文の準備ができました。 次のステップはメッセージのルーティングであり、メッセージ本文は変更されないため、dpvar_1変数を作成し、結果を保存します。 結果変数への入力を指すのはこの変数です。 変更を保存します。
   
   
   
   
   
   
6. ルーティングアクションを追加し、次のパラメーターを設定します。 IIBURLRoute.xslファイルはコンテキスト変数の値を受け取り、その一部はサービス要求変数として設定され、残りはサービス変数に格納される宛先システムへの要求のURIを形成します。
   
   
   
   
   
   
7. 同様に、さらに2つのルールを作成し、すべての変更を保存します。
   
   
   • 方向：サーバークライアント、名前：IIBPolicy_rule_resp;
     
     変換：入力INPUT、出力PIPE、変換ファイルvar：// context / IIB / ansTransform（「オンザフライ」応答の変換を置換するためのコンテキスト変数）。
   • 方向：エラー、名前：IIBPolicy_rule_error;
     
     変換：入力NULL、出力PIPE、変換ファイルvar：// context / IIB / errTransform（オンザフライでエラー変換を置換するコンテキスト変数）。
   
   
   
8. 最終的なポリシーの結果は次のようになります。
   
   
   
   
9. MPGの作成が完了したら、変更を保存します。
   
   

パート5.テスト

5.1。 準備する

1. たとえば、メッセージをキューに読み書きするためのrfhutilユーティリティをダウンロードします。
2. テストファイルは、プロジェクトファイルと同じディレクトリのテストフォルダーにあります。

5.2。 ヘルスチェック

1. curlユーティリティを使用してリクエストを送信します（以下のリクエストの場合、現在のディレクトリはexample.jsonと同じである必要があります）。
   
   
   
   

    curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage" -H "Content-Type: application/json" --data-binary @example.json
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
2. rfhutilユーティリティの2つのインスタンスを開き、最初のインスタンスでDP.IIB.REQINキューからメッセージを減算します。
   
   
3. [MQMD]タブに移動して、MessageIDをコピーします。
   
   
4. 2番目のインスタンスでは、rs.xmlファイルを開き、MQMDタブでCorrelIDにメッセージ識別子を挿入し、DP.IIB.RESINキューにメッセージを入れます。
   
   
5. 同様の答えが得られるはずです。
   
   
   
   
   
   
6. 手順1〜3を繰り返します。
   
   
7. rs_error.xml correllId;
   
   
8. 
   
   
   
   
   
   

6.

6.1。 理論

Log Targets , .

Log Targets . , 4 1000Kb, . 2-4 . , . , DataPower, , , , , , - MPG, .

6.2。 練習する

1. trunk;
2. Log Target ;
3. :
   
   
   • (IIB_LOG);
   • (File);
   • (Text);
   • timestamp(zulu);
   • (logtemp:///IIB.log — IIBMPG);
   • (1000).
     
     
     
     
   
   
   
4. . MPG IIBMPG.
   
   
   
   
   
   
5. , , ( , ).
   
   
   
   
   
   
6. ;
   
   
7. ;
   
   
8. .
   
   
9. Log Targets MPG.
   
   
10. :
    
    
    • , , .
      
      
      
      
      
      
    • .
      
      
      
      
      
      
    
    
    

7. -

1. – , . – , , - .
   
   
2. . View Logs. , « », « » .
   
   
3. . . MPG Show Probe -> Enable Probe. . , .
   
   
   
   
   
   
4. デバッグモードが不要になったら、オフにします。
   
   

他のすべてが失敗した場合は、コメントで質問してください。