test

通信アダプタ用 OTD の開発

バッチアダプタ OTD の使用法

バッチ OTD の概要

OTD には、オブジェクトを定義する一連のルールが含まれます。オブジェクトは、プロジェクトのコラボレーション定義を作成するための基礎として使用される OTD を通過するデータをエンコードします。

各 OTD は、アダプタの固有の機能セットを持つテンプレートとして機能します。バッチアダプタ OTD テンプレートは、カスタマイズ対象外で、編集できません。

OTD は、次の 4 つの部品で構成されます。

OTD フォルダ構造の上位レベルのビューには、FTP、セキュリティー保護された FTP、バッチレコード、またはローカルファイルデータ交換を呼び出すビジネスルールの作成に使用できるメソッドおよび属性が表示されます。

バッチアダプタ OTD のタイプ

アダプタで使用可能な、特化された OTD は次の図のとおりです。

表 1–1 バッチアダプタ OTD

OTD 名

説明

BatchFTP 

リモートシステムへの FTP アクセスを提供します。 

BatchFTPOverSSL 

FTP を SSL 上で使用して、セキュリティー保護されたデータ転送を提供します。 

BatchSCP 

Secure Shell (SSH) をベースとなるプロトコルとしながら Secure Copy Protocol を使用して、セキュリティー保護されたデータ転送を提供します。 

BatchSFTP 

SSH ファイル転送プロトコル (SFTP プロトコル) を使用して、セキュリティー保護されたデータ転送を提供します。 

BatchLocalFile 

ローカルファイルシステムに簡単にアクセスできるようにします。 

BatchRecord 

アダプタで、指定した形式のレコードのペイロードを解析または作成 (あるいはその両方) できるようにします。 

BatchInbound 

入力ファイルをポーリングし、ファイルの名前を GUID に変更して、ビジネスプロセスまたはコラボレーションをトリガーします。 

この章では、これらの各 OTD についてと、各 OTD をアダプタで使用する方法を説明します。

OTD の機能

OTD には、次の機能があります。

すべての OTD は、Netbeans IDE を使用して設定および管理します。これらの OTD に関連するすべてのクライアントコンポーネントには、独自の要件があります。詳細は、クライアントシステムのマニュアルを参照してください。

BatchFTP、BatchLocalFile、および BatchRecord OTD の場合、(プロパティーエディタの) 環境プロパティーまたは接続マッププロパティーに対応するセクションがあるノードのみが、OTD 上に実装されます。残りのノードは実装されず、将来の使用に備えて予約されます。

BatchFTP、BatchLocalFile、および BatchRecord OTD の場合、(プロパティーエディタの) 環境プロパティーまたは接続マッププロパティーに出現する設定パラメータのみが OTD での使用をサポートされます。残りの設定パラメータは実装されず、将来の使用に備えて予約されます。実装済み設定パラメータは、実装されていないノードからアクセスおよび使用できることがありますが、こうした使用方法はお勧めしません。

BatchFTP OTD

バッチアダプタには、FTP データ転送機能の実行を可能にする 4 つの OTD が含まれます。BatchFTP OTD を使用すると、Sun Enterprise Service Bus システムは、ファイルに格納されたオブジェクトを受信および配信する目的で他のネットワークホストとデータを交換できます。また、BatchFTPOverSSL、BatchSCP、および BatchSFTP OTD を使用すると、SSL または SSH 上で FTP を使用して、ローカルホストとリモートホスト間でデータを安全に転送できます。

BatchFTP OTD の構造

BatchFTP OTD には、Client、Configuration、Provider、State、および StateManager という 5 つの上位レベルノードが含まれます (次の図を参照)。これらのノードを展開すると、サブノードが表示されます。

図 1–6 BatchFTP OTD の構造

BatchFTP OTD の構造

Configuration ノード

OTD の Configuration ノードの各フィールドサブノードは、アダプタの FTP 設定パラメータのいずれかに対応します。

Client および Provider ノード

この OTD には、さらに 2 つの上位レベルノード、Client および Provider が含まれます。これらのノードは、アダプタのそれぞれの機能インタフェースを実装します。

BatchFTP OTD のノードの機能

次のリストは、BatchFTP OTD の各ノードについて、主要機能などを説明しています。

BatchFTP OTD の使用法

BatchFTP OTD ノードを使用すると、FTP 処理を制御するコラボレーションの特定のアダプタ設定パラメータを設定できます。いったん設定パラメータを設定したら、このコラボレーションを使用する各該当アダプタコンポーネントで同じパラメータを定義する必要がありません。

型変換の処理

