IMS Synchronous Request サンプルについて

IMS Synchronous Request サンプルは IMSRequest ノードを使用します。 このノードがどのように機能し、構成されるかに関する概要は、WebSphere Message Broker 資料の、IBM 情報管理システム (IMS) を参照してください。

このサンプルは Display All Invoices (DSPALLI) トランザクションを使用します。これは IMS システムに通常インストールされる IMS サンプル・トランザクションです。 サンプルの使用を試みる前に、これがインストール済みであることをシステム管理者に確認してください。 送り状に関する詳細を取り出すために REXX プログラム (DFSSAM07) または COBOL プログラム (DFSSAM7) を実行するよう、DSPALLI トランザクションをセットアップできます。 これらのプログラムは同じ機能を実行して同じ論理データを生成しますが、通信上の物理フォーマットは異なります (たとえば、異なるサイズ・フィールド、追加のセグメントなど)。 デフォルトでは、DSPALLI は REXX を使用するようセットアップされます。 COBOL を使用するよう DSPALLI を変更できますが、COBOL プログラムはすぐに使用できる状態で提供されていないため、コンパイルしてリンクする必要があります。 このサンプルはどちらのプログラムでも機能します。 要求ノードを使用するメッセージ・フローの設計方法を理解するために、最初は REXX バージョンを使用してください。 ただし、COBOL バージョンの方が REXX バージョンよりも高速に実行されます。

このサンプル・フローは、IMS システムと対話する WebSphere Message Broker メッセージ・フローの設計方法を示しています。 IMS と対話する際には、以下の 2 つの要素を考慮することが重要です。 この 2 つの要素を区別して理解することは重要です。 IMS メッセージ自体には処理対象のデータが含まれるだけでなく、データ・サイズに関する構造情報 (メッセージの各セグメントの最初の LLZZ データ) や、データの処理方法を示すメタデータ (データの最初の部分はトランザクションまたはコマンドの名前) も含まれるためです。 これらのメッセージの構造に関する説明は、IBM 情報管理システム (IMS) を参照してください。

IMSRequest ノードは IMS Connect との接続を提供し、トランザクション実行時のコミット・モードおよび同期レベルの選択を可能にします。 サンプルでは、これらのプロパティーがデフォルト値に設定されています。 つまり、コミット・モードは send_then_commit、同期レベルは confirm です。 これらの値は、通常、同期要求を実行する際に使われます。 ノードは、LLZZ 設定済みの IMS メッセージへの直列化が可能なメッセージ・ツリーを受け取ることを想定します。 IMS からの応答ビット・ストリームは、Request ノードの「応答メッセージ構文解析」タブで構成されたパーサーに経路指定されます。

DSPALLI によって使用されるメッセージ構造

このサンプルで使用される DSPALLI トランザクションは、単一セグメントの入力メッセージを必要とし、複数セグメントの出力メッセージを作成します。 出力で生成されるセグメントの数は、プログラムの処理内容に応じて異なります。 REXX バージョンのプログラムを使用する場合、成功したメッセージの先頭にはヘッダーを形成する 5 つのセグメントがあり、さらに表示される送り状ごとに 1 つのセグメントがあります。 COBOL バージョンには 3 つのセグメントがあり、その後に送り状が続きます。 REXX フォーマットの 3 番目のセグメントにはデータがなく、COBOL フォーマットにはデータが含まれるため、2 つのフォーマットを区別できます。 このトピックでは、REXX バージョンと明記しない限り、COBOL バージョンのみの情報を示しています。 その理由は、ほとんどのアプリケーションが REXX ではなく COBOL で作成されるため、また (必要なメッセージ・セットの開発を容易にする) COBOL コピーブックのインポートが WebSphere Message Broker でサポートされているためです。 失敗した場合には、失敗の原因を示す 1 つのセグメントだけが DSPALLI からの応答に含まれます。

COBOL バージョンの COBOL 構造は、プログラム SRC DFSSAM7 に含まれています。 ここでは、プログラムで使用されるセグメントごとに構造が定義されています。 このサンプルで使用される主な 3 つのセグメントは次のとおりです。

このプログラムには他のセグメントのデータ構造も存在しますが、これらはこのサンプルとは関係のないヘッダー構造であるため、インポートする必要はありません。 これらのセグメントは、LL および残りのデータと同様に未解析のままになる可能性があります。

次のように、TERM-IN-AREA セグメントは、トランザクションによって接頭部を付けられる他の多くのトランザクションの入力セグメントと似ています。

006010 01 TERM-IN-AREA.                                               00350000
006020 02 CHAR-COUNT PICTURE S99 COMPUTATIONAL. 00360000
006030 02 FILLER PICTURE S99 COMPUTATIONAL. 00370000
006040 02 TRANS-CODE PICTURE X(7). 00380000
006050 02 MESSAGE-TEXT-START PICTURE X(125). 00380000

主要な構造は次のとおりです。

成功した出力メッセージには、次のような 3 つのヘッダー・セクションと、繰り返される詳細セクションが含まれます。

このサンプルは詳細セクションだけを構文解析して、ヘッダー・セクションは未解析のままにします。 この後の『DSPALLI 用の MRM メッセージ・セットの構築』では、この構文解析が MRM でどのように実行されるかを示します。 以下のサンプルは DETAIL-OUT セグメントの最初の数行だけを示しています。 全体的な構造については DFSSAM7 を参照してください。
010010 01 DETAIL-OUT.                                                 00900000
010020 02 DO-CHAR-CNT PICTURE S99 VALUE +84 COMP. 00910000
010030 02 FILLER PICTURE S99 VALUE +0 COMP. 00920000
010050 02 DO-LINE-CNT PICTURE Z9. 00930000
010055 02 FILLER PICTURE X VALUE '.'. 00940000
010060 02 FILLER PICTURE XX VALUE SPACES. 00950000
主要な構造は次のとおりです。 サンプルによって使用される最後のセグメント REJECT-MESSAGE は、送り状の詳細を取得する際に (無効な部品番号などの理由で) トランザクションに問題が発生した場合に出現します。
015010 01 REJECT-MESSAGE.                                              01450000
015020 02 REJ-CHAR-CNT PICTURE S99 COMPUTATIONAL. 01460000
015030 02 FILLER PICTURE S99 COMPUTATIONAL VALUE +0. 01470000
015050 02 FILLER PICTURE X(8) VALUE '.PART = '. 01480000
015060 02 REJ-PN PICTURE X(16) VALUE SPACES. 01490000
015070 02 REJECT-REASON PICTURE X(110). 01500000
主要な構造は次のとおりです。

DSPALLI 用の MRM メッセージ・セットの構成

プログラム DFSSAM7 には DSPALLI で必要なすべてのデータ構造が含まれています。 MRM メッセージ・セットを構成する第 1 段階は、COBOL インポーターを使って必要な構造をメッセージ・セットにインポートすることです。 その手順は以下のとおりです。

  1. COBOL という名前のバイナリー物理フォーマットの新しいメッセージ・セットを作成します。
  2. 新しいメッセージ・セットを展開し、「メッセージ定義」フォルダーを右クリックして、「新規」>「メッセージ定義ファイルの作成元」>「COBOL ファイル」をクリックします。
  3. ブラウズして、(システムで独自に得られるか、または DFSSAM7 から抽出される) ファイル DFSSAM7.cbl を見つけます。
  4. 「次へ」をクリックして「メッセージおよび構造の選択」画面を表示します。TERM-IN-AREA、DETAIL-OUT、および REJECT-MESSAGE という 3 つの構造を「構造のインポート」セクションに追加します。
  5. TERM-IN-AREA および REJECT-MESSAGE の横のチェック・ボックスを選択して、これらのエレメントのメッセージ・タイプが作成されるようにします。 DETAIL-OUT は応答メッセージの単なる一部分であるため、それ自体はメッセージ・タイプではありません。 それ以外のオプションは変更しないでください。
  6. 「次へ」をクリックして、「終了」をクリックします。 DSPALLI という新しいメッセージ定義が作成され、2 つのメッセージ・タイプ msg_TERMINAREA および msg_TERMINAREA がそれに含まれます。
トランザクション DSPALLI は、プログラムの動作に応じて異なる構造を戻す可能性があります (たとえばエラーが発生した場合)。 この状況を扱うために、サンプルでは、まず一般的な構造を使って応答を構文解析してセグメントに分けます。 その後、使用すべき構造が識別された時点で、正しい構造を使って再解析します。 (IMS トランザクションからのあらゆる応答に使用できる) 汎用構造を構成するには、以下の手順に従います。
  1. メッセージ定義 DSPALLI をエディターで開き、「メッセージ」を右クリックして 「メッセージの追加」をクリックします。
  2. 新しいメッセージに msg_IMSMessage という名前を付けます。
  3. 「タイプ」を右クリックして、「複合タイプを追加」をクリックします。
  4. タイプに segmentType という名前を付けます。
  5. IMSSegment という新しいエレメントを、タイプ segmentmsg_IMSMessage に追加します。 その max occur 値を必ず -1 (無制限) にしてください。
  6. LL および ZZdata という名前の 2 つのローカル・エレメントをタイプに追加します。 LL フィールドのデータ・タイプは intZZdata フィールドのデータ・タイプは string にする必要があります。
    IMSMessage の構造
  7. ZZdata フィールドを選択して、「概要」から「プロパティー」に切り替えます。
  8. COBOL 物理表現を「長さ」から「長さ参照」に変更します。
  9. 「長さ参照」フィールドを LL に設定します。
  10. LL フィールドは LL と ZZ を含むセグメント全体の長さであるため、「包括的な長さ参照」を選択します。 IMS メッセージの物理フォーマット

これで、メッセージ・タイプ msg_IMSMessage を使用して、任意の IMS 応答メッセージを構文解析して個々のセグメントに分けることができます (ただしセグメント自体は構文解析できません)。 サンプルではこのメッセージ・タイプを使って IMS システムからの応答を構文解析した後、セグメントの数とサイズに基づいて、別のメッセージ・タイプを使って再解析します。

拒否メッセージを扱うためのエラー・メッセージ・タイプ msg_REJECTMESSAGE は既に定義済みです。 必要な最後のメッセージ・タイプは、すべての DETAIL-OUT セグメントを含む以下のような成功メッセージ・タイプです。

  1. メッセージ定義 DSPALLI をエディターで開き、「メッセージ」を右クリックして 「メッセージの追加」をクリックします。
  2. 新しいメッセージ・タイプに msg_COBOLRESPONSE という名前を付けます。
  3. segmentType タイプの IMSSegment、および DETAILOUT タイプの msg_DETAILOUT という名前の 2 つのエレメントを、新しいタイプに追加します。
  4. IMSSegmentmin occurs および max occurs3 にする必要があります (構文解析されない 3 つのヘッダー・セグメント用)。
  5. msg_DETAILOUT セグメントの min occurs0max occurs は無制限 (-1) にする必要があります。 COBOL 応答のデータ構造

これで、必要なすべてのデータ構造が作成されました。 サンプル・メッセージ・フローには、これらの構造を使って XML 文書を IMS 要求にマップした後、(XML 文書に再びマップされる) IMS 応答を構文解析する方法が示されています。

メッセージ・フローの働き

サンプルの基本的な機能は、XML メッセージを WebSphere MQ キューから取得して IMS 要求に変換し、IMS に対してトランザクションを実行して、その応答を WebSphere MQ キュー上の XML メッセージとして再びフォーマットすることです。 以下の図は、メッセージ・フローがどのようなものであるかを示しています。

IMS 要求メッセージ・フロー

以下のリストでは、ノードごとの処理について説明します。

  1. MQInput ノードはキュー IMS_SYNC_REQUEST_IN1 からメッセージを取得し、XML パーサーを使ってそれを構文解析します。
  2. InputMapping ノードは XML 構造を msg_TERMINAREA にマップします。 また、このノードは、メッセージ・タイプで自動生成できない LL 値を計算します。
  3. SaveMQMD Compute ノードは、メッセージ ID と相関 ID を保存するために MQMD を保存します。 (他のトランスポートを使用する場合、または応答メッセージでメッセージ ID と相関 ID が必要でない場合には、このノードを省略できます。)
  4. IMSRequest ノードはデータを直列化して、実行用に IMS に送ります。 このノードは汎用メッセージ・タイプ msg_IMSMessage を使用して、戻されるビット・ストリームを構文解析し、これによってビット・ストリームは個々のセグメントに分割されます。
  5. Reject? Filter ノードはセグメント数をカウントします。セグメントが 1 つであれば応答としてエラーを戻し、複数であれば成功です。
  6. ProcessSuccessReponse サブフローは msg_COBOLRESPONSE フォーマットを使ってビット・ストリームを再解析し、それをマップして XML フォーマットを作成します。
  7. ProcessRejectResponse サブフローは msg_REJECTMESSAGE メッセージ・タイプを使ってビット・ストリームを再解析し、それを XML 応答にマップします。
  8. RestoreMQMD Compute ノードは元の MQMD を追加します。
  9. MQOutput ノードは、XML メッセージをキュー IMS_SYNC_REQUEST_OUT1 に書き込みます。
メッセージ・フローの最も重要な部分は、応答メッセージの構文解析です。 強く型付けされていない IMS トランザクションは任意の数または組み合わせのセグメントを戻す可能性があるため、この構文解析は複雑です。 フローはこの状況を扱うために、まず、IMSRequest ノードから戻されるあらゆるデータを処理できる汎用セグメント・メッセージ・タイプを使って応答を構文解析した後、既知のタイプで再解析可能な処理にメッセージを送るために Filter ノード (または任意の経路指定ノード) 内でロジックを使用します。 この汎用ロジックはすべての IMS トランザクションに使用できます。 ただし、そのためにはセグメント定義をインポートできる (または手作業で構成できる) 必要があり、どのメッセージ・タイプを使用すべきかの識別に役立つ何らかのデータがセグメント内に存在する必要もあります。 このメッセージ・フローでは ResetContentDescriptor ノードを使って再解析を実行しますが、ESQL ステートメントを使って再解析を実行することもできます。

REXX バージョンでのメッセージ・フローの動作

上記の説明は基本的に COBOL に当てはまります。 REXX バージョンのプログラムの入力メッセージも COBOL プログラムと同じであるため、このメッセージ・フローは REXX バージョンでも機能します。 主な相違点は、応答メッセージです。 主に次の 2 つの点で、応答メッセージは互いに異なります。

このため、サンプルでは msg_COBOLRESPONSE および msg_REXXRESPONSE の 2 つの応答フォーマットが必要です。 これらのフォーマットの主な相違点として、REXX バージョンには詳細セグメントの前に 5 つのヘッダー・セグメントがあります。 詳細セグメントは同じですが、さまざまなデータ・タイプを扱う新しい REXX 物理フォーマットが追加されています。 REXX 応答を構文解析する際、フォーマット REXX のメッセージ・タイプ msg_REXXRESPONSE が使用されます。

サンプルのホームに戻る