test

通信アダプタ用 OTD の開発

第 1 章 通信アダプタ用 OTD の開発

以降のセクションでは、通信アダプタ用 OTD の開発方法について説明します。次のタスクおよび参照情報を扱っています。

HTTPS OTD について

HTTPS クライアント OTD

HTTPS OTD は、HTTPSAdapter に固有の OTD です。コラボレーションでインバウンド OTD またはアウトバウンド OTD として使用されます。

OTD は、メソッドおよびプロパティーを含むフィールドから構成されるツリー状の階層データ構造になっています。

OTD の最上位ルート要素は HTTPClientApplication インタフェースで、その下のフィールドには Java メソッドが含まれます。これらの Java メソッドを使用すると、HTTP メッセージ形式を指定して、HTTP サーバーとの間でメッセージングを起動するビジネスルールを作成できます。

他の Java クラスおよびメソッドにアクセスするには、コラボレーションエディタ (Java) を使用すると、HTTPClientApplication で使用可能なコンテンツ全体を活用できます。

HTTP OTD メソッドの説明

HTTP OTD には、HTTP データ交換で使用される次のメソッドが含まれます。

get

コラボレーション (Java) で HTTP get 要求を HTTP サーバーに送信するために呼び出されるメソッド。

post

コラボレーション (Java) で HTTP post 要求を HTTP サーバーに送信するために呼び出されるメソッド。

getRequest

コラボレーション (Java) で、URL の設定、プロパティーの追加など、ヘルパーメソッドに関連する他の「要求」のために呼び出されるメソッド。

getResult

コラボレーション (Java) で、応答コード、応答結果、テキスト結果の取得など、ヘルパーメソッドに関連する他の「応答」のために呼び出されるメソッド。

HTTP OTD で使用可能なメソッドの詳細は、HTTPSAdapter の Javadoc を参照してください。

HTTPS サーバー OTD

HTTPS サーバー入力 OTD には、Request と Response という 2 つのノードがあります。Request ノードには HTTPS サーバーアダプタが HTTP クライアントから受信するデータが含まれ、Response ノードは HTTP クライアントに送り返す HTTP 応答データを設定するために使用されます。

図 1–1 入力サーバーの OTD

入力サーバーの OTD

図 1–2 入力サーバーの Request ノード

入力サーバーの Request ノード

図 1–3 入力サーバーの Response ノード

入力サーバーの Response ノード

サーバー OTD の操作

OTD の Request ノードおよび Response ノードを使用して、HTTPS コラボレーションでロジックを構築します。HTTP サーバーの入力 OTD でsendResponse() メソッドが呼び出されるまで、HTTP 応答は HTTP クライアントに送り返されません。

図 1–4 sendResponse() メソッド

sendResponse() メソッド

応答をクライアントに送り返すには、このメソッドを使用することが重要です。このメソッドを使用しないと、クライアントは応答をいつまでも待ち続けます。HTTP では、有効なアプリケーション応答であれ、アプリケーションのエラー応答であれ、応答がクライアントに送信されることが必要です。

コラボレーションの例

次の例は、Request ノードから Method プロパティーを介して HTTP メソッドを取得し、要求から取得された HTTP メソッドを示す HTML 応答を作成し、Response ノードで ContentType プロパティーを「text/html」として設定し、Text プロパティーに HTML 応答を設定してから、構築した応答を HTTP クライアントに送信するために HTTP サーバーの入力 OTD 応答で sendResponse() メソッドを呼び出す簡単な Java コラボレーションを示しています。

図 1–5 sendResponse() の例

sendResponse() の例

バッチアダプタ 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 

新規 COM/DCOM OTD の作成

COM OTD ウィザードは、COM オートメーション互換コンポーネントの型ライブラリファイルから OTD を生成します。COM 型ライブラリファイルは、オートメーション互換コンポーネントから公開されるメソッドおよびプロパティーを記述します。COM 型ライブラリは、ファイル拡張子 .tlb または .olb を持つことがありますが、ほとんどのコンポーネントは、通常、コンポーネントを含む DLL、OCX、または EXE ファイルに型ライブラリファイルを組み込んでいます。