BatchFTP OTD の Payload ノードは、バイト配列 (byte[] ) として定義済みです。この定義により、アダプタはバイナリデータと文字データの両方を処理できます。

たとえば、「data」ノードが String (java.lang.String) として定義されている別の OTD (別のアダプタの OTD や、ユーザーが定義した OTD など) を使用できます。その String を BatchFTP OTD の Payload ノードにマップすると、コラボレーションエディタは、自動的に型変換を行い、次の例に示したようなコードを作成します。

注 –

この機能は注意して使用してください。これは、多くの状況で機能しますが、デフォルトのエンコーディングが変換でエラーを引き起こすことがあります。

コード変換と生成

たとえば、文字列からバイトへの配列変換 (またはその逆) で生成される Java コードは次のようになります。


 getoutput().setPayload(STCTypeConverter.toByteArray
    (getinput().getBlob()));

または


 getinput().setBlob(STCTypeConverter.toString
    (getoutput().getPayload()));

ブロブデータをバイト配列として定義した場合、型変換は不要です。変換が必要な場合、コラボレーションエディタは、前の例に示しているように、Java 仮想マシン (JVM) のデフォルトエンコーディングを使用してコードへの変換を実行します。

型変換のトラブルシューティング

前に説明したように、デフォルトエンコーディングおよび変換は、多くの状況で機能します。ただし、たとえば .zip ファイルのようなバイナリデータで、エンコーディングが変換でエラーを引き起こすことがあります。データ文字セットと JVM のデフォルトエンコーディングに応じて、適切なエンコーディングを選択してください。ほとんどの場合、エンコーディング文字列「ISO-8859-1」を使用するのが最善の選択です。

このエンコーディングを使用するには、エンコーディング文字列を追加することによってコードを手作業で変更します。前の例では、「ISO-8859-1」を使用するコードは次のようになります。


 getoutput().setPayload(STCTypeConverter.toByteArray
    (getinput().getBlob(), "ISO-8859-1"));

または


 getinput().setBlob(STCTypeConverter.toString
    (getoutput().getPayload(), "ISO-8859-1"));

この文字列を使用すると、この型変換の問題が解決されます。詳細は、該当する JVM エンコーディングのリファレンスマニュアルを参照してください。

基本的な BatchFTP OTD メソッド

フィールド要素に加えて、BatchFTP OTD の Client ノードには、アダプタのクライアントインタフェース機能を拡張するメソッドが含まれます。これらのメソッドは、OTD の適切な使用に不可欠であるため、ここで詳しく説明します。次のメソッドがあります。

シーケンス番号付け

シーケンス番号付け機能を使用すると、FTP のターゲットディレクトリ名またはファイル名がシーケンス番号を含むように設定できます。OTD のアダプタ設定パラメータを使用して、開始シーケンス番号および最大シーケンス番号を設定できます。

このパラメータは、名前パターン %# に使用します。

また、この機能は BatchLocalFile OTD でも使用できます。これらの設定パラメータの詳細は、「シーケンス番号付け」 (BatchFTP 接続マップ) を参照してください。

その他の FTP ファイル転送コマンド

また、BatchFTP OTD では、ファイル転送処理の直前または直後に実行するコマンドを入力できます。詳細は、「ファイル転送前/転送後コマンド」のセクションを参照してください。

BatchFTPOverSSL OTD

SSL 上のセキュリティー保護されたバッチ FTP OTD (BatchFTPOverSSL) は、Secure Sockets Layer (SSL) プロトコルを使用して、セキュリティー保護されたデータ転送を提供します。

外部 FTP サーバー、SSL サーバーなどの設定については、アプリケーションのマニュアルを参照してください。

BatchFTPOverSSL OTD の構造

BatchFTPOverSSL OTD には、Client と Configuration という 2 つの上位レベルノードが含まれます (次の図を参照)。これらのノードを展開すると、サブノードが表示されます。

図 1–7 BatchFTPOverSSL OTD の構造

BatchFTPOverSSL OTD の構造

BatchFTPOverSSL OTD のノードの機能

次のリストは、BatchFTPOverSSL OTD の各ノードについて、主要機能などを説明しています。

BatchFTPOverSSL: OTD のルートノードを表します。

Configuration ノード

Configuration ノードの下にある BatchFTPOverSSL のサブノードは、BatchFTPOverSSL アダプタの接続マップ設定パラメータおよび環境設定パラメータに対応します。

BatchFTPOverSSL Client ノード

Client ノードには、OTD にアダプタのクライアントインタフェースを実装するサブノードが含まれます。BatchFTPOverSSL Client ノードには、次のメソッドが含まれます。

BatchSFTP OTD

セキュリティー保護されたバッチ SFTP OTD (BatchSFTP) は、SSH ファイル転送プロトコル、つまり SFTP を使用して、セキュリティー保護されたデータ転送を提供します。SFTP には、中断された転送の再開、ディレクトリリスト、リモートファイルの削除など、リモートファイルに対するさまざまな処理が備わっています。

SFTP は、Secure Shell (SSH) プロトコルを使用して、ローカルとリモートホスト間、または 2 つのリモートホスト間でコンピュータファイルをセキュリティーで保護しながら転送する手段の 1 つです。BatchSFTP OTD は、SFTP を使用して、ファイルをリモートホストにコピーするか、またはリモートホストからコピーします。

BatchSFTP OTD の構造

BatchSFTP OTD には、Client と Configuration という 2 つの上位レベルノードが含まれます (次の図を参照)。これらのノードを展開すると、サブノードが表示されます。

図 1–8 BatchSFTP OTD の構造

BatchSFTP OTD の構造

BatchSFTP OTD のノードの機能

次のリストは、BatchSFTP OTD の各ノードについて、主要機能などを説明しています。

BatchSFTP: OTD のルートノードを表します。

Configuration ノード

Configuration ノードの下にある BatchSFTP のサブノードは、BatchSFTP アダプタの接続マップ設定パラメータおよび環境設定パラメータに対応します。

BatchSFTP の Client ノード

BatchSFTP OTD の Client ノードには、次のメソッドが含まれます。

BatchSCP OTD

セキュリティー保護されたバッチ SCP OTD (BatchSCP) は、Secure Shell (SSH) をベースとなるプロトコルとしながら Secure Copy Protocol を使用して、セキュリティー保護されたデータ転送を提供します。SCP は RCP (遠隔コピー) に似ていますが、RSH (リモートシェル) ではなく Secure Shell (SSH) 上でファイルがコピーされる点が異なります。ファイルが SCP を使用してコピーされると、データは転送中に暗号化されます。

外部 FTP サーバー、SSH サーバーなどの設定については、アプリケーションのマニュアルを参照してください。

BatchSCP OTD の構造

BatchSCP OTD には、Client と Configuration という 2 つの上位レベルノードが含まれます (次の図を参照)。これらのノードを展開すると、サブノードが表示されます。

図 1–9 BatchSCP OTD の構造

BatchSCP OTD の構造

BatchSCP OTD のノードの機能

次のリストは、BatchSCP OTD の各ノードについて、主要機能などを説明しています。

BatchSCP: OTD のルートノードを表します。

Configuration ノード

Configuration ノードの下にある BatchSCP のサブノードは、BatchSCP アダプタの接続マップ設定パラメータおよび環境設定パラメータに対応します (次の図を参照)。

BatchSCP の Client ノード

BatchSCP OTD の Client ノードには、次のメソッドが含まれます。

BatchLocalFile OTD

BatchLocalFile OTD は、ローカルシステム上のファイルへのアクセスを提供します。Sun Enterprise Service Bus では、ファイルアクセスは必ずしも必要ではありませんが、ファイル処理はバッチアダプタの中核機能の 1 つであるため、バッチアダプタにはファイルアクセス機能が備わっています。

その他に BatchLocalFile の機能として、ファイルにアクセスするための正規表現、ファイルを作成するためのシーケンス番号付け方法などがあります。

BatchLocalFile OTD の構造

BatchLocalFile OTD には、Client、Configuration、PersistentState、および State Manager という 4 つの上位レベルノードが含まれます (次の図を参照)。これらのノードを展開すると、サブノードが表示されます。

図 1–10 BatchLocalFile OTD の構造

BatchLocalFile OTD の構造

Configuration ノード

各 Batch OTD と同様に、BatchLocalFile OTD の Configuration ノードの下にある各フィールドサブノードは、この OTD のアダプタの設定パラメータのいずれかに対応します。詳細は、BatchLocalFile の接続マッププロパティーを参照してください。

Client ノード

この OTD には、さらに上位レベルノード、Client が含まれます。このノードは、アダプタの各機能インタフェースを実装します。

クライアントインタフェースは、OTD の機能が実際に使用される方法です。この機能には、OTD の基本的な処理および機能が含まれます。クライアントインタフェースは、OTD のファイルサービスを提供します。

BatchLocalFile OTD のノードの機能

次のリストは、BatchLocalFile OTD のノードについて、主要機能などを説明しています。

BatchLocalFile OTD の使用法

このセクションでは、BatchLocalFile OTD の機能を使用する方法を説明します。

BatchLocalFile OTD で実行できる呼び出しは、特定の順序である必要はありません。ただし、1 つのコラボレーションルールの実行で複数の転送を行う場合、1 つの転送が終了するごとに reset() を呼び出す必要があります。複数のファイルを転送する動的なバッチ順はこのケースに当てはまります。

Java コラボレーションを使用して、BatchLocalFile インタフェースを使用しながらシーケンス番号を持つ複数のファイルを生成している場合は、reset() メソッドを呼び出して、1 つのファイルの終わりと、次のファイルの開始を示してください。

BatchLocalFile 固有の機能

BatchLocalFile OTD を使用してローカルファイルからレコードを読み取ることには、次の利点があります。

ファイル転送前/転送後コマンド

アダプタには、実際のファイル転送の直前または直後にアクションを実行できる機能があります。これらの設定をアダプタの設定パラメータ、または対象の OTD の Configuration ノードに入力できます。

これらの機能は、BatchLocalFile OTD と BatchFTP OTD の両方で使用できます。

転送前コマンド

インバウンド転送の場合、ターゲットシステムをポーリングしている他のクライアントに対して、同じディレクトリおよびファイルパターンまたは名前でファイルを使用できないようにすることができます (Rename)。アウトバウンド転送の場合、既存のファイルの自動バックアップを作成できます (Copy)。

次の転送前オプションがあります。

適切に保護、バックアップ、または復旧を行うには、目的にかなった適切な設定を選択します。たとえば、アウトバウンドの追加転送での失敗から復旧する場合は、Copy 設定を使用します。ファイル名およびディレクトリ名を指定するときに、正規表現、特殊文字のいずれか、または両方を使用できます。

転送後コマンド

インバウンド転送の場合、自動バックアップを作成することで、転送済みファイルを「消費済み」として指定したり (Rename)、永久に破棄したり (Delete) することができます。アウトバウンド転送の場合、転送済みファイルの名前を変更することで、そのファイルを他のクライアントで使用できるようにすることができます。ファイル名およびディレクトリ名を指定するときに、正規表現、特殊文字のいずれか、または両方を使用できます。

次の転送後オプションがあります。

転送前コマンドおよび転送後コマンドの詳細は、次を参照してください。

BatchFTP OTD

BatchLocalFile OTD

基本的な BatchLocalFile OTD メソッド

フィールド要素に加えて、BatchLocalFile OTD の Client ノードには、アダプタのクライアントインタフェース機能を拡張するメソッドが含まれます。これらのメソッドは、OTD の適切な使用に不可欠です。メソッドは次のとおりです。

読み取りの再開機能

この機能の目的は、アプリケーションで、大規模ファイル全体を 1 度に処理するのではなく、分けて読み取れるようにすることです。読み取りの再開を使用すると、データストリーミングを使用しているときに、システムにおいてファイルを後続の複数のビジネスルールの実行で読み取ることができます。

全体の処理

読み取りの再開機能の処理は、現在の成功したファイル読み取り処理、ブレークについての持続的な情報を維持し、最後に格納されたブレーク位置から次の読み取り処理を再開することで実現されます。その結果、現在のファイルは分けて読み取られ、各部分の開始および終了は、定義済みのブレーク条件によって判断されます。

ブレーク条件は、ビジネスルールの定義を通じて決定します。読み取りの再開機能は、1 つのビジネスルールで 1 度にファイルの一部分を読み取ることを基本として動作するため、これらのルールでブレークを決定します。各ビジネスルールは、ファイルの一部分の読み取りを実行し、ブレークして、次のルールに移動します。次のルールは、次の部分をブレークまで読み取り、以降、ファイル全体が読み取られるまで続けられます。

ブレーク条件は、コラボレーションルールで決定する、任意の種類の停止ポイントにすることができます。たとえば、この条件は、一定数のレコードにしたり、区切り記号にしたり、または特定の文字列に到達したときにしたりできます。

OTD の Client ノードには読み取り専用のプロパティー (ResumeReadingInProgress ノード) があり、進行中の読み取りの再開処理があるかどうかを示します。このノードは、情報提供のみを目的としています。また、読み取りの再開機能は、データストリーミングモードでのみ使用できます。

この機能には、アダプタの設定オプションを設定するほかには、特別な処理上の要件はありません。アダプタ設定には、この機能を有効または無効にするオプションがあります。このオプションには、実行時にもアクセスできます。

注 –

この機能を有効にすると、アダプタは、常に、進行中の読み取りの再開処理があるかどうかを最初に確認します。この機能が進行中でない場合、アダプタは、アダプタの設定に基づいて次のファイルを判断します。

段階ごとの処理

図 1–11 は、読み取りの再開機能がファイルの転送前/転送後コマンドと同調して処理を実行する方法を示しています。この例では、コラボレーションは、同じビジネスルールを 4 回実行します。ビジネスルールが実行されるごとに、コラボレーションはファイルの別のセクションを読み取ります。コラボレーションは、最後のレコードを読み取ると、転送後コマンドを実行します。

図 1–11 読み取りの再開処理

読み取りの再開処理

この例では、読み取りは次の段階で起こります。

  1. アダプタは、ファイルの読み取りを開始し、データを部分的に読み取った後 (パート 1 の終わり) でブレーク条件に達します。アダプタの転送前コマンドはすでに実行されています。読み取りの再開状態が格納され、転送後コマンドは実行されません。アダプタは、ビジネスルールの次の実行を待機します。

  2. 読み取りの再開処理は進行中ですが、データの部分的な読み取りを達成しただけです。アダプタは、1 つのブレーク条件から次のブレーク条件までを読み取ります (図のパート 2 とパート 3)。それぞれのケースで読み取りの再開状態が格納され、アダプタは、1 部分読み取るごとに 1 回ビジネスルールを実行します。

  3. 読み取りの再開処理は進行中で、ビジネスルールの最後の実行時にデータの読み取りを完了します (パート 4)。アダプタは、ブレーク条件からファイルの末尾までを読み取ります。読み取りの再開状態は格納されず、次にすべての転送後コマンドが実行されます。

前のすべての段階で、ビジネスルールは繰り返し実行され、ファイルの現在の読み取り位置は、実行ごとに変化します。ファイルが図のパート 1 よりも小さい場合、アダプタはブレーク条件に達しません。通常の処理が行われ、読み取りの再開状態は格納されません。転送前コマンドおよび転送後コマンドが実行されます。

読み取りの再開を無効にした場合の処理

読み取りの再開機能を無効にすると、次のようになります。

読み取りの再開状態を格納しない

読み取りの再開機能が有効になっていても、部分的なデータストリームの読み取りが必要な場合があります。たとえば、レコードパーサーの上位になんらかのアプリケーションロジックがあり、このロジックが、破壊されたレコードがあるためにファイルの残りを放棄して、ファイルの内容を一部だけ読み取った後にファイルを正常に閉じることがあります。

この場合、finish() を呼び出す前に、LocalFileOTD.Configuration.ResumeReading ノードを False に設定します。この設定は、BatchLocalFile OTD に対して、読み取りの再開状態を格納せずに処理を完了するように指示します。必要に応じて、この後に通知を送信したり、他の処理を実行するようにコラボレーションルールを設定できます。

データストリームアダプタプロバイダ

BatchLocalFile OTD を使用して、アダプタのデータストリーミング機能を実装できます。この機能は、FTP OTD およびレコード処理 OTD にも備わっています。ただし、BatchLocalFile OTD はデータストリームアダプタプロバイダである一方、他の 2 つの OTD はコンシューマに過ぎません。OTD のデータストリーミング機能の使用方法については、「コンポーネント間でのデータのストリーミング」セクションを参照してください。

シーケンス番号付け

BatchLocalFile OTD のシーケンス番号付けは、BatchFTP OTD のシーケンス番号付けと同様に動作します。詳細は、「シーケンス番号付け」を参照してください。

シーケンス番号付けを使用した複数ファイルの生成

Java コラボレーションを使用して、BatchLocalFile インタフェースを使用しながらシーケンス番号を持つ複数のファイルを生成している場合は、reset() を呼び出して、1 つのファイルの終わりと、次のファイルの開始を示してください。

型変換の処理

この OTD のこの機能は、BatchFTP OTD の型変換と同様に動作します。詳細は、「型変換の処理」を参照してください。

推奨する運用

コラボレーションにおいてレコードを解析したり、ペイロードを構築するには、レコードを処理する 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 のようにです。

BatchRecord OTD

バッチアダプタのレコード処理 OTD である BatchRecord を使用すると、受信ペイロード (ペイロードデータ) からレコードを解析 (抽出) したり、レコードから構成される送信ペイロードを作成したりできます。この OTD の処理と使用方法の理解のために、いくつかの用語を説明します。

ここでペイロードという用語は、インメモリーバッファーを指します。つまり、バイトシーケンスまたはストリームです。また、このコンテキストでのレコードとは、データベースの場合のレコードとは異なります。レコードとは、単に、固定長や区切りレコードなど、既知の単純な構造を持つバイトシーケンスを意味します。

たとえば、この OTD では次の各レコードタイプを解析または作成できます。

レコード処理 OTD は、次の形式のレコードを処理できます。

DBCS データに文字区切りを使用する場合は、単一バイト文字を使用するか、または 2 バイト文字のいずれのバイトとも一致しない 16 進値を持つ同等な 16 進値を使用します。

BatchRecord OTD の構造

BatchRecord OTD には、Client、Configuration、PersistentState、および StateManager という 4 つの上位レベルノードが含まれます (次の図を参照)。これらのノードを展開すると、サブノードが表示されます。

図 1–12 BatchRecord OTD の構造

BatchRecord OTD の構造

OTD の構造と処理

OTD の Configuration ノードの下の各フィールドノードは、アダプタのレコード処理設定パラメータのいずれかに対応します。

レコード処理 OTD ノードの機能

次のリストは、レコード処理 OTD のこれらの主要ノードについて、その機能などを説明しています。

レコード処理 OTD の使用法

この OTD には次の基本的な使用法があります。

OTD の単一のインスタンスは、同じコラボレーション内で同時に両方の目的に使用するようになっていません。この制限を強制するには、アダプタの「一般設定」パラメータの下に「解析または作成モード」と呼ばれる設定があります。この設定で「解析」または「作成」のいずれかを選択できます。

get() および put() の使用法

get() および put() メソッドは、この OTD の機能の中核です。いずれかのメソッドを呼び出すと、取得または追加するレコードは、固定長または区切りなど、アダプタの設定で指定されたタイプであると見なされます。

get() メソッドは例外をスローできますが、この動作は、通常、重大な失敗がある場合のみ起こります。ペイロードデータ (またはストリーミングしている場合はストリーム) が設定される前に get() を呼び出そうとすることは、こうした失敗の一例です。get() 呼び出しからの戻り値を確認するようにコラボレーションをコーディングすることをお勧めします。戻り値 true は取得処理が成功したことを意味し、false は失敗を意味します。

「解析または作成モード」の選択

アダプタは、モード設定に従って、適切な呼び出しが行われているかどうかを確認します。たとえば、解析モード環境で put() を呼び出すと、アダプタは、原因を説明する該当エラーメッセージを添えて、例外をスローします。作成モードで get() を呼び出してもエラーになります。

アダプタがこうした制限を必要とするのは、次の理由からです。

このため、OTD は、特定のコラボレーションの転送元側または転送先側に必要に応じて配置し、OTD をペイロードの解析または作成に使用します。しかし、同時に解析と作成を行うことはできません。OTD をコラボレーションに実装するには、コラボレーションルールエディタを使用します。

ペイロードの作成

ペイロードデータを外部システムに送信する場合は、そのシステムとインタフェースをとっているコラボレーションのアウトバウンド側に OTD を配置できます。連続して put() を呼び出すと、アダプタ設定で定義した形式でペイロードデータが構築されます。

すべてのレコードがペイロードに追加されたら、コラボレーションのアウトバウンドの転送先を表すノード (複数可) にペイロードをドラッグ＆ドロップできます。また、ペイロードの転送先として出力ストリームを設定できます (ペイロードのストリーミングの詳細は、表 1–3 を参照)。

データペイロードを構築するときは、送信するデータのタイプと形式を考慮します。アダプタでは、次の形式を使用できます。

ペイロードの解析

外部システムからのインバウンドのペイロードデータを表すには、(コラボレーションルールエディタから) OTD のペイロードノードにデータをマップします。また、入力ストリームを転送元として指定することもできます。

いずれの場合も、連続して get() を呼び出すごとに、ペイロードから次のレコードが抽出されます。抽出されるレコードのタイプは、固定サイズ、区切りなどのアダプタの設定で設定したパラメータによって決まります。

解析コラボレーションは、抽出した各レコードに対する処理を含めて設計します。通常、レコードを別のコラボレーションに送り、そこにあるカスタム OTD がレコード形式を記述し、さらに処理を実行するという方法がとられます。

ペイロードの完全な消費

ペイロードは完全に消費することができます。つまり、get() を連続して何度も呼び出すと、ペイロード内のすべてのレコードを取得できます。この時点で連続して get() を呼び出すと、ブール型の false が返されます。サブジェクトコラボレーションのビジネスルールは、この可能性を考慮に入れて設計します。

データストリーミングでのレコード処理の使用法

データストリーミングでレコード処理 OTD を使用している場合は、出力ファイルを上書きしないように注意してください。OTD が、同じ出力ファイル名を使用する BatchLocalFile OTD に絶えずストリーミングしている場合、OTD は出力側のファイルを上書きすることがあります。

この問題を回避するためには、ファイルのシーケンス番号付けを使用するか、またはコラボレーションルールの出力ファイル名を変更します。シーケンス番号付けを使用すると、BatchLocalFile OTD は、個々のファイルにシーケンス番号を追加することでそれぞれを区別します。ターゲットファイル名と転送後ファイル名のいずれか、または両方を使用すると、出力ファイルの名前を別のファイル名に変更できます。

これらの機能の使用法については、「シーケンス番号付け」および「ファイル転送前/転送後コマンド」を参照してください。

BatchInbound OTD

BatchInbound 入力 (トリガー) ファイルアダプタは、入力ファイルをポーリングし、ファイルの名前を GUID プレフィックスで変更して、ビジネスプロセスまたはコラボレーションをトリガーします。

バッチアダプタの BatchInbound OTD は、入力ディレクトリでインバウンドターゲットファイルを定期的にポーリングする点で、インバウンドのファイルアダプタと同様に機能します。ただし、ファイルアダプタと異なり、BatchInbound アダプタによって該当する名前のファイルが受信されると、ターゲットファイルの名前は GUID.original_filename のパターンに変更されます。これは、ファイルの上書きを防ぎ、送信を 1 回のみにすることを目的としています。GUID (Globally Unique Identifier) は、128 ビットの値を表す、一意のフォーマットされた文字列を提供します。

BatchInbound OTD は、ファイルを読み取りません。ビジネスプロセスまたはコラボレーションをトリガーするファイルの名前を提供するようにファイルの名前を変更します。

BatchInbound OTD の構造

BatchInbound OTD には、BatchAppconnMessage という 1 つの上位レベルノードが含まれ、そこには PathDirName、OriginalFileName、および GUIDFileName という 3 つのフィールドが含まれます (次の図を参照)。これらのノードは、外部入力ディレクトリ、元のファイル名、および GUID ファイル名を提供します。

図 1–13 BatchInbound OTD の構造

BatchInbound OTD の構造

バッチアダプタでの正規表現の使用法

正規表現とは文字列で、その中に含まれる一部の文字が照合パターンに関する特別な意味を持ちます。このセクションでは、HTTPS で正規表現を使用する方法に関する基本的なガイドラインを示します。

正規表現: 概要

正規表現を使用すると、ファイル名およびディレクトリ名に対するパターンを指定できます。正規表現は「取得」処理 (受信、つまり転送元) に使用するのに対し、名前パターンは「出力」処理 (送信、つまり転送先) に使用します。

BatchFTP、Batch FTPOverSSL、BatchSFTP、BatchLocalFile、および BatchInbound の各 OTD では、正規表現を使用できます。たとえば、特定の拡張子を持つすべてのファイルにアクセスできます。

正規表現は次のように機能します。

正規表現の入力

FTP またはローカルファイル名の正規表現は、さまざまな方法で入力できます。たとえば、*\.dat$ や ^xyz.*\.dat$ などです。最初の例は、拡張子 .dat を持つすべてのファイルを示します。2 番目の例は、拡張子が .dat で名前が xyz で始まるすべてのファイル名を示します。

もう 1 つの例として、file[0-9]\.dat も可能です。この表現は、file0.dat、file1.dat、file2.dat などから file9.dat までを指定します。また、これは xyz.file0.dat、xyz.file1.dat などに一致します。このタイプの表現は、「file」の前の一切を除外しません。「file」の前のすべての文字を除外するには (「file」から始まることを条件とするには) ^file[0-9].dat または \Afile[0-9].dat を使用します。

これらのタイプの正規表現パターンを取得処理に使用できます。

正規表現とアダプタ

アダプタには、各プロパティーの後に正規表現をオプションとして許可する File Name Is Pattern または Directory Name Is Pattern 設定パラメータが備わっています。この機能を使用して、入力したパターンが正規表現か、またはリテラルに解釈する静的なテキストエントリかどうかを指定できます。

注 –

正規表現は、ファイル名に対する部分一致でも解決します。この解決処理は、ファイル名ではなくファイル名の内容を検索します。

ディレクトリの正規表現のルール

ディレクトリ名に正規表現を使用する場合は、特別な考慮が必要です。このセクションでは、これらの制限を説明し、例をいくつか示します。

ディレクトリ名として正規表現を使用する場合の制限

ディレクトリ名として正規表現を使用する場合、次の制限が適用されます。

正規表現されたディレクトリ名の例

次に、正規表現されたディレクトリ名の例をいくつか示します。

バッチアダプタでの名前パターンの使用法

バッチアダプタでは、よく使用する情報を省略表現として表す特殊文字である、名前パターンを使用できます。これらの文字の組み合わせを使用して、この特定の情報のプレースホルダを指定できます。これらの文字を使用して、日付/時刻、数値、およびファイル名情報を迅速に伝達できます。

BatchFTP、Batch FTPOverSSL、BatchSFTP、BatchLocalFile、および BatchInbound の各 OTD では、特殊文字の使用、つまり名前パターンの指定が許可されています。名前パターンを使用すると、ファイル名およびディレクトリ名のパターンを指定できます。名前パターンは「出力」処理 (送信、つまり転送先) に使用するのに対し、正規表現は「取得」処理 (受信、つまり転送元) に使用します。

特殊文字は、アダプタがファイル名パターンに使用するユーティリティーです。その使用に関する全般的なルールは、次のとおりです。

たとえば、出力処理で、file%#.dat のようなパターンを使用できます。このパターンは、設定のシーケンス番号設定を使用し、出力処理のたびに、file1.dat、file2.dat といった名前が付いた連続したファイルが作成されます。

正規表現については、「バッチアダプタでの正規表現の使用法」を参照してください。

名前パターンのタイプ

アダプタには、次のタイプの名前パターンが備わっています。

展開処理の順序は、前のリストと逆順です。つまり、最初にファイル名、次にシーケンス番号、最後にタイムスタンプが展開されます。

名前パターンの例をさらにいくつか示します。

名前の解決

通常、名前パターンまたは正規表現を使用した転送前/転送後名は、get() および put() メソッドの呼び出し時に解決されます。しかし、コラボレーションルールを使用するときに、アダプタが、実際の get() または put() 呼び出しの前に、解決された名前を取得しなければならない場合があります。

こうした場合、BatchFTP OTD の ResolvedNamesForGet および ResolvedNamesForPut ノードを使用して、前述のように解決された名前を取得できます。たとえば、次のようにです。

getResolvedNamesForPut().getTargetFileName()

前のコードは、パターン file%# に基づいて file1 になります。この使用法では、OTD ノードは、目的のメソッドを呼び出すために使用できます。

日付/時刻形式の構文

アダプタは、Java の単純なデフォルトの日付および時刻形式構文 (米国ロケール) を使用します。これらの形式を名前パターンに指定するには、時刻パターン文字列を使用します。

注 –

アダプタは、Java クラス java.text.SimpleDateFormat の Java 標準日付/タイムスタンプを使用します。これらの形式の一部は、使用中の Java SDK バージョンによっては、次に示すリストと異なることがあります。

これらのパターンでは、すべての ASCII 文字はパターン文字として予約されています。完全なリストについては、表 1–2 を参照してください。

表 1–2 時刻パターン文字列と意味

シンボル 

意味 

表現 

例 

%G 

年号指示子 

テキスト 

AD 

%y 

年 

数 

1996 

%M 

月 (年) 

テキストおよび数 

July & 07 

%d 

日 (月) 

数 

10 

%h 

時間 (午前/午後) (1 - 12) 

数 

12 

%H 

時 (日) (0 - 23) 

数 

0 

%m 

分 (時) 

数 

30 

%s 

秒 (分) 

数 

55 

%S 

ミリ秒 

数 

978 

%E 

曜日 (週) 

テキスト 

火曜日 

%D 

日 (年) 

数 

189 

%F 

曜日 (月) 

数 

2 (7 月の第 2 水曜日) 

%w 

週 (年) 

数 

27 

%W 

週 (月) 

数 

2 

%a 

午前/午後記号 

テキスト 

PM 

%k 

時間 (日) (1 - 24) 

数 

24 

%K 

時間 (午前/午後) (0 - 11) 

数 

0 

%z 

タイムゾーン 

テキスト 

太平洋標準時 

日付/時刻形式の全般的なルールは、次のとおりです。

表 1–3 米国ロケールの日付/時刻パターン

形式パターン 

結果 

yyyy.MM.dd, G, ’at’ hh:mm:ss, z 

1996.07.10 AD at 15:08:56 PDT 

E, M, dd, ’’yy 

Wednesday, July 10, ’96 

h:mm, a 

12:08 PM 

h, ’o’’clock’ a, z 

12 o’clock PM., Pacific Daylight Time 

K:mm a, z 

0:00 p.m., PST 

yyyyy.M.dd, G, hh:mm, a 

1996.July.10 AD 12:08 PM