この付録では、Oracle B2BでSOAインフラストラクチャおよびJMS内部キューを使用して大きなペイロードを処理する方法について説明します。
この付録の内容は次のとおりです。
Oracle B2Bでは、SOAインフラストラクチャおよびJMS内部キューを通じて大きなペイロードを処理できます。B2Bトランザクションが処理できる大きなペイロードの例として、複数の発注書が含まれる大きなバッチ・ファイルがあります。
ただし、大きなペイロードの定義はユーザー定義であり、顧客やユースケースごとに異なります。大きなペイロードを超えるペイロードに含まれる内容は、データベースではなくファイル・システムに格納され、大きなペイロード構成の一部として指定されます。これによってデータベース表の領域が確保され、実行時のパフォーマンスが最適化されます。
また、12.1.3で使用できるようになったドキュメント・ストリーミング機能により、ドキュメントのチャネルとタイプがストリーミングの条件を満たす場合、ドキュメントは、ペイロード全体をメモリーにロードするのではなく、ストリームを通じて処理されます。詳細は、この後のストリーミングに関する説明を参照してください。
注意:
JMSの大きなペイロードは、ファイル参照ではなくJMS本体を介して送信されます。ファイル参照をバックエンドに送信する場合は、b2b.InlineJMSLargePayLoad
をfalseに設定します。
インバウンド設定
図A-1に、インバウンドの場合に設定するプロパティを示します。「管理」→「構成」に移動します。
大きなペイロードを処理するためにコンポジットをデプロイする場合は、この構成のみが必要となります。B2Bでペイロードをコンポジットに配信しない場合は、図A-2に示すように、「JMSキューをデフォルトとして使用」を「true」に設定します。「管理」→「構成」に移動します。
「JMSキューをデフォルトとして使用」を「true」に設定すると、ペイロードはB2B_IN_QUEUE
(JMSベースのキュー)に配信されます。
アウトバウンド設定
図A-3に、アウトバウンドの場合に設定するプロパティを示します。
Oracle B2Bでは、大きなペイロード(そのサイズは構成設定としてユーザーによって指定されます)をメモリーにロードするのではなく、ストリームを使用して処理できます。
以前は、大きなペイロード・サイズを指定すると、Oracle B2Bはペイロードをデータベースに保持せず、大きなペイロード・ディレクトリにペイロードが配置されました。しかし、ストリーム処理が使用できるようになる前は、Oracle B2Bはペイロードをメモリーにロードして処理するため、非常に大きなペイロードの場合、JVMがヒープ領域を使いはたすことがあります。
大きなペイロードの場合にヒープ内でJVMメモリー領域が不足することを回避するために、Oracle B2Bはペイロードのストリームベース処理をサポートするようになりました。
現在、ストリームベース処理がサポートされているドキュメント・タイプは、次のとおりです。
EDI X12
EDI_EDIFACT
HL7
現在、ストリームベース処理がサポートされているトランスポート・プロトコルは、次のとおりです。
File
FTP
SFTP
MFT
ストリームベース処理は、バッチ処理で特に効果的です(たとえば、10,000ペイロードが1GBバッチに圧縮されている場合)。ペイロードのバッチ処理が解除されると、システムに多くの負荷がかかります。
トランスポートの観点からみると、大きなペイロードしきい値を超えた場合に、ストリームを介して入力ペイロードを処理できるプロトコルは、ファイル、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個すべてをメモリーにロードする必要があるという制限が課せられ、最終的にメモリーのオーバーフローを引き起こします。
ストリーミングは、次の状況では発生しません。
HTTPトランスポートの場合、ペイロードは最初、メモリーにロードされます。ただし、保持されている間にペイロード・サイズがチェックされ、そのサイズが大きなペイロード・サイズより大きいと、ペイロードはデータベースではなくファイル・システムに保持されます。しかし、ペイロードはストリームで処理できません。
処理レイヤーでは、チェックを実行してペイロードが大きなペイロードかどうかを判断し、Oracle B2Bがペイロードをストリームとして処理します。ペイロードがOAGペイロードのようにEDI/X12/HL7以外のペイロードの場合は、メモリーにロードされます。
サービス・エンジンによって大きなペイロードが送信されることをB2Bに通知することも必要となります。変更は次の2つの手順で行います。
Oracle B2Bに大きなペイロードを送信する場合は、BPELプロセスにb2b.largePayload
プロパティを設定する必要があります。大きなペイロードを処理しないコンポジット・サンプルの場合、変更はありません。
注意:
この設定部分の動作は、以前のリリースとは異なります。以前は、このディレクトリはプレーン・ディレクトリでした。しかし、12.1.3.0以降、ストリーム・ストアとして扱われます。これまでは、処理の最中にディレクトリを変更しても、アプリケーションがファイル参照全体を保持しているため、アプリケーションは問題なく動作すると考えられます。しかし、これらが内部的に抽象化され、アプリケーションはストリーム・ストアIDのみを保持するようになりました。
場所の変更が必要な場合は、すべてのペイロードを1つのディレクトリから別のディレクトリに移行する必要があります。ストリーム・ストアの場所の変更を反映するには、サーバーを再起動する必要があります。
Oracle B2Bでこのフラグを処理するためのコード変更。
<variables>
セクションでアウトバウンドBPELプロセスにVariable_largePayload変数を宣言します。
<variable name="Variable_largePayload" type="xsd:string"/>
「割当て」アクティビティで、変数に'true'
をコピーします。
<copy> <from expression="'true'"/> <to variable="Variable_largePayload"/> </copy>
「起動」アクティビティで、変数をb2b.largePayload
に割り当てます。
<bpelx:inputProperty name="b2b.largePayload" variable="Variable_largePayload"/>
注意:
BPELでOracle B2Bに大きなペイロードを送信しない場合は、このプロパティを設定しないでください。
コードをチェックインした後、その確認のために大きなペイロードのサンプルを更新する必要があります。
BPELおよびメディエータで、b2b.largePayload
をtrue
に設定した場合、largePayloadDir
が必要になります(Oracle B2Bで設定します)。b2b.largePayload
を設定していない場合、このディレクトリは問題になりません。
Oracle B2Bでは、大きなペイロードを対応するエンドポイントに送信した後、そのペイロードを大きなペイロード処理ディレクトリに保持します。
大きなペイロードのサポートについて
ペイロードの処理とストリーミングには、次の制限が適用されます。
特定のドキュメント・タイプのみがストリーミングをサポートします。
特定のトランスポート・タイプのみがサポートされます。
XPatch抽出などの機能は、現在、XMLペイロードをメモリーにロードして抽出する傾向があります。(しかし、バッチ処理が行われる場合、その影響は小さくなります。個々のペイロードのサイズは小さく、抽出が完了すると、ロードされた参照がクリアされてガベージ・コレクションがすぐに可能となるためです。)
2GBを超えるドキュメントはサポートされません。
HL7カスタム・デリミタを使用する場合、ネイティブのペイロードがメモリーにロードされます。