推奨する運用

コラボレーションにおいてレコードを解析したり、ペイロードを構築するには、レコードを処理する BatchRecord OTD を BatchLocalFile OTD と組み合わせて使用してください。2 つの OTD を組み合わせて使用すると、BatchFTP OTD のみを使用する場合に比べて多くの利点があります。

例 1: 大規模ファイルの解析

たとえば、大規模ファイルを解析するコラボレーションルールを設定し、レコードをデータベースまたは JMS IQ Manager に送信するとします。解析処理中に問題が発生した場合、ファイル全体を FTP サーバーからふたたび送信する必要があります。

対照的に、ローカルファイルシステムからストリーミングを実行していると、エラーが発生した場合も同じファイルを再度 FTP 転送することは回避できます。この方法には、大規模ファイルでデータストリーミングおよび読み取りの再開機能を使用できるという利点があります (「コンポーネント間でのデータのストリーミング」および「読み取りの再開機能」を参照)。

例 2: 速度が遅く、複雑なクエリー

もう 1 つのシナリオとして、多数のレコードを取得するために速度が遅く、複雑な SQL クエリーが使用されている場合が考えられます。コラボレーションルールは、レコード処理 OTD を使用して Payload ノードにこれらのレコードをパックし、FTP を介して外部システムに送信します。FTP 転送が失敗すると、SQL クエリーを再度実行する必要があります。

対照的に、BatchLocalFile OTD を使用してデータペイロードがローカルに格納されている場合、SQL クエリーを再実行する必要なく、FTP 転送を繰り返せます。こうした場合、データストリーミングおよびローカルファイルの追加も使用できます。

どちらの場合も、データストリーミングリンクを使用すると、BatchFTP OTD で使用されるインメモリー・データペイロード転送と比べて、必要なメモリー量を大幅に削減できます。

OTD の限界

BatchLocalFile OTD は、マップされたドライブおよび NFS マウント済みドライブをサポートします。ただし、ドライブのマッピングはサポートしません。つまり、ドライブはすでにマップ済みまたはマウント済みである必要があります。アダプタ自体は、マッピングやマウントを一切行いません。

OTD は Universal Reference Identifier (URI) をサポートしますが、スキーマは除外します。たとえば、\\drive\directory\file_name のようにです。