| Oracle® Fusion Middlewareテクノロジ・アダプタの理解 12c (12.2.1) E69958-02 |
|
 前 |
 次 |
この章では、Oracle BPEL Process ManagerおよびOracle Mediatorで動作する、Oracleファイル・アダプタおよびOracle FTPアダプタの使用方法について説明します。Oracleファイル/FTPアダプタの概念、機能、構成および使用例に関する情報も参照できます。
この章の内容は次のとおりです。
注意:
Oracle JCA Adapter for Files/FTPという用語は、Oracleファイル・アダプタおよびOracle FTPアダプタを指します。これらは非常に似た機能を持ちますが、個別のアダプタです。
Oracle BPEL PMとメディエータには、Oracleファイル/FTPアダプタが組み込まれています。Oracleファイル/FTPアダプタを使用すると、ローカル・ファイルシステムやリモート・ファイルシステムのファイルを(ファイル転送プロトコル(FTP)を使用して) BPELプロセスまたはメディエータで交換(読取りおよび書込み)できるようになります。ファイルは、XMLとXML以外のデータ形式のどちらでもかまいません。
この項には次のトピックが含まれます:
Oracleファイル/FTPアダプタはJCA 1.5アーキテクチャに基づいています。JCAでは、異機種間のエンタープライズ情報システム(EIS)の統合に標準アーキテクチャを提供します。Oracleファイル/FTPアダプタのJCAバインディング・コンポーネントでは、基盤となるJCA相互作用がOracle BPEL PM統合のサービス(JCAバインディングを使用したWSDL)として公開されています。Oracle JCAアダプタのアーキテクチャの詳細は、「Oracle JCAアダプタの概要」を参照してください。
Oracleファイル/FTPアダプタはOracle BPEL PMと自動的に統合されます。JDeveloper BPELデザイナの「コンポーネント」ウィンドウからFTPアダプタの「ファイル・アダプタ」をドラッグ・アンド・ドロップすると、図4-1 に示すように、アダプタ構成ウィザードが起動されて「ようこそ」ページが表示されます。
このウィザードでOracleファイル/FTPアダプタを選択して構成できます。アダプタ構成ウィザードでは、図4-2 に示すように、サービス名の入力を求められます。
構成が完了すると、Oracle JDeveloperの「アプリケーション・ナビゲータ」セクションにWSDLとJCAのファイルのペアが作成されます。(JDeveloper)このJCAファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。
アダプタ構成ウィザードの「操作タイプ」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。表4-1 に実行可能な操作をリスト表示し、指定する必要のある構成情報が説明されている項を示します。
表4-1 Oracle BPEL Process Managerについてサポートされている操作
| 操作 | 参照先 |
|---|---|
Oracleファイル・アダプタ |
- |
|
|
|
|
|
|
|
|
Oracle FTPアダプタ |
- |
|
|
|
|
|
|
|
Oracle JCAアダプタとOracle BPEL PMの統合の詳細は、「Oracle JCAアダプタの概要」を参照してください。
Oracleファイル/FTPアダプタはメディエータと自動的に統合されます。JDeveloperデザイナでOracleファイル/FTPアダプタ・サービスを作成すると、アダプタ構成ウィザードが起動します。
このウィザードでOracleファイル/FTPアダプタを選択して構成できます。構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションにWSDLとJCAのファイルのペアが作成されます。このJCAファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。
アダプタ構成ウィザードの「操作タイプ」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。表4-2 に実行可能な操作をリスト表示し、指定する必要のある構成情報が説明されている項を示します。アダプタおよびメディエータの詳細は、「Oracle JCAアダプタの概要」を参照してください。
表4-2 Oracle Mediatorについてサポートされている操作
| 操作 | 参照先 |
|---|---|
Oracleファイル・アダプタ |
- |
|
|
|
|
|
|
|
|
Oracle FTPアダプタ |
- |
|
|
|
|
|
|
|
コンポジットは、設計されて単一アプリケーションにデプロイされるサービス、サービス・コンポーネント(Oracle BPEL PM)、ワイヤおよび参照のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。コンポジットの詳細は、composite.xmlファイルに格納されます。SOAコンポジットとの統合の詳細は、「Oracle SOAコンポジットとアダプタの統合」を参照してください。
使用すると、ローカルやリモートのファイルシステムのディレクトリを操作するようにBPELプロセスを構成できます。この項では、次の機能について説明します。
注意:
大量の同時メッセージを使用するように設計された、コンポジットの場合は、オペレーティング・システムのオープン・ファイル数パラメータを大きい値に設定する必要があります。たとえば、Linuxのオープン・ファイル数パラメータを8192に設定するには、ulimit -n 8192コマンドを使用します。
次のファイル形式の読取りおよび書込みが可能で、実行時にアダプタ・トランスレータ・コンポーネントが使用されます。
XML (XSDおよびDTDベースの両方)
デリミタ付き
位置固定
バイナリ・データ
COBOLコピーブック・データ
ファイル・コンテンツを不透明(Opaque)オブジェクトとして処理し、コンテンツを(変換せずに)元の形式で渡すこともできます。不透明オプションでは、構造をXSDで取得できないJPGやGIFなどのバイナリ・データや、変換の不要なデータが処理されます。
不透明表現base-64ではペイロードがエンコードされ、インメモリー・ペイロードのサイズが1/3増加することに注意してください。不透明/base-64表現は通常、XML内のバイナリ・データを渡すために使用されます。添付ファイルのサポートの詳細は、「大きなペイロードのサポート」も参照してください。
トランスレータにより、様々なフォーマットのネイティブ・データからXMLへの変換、およびXMLから他のフォーマットへの変換を、実行できるようになります。ネイティブ・データは単純な形式(フラット構造)または複雑な形式(親子関係)のいずれかです。トランスレータでは、XMLフォーマットのデータと非XML(ネイティブ)フォーマットのデータの両方を処理できます。
すべてのプラットフォームでRFC 959準拠のほとんどのFTPサーバーをサポートしています。その他のFTPサーバーをサポート可能にするプラガブル・メカニズムも利用できます。さらに、SolarisおよびLinuxでSSLによるFTP (FTPS)をサポートしています。SSHトランスポートを使用したSFTP(Secure FTP)もサポートしています。
注意:
バージョン3以降のSFTPサーバーをサポートしています。
インバウンド方向およびアウトバウンド方向でファイルの交換が行われます。交換の方向により、実行されるタスクの内容は異なります。
Oracle BPEL PMに送信されるインバウンド・ファイルの場合、次の操作が実行されます。
ファイルシステムのポーリングによる一致ファイルの検索
ファイル・コンテンツの読取りおよび変換。ネイティブ・データは、設計時に定義されたネイティブ・スキーマ(NXSD)に基づいて変換されます。
変換済コンテンツのXMLメッセージとしてのパブリッシュ
この機能はファイル読取り操作と呼ばれます。
Oracle BPEL PMから送信されるアウトバウンド・ファイルの場合、次の操作が実行されます。
BPELからのメッセージの受信。
設計時に指定されたXMLコンテンツの書式設定。
出力ファイルの生成。出力ファイルは、基準(経過時間、ファイル・サイズおよびメッセージ数)に基づいて作成されます。これらの基準の組合せを出力ファイル用に指定することもできます。
この機能はファイル書込み操作と呼ばれます。この操作は、JCAアウトバウンド相互作用と呼ばれます。
インバウンドおよびアウトバウンドの方向ごとに、一連の構成パラメータが使用されます。次に例を示します。
インバウンドでは、入力ファイルが配置されるインバウンド・ディレクトリ用のパラメータと、ディレクトリをポーリングする頻度があります。
アウトバウンドでは、ファイルを書き込むアウトバウンド・ディレクトリ用のパラメータと、使用するファイル・ネーミング規則があります。
注意:
パブリッシュ・サイズ、メッセージ数およびポーリング頻度などの構成パラメータを変更するには、アダプタ構成ウィザードを使用する必要があります。
JCAファイル内のこれらのパラメータの値を手動で変更しないでください。
ファイル・リーダーではポーリング規則がサポートされており、いくつかの後処理オプションが用意されています。処理後にファイルを削除するか、移動するか、またはそのまま保持するかを指定できます。ファイル・リーダーでは、単一のメッセージとしてではなく、ファイル・コンテンツを分割してバッチで公開できます。この機能は、パフォーマンス・チューニングに使用できます。ファイル・リーダーでは、ファイルが何度も配信されることはありません。
読取りと書込みの機能の詳細は、次の項を参照してください。
.jcaファイル内でpublishSizeパラメータを使用して、バッチ・サイズを定義できます。
このプロパティは、ファイルに複数のメッセージがあるかどうか、およびBPELプロセスに一度にパブリッシュするメッセージ数を指定します。
たとえば、あるファイルに11個のレコードがあり、このパラメータが2に設定されている場合、そのファイルでは一度に2レコードずつ処理され、最終レコードは6回目に処理されます。
ファイルに複数のメッセージがある場合には、特定数のバッチでメッセージをパブリッシュすることを選択できます。これはデバッチと呼ばれます。デバッチ中、再開と同時にファイル・リーダーは、前回の実行時に中断した場所から処理するため、メッセージが重複することはありません。XMLフォーマットとネイティブ・フォーマットのファイルでは、ファイルのデバッチ処理がサポートされています。
最終バッチがデバッチ・シナリオに達したときに呼び出されるバッチ通知コールバック(Javaクラス)を登録できます。
<service ...
<binding.jca ...
<property name="batchNotificationHandler">java://oracle.sample.SampleBatchCalloutHandler </property>
ここでのプロパティ値はjava://{custom_class}を指定し、そこにoracle.sample.SampleBatchCalloutHandlerが実装される必要があります
package oracle.tip.adapter.api.callout.batch;
public interface BatchNotificationCallout extends Callout
{
public void onInitiateBatch(String rootId,
String metaData)
throws ResourceException;
public void onFailedBatch(String rootId,
String metaData,
long currentBatchSize,
Throwable reason)
throws ResourceException;
public void onCompletedBatch(String rootId,
String metaData,
long finalBatchSize)
throws ResourceException;
ファイルのチャンク読取り操作では、大きなファイルの処理が可能になり、whileループ内でBPEL invokeアクティビティを使用してターゲット・ファイルが処理されます。
具体的には、FileAdapterによって、BPELプロセス・モデラーはinvokeアクティビティを使用して非常に大きなファイルから論理チャンクを取得できるため、ファイルのメモリー制限を超えません。このプロセスでは、ループ内でチャンク相互作用をコールすることにより、一度に1つずつ論理チャンクを実行してファイル全体を処理します。目的は、ファイルのアウトバウンド処理でデバッチ処理できるようにすることです。
ファイル・アダプタ構成ウィザードを使用して、チャンク・ファイル(.jcaファイル)およびWSDLファイルを定義します。
FileAdapterは、チャンク読取り操作のネイティブ・データをXMLに変換し、それをBPEL変数として返します。
チャンク読取りを実行するには、通常、BPEL内にinvokeアクティビティを作成します。
また、ファイル・アダプタ構成ウィザードを使用して、WSDL操作として「チャンク同期読取り」を選択し、オプションで、構成ウィザードを使用して、ChunkedInteractionSpecに書き込まれるファイル入力ディレクトリおよびファイル名を構成します。
invokeアクティビティがコールされるたびに、ヘッダー値とペイロードが返されます。
これらのヘッダー値には、行番号、列番号、およびファイルの終わりに達したかどうかを示すインジケータが含まれます。以降のファイル・アダプタのコールのために、必ずリターン・ヘッダーの行番号と列番号をアウトバウンド・ヘッダーにコピーしてください。必要に応じて、入力ディレクトリおよびファイル名をヘッダー値として指定することもできます。
FileAdapterのチャンク相互作用は、BPELから起動されます。ネイティブ・データ・ファイルの場合、行番号と列番号もヘッダー値として渡されます。
ループ内でチャンク相互作用が初めてコールされるときのLineNumberおよびColumnNumberの値は空白であり、それ以降のコールでは、これらの値はinvokeの戻り値から1を引いた値(つまり、invokeの前の値)になります。
BPEL invokeは、表4-3 に示されているパラメータを使用してChunkedInteractionをコールします。
表4-3 チャンク相互作用のためのBPEL invokeパラメータ
| パラメータ | 取得場所 |
|---|---|
|
ChunkedInteractionSpecまたはBPELヘッダー |
|
ChunkedInteractionSpecまたはBPELヘッダー |
|
ChunkedInteractionSpec (デバッチ処理におけるPublishSizeと類似) |
|
ヘッダー(オプション) |
|
ヘッダー(オプション) |
|
ヘッダー(オプション) |
ChunkSizeパラメータは、チャンク読取り操作でのファイル・チャンク・サイズに関連する情報を提供するもので、(ファイル・アダプタ構成ウィザードを使用して) ChunkedInteractionSpec内に別の値を構成していない場合は、デフォルトで1になります。
具体的には、ChunkSizeパラメータは、返されるノードまたはレコード(行ではない)の数を制御します。
たとえば、ネイティブCSVファイルのアドレス帳がある場合、ChunkSizeとして5を指定すると、invokeアクティビティがコールされるたびに、5個のアドレス帳ノードを含むXMLファイル(XMLフォーマットのCSVレコード5行)が返されます。
この意味で、ChunkSizeパラメータは、FileAdapterでインバウンド・トランザクションに使用されるPublishSizeパラメータと似ています。
次の例に、チャンク読取り参照バインディングのための拒否ハンドラの構成方法を示します。
例 - チャンク読取りのための拒否ハンドラ・バインディング
<reference name="ReadAddressChunk">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel/adapter
/file/ReadAddressChunk/
#wsdl.interface(ChunkedRead_ptt)"/>
<binding.jca config="ReadAddressChunk_file.jca">
<property name="rejectedMessageHandlers" source=""
type="xs:string" many="false" override="may"
>file:///c:/temp</property>
</binding.jca>
</reference>
invokeの後は必ず、以降のinvokeのためにリターン・ヘッダーをアウトバウンド・ヘッダーにコピーする必要があります。LineNumber/ColumnNumberはアダプタでブックキーピング目的のみに使用されるものであり、リターン・ヘッダーからこれらの値をチャンク相互作用がコールされる前のヘッダーにコピーする必要があります。
これに対し、RecordNumberは、データが(ネイティブ・データではなく) XMLフォーマットのときに使用されます。その意味で、RecordNumberは、ネイティブ・データのブックキーピングに使用されるLineNumber/ColumnNumberとは相互に排他的です。
次に、チャンク読取りのためのJCAファイルの例を示します。
例 - チャンク読取りのためのJCAファイル
<interaction-spec className="oracle.tip.adapter.file.
outbound.ChunkedInteractionSpec">
<property name="PhysicalDirectory"
value="/tmp/chunked/in"/>
<property name="FileName" value="dummy.txt"/>
<property name="ChunkSize" value="10"/>
</interaction-spec>
次の例に、チャンク読取り相互作用のために生成されたアダプタWSDLファイルを示します。
例 - チャンク読取りのWSDLファイル
<?xml version = '1.0' encoding = 'UTF-8'?>
<definitions name="ReadAddressChunk"
targetNamespace="http://xmlns.oracle.com/pcbpel
/adapter/file/ReadAddressChunk/"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/
file/ReadAddressChunk/" xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:imp1="http://xmlns.oracle.com/pcbpel/demoSchema/csv">
<documentation>Returns a finite chunk from the target
file based on the chunk size parameter</documentation>
<types>
<schema targetNamespace="http://xmlns.oracle.com/
pcbpel/adapter/
file/ReadAddressChunk/"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://xmlns.oracle.com/pcbpel
/demoSchema/csv"
schemaLocation="xsd/address-csv.xsd"/>
<element name="empty">
<complexType/>
</element>
</schema>
</types>
<message name="Empty_msg">
<part name="Empty" element="tns:empty"/>
</message>
<message name="Root-Element_msg">
<part name=
"Root-Element" element="imp1:Root-Element"/>
</message>
<portType name="ChunkedRead_ptt">
<operation name="ChunkedRead">
<input message="tns:Empty_msg"/>
<output message="tns:Root-Element_msg"/>
</operation>
</portType>
<plt:partnerLinkType name="ChunkedRead_plt">
<plt:role name="ChunkedRead_role">
<plt:portType
name="tns:ChunkedRead_ptt"/>
</plt:role>
</plt:partnerLinkType>
</definitions>
ファイル読取り相互作用をモデル化するには、ファイル・アダプタ構成ウィザードを使用します。
他のファイル・アダプタ操作を構成する場合と同様、ファイル・アダプタの最初の3つの画面を使用できます。
変換例外(nXSD仕様に違反する不正レコード)が発生すると、エラーが発生した行や列などの詳細を含む変換例外メッセージがリターン・ヘッダーに移入されます。
ただし、特定の変換エラーが発生してもフォルトにはなりません。これはリターン・ヘッダー内の値となります。jca.file.IsMessageRejectedおよびjca.file.RejectionReasonヘッダーの値を確認して、拒否が発生したかどうかを確認する必要があります。また、jca.file.NoDataFoundヘッダーの値も確認できます。
nxsd:uniqueMessageSeparatorコンストラクトを使用すると、アダプタは不正なレコードをスキップして、次のレコード・セットの処理を続行できます。(uniqueMessageSeparatorの詳細は、「ネイティブ・フォーマット・ビルダー・ウィザード」を参照してください。)
uniqueMessageSeparatorを使用しない場合、アダプタはEndOfFileを返し、それによってwhileループが終了します。
このため、ファイルの終わりの状況を想定せずに処理を続行する場合は、uniqueMessageSeparatorコンストラクトが必要です。uniqueMessageSeparatorコンストラクトがない場合、ファイルの残りの部分が単一のチャンクとして拒否され、ファイル全体が拒否されます。
nxsd:uniqueMessageSeparatorコンストラクトを使用するシナリオにおけるリターン・ヘッダーの体裁の例は、図4-7 を参照してください。
このシナリオは、(それぞれが複雑である) 6件のレコードを持ち、各代替レコードが不正であったファイルとのチャンク相互作用を示しています。このシナリオでは、ChunkSizeとして5を使用しました。
returnHeaderは、メッセージが拒否されたこと(isMessageRejected=true)、および3つの不正レコードに対して拒否理由が移入される(具体的には行17、37および57のレコードが不正であった)ことを示しています。
NoDataFoundパラメータはfalseに設定されているため、残りの3つのレコードのデータは返されます。
図4-7 nxsd:uniqueMessageSeparatorを使用した場合のリターン・アウトバウンド・ヘッダーの体裁
同じレコードが、ユーザー構成の拒否フォルダ(この場合はC:\foo)に対しても拒否されます。図4-8を参照してください。
Oracleファイル/FTPアダプタでファイルを特定の順序で処理する必要がある場合は、アダプタのファイル・ソート機能を使用できます。たとえば、ソート・パラメータは、ファイルをタイムスタンプの昇順または降順で処理するように構成できます。
ソート・シナリオの場合、次の前提条件を満たす必要があります。
同期操作の使用
インバウンドJCAファイルへの次のプロパティの追加
<property name="ListSorter" value="oracle.tip.adapter.file.inbound.listing.TimestampSorterAscending"/> <property name="SingleThreadModel" value="true"/>
アウトバウンド・ファイルやアウトバウンド・ディレクトリの論理名または物理名を動的に指定できます。動的なアウトバウンド・ディレクトリを指定する方法は、「アウトバウンド・ファイル・ディレクトリの作成」を参照してください。
FTP (FTPS)とセキュアFTP (SFTP)をサポートしており、ネットワークを介したセキュアなファイル転送が可能です。
詳細は、「セキュアFTPの使用」および「SFTPの使用」を参照してください。
インバウンド・ディレクトリからファイルを取得してファイルを処理し、処理したファイルを出力ディレクトリに送信します。ただし、非トランザクションの性質があるため、このプロセス中にOracle RACバックエンドまたはSOA管理サーバーでフェイルオーバーが発生すると、ファイルが2回処理されます。その結果、出力ディレクトリにファイルが重複して存在する場合があります。
プロキシ・サポート機能を使用すると、ファイアウォール外部のFTPサーバーやプロキシ・サーバーを介してのみアクセス可能なFTPサーバーとの間でデータを転送および取得できます。プロキシ・サーバーにより、イントラネット上のホストからインターネット上のホストに間接的に接続できます。図4-9 に、プロキシ・サーバーが接続を作成してクライアントとリモートFTPサーバーとの直接接続をシミュレートする様子を示します。
HTTPプロキシ機能を使用するには、プロキシ・サーバーでHTTP接続を介したFTP通信量をサポートしている必要があります。また、この機能でサポートされるのはパッシブ・データ接続のみです。構成方法の詳細は、「HTTPプロキシ用の構成」を参照してください。
Oracle BPEL PMの場合、BPELプロセスに対するファイル名、ディレクトリ、ファイル・サイズ、最終変更時間などのファイル・メタデータのみのパブリッシュをサポートしており、ペイロードは除外されます。このプロセスでは、このメタデータを以降の処理に使用できます。たとえば、プロセスで別の参照をコールし、以降の処理のためにファイル名とディレクトリ名を渡すことができます。通知サービスとして使用し、インバウンド・ディレクトリに新規ファイルが出現するたびにプロセスに通知できます。この機能を使用するには、読取り操作の構成時にJDeveloperウィザードで「ファイルの内容を読み取らない」チェック・ボックスを選択します。
Oracle BPEL PMの場合、大きいファイルを添付として転送する機能をサポートしています。この機能を使用するには、読取り操作の構成時にJDeveloperの構成ウィザードで「ファイルを添付ファイルとして読取り」チェック・ボックスを選択します。
このオプションを選択すると、ある場所から別の場所へ大量のデータが添付として不透明に転送されます。たとえば、大量のMS Word文書、イメージおよびPDFをコンポジット・アプリケーション内でコンテンツを処理せずに転送できます。大きなペイロードを添付として渡す方法は、「添付ファイルとしてのOracleファイル・アダプタのRead File」を参照してください。
さらに、Oracleファイル・アダプタにより、ファイルを添付として書き込む機能が提供されます。ファイルを添付ファイルとして書き込むときに標準ペイロードも所有している場合は、添付ファイルが書き込まれ、ペイロードは無視されます。
注意:
大きなペイロードを不透明スキーマとして渡すことはできません。
インバウンド・アダプタのエンドポイントのアクティブ化の制御に使用可能なファイルベースのトリガーをサポートしています。ファイルベースのトリガーの使用方法は、「ファイル・ポーリング」を参照してください。
プロセス・モデラーでは、処理のためにファイルを取得する前に前処理を行ったり、宛先フォルダにファイルを書き出す前に後処理を行う必要がある状況が発生する場合があります。たとえば、Oracleファイル/FTPアダプタで受信されたファイルは圧縮または暗号化される可能性があるため、ファイルを処理する前に、アダプタでファイルを解凍または復号化する必要があります。この場合、カスタム・コードを使用して、ファイルを処理する前に解凍または復号化する必要があります。Oracleファイル/FTPアダプタでは、ファイルの前処理や後処理のためにプラグインできるカスタム・コードの使用がサポートされています。
ファイルの前処理および後処理の実装は、Oracleファイル/FTPアダプタの次の通信モードに制限されています。
Read FileまたはGet File
Write FileまたはPut File
同期Read File
チャンク読取り
この項では、次の項目について説明します。
ファイルの前処理および後処理のメカニズムは、パイプラインおよびバルブとして構成されます。この項では、パイプラインおよびバルブについて説明します。
パイプラインには、カスタム定義された一連のバルブが含まれます。ファイルシステムからパイプラインにロードされたストリームは、順序付けられた一連のバルブによって処理され、処理の後に、変更されたストリームがアダプタに返されます。
バルブは、パイプライン処理における主要な実行コンポーネントです。バルブでは、受信したコンテンツを処理して、処理済のコンテンツを次のバルブに転送します。たとえば、暗号化され、かつ圧縮されたファイルをOracleファイル/FTPアダプタで受信するというシナリオでは、解凍バルブの後に復号化バルブを使用するパイプラインを構成できます。図4-10 に示すように、ファイル・コンテンツは解凍バルブで解凍された後、復号化バルブに転送され、復号化バルブで復号化されて、最終的なコンテンツがOracleファイル/FTPアダプタで使用できるようになります。
ファイルの前処理および後処理のメカニズムを構成するには、パイプラインを定義して、対応するJCAファイルでパイプラインを構成する必要があります。
パイプラインを構成する手順は、次のとおりです。
すべてのバルブにValveまたはStagedValveインタフェースを実装する必要があります。
ヒント:
バルブを最初から実装するかわりに、ビジネス要件に応じてAbstractValveクラスまたはAbstractStagedValveクラスのいずれかを拡張できます。
次の例に、サンプルのValveインタフェースを示します。
例 - Valveインタフェース
package oracle.tip.pc.services.pipeline; import java.io.IOException; /** <p> * Valve component is resposible for processing the input stream * and returning a modified input stream. * The <code>execute()</code> method of the valve gets invoked * by the caller (on behalf) of the pipeline. This method must * return the input stream wrapped within an InputStreamContext. * The Valve is also responsible for error handling specifically * * The Valve can be marked as reentrant in which case the caller * must call the <code>execute()</code> multiple times and each * invocation must return a new input stream. This is useful, if * you are writing an UnzipValve since each iteration of the valve * must return the input stream for a different zipped entry. * <b> You must note that only the first Valve in the pipeline can * be reentrant </b> * * The Valve has another flavor <code>StagedValve</code> and if * the valve implements StagedValve, then the valve must store * intermediate content in a staging file and return it whenever * required. * </p> */ public interface Valve { /** * Set the Pipeline instance. This parameter can be * used to get a reference to the PipelineContext instance. * @param pipeline */ public void setPipeline(Pipeline pipeline); /** Returns the Pipeline instance. * @return */ public Pipeline getPipeline(); /** Returns true if the valve has more input streams to return * For example, if the input stream is from a zipped file, then * each invocation of <code>execute()</code> returns a different * input stream once for each zipped entry. The caller calls * <code>hasNext()</code> to check if more entries are available * @return true/false */ public boolean hasNext(); /** Set to true if the caller can call the valve multiple times * e.g. in case of ZippedInputStreams * @param reentrant */ public void setReentrant(boolean reentrant); /** Returns true if the valve is reentrant. * @return */ public boolean isReentrant(); /** The method is called by pipeline to return the modified input stream * @param in * @return InputStreamContext that wraps * the input stream along with required metadata * @throws PipelineException */ public InputStreamContext execute(InputStreamContext in) throws PipelineException, IOException; /** * This method is called by the pipeline after the caller * publishes the * message to the SCA container. * In the case of a zipped file, this method * gets called repeatedly, once * for each entry in the zip file. * This should be used by the Valve to do * additional tasks such as * delete the staging file that has been processed * in a reentrant * scenario. * @param in The original InputStreamContext returned from <code>execute()</code> */ public void finalize(InputStreamContext in); /**Cleans up intermediate staging files, input streams * @throws PipelineException, IOException */ public void cleanup() throws PipelineException, IOException; }
StagedValveには、ステージング・ファイルの中間コンテンツが格納されます。次の例に、Valveインタフェースを拡張するStagedValveインタフェースを示します。
例 - Valveインタフェースを拡張するStagedValveインタフェース
package oracle.tip.pc.services.pipeline; import java.io.File; /** * A special valve that stages the modified * input stream in a staging file. * If such a <code>Valve</code> exists, then * it must return the staging file containing * the intermediate data. */ public interface StagedValve extends Valve { /** * @return staging file where the valve * stores its intermediate results */ public File getStagingFile(); }
次の例に、Valveインタフェースを実装するAbstractValveクラスのサンプルを示します。
例 - Valveインタフェースを実装するAbstractValveインタフェース
package oracle.tip.pc.services.pipeline; import java.io.IOException; /** * A bare bone implementation of Valve. The user should * extend from * AbstractValve rather than implementing a Valve from scratch * */ public abstract class AbstractValve implements Valve { /** * The pipeline instance is stored as a member */ private Pipeline pipeline = null; /** * If reentrant is set to true, then the Valve must adhere to the following: * i) It must the first valve in the pipeline ii) * Must implement hasNext * method and return true if more input * streams are available A reentrant * valve will be called by the pipeline * more than once and each time the * valve must return a different input stream, * for example Zipped entries * within a zip file */ private boolean reentrant = false; /* * Save the pipeline instance. * * @see * oracle.tip.pc.services.pipeline.Valve#setPipeline * (oracle.tip.pc.services.pipeline.Pipeline) */ public void setPipeline(Pipeline pipeline) { this.pipeline = pipeline; } /* * Return the pipeline instance (non-Javadoc) * * @see oracle.tip.pc.services.pipeline. * Valve#getPipeline() */ public Pipeline getPipeline() { return this.pipeline; } /* * Return true if the valve is reentrant (non-Javadoc) * * @see oracle.tip.pc.services.pipeline. * Valve#isReentrant() */ public boolean isReentrant() { return this.reentrant; } /* * If set to true, the valve is reentrant (non-Javadoc) * * @see oracle.tip.pc.services.pipeline. * Valve#setReentrant(boolean) * */ public void setReentrant(boolean reentrant) { this.reentrant = reentrant; } /* * By default, set to false For valves * that can return more than one * inputstreams to callers, this parameter * must return true/false depending * on the availability of input streams (non-Javadoc) * * @see oracle.tip.pc.services.pipeline.Valve#hasNext() */ public boolean hasNext() { return false; } /* * Implemented by concrete valve (non-Javadoc) * * @see oracle.tip.pc.services.pipeline. * Valve#execute(InputStreamContext) */ public abstract InputStreamContext execute(InputStreamContext in) throws PipelineException, IOException; /* * Implemented by concrete valve (non-Javadoc) * * @see * oracle.tip.pc.services.pipeline.Valve#finalize * (oracle.tip.pc.services.pipeline.In * putStreamContext) * / public abstract void finalize(InputStreamContext in); /* * Implemented by concrete valve (non-Javadoc) * * @see oracle.tip.pc.services.pipeline. * Valve#cleanup() */ public abstract void cleanup() throws PipelineException, IOException; }
次の例に、AbstractValveクラスを拡張するAbstractStagedValveクラスを示します。
例 - AbstractValveクラスを拡張するAbstractStagedValveクラス
package oracle.tip.pc.services.pipeline; import java.io.File; import java.io.IOException; public abstract class AbstractStagedValve extends AbstractValve implements StagedValve { public abstract File getStagingFile(); public abstract void cleanup() throws IOException, PipelineException; public abstract InputStreamContext execute(InputStreamContext in) throws IOException, PipelineException; }
バルブの詳細は、「Oracle JCAアダプタ・バルブ」を参照してください。
バルブをコンパイルするには、bpm-infra.jarファイルを使用する必要があります。bpm-infra.jarファイルは、$MW_HOME/AS11gR1SOA/soa/modules/oracle.soa.fabric_11.1.1/bpm-infra.jarにあります。
bpm-infra.jarファイルに対するSOAプロジェクトを参照するには、次の手順を使用します。
「アプリケーション・ナビゲータ」で、SOAプロジェクトを右クリックします。
「プロジェクト・プロパティ」を選択します。「プロジェクト・プロパティ」ダイアログが表示されます。
「ライブラリとクラスパス」をクリックします。図4-11 に示すように、「ライブラリとクラスパス」ペインが表示されます。
「Jar/ディレクトリの追加」をクリックします。「アーカイブまたはディレクトリの追加」ダイアログが表示されます。
参照してbpm-infra.jarファイルを選択します。Bpm-infra.jarファイルは、$MW_HOME/AS11gR1SOA/soa/modules/oracle.soa.fabric_11.1.1/bpm-infra.jarにあります。
「OK」をクリックします。bpm-infra.jarファイルが「クラスパス・エントリ」に表示されます。
bpm-infra.jarファイルを使用してバルブをコンパイルします。
コンパイルされたバルブを含むJARファイルをsoainfraドメインのクラスパスに追加して、Oracle WebLogic Serverクラスパスで使用できるようにします。たとえば、$MW_HOME/user_projects/domains/soainfra/libなどです。
注意:
「クラス・ファイルのバージョン50.0が正しくありません。49.0である必要があります。」などのコンパイル・エラーを回避するには、JDK 6.0を使用してbpm-infra.jarをコンパイルするようにしてください。
パイプラインを構成するには、次のスキーマに準拠するXMLファイルを作成する必要があります。
例 - パイプライン作成のためのXML
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.oracle.com/adapter/pipeline">
<xs:element name="pipeline">
<xs:complexType>
<xs:sequence>
<xs:element ref="valves">
<xs:complexType>
<xs:sequence>
<xs:element ref="valve"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:attribute name="reentrant"
type="xs:NMTOKEN"
use="optional" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:attribute name="useStaging"
type="xs:NMTOKEN" use="optional" />
<xs:attribute name="batchNotificationHandler"
type="xs:NMTOKEN" use="
optional" />
</xs:element>
</xs:schema
パイプラインに対してSimpleUnzipValveおよびSimpleDecryptValveの2つのバルブを使用して構成したサンプルのXMLファイルを次に示します。
例 - パイプラインに対して2つのバルブを使用して構成したXMLファイル
<?xml version="1.0"?>
<pipeline xmlns=
"http://www.oracle.com/adapter/pipeline">
<valves>
<valve>valves.SimpleUnzipValve</valve>
<valve> valves.SimpleDecryptValve </valve>
</valves>
</pipeline>
pipeline.xmlファイルをSOAプロジェクト・ディレクトリに追加する必要があります。パイプラインを統合するには、この手順が必須です。図4-12 に、InboundUnzipAndOutboundZipプロジェクトに追加されたサンプルのpipeline.xmlファイル(unzippipeline.xml)を示します。
SOAプロジェクトの一部であるパイプラインは、次のプロパティを追加してインバウンドJCAファイルを変更することにより登録する必要があります。
<property name="PipelineFile" value="pipeline.xml"/>
たとえば、図4-12 に示すように、JCAファイル(FileInUnzip_file.jca)には、UnzipパイプラインをOracleファイル・アダプタに登録するために次のプロパティが追加されています。
<property name="PipelineFile" value="unzippipeline.xml"/>
単純なバルブを使用したシナリオがある場合もあります。単純なバルブとは、リエントラント性などの追加メタデータやbatchNotificationHandlersを必要としないバルブのことです。単純なバルブを使用するシナリオの場合、パイプラインは、次のサンプルに示すようにActivationSpecまたはInteractionSpecプロパティとして構成できます。
例 - 単純なバルブを使用したパイプライン構成
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="FlatStructureIn"
adapter="File Adapter"
xmlns="http://platform.integration.
oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/FileAdapter"
UIincludeWildcard="*.txt"
adapterRef=""/>
<endpoint-activation operation="Read">
<activation-spec
className="oracle.tip.adapter.file.
inbound.FileActivationSpec">
<property name="UseHeaders" value="false"/>
<property name=
"LogicalDirectory" value="InputFileDir"/>
<property name="Recursive" value="true"/>
<property name="DeleteFile" value="true"/>
<property name="IncludeFiles" value=".*\.txt"/>
<property name="PollingFrequency" value="10"/>
<property name="MinimumAge" value="0"/>
<property name="OpaqueSchema" value="false"/>
</activation-spec>
</endpoint-activation>
</adapter-config>
注意:
PipelineValvesプロパティのvalueには、カンマ(,)の後にスペースはありません。
注意:
PipelineValveプロパティを使用してパイプラインを構成する場合、リエントラント・バルブやバッチ通知ハンドラなどの追加メタデータは構成できません。追加メタデータは、XMLベースのアプローチに使用されるPipelineFileを使用する場合にのみ構成できます。
リエントラント・バルブを使用すると、Zipファイル内の個別エントリを処理できます。Zipファイル内のすべてのエントリを処理するシナリオでは、各エントリがData Encryption Standard (DES)を使用して暗号化されますが、reentrant="true"属性を解凍バルブに次のように追加することにより、バルブを構成できます。
例 - reentrant=true属性の構成
<?xml version="1.0"?>
<pipeline xmlns="http://www.oracle.com/adapter/pipeline">
<valves>
<valve reentrant="true">valves.ReentrantUnzipValve</valve>
<valve> valves.SimpleDecryptValve </valve>
</valves>
</pipeline>
この例では、Zipファイル全体が処理されるまで、パイプラインによってReentrantUnzipValveの次にSimpleDecryptValveが同じ順序で繰り返し起動されます。つまり、まずReentrantUnzipValveが起動されて圧縮された最初のエントリのデータを返し、次に、そのエントリがSimpleDecryptValveに送られて復号化され、最終的なコンテンツがアダプタに返されます。このプロセスが、Zipファイル内のすべてのエントリが処理されるまで繰り返されます。
また、バルブにはsetMessageKey() APIを使用してメッセージ・キーを設定する必要があります。詳細は、「複数ファイルの処理用の解凍バルブ」を参照してください。
Zipファイルのエラー処理
Zipファイル内の個別のエントリに対する変換エラーがある場合、変換エラーのあるエントリは拒否され、他のエントリが処理されます。
パブリッシュ操作中のエラーがある場合、パブリッシュ操作は再試行され、再試行セマンティックが保持されます。再試行セマンティックが保持されない場合、元のファイルが拒否されてパイプラインは終了します。
BatchNotificationHandler APIは、Oracleファイル/FTPアダプタのインバウンドのデバッチ機能とともに使用されます。デバッチ・シナリオでは各ファイルに複数メッセージが含まれ、クラッシュ・リカバリに対するなんらかのブックキーピングが必要となります。このことはBatchNotificationHandler APIによって容易になります。このAPIによりバッチが開始、発生または終了するたびにパイプラインから通知を受け取ります。次の例に、BatchNotificationHandlerインタフェースを示します。
例 - BatchNotificationハンドラ
package oracle.tip.pc.services.pipeline;
/*
* Whenever the caller processes de-batchable files,
* each file can
* have multiple messages and this handler
* allows the user to plug in
* a notification mechanism into the pipeline.
*
* This is particularly useful in crash recovery
* situations
*/
public interface BatchNotificationHandler {
/*
* The Pipeline instance is set by the
* PipelineFactory when the
* BatchNotificationHandler instance is created
*/
public void setPipeline(Pipeline pipeline);
public Pipeline getPipeline();
/*
* Called when the BatchNotificationHandler
* is instantiated
*/
public void initialize();
/*
* Called by the adapter when a batch begins,
* the implementation must
* return
* a BatchContext instance with the
* following information:
* i) batchId: a unique
* id that will be returned
* every time onBatch is
* invoked by called
* ii)line/col/record/offset:
* for error recovery cases
*/
public BatchContext onBatchBegin();
/*
* Called by the adapter
* when a batch is submitted.
* The parameter holds the
* line/column/record/offset for the successful batch
* that is published.
* Here the implementation
* must save these in
* order to recover from
* crashes
*/
public void onBatch(BatchContext ctx);
/*
* Called by the adapter when a batch
* completes.
* This must be used to clean up
*/
public void onBatchCompletion
(boolean success);
}
デバッチ処理を含むパイプラインを使用するには、BatchNotificationHandlerインスタンスを使用したパイプラインを構成する必要があります。次の例を参照してください。
例 - BatchNotificationHandlerインスタンスを使用したパイプラインの構成
<?xml version="1.0"?>
<pipeline xmlns="http://www.oracle.com
/adapter/pipeline" batchNotificationHandler="oracle.tip.pc.services. pipeline.ConsoleBatchNotificationHandler">
<valves>
<valve reentrant="true">valves.
SimpleUnzipValve</valve>
<valve>valves.SimpleDecryptValve</valve>
</valves>
</pipeline>
uniqueMessageSeparatorプロパティなどのインバウンド・エラー処理機能が用意されています。
デバッチ処理(1つのファイルに複数のメッセージがある場合)では、不正メッセージの開始部分からファイルの終わりまでが拒否されます。各メッセージに一意のセパレータがあり、そのセパレータがいずれのデータの一部でもない場合、拒否される部分はより細かくなります。その場合、ネイティブ・スキーマのスキーマ要素にuniqueMessageSeparatorプロパティを定義し、この一意のメッセージ・セパレータの値を取得できます。1つのファイル内の複数レコードの解析(デバッチ処理)中、このプロパティがアダプタ・トランスレータの動作を制御します。このプロパティを使用することにより、大きなバッチ・ファイルに不正メッセージが検出された場合でもリカバリが可能になります。不正レコードが検出されると、アダプタ・トランスレータは次の一意のメッセージ・セパレータ境界にスキップし、そこから続行します。このプロパティを設定しないと、不正レコード以降のすべてのレコードが拒否されます。
次の例に、uniqueMessageSeparatorプロパティの使用例を示します。
例 - uniqueMessageSeparatorプロパティの使用方法を示すスキーマ・ファイル
<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/
2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/
pcbpel/nxsd"
targetNamespace=
"http://TargetNamespace.com/Reader"
xmlns:tns=
"http://TargetNamespace.com/Reader"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:encoding="US-ASCII" nxsd:stream="chars"
nxsd:version="NXSD"
nxsd:uniqueMessageSeparator="${eol}">
<xsd:element name="emp-listing">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="emp" minOccurs="1"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="GUID"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy=""">
</xsd:element>
<xsd:element name="Designation"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy=""">
</xsd:element>
<xsd:element name="Car" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy=""">
</xsd:element>
<xsd:element name="Labtop" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy=""">
</xsd:element>
<xsd:element name="Location"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy=""">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
<!--NXSDWIZ:D:\work\jDevProjects\Temp_BPEL_process
\Sample2\note.txt:-->
<!--USE-HEADER:false:-->
拒否されたメッセージ、接続エラーおよびメッセージ・エラーの処理の詳細は、「拒否されたメッセージの処理」を参照してください。
この項では、サポートするスレッド・モデルについて説明します。抑制または抑制解除するには、スレッド・モデルの知識が必要です。次のスレッド・モデルを使用します。
デフォルトのスレッド・モデルでは、インバウンドの各エンドポイントに対してポーラーが作成されます。ポーラーは、ファイル・メタデータをインメモリー・キューにエンキューします。このファイル・メタデータはプロセッサ・スレッドのグローバル・プールによって処理されます。図4-13 はデフォルトのスレッド・モデルを示しています。
次の手順で、デフォルトのスレッド・モデルの機能を明確に示します。
ポーラーは、入力ディレクトリ内のファイルを定期的に検索します。ポーラーがファイルを検索する間隔は、インバウンドJCAファイルのPollingFrequencyパラメータで指定されます。
ポーラーは、構成済のインバウンド・ディレクトリで検出した新規ファイルごとに、ファイル名、ファイル・ディレクトリ、変更時間、ファイル・サイズなどの情報を内部のインメモリー・キューにエンキューします。
注意:
新規ファイルとは処理されていないファイルです。
プロセッサ・ワーカー・スレッドのグローバル・プールは、インメモリー・キューのファイルの処理を待機します。
プロセッサ・ワーカー・スレッドは内部キューからファイルを取得し、次のアクションを実行します。
適切なトランスレータ(テキスト、バイナリ、XMLまたは不透明データを読み取るトランスレータなど)にファイルの内容をストリームします。
トランスレータによるXMLの結果をSCAインフラストラクチャにパブリッシュします。
ファイル処理後の削除やアーカイブなど、必要な後処理を実行します。
デフォルトのスレッド動作を変更できます。スレッド・モデルを変更すると、抑制動作が変更されます。以降の各項では、変更されたスレッド動作について説明します。
シングル・スレッド・モデルは、ポーラーがプロセッサの役割を果たせるようにする、変更されたスレッド・モデルです。ポーラー・スレッドは、同じスレッド内のファイルを処理します。このモデルでは、プロセッサ・スレッドのグローバル・プールは使用されません。シングル・スレッド・モデルのプロパティは、インバウンドJCAファイルで次のように定義できます。
例 - シングル・スレッド・モデルのプロパティの定義
<activation-spec className="oracle.tip.adapter.file. inbound.FileActivationSpec"> <property../> <property name="SingleThreadModel" value="true"/> <property../> </activation-spec>
パーティション化スレッド・モデルは、インメモリー・キューがパーティション化され、各コンポジット・アプリケーションがそれぞれのインメモリー・キューを取得する、変更されたスレッド・モデルです。プロセッサ・ワーカー・スレッドのグローバル・プールに依存しないで独自のプロセッサ・スレッドを作成し、エンキューされたファイルを処理できます。パーティション・モデルのプロパティは、インバウンドJCAファイルで定義できます。次の例を参照してください。
例 - インバウンドJCAファイルでのパーティション・モデルのプロパティの定義
<activation-spec className="oracle.tip.adapter.file.inbound. FileActivationSpec"> <property../> <property name="ThreadCount" value="4"/> <property../> </activation-spec>
この例で、パーティション・モデルのプロパティ定義は次のようになります。
ThreadCountプロパティが0に設定されている場合、スレッド動作はシングル・スレッド・モデルと同様になります。
ThreadCountプロパティが-1に設定されている場合、グローバル・スレッド・プールが使用され、動作はデフォルトのスレッド・モデルと同じになります。
ThreadCountプロパティの最大値は40です。
インバウンド操作とアウトバウンド操作を抑制するためのノブを提供することでパフォーマンス・チューニング機能をサポートしています。アウトバウンド操作のパフォーマンス・チューニングに使用できるパラメータも提供されます。
パフォーマンス・チューニングの詳細は、このマニュアルの「Oracle JCAアダプタ・チューニング・ガイド」を参照してください。
Oracle BPEL Process Managerおよびサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能をサポートしています。この機能は、インバウンド操作とアウトバウンド操作の両方でサポートされています。
1つのアクティブ化における複数ディレクトリのポーリングをサポートしています。JDeveloperで単一ディレクトリではなく複数のディレクトリを指定できます。これは、物理ディレクトリと論理ディレクトリの両方に適用可能です。
注意:
インバウンドが着信ファイルを複数のディレクトリでポーリングするように構成されている場合は、ファイル・リーダーがこれらのディレクトリのポーリングを開始する前に、すべての最上位ディレクトリ(入力ファイルが表示されるインバウンド・ディレクトリ)が存在している必要があります。
1つ以上のインバウンド・ディレクトリを選択した後、サブディレクトリの再帰的な処理が必要かどうかも指定できます。「ファイルを再帰的に処理します」オプションを選択した場合は、ディレクトリが再帰的に処理されます。図4-14 に示すように、デフォルトでは、このオプションが「ファイル・ディレクトリ」ページで選択されます。
複数のディレクトリを選択した場合、生成されるJCAファイルではディレクトリのセパレータとしてセミコロン(;)が使用されます。ただし、他のセパレータへの変更も可能です。その場合は、生成されたJCAファイルに手動でDirectorySeparator="選択したセパレータ"を追加します。たとえば、セパレータとしてカンマ(,)を使用する場合は、まず物理ディレクトリ内でセパレータを","に変更してから、JCAファイルに<property name="DirectorySeparator" value=","/>を追加します。
さらに、ディレクトリを再帰的に処理し、1つ以上のサブディレクトリに適切な権限がない場合、インバウンド・アダプタは処理時に例外をスローします。この例外を無視する場合は、次の例に示すようにcomposite.xmlでignoreListingErrorsの名前を持つバインディング・プロパティを定義する必要があります。
例 - ignoreLIstingErrorsという名前のバインディング・プロパティの定義
<service name="FlatStructureIn">
<interface.wsdl
interface="http://xmlns.oracle.com/
pcbpel/adapter/file/
FlatStructureIn/#wsdl.inte
rface(Read_ptt)"/>
<binding.jca config="FlatStructureIn_file.jca">
<property name="ignoreListingErrors"
type="xs:string"
many="false">true</property>
</binding.jca>
</service>
使用すると、既存のファイルに追加するアウトバウンド相互作用を構成できます。「既存のファイルに追加します」オプションを使用すると、アウトバウンド起動で同じファイルに書き込むことができます。ファイル名に追加するには、2つの方法があります。
静的 - アウトバウンドのJCAファイルに追加します。
動的 - ヘッダー・メカニズムを使用します。
注意:
SFTPシナリオの場合、追加モードはサポートされておらず、既存のファイルに追加されるかわりにファイルが上書きされます。
「ファイル構成」ページで「既存のファイルに追加します」オプションを選択すると、「メッセージ数の到達」、「経過時間の超過」、「ファイル・サイズの超過」などのバッチ処理オプションが無効になります。図4-15 に、「既存のファイルに追加します」オプションを示します。
ウィザードで「追加」を選択すると、バッチ処理オプションが無効化されます。また、静的ファイル・ネーミング規則ではなく動的ファイル・ネーミング規則を指定すると、次のエラー・メッセージが表示されます。
You cannot choose to Append Files and use a dynamic file naming convention at the same time
追加機能を使用する場合は、FTPサーバーがAPPEコマンドをサポートしていることを確認してください。
Oracle SOA Suiteの以前のバージョンでは、インバウンドではNLST(名前リスト)FTPコマンドを使用してFTPサーバーから取得したファイル名のリストを読み取っていました。ただし、NLSTコマンドはディレクトリ名を返さないため、ディレクトリ内での再帰的処理はできませんでした。現在、かわりにLISTコマンドを使用しています。
ただし、LISTコマンドによるレスポンスはFTPサーバーによって異なります。LISTコマンドに起因する微妙な差異を標準の方法に取り入れるために、次のパラメータがデプロイメント・ディスクリプタに追加されています。
defaultDateFormat: このパラメータでは、デフォルトの日付書式の値を指定します。FTPサーバー上では、これは古いファイルの値です。このパラメータのデフォルト値はMMM d yyyyです。これは、UNIX型のほとんどのFTPサーバーが古いファイルの最終変更時のタイムスタンプをMMM d yyyyの書式で返すためです。たとえば、Jan 31 2006です。
FTPコマンドライン・クライアントでls -lコマンドを使用すると、FTPサーバーのデフォルトの日付書式を確認できます。たとえば、Linuxで稼働しているvsftpdサーバーの場合、ls -lは次の結果を返します。
-rw-r--r-- 1 500 500 377 Jan 22 2005 test.txt
Microsoft Windows NT FTPサーバーの場合、defaultDateFormatはMM-dd-yy hh:mmaです。たとえば、03-24-09 08:06AM <DIR> oracleのようになります。
recentDateFormat: このパラメータでは、最新の日付書式の値を指定します。FTPサーバー上では、これは最近作成されたファイルの値です。
このパラメータのデフォルト値はMMM d HH:mmです。これは、UNIX型のほとんどのFTPサーバーが最近作成されたファイルの最終変更日付をMMM d HH:mmの書式で返すためです。たとえば、Jan 31 21:32のようになります。
FTPコマンドライン・クライアントでls -lコマンドを使用すると、FTPサーバーのデフォルトの日付書式を確認できます。たとえば、Linuxで稼働しているvsftpdサーバーの場合、ls -lは次の結果を返します。
150 Here comes the directory listing. -rw-r--r-- 1 500 500 377 Jan 30 21:32 address.txt -rw-r--r-- 1 500 500 580 Jan 3121:32 container.txt .....................................................................................
Microsoft Windows NT FTPサーバーの場合、recentDateFormatパラメータはMM-dd-yy hh:mmaというフォーマットになります。たとえば、03-24-09 08:06AM <DIR> oracleのようになります。
serverTimeZone: サーバーのタイムゾーン(America/Los_Angelesなど)です。このパラメータを空白に設定すると、実行しているサーバーのデフォルト・タイムゾーンが使用されます。
listParserKey: LISTコマンドによるレスポンスをどのように解析するかを指示します。デフォルト値はUNIXです。この場合、UNIX型FTPサーバーの一般的なパーサーを使用します。UNIX以外にサポートされている値には、Microsoft Windows NT FTPサーバーに固有のWINおよびWINDOWSがあります。
注意:
ロケール言語がFTPサーバーとオペレーティング・システムで異なる場合があります。FTPサーバーと稼働元のオペレーティング・システムのロケールが同じだと仮定しないでください。ロケールが異なる場合は、serverLocaleLanguage、serverLocaleCountryおよびserverLocaleVariantパラメータを設定する必要があります。
serverLocaleLanguage: このパラメータでは、言語のロケール・コンストラクトを指定します。
serverLocaleCountry: このパラメータでは、国のロケール・コンストラクトを指定します。
serverLocaleVariant: このパラメータでは、バリアントのロケール・コンストラクトを指定します。
通常、FTPサーバーの標準の日付書式は、FTPサーバーのインストール時に構成されます。FTPサーバーでdefaultDateFormatにMMM d yyyyの書式を、recentDateFormatにMMM d HH:mmの書式を使用する場合、その対応するデプロイメント・ディスクリプタで同じ書式を使用する必要があります。
コマンドラインFTPでls -lを入力すると、次の内容を確認できます。
200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. -rw-r--r-- 1 500 500 377 Jan 22 21:32 1.txt -rw-r--r-- 1 500 500 580 Jan 22 21:32 2.txt .................................................................................
これはFTPサーバーのrecentDateFormatパラメータであり、たとえば、MMM d HH:mm (Jan 22 21:32)のように表示されます。同様に、サーバーに古いファイルがある場合、そのサーバーでは時と分の部分が表示されず、次のように表示されます。
-rw-r--r-- 1 500 500 377 Jan 22 2005 test.txt
これはデフォルトの日付書式です。たとえば、MMM d yyyy (Jan 22 2005)のように表示されます。
さらに、特定のタイムゾーンで実行しているFTPサーバーのタイムスタンプを解析するために、serverTimeZoneパラメータが使用されます。その値には、PSTのような略称かAmerica/Los_Angelesのような完全名のいずれかが指定されます。
さらに、FTPサーバーを異なるロケールで実行している場合もあります。言語、国、バリアントによるロケールを構成するために、serverLocaleLanguage、serverLocaleCountryおよびserverLocaleVariantの各パラメータを使用します。ここで
言語は小文字2文字のISO-639コードで指定します(例: en)。
国は大文字2文字のISO-3166コードで指定します(例: US)。
バリアントはベンダーおよびブラウザ固有のコードで指定します。
これらのロケール・パラメータが指定されていない場合、システム・ロケールを使用してタイムスタンプを解析します。
さらに、FTPサーバーをSOAスイートとは異なるシステムで実行している場合は、マシン間のタイムゾーンの差異を処理する必要があります。実行しているシステムとFTPサーバーの時差をミリ秒に換算し、その値をcomposite.xmlファイルのバインディング・プロパティtimestampOffsetとして追加する必要があります。
たとえば、FTPサーバーがローカル時間よりも6時間進んでいる場合は、次のエンドポイント・プロパティをサービスまたは参照に追加する必要があります。次の例を参照してください。
例 - FTPサーバーがローカル時間よりも進んでいる場合に追加するエンドポイント・プロパティ
<service name="FTPDebatchingIn">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel
/adapter/ftp/FTPDebatchingIn/#wsdl.
interface(Get_ptt)"/>
<binding.jca config="DebatchingIn_ftp.jca">
<property name=" timestampOffset"
type="xs:string"
many="false" source=""
override="may"> 21600000</property>
</binding.jca>
</service>
LISTコマンドを適切に処理できないFTPサーバーもあります。その場合は、リスト表示にNLSTコマンドを使用します。ただし、NLSTではディレクトリを再帰的に処理できません。
NLSTコマンドを使用するには、次のプロパティをJCAファイルに追加する必要があります。次の例を参照してください。
例 - NLSTプロパティの追加
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="FTPDebatchingIn"
adapter="Ftp Adapter"
xmlns="http://platform.integration.oracle/
blocks/adapter/fw/metadata">
<connection-factory location="eis/Ftp/FtpAdapter"
UIincludeWildcard="*.txt"
adapterRef=""/>
<activation-spec
className="oracle.tip.adapter.ftp.
inbound.FTPActivationSpec">
…………………………………………..
…………………………………………..
<property name="UseNlst" value="true"/>
</activation-spec>
</endpoint-activation>
</adapter-config>
リソース・アダプタは、エンタープライズ情報システム(EIS)とのアウトバウンド接続を確立する際に、有効なセキュリティ資格証明を使用してサインオンする必要があります。J2CA 1.5仕様に従って、Oracle WebLogic Serverではアウトバウンド接続についてコンテナ管理のサインオンとアプリケーション管理のサインオンの両方がサポートされています。実行時に、Oracle WebLogic Serverは、起動するクライアント・コンポーネントのデプロイメント・ディスクリプタまたはリソース・アダプタのデプロイメント・ディスクリプタのres-auth要素で指定された情報に基づいて、選択されたサインオン・メカニズムを判別します。この項では、Oracle WebLogic Serverのコンテナ管理のサインオンを使用して、Oracle JCAアダプタのユーザー名とパスワードを保護する手順について説明します。
Oracle WebLogic ServerとEISの両方で、独立したセキュリティ・レルムが保守されます。コンテナ管理のサインオンを使用すると、Oracle WebLogic Serverにサインオンできるのみでなく、EISに別途サインオンしなくてもリソース・アダプタを介してEISにアクセスするアプリケーションを使用できます。Oracle WebLogic Serverでは、コンテナ管理のサインオンに資格証明マッピングが使用されます。Oracle WebLogicセキュリティ・プリンシパル(認証済の個別ユーザーまたはクライアント・アプリケーション)の資格証明(ユーザー名/パスワードのペアまたはセキュリティ・トークン)が、EISへのアクセスに必要な対応する資格証明にマップされます。デプロイ済の任意のリソース・アダプタに適用可能なセキュリティ・プリンシパルについて、資格証明マッピングを構成できます。
最初にコンテナ管理のサインオンを使用するには、使用する接続プールでコンテナ管理のサインオンがサポートされていることを確認する必要があります。既存の接続プールに対してコンテナ管理のサインオンを有効にする場合、またはコンテナ管理のサインオンをサポートする新規のプールを作成する場合は、次の手順を実行します。
「ドメイン構造」ペインで「デプロイメント」をクリックします。図4-16 に示すように、デプロイ済のアプリケーションとアダプタが表示されます。
図4-16 Oracle WebLogic Server管理コンソール - 「デプロイメントの概要」ページ
FtpAdapterをクリックします。図4-17 に示すように、「FtpAdapterの設定」ページが表示されます。図4-17 Oracle WebLogic Server管理コンソール - 「FtpAdapterの設定」ページ
図4-18 Oracle WebLogic Server管理コンソール - 「FtpAdapterの設定」ページ
図4-19 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ
図4-20 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ
図4-21 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ
注意:
「初期接続作成用ユーザー」および「未認証WLSユーザー」オプションの場合、資格証明マッピングはサポートされていません。
weblogicと入力します。これはデフォルト・ユーザー名です。構成によっては「構成済みユーザー名」を使用できないことがあるため、その場合は「デフォルト・ユーザー」を選択します。図4-22 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ
図4-23 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ
図4-24 Oracle WebLogic Server管理コンソール - 「FtpAdapterの設定」ページ
概念については、次の項で説明しています。
インバウンド方向では、ファイルシステムからのファイルのポーリングおよび読取りが行われて処理されます。この項では、インバウンド・ファイル読取り機能の概要を説明します。BPELプロセスで使用するように構成するには、アダプタ構成ウィザードを使用します。構成すると、インバウンドのWSDLおよびJCAファイルのペアが作成されます。
次の項では、ファイル読取りについて説明します。
図4-26 に示すアダプタ構成ウィザードの「ファイル・ディレクトリ」ページでは、インバウンド・ファイルの読取りに使用するディレクトリや、正常に処理されたファイルを配置するディレクトリの情報を指定できます。ディレクトリ内のファイルを再帰的に処理することも選択できます。さらに、複数のディレクトリも指定できます。
次の項では、指定するファイル・ディレクトリ情報について説明します。
Oracle BPEL PMが関係するコンポジットでは、インバウンドのディレクトリ名を物理パスまたは論理パスとして指定できます。物理パスはc:\inputDirのような値です。
注意:
インバウンドが着信ファイルを複数のディレクトリでポーリングするように構成されている場合は、ファイル・リーダーがこれらのディレクトリのポーリングを開始する前に、すべての最上位ディレクトリ(入力ファイルが表示されるインバウンド・ディレクトリ)が存在している必要があります。
コンポジットでは、論理プロパティはインバウンドJCAファイルで指定され、その論理/物理マッピングはバインディング・プロパティを使用して解決されます。設計時に一度論理パラメータを指定し、必要に応じて後から物理ディレクトリ名を変更できます。
たとえば、論理入力ディレクトリ名がInputFileDirの場合、生成されるインバウンドJCAファイルは次のようになります。
例 - 生成されたインバウンド.jcaファイル
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="FlatStructureIn"
adapter="File Adapter"
xmlns="http://platform.integration.oracle/
blocks/adapter/fw/metadata">
<connection-factory location="eis/FileAdapter"
UIincludeWildcard="*.txt"
adapterRef=""/>
<endpoint-activation operation="Read">
<activation-spec
className="oracle.tip.adapter.file.
inbound.FileActivationSpec">
<property name="UseHeaders" value="false"/>
<property name="LogicalDirectory"
value="InputFileDir"/>
<property name="Recursive" value="true"/>
<property name="DeleteFile" value="true"/>
<property name="IncludeFiles" value=".*\.txt"/>
<property name="PollingFrequency" value="10"/>
<property name="MinimumAge" value="0"/>
<property name="OpaqueSchema" value="false"/>
</activation-spec>
</endpoint-activation>
</adapter-config>
composite.xmlファイルで、対応する論理ActivationSpecまたはInteractionSpecの物理パラメータ値(この場合はディレクトリ・パス)を指定します。これにより、論理ディレクトリ名と実際の物理ディレクトリ名のマッピングが解決されます。次の例を参照してください。
例 - 対応するActivationSpecまたはInteractionSpecのディレクトリ・パスの指定
<service name="FlatStructureIn">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel/
adapter/file/FlatStructureIn/#wsdl.
interface(Read_ptt)"/>
<binding.jca config="FlatStructureIn_file.jca">
<property name=" InputFileDir" type="xs:string"
many="false" source=""
override="may"> /home/user/inputDir</property>
</binding.jca>
</service>
このオプションでは、正常に処理されたファイルを配置するディレクトリを指定できます。また、アーカイブ・ディレクトリを論理名として指定できます。この場合は、「SOAコンポジットでのインバウンドの物理または論理ディレクトリ・パスの指定」で説明されている論理ディレクトリから物理ディレクトリへのマッピングを行う必要があります。
図4-27 に示すアダプタ構成ウィザードの「ファイルのフィルタ処理」ページでは、取得または無視するファイルの詳細を指定できます。
インバウンド方向のファイル・リスナーとして機能します。ローカルまたはリモートのファイルシステム上の指定したディレクトリがポーリングされ、指定したネーミング基準に一致するファイルが検索されます。
次の項では、指定するファイル・フィルタ処理情報について説明します。
インバウンド・ファイルのポーリングに使用するネーミング規則を指定します。また、処理対象外にするファイルのネーミング規則も指定できます。2つのネーミング規則を選択できます。インバウンド・ディレクトリに配置されるファイルと一致します。
ファイル・ワイルドカード(po*.txt)
poで始まり.txtで終わるすべてのファイルが取得されます。この規則はWindowsオペレーティング・システムの標準に準拠しています。
正規表現(po.*\.txt)
poで始まり.txtで終わるすべてのファイルが取得されます。この規則は、Java Development Kit (JDK)の正規表現(regex)構文に準拠しています。
注意:
後から別のネーミング・パターンを選択する場合は、「インクルード・ファイルの名前パターン」および「処理対象外ファイルの名前パターン」フィールドで指定するネーミング規則も変更してください。アダプタ構成ウィザードにより自動的に変更されることはありません。
ファイルを取得する際、検索対象として*.*を指定しないでください。
オペレーティング・システムにより設定されているファイルの長さの制限に注意してください。たとえば、Windowsオペレーティング・システムでは、ファイル名(ファイル名と完全なディレクトリ・パスを合せた長さ)を256文字より長くできません。制限によりファイル名に特定の文字を使用できないオペレーティング・システムもあります。たとえば、Windowsオペレーティング・システムでは、バックスラッシュ(\)、スラッシュ(/)、コロン(:)、アスタリスク(*)、左角カッコ(<)、右角カッコ(>)または縦線(|)などの文字は許可されていません。
正規表現を使用する場合、「インクルード・ファイルの名前パターン」および「処理対象外ファイルの名前パターン」フィールドで指定する値は、JDKの正規表現(regex)構文に準拠している必要があります。どちらのフィールドにも、異なるregexパターンを別々に指定する必要があります。「インクルード・ファイルの名前パターン」フィールドおよび「処理対象外ファイルの名前パターン」フィールドは、インバウンドWSDLファイルのIncludeFilesおよびExcludeFilesパラメータに対応します。
注意:
regexパターンはJDK regexパターンに準拠しています。JDK regexパターンに準じると、任意の文字列が任意の回数発生するパターンの正しいコノテーションはピリオドとプラス記号です(.+)。JDK regexでは、アスタリスク(*)は任意の文字が任意の回数発生する文字列のプレースホルダではありません。
インバウンドで、poで始まり、拡張子がtxtであるすべてのファイル名を取得するには、名前パターンが正規表現である場合は、「インクルード・ファイルの名前パターン」フィールドでpo.*\.txtとして指定する必要があります。次にこのregexパターンの例で使用された記号の意味を示します。
ピリオド(.)は任意の文字を表します。
アスタリスク(*)は任意の発生数を表します。
ピリオドが続くバックスラッシュ(\.)は、エスケープ文字のバックスラッシュで示されているように、文字としてのピリオド(.)を表します。
「処理対象外ファイルの名前パターン」フィールドも同様に構成します。
「インクルード・ファイルの名前パターン」フィールドと「処理対象外ファイルの名前パターン」フィールドの式に重複がある場合、処理対象外ファイルの式が優先されます。たとえば、「インクルード・ファイルの名前パターン」がabc*.txtに設定され、「処理対象外ファイルの名前パターン」がabcd*.txtに設定されている場合、abcd*.txtファイルは受信されません。
注意:
「インクルード・ファイルの名前パターン」フィールドには名前パターンを入力する必要があり、空白のままにすることはできません。入力しなかった場合、インバウンド・アダプタ・サービスはインバウンド・ディレクトリ内に存在するすべてのファイルを読み取り、不正な結果を招きます。
表4-4 にJava regex構文の詳細を示します。
注意:
JDK regexのパターン名を、プラス記号(+)、疑問符(?)またはアスタリスク(*)で始めることはできません。
表4-4 Javaの正規表現構文
| 一致対象 | 構文 |
|---|---|
文字 |
- |
文字 |
|
バックスラッシュ文字 |
|
8進数値 |
|
8進数値 |
|
8進数値 |
|
16進数値 |
|
16進数値 |
|
タブ文字 |
|
改行文字 |
|
キャリッジ・リターン文字 |
|
用紙送り文字 |
|
警告(ベル)文字 |
|
エスケープ文字 |
|
|
|
- |
- |
文字クラス |
- |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- |
- |
定義済の文字クラス |
- |
任意の文字(行の終了文字と一致する場合もある) |
- |
数字: |
|
数字以外: |
|
空白文字: |
|
空白文字以外: |
|
単語文字: |
|
単語以外の文字: |
|
最長一致数量子 |
- |
|
|
|
|
|
|
|
|
|
|
|
|
Java regex構文の詳細は、次のサイトを参照してください。
FileList操作ではjava.file.IncludeFilesプロパティは公開されません。このプロパティは、次の例に示すように、アダプタ相互作用の設計中に構成され、ヘッダーを通じてオーバーライドすることはできません。
例 - FileList操作のオーバーライド
<adapter-config name="ListFiles" adapter="File Adapter" xmlns="http://platform.integration.oracle
/blocks/adapter/fw/metadata">
<connection-factory location="eis/FileAdapter"
UIincludeWildcard="*.txt"
adapterRef=""/>
<endpoint-interaction portType="FileListing_ptt"
operation="FileListing">
<interaction-spec className=
"oracle.tip.adapter.file.outbound.
FileListInteractionSpec">
<property name="PhysicalDirectory"
value="%INP_DIR%"/>
<property name="PhysicalDirectory"
value="%INP_DIR%"/>
<property name="Recursive" value="true"/>
<property name="Recursive"
value="true"/>
<property name="IncludeFiles"
value=".*\.txt"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
この例では、いったん設定されたIncludeFilesは変更できません。
複数のメッセージが含まれるファイルを着信するかどうかを選択し、パブリッシュする1つのバッチ・ファイルに含まれるメッセージ数を指定できます。ファイルに反復要素を含むメッセージが含まれる場合、特定のバッチ数でメッセージをパブリッシュするように選択できます。図4-27を参照してください。
ファイルに複数のメッセージがありチェック・ボックスが選択されている場合は、デバッチ処理が行われます。デバッチ処理が行われないのは、ファイルのメッセージが1つのみでチェック・ボックスが選択されていない場合です。ネイティブ・ファイルとXMLファイルではデバッチ処理がサポートされています。
図4-28 に示すアダプタ構成ウィザードの「ファイル・ポーリング」ページでは、次に示すインバウンド・ポーリング・パラメータを指定できます。
新しいファイルを取得するためにインバウンド・ディレクトリをポーリングする頻度。
取得するファイルの最短経過時間。たとえば、このポーリング・パラメータにより、大きなファイルが処理用に取得される前に、ディレクトリに完全にコピーできるようになります。経過時間は最終更新時のタイムスタンプで決定されます。たとえば、ファイルの書込みに3分から4分かかることがわかっている場合は、最短経過時間を5分に設定します。入力ディレクトリでファイルが検出されても、更新時間から5分経過していない場合、まだ書込みが行われている可能性があるためファイルは取得されません。
注意:
JCAファイル内のpollingパラメータの値を手動で変更しないでください。このパラメータを変更するには、アダプタ構成ウィザードを使用する必要があります。
デフォルトでは、エンドポイントがアクティブ化されると、インバウンドのOracleファイル/FTPアダプタによるポーリングが開始されます。ただし、より厳密にポーリングを制御する場合は、ファイルベースのトリガーを使用できます。Oracleファイル/FTPアダプタでは、指定のトリガー・ファイルがローカル・ディレクトリまたはリモート・ディレクトリで検出されると、そのファイルのポーリングがインバウンド・ディレクトリ内で開始されます。
たとえば、あるBPELプロセスがファイルをディレクトリに書き込んでおり、第2のBPELプロセスが同じディレクトリでファイルをポーリングしているとします。第1のプロセスによる全ファイルの書込みが完了した後でのみ、第2のプロセスによるディレクトリのポーリングを開始するために、トリガー・ファイルを使用できます。第1のプロセスを、最後にトリガー・ファイルを作成するように構成できます。第2のプロセスは、トリガー・ファイルを検出した後でインバウンド・ディレクトリのポーリングを開始します。
注意:
トリガー・ファイルのライフサイクルは、アダプタでは管理されません。トリガー・ファイルは外部で管理する必要があります。たとえば、エンドポイントをアントリガーし、外部アプリケーションを使用してトリガー・ファイルを削除して、TriggerFileStrategyをEndpointActivationまたはEveryTimeに指定します。トリガー・ファイル・ディレクトリは、インバウンドのポーリング・ディレクトリと同一でなくてもかまいません。ただし、トリガー・ファイル・ディレクトリおよびインバウンドのポーリング・ディレクトリが同じ場合は、図4-27 に示すように、トリガー・ファイルの名前がアダプタ構成ページで指定したファイル・フィルタに類似していないことを確認する必要があります。
トリガー・ファイルの内容が読み取られることはないため、インバウンドのreceiveアクティビティのペイロードとして使用しないでください。
表4-5 に、インバウンド・サービスのJCAファイルに指定する必要があるパラメータを示します。
表4-5 トリガー・ファイルのパラメータ
| パラメータ | 説明 | 例 |
|---|---|---|
または
|
Oracleファイル/FTPアダプタがトリガー・ファイルを検索するディレクトリの物理名または論理名。
|
|
|
トリガー・ファイル名。 |
|
|
トリガー・メカニズムとして使用される戦略。次の値をとります。 EndpointActivation: アダプタは、コンポジットがアクティブ化されるたびにトリガー・ファイルを検索します。注意: コンテナの起動、アプリケーションの再デプロイ、Fusion Middleware Controlによるコンポジット・アプリケーションのリタイアまたはアクティブ化を行うたびに、コンポジットがアクティブ化されます。 コンテナを再起動するたびに、指定されたディレクトリでトリガー・ファイルが検出されるまでコンポジット・アプリケーションはトリガーされません。 OnceOnly: アダプタは、その存続期間で1回のみトリガー・ファイルを検索します。検出されたトリガー・ファイルは、再起動後および再デプロイ後も記憶されます。 EveryTime: アダプタは、各ポーリング・サイクルでトリガー・ファイルを検索します。 |
|
インバウンド・サービスにおけるJCAファイルのサンプルを次に示します。
例 - インバウンド・サービスのサンプルの.jcaファイル
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="FlatStructureIn" adapter="File Adapter"
xmlns="http://platform.integration.oracle/
blocks/adapter/fw/metadata">
<connection-factory
location="eis/FileAdapter"
UIincludeWildcard="*.txt"
adapterRef=""/>
<endpoint-activation operation="Read">
<activation-spec className=
"oracle.tip.adapter.file.
inbound.FileActivationSpec">
<property.../>
<property name=
"TriggerFilePhysicalDirectory"
value="/tmp/flat/ArchiveDir"/>
</activation-spec>
</endpoint-activation>
</adapter-config>
次に表示されるアダプタ構成ウィザードのページは、図4-29 の「メッセージ」ページです。このページでは、変換用のXSDスキーマ・ファイルを選択できます。
ネイティブ・フォーマット変換が不要である場合は(JPGまたはGIFイメージが処理中であるなど)、「ネイティブ・フォーマット変換は不要」チェック・ボックスを選択します。ファイルはBase64エンコーディングで渡されます。
トランスレーションにはXSDファイルが必要です。新しいスキーマの定義、または既存のデータ型定義(DTD)やCOBOLコピーブックの変換を行うには、「ネイティブ・フォーマットのスキーマの定義」を選択します。これにより、ネイティブ・フォーマット・ビルダー・ウィザードが起動されます。このウィザードは、カンマ区切り値(CSV)、固定長、DTDおよびCOBOLコピーブックなどのファイル形式を使用したネイティブ・スキーマ・ファイルの作成を支援します。ネイティブ・スキーマ・ファイルの作成後、「スキーマ・ファイルのURL」および「スキーマ要素」フィールドが入力された「メッセージ」ページが表示されます。詳細は、「サポートされているファイル形式」を参照してください。
注意:
指定するスキーマにネームスペースが含まれていることを確認してください。スキーマにネームスペースがないと、エラー・メッセージが表示されます。
構成が終了すると、インバウンド・サービスのJCAファイルが生成されます。ファイル名は、アダプタ構成ウィザードの「サービス名」ページで指定したサービス名と同じです。後からウィザードを再起動して、操作定義を変更できます。
ActivationSpecパラメータには、インバウンド構成情報が含まれています。ActivationSpecと一連のインバウンド・プロパティは、インバウンドJCAファイルの一部です。
表4-6 に、インバウンドJCAファイルのサンプルのプロパティを示します。
表4-6 インバウンド・サービスのサンプルのJCAプロパティ
| プロパティ | サンプル値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ActivationSpecプロパティの値は、設計時にアダプタ構成ウィザードで指定されます(表4-6 を参照)。インバウンドでは次の構成プロパティを表使用します。
PollingFrequency
MinimumAge
PhysicalDirectory
LogicalDirectory
PublishSize
PhysicalArchiveDirectory
LogicalArchiveDirectory
IncludeFiles
ExcludeFiles
UseHeaders
ListSorter
ThreadCount
Recursive
MaxRaiseSize
これらの構成プロパティの説明は、このマニュアルの付録Aを参照してください。
図4-30に示すように、ペイロードを除いて、次のヘッダー・メタデータをインバウンド・サービスからパブリッシュします。
jca.file.FileName: ファイル名
jca.file.Directory: ディレクトリ名
jca.file.Batch: デバッチ処理におけるバッチの一意の名前
jca.file.BatchIndex: デバッチ処理におけるバッチ内の各メッセージのバッチ索引
jca.file.Size: ファイル・サイズ
jca.file.LastModifiedTime: ファイルの最終変更時間
アウトバウンド方向では、サービス・エンジンからのメッセージを受信し、ファイルシステムのファイルに書き込みます。この項では、アウトバウンド・ファイル書込み機能の概要を説明します。BPELプロセスまたはサービスで使用するように構成するには、アダプタ構成ウィザードを使用します。これにより、アウトバウンドのWSDLとJCAのファイルのペアが作成されます。
この項には次のトピックが含まれます:
アウトバウンド操作では、図4-31に示すように「Write File」操作を選択します。
「出力ヘッダーの追加」チェック・ボックスは、「Write File」を選択した場合に表示されます。このチェック・ボックスを選択すると、アダプタWSDLに、ヘッダー・スキーマをポイントする出力メッセージが含められます(太字で示されます)。
例 - スキーマをポイントする出力メッセージを含むアダプタWSDL
<wsdl:definitions name="fileout3"
targetNamespace="http://xmlns.oracle.com/pcbpel
/adapter/file/SOAApp1/NewJCAFmwk/
fileout3"
xmlns:jca="http://xmlns.
oracle.com/pcbpel/wsdl/jca/"
xmlns:FILEAPP="http://xmlns.oracle.com
/pcbpel/adapter/file/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://xmlns.oracle.com/pcbpel
/adapter/file/SOAApp1/NewJCAFmwk/
fileout3"
xmlns:plt="http://schemas.xmlsoap.org/ws
/2003/05/partner-link/">"
xmlns:opaque=
"http://xmlns.oracle.com/
pcbpel/adapter/opaque/"
<plt:role name="Write_role" >
<plt:portType name="tns:Write_ptt" />
</plt:role>
</plt:partnerLinkType>"
<wsdl:types>
<schema TargetNamespace=
"http://xlmns.oracle.com/pcbpel/
adapter/opaque/"
xmlns:opaque="http://xmlns.oracle.com
/pcbpel/adapter/opaque/"
xmlns="http://www.w3.org/2001/XMLSchema" >
<element name="opaqueElement"
type="base64Binary" />
</schema>
<schema targetNamespace=
"http://xmlns.oracle.com/pcbpel/
adapter/file/"
xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified"
<element name="OutboundFileHeaderType" >
<complexType>
<sequence>
<element name="filename" type="string" />
<element name="directory" type="string" />
</sequence>
</complexType>
</element>
</schema>
</wsdl:types>
<wsdl:message name="Write_msg">
<wsdl:part name="opaque" element=
"opaque:opaqueElement"/>
</wsdl:message>
<wsdl:message name="Output_msg">
<wsdl:part name="body"
element=
"FILEAPP:OutboundFileHeaderType"/>
</wsdl:message>
<wsdl:portType name="Write_ptt">
<wsdl:operation name="Write">
<wsdl:input message="tns:Write_msg"/>
<wsdl:output message="tns:Output_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
編集モードで出力ヘッダーの更新チェック・ボックスを選択すると、出力メッセージ/ヘッダー・スキーマがアダプタWSDLから削除されます。
アウトバウンド操作では、アウトバウンド・ディレクトリ、使用するアウトバウンド・ファイル・ネーミング規則、および必要な場合は使用するバッチ・ファイル規則も指定できます。
図4-32 に示すアダプタ構成ウィザードの「ファイル構成」ページでは、発信ファイルのディレクトリやアウトバウンド・ファイル・ネーミング規則を指定できます。
次の項では、指定するファイル構成情報について説明します。
アウトバウンド・ディレクトリ名を物理または論理パスとして指定できます。物理パスはc:\outputDirのような値です。
論理アウトバウンド・ディレクトリ名がOutputFileDirの場合、論理パラメータを指定すると、生成されるJCAファイルは次のようになります。次の例を参照してください。
例 - サンプルの論理アウトバウンド・ディレクトリに対して生成されるJCAファイル
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="FlatStructureOut"
adapter="File Adapter"
xmlns="http://platform.integration.
oracle/blocks/
adapter/fw/metadata">
<connection-factory location="eis/FileAdapter"
adapterRef=""/>
<endpoint-interaction operation="Write">
<interaction-spec
className="oracle.tip.adapter.file.outbound.
FileInteractionSpec">
<property name="LogicalDirectory"
value="OutputFileDir"/>
<property name="FileNamingConvention"
value="%yyMMddHHmmssSS%_%SEQ%_
%yyyyMMdd%_%SEQ%.out.%SEQ%"/>
<property name="Append" value="false"/>
<property name="NumberMessages" value="1"/>
<property name="OpaqueSchema" value="false"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
JDeveloperウィザードの「外部参照」スイムレーンでアウトバウンド・アダプタを選択します(composite.xmlのタブに表示されます)。アウトバウンド・アダプタの「プロパティ・インスペクタ」でバインディング・プロパティを作成します(下方向にスクロールして表示する必要があります)。「プロパティの作成」ボックスが表示されてから、「名前」フィールドにOutputFileDirと入力し、「値」フィールドに実際の出力ディレクトリ名(例: C:\outputDir)を入力します。composite.xmlファイルが表示されます。次の例を参照してください。
例 - アウトバウンド・ディレクトリが指定されたプロパティの作成
<reference name="FlatStructureOut">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel/adapter
/file/FlatStructureOut/
#wsdl.interface(Write_ptt)"/>
<binding.jca config="FlatStructureOut_file.jca">
<property name="OutputFileDir"
type="xs:string" many="false"
override="may">C:\outputDir
</property>
</binding.jca>
</reference>
注意:
アウトバウンド・ファイル名の長さ(ファイル名と完全なディレクトリ・パスを合せた長さ)は200文字に制限してください。これは厳密な制限ではありませんが推奨事項です。アウトバウンド・ファイル名が長い場合(215文字など)、その名前を持つ空白のファイルがアウトバウンド・ディレクトリに作成されます。
アウトバウンド・ディレクトリ名を物理または論理パスとして指定できます。物理パスはc:\inputDirのような値です。
図4-26 に示すように、「ファイル・ディレクトリ」ページで設計時に論理名を指定し、「エンドポイント・プロパティ」で論理/物理マッピングを指定できます。たとえば、WriteFileはアウトバウンド・アダプタ・サービスです。設計時には、論理ディレクトリ名としてOutDirを指定しています。
アウトバウンド操作の場合は、動的なアウトバウンド・ディレクトリ名を指定できます。変数を設定すると、動的なアウトバウンド・ディレクトリ名を指定できます。
例 - 変数の設定による動的なアウトバウンド・ディレクトリ名の指定
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="ReadAddressChunk"
adapter="File Adapter"
xmlns="http://platform.integration.oracle
/blocks/adapter/fw/metadata">
<connection-factory location="eis/FileAdapter"
adapterRef=""/>
<endpoint-interaction operation="ChunkedRead">
<interaction-spec
className=
"oracle.tip.adapter.file.outbound.
ChunkedInteractionSpec">
<property name=
"PhysicalDirectory" value="C:\foo"/>
<property name="FileName" value="dummy.txt"/>
<property name="ChunkSize" value="1"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
この例では、JCAファイルで物理ディレクトリが"C:\foo"に設定されていますが、実行時、このディレクトリ名は割り当てられた値に動的に変更されます。この例では、物理ディレクトリは動的に"C:\out"に変更されます。
動的なアウトバウンド・ディレクトリ名を指定するには、次の手順を実行します。
xsd:stringの変数MyDirを作成します。
jca.file.Directoryプロパティを選択し、「値」をMyDir (ステップ4で作成したディレクトリ)に設定します。図4-35 に示すように、「タイプ」列がinputに設定されていることを確認してください。注意:
動的ディレクトリを使用する場合は、NumberMessages、ElapsedTime、FileSizeなどのパラメータがアウトバウンド・アダプタ・サービスのWSDLファイルで定義されていないことを確認してください。これらのパラメータは、動的ディレクトリではサポートされていません。
発信ファイルに使用するネーミング規則を指定します。po.txtなどの完全に静的な名前は入力できません。これは発信ファイル名の一意性を保つためで、ファイルが意図せず上書きされるのを防ぎます。そのかわり、発信ファイル名は静的部分と動的部分で構成されている必要があります。
図4-32 に示したファイルの例では、接頭辞と接尾辞の部分は静的です(例: po_および.xml)。名前の%SEQ%変数は動的部分で、順序番号やタイムスタンプ(タイムスタンプのファイルを作成する場合の変数はpo_%yyMMddHHmmss%.xml)になります。
発信ファイルのネーミング規則として、po_で始まり順序番号と拡張子txtが続く名前を選択する場合には、po_%SEQ%.txtと指定する必要があります。
発信ファイルのネーミング規則として、po_で始まりyyyy.MM.ddというパターンのタイムスタンプと拡張子txtが続く名前を選択する場合には、po_%yyyy.MM.dd%.txtと指定する必要があります。たとえば、発信ファイル名はpo_2004.11.29.txtになります。
さらに、ファイル・ネーミング規則を組み合せることもできます。たとえば、po_%SEQ%_%yyyy.MM.dd%_%SEQ%.txtのようにファイル・ネーミング規則を指定できます。
注意:
タイムスタンプ・パターンの使用時に、後続のコールで同じタイムスタンプが生成されてメッセージが失われることがあります。その解決策は、タイムスタンプ・パターンを順序パターンと組み合せることです。または、ミリ秒に最も近いタイムスタンプ・パターンを使用することもできます。その場合、アダプタはファイル名の一意性に対処します。
アウトバウンドの同期的読取りには正規表現を使用できません。そのような場合には、正確なファイル名がわかっている必要があります。
タイムスタンプは日付と時間のパターンの文字列で指定します。日時パターン文字列内では、引用符で囲まれていない'A' - 'Z'および'a' - 'z'は、日付または時間文字列のコンポーネントを表すパターン文字として解釈されます。テキストは、解釈されないように一重引用符(')で囲むことができます。文字''は一重引用符を表します。その他すべての文字は解釈されません。
表4-7 にJavaのパターン文字の定義を示します。
表4-7 Javaのパターン文字
| 文字 | 日付または時刻のコンポーネント | 表示内容 | 例 |
|---|---|---|---|
|
紀元 |
テキスト |
|
|
年 |
年 |
|
|
年における月 |
月 |
|
|
年における週 |
数値 |
|
|
月における週 |
数値 |
|
|
年における日 |
数値 |
|
|
月における日 |
数値 |
|
|
月における曜日 |
数値 |
|
|
曜日 |
テキスト |
|
|
午前/午後 |
テキスト |
|
|
1日における時間(0-23) |
数値 |
|
|
1日における時間(1-24) |
数値 |
|
|
午前/午後における時間(0-11) |
数値 |
|
|
午前/午後における時間(1-12) |
数値 |
|
|
1時間における分 |
数値 |
|
|
1分における秒 |
数値 |
|
|
ミリ秒 |
数値 |
|
|
タイムゾーン |
一般的なタイムゾーン |
|
|
タイムゾーン |
RFC 822タイムゾーン |
|
次にパターンの異なる表示内容を示します。
テキスト
書式設定において、パターン文字が4文字以上の場合は、完全な表記が使用されます。それ以外の場合、可能であれば、省略表記が使用されます。解析では、パターン文字の数にかかわらず、どちらの表記も使用できます。
数値
書式設定において、パターン文字の数は最小桁数になり、これに満たない場合は最小桁数まで0が表示されます。解析において、2つの隣接したフィールドを区別する必要がない場合、パターン文字の数は無視されます。
年
書式設定において、パターン文字が2文字の場合は、年は2桁に切り捨てられます。それ以外の場合は数値として解釈されます。
解析において、パターン文字が3文字以上の場合は、桁数にかかわらず、年は文字どおりに解釈されます。パターンMM/dd/yyyyを使用すると、01/11/12はJan 11, 12 A.D.と解析されます。
年のパターンが省略されている(yまたはyy)解析において、省略された年は複数の世紀に対して解釈されます。日付は、時間インスタンス作成の80年前から20年後までの間の日付に調整されます。たとえば、パターンMM/dd/yyを使用してJan 1, 1997を作成した場合、文字列05/04/64がMay 4, 1964と解釈される一方で、文字列01/11/12はJan 11, 2012と解釈されます。解析中、数字が2つ含まれる文字列のみがデフォルトの世紀に解析されます。1桁の文字列、3桁以上の文字列またはすべてが数字ではない2桁の文字列(たとえば-1)など、それ以外の数値文字列は文字どおりに解釈されます。そのため、01/02/3または01/02/003は、同じパターンを使用してJan 2, 3 ADと解析されます。また、01/02/-3はJan 2, 4 BCと解析されます。
月
パターン文字が3桁以上の場合、月はテキストとして解釈されます。それ以外の場合は数値として解釈されます。
一般的なタイムゾーン
タイムゾーンに名前がある場合はテキストとして解釈されます。GMTオフセット値を表すタイムゾーンの場合、次の構文が使用されます。
GMTOffsetTimeZone:
GMTSign Hours:Minutes
Sign: one of
+ -
Hours:
Digit
Digit Digit
Minutes:
Digit Digit
Digit: one of
0 1 2 3 4 5 6 7 8 9
Hoursは0から23の間で、Minutesは00から59の間です。書式設定はロケールに依存せず、数字はUnicode標準のBasic Latinブロックから取得する必要があります。
解析では、RFC 822タイムゾーンも使用できます。
書式設定では、RFC 822の4桁のタイムゾーンが使用されます。
RFC822TimeZone:
Sign TwoDigitHours Minutes
TwoDigitHours:
Digit Digit
TwoDigitHoursは00から23の間である必要があります。その他の定義は、一般的なタイムゾーンと同じです。
解析では、一般的なタイムゾーンも使用できます。
アウトバウンド操作の場合は、動的なアウトバウンド・ファイル名を指定できます。変数を設定すると、動的なアウトバウンド・ファイル名を指定できます。
例 - 変数の設定による動的なアウトバウンド・ファイル名の指定
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="ReadAddressChunk"
adapter="File Adapter"
xmlns="http://platform.integration.oracle/blocks
/adapter/fw/metadata">
<connection-factory location=
"eis/FileAdapter"
adapterRef=""/>
<endpoint-interaction operation
="ChunkedRead">
<interaction-spec
className="oracle.tip.adapter.file.outbound.
ChunkedInteractionSpec">
<property name="PhysicalDirectory"
value="C:\foo"/>
<property name="FileName"
value="dummy.txt"/>
<property name="ChunkSize" value="1"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
この例では、JCAファイルで物理ディレクトリが"C:\foo"に設定されていますが、実行時、このディレクトリ名は割り当てられた値に動的に変更されます。この例では、物理ディレクトリは動的に"C:\out"に変更されます。動的なアウトバウンド・ディレクトリ名を指定するには、次の手順を実行します。
jca.file.FileNameプロパティを選択し、「値」をfile(ステップ4で作成したファイル)に設定します。図4-36 に示すように、「タイプ」列がinputに設定されていることを確認してください。注意:
動的ファイルを使用する場合は、NumberMessages、ElapsedTime、FileSizeなどのパラメータがアウトバウンド・アダプタ・サービスのWSDLファイルで定義されていないことを確認してください。これらのパラメータは、動的ファイルではサポートされていません。
最も簡単なシナリオの場合、1つのメッセージに1つのファイルの書込みを指定します。また、バッチ・ファイル書込みに関するアウトバウンドの規則も指定できます。これにより、1つのバッチ・ファイルでパブリッシュするメッセージ数を指定できます。次に示すバッチ・ファイルの設定は、図4-32 の「ファイル構成」ページで指定されています。
メッセージ数の到達
到達した際に新しい発信ファイルを作成する値を指定します。
経過時間の超過
超過した際に新しい発信ファイルを作成する値を指定します。
注意:
「経過時間の超過」バッチ処理基準が評価されて新しい発信ファイルが作成されるのは、起動の発生時のみです。
たとえば、「経過時間の超過」を15秒に指定した場合、最初に受信したメッセージは、バッチ処理条件が有効でないため15秒が経過しても書き込まれません。第2のメッセージを受信すると、第1のメッセージに対してバッチ処理条件が有効になり、経過時間が15秒を超過した時点で出力ファイルが作成されます。
ファイル・サイズの超過
到達した際に発信ファイルを作成するファイル・サイズを指定します。たとえば、受信したメッセージ数に3を、ファイル・サイズに1MBという値を指定したとします。合計すると1MB以上になる2つのメッセージや、1MBに満たない3つのメッセージを受信した場合に、出力ファイルが作成されます。
注意:
JCAファイル内の前述のリストに指定されているファイル構成を手動で変更しないでください。これらの構成を変更するには、アダプタ構成ウィザードを使用する必要があります。
バッチ処理中に問題が発生した場合、リカバリでは中断した場所からバッチ処理が開始されます。
次に表示されるアダプタ構成ウィザードのページは、図4-37 に示す「メッセージ」ページです。このページでは、変換用のXSDスキーマ・ファイルを選択できます。
インバウンド方向のスキーマの指定と同様に、このページでは次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、「ネイティブ・データ変換」を参照してください。
アダプタ構成ウィザードを使用した構成が完了すると、アウトバウンド操作用のWSDLとJCAのファイルのペアが生成されます。ファイル名は、図2-8 に示すアダプタ構成ウィザードの「サービス名」ページで指定したサービス名と同じです。後からウィザードを再起動して、操作定義を変更できます。
サンプルのアウトバウンドJCAファイルには、表4-8 に記載されている情報が格納されます。
表4-8 アウトバウンド・サービスのサンプルのJCAプロパティ
| プロパティ | サンプル値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
アウトバウンドでは、次の構成パラメータが使用されます。
PhysicalDirectory
LogicalDirectory
NumberMessages
ElapsedTime
FileSize
FileNamingConvention
Append
これらの構成プロパティの詳細は、「Oracle JCAアダプタのプロパティ」を参照してください。
アウトバウンド方向では、Oracleファイル/FTPアダプタは1つのファイルのコンテンツを読み取ることができます。この項では、アウトバウンドの同期ファイル読取り機能の概要について説明します。ファイルを同期的に読み取るには、図4-38 に示すように「同期Read File」操作を選択します。
アウトバウンド方向では、Oracleファイル/FTPアダプタを使用すると、同期ファイル読取り操作を使用して1つのファイルのコンテンツを読み取ることができます。この操作により、ファイルを添付ファイルとして読み取ることができるようになりました。ファイルを添付ファイルとして読み取るためのチェック・ボックスを選択します。添付ファイルに対する残りのオプションは任意指定であり、サービス・エンジンでこれらの情報が必要な場合に役立ちます。
アダプタ構成ウィザードのページの多くは、「ファイル名」ページを除いて、ファイル読取り操作の場合と同様です。図4-39 に示すように、「ファイル名」フィールドでは読み取るファイルの名前を指定できます。
この機能では、BPELアクティビティを使用してターゲット・ディレクトリからファイルのリストを取得します。このファイルのリストはXML文書として返され、ファイル名、ディレクトリ名、ファイル・サイズ、最終変更時間などの情報が記載されています。この項では、ファイル・リスティング機能の概要について説明します。BPELプロセスまたはサービスで使用するように構成するには、アダプタ構成ウィザードを使用します。これにより、アウトバウンドのWSDLとJCAのファイルのペアが作成されます。
注意:
標準Java APIには作成時間を取得するためのメカニズムがないため、ファイル作成時間プロパティcreationTimeはサポートされていません。creationTimeプロパティの値は常に0として表示されます。
例:
<creationTime xmlns="http://xmlns.oracle.com /pcbpel/adapter/file/FAListFiles/FAListFilesTest/ReadS/"> 0</creationTime>
この項には次のトピックが含まれます:
図4-41 に示すアダプタ構成ウィザードの「ファイル・ディレクトリ」ページでは、リスト表示操作のファイル名の読取りに使用するディレクトリの情報を指定できます。ディレクトリ内のファイルを再帰的にリスト表示することもできます。
次の項では、指定するファイル・ディレクトリ情報について説明します。
Oracle BPEL PMが関係するコンポジットでは、ディレクトリ名を物理パスまたは論理パスとして指定できます。物理パスはC:\inputDirのような値です。
コンポジットでは、論理プロパティはJCAファイルで指定され、その論理/物理マッピングはバインディング・プロパティを使用して解決されます。設計時に必要なディレクトリを指定し、必要に応じて後からディレクトリ名を変更できます。
たとえば、論理入力ディレクトリ名がC:\inputDirの場合、生成されるJCAファイルは次のようになります。
例 - 論理入力ディレクトリに対して生成される.jcaファイル
<adapter-config name="ListFiles"
adapter="File Adapter"
xmlns="http://platform.integration.oracle
/blocks/adapter/fw/metadata">
<connection-factory location="eis/FileAdapter"
UIincludeWildcard="*.txt"
adapterRef=""/>
<endpoint-interaction portType="FileListing_ptt"
operation="FileListing">
<interaction-spec
className="oracle.tip.adapter.file.
outbound.FileListInteractionSpec">
<property name="PhysicalDirectory"
value="C:\inputDir"/>
<property name="Recursive" value="true"/>
<property name="IncludeFiles" value=".*\.txt"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
図4-42 に示すアダプタ構成ウィザードの「ファイルのフィルタ処理」ページでは、取得または無視するファイルの詳細を指定できます。
ファイル・リスナーとして機能し、ローカルまたはリモートのファイルシステムの指定されたディレクトリをポーリングして、指定されたネーミング基準に一致するファイルを検索します。
次の項では、指定するファイル・フィルタ処理情報について説明します。
インバウンド・ファイルのポーリングに使用するネーミング規則を指定します。また、処理対象外にするファイルのネーミング規則も指定できます。2つのネーミング規則を選択できます。インバウンド・ディレクトリに配置されるファイルと一致します。
ファイル・ワイルドカード(po*.txt)
poで始まり.txtで終わるすべてのファイルが取得されます。この規則はオペレーティング・システムの標準に準拠しています。
正規表現(po.*\.txt)
poで始まり.txtで終わるすべてのファイルが取得されます。この規則は、Java Development Kit (JDK)の正規表現(regex)構文に準拠しています。
注意:
後から別のネーミング・パターンを選択する場合は、「インクルード・ファイルの名前パターン」および「処理対象外ファイルの名前パターン」フィールドで指定するネーミング規則も変更してください。アダプタ構成ウィザードにより自動的に変更されることはありません。
ファイルを取得する際、検索対象として*.*を指定しないでください。
オペレーティング・システムにより設定されているファイルの長さの制限に注意してください。たとえば、Windowsオペレーティング・システムでは、ファイル名(ファイル名と完全なディレクトリ・パスを合せた長さ)を256文字より長くできません。制限によりファイル名に特定の文字を使用できないオペレーティング・システムもあります。たとえば、Windowsオペレーティング・システムでは、バックスラッシュ(\)、スラッシュ(/)、コロン(:)、アスタリスク(*)、左角カッコ(<)、右角カッコ(>)または縦線(|)などの文字は許可されていません。
正規表現を使用する場合、「インクルード・ファイルの名前パターン」および「処理対象外ファイルの名前パターン」フィールドで指定する値は、JDKの正規表現(regex)構文に準拠している必要があります。どちらのフィールドにも、異なるregexパターンを別々に指定する必要があります。「インクルード・ファイルの名前パターン」フィールドおよび「処理対象外ファイルの名前パターン」フィールドは、インバウンドWSDLファイルのIncludeFilesおよびExcludeFilesパラメータに対応します。
注意:
regexパターンはJDK regexパターンに準拠しています。JDK regexパターンに準じると、任意の文字列が任意の回数発生するパターンの正しいコノテーションはピリオドとプラス記号です(.+)。JDK regexでは、アスタリスク(*)は任意の文字が任意の回数発生する文字列のプレースホルダではありません。
インバウンドで、poで始まり、拡張子がtxtであるすべてのファイル名を取得するには、名前パターンが正規表現である場合は、「インクルード・ファイルの名前パターン」フィールドでpo.*\.txtとして指定する必要があります。次にこのregexパターンの例で使用された記号の意味を示します。
ピリオド(.)は任意の文字を表します。
アスタリスク(*)は任意の発生数を表します。
ピリオドが続くバックスラッシュ(\.)は、エスケープ文字のバックスラッシュで示されているように、文字としてのピリオド(.)を表します。
「処理対象外ファイルの名前パターン」フィールドも同様に構成します。
「インクルード・ファイルの名前パターン」フィールドと「処理対象外ファイルの名前パターン」フィールドの式に重複がある場合、処理対象外ファイルの式が優先されます。たとえば、「インクルード・ファイルの名前パターン」がabc*.txtに設定され、「処理対象外ファイルの名前パターン」がabcd*.txtに設定されている場合、接頭辞abcd*.txtが付いたファイルはすべて受信されます。
注意:
JDK regexのパターン名を、プラス記号(+)、疑問符(?)またはアスタリスク(*)で始めることはできません。
Java regex構文の詳細は、次のサイトを参照してください。
http://java.sun.com/j2se/1.5.0/docs/api
注意:
ファイルは読み取られないため、ネイティブ・データ変換は行われません。
インバウンド方向では、Oracle FTPアダプタはOracleファイル・アダプタのRead File操作と同様に機能し、処理のためにファイルシステムのファイルをポーリングして取得します。主な違いは、Oracle FTPアダプタがリモートでのファイル交換に使用されることです。FTPアダプタをリモートでのファイル交換用に構成するために、図4-43 に示すように、アダプタ構成ウィザードでは後で使用するFTPサーバーへの接続情報が求められます。
デフォルトのアダプタ・インスタンスのJNDI名はeis/Ftp/FtpAdapterです。または、カスタム名を使用します。この名前で、実行時にFTPサーバーに接続します。
注意:
Oracle FTPアダプタでは、大きなファイルの転送時にFTPコマンドのRESTARTとRECOVERYを使用できません。
ログイン後、Get File(読取り)操作と配信するファイル・タイプを選択します。図4-44 にこの選択内容を示します。
デプロイメント・ディスクリプタのserverTypeプロパティは、データ転送時に行セパレータを判別するために使用されます。プロパティ値としてunix、winまたはmacを指定できます。これらの値は、FTPサーバーが稼働しているオペレーティング・システムを表します。デフォルトでは、serverTypeプロパティの値はunixです。
値macを指定すると、行セパレータとして\rが使用されます。unixを指定すると\nが使用され、winを指定すると\r\nが使用されます。アウトバウンド操作時に行セパレータを書き込むために、NXSDトランスレータ・コンポーネントによってこのプロパティが使用されることに注意してください。
これ以降のGet File操作のアダプタ構成ウィザードのページは、ファイルのRead File操作のページと同じです。表4-9 は、表示されるページと各機能の説明が記載されている項を示しています。
表4-9 Get File操作のアダプタ構成ウィザードのページ
| ページ | 参照先 |
|---|---|
ファイル・ディレクトリ(図4-26 ) |
|
ファイルのフィルタ処理(図4-27 ) |
|
ファイル・ポーリング(図4-28 ) |
|
メッセージ(図4-29) |
上級ユーザーは、その他のアダプタ構成ウィザードのページを使用することもできます。それが図4-45 のページで、図4-28 の「ファイル・ポーリング」ページで次のいずれかまたは両方の選択を行った後にのみ表示されます。
「正常な取得後にファイルを削除」チェック・ボックスの選択を解除
「ファイルの最小経過時間」フィールドの値を0より大きな値に設定
このページでは、リモートFTPサーバー上のファイルの変更時間を取得する方法を指定できます。
注意:
Oracle FTPアダプタでは、タイムスタンプのリスト表示と取得にNLSTではなくLISTコマンドが使用されますが、これは時間の書式の指定が不要であるためです。ただし、次のいずれかを行う場合は、示されているように時間の書式を指定する必要があります。
リスト表示のコマンドとしてNLSTを指定する場合(マッピング・ファイルを使用するか、インバウンドJCAファイルでUseNlst="true"パラメータを使用)
「ファイル名サブストリング」オプションを使用する場合
これらのカテゴリに該当しない場合、この注意事項は適用されません。
ファイルシステム
このオプションを使用すると、ファイルシステムのリスト・コマンドを使用してファイルの変更時間を日付/時間の書式で取得できます。ただし、このオプションはあまり使用されず、サポートしていないFTPサーバーもあります。使用しているサーバーでファイルシステムのリスト・コマンドがサポートされているかどうか、どのコマンドライン構文を使用するか、およびどのように出力を解析するかは、FTPサーバーのドキュメントを参照してください。
たとえば、ファイルシステムのリスト・コマンドquote mdtm filenameがサポートされており、次の情報が返ってきたとします。
213 20050602102633
開始索引、終了索引およびファイル変更時間の日付/時間の書式をカンマ区切りの単一の値(4,18,yyyyMMddHHmmssなど)として日付書式/時間書式フィールドに指定します。
ここで:
4はファイル変更時間の開始索引です。
18はファイル変更時間の終了索引です。
yyyyMMddHHmmssは、quote mdtm filenameコマンドで取得されたファイル変更時間の日付/時間の書式です。
結果のJCAファイルには、次のパラメータと値が含まれます。
<property name=" FileModificationTime " value=" FileSystem "/> <property name=" ModificationTimeFormat" value=" 4,18,yyyyMMddHHmmss "/>
タイムゾーンの問題を処理するには、タイムスタンプの違いを理解している必要があります。FTPサーバーのタイムゾーンは、Windowsの「日付と時刻のプロパティ」(たとえば、Windowsのタスク・バーに表示されている時刻をダブルクリック)を使用して決定されます。Oracle FTPアダプタを実行しているシステムとFTPサーバーの時差をミリ秒に換算し、その値をcomposite.xmlファイルのバインディング・プロパティとして追加します。
<binding.jca config="FlatStructureIn_file.jca"> <property name="timestampOffset" source="" type="xs:string" many="false" override="may">238488888</property--> </binding.jca>
ディレクトリ・リスティング
このオプションを使用すると、FTPディレクトリ・リスティング・コマンドを使用してファイル変更時間から日付/時間書式を取得できます。たとえば、ディレクトリ・リスティング・コマンド(ls -l)で次の情報が返ってきたとします。
12-27-04 07:44AM 2829 NativeData2.txt
開始索引、終了索引およびファイル変更時間の日付/時間の書式を、カンマ区切りの単一の値(0,17, MM-dd-yy hh:mmaなど)として、「旧ファイルの日付書式/時刻書式」フィールドまたは「最新ファイルの日付書式/時刻書式」フィールドに指定します。
ここで:
0はファイル変更時間の開始索引です。
17はファイル変更時間の終了索引です。
MM-dd-yy hh:mmaは、ls -lコマンドで取得されたファイル変更時間の日付/時間のフォーマットです。この例では、「最新ファイルの日付書式/時刻書式」フィールドに値が入力されています。このフィールドはネーミング規則に準拠しており、書式が最新のファイルから取得されたことを意味します。一方、「旧ファイルの日付書式/時刻書式」フィールドでは最も古いファイルから書式が取得されます。
結果のJCAファイルには、次のパラメータと値が含まれます。
<property name=" FileModificationTime " value=" DirListing"/> <property name=" ModificationTimeFormat" value="0,17, MM-dd-yy hh:mma "/>
タイムゾーンの問題を処理するには、タイムスタンプの違いを理解している必要があります。FTPサーバーのタイムゾーンは、Windowsの「日付と時刻のプロパティ」(たとえば、Windowsのタスク・バーに表示されている時刻をダブルクリック)を使用して決定されます。Oracle FTPアダプタを実行しているシステムとFTPサーバーの時差をミリ秒に換算し、その値をcomposite.xmlファイルのバインディング・プロパティとして追加します。
<binding.jca config="FlatStructureIn_file.jca"> <property name="timestampOffset" source="" type="xs:string" many="false" override="may">238488888</property--> </binding.jca>
ファイル名サブストリング
このオプションを使用すると、ファイル名から変更時間を取得できます。たとえば、ファイル名がfixedLength_20050324.txtの場合、次の値を指定できます。
「サブストリング開始索引」フィールドに開始索引を指定できます(12など)。
「終了索引」フィールドの終了索引(20など)
ファイル名でファイル変更時間を表すためにJavaのSimpleDateFormatに準拠している「日付書式/時間書式」フィールドの日付と時間の書式(yyyyMMddなど)
結果のJCAファイルには、次のパラメータと値が含まれます。
<property name=" FileModificationTime " value=" Filename"/> <property name=" FileNameSubstringBegin " value="12 "/> <property name=" FileNameSubstringEnd " value="20"/> <property name=" ModificationTimeFormat " value=" yyyyMMdd "/>
「アダプタ構成ウィザード」を完了すると、JDeveloperの「アプリケーション」セクションに構成ファイルが作成されます。
エラー処理の詳細は、図2-29 を参照してください。
また、次のサンプルに示すように、DefaultDateFormatパラメータおよびRecentDateFormatパラメータをOracle FTPアダプタのデプロイメント・ディスクリプタに追加することも必要となります。
<non-managed-connection
managedConnectionFactoryClassName=
"oracle.tip.adapter.ftp.
FTPManagedConnectionFactory">
<property name="host" value="localhost"/>
<property name="port" value="21"/>
<property name="username" value="****"/>
<property name="password" value="****"/>
<property name="listParserKey" value="UNIX"/>
<property name="defaultDateFormat"
value="MMM d yyyy"/>
<property name="recentDateFormat"
value="MMM d HH:mm"/>
</non-managed-connection>
DefaultDateFormatパラメータおよびRecentDateFormatパラメータの詳細は、「Oracleファイル/FTPアダプタのディレクトリ内のファイルの再帰的処理」を参照してください。
アウトバウンド方向では、Write File操作と同じ機能を果します。BPELプロセスまたはサービスからメッセージを受信し、ファイル内のメッセージをファイルシステム(この場合はリモート)に書き込みます。メッセージをリモート・システムに書き込む必要があるため、図4-43 に示すように、アダプタ構成ウィザードではアダプタ・インスタンスのJNDI名でFTPサーバーに接続するように求められます。
ログイン後、Put File(書込み)操作と配信するファイル・タイプを選択します。図4-46 にこの選択内容を示します。
これ以降のPut File操作のアダプタ構成ウィザードのページは、Write File操作のページと同じです。表4-10 に、表示されるページとその機能の説明が記載されている項を示します。
「アダプタ構成ウィザード」を完了すると、JDeveloperの「アプリケーション」セクションに構成ファイルが作成されます。
アウトバウンド方向では、同期Read File操作と同様に機能し、ファイルシステムのファイルをポーリングして取得し、ファイルの現在のコンテンツを読み取ります。主な違いは、リモートでのファイル交換に使用されることです。このポーリングのため、アダプタ構成ウィザードでは後で使用するFTPサーバーへの接続情報が求められます。ファイルを同期的に読み取るには、図4-47 に示すように「同期Get File」操作を選択します。
ファイル・リスティングの概要は、「ファイル・リスティングの説明」に記載されているファイル・リスティングの概要と似ています。ターゲット・ディレクトリのファイルをポーリングし、ファイルのリストを指定されたFTPの場所に表示します。ファイルのコンテンツは読み取られませんこの機能では、invokeアクティビティを使用してターゲット・ディレクトリからファイルのリストを取得します。このファイルのリストはXML文書として返され、ファイル名、ディレクトリ名、ファイル・サイズ、最終変更時間などの情報が記載されています。
注意:
標準Java APIには作成時間を取得するためのメカニズムがないため、FTPの場合、ファイル作成時間プロパティcreationTimeはサポートされていません。creationTimeプロパティの値は常に0として表示されます。
creationTimeプロパティは、SFTPの場合にのみサポートされています。
BPELプロセスまたはサービスで使用するように構成するには、アダプタ構成ウィザードを使用します。これにより、アウトバウンドのWSDLとJCAのファイルのペアが作成されます。
ファイルのリストを表示するには、アダプタ構成ウィザードの「操作タイプ」ページで「List Files」操作を選択します。アダプタ構成ウィザードの「ファイル・ディレクトリ」ページでは、リスト表示操作のファイル名の読取りに使用するディレクトリの情報を指定する必要があります。ディレクトリ内のファイルを再帰的にリスト表示することもできます。アダプタ構成ウィザードの「ファイルのフィルタ処理」ページでは、取得または無視するファイルの詳細を指定できます。
リスナーとして機能し、ローカルまたはリモートのファイルシステムの指定されたディレクトリをポーリングして、指定されたネーミング基準に一致するファイルを検索します。
次の各項では、Oracleファイル/FTPアダプタの各種構成タスクについて説明します。
注意:
ftpAbsolutePathBeginパラメータを使用して、FTPアダプタが発行したFTPコマンドで使用されたディレクトリ名が、絶対ディレクトリか相対ディレクトリかをアダプタに示すことができます。ディレクトリ名がftpAbsolutePathBeginで始まっている場合は絶対ディレクトリで、それ以外の場合は相対ディレクトリとして扱われます。
リモートFTPサーバーにアクセスするには、次の資格証明を構成する必要があります。
ユーザー名: リモートFTPサーバーで使用するユーザー名
パスワード: リモートFTPサーバーで使用するパスワード
ポート: 21
ホスト: リモートFTPサーバーのIPアドレス
これらの資格証明を構成するには、Oracle WebLogic Serverコンソールを使用してweblogic-ra.xmlファイルを変更する必要があります。
これを行うには、Oracle WebLogic Server管理コンソールで次の手順を実行します。
javax.resource.cci.ConnectionFactoryを展開し、変更するインスタンスを選択します。(たとえば、非高可用性の使用例では、eis/Ftp/FtpAdapterインスタンスを選択します。)次の各項では、アクティブ/アクティブ・トポロジに対する高可用性のために構成する際の要件と手順について説明します。
高可用性を実現するように構成するには、次の前提条件が満たされていることを確認する必要があります。
クラスタリングされた複数のプロセスで、同じ物理ディレクトリが使用されている必要があります。
connection-factoryでコントロール・ディレクトリと同じ共有ディレクトリが指定され、その名前が一致している必要があります。たとえば、一方のconnection-factoryのデプロイメント・ディスクリプタでcontrolDirの値として/shared/control_dirが指定されている場合は、もう一方のデプロイメント・ディスクリプタでも同じ値が指定されている必要があります。
アダプタを正常に機能させるために、リモート・フォルトに対するフォルト・ポリシーとフォルト・バインディングが作成されている必要があります。フォルト・ポリシーとフォルト・バインディングの詳細は、「エラー処理」を参照してください。
JCAファイル内にMaxRaiseSizeプロパティを設定する必要があります。
注意:
大きなペイロードについては、次の設定を追加してSOADataSourceのトランザクション・タイムアウトを増やす必要があります。
<xa-set-transaction-timeout>true</xa-set-transaction-timeout> <xa-transaction-timeout>1000</xa-transaction-timeout>
注意:
Windowsプラットフォームの場合は、入力ディレクトリと出力ディレクトリが正規化されていることを確認する必要があります。たとえば、c:\bpel\inputのかわりにC:\bpel\inputを使用する必要があります。c:のかわりに大文字のドライブ名C:を使用することに注意してください。
注意:
すべてのプラットフォームで、入力ディレクトリ名または出力ディレクトリ名をJavaシステム・プロパティfile.separator値で終了しないようにしてください。たとえば、/tmp/file/in/はファイル・セパレータのスラッシュが末尾にあるため無効ですが、/tmp/file/inは有効です。
1つのノードのみが分散トポロジで特定のファイルを処理する必要があります。データベース表をコーディネータとして使用すると、インバウンド操作での可用性が向上します。
データベース表をコーディネータとして使用して、インバウンドのサービスの可用性を高めるには、次の手順を使用します。
注意:
データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。
データベース表の作成
データベース・スキーマはsoainfraの一部として事前作成されているため、この手順を実行する必要はありません。
デプロイメント・ディスクリプタの変更
Oracle WebLogic Server管理コンソールで、eis/HAFileAdapterに対応するconnection-instanceのデプロイメント・ディスクリプタを変更します。
Oracle WebLogic Server管理コンソールにログインします。コンソールにアクセスするには、http://servername:portnumber/consoleにナビゲートします。
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントのサマリー」の下にある「FileAdapter」をクリックします。
「構成」タブをクリックします。
「アウトバウンド接続プール」タブをクリックし、javax.resource.cci.ConnectionFactoryを開いて図4-48 に示すように構成済のコネクション・ファクトリを表示します。
図4-48 Oracle WebLogic Server管理コンソール - 「FileAdapterの設定」ページ
「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。
図4-49 に示すようにコネクション・ファクトリのプロパティを更新します。
図4-49 Oracle WebLogic Server管理コンソール - 「javax.resource.cci.ConnectionFactoryの設定」ページ
コネクション・ファクトリ内の新規パラメータは、次のとおりです。
controlDir - 制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタ内で複数のWebLogic Serverインスタンスを実行する場合は、共有の場所に設定する必要があります。
inboundDataSource - 値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマを事前に作成する場所であるデータ・ソースです。事前作成されたスキーマ・ファイルは、$BEA_HOME/AS11gR1SOA/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlで参照できます。それ以外の場所にスキーマを作成するには、このスクリプトを使用します。別のスキーマを選択した場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。
次の例に示すように、コネクション・ファクトリを使用するためにBPELプロセスまたはシナリオを構成します。
<adapter-config name="FlatStructureIn" adapter="File Adapter" xmlns="http://platform.integration. oracle/blocks/adapter/fw/metadata"> <connection-factory location= "eis/HAFileAdapter" UIincludeWildcard="*.txt" adapterRef=""/> <endpoint-activation portType="Read_ptt" operation="Read"> <activation-spec className="oracle.tip.adapter. file.inbound.FileActivationSpec"../> <property../> <property../> </activation-spec> </endpoint-activation> </adapter-config>
注意:
接続ファクトリの位置属性は、eis/HAFileAdapterに設定されています。
複数の参照が同じディレクトリに書き込まれた場合に相互にオーバーライドされないようにする必要があります。次のロック機能を使用すると、アウトバウンド操作での可用性が向上します。
データベースmutex
ユーザー定義mutex
データベース表をコーディネータとして使用して、アウトバウンドのOracleファイル/FTPアダプタ・サービスの可用性を高めるには、次の手順を使用します。
注意:
データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトを増やす必要があります。
データベース表の作成
データベース・スキーマはsoainfraの一部として事前作成されているため、この手順を実行する必要はありません。
Oracleファイル・アダプタのデプロイメント・ディスクリプタの変更
Oracle WebLogic Server管理コンソールで、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。
Oracle WebLogic Server管理コンソールにログインします。コンソールにアクセスするには、http://servername:portnumber/consoleにナビゲートします。
「ドメイン構造」の左ペインで「デプロイメント」をクリックします。
右ペインの「デプロイメントのサマリー」で「FileAdapter」をクリックします。
「構成」タブをクリックします。
「アウトバウンド接続プール」タブをクリックし、javax.resource.cci.ConnectionFactoryを開いて図4-48 に示すように構成済のコネクション・ファクトリを表示します。
「eis/HAFileAdapter」をクリックします。高可用性に対応するコネクション・ファクトリの「アウトバウンド接続のプロパティ」ページが表示されます。
図4-50 に示すようにコネクション・ファクトリのプロパティを更新します。
図4-50 Oracle WebLogic Server管理コンソール - 「javax.resource.cci.ConnectionFactoryの設定」ページ
Oracleファイル/FTPアダプタのコネクション・ファクトリの新しいパラメータは次のとおりです。
controlDir - 制御ファイルを格納するディレクトリ構造に設定します。1つのクラスタ内で複数のWebLogic Serverインスタンスを実行する場合は、共有の場所に設定する必要があります。
inboundDataSource - 値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマが事前作成されるデータソースです。事前作成されたスキーマは、$BEA_HOME/AS11gR1SOA/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlで参照できます。それ以外の場所にスキーマを作成するには、このスクリプトを使用します。別のスキーマを選択した場合は、それに応じてinboundDataSourceプロパティを設定する必要があります。
outboundDataSource - 値をjdbc/SOADataSourceに設定します。これは、高可用性に対応するスキーマが事前作成されるデータソースです。事前作成されたスキーマは、$BEA_HOME/AS11gR1SOA/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sqlで参照できます。それ以外の場所にスキーマを作成するには、このスクリプトを使用します。その場合は、outboundDataSourceプロパティを設定する必要があります。
outboundLockTypeForWrite - Oracle Databaseを使用する場合は値をoracleに設定します。デフォルトでは、Oracleファイル/FTPアダプタはメモリー内mutexを使用してアウトバウンドの書込み操作をロックします。書込み操作を同期化するには、次の値のいずれかを選択する必要があります。
memory - Oracleファイル/FTPアダプタは、インメモリーmutexを使用してファイルシステムへのアクセスを同期化します。
oracle - アダプタはOracle Databaseの順序を使用します。
db - アダプタは、事前作成されたデータベース表(FILEADAPTER_MUTEX)をロック・メカニズムとして使用します。このオプションは、Oracle Databaseスキーマ以外のスキーマを使用している場合にのみ使用します。
user-defined - アダプタはユーザー定義mutexを使用します。ユーザー定義mutexを構成するには、mutexインタフェースoracle.tip.adapter.file.Mutexを実装し、名前がoracle.tip.adapter.file.mutexで、アウトバウンド参照のmutexの完全修飾クラス名の値を指定した新規バインディング・プロパティを構成する必要があります。
次の例に示すように、コネクション・ファクトリを使用するためにBPELプロセスまたはメディエータのシナリオを構成します。
<adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration. oracle/blocks/adapter/fw/metadata"> <connection-factory location="eis/HAFileAdapter" adapterRef=""/> <endpoint-interaction portType="Write_ptt" operation="Write"> <interaction-spec className="oracle.tip.adapter.file.outbound .FileInteractionSpec"> <property../> <property../> </interaction-spec> </endpoint-interaction> </adapter-config>
注意:
接続ファクトリの位置属性は、eis/HAFileAdapterに設定されています。
BPELおよびメディエータ・サービス・エンジンの両方のJCAヘッダー・プロパティを使用すると、このコネクション・ファクトリの位置を動的に変更できます。FTP JCAコネクション・ファクトリ・パラメータを動的に設定するには、リモートの場所(jndi)を削除するかまたは無効な値(存在しないjndi)を指定します。これが発生するのは、管理対象ではないコネクション・ファクトリでは、location=<jndi>が指定されている場合、アウトバウンド・コネクションjndiに定義されたパラメータの方が優先度が高いからです。つまり、.jcaに指定された値は無効になります。
Windows、SolarisおよびLinuxでセキュアFTP機能を使用できます。Windowsの場合、この機能はOpenSSLを使用したFileZilla FTPサーバーで動作確認されています。この項では、セキュアFTP機能の概要と、この機能のインストールおよび構成方法を説明します。
この項には次のトピックが含まれます:
機密データがリモート・サーバーへ転送される環境(クレジット・カード情報のHTTPサーバーへの送信など)では、セキュリティの問題は非常に重要です。このような場合、セキュリティには主に次の2つの要件があります。
データ交換をしているリモート・サーバーの信頼性
データの傍受を試みる第三者からの保護
Secure Socket Layer (SSL)の証明書と暗号化は、この2つのセキュリティ要件を満たすことに重点が置かれています。FTPでSSLが使用される場合、そのセキュリティ・メカニズムはFTPS(またはFTP over SSL)と呼ばれます。
SSL環境でクライアントの信頼を得るために、サーバーは認識済の認証局から証明書(X.509証明書など)を取得します。FTPサーバーを設定する際には、OpenSSLを使用してサーバーの証明書を作成します。どのクライアントも、初めは少数のパーティしか信頼しません。サーバーが信頼されているパーティの1つである場合、またはサーバーの証明書がそれらのパーティのいずれかで発行されたものである場合、間接的であるにしても信頼を得たことになります。たとえば、サーバーの証明書が、認証局Bから発行された証明書を持つ認証局Aから発行されたもので、クライアントがBを信頼していればそれで問題ありません。図4-51 に示す設定では、サーバーの証明書は信頼できる証明書として、直接クライアントの証明書ストアにインポートされます。
送信前に暗号化し、受信後に復号することで、転送するデータは盗用されなくなります。データが大量な場合、(データの暗号化と復号に同じ鍵を使用する)対称型暗号化は公開鍵と秘密鍵を使用する方法よりもはるかに高速です。対称型暗号化はFTPSで使用される方法です。ただし、クライアントとサーバーがデータの暗号化や復号に同じ鍵を使用するには、共通の鍵について合意する必要があります。通常、クライアントが次のタスクを実行することで合意が成立します。
セッション鍵の生成(データの暗号化と復号に使用)
サーバーの証明書の一部であるサーバーの公開鍵を使用したセッション鍵の暗号化
サーバーへの鍵の送信
サーバーは秘密鍵を使用してこのセッション鍵を復号化し、クライアントに送信する前にそのセッション鍵を使用してファイル・データを暗号化します。
次の各項では、SolarisおよびLinux用のセキュアFTPのインストールおよび構成方法について説明します。
OpenSSLは、SSLプロトコルのオープン・ソースの実装です。OpenSSLは基本的な暗号機能を実装し、ユーティリティ関数を提供します。FTPサーバーとして使用するSolarisまたはLinuxのホストにOpenSSLをインストールして構成します。
vsftpdサーバーは、UNIXシステム用のセキュアで高速なFTPサーバーです。FTPサーバーとして使用するSolarisまたはLinuxのホストにvsftpdをインストールして構成します。
FTPS機能はOpenSSLを使用したFileZilla FTPサーバーで動作確認されています。WindowsでFileZillaを使用する場合にOpenSSLをインストールおよび構成するには、次の各項の手順に従う必要があります。
OpenSSLは、SSLプロトコルのオープン・ソースの実装です。OpenSSLは基本的な暗号機能を実装し、ユーティリティ関数を提供します。FTPサーバーとして使用するWindowsのホストにOpenSSLをインストールして構成するには、次の手順を実行します。
(FileZillaの「新規証明書の生成」ボタンをクリックすることで、FileZillaユーティリティを使用して秘密鍵および証明書を生成し、この項の手順をスキップできます。入力する「共通名」が、FileZilla FTPサーバーが実行中のマシンの完全修飾ホスト名またはIPであることを確認します。その場合でも、「サーバー鍵のPEMからPKCS12フォーマットへの変換」の手順は実行する必要がありますが、FileZillaによって生成された秘密鍵および証明書ファイルを使用します。)
サーバー鍵ファイルおよび証明書ファイルを作成するには、次の手順を実行します。
サーバー鍵およびサーバー証明書をFileZillaにインポートするには、次の手順を実行します。
注意:
「Key password」フィールドでは、「OpenSSLのサーバー鍵およびサーバー証明書の作成」の手順3で生成したPEMパスフレーズを使用する必要があります。
Oracle FTPアダプタではPEMフォーマットが認識されないため、サーバー鍵およびサーバー証明書をPEMフォーマットからPKCS#12フォーマットへ変換する必要があります。サーバー鍵およびサーバー証明書をPKCS#12フォーマットに変換するには、次の手順を実行します。
SSHファイル転送プロトコル(SFTP)は、ネットワークを介したセキュアなファイル転送を可能にするネットワーク・プロトコルです。WindowsおよびLinuxでのSFTP機能の使用をサポートします。この項では、SFTP機能の概要と、この機能のインストールおよび構成方法を説明します。
この項では、次のタスクを取り上げます。
FTPは、クライアントが基礎となるSSHトランスポートを介してファイルを安全に転送できるようにするネットワーク・プロトコルです。SFTPはFTP over SSHともファイル転送プロトコル(FTP)とも異なります。図4-53 に、SSHクライアントとSSHサーバーの間の通信プロセスを示します。SFTPはWindowsとLinuxでサポートされています。
SFTPの機能は、次のとおりです。
SSHプロトコルでは、暗号化に公開鍵暗号を使用します。ここでは、データがどのように暗号化されるかについて説明します。
本来、SSHプロトコルでは、パスワードまたはセッション鍵をネットワークでの転送時に暗号化することでパスワード認証をサポートしています。また、SSHプロトコルでは「既知のホスト」というメカニズムを使用して、IPスプーフィングなどの脅威を防止します。クライアントとサーバーの両方でこのメカニズムが使用されている場合、あらゆる種類の通信を行う前に相互にアイデンティティを証明する必要があります。
SSHプロトコルは、Message Digest Algorithm 5 (MD5)やSecure Hash Algorithm (SHA-1)など、広範囲に信頼されているバルク・ハッシュ・アルゴリズムを使用することで、挿入攻撃を防止します。「暗号化」で説明したアルゴリズムを使用してデータ整合性チェックサムを実装することで、送信中のデータが故意に改ざんされるのを防止できます。
OpenSSH for Windowsは、WindowsでのSSHプロトコルの無償実装です。Windows XPでOpenSSHをインストールおよび構成するには、次の手順を実行します。
Administrator権限を持つユーザーとしてログインします。
次のサイトからsetup.exeをダウンロードします。
http://www.cygwin.com
setup.exeを実行します。「Cygwin Net Release Setup」ウィンドウが表示されます。
「Next」をクリックします。「Choose Installation type」ウィンドウが表示されます。
ダウンロード・ソースとして「Install from Internet」を選択し、「Next」をクリックします。「Choose Installation Directory」ウィンドウが表示されます。
「root directory」はC:\cygwinのままにしておきます。「Install For」および「Default Text File Type」フィールドも、デフォルト・オプションのままにしておきます。
「Next」をクリックします。「Select Local Package Directory」ウィンドウが表示されます。
「Browse」をクリックし、ローカル・パッケージ・ディレクトリとして「C:\cygwin」を選択します。
「Next」をクリックします。「Select Connection Type」ウィンドウが表示されます。
インターネット接続の設定を選択して「Next」をクリックします。「Choose Download Site(s)」ウィンドウが表示されます。
「Available Download Sites」リストからサイトを選択し、「Next」をクリックします。「Select Packages」ウィンドウが表示されます。
「View」をクリックして、インストール可能な全パッケージのリストを表示します。
デフォルト値でない場合は「openssh」を選択します。
opensshの「Binaries」ボックスを選択します。
「Next」をクリックしてインストールを開始します。
Windows XPデスクトップで、「マイ コンピュータ」を右クリックして「プロパティ」を選択します。
「詳細設定」タブをクリックし、「環境変数」をクリックします。
「新規」をクリックし、「変数名」フィールドにCYGWIN、「変数値」フィールドにntsecと入力します。
システム・パスにC:\cygwin\binを追加します。
「cygwin」ウィンドウを開きます。
ssh-host-configと入力します。
次のプロンプトが表示されます。
Shall privilege separation be used? (yes/no)
yesと入力します。
Shall this script create a local user 'sshd' on this machine?
yesと入力します。
Do you want to install sshd as service?
(Say "no" if it's already installed as service)(yes/no)
yesと入力します。
Which value should the environmentvariable CYGWIN have when sshdstarts? It's recommended to setat least "ntsec" to be able to change user context without password. Default is "binmode ntsec tty".
ntsecと入力します。
net start sshdと入力してsshdサービスを開始します。
「cygwin」ウィンドウで次のコマンドを実行して、Windowsのローカル・ユーザー・アカウントをcygwinにレプリケートします。
mkpasswd --local > /etc/passwd mkgroup --local > /etc/group
設定をテストするために、「cygwin」ウィンドウにssh localhostと入力します。
SFTP機能を使用するには、デプロイメント・ディスクリプタを変更する必要があります。
表4-12 に、デプロイメント・ディスクリプタで値を指定する必要があるプロパティを示します。これらのプロパティの値は、認証のタイプとOpenSSHの場所に応じて異なります。
表4-12 SFTPのプロパティ
| プロパティ | 説明 |
|---|---|
|
必須: はい デフォルト値: |
|
パスワードベース認証の場合は パスワードベース認証の場合は、 公開鍵認証の場合は、 必須: はい |
|
これはオプション・パラメータであり、ユーザーはメッセージ暗号化に使用するセッション鍵を交換する際にデフォルトの鍵交換プロトコルを選択できます。 必須: いいえ デフォルト値: |
|
このパラメータにより、通信中のデータを圧縮するかどうかを選択できます。 必須: いいえ |
|
このパラメータにより、データ整合性チェックに使用するバルク・ハッシュ・アルゴリズムを選択できます。 必須: いいえ デフォルト値: |
|
このパラメータにより、通信に使用する非対称型暗号を構成できます。 必須: いいえ デフォルト値: |
|
秘密鍵ファイルへのパスを指定します。 必須: いいえ |
|
次のリストから暗号を1つ指定します。
必須: いいえ デフォルト値: blowfish-cbc |
|
SSHサーバーがファイアウォールの内側にある場合は HTTPを選択した場合は、次のパラメータの値を指定する必要があります。
必須: はい |
パスワード認証を使用するように設定するには、表4-12に示したプロパティの値をデプロイメント・ディスクリプタで指定する必要があります。authenticationTypeプロパティがpasswordに設定されていることを確認してください。
表4-13 のプロパティと値を指定します。
表4-13 サンプルのSFTPのプロパティとその値
| プロパティ | 値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
- |
|
|
|
|
公開鍵認証の場合は、最初にOpenSSHを構成してから設定する必要があります。
設定は、OpenSSHがファイアウォールの内側で実行されるかどうかに応じて異なります。
OpenSSHがファイアウォールの内側で実行される場合は、次の項を参照してください。
OpenSSHがファイアウォールの外側で実行される場合は、次の項を参照してください。
公開鍵認証を使用するように設定するには、表4-12に示したパラメータの値をデプロイメント・ディスクリプタで指定する必要があります。authenticationTypeパラメータがpublickeyに、transportProviderパラメータがsocketに設定されていることを確認します。privateKeyFileパラメータには、秘密鍵ファイルの場所が含まれている必要があります。
表4-14 に、公開鍵認証プロパティとその値のサンプル・リストを示します。
表4-14 サンプルのSFTPのプロパティとその値
| プロパティ | 値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OpenSSHがファイアウォールの外側で実行されている場合に、公開鍵認証用に設定するには、次の手順を実行します。
表4-15 に、公開鍵認証プロパティおよびプロキシ・プロパティのサンプル・リストを示します。
表4-15 サンプルのSFTPのプロパティとその値
| プロパティ | 値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
この項では、SFTP用の接続ファクトリの構成中にFIPS準拠を有効化する方法について説明します。
FTPアダプタは、暗号化を使用してセキュリティ機能を実装するか、セキュリティ・ポリシーを施行する場合は常にFIPS-140の検証された暗号化の使用をサポートします。たとえば、暗号化、復号化、署名、ハッシュ、検証などです。
SFTP用の接続ファクトリの構成中にFIPS準拠を有効化します。FIPS準拠を選択する場合、システムはMaverickクライアントのFIPSモードを有効化し、構成された優先鍵交換アルゴリズムおよび公開鍵アルゴリズムを使用してSFTPサーバーに接続します。SFTPClientを更新して、これらの変更に対応します。
EnableFIPSMode接続ファクトリ・プロパティを有効化すると、アダプタはMaverickでenableFIPS()を使用します。有効化するには、次の例に示すように値をtrueに変更します。
<wls:property> <wls:name>EnableFIPSModewls:name>EnableFIPSMode> <wls:value>truewls:value>true> </wls:property>
eis/Ftp/SftpAdapter_FIPSにあるSftpAdapter_FIPS接続ファクトリで、プロパティはすでにtrueに設定されています。
J2SSH Maverickライブラリは、<MW_HOME>/soa/soa/modules/maverick-all.jarで更新されます
Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesは、<jre>/lib/securityに配置されています
KeyStoreProviderName = com.rsa.jsse.JsseProvider
KeyStoreType = PKCS12
KeystoreAlgorithm = X509
PkiProvider =
JsseProvider = RsaJsse
TrustManager = oracle.tip.adapter.ftp.ServerTrustManager
EnableFIPSMode = true
FIPSモードを有効化する場合、FIPS準拠の暗号リストから優先暗号を選択します。
| 機能 | 無効化されるFIPSモード | 有効化されるFIPSモード |
|---|---|---|
鍵の交換 |
diffie-hellman-group14-sha1 diffie-hellman-group1-sha1(デフォルト) diffie-hellman-group-exchange-sha1 diffie-hellman-group-exchange-sha256 |
diffie-hellman-group14-sha1(デフォルト) |
公開鍵アルゴリズム |
ssh-rsa(デフォルト) ssh-dss x509v3-sign-rsa x509v3-sign-dss x509v3-sign-rsa-sha1 |
ssh-rsa(デフォルト) |
詳細は、『Oracle® Fusion Middleware Oracle Fusion Middlewareの管理』のOracle Fusion MiddlewareのFIPS 140サポートに関する項を参照してください。
サポートしているプロキシはHTTPプロキシのみです。HTTPプロキシ・サポートは、プレーンFTPモードおよびSFTPモードという2つのモードで使用できます。この項では、プレーンFTPモードとSFTPモードで実行するように構成する方法について説明します。次の項目が含まれます。
プレーンFTPモードで実行する場合は、デプロイメント・ディスクリプタで特定のパラメータの値を指定する必要があります。表4-16 に変更が必要なプロパティを示します。
表4-16 プレーンFTPモードのプロパティ
| プロパティ | 説明 |
|---|---|
|
リモートFTPサーバー名。 |
|
FTP制御ポート番号。 |
|
FTPユーザー名。 |
|
FTPパスワード。 |
|
プロキシ・ホスト名。 |
|
プロキシ・ポート番号。 |
|
プロキシ・ユーザー名。 |
|
プロキシ・パスワード。 |
|
プロキシ・タイプ。サポートされるのはHTTPプロキシ・タイプのみです。 |
|
プロキシ定義ファイルの絶対パス。 このパラメータはオプションです。 詳細は、「プロキシ定義ファイル」を参照してください。 |
|
プロキシを使用する場合は |
表4-17に、デプロイメント・ディスクリプタのプロパティとその値のサンプル・リストを示します。
表4-17 サンプルのプレーンFTPモードのプロパティとその値
| プロパティ | 値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
すべてのプロキシ固有情報をプロキシ定義ファイルで指定し、このファイルを使用するようにデプロイメント・ディスクリプタのproxyDefinitionFileプロパティでアダプタを構成できます。プロキシ定義ファイルはXMLフォーマットで記述され、XMLスキーマに基づきます。次の例に、プロキシ定義ファイルのXMLスキーマを示します。プロキシ定義ファイルは、このXMLスキーマに基づく必要があります。
例 - プロキシ定義ファイルのXMLスキーマ
<?xml version = \"1.0\" encoding = \"UTF-8\"?>
<schema targetNamespace = "http://ns.oracle.com/ip
/af/ftp/proxy" xmlns =
"http://www.w3.org/2001/XMLSchema"
xmlns:proxy="http://ns.oracle.com/ip/af/ftp/proxy">
<element name="ProxyDefinitions" type="proxy:
ProxyDefinitionsType"/>
<complexType name="ProxyDefinitionsType">
<sequence>
<element name="Proxy"
type="proxy:ProxyDefinition"
minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="ProxyDefinition">
<sequence>
<element name="Step"
type="proxy:StepType"
minOccurs="1"
maxOccurs="unbounded"/>
</sequence>
<attribute name="key" type="ID"
use="required"/>
<attribute name="description"
type="string"
use="required"/>
<attribute name="type"
type="proxy:Protocol"
use="optional"/>
</complexType>
<complexType name="StepType">
<simpleContent>
<extension base="string">
<attribute name="command"
type="string"
use="required"/>
<attribute name="args" type="string"
use="required"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="Protocol">
<restriction base="string">
<enumeration value="ftp" />
<enumeration value="http" />
</restriction>
</simpleType>
</schema>
「例 - プロキシ定義ファイルのXMLスキーマ」に基づくサンプルのプロキシ定義ファイルは、次の例のようになります。
例 - プロキシ定義ファイル
<?xml version = '1.0' standalone = 'yes'?>
<proxy:ProxyDefinitions xmlns:proxy=
"http://ns.oracle.com/ip/af/ftp/proxy">
<Proxy key="http" description="http" type="http">
<Step command="USER" args="remote_username" />
<Step command="PASS" args="remote_password" />
</Proxy>
</proxy:ProxyDefinitions>
「例 - プロキシ定義ファイル」のファイルを使用すると、次の一連のログイン・コマンドが送信されます。
USER remote_username
PASS remote_password
プロキシ定義ファイルで、デプロイメント・ディスクリプタの値を取得するように指定することもできます。その場合は次の式を使用できます。
$proxy.user: デプロイメント・ディスクリプタのproxyUsernameパラメータの値に対応します。
$proxy.pass: デプロイメント・ディスクリプタのproxyPasswordパラメータの値に対応します。
$remote.user: デプロイメント・ディスクリプタのusernameパラメータの値に対応します。
$remote.pass: デプロイメント・ディスクリプタのpasswordパラメータの値に対応します。
$remote.host: デプロイメント・ディスクリプタのhostパラメータの値に対応します。
$remote.port: デプロイメント・ディスクリプタのportパラメータの値に対応します。
次の例に、「例 - プロキシ定義ファイル」のXMLスキーマに基づき、weblogic-ra.xmlファイルから値を取得するサンプルのプロキシ定義ファイルを示します。
例 - デプロイメント・ディスクリプタから値を取得するプロキシ定義ファイル
<?xml version = '1.0' standalone = 'yes'?>
<proxy:ProxyDefinitions xmlns:proxy=
"http://ns.oracle.com/ip/af/ftp/proxy">
<Proxy key="http" description="http" type="http">
<Step command="USER" args="$remote.user" />
<Step command="PASS" args="$remote.pass" />
</Proxy>
</proxy:ProxyDefinitions>
SFTPモードで実行する場合は、デプロイメント・ディスクリプタで特定のプロパティの値を指定する必要があります。表4-18 に変更が必要なプロパティを示します。
表4-18 SFTPモードのプロパティ
| プロパティ | 説明 |
|---|---|
|
リモートFTPサーバー名。 |
|
FTP制御ポート番号。 |
|
SFTPユーザー名。 |
|
SFTPパスワード。 |
|
プロキシ・サーバーのホスト名。 |
|
プロキシ・ポート番号。 |
|
プロキシ・ユーザー名。 |
|
プロキシ・パスワード。 |
|
SFTPモードの場合は |
|
「SFTP用の設定」を参照してください |
|
値 |
表4-19 に、デプロイメント・ディスクリプタのプロパティのサンプル・リストを示します。
表4-19 サンプルのSFTPモードのプロパティとその値
| プロパティ | 値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SOAとOSBの両方で、アクティブ/アクティブ・トポロジ内に高可用性のためのファイル/FTPアダプタを構成できます。高可用性は、インバウンドとアウトバウンドの両方の操作に対して構成できます。
Oracleファイル/FTPアダプタでは、分散トポロジ内で1つのノードのみが特定のファイルを処理することが保証されます。HAを有効にするために、ファイル/FTPアダプタはデータベース表またはCoherenceキャッシュをコーディネータとして使用して、Oracleファイル/FTPアダプタのインバウンド操作に対する高可用性を保証しています。
データベース表を使用して高可用性を有効にするには、.jcaファイル内にeis/HAFIleAdapterを指定する必要があります。これは高可用性のためにOracle表を使用することを指定するものであり、SQL Server表の場合はeis/HAFileAdapterMQSSQL、DB2表の場合はeis/HAFileAdapterDB2をそれぞれ指定します。
ファイル/FTPアダプタでは、HA機能のためにデータベース・ベースのコーディネータだけでなくCoherenceもサポートされています。このためには、ファイル・アダプタの場合はeis/CoherenceHAFileAdapter、FTPアダプタの場合はeis/Ftp/CoherenceHAFtpAdapterを指定できます。
次に示すファイル・アダプタ用の.jcaファイルでは、コネクション・ファクトリがCoherenceHAFileAdapterとして指定されています。
例 - コネクション・ファクトリとしてCoherenceHAFileAdapterが指定されたファイル・アダプタ用の.jcaファイル
<adapter-config name="FileHACoherenceIn"
adapter="File Adapter"
wsdlLocation="FileHACoherenceIn.wsdl"
xmlns="http://platform.integration.
oracle/blocks/adapter/fw/metadata">
<connection-factory location=
"eis/CoherenceHAFileAdapter"
UIincludeWildcard="*.zip" adapterRef=""/>
<endpoint-activation portType="Read_ptt"
operation="Read">
<activation-spec className=
"oracle.tip.adapter.file.
inbound.
FileActivationSpec">
<[..]>
<[..]>
</activation-spec>
</endpoint-activation>
</adapter-config>
Oracleファイル/FTPアダプタでは、複数の参照が同じディレクトリに書き込まれた場合に相互に上書きされないことが保証されています。
アダプタは、データベース表を使用して、フォルダ内の同じファイルに対する同時書込みへのアクセスをシリアライズします。この手順はインバウンド操作の場合と同様であり、Oracle表を使用するeis/HAFileAdapterを選択するか、SQL Serverの場合はeis/HAFileAdapterMQSSQL、DB2の場合はeis/HAFileAdapterDB2をそれぞれ選択する必要があります。
ファイル/FTPアダプタでのインバウンド操作に対する高可用性と同様に、ファイル/FTPアダプタでアウトバウンド操作を実行する場合も、高可用性機能のためのCoherenceがサポートされています。設計の経験に基づいて、ファイル・アダプタの場合はeis/CoherenceHAFileAdapter、FTPアダプタの場合はeis/Ftp/CoherenceHAFtpAdapterを.jcaファイル内に指定する必要があります。
ファイル/FTPアダプタでは、Coherenceをロッキング・メカニズムとして使用して、インバウンドとアウトバウンドの両方で高可用性をサポートしています。
インバウンド処理の場合、ファイル/FTPアダプタは、ファイル処理(ファイル変換を実行してファブリックにパブリッシュするなど)を試行する前にファイルをロックする必要があります。同じファイルに対するロックが別のノードによってすでに保持されている場合、アダプタはそのファイルを無視して、次のファイルの処理に進みます。
ある特定のノードがすべてのファイルに対するロックを取得してファイルの配信を独占することがないように、インバウンド処理に対してMaxRaiseSizeを有限値に構成する必要があります。次の例を参照してください。
例 - MaxRaiseSizeが有限値に構成された.jcaファイル
<adapter-config name="FileHACoherenceIn" adapter="File Adapter" wsdlLocation="FileHACoherenceIn.wsdl" xmlns="http://platform.integration.oracle/blocks/
adapter/fw/metadata">
<connection-factory location="eis/CoherenceHAFileAdapter" UIincludeWildcard="*.zip" adapterRef=""/>
<endpoint-activation portType="Read_ptt" operation="Read">
<activation-spec className="oracle.tip.adapter.file.inbound.FileActivationSpec">
<property name="MaxRaiseSize" value="100"/>
<[..]>
<[..]>
</activation-spec>
</endpoint-activation>
</adapter-config>
また、(たとえば、Readonly pollingに対して) DeleteFile = "false"を構成した場合や、デバッチ処理を使用する場合は、クラスタ内のすべてのノードが同じパスを参照するように、有効な共有場所を構成する必要があります。いずれの場合も、ファイル/FTPアダプタはなんらかのコントロール情報を共有コントロール・ディレクトリに格納し、処理中に1つのノードが停止すると2つ目のノードがまったく同じコントロール情報を参照するため、これが必要となります。
独自のCoherenceキャッシュを指定するには、次のいずれかのパラメータを使用します。
CoherenceCacheConfig - Coherenceキャッシュ構成の相対パス
InboundCoherenceCacheName - インバウンドのファイル/FTPアダプタに使用されるCoherence NamedCache
OutboundCoherenceCacheName - アウトバウンドのファイル/FTPアダプタに使用されるCoherence NamedCache
独自のキャッシュ構成を作成する場合、キャッシュ構成をjarファイル内にバンドルして、サーバーのクラスパスに追加します(キャッシュ構成を含むjarファイルを$DOMAIN_HOME/libディレクトリにコピーしてから、コネクション・ファクトリ内の構成を参照する方法が簡単です)。デフォルト値が提供されています。
例 - 独自のCoherenceキャッシュの指定
<wls:properties>
<wls:property>
<wls:name>CoherenceCacheConfig</wls:name>
<wls:value>config/
fileadapter-cache-config.xml</wls:value>
</wls:property>
<wls:property>
<wls:name>InboundCoherenceCacheName</wls:name>
<wls:value>FileAdapter-inbound</wls:value>
</wls:property>
<wls:property>
<wls:name>OutboundCoherenceCacheName</wls:name>
<wls:value>FileAdapter-outbound</wls:value>
</wls:property>
<wls:property../>
<wls:property../>
<wls:properties>
クラスタ内の同じファイルに追加する場合、アダプタが、追加先のfilename beginの名前付きキャッシュに対する明示的なロックを取得する必要があります。
また、バッチ処理を使用する場合、バッチ処理基準でアウトバウンド・フォルダへの書込みを強制するように評価される前に、バッチ処理されたコンテンツを格納するためのコントロール・ディレクトリが必要です。
アウトバウンドでのHAを実現するためには、アダプタには共有ファイル・システムに対するコントロール・ディレクトリが必要です(これはインバウンドでの機能と同様です)。
高可用性シナリオでXAトランザクション機能を提供する場合は、次の手順を実行します。
oracle.tip.adapter.file.NonSharedConnectionFactoryを選択します。図4-56 「oracle.tip.adapter.file.NonSharedConnectionFactory」が選択されたWebLogicコンソールのファイル・アダプタ・デプロイメント
図4-58 アウトバウンド接続プロパティが表示されたインスタンスを示すWebLogicコンソール
表4-20 も参照してください
表4-20 JNDIインスタンスのアウトバウンド接続プロパティ
| プロパティ | プロパティ・タイプ | プロパティ値 | 動的索引付けのサポート |
|---|---|---|---|
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
|
java.lang.string |
|
False |
この項は、次のOracleファイル/FTPアダプタの使用例で構成されています。
これは、大きいXML文書を小さい個別のXMLフラグメントにデバッチするOracleファイル・アダプタ機能です。
この使用例では、XMLのデバッチ・プロセスでOracleファイル・アダプタを使用し、繰返しノードとしてXMLファイルで発生する従業員のバッチを含むXMLファイルをデバッチします。その後、アダプタによってこれらのノードが処理され、個々の各ノードが個別の出力ファイルに書き込まれます。
この使用例には、次の項目が含まれます。
デバッチを実行するには、Adapters-102FileAdapterXMLDebatchingサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。
artifacts/input/emps.xml
artifacts/schemas/employees.xsd
Adapters-102FileAdapterXMLDebatchingサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
この項では、反復要素を含む入力XMLドキュメントをより小さいドキュメントに分割するプロセスについて説明します。これは、ファイル・アダプタまたはFTPアダプタでXMLデバッチ処理を使用する場合に役に立ちます。
nxsd:elementDepthは、XML構造の反復要素maxOccurs=’unboundedがルート要素の直下の子孫ではない場合に、XMLのデバッチ処理を促進するスキーマ・レベルの注釈です。nxsd:elementDepthの値は、XSDに定義されたXML構造に準拠する必要があります。 反復要素を含むXMLドキュメントの例
<root> <ElementList> <element1> <element11>11</element11> <element12>12</element12> </element1> <element1> <element11>21</element11> <element12>22</element12> </element1> <element1> <element11>31</element11> <element12>32</element12> </element1> </ElementList> </root>
反復要素を含むXMLドキュメントを分割する手順
注意:
設計時に正しい値を適用します。正しい値は、ルート要素の下から始まるレベルの数です。値が正しくないと、予期しない結果が発生し、無効なXMLドキュメントが生成されます。たとえば、次のスキーマで必要な出力を得るためには、反復要素<element1>がルート要素<root>の2レベル下に位置するので、nxsd:elementDepthは2に設定する必要があります。 必要な出力を生成するには、 xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:elementDepth="2"を追加して、XMLスキーマを変更します
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.examplefileIn.org"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:elementDepth="2"
targetNamespace="http://www.examplefileIn.org"
elementFormDefault="qualified">
<xsd:element name="root">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ElementList">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="element1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="element11" type="xsd:string"/>
<xsd:element name="element12" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
SOA-XMLDebatchingと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。
BPELXMLDebatchingと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。
XMLDebatchingInと入力します。
*.xmlと入力し、「ファイルが複数のメッセージを含む」チェック・ボックスを選択し、「バッチでメッセージをパブリッシュする数」ボックスの値として1を指定します。
composite.xmlが表示されます。ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・ファイル・アダプタ・サービスを作成するには、次の手順を実行します。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-75 のように表示されます。
この項では、反復要素を含む入力XMLドキュメントをより小さいドキュメントに分割するプロセスについて説明します。これは、ファイル・アダプタまたはFTPアダプタでXMLデバッチ処理を使用する場合に役に立ちます。
nxsd:elementDepthは、XML構造の反復要素maxOccurs=’unboundedがルート要素の直下の子孫ではない場合に、XMLのデバッチ処理を促進するスキーマ・レベルの注釈です。nxsd:elementDepthの値は、XSDに定義されたXML構造に準拠する必要があります。 反復要素を含むXMLドキュメントの例
<root> <ElementList> <element1> <element11>11</element11> <element12>12</element12> </element1> <element1> <element11>21</element11> <element12>22</element12> </element1> <element1> <element11>31</element11> <element12>32</element12> </element1> </ElementList> </root>
反復要素を含むXMLドキュメントを分割する手順
注意:
設計時に正しい値を適用します。正しい値は、ルート要素の下から始まるレベルの数です。値が正しくないと、予期しない結果が発生し、無効なXMLドキュメントが生成されます。たとえば、次のスキーマで必要な出力を得るためには、反復要素<element1>がルート要素<root>の2レベル下に位置するので、nxsd:elementDepthは2に設定する必要があります。 必要な出力を生成するには、 xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:elementDepth="2"を追加して、XMLスキーマを変更します
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.examplefileIn.org"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:elementDepth="2"
targetNamespace="http://www.examplefileIn.org"
elementFormDefault="qualified">
<xsd:element name="root">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ElementList">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="element1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="element11" type="xsd:string"/>
<xsd:element name="element12" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
TransformPayloadと入力します。前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
この使用例では、フラット構造のビジネス・プロセスでOracleファイル・アダプタを使用して、カンマ区切り値(CSV)ファイルのアドレス帳エントリを処理する方法について説明します。これらのエントリは、その後変換されて固定長フォーマットで別のファイルに書き込まれます。
この使用例には、次の項目が含まれます。
フラット構造のビジネス・プロセスを実行するには、Adapters-101FileAdapterFlatStructureサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。
artifacts/input/address-csv.txt
artifacts/schemas/address-csv.xsd
artifacts/schemas/address-fixedLength.xsd
artifacts/xsl/addr1Toaddr2.xsl
Adapters-101FileAdapterFlatStructureサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-92 のように表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
この使用例では、メディエータがReadFileというインバウンドOracleファイル・アダプタ・サービスを介して、ファイルシステムから顧客データをテキスト・ファイルとして受信します。ReadFileアダプタ・サービスから、ReadFile_RSというルーティング・サービスにメッセージが送信されます。ReadFile_RSからアウトバウンド・アダプタ・サービスWriteFTPにメッセージが送信されます。WriteFTPサービスにより、メッセージが関連外部アプリケーションに配信されます。
この使用例には、次の項目が含まれます。
この例は、基本的なコンストラクト(サービスやルーティング・サービスなど)と、サービスを作成およびデプロイするJDeveloper環境を十分に理解していることを前提としています。
フラット構造のビジネス・プロセスを実行するには、Adapters-101FileAdapterFlatStructureサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。
artifacts/schemas/address-csv.xsd
Adapters-101FileAdapterFlatStructureサンプルを参照するには、Oracle SOA Sample Codeサイトにアクセスします。
使用例のアプリケーションとプロジェクトを作成するには、次の手順を実行します。
FileFTP_RWと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。FileRead_FTPWriteと入力します。FileRead_RSと入力します。FileFTP_RWアプリケーションとFileRead_FTPWriteプロジェクトが設計領域に表示されます。メッセージの構造を定義するXSDファイルをインポートするには、次の手順を実行します。
Schemaディレクトリを作成し、このディレクトリにaddress-csv.xsdファイルをコピーします(このファイルの場所の詳細は、「前提条件」を参照)。
「アプリケーション・ナビゲータ」で「FileRead_FTPWrite」を選択します。
「ファイル」メニューから「インポート」を選択します。「インポート」ダイアログが表示されます。
「インポートするものを選択」リストから「Webソース」を選択して「OK」をクリックします。「Webソース」ダイアログが表示されます。
「コピー元」フィールドの右側にある「参照」をクリックします。「ディレクトリの選択」ダイアログが表示されます。
「スキーマ」ディレクトリにナビゲートして「選択」をクリックします。ディレクトリが選択された状態で「Webソース」ダイアログが表示されます。
「OK」をクリックします。
ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します
ReadFileと入力します。*.txtと入力して「次へ」をクリックします。「ファイル・ポーリング」ページが表示されます。FTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。
WriteFTPと入力します。po_%SEQ%.txtを指定します。作成した3つのコンポーネント(インバウンド・サービス、コンポーネント、アウトバウンド参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
composite.xmlが図4-96 のように表示されます。前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
この使用例では、スケーラブルなDOMプロセスでストリーミング機能を使用して、大型ファイルをディレクトリ間でコピーまたは移動する方法を説明します。
ストリーミング・オプションは、DB2のハイドレーション・ストアではサポートされません。
この使用例には、次の項目が含まれます。
大きいペイロードのストリーミング・プロセスを実行するには、Adapters-103FileAdapterScalableDOMサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。
artifacts/schemas/address-csv.xsd
artifacts/input/address-csv-large.txt
Adapters-103FileAdapterScalableDOMサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
SOA-ScalableDOMと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。ScalableDOMと入力します。BPELScalableDOMと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-102 のように表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
チャンク読取りは、whileループ内でinvokeアクティビティを使用してターゲット・ファイルを処理するOracleファイル・アダプタ機能です。この機能を使用すると、大きいファイルを適宜処理できます。
この使用例には、次の項目が含まれます。
ChunkRead操作を実行するには、Adapters-106FileAdapterChunkedReadサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。
artifacts/schemas/address-csv.xsd
artifacts/schemas/address-fixedLength.xsd
artifacts/xsl/addr1Toaddr2.xsl
artifacts/input/address-csv.txt
Adapters-106FileAdapterChunkedReadサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
SOAコンポジット・アプリケーションを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。
ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。
composite.xmlが表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、2つのアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-114 のように表示されます。
<variable name="dir" type="xsd:string"/>
<variable name="file" type="xsd:string"/>
<variable name="outIsEOF" type="xsd:string"/>
<variable name="outLineNumber" type="xsd:string"/>
<variable name="outColumnNumber" type="xsd:string"/>
<variable name="returnIsEOF" type="xsd:string"/>
<variable name="returnLineNumber" type="xsd:string"/>
<variable name="returnColumnNumber" type="xsd:string"/>
<variable name="returnIsMessageRejected" type="xsd:string"/>
<variable name="returnRejectionReason" type="xsd:string"/>
<variable name="returnNoDataFound" type="xsd:string"/>
注意:
すべての変数は、タイプxsd:stringの単純型です。
jca.file.FileNameプロパティに対して同じ手順を繰り返し、値をfileに設定します。図4-116 に示すように、「Receive」ダイアログが表示されます。図4-116 「Receive」ダイアログ - 「アダプタ」タブ
CopyHeadersというassignアクティビティを追加し、invokeアクティビティからreturnパラメータをコピーします。図4-122 に示すように、Assignダイアログが表示されます。前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
これは、ファイルシステムのソース・ディレクトリから宛先ディレクトリに大量のデータを添付ファイルとして不透明にコピーまたは移動するOracleファイル・アダプタ機能です。たとえば、大量のMS Word文書、イメージおよびPDFをコンポジット・アプリケーション内でコンテンツを処理せずに転送できます。添付ファイルとしてのファイル読取り機能は、「Read File」オプションが選択されている場合にのみ使用できます。
この使用例では、大きい*.docファイルを添付ファイルとして処理するOracleファイル・アダプタの機能について説明します。添付ファイルとしてファイルを読み取るこの機能は、Opaque変換によく似ています。ただし、GB規模の添付ファイルが可能であるかどうかはデータベースの制限によって異なります。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
AttachmentAppアプリケーションとAttachmentプロジェクトが設計領域に表示されます。ローカル・ディレクトリから大きいファイルを読み取るインバウンドのサービスを作成するには、次の手順を実行します。
注意:
「キャラクタ・セット」、「エンコーディング」および「コンテンツ・タイプ」の各フィールドは無視してください。この添付ファイルの読取りを必要とするサード・パーティのアプリケーションを使用している場合にのみ、これらのフィールドに値を移入します。この使用例の添付ファイルは、最終的にアウトバウンドで使用されるため、これらの値は必要としません。
composite.xmlが表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-132 のように表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
これは、invokeアクティビティを使用してターゲット・ディレクトリからファイルのリストを取得するOracleファイル・アダプタ機能です。このファイルのリストはXML文書として返され、ファイル名、ディレクトリ名、ファイル・サイズ、最終変更時間などの情報が記載されています。
この使用例には、次の項目が含まれます。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
ターゲット・ディレクトリのファイルのリストを表示するアウトバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。作成した2つのコンポーネント(BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-145 のように表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
この使用例では、カスタム・フォーマットで定義されたネイティブ・データを処理するOracleファイル・アダプタ機能について説明します。このサンプルでは、カスタム・フォーマットはinvoice-nxsd.xsdに定義されている請求書を表します。Oracleファイル・アダプタでは、invoice.txtファイルを処理してComplexStructure BPELプロセスにパブリッシュします。その後、PurchaseOrderに変換されてxmlファイルとして書き出されます。
この使用例には、次の項目が含まれます。
複雑な構造のビジネス・プロセスを実行するには、Adapters-104FileAdapterComplexStructureサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。
artifacts/schemas/invoice-nxsd.xsd
artifacts/schemas/po.xsd
artifacts/xsl/InvToPo.xsl
artifacts/input/invoice.txt
Adapters-104FileAdapterComplexStructureサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-155 のように表示されます。
ReceiveInvoiceと入力します。InvokeWriteと入力します。InvokeWrite_Write_OutputVariableと入力し、「OK」をクリックします。「Invoke」ダイアログが表示されます。前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
これは、大きいXML文書を小さい個別のXMLフラグメントにデバッチするOracle FTPアダプタの機能です。この使用例では、ビジネス・プロセス・サンプルのデバッチ処理でOracle FTPアダプタを使用して、1つ以上の請求書や発注などのビジネス・レコードのバッチを含むファイルを処理する方法について説明します。これにより、発注(PO)がデバッチされて個別の出力ファイルに書き込まれます。
この使用例には、次の項目が含まれます。
複雑な構造のビジネス・プロセスを実行するには、Adapters-101FTPAdapterDebatchingサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。
artifacts/schemas/container.xsd
artifacts/schemas/po.xsd
artifacts/xsl/InvToPo.xsl
artifacts/xsl/PoToPo.xsl
artifacts/input/container.txt
Adapters-101FTPAdapterDebatchingサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-162 のように表示されます。
「BPELFTPDebatching.bpel」ページが表示されます。Receiveと入力します。「BPELFTPDebatching.bpel」ページが表示されており、receiveアクティビティが追加されています。Writeと入力します。Write_Put_OutputVariableと入力し、「OK」をクリックします。Invokeダイアログが表示されます。「BPELFTPDebatching.bpel」ページが表示されており、invokeアクティビティが追加されています。「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にswitchアクティビティをドラッグ・アンド・ドロップします。
switchアクティビティを開きます。これにより、<case>および<otherwise>の値を入力するための画面が表示されます。
図4-163 に示すように、「<case>」セクションで「条件式の表示」アイコンをクリックします。「条件式」ポップアップ・ウィンドウが表示されます。
ポップアップ・ウィンドウ内で「XPath式ビルダー」アイコンをクリックします。「式ビルダー」ダイアログが表示されます。
図4-164 に示すように、式としてstarts-with(local-name(ora:getNodes('receive_Get_InputVariable','body','/ns3:container/child::*[position()=1]')),'invoice')を入力し、「OK」をクリックします。画面が「条件式」ポップアップ・ウィンドウに戻ります。
「<case>」セクションと「<otherwise>」セクションに1つずつ、2つのトランスフォーメーション・アクティビティを追加します。
transformアクティビティを「<case>」セクションにドラッグ・アンド・ドロップします。
transformアクティビティをダブルクリックします。
「名前」フィールドにInvToPoと入力します。
「トランスフォーメーション」タブをクリックします。
「作成」アイコンをクリックします。「ソース変数」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
「ターゲット変数」リスト「Write_Put_OutputVariable」を選択します。
「マッパー・ファイル」フィールドの端にある「マッピングの参照」アイコンをクリックし、「InvToPo.xsl」ファイルを選択します。
「OK」をクリックします。
同じプロセスを第2のトランスフォーメーションについて繰り返します。このtransformアクティビティの場合は、マッパー・ファイルとしてPoToPo.xslを選択します。
図4-165 に示すように、「BPELFTPDebatching.bpel」ページが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
この使用例では、invokeアクティビティを使用してプロセス途中の同期読取り操作を実行するOracle FTPアダプタの機能について説明します。この使用例で説明するアダプタ機能は、次のとおりです。
Oracleファイル・アダプタ(読取り操作)
Oracle FTPアダプタ(同期読取り操作)
実行時に読取り対象のファイル名を指定する機能
Oracleファイル・アダプタ(書込み操作)
このプロセスは、インバウンドOracleファイル・アダプタによる監視対象のローカル・ディレクトリにファイルが存在することで開始されます。トリガー・ファイルには、同期読取り操作で読み取られるファイルの名前が含まれています。このファイル名は、ヘッダーを介してアダプタに渡されます。これを行うには、invokeアクティビティの「プロパティ」タブを使用します。この同期読取り操作は、FTPサーバー上のリモート・ディレクトリに対して実行されます。読取り結果は変換され、アウトバウンドOracleファイル・アダプタを介してローカル・ディレクトリに書き出されます。この項には次のトピックが含まれます:
FTPの動的同期読取りを実行するには、Adapters-102FTPAdapterDynamicSynchronousReadサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。
artifacts/schemas/address-csv.xsd
artifacts/schemas/address-fixedLength.xsd
artifacts/schemas/trigger.xsd
artifacts/xsl/addr1Toaddr2.xsl
artifacts/input/address_csv.txt
artifacts/input/trigger.trg
Adapters-102FTPAdapterDynamicSynchronousReadサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。
composite.xmlが表示されます。
composite.xmlが表示されます。作成した4つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、2つのアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
JDeveloperのcomposite.xmlが図4-170 のように表示されます。
ReceiveTriggerと入力します。図4-172 JDeveloper - 「BPELDynamicSynchronousRead.bpel」ページ
図4-174 JDeveloper - BPELDynamicSynchronousRead.bpel
図4-175 JDeveloper - BPELDynamicSynchronousRead.bpel
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
使用すると、ある場所から別の場所にファイルをコピーまたは移動したり、ターゲット・ディレクトリからファイルを削除できます。さらに、ローカル・ファイルシステムとリモート・ファイルシステムの間でファイルをコピーまたは移動できます。この機能は、アウトバウンド・サービスの相互作用仕様として実装されます。そのため、BPELのinvokeアクティビティまたはメディエータのルーティング・ルールを使用してこの機能にアクセスできます。
高レベルでは、アウトバウンド・サービスを作成して、ソース・ディレクトリおよびターゲット・ディレクトリとファイル名を使用してこのサービスを構成する必要があります。
次の使用例では、アウトバウンド・サービスの使用によりファイルをコピー、移動および削除できる、サポートされている新機能を説明しています。
ウィザードで実行できるのはこの手順の一部のみです。これは、該当するアダプタ構成ウィザードが使用可能でないためです。生成したJCAファイルを手動で構成することにより、残りの手順を完了してください。
ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリにファイルを移動するには、次の手順を実行します。
空のBPELプロセスを作成します。
「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。「アダプタ構成ウィザード - ようこそ」ページが表示されます。
「Next」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにサービス名を入力します。
「Next」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。
「同期Read File」を選択し、「操作名」フィールドにFileMoveと入力して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。
注意:
同期Read Fileを選択したのは、この操作の結果として生成されるWSDLファイルが、I/O操作に必要なファイルと同様のものであるためです。
着信ファイル用のディレクトリのダミー物理パスを入力し、「次へ」をクリックします。「ファイル名」ページが表示されます。
注意:
このダミー・ディレクトリは使用されません。以降の手順でこのディレクトリを手動で変更する必要があります。
ダミー・ファイル名を入力し、「次へ」をクリックします。「メッセージ」ページが表示されます。
注意:
入力したダミー・ファイル名は使用されません。以降の手順でこのファイル名を手動で変更する必要があります。
「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。これで、アウトバウンドの構成は完了です。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFileMove内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。BPELコンポーネントがアウトバウンド・サービスに接続されます。
デフォルト設定を選択して、先ほど作成したFileMoveサービスのinvokeアクティビティを作成します。
次の手順では、生成したWSDLファイルをMoveFileServiceサービス用に変更し、移動操作の新規の相互作用仕様で構成します。
次の例に示すように、FileMove_file.jcaファイルを開いてエンドポイント相互作用を変更します。
JCAファイルは、ソース・ディレクトリおよびターゲット・ディレクトリとファイルの詳細を使用して構成する必要があります。ソース・ディレクトリおよびターゲット・ディレクトリとファイルの詳細は、JCAファイルでハードコードすることも、ヘッダー変数を使用して移入することもできます。この例では、ヘッダー変数が使用されています。
例 - ソース・ディレクトリとターゲット・ディレクトリおよびファイルの詳細を含むJCAファイルの構成
<adapter-config name="FileMove" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/FileAdapter" adapterRef=""/>
<endpoint-interaction portType="FileMove_ptt" operation="FileMove">
<interaction-spec
className="oracle.tip.adapter.file.outbound.FileIoInteractionSpec">
<property name="SourcePhysicalDirectory" value="foo1"/>
<property name="SourceFileName" value="bar1"/>
<property name="TargetPhysicalDirectory" value="foo2"/>
<property name="TargetFileName" value="bar2"/>
<property name="Type" value="MOVE"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
注意:
className属性が変更され、SourcePhysicalDirectory、SourceFileName、TargetPhysicalDirectory、TargetFileNameおよびTypeが追加されました。現在、ソースおよびターゲットの詳細の値はダミーです。これらは実行時に移入する必要があります。これらの値を特定のディレクトリまたはファイル名にハードコードすることもできます。
Type属性によって操作のタイプが決まります。Type属性の許容値にはMOVEの他にCOPYとDELETEがあります。
次の手順を実行して、実際のディレクトリ名とファイル名をソース・ファイルとターゲット・ファイルのパラメータにマッピングします。
適切な名前を付けた4つの文字列変数を作成します。ソース・ディレクトリおよびターゲット・ディレクトリの詳細にこれらの変数を移入する必要があります。BPELソース・ビューに次のように表示されます。
<variables>
<variable name="InvokeMoveOperation_FileMove_InputVariable"
messageType="ns1:Empty_msg"/>
<variable name="InvokeMoveOperation_FileMove_OutputVariable"
messageType="ns1:FileMove_msg"/>
<variable name="sourceDirectory" type="xsd:string"/>
<variable name="sourceFileName" type="xsd:string"/>
<variable name="targetDirectory" type="xsd:string"/>
<variable name="targetFileName" type="xsd:string"/>
</variables>
assignアクティビティを作成し、sourceDirectory、sourceFileName、targetDirectoryおよびtargetFileName変数に値を割り当てます。この割当て操作は、BPELソース・ビューに次の例のように表示されます。
例 - 値を割り当てるためのassignアクティビティの作成
<assign name="AssignFileDetails">
<copy>
<from expression="'/home/alex'"/>
<to variable="sourceDirectory"/>
</copy>
<copy>
<from expression="'input.txt'"/>
<to variable="sourceFileName"/>
</copy>
<copy>
<from expression="'/home/alex'"/>
<to variable="targetDirectory"/>
</copy>
<copy>
<from expression="'output.txt'"/>
<to variable="targetFileName"/>
</copy>
</assign>
この例では、/home/alexから/home/alex内のoutput.txtにinput.txtが移動されます。
注意:
この例では、ソースおよびターゲットの詳細がハードコードされています。これらの詳細は、ランタイム・パラメータとして指定することもできます。
これらのパラメータをヘッダーとして起動操作に渡します。これらの変数値によってJCAファイルのパラメータがオーバーライドされます。
例 - パラメータをヘッダーとして起動操作に渡す方法
<invoke name="InvokeMoveOperation"
inputVariable="InvokeMoveOperation_FileMove_InputVariable"
outputVariable="InvokeMoveOperation_FileMove_OutputVariable"
partnerLink="FileMove" portType="ns1:FileMove_ptt"
operation="FileMove">
<bpelx:inputProperty name="jca.file.SourceDirectory"
variable="sourceDirectory"/>
<bpelx:inputProperty name="jca.file.SourceFileName"
variable="sourceFileName"/>
<bpelx:inputProperty name="jca.file.TargetDirectory"
variable="targetDirectory"/>
<bpelx:inputProperty name="jca.file.TargetFileName"
variable="targetFileName"/>
</invoke>
最後に、最初のreceiveまたはpickアクティビティを追加します。
ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動が完了しました。
ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリにファイルをコピーするには、次の手順を実行します。
ファイルを削除するには、TargetPhysicalDirectoryおよびTargetFileNameパラメータが必要です。
注意:
ローカル・ファイルシステム・ディレクトリからファイルを削除する場合、SourcePhysicalDirectoryおよびSourceFileNameは必要ありません。
ファイルdelete_me.txtを/home/alexディレクトリから削除するには、次の手順を実行します。
サイズが1GBの大きいCSVファイルをソース・ディレクトリで使用するシナリオを想定します。その場合は、次の手順を実行する必要があります。
CSVをXMLに変換します。
結果として生じたXMLをXSLを使用して変換します。
変換操作で生じたファイルを固定長ファイルに変換します。
この使用例は、BPELサンプル・ディレクトリのFlatStructureサンプルと似ています。相違点は、1つのファイルI/O相互作用で3つの手順が発生することです。
注意:
3つの手順はすべて、1つのファイルI/O相互作用で発生します。これは、データ・ファイル内のすべてのレコードが同じタイプに属している場合にのみ該当します。
大きいCSVファイルを使用して前述のシナリオに記載された操作を実行するには、次の手順を実行します。
I/Oの使用例は、使用例とよく似ています。ただし、注意が必要な微妙な相違点がいくつかあります。
この使用例では、同じディレクトリ内にファイルを移動しますが、これは、同じサーバー上での名前の変更操作に似ています。ほとんどのFTPサーバーは、FTPサーバーでのファイルの名前変更を行うRNFR/RNTOのFTPコマンドをサポートしています。
ただし、RNFR/RNTOコマンドをサポートしていない場合でも、バインディング・プロパティUseNativeRenameOperationを使用すれば同じディレクトリ内にファイルを移動できます。デフォルトでは、このプロパティはTRUEに設定されています。その場合は、ネイティブのRNFR/RNTOコマンドが使用されます。ただし、このプロパティをFALSEに設定すると、移動操作をエミュレートするためにGetコマンドとPutコマンド、さらにDeleteコマンドが使用されます。
ウィザードで実行できるのはこの手順の一部のみです。これは、該当するアダプタ構成ウィザードが使用可能でないためです。生成したJCAファイルを手動で構成することにより、残りの手順を完了してください。
リモート・ディレクトリから同じFTPサーバーの別のリモート・ディレクトリにファイルを移動するには、次の手順を実行します。
空のBPELプロセスを作成します。
「コンポーネント」ウィンドウから「外部参照」スイムレーンにFTPアダプタをドラッグ・アンド・ドロップします。「アダプタ構成ウィザード - ようこそ」ページが表示されます。
「Next」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにサービス名を入力します。
「Next」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「Next」をクリックします。「FTPサーバー接続」ページが表示されます。
FTPサーバーのJNDI名を入力して「次へ」をクリックします。「操作」ページが表示されます。
「同期Get File」を選択し、「操作名」フィールドにFTPMoveと入力して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。
注意:
同期Get Fileを選択したのは、この操作の結果として生成されるWSDLファイルが、I/O操作に必要なファイルと同様のものであるためです。
着信ファイル用のディレクトリのダミー物理パスを入力し、「次へ」をクリックします。「ファイル名」ページが表示されます。
注意:
このダミー・ディレクトリは使用されません。以降の手順でこのディレクトリを手動で変更する必要があります。
ダミー・ファイル名を入力し、「次へ」をクリックします。「ファイル名」ページが表示されます。
注意:
入力したダミー・ファイル名は使用されません。以降の手順でこのファイル名を手動で変更する必要があります。
「Next」をクリックします。「メッセージ」ページが表示されます。
「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。これで、アウトバウンドの構成は完了です。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFTPMove内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。BPELコンポーネントがアウトバウンド・サービスに接続されます。
「ファイル」、「すべて保存」を順番にクリックします。
先ほど作成したFTPMoveサービスのinvokeアクティビティを作成します。
次の手順では、生成したWSDLファイルをFTPMoveサービス用に変更し、移動操作の新規の相互作用仕様で構成します。
次の例に示すように、FTPMove_ftp.jcaファイルを開いてinteraction-specを変更します。
JCAファイルは、ソース・ディレクトリおよびターゲット・ディレクトリとファイルの詳細を使用して構成する必要があります。ソース・ディレクトリおよびターゲット・ディレクトリとファイルの詳細は、JCAファイルでハードコードすることも、ヘッダー変数を使用して移入することもできます。
この例では、ヘッダー変数が使用されています。
例 - 移動操作のためのjcaファイルのinteraction-spec部分の変更
<adapter-config name="FTPMove" adapter="Ftp Adapter"
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/Ftp/FtpAdapter" adapterRef=""/>
<endpoint-interaction portType="FTPMove_ptt" operation="FTPMove">
<interaction-spec
className="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec">
<property name="SourcePhysicalDirectory" value="foo1"/>
<property name="SourceFileName" value="bar1"/>
<property name="TargetPhysicalDirectory" value="foo2"/>
<property name="TargetFileName" value="bar2"/>
<property name="Type" value="MOVE"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
注意:
className属性が変更され、SourcePhysicalDirectory、SourceFileName、TargetPhysicalDirectory、TargetFileNameおよびTypeが追加されました。現在、ソースおよびターゲットの詳細の値はダミーです。これらは実行時に移入する必要があります。これらの値を特定のディレクトリまたはファイル名にハードコードすることもできます。
Type属性によって操作のタイプが決まります。Type属性の許容値にはMOVEの他にCOPYとDELETEがあります。
次の手順を実行して、実際のディレクトリ名とファイル名をソース・ファイルとターゲット・ファイルのパラメータにマッピングします。
適切な名前を付けた4つの文字列変数を作成します。ソース・ディレクトリおよびターゲット・ディレクトリの詳細にこれらの変数を移入する必要があります。BPELソース・ビューに次のように表示されます。
<variables>
<variable name="InvokeMoveOperation_FileMove_InputVariable"
messageType="ns1:Empty_msg"/>
<variable name="InvokeMoveOperation_FileMove_OutputVariable"
messageType="ns1:FileMove_msg"/>
<variable name="sourceDirectory" type="xsd:string"/>
<variable name="sourceFileName" type="xsd:string"/>
<variable name="targetDirectory" type="xsd:string"/>
<variable name="targetFileName" type="xsd:string"/>
</variables>
assignアクティビティを作成し、sourceDirectory、sourceFileName、targetDirectoryおよびtargetFileName変数に値を割り当てます。この割当て操作は、BPELソース・ビューに次の例のように表示されます。
例 - assignアクティビティの作成
<assign name="AssignFTPFileDetails">
<copy>
<from expression="'/home/ftp'"/>
<to variable="sourceDirectory"/>
</copy>
<copy>
<from expression="'input.txt'"/>
<to variable="sourceFileName"/>
</copy>
<copy>
<from expression="'/home/ftp/out'"/>
<to variable="targetDirectory"/>
</copy>
<copy>
<from expression="'output.txt'"/>
<to variable="targetFileName"/>
</copy>
</assign>
この例では、input.txtが/home/ftpから/home/ftp/out内のoutput.txtに移動または名前変更されます。
注意:
この例では、ソースおよびターゲットの詳細がハードコードされています。これらの詳細は、ランタイム・パラメータとして指定することもできます。
これらのパラメータをヘッダーとして起動操作に渡します。これらの変数値によってJCAファイルのパラメータがオーバーライドされます。
例 - パラメータをヘッダーとして起動操作に渡す方法
<invoke name="InvokeRenameService" inputVariable="InvokeRenameService_RenameFile_InputVariable" partnerLink="RenameFTPFile" portType="ns2:RenameFile_ptt" operation="RenameFile"> <bpelx:inputProperty name="jca.file.SourceDirectory" variable="returnDirectory"/> <bpelx:inputProperty name="jca.file.SourceFileName" variable="returnFile"/> <bpelx:inputProperty name="jca.file.TargetDirectory" variable="returnDirectory"/> <bpelx:inputProperty name="jca.file.TargetFileName" variable="targetFile"/> </invoke>
最後に、最初のreceiveまたはpickアクティビティを追加します。
リモート・ディレクトリから同じFTPサーバーの別のリモート・ディレクトリへのファイルの移動または名前変更が完了しました。
注意:
FTPサーバーがRNFR/RNTOのFTPコマンドをサポートしていない場合は、次の例に示すように、UseNativeRenameOperationをFALSEに設定し、composite.xmlでプロパティを定義する必要があります。
<reference name="FTPMove" ui:wsdlLocation="FTPMove.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel
/adapter/ftp/SOAFtpIO/SOAFtpIO/
FTPMove/#wsdl.interface(FTPMove_ptt)"/>
<binding.jca config="FTPMove_ftp.jca">
<property name="UseNativeRenameOperation"
type="xs:string" many="false" override="may">false</property>
</binding.jca>
</reference>
この使用例の手順は「あるリモート・ディレクトリから同じFTPサーバーの別のリモート・ディレクトリへのファイルの移動」の使用例と同じです。ただし、ソース・ディレクトリをローカルとして、ターゲット・ディレクトリをリモートとして構成する必要があります。
次の例に示すように、SourceIsRemoteおよびTargetIsRemoteプロパティを使用して、ソース・ファイルおよびターゲット・ファイルをローカル・ファイルシステムまたはリモート・ファイルシステムのいずれに置くかを指定します。
例 - SourceIsRemoteおよびTargetIsRemoteプロパティの使用
<adapter-config name="FTPMove" adapter="Ftp Adapter"
xmlns="http://platform.integration.oracle/
blocks/adapter/fw/metadata">
<connection-factory location="eis/Ftp/FtpAdapter"
adapterRef=""/>
<endpoint-interaction portType="FTPMove_ptt"
operation="FTPMove">
<interaction-spec
className="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec">
<property name="SourcePhysicalDirectory" value="foo1"/>
<property name="SourceFileName" value="bar1"/>
<property name="SourceIsRemote" value="false"/>
<property name="TargetPhysicalDirectory" value="foo2"/>
<property name="TargetFileName" value="bar2"/>
<property name="Type" value="MOVE"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
注意:
この例では、SourceIsRemoteがfalseとして構成されています。この場合、FTPの入出力操作では、ソース・ファイルをローカル・ファイルシステムから取得するものと仮定します。また、ターゲットに対するパラメータは指定しませんでした。これは、デフォルトでTargetIsRemoteがtrueに設定されているためです。
この使用例の手順は「ファイルシステムのローカル・ディレクトリからFTPサーバーのリモート・ディレクトリへのファイルの移動」の使用例と同じです。ただし、次の例に示すように、ソース・ディレクトリをリモートとして、ターゲット・ディレクトリをローカルとして構成する必要があります。
例 - リモートとしてソース・ディレクトリ、ローカルとしてターゲット・ディレクトリを構成
<adapter-config name="FTPMove" adapter="Ftp Adapter"
xmlns="http://platform.integration.oracle
/blocks/adapter/fw/metadata">
<connection-factory location="eis/Ftp/FtpAdapter"
adapterRef=""/>
<endpoint-interaction portType="FTPMove_ptt"
operation="FTPMove">
<interaction-spec
className="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec">
<property name="SourcePhysicalDirectory" value="foo1"/>
<property name="SourceFileName" value="bar1"/>
<property name="TargetPhysicalDirectory" value="foo2"/>
<property name="TargetFileName" value="bar2"/>
<property name="TargetIsRemote" value="false"/>
<property name="Type" value="MOVE"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
注意:
この例では、TargetIsRemoteがfalseとして構成されています。この場合、FTPのI/Oでは、ソース・ファイルはリモート・ファイルシステムから取得するが、ターゲット・ファイルはローカル・ファイルシステム上にあると仮定します。また、ソースに対するパラメータは指定しませんでした。これは、デフォルトでSourceIsRemoteがtrueに設定されているためです。
あるFTPサーバーから別のFTPサーバーにファイルを移動するには、次の項に記載されている使用例を順に実行する必要があります。
「FTPサーバーのリモート・ディレクトリからファイルシステムのローカル・ディレクトリへのファイルの移動」: ローカル・ディレクトリから別のFTPサーバーにファイルをアップロード
「ファイルシステムのローカル・ディレクトリからFTPサーバーのリモート・ディレクトリへのファイルの移動」: FTPサーバーからローカル・ディレクトリにファイルをダウンロード
デフォルトでは、テクノロジ・アダプタを使用すると、JDeveloperアダプタ・ウィザードによって非同期WSDLが生成されます。通常、11gでアダプタ・シナリオを作成する場合は、次の手順に従います。
図4-176 に示す画面が表示されたら、この画面でプロセス詳細を入力します。テンプレートとして「サービスを後で定義」を選択する必要があります。
アダプタを使用するほとんどのBPELプロセスは、この方法でモデル化されます。生成されたWSDLは一方向的であることを示しており、これによりBPELプロセスは非同期的になります。
つまり、インバウンド・ファイル・アダプタによりディレクトリ内のファイルをポーリングし、そこで見つかった各ファイルについて、コンテンツをXMLに変換してBPELにパブリッシュします。
ただし、BPELプロセスが非同期的であるため、ファイル・アダプタがパブリッシュ後すぐに戻されて、必要な後処理、たとえば、データの削除やアーカイブが実行されます。
このような非同期BPELプロセスの短所は、インバウンド・アダプタの調整が難しくなる点です。つまり、ダウンストリームのビジネス・プロセスで処理が完了するのを待機せずに、インバウンド・アダプタによってBPELにメッセージが送信され続けます。この結果、メモリー使用量の増加やCPU使用率の上昇などの問題が発生する可能性があります。
これらの問題の発生を抑制するため、WSDLおよびBPELのアーティファクトを同期プロセスに手動で変更できます。同期BPELプロセスに変更したら、インバウンド・ファイル・アダプタでは、次のファイルまたはメッセージを処理する前に<reply>でダウンストリーム・プロセスによる処理が完了するまで強制的に待機するようになり、結果的にファイル・アダプタが自動的に調整されます。
図4-180 に示されている、変更されたWSDLを参照してください。ここでは、一方向のWSDLを双方向のWSDLに変換することによって、WSDLを同期的にしています。
次のステップでは、次の例のように、BPELプロセスの最後にあるインバウンド・アダプタのパートナ・リンクに<reply>アクティビティを追加します。
最終的なプロセスは図4-182 のようになります。
図4-182 ReceiveおよびReply BPELアクティビティを含む同期ファイル・アダプタ・プロセス
デフォルトではメディエータのルーティング・ルールは順次であるため、このタイプの作業はメディエータでは不要です。つまり、メディエータでは、ルーティング・ルールの処理にコール元のスレッド(インバウンド・ファイル・アダプタのスレッド)が使用されます。メディエータのWSDLが一方向でもこれは当てはまります。
5つの異なるFTPサーバーに同じファイルを送信する必要がある場合、たとえば、各コネクション・ファクトリの位置に1つずつ、合計5つのFtpAdapter参照を作成できます。ただし、これは最適な方法ではないため、かわりに動的パートナ・リンクという概念を使用できます。
アダプタを管理モードで実行している場合、FtpAdapterのWebLogic Serverコンソールでコネクション・ファクトリJNDIを構成する必要があります。
図4-183 の例では、localhost上で実行されているFTPサーバーにコネクション・ファクトリJNDIの位置eis/Ftp/FtpAdapterがマッピングされています。
図4-183 localhost上で実行されているFTPサーバーにマッピングされたコネクション・ファクトリのJNDIの位置 - weblogic.raのサンプル
図4-184 FTPアダプタのマッピングを示すコネクション・ファクトリ
アプリケーション・サーバーでコネクション・ファクトリを構成した後は、SCAプロセスのjcaアーティファクトでそのコネクション・ファクトリのJNDIを参照する必要があります。例では、.jcaファイル内のFTPOut参照で、eis/Ftp/FtpAdapterに対応するFTPサーバーが使用されています。
BPELおよびメディエータ・サービス・エンジンの両方のJCAヘッダー・プロパティを使用すると、このコネクション・ファクトリの位置を動的に変更できます。このためには、図4-185 に示すように、BPELまたはメディエータを使用するビジネス・シナリオで予約済のJCAヘッダー・プロパティjca.jndiを使用する必要があります。
動的パートナ・リンクを使用する場合は、次の点に注意する必要があります。
コネクション・ファクトリをSOAサーバー上に事前構成する必要があります。BPELの例では、シナリオのデプロイ前に、FtpAdapterのWebLogic Serverデプロイメント・ディスクリプタでeis/Ftp/FtpAdater1およびeis/Ftp/FtpAdater2の両方を構成する必要があります。
動的パートナ・リンクはアウトバウンド起動にのみ適用可能です。
ファイル/FTPアダプタでは、順序番号を使用するようにアウトバウンド書込みを構成できます。たとえば、address-data_%SEQ%.txtをFileNamingConventionとして選択すると、すべてのファイルがaddress-data_1.txt、address-data_2.txtなどとして生成されます。
図4-186を参照してください。
順序番号は、特定のアダプタ・プロジェクト(またはシナリオ)のコントロール・ディレクトリに属しています。ファイルまたはFTPアダプタを使用するプロジェクトごとに、記帳を目的として一意のディレクトリが作成されます。このコントロール・ディレクトリは一意である必要があるため、アダプタにより、ダイジェストが使用されて同じコントロール・ディレクトリが2つ存在しないことが確認されます。
たとえば、例にあるFlatStructureサンプルの場合、マイ・プロジェクトのコントロール情報はFMW_HOME/user_projects/domains/soainfra/fileftp/controlFiles/[DIGEST]/outboundに配置されます(DIGESTの値はプロジェクトごとに異なります)。
このディレクトリ内にあるcontrol_ob.propertiesファイルに、順序番号が保持されます。順序番号はバイナリ形式で保持されるため、その内容を表示するには16進数エディタが必要です。もう1つ、SEQ_nnnという0バイトのファイルがあります。この追加のファイルはバックアップとして保持されます。
アダプタ・ランタイムにとって問題となることの1つは、コントロール・ファイルが2つのスレッドによって誤って同時に更新されないように、コントロール・ファイルに対するすべての書込みを保護する必要がある点です。この保護のためにmutexが利用されています。
mutexには異なるタイプのものがあります。
インメモリー
データベース・ベース
Coherenceベース
ユーザー定義
特にアダプタに対するトランザクションの負荷が大きい場合、mutexがボトルネックになることがあります。ただし、アダプタでは、データベース順序またはストアド・プロシージャからアダプタの順序値が導出されるように構成を変更できます。その場合、mutexがバイパスされてプロセスのスループットが向上します。
スループットを向上させる最も単純な方法は、eis/HAFileAdapterを使用するようにアウトバウンドJCAファイルのJNDIコネクション・ファクトリの位置を切り替える方法です。
図4-187 HAFileAdapterを使用するためのJNDIコネクション・ファクトリの切替え
この変更の結果、アダプタ・ランタイムによってOracle Database上に順序が作成されるようになります。たとえば、SOAインフラ・スキーマ内でselect * from user_sequencesを実行すると、SEQ_<GUID>__という名前で新しい順序が作成されて表示されます(GUIDはプロジェクトごとに異なります)。
ただし、独自の順序を使用するには、SequenceNameというJCAファイルに新しいプロパティを追加する必要があります。この順序は、soainfraスキーマで前もって作成する必要があります。図4-188を参照してください。
デハイドレーション・サポートとしてDB2またはMS SQL Serverを使用するシナリオは、若干異なります。DB2では順序がネイティブでサポートされていますが、MS SQL Serverではサポートされていません。
DB2の場合、アダプタ・ランタイムは固有に生成された順序を使用しますが、MSSQL Serverの場合、アダプタは製品に付属のストアド・プロシージャを利用します。
SOA Suiteでデハイドレーション・ストアとしてDB2を実行する場合と同じ結果を得るには、JCAファイル内のコネクション・ファクトリのJNDI名をeis/HAFileAdapterDB2に変更します。
デハイドレーション・ストアとしてMSSQLを実行する場合と同じ結果を得るには、eis/HAFileAdapterMSSQLを使用します。
図4-189 に示すように、製品に付属しているストアド・プロシージャ以外のストアド・プロシージャを使用するには、バインディング・プロパティを使用してアダプタの動作をオーバーライドする必要があり、具体的にはストアド・プロシージャを使用するようにアダプタに指示する必要があります。
ファイル/FTPアダプタを追加モードで使用する場合、アダプタ・ランタイムによってmutexの機能が下げられてペシミスティック・ロックが使用され、異なるノードのライターによって同じファイルに対して同時に追加が実行されないようになります。
ファイル/FTPアダプタでは、ファイルを処理する順序を制御できます。たとえば、ファイルの変更時刻、ファイル・サイズまたは他の決定要素の順序で、ファイルを処理する必要がある場合があります。
ファイル/FTPアダプタでは、インバウンド・ファイル/FTPアダプタ・サービスのJCAファイルでFileSorter属性を定義することによって、ファイルを処理する順序を制御できます。図4-190を参照してください。
図4-190 ファイル・ソーターの指定
ファイル/FTPアダプタには、次の例に示す、最終変更時刻を使用する2つの事前定義済のソーターが備わっています。
ただし、ソート順序を自分で定義することが必要な場合もあります。このためには、Java Comparatorを実装し、それをファイル・アダプタに登録できます。これを行うには、次の手順を実行します。
FileSizeSorter Comparatorでは、ファイルがファイル・サイズの降順でソートされます。図4-192を参照してください。現在のFTPアダプタは、標準のFTPコマンドおよび各コマンドの有効なリターン・コードが定義されたRFC 959に準拠しています。ただし、固有のコマンドを使用するFTPサーバーもあります。たとえば、メインフレームで実行される一部のFTPサーバーでは、QUOTE SITEコマンドを使用して保存フォーマットを送信します(例: QUOTE SITE BLKSIZE=30000。相互作用のブロック・サイズを30000に設定)。
また、一部のFTPサーバーでは、FTPアダプタで処理する必要のある標準のFTPコマンドに対しても標準でないFTPリターン・コードを返します。FTPアダプタには、FTPサーバーのこれらのわずかな機能の違いに対応するための接続性レイヤーが用意されています。要約すると、次の理由でFTPアダプタの内部を公開する必要性があります。
一部のFTPサーバーは、異なる方法で標準のFTPコマンドに応答します。
特定のFTPサーバーでは、固有のFTPコマンドを使用する必要があります。
一部のFTPサーバーは、わずかに異なる形式でデータを返します。たとえば、LISTコマンドによりタイムスタンプ情報がAug 29 2011として返されるFTPサーバーもあれば、29AUG-2011として返されるFTPサーバーもあります。
FTPアダプタでは、一連のFTPコマンドおよびそのリターン・コードが使用されます。接続性をサポートするために、FTPアダプタによってこの機能が実装されます。
FTPアダプタは、デフォルトのFTPClient実装のlogin()操作をオーバーライドするように拡張できます。
ユーザーがFTPサーバーへのログイン時にアカウント名を指定する必要がある場合に対応して、デフォルトの実装を拡張できます。次の例に示すように、一般的なFTPクライアントは通常、各FTP接続を開始するときに、認可プロセスの一部としてFTPサーバーに対してUSERコマンド、PASSコマンドの順に使用します。
USER <SP><user-name><CRLF> PASS <SP> <password><CRLF>
この中の<SP>は空白を示し、<CRLF>はキャリッジ・リターンと改行を示します。ただし、次の例に示すように、PASSコマンドの後にアカウント名(ACCTコマンド)が渡されることをFTPサーバーが必要とする場合もあります。
ACCT <SP><Account Name><CRLF>
Account Nameは、ユーザーが認可をリクエストするサーバー上のアカウント名を示します。
この拡張によって、FTPアダプタは、認可でPASSコマンドの送信直後にACCTコマンドを送信できるようになります。
この動作を実現するには、(FTPアダプタに付属の) FTPClient実装により公開されたlogin()メソッドをオーバーライドする必要があります。
FTPアダプタにおけるFTPプロトコルのクライアント側はインタフェースIFTPClientを使用して公開され、デフォルトの実装はFTPClientによって提供されます。
FTPアダプタでは、デフォルトのFTPClient実装をオーバーライドし、login()メソッドにACCTのサポートを追加できます。
この方法でFTPClientを拡張した後は、FTPアダプタのコネクション・ファクトリ内にクラス名を構成する必要があります。
FTPアダプタは、LISTコマンドを送信してサーバーからファイル・リストを返します。FTPアダプタは、LISTコマンドに対するレスポンスを使用して、処理が必要なファイルのリストを取得します。
ただし、LISTコマンドへのレスポンスは、FTPサーバーのタイプによって若干異なります(表4-21 を参照)。
レスポンスの構造の違いに対応するために、FTPアダプタでは解析用にFtpListResponseParserおよびFtpTimestampParserインスタンスが採用されています。FTPアダプタには、各種FTPサーバー・タイプに対するFtpListResponseParserおよびFtpTimestampParserの実装が事前に作成されて付属しています。
FTPアダプタのWebLogicデプロイメント・ディスクリプタのコネクション・ファクトリ内にこれらの実装を構成するには、listParserKeyとtimeParserKeyにそれぞれ適切な値を設定します。
各種FTPサーバー・タイプからのLISTコマンドに対する様々なレスポンスを理解するには、表4-21 を参照してください。
表4-21 様々なFTPサーバー・タイプからのLISTコマンドに対するレスポンス
| FTPサーバー・タイプ | LISTコマンドの結果 |
|---|---|
UNIX |
-rwxr-xr-x 2 root root 1024 Apr 1 14:12 test.txt |
Windows |
09-13-11 12:10 23 test.txt |
MVS |
SAVE00 3390 2004/06/23 1 1 FB 128 6144 PS IN.TXT |
MLSDは、FTPサーバー・タイプに関係なく標準化されたディレクトリ・リスティングを提供する新しいFTPコマンドです。
MLSDコマンドをサポートするようにFTPアダプタを拡張できます。
MLSDレスポンスのフォーマットは次に示す例で定義されているため、MLSDコマンドに対するレスポンスは、LISTコマンドを使用する場合とは異なります。
type=file;modify=20110101010101;size=1024; address-csv.txt type=dir;modify=20110101010101; my_files type=file;size=1023;modify=20112011011001; index.htm
現在、MLSDは一部のFTPサーバーのみでサポートされています。
MLSDコマンドをサポートするために、FtpListResponseParserおよびFtpTimestampParserのプラグイン実装を使用できます(「FtpTimestampParserインタフェース」を参照)。これを行うには、次の手順を実行します。
ほとんどのFTPサーバーでは、最近作成されたファイルの変更時刻の表示書式が古いファイルの表示書式と若干異なるため、FtpTimestampParserの実装では2種類の日付/時間書式(defaultDateFormatおよびrecentDateFormat)が公開されます。
たとえば、UNIXシステムでは、古いファイルはAug 29 2011と表示され、2014年3月12日に作成された新しいファイルはMar 12 10:00と表示されます。
MLSDを使用する場合、weblogic-ra.xml内のコネクション・ファクトリで、defaultDateFormatをyyyyMMddhhmmssに、recentDateFormatをyyyyMMddhhmmss.SSSに設定する必要があります。
FTPアダプタは次の操作を公開します。これらの各操作は、対応するFTPコマンドにマップされています。
表4-22 FTPアダプタとFTPコマンドのマッピング
| FTPアダプタ操作 | 説明 | FTP操作 |
|---|---|---|
リスティング |
サーバーからファイルのリストを返します。 |
LIST/NLST/MLSD |
格納 |
アウトバウンド操作としてサーバーに単一ファイルを格納します。 |
STOR |
取得 |
サーバー上の単一ファイルを取得します。 |
RETR |
削除 |
サーバー上の単一ファイルを削除します。 |
DELE |
リスティング操作にLISTではなくMLSDを送信し、STORではなくSTOU (Store Uniqueに対応するFTPコマンド)を送信するようにFTPアダプタのシナリオを構成できるため、これらの操作(リスティング、格納、削除、取得)を拡張できます。同様に、他のコマンドも変更できます。この場合は、すでにサポートされているLIST/NLSTコマンドに加えてMLSDもサポートするようにリスティング操作を拡張します。
先に、MLSDに対するレスポンスを解析するようにFTPアダプタを構成しました。この項では、FTPアダプタで本来送信されるLIST/NLSTコマンドではなくMLSDコマンドが送信されるようにする方法について説明します。MLSDコマンドを送信するには、ftpmapping.xsdに対応する、リスティング操作をオーバーライドするマッピング・ファイル(my_mapping.xmlなど)を作成します(「ftpmappingスキーマ」を参照)。例:
<ftpmapping xmlns="http://schemas.oracle.com
/ftpadapter/mapping">
<listing command="MLSD="${default}"
success="$ftp.code = 150 or $ftp.code=125
or $ftp.code=226">
</listing>
</ftpmapping>
この例のリスティング操作では、FTPサーバーでリスティングがソートされるように、基本のLISTコマンドではなくMLSD FTPコマンドが使用されています。
成功/エラーの条件を指定するには、success属性を使用できます。コントロール・チャネルが125、150または226を返した場合、FTPアダプタはこれを成功とみなしますが、それ以外の場合はアダプタ例外が発生し、インバウンドまたはアウトバウンドのリスティング操作を構成しているバインディング・コンポーネント・パイプラインに伝播されます。
マッピング・ファイルのMLSD引数として使用できる値は次のとおりです。
${default}は、リクエストの結果として送信される元のディレクトリ・パスに置き換えられます。したがって、アウトバウンドjca内にPhysicalDirectoryとして/home/foo1を指定してコンポジットを構成し、アウトバウンド・ヘッダーでjca.ftp.Directoryパラメータのヘッダー値として/home/foo2を使用した場合、このパラメータは/home/foo2に置き換えられます。
ほとんどの場合、引数値を${default}から他の値に変更することはありません。
マッピング・ファイル内のハードコードされた値(例: argument="/home/bar")。これを使用すると、ハードコードされた値が使用されます。これは、コンポジット構成内に構成したjcaパラメータ/ヘッダーをオーバーライドします。
マッピング・ファイルを作成した後は、それをコンポジット・アプリケーションにコピーする必要があります。マッピング・ファイルをコンポジット・アプリケーションのJCAファイルと同じディレクトリに追加します。次の例に示すように、マッピング・ファイルはJCAアクティブ化または相互作用の一部として構成する必要があります。
例 - JCAアクティブ化または相互作用の一部としてのマッピングの構成
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="FTPIn" adapter="Ftp Adapter" …>
<connection-factory location="eis/Ftp/FtpAdapter" …/>
<endpoint-activation operation="Get">
<activation-spec className="oracle.tip.adapter.ftp.inbound.
FTPActivationSpec">
<[..]>
<property name="FtpMappingFile"
value="my_mapping.xml"/>
<[..]>
</activation-spec>
</endpoint-activation>
MVSシステム上のデータセットには、ディスク領域(PRIMARY/SECONDARY)、論理レコード長(LRECL)、ブロック・サイズ(BLKSIZE)という特性があります。MVSシステムで実行されているFTPサーバーは、これらの構成を認識しています。
これらの構成にはそれぞれデフォルト値がありますが、MVSシステムからダウンロード/アップロードするデータセットによっては、デフォルトをオーバーライドする必要がある場合もあります。
たとえば、大きなデータセットを50MBのFTPサーバーにアップロードするとします。この場合は、STOR操作の実行前に追加の領域を割り当てる必要があります。たとえば、BLKSIZEとして6192、LRECLとして86を構成する必要があります。これらのパラメータを設定しない場合、FTP転送(STOR操作)は失敗します。
ただし、FTPサーバーには、送信するコマンドの前にQUOTE SITEを使用することにより固有のコマンドを送信する方法があります。
QUOTE SITEからのリターン・コードは固有コマンドの種類によって異なることがあります。その場合、次のコマンドがSTORコマンドより前に送信されます。
QUOTE<SP>SITE<SP>BLKSIZE=6192<CRLF> QUOTE<SP>SITE<SP>LRECL=86<CRLF> STOR<SP>SM.KAR.SARL<CRLF>
この場合は、これらの追加のQUOTE SITEコマンドをFTPサーバーに送信するために格納操作を拡張しました。
FTPサーバーに送信できるのは制御コマンドのみです。制御コマンドとは、クライアントがデータ・チャネルからデータを読み取る必要がないコマンドのことです。たとえば、CWD、PWD、MKD、QUOTE SITE、DELEなどのコマンドは制御コマンドです。
一方、RETR、STOR、STOU、LIST、NLST、MLSDなどのコマンドはデータ・コマンドです。
データ・コマンドが発行されると、クライアントはデータ・チャネルからレスポンスを読み取る必要があります。ただし、制御コマンドの場合は、レスポンスが制御チャネルそのものに戻されます。STORなどの制御コマンドをFTPサーバーに送信するには、例に示すように、ftpmapping.xsdに対応する、格納操作をオーバーライドするマッピング・ファイル(my_mapping.xmlなど)を作成する必要があります(「ftpmappingスキーマ」を参照)。
<ftpmapping xmlns="http://schemas.oracle.com/ftpadapter/mapping">
<store>
<executecommandsbefore>
<command value="QUOTE SITE" argument="BLKSIZE=6192" success="$ftp.code >= 200 and $ftp.code <= 300">
<command value="QUOTE SITE" argument="LRECL=86" success="$ftp.code >= 200 and $ftp.code <= 300">
</executecommandsbefore>
</store>
</ftpmapping>
この例では、追加でQUOTE SITEコマンドを送信するSTOR操作の前にexecutecommandsbefore文があります。
同じ構成を次の例のように表現することもできます。
例 - マッピング・ファイルの構成
<ftpmapping xmlns="http://schemas.oracle.
com/ftpadapter/mapping">
<globalcommandsconfiguration >
<global-ftp-command id="BLKSIZE" command="QUOTE SIZE" argument="${jca.ftp.BlockSize}"
success="$ftp.code >= 200 and $ftp.code <= 300"/>
<global-ftp-command id="LRECL" command ="QUOTE SIZE" argument="${jca.ftp.LogicalRecordSize"
success="$ftp.code >l= 200 and $ftp.code <= 300"/>
</globalcommandsconfiguration>
<store>
<executecommandsbefore>
<ftp-command commandref="BLKSIZE" >
<ftp-command commandref="LRECL" >
</executecommandsbefore>
</store>
</ftpmapping>
この例では、コマンドをグローバルに構成し、commandref属性を使用してこれらを参照しています。どちらのマッピング・メタデータ表現方法も同じであるため、要件に応じていずれかを選択できます。
jca.ftp.BlockSizeおよびjca.ftp.RecordSizeは正規化されたメッセージ・プロパティ(たとえば、BPEL <invoke>アクティビティにおけるヘッダーなど)として渡すことができます。
例 - BlockSizeおよびRecordSizeを正規化されたメッセージ・プロパティとして渡す方法
<assign name="AssignFtpMetadata">
<copy>
<from expression="'BLKSIZE=6192'"/>
<to variable="blockSize"/>
</copy>
<copy>
<from expression="LRECL=86"/>
<to variable="logicalRecordSize"/>
</copy>
<invoke name="WriteWeatherData"
bpelx:invokeAsDetail="no"
inputVariable=
"WriteWeatherData_Put_InputVariable"
partnerLink="XmlOut"
portType="ns2:Put_ptt" operation="Put">
<bpelx:inputProperty name="jca.ftp.BlockSize"
variable="blockSize"/>
<bpelx:inputProperty name=
"jca.ftp.LogicalRecordSize"
variable="logicalRecordSize"/>
</invoke>
マッピング・ファイルは、相互指定用の.jcaファイルと同じディレクトリにコピーする必要があります。このマッピング・ファイルは、次の例に示すようにJCA相互指定の一部として構成する必要があります。
例 - JCA相互指定の一部としてのマッピング・ファイルの構成
<?xml version="1.0" encoding="UTF-8"?>
<adapter-config name="FTPOut" adapter="Ftp Adapter" …>
<connection-factory location="eis/Ftp/FtpAdapter" …/>
<endpoint- interaction operation="Get">
<interaction-spec
className="oracle.tip.adapter.
ftp.outbound.FTPInteractionSpec">
<[..]>
<property name="FtpMappingFile"
value="my_mapping.xml"/>
<[..]>
</interaction-spec>
</endpoint-interaction>
</adapter-config>
FTPアダプタを拡張する際に使用できるその他の構成パラメータは、次のとおりです。
FtpMappingFile
これは、インバウンド相互作用とアウトバウンド相互作用のどちらのjcaファイル内にも指定できます。これにより、コンポジット・アプリケーションを基準にしたマッピング・ファイルの相対パスが格納されます。「ftpmappingスキーマ」に、ftpmappingスキーマの例を示します。
インバウンド操作とアウトバウンド操作の両方で、同じマッピング・ファイルを使用してください。
たとえば、<property name="FtpMappingFile" value="xsd/ftp_mapping.xml"/>は、マッピング・ファイルがコンポジット・アプリケーションのxsdフォルダに存在していることを意味します。
ftpClientClass
これは、FTPアダプタのデプロイメント・ディスクリプタ内にコネクション・ファクトリ・パラメータとして指定できます。独自のFTPClient実装を指定する場合は、ここにその実装の完全修飾クラス名を挿入します。
listParserKey
これは、FTPアダプタのデプロイメント・ディスクリプタ内にコネクション・ファクトリ・パラメータとして指定できます。独自のFtpListResponseParser実装を指定する場合は、ここにその実装の完全修飾クラス名を挿入します。
timeParserKey
これは、FTPアダプタのデプロイメント・ディスクリプタ内にコネクション・ファクトリ・パラメータとして指定できます。
独自のFtpTimestampParser実装を指定する場合は、ここにその実装の完全修飾クラス名を挿入します。
次に、FTPClient実装のサンプルを示します。
例 - FTPClient実装のサンプル
import oracle.tip.adapter.file.LoggerUtil;
import oracle.tip.adapter.file.FileResourceException;
import oracle.tip.adapter.ftp.IFtpDescriptor;
import oracle.tip.adapter.ftp.FTPReply;
import oracle.tip.adapter.ftp.FTPClient;
import oracle.tip.adapter.ftp.FTPCommand;
import oracle.tip.adapter.ftp.IFTPClient;
import javax.resource.ResourceException;
import java.io.IOException;
import oracle.tip.pc.infra.exception.
PCExceptionIndex;
import javax.resource.spi.security.
PasswordCredential;
import java.net.Socket;
import java.util.logging.Logger;
import java.util.logging.Level;
public class TestFTPClient extends FTPClient
implements
IFTPClient {
private Logger _logger = Logger.getLogger
(TestFTPClient.class.getName());
public TestFTPClient() {
super();
Sample FTPClient Implementation
}
public void initialize(IFtpDescriptor ftpDescriptor) {
super.initialize(ftpDescriptor);
}
public Logger getLogger() {
return _logger;
}
public boolean login(Socket controlSocket,
PasswordCredential pc)
throws IOException,
ResourceException
{
intrc = 0;
String replyStr = null;
logDebug("TestFTPClient::login(...) invoked ");
replyStr = user(controlSocket,
pc.getUserName());
rc = getReplyCode(replyStr,
m_ftpDesc.getHost());
logDebug("TestFTPClient::
command[USER] =>" + rc + "<=");
if(FTPReply.isPositiveCompletion(rc)) {
return true;
}
if(!FTPReply.isPositiveIntermediate(rc)) {
// USER failed
logError("Unable to login
to server '"
+ m_ftpDesc.getHost() + "'; " +
"FTP command USER returned
unexpected reply code : " + rc);
FileResourceException frex = new FileResourceException(PCExceptionIndex.ERROR_LOGIN);
frex.setEISErrorCode(String.valueOf(rc));
frex.setEISErrorMessage(replyStr);
throw frex;
}
replyStr = pass(controlSocket,
new String(pc.getPassword()));
rc = getReplyCode(replyStr, m_ftpDesc.getHost());
logDebug("TestFTPClient::
command[PASS] =>" + rc + "<=");
if ( FTPReply.isPositiveCompletion(rc)) {
return true;
}
if ( !FTPReply.isPositiveIntermediate(rc)) {
// PASS failed
logError("Unable to login to server '" +
m_ftpDesc.getHost() + "'; " +
"FTP command PASS returned
unexpected
reply code : " + rc );
FileResourceException frex = new FileResourceException(PCExceptionIndex.ERROR_LOGIN);
frex.setEISErrorCode(String.valueOf(rc));
frex.setEISErrorMessage(replyStr);
throw frex;
}
//Check ACCT account
String accountName = "hard-coded";
replyStr = sendCommand(controlSocket,
FTPCommand.ACCT,
accountName);
rc = getReplyCode(replyStr,
m_ftpDesc.getHost());
logDebug("TestFTPClient::
command[ACCT] =>" + rc + "<=");
if ( !FTPReply.isPositiveCompletion(rc)) {
// ACCT failed
logError("Unable to login to
server '" + m_ftpDesc.getHost() + "'; " +
"FTP command ACCT returned unexpected
reply code : " + rc );
FileResourceException frex = new FileResourceException(PCExceptionIndex.ERROR_LOGIN);
frex.setEISErrorCode(String.valueOf(rc));
frex.setEISErrorMessage(replyStr);
throw frex;
}
return true;
}
private void logDebug(String logData){
_logger.log(Level.FINE, logData);
}
private void logError(String logData){
_logger.log(Level.SEVERE, logData);
}
}
次のFTPListResponseParserインタフェースは、FTPファイル・リスティングを解析してその情報をFileInfoインスタンスに変換するためのインタフェースを定義しています。
例 - FTPListResponseParserのサンプル
package oracle.tip.adapter.ftp.parsers;
import …
/**
* FtpListResponseParser defines the interface for
* parsing FTP file listings
* and converting that information into FileInfo instances.
* It also uses a default
* or a user supplied Timestamp parser instance to parse the
* file modified time
*/
public interface FtpListResponseParser
{
/**
* This parameter can be used
* to throttle the Ftp Adapter to
* return the required
* number of files from the call based on heuristics
* such as memory available
* @param pageSize The number of FileInfo
* instances to be returned
*/
public void setPageSize(int pageSize);
/**
* @return Returns the page size
*/
public int getPageSize();
/**
* This method is used to configure
* the parser instance
* being returned.
* @param ftpDescriptor
*/
public void configure(IFtpDescriptor ftpDescriptor);
/**
* Parses an Ftp listing and returns an array
* of FileInfo
* @param directory The Ftp directory being listed
* @param stream The data socket stream to read from
* @param encoding Server encoding
* @return The list of FileInfo instances
* @exception Exception Any exception in reading
* the data socket stream.
*/
public FileInfo[] parseListResponse(String directory,
InputStream stream, String encoding)
throws IOException;
/**
* Parses an Ftp listing and returns an
* array of FileInfo
* using the default encoding
* @param directory The Ftp directory being listed
* @param stream The data socket stream to read from
* @return The list of FileInfo instances
* @exception Exception Any exception in reading
* the data socket stream.
*/
public FileInfo[] parseListResponse(String directory,
InputStream stream) throws IOException;
/**
* Returns a single FileInfo instance from a single line
* @param line The line read from the data socket
*/
public FileInfo parseLine(String line);
/**
* Reads and returns a single line from
* the data socket
* @param reader The reader constructed
* from the data socket stream
* @return The line read from the socket stream
* @exception Exception Any exception in
* reading the data socket stream.
*/
public String nextLine(BufferedReader reader)
throws IOException;
/**
* Preprocessing hook before the list
* is returned to the client
* @param originalList List of lines read
*/
public List preProcess(List originalList);
/**
* Set the parser for parsing the File timestamps
* returned from the call to listing
* @param ftpTimestampParser The Timestamp
* parser interface
*/
public void setTimestampParser(FtpTimestampParser
ftpTimestampParser);
/**
* Parses the timestamp from listing
* @exception Exception Any exception
* in parsing the time
*/
public long parseTimestamp(String timestamp)
throws Exception;
}
FTPTimestampParserは、FTPサーバー上のファイルのタイムスタンプを解析するためのインタフェースを定義します。次の例を参照してください。
例 - FtpTimestampParserインタフェースのサンプル
package oracle.tip.adapter.ftp.parsers;
import …;
/**
* FtpTimestampParser defines
* the interface for parsing timestamps from
* files on Ftp Server.
*
*/
public interface FtpTimestampParser
{
/**
* This parameter can be used to configure
* the timestamp parser implementation
* @param ftpDescriptor The IFtpDescriptor
* instance used
*to configure the timestamp parser
*/
public void setFtpDescriptor(
IFtpDescriptor ftpDescriptor);
/**
* Returns the timestamp from the file
* time in listing format
* @param timestamp File time from the File listing
* @return timestamp in long
* @throws Exception
*/
public long parseTimestamp(String timestamp)
throws Exception;
}
}
次の例に、FTPマッピング・スキーマのftpmappingを示します。
例 - FTPMappingスキーマ
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.oracle.
com/ftpadapter/mapping"
xmlns:tns="http://schemas.oracle.com
/ftpadapter/mapping"
targetNamespace="http://schemas.oracle.com/
ftpadapter/mapping"
elementFormDefault="qualified"
attributeFormDefault=
"unqualified">
<xsd:element name="ftpmapping">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="globalcommandsconfiguration"
minOccurs="0" />
<xsd:element name="listing" type="tns:ftp-operation-type"
minOccurs="0" />
<xsd:element name="retrieve" type="tns:ftp-operation-type"
minOccurs="0"/>
<xsd:element name="store" type="tns:ftp-operation-type"
minOccurs="0"/>
<xsd:element name="delete"
type="tns:ftp-operation-type"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
<xsd:complexType name="ftp-operation-type">
<xsd:sequence>
<xsd:element ref="executecommandsbefore"
minOccurs="0"/>
<xsd:element ref="executecommandsafter"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="command" type="xsd:string"
use="optional" />
<xsd:attribute name="argument"
type="xsd:string"
use="optional" />
<xsd:attribute name="success" type="xsd:string"
use="optional" />
<xsd:attribute name="desc" type="xsd:string"
use="optional" />
<xsd:attribute name="commandref"
type="xsd:string"
use="optional" />
</xsd:complexType>
<xsd:element name="executecommandsafter">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ftp-command"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="executecommandsbefore">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ftp-command"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ftp-command">
<xsd:complexType>
<xsd:attribute name="argument"
type="xsd:string"
use="optional" />
<xsd:attribute name="success"
type="xsd:string"
use="optional" />
<xsd:attribute name="desc"
type="xsd:string"
use="optional" />
<xsd:attribute name="command"
type="xsd:string"
use="optional" />
<xsd:attribute name="commandref"
type="xsd:string"
use="optional" />
</xsd:complexType>
</xsd:element>
<xsd:element name="global-ftp-command">
<xsd:complexType>
<xsd:attribute name="argument"
type="xsd:string"
use="optional" />
<xsd:attribute name="success" type="xsd:string"
use="required" />
<xsd:attribute name="desc" type="xsd:string"
use="optional" />
<xsd:attribute name="id" type="xsd:string"
use="required" />
<xsd:attribute name="command" type="xsd:string"
use="required" />
</xsd:complexType>
</xsd:element>
<xsd:element name="globalcommandsconfiguration">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="global-ftp-command"
minOccurs="0"
maxOccurs="unbounded" />
示されている内容でMANIFEST.MFファイルを作成します。Class-pathディレクティブを含める必要があります。Class-pathディレクティブ内の各エントリは空白で区切ります。
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 20.4-b02 (Sun Microsystems Inc.)
Implementation-Vendor: Oracle
Implementation-Title: Ftp Adapter Extensibility
Implementation-Version: 11.1.1
Product-Name: Ftp Adapter Extensibility Manifest
Product-Version: 12.1.2.0.0
Specification-Version: 11.1.1
Class-Path: jca-binding-api.jar fileAdapter.jar ftpAdapter.jar ../../../../wlserver/modules/javax.resource_1.6.1.jar ../oracle.soa.fabric_11.1.1/bpm-infra.jar
このMANIFEST.MFを含めるには、次の手順を実行します。
次の例に、ListParserおよびTimeParserのサンプルを示します。
例 - ListParserおよびTimeParserのサンプル
package oracle.tip.adapter.ftp.test;
import java.util.regex.Pattern;
import java.util.Map;
import java.util.HashMap;
import java.util.StringTokenizer;
import oracle.tip.adapter.file.FileInfo;
import oracle.tip.adapter.file.FileLogger;
import oracle.tip.adapter.file.LoggerUtil;
import oracle.tip.adapter.ftp.IFtpDescriptor;
import oracle.tip.adapter.ftp.parsers.
FtpTimestampParser;
import oracle.tip.adapter.ftp.parsers.
FtpListResponseParserImpl;
/**
* Implementation of FtpListResponseParser
for MLSD responses
* Responses are return as
- type=file;modify=20110101010101;size=1024;
filename
*/
public class MLSDListResponseParserImpl
extends FtpListResponseParserImpl
{
private static final String TYPE = "type";
private static final String SIZE = "size";
private static final String MODIFY = "modify";
public MLSDListResponseParserImpl()
{
}
/**
* Returns a FileInfo instance
* for a single line.
* @param line Line from list response
* @return FileInfo instance
*/
public FileInfo parseLine(String line)
throws Exception
{
System.out.println
("MLSDListResponseParseImpl::parseLine
called [" + line + "]");
FileInfo fileInfo = new FileInfo();
fileInfo.setRaw(line);
//extract the file name
String response[] = line.split(" ");
if(response == null || response.length != 2){
throw new Exception("Invalid response
from ftp server [" + line + "]");
}
fileInfo.setFileName(response[1]);
StringTokenizer st = new
StringTokenizer(response[0], ";");
Map<String, String> properties =
new HashMap<String, String>();
String token = null;
while(st.hasMoreElements()){
token = st.nextToken().trim();
int index = token.indexOf('=');
if(index == -1){
throw new Exception
("Invalid ftp line since token
[" + token + "]
does not contain '='");
}
String key = token.substring(0, index).trim();
String value = token.substring(index+ 1,
token.length()).trim();
if(key.length() ==0 || value.length() ==0){
throw new Exception("Invalid ftp line since
either key[" + key + "] or value [" + value + "]
is invalid");
}
properties.put(key, value);
}
String type = properties.get(TYPE);
String modify = properties.get(MODIFY);
String size = properties.get(SIZE);
if("file".equals(type)){
fileInfo.setFileType(FileInfo.IS_FILE);
}
else if("dir".equals(type)){
fileInfo.setFileType(FileInfo.IS_DIR);
}
else {
fileInfo.setFileType(FileInfo.IS_UNKNOWN);
}
try{
fileInfo.setSize(Long.parseLong(size));
}
catch(NumberFormatException e){
}
long modifiedTime = 0;
try{
modifiedTime = parseTimestamp(modify);
fileInfo.setTimestamp(modifiedTime);
}
catch(Exception e){
FileLogger.logWarning
("Unable to parse timestamp[" + modify + "]",e);
}
System.out.println("FileInfo returned
[" + fileInfo + "]");
return fileInfo;
}