ProcedureCOM OTD を作成する

  1. プロジェクトエクスプローラツリーでプロジェクトを右クリックし、ショートカットメニューから「新規」 > 「オブジェクト型定義」を選択します。

  2. 新規オブジェクト型定義ウィザードの「ウィザードタイプの選択」ウィンドウで、COM ウィザードを選択し、「次へ」をクリックします (次の図を参照)。

    Com OTD ウィザード 1

  3. OTD を作成する基になる型ライブラリファイルを含むディレクトリを参照します。1 度に選択できる型ライブラリファイルは 1 つのみです。型ライブラリファイルを選択し、「選択」ボタンをクリックして (次の図を参照)、「次へ」をクリックします。

    COM OTD ウィザード 2

  4. 型ライブラリから 1 つまたは複数のCoClass を選択して、「次へ」をクリックします (次の図を参照)。

    COM OTD ウィザード 3

  5. 「OTD 名」フィールドに新規 OTD の名前を入力し、「完了」をクリックします (次の図を参照)。

    COM OTD ウィザード 4

    選択した CoClass のいずれかにサポートされていないデータ型のメソッドが含まれる場合、「情報」ボックスが表示されます。

    「情報」ボックスには、OTD にいくつかのメソッドが作成されなかったことと、生成された「スキップされたメソッド」ログの場所が示されます。このログは、OTD の作成時にスキップされたメソッドのレポートです (この情報は、IDE ログファイルにも書き込まれる)。この情報ボックスが表示された場合は、「了解」をクリックして確認し、「情報」ボックスを閉じます。

    OTD エディタが表示され、新しい OTD が表示されます (次の図を参照)。

    COM OTD ウィザード 5

    作成された OTD をコラボレーションで使用できるようになりました。

    OTD エディタの使用法については、『Sun Enterprise Service Bus』を参照してください。

OTD の再起動

1 つの OTD が何行ものメタデータで構成されることがあります。OTD 内のメタデータに変更が生じた場合、最初から作り直す必要はありません。再起動機能を使用すると、OTD を同じ名前で再構築して保存し、同じ Java コラボレーションルールまたは BPEL に再起動することができます。

Procedure既存の OTD を再起動する

  1. エンタープライズエクスプローラで、OTD を右クリックします。サブメニューから、「再起動」をクリックします。ファイルの選択ウィザードが開きます。

  2. 再起動する「ファイル名」を入力 (または「参照」して「選択」) して、「次へ」をクリックします。

  3. OTD を作成するときと同様にウィザードを続けます。

  4. 「完了」ボタンをクリックして、変更を保存します。

    OTD を再起動するとき、次の場合は既存のコラボレーションは影響を受けません。

    • 新規列が追加された場合

    • 削除された列が元のコラボレーションで使用されていなかった場合

      注 –

      列の名前を変更または削除した場合に、既存のコラボレーションを変更しないと、検証は失敗します。

ファイルアダプタコンポーネント

ファイルアダプタは、Sun JavaTM Composite Application Platform Suite およびアダプタ Intelligent Adapter に付属するほとんどのサンプルプロジェクトで使用されます。ファイルアダプタには、このアダプタに固有の次のコンポーネントが含まれます。

ファイル OTD の処理

次のファイルアダプタ OTD の属性、つまり処理は、BPEL プロジェクトと JCD プロジェクトの両方で使用されます。

write (出力) ビジネスプロセス処理には、着信するエラー例外メッセージを受信および処理するための、追加の入力機能があります。

HL7 OTD の操作

OTD エディタは、選択されたオブジェクト型定義 (OTD) の構造を表示します。また、組み込み型のテスターでその処理を確認できます。エディタを使用して OTD の作成および変更を行うこともできます。オブジェクト型定義、OTD の構造、および OTD エディタの概要については、『Sun Enterprise Service Bus ユーザーガイド』を参照してください。その中では、使用可能なすべての OTD プロパティーを定義し、OTD エディタのすべての機能を説明しています。

次のセクションでは、OTD エディタでライブラリ OTD を使用する場合に固有の情報について説明します。これらの OTD は、業界固有のデータ交換システムおよびオープンソース標準で使用されるメッセージタイプに対応するテンプレートです。テンプレートは事前に定義されており、そのまま使用できるほか、OTD エディタを使用して変更することもできます。

OTD エディタを使用した OTD の表示

OTD エディタは、選択されたオブジェクト型定義 (OTD) の構造を表示します。また、組み込み型のテスターでその処理を確認できます。エディタを使用して、ユーザー定義の OTD を作成および変更することもできます。

ProcedureOTD を表示する

OTD エディタを使用して HL7 汎用 OTD または HL7 ライブラリ OTD (HL7 アダプタを Sun HL7 OTD ライブラリと組み合わせて使用している場合) を表示するには、次の手順に従います。

  1. Java CAPS のプロジェクトツリーで、Sun OTD ライブラリディレクトリ、HL7 ディレクトリ、該当する HL7 ライブラリバージョンのフォルダの順に展開します。ビルドにはインストールしたバージョンのみが表示されます。

  2. プロジェクトエディタの OTD ライブラリにある使用可能な OTD は保護されています (読み取り専用)。現在の場所で OTD をダブルクリックすることで、OTD を「読み取り専用」モードで表示できます。

ProcedureOTD をプロジェクトにコピーする

  1. OTD を編集可能モードで表示するには、OTD をプロジェクトにコピー＆ペーストします。OTD を右クリックし、ショートカットメニューから「コピー」を選択して、次にプロジェクトを右クリックし、ショートカットメニューから「ペースト」を選択します。OTD がプロジェクトエクスプローラツリーのプロジェクトに追加されます。

  2. コピーされた OTD を表示するには、コピーされた OTD をダブルクリックします。編集可能な OTD が OTD エディタに表示されます。ライブラリ OTD の場合、OTD セグメントは引き続き書き込み保護されています。この時点で、OTD プロパティーは、ルートノードからのみ変更できます (次の図を参照)。

    OTD エディタ - HL7_25_ADT_A01

  3. エディタの「オブジェクト型定義」区画で、任意の OTD ノードまたはサブノードを選択すると、エディタの「プロパティー」区画にノードのプロパティーが表示されます。

    オブジェクト型定義、OTD の構造、および OTD エディタの概要については、『Sun Enterprise Service Bus ユーザーガイド』を参照してください。

OTD エディタを使用した OTD の変更

OTD のチェックアウトとチェックイン

汎用 HL7 OTDS (HL7 OTD ライブラリからインストールされる OTD) は、Project Explorer の Sun フォルダにあります。これらの OTD は保護されており、変更できません。これにより、元の OTD を常に元の形で使用できます。OTD を変更するには、まず OTD を「Sun」 > 「OTD ライブラリ」フォルダからプロジェクトにコピー＆ペーストします。

プロジェクトに保存したすべての OTD のバージョンを管理できます。OTD をチェックインまたはチェックアウトするには、プロジェクトエクスプローラツリーで OTD を右クリックし、ショートカットメニューから「バージョン管理」 > 「チェックアウト」または「チェックイン」を選択します。OTD がチェックインされると、プロジェクトエクスプローラツリーに OTD ファイルアイコンが「ロック」として表示されます (アイコンに赤い南京錠が含まれる)。

OTD のルートプロパティーの編集

プロジェクトにコピーした HL7 OTD は、ルートノードからのみ編集できます。OTD の各セグメントは書き込み保護されています。OTD セグメントは、OTD エディタの「参照」区画で見ることができます。この「参照」区画には、OTD ファイルの内部テンプレートおよび外部テンプレートが含まれます。ライブラリ OTD の特定のセグメントを編集する方法は、「OTD セグメントの追加および編集」を参照してください。OTD プロパティーの詳細は、「OTD プロパティー」を参照してください。

ルートノードのプロパティー

次の表に、ルートノードに関連付けられた一連のプロパティーを示します。

ノードプロパティーの説明 

name 

ノードの表示名。これは、事実上任意の文字列にすることができます。 

javaName 

プロパティーアクセサベース名。これは、通常、表示名から引き出され、Java 識別子に対する制限に適合するように変更されます。Sun Enterprise Service Bus によって自動的に提供されます。 

javaType 

Java 型。自動的に割り当てられ、編集できません。 

comment 

自由形式のテキスト (実行時には無効)。 

delim 

指定された区切り文字。「区切り文字の指定」を参照してください。

nodeType 

マーシャル/アンマーシャルフォーマットを制御します。「ノードタイプの指定」を参照してください。

antecoding 

入力データのコーディングを指定します (219 ページの「データエンコーディングの指定」参照)。このプロパティーを指定しないと、decoding プロパティーに指定した値が入力データに使用されます。このプロパティーは、top プロパティーが true に設定されている場合のみ表示されます。

decoding 

アンマーシャルコーディングを指定します (219 ページの「データエンコーディングの指定」参照)。(DBCS データには UTF-8 を使用することをお勧めします。これは、一部の ASCII 区切り文字の 16 進値が 2 バイト文字に含まれる 16 進値と一致することがあるためです。)このプロパティーは、top プロパティーが true に設定されている場合のみ表示されます。

encoding 

マーシャルコーディングを指定します (219 ページの「データエンコーディングの指定」参照)。このプロパティーは、top プロパティーが true に設定されている場合のみ表示されます。 

order 

アンマーシャルプロセスの間の、選択したノードの子の順序を指定します。 

  • seq: 子ノードを、指定されたメタデータの順序どおりに表示するよう指定します。

  • any: 子ノードを、グループのまま任意の順序で表示できるよう指定します。

  • mix: 子ノードを任意の順序で表示できるよう指定します。

postcoding 

出力データのコーディングを指定します (219 ページの「データエンコーディングの指定」参照)。このプロパティーを指定しないと、encoding プロパティーに指定した値が出力データに使用されます。このプロパティーは、top プロパティーが true に設定されている場合のみ表示されます。

public 

今後の開発用に予約済み 

top 

ルートノードのフラグ: マーシャル/アンマーシャルのサポート (T/F)。 

ルートノードから編集したプロパティーは、OTD に包括的に適用されます。たとえば、ルートノードから変更したレベル 3 の区切り文字は、レベル 3 のすべてのノードの区切り文字に適用されます。特定のセグメントのプロパティーは排他的に編集できますが、このためには、セグメントが参照する特定の OTD をプロジェクトにコピー＆ペーストします。特定のセグメントの編集については、「OTD セグメントの追加および編集」を参照してください。

ProcedureHL7 OTD のルートノードプロパティーを編集する

  1. OTD をプロジェクトにコピー＆ペーストします。OTD がプロジェクトエクスプローラツリーのプロジェクトに追加されます。

  2. OTD をダブルクリックして、OTD エディタでプロジェクトを開きます。

  3. エディタの「オブジェクト型定義」区画で、OTD のルートノードを選択します。エディタの「プロパティー」区画にルートプロパティーが表示されます。

  4. 「プロパティー」区画で、プロパティーを編集する任意のプロパティーフィールドをクリックします。

OTD 区切り文字の編集

すべてのノードレベルの区切り文字は、ルートノードから設定 (および変更) します。デフォルトのレベル 1 の区切り文字は ASCII 以外の文字であることに注意してください。いったん変更すると、文字として入力し直すことはできません (ただし、ペーストは可能)。OTD の特定セグメントの編集については、「OTD セグメントの追加および編集」を参照してください。

Procedureルートノードから区切り文字を編集する

  1. OTD エディタで、「オブジェクト型定義」区画のルートノードを選択します (この例では ADT_A02 とします)。「プロパティー」区画で、delim プロパティーフィールドをダブルクリックします。省略記号 (...) ボタンがフィールドに表示されます。省略記号ボタンをクリックします。区切り文字リストエディタが表示されます (次の図を参照)。

    HL7 OTD エディタ - 区切り文字リストエディタ

  2. OTD エディタの「プロパティー」フィールドでどのレベルのフィールドをダブルクリックしても、そのフィールドは編集可能になるか、またはオプションのリストが表示されます。レベル 3 の「区切り文字バイト」フィールドをダブルクリックします (前の図を参照)。現在の区切り文字をナンバー記号 (#) に変更し、次のフィールドに Tab で移動して、「了解」をクリックします。

    OTD に存在するレベル 3 のすべてのノードの区切り文字がナンバー記号 (#) になります。ただし、特定のセグメントで別途指定されている場合は除きます。次の図は、オブジェクト型定義ツリー内のさまざまなレベルの例をルートノードから示しています。

    ルートノードからのノードレベル

HL7 の標準エンコーディング文字の変更

すべての HL7 OTD には、HL7 標準の定義に従って、区切り文字の定義済みリストがあります。HL7 メッセージ内の区切りエンコーディング文字を変更する場合は、OTD エディタを使用してルートノードから OTD の区切り文字を変更して、HL7 メッセージで使用している区切り文字と一致させます。

区切りエンコーディング文字フィールドは、4 つのエンコーディング文字とフィールド区切り文字から構成される固定長フィールドです。5 番目 (追加) の文字は、セグメントのフィールド区切り文字として必要です。

エンコーディング文字と突き合わせた妥当性検査を行うには、次のように、事前に構築されたコラボレーションルールを変更します。


// first unmarshal the HL7 OTD payload



// then get the encoding character field:

String encodingChars = otdHL7_GENERIC_EVT_1.getMSH().getMsh2EncodingCharacters();



if (!encodingChars.equals(“<customer_encoding_characters>”)) {

validated = false;

ErrorMessage = "Validation Failure: Receiving Facility";

log( LOG_LEVEL_ERROR, "Validate HL7 Message failed: Encoding character field" );

}

区切り文字の指定

ノードは、外部データ表現内の階層化されたデータ構造内で、外部データ表現そのものと、その下位に使用される一連の区切り文字を定義します。ノードで区切り文字リストを定義している場合、上位の区切り文字リストは、このノード自体とその下位に一切影響しません。区切り記号リストは、通常、ルートノードに指定します。

たとえば、次のデータを解析する場合、


a^b|c^d|e

OTD を次のように定義できます。

この OTD の区切り文字リストは、demo-otd 要素で指定するため、OTD 全体に適用され、2 つのレベルを持ちます。

レベル 1

レベル 2

レベル 1 の区切り文字は、2 つの要素およびフィールド 5 に適用され、レベル 2 の区切り文字はフィールド 1 から 4 に適用されます。

区切り文字リストは、この非常に簡単な例よりもずっと複雑になることがあります。たとえば、任意の特定レベルで異なるタイプの区切り文字を複数作成したり、例のようにルートノードでだけでなく、OTD 内の任意のノードで区切り文字リストを指定したりすることができます。区切り文字リストの作成手順については、「OTD エディタを使用した OTD の変更」を参照してください。

区切り文字のプロパティー

区切り文字は、区切り文字リストエディタを使用して定義します。

区切り文字のプロパティーと値を表 1–4 に示します。

表 1–4 区切り文字のプロパティー

区切り文字のプロパティーと値のオプション 

プロパティー 

オプション 

説明 

レベル 

 

定義中のノードの下の子レベル。 

タイプ 

escape 

エスケープシーケンス。 
 

repeat 

配列区切り文字/セパレータ。 
 

normal 

終端文字。 

区切り文字バイト 

 

区切り文字 (単一または複数の文字)。 

優先度 

 

「優先度」を参照してください。 

オプションモード 

never 

入力では許可せず、出力では発行しません (区切り文字間の空のフィールドは、長さゼロのデータフィールドを意味する)。 
 

allow 

空のフィールドが存在する場合はスキップし、存在しない場合、出力では区切りません。 
 

cheer 

空のフィールドが存在する場合はスキップし、存在しない場合、出力では区切ります。 
 

force 

入力では空の区切られたフィールドが必須で、出力では常に区切ります。 

ターミネータモード 

never 

入力では許可せず、出力では発行しません (純粋なセパレータ)。 
 

allow 

入力では許可し、出力では発行しません。 
 

cheer 

入力では許可し、出力では常に発行します。 
 

force 

入力では必須で、出力では常に発行します (純粋な終端文字)。 

タイププロパティー - Escape オプション

escape 区切り文字は、解析時に認識されて無視されるシーケンスです。その目的は、エスケープシーケンスの使用を許可して、データ内にバイトシーケンスを組み込むことで、この存在がないと、区切り文字の出現として見なされます。

たとえば、あるレベルに通常の区切り文字「+」が存在し、エスケープ区切り文字「\+」を定義した場合、aaa+b\+c+dddは 3 つのフィールド、aaa、b\+c、および ddd として解析されます。エスケープ区切り文字を定義しなかった場合、シーケンスは 4 つのフィールド、aaa、b\、c、および ddd として解析されます。

ただし、あるレベルでエスケープ区切り文字が 1 つのみの場合、delim および array ノードでは区切り文字の定義されていない状態を表します。

区切り文字バイト

基本的には、区切り文字として使用できる文字に制限はありません。ただし、データと混同する可能性のある文字や、エスケープシーケンスと衝突する文字は避けてください。バックスラッシュ (\) は通常、エスケープ文字として使用されます。HL7 プロトコルは、エスケープシーケンスの一部に二重のバックスラッシュを使用して特別なテキストフォーマット指示を与えます。

注 –

コロン (:) は区切り文字として使用しないでください。コロンは、システムが生成した時刻文字列でリテラルとして使用されます。これは、ドメインのシャットダウン後などの復旧手順を妨げる可能性があります。

ターミネータモードプロパティー

前の例に示したツリー構造を見てみましょう。この構造では、ノード a はその区切り文字としてパイプ (|) を、サブノード b はその区切り文字としてチルダ (~) を、サブノード c はその区切り文字としてアスタリスク (*) を持っています。

オプション 

入力 

出力 

never 

c|

c|

allow 

c| または c*|

c|

cheer 

c| または c*|

c*|

force 

c*|

c*|

オプションモードプロパティー

次の図に示したツリー構造を見てみましょう。この構造では、ノード a はその区切り文字としてパイプ (|) を、サブノード b、c、および d はいずれもその区切り文字としてアスタリスク (*) を持っています。

オプション 

入力 

出力 

never 

b*d|

b*d|

allow 

b**d|

b*d|

cheer 

b**d|

b**d|

force 

b**d|

b**d|

オプション 

入力 

出力 

never 

b|

b|

allow 

b|、b*|、または b**|

b|

cheer 

b|、b*|、または b**|

b**|

force 

b**|

b**|

優先度

優先度は、ある区切り文字の他の区切り文字に対する優先順位を示します。デフォルトでは、すべての区切り文字の優先度は 10 で、つまり、すべての区切り文字は同様と見なされ、固定フィールドは優先度 10 でハードコードされます。親ノードの区切り文字は、子フィールドの解析時には考慮されず、子の区切り文字 (または子が固定フィールドの場合はその長さ) のみが考慮されます。

区切り文字の優先度を変更すると、入力データストリームに異なる方法で区切り文字が適用されるようになります。次に例を示します。

OTD セグメントの追加および編集

HL7 ライブラリ OTD は、HL7 メッセージセグメントに対応するさまざまな OTD で構成されています。メインの HL7 メッセージ OTD は、同じ HL7 ディレクトリ内にあるセグメント OTD への参照を含んでいます。

セグメントの編集

次の例では、HL7_25_ADT_A02 OTD を使用しています。OTD の特定セグメントのプロパティーを編集するには、次の手順に従います。

  1. 編集する OTD セグメントを決定したら、プロジェクトエクスプローラの「Sun」 > 「OTD ライブラリ」 > 「HL7 フォルダ」からセグメント OTD をプロジェクトにコピー＆ペーストします。

  2. エディタの「オブジェクト型定義」区画に示されているセグメント OTD の順序を書き留めておきます。元の OTD 構造を保つことが重要です。次の手順では、このリストからセグメント OTD を削除します。したがって、元のセグメント OTD の位置を書き留めておき、編集したセグメント OTD を OTD 構造内の元の位置に再配置できるようにすることが重要です (次の図を参照)。

    OTD セグメントの位置

  3. 「参照」区画の「内部」タブで、SFT セグメントを右クリックし、「削除」を選択して、セグメントを削除します。

  4. 「オブジェクト型定義」区画で、OTD ツリーから SFT セグメントを削除します。このためには、セグメントを右クリックし、ショートカットメニューから「削除」を選択します。

  5. 「参照」区画の「外部」タブで、セグメント OTD の参照のうちどれかひとつを削除します。この操作によって、このセグメント OTD に対する他のすべての参照も削除されます。

  6. セグメント OTD をメイン OTD にインポートするには、「OTD を外部テンプレートにインポート」アイコンをクリックします。「インポート」ダイアログボックスが表示されます。

  7. 「インポート」ダイアログボックスで、プロジェクトファイルからインポートする OTD を検出して選択します。「追加」ボタンをクリックして、OTD を「インポートする OTD の選択」フィールドに追加します。「インポート」をクリックします (次の図を参照)。OTD がエディタの「参照」区画の「外部」タブに追加されます。

    OTD セグメントのインポート

  8. 「参照」区画の「外部」タブから、インポートしたセグメントの参照 (この例の場合、HL7_25_SFT/SFT) を「オブジェクト型定義」区画のルートノードにドラッグ＆ドロップします。セグメントがオブジェクト型定義ツリーに追加されます。

  9. オブジェクト型定義ツリーで、セグメントを右クリックし、ショートカットメニューから「上のレベルへ」を選択して、セグメントをツリーの上位へ移動します。この手順を繰り返して、置き換え中のセグメントが存在していたのと同じ位置に新規セグメントが配置されるようにします。

  10. 変更をリポジトリに保存します。

これで、プロジェクトに配置されたセグメント OTD を開き、そのプロパティーを編集できるようになりました。

メッセージ OTD へのセグメント OTD の追加

また、OTD の外部テンプレートにほかのセグメント OTD を追加することで、OTD を変更することもできます。

  1. OTD とインポートするセグメント OTD をプロジェクトにコピーして保存します。OTD エディタで OTD を開きます。

  2. OTD エディタのツールバーで、「OTD を外部テンプレートにインポート」アイコンをクリックします。「インポート」ダイアログボックスが表示されます。

  3. 「インポート」ダイアログボックスで、プロジェクトファイルからインポートする OTD を検出して選択します。「追加」ボタンをクリックして、OTD を「インポートする OTD の選択」フィールドに追加します。「インポート」をクリックします。OTD がエディタの「参照」区画の「外部」タブに追加されます。

  4. 「参照」区画の「外部」タブから、セグメント OTD 参照を「オブジェクト型定義」区画のルートノードにドラッグ＆ドロップします。セグメント OTD がオブジェクト型定義ツリーに追加されます。

  5. 変更をリポジトリに保存します。

OTD プロパティー

OTD エディタの「オブジェクト型定義」区画 (中央の区画) には、OTD のノード、要素、およびフィールドが表示されます。これらのいずれかを選択すると、その項目のプロパティーが「プロパティー」区画に表示されます。

ノードのプロパティー

OTD エディタで HL7 OTD を開くと、ルートノードのプロパティーが「プロパティー」区画に表示されます。設定できるノードのプロパティーを次の表に示します。

ノードプロパティーの説明 

name 

ノードの表示名。これは、事実上任意の文字列にすることができます。 

javaName 

プロパティーアクセサベース名。これは、通常、表示名から引き出され、Java 識別子に対する制限に適合するように変更されます。Sun Enterprise Service Bus によって自動的に提供されます。 

javaType 

Java 型。自動的に割り当てられ、編集できません。 

comment 

自由形式のテキスト (実行時には無効)。 

delim 

指定された区切り文字。「区切り文字の指定」を参照してください。

nodeType 

マーシャル/アンマーシャルフォーマットを制御します。「ノードタイプの指定」を参照してください。

antecoding 

入力データのコーディングを指定します (219 ページの「データエンコーディングの指定」参照)。このプロパティーを指定しないと、decoding プロパティーに指定した値が入力データに使用されます。このプロパティーは、top プロパティーが true に設定されている場合のみ表示されます。

decoding 

アンマーシャルコーディングを指定します (219 ページの「データエンコーディングの指定」参照)。(DBCS データには UTF-8 を使用することをお勧めします。これは、一部の ASCII 区切り文字の 16 進値が 2 バイト文字に含まれる 16 進値と一致することがあるためです。)このプロパティーは、top プロパティーが true に設定されている場合のみ表示されます。

encoding 

マーシャルコーディングを指定します (219 ページの「データエンコーディングの指定」参照)。このプロパティーは、top プロパティーが true に設定されている場合のみ表示されます。 

order 

アンマーシャルプロセスの間の、選択したノードの子の順序を指定します。 

  • seq: 子ノードを、指定されたメタデータの順序どおりに表示するよう指定します。

  • any: 子ノードを、グループのまま任意の順序で表示できるよう指定します。

  • mix: 子ノードを任意の順序で表示できるよう指定します。

postcoding 

出力データのコーディングを指定します (219 ページの「データエンコーディングの指定」参照)。このプロパティーを指定しないと、encoding プロパティーに指定した値が出力データに使用されます。このプロパティーは、top プロパティーが true に設定されている場合のみ表示されます。

public 

今後の開発用に予約済み 

showDelim 

nodeType が区切られている場合。 

top 

ルートノードのフラグ: マーシャル/アンマーシャルのサポート (T/F)。 

注 –

javaName プロパティーは変更しないでください。

要素のプロパティー

次の図に、要素レベルに関連付けられた一連のプロパティーを示します。

図 1–14 OTD エディタ - OTD 要素のプロパティー

OTD エディタ - OTD 要素のプロパティー

設定できる要素のプロパティーを次の表に示します。

要素プロパティーの説明 

name 

要素の表示名。 

javaName 

プロパティーアクセサベース名。 

javaType 

Java 型。自動的に割り当てられ、編集できません。 

comment 

自由形式のテキスト (実行時には無効)。 

access 

アクセス仕様。 

optional 

フラグ: この要素が省略可能かどうか (T/F) ルート、または選択したノードの子には適用されません。 

repeat 

フラグ: このノードは複数回の出現を許可されるかどうか (T/F) ルート、または選択したノードの子には適用されません。 

maxOccurs 

ノードが反復の場合に、ノードの最大出現回数を指定します。ノードが反復でない場合、プロパティーは影響しませんが、値 >1 に設定されている場合、検証時にエラーが表示されることがあります。 

delim 

区切り文字仕様 (「区切り文字の指定」参照)。

nodeType 

マーシャル/アンマーシャルフォーマットを制御します。 

showDelim 

nodeType が区切られている場合。 

Public 

将来の使用向けで、現在はアクティブではありません。 

Top 

マーシャル/アンマーシャルがサポートされているかどうかを指定します (true または false)。デフォルト値は true です。 

注 –

javaName プロパティーは変更しないでください。

フィールドのプロパティー

次の図に、フィールドレベルに関連付けられた一連のプロパティーを示します。

図 1–15 OTD エディタ - OTD フィールドのプロパティー

OTD エディタ - OTD フィールドのプロパティー

設定できるフィールドのプロパティーを次の表に示します。

フィールドプロパティーの説明 

name 

フィールドの表示名。 

javaName 

プロパティーアクセサベース名。 

javaType 

Java 型: java.lang.String またはバイト配列 (byte[]) のいずれか。 

comment 

自由形式のテキスト (実行時には無効)。 

access 

アクセス仕様。 

optional 

フィールドがインスタンスに存在しないことを許可されるかどうかを指定します。「値」フィールドをクリックすると、true と false が切り替わります。フィールドが選択した要素ノードの子である場合は適用されません。 

repeat 

ノードが複数回の出現を許可されるかどうかを指定します。「値」フィールドをクリックすると、true と false が切り替わります。フィールドが選択した要素ノードの子である場合は適用されません。 

maxOccurs 

ノードが反復の場合に、ノードの最大出現回数を指定します。ノードが反復でない場合、プロパティーは影響しませんが、値 >1 に設定されている場合、検証時にエラーが表示されることがあります。 

delim 

区切り文字仕様 (「区切り文字の指定」参照)。

initial 

親ノードの作成時またはリセット時に設定される、フィールドの初期値。指定した場合、ノードにデータが取り込まれる前に、ノードに割り当てられます。 

match 

nodeType が区切られている場合、データに対する完全一致を実行します。

nodeType 

マーシャル/アンマーシャルフォーマットを制御します。 

align 

match プロパティーのバイト整列の基準を指定します。 

decoding 

nodeType が fixed の場合のみ表示されます。アンマーシャルコーディングを指定します(DBCS データには UTF-8 を使用することをお勧めします。これは、一部の ASCII 区切り文字の 16 進値が 2 バイト文字に含まれる 16 進値と一致することがあるためです)。 

encoding 

nodeType が fixed の場合のみ表示されます。マーシャルコーディングを指定します。 

length 

nodeType が fixed の場合のみ表示されます。フィールドの長さを指定します。デフォルト値は 0 です。 

注 –

javaName プロパティーは変更しないでください。

ノードタイプの指定

nodeType プロパティーフィールドをクリックすると、フィールドが編集できるようになります。矢印ボタンをクリックすると、選択メニューが表示されます。プロパティーオプションの説明を次の表に示します。

ノードタイプのプロパティーオプション 

オプション 

説明 

要素 

フィールド 

内部 

array 

array は区切られた構造です。反復される場合、出現は repeat 区切り文字によって区切られます。最後の出現は、normal 区切り文字で終端処理できます。

はい 

はい 

単一またはグループ 

delim 

delim (区切り) 構造。反復される場合、出現は normal 区切り文字によって区切られます。

はい 

はい 

単一またはグループ 

fixed 

fixed は固定長を意味し、負でない整数によって指定されます (また、0 は親ノードデータの終わりを意味します)。 

はい 

はい 

単一またはグループ 

group 

group は、繰り返しなどのために、組織的なグループ化を可能にします。要素のみに適用されます。 

はい 

いいえ 

グループ 

trans 

trans (一時) は、スクラッチパッドフィールドとして、内部ツリーのみに表示されます。外部データ表現には出現せず、子として trans nodeType のみを持つことができます。

はい 

はい 

選択、単一、またはグループ 

注 –

OTD ノードを移動した場合は、そのノードの nodeType をリセットします。

ノードの管理

OTD エディタでは、次の操作が可能です。

これらのコマンドには、ノードのコンテキストメニューからアクセスします。

SNA オブジェクト型定義 (OTD)

他のほとんどのアダプタと異なり、SNA アダプタは OTD ウィザードで構成されていません。OTD ウィザードは、通常、アダプタプロジェクトで使用するコラボレーションの作成を容易にします。OTD ウィザードが使用可能な場合、最小限の機能を提供するためにスケルトンのコラボレーションが作成され、これをアプリケーションのニーズに適合するように変更します。SNA アダプタのように、OTD ウィザードがない場合、コラボレーションは完全にゼロから作成します。

Procedure標準の SNA アダプタ OTD を新規 Java コラボレーションに関連付ける

  1. プロジェクトエクスプローラで、ターゲットのプロジェクトを右クリックします。

  2. 「新規」 > 「コラボレーション定義 (Java)」を選択します。

  3. コラボレーション定義ウィザード (Java)の手順 1 と 2 を完了します。

  4. 「検索」ドロップダウンボックスをたどって、新規コラボレーションで使用する OTD、SeeBeyond.eWays.SNALU62 を選択します。

  5. 目的の OTD 名を強調表示し、「追加」ボタンをクリックします。

  6. 必要に応じて、コラボレーションで使用する OTD のインスタンス名を変更します。

  7. 「完了」ボタンをクリックします。

    SNA アダプタ OTD を実装する新規コラボレーションが作成されます。コラボレーションで使用できる SNA アダプタのメソッドについては、関連する Javadoc を参照してください。