大きなペイロードの処理

この付録では、Oracle B2BでSOAインフラストラクチャおよびJMS内部キューを使用して大きなペイロードを処理する方法について説明します。

この付録の内容は次のとおりです。

A.1 大きなペイロードの処理

Oracle B2Bでは、SOAインフラストラクチャおよびJMS内部キューを通じて大きなペイロードを処理できます。B2Bトランザクションが処理できる大きなペイロードの例として、複数の発注書が含まれる大きなバッチ・ファイルがあります。

ただし、大きなペイロードの定義はユーザー定義であり、顧客やユースケースごとに異なります。大きなペイロードを超えるペイロードに含まれる内容は、データベースではなくファイル・システムに格納され、大きなペイロード構成の一部として指定されます。これによってデータベース表の領域が確保され、実行時のパフォーマンスが最適化されます。

また、12.1.3で使用できるようになったドキュメント・ストリーミング機能により、ドキュメントのチャネルとタイプがストリーミングの条件を満たす場合、ドキュメントは、ペイロード全体をメモリーにロードするのではなく、ストリームを通じて処理されます。詳細は、この後のストリーミングに関する説明を参照してください。

ノート:

JMSの大きなペイロードは、ファイル参照ではなくJMS本体を介して送信されます。ファイル参照をバックエンドに送信する場合は、b2b.InlineJMSLargePayLoadをfalseに設定します。

A.1.1 大きなペイロードのサポートの概要

インバウンド設定

図A-1に、インバウンドの場合に設定するプロパティを示します。「管理」「構成」に移動します。

図A-1 大きなペイロード・サイズ

図A-1の説明
「図A-1 大きなペイロード・サイズ」の説明

大きなペイロードを処理するためにコンポジットをデプロイする場合は、この構成のみが必要となります。B2Bでペイロードをコンポジットに配信しない場合は、図A-2に示すように、「JMSキューをデフォルトとして使用」を「true」に設定します。「管理」「構成」に移動します。

図A-2 JMSキューの使用

図A-2の説明が続きます
「図A-2 JMSキューの使用」の説明

「JMSキューをデフォルトとして使用」を「true」に設定すると、ペイロードはB2B_IN_QUEUE (JMSベースのキュー)に配信されます。

アウトバウンド設定

図A-3に、アウトバウンドの場合に設定するプロパティを示します。

図A-3 大きなペイロード・ディレクトリ

図A-3の説明が続きます
「図A-3 大きなペイロード・ディレクトリ」の説明

A.2 ドキュメント・ストリームを使用する大きなペイロードの処理

Oracle B2Bでは、大きなペイロード(そのサイズは構成設定としてユーザーによって指定されます)をインメモリーにロードするのではなく、ストリームを使用して処理できます。

以前は、大きなペイロード・サイズを指定すると、Oracle B2Bはペイロードをデータベースに保持せず、大きなペイロード・ディレクトリにペイロードが配置されました。しかし、ストリーム処理が使用できるようになる前は、Oracle B2Bはペイロードをメモリーにロードして処理するため、非常に大きなペイロードの場合、JVMがヒープ領域を使いはたすことがあります。

大きなペイロードの場合にヒープ内でJVMメモリー領域が不足することを回避するために、Oracle B2Bはペイロードのストリームベース処理をサポートするようになりました。

現在、ストリームベース処理がサポートされているドキュメント・タイプは、次のとおりです。

  • EDI X12

  • EDI_EDIFACT

  • HL7

現在、ストリームベース処理がサポートされているトランスポート・プロトコルは、次のとおりです。

  • ファイル

  • FTP

  • SFTP

  • MFT

ストリームベース処理は、バッチ処理で特に効果的です(たとえば、10,000ペイロードが1GBバッチに圧縮されている場合)。ペイロードのバッチ処理が解除されると、システムに多くの負荷がかかります。

A.2.1 ストリーミングの動作方法

トランスポートの観点からみると、大きなペイロードしきい値を超えた場合に、ストリームを介して入力ペイロードを処理できるプロトコルは、ファイル、FTP、SFTPおよびMFTのみです。つまり、先行するトランスポートを介してシステムが受信するペイロードが大きなペイロード・サイズを超える場合、ペイロードはメモリーにロードされず、ファイル・システムに送信されます(大きなペイロード・ディレクトリに格納されます)。HTTPトランスポートの場合、ペイロードは最初、メモリーにロードされます。ただし、保持されている間にペイロード・サイズがチェックされ、そのサイズが大きなペイロード・サイズより大きいと、ペイロードはデータベースではなくファイル・システムに保持されます。しかし、ペイロードはストリームで処理できません。

大きなペイロードを受信すると、Oracle B2Bエンジンは入力ストリーム参照をファイルに格納します。メモリーにはロードしません。識別レイヤー(取引パートナまたはドキュメント・タイプが識別される)では、Oracle B2Bはペイロードを大きなペイロードとして識別し、ペイロードをメモリーではなくストリームにプッシュします。処理レイヤーでは、同じチェックを実行してペイロードが大きなペイロードかどうかを判断し、Oracle B2Bがペイロードをストリームとして処理します。

しかし、ペイロードがOAGペイロードのようにEDI以外のペイロードの場合は、メモリーにロードされます。EDIペイロードの場合、処理の際にペイロードは入力ストリームから読み取られ、出力ストリームに渡されます。出力ストリームは、処理ディレクトリと呼ばれるディレクトリに格納されます。通常、Oracle B2Bは、大きなペイロード・ディレクトリ自体の中に処理ディレクトリを作成します。

たとえば、Oracle B2Bがファイル・チャネルを介して10,000バッチ処理メッセージ(ペイロード)が含まれる1GBのペイロードを受信し、大きなペイロード・サイズは2MBと指定されているものとします。ファイル・リスニング・チャネルはペイロードを読み取り、それを大きなペイロード・ディレクトリにコピーし、ペイロードを参照するワイヤ・メッセージを作成します。

処理の後、ペイロードはビジネス・メッセージおよびアプリケーション・メッセージに挿入され、バックエンドに配信されます。10,000メッセージのすべてが2MBより大きいわけではありません。

ペイロードがビジネス・メッセージに挿入されるときにチェックが行われ、ペイロードが大きなペイロードかどうかが判断されます。ペイロードが大きなペイロードの場合、処理ディレクトリからペイロード・ファイルがコピーされ、大きなペイロード・ディレクトリにエントリが作成されます。そのエントリへの参照がビジネス・メッセージに設定され、大きなペイロードであることがヘッダーで識別されます(large payload = true)。

ビジネス・メッセージ内のリンク参照をクリックすると、該当の場所からペイロードがロードされます。大きなペイロード・サイズに満たないペイロードはメモリーにコピーされ、データベースに移動されます。ただし、大きなペイロード・サイズに満たないサイズのペイロードでも、XMLへの変換後に、そのサイズが大きなペイロード・サイズを超えることは珍しくありません。このような場合、ペイロードはデータベースに保持されず、ファイル参照がビジネス・メッセージに渡されます。

ストリーミングを使用すると、B2Bはトランザクションを1つずつ読み取り、メモリー内での処理を完了してから、次のトランザクションをメモリーにロードします。このため、大きなペイロードである多数のトランザクションが含まれるEDIファイルを処理する際、B2Nエンジンがメモリーを使いはたすことはありません。

しかし、それぞれが2MB未満である10,000メッセージという前述の例の場合、10,000メッセージのペイロード全体を1つのトランザクションで処理することは不可能です。バッチの部分コミット・サイズ(たとえば、200メッセージ)を指定する必要があります。それによって、部分コミット・サイズに達するたびに、200メッセージがデータベースにコミットされます。

JTAが高い値に設定されていても、すべてのメッセージを単一のトランザクションで処理しようとする場合、小さなペイロードであるため配信と保持の際にOracle B2Bが10,000個すべてをメモリーにロードする必要があるという制限が課せられ、最終的にメモリーのオーバーフローを引き起こします。

A.2.1.1 ストリーミングが発生しない場合

ストリーミングは、次の状況では発生しません。

  • HTTPトランスポートの場合、ペイロードは最初、メモリーにロードされます。ただし、保持されている間にペイロード・サイズがチェックされ、そのサイズが大きなペイロード・サイズより大きいと、ペイロードはデータベースではなくファイル・システムに保持されます。しかし、ペイロードはストリームで処理できません。

  • 処理レイヤーでは、チェックを実行してペイロードが大きなペイロードかどうかを判断し、Oracle B2Bがペイロードをストリームとして処理します。ペイロードがOAGペイロードのようにEDI/X12/HL7以外のペイロードの場合は、メモリーにロードされます。

A.2.1.2 バックエンドからのドキュメント・ストリームの使用

サービス・エンジンによって大きなペイロードが送信されることをB2Bに通知することも必要となります。変更は次の2つのステップで行います。

Oracle B2Bに大きなペイロードを送信する場合は、BPELプロセスにb2b.largePayloadプロパティを設定する必要があります。大きなペイロードを処理しないコンポジット・サンプルの場合、変更はありません。

ノート:

この設定部分の動作は、以前のリリースとは異なります。以前は、このディレクトリはプレーン・ディレクトリでした。しかし、12.1.3.0以降、ストリーム・ストアとして扱われます。これまでは、処理の最中にディレクトリを変更しても、アプリケーションがファイル参照全体を保持しているため、アプリケーションは問題なく動作すると考えられます。しかし、これらが内部的に抽象化され、アプリケーションはストリーム・ストアIDのみを保持するようになりました。

場所の変更が必要な場合は、すべてのペイロードを1つのディレクトリから別のディレクトリに移行する必要があります。ストリーム・ストアの場所の変更を反映するには、サーバーを再起動する必要があります。

Oracle B2Bでこのフラグを処理するためのコード変更。

  1. <variables>セクションでアウトバウンドBPELプロセスにVariable_largePayload変数を宣言します。

    <variable name="Variable_largePayload" type="xsd:string"/>
    
  2. 「割当て」アクティビティで、変数に'true'をコピーします。

    <copy>
     <from expression="'true'"/>
     <to variable="Variable_largePayload"/>
    </copy>
    
  3. 「起動」アクティビティで、変数をb2b.largePayloadに割り当てます。

    <bpelx:inputProperty name="b2b.largePayload"
     variable="Variable_largePayload"/>
    

ノート:

BPELでOracle B2Bに大きなペイロードを送信しない場合は、このプロパティを設定しないでください。

コードをチェックインした後、その確認のために大きなペイロードのサンプルを更新する必要があります。

BPELおよびメディエータで、b2b.largePayloadtrueに設定した場合、largePayloadDirが必要になります(Oracle B2Bで設定します)。b2b.largePayloadを設定していない場合、このディレクトリは問題になりません。

Oracle B2Bでは、大きなペイロードを対応するエンドポイントに送信した後、そのペイロードを大きなペイロード処理ディレクトリに保持します。

大きなペイロードのサポートについて

  1. 大きなペイロードのテストを行う場合は、「管理」「構成」タブの「ペイロードをログに記録」を「false」に設定します。
  2. 大きなペイロードのテストを行う場合は、「管理」「構成」タブの「ペイロードの表示」を「false」に設定して、レポートにペイロードが表示されないようにします。
  3. 大きなペイロードを処理するときにエンキュー・スクリプトを使用する場合は、次の指定を追加します
    eventName=LARGE_PAYLOAD=true
    
  4. -Xmx2048mを使用するように最大ヒープ・サイズを増やします。
  5. SOAデータソースが自動的に拡張されるようにデータベースの表領域サイズを増やし、表領域ファイル・サイズの上限を上げます。

    alter database datafile '/scratch/$user/auto_work/db230/oradata/db230/SH_soainfra.dbf' autoextend on next 10M maxsize 4096M

  6. Oracle WebLogic管理サーバーのトランザクション・タイムアウトを次のように設定します。
    • Weblogicコンソール・サービス -> JTAタイムアウト秒=720秒

    • Weblogicコンソール・サービス -> JDBC -> DataSources -> SOADataSource - XAタイムアウトを120秒と180秒の間に増やす

  7. Oracle B2Bを(SOAインフラストラクチャを使用せずに)単独で使用する場合は、Oracle Enterprise Manager Fusion Middleware Controlを使用して、b2b.jtaTimeoutにJTAタイムアウトを設定できます。詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイドを参照してください。
  8. アウトバウンドSOAコンポジットの場合は、図A-4に示すように、ファイル・アダプタ用に「ファイル・ストリーミングを使用します」オプションを常に選択します。

    図A-4 ファイル・アダプタ用の「ファイル・ストリーミングを使用します」オプション

    図A-4の説明が続きます
    「図A-4 ファイル・アダプタ用の「ファイル・ストリーミングを使用します」オプション」の説明
A.2.1.3 大きなデータセットの設定シナリオ

次の推奨設定は、約2,500の取引パートナを含むデータセット(サイズが約253MBのエクスポートZIPファイル)があり、6GBのコンピュータを使用することを想定しています。このような設定を使用すると、アップグレード・アシスタントを使用した場合に、データ・アップロード時間を大幅に短縮できます。

  1. Oracle WebLogic Server管理コンソールを使用して、次の値を増やします
    • JTAトランザクション・タイムアウトを30から350に増やします

    • 最大メッセージ・サイズをデフォルト・サイズから200000000に増やします

  2. パフォーマンス向上のために索引を追加します。Oracle Database 11g Enterprise Editionリリース11.1.0.7.0 - 製品版を「パーティショニング」、「OLAP」、「データ・マイニング」、「Real Application Testing」の各オプションとともに使用して、次の処理を実行します。
    SQL> create index idx_mds_attr on
    rc1_mds.MDS_ATTRIBUTES("ATT_VALUE","ATT_LOCALNAME");
    Index created.
    
    SQL> create index idx_mds_path on
    rc1_mds.MDS_PATHS("PATH_CONTENTID","PATH_PARTITION_ID");
    Index created.
    
    SQL> commit;
    
  3. 次の更新後のメモリー設定を使用して管理対象サーバーを起動します。
    DEFAULT_MEM_ARGS="-Xms1024m -Xmx2048m"
    
  4. ORACLE_HOME/bin/UAデフォルト・メモリーをデフォルトの256から2048に変更します。デフォルトは
    $JAVA_HOME/bin/java ${JAVAMODE} -Xmx256m -classpath ${CLASSPATH}
    -Dua.home=$base_dir -Dice.pilots.html4.ignoreNonGenericFonts=true
    -Dsun.lang.ClassLoader.allowArraySyntax=true
    -Doracle.installer.oui_loc=$OUI_HOME oracle.ias.upgrade.UpgradeDriver
    $ARGUMENTS
    

    このデフォルトを次のように変更します

    $JAVA_HOME/bin/java ${JAVAMODE} -Xmx2048m -classpath ${CLASSPATH}
    -Dua.home=$base_dir -Dice.pilots.html4.ignoreNonGenericFonts=true
    -Dsun.lang.ClassLoader.allowArraySyntax=true
    -Doracle.installer.oui_loc=$OUI_HOME oracle.ias.upgrade.UpgradeDriver
    $ARGUMENTS
    
  5. 「スタック・スレッド最大時間」の値を600から2000に変更します。

A.2.2 制限事項

ペイロードの処理とストリーミングには、次の制限が適用されます。

  • 特定のドキュメント・タイプのみがストリーミングをサポートします。

  • 特定のトランスポート・タイプのみがサポートされます。

  • XPatch抽出などの機能は、現在、XMLペイロードをメモリーにロードして抽出する傾向があります。(しかし、バッチ処理が行われる場合、その影響は小さくなります。個々のペイロードのサイズは小さく、抽出が完了すると、ロードされた参照がクリアされてガベージ・コレクションがすぐに可能となるためです。)

  • 2GBを超えるドキュメントはサポートされません。

  • HL7カスタム・デリミタを使用する場合、ネイティブのペイロードがメモリーにロードされます。