Oracle® Fusion Middleware

テクノロジ・アダプタの理解

12c (12.2.1)

E69958-02(原本部品番号:E58942-03)

2016年2月

基礎となる概念、SOA内のコンテキスト、およびSOA JCAテクノロジ・アダプタの開発とデプロイについて記述した、Oracle SOA(サービス指向アーキテクチャ)開発者向けのドキュメント

Oracle Fusion Middlewareテクノロジ・アダプタの理解, 12c (12.2.1)

E69958-02

Copyright © 2010, 2016, Oracle and/or its affiliatesAll rights reserved.

原本著者: Oracle Corporation

原本協力者: Amandeep Mahajan, Bo Stern, Srimant Misra, Deepak Agarwal, Raghavendra Chandrashekar, Stephen Mcritchie, Michael Chiocca, Rod Fernandez, Sunil Gopal, Manas Panda, Sagar Shiruguppi, Vikas Anand, Sujay Bandyopadhyay, Syed Zarina, Anuj Kaushal, Ashish Mathur, Prateek Maheshwari, Dhaval B Shah, Sandeep Jain

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

リリース12.2.1用のこのガイドでの新しい情報
第I部 概要と説明

1 Oracle JCAアダプタの概要

- 1.1 Oracle JCAアダプタの機能

- 1.2 Oracle JCAアダプタのタイプ

- 1.2.1 Oracleテクノロジ・アダプタ

- 1.2.1.1 アーキテクチャ

- 1.2.1.2 設計時コンポーネント

- 1.2.1.3 ランタイム・コンポーネント

- 1.2.1.3.1 Fusion Middleware Controlのアクセシビリティおよびテクノロジ・アダプタ

- 1.2.1.4 デプロイメント

- 1.2.2 レガシー・アダプタ

- 1.2.2.1 アーキテクチャ

- 1.2.2.1.1 Oracle Connect

- 1.2.2.1.2 Oracle Studio

- 1.2.2.1.3 J2CAアダプタ

- 1.2.2.2 設計時コンポーネント

- 1.2.2.3 ランタイム・コンポーネント

- 1.2.2.4 デプロイメント

- 1.2.3 パッケージ・アプリケーション・アダプタ

- 1.2.3.1 アーキテクチャ

- 1.2.3.1.1 アプリケーション・エクスプローラ

- 1.2.3.1.2 BSE

- 1.2.3.1.3 J2CA 1.5リソース・アダプタ

- 1.2.3.2 設計時コンポーネント

- 1.2.3.3 ランタイム・コンポーネント

- 1.2.3.4 デプロイメント

- 1.2.4 Oracle E-Business Suiteアダプタ

- 1.3 Oracle JCAアダプタ・サービスのタイプ

- 1.3.1 リクエスト-レスポンス(アウトバウンド相互作用)サービス

- 1.3.2 イベント通知(インバウンド相互作用)サービス

- 1.3.3 メタデータ・サービス

2 アダプタ・フレームワーク

- 2.1 Oracle JCAアダプタのインストール

- 2.2 起動と停止

- 2.3 既存WSDLのインポートによるアダプタ・インタフェースの定義

- 2.3.1 Oracle MQ Seriesアダプタ、Oracle JMSアダプタ、Oracle AQアダプタ用のアダプタ構成ウィザード

- 2.3.1.1 コールバックの使用例

- 2.4 Oracle JCAアダプタのメッセージ・ヘッダー・プロパティの構成

- 2.5 物理デプロイ

- 2.5.1 RARデプロイメント・ディスクリプタ・ファイルとweblogic-ra.xmlテンプレート・ファイル

- 2.6 Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成

- 2.7 JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ

- 2.7.1 SOAプロジェクトおよびアプリケーションに対するアプリケーション・プロファイルのデプロイ

- 2.7.2 アダプタのデプロイメントの検証

- 2.8 Jarファイルが関連付けられていないアダプタRARファイルの手動デプロイ

- 2.8.1 手動デプロイメントの例

- 2.9 リモートOracle SOAサーバーで作業中のデプロイメント計画の処理

- 2.10 異なる環境からのリポジトリの移行

- 2.11 メッセージの順序付け

- 2.12 メッセージの損失がないことをOracle JCAアダプタで保証する方法

- 2.12.1 XAトランザクションのサポート

- 2.12.2 ローカル・トランザクションとグローバル(XA)トランザクション

- 2.12.2.1 ローカル・トランザクションのアダプタ・サポート

- 2.12.2.2 グローバル・トランザクションのアダプタ・サポート

- 2.12.2.2.1 グローバル・トランザクションの再試行およびロールバックとフォルト・ポリシー

- 2.12.3 トランザクションとアダプタの基本概念

- 2.12.3.1 非同期トランザクション・フロー

- 2.12.3.1.1 JMS、BPEL、DBアダプタとデータベースの使用例

- 2.12.3.2 同期トランザクション・フロー

- 2.12.4 インバウンド・トランザクション

- 2.12.5 アウトバウンド・トランザクション

- 2.13 コンポジットの可用性とインバウンド・アダプタ

- 2.14 アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート

- 2.14.1 同一のアダプタ・エンドポイントの複数のアクティブ化

- 2.14.2 ホットスタンバイ状態

- 2.15 アダプタ内での相関サポート

- 2.15.1 起動と一致しない受信メッセージのCorrelationID: ログ・エラー・メッセージ

- 2.15.1.1 一致しないネイティブ相関IDの拒否

- 2.16 ペイロード・サイズしきい値の設定

- 2.16.1 ペイロードのネイティブ・サイズ

- 2.16.1.1 ペイロードしきい値の設定

- 2.16.1.2 ペイロード・サイズ強制の制限

- 2.16.1.2.1 グローバル・ペイロード・サイズの有限値への変更

- 2.17 大きなペイロードのストリーミング

- 2.18 バッチ処理とデバッチ処理のサポート

- 2.19 アダプタ・コネクション・ファクトリの追加

- 2.19.1 データソースの作成

- 2.19.2 接続プールの作成

- 2.20 アダプタ・コネクション・ファクトリの追加または更新

- 2.20.1 JCAファイルの変更

- 2.20.2 構成プランの使用

- 2.20.3 WebLogic Serverコンソールを使用した新規接続の作成

- 2.21 Oracle JCAアダプタで使用するデータソースの推奨設定

- 2.22 エラー処理

- 2.22.1 拒否されたメッセージの処理

- 2.22.1.1 下流で発生したエラーまたはフォルトの処理方法

- 2.22.1.2 拒否ハンドラの構成

- 2.22.1.2.1 フォルト・ポリシーの作成

- 2.22.1.3 拒否されたメッセージのチェック

- 2.22.1.3.1 データベースからのチェック

- 2.22.1.3.2 Fusion Middleware Controlコンソールからのチェック

- 2.22.1.3.3 メッセージ・エラーの処理: サンプル・シナリオ

- 2.22.2 インバウンド相互作用のエラー処理

- 2.22.2.1 メッセージ・エラーの拒否ハンドラ

- 2.22.2.1.1 Webサービス・ハンドラ

- 2.22.2.1.2 カスタムJavaハンドラ

- 2.22.2.1.3 JMSキュー

- 2.22.2.1.4 ファイル

- 2.22.2.2 インバウンドの再試行可能なエラー

- 2.22.2.2.1 再試行可能なエラーを処理するインバウンド・アダプタの構成

- 2.22.2.2.2 composite.xmlファイルでのインバウンド再試行プロパティの指定

- 2.22.2.2.3 インバウンド・アダプタ・エンドポイントのjca.retry. countのデフォルト値の変更

- 2.22.2.2.4 MBeansブラウザを使用したグローバル・プロパティの変更

- 2.22.2.3 インバウンドの再試行不可能なエラー

- 2.22.2.3.1 再試行不可能なエラーの例

- 2.22.3 アウトバウンド・アダプタ相互作用のエラー処理

- 2.22.3.1 アウトバウンド・アダプタ・エラー処理の再試行可能なエラー

- 2.22.3.1.1 composite.xmlファイルでのアウトバウンド・エラー処理の再試行可能プロパティの設定

- 2.22.3.1.2 例: アウトバウンド相互作用に関する再試行可能な例外の値の設定方法

- 2.22.3.2 アウトバウンド相互作用処理に関する再試行不可能なエラー

- 2.22.3.2.1 フォルトの伝播

- 2.22.3.2.2 フォルト・ポリシー・メカニズムが動作しない2つのケース

- 2.23 JCAアダプタとOracle Web Services Managerの統合による監査証跡内の機密データの保護

- 2.23.1 エンドポイントへのJCA暗号化のアタッチ

- 2.24 アプリケーションのテスト

- 2.25 Oracle JCAアダプタのトレース・レベルの設定

- 2.25.1 Oracle JCAアダプタのトレース・レベルの設定方法

- 2.26 アダプタ・ログの表示

- 2.27 アダプタの診断能力ダンプ

- 2.28 カスタム・アダプタの作成

- 2.28.1 カスタム・アダプタの構成

- 2.28.1.1 カスタム・アダプタ画面のフロー

- 2.28.2 アダプタに関するよくある質問

- 2.28.2.1 アプリケーションがタイムアウトになる理由

- 2.28.2.2 トランザクション・アダプタと非トランザクション・アダプタの違いはなんですか。

- 2.28.2.3 アプリケーションの拒否されたメッセージとはなんですか。何かできることがありますか。

- 2.29 高度なトピック: テクノロジ間での実行コンテキストIDの使用

- 2.29.1 ECIDの配置

- 2.29.2 コンポジット・サービス/参照の構成

- 2.29.3 データベース/ファイル/JMSの単純な例

3 アダプタとOracle Application Serverコンポーネントの統合

- 3.1 アダプタとOracle WebLogic Serverの統合

- 3.1.1 Oracle WebLogic Serverの概要

- 3.1.2 Oracle WebLogic Serverとアダプタの統合

- 3.1.2.1 設計時

- 3.1.2.2 実行時

- 3.2 アダプタとOracle Fusion Middlewareの統合

- 3.2.1 Oracle BPEL Process Managerの概要

- 3.2.2 Oracle Mediatorの概要

- 3.2.3 Oracle Fusion Middlewareとアダプタの統合

- 3.2.3.1 設計時

- 3.2.3.2 実行時

- 3.2.3.3 使用例: Oracle BPEL Process Managerの統合

- 3.2.4 Oracle SOAコンポジットとアダプタの統合

- 3.2.4.1 Oracle SOAコンポジットの概要

- 3.2.4.2 アダプタとOracle SOAコンポジットの統合

- 3.3 監視

4 Oracle JCA Adapter for Files/FTP

- 4.1 Oracleファイル/FTPアダプタの概要

- 4.1.1 Oracleファイル/FTPアダプタのアーキテクチャ

- 4.1.2 Oracleファイル/FTPアダプタとOracle BPEL PMの統合

- 4.1.3 Oracleファイル/FTPアダプタとメディエータの統合

- 4.1.4 SOAコンポジットとの統合

- 4.2 機能

- 4.2.1 ファイル・フォーマット

- 4.2.2 FTPサーバー

- 4.2.3 インバウンドおよびアウトバウンド相互作用

- 4.2.4 ファイルのデバッチ処理

- 4.2.5 ファイルのChunkedRead

- 4.2.5.1 チャンク相互作用ファイル・アダプタ処理

- 4.2.5.1.1 ファイル・チャンク相互作用のBPEL起動

- 4.2.5.1.2 ChunkSizeパラメータ

- 4.2.5.2 ファイル・アダプタ構成ウィザードを使用したチャンク読取り相互作用のモデル化の実行

- 4.2.5.2.1 チャンク相互作用のエラー処理の概要

- 4.2.5.2.2 不正なレコードのスキップ

- 4.2.5.2.3 チャンク相互作用のヘッダーおよび拒否されたチャンク相互作用のメッセージの例

- 4.2.6 ファイルのソート

- 4.2.7 動的アウトバウンド・ディレクトリとファイル名の指定

- 4.2.8 セキュリティ

- 4.2.9 非トランザクション

- 4.2.10 プロキシのサポート

- 4.2.11 ペイロード以外のサポート

- 4.2.12 大きなペイロードのサポート

- 4.2.13 ファイルベースのトリガー

- 4.2.14 ファイルの前処理および後処理

- 4.2.14.1 ファイルの前処理および後処理のメカニズム

- 4.2.14.2 パイプラインの構成

- 4.2.14.2.1 バルブの実装および拡張

- 4.2.14.2.2 バルブのコンパイル

- 4.2.14.2.3 パイプラインの作成

- 4.2.14.2.4 SOAプロジェクト・ディレクトリへのパイプラインの追加

- 4.2.14.2.5 パイプラインの登録

- 4.2.14.3 Zipファイルに対するリエントラント・バルブの使用

- 4.2.14.4 バッチ通知ハンドラの構成

- 4.2.15 エラー処理

- 4.2.15.1 不正な形式のXMLファイルのローカル・ファイルシステム・フォルダへの送信

- 4.2.16 スレッド・モデル

- 4.2.16.1 デフォルトのスレッド・モデル

- 4.2.16.2 変更されたスレッド・モデル

- 4.2.16.2.1 シングル・スレッド・モデル

- 4.2.16.2.2 パーティション化スレッド・モデル

- 4.2.17 パフォーマンス・チューニング

- 4.2.18 高可用性

- 4.2.19 複数のディレクトリ

- 4.2.20 追加モード

- 4.2.21 ディレクトリ内のファイルの再帰的処理

- 4.2.21.1 デプロイメント・ディスクリプタのパラメータの構成

- 4.2.22 エンタープライズ情報システムの資格証明の保護

- 4.3 Oracleファイル/FTPアダプタの説明

- 4.3.1 ファイル読取りの説明

- 4.3.1.1 インバウンド操作

- 4.3.1.2 インバウンド・ファイル・ディレクトリの指定

- 4.3.1.2.1 SOAコンポジットでのインバウンドの物理または論理ディレクトリ・パスの指定

- 4.3.1.2.2 正常に処理されたファイルのアーカイブ

- 4.3.1.2.3 取得後のファイルの削除

- 4.3.1.3 ファイルの検索とバッチ処理

- 4.3.1.3.1 ネーミング・パターンの指定

- 4.3.1.3.2 処理対象ファイルと処理対象外ファイル

- 4.3.1.3.3 処理対象ファイルと処理対象外ファイル

- 4.3.1.3.4 メッセージのデバッチ処理

- 4.3.1.4 ファイル・ポーリング

- 4.3.1.4.1 トリガー・ファイルの使用

- 4.3.1.5 後処理

- 4.3.1.6 ネイティブ・データ・トランスレーション

- 4.3.1.7 インバウンド・サービス

- 4.3.1.8 インバウンド・ヘッダー

- 4.3.2 ファイル書込みの説明

- 4.3.2.1 アウトバウンド操作

- 4.3.2.2 アウトバウンド・ファイル・ディレクトリの作成

- 4.3.2.2.1 Oracle BPEL PMでのアウトバウンドの物理または論理ディレクトリ・パスの指定

- 4.3.2.2.2 アウトバウンドの物理または論理ディレクトリ・パスの指定

- 4.3.2.2.3 動的なアウトバウンド・ディレクトリ名の指定

- 4.3.2.2.4 アウトバウンド・ファイル・ネーミング規則の指定

- 4.3.2.2.5 動的なアウトバウンド・ファイル名の指定

- 4.3.2.2.6 複数のアウトバウンド・メッセージのバッチ処理

- 4.3.2.3 ネイティブ・データ・トランスレーション

- 4.3.2.4 アウトバウンド・サービス・ファイル

- 4.3.2.5 アウトバウンド・ヘッダー

- 4.3.3 同期読取りの説明

- 4.3.4 ファイル・リスティングの説明

- 4.3.4.1 リスト表示操作

- 4.3.4.2 ファイル・ディレクトリの指定

- 4.3.4.2.1 SOAコンポジットでのインバウンドの物理または論理ディレクトリ・パスの指定

- 4.3.4.3 ファイルの検索

- 4.3.4.3.1 ネーミング・パターンの指定

- 4.3.4.3.2 処理対象ファイルと処理対象外ファイル

- 4.3.5 Oracle FTPアダプタのGet Fileの説明

- 4.3.6 Put Fileの説明

- 4.3.7 同期Get Fileの説明

- 4.3.8 ファイル・リスティングの説明

- 4.3.9 ファイル/FTPアダプタの拡張

- 4.4 Oracleファイル/FTPアダプタの構成

- 4.4.1 リモートFTPサーバーにアクセスするための資格証明の構成

- 4.4.2 高可用性の構成

- 4.4.2.1 高可用性の前提条件

- 4.4.2.2 インバウンド操作の高可用性

- 4.4.2.2.1 コーディネータとしてのデータベース表の使用

- 4.4.2.3 アウトバウンド操作の高可用性

- 4.4.2.3.1 データベースMutexの使用

- 4.4.3 セキュアFTPの使用

- 4.4.3.1 セキュアFTPの概要

- 4.4.3.2 SolarisおよびLinuxでのFTP Over SSLのインストールおよび構成

- 4.4.3.2.1 OpenSSLのインストールおよび構成

- 4.4.3.2.2 vsftpdのインストールおよび構成

- 4.4.3.2.3 設定

- 4.4.3.3 WindowsでのFTP Over SSLのインストールおよび構成

- 4.4.3.3.1 OpenSSLのインストール

- 4.4.3.3.2 OpenSSLのサーバー鍵およびサーバー証明書の生成

- 4.4.3.3.3 サーバー鍵およびサーバー証明書のFileZillaサーバーへのインポート

- 4.4.3.3.4 サーバー鍵のPEMからPKCS12フォーマットへの変換

- 4.4.3.3.5 新しい鍵を使用するためのOracle FTPアダプタのデプロイメント・ディスクリプタの構成

- 4.4.4 SFTPの使用

- 4.4.4.1 SFTPの概要

- 4.4.4.1.1 暗号化

- 4.4.4.1.2 認証

- 4.4.4.1.3 整合性

- 4.4.4.1.4 データ圧縮

- 4.4.4.2 OpenSSH for Windowsのインストールと構成

- 4.4.4.3 SFTP用の設定

- 4.4.4.3.1 パスワードによる認証の構成

- 4.4.4.3.2 公開鍵認証の構成

- 4.4.4.3.3 公開鍵認証を使用するためのOpenSSHの構成

- 4.4.4.3.4 OpenSSHがファイアウォールの内側で実行されている場合の公開鍵認証用の構成

- 4.4.4.3.5 OpenSSHがファイアウォールの外側で実行されている場合の公開鍵認証用の構成

- 4.4.5 OracleファイルとFTPアダプタのFIPS準拠の有効化

- 4.4.6 HTTPプロキシのための構成

- 4.4.6.1 プレーンFTPモード用の構成

- 4.4.6.1.1 プロキシ定義ファイル

- 4.4.6.2 SFTPモード用の構成

- 4.4.7 高可用性のためのファイル/FTPアダプタの構成

- 4.4.7.1 インバウンド操作

- 4.4.7.2 アウトバウンド操作

- 4.4.7.3 その他の考慮事項

- 4.4.7.3.1 インバウンド操作

- 4.4.7.3.2 アウトバウンド操作

- 4.4.7.3.3 高可用性シナリオでのXAの構成

- 4.5 Oracleファイル/FTPアダプタの使用例

- 4.5.1 Oracleファイル・アダプタのXMLデバッチ処理

- 4.5.1.1 前提条件

- 4.5.1.2 反復要素を含む入力XMLドキュメントの分割

- 4.5.1.3 SOAコンポジットの設計

- 4.5.1.4 インバウンド・サービスの作成

- 4.5.1.5 アウトバウンド・ファイル・アダプタ・サービスの作成

- 4.5.1.6 サービスとアクティビティのワイヤリング

- 4.5.1.6.1 反復要素を含む入力XMLドキュメントの分割

- 4.5.1.6.2 receiveアクティビティの追加

- 4.5.1.6.3 invokeアクティビティの追加

- 4.5.1.6.4 transformアクティビティの追加

- 4.5.1.7 JDeveloperを使用したデプロイ

- 4.5.1.8 Oracle Enterprise Manager Fusion Middleware Controlコンソール(Fusion Middleware Controlコンソール)を使用した監視

- 4.5.2 Oracle BPEL PMのフラット構造

- 4.5.2.1 前提条件

- 4.5.2.2 SOAコンポジットの設計

- 4.5.2.3 インバウンド・サービスの作成

- 4.5.3.5 アウトバウンド・サービスの作成

- 4.5.2.5 サービスとアクティビティのワイヤリング

- 4.5.2.5.1 receiveアクティビティの追加

- 4.5.2.5.2 invokeアクティビティの追加

- 4.5.2.5.3 transformアクティビティの追加

- 4.5.2.6 JDeveloperを使用したデプロイ

- 4.5.2.7 Oracle Fusion Middleware Controlコンソールを使用した監視

- 4.5.3 メディエータのフラット構造

- 4.5.3.1 前提条件

- 4.5.3.2 アプリケーションとプロジェクトの作成

- 4.5.3.3 スキーマ定義(.XSD)ファイルのインポート

- 4.5.3.4 インバウンド・サービスの作成

- 4.5.3.5 アウトバウンド・サービスの作成

- 4.5.3.6 サービスのワイヤリング

- 4.5.3.7 ルーティング・ルールの作成

- 4.5.3.8 JDeveloperを使用したデプロイ

- 4.5.3.9 実行時タスク

- 4.5.4 Oracleファイル・アダプタのスケーラブルなDOM

- 4.5.4.1 前提条件

- 4.5.4.2 SOAコンポジットの設計

- 4.5.4.3 インバウンド・サービスの作成

- 4.5.4.4 アウトバウンド・サービスの作成

- 4.5.4.5 サービスとアクティビティのワイヤリング

- 4.5.4.5.1 receiveアクティビティの追加

- 4.5.4.5.2 invokeアクティビティの追加

- 4.5.4.5.3 assignアクティビティの追加

- 4.5.4.6 JDeveloperを使用したデプロイ

- 4.5.4.7 Fusion Middleware Controlコンソールを使用した監視

- 4.5.5 Oracleファイル・アダプタのチャンク読取り

- 4.5.5.1 前提条件

- 4.5.5.2 SOAコンポジットの設計

- 4.5.5.3 インバウンド・サービスの作成

- 4.5.5.4 アウトバウンド・サービスの作成

- 4.5.5.4.1 別のアウトバウンドOracleファイル・アダプタ・サービスの追加

- 4.5.5.5 サービスとアクティビティのワイヤリング

- 4.5.5.5.1 receiveアクティビティの追加

- 4.5.5.5.2 assignアクティビティの追加

- 4.5.5.5.3 invokeアクティビティの追加

- 4.5.5.5.4 switchアクティビティの追加

- 4.5.5.5.5 transformアクティビティの追加

- 4.5.5.6 JDeveloperを使用したデプロイ

- 4.5.5.7 Fusion Middleware Controlコンソールを使用した監視

- 添付ファイルとしての4.5.6 Oracleファイル・アダプタのRead File

- 4.5.6.1 前提条件

- 4.5.6.2 SOAコンポジットの設計

- 4.5.6.3 インバウンド・サービスの作成

- 4.5.6.4 アウトバウンド・サービスの作成

- 4.5.6.5 サービスとアクティビティのワイヤリング

- 4.5.6.5.1 receiveアクティビティの追加

- 4.5.6.5.2 invokeアクティビティの追加

- 4.5.6.5.3 assignアクティビティの追加

- 4.5.6.6 JDeveloperを使用したデプロイ

- 4.5.6.7 Fusion Middleware Controlコンソールを使用した監視

- 4.5.7 Oracleファイル・アダプタのファイル・リスティング

- 4.5.7.1 前提条件

- 4.5.7.2 SOAコンポジットの設計

- 4.5.7.3 アウトバウンド・サービスの作成

- 4.5.7.4 サービスとアクティビティのワイヤリング

- 4.5.7.4.1 文字列変数の作成

- 4.5.7.4.2 invokeアクティビティの追加

- 4.5.7.4.3 assignアクティビティの追加

- 4.5.7.5 JDeveloperを使用したデプロイ

- 4.5.7.6 Fusion Middleware Controlコンソールを使用した監視

- 4.5.8 Oracleファイル・アダプタの複雑な構造

- 4.5.8.1 前提条件

- 4.5.8.2 SOAコンポジットの設計

- 4.5.8.3 インバウンド・サービスの作成

- 4.5.8.4 アウトバウンド・サービスの作成

- 4.5.8.5 サービスとアクティビティのワイヤリング

- 4.5.8.5.1 receiveアクティビティの追加

- 4.5.8.5.2 invokeアクティビティの追加

- 4.5.8.5.3 transformアクティビティの追加

- 4.5.8.6 JDeveloperを使用したデプロイ

- 4.5.8.7 Fusion Middleware Controlコンソールを使用した監視

- 4.5.9 Oracle FTPアダプタのデバッチ処理

- 4.5.9.1 前提条件

- 4.5.9.2 SOAコンポジットの設計

- 4.5.9.3 インバウンド・サービスの作成

- 4.5.9.4 アウトバウンド・サービスの作成

- 4.5.9.5 サービスとアクティビティのワイヤリング

- 4.5.9.5.1 receiveアクティビティの追加

- 4.5.9.5.2 invokeアクティビティの追加

- 4.5.9.5.3 switchアクティビティの追加

- 4.5.9.6 JDeveloperを使用したデプロイ

- 4.5.9.7 Fusion Middleware Controlコンソールを使用した監視

- 4.5.10 Oracle FTPアダプタの動的な同期読取り

- 4.5.10.1 前提条件

- 4.5.10.2 SOAコンポジットの設計

- 4.5.10.3 インバウンド・サービスの作成

- 4.5.10.4 アウトバウンド・サービスの作成

- 4.5.10.4.1 アウトバウンドOracleファイル・アダプタ・サービスの追加

- 4.5.10.5 サービスとアクティビティのワイヤリング

- 4.5.10.5.1 receiveアクティビティの追加

- 4.5.10.5.2 変数の作成とinvokeアクティビティの追加

- 4.5.10.5.3 別のinvokeアクティビティの追加

- 4.5.10.5.4 assignアクティビティの追加

- 4.5.10.5.5 transformアクティビティの追加

- 4.5.10.6 JDeveloperを使用したデプロイ

- 4.5.10.7 Fusion Middleware Controlコンソールを使用した監視

- 4.5.11 ファイルのコピー、移動および削除

- 4.5.11.1 ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動

- 4.5.11.2 ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルのコピー

- 4.5.11.3 ローカル・ファイルシステム・ディレクトリからのファイルの削除

- 4.5.11.4 大きいCSVソース・ファイルの使用

- 4.5.11.5 あるリモート・ディレクトリから同じFTPサーバーの別のリモート・ディレクトリへのファイルの移動

- 4.5.11.6 ファイルシステムのローカル・ディレクトリからFTPサーバーのリモート・ディレクトリへのファイルの移動

- 4.5.11.7 FTPサーバーのリモート・ディレクトリからファイルシステムのローカル・ディレクトリへのファイルの移動

- 4.5.11.8 あるFTPサーバーから別のFTPサーバーへのファイルの移動

- 4.5.12 ファイル・アダプタを使用した同期BPELコンポジットの作成

- 4.5.12.1 FTPアダプタでのコネクション・ファクトリJNDIの動的な変更

- 4.5.12.2 アウトバウンド書込み操作からのファイルの詳細の取得

- 4.5.13 ファイル/FTPアダプタの順序付け方法の変更

- 4.5.14 ファイルの処理順序の制御

- 4.5.15 FTPアダプタの拡張

- 4.5.15.1 FTP/ファイル・アダプタの拡張の使用例

- 4.5.15.2 FTPクライアント・ログインのFTPアダプタ拡張

- 4.5.15.2.1 FTPClient実装の拡張によるlogin()のオーバーライド

- 4.5.15.3 MLSDコマンドに対するレスポンスを処理するためのFTPアダプタの構成

- 4.5.15.3.1 MLSDの拡張

- 4.5.15.3.2 MLSDコマンドをサポートするためのプラグイン実装の構成

- 4.5.15.3.3 LISTコマンドではなくMLSDコマンドを送信するためのリスティング操作の拡張

- 4.5.15.4 MVSプラットフォームで実行されているFTPサーバーに追加の固有FTPコマンドを送信するための格納操作の拡張

- 4.5.15.5 その他の構成パラメータ、実装、インタフェースおよびスキーマ

- 4.5.15.5.1 FTPClient実装のサンプル

- 4.5.15.6 FtpListResponseParserインタフェース

- 4.5.15.7 FtpTimestampParserインタフェース

- 4.5.15.8 ftpmappingスキーマ

- 4.5.15.8.1 Manifest.MFファイルを使用したコンパイル用のfileftp.jarの生成

- 4.5.15.8.2 ListParserおよびTimeParserのサンプル

5 Oracle JCA Adapter for Sockets

- 5.1 Oracleソケット・アダプタの概要

- 5.1.1 アーキテクチャ

- 5.1.1.1 ソケット・アダプタのメッセージ拒否および再発行は使用されない

- 5.1.2 メディエータとの統合

- 5.1.3 Oracle BPEL PMとの統合

- 5.1.4 SOAコンポジットとの統合

- 5.2 機能

- 5.3 概念

- 5.3.1 通信モード

- 5.3.1.1 インバウンド同期リクエスト/レスポンス

- 5.3.1.2 アウトバウンド同期リクエスト/レスポンス

- 5.3.1.3 インバウンド受信

- 5.3.1.4 アウトバウンド起動

- 5.3.2 プロトコル定義メカニズム

- 5.3.2.1 スタイルシートを使用したハンドシェイク・メカニズムを持つプロトコル

- 5.3.2.2 カスタムJavaコードを使用したハンドシェイク・メカニズムを持つプロトコル

- 5.3.2.3 ハンドシェイク・メカニズムを持たないプロトコル

- 5.3.3 キャラクタ・エンコーディングとバイト順

- 5.3.4 パフォーマンス・チューニング

- 5.3.4.1 接続プーリングの構成

- 5.3.4.1.1 Oracleソケット・アダプタの接続プーリングの構成方法

- 5.4 構成

- 5.4.1 weblogic-ra.xmlファイルの変更

- 5.4.2 ハンドシェイクのモデル化

- 5.4.2.1 アウトバウンド・ハンドシェイクのモデル化

- 5.4.2.2 インバウンド・ハンドシェイクのモデル化

- 5.4.3 XSLマッパー・ツールを使用したXSLファイルの設計

- 5.4.3.1 インバウンド同期リクエスト/リプライに使用するXSLの設計

- 5.4.3.1.1 SOAコンポジットの設計

- 5.4.3.1.2 インバウンドOracleソケット・アダプタの作成

- 5.4.3.2 アウトバウンド同期リクエスト/リプライに使用するXSLの設計

- 5.4.3.2.1 SOAコンポジットの設計

- 5.4.3.2.2 アウトバウンドOracleソケット・アダプタの作成

- 5.4.4 Oracleソケット・アダプタの構成プランでのTCPポートの指定

- 5.4.5 JavaScriptのサポート

- 5.4.5.1 SOCKETアダプタ構成ウィザードによる、使用するスクリプトの定義

- 5.4.5.2 レポート

- 5.4.5.3 サンプル・スクリプト

- 5.4.6 ソケット・アダプタNIOのサポート

- 5.4.7 ソケット・アダプタに対するSSLのサポート

- 5.4.7.1 ソケット・アダプタでのSSLのサポート

- 5.5 使用例

- 5.5.1 Oracleソケット・アダプタHello World

- 5.5.1.1 前提条件

- 5.5.1.2 SOAコンポジットの設計

- 5.5.1.3 インバウンド・サービスの作成

- 5.5.1.4 アウトバウンド・サービスの作成

- 5.5.1.5 サービスとアクティビティのワイヤリング

- 5.5.1.5.1 receiveアクティビティの追加

- 5.5.1.5.2 invokeアクティビティの追加

- 5.5.1.5.3 replyアクティビティの追加

- 5.5.1.5.4 assignアクティビティの追加

- 5.5.1.6 JDeveloperを使用したデプロイ

- 5.5.1.7 Oracle Enterprise Manager Fusion Middleware Controlコンソール(Fusion Middleware Controlコンソール)を使用した監視

- 5.5.2 フライト情報表示システム

- 5.5.2.1 前提条件

- 5.5.2.2 SOAコンポジットの設計

- 5.5.2.3 インバウンド・サービスの作成

- 5.5.2.4 アウトバウンド・サービスの作成

- 5.5.2.5 サービスとアクティビティのワイヤリング

- 5.5.2.5.1 receiveアクティビティの追加

- 5.5.2.5.2 replyアクティビティの追加

- 5.5.2.5.3 flowアクティビティの追加

- 5.5.2.5.4 Airline1サーバーのフローの設計

- 5.5.2.5.5 Airline2サーバーのフローの設計

- 5.5.2.5.6 Airline3サーバーのフローの設計

- 5.5.2.5.7 assignアクティビティの追加

- 5.5.2.6 JDeveloperを使用したデプロイ

- 5.5.2.7 Fusion Middleware Controlコンソールを使用した監視

- 5.5.3 ソケット・アダプタのクラスタ・サポート

- 5.5.3.1 ソケット・アダプタをクラスタ化環境で使用するための構成

- 5.5.3.1.1 Coherenceによるパフォーマンスの最適化

- 5.5.3.1.2 クラスタ化環境でソケット・アダプタのサポートを有効化するための、JNDIコネクション・ファクトリの「ポート」プロパティの更新

6 ネイティブ・フォーマット・ビルダー・ウィザード

- 6.1 ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ・ファイルの作成

- 6.1.1 サポートされているファイル形式

- 6.1.1.1 デリミタ

- 6.1.1.2 固定長(位置固定)

- 6.1.1.3 複合タイプ

- 6.1.1.4 DTD

- 6.1.1.5 COBOLコピーブック

- 6.1.1.5.1 ユーザー入力

- 6.1.1.5.2 COBOL句

- 6.1.1.5.3 ピクチャ編集タイプ

- 6.1.1.6 XSDに変換されるMFL

- 6.1.1.7 JSON Interchangeフォーマット

- 6.1.2 ネイティブ・スキーマ・ファイルの編集

- 6.2 ネイティブ・スキーマ・コンストラクト

- 6.2.1 ネイティブ・スキーマ・コンストラクトについて

- 6.2.2 ネイティブ・スキーマ・コンストラクトの使用

- 6.2.2.1 固定長データの定義

- 6.2.2.2 終了データの定義

- 6.2.2.3 囲みデータの定義

- 6.2.2.4 リストの定義

- 6.2.2.4.1 すべてのアイテムが同じマークで区切られているが最後のアイテムが異なるマークで終了している場合(バインド済)

- 6.2.2.4.2 最後のアイテムを含みすべてのアイテムが同じマークで区切られている場合(バインドなし)

- 6.2.2.5 配列の定義

- 6.2.2.5.1 すべてのセルが同じマークで区切られているが最後のセルが異なるマークで終了している場合(バインド済)

- 6.2.2.5.2 最後のセルを含み、すべてのセルが同じマークで区切られている場合(バインドなし)

- 6.2.2.5.3 セルはマークで区切られていないが最後のセルがマークで終了している場合(バインド済)

- 6.2.2.5.4 ネイティブ・データからセルの数が読み取られる場合

- 6.2.2.5.5 明示的な配列長

- 6.2.2.6 条件付き処理

- 6.2.2.6.1 条件に基づきchoiceモデル・グループ内の1つの要素を処理する場合

- 6.2.2.6.2 条件に基づきsequenceモデル・グループ内の複数の要素を処理する場合

- 6.2.2.7 日付の定義

- 6.2.2.7.1 日付の定義: ローカル・サポートあり

- 6.2.2.8 変数の使用

- 6.2.2.9 接頭辞と接尾辞の定義

- 6.2.2.10 スキップするデータの定義

- 6.2.2.11 fixedおよびdefault値の定義

- 6.2.2.12 writeの定義

- 6.2.2.13 LookAheadの定義

- 6.2.2.13.1 LookAhead: タイプ1

- 6.2.2.13.2 LookAhead: タイプ2

- 6.2.2.14 正規表現を使用したレコードの条件付き処理に対する複雑なLookAhead戦略の定義

- 6.2.2.14.1 パターンの検索時に改行文字を含める

- 6.2.2.15 outboundHeaderの定義

- 6.2.2.16 conditionValueでの複雑な条件の定義

- 6.2.2.17 choiceConditionでの複雑な条件の定義

- 6.2.2.18 dataLinesの定義

- 6.2.2.19 タイムゾーンを使用した日付書式の定義

- 6.2.2.20 変換中の検証の実装

- 6.2.2.20.1 ペイロード検証

- 6.2.2.20.2 スキーマ検証

- 6.2.2.21 BOMを使用したファイルの処理

- 6.2.3 インバウンドおよびアウトバウンド・ネイティブ・データのマルチバイト変換

- 6.2.3.1 初期の問題

- 6.2.3.2 解決策

- 6.2.3.3 パディング・データの指定

- 6.2.3.4 接頭辞または接尾辞の指定

- 6.2.3.5 マルチストリーム・データによるトランスレータの動作

- 6.2.3.6 アウトバウンド変換の動作

- 6.2.3.7 例

- 6.2.3.7.1 Base 64バイナリ・パディング・データ

- 6.2.3.7.2 バイナリ

- 6.2.3.7.3 シフトJISエンコーディング

- 6.2.3.7.4 識別子の長さの例

- 6.2.3.7.5 識別子の例(base64BInary)

- 6.2.3.7.6 識別子: SJISを使用したパディング・データ

- 6.2.3.7.7 識別子: バイナリのパディング

- 6.2.3.7.8 マルチバイト・バイナリ要素のパディング

- 6.2.3.7.9 マルチバイトの10進数のパディング

- 6.2.4 SOSIサポート

- 6.3 トランスレータXPath関数

- 6.3.1 用語

- 6.3.2 トランスレータXPath関数

- 6.3.2.1 doTranslateFromNative関数

- 6.3.2.2 doTranslateToNative関数

- 6.3.2.3 doStreamingTranslate関数

- 6.3.2.4 バッチ処理によるトランスフォーメーションの特徴

- 6.4 ネイティブ・フォーマット・ビルダーの使用例

- 6.4.1 デリミタ付きファイル構造のスキーマの定義

- 6.4.1.1 アスタリスク(*)区切り値ファイルの構造の定義

- 6.4.2 固定長ファイル構造のスキーマの定義

- 6.4.3 複雑なファイル構造のスキーマの定義

- 6.4.4 ネームスペースのないXMLのネームスペースの削除または追加

- 6.4.5 複雑なファイル構造の選択条件スキーマの定義

- 6.4.6 複雑なファイル構造のLookAheadを使用する選択条件の定義

- 6.4.7 複雑なファイル構造の配列タイプ・スキーマの定義

- 6.4.8 DTDファイル構造のスキーマの定義

- 6.4.9 COBOLコピーブック・ファイル構造のスキーマの定義

- 6.4.9.1 複数のルート・レベル

- 6.4.9.2 単一のルート・レベル、仮想小数点、固定長配列

- 6.4.9.3 可変長配列

- 6.4.9.4 数値型

- 6.5 nXSDトランスレータのテスト用コマンドライン・ツール

- 6.5.1 前提条件

- 6.5.2 テスト・ツールの実行

- 6.5.3 ネイティブ・フォーマット・ビルダーを使用したMFL変換の実行

- 6.5.3.1 MFLフォーマット・ファイルからスキーマ・フォーマットへの変換

- 6.5.3.2 スキーマ・ファイルの生成およびSOAコンポジット・プロセスへの追加

- 6.5.3.2.1 MFLファイルの例

- 6.5.3.2.2 MFLファイルの例から作成されるスキーマ・ファイルの例

- 6.5.3.3 ネイティブ・フォーマット・ビルダー・ウィザードでのMFLファイル変換のフロー

- 6.5.4 マルチキャラクタ・ストリーミングのサポート

- 6.5.5 共有デリミタ

- 6.5.5.1 インバウンドの共有デリミタ処理を使用するNXSDトランスレータの基本概念

- 6.5.5.1.1 セルおよび配列の終了

- 6.5.5.1.2 重要な用語

- 6.5.5.1.3 セル・セパレータおよび配列の終端文字の共有

- 6.5.5.1.4 動作

- 6.5.5.2 終了の使用例

- 6.5.5.3 固定長の使用例

- 6.5.5.4 囲みの使用例

- 6.5.5.5 その他の使用例

- 6.5.5.5.1 Shared_array_Terminator.xsd

- 6.5.5.5.2 Shared_trailing_array.xsd

- 6.5.5.5.3 Shared_trailing_OptionalArray.xsdの使用例

第II部 メッセージ・アダプタ

7 Oracle JCA Adapter for AQ

- 7.1 Oracle AQアダプタの概要

- 7.1.1 Oracle AQアダプタの次のコンポーネントとの統合

- 7.1.2 Oracle Mediatorとの統合

- 7.2 Oracle AQアダプタの機能

- 7.2.1 エンキュー固有の機能(メッセージ生成)

- 7.2.2 デキューおよびエンキューの機能

- 7.2.3 同期リクエスト/レスポンス

- 7.2.3.1 AQ同期リクエスト/レスポンス相互作用パターンの構成ウィザード・フロー

- 7.2.3.1.1 同期リクエスト//リプライ相互作用パターンを使用したAQアダプタの編集

- 7.2.4 同期デキュー

- 7.2.4.1 AQ同期デキューの構成ウィザード・フロー

- 7.2.4.2 同期リクエスト/リプライのJCAファイル

- 7.2.4.3 同期デキューのJCAファイル

- 7.2.5 サポートされているADTペイロード・タイプ

- 7.2.6 ネイティブ・フォーマット・ビルダー・ウィザード

- 7.2.7 正規化されたメッセージのサポート

- 7.2.8 DOM2準拠

- 7.2.9 メッセージ・サイズ対応

- 7.2.10 複数の受信者スレッド

- 7.2.11 DequeueTimeoutプロパティ

- 7.2.12 デキュー・タイムアウトおよび複数のインバウンド・ポーリング・スレッドの制御

- 7.2.13 ストリーム・ペイロードのサポート

- 7.2.14 インバウンドの再試行

- 7.2.15 エラー処理のサポート

- 7.2.16 パフォーマンスのチューニング

- 7.3 Oracle AQアダプタのデプロイメント

- 7.4 使用例

- 7.4.1 一般的な使用例

- 7.4.1.1 アダプタ構成ウィザードの概要

- 7.4.1.1.1 前提条件の確認

- 7.4.1.1.2 アプリケーションおよびSOAプロジェクトの作成

- 7.4.1.1.3 サービスの定義

- 7.4.1.1.4 生成されたWSDLおよびJCAファイル

- 7.4.1.2 オブジェクトとADTペイロードのデキューおよびエンキュー

- 7.4.1.3 オブジェクト・ペイロードの1つの列のデキュー

- 7.4.1.4 エンキュー/デキュー操作タイプの構成

- 7.4.1.4.1 前提条件の確認

- 7.4.1.4.2 アプリケーションおよびSOAプロジェクトの作成

- 7.4.1.4.3 Oracle AQアダプタ・サービスの定義

- 7.4.1.4.4 サービスとアクティビティのワイヤリング

- 7.4.1.4.5 JDeveloperを使用したデプロイ

- 7.4.1.4.6 Fusion Middleware Controlコンソールを使用した監視

- 7.4.1.4.7 生成されたWSDLおよびJCAファイル

- 7.4.1.5 デキュー中のメッセージのフィルタ処理に対する相関IDの使用

- 7.4.1.6 マルチ・サブスクライバ・キューからのエンキューおよびデキュー

- 7.4.2 ADTキュー

- 7.4.2.1 前提条件の確認

- 7.4.2.2 アプリケーションおよびSOAプロジェクトの作成

- 7.4.2.3 インバウンドOracle AQアダプタの作成

- 7.4.2.4 アウトバウンドOracle AQアダプタの作成

- 7.4.2.5 サービスとアクティビティのワイヤリング

- 7.4.2.6 ルーティング・サービスの構成

- 7.4.2.7 Oracle WebLogic Server管理コンソールでのデータソースの構成

- 7.4.2.8 JDeveloperを使用したデプロイ

- 7.4.2.9 Fusion Middleware Controlコンソールを使用した監視

- 7.4.3 Oracle AQアダプタのRAWキュー

- 7.4.3.1 前提条件

- 7.4.3.2 アプリケーションおよびSOAプロジェクトの作成

- 7.4.3.3 インバウンド・アダプタ・サービスの作成

- 7.4.3.4 アウトバウンド・アダプタ・サービスの作成

- 7.4.3.5 サービスとアクティビティのワイヤリング

- 7.4.3.6 Oracle WebLogic Server管理コンソールでのデータソースの構成

- 7.4.3.7 JDeveloperを使用したデプロイ

- 7.4.3.8 Fusion Middleware Controlコンソールを使用した監視

8 Oracle JCA Adapter for JMS

- 8.1 Oracle JMSアダプタの概要

- 8.1.1 Oracle BPEL Process Managerとの統合

- 8.1.2 Oracle JMSアダプタとOracle Mediatorの統合

- 8.2 Oracle JMSアダプタの機能

- 8.3 Oracle JMSアダプタの概念

- 8.3.1 Point-to-Point

- 8.3.2 パブリッシュ/サブスクライブ

- 8.3.3 宛先、接続、コネクション・ファクトリおよびセッション

- 8.3.4 JMSメッセージの構造

- 8.3.5 Oracle JMSアダプタのヘッダー・プロパティ

- 8.3.6 サード・パーティ・サービス・プロバイダとの接続

- 8.3.6.1 バインディング

- 8.4 Oracle JMSアダプタの使用例

- 8.4.1 Oracle JMSアダプタの構成

- 8.4.1.1 アプリケーションおよびSOAプロジェクトの作成

- 8.4.1.2 アダプタ構成ウィザードを使用した構成

- 8.4.1.3 生成されるファイル

- 8.4.1.4 weblogic-ra.xmlファイル

- 8.4.1.4.1 Oracle WebLogic Server管理コンソールを使用した新規接続の作成

- 8.4.1.4.2 サード・パーティのJMSプロバイダの追加

- 8.4.1.5 メッセージ発行手順

- 8.4.2 TIBCO JMSを使用したOracle JMSアダプタの構成

- 8.4.2.1 非SSL接続での事前構成済のTibcoコネクション・ファクトリの使用

- 8.4.2.2 非SSL接続での動的に作成されたTibcoコネクション・ファクトリの使用

- 8.4.2.3 SSL接続での事前構成済のTibcoコネクション・ファクトリの使用

- 8.4.2.4 SSL接続での動的に作成されたTibcoコネクション・ファクトリの使用

- 8.4.3 IBM WebSphere MQ JMSを使用したOracle JMSアダプタの構成

- 8.4.3.1 非XAデータソース

- 8.4.3.1.1 マルチインスタンス・キュー・マネージャの使用

- 8.4.3.2 XAデータソース

- 8.4.4 Active MQ JMSを使用したOracle JMSアダプタの構成

- 8.4.5 WebLogic Server JMSテキスト・メッセージ

- 8.4.5.1 前提条件の確認

- 8.4.5.1.1 Oracle WebLogic Server管理コンソールでのキューの作成

- 8.4.5.1.2 Q2Qorders.xsdファイルの作成

- 8.4.5.2 アプリケーション・サーバー接続の作成

- 8.4.5.3 アプリケーションおよびSOAプロジェクトの作成

- 8.4.5.4 インバウンド・アダプタ・サービスの作成

- 8.4.5.5 アウトバウンド・アダプタ・サービスの作成

- 8.4.5.6 サービスとアクティビティのワイヤリング

- 8.4.5.7 JDeveloperを使用したデプロイ

- 8.4.5.8 Fusion Middleware Controlコンソールを使用した監視

- 8.4.6 リモートOracle WebLogic Serverドメイン内のWLS JMSサーバーからのキューとトピックへのアクセス

- 8.4.6.1 リモート・サーバーが使用される場合のJMSアダプタの制限

- 8.4.7 同期/非同期リクエスト-リプライ相互作用パターン

- 8.4.7.1 同期リクエスト-リプライ・パターン

- 8.4.7.2 非同期リクエスト-リプライ・パターン

- 8.4.8 AQ JMSテキスト・メッセージ

- 8.4.8.1 前提条件の確認

- 8.4.8.1.1 Oracle WebLogic Server管理コンソールでのAQ JMSの構成

- 8.4.8.1.2 Oracleデータベースでのキューの作成

- 8.4.8.2 アプリケーション・サーバー接続の作成

- 8.4.8.3 アプリケーションおよびSOAプロジェクトの作成

- 8.4.8.4 インバウンド・アダプタ・サービスの作成

- 8.4.8.5 アウトバウンド・アダプタ・サービスの作成

- 8.4.8.6 サービスとアクティビティのワイヤリング

- 8.4.8.7 JDeveloperを使用したデプロイ

- 8.4.8.8 Fusion Middleware Controlコンソールを使用した監視

- 8.4.9 OC4J 10.1.3.4サーバーからリリース11gで作成されたキューとトピックへのアクセス

- 8.4.10 10.1.3.X OC4Jに存在するキューにアクセスするための11G以降のサーバーの構成

- 8.4.10.1 Web Logic ServerのdomainsフォルダへのJarファイルのコピー

- 8.4.10.2 weblogic-ra.xmlファイルへのコネクタ・ファクトリの追加

- 8.4.11 WebLogic Server JMS上の分散宛先(キューとトピック)へのアクセス

- 8.4.11.1 分散トピックにアクセスするためのJMSアダプタの指定

- 8.4.11.2 分散キューと分散トピックを使用したJMSアダプタ

- 8.4.11.3 アプリケーションごとに1つのメッセージのコピー(デフォルトの動作)

- 8.4.11.4 アダプタ・エンドポイントごとに1つのメッセージのコピー

- 8.4.11.4.1 アクティブ化の仕様を定義するときのメッセージ・セレクタの指定

- 8.4.11.4.2 互換性と移行

- 8.4.12 IBM WebSphereのデフォルトのJMSプロバイダを使用したOracle JMSアダプタの構成

- 8.4.13 JMSアダプタでのリクエスト-リプライの構成

- 8.4.14 JMSアダプタでのWLS JMS順序単位の使用

- 8.4.14.1 順序単位プロパティの取得

- 8.4.15 JMS同期消費

- 8.4.15.1 JMS同期消費の構成

9 Oracle JCA Adapter for Database

- 9.1 概要

- 9.1.1機能概要

- 9.1.1.1 Oracle BPEL PMとの統合

- 9.1.2 設計の概要

- 9.2 データベース・アダプタ構成ウィザードの概要

- 9.2.1 アプリケーションおよびSOAプロジェクトの作成

- 9.2.2 定義

- 9.2.3 データベースへの接続

- 9.2.4 操作タイプの選択

- 9.2.5 表の選択およびインポート

- 9.2.6 主キーの定義

- 9.2.6.1 主キーとしてのROWIDの使用

- 9.2.6.1.1 「主キー」ページでのROWIDの使用

- 9.2.7 リレーションシップの作成

- 9.2.7.1 リレーションシップが作成または削除された際の動作

- 9.2.7.2 様々なタイプの1対1マッピング

- 9.2.7.3 外部キーが主キーである場合

- 9.2.8 属性フィルタの作成

- 9.2.9 WHERE句の定義

- 9.2.10 読取り後戦略の選択

- 9.2.10.1 読取り済の行の削除

- 9.2.10.2 表のフィールドの更新(論理削除)

- 9.2.10.3 順序表の更新

- 9.2.10.4 異なるデータベースにある外部順序表の更新

- 9.2.10.5 順序ファイルの更新

- 9.2.11 ポーリング・オプションの指定

- 9.2.12 詳細オプションの指定

- 9.2.13 Pure SQL操作に必要なSQL文字列の入力

- 9.3 機能

- 9.3.1 トランザクション・サポート

- 9.3.1.1 グローバル・トランザクションへの関与のための構成

- 9.3.1.2 両方を同じグローバル・トランザクションで起動

- 9.3.1.3 失敗時のロールバックが必須

- 9.3.1.3.1 両方の起動に対する同一セッションの使用

- 9.3.1.4 トランザクション/XAサポート

- 9.3.1.4.1 グローバル・トランザクションへの関与のための構成

- 9.3.1.4.2 失敗時のロールバックが必須

- 9.3.2 Pure SQL - XMLタイプのサポート

- 9.3.3 強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート

- 9.3.4 プロキシ認証のサポート

- 9.3.5 大きなペイロードのストリーミング

- 9.3.6 スキーマ検証

- 9.3.7 高可用性

- 9.3.8 スケーラビリティ

- 9.3.8.1 分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE (SKIP LOCKED)

- 9.3.8.1.1 SKIP LOCKEDの詳細

- 9.3.8.1.2 Oracle以外のデータベース

- 9.3.8.1.3 PollingInterval、MaxTransactionSizeおよびActivationInstancesの詳細な構成

- 9.3.8.1.4 パーティション・フィールド

- 9.3.8.1.5 activationInstances

- 9.3.8.1.6 索引付けおよびNULL値

- 9.3.8.1.7 ロッキングのスキップの無効化

- 9.3.8.1.8 MarkReservedValueとロッキングのスキップ

- 9.3.8.1.9 SequencingPollingStrategy (最終読取りまたは最終更新)

- 9.3.8.2 分散ポーリングのベスト・プラクティス2: 最初に単一ノードでチューニングする

- 9.3.9 パフォーマンス・チューニング

- 9.3.10 detectOmissions機能

- 9.3.11 OutputCompletedXml機能

- 9.3.12 インバウンドおよびアウトバウンド・トランザクションのQueryTimeout

- 9.3.13 BPELへの同期ポストの実行(順序配信の許可)

- 9.4 概念

- 9.4.1 リレーショナルからXMLへのマッピング

- 9.4.1.1 リレーショナル型からXMLスキーマ型へ

- 9.4.1.2 任意のリレーショナル・スキーマの任意のXMLスキーマへのマッピング

- 9.4.1.3 複数の表の問合せ

- 9.4.1.3.1 リレーションシップの問合せを使用する方法(TopLinkのデフォルト)

- 9.4.1.3.2 オリジナルのselectを利用する方法(TopLinkのバッチ属性読取り)

- 9.4.1.3.3 単一結果セットを戻す方法(TopLinkの結合属性読取り)

- 9.4.1.3.4 複数の表の問合せに使用した2つの方法の比較

- 9.4.2 WebサービスとしてのSQL操作

- 9.4.2.1 DML操作

- 9.4.2.2 ポーリング戦略

- 9.5 データベース・アダプタ・デプロイメント

- 9.5.1 サード・パーティ・データベースを使用したデプロイメント

- 9.6 JDBCドライバとデータベース接続の構成

- 9.6.1 ネイティブまたはバンドルされたOracle WebLogic Server JDBCドライバを使用したデータベース接続の作成

- 9.6.2 サード・パーティJDBCドライバを使用したデータベース接続の作成

- 9.6.3 サード・パーティJDBCドライバおよびデータベース接続情報の概要

- 9.6.3.1 Microsoft SQL Serverの使用方法

- 9.6.3.2 SQLSERVER Weblogic JDBCドライバの使用

- 9.6.3.3 Sybaseデータベースの使用方法

- 9.6.3.3.1 Sybase JConnect JDBCドライバの使用方法

- 9.6.3.4 Informixデータベースの使用方法

- 9.6.3.4.1 Informix JDBCドライバの使用方法

- 9.6.3.5 IBM DB2データベースの使用方法

- 9.6.3.5.1 IBM DB2ドライバ

- 9.6.3.5.2 JT400ドライバ(AS400 DB2)

- 9.6.3.5.3 IBM Universalドライバ

- 9.6.3.6 MySQLデータベースの使用方法

- 9.6.3.7 Derbyデータベースの使用

- 9.6.3.8 Progressデータベースの使用

- 9.6.4 JDBCドライバJARファイルの場所とクラスパスの設定

- 9.7 ストアド・プロシージャおよびファンクションのサポート

- 9.7.1 設計時: アダプタ構成ウィザードの使用

- 9.7.1.1 最上位のスタンドアロンAPIの使用

- 9.7.1.2 パッケージ化されたAPIの使用およびオーバーロード

- 9.7.2 サポートされるサード・パーティ・データベース

- 9.7.2.1 使用される用語

- 9.7.2.2 重要な注意点

- 9.7.2.2.1 Microsoft SQL Server

- 9.7.2.2.2 DB2データ型

- 9.7.2.2.3 IBM DB2 AS/400

- 9.7.2.3 データベース接続の作成

- 9.7.3 設計時: 成果物の生成

- 9.7.3.1 WSDL–XSDリレーションシップ

- 9.7.3.2 JCAファイル

- 9.7.3.3 Oracleのデータ型

- 9.7.3.4 生成されたXSD属性

- 9.7.3.5 ユーザー定義タイプ

- 9.7.3.6 複雑なユーザー定義タイプ

- 9.7.3.7 オブジェクト・タイプの継承

- 9.7.3.8 オブジェクト参照

- 9.7.3.9 別のスキーマのタイプの参照

- 9.7.3.10 XSDプルーニングの最適化

- 9.7.4 実行時: ストアド・プロシージャの起動前

- 9.7.4.1 値のバインディング

- 9.7.4.2 データ型の変換

- 9.7.5 実行時: ストアド・プロシージャの起動後

- 9.7.5.1 データ型の変換

- 9.7.5.2 NULL値

- 9.7.5.3 ファンクションの戻り値

- 9.7.6 実行時: サード・パーティ・データベースの共通機能

- 9.7.6.1 ResultSetsの処理

- 9.7.6.2 INTEGERステータス値の戻し

- 9.7.7 高度なトピック

- 9.7.7.1 強い型指定のXSDを使用した行セットのサポート

- 9.7.7.1.1 設計時

- 9.7.7.1.2 実行時

- 9.7.7.2 弱い型指定のXSDを使用した行セットのサポート

- 9.7.7.2.1 設計時

- 9.7.7.2.2 実行時

- 9.7.7.3 PL/SQLブール、PL/SQLレコードおよびPL/SQL表タイプのサポート

- 9.7.7.3.1 ラッパー・プロシージャのデフォルト句

- 9.8 Oracleデータベース・アダプタの使用例

- 9.8.1 使用例

- 9.8.2 Oracleデータベース・アダプタ - ストアド・プロシージャの使用例

- 9.8.2.1 JDeveloper BPELデザイナにおけるストアド・プロシージャの作成および構成

- 9.8.2.1.1 前提条件

- 9.8.2.1.2 アプリケーションおよびSOAコンポジットの作成

- 9.8.2.1.3 アウトバウンド・サービスの作成

- 9.8.2.1.4 invokeアクティビティの追加

- 9.8.2.1.5 リクエスト・メッセージのメッセージ・パートの変更

- 9.8.2.1.6 レスポンス・メッセージのメッセージ・パートの変更

- 9.8.2.1.7 入力変数のassignアクティビティの追加

- 9.8.2.1.8 出力変数のassignアクティビティの追加

- 9.8.2.1.9 JDeveloperを使用したデプロイ

- 9.8.2.1.10 Oracle WebLogic Server管理コンソールでのデータソースの作成

- 9.8.2.1.11 Fusion Middleware Controlコンソールを使用した監視

- 9.8.2.2 ファイルからストアド・プロシージャへの使用例

- 9.8.2.2.1 前提条件

- 9.8.2.2.2 アプリケーションおよびSOAプロジェクトの作成

- 9.8.2.2.3 アウトバウンド・サービスの作成

- 9.8.2.2.4 invokeアクティビティの作成

- 9.8.2.2.5 インバウンド・ファイル・アダプタ・サービスの作成

- 9.8.2.2.6 receiveアクティビティの追加

- 9.8.2.2.7 assignアクティビティの追加

- 9.8.2.2.8 サービスとアクティビティのワイヤリング

- 9.8.2.2.9 JDeveloperを使用したデプロイ

- 9.8.2.2.10 データソースの作成

- 9.8.2.2.11 接続インスタンスの追加

- 9.8.2.2.12 ファイル・アダプタ・サービスとSQL*Plusを使用したテスト

- 9.8.2.2.13 Fusion Middleware Controlコンソールを使用した監視

- 9.8.3 データベース・アダプタ/Coherence統合

- 9.8.3.1 データベースに対する挿入/更新

- 9.8.3.1.1 選択の最適化

- 9.8.3.1.2 Coherenceとデータベース・アダプタの統合による効果が得られない問合せ

- 9.8.3.2 データベース・アダプタ/Coherence統合のアーキテクチャ

- 9.8.3.2.1 WebLogic Server 10.3.5とのCoherenceデータベース・アダプタ統合の使用

- 9.8.3.2.2 データベース・アダプタの現在の設計(Coherenceキャッシュなし)

- 9.8.3.2.3 読取り/書込み用Coherenceキャッシュとデータベース・アダプタの統合

- 9.8.3.2.4 読取り用Coherenceキャッシュとデータベース・アダプタの統合

- 9.8.3.2.5 「操作タイプ」画面を使用したキャッシュなしの有効化

- 9.8.3.2.6 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化

- 9.8.3.2.7 「操作タイプ」画面を使用した読取りキャッシュの有効化

- 9.8.3.2.8 Coherence/データベース・アダプタ統合でのXAトランザクション、読取り/書込みおよび読取り操作

- 9.8.3.2.9 Coherenceキャッシュのライフサイクルおよび構成

- 9.8.3.3 例による問合せ

- 9.8.3.3.1 例による問合せと通常の問合せの組合せ

- 9.8.3.3.2 使用に関する制約事項

- 9.8.3.4 UTF16文字データ挿入のor-mappings.xmlファイルの変更

10 Oracle JCA Adapter for MQ Series

- 10.1 MQ Seriesメッセージ・キューイングの概要

- 10.1.1 MQ Seriesの概要

- 10.2 ネイティブOracle MQ Seriesアダプタの概要

- 10.2.1 必要性

- 10.2.2 次のコンポーネントとの統合

- 10.2.3 次のコンポーネントとの統合

- 10.3 機能

- 10.3.1 RFHバージョン2 (RFH2)ヘッダー

- 10.3.1.1 固定部分

- 10.3.1.2 可変部分

- 10.3.2 SSLの有効化

- 10.3.3 XAトランザクション

- 10.3.3.1 XAリカバリ

- 10.3.3.2 ActiveMQ Series 5.8と通信するためにJMSアダプタで使用可能なXAサポート

- 10.3.4 高可用性

- 10.3.4.1 高可用性の前提条件

- 10.3.4.2 インバウンド/アウトバウンド操作での高可用性

- 10.3.5 スケーラビリティ

- 10.3.6 エンタープライズ情報システムの資格証明の保護

- 10.3.7 フォルト・ポリシー

- 10.3.8 インバウンド拒否ハンドラ

- 10.3.9 再試行メカニズム

- 10.3.9.1 JCAインバウンド再試行メカニズム

- 10.3.9.2 メッセージ・バックアウト・キュー

- 10.3.10 パフォーマンス・チューニング

- 10.4 概念

- 10.4.1 メッセージングのシナリオ

- 10.4.1.1 メッセージのエンキュー

- 10.4.1.2 メッセージのデキュー

- 10.4.1.3 非同期リクエスト-レスポンス(Oracle BPEL PMがクライアントの場合)

- 10.4.1.4 同期リクエスト-レスポンス(Oracle BPEL PMがサーバーの場合)

- 10.4.1.5 非同期リクエスト-レスポンス(Oracle BPEL PMがサーバーの場合)

- 10.4.1.6 同期リクエスト-レスポンス(サーバーの場合)

- 10.4.1.7 同期リクエスト-レスポンス(Oracle BPEL PMがクライアントの場合)

- 10.4.1.8 同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

- 10.4.1.9 非同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

- 10.4.1.10 アウトバウンド・デキューのシナリオ

- 10.4.2 メッセージ・プロパティ

- 10.4.2.1 メッセージ・タイプ

- 10.4.2.2 メッセージのフォーマット

- 10.4.2.3 メッセージの有効期限

- 10.4.2.4 メッセージの優先度

- 10.4.2.5 メッセージの永続性

- 10.4.3 相関スキーマ

- 10.4.4 配布リストのサポート

- 10.4.5 レポート・メッセージ

- 10.4.6 メッセージ配信失敗オプション

- 10.4.7 メッセージのセグメンテーション

- 10.4.8 CICSとの統合

- 10.4.9 MQ Seriesのクライアント・チャネル定義表機能の使用

- 10.4.10 大きなペイロードのサポート

- 10.4.10.1 大きなペイロード用のインバウンドMQアダプタの構成

- 10.4.10.2 大きなペイロード用のアウトバウンドMQアダプタの構成

- 10.4.11 添付のサポート

- 10.5 構成

- 10.5.1 クラスパスへのjarファイルの追加: MQ Series 6および7

- 10.5.2 JNDIエントリの追加

- 10.5.3 接続のバインディング・モードの有効化

- 10.5.4 メッセージ・セレクタを使用したメッセージの選択的デキュー

- 10.5.4.1 MQアダプタ構成ウィザードでのメッセージ・セレクタ

- 10.5.4.2 MQでのメッセージ・セレクタの使用

- 10.5.4.2.1 メッセージ・セレクタ構文: リテラル

- 10.5.4.2.2 メッセージ・セレクタ識別子

- 10.5.4.2.3 メッセージ・セレクタの式

- 10.5.4.2.4 メッセージ・セレクタの演算子

- 10.5.4.2.5 メッセージ・セレクタの比較

- 10.5.4.2.6 メッセージ・セレクタの算術

- 10.5.4.2.7 メッセージ・セレクタの高度な演算子

- 10.5.4.2.8 メッセージ・セレクタの例

- 10.5.4.2.9 メッセージ・セレクタ使用例: メッセージ・セレクタを使用してMQキューからメッセージを選択的に受信する1つのBPELプロセス

- 10.5.4.2.10 サンプル・メッセージでの使用方法

- 10.5.4.2.11 同じMQキューからメッセージを受信する2つのBPELプロセス。両方のプロセスに相互排他メッセージ・セレクタが定義されている

- 10.5.4.2.12 2つのBPELプロセス使用例のメッセージ・セレクタの作成

- 10.5.4.2.13 2つのBPELプロセス使用例でのサンプル・メッセージの使用方法

- 10.6 使用例

- 10.6.1 デキュー/エンキュー

- 10.6.1.1 前提条件

- 10.6.1.2 SOAコンポジットの設計

- 10.6.1.3 インバウンド・アダプタ・サービスの作成

- 10.6.1.4 アウトバウンド・アダプタ・サービスの作成

- 10.6.1.5 サービスとアクティビティのワイヤリング

- 10.6.1.6 JDeveloperを使用したデプロイ

- 10.6.1.7 Fusion Middleware Controlコンソールを使用した監視

- 10.6.2 インバウンド同期リクエスト-リプライ

- 10.6.2.1 前提条件

- 10.6.2.2 SOAコンポジットの設計

- 10.6.2.3 インバウンド・アダプタ・サービスの作成

- 10.6.2.4 サービスとアクティビティのワイヤリング

- 10.6.2.5 JDeveloperを使用したデプロイ

- 10.6.2.6 Fusion Middleware Controlコンソールを使用した監視

- 10.6.3 インバウンド/アウトバウンド同期リクエスト-リプライ

- 10.6.3.1 前提条件

- 10.6.3.2 SOAコンポジットの設計

- 10.6.3.3 インバウンド・アダプタ・サービスの作成

- 10.6.3.4 アウトバウンド・アダプタ・サービスの作成

- 10.6.3.5 サービスとアクティビティのワイヤリング

- 10.6.3.6 JDeveloperを使用したデプロイ

- 10.6.3.7 Fusion Middleware Controlコンソールを使用した監視

- 10.6.4 非同期リクエスト-リプライ

- 10.6.4.1 前提条件

- 10.6.4.2 SOAコンポジットの設計

- 10.6.4.3 インバウンド・アダプタ・サービスの作成

- 10.6.4.4 非同期アウトバウンド・リクエスト-リプライ・アダプタ・サービス・アウトバウンドの作成

- 10.6.4.5 もう1つのアウトバウンド・アダプタ・サービスの作成

- 10.6.4.6 サービスとアクティビティのワイヤリング

- 10.6.4.7 JDeveloperを使用したデプロイ

- 10.6.4.8 Fusion Middleware Controlコンソールを使用した監視

- 10.6.5 アウトバウンド・デキュー

- 10.6.5.1 前提条件

- 10.6.5.2 SOAコンポジットの設計

- 10.6.5.3 アウトバウンド・デキュー・アダプタ・サービスの作成

- 10.6.5.4 サービスとアクティビティのワイヤリング

- 10.6.5.5 JDeveloperを使用したデプロイ

- 10.6.5.6 Fusion Middleware Controlコンソールを使用した監視

- 10.6.6 バックアウト・キューの構成

- 10.6.6.1 前提条件

- 10.6.6.2 SOAコンポジットの設計

- 10.6.6.3 インバウンド・アダプタ・サービスの作成

- 10.6.6.4 アウトバウンド・アダプタ・サービスの作成

- 10.6.6.5 サービスとアクティビティのワイヤリング

- 10.6.6.6 JDeveloperを使用したデプロイ

- 10.6.6.7 Fusion Middleware Controlコンソールを使用した監視

- 10.6.7 CCDTのユース・ケース

- 10.6.7.1 キュー・マネージャのプロパティおよびCCDTの構成の例

- 10.6.7.2 ConnectionFactory JNDIの構成

- 10.6.7.3 CCDTurlの構成

- 10.6.7.4 QueueManagerNameの構成

- 10.6.8 単一または複数のRFH2ルールの読取りおよびヘッダー・バージョン2ヘッダーの書式設定

- 10.6.8.1 両側の複数のRFH2ヘッダーを含むインバウンドおよびアウトバウンド

- 10.6.8.1.1 SOAコンポジットの設計

- 10.6.8.1.2 インバウンド・アダプタ・サービスの作成

- 10.6.8.1.3 アウトバウンド・アダプタ・サービスの作成

- 10.6.8.1.4 サービスとアクティビティのワイヤリング

- 10.6.8.1.5 JDeveloperを使用したデプロイ

- 10.6.8.2 複数のRFH2ヘッダーを含むアウトバウンド・デキュー

- 10.6.8.2.1 SOAコンポジットの設計

- 10.6.8.2.2 アウトバウンド・デキュー・アダプタ・サービスの作成

- 10.6.8.2.3 サービスとアクティビティのワイヤリング

- 10.6.8.2.4 JDeveloperを使用したデプロイ

- 10.6.9 メッセージを添付ファイルとして処理

- 10.6.9.1 SOAコンポジットの設計

- 10.6.9.2 インバウンド・アダプタ・サービスの作成

- 10.6.9.3 アウトバウンド・アダプタ・サービスの作成

- 10.6.9.4 サービスとアクティビティのワイヤリング

- 10.6.9.5 JDeveloperを使用したデプロイ

11 Oracle JCA Adapter for UMS

- 11.1 UMSおよびUMSアダプタの概念

- 11.1.1 ユーザー・メッセージング・サービス

- 11.1.2 Oracle UMSアダプタ

- 11.2 Oracle User Messaging Service機能

- 11.2.1 UMSアダプタのメッセージの概要

- 11.2.1.1 カスタムJavaコールアウト

- 11.2.1.1.1 カスタムJavaコールアウトのユース・ケース

- 11.2.1.1.2 カスタム・コールアウト・ファシリティの使用

- 11.2.2 トランザクション・サポート

- 11.2.2.1 インバウンド・エラー処理

- 11.2.2.2 アウトバウンド・エラー処理

- 11.2.2.2.1 ステータス・レポートでの失敗した送信通知の再試行メカニズム

- 11.2.2.2.2 クラスタでのインバウンド受信通知(ポーリングまたはリスナーを使用)

- 11.2.2.2.3 UMSアダプタのプロパティおよびMIMEタイプの構成

- 11.2.2.2.4 固有のヘッダー

- 11.2.2.3 電子メールの添付ファイル

- 11.2.2.4 メールの添付ファイルの処理

- 11.2.2.4.1 BPEL内の添付ファイルと関連付けられたMIME情報の取得

- 11.2.2.4.2 BPEL内の複数の添付ファイルに対するMIME情報の設定

- 11.2.2.5 UMSアダプタのインバウンド操作およびアウトバウンド操作

- 11.2.2.5.1 Oracle UMSアダプタのインバウンド通知の受信の概念

- 11.2.2.5.2 Oracle UMSのアウトバウンド通知の送信の概念

- 11.2.2.5.3 メッセージIDのリプライ・リクエストとしての受信

- 11.2.3 Oracle UMSアダプタの構成

- 11.2.3.1 UMSアダプタの電子メール・ドライバの構成 - アウトバウンド接続性

- 11.2.3.2 UMSアダプタの電子メール・ドライバの構成 - インバウンド接続性

- 11.2.3.3 ユーザー・メッセージングXMPPドライバの構成

- 11.2.3.4 ユーザー・メッセージングSMPPドライバの構成

- 11.2.3.5 ファイアウォール・トラバースのためのHTTPプロキシの構成

- 11.2.3.6 インバウンド接続性のためのアダプタ・サービスおよびBPELプロセスの設計

- 11.2.3.7 アウトバウンド接続性のためのアダプタ・サービスおよびBPELプロセスの設計

12 Oracle JCA Adapter for LDAP

- 12.1 LDAPの概念

- 12.1.1 LDAPのエントリ、属性および値

- 12.1.2 LDAPのディレクトリ構造

- 12.1.3 識別名と相対識別名

- 12.1.4 LDAPサービスおよびサービス・クライアント

- 12.1.5 リフェラル

- 12.1.6 エイリアス

- 12.2 LDAPアダプタの構成

- 12.2.1 コントロール

- 12.2.1.1 リクエスト・コントロールの形式

- 12.2.1.2 LDAPコントロールの制限事項

- 12.2.1.3 設計時ウィザードでのデフォルト以外のコントロールの構成

- 12.2.1.3.1 コントロールの可用性

- 12.2.2 LDAPブラウザ

- 12.2.2.1 属性ビューア

- 12.2.2.1.1 折りたたみ

- 12.2.2.1.2 検索

- 12.3 Oracle LDAPアダプタの機能

- 12.3.1 LDAPアダプタの構成

- 12.3.2 LDAPアダプタのJNDI接続プール・プロパティ

- 12.3.3 アウトバウンド操作

- 12.3.3.1 追加操作

- 12.3.3.2 削除操作

- 12.3.3.3 変更操作

- 12.3.3.4 DNの変更操作

- 12.3.3.5 比較操作

- 12.3.3.6 検索操作

- 12.3.3.7 DSML操作

- 12.3.4 インバウンドLDAPアダプタの機能

- 12.3.4.1 LDAPアダプタのエントリ変更通知

- 12.3.4.1.1 LDAPアダプタのエントリ変更通知構成ウィザードのフロー

- 12.3.4.2 LDAPアダプタの変更ログ通知

- 12.3.4.2.1 LDAPアダプタ構成ウィザードの変更ログ通知のフロー

- 12.3.4.3 エントリ変更通知のエラー条件

- 12.3.5 ロギング

- 12.3.6 セキュリティ

- 12.3.6.1 アウトバウンド資格証明マッピングの作成

- 12.3.7 SSLを介したLDAP

- 12.3.8 ペイロード・サイズしきい値

- 12.3.9 高可用性

- 12.3.10 LDAPアダプタの例外処理

- 12.3.10.1 インバウンド再試行可能例外

- 12.3.10.2 インバウンド再試行不可例外

- 12.3.10.3 アウトバウンド再試行可能例外

- 12.3.10.4 アウトバウンド再試行不可例外

- 12.4 LDAPアダプタのサンプル

13 Oracle JCA Adapter for Microsoft Message Queueing

- 13.1 Oracle JCA Adapter for MSMQの概念と機能

- 13.1.1 MSMQの用語

- 13.1.1.1 jCOMおよびMSMQアダプタ

- 13.1.1.1.1 バックグラウンド

- 13.1.1.1.2 MSMQアダプタの影響

- 13.1.1.2 セキュリティ

- 13.1.1.2.1 コンポーネント管理のサインオン

- 13.1.1.2.2 コンテナ管理のサインオン

- 13.1.1.3 ロギングおよび診断能力

- 13.1.1.4 MSMQアダプタおよび高可用性

- 13.1.2 Windows Server 2008でのMSMQの設定

- 13.1.3 Oracle Weblogic Server for COMの設定

- 13.1.3.1 トランザクション管理およびエラー処理

- 13.1.3.1.1 トランザクション管理

- 13.1.3.1.2 フォルト処理

- 13.1.3.1.3 アウトバウンド再試行可能エラー

- 13.1.3.1.4 アウトバウンド再試行不可エラー

- 13.1.4 MSMQアダプタの機能

- 13.1.5 サポートされるMSMQプロパティ

- 13.2 MSMQアダプタ構成ウィザードのフロー

- 13.2.1 エンキュー操作の作成

- 13.2.2 サンプルのMSMQアダプタ・コネクション・ファクトリ・プロパティ

- 13.2.3 MSMQアダプタ設計時アーティファクト

- 13.2.3.1 MSMQエンキュー操作のサンプルJCAファイル

- 13.2.3.2 MSMQデキュー操作のサンプルJCA

- 13.2.3.3 設計時WSDLアーティファクト

- 13.2.3.3.1 MSMQエンキュー操作のWSDL

- 13.2.3.3.2 MSMQアダプタのデキュー操作のWSDL

- 13.3 MSMQの使用例

- 13.3.1 パブリック・キューでのメッセージのエンキュー/デキュー

- 13.3.1.1 SOAコンポジットの設計

- 13.3.1.2 インバウンドOracle MSMQアダプタ・サービスの作成

- 13.3.1.3 アウトバウンドOracle MSMQアダプタ・サービスの作成

- 13.3.1.4 サービスとアクティビティのワイヤリング

- 13.3.1.5 receiveアクティビティの追加

- 13.3.1.6 invokeアクティビティの追加

- 13.3.1.7 assignアクティビティの追加

- 13.3.2 プライベート・キューでのメッセージのエンキュー/デキュー

- 13.3.2.1 SOAコンポジットの設計

- 13.3.2.2 インバウンドOracle MSMQアダプタ・サービスの作成

- 13.3.2.3 アウトバウンドOracle MSMQアダプタ・サービスの作成

- 13.3.2.4 サービスとアクティビティのワイヤリング

- 13.3.2.5 receiveアクティビティの追加

- 13.3.2.6 invokeアクティビティの追加

- 13.3.2.7 assignアクティビティの追加

- 13.3.3 配信リストへのメッセージのエンキュー

- 13.3.3.1 SOAコンポジットの設計

- 13.3.3.2 インバウンドOracleファイル・アダプタ・サービスの作成

- 13.3.3.3 アウトバウンドOracle MSMQアダプタ・サービスの作成

- 13.3.3.4 サービスとアクティビティのワイヤリング

- 13.3.3.5 receiveアクティビティの追加

- 13.3.3.6 invokeアクティビティの追加

- 13.3.3.7 assignアクティビティの追加

14 Oracle JCA Adapter for Coherence

- 14.1 Oracle CoherenceおよびOracle JCA Coherenceアダプタの概念

- 14.1.1 Coherenceキャッシュ

- 14.1.2 コヒーレンス・アダプタ

- 14.1.3 互換性

- 14.1.4 Oracle Coherenceアダプタの機能

- 14.1.4.1 基本的な使用例

- 14.1.4.1.1 リモート・クラスタへのコヒーレンス・アダプタ接続の構成

- 14.1.4.1.2 ローカル・クラスタへのコヒーレンス・アダプタ接続

- 14.2 コヒーレンス・アダプタの構成

- 14.3 Coherenceキャッシュ内のアイテムの問合せ

- 14.4 「XML」が選択されている場合のPut操作、Get操作および問合せ操作のメッセージの定義

- 14.4.1 「POJO」が選択されている場合のPut操作、Get操作および問合せ操作のメッセージの定義

- 14.5 コヒーレンス・アダプタのファイルおよびアーティファクト

- 14.5.1 JCAファイル

- 14.5.2 Put操作のWSDL

- 14.5.3 バインド変数が含まれるフィルタ式による削除のWSDL

- 14.5.4 Get操作のWSDL

- 14.5.5 バインド変数が含まれるフィルタ式による問合せのWSDL

- 14.6 コヒーレンス・アダプタ使用のヒント

15 Oracle JCA Adapter for JDE Edwards World

- 15.1 JD Edwards WorldシステムとJDE Edwards Worldアダプタの概念

- 15.2 機能

- 15.3 JD Edwards Worldアダプタの構成

- 15.3.1 JDEdwards Worldアダプタの接続プーリングの構成

- 15.4 JD Edwards Worldアダプタ構成ウィザードのフロー: 挿入操作

- 15.5 JD Edwards Worldアダプタ: 選択操作

- 15.5.1 構成ファイル

- 15.5.1.1 挿入操作のWSDLおよび.jcaファイルの例

- 15.5.1.2 選択操作のWSDLおよび.jcaファイルの例

16 Oracle JCA Adapter for Siebel

- 16.1 Oracle JCA Adapter for Siebelの概要

- 16.2 Oracle JCA Adapter for Siebelの概念

- 16.3 Oracle JCA Adapter for Siebel機能

- 16.4 Oracle JCA Adapter for Siebelのデザイン・タイムおよびランタイム機能

- 16.5 Oracle JCA Adapter for Siebelの構成

- 16.5.1 Oracle JCA Adapter for Siebel構成ウィザードの接続パラメータ

- 16.5.2 Oracle JCA Adapter for Siebel構成ウィザードのフロー

- 16.6 JDeveloperを使用したデプロイ

- 16.7 Oracle JCA Adapter for Siebelのアクティブ化

- 16.8 Oracle JCA Adapter for Siebelの接続プーリングの構成

- 16.9 Oracle JCA Adapter for Siebelアーティファクト

17 Oracle JCAアダプタ・チューニング・ガイド

- 17.1 Oracle JCAアダプタ・フレームワークのパフォーマンスおよびチューニング

- 17.1.1 payloadSizeThreshold

- 17.1.1.1 DOMまたはスケーラブルなDOM

- 17.1.1.2 同期消費

- 17.1.1.3 payloadSizeThresholdが適切にチューニングされていない場合の症状

- 17.1.1.4 チューニングのデメリット

- 17.1.1.5 症状が発生した場合の推奨事項

- 17.1.2 minimumDelayBetweenMessages

- 17.1.2.1 適切にチューニングされていない場合の症状

- 17.1.2.2 チューニングのデメリット

- 17.1.2.3 症状が発生した場合の推奨事項

- 17.2 JMSアダプタ

- 17.2.1 adapter.jms.receive.threads

- 17.2.1.1 適切にチューニングされていない場合の症状

- 17.2.1.2 チューニングのデメリット

- 17.2.1.3 症状が発生した場合の推奨事項

- 17.2.2 EnableStreaming

- 17.2.2.1 適切にチューニングされていない場合の症状

- 17.2.2.2 チューニングのデメリット

- 17.2.2.3 症状が発生した場合の推奨事項

- 17.2.3 adapter.jms.receive.timeout

- 17.2.3.1 適切にチューニングされていない場合の症状

- 17.2.3.2 チューニングのデメリット

- 17.2.3.3 症状が発生した場合の推奨事項

- 17.3 AQアダプタ

- 17.3.1 adapter.aq.dequeue.threads

- 17.3.1.1 適切にチューニングされていない場合の症状

- 17.3.1.2 チューニングのデメリット

- 17.3.1.3 症状が発生した場合の推奨事項

- 17.3.2 EnableStreaming

- 17.3.2.1 適切にチューニングされていない場合の症状

- 17.3.2.2 チューニングのデメリット

- 17.3.2.3 症状が発生した場合の推奨事項

- 17.3.3 DequeueTimeOut

- 17.3.3.1 適切にチューニングされていない場合の症状

- 17.3.3.2 チューニングのデメリット

- 17.3.3.3 症状が発生した場合の推奨事項

- 17.4 ファイル/FTPアダプタ

- 17.4.1 スレッド数およびシングル・スレッド・モデル

- 17.4.1.1 適切にチューニングされていない場合の症状

- 17.4.1.2 チューニングのデメリット

- 17.4.1.3 症状が発生した場合の推奨事項

- 17.4.2 maxRaiseSize

- 17.4.2.1 適切にチューニングされていない場合の症状

- 17.4.2.2 チューニングのデメリット

- 17.4.2.3 症状が発生した場合の推奨事項

- 17.4.3 PublishSize

- 17.4.3.1 適切にチューニングされていない場合の症状

- 17.4.3.2 チューニングのデメリット

- 17.4.3.3 症状が発生した場合の推奨事項

- 17.4.4 ChunkSize

- 17.4.4.1 適切にチューニングされていない場合の症状

- 17.4.4.2 チューニングのデメリット

- 17.4.4.3 症状が発生した場合の推奨事項

- 17.5 データベース・アダプタ

- 17.5.1 索引の使用

- 17.5.1.1 適切にチューニングされていない場合の症状

- 17.5.1.2 チューニングのデメリット

- 17.5.1.3 症状が発生した場合の推奨事項

- 17.5.2 MaxTransactionSizeおよびMaxRaiseSize

- 17.5.2.1 適切にチューニングされていない場合の症状

- 17.5.2.2 チューニングのデメリット

- 17.5.2.3 症状が発生した場合の推奨事項

- 17.5.3 RowsPerPollingIntervalを使用しない

- 17.5.3.1 適切にチューニングされていない場合の症状

- 17.5.3.2 チューニングのデメリット

- 17.5.3.3 症状が発生した場合の推奨事項

- 17.5.4 ロッキングのスキップの有効化(usesSkipLockingパラメータの使用)

- 17.5.4.1 適切にチューニングされていない場合の症状

- 17.5.4.2 チューニングのデメリット

- 17.5.4.3 症状が発生した場合の推奨事項

- 17.5.5 NumberOfThreadsの増加

- 17.5.5.1 適切にチューニングされていない場合の症状

- 17.5.5.2 チューニングのデメリット

- 17.5.5.3 症状が発生した場合の推奨事項

A Oracle JCAアダプタのプロパティ

- A.1 Oracleファイル/FTPアダプタのプロパティ

- A.2 プロパティ

- A.3 プロパティ

- A.4 プロパティ

- A.5 プロパティ

- A.6 Oracle MQ Seriesアダプタのプロパティ

- A.7 LDAPアダプタのプロパティ

- A.8 コヒーレンス・アダプタのプロパティ

- A.9 MSMQ JCAアダプタのプロパティ

- A.10 UMS JCAアダプタのプロパティ

- A.11 Oracle JCAアダプタの汎用プロパティ

- A.12 Oracleアダプタの汎用バインディング・プロパティ

B Oracle JCAアダプタ・バルブ

- B.1 単純な解凍バルブ

- B.2 ステージング・ファイルを使用する単純な復号化バルブ

- B.3 アウトバウンド・ファイルの暗号化用バルブ

- B.4 複数ファイルの処理用の解凍バルブ

C Oracle MQ Seriesアダプタのサポート対象エンコーディング

- C.1 Oracle MQ Seriesアダプタのエンコーディング

- C.1.1 その他の標準Javaエンコーディングのサポートの追加

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

これらのアダプタを使用するすべてのユーザーを対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middleware 12c (12.1.3)のドキュメント・セットにある次のドキュメントを参照してください。

- Oracle WebLogic Serverのリソース・アダプタの開発

- Oracle® Fusion Middleware Oracle E-Business Suite Adapterユーザーズ・ガイド

- 『Oracle SOA Suiteを使用したSOAアプリケーションの開発』

- 『Oracle Fusion Middlewareの管理』

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

- Oracle Service Busの管理

- Oracle® Application Serverレガシー・アダプタ・インストレーション・ガイド

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドでのリリース12.2.1の新機能

ここでは、このガイドで説明するOracle Integration Adaptersの新しい機能と変更された機能について説明し、追加情報の参照先を示します。

次の表に、追加または更新された内容を示します。既知の問題のリスト(リリース・ノート)は、「Oracle SOA製品の既知の問題」を参照してください。

表1 このガイドでのリリース12.2.1の新機能

内容

変更内容

Oracle JCA Adapter for Siebel

新しいアダプタOracle JCA Adapter for Siebelの章を追加しました

第I部 概要と説明

第I部は、次の章で構成されています。

- Oracle JCAアダプタの概要

- アダプタ・フレームワーク

- アダプタとOracle Application Serverコンポーネントの統合

- Oracle JCA Adapter for Files/FTP

- Oracle JCA Adapter for Sockets

- ネイティブ・フォーマット・ビルダー・ウィザード

1 Oracle JCAアダプタの概要

この章では、ビジネス・アプリケーションの統合を可能にし、異種アプリケーション間の相互通信に必要な堅牢、軽量で高度にスケーラブルな標準ベースの統合フレームワークを提供する、Oracle JCA準拠アダプタの概要を示します。この章では、今日のビジネス・アプリケーション処理の中におけるJCAアダプタのコンテキストについて説明します。

ビジネス・プロセスの最適化に対するニーズの高まりに伴い、既存のバックエンド・アプリケーションとの効果的な統合が成功への鍵となっています。ビジネス・プロセスを最適化するために、JCA 1.5コンポーネント・リソース・アダプタを使用してアプリケーションを統合できます。各アダプタでは堅牢、軽量で高度にスケーラブルな標準ベースの統合フレームワークがサポートされており、異種アプリケーション相互の通信を可能にします。たとえば、アダプタにより、パッケージ・アプリケーション、レガシー・アプリケーション、データベースおよびWebサービスを統合できます。Oracle JCAアダプタを使用すると、様々なベンダーから異なるテクノロジに基づいて提供されて異なるプラットフォームで動作する異種アプリケーションを統合することで、相互運用性を保証できます。

注意:

アダプタのシステム要件に関連する証明書マトリックスは、Oracle Technology Networkのアダプタのホームページ(http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)にあります

現在のアダプタのリストについては、http://www.oracle.com/technetwork/middleware/adapters/overview/index-083423.htmlを参照してください

この章の内容は次のとおりです。

- Oracle JCAアダプタの機能

- Oracle JCAアダプタのタイプ

- Oracle JCAアダプタ・サービスのタイプ

1.1 Oracle JCAアダプタの機能

このトピックでは、Oracle JCAアダプタの機能について説明します。

Oracle JCAアダプタのメリットは、次のとおりです。

- 複雑なビジネス・プロセスを統合するための接続性プラットフォームの提供: アダプタにより、メインフレームおよびレガシー・アプリケーションがEnterprise Resource Planning (ERP)システム、カスタマ・リレーションシップ・マネジメント(CRM)システム、データベース・システムおよびメッセージ・システムと統合されます。オラクル社は、SAPやSiebelなどの各種パッケージ・アプリケーションおよびデータベースを接続できるようにアダプタを提供しています。また、ミドルウェア・メッセージ・システム(MQSeriesやOracle Advanced Queuingなど)とレガシー・アプリケーション(CICSおよびTuxedoなど)も、アダプタにより統合されて完全なソリューションを提供します。

- オープン・スタンダードのサポート: アダプタは、J2EE Connector Architecture (JCA)バージョン1.5、eXtensible Markup Language (XML)およびWeb Service Definition Language (WSDL)など、一連の標準に基づいています。標準のサポートによりユーザーの学習曲線が短縮され、単一ベンダーに依存する必要がなくなります。

- サービス・コンポーネント・アーキテクチャ(SCA)アセンブリ・モデル: コンポジット・アプリケーションを形成するためのサービス詳細とその相互依存関係を提供します。SCAにより、ビジネス・ロジックを、すべてのSCA準拠アプリケーションに容易に統合できる再利用可能なサービス・コンポーネントとして表現できます。このようなアプリケーションはSOAコンポジット・アプリケーションと呼ばれます。SCA標準の仕様は、Organization for the Advancement of Structured Information Standards (OASIS)により保守管理されています。

- サービス指向アーキテクチャ(SOA)の実装: オープン・スタンダードのサポートにより、アダプタでは疎結合、柔軟性および拡張性を容易にするSOAを実装できます。

- ネイティブAPIの使用: アダプタではバックエンド・システムとの複数のインタフェース方法がサポートされ、各種のデプロイメント・オプションが用意されています。アダプタではバックエンド・アプリケーションとの通信にネイティブAPIが使用され、ネイティブ・データからクライアントに提供する標準XMLへの変換にも使用されます。

- データのモデル化: アダプタでは、設計時に構成したアダプタ・メタデータに基づいてネイティブAPIと標準XMLの間の変換が実行されます。アダプタ構成は設計時に定義され、ランタイム・コンポーネントにより使用されます。

- リアルタイムの双方向接続の促進: アダプタにより、各種バックエンド・システムとの双方向通信が提供されます。これには、バックエンド・システムへのリクエストの送信とレスポンスの受信が含まれます。リアルタイム・イベント通知サービスも、アダプタによりサポートされています。このサービスにより、バックエンド・データの作成、削除および更新について、成功したバックエンド・トランザクションに関連付けられたバックエンド・イベントに関する通知が送信されます。この2方向接続性により、迅速、柔軟かつ効果的な統合と、それに伴うコストの削減が保証されます。

- 可用性の最大化: Oracle JCAアダプタはJ2CA 1.5仕様に基づいています。したがって、アダプタは基礎となるOracle Application Serverプラットフォームのスケーラビリティと高度な可用性を完全に利用できます。
詳細は、『Oracle WebLogic Serverリソース・アダプタの開発』を参照してください。

- 使用しやすい設計時ツールの提供: アダプタで使用される設計時ツールにはGraphical User Interface (GUI)が用意されており、迅速な実装およびデプロイメントのためにアダプタを構成して管理できます。さらに、ツールを使用してバックエンド・スキーマを参照、ダウンロードおよび構成できます。

- Oracle Application Serverコンポーネントとのシームレスな統合のサポート: アダプタによりOracle Fusion Middlewareが統合されます。アダプタによりOracle Fusion MiddlewareプラットフォームのJCAバインディング・コンポーネントが統合されます。これにより、他のサービス・エンジンおよびバインディング・コンポーネントがシームレスに統合されます。

1.2 Oracle JCAアダプタのタイプ

このトピックでは、Oracle JCAアダプタのタイプに関する情報を提供します。

Oracle JCAアダプタには、次のものがあります。

- Oracleテクノロジ・アダプタ

- レガシー・アダプタ

- パッケージ・アプリケーション・アダプタ

- Oracle E-Business Suiteアダプタ

図1-1 に、様々なタイプのアダプタを示します。

図1-1 Oracle JCAアダプタのタイプ

1.2.1 Oracleテクノロジ・アダプタ

Oracleテクノロジ・アダプタによって、Oracle Application ServerおよびOracle Fusion Middlewareコンポーネント(Oracle BPEL Process Manager (Oracle BPEL PM)やOracle Mediatorコンポーネントなど)が、ファイルシステム、FTPサーバー、データベース・キュー(アドバンスト・キュー、すなわちAQ)、Java Message Services (JMS)、データベース表およびメッセージ・キュー(MQ Series)と統合されます。

このタイプのアダプタには、次のものがあります。

- Oracle JCA Adapter for Files/FTP

- Oracle JCA Adapter for Sockets

- Oracle JCA Adapter for AQ

- Oracle JCA Adapter for JMS

- Oracle JCA Adapter for Database

- Oracle JCA Adapter for MQ Series

- Oracle JCA Adapter for UMS

- Oracle JCA Adapter for LDAP

- Oracle JCA Adapter for Microsoft Message Queueing

- Oracle JCA Adapter for Coherence

- Oracle JCA Adapter for JDE Edwards World

- Oracle JCA Adapter for Siebel

Oracleテクノロジ・アダプタは、Oracle Fusion Middlewareの一部としてインストールされます。

この項には次のトピックが含まれます:

- アーキテクチャ

- 設計時コンポーネント

- ランタイム・コンポーネント

- デプロイメント

詳細は、次を参照してください。

- このマニュアルの以降の章

- Oracle WebLogic Serverのリソース・アダプタの開発

- 『Oracle SOA Suiteを使用したSOAアプリケーションの開発』

- 『Oracle Fusion Middlewareの管理』

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

1.2.1.1 アーキテクチャ

Oracleテクノロジ・アダプタはJ2EE Connector Architecture (JCA) 1.5標準に基づいており、Oracle Fusion Middlewareと同じOracle WebLogic Serverにリソース・アダプタとしてデプロイされます。Oracle Adapter for Oracle Applicationsは、Oracleテクノロジ・アダプタと同じアーキテクチャで構成されています。図1-2 に、Oracleテクノロジ・アダプタのアーキテクチャを示します。

図1-2 Oracleテクノロジ・アダプタのアーキテクチャ

1.2.1.2 設計時コンポーネント

設計時に、Oracleテクノロジ・アダプタはOracle JDeveloper (JDeveloper)を使用してアダプタ・メタデータを生成します。バインディング構成ファイルはJ2CA中心のXMLマークアップから構成されます。J2CAバインディング構成ファイルは、J2CA 1.5リソース・アダプタをOracle Fusion Middlewareとシームレスに統合するためにJCAバインディング・コンポーネントで使用されます。

Oracleテクノロジ・アダプタとOracle Fusion Middlewareの統合の詳細は、「アダプタとOracle Fusion Middlewareの統合」を参照してください。

JDeveloperでは、スクリーン・リーダーのサポート、スクリーン拡大鏡、キーボード操作用の標準ショートカット・キーなどのアクセシビリティ・オプションが提供されています。フォントのサイズや色、オブジェクトの色や形などを変えて、判読性を高めるためにJDeveloperをカスタマイズすることもできます。JDeveloperのアクセシビリティを構成する方法の詳細および手順は、『Oracle JDeveloperによるアプリケーションの開発』のOracle JDeveloperのアクセシビリティについての情報に関する項を参照してください。

Oracle JCA Adapter for Database用のWSDLおよびバインディング構成ファイルの生成の例:

JDeveloperを使用して、構成できます。このアダプタを使用すると、データ操作の実行、ストアド・プロシージャやファンクションのコールおよびデータベース・イベントのリアルタイムでのパブリッシュが容易になります。アダプタ定義を構成するには、「コンポーネント」ウィンドウから、「データベース・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。

図1-3 に、「表のインポート」ウィンドウで参照してアダプタに必要な表を選択する方法を示します。

図1-3 必要な表の参照

図1-4に、WSDL設定を指定する方法を示します。

図1-4 WSDL設定の指定

次に、データベース接続を確立し、操作タイプを選択し、必要な表を選択する必要があります。ランタイム接続パラメータはweblogic-ra.xmlファイル内で指定され、設計時に指定するJava Naming and Directory Interface (JNDI)名にリンクされます。図1-5 に、新規データベース接続の作成方法を示します。

図1-5 新規データベース接続の作成

最後に、図1-6に示すように、JDeveloperによりJ2CAバインディングを使用してWSDLファイルおよびバインディング構成ファイルが生成されます。

図1-6 JCAファイルの構造

1.2.1.3 ランタイム・コンポーネント

Oracleテクノロジ・アダプタのランタイム・コンポーネントは、特定のバックエンド・アプリケーション用のJ2CA 1.5リソース・アダプタです。Oracleテクノロジ・アダプタは、Oracle WebLogic ServerのJ2CAコンテナにデプロイされます。Oracle Fusion Middlewareは、JCAバインディング・コンポーネントを介してJ2CA 1.5アダプタと統合され、Webサービス・メッセージがJ2CA相互作用との間で変換されます。

Oracle Fusion Middlewareでは、JCAバインディング・コンポーネントを使用してリクエスト-レスポンス・サービス(J2CAアウトバウンド相互作用)がSCAコンポジット参照と統合され、アダプタ・イベントがSCAコンポジット・サービスにパブリッシュされます。

Oracleテクノロジ・アダプタとOracle Fusion Middlewareの統合の詳細は、「アダプタとOracle Application Serverコンポーネントの統合」を参照してください。

1.2.1.3.1 Fusion Middleware Controlのアクセシビリティおよびテクノロジ・アダプタ

Fusion Middleware Controlによって、アプリケーションを監視および管理するページにアクセシビリティ・オプションが提供されます。Fusion Middleware Controlは、スクリーン・リーダーをサポートしており、キーボード・ナビゲーションをサポートするための標準のショートカット・キーを提供しています。読みやすくするために、コンソール・ページを高コントラストで表示したり、大きなフォントで表示したりすることもできます。Fusion Middleware Controlにおけるアクセシビリティの構成の詳細と手順は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareのアクセシビリティ・オプションの使用に関する項を参照してください。

1.2.1.4 デプロイメント

Oracleテクノロジ・アダプタは、インストール時にOracle Fusion Middlewareと同じOracle WebServerコンテナにJ2CA 1.5リソース・アダプタとしてデプロイされます。Oracleテクノロジ・アダプタはJ2CA 1.5リソース・アダプタとして物理的にデプロイされますが、論理的にデプロイするには、設計時にJDeveloperを使用してweblogic-ra.xmlファイルを編集し、J2CA 1.5リソース・アダプタ用のコネクション・ファクトリ・エントリを作成する必要があります。JDeveloperを使用してJNDI名を指定します。JNDI名は、コンポジットがOracle WebLogic Serverにデプロイされる際に使用される接続のプレースホルダとして機能します。このプレースホルダにより、開発とその後の本番に異なるデータベースを使用できます。ただし、論理的なデプロイ変更を有効にする場合(つまり、新規のアウトバウンド接続を作成する場合にのみ)、WebLogic Serverコンテナ・プロセスの更新が必要になります。既存のJNDIのアウトバウンド接続プロパティを更新する場合は、Oracle WebLogic Serverの再起動が必要です。既存のJNDIのアウトバウンド接続プロパティを更新するときにサーバーの再起動を回避するには、「アダプタ・コネクション・ファクトリの追加または更新」を参照してください。

1.2.2 レガシー・アダプタ

レガシー・アダプタにより、レガシー通信プロトコルを使用して、レガシーおよびメインフレーム・アプリケーションと統合されます。

このタイプのアダプタには、次のものがあります。

- OracleAS Adapter for Tuxedo

- OracleAS Adapter for CICS

- OracleAS Adapter for VSAM

- OracleAS Adapter for IMS/TM

- OracleAS Adapter for IMS/DB

レガシー・アダプタは、OracleAS Adapters CDに収録されています。

この項には次のトピックが含まれます:

- アーキテクチャ

- 設計時コンポーネント

- ランタイム・コンポーネント

- デプロイメント

詳細は、次を参照してください。

- Oracle WebLogic Serverのリソース・アダプタの開発

- 『Oracle SOA Suiteを使用したSOAアプリケーションの開発』

- 『Oracle Fusion Middlewareの管理』

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

1.2.2.1 アーキテクチャ

レガシー・アダプタのアーキテクチャには、次のコンポーネントが含まれています。

- Oracle Connect

- Oracle Studio

- J2CAアダプタ

図1-7 に、レガシー・アダプタのアーキテクチャを示します。

図1-7 レガシー・アダプタのアーキテクチャ

チェンジ・データ・キャプチャ(CDC)アダプタのアーキテクチャも同じです。

1.2.2.1.1 Oracle Connect

Oracle Connectは、レガシーおよびメインフレーム・プラットフォームに常駐するコンポーネントです。メインフレーム・アプリケーションおよびデータ・ストアとの通信に使用するネイティブ・アダプタで構成されています。Oracle Connectを構成するコンポーネントは、次のとおりです。

- サーバー・プロセス

- ネイティブ・アダプタ

- デーモン

- リポジトリ

サーバー・プロセス: Oracle Connectは、クライアント・リクエストを処理する複数のサーバーで構成されています。

ネイティブ・アダプタ: Oracle Connectは、TuxedoおよびIMS-TMトランザクション・システムと通信するための各種埋込みネイティブ・アダプタと、VSAMやIMS-DBなどのメインフレーム・システム上にある各種データベースおよびファイルシステムと通信するためのデータベース・ドライバで構成されています。ネイティブ・アダプタにより、レガシーCOBOLアプリケーション・データなどのアプリケーション構造がXMLとの間で変換されます。メインフレーム・データと標準XMLデータの間の正確なマッピングには、XSDスキーマが使用されます。

デーモン: デーモンは、複数のサーバー構成を管理して保守するRPCベースのリスナーです。これはOracle Connectを実行中のすべてのコンピュータ上で動作し、ユーザー認証と認可、接続の割当ておよびサーバー・プロセスの管理を処理します。

クライアントが接続をリクエストすると、デーモンがこの接続を処理するためのサーバー・プロセスを割り当てます。割り当てられるサーバー・プロセスは、新規プロセスの場合と実行中のプロセスの場合があります。クライアント・セッションとサーバー・プロセス間の以降の通信は直接行われ、デーモンは関与しません。ただし、接続の終了時にサーバー・プロセスが停止されるか、別のクライアントにより使用中の場合は、デーモンに通知されます。

デーモンでは、ワークスペースと呼ばれる複数のサーバー構成がサポートされています。各ワークスペースにより、アクセス可能なデータソース、アプリケーション、環境設定、セキュリティ要件およびサーバー割当てルールが定義されます。デーモンによりクライアントが認証され、特定のサーバー・ワークスペース内のサーバー・プロセスに対するリクエストが認可され、必要なサーバーがクライアントに提供されます。デーモンによるサーバーの割当ては、クライアントが使用しているワークスペースに基づきます。そのため、クライアントは1つのワークスペースを使用してデータソースにアクセスできます。その場合は、既存のサーバー・プールからサーバー・プロセスが割り当てられます。クライアントが別のワークスペースを使用してデータソースにアクセスすることもできます。その場合は、クライアント・リクエストごとに新規サーバー・プロセスが割り当てられます。フェイルセーフ・メカニズムにより、可用性を高めるためのスタンバイとして機能する代替デーモンを指定できます。

リポジトリ: Oracle Connectでは、XMLベースのスキーマおよび構成情報を格納するためのリポジトリがサポートされています。リポジトリはOracle Connectインスタンスごとに1つ存在します。リポジトリには、次の情報が格納されます。

- Oracle Connect構成設定(クライアント/サーバーの通信を制御するデーモン設定など)

- ユーザー・プロファイル(複数のバックエンド・アプリケーションおよびデータソースへのシングル・サインオンを有効化)

- 各アダプタのアダプタ・メタデータ(アダプタのリクエスト-レスポンスおよびイベント・サービスなど)

1.2.2.1.2 Oracle Studio

Oracle Studioは、メインフレーム用OracleAS Adapterを構成するための設計時ツールです。これにより、ネイティブ・アダプタのサービス、イベントおよび接続情報を構成できます。構成情報は、レガシーまたはメインフレーム・アプリケーションのOracle Connectリポジトリに格納されます。さらに、Oracle Connectの管理と監視にも使用できます。Oracle Studioを使用できるのは、Windowsプラットフォームの場合のみです。Oracle Studioは、Eclipse GUIフレームワークに基づいています。

1.2.2.1.3 J2CAアダプタ

J2EE Connector Architecture (J2CA)アダプタにより、WebLogic Serverアプリケーション・クライアント・リクエストがOracle Connectアプリケーションに転送されます。Oracle Connectはメインフレーム・アプリケーションと通信し、レスポンスをJ2CAアダプタに転送します。レスポンスにはトランザクション・データが含まれていたり、リクエストでエラーが発生した場合は例外データが含まれている場合もあります。Oracle Fusion Middlewareは、J2CAレガシー・アダプタを介してOracle Connectと統合されます。

1.2.2.2 設計時コンポーネント

設計時にレガシー・アダプタを構成するには、図1-8 に示すようにOracle Studioを使用します。

図1-8 Oracle Studio

OraleAS Adapter for Tuxedoの構成の例:

図1-9 および図1-10 に示すように、Oracle Studioを使用してOracleAS Adapter for Tuxedoを構成できます。

図1-9 OracleAS Adapter for Tuxedoの構成

図1-10 OracleAS Adapter for Tuxedoの相互作用タイプの選択

1.2.2.3 ランタイム・コンポーネント

実行時には、設計時に生成されたWSDLファイルが統合コンポーネントにより使用されます。たとえば、Oracle Fusion Middlewareでは、JCAバインディング・コンポーネントを使用してリクエスト-レスポンス・サービス(J2CAアウトバウンド相互作用)がBPELのinvokeアクティビティと統合され、イベントがBPELプロセスのreceiveアクティビティにパブリッシュされます。

詳細は、「アダプタとOracle Fusion Middlewareの統合」を参照してください。

1.2.2.4 デプロイメント

レガシー・アダプタは、インストール時にOracle WebLogic Server J2CAコンテナにJ2CAリソース・アダプタとしてデプロイされます。アダプタは、統合するOracle Fusion Middlewareと同じOracle WebLogic Serverコンテナ内に存在する必要があります。

1.2.3 パッケージ・アプリケーション・アダプタ

パッケージ・アプリケーション・アダプタにより、Oracle Application Serverが各種のパッケージ・アプリケーション(SAPやSiebelなど)と統合されます。

SOA Suite 11gでは、次のエンタープライズ・アプリケーション・アダプタを提供します。

- OracleAS Adapter for PeopleSoft

- OracleAS Adapter for SAP R/3

- OracleAS Adapter for Siebel

- Oracle AS Adapter for J.D.Edwards EnterpriseOne and OneWorld

これらのアダプタは、標準のSOA Suiteのインストールから個別にダウンロードおよびインストールされます。また、これらのアダプタの設計時タスクはすべてOracle Application Explorerによって実行され、必要なWSDLとスキーマ・アーティファクトを生成してJDeveloperにインポートされます。

以前のOracle iWayアダプタはJDE EnterpriseOneおよびJDE OneWorld製品向けでしたが、新しいJDEアダプタはJDE World製品専用です。

SOA Suite 12.1.3には、SOA Suiteですぐに使用できる2つのアダプタが含まれています。

- Oracle Adapter for SAP、および

- Oracle Adapter for J.D.Edwards World

他のテクノロジ・アダプタと同様に、これらのアダプタの設計時にはOracle JDeveloperを使用します。

アダプタ・コンポーネントは、各アプリケーションとの統合をモデル化できるコンポーネントで、すぐに使用できます。これらのアダプタのライセンスの詳細は、ライセンス・ドキュメントを参照してください。

この項には次のトピックが含まれます:

- アーキテクチャ

- 設計時コンポーネント

- ランタイム・コンポーネント

- デプロイメント

詳細は、次を参照してください。

- Oracle WebLogic Serverのリソース・アダプタの開発

- 『Oracle SOA Suiteを使用したSOAアプリケーションの開発』

- 『Oracle Fusion Middlewareの管理』

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

1.2.3.1 アーキテクチャ

パッケージ・アプリケーション・アダプタは、J2EE Connector Architecture (J2CA) 1.5リソース・アダプタまたはWebサービス・サーブレットとしてOracle WebLogic Serverコンテナにデプロイできます。パッケージ・アプリケーション・アダプタでは、J2CAインタフェースに加えて、Web Service Definition Language (WSDL)およびSimple Object Access Protocol (SOAP)インタフェースがサポートされています。パッケージ・アプリケーション・アダプタをJ2CAおよびWebサービスとしてデプロイするには、リポジトリ・プロジェクトが必要です。J2CAデプロイメントの場合、リソース・アダプタは複数のバックエンド接続オブジェクトを格納できるリポジトリ・プロジェクトを指します。デプロイメント・ディスクリプタweblogic-ra.xmlは、J2CAリポジトリ・プロジェクトとそのプロジェクト内でアクセスするための接続名を指します。WSDLデプロイメントの場合、WSDLリポジトリ・プロジェクトはアダプタ・メタデータを記述する一連のWSDLファイルで構成されます。

注意:

このリリースでは、WSDLおよびSOAP拡張をサポートしているのは次のパッケージ・アプリケーション・アダプタのみです。

- OracleAS Adapter for SAP

- OracleAS Adapter for Siebel

- OracleAS Adapter for PeopleSoft

- OracleAS Adapter for J.D. Edwards

パッケージ・アプリケーション・アダプタのアーキテクチャは、OracleAS Adapter Application Explorer(アプリケーション・エクスプローラ)、J2CA 1.5リソース・アダプタおよびBusiness Services Engine (BSE)で構成されています。

図1-11 に、パッケージ・アプリケーション・アダプタのアーキテクチャを示します。

図1-11 パッケージ・アプリケーション・アダプタのアーキテクチャ

この項では、パッケージ・アプリケーション・アダプタ・アーキテクチャのコンポーネントについて説明します。

この項には次のトピックが含まれます:

- アプリケーション・エクスプローラ

- BSE

- J2CA 1.5リソース・アダプタ

1.2.3.1.1 アプリケーション・エクスプローラ

アプリケーション・エクスプローラは、パッケージ・アプリケーション・アダプタを構成するための、Java Swingベースの設計時ツールです。アプリケーション・エクスプローラを使用すると、バックエンド・アプリケーション接続を構成し、バックエンド・アプリケーション・スキーマを参照し、これらのスキーマをアダプタ・サービスとして公開できます。アプリケーション・エクスプローラは、バックエンド・アプリケーション固有のメタデータを参照するための、パッケージ・アプリケーション固有のプラグインに付属しています。

アプリケーション・エクスプローラを使用すると、Oracleアダプタのリポジトリ・プロジェクトを作成できます。各リポジトリ・プロジェクトは、複数のバックエンド・アプリケーション接続で構成できます。スキーマは、Oracle Adapter J2CAインタフェースまたはBSE用のXMLスキーマ定義(XSD)、またはSOAPバインディングを使用するWSDLとして表されます。

1.2.3.1.2 BSE

アプリケーション・エクスプローラは、Oracle WebLogic ServerコンテナにデプロイされるBSEと連動します。BSEでは、クライアントからリクエストを受け入れ、バックエンド・アプリケーションと対話し、バックエンド・アプリケーションからクライアントにレスポンスを送信するためのプロトコルとしてSOAPが使用されます。

1.2.3.1.3 J2CA 1.5リソース・アダプタ

J2CA 1.5リソース・アダプタは、バックエンド・イベントを受信するためのチャネル・コンポーネントで構成されています。

1.2.3.2 設計時コンポーネント

アプリケーション・エクスプローラを使用して、設計時にパッケージ・アプリケーション・アダプタを構成します。このツールを使用して、バックエンド接続のリストを含んだ、J2CA 1.5リソース・アダプタ用のリポジトリ・プロジェクトを作成します。アプリケーション・エクスプローラでは、バックエンド・メタデータがJ2CA拡張を使用するXSDおよびWSDLとして公開されます。XSDメタデータは、Oracle WebLogic Serverアプリケーション・クライアントでJ2CA Common Client Interface (CCI)のアプリケーション・プログラム・インタフェース(API)を介した統合に使用されます。J2CA拡張を使用するWSDLは、Business Process Execution Language for Web Services (BPEL) Process Managerとの統合に使用されます。BSEのメタデータは、WSDLまたはSOAPとして定義できます。

図1-12 に、アプリケーション・エクスプローラを示します。

図1-12 アプリケーション・エクスプローラ

OracleAS Adapter for SAP用のXMLリクエスト・スキーマの生成の例

アプリケーション・エクスプローラを使用して、OracleAS Adapter for SAP用の接続を確立できます。このような接続を確立するには、まず図1-13 および図1-14 に示すようにOracleAS Adapter for SAPに対してターゲットを定義する必要があります。

図1-13 OracleAS Adapter for SAPの選択

図1-14 OracleAS Adapter for SAPに対するターゲットの定義

SAPビジネス関数ライブラリを開いてオブジェクトを選択した後、アプリケーション・エクスプローラを使用して、その関数に使用するXMLリクエスト・スキーマとXMLレスポンス・スキーマを作成できます。各スキーマ・タイプのXMLを表示するには、図1-15 に示すように必要なタブを選択します。

図1-15 XMLスキーマの表示

1.2.3.3 ランタイム・コンポーネント

パッケージ・アプリケーション・アダプタのランタイム・コンポーネントには、J2CA 1.5リソース・アダプタ、BSEおよびサーブレットなどがあります。WebLogic Serverアプリケーション・クライアントでは、CCI APIを使用してJ2CA 1.5リソース・アダプタに直接インタフェースします。J2CA 1.5リソース・アダプタは、JCAバインディング・コンポーネントを介してOracle Fusion Middlewareと統合されます。実行時には、JCAバインディング・コンポーネントにより、設計時に構成されたアダプタ・メタデータ(WSDLおよびバインディング構成)に基づいて、Oracle Fusion Middlewareサービス・リクエストとJ2CAコールの間の変換が実行されます。

実行時には、設計時に生成されたWSDLファイルが統合コンポーネントにより使用されます。たとえば、Oracle Fusion Middlewareでは、JCAバインディング・コンポーネントを使用してリクエスト-レスポンス・サービス(J2CAアウトバウンド相互作用)がBPELプロセスのinvokeアクティビティと統合され、アダプタ・イベントがBPELプロセスのreceiveアクティビティにパブリッシュされます。

Oracle Fusion Middlewareとの統合の詳細は、「アダプタとOracle Fusion Middlewareの統合」を参照してください。

1.2.3.4 デプロイメント

パッケージ・アプリケーション・アダプタは、インストール時にWebLogic Server J2CAコンテナにJ2CA 1.5リソース・アダプタとしてデプロイされます。アダプタは、統合するOracle BPEL PMと同じWebLogic Serverコンテナ内に存在する必要があります。

すべてのWebサービス・クライアントをBSEサーブレットと統合できます。

BSEは、インストール時にWebLogic Serverコンテナにサーブレットとしてデプロイされます。BSEはリモート配置が可能で、Oracle BPEL PMと同じコンテナになくてもかまいません。

1.2.4 Oracle E-Business Suiteアダプタ

Oracle Applicationsは、Oracleアプリケーションと非Oracleアプリケーションのデータを統合し、企業全体で顧客、サプライヤ、パートナおよび従業員を一元的に定義できるようにする、統合情報アーキテクチャ上に構築されます。これにより、現在のパフォーマンス・メトリック、財務比率、損益要約などの情報を取得できるアプリケーションのスイートが提供されます。Oracle Applicationsを非Oracleアプリケーションに接続するには、Oracle E-Business Suiteアダプタを使用します。

Oracle Adapter for Oracle Applications (E-Business Suite)によって、Oracle Applicationsへの包括的、双方向、マルチモード、同期および非同期の接続が可能になります。アダプタでは、Oracle E-Business Suiteのバージョンに基づいたカスタム統合インタフェース・タイプの選択を含む、リリース12およびリリース11iのOracle Applicationsのすべてのモジュールがサポートされます。

Oracle Adapter for Oracle Applications (E-Business Suite)のアーキテクチャは、Oracleテクノロジ・アダプタに類似しています。

詳細は、次を参照してください。

- Oracle Fusion Middleware Oracle E-Business Suite Adapterユーザーズ・ガイド

- Oracle WebLogic Serverのリソース・アダプタの開発

- 『Oracle SOA Suiteを使用したSOAアプリケーションの開発』

- 『Oracle Fusion Middlewareの管理』

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

1.3 Oracle JCAアダプタ・サービスのタイプ

このトピックでは、Oracle JCAアダプタ・サービスのタイプに関する情報を提供します。

アダプタには、アプリケーション間の通信を容易にするために次のタイプのサービスが用意されています。

- リクエスト-レスポンス(アウトバウンド相互作用)サービス

- イベント通知(インバウンド相互作用)サービス

- メタデータ・サービス

1.3.1 リクエスト-レスポンス(アウトバウンド相互作用)サービス

アダプタでは、同期リクエスト-レスポンス・サービスがサポートされています。アダプタはアダプタ・クライアントからリクエストを受信すると、リクエストをネイティブなバックエンド・データ形式に変換し、バックエンド・アプリケーション内で該当するメソッドをコールします。さらに、リクエスト-レスポンス・サービスは逆変換の実行後に、JCAバインディング・コンポーネントへのバックエンド・レスポンスを取得します。J2CA用語では、このタイプのサービスはアウトバウンド相互作用とも呼ばれます。

リクエスト-レスポンス・サービスは、バックエンド・データの作成、削除、更新および問合せと、バックエンド・ワークフローおよびトランザクションのコールに使用できます。たとえば、WebLogic Serverアプリケーション・クライアントでは、OracleAS Adapter for SAPを使用してSAPアプリケーション内で顧客を作成できます。

図1-16 に、リクエスト-レスポンス・サービスを示します。

図1-16 リクエスト-レスポンス・サービス

1.3.2 イベント通知(インバウンド相互作用)サービス

アダプタでは、非同期通信パラダイムであるイベント通知サービスがサポートされています。J2CA用語では、このタイプのサービスはインバウンド相互作用とも呼ばれます。

アダプタは、バックエンド・イベントの変化をリスニングまたはポーリングします。イベントをリスニングするアダプタは、イベントをアダプタにプッシュするように構成されているバックエンド・アプリケーション用のリスナーとして登録されます。アダプタは、クライアント・アプリケーションに必要なイベントを、バックエンド・アプリケーション(通常はデータベースまたはファイル)でポーリングすることもできます。

イベント通知サービスを使用すると、バックエンド・データの作成、削除および更新について、成功したバックエンド・トランザクションに関連付けられたバックエンド・イベントを追跡できます。

図1-17 に、イベント通知サービスを示します。

図1-17 イベント通知サービス

1.3.3 メタデータ・サービス

アダプタ・メタデータ定義には、ビジネス・オブジェクトおよびサービス用のバックエンド接続およびスキーマに関する情報が格納されます。アダプタは、メタデータを参照および格納するための設計時コンポーネントと、サービスを実行するためのランタイム・コンポーネントで構成されています。アダプタ・メタデータ定義は、XMLスキーマ定義(XSD)、WSDLおよびバインディング構成ファイルとして生成されます。図1-18 に、メタデータの相互作用を示します。

図1-18 メタデータ・サービス

2 アダプタ・フレームワーク

この章では、JCAバインディング・コンポーネントを介してOracle Fusion Middlewareと統合される、Oracle JCAアダプタのインストール、起動と停止、エラー処理、構成とデプロイについて説明します。

Oracle JCAアダプタはJ2EE Connector Architecture (J2CA) 1.5標準に基づいており、Oracle Containers for Java EEにデプロイされます。Oracle JCAアダプタのライフサイクルは、Oracle Fusion Middlewareに依存します。これらのアダプタは、JCAバインディング・コンポーネントを介してOracle Fusion Middlewareと統合されます。

この章の内容は次のとおりです。

- Oracle JCAアダプタのインストール

- Oracle JCAアダプタの起動と停止

- 既存WSDLのインポートによるアダプタ・インタフェースの定義

- Oracle JCAアダプタのメッセージ・ヘッダー・プロパティの構成

- Oracle JCAアダプタの物理デプロイ

- Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成

- JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ

- Jarファイルが関連付けられていないアダプタRARファイルの手動デプロイ

- リモートOracle SOAサーバーで作業中のデプロイメント計画の処理

- 異なる環境からのリポジトリの移行

- メッセージの損失がないことをOracle JCAアダプタで保証する方法

- コンポジットの可用性とインバウンド・アダプタ

- アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート

- アダプタ内での相関サポート

- ペイロード・サイズしきい値の設定

- 大きなペイロードのストリーミング

- バッチ処理とデバッチ処理のサポート

- アダプタ・コネクション・ファクトリの追加

- アダプタ・コネクション・ファクトリの追加または更新

- Oracle JCAアダプタで使用するデータソースの推奨設定

- エラー処理

- アプリケーションのテスト

- Oracle JCAアダプタのトレース・レベルの設定

- アダプタ・ログの表示

- カスタム・アダプタの作成

2.1 Oracle JCAアダプタのインストール

このトピックでは、Oracle JCAアダプタのインストール手順について説明します。

Oracleテクノロジ・アダプタとOracle Adapter for Oracle Applicationsは、Oracle Fusion Middlewareインストールの一部として使用可能です。これらのアダプタでは、Oracle Containers for Java EEと中間層デプロイメントの両方がサポートされています。詳細は、Oracle Fusion Middlewareのインストールのプランニングを参照してください。

SOA Foundationプロファイルによって、アダプタは論理的に2つのグループに分けられます。Tier 1とTier 2があります。

Tier 1のアダプタには、次のものが含まれます。

- ファイル

- FTP

- データベース

- JMS

- AQ

- MQ Series

- UMS

Tier 2のアダプタには、次のものが含まれます。

- ソケット

- LDAP

- コヒーレンス

- MSMQ

- JDE

- SAP

- AS400

Tier 1のアダプタは、このリリースをインストールすると、デフォルトで有効になります。残りのアダプタはインストール済の状態ですが、管理対象サーバーにターゲット設定されていません。これらを使用するには、手動でターゲット設定する必要があります。

レガシー・アダプタとパッケージ・アプリケーション・アダプタは、Oracle Fusion Middleware AdaptersおよびConnectors CDに収録されています。これらのアダプタでは、中間層デプロイメントのみがサポートされています。

注意:

アダプタをインストールする前に、次のページ(http://docs.oracle.com/html/E18558_01/fusion_requirements.htm)のシステム要件ドキュメントを参照してください。

2.2 起動と停止

JCA 1.5リソース・アダプタとしてデプロイされます。したがって、アダプタを起動または停止するには、すべてのリソース・アダプタでSPIインタフェースの一部としてstart (BootstrapContext)およびstopメソッドを実装する必要があります。開始されるのは、それらを使用するSOAコンポジットがアウトバウンド相互作用を開始するときです。また、インバウンド相互作用にSOAコンポジット自体がロードされるとき、またはアダプタによりイベントがJCAバインディング・コンポーネントにパブリッシュされるときにも、アダプタを起動できます。

アダプタの起動後に停止するには、停止するか、またはOracle Fusion Middleware内でJ2EEアプリケーションを停止します。このリリースでは、JCAバインディング・コンポーネントはJCA 1.5コンテナの一部として機能します。

コンポジットをデプロイする前に、サーバーの起動ログファイルに次のようなメッセージが表示されることがあります。これらは問題のない警告で、アダプタが適切に機能していることを表しています。

<Warning> <J2EE> <slc01aec> <soa_server1> <[ACTIVE] ExecuteThread: '0' for   queue: 'weblogic.kernel.Default (self-tuning)'>
<<WLS Kernel>> <>  <57ab8b08-803c-4edb-9da9-82791e12c429-00000004>
<1372403795938> <BEA-160140>  <Unresolved optional package references
(in META-INF/MANIFEST.MF):   [Extension-Name: oracle.adapter.ext, referenced from:   /scratch/vaspatel/fmwhome12/soa/soa/connectors
/FileAdapter.rar]. Ensure that   the referenced optional package has been
deployed as a library.>  <Warning> <J2EE> <slc01aec> <soa_server1>
<[ACTIVE] ExecuteThread: '0' for  queue: 'weblogic.kernel.Default (self-tuning)'>
<<WLS Kernel>> <>  <57ab8b08-803c-4edb-9da9-82791e12c429-00000004>
<1372403796778> <BEA-160140>  <Unresolved optional package references
(in META-INF/MANIFEST.MF):  [Extension-Name: oracle.adapter.ext, referenced from:  /scratch/vaspatel/fmwhome12/soa/soa/
connectors/FtpAdapter.rar]. Ensure that  the referenced optional package has been
deployed as a library.>

2.3 既存WSDLのインポートによるアダプタ・インタフェースの定義

図2-1 に示すように、次のいずれかの方法を使用して、「アダプタ構成ウィザード - アダプタ・インタフェース」ページでアダプタ・インタフェースを定義できます。

- 「アダプタ構成ウィザード - アダプタ・インタフェース」ページの後に表示されるページで、指定した操作名とスキーマを使用して生成されるWSDLを使用します。

- 既存のWSDLをインポートします。

図2-1 「アダプタ構成ウィザード - アダプタ・インタフェース」ページ

この項では、既存のWSDLをインポートしてアダプタ・インタフェースを定義する方法について説明します。この機能を使用すると、既存のWSDLを使用してアダプタ・サービスまたは参照を作成できます。既存のWSDLを選択するオプションは、次のアダプタについてのみサポートされています。

- Oracleソケット・アダプタ

- Oracle JCA Adapter for MSMQ

- Oracle JCA Adapter for UMS

- Oracle JCA Adapter for Oracle JD Edwards World

- Oracle JCA Adapter for LDAP

- Oracle JCA Adapter for Coherence

既存のWSDLをインポートしてアダプタ・インタフェースを定義するというオプションを選択した場合、以降のウィザード・ページの一部の機能が無効になります。たとえば、WSDLでは操作名とメッセージ・スキーマを定義するため、図2-2 に示すように、以降の操作名フィールドとスキーマ要素フィールドには値が自動的に入力されて変更できません。ただし、既存のWSDLを使用するように選択しなければ、アダプタ・ウィザードの動作は変わりません。

図2-2 フィールドに自動的に移入された「操作」ページ

2.3.1 Oracle MQ Seriesアダプタ、Oracle JMSアダプタ、Oracle AQアダプタ用のアダプタ構成ウィザード

アダプタ構成ウィザードは、他のアダプタとは異なって表示されます。ポート・タイプや操作などのコールバックを選択するための追加オプションがあります。

アダプタ構成ウィザードの以降のオプションは、選択したポート・タイプと操作に応じて有効または無効になります。

2.3.1.1 コールバックの使用例

たとえば、アダプタ構成ウィザードを使用して定義する場合、コールバックを選択すると、「MQにメッセージを送信し、リプライ/レポートを取得」およびMQからメッセージを取得し、リプライ/レポートを非同期で送信オプションのみが有効になります。

コールバックを選択しなかった場合は、「MQにメッセージを蓄積」および「MQからメッセージを取得」オプションのみが有効になります。

同期リプライを含むWSDL操作を選択した場合は、MQからメッセージを取得し、リプライ/レポートを同期で送信オプションが有効になります。既存のWSDLを使用する場合、CICSまたはIMSスキーマを使用するオプションは無効になります。

注意:

既存のWSDLをインポートする最も一般的な方法は、最初にOracle BPELプロセスまたはメディエータを作成し、それらのWSDLファイルをスキーマ(またはNXSD)から定義します。これが完了すると、アダプタ・サービスが作成され、BPELプロセスまたはメディエータ・コンポーネントに作成されたWSDLファイルが既存のWSDLファイルとしてインポートされます。

ただし、この機能はスキーマ要素を使用するメッセージにのみ機能することに注意する必要があります。単純型と複合型はサポートされていません。

2.4 Oracle JCAアダプタのメッセージ・ヘッダー・プロパティの構成

Oracle JCAアダプタにより、基礎となるバックエンド操作固有のプロパティがメッセージ・ヘッダー要素として公開され、これらの要素をビジネス・プロセス内で操作できるようになります。

これらのプロパティが公開されているため、Fusion Middleware ControlコンソールでOracle JCAアダプタのプロパティを追加または削除したり元に戻すことができます。ただし、プロパティのタイプによっては、プロパティの変更を適用するには、コンポジット・アプリケーションを再デプロイする必要があります。

注意:

SOAコンポジット・エディタのプロパティ・インスペクタを使用して、JCAプロパティを変更できます。ただし、この方法で変更を実行する場合、変更したプロパティの検証は行われません。

表2-1 に、構成できるメッセージ・ヘッダー・プロパティのタイプおよび再デプロイが必要かどうかを示します。

表2-1 Oracle JCAアダプタのプロパティ・タイプ

プロパティ・タイプ

説明

制限

アクティブ化仕様および相互作用仕様

SOAコンポジット・アプリケーション内で、アクティブ化仕様プロパティはサービスとして機能し、相互作用仕様プロパティは参照として機能します。

これらのプロパティは追加したり削除しないでください。値の変更のみが可能です。

これらのプロパティには、リサイクル対象のアダプタ・エンドポイントが必要です。これらのプロパティ・タイプは、他のプロパティにも依存しています。プロパティを追加する場合、他にも追加する必要がある従属プロパティを把握する方法はありません。

エンドポイント

これらは、アクティブ化仕様プロパティまたは相互作用仕様プロパティを介して公開されない、チューニングに関連するプロパティ(タイムアウト、しきい値、最大間隔などを指定する)です。

エンドポイント・プロパティの追加、削除または変更には制限がありません。プロパティが追加、削除または変更されるとアダプタに通知が送信されますが、アダプタによる再デプロイメントは不要です。

jca.retry.*エンドポイント・プロパティは、コンポジットを再デプロイしないと追加または削除できません。ただし、Fusion Middleware Controlコンソールを使用すると、コンポジットを再デプロイしないでこれらのプロパティを変更できます。

詳細は、「Oracleファイル/FTPアダプタのプロパティ」を参照してください

2.5 物理デプロイ

コンテナにJCA 1.5リソース・アダプタとしてデプロイされます。アダプタは、Javaアーカイブ(JAR)フォーマットを使用してリソース・アダプタ・アーカイブ(RAR)ファイルとしてパッケージ化されます。

アダプタの物理デプロイでは、RARファイルを使用して、基礎となるWebLogic Serverまたは中間層プラットフォームにアダプタをコネクタとして登録します。

注意:

アダプタに変更を行った後、サーバーを再起動してデプロイメントを更新する必要があります。そうしなければ、行った変更は有効になりません。構成プラン・ファイルに構成の変更を保存した後、デプロイメントを更新して変更を反映する必要があります。

デプロイメントの更新アクションによって、新しいプラン・ファイルが各サーバー・インスタンスのステージング・ディレクトリに同期されます。その時点で、新しいデプロイメント・プランがソースでアクティブになります。

2.5.1 RARデプロイメント・ディスクリプタ・ファイルとweblogic-ra.xmlテンプレート・ファイル

RARファイルには、リソース・アダプタに関するデプロイ固有の情報を含んだデプロイメント・ディスクリプタXMLファイルra.xmlが含まれています。さらに、RARファイルには、Oracle Containers for Java EEとリソース・アダプタの間の規定に関する宣言情報も含まれています。

アダプタでは、.rarファイル内のra.xmlファイルのみでなく、weblogic-ra.xmlテンプレート・ファイルもパッケージされます。weblogic-ra.xmlファイルは、リソース・アダプタのConnectorFactoryオブジェクトの定義に使用されます(論理デプロイ)。weblogic-ra.xmlファイルは、リソース・アダプタ用のOracle Containers for EE固有のデプロイメント・ディスクリプタです。これにはリソース・アダプタをWebLogic Serverにデプロイするためのデプロイ構成が含まれています。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface (JNDI)名、接続プーリング・パラメータ、リソースのプリンシパル・マッピング・メカニズムおよび構成などが含まれます。

ファイル

目次

RARファイル

リソース・アダプタに関するデプロイ固有の情報を含みます。

Oracle Containers for Java EEとリソース・アダプタの間の規定に関する宣言情報を含みます

weblogic-ra.xmlテンプレート・ファイル

リソース・アダプタのConnectorFactoryオブジェクト(論理デプロイ)を定義します。

リソース・アダプタをWebLogic Serverにデプロイするためのデプロイ構成を含みます。

リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報を提供します。

使用するJava Naming and Directory Interface (JNDI)名を提供します。

接続プーリングのパラメータを提供します。

リソースのプリンシパル・マッピング・メカニズムを提供します。

構成情報を提供します

詳細は、次を参照してください。

- Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成

- JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ

- Jarファイルが関連付けられていないアダプタRARファイルの手動デプロイ

- リモートOracle SOAサーバーで作業中のデプロイメント計画の処理

- 異なる環境からのリポジトリの移行

- アダプタ・コネクション・ファクトリの追加

- Oracle JCAアダプタで使用するデータソースの推奨設定

2.6 Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成

設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。このような接続性を確立するには、アプリケーション・サーバー接続を作成する必要があります。

次の手順に従ってアプリケーション・サーバー接続を作成します。

1. 「ファイル」メニューの「新規」をクリックします。

図2-3 に示すように、「新規ギャラリ」ページが表示されます。

図2-3 「新規ギャラリ」ページ

2. 「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。

「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。

3. 「アプリケーション・サーバー接続」を選択し、「OK」をクリックします。

図2-4 に示すように、「アプリケーション・サーバー接続の作成」ページが表示されます。

図2-4 「アプリケーション・サーバー接続の作成 - 名前とタイプ」ページ

4. 「接続名」フィールドに接続名を入力します。たとえば、AppsServerConnection1のように指定します。

5. 「接続タイプ」で「WebLogic 10.3」を選択し、「次へ」をクリックします。

図2-5 に示すように、「認証」ページが表示されます。

図2-5 「アプリケーション・サーバー接続の作成 - 認証」ページ

6. ユーザー名とパスワードを入力して「次へ」をクリックします。

図2-6 に示すように、「アプリケーション・サーバー接続の作成 - 構成」ページが表示されます。

図2-6 「アプリケーション・サーバー接続の作成 - 構成」ページ

7. 「構成」ページでホスト名、ポート詳細およびドメイン・サーバー名を入力します。

8. 「次へ」をクリックします。

図2-7 に示すように、「アプリケーション・サーバー接続の作成 - テスト」ページが表示されます。

図2-7 「アプリケーション・サーバー接続の作成 - テスト」ページ

9. 「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。

10. 「終了」をクリックします。

サーバー接続が作成されました。

2.7 JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ

SOAコンポジット・アプリケーションはJDeveloperからデプロイします。

JDeveloperでは、デプロイするSOAプロジェクトおよびアプリケーションに対してプロファイルを使用する必要があります。この項では、JDeveloperによるプロファイルの作成およびデプロイ方法について説明します。

2.7.1 SOAプロジェクトおよびアプリケーションに対するアプリケーション・プロファイルのデプロイ

この項では、SOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする方法を説明します。アプリケーションをデプロイするには、次の手順を実行する必要があります。

1. デプロイするプロジェクトを右クリックし、図2-8 に示すように「デプロイ」→「project_name」→「デプロイ先」→「Application_Server_Connection_Name」を選択します。

「SOAデプロイメントと構成ダイアログ」が表示されます。

図2-8 アプリケーション・プロファイルのデプロイメント

2. 図2-9 に示すように、デフォルト設定を使用します。

図2-9 「SOAデプロイメントと構成ダイアログ」

3. 「OK」をクリックします。

「認可リクエスト」ダイアログが表示されます。

4. ユーザー名とパスワードを入力して「OK」をクリックします。

プロジェクトがコンパイルされ、管理サーバーにデプロイされます。設計領域で「デプロイメント」タブをクリックすると、デプロイメント・ログを表示できます。

同じバージョンのSOAコンポジット・アプリケーションを再デプロイする場合、コンポジット名は変更できません。「SOAデプロイメントと構成ダイアログ」で「同じリビジョンIDで既存のコンポジットを上書きします。」チェック・ボックスを選択した場合は、同じリビジョン番号でデプロイできます。ただし、このチェック・ボックスを選択していない場合は、デプロイメント・ログに次のエラー・メッセージが表示されます。

pr 29, 2009 1:55:57 AM
oracle.integration.platform.blocks.deploy.
servlet.CompositeDeployerMessages
severeSendError
SEVERE: Sending back error message:
Error during composite deployment:
oracle.fabric.common.FabricDeploymentException:
Composite with same revision ID already exists:
default/<application name>!<revision id>.
Please set the overwrite flag or use different
revision ID.
Abort deployment...

2.7.2 アダプタのデプロイメントの検証

JCAアダプタの設計時の構成ウィザード画面をキャプチャしたJCAアダプタ・メタデータは、サーバーにデプロイされるときに検証されます。

たとえば、/in/valid/directoryのPhysicalDirectory値を選択していて、SOAサーバーがこのメタデータを使用してアダプタのデプロイを試行する場合、(ファイル)アダプタはすべてのメタデータを参照し、1つまたは複数のメタデータが正しくない場合は例外をスローします。

これにより、JDeveloperでデプロイメント・アクションのロールバックが発生します。アダプタは、実行時に、すべての参照およびJNDI名付きのJCAコネクション・ファクトリが使用可能なこと(エラーなく参照できること)を検証します。データソースとコネクション・ファクトリが使用可能な場合は、デプロイメントが検証され、処理が続行されます。

Oracle SOAプラットフォームの11xxシリーズのリリースからプロジェクトを移行した場合、そのプロジェクトに対するデプロイメントの検証ロジックは施行されません。そのため、以前のコンポジット・アプリケーションは中断しません。

2.8 Jarファイルが関連付けられていないアダプタRARファイルの手動デプロイ

この項では、jarファイルが関連付けられていないアダプタRARファイルを手動でデプロイする方法について説明します。

META-INF/ra.xmlとMETA-INF/weblogic-ra.xmlのみを含み、JNDIの作成に必要なjarファイル・アダプタが含まれていない任意のアダプタRARファイルをデプロイする場合は、デプロイ時に、Oracle WebLogic Serverがアダプタのjarファイルのロード後にこのRARファイルをデプロイできるよう、デプロイメント順序を高い値(500など)に変更する必要があります。

2.8.1 手動デプロイメントの例

たとえば、META-INF/ra.xmlとMETA-INF /weblogic-ra.xmlのみを含み、新しいJNDIのインスタンス化に必要なjarファイル・アダプタ(DbAdapter.jar)が含まれていないDBAdapter_NewJndis.rarファイルをデプロイする場合は、次の手順を実行できます。

注意:

この場合、DBAdapter_NewJndis.rarファイルをデプロイした後で、デプロイメント順序をより高い値に変更する必要があります。これにより、Oracle WebLogic Serverを再起動した場合でも、Oracle WebLogic ServerによってDBAdapter_NewJndi.rarファイルが正しくデプロイされます。

次の手順に従って、jarファイルが関連付けられていないアダプタRARファイルを手動でデプロイします。

1. Oracle WebLogic Server管理コンソール: http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

3. 「ドメイン構造」ペインで「デプロイメント」を選択します。

Oracle WebLogic Server管理コンソールの「デプロイメントのサマリー」ページが表示されます。

4. 「インストール」をクリックします。

「アプリケーション・インストール・アシスタント」ページが表示されます。

5. 「パス」フィールドにアプリケーション・ディレクトリまたはファイルのパスを入力し、「次」をクリックします。

6. このアプリケーションのデプロイ先サーバーを選択し、「次へ」をクリックします。

「オプション設定」ページが表示されます。

7. これらの設定を変更するかデフォルトを受け入れて、「次へ」をクリックします。

「選択項目を確認して「終了」をクリック」ページが表示されます。

8. 「終了」をクリックしてデプロイを完了します。

9. RARファイルをデプロイした後、「デプロイメントの概要」の下でデプロイしたRARファイルの名前をクリックします。

「設定」ページが表示されます。

10. 「デプロイ順序」フィールドの値をデフォルト値よりも大きい値に変更します。たとえば、500です。

これにより、新規にデプロイしたRARファイルがロードされるのは、常にOracle WebLogic Serverにより関連クラスがロードされた後になります。

2.9 リモートOracle SOAサーバーで作業中のデプロイメント計画の処理

AdminserverがコンピュータAで実行中で、Oracle SOA ServerがコンピュータBで実行中の場合は、Oracle SOA Serverで行った変更内容をアクティブ化する前に、デプロイメント計画ファイルをコンピュータBにコピーする必要があります。

デプロイメント計画をOracle SOA Serverコンピュータにコピーせずに変更内容をアクティブ化しようとすると、NullPointerExceptionがスローされます。

2.10 異なる環境からのリポジトリの移行

アダプタ構成ウィザードによって生成されたすべてのJCAファイルにはJNDIへの参照があります。参照はweblogic-ra.xmlファイルに定義されていますが、これはアダプタのデプロイメント・ディスクリプタです。

JNDI名は開発環境からテスト環境または本番環境に移行する際のキーとなります。

開発、テストおよび本番の3つのすべての環境でJNDI名が同一になるようにweblogic-ra.xmlファイルを更新する必要があります。

再試行間隔や再試行回数などのデプロイメント時のプロパティの値を指定し、テスト環境または本番環境に再デプロイする必要があります。

weblogic-ra.xmlはエンドポイントを開発EIS、テストEIS、または本番EISとして識別します。たとえば、データベース・アダプタ・サービス・ウィザードを通じて実行しているときは、eis/DB/custStoreをcreateCustomerサービスのJNDI名として指定します。

このアダプタ・サービスを使用してコンポジットをモデル化した後は、一切の変更を行わずに開発、テストおよび本番環境にデプロイする必要があります。ただし、デプロイの前に、正しいEISインスタンスを指している各環境に、eis/DB/custStoreに対応するJNDIエントリがあることを確認してください。

要約:

- すべてのJCAファイルはweblogic-ra.xmlファイルに定義されたJNDI名を参照します。

- デプロイするすべての環境でJNDI名が同じになるようにweblogic-ra.xmlファイルを更新する必要があります。

- weblogic-ra.xmlデプロイメント・ディスクリプタを使用して、再試行間隔や再試行回数などのデプロイメント時のプロパティの値を指定します。このファイルは、エンドポイントの環境も識別します。

- デプロイメントの前に、適切な環境に対応するJNDIエントリがあることを確認します。

2.11 メッセージの順序付け

このトピックでは、出力メッセージとreplyアクティビティを追加して、一方向の非同期BPELプロセスを同期させるプロセスについて説明します。

メッセージを順序付けるには、BPELプロセスを同期させます。成功した後、BPELエンジンへのメッセージをパブリッシュするリソース・アダプタ・スレッドをBPELインスタンス全体の実行に使用します。

非同期BPELプロセスの場合は、BPELエンジンのワーカー・スレッド・プロセスがメッセージを受信します。そのため、1つのBPELインスタンスがほぼ他のプロセスからのものになるため、メッセージの順序付けは保証されません。

通常、1つのJCAリソース・アダプタのウィザードでは、一方向の (非同期) WSDL、つまり操作に入力メッセージのみを含むWSDLのみが作成されます。WSDLを生成したウィザードは手動で変更し、入力メッセージと出力メッセージを含むリクエスト-レスポンス (同期) タイプのWSDLにする必要があります。

次に、通常は生成されないレスポンス(出力)メッセージのXMLスキーマ・タイプを作成する例を示します。

<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://acme.com/adapterService/">
<import namespace="http://TargetNamespace.com/adapterService/type"
schemaLocation="adapterTypes.xsd" />
.
.
.
<element name="empty">
<complexType/>
</element>

次の例に示すように、アダプタWSDLファイル内にWSDLメッセージを定義します。

<message name="ignoreMessage">
<part name="empty" element="tns:empty"/>
</message>

次の例に示すように、出力メッセージをインバウンドWSDL操作に追加します。

<portType name="Receive_ptt">
<operation name="Receive">
<input message="tns:payloadMessage"/>
<output message="tns:ignoreMessage"/>
</operation>
</porttype>

次の例に示すように、バインディング・セクションに出力要素を追加します。

<binding name="Receive_binding" type="tns:Receive_ptt">
<pc:inbound_binding />
<operation name="Receive">
<jca:operation .../>
<input/>
<output/>
</operation>
</binding>

次の例に示すように、BPELプロセスのビジネス・プロセス・ロジックの最後にreplyアクティビティを追加します。

<variables>
<variable name="ignore" messageType="ns1:ignoreMessage"/>
.
.
.
<sequence name="main">
<receive partnerLink="ReceivePL" portType="ns1:Receive_ptt"
operation="Receive"
variable="Receive_1_Read_InputVariable"
createInstance="yes"/>
.
.
.
<!-- processing -->
<invoke partnerLink="DB_Insert" portType="ns1:DB_Insert_ptt"
operation="InsertCust" inputVariable="NewCust"/>
<reply partnerLink="ReceivePL" portType="ns1:Receive_ptt"
operation="Receive" variable="ignore"/>
.
.
.
<!-- optionally more processing -->
</sequence>

この例のリソース・アダプタがマルチスレッド・インバウンドをサポートしている場合は、複数スレッドの確率的な遅延によってメッセージ順序付けが保証されなくなるため、1つのスレッドのみを使用するよう構成/調整します。

2.12 メッセージの損失がないことをOracle JCAアダプタで保証する方法

この項では、メッセージの損失がないことをアダプタで保証する方法について説明します。

トランザクション・アダプタによって、エンタープライズ情報システム(EIS)は1フェーズ・コミットまたは2フェーズ・コミット(ローカル・トランザクションまたはグローバル/分散トランザクション)に参加できます。

非トランザクション・アダプタはトランザクション・セマンティクスを使用せずに、配信を確保する固有のスキームを実装します。

この項では、次の内容について説明します。

- ローカル・トランザクションとグローバル(XA)トランザクション

- トランザクションとアダプタの基本概念

- アウトバウンド・トランザクション

詳細は、次を参照してください。

- コンポジットの可用性とインバウンド・アダプタ

- 概要

2.12.1 XAトランザクションのサポート

XAの目標は、同一のトランザクション内から複数のリソース(データベース、アプリケーション・サーバー、メッセージ・キュー、トランザクション・キャッシュ)にアクセスできるようにすることです。XAは2フェーズ・コミットを使用して、すべてのリソースがどのようなトランザクションでも一貫してコミットまたはロールバックするようにします。

XAの仕様には、リソース・マネージャがトランザクション・アクセスをサポートするために実行する必要のある手順が記述されています。この仕様を順守するリソース・マネージャはXA準拠であると呼ばれます。

XAトランザクションは、複数のリソースを操作する場合に使用するシナリオの一部です。たとえば、2つ以上のデータベース、データベースとJMS接続、またはこれらのすべてとアダプタ、これらがすべて単一のトランザクション内にある場合などです。

トランザクション・アダプタにより、XAトランザクション・サポートが有効になります。これは、固有のデータ処理とともに、それぞれの変更の結果が明確に定義されるようにして、成功または失敗の結果、データが破損する可能性を防止します。他の変更とは独立して実行され、完了すると、基礎となるデータは他のトランザクションが発生するまで同一の状態に置かれます。

XAは2フェーズ・コミット・プロトコルで、1フェーズ・コミット/エミュレート・プロトコルよりも堅牢です。1フェーズ・プロトコルやエミュレート・プロトコルでは、メッセージが消失したりロールバック/コミットの不整合が発生する可能性があります。

2.12.2 ローカル・トランザクションとグローバル(XA)トランザクション

XAトランザクションはアプリケーション・サーバーのトランザクション・マネージャによって開始されるトランザクションです。すべてのXAリソースは任意のアクティブなグローバル・トランザクションに参加する必要があり、トランザクション・マネージャのシグナルによってのみコミットまたはロールバックされます。シグナルの受信後にコミットが失敗した場合は、最終的にコミットが必ず行われるようなリカバリ・メカニズムも存在している必要があります。

未参加のローカル・リソースはアクティブなグローバル・トランザクションに関係なくローカル・トランザクションを開始または終了できます。コミットは即座に実行される可能性があり、これはトランザクション・マネージャからのシグナルへの応答ではありません。コミットに失敗するとトランザクションはロールバックされ、例外がスローされます。コミットを同期する他のリソースがないため、このトランザクションの特別なリカバリは不要です。

2.12.2.1 ローカル・トランザクションのアダプタ・サポート

アダプタではra.xmlデプロイメント・ディスクリプタ・ファイルのtransaction-support要素を指定することによって、トランザクション・サポートのタイプが定義されます。

2.12.2.2 グローバル・トランザクションのアダプタ・サポート

アダプタは基礎となるアプリケーション・サーバー・トランザクション・マネージャを利用するJCA 1.5 XA規定でグローバル・トランザクションをサポートします。

基礎となるアプリケーション・トランザクション・マネージャを利用するアダプタのタイプには、Oracle Adapter for Oracle Applications、データベース、アドバンスト・キューイング、JMSおよびMQSeriesアダプタなどがあります。

基礎となるトランザクション・マネージャを利用しない非トランザクション・アダプタには、Oracleファイル・アダプタとOracle FTPアダプタがあります。

2.12.2.2.1 グローバル・トランザクションの再試行およびロールバックとフォルト・ポリシー

グローバル・トランザクションの参加者はだれでもグローバル・トランザクションにロールバックのマークを付けることができます。グローバル・トランザクションにロールバックのマークが付けられると、他の参加者がロールバックを取り消すことはできなくなります。

フォルト・タイプは、エラーが再試行可能かどうかを示します。再試行可能な場合は、JCA再試行プロパティによって再試行が管理されます。エラー処理の項を参照してください。エラーが再試行不可能とみなされた場合、このようなエラーの処理はフォルト・ポリシーによって管理されます - その場合、フォルト・ポリシーが実行されます。これは、インバウンド・アダプタとアウトバウンド・アダプタでも同じです。

フォルト・ポリシーによって実行される操作はローカル・トランザクション内に留まり、グローバル・トランザクションには含まれません。

特に、固有のトランザクションで実行するフォルト・ポリシーは、特定の参照の実行を開始する前に既存のすべてのJTAトランザクションをコミットします(たとえば、Oracle BPEL PMでのinvokeアクティビティなど)。既存のJTAトランザクションが一時停止されてからコミットされることはありません。

非トランザクション・アダプタをトランザクション・アダプタとともに使用する際は、再試行によって非トランザクション・データに影響する場合があるため、重複するメッセージの作成などに注意してください。たとえば、メッセージの重複が発生しないようにビジネス・プロセスをモデル化するなどして、注意を払う必要があります。

デキューおよびエンキュー・レスポンスがキューにリプライするインバウンド同期リクエスト/レスポンス・シナリオは、手動リカバリの候補ではありません。そのため、再試行の上限に達した場合、失敗としてマークされます。

2.12.3 トランザクションとアダプタの基本概念

再試行に関するトピックの追加情報は、「拒否されたメッセージの処理」およびそれ以降の項を参照してください。

- ポーリング: すべてのレガシー・アダプタは、プル、つまりポーリングをサポートしていますが、これは、イベントを受信する、つまりEISエンドポイントに使用可能なメッセージおよびデータを定期的に問い合せるためにバックエンド・アプリケーションに接続するモデルです。この例外は、異なるロジスティクスのセットを使用しますが、その場合、ソケット・アダプタは、他のアダプタがクライアント・ソケットを使用して接続するのと同じようにEISエンドポイントに接続する(ポーリング)か、サーバー・ソケットを作成してから着信リクエストを待機できます(プッシュ)。ポーリングでは、接続関連の問題はリカバリ可能であり、インバウンド・アダプタはEISとの接続を確立できるまで再試行を続けます。アダプタ・エンドポイントは、コンポジットがアクティブな期間中、失われた接続の回復を試行します。また、この期間中、接続の問題を特定する診断でログを更新します。

- ローカル再試行: 通常は、一時的な接続エラーです。再試行を再び試行でき、再試行によってデータが壊れることはありません。ただし、連続しないローカル再試行はトランザクション状態を変更できます。再試行可能なエラーの例には、一時的な権限エラーまたはリソース制限エラー、あるいはその両方が含まれます。トランザクションが再試行可能な場合、これは必ずしもロールバックを意味するとはかぎりません。

- グローバル再試行: コンポジットの開始点(BPELがコンポジットの一部であるBPEL Receiveなど)にロールバックされるトランザクションで、BPEL Receiveは、コンポジット・アプリケーション内のBPELフロー内の開始点にあります。トランザクションは無制限に再試行することも、jca.count.retryが示す回数だけ再試行することもできます。再試行の前に、ロールバックが発生する可能性があります。たとえば、同期プロセスにBPELフォルトがある場合、マスターおよび子レコードによるデータベースの部分更新があり、一時的なデータベース・フォルトが発生して、toplinkマッピング・ロジックにより再試行が受入可能であると決定された場合などです。つまり、データが損なわれていないために明示的な再試行とみなされ、ロールバックが必要な場合、グローバル再試行が行われる可能性があります。

- 再試行不可: 再試行されないトランザクション。再試行不可の状態では、既存の状態の変更はありません。再試行なしの条件は、バインディング・フォルトから導出されます。通常、再試行不可の状況は、データベースの整合性が問題である場合に発生します。したがって、再試行不可のトランザクションが拒否された場合、ロールバックされます(通常、このトランザクションはデータベース制約の問題に関連しています)。「データがすでに存在します」などのエラー(主キー・エラーなど)は、メッセージ相関IDエラーと同様に、再試行できません。再試行できないエラーのリストは、この章の後半にあります。

- インバウンド・トランザクション: インバウンド・アダプタによって開始されたトランザクションです。たとえば、JMSシステムからSOAシステムに入るトランザクションなどです。

- アウトバウンド・トランザクション: SOAシステムからの(つまり、アダプタからの)アウトバウンド・トランザクションです。たとえば、SOAシステムの外部でデータベースに対して作成されたトランザクションなどです。

- JTAトランザクション: プロセスの各ステップはJTAトランザクションのコンテキスト内で実行されます。JTAトランザクションでは1つ以上の操作がアトミック作業ユニットとして実行されます。XAについては、前述の項を参照してください。

- 非同期トランザクション: サブトランザクションで構成されるコンポジット・トランザクションです。ただし、これらのサブトランザクションは連続的でシリアライズされているため、一部のサブトランザクションがコミットされても、他のサブトランザクションが実行中であったり、まだ実行されていない場合があります。非同期トランザクションはただ1回のみ伝播されることが保証されています。ソースの更新がコミットされると、トランザクションがコミットされ、ターゲットに対する更新が適切に伝播されることが予期されます。

- 同期トランザクション: 中間プロセスなしに、あるエンドポイントから別のエンドポイントへ1つのスレッドで実行されるトランザクションです。これはシリアライズされていません。

2.12.3.1 非同期トランザクション・フロー

次の項では、非同期トランザクションと同期トランザクションについて、JMS、DB、BPELテクノロジの標準的なアダプタの組合せを通じて説明します。例ではメディエータなどの他のアダプタや他の手段が使用されている場合もあります。

非同期サービス・エントリ・ポイントの場合、トランザクション・アダプタはコンポジットにインバウンド・メッセージを送信する前に、グローバルJTAトランザクションを開始します。

2.12.3.1.1 JMS、BPEL、DBアダプタとデータベースの使用例

次に示す例では、JMSアダプタにバインドされたテスト・コンポジットを使用し、JMSアダプタは、この例ではBPELにバインドされたコンポジットにバインドされ、BPELはDBアダプタにワイヤリングされます。BPELはメッセージをDBアダプタにディスパッチします。

この例では、メッセージはポーリングJMSアダプタによってJMSから読み込まれ、BPELプロセスに書き込まれます、BPELプロセスではトランザクションがコミットされます。これはJTA1(最初のXAトランザクション)です。

再試行が不可能な、または再試行回数の上限に達したBPELアクティビティ・エラーについては、BPELは情報を格納するリカバリ表に書込みを行います。この情報にはBPELエラーが含まれます。

2番目のトランザクションJTA2は、BPELディスパッチ表から読み取るDBアダプタで始まり、データベース挿入引数を取得して、更新メッセージをDBアダプタに書き込みます。このトランザクションJTA 2は参照エンドポイントDBアダプタ(つまり、SOAからのアウトバウンド)からデータベース自体へのアウトバウンドを続行します。データベース内の重複するデータ状況からの再試行状況は、DBアダプタからBPELの表に再試行されるか、データベースからDBアダプタに再試行されます。

エラー処理のグローバル再試行は、BPEL Receiveアクティビティ・インスタンス、または通常はトランザクションが開始された位置に戻ります。このような再試行は、一時的なデータベース・フォルトなどのエラーがあった場合に行われる可能性があります。デフォルトの再試行回数は無制限(デフォルト)、またはjca.retry.countプロパティで指定された回数です。

2番目のXAトランザクションJTA2の一部でエラーが発生した場合は、ロールバックが発生します。

2.12.3.2 同期トランザクション・フロー

同期プロセスでは、アダプタによって開始されるグローバル・トランザクションは次の両方にわたります。

- メッセージの配信

- コンポジットの実行

非同期トランザクション・フローと同様、デフォルトの再試行回数は無制限で、jca.count.retryで指定できます。

同期トランザクション・フローは非同期フローと似ていますが、次の点が異なります。

- フローは、JMSアダプタと中間処理(BPEL処理など)の間、およびBPELとデータベース・アダプタの間(同じ例を使用)のリクエスト-レスポンス・メッセージで構成されます、データベース・アダプタには、挿入などを要求するメッセージが書き込まれます。同期トランザクションでは、再試行可能なエラーはコンポジット内のBPEL (例の中間状態)によって捕捉されません。トランザクションは、最終的にJMSアダプタに返され、グローバル再試行が行われる可能性があります。

- 同期トランザクションは単に1つのJTAトランザクションであり、2つのトランザクションではありません。

- アダプタ拒否表は、アダプタ拒否のレコードを保持します。同期トランザクションのコンテキスト内では、ローカルのBPELエラー処理はバイパスされます。同期トランザクションでは、プライベートBPEL表には関連するアダプタ拒否データは含まれません。かわりに、データはアダプタ拒否表に保持されます。

- 再試行回数の上限に達したローカル再試行はBPELリカバリ表に格納されます。

同期の例で使用されているのと類似の例を使用して、同期メッセージ・フローの例が非同期における例に対し、トランザクションを通じてたった1つのJTAトランザクションJTA 1で構成されていたことを思い出すと、処理は簡単です。トランザクションはサービス・エンドポイントへのポーリングされたインバウンド・メッセージで開始され、JMSでのメッセージの読取り、BPELプロセスへの書込みが行われます。

非同期トランザクションとは異なり、同期トランザクションでは、JTAトランザクションはこの時点ではコミットされません。

かわりに、同じJTAトランザクションは参照エンドポイントDBアダプタからデータベース自体へのアウトバウンドを続行します。その後、BPELからメッセージが読み込まれ、BPELからの挿入引数を使用してDBアダプタが起動されます。この時点でJTAトランザクションがコミットされます。

非同期トランザクションと同様、再試行はグローバルに行われ、jca.retry.countプロパティで指定された回数に従います。この例では、ローカルで再試行可能なフォルトはデータベースからBPELプロセス、またはデータベースからDBアダプタに戻って試行されます。

2.12.4 インバウンド・トランザクション

インバウンド・アダプタは独立したワーク・スレッドで実行します。アダプタは接続のリカバリを行い、固有の再試行プロパティを使用します(たとえば、adapter.jms.retry.intervalなど)。

トランザクション・アダプタはコンポジットにインバウンド・メッセージを送信する前に、グローバルJTAトランザクションを開始します。

トランザクション・アダプタの場合、再試行はローカル再試行(BPELリモート・フォルトなど)、グローバル再試行、または再試行なし(バインディング・フォルトと同様)のいずれかになります。グローバル再試行はトランザクションが開始した場所に返されます。デフォルトの再試行回数は無制限ですが、jca.retry.countで指定された回数のみ再試行可能です。

アダプタに制御が戻ると、アダプタはJTAトランザクションをコミットし、次の一連の操作をアトミック作業ユニットとして実行します。

- インバウンド・アダプタ・エンドポイント(表やキューなど)からのメッセージの削除をコミットします。

- コンポジット・インスタンスの実行をコミットします。

この一連のコミット操作、つまりメッセージの削除とコンポジット・インスタンスの実行においていずれかの操作が失敗すると、操作は両方ともロールバックされます。

2.12.5 アウトバウンド・トランザクション

Oracle JCAアダプタの起動を含むすべてのアウトバウンド・トランザクション・コンポジット・アクティビティは、グローバル・トランザクションの一部です。エラーが発生すると、デフォルトの動作では、すべてのアクティビティはコミットされるかまたはロールバックされるかのいずれかになります。

たとえば、BPELプロセスは異なるInvokeアクティビティを通じて、(異なるデータベースの)複数の表にデータを挿入できます。

BPELインスタンスが終わりに近づくと、JTAトランザクションがコミットされます。

データベースの挿入操作はこの時点でのみコミットされます。

ただし、BPELインスタンスの実行中にエラーが発生した場合、すべてのアクティビティ(およびそれに伴うデータベース操作)は最後のBPELデハイドレーション・ポイント(最後にBPELインスタンスがデータベースに格納された時点)までロールバックされます。

アウトバウンド・トランザクションが再試行可能かどうかは、特定の相互作用の性質および範囲によって異なります。具体的には次のとおりです。

- たとえばデータベースの整合性など、アウトバウンド・トランザクションのターゲット側で整合性を伴う相互作用は再試行されません。

- 単一レコードでの些細なデータベースの問題など、ローカル再試行が可能な条件が存在する場合は、ローカル再試行が行われます。

- たとえばマスター詳細レコードと子レコードの両方を更新するような問題など、エラーが解消する余地のあるより複雑なデータベース整合性のシナリオにおける再試行では、トランザクションは最初のBPEL Receiveまでロールバックされ、再び開始される場合があります(BPELを使用するシナリオの場合)。再試行はここでもjca.retryに従いますが、他のいずれかのBPELエラー処理の再試行パラメータに従う場合もあります。

- アダプタからのアウトバウンドの接続上の問題は、一般に、常に再試行可能です。アウトバウンド・トランザクションでは、アダプタは接続が確立できない場合に再試行可能例外をスローし、これにより適切なJCAバインディングが再試行します(jca.retry.countを経由)。

アウトバウンド相互作用に関連する接続の再試行可能なエラーの例には、データベース・リスナーが起動されていないために発生する接続エラーなどがあります。

2.13 コンポジットの可用性とインバウンド・アダプタ

WebLogicプラットフォームではOracle WebLogic Serverの移行が使用されているため、管理サーバーに障害が発生した場合に、同じ物理システムまたは別の物理システム上でそのサーバーが自動的に再起動し、障害が発生したサーバー上のコンポジットに固有のインバウンド・アダプタの機能が再開されます。

その間に、他のクラスタ・メンバー上のインバウンド・アダプタはメッセージ・サービス処理を続行できます。

詳細は、次を参照してください。

- アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート

- ファイル/FTPアダプタ: 「高可用性」

- データベース・アダプタ: 「高可用性」

- MQアダプタ: 「高可用性」

- メッセージの損失がないことをOracle JCAアダプタで保証する方法

- 『Oracle Fusion Middleware高可用性ガイド』のOracle JCAアダプタと高可用性の説明に関する項。

2.14 アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート

JCAバインディング・コンポーネントでは、インバウンド・アダプタ・サービスのアクティブ・フェイルオーバーがサポートされています。

このフェイルオーバー機能を特定のインバウンド・アダプタのエンドポイントに対して有効にするには、次のサンプル・コードに示すように、singleton JCAサービス・バインディング・プロパティ(composite.xml)を<binding.jca>要素に追加し、値をtrueに設定する必要があります。

この機能を無効にするには、singletonプロパティの値をfalseに設定します(または、<binding.jca>要素からプロパティを削除します)。

例 - composite.xmlのシングルトン・プロパティ

<service name="JmsTopicSubscr" ui:wsdlLocation="JmsTopicSubscr.wsdl">
<interface.wsdl interface=
"http://xmlns.oracle.com/
...#wsdl.interface(Subscr_ptt)"/>
<binding.jca config="JmsTopicSubscr_file.jca">
<property name="singleton">true</property>
</binding.jca>
</service>

2.14.1 同一のアダプタ・エンドポイントの複数のアクティブ化

Oracle WebLogicクラスタでは、同一(JMSなど)のアダプタ(インバウンド)のエンドポイント(特定のコンポジット・サービス向け)の複数のアクティブ化が、クラスタ内でアクティブなアダプタ・フレームワークのすべてのインスタンスによって、暗黙的かつ自動的に検出されます。

ただし、メッセージの読取りまたはパブリッシュを開始できるアクティブ化は1つのみです。

JCAバインディング・コンポーネントのインスタンスによって、プライマリのアクティブ化の役割を引き受ける1つのアクティブ化がアクティブ化の中からランダムに選択されます。

2.14.2 ホットスタンバイ状態

Oracle WebLogicクラスタ内の他のアクティブ化(インスタンスとも呼ばれる)は、JCAリソース・アダプタでEndpointActivationを起動せずにホットスタンバイ状態で開始されます。これらのアクティブ化にプライマリのアクティブ化の役割を再度割り当てることができます。

プライマリのアクティブ化がある時点で応答しなくなったり、手動で非アクティブ化されたり、クラッシュまたは終了した場合、Oracle WebLogicクラスタの残りのJCAバインディング・コンポーネント・メンバーのいずれかが即座にこの非アクティブ化を検出し、スタンバイ状態のアクティブ化エージェントの1つにプライマリのアクティブ化の役割を再度割り当てます。

詳細は、「コンポジットの可用性とインバウンド・アダプタ」を参照してください。

2.15 アダプタ内での相関サポート

ネイティブ相関を使用し、コールバック・インタフェース(参照用)を定義するか、中間プロセスBPEL Receiveによって、インバウンド非同期メッセージを前のアウトバウンド・メッセージに関連付けることができます。

たとえば、次のコンポジットではそのような相関が定義されます。

<reference name='Outbound'>
<interface.wedl
interface="http://xmlns.oracle.com/pcbpel/demo#wsdl.interface
(JMSOutbound_PortType)"
callbackinterface=
"http://xmlns.oracle.com/pcbpel/demo#wsdl.interface
(JMSCallback_PortType)"/>
<binding.jca.operation="Consume"
config="SampleOutbound_adapter.jca"/>

jcaファイルにはJCA相互作用とJCAアクティブ化の両方が含まれている必要があります。

リクエストとレスポンスの間の関連付けはJCAバインディング・ランタイムによって透過的に行われます。

JMSの使用例では、サード・パーティ・アプリケーションはリクエスト・メッセージのJMSメッセージIDをレスポンス・メッセージのJMS相関IDにコピーする必要があります。

使用例の場合は、外部アプリケーションによってリクエスト(起動)メッセージのMessageIdがレスポンス(受信)メッセージのCorrelationIdにコピーされると、アダプタ・フレームワークによってBPEL相関が確実に発生します。

2.15.1 起動と一致しない受信メッセージのCorrelationID: ログ・エラー・メッセージ

ただし、受信メッセージのCorrelationIdが以前のどの起動メッセージとも一致しない場合、メッセージは実際に存在しないBPEL対話にマップされます。

この場合、メッセージはデータベースに保持されますが、次のサンプル・コードに示すようなSEVEREログ・メッセージが表示される場合があります。

例 - receiveのcorrelationIdが前の起動のいずれとも一致しない場合のログ・エラー

SEVERE: JCABinding=>  aqadapter
aqadapterAdapter Service aqadapter was
unable to perform delivery of inbound message
to the composite ... due to: Cannot
simply post callback message to the composite
as there is no
service element associated with the callback.
Recommendation:
add/set the JCA reference/binding property
'rejectUncorrelatedMessages' to true ...
SEVERE: JCABinding=>  aqadapter Unable to
create/save Composite Instance Fault due to: null

2.15.1.1 一致しないネイティブ相関IDの拒否

次のサンプル・コードに示すように、rejectUncorrelatedMessagesサービス・バインディング・プロパティをcomposite.xmlファイルに追加して、一致しないネイティブ相関IDを拒否するようにアダプタ・フレームワークの動作を明示的に変更できます。

例 - rejectUncorrelatedMessagesプロパティの設定

<reference name="ReqReply" ui:wsdlLocation=
"ReqReply.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel
/adapter/mq/MQAsyncSol_ReplyQ_
NonRelatedMsg/SOA_AsyncSol_ReplyQ_NonRelatedMsg/
ReqReply/#wsdl.
interface(Enqueue_ptt)"
callbackInterface="http://xmlns.oracle.com/
pcbpel/adapter/mq/
MQAsyncSol_ReplyQ_NonRelatedMsg/
SOA_AsyncSol_ReplyQ_NonRelatedMsg/ReqReply/
#wsdl.interface(Dequeue_ptt)"/>
<binding.jca config="ReqReply_mq.jca">
<property name="rejectUncorrelatedMessages">
true</property>
</binding.jca>
</reference>

rejectUncorrelatedMessagesがtrueに設定されている場合、相関付けできない受信メッセージはアダプタ・フレームワークによって拒否されます。つまり、パブリッシュしているJCAリソース・アダプタにプッシュバックされます。

デフォルトでは、このプロパティはfalseに設定されます。

詳細は、次を参照してください。

- エラー処理

- Oracle JMSアダプタの機能

- 正規化されたメッセージのサポート

- Oracle JCAアダプタのプロパティ。

2.16 ペイロード・サイズしきい値の設定

システム・リソースは有限であり、処理にはしきい値制限があります。システム・リソースに依存するOracle SOA Suiteにも一定のサイズ制限がありますが、大部分は基礎となるリソースに起因するもので、これを超える受信リクエストの処理は実行できません。

たとえば、大きなペイロードを処理できますが、Oracle BPEL PMは大きなペイロードを処理する際に多くのメモリーを消費し、この結果OutOfMemory条件が発生し、システム全体が影響を受ける場合があります。

OutOfMemoryなどのエラーを回避するには、ペイロードしきい値を設定する必要があります。ペイロードしきい値を設定すると、しきい値制限よりも小さいペイロードを処理し、その他を拒否することを保証できます。この項では、ペイロードの相対サイズに関する考慮事項について説明します。

2.16.1 ペイロードのネイティブ・サイズ

ペイロードのネイティブ・サイズを使用できる場合、関連するアダプタはペイロードのネイティブ・サイズを使用して、しきい値制限を超えないようにペイロードのサイズを制限します。

たとえば、Oracleファイル・アダプタではポーリングされたファイルのネイティブ・サイズを使用できます。サイズがペイロード・サイズのしきい値を超える場合、ファイルは拒否されます。

ペイロードのネイティブ・サイズを使用できない場合、たとえばよくあるケースですが、アダプタはペイロードのネイティブ・サイズを内部で計算する必要があります。

非XMLの変換またはシリアライズXMLの解析にネイティブ変換ライブラリを使用して、ネイティブ・サイズを内部で特定できます。

Oracleデータベース・アダプタは変換フレームワークに依存していませんが、ネイティブ・メッセージのサイズを計算するための特別な処理メカニズムが組み込まれています。

注意:

エラー・リカバリでのデバッチ処理の場合、ペイロード・サイズしきい値を慎重に使用する必要があります。ペイロード・サイズの違反により、誤りのあるレコードの場合、ストリームのスキップ中に不当な拒否が発生することがあります。

2.16.1.1 ペイロードしきい値の設定

ペイロードしきい値は、公開されるノブを使用して設定できます。次のサンプルに示すように、ノブはアダプタ・サービスのバインディング・プロパティとしてcomposite.xmlファイルで設定できます(1000の値はバイト単位です)。

<binding.jca config="getMsg_mq.jca">
<property name="payloadSizeThreshold" type="xs:string"
many="false"override="may">1000</property>
</binding.jca>

2.16.1.2 ペイロード・サイズ強制の制限

ペイロードのネイティブ・サイズを使用できず、かつ、特定のアダプタでネイティブ変換ライブラリが使用されない場合、ペイロード・サイズしきい値制限を強制できません。たとえば、Oracleファイル/FTPアダプタがファイル・コンテンツのチャンクを渡し、実際のネイティブ・サイズが不明であるXMLデバッチ処理の場合は、ペイロード・サイズしきい値制限を使用できません。また、シリアライズされたXMLペイロードについて、ネイティブ変換ライブラリのかわりに、ネイティブ・サイズを計算する機能がないXDKパーサーが解析に使用される場合にも、ペイロード・サイズしきい値制限を使用できません。

XSDおよび不透明(Opaque)トランスレータ・シナリオは、ペイロード・サイズが決定されるアダプタでのみ処理できます。特定のサポートされているシナリオの詳細は、表2-2を参照してください。

表2-2 サポートされている変換シナリオ

シナリオ

NXSD

はい

はい

はい

はい

適用なし

XSD

はい

はい

はい

いいえ

はい

不透明(Opaque)

はい

はい

はい

いいえ

適用なし

DTD

いいえ

いいえ

いいえ

いいえ

適用なし

2.16.1.2.1 グローバル・ペイロード・サイズの有限値への変更

また、ペイロード・サイズを制限するグローバル・プロパティを設定して、payloadSizeThresholdのデフォルト値を(無限から)有限数に変更できます。この場合、payloadSizeThresholdのデフォルト値を有限数に設定すると、特定のインバウンド・アダプタのエンドポイントのpayloadSizeThresholdプロパティ値を明示的に構成しない場合にも、グローバル・デフォルトが有効になります。グローバル・デフォルトをcomposite.xmlの値とともに指定した場合、composite.xmlで指定した値によってグローバル値がオーバーライドされます。

Fusion Middleware ControlのMBeanブラウザ(アダプタMbean)を使用して、このグローバル・プロパティを変更できます。この変更は、すべての現在および将来のエンドポイントに対して即座に有効になります。

2.17 大きなペイロードのストリーミング

Oracle JCAアダプタは、インバウンド処理とアウトバウンド処理の両方で大きなペイロードの処理をサポートしています。ただし、ストリーミング機能を明示的にサポートしているのは次のアダプタのみです。

- Oracleファイル・アダプタ
詳細は、「Oracleファイル・アダプタのスケーラブルなDOM」を参照してください。

- Oracle AQアダプタ
詳細は、「ストリーム・ペイロードのサポート」を参照してください。

- Oracle JMSアダプタ
詳細は、「大きなペイロードのストリーミング」を参照してください。

- Oracleデータベース・アダプタ
詳細は、「大きなペイロードのストリーミング」を参照してください。

他のアダプタには、両方の明示的なサポートはありません。

2.18 バッチ処理とデバッチ処理のサポート

次のアダプタでは、バッチ機能とデバッチ機能がサポートされています。

- Oracle JCA Adapter for Files

- Oracle JCA Adapter for FTP

- Oracle JCA Adapter for Databases

Oracle JCA Adapter for FileとOracle JCA Adapter for FTPは、単一の大型ファイルを複数のバッチにデバッチ処理するためのReaderで構成されています。設計時構成中にバッチ・サイズを指定する必要があります。さらに、アダプタには一連のメッセージを単一ファイルにバッチ処理するためのライターも組み込まれています。詳細は、「ファイルのデバッチ処理」を参照してください。

Oracle JCA Adapter for Databasesは、一連の表をポーリングしてイベントを検出するためのパブリッシュ・コンポーネントで構成されています。このコンポーネントでは、BPELプロセスの1度に1つのレコードまたは1度に複数のレコードに対してイベントを発生させることができます。詳細は、「ポーリング戦略」を参照してください。

2.19 アダプタ・コネクション・ファクトリの追加

アダプタの論理デプロイメントでは、weblogic-ra.xmlデプロイメント・ディスクリプタ・ファイル内にConnectionFactoryオブジェクトを作成します。weblogic-ra.xmlファイルには、アダプタのランタイム接続パラメータが含まれています。

接続情報を追加してJNDI名を割り当てるには、Oracle WebLogic Server管理コンソールまたはWLSTスクリプトを使用して、リソース・アダプタの対応するweblogic-ra.xmlファイルを編集する必要があります。

コネクション・ファクトリの作成の詳細は、Oracle WebLogic ServerおよびOracle Coherenceのインストールと構成を参照してください。

次の手順では、Oracle WebLogic Server管理コンソールでDatabaseコネクション・ファクトリを設定する方法について説明します。

この項には次のトピックが含まれます:

- データソースの作成

- 接続プールの作成

2.19.1 データソースの作成

データソースを作成する手順は、次のとおりです。

1. http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

3. 「ドメイン構造」の下で、「サービス」、「JDBC」を選択し、「データ・ソース」をクリックします。

「JDBCデータ・ソースのサマリー」ページが表示されます。

4. 「新規」をクリックします。「新しいJDBCデータ・ソースの作成」ページが表示されます。

5. 新しいJDBCデータソースの識別に使用するプロパティについて次の値を入力します。

- 名前: soademoDatabase

- JNDI名: jdbc/soademoDatabase

- データベースのタイプ: Oracle
「データベース・ドライバ」はデフォルト値のままにしておきます。

6. 「次」を選択します。「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページが表示されます。

7. 「次」を選択します。「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページが表示されます。

8. 「接続プロパティ」ページで接続プロパティを入力し、「次へ」をクリックします。

「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページが表示されます。

9. 「構成のテスト」をクリックし、データベースの可用性および指定した接続プロパティをテストします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページの上部に接続テストに成功したことを示すメッセージが表示されます。

10. 「次」を選択します。「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページが表示されます。

11. ターゲットを選択して「終了」をクリックします。データソースが作成されました。

「JDBCデータ・ソースのサマリー」ページが表示されます。このページは、このドメインで作成されたJDBCデータ・ソース・オブジェクトについて要約しています。このリストには、作成したデータソースが表示されます。

2.19.2 接続プールの作成

接続プールを作成する手順は、次のとおりです。

1. http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

3. 「ドメイン構造」の下で、「デプロイメント」をクリックします。
「デプロイメントのサマリー」ページが表示されます。

4. 「デプロイメント」リストでデータベース・アダプタ名をクリックします。
「DbAdapterの設定」ページが表示されます。

5. 「構成」タブをクリックし、「アウトバウンド接続プール」タブをクリックします。
「アウトバウンド接続プールの構成表」が表示されます。

6. 「新規」をクリックします。

7. 「javax.resource.cci.ConnectionFactory」を選択し、「次へ」をクリックします。
「新しいアウトバウンド接続の作成」ページが表示されます。

8. 「JNDI名:」フィールドにeis/DB/soademoDatabaseと入力します。

注意:

この手順で入力するJNDI値は、「データソースの作成」の手順5で入力した値とは異なります。この手順で指定するJNDI名は、後でアプリケーションの構築時に作成するデータベース接続に入力する値と一致する必要があります。

9. 「終了」をクリックします。
このリソース・アダプタのアウトバウンド接続プール・グループとインスタンスの表を示す「DbAdapterの設定」ページが表示されます。

構成の変更内容は、新規デプロイメント計画に格納する必要があります。これを次のステップで行います。

10. 「パス」フィールドで、デプロイメント計画ファイルのパスを選択または入力します。パスは「.xml」で終了する必要があります。

注意:

AdminserverがコンピュータAで実行中で、Oracle SOA ServerがコンピュータBで実行中の場合は、Oracle SOA Serverで行った変更内容をアクティブ化する前に、デプロイメント計画ファイルをコンピュータBにコピーする必要があります。

デプロイメント計画をOracle SOA Serverコンピュータにコピーせずに変更内容をアクティブ化しようとすると、NullPointerExceptionがスローされます。

11. 「プロパティ」フィールドに、xADataSourceNameの値としてjdbc/soademoDatabaseを入力します。

12. 「保存」をクリックします。

注意:

この手順のように「保存」をクリックした時点ではプロパティが保存されません。かわりに、変更内容を保存するには[Enter]を押す必要があります。

13. 「ドメイン構造」の下で、「デプロイメント」をクリックします。
「デプロイメントの概要」が表示されます。

14. 次の手順を実行します。

a. 「DbAdapter」チェック・ボックスを選択し、「更新」を選択します。
「アプリケーション更新アシスタント」ページが表示されます。

b. 「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します」オプションを選択します。

c. 「次へ」をクリックして、「完了」をクリックします。
選択したデプロイメントが更新されたことを示す「デプロイメントのサマリー」ページが表示されます。

15. 「ドメイン構造」で、「デプロイメント」、「DbAdapter」、「構成」および「アウトバウンド接続プール」を順にクリックします。
ステップ11で入力したxADataSourceプロパティの値が「接続ファクトリ・インタフェース」タブに表示されます。

注意:

アウトバウンド接続プールについて新規の値を追加する場合、管理対象サーバーや管理サーバーを再起動する必要はありません。ただし、既存の接続プールのプロパティを編集した場合は、サーバーを再起動する必要があります。

2.20 アダプタ・コネクション・ファクトリの追加または更新

新規アダプタ・コネクション・ファクトリを追加するか、既存のアダプタ・コネクション・ファクトリを更新できます。

アダプタ・コネクション・ファクトリを追加または更新する場合は、次の手順のいずれかを実行して、コンポジットで新規アダプタ・コネクション・ファクトリのプロパティが使用されていることを確認する必要があります。

2.20.1 JCAファイルの変更

次の手順を実行します。

1. JCAアダプタ・コネクション・ファクトリ用の新規JNDIを作成します。コネクション・ファクトリの作成の詳細は、Oracle WebLogic ServerおよびOracle Coherenceのインストールと構成を参照してください。

2. デプロイされたコンポジットのJCAファイルを新規JNDIを指すように変更します。

コンポジットは新しく作成されたJNDIからプロパティを取得します。

2.20.2 構成プランの使用

1. JCAアダプタ・コネクション・ファクトリ用の新規JNDIを作成します。

2. コンポジットの構成プランを作成します。
構成プランを作成するには、JDeveloperの設計領域でcomposite.xmlを右クリックします。表示されたメニューで「構成プランの生成」をクリックします。構成プランが生成されます。

3. JCAファイルでJNDIの論理名を指定します。
たとえば、次のサンプルで、jndi-nameは論理JNDI名です。

<connection-factory location="jndi-name" adapterRef=""/>

4. 構成計画で、論理名を新規JNDIの絶対値に置き換えます。
たとえば、次の例では、論理JNDI名jndi-nameは、絶対値eis/MQ/MQSeriesAdapter7に置き換えられています。

<wsdlAndSchema
name="DQ1.wsdl|DQ1_mq.jca
|EQ1.wsdl|EQ1_mq.jca|monitor.config">
<searchReplace>
<search>jndi-name</search>
<replace>eis/MQ/MQSeriesAdapter7</replace>
</searchReplace>
</wsdlAndSchema>

コンポジットで新規アダプタ・コネクション・ファクトリのプロパティが使用される場合、再起動を回避するには、次の手順を実行する必要があります。

1. Oracle WebLogic Server管理コンソールのホーム・ページにログインします。

2. 「ドメイン構造」ペインで「デプロイメント」を選択します。
「Oracle WebLogic Server管理コンソール - デプロイメントのサマリー」ページが表示されます。

3. 新しいコネクション・ファクトリを追加したアダプタを選択します。

4. 「更新」をクリックします。
「アプリケーション更新アシスタント」ページが表示されます。

5. 「このアプリケーションを新しいデプロイメント・プランの変更とあわせた場所に更新します」オプションを選択します。

6. 「次へ」をクリックして、「完了」をクリックします。
選択したデプロイメントが更新されたことを示す「デプロイメントのサマリー」ページが表示されます。この手順を使用して、たとえば、再起動の必要なしにアダプタのエンドポイントを変更できます。

2.20.3 WebLogic Serverコンソールを使用した新規接続の作成

WebLogicコンソールを使用すると、JMSで使用するコネクション・ファクトリを作成できます。「Oracle WebLogic Server管理コンソールを使用した新規接続の作成」を参照してください

2.21 Oracle JCAアダプタで使用するデータソースの推奨設定

この項では、Oracle JCAアダプタで使用する非XAデータソースとXAデータソースの推奨設定について説明します。

マルチ・データ・ソースの推奨設定は、次のとおりです。

- test-frequency-secondsを5に設定します

- algorithm-typeをLoad-Balancingに設定します。

- data-source-listでは、カンマ区切りの子データソース・リストを指す必要があります。たとえば、(JDBC Data Source-0,JDBC Data Source-1)を指定します。

エンドポイント・プロパティがOracle RACデータベースに常駐する場合は、マルチ・データソースを使用します。

表2-3 に、Oracle JCAアダプタで使用するXAデータソースと非XAデータソースの推奨設定を示します。

表2-3 XAデータソースと非XAデータソースの推奨設定

XAデータソース

非XAデータソース

使用するドライバはoracle.jdbc.xa.client.OracleXADataSourceです。

使用するドライバはoracle.jdbc.OracleDriverです。

JDBC URLには次のフォーマットを使用する必要があります。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=service_name)(INSTANCE_NAME=inst1)))

XAデータソースと同じです。

次のプロパティを設定する必要があります。

<property>
<name>oracle.net.CONNECT_TIMEOUT</name>
<value>10000</value>
</property>

XAデータソースと同じです。

initial-capacityの値は0にする必要があります。

XAデータソースと同じです。

connection-creation-retry-frequency-secondsの値は10にする必要があります。

XAデータソースと同じです。

test-frequency-secondsの値は300にする必要があります。

XAデータソースと同じです。

test-connections-on-reserveの値はTRUEにする必要があります。

XAデータソースと同じです。

test-table-nameの値はSQL SELECT 1 FROM DUALにする必要があります。

XAデータソースと同じです。

seconds-to-trust-an-idle-pool-connectionの値は0にする必要があります。

XAデータソースと同じです。

global-transactions-protocolの値はTwoPhaseCommitにする必要があります。

global-transactions-protocolの値はNoneにする必要があります。

keep-xa-conn-till-tx-completeの値はTRUEにする必要があります。

該当なし

xa-retry-duration-secondsの値は300にする必要があります。

該当なし

xa-retry-interval-secondsの値は60にする必要があります。

該当なし

注意:

表2-3 に示した設定は、単一インスタンスとOracle RACデータベースの両方のタイプのデータベースに適用可能です。Oracle RACデータベースの場合は、エンドポイント用に作成されたマルチ・データソースを構成するデータソースに、これらの設定を使用する必要があります。詳細は、Oracle RACのドキュメント(http://www.oracle.com/technetwork/database/options/clustering/documentation/index.html)を参照してください。

表2-3 で説明している設定の適用に加えて、『Oracle WebLogic Server JTAアプリケーションの開発』のOracle Thin/XAドライバの使用に関する手順を実行する必要があります

これらの手順は、XAドライバを使用するデータソースに必須です。前述のリンクで記述されている手順を実行した後、次のSQL文を実行してWLS JTAリカバリが機能できるようにする必要があります。

grant select on sys.dba_pending_transactions to public
GRANT FORCE ANY TRANSACTION TO public
grant execute on sys.dbms_xa to public

2.22 エラー処理

利用できるエラー処理機能を次の項に示します。これらの拒否ハンドラは、同期プロセスでのみ適用可能です。非同期プロセスや一方向プロセスには適用されません。

この項には次のトピックが含まれます:

- インバウンド相互作用のエラー処理

- アウトバウンド・アダプタ相互作用のエラー処理

- メッセージ・エラーの処理: サンプル・シナリオ

2.22.1 拒否されたメッセージの処理

サービス・インフラストラクチャにポストされる前にエラーになったメッセージは、拒否されたメッセージと呼ばれます。たとえば、CSVフォーマットのデータを含んだファイルを取得し、XMLフォーマットに(NXSDを使用して)変換しようとします。その場合、変換中になんらかのエラーがあると、このメッセージは拒否され、ターゲット・コンポジットにはポストされません。

拒否されたメッセージを生成するのは、主としてアダプタとバインディング・コンポーネントです。

2.22.1.1 下流で発生したエラーまたはフォルトの処理方法

同期フローの下流で発生したエラーまたは障害は、インバウンド・アダプタによって次のように処理されます。

- 例外が再試行不可能な場合は、即座に拒否されます。

- 例外が再試行可能な場合は、無制限に再試行されます。

- 再試行はjca.retry.countの値(構成されている場合)と同じ回数だけ行われ、再試行回数の上限に達した場合は拒否されます。

バインディング・レベルでエラーになったメッセージはアダプタによって拒否されます。つまり、サービス・インフラストラクチャ・レイヤーに入る前にエラーになります。

拒否されたメッセージは、すべてペイロードとともにデータベースに格納されます。拒否メッセージは後から問い合せることができます。

フォルトはバインディングまたはリモートとして分類することもできます。通常、リモート・フォルトはデータベースの接続停止などの一時的な障害で再試行可能であるのに対し、バインディング・フォルトは非一時的な障害で再試行不可能としてマークされます。状況に応じて、これらの非一時的な障害も修正できます。たとえば、MQ Seriesアダプタのターゲット・キューがデータベースの完全または一意の制約違反になるようなフォルトは修正可能です。ただし、変換やトランスフォーメーションによる検証の失敗などの特定の非一時的な障害は、コンポジットを再デプロイせずに修正することはできません。バインディング・フォルトとリモート・フォルトの両方が原因で拒否されたメッセージは、リカバリ可能としてマークされます(手動リカバリの場合)。リカバリの成功はシナリオに依存します。手動リカバリが失敗する場合は、失敗したインスタンスを調査してアクションを開始する必要があります。

この項には次のトピックが含まれます:

- 拒否ハンドラの構成

- 拒否されたメッセージのチェック

詳細は、「アダプタ内での相関サポート」を参照してください。

2.22.1.2 拒否ハンドラの構成

10.xリリースでは、拒否ハンドラはOracle BPELプロセスのデプロイメント・ディスクリプタ(bpel.xml)内で定義されていました。

ただし、11gリリースでは、フォルト・ポリシーを使用して拒否ハンドラを定義する必要があります。

インバウンド拒否ハンドラの場合、指定できるアクション・ハンドラは1つのみです。

2.22.1.2.1 フォルト・ポリシーの作成

次の手順に示すように、fault-policies.xmlおよびfault-bindings.xmlという2つのファイルを作成し、JDeveloperのSOAプロジェクト・ディレクトリにコピーする必要があります。

1. 拒否されたメッセージに関するフォルト・ポリシーをfault-policies.xmlファイル内で定義します。このファイルは、JDeveloperのプロジェクト・ディレクトリにcomposite.xmlとともに格納されています。

次にフォルト・ポリシーの例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies>
<faultPolicy version="2.0.1" id="RejectedMessages">
<Conditions> <!-- All the fault conditions
are defined here -->
<faultName xmlns:rjm="http://schemas.oracle.com
/sca/rejectedmessages" name="rjm:
<SERVICE_NAME>"> <!-- local part of fault
name should be the service name-->
<condition>
<action ref="writeToFile"/> <!-- action
to be taken, refer to Actions section
for details of the action -->
</condition>
</faultName>
</Conditions>
<Actions> <!-- All the actions are defined here -->
<Action id="writeToFile">
<fileAction>
<location>/tmp/rej_msgs</location>
<fileName>emp_%ID%_
%TIMESTAMP%.xml</fileName>
</fileAction>
</Action>
</Actions>
</faultPolicy>
</faultPolicies>

2. 次の例に示すように、フォルト・ポリシーをfault-bindings.xml内のコンポジットのサービス・エンドポイントに関連付ける必要があります。

<faultPolicyBindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel
/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance">
...
<service faultPolicy="RejectedMessages">
<name>Read</name>
</service>
...
</faultPolicyBindings>

3. fault-policies.xmlおよびfault-bindings.xmlファイルをSOAコンポジットのプロジェクト・ディレクトリにコピーします。

4. SOAコンポジット・プロジェクトをデプロイします。

注意:

「拒否ハンドラの構成」の説明に従って拒否ハンドラを構成しなければ、デフォルトのファイルベース拒否ハンドラが処理を開始し、拒否されたメッセージは<domain_home>/rejmsgs/<wls_server_name>/<composite_name>に移動されます。

また、Oracle BPEL Process Manager (Oracle BPEL PM)と同じフォルト・ポリシーで、メディエータ・コンポーネントで拒否されたメッセージを構成することもできます。

2.22.1.3 拒否されたメッセージのチェック

拒否メッセージはrejected_message表に格納されます。

次のいずれかの手順を使用して、拒否されたメッセージをチェックできます。メッセージを取得し、固有の実装に応じて追加処理を実行できます。

- データベースからのチェック

- Fusion Middleware Controlコンソールからのチェック

2.22.1.3.1 データベースからのチェック

データベースからのチェックを行うには、データベースにsoainfraスキーマとして接続し、次のSQLコマンドを実行する必要があります。

select * from rejected_message

2.22.1.3.2 Fusion Middleware Controlコンソールからのチェック

「ダッシュボード」タブの「最新のフォルトと拒否メッセージ」セクションまたは「フォルト・メッセージと拒否メッセージ」タブで、拒否されたメッセージを表示できます。

Fusion Middleware Controlコンソールを拒否されたメッセージのチェックに使用する方法の詳細は、次を参照してください。

- 『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のインバウンド・アダプタに対する最新のフォルトと拒否メッセージの監視に関する項。

- 『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のインバウンド・アダプタに対するフォルトと拒否メッセージの監視に関する項

2.22.1.3.3 メッセージ・エラーの処理: サンプル・シナリオ

この項では、メッセージ・エラーの処理方法についてサンプル・シナリオを使用して説明します。

図2-10 に示すように、2つのコンポジットComposite1およびComposite2があり、それぞれにOracle BPELプロセスがあり、ローカル・リソースとXAリソースが混在しています。

図2-10 サンプル・シナリオ: メッセージ・エラーの処理

メッセージがすべてのキュー(Q1、Q2およびQ3)に正常に配信された場合、トランザクションは正常にコミットされます。

メッセージがQ1 (またはいずれかのキュー)に配信されず、キューQ2およびQ3に配信された場合、トランザクションは3つのメッセージすべてをロールバックする必要がありますが、これは、すべてがXAリソースであり、XAユニットのいずれかに例外が発生したためです。

ロールバック例外は、Q1が失敗した2番目のコンポジットにのみスローされます。トランザクションは3つのキューすべてのメッセージをロールバックするかわりにQ2とQ3をコミットします。

失敗したキューが1つのみで他の2つにはメッセージが正常に配信された場合も、トランザクションですべてのキューをロールバックするには、コールされたコンポジット(Composite2)のcomposite.xmlファイルを次のサンプル・コードに示すように変更する必要があります。

例 - Composite2のcomposite.xmlの変更

<component name="BPELProcess1">
<implementation.bpel src="BPELProcess1.bpel"/>
<property name="bpel.config.transaction">
required</property>
</component>

これにより、プロパティbpel.config.transactionの値がrequiredに設定され、失敗したキューが1つでもトランザクションですべてのキューがロールバックされるようになります。

bpel.config.transactionプロパティをrequiredの値に設定すると、Oracle BPELエンジンは新規トランザクションを作成せず、コール元のトランザクションを使用して同期リクエストを効果的に処理します。したがって、いずれかの時点でトランザクションがロールバックすると、そのトランザクションでの実行内容は何もコミットされません。

2.22.2 インバウンド相互作用のエラー処理

拒否メッセージ・ハンドラを指定することにより、インバウンド・アダプタでのエラー処理方法を決定できます。

2.22.2.1 メッセージ・エラーの拒否ハンドラ

拒否ハンドラを作成して、メッセージ・エラーを処理できます。メッセージ・エラーには変換時のエラー、相関IDの不一致、メッセージ受信後のXML解析エラーなどがあります。

メッセージ・エラーで使用可能な拒否ハンドラ

再試行可能性の点からエラー処理を検討する前に、使用可能なエラー・ハンドラを理解することが重要です。

次に示すのは、フォルト・ポリシーで構成できるシステム定義のエラー・ハンドラです。

- Webサービス・ハンドラ

- カスタムJavaハンドラ

- JMSキュー

- ファイル

2.22.2.1.1 Webサービス・ハンドラ

拒否されたメッセージは、Webサービスを呼び出して処理できます。Webサービスを使用してこれらのエラーを処理する場合は、次の例に示すように、ターゲット・サービスによって実装された定義済のWSDLインタフェース、Webサービス呼出し用のSOAPバインディング、Webサービスの添付として渡されるネイティブ・ペイロードを実装する必要があります。

- <Action id="ora-ws">
<invokeWS uri="WebServiceURI"/>
<!-- format - <Absolute wsdl path>|service name|port name -->
</Action>

Webサービス・ハンドラのWSDLインタフェースには、単一のポート・タイプ、1つの入力操作、および入力メッセージ用スキーマが必要です。これを次の例に示します。

例 - Webサービス・ハンドラのWSDLインタフェース

<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/pcbpel/errorHandling"
xmlns:tns="http://xmlns.oracle.com/pcbpel/errorHandling"
elementFormDefault="qualified">
<element name="RejectedMessage" type="tns:RejectedMessageType">
<complexType name="RejectedMessageType"/>
<sequence>
<element name="MessageHeader" type="string"/>
<!-- base64 encoded string -->
<element name="MessagePayload" type="string"/>
<!-- base64 encoded string -->
<element name="RejectionReason" type="string"/>
</sequence>
<attribute name="RejectionId" type="string"/>
</complexType>
</schema>

2.22.2.1.2 カスタムJavaハンドラ

エラー処理の別のオプションでは、エラーを転送する定義済のJavaフレームワーク(インタフェース)を作成します。次の例に示すように、ターゲット・クラスによってJavaインタフェースを実装できます。

- <Action id="ora-custom">
<javaAction className="mypackage.myClass"
defaultAction="ora-terminate">
<returnValue value="SUCCESS" ref="ora-file"/>
<returnValue value="FAILED" ref="ora-ws"/>
</javaAction>
</Action>

インタフェース自身はフォルト・リカバリ・クラスを指定します。インタフェースの例については、次のスニペットを参照してください。

package oracle.integration.platform.faultpolicy;
public interface IFaultRecoveryJavaClass
{
public void handleRetrySuccess
( IFaultRecoveryContext ctx);
public String handleFault( IFaultRecoveryContext ctx);}

2.22.2.1.3 JMSキュー

拒否メッセージは、適切なコンテキストとペイロードとともにJMSメッセージとしてJMSキューにエンキューすることはできませんが、次の2つの例に示すようにAQアダプタを使用してこのタスクを実行できます。

最初の例は、スタンドアロン・データベースを使用します。

例 - スタンドアロン・データベースとAQアダプタを使用した拒否メッセージのエンキュー

<faultPolicies>
<faultPolicy version="2.0.1" id="MQ_ServiceFaults_MED">
<Conditions>
<faultName xmlns:rjm="http://schemas.oracle.
com/sca/rejectedmessages" name="rjm:DQ">
<condition>
<action ref="ora-enqueue"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-enqueue">
<enqueue uri="jdbc:oracle:thin:
@//myhost.com:1521/orcl#scott/tiger#REJ_MSG_Q" />
</Action>
</Actions>
</faultPolicy>
</faultPolicies>

2番目の例は、Oracle RACデータベースとともに使用されます。

例 - Oracle RACデータベースとAQアダプタを使用した拒否メッセージのエンキュー

<Action id="ora-queue">
<enqueue uri="QueueURI"/> <!-- QueueURI format  -
jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS_
LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<host1>)(PORT=<port1>))(
ADDRESS=(PROTOCOL=TCP)(HOST=<host2>)(PORT=<port2>)))(CONNECT_DATA=(SERVICE_
NAME=<service_name>)))#<un>/<pw>#queue -->
</Action>

2.22.2.1.4 ファイル

拒否されたメッセージをファイルに格納することによって、メッセージのエラー・ハンドラを作成します。次の例に示すように、適切なコンテキストとともにペイロードを格納できます。ペイロード・ファイルは、構成した場所に作成されます。

<Action id="ora-file">
<fileAction>
<location>FOLDER_LOCATION</location>
<fileName>FILE_NAME</fileName>
<!-- FILE_NAME will support %ID%(rejected message instance id) or %TIMESTAMP% wildcards -->
</fileAction>
</Action>

データベース内でのエラーのペイロードの永続性は、デフォルトで有効になっています。ファイル・アダプタ・ハンドラの場合にのみ、拒否されたメッセージのプロパティをすべて含んだメタデータ・ファイルが作成されます。

たとえば、このメタデータ・ファイルにはインバウンド方向やファイル名などの情報が含まれます。メタデータ・ファイルの場所はペイロード・ファイルと同じで、ネーミング・パターンは<FILE_NAME>_metadataです。

拒否メッセージの再発行には、ペイロードの永続性が必要です。ペイロードはデータベースに格納され、Fusion Middleware Controlコンソールを介してペイロード表示機能を使用できます。デフォルトのエラー・ハンドラへのペイロードの指定に加えて、メッセージ/ペイロードは構成された各エラー・ハンドラに完全に指定されます。

2.22.2.2 インバウンドの再試行可能なエラー

インバウンドの再試行可能なエラーは通常、一時的な接続エラーです。インバウンド・アダプタによって再試行が行われるのは、アウトバウンド・バインディングによってスローされた同期プロセスの再試行可能なエラーのみです(回数はデフォルトでは無制限であり、jca.retry.countプロパティの設定によって制限されます)。JTAトランザクションはいずれも再試行の前にロールバックされます。

アウトバウンド・アダプタによってスローされる再試行可能なエラーの例には、接続エラーだけでなく、一時的な権限エラーまたはリソース制限エラー、あるいはその両方も含まれます。

「データがすでに存在します」などのエラー(主キー・エラーなど)は再試行できません。また、メッセージ相関IDエラーは再試行できません。

設定された再試行回数の上限に達した場合、拒否メカニズムによってエラーが処理されます。

2.22.2.2.1 再試行可能なエラーを処理するインバウンド・アダプタの構成

インバウンド・アダプタを構成して、インバウンドの再試行可能なエラーを処理できます。次のプロパティはインバウンド相互作用の再試行可能な例外のためにサポートされており、composite.xmlファイル内に指定できます。

デフォルトでは、インバウンド・エラーは無制限に再試行されますが、アダプタの再試行はコンポジット(ローカル)アプリケーションのレベル、またはグローバル・レベルで行われます。

コンポジットでプロパティを構成した後、サービス・レベルではプロパティの構成に意味があります(たとえば、拒否前に再試行回数を構成すると、間隔プロパティの値はデフォルト値になります)。

composite.xmlファイルでは、次のプロパティを指定できます。

- jca.retry.count
拒否までの再試行回数の最大値を指定します。この値の指定は、他のプロパティの値を指定するための前提条件です。

- jca.retry.interval
再試行間の時間間隔(秒単位)を指定します。

- jca.retry.backoff
再試行間隔の増加係数(正の整数)を指定します。

- jca.retry.maxInterval
再試行間隔の最大値、つまりバックオフ > 1の場合の上限を指定します。

2.22.2.2.2 composite.xmlファイルでのインバウンド再試行プロパティの指定

コンポジット・アプリケーションのxmlディスクリプタを変更して、再試行に適用されるプロパティを指定できます。前述のプロパティ・リストは、次の例に示すようにJDeveloperのcomposite.xmlファイルで指定します。

<service name="Inbound">
<interface.wsdl interface="http://
xmlns...#wsdl.interface(Inbound_PortType)"/>
<binding.jca config="Inbound_db.jca">
<property name="jca.retry.count">5</property>
<property name="jca.retry.interval">1</property>
<property name="jca.retry.backoff">2</property>
<property name="jca.retry.maxInterval">6</property>
</binding.jca>
</service>

再試行可能な例外については、jca.retry.countの値を再試行の実行回数に設定する必要があります。

たとえば、jca.retry.countの値を10に設定すると、再試行は10回行われます。

ただし、jca.retry.countの値が設定されていない場合、再試行は無制限に実行されます。これは再試行可能なエラーのデフォルトです。

注意:

エラーに関してインバウンド・アダプタが無限に再試行すると、再試行のたびに別のコンポジット・インスタンスが作成されるため、複数のコンポジット・インスタンスが作成されることになります。

2.22.2.2.3 インバウンド・アダプタ・エンドポイントのjca.retry. countのデフォルト値の変更

再試行を制限するグローバル・プロパティを変更して、jca.retry.countのデフォルト値を(無限から)有限数に変更できます。

この場合、jca.retry.countのデフォルト値を有限数に設定すると、特定のインバウンド・アダプタのエンドポイントのjca.retry.countプロパティ値を明示的に構成しない場合にも、グローバル・デフォルトが有効になります。

グローバル・デフォルトをcomposite.xmlの値とともに指定した場合、composite.xmlで指定した値によってグローバル値がオーバーライドされます。

Fusion Middleware ControlコンソールのMBeanブラウザ(アダプタMbean)を使用して、このグローバル・プロパティを変更できます。この変更は、すべての現在および将来のエンドポイントに対して即座に有効になります。

2.22.2.2.4 MBeansブラウザを使用したグローバル・プロパティの変更

Fusion Middleware ControlのMBeanブラウザ(アダプタMbean)を使用して、グローバル・プロパティを変更するには、次の手順を実行する必要があります。

1. http://servername:portnumber/emにナビゲートします。

Fusion Middleware Controlコンソールにホーム・ページが表示されます。

2. 左ペインのナビゲータで「SOA」フォルダの「soa-infra」を右クリックします。

「soa-infra」ページが表示されます。

3. 図2-11 に示すように、「SOAインフラストラクチャ」メニューで、「管理」、「システムMBeanブラウザ」の順に選択します。

「システムMBeanブラウザ」ページが表示されます。

図2-11 「soa-infra」ページ

4. 図2-12 に示すように、「oracle.as.soainfra.config」、「サーバー」、「AdapterConfig」、「アダプタ」の順に選択します。

図2-12 「soa-infra」ページ: システムMBeanブラウザ

5. GlobalInboundJcaRetryCount属性を変更します(グローバル・プロパティの例を参照)

2.22.2.3 インバウンドの再試行不可能なエラー

再試行不可能なエラーは通常、変換またはメッセージ解析の結果生成されます。

インバウンド・アダプタはインバウンド・メッセージを拒否することによって、エンタープライズ情報システムからスローされた再試行不可能なエラーを処理します。エラーが再試行不可能な場合は、拒否ハンドラを使用して再試行不可能なエラーを処理する必要があります。

2.22.2.3.1 再試行不可能なエラーの例

エンタープライズ情報システムとの相互作用からスローされた再試行不可能なエラーの例には、次が含まれます。

- 主キーの違反

- キューが存在しない

- マスター・レコードが存在しない

- ペイロードをシリアライズできない

再試行不可能なエラーは、単に再試行しても解決されないと予想されるため、再試行されません。たとえば、あるファイルからのメッセージがメディエータを介してインバウンド・ファイル・アダプタに送信される場合があります。メディエータには、データベース表にデータを挿入するアウトバウンド・データベース・アダプタへの順次ルーティングがあります。DBアダプタでは挿入操作が実行中であるため、固有の制限エラーが発生する場合があります。この固有の制限エラーは、次のように処理されます。

- アウトバウンド・データベース・アダプタによって再試行不可能なエラーと見なされます。

- 伝播によってインバウンド・アダプタに戻ります。

- 拒否ハンドラを使用して、インバウンド・アダプタによっても再試行不可能なエラーと見なされます。定義されているフォルト・ポリシーがある場合は、アダプタによって使用されます。

メディエータで変換エラーが発生する可能性があります。この種のエラーは再試行不可能です。WSDLのシグネチャに応じて、エラーは処理を行うインバウンド・アダプタに戻されます。

2.22.3 アウトバウンド・アダプタ相互作用のエラー処理

アウトバウンド相互作用エラーは、アダプタからのアウトバウンド相互作用を持つメッセージで発生します。

この項では、これらのアウトバウンド相互作用エラーの再試行可能性と不可能性について説明し、関連する設定可能なプロパティの概要について示します。

2.22.3.1 アウトバウンド・アダプタ・エラー処理の再試行可能なエラー

アウトバウンドの再試行可能なエラーは、composite.xmlファイルのjca.retry.countの値に基づいて再試行できます。

2.22.3.1.1 composite.xmlファイルでのアウトバウンド・エラー処理の再試行可能プロパティの設定

アウトバウンド・エラー処理の再試行可能な例外については、jca.retry.countの値を再試行の実行回数に設定する必要があります。

たとえば、jca.retry.countの値を10に設定すると、再試行は10回行われます。

ただし、jca.retry.countの値が設定されていない場合は、コンポジットの一部にフォルト・ポリシーが含まれていれば、フォルト・ポリシーによって再試行が実行されます。

2.22.3.1.2 例: アウトバウンド相互作用に関する再試行可能な例外の値の設定方法

次のコード・スニペットは、アウトバウンド相互作用に関する再試行可能な例外についてcomposite.xmlファイルに値を設定する方法の一例です。

再試行は5分に設定され(間隔は1分)、他のプロパティは適切に構成されます。前述のように、追加のプロパティが意味を持つのは、jca.retry.countプロパティが指定されている場合です。

<reference name="Outbound">
<interface.wsdl interface="http://
xmlns...#wsdl.interface(Outbound_PortType)"/>
<binding.jca config="Outbound_jms.jca">
<property name="jca.retry.count">5</property>
<property name="jca.retry.interval">1</property>
<property name="jca.retry.backoff">2</property>
<property name="jca.retry.maxInterval">6</property>
<property name="jca.retry.maxPeriod">30</property>
</binding.jca>
</reference>

2.22.3.2 アウトバウンド相互作用処理に関する再試行不可能なエラー

アウトバウンド相互作用に関する再試行不可能な例外は、fault-policy.xmlファイルを介して実行可能な再接続試行の最大回数を定義することで処理が可能で、このファイルは、再試行不可能なエラーに予期される動作を設定します。

このフォルト・ポリシー・ファイルでは、次の例に示すように、再接続試行のパラメータを指定します。これには、次のものがあります。

- 再接続の再試行回数(retryCount)

- 再接続の再試行間隔(retryInterval)

- 接続の再試行に関する指数関数的バックオフ値(exponentialBackoff)

すべての時間測定は秒単位で指定されます。

例 - 再接続試行のパラメータの指定

<faultName xmlns:bplex="http://schemas.oracle.com/bpel/extension" name='bplex;bindingFault">
<condition>
<action ref="ora-retry"/>
</faultName>
</condition>
<Actions>
<Action id="ora-retry">
<retry>
<retryCount>10</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff>2</exponentialBackoff>
</retry>
</Action>
</Actions>

次の例に示すように、faultPolicy ConnectionFaultsと参照名writeMessageToQueueを使用して、フォルト・ポリシーをfault-bindings.xmlファイル内のコンポジットの参照エンドポイントに関連付ける必要があります。

例 - フォルト・ポリシーとコンポジットの参照エンドポイントの関連付け

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<reference faultPolicy="ConnectionFaults">
<name>writeMessageToQueue</name>
</reference>
</faultPolicyBindings>

有効な結果が生成される前に構成済の再試行回数に達すると、サービス・インフラストラクチャ起動例外がスローされます。

2.22.3.2.1 フォルトの伝播

サービス・インフラストラクチャ起動例外のタイプの伝播は、アウトバウンド・アダプタによって報告されたエラーに対して、インバウンド・アダプタが応答できるようにするために重要です。

図2-13は、アダプタによるサービス・インフラストラクチャの同期呼び出しにおけるフォルトの伝播を示します。この後、下流のアダプタを呼び出します。

この図で、サービス・インフラストラクチャ起動例外は、下流のアダプタから介して呼び出し元のアダプタに伝播しています。

図2-13 フォルトの伝播

2.22.3.2.2 フォルト・ポリシー・メカニズムが動作しない2つのケース

次の2つのケースでは、フォルト・ポリシー・メカニズムが動作しません。

- XAモードのアウトバウンド・アダプタ

- メディエータの順次ルーティングでのアウトバウンド・アダプタ

XAモードのアウトバウンド・アダプタ

フォルト・ポリシー・メカニズムは、XAモードのアウトバウンド・アダプタでは機能しません。

たとえば、XAモードで、フォルト・ポリシーをアウトバウンド・アダプタの失敗時に再試行させる必要がある場合、フォルト・ポリシーは再試行されず、この失敗の発生前に成功していたアウトバウンド・アダプタはメッセージをロールバックしません。

メディエータの順次でのアウトバウンド・アダプタ

フォルト・ポリシーは、メディエータの順次ルーティングで起動されたアウトバウンド・アダプタでも機能しません。これは、メディエータのフォルト・ポリシーはパラレル・ルーティング・ルールにのみ適用可能であるためです。

2.23 JCAアダプタとOracle Web Services Managerの統合による監査証跡内の機密データの保護

アウトバンド・アダプタにメッセージを送るBPELプロセスに対してインバウンド・アダプタがメッセージを送信するシナリオにおいて、JDeveloperとFusion Middleware Controlを介してOracle Web Services Manager (OWSM)を使用し、ペイロードにPII (個人の身元を特定する情報)ポリシーを適用できます。

この方法でOWSMを使用すると、暗号化および復号化されるようにアダプタ・ペイロードを構成できます。BPEL監査証跡を調査する個人には、ユーザーが暗号化するように指定したデータは表示されません。

暗号化するインバウンドからペイロード要素を選択します。対応するエンドポイントに対して、復号化する同じ要素を選択する必要もあります。

一般的に、Webサービスのセキュリティには、認証、許可(またはアクセス制御)、機密およびプライバシ保護、整合性、否認防止などのいくつかの側面があります。

アダプタでこれを使用することは、個人の身元を特定する機密情報(PII)の維持に関連します。

2.23.1 エンドポイントへのJCA暗号化のアタッチ

PIIポリシーをペイロードに適用するには、JCAの暗号化および復号化をJCAエンドポイントで実現します。PIIの暗号化の目的は、データがシステム内部にあるときにその安全を守ることです。

そのためには、独自のマップ名とキー名を含むセキュリティ資格証明をエンドポイントのデータに対して指定します。エンドポイントに指定するセキュリティ資格証明は、指定するマップ名とキー名で一意に識別されます。

次の手順を実行して、JCAの暗号化および復号化をサービス・エンドポイントと参照エンドポイントにアタッチします。表示する例は、ファイル・サービスです。

1. Fusion Middleware Controlにログインします。

2. 「WebLogic Server」→「セキュリティ」→「資格証明」→「マップの作成」を選択します。「マップの作成」をクリックします。「マップの作成」ダイアログが表示されます。

図2-14 資格証明ストアへのナビゲートおよびマップ作成プロセスの開始

3. 図2-15 に示すとおり、「マップ」ダイアログにoracle.wsm.securityを入力して保存します。

図2-15 マップの作成、「マップの作成」ダイアログの表示、指定したマップ名の指示

4. キーの作成機能が有効になります。図2-16 に示すように、マップに関連付けるキー名を入力します。

図2-16 指定したセキュリティ・マップを使用したセキュリティ・キーの作成

エントリの記入が完了すると、図2-17 のようにダイアログが表示されます。キーを作成するときにマップを指定する必要があります。

図2-17 指定したセキュリティ・マップを使用したセキュリティ・キーの作成および入力値

5. JDeveloperで、ファイル・サービス・エンドポイントで暗号化キーをアタッチし、コンポジット設計を完了するための式ビルダーを選択します。図2-18 にサービス・エンドポイントの「機密データの暗号化」オプションの使用方法を示します。

図2-18 サービス・エンドポイントでの暗号化キーのアタッチ

「リクエスト・データの暗号化」ダイアログを図2-19 に示します。「編集」アイコンを選択してPIIポリシーを編集し、暗号化するファイルを指定します。

図2-19 「リクエスト・データの暗号化」ダイアログ

6. 「暗号化するフィールドを選択します」ダイアログが表示されます。「追加」ボタンをクリックして、式ビルダーを表示します。

図2-20 「暗号化するフィールドを選択します」ダイアログの使用

7. 「式ビルダー」に、暗号化のJCAポリシーをアタッチできる変数リストが表示されます。

図2-21 式ビルダーの使用によるポリシーをアタッチできる変数リストの取得

8. 最後に、サービス・ポイントで暗号化をアタッチしたのと同じ方法で、参照エンドポイントで復号化をアタッチする必要があります。それぞれのエンドポイントに暗号化および復号化を指定したら、ペイロードで選択したデータへのPIIポリシーの適用が完了します。

SOAおよびセキュリティの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

2.24 アプリケーションのテスト

デプロイされたSOAコンポジット・アプリケーションのインスタンスを実行およびテストできます。このようなインスタンスの実行およびテストにより、次のことが可能になります。

- コンポジット・アプリケーションの管理

- コンポジットのインスタンスの起動

- コンポジットのインスタンスの追跡

- 詳細なコンポーネント・インスタンスの監査証跡の表示

アプリケーションのテストの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

2.25 Oracle JCAアダプタのトレース・レベルの設定

次のタイプのアダプタについて、トレース・レベルを設定します。

- Oracle JCAアダプタとOracle Adapter for Oracle Applications: ロガーoracle.soa.adapterでログ・レベルをTRACE:32のように設定します。
アダプタのトレース・レベルの設定の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

- パッケージ・アプリケーション・アダプタ: アウトバウンド相互作用の場合は、weblogic-ra.xmlファイル内でパッケージ・アプリケーション・アダプタのLoglevelプロパティを設定します。

- レガシー・アダプタ: Oracle Studioを使用して、Oracle Connectとメインフレーム・サーバーのトレース・レベルを設定できます。

2.25.1 Oracle JCAアダプタのトレース・レベルの設定方法

Fusion Middleware Controlコンソールを使用してトレース・レベルを設定するには、次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。

Fusion Middleware Controlコンソールのホーム・ページが表示されます。

2. 左ペインの「ナビゲータ」で「SOA」フォルダの「soa-infra」を右クリックします。

コンソールによってメニューが表示されます。

3. 図2-22 に示すように、「ログ」→「ログ構成」の順に選択します。

図2-22 「ログ構成」ページへのナビゲート

「ログ構成」ページが表示されます。

4. ロガー名リストで「oracle.soa.adapter」を探し、「Oracle Diagnostic Loggingレベル(Javaレベル)」フィールドでログ・レベルを変更します。この例では、図2-23に示すようにリストから「Trace:32 (FINEST)」 を選択します。

注意:

コンピュータの再起動と再起動の間もログ・レベルを確実に保持するには、「表示」リストから「永続ログ・レベル状態のログ出力」を選択します。デフォルトでは、ログ・レベルはランタイム・ログ出力用に設定されます。ランタイム・ログ出力は、コンポーネントの再起動と再起動の間に保持されません。

図2-23 「ログ構成」ページ

詳細は、「アダプタ・ログの表示」を参照してください。

2.26 アダプタ・ログの表示

次のように、ログを表示できます。

- Oracle Adapter for Oracle Applications: これらのアダプタでは、ログ・ファイルをOracle Diagnostic Logging (ODL)フォーマットでリダイレクトするJCAバインディング・コンポーネントのLogManagerインタフェースが実装されます。アウトバウンド相互作用とインバウンド相互作用の両方について、ログ・ファイルがsoa-diagnostic.logファイルにリダイレクトされます。
server-soa管理サーバーにデプロイされているOracle SOA Suiteのログ・ファイルは、次の場所にあります。

MW_HOME/user_projects/domains/domain_name/servers/server-soa/logs/soa-diagnostic.log

ログ・ファイルの検索と閲覧の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

- パッケージ・アプリケーション・アダプタ: このタイプのアダプタはJ2CA 1.5標準の一部ではないため、LogManagerインタフェースは実装されません。したがって、システム・コンポーネントの場合、ログ出力は次の場所にリダイレクトされます。
ORACLE_INSTANCE\diagnostics\logs\component_type\component_name。アウトバウンド相互作用の場合、ログは同じ場所に移動されます。これに対して、インバウンド相互作用の場合、ログはsoa-diagnostic.logにリダイレクトされます。

- レガシー・アダプタ: レガシー・アダプタは、J2CAリソース・アダプタとOracle Connectで構成され、Oracle Connectはメインフレーム・アプリケーションおよびデータ・ストアと通信するためのネイティブ・アダプタで構成されます。Oracle Connectのログは、Oracle Studioを使用して表示できます。Oracle Studioは、メインフレーム・アダプタのデザインタイム・ツールであり、Oracle Connectの管理ツールです。Oracle Connectは、デーモン・ログ、ワークスペース・ログ、サーバー・プロセス・ログなど、様々なタイプのログを生成します。

詳細は、「Oracle JCAアダプタのトレース・レベルの設定」を参照してください。

2.27 アダプタの診断能力ダンプ

診断能力ダンプの詳細は、SOA管理ガイドのサポートされるSOAアダプタの診断能力ダンプに関する項を参照してください。

2.28 カスタム・アダプタの作成

カスタムJCAアダプタ・ウィザードをJDeveloper IDEで汎用アダプタ・ウィザードとして構成して、相互作用/アクティブ化の仕様、プロパティおよびデフォルト値を構成ファイルから読み取って表示できます。ウィザードでは仕様の選択、デフォルトのプロパティ値のオーバーライド、新しいプロパティの追加を行うことができます。カスタム・アダプタ・ウィザードには、次のようないくつかの目的があります。

- カスタム・アダプタ・ウィザードはそのままで使用して、カスタム・ランタイプ・アダプタをサポートできます。カスタム・アダプタを使用する場合は、カスタム・アダプタ構成ファイルcustomAdapter-config.xmlを指定(または拡張)します。

- より具体的なアダプタを作成する場合は、カスタム・アダプタ・クラスを変更または拡張できます(たとえば、アダプタにあわせてテキストを変更できます)。

- カスタム・アダプタ・ウィザードを使用して、JCAアダプタ・フレームワークを使用し、SCAEndpointインタフェースにフックすることで、新しいアダプタ・ウィザードを作成する方法についての簡単な例を確認できます。
SOA JDeveloper拡張をインストールすると、カスタム・アダプタのJavaソース・ファイルは<JAVA_HOME> /jdeveloper/integration/adapters/samples/customに配置されます

2.28.1 カスタム・アダプタの構成

カスタム・アダプタは、デフォルトではJDeveloperコンポーネントに表示されません。次に、カスタム・アダプタがJDeveloperコンポーネントに表示されるようにextension.xmlファイルを更新する推奨の方法を示します。

1. アーカイブ・マネージャで <jdev_home>\soa\plugins\jdeveloper\extensions\oracle.sca.ui.adapters.jarを開きます。

2. META-INF/extension.xmlを検索して選択し、「抽出」を選択します。jarが含まれている現在のファイルにファイルを格納できます。

3. Linuxのコマンド・ラインから、抽出したextension.xmlファイルを編集します(viまたはemacsを使用)。

4. カスタム・アダプタのエントリのコメントを外し、ファイルを格納します。

5. アーカイブ・マネージャで、「追加」ボタンを押します(アーカイブするファイルを追加します)。extension.xmlファイルを選択して、「追加」をクリックします。

6. JDeveloperを再起動します。

<JDEV_HOME>\jdeveloper\integration\seed\soa\configuration\ custom\Adapter-config.xmlファイルには、カスタム・アダプタの詳細なオプション(connection-factoryの場所、interaction-spec className、activation-spec className、プロパティ)が含まれています。

activation-spec内のプロパティは、インバウンド・アダプタに固有のプロパティです。interaction-spec内のプロパティは、アウトバウンド・アダプタに固有のプロパティです。プロパティの値はカスタム・アダプタによって表示されたデフォルト値です。

customAdapter-config.xmlの内容は、カスタム・ランタイム・アダプタで必要なオプションにあわせて変更できます。たとえば、すべてのプロパティの名前やデフォルト値の変更、新しいプロパティの追加、複数のアクティブ化仕様と相互作用仕様の追加などを行うことができます。

displayResourceKeyおよびresourceBundle属性はオプションです。activation-spec、interaction-spec、またはproperty要素にdisplayResourceKeyが含まれている場合、属性値はリソース・バンドルから表示可能なテキストを取得するキーとして使用されます。リソース・バンドルが使用できない場合やバンドルにキーがない場合は、キー自身が表示可能なテキストとして使用されます(リソース・バンドルを含める必要はありません)。使用するリソース・バンドルは、connection-factory要素にresourceBundle属性を配置することによって指定できます。

変更されたcustomAdapter-config.xmlの例を示します。

例 - 変更されたcustomAdapter-config.xml

<adapter-config xmlns="http://platform.integration.oracle/blocks/
adapter/fw/metadata">

<connection-factory location="eis/Custom/CustomAdapter"
resourceBundle="oracle.tip.tools.ide.pm.modules.
bizintegration.adapter.custom.resource. CustomStringResourceBundle"/>

<endpoint-interaction >
<interaction-spec className="oracle.tip.adapter.
custom.outbound.
CustomInteractionSpec" displayResourceKey=
"CustomInteractionSpec" >
<property name="PropX" value="x"
displayResourceKey="SAMP_PROP_X" />
<property name="PropY" value="y"
displayResourceKey="Sample Property Y"/>
<property name="Append" value="false"/>
<property name="NumberMessages" value="1"/>
</interaction-spec>
</endpoint-interaction>

<endpoint-activation>
<activation-spec className=
"oracle.tip.adapter.custom.inbound.CustomActivationSpec"
displayResourceKey="CustomActivationSpec">
<property name="UseHeaders" value="false"/>
<property name="PhysicalDirectory" value="x"/>
<property name="Recursive" value="true"/>
<property name="DeleteFile" value="true"/>
<property name="IncludeFiles" value="x"/>
<property name="PollingFrequency" value="60"/>
<property name="MinimumAge" value="0"/>
</activation-spec>
</endpoint-activation>

</adapter-config>

2.28.1.1 カスタム・アダプタ画面のフロー

JDeveloper内で「公開されたサービス」または「外部参照」スイムレーンに「カスタムJCAアダプタ」アイコンをドラッグ・アンド・ドロップすると、アダプタ構成の「ようこそ」ページがIDEに表示されます。「次へ」を選択して、カスタム・アダプタ構成ウィザードのワークフローを開始できます。

図2-24 「アダプタ構成ウィザード - ようこそ」画面

次の画面には、他のアダプタの構成ウィザードと同じようにサービスのタイプと名前が表示されます。この画面により、構成するアダプタにおいて意味のあるサービスの名前を指定できます。

図2-25 「アダプタ構成ウィザード - サービス名」画面

config.xmlファイルに<connection-factory>エントリが(カスタム・ランタイム・アダプタで必要なため)含まれている場合は、ウィザードの「接続情報」ページにデフォルトの「コネクション・ファクトリの位置」が表示されます。config.xmlに<connection-factory>エントリが(カスタム・ランタイム・アダプタで不要なため)含まれていない場合、ウィザードのこのページは表示されません。

図2-26 「アダプタ構成ウィザード - 接続情報」画面

次の「アダプタ・インタフェース」画面には、他のアダプタの構成ウィザードと同じように情報が表示されます。(各アダプタの構成ウィザードの詳細は個々の適切な章を参照してください。)この画面には、後で作成する操作およびスキーマで新しいWSDLを定義する方法、またはWSDLの名前、ポート・タイプおよび操作を使用して既存のWSDLをインポートする方法が示されています。

図2-27 カスタム・アダプタ・ウィザードの「アダプタ・インタフェース」画面

次の画面では、相互作用のタイプ、つまりインバウンドまたはアウトバウンドを選択できます。アウトバウンド相互作用を選択すると、ウィザードには相互作用クラス名(または、この例のような変換済の表示名)のリストが表示され、その中から選択できます。これらは事前に、customAdapter-config.xmlファイルで指定した名前です。

図2-28 カスタム・アダプタ構成ウィザードの「操作」画面(インバウンドの選択)

次の画面では、JCAプロパティの名前と値を指定できます。選択したクラス名に応じて、customAdapter-config.xmlファイル内でそのクラス名に関連付けられているプロパティが表示されます。この画面では、デフォルト値の変更やプロパティの追加と削除を行うことができます。

図2-29 カスタム・アダプタ構成ウィザードのJCAプロパティ画面

次の画面は、カスタム・アダプタ・ウィザードの「メッセージ」画面です。この画面では、他のアダプタ構成ウィザードと同じように、スキーマを指定するか、またはスキーマが不透明であることを宣言することで、ファイルの読取り操作に関するメッセージを定義できます。

図2-30 カスタム・アダプタ構成ウィザードの「メッセージ」画面

次のページは、カスタム・アダプタ構成ウィザードの「最後」画面です。作成したWSDLファイルの名前が表示されます。

図2-31 カスタム・アダプタ構成ウィザードの「最後」画面

2.28.2 アダプタに関するよくある質問

次に、アダプタに関するよくある質問をいくつか挙げます。

2.28.2.1 アプリケーションがタイムアウトになる理由

コンポジット・アプリケーションがタイムアウトになるのはなぜですか。コンポジット・アプリケーションがアダプタを使用して実行するのに十分な時間を指定しても、アプリケーションは依然としてタイムアウトになります。

この一因に、WebLogicのタイムアウト値があります。ビジネス・プロセスでアダプタを使用する場合は、WebLogic Server JTAのタイムアウト値を考慮する必要があります。

たとえば、Timeout Secondsの値が30秒に設定されているとします。Oracle WebLogic JTA属性Timeout Secondsの値をデフォルトの30よりも大きい値、ビジネス・プロセスのコンテキスト全体で意味を持つ値に増やす必要があります。WebLogic Serverコンソールを使用して、「WLSコンソール」→SOADomain→「構成」→「JTA」に移動し、JTAトランザクションのタイムアウト値を変更できます。しかく

2.28.2.2 トランザクション・アダプタと非トランザクション・アダプタの違いはなんですか。

Oracle JMSアダプタなどのトランザクション・アダプタはJTAトランザクション内で実行されます。トランザクションでは1つ以上の操作がアトミック作業ユニットとして実行されます。

トランザクション内の1つの操作が失敗すると、すべての操作がロールバックされて、アプリケーションは元の状態に戻ります。ビジネス・プロセス・ロジックがステートフルまたはステートレスのどちらで定義されているかによって、特定のビジネス・プロセス内には1つ以上のトランザクションが含まれている場合があります。

非トランザクション・アダプタはトランザクション・セマンティクスを使用せずに、配信を確保する固有のスキームを実装します。

サービス・エンジンはインバウンド・ディレクトリからファイルを取得して処理し、処理したファイルを出力ディレクトリに送信します。インバウンド・アダプタは、変換(構成されている場合)およびビジネス・シナリオの一部として処理された変換済コンテンツのパブリッシュに制限されています。ビジネス・シナリオではアダプタを使用して、出力ディレクトリへの書込みを行うことができます。ただし、Oracleファイル・アダプタには非トランザクションの性質があるため、このプロセス中に障害によってフェイルオーバーが発生すると、ファイルが失われる可能性があります。その結果、インバウンド・アダプタが読み取ったファイルの一部が出力ディレクトリに送信されない場合があります。当然ながら、単一ノード・クラスタ(またはクラスタなし)の場合は、フェイルオーバーのオプションはありません。

ファイル・アダプタは、メッセージの損失を防ぐ高可用性が構成されていないかわりに、ファイル・システムへの整合性のあるアクセスとクラスタ・ノード間のロード・バランシングを確保するように構成されています。単一ノードのセットアップの場合、ファイル・アダプタの高可用性は不要で、メッセージの損失は発生しません。

このように、非トランザクションの性質があるため、Oracleファイル・アダプタに高可用性を構成して、フェイルオーバーの発生時にファイルが重複しないようにする必要があります。ファイル・アダプタでメッセージが失われることはなくなりますが、(障害時リカバリにおいて)一部が重複する可能性があります。

また、処理のシナリオにトランザクション・アダプタと非トランザクション・アダプタが含まれている場合は、非トランザクション部分の処理内でのファイルの整合性を確保する必要があります。

JMSアダプタはローカル・トランザクションでも機能できます。これは、(グローバル)JTAトランザクションの境界内から独立して開始され、コミットされるトランザクションです。つまり、ローカル・トランザクションはアダプタの現在の起動においてのみ存続します。

2.28.2.3 アプリケーションの拒否されたメッセージとはなんですか。その処理は可能ですか。

拒否されたメッセージは、デフォルトではデータベース(具体的にはrejected_message表)内に格納されます。デフォルトの拒否されたメッセージ・ハンドラは、メッセージをファイルシステム上に格納し、拒否されたメッセージを明示的に処理するポリシーが定義されていない場合に関与します。このハンドラは、WLS_HOMEの事前に定義された場所にあるファイル・システム上にメッセージのペイロードおよびプロパティを格納します。現在、Oracle SOA Suiteには拒否されたメッセージを再発行する機能がないため、ユーザーが再発行を処理します。

2.29 高度なトピック: テクノロジ間での実行コンテキストIDの使用

SOA Suite 11gデプロイメントでは、FTP、データベースおよびファイルとの統合などの様々なアクティビティやその他のアクティビティに対してテクノロジ・アダプタの使用を組み込むことができます。これらのアダプタとの統合は簡単な上に機能を強化しますが、操作の観点からいくつかの課題が生じる可能性もあります。

その課題の1つに、SOAコンポーネント・インスタンス間で論理ビジネス・トランザクションを関連付ける方法があります。通常、この関連付けは実行コンテキストID ()を使用して実行されますが、ビジネス・トランザクションの範囲がFTP、データベース、ファイルなどのテクノロジにまで及ぶと、ECIDの関連付けが失われる可能性があります。

OracleアダプタのJCAフレームワークの新機能では伝播が可能です。この機能は、11.1.1.4および11.1.1.5で使用可能なバック・ポートを持つSOA Suite 11.1.1.7で使用できます。

ECIDの伝播の基本概念は、ECIDを格納できるメッセージのペイロードで場所を識別することにあります。

次に、メッセージのECIDの場所に関連する2つの「バインディング・プロパティ」が「公開されたサービス」(コンポジットの左側)または「外部参照」(コンポジットの右側)のいずれかに追加されます。

これにより、メッセージからECIDを抽出するか、メッセージにECIDを追加するための十分な情報がJCAフレームワークに提供されます。

メッセージからECIDを抽出すると、そのECIDが新しいコンポーネント・インスタンスに使用されます。

2.29.1 ECIDの配置

メッセージでECIDの格納場所を決定する際には、次の2つのオプションがあります。

- メッセージ・スキーマに新しいオプションの要素を追加します。

- スキーマで使用されていない既存の要素を利用します。

メッセージにオプションの要素を追加できることが最善のシナリオです。未使用の要素を見つけることはほとんどの場合に難しいことがわかっています。スキーマには、次のように表示されるECID値が保持されています。

11d1def534ea1be0:7ae4cac3:13b4455735c:-8000-00000000000002dc

2.29.2 コンポジット・サービス/参照の構成

メッセージ内でECIDの格納に必要な場所を特定すると、JCAフレームワークでもその情報を保持する必要があります。フレームワークで必要な2つの情報は、次のメッセージ・スキーマに関連付けられています。

- メッセージ内の要素の名前空間

- メッセージ内の要素に対するXPath

これをより理解するには、最初に次のデータベース表の例を確認します。

図2-32 データベース表の例

データベース・アダプタ構成ウィザードでコンポジットに「公開されたサービス」が作成されると、次のスキーマが作成されます。

図2-33 公開されたサービスの作成時に作成されるスキーマ

この例では、コンポジット内のReadRowサービスに追加される2つの「バインディング・プロパティ」を次のように示しています。

<!-- Properties for the binding to propagate the  from the database table -->
<property name="jca..nslist" type="xs:string" many="false">
xmlns:ns1="http://xmlns.oracle.com/pcbpel/adapter/db/top/ReadRow"
</property>

<property name="jca..xpath" type="xs:string" many="false">
/ns1:PropagationCollection/ns1:Propagation/ns1:
</property>

jca..nslistという名前のプロパティは、スキーマで定義されたtargetNamespaceを含みます。

jca..xpathという名前のプロパティは、要素に対するXPath文を含みます。

XPath文は、jca..nslistプロパティで定義されている適切なネームスペース接頭辞(ns1)を含みます。

データベース・アダプタ・サービスでデータベースから行を読み取ると、ペイロードからECID値が取得され、さらにペイロードからECID要素が削除されます。コンポーネント・インスタンスが作成されると、取得されたECIDと関連付けられ、ペイロードにはECID要素/値を除くすべてが含まれます。ECIDは、データベース、ファイルまたはキューなどのリソース・テクノロジに安全に格納された場合のみ表示可能となります。

2.29.3 データベース/ファイル/JMSの単純な例

この項には、データベース、表、ファイルおよびJMSキューを使用したECIDの伝播方法について簡略化された例が含まれています。この例のコンポジットは次のように表示されます。

図2-34 例のコンポジット

この例のフローは次の順序で発生します。

- insertwithbpelprocess_client_epサービスを使用してデータベースの挿入を起動します。

- InsertWithBPELProcessにより、データベース・アダプタを使用してデータベースに行が追加されます。JCAフレームワークでは、挿入の前にメッセージにECIDが追加されます。

- ReadRowサービスではレコードが取得され、JCAフレームワークではメッセージから抽出されます。メッセージからECID要素が削除されます。

- ReadRowBPLProcessのインスタンスが作成され、取得したECIDと関連付けられます。

- ReadRowBPELProcessにより、ファイル・アダプタを介してファイル・システムにレコードが書き込まれます。JCAフレームワークでは、ファイルにメッセージを書き込む前にメッセージにECIDが追加されます。

- ReadFileサービスではファイル・システムからレコードが取得され、JCAフレームワークではメッセージからECIDが抽出されます。メッセージからECID要素が削除されます。

- ReadFileBPELProcessのインスタンスが作成され、取得したECIDと関連付けられます。

- ReadFileBPELProcessにより、JMSアダプタを使用してメッセージがエンキューされます。JCAフレームワークでは、メッセージECIDをエンキューする前にメッセージにECIDが追加されます。

- DequeueMessageサービスではレコードが取得され、JCAフレームワークではメッセージからECIDが抽出されます。メッセージからECID要素が削除されます。

- DequeueMessageBPELProcessのインスタンスが作成され、取得したECIDと関連付けられます。

- 論理フローが終了します。

Fusion Middleware Controlに「フローのトレース」が表示されると、ECIDによって関連付けられたすべてのインスタンスが表示されます。

図2-35 ECIDにより関連付けられたすべてのインスタンス(「フローのトレース」に表示)

3 アダプタとOracle Application Serverコンポーネントの統合

この章では、アダプタをOracle SOA SuiteおよびOracle WebLogic Serverと統合する方法について説明します。

この章の内容は次のとおりです。

- アダプタとOracle WebLogic Serverの統合

- アダプタとOracle Fusion Middlewareの統合

- 監視

3.1 アダプタとOracle WebLogic Serverの統合

Oracle JCAアダプタはJ2CA 1.5仕様に基づいており、Oracle WebLogic Serverにデプロイされます。リソース・アダプタは、Fusion Middlewareと同じJava仮想マシン(JVM)で実行されます。この項では、Oracle WebLogic Serverの概要と、アダプタとの設計時および実行時の統合について説明します。

この項には次のトピックが含まれます:

- Oracle WebLogic Serverの概要

- Oracle WebLogic Serverとアダプタの統合

3.1.1 Oracle WebLogic Serverの概要

Oracle WebLogic Serverは、スケーラブルなエンタープライズ対応のJavaプラットフォームであり、Enterprise Edition(Java EE)のアプリケーション・サーバーです。WebLogic Serverインフラストラクチャは、様々なタイプの分散アプリケーションのデプロイをサポートしています。サービス指向アーキテクチャ(SOA)に基づくアプリケーションを構築する上で理想的な基盤です。

すべてのクライアント・アプリケーションは、Oracle WebLogic Server環境で実行されます。Oracle WebLogic Serverクライアント・アプリケーションをリソース・アダプタと統合するには、Common Client Interface (CCI)を使用します。Oracle WebLogic Serverアダプタ・クライアントには、CCIアプリケーション・プログラム・インタフェース(API)を実装するサーブレット、EJBまたはJavaアプリケーション・クライアントがあります。CCIでは、アプリケーション・コンポーネントがバックエンド・アプリケーションにアクセスするための標準的なクライアントAPIが定義されます。

これに対して、Oracle WebLogic Serverコンテナとリソース・アダプタの間の規定は、サービス・プロバイダ・インタフェース(SPI)により定義されます。規定により、Oracle WebLogic Serverとアダプタの間の標準が定義されます。これらの規定はシステムにより自動的に処理され、アプリケーション開発者から隠されます。図3-1 に、CCIとSPIの規定を示します。

図3-1 Oracle WebLogic Serverとリソース・アダプタの間の規定

Oracle WebLogic Serverアーキテクチャには、次に示すシステム・レベルの一連の規定が含まれています。

- 接続管理: アプリケーション・コンポーネントがバックエンド・アプリケーションに接続して、Oracle WebLogic Serverコンテナの接続プーリング・サポート機能を利用できるようにします。これにより、バックエンド・アプリケーションへのアクセスを必要とする多数のコンポーネントをサポートできるスケーラブルで効果的な環境が得られます。詳細は、「アダプタ・コネクション・ファクトリの追加」を参照してください。

- トランザクション管理: アプリケーション・サーバーがトランザクション・マネージャを使用して、複数のリソース・マネージャ間のトランザクションを管理できるようにします。ほとんどのアダプタではローカル・トランザクション(1フェーズ・コミット)のみがサポートされ、XAトランザクション(2フェーズ・コミット)はサポートされていません。詳細は、「メッセージの損失がないことをOracle JCAアダプタで保証する方法」を参照してください。
すべてのOracle JCAアダプタはトランザクションについて適切な値を使用して事前に構成されており、この構成はOracle WebLogic Server管理コンソールで変更しないでください。

- セキュリティ管理: WebLogic Serverのセキュリティ・アーキテクチャは、Web上でアプリケーションを使用可能にするというセキュリティ上の課題に対処するように設計された包括的で柔軟なセキュリティ・インフラストラクチャを提供します。WebLogicのセキュリティは、スタンドアロンで使用してWebLogic Serverアプリケーションを保護したり、最良のセキュリティ管理ソリューションを表すエンタープライズ単位のセキュリティ管理システムの一部として使用できます。

3.1.2 Oracle WebLogic Serverとアダプタの統合

J2CA 1.5仕様に基づいており、このリリースではOracle WebLogic ServerコンテナにJ2CAリソース・アダプタとしてデプロイされます。J2CAリソース・アダプタは、Javaアーカイブ(JAR)フォーマットを使用してリソース・アダプタ・アーカイブ(RAR)にパッケージされます。RARファイルには、適切にフォーマットされたデプロイメント・ディスクリプタ(/META-INF/ra.xml)が含まれています。さらに、Oracle WebLogic Serverとリソース・アダプタの間の規定に関する宣言情報も含まれています。

Oracle WebLogic Serverでは、J2CAアダプタのデプロイメント中に対応するweblogic-ra.xmlファイルが生成されます。weblogic-ra.xmlファイルは、リソース・アダプタ用のデプロイメント・ディスクリプタです。これにはリソース・アダプタをOracle WebLogic Serverにデプロイするためのデプロイ構成が含まれています。これには、リソース・アダプタのデプロイメント・ディスクリプタで指定されたバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface (JNDI)名、接続プーリング・パラメータ、リソースのプリンシパル・マッピング・メカニズムおよび構成などが含まれます。

3.1.2.1 設計時

アダプタ設計時ツールを使用して、アダプタのリクエスト-レスポンス・サービス用のWSLD、XSDおよびJCAアーティファクトを生成します。これらのアーティファクトに含まれる情報は、JCA相互作用の作成時に使用されます。Oracle WebLogic Serverクライアントでは、これらのXSDファイルが実行時に使用されて、J2CAアウトバウンド相互作用がコールされます。

パッケージ・アプリケーション・アダプタでは、OracleAS Adapter Application Explorer (アプリケーション・エクスプローラ)が使用され、レガシー・アダプタではOracleAS Studioが使用され、テクノロジ・アダプタではOracle JDeveloper (JDeveloper)が使用されます。

詳細は、「設計時」を参照してください。

3.1.2.2 実行時

J2CA 1.5リソース・アダプタとしてOracle WebLogic Serverコンテナにデプロイされます。J2CA 1.5仕様は、ライフサイクル管理、メッセージ・インフロー(アダプタ・イベントのパブリッシュ用)および作業管理の規定に対処しています。

3.2 アダプタとOracle Fusion Middlewareの統合

アダプタによりOracle Fusion MiddlewareプラットフォームのJCAバインディング・コンポーネントが統合されます。これにより、Oracle BPEL Process Manager (Oracle BPEL PM)やOracle Mediatorなどのサービス・エンジンがシームレスに統合されます。

図3-2 に、Oracle JCAアダプタのアーキテクチャを示します。

図3-2 Oracle Fusion MiddlewareにおけるOracleアダプタのアーキテクチャ

アダプタ構成ウィザードでは、特に、対応するサービスのバインディング情報を含むWSDLとJCAプロパティ・ファイルが生成されます。

Oracleテクノロジ・アダプタでは、処理するすべてのインバウンドおよびアウトバウンド・メッセージの統計を収集およびパブリッシュします。詳細は、「監視」を参照してください。

アダプタとOracle Service Busの使用の詳細は、『Oracle® Fusion Middleware Oracle Service Bus開発者ガイド』のアダプタの使用に関する説明を参照してください。Open Service Bus (OSB)では、.jcaファイルがcomposite.xml自体によって参照されるのではなく、プロキシ/ビジネス・サービスによって参照されることが唯一の違いです。

この項には、次の項目が含まれます。

- Oracle BPEL Process Managerの概要

- Oracle Mediatorの概要

- Oracle Fusion Middlewareとアダプタの統合

- Oracle SOAコンポジットとアダプタの統合

3.2.1 Oracle BPEL Process Managerの概要

Oracle BPEL PMは、Oracle BPEL PMビジネス・プロセスを作成、デプロイおよび管理するための包括的なソリューションです。Oracle BPEL PMはサービス指向アーキテクチャ(SOA)に基づいており、柔軟性、相互運用性、再利用性、拡張性および迅速な実装を提供します。Oracle BPEL PMにより、既存のビジネス・プロセスの管理、変更、拡張および再デプロイに伴う全体のコストが削減されます。各ビジネス・アクティビティは自己完結型でわかりやすいモジュラ・アプリケーションであり、WSDLファイルにより定義されるインタフェースと、Webサービスとしてモデル化されるビジネス・プロセスを備えています。

3.2.2 Oracle Mediatorの概要

Oracle Mediatorは、サービスおよびイベントの各種プロデューサとコンシューマ間を仲介するための軽量フレームワークを提供します。ほとんどのビジネス環境では、顧客データは、取引先、レガシー・アプリケーション、エンタープライズ・アプリケーション、データベース、カスタム・アプリケーションなど、様々なソースに点在しています。このデータを統合するというチャレンジは、Oracle Mediatorを使用して、同じデータが更新対象や共通の注目対象となる全アプリケーションに適切なリアルタイム・データ・アクセスを提供することで満たすことができます。たとえば、メディエータはアプリケーションやサービスからテキスト・ファイルに含まれたデータを受け入れ、顧客リポジトリとして機能するデータベースの更新に適したフォーマットに変換し、そのデータベースにルーティングして配信できます。

3.2.3 Oracle Fusion Middlewareとアダプタの統合

J2CA 1.5リソース・アダプタとOracle BPEL PMおよびOracle Mediatorを双方向で統合するために、JCAバインディング・コンポーネントが使用されています。WSDLファイルおよびJCAバインディングが生成され、Webサービスとして基礎になる相互作用が公開されます。

アダプタ・サービスへのインタフェース(入力/出力XML要素)は、WSDLファイルを介して記述されます。ただし、リリース11gでは、バインディング要素が削除され、WSDLファイルが抽象になっています。かわりに、JCAバインディング・コンポーネント(以前のリリースにおけるアダプタ・フレームワーク)とアダプタが特定のEIS上で特定のコールについて起動するために必要とするバインディング情報は、個別のbinding.jcaファイルに格納されます。

この項では、次の内容について説明します。

- 設計時

- 実行時

- 使用例: Oracle BPEL Process Managerの統合

- Oracle SOAコンポジットの概要

- アダプタとOracle SOAコンポジットの統合

3.2.3.1 設計時

アダプタをOracle BPEL PMおよびOracle Mediatorと統合する間に、基礎となるアダプタ・サービスがJ2CA拡張を使用するWSDLファイルとして公開されます。次の表に、各種アダプタ用のWSDLファイルとJCAファイルの生成に使用する設計時ツールを示します。

アダプタ

ツール

Oracleテクノロジ・アダプタ

Oracle JDeveloper

メインフレームおよびTPモニター・アダプタ

Oracle Studio

パッケージ・アプリケーション・アダプタ

アプリケーション・エクスプローラ

Oracle Applications用のOracleアダプタ

Oracle JDeveloper

WSDLファイルは、アダプタのリクエスト-レスポンス・サービスとイベント通知サービスの両方について作成されます。J2CA拡張には、JCAバインディング・コンポーネントで実行時にWebサービス・メッセージをJ2CA相互作用との間で変換するために必要なJ2CA要素が含まれています。J2CAのWSDL拡張要素には、JCAバインディング・コンポーネントでリクエスト-レスポンス・サービスをコールし、インバウンドJ2CA 1.5エンドポイントをアクティブ化してインバウンド・イベントを受信するためのメタデータが含まれています。リクエスト-レスポンス・サービス用のJ2CA拡張要素には、アウトバウンド相互作用をコールするためのJNDIロケーションとInteractionSpecの詳細が含まれています。イベント通知サービス用のJ2CA拡張要素には、J2CAインバウンド相互作用を介してアダプタ・イベントをパブリッシュするための、リソース・アダプタ・クラス名とActivationSpecパラメータが含まれています。

図3-3に、使用される設計時ツールのJDeveloperを示します。

図3-3 テクノロジ・アダプタの設計時構成

図3-4 に、パッケージ・アプリケーション・アダプタの構成に使用する設計時ツールを示します。この図では、設計時ツールを使用して、アダプタ・メタデータがWSDLファイルとして公開されています。WSDLファイルは、実行時にBPEL Process Managerにより消費されます。

図3-4 パッケージ・アプリケーション・アダプタの構成

3.2.3.2 実行時

アダプタはJ2CA 1.5仕様に基づいており、BPELはOracle WebLogic Serverで実行時にデプロイされます。JCAバインディング・コンポーネントは、実行時に標準のJ2CA 1.5リソース・アダプタをOracle BPEL Process ManagerおよびOracle Mediatorと結び付けて統合するレイヤーとして機能します。

BPEL Invokeアクティビティにより開始されたWebサービスの呼出しはJ2CA CCIアウトバウンド相互作用に変換され、J2CAレスポンスはWebサービス・レスポンスに変換されます。

3.2.3.3 使用例: Oracle BPEL Process Managerの統合

図3-5 に示すように、Oracle BPEL PMの「パートナ・リンク」ダイアログから、Oracle BPEL PMで提供されているアダプタにアクセスできます。

図3-5 「パートナ・リンク」ダイアログ・ボックス

図3-6 に示すように「サービスの定義」アイコンをクリックし、「サービスまたはアダプタの設定」ダイアログにアクセスします。

図3-6 アダプタの定義

このダイアログを使用すると、Oracle BPELプロセスで使用するアダプタ・タイプ(図3-7 を参照)を設定できます。

図3-7 アダプタ・タイプ

アダプタ・タイプを選択(この場合)し、「OK」をクリックすると、図3-8に示すように、「アダプタ構成ウィザード」 - 「ようこそ」ページが表示されます。

図3-8 「アダプタ構成ウィザード - ようこそ」ページ

「次へ」をクリックすると、図3-9 に示す「サービス名」ページが表示されます。サービス名の入力を要求されます。

この例では、図3-7 に示すように「AQアダプタ」が選択されています。ウィザードが完了すると、BPELプロセスの「アプリケーション・ナビゲータ」にこのサービス名のWSDLファイルが表示されます(この例では、「DequeueDemo.wsdl」という名前です)。このファイルには、このウィザードで指定したアダプタ構成設定が含まれます。その他の構成ファイル(ヘッダー・プロパティやアダプタ固有のファイルなど)も作成され、「アプリケーション・ナビゲータ」に表示されます。

図3-9 「アダプタ構成ウィザード - サービス名」ページ

「サービス名」ウィンドウ以降に表示されるアダプタ構成ウィザードのウィンドウは、選択したアダプタ・タイプによって異なります。これらの構成ウィンドウや指定する情報については、このガイドの後続の章で説明します。

3.2.4 Oracle SOAコンポジットとアダプタの統合

Oracle SOA Suiteと統合できます。

この項には、次の項目が含まれます。

- Oracle SOAコンポジットの概要

- アダプタとOracle SOAコンポジットの統合

3.2.4.1 Oracle SOAコンポジットの概要

SOAコンポジット・アプリケーションは、ビジネス・ニーズを満たすために設計されてデプロイされるサービス、サービス・コンポーネント、参照およびワイヤのアセンブリです。

SOAは、接続済エンタープライズ・アプリケーションの構築をサポートするエンタープライズ・アーキテクチャを提供します。SOAは、統合と再利用が容易で、柔軟かつ順応性のあるITインフラストラクチャを作成するモジュール型ビジネスのWebサービスとして、エンタープライズ・アプリケーションの開発を促進します。

3.2.4.2 アダプタとOracle SOAコンポジットの統合

コンポジットは、設計されて単一アプリケーションにデプロイされるサービス、サービス・コンポーネント、ワイヤおよび参照のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。

たとえば、コンポジットには、インバウンド・サービス・バインディング・コンポーネント(インバウンド・アダプタ)、BPELプロセス・サービス・コンポーネントおよびアウトバウンド参照バインディング・コンポーネント(アウトバウンド・アダプタ)が含まれます。このコンポジットの詳細は、composite.xmlファイルに格納されます。

通常、Oracle SOAコンポジットは、次の各部で構成されています。

- バインディング・コンポーネント
バインディング・コンポーネントにより、SOAコンポジットと外部との接続性が確立されます。バインディング・コンポーネントには、次の2種類があります。

- サービス・バインディング・コンポーネント
外部に対してSOAコンポジット・アプリケーションへのエントリ・ポイントを提供します。サービスのWSDLファイルにより、外部アプリケーションに機能が通知されます。これらの機能は、SOAコンポジット・アプリケーション・コンポーネントとの接続に使用されます。サービスのバインディング接続性により、Oracle JCAアダプタなどのサービスと通信できるプロトコルが記述されます。

- 参照バインディング・コンポーネント
SOAコンポジット・アプリケーションから外部にある外部サービスに送信するメッセージを有効にします。

Oracle SOA Suiteでは、サービスおよび参照をテクノロジ(データベース、ファイル・システム、FTPサーバー、メッセージング: JMS、IBM MQなど)およびアプリケーション(Oracle E-Business Suite、PeopleSoftなど)と統合するためのWebサービス(Oracle JCAアダプタなど)を提供します。これには次が含まれます。

- サービス・インフラストラクチャ
内部メッセージ・トランスポートを提供します。たとえば、インバウンド・アダプタからメッセージを受信して、処理のためにBPELプロセス・サービス・エンジンにポストします。

- サービス・エンジン(サービス・コンポーネントをホストするコンテナ)
サービス・コンポーネントのビジネス・ロジックまたは処理ルールをホストします。各サービス・コンポーネントには固有のサービス・エンジンがあります。たとえば、Oracle BPELプロセス・エンジンやOracle Mediatorコンポーネントなどです。

アダプタとサービス・エンジンの統合の詳細は、「アダプタとOracle Fusion Middlewareの統合」を参照してください。

- UDDIとMDS
MDS(メタデータ・サービス)リポジトリには、使用可能なサービスの記述が格納されます。UDDIでは、これらのサービスが通知され、実行時における検出と動的バインディングを可能にします。

- SOAアーカイブ: コンポジット
コンポジット・アプリケーションを記述するデプロイメント・ユニット。

コンポジットは、設計されて単一アプリケーションにデプロイされるサービス(インバウンド・アダプタなど)、サービス・コンポーネント、ワイヤおよび参照(アウトバウンド・アダプタなど)のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。SOAプロジェクトを作成すると、composite.xmlファイルが自動的に作成されます。このファイルでは、サービス、サービス・コンポーネント、参照およびワイヤのコンポジット・アセンブリ全体が記述されます。つまり、composite.xmlファイルではSOAコンポジット全体が記述されます。

composite.xmlのサンプルの詳細は、次の例を参照してください。

例 - composite.xmlファイル

Composite.xml (JCA Bindings)<?xml version="1.0"
encoding="UTF-8" ?>
<!-- Generated by Oracle SOA Modeler version
<! -- 1.0 at [2/23/09 3:02 PM]. -->
<composite name="MediatorFlatStructure"
revision="1.0"
label="2009-02-23_15-02-00_374"
mode="active"
state="on"
xmlns="http://xmlns.oracle.com/sca/1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
xmlns:ui="http://xmlns.oracle.com/soa/designer/">
<import namespace="http://xmlns.oracle.com/pcbpel/
adapter/file/SOA-FlatStructure/
MediatorFlatStructure/MedFlatIn%2F"
location="MedFlatIn.wsdl" importType="wsdl"/>
<import namespace="http://xmlns.oracle.com/pcbpel/
adapter/file/SOA-FlatStructure/
MediatorFlatStructure/MedFlatOut%2F"
location="MedFlatOut.wsdl" importType="wsdl"/>
<service name="MedFlatIn"
ui:wsdlLocation="MedFlatIn.wsdl">
<interface.wsdl interface=
"http://xmlns.oracle.com/pcbpel/
adapter/file/SOA-FlatStructure/
MediatorFlatStructure/MedFlatIn%2F#wsdl.
interface(Read_ptt)"/>
<binding.jca config="MedFlatIn_file.jca"/>
</service>
<component name="MediatorFlat">
<implementation.mediator
src="MediatorFlat.mplan"/>
</component>
<reference name="MedFlatOut"
ui:wsdlLocation="MedFlatOut.wsdl">
<interface.wsdl interface=
"http://xmlns.oracle.com/pcbpel/
adapter/file/SOA-FlatStructure/
MediatorFlatStructure/
MedFlatOut%2F#wsdl.interface(Write_ptt)"/>
<binding.jca config="MedFlatOut_file.jca"/>
</reference>
<wire>
<source.uri>MedFlatIn</source.uri>
<target.uri>
MediatorFlat/MediatorFlat</target.uri>
</wire>
<wire>
<source.uri>MediatorFlat/MedFlatOut</source.uri>         <target.uri>MedFlatOut</target.uri>
</wire>
</composite>

Oracle SOAコンポジット、およびその各種サービスとの統合の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。

3.3 監視

Oracle BPEL Process ManagerおよびOracle Mediatorには、Oracle JCAアダプタ(ファイル、JMSおよびデータベースなど)があり、それぞれがインバウンドまたはアウトバウンドで処理するすべてのメッセージの統計が収集され、パブリッシュされます。統計は、カテゴリと個別タスクにわかれています。次の例に、アウトバウンド(参照)プロセス内で統計がどのようにわかれているかを示します。

- アダプタの前処理

- InteractionSpecの準備

- アダプタの処理

- コール可能な文の設定

- データベースの起動

- 結果の解析

- アダプタの後処理

アダプタ統計は、Fusion Middleware Controlコンソールで表示できます。アダプタ統計を表示する手順は、次のとおりです。

1. http://servername:portnumber/emにナビゲートします。

2. 「ターゲット・ナビゲーション・ツリー」(左端のペイン)のSOAフォルダにあるsoa_infraをクリックします。

「soa-infra」ページが表示されます。

3. 「soa-infra」ページの「SOAインフラストラクチャ」メニューで「サービスと参照」をクリックします。

図3-10 診断レポートを使用したFusion Middleware Controlコンソールでのアダプタ統計の表示

図3-11 に示すように、「SOAインフラストラクチャ・ホーム > インタフェース」ページが表示されます。

このページには、現在アクティブなすべてのアダプタのインバウンド相互作用(サービス)およびアウトバウンド相互作用(参照)のリストと、各アダプタで実行される各種ステップの平均実行時間が表示されます。

図3-11 「SOAインフラストラクチャ・ホーム」ページ

このリリースの新機能であるアダプタ・レポートなど、SOAアダプタの監視および構成の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の、特に「Oracle JCAアダプタの監視」と「Oracle JCAアダプタの構成」の各章を参照してください。「SOAコンポジット・アプリケーションの問題の診断」の章には、アダプタに関連するSOAコンポジット・アプリケーションの問題の診断に役立つアダプタ・ログの使用方法が記載されています。

4 Oracle JCA Adapter for Files/FTP

この章では、Oracle BPEL Process ManagerおよびOracle Mediatorで動作する、Oracleファイル・アダプタおよびOracle FTPアダプタの使用方法について説明します。Oracleファイル/FTPアダプタの概念、機能、構成および使用例に関する情報も参照できます。

この章の内容は次のとおりです。

- Oracleファイル/FTPアダプタの概要

- 機能

- Oracleファイル/FTPアダプタの説明

- Oracleファイル/FTPアダプタの構成

- Oracleファイル/FTPアダプタの使用例

注意:

Oracle JCA Adapter for Files/FTPという用語は、Oracleファイル・アダプタおよびOracle FTPアダプタを指します。これらは非常に似た機能を持ちますが、個別のアダプタです。

4.1 Oracleファイル/FTPアダプタの概要

Oracle BPEL PMとメディエータには、Oracleファイル/FTPアダプタが組み込まれています。Oracleファイル/FTPアダプタを使用すると、ローカル・ファイルシステムやリモート・ファイルシステムのファイルを(ファイル転送プロトコル(FTP)を使用して) BPELプロセスまたはメディエータで交換(読取りおよび書込み)できるようになります。ファイルは、XMLとXML以外のデータ形式のどちらでもかまいません。

この項には次のトピックが含まれます:

- Oracleファイル/FTPアダプタのアーキテクチャ

- Oracleファイル/FTPアダプタとOracle BPEL PMの統合

- Oracleファイル/FTPアダプタとメディエータの統合

- SOAコンポジットとの統合

4.1.1 Oracleファイル/FTPアダプタのアーキテクチャ

Oracleファイル/FTPアダプタはJCA 1.5アーキテクチャに基づいています。JCAでは、異機種間のエンタープライズ情報システム(EIS)の統合に標準アーキテクチャを提供します。Oracleファイル/FTPアダプタのJCAバインディング・コンポーネントでは、基盤となるJCA相互作用がOracle BPEL PM統合のサービス(JCAバインディングを使用したWSDL)として公開されています。Oracle JCAアダプタのアーキテクチャの詳細は、「Oracle JCAアダプタの概要」を参照してください。

4.1.2 Oracleファイル/FTPアダプタとOracle BPEL PMの統合

Oracleファイル/FTPアダプタはOracle BPEL PMと自動的に統合されます。JDeveloper BPELデザイナの「コンポーネント」ウィンドウからFTPアダプタの「ファイル・アダプタ」をドラッグ・アンド・ドロップすると、図4-1 に示すように、アダプタ構成ウィザードが起動されて「ようこそ」ページが表示されます。

図4-1 「アダプタ構成ウィザード - ようこそ」ページ

このウィザードでOracleファイル/FTPアダプタを選択して構成できます。アダプタ構成ウィザードでは、図4-2 に示すように、サービス名の入力を求められます。

図4-2 「アダプタ構成ウィザード - サービス名」ページ

構成が完了すると、Oracle JDeveloperの「アプリケーション・ナビゲータ」セクションにWSDLとJCAのファイルのペアが作成されます。(JDeveloper)このJCAファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。

アダプタ構成ウィザードの「操作タイプ」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。表4-1 に実行可能な操作をリスト表示し、指定する必要のある構成情報が説明されている項を示します。

表4-1 Oracle BPEL Process Managerについてサポートされている操作

操作

参照先

Oracleファイル・アダプタ

-

- Read File(インバウンド操作)

ファイル読取りの説明

- Write File(アウトバウンド操作)

ファイル書込みの説明

- 同期Read File(アウトバウンド操作)

同期読取りの説明

- List Files(アウトバウンド操作)

ファイル・リスティングの説明

Oracle FTPアダプタ

-

- Get File(インバウンド操作)

Get Fileの説明

- Put File(アウトバウンド操作)

Put Fileの説明

- 同期Get File(アウトバウンド操作)

同期Get Fileの説明

- List Files(アウトバウンド操作)

ファイル・リスティングの説明

Oracle JCAアダプタとOracle BPEL PMの統合の詳細は、「Oracle JCAアダプタの概要」を参照してください。

4.1.3 Oracleファイル/FTPアダプタとメディエータの統合

Oracleファイル/FTPアダプタはメディエータと自動的に統合されます。JDeveloperデザイナでOracleファイル/FTPアダプタ・サービスを作成すると、アダプタ構成ウィザードが起動します。

このウィザードでOracleファイル/FTPアダプタを選択して構成できます。構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションにWSDLとJCAのファイルのペアが作成されます。このJCAファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。

アダプタ構成ウィザードの「操作タイプ」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。表4-2 に実行可能な操作をリスト表示し、指定する必要のある構成情報が説明されている項を示します。アダプタおよびメディエータの詳細は、「Oracle JCAアダプタの概要」を参照してください。

表4-2 Oracle Mediatorについてサポートされている操作

操作

参照先

Oracleファイル・アダプタ

-

- Read File(インバウンド操作)

ファイル読取りの説明

- Write File(アウトバウンド操作)

ファイル書込みの説明

- 同期Read File(アウトバウンド操作)

同期読取りの説明

- List Files(アウトバウンド操作)

ファイル・リスティングの説明

Oracle FTPアダプタ

-

- Get File(インバウンド操作)

Get Fileの説明

- Put File(アウトバウンド操作)

Put Fileの説明

- 同期Get File(アウトバウンド操作)

同期Get Fileの説明

- List Files(アウトバウンド操作)

ファイル・リスティングの説明

4.1.4 SOAコンポジットとの統合

コンポジットは、設計されて単一アプリケーションにデプロイされるサービス、サービス・コンポーネント(Oracle BPEL PM)、ワイヤおよび参照のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。コンポジットの詳細は、composite.xmlファイルに格納されます。SOAコンポジットとの統合の詳細は、「Oracle SOAコンポジットとアダプタの統合」を参照してください。

4.2 機能

使用すると、ローカルやリモートのファイルシステムのディレクトリを操作するようにBPELプロセスを構成できます。この項では、次の機能について説明します。

- ファイル・フォーマット

- FTPサーバー

- インバウンドおよびアウトバウンド相互作用

- ファイルのデバッチ処理

- ファイルのChunkedRead

- ファイルのソート

- 動的アウトバウンド・ディレクトリとファイル名の指定

- セキュリティ

- 非トランザクション

- プロキシのサポート

- ペイロード以外のサポート

- 大きなペイロードのサポート

- ファイルベースのトリガー

- ファイルの前処理および後処理

- エラー処理

- スレッド・モデル

- パフォーマンス・チューニング

- 高可用性

- 複数のディレクトリ

- 追加モード

- ディレクトリ内のファイルの再帰的処理

- エンタープライズ情報システムの資格証明の保護

注意:

大量の同時メッセージを使用するように設計された、コンポジットの場合は、オペレーティング・システムのオープン・ファイル数パラメータを大きい値に設定する必要があります。たとえば、Linuxのオープン・ファイル数パラメータを8192に設定するには、ulimit -n 8192コマンドを使用します。

4.2.1 ファイル・フォーマット

次のファイル形式の読取りおよび書込みが可能で、実行時にアダプタ・トランスレータ・コンポーネントが使用されます。

- XML (XSDおよびDTDベースの両方)

- デリミタ付き

- 位置固定

- バイナリ・データ

- COBOLコピーブック・データ

ファイル・コンテンツを不透明(Opaque)オブジェクトとして処理し、コンテンツを(変換せずに)元の形式で渡すこともできます。不透明オプションでは、構造をXSDで取得できないJPGやGIFなどのバイナリ・データや、変換の不要なデータが処理されます。

不透明表現base-64ではペイロードがエンコードされ、インメモリー・ペイロードのサイズが1/3増加することに注意してください。不透明/base-64表現は通常、XML内のバイナリ・データを渡すために使用されます。添付ファイルのサポートの詳細は、「大きなペイロードのサポート」も参照してください。

トランスレータにより、様々なフォーマットのネイティブ・データからXMLへの変換、およびXMLから他のフォーマットへの変換を、実行できるようになります。ネイティブ・データは単純な形式(フラット構造)または複雑な形式(親子関係)のいずれかです。トランスレータでは、XMLフォーマットのデータと非XML(ネイティブ)フォーマットのデータの両方を処理できます。

4.2.2 FTPサーバー

すべてのプラットフォームでRFC 959準拠のほとんどのFTPサーバーをサポートしています。その他のFTPサーバーをサポート可能にするプラガブル・メカニズムも利用できます。さらに、SolarisおよびLinuxでSSLによるFTP (FTPS)をサポートしています。SSHトランスポートを使用したSFTP(Secure FTP)もサポートしています。

注意:

バージョン3以降のSFTPサーバーをサポートしています。

4.2.3 インバウンドおよびアウトバウンド相互作用

インバウンド方向およびアウトバウンド方向でファイルの交換が行われます。交換の方向により、実行されるタスクの内容は異なります。

Oracle BPEL PMに送信されるインバウンド・ファイルの場合、次の操作が実行されます。

1. ファイルシステムのポーリングによる一致ファイルの検索

2. ファイル・コンテンツの読取りおよび変換。ネイティブ・データは、設計時に定義されたネイティブ・スキーマ(NXSD)に基づいて変換されます。

3. 変換済コンテンツのXMLメッセージとしてのパブリッシュ

この機能はファイル読取り操作と呼ばれます。

Oracle BPEL PMから送信されるアウトバウンド・ファイルの場合、次の操作が実行されます。

1. BPELからのメッセージの受信。

2. 設計時に指定されたXMLコンテンツの書式設定。

3. 出力ファイルの生成。出力ファイルは、基準(経過時間、ファイル・サイズおよびメッセージ数)に基づいて作成されます。これらの基準の組合せを出力ファイル用に指定することもできます。

この機能はファイル書込み操作と呼ばれます。この操作は、JCAアウトバウンド相互作用と呼ばれます。

インバウンドおよびアウトバウンドの方向ごとに、一連の構成パラメータが使用されます。次に例を示します。

- インバウンドでは、入力ファイルが配置されるインバウンド・ディレクトリ用のパラメータと、ディレクトリをポーリングする頻度があります。

- アウトバウンドでは、ファイルを書き込むアウトバウンド・ディレクトリ用のパラメータと、使用するファイル・ネーミング規則があります。

注意:

パブリッシュ・サイズ、メッセージ数およびポーリング頻度などの構成パラメータを変更するには、アダプタ構成ウィザードを使用する必要があります。

JCAファイル内のこれらのパラメータの値を手動で変更しないでください。

ファイル・リーダーではポーリング規則がサポートされており、いくつかの後処理オプションが用意されています。処理後にファイルを削除するか、移動するか、またはそのまま保持するかを指定できます。ファイル・リーダーでは、単一のメッセージとしてではなく、ファイル・コンテンツを分割してバッチで公開できます。この機能は、パフォーマンス・チューニングに使用できます。ファイル・リーダーでは、ファイルが何度も配信されることはありません。

読取りと書込みの機能の詳細は、次の項を参照してください。

- ファイル読取りの説明

- ファイル書込みの説明

- Get Fileの説明

- Put Fileの説明

4.2.4 ファイルのデバッチ処理

.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;

4.2.5 ファイルのChunkedRead

ファイルのチャンク読取り操作では、大きなファイルの処理が可能になり、whileループ内でBPEL invokeアクティビティを使用してターゲット・ファイルが処理されます。

具体的には、FileAdapterによって、BPELプロセス・モデラーはinvokeアクティビティを使用して非常に大きなファイルから論理チャンクを取得できるため、ファイルのメモリー制限を超えません。このプロセスでは、ループ内でチャンク相互作用をコールすることにより、一度に1つずつ論理チャンクを実行してファイル全体を処理します。目的は、ファイルのアウトバウンド処理でデバッチ処理できるようにすることです。

ファイル・アダプタ構成ウィザードを使用して、チャンク・ファイル(.jcaファイル)およびWSDLファイルを定義します。

4.2.5.1 チャンク相互作用ファイル・アダプタ処理

FileAdapterは、チャンク読取り操作のネイティブ・データをXMLに変換し、それをBPEL変数として返します。

チャンク読取りを実行するには、通常、BPEL内にinvokeアクティビティを作成します。

また、ファイル・アダプタ構成ウィザードを使用して、WSDL操作として「チャンク同期読取り」を選択し、オプションで、構成ウィザードを使用して、ChunkedInteractionSpecに書き込まれるファイル入力ディレクトリおよびファイル名を構成します。

invokeアクティビティがコールされるたびに、ヘッダー値とペイロードが返されます。

これらのヘッダー値には、行番号、列番号、およびファイルの終わりに達したかどうかを示すインジケータが含まれます。以降のファイル・アダプタのコールのために、必ずリターン・ヘッダーの行番号と列番号をアウトバウンド・ヘッダーにコピーしてください。必要に応じて、入力ディレクトリおよびファイル名をヘッダー値として指定することもできます。

4.2.5.1.1 ファイル・チャンク相互作用のBPEL起動

FileAdapterのチャンク相互作用は、BPELから起動されます。ネイティブ・データ・ファイルの場合、行番号と列番号もヘッダー値として渡されます。

ループ内でチャンク相互作用が初めてコールされるときのLineNumberおよびColumnNumberの値は空白であり、それ以降のコールでは、これらの値はinvokeの戻り値から1を引いた値(つまり、invokeの前の値)になります。

BPEL invokeは、表4-3 に示されているパラメータを使用してChunkedInteractionをコールします。

表4-3 チャンク相互作用のためのBPEL invokeパラメータ

パラメータ

取得場所

Physical/LogicalDirectory

ChunkedInteractionSpecまたはBPELヘッダー

FileName

ChunkedInteractionSpecまたはBPELヘッダー

ChunkSizeBatchSize

ChunkedInteractionSpec (デバッチ処理におけるPublishSizeと類似)

LineNumber

ヘッダー(オプション)

ColumnNumber

ヘッダー(オプション)

RecordNumber

ヘッダー(オプション)

4.2.5.1.2 ChunkSizeパラメータ

ChunkSizeパラメータは、チャンク読取り操作でのファイル・チャンク・サイズに関連する情報を提供するもので、(ファイル・アダプタ構成ウィザードを使用して) ChunkedInteractionSpec内に別の値を構成していない場合は、デフォルトで1になります。

具体的には、ChunkSizeパラメータは、返されるノードまたはレコード(行ではない)の数を制御します。

たとえば、ネイティブCSVファイルのアドレス帳がある場合、ChunkSizeとして5を指定すると、invokeアクティビティがコールされるたびに、5個のアドレス帳ノードを含むXMLファイル(XMLフォーマットのCSVレコード5行)が返されます。

この意味で、ChunkSizeパラメータは、FileAdapterでインバウンド・トランザクションに使用されるPublishSizeパラメータと似ています。

4.2.5.1.2.1 チャンク読取りのための拒否ハンドラ・バインディングの例

次の例に、チャンク読取り参照バインディングのための拒否ハンドラの構成方法を示します。

例 - チャンク読取りのための拒否ハンドラ・バインディング

<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>

4.2.5.1.2.2 行番号/列番号またはレコード番号の使用

invokeの後は必ず、以降のinvokeのためにリターン・ヘッダーをアウトバウンド・ヘッダーにコピーする必要があります。LineNumber/ColumnNumberはアダプタでブックキーピング目的のみに使用されるものであり、リターン・ヘッダーからこれらの値をチャンク相互作用がコールされる前のヘッダーにコピーする必要があります。

これに対し、RecordNumberは、データが(ネイティブ・データではなく) XMLフォーマットのときに使用されます。その意味で、RecordNumberは、ネイティブ・データのブックキーピングに使用されるLineNumber/ColumnNumberとは相互に排他的です。

4.2.5.1.2.3 ファイル・チャンク読取り相互作用のアーティファクト

次に、チャンク読取りのための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>

4.2.5.2 ファイル・アダプタ構成ウィザードを使用したチャンク読取り相互作用のモデル化の実行

ファイル読取り相互作用をモデル化するには、ファイル・アダプタ構成ウィザードを使用します。

他のファイル・アダプタ操作を構成する場合と同様、ファイル・アダプタの最初の3つの画面を使用できます。

1. ファイル・アダプタの「操作」画面で、「チャンク読取り」を指定します。

図4-3 「チャンク読取り」が選択されたファイル・アダプタ構成ウィザードの「操作」ページ

2. 「ファイル・ディレクトリ」で、チャンク読取り操作のディレクトリ情報を指定します。

図4-4 ファイル・アダプタ構成ウィザードでのチャンク読取り操作のディレクトリ情報の指定

3. 「ファイル・ディレクトリ」ページで、指定したディレクトリ・パスが物理パスか論理パスかを指定します。ファイルを指定するか、参照してファイルを検索します。チェック・ボックスを選択し、アーカイブ・ファイルの物理パスの名前を示すディレクトリを指定します。デフォルトでは、正常に取得が完了するとファイルが削除されます。「次へ」を選択します。

4. 「ファイル・アダプタ構成ウィザード」の「ファイル名」ページが表示されます。チャンク読取り操作のファイル名を指定します。「次へ」を選択します。

図4-5 ファイル・アダプタ構成ウィザードの「ファイル名」ページ

5. ファイル・アダプタ構成ウィザードの「メッセージ」画面が表示されます。

図4-6 ファイル・アダプタ構成ウィザードの「メッセージ」画面

6. ファイル・アダプタ・ウィザードの「メッセージ」画面では、チャンク読取りファイル操作で使用するメッセージを定義できます。ファイルの場所を指定し、着信ファイルに対するメッセージを定義するスキーマ要素を選択します。既存のスキーマ定義を検索するには、参照ボタンを使用します。「スキーマを不透明にする」を選択した場合、スキーマを指定する必要はありません。「次へ」または「終了」を選択して、ファイル・アダプタ構成ウィザードを表示し、チャンク読取りファイル操作に使用するWSDLのディレクトリ・パスと名前を表示します。

4.2.5.2.1 チャンク相互作用のエラー処理の概要

変換例外(nXSD仕様に違反する不正レコード)が発生すると、エラーが発生した行や列などの詳細を含む変換例外メッセージがリターン・ヘッダーに移入されます。

ただし、特定の変換エラーが発生してもフォルトにはなりません。これはリターン・ヘッダー内の値となります。jca.file.IsMessageRejectedおよびjca.file.RejectionReasonヘッダーの値を確認して、拒否が発生したかどうかを確認する必要があります。また、jca.file.NoDataFoundヘッダーの値も確認できます。

4.2.5.2.2 不正なレコードのスキップ

nxsd:uniqueMessageSeparatorコンストラクトを使用すると、アダプタは不正なレコードをスキップして、次のレコード・セットの処理を続行できます。(uniqueMessageSeparatorの詳細は、「ネイティブ・フォーマット・ビルダー・ウィザード」を参照してください。)

uniqueMessageSeparatorを使用しない場合、アダプタはEndOfFileを返し、それによってwhileループが終了します。

このため、ファイルの終わりの状況を想定せずに処理を続行する場合は、uniqueMessageSeparatorコンストラクトが必要です。uniqueMessageSeparatorコンストラクトがない場合、ファイルの残りの部分が単一のチャンクとして拒否され、ファイル全体が拒否されます。

4.2.5.2.3 チャンク相互作用のヘッダーおよび拒否されたチャンク相互作用のメッセージの例

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を参照してください。

図4-8 拒否フォルダ内のチャンク読取り相互作用の拒否メッセージ

4.2.6 ファイルのソート

Oracleファイル/FTPアダプタでファイルを特定の順序で処理する必要がある場合は、アダプタのファイル・ソート機能を使用できます。たとえば、ソート・パラメータは、ファイルをタイムスタンプの昇順または降順で処理するように構成できます。

ソート・シナリオの場合、次の前提条件を満たす必要があります。

- 同期操作の使用

- インバウンドJCAファイルへの次のプロパティの追加

<property name="ListSorter"
value="oracle.tip.adapter.file.inbound.listing.TimestampSorterAscending"/>
<property name="SingleThreadModel" value="true"/>

4.2.7 動的アウトバウンド・ディレクトリとファイル名の指定

アウトバウンド・ファイルやアウトバウンド・ディレクトリの論理名または物理名を動的に指定できます。動的なアウトバウンド・ディレクトリを指定する方法は、「アウトバウンド・ファイル・ディレクトリの作成」を参照してください。

4.2.8 セキュリティ

FTP (FTPS)とセキュアFTP (SFTP)をサポートしており、ネットワークを介したセキュアなファイル転送が可能です。

詳細は、「セキュアFTPの使用」および「SFTPの使用」を参照してください。

4.2.9 非トランザクション

インバウンド・ディレクトリからファイルを取得してファイルを処理し、処理したファイルを出力ディレクトリに送信します。ただし、非トランザクションの性質があるため、このプロセス中にOracle RACバックエンドまたはSOA管理サーバーでフェイルオーバーが発生すると、ファイルが2回処理されます。その結果、出力ディレクトリにファイルが重複して存在する場合があります。

4.2.10 プロキシのサポート

プロキシ・サポート機能を使用すると、ファイアウォール外部のFTPサーバーやプロキシ・サーバーを介してのみアクセス可能なFTPサーバーとの間でデータを転送および取得できます。プロキシ・サーバーにより、イントラネット上のホストからインターネット上のホストに間接的に接続できます。図4-9 に、プロキシ・サーバーが接続を作成してクライアントとリモートFTPサーバーとの直接接続をシミュレートする様子を示します。

図4-9 プロキシ・サーバーを介したリモートFTPサーバー接続

HTTPプロキシ機能を使用するには、プロキシ・サーバーでHTTP接続を介したFTP通信量をサポートしている必要があります。また、この機能でサポートされるのはパッシブ・データ接続のみです。構成方法の詳細は、「HTTPプロキシ用の構成」を参照してください。

4.2.11 ペイロード以外のサポート

Oracle BPEL PMの場合、BPELプロセスに対するファイル名、ディレクトリ、ファイル・サイズ、最終変更時間などのファイル・メタデータのみのパブリッシュをサポートしており、ペイロードは除外されます。このプロセスでは、このメタデータを以降の処理に使用できます。たとえば、プロセスで別の参照をコールし、以降の処理のためにファイル名とディレクトリ名を渡すことができます。通知サービスとして使用し、インバウンド・ディレクトリに新規ファイルが出現するたびにプロセスに通知できます。この機能を使用するには、読取り操作の構成時にJDeveloperウィザードで「ファイルの内容を読み取らない」チェック・ボックスを選択します。

4.2.12 大きなペイロードのサポート

Oracle BPEL PMの場合、大きいファイルを添付として転送する機能をサポートしています。この機能を使用するには、読取り操作の構成時にJDeveloperの構成ウィザードで「ファイルを添付ファイルとして読取り」チェック・ボックスを選択します。

このオプションを選択すると、ある場所から別の場所へ大量のデータが添付として不透明に転送されます。たとえば、大量のMS Word文書、イメージおよびPDFをコンポジット・アプリケーション内でコンテンツを処理せずに転送できます。大きなペイロードを添付として渡す方法は、「添付ファイルとしてのOracleファイル・アダプタのRead File」を参照してください。

さらに、Oracleファイル・アダプタにより、ファイルを添付として書き込む機能が提供されます。ファイルを添付ファイルとして書き込むときに標準ペイロードも所有している場合は、添付ファイルが書き込まれ、ペイロードは無視されます。

注意:

大きなペイロードを不透明スキーマとして渡すことはできません。

4.2.13 ファイルベースのトリガー

インバウンド・アダプタのエンドポイントのアクティブ化の制御に使用可能なファイルベースのトリガーをサポートしています。ファイルベースのトリガーの使用方法は、「ファイル・ポーリング」を参照してください。

4.2.14 ファイルの前処理および後処理

プロセス・モデラーでは、処理のためにファイルを取得する前に前処理を行ったり、宛先フォルダにファイルを書き出す前に後処理を行う必要がある状況が発生する場合があります。たとえば、Oracleファイル/FTPアダプタで受信されたファイルは圧縮または暗号化される可能性があるため、ファイルを処理する前に、アダプタでファイルを解凍または復号化する必要があります。この場合、カスタム・コードを使用して、ファイルを処理する前に解凍または復号化する必要があります。Oracleファイル/FTPアダプタでは、ファイルの前処理や後処理のためにプラグインできるカスタム・コードの使用がサポートされています。

ファイルの前処理および後処理の実装は、Oracleファイル/FTPアダプタの次の通信モードに制限されています。

- Read FileまたはGet File

- Write FileまたはPut File

- 同期Read File

- チャンク読取り

この項では、次の項目について説明します。

- ファイルの前処理および後処理のメカニズム

- パイプラインの構成

- Zipファイルに対するリエントラント・バルブの使用

- バッチ通知ハンドラの構成

4.2.14.1 ファイルの前処理および後処理のメカニズム

ファイルの前処理および後処理のメカニズムは、パイプラインおよびバルブとして構成されます。この項では、パイプラインおよびバルブについて説明します。

パイプラインには、カスタム定義された一連のバルブが含まれます。ファイルシステムからパイプラインにロードされたストリームは、順序付けられた一連のバルブによって処理され、処理の後に、変更されたストリームがアダプタに返されます。

バルブは、パイプライン処理における主要な実行コンポーネントです。バルブでは、受信したコンテンツを処理して、処理済のコンテンツを次のバルブに転送します。たとえば、暗号化され、かつ圧縮されたファイルをOracleファイル/FTPアダプタで受信するというシナリオでは、解凍バルブの後に復号化バルブを使用するパイプラインを構成できます。図4-10 に示すように、ファイル・コンテンツは解凍バルブで解凍された後、復号化バルブに転送され、復号化バルブで復号化されて、最終的なコンテンツがOracleファイル/FTPアダプタで使用できるようになります。

図4-10 サンプルの前処理パイプライン

4.2.14.2 パイプラインの構成

ファイルの前処理および後処理のメカニズムを構成するには、パイプラインを定義して、対応するJCAファイルでパイプラインを構成する必要があります。

パイプラインを構成する手順は、次のとおりです。

- バルブの実装および拡張

- バルブのコンパイル

- パイプラインの作成

- SOAプロジェクト・ディレクトリへのパイプラインの追加

- パイプラインの登録

4.2.14.2.1 バルブの実装および拡張

- すべてのバルブに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アダプタ・バルブ」を参照してください。

4.2.14.2.2 バルブのコンパイル

- バルブをコンパイルするには、bpm-infra.jarファイルを使用する必要があります。bpm-infra.jarファイルは、$MW_HOME/AS11gR1SOA/soa/modules/oracle.soa.fabric_11.1.1/bpm-infra.jarにあります。

1. bpm-infra.jarファイルに対するSOAプロジェクトを参照するには、次の手順を使用します。

a. 「アプリケーション・ナビゲータ」で、SOAプロジェクトを右クリックします。

b. 「プロジェクト・プロパティ」を選択します。「プロジェクト・プロパティ」ダイアログが表示されます。

c. 「ライブラリとクラスパス」をクリックします。図4-11 に示すように、「ライブラリとクラスパス」ペインが表示されます。

図4-11 「プロジェクト・プロパティ」ダイアログ

d. 「Jar/ディレクトリの追加」をクリックします。「アーカイブまたはディレクトリの追加」ダイアログが表示されます。

e. 参照してbpm-infra.jarファイルを選択します。Bpm-infra.jarファイルは、$MW_HOME/AS11gR1SOA/soa/modules/oracle.soa.fabric_11.1.1/bpm-infra.jarにあります。

f. 「OK」をクリックします。bpm-infra.jarファイルが「クラスパス・エントリ」に表示されます。

2. bpm-infra.jarファイルを使用してバルブをコンパイルします。

3. コンパイルされたバルブを含むJARファイルをsoainfraドメインのクラスパスに追加して、Oracle WebLogic Serverクラスパスで使用できるようにします。たとえば、$MW_HOME/user_projects/domains/soainfra/libなどです。

注意:

「クラス・ファイルのバージョン50.0が正しくありません。49.0である必要があります。」などのコンパイル・エラーを回避するには、JDK 6.0を使用してbpm-infra.jarをコンパイルするようにしてください。

4.2.14.2.3 パイプラインの作成

- パイプラインを構成するには、次のスキーマに準拠する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>

4.2.14.2.4 SOAプロジェクト・ディレクトリへのパイプラインの追加

- pipeline.xmlファイルをSOAプロジェクト・ディレクトリに追加する必要があります。パイプラインを統合するには、この手順が必須です。図4-12 に、InboundUnzipAndOutboundZipプロジェクトに追加されたサンプルのpipeline.xmlファイル(unzippipeline.xml)を示します。

図4-12 unzippipeline.xmlファイルを含むプロジェクト

4.2.14.2.5 パイプラインの登録

- 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を使用する場合にのみ構成できます。

4.2.14.3 Zipファイルに対するリエントラント・バルブの使用

リエントラント・バルブを使用すると、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ファイル内の個別のエントリに対する変換エラーがある場合、変換エラーのあるエントリは拒否され、他のエントリが処理されます。

パブリッシュ操作中のエラーがある場合、パブリッシュ操作は再試行され、再試行セマンティックが保持されます。再試行セマンティックが保持されない場合、元のファイルが拒否されてパイプラインは終了します。

4.2.14.4 バッチ通知ハンドラの構成

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>

4.2.15 エラー処理

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="&quot;">
</xsd:element>
<xsd:element name="Designation"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="Car" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="Labtop" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="Location"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;">
</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.2.15.1 不正な形式のXMLファイルのローカル・ファイルシステム・フォルダへの送信

インバウンド読取りの操作中、不正な形式のXMLファイルが読み取られるとエラーが発生します。エラーになったファイルは、デフォルトでリモート・ファイル・システムに送信されてアーカイブされます。

エラー・ファイルをローカル・ファイルシステムでアーカイブするには、jcaファイル内でuseRemoteErrorArchiveプロパティを指定し、そのプロパティをfalseに設定します。

このプロパティのデフォルト値はtrueです。

4.2.16 スレッド・モデル

この項では、サポートするスレッド・モデルについて説明します。抑制または抑制解除するには、スレッド・モデルの知識が必要です。次のスレッド・モデルを使用します。

- デフォルトのスレッド・モデル

- 変更されたスレッド・モデル

4.2.16.1 デフォルトのスレッド・モデル

デフォルトのスレッド・モデルでは、インバウンドの各エンドポイントに対してポーラーが作成されます。ポーラーは、ファイル・メタデータをインメモリー・キューにエンキューします。このファイル・メタデータはプロセッサ・スレッドのグローバル・プールによって処理されます。図4-13 はデフォルトのスレッド・モデルを示しています。

図4-13 デフォルトのスレッド・モデル

次の手順で、デフォルトのスレッド・モデルの機能を明確に示します。

1. ポーラーは、入力ディレクトリ内のファイルを定期的に検索します。ポーラーがファイルを検索する間隔は、インバウンドJCAファイルのPollingFrequencyパラメータで指定されます。

2. ポーラーは、構成済のインバウンド・ディレクトリで検出した新規ファイルごとに、ファイル名、ファイル・ディレクトリ、変更時間、ファイル・サイズなどの情報を内部のインメモリー・キューにエンキューします。

注意:

新規ファイルとは処理されていないファイルです。

3. プロセッサ・ワーカー・スレッドのグローバル・プールは、インメモリー・キューのファイルの処理を待機します。

4. プロセッサ・ワーカー・スレッドは内部キューからファイルを取得し、次のアクションを実行します。

a. 適切なトランスレータ(テキスト、バイナリ、XMLまたは不透明データを読み取るトランスレータなど)にファイルの内容をストリームします。

b. トランスレータによるXMLの結果をSCAインフラストラクチャにパブリッシュします。

c. ファイル処理後の削除やアーカイブなど、必要な後処理を実行します。

4.2.16.2 変更されたスレッド・モデル

デフォルトのスレッド動作を変更できます。スレッド・モデルを変更すると、抑制動作が変更されます。以降の各項では、変更されたスレッド動作について説明します。

- シングル・スレッド・モデル

- パーティション化スレッド・モデル

4.2.16.2.1 シングル・スレッド・モデル

シングル・スレッド・モデルは、ポーラーがプロセッサの役割を果たせるようにする、変更されたスレッド・モデルです。ポーラー・スレッドは、同じスレッド内のファイルを処理します。このモデルでは、プロセッサ・スレッドのグローバル・プールは使用されません。シングル・スレッド・モデルのプロパティは、インバウンドJCAファイルで次のように定義できます。

例 - シングル・スレッド・モデルのプロパティの定義

<activation-spec className="oracle.tip.adapter.file.
inbound.FileActivationSpec">
<property../>
<property name="SingleThreadModel" value="true"/>
<property../>
</activation-spec>

4.2.16.2.2 パーティション化スレッド・モデル

パーティション化スレッド・モデルは、インメモリー・キューがパーティション化され、各コンポジット・アプリケーションがそれぞれのインメモリー・キューを取得する、変更されたスレッド・モデルです。プロセッサ・ワーカー・スレッドのグローバル・プールに依存しないで独自のプロセッサ・スレッドを作成し、エンキューされたファイルを処理できます。パーティション・モデルのプロパティは、インバウンド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です。

4.2.17 パフォーマンス・チューニング

インバウンド操作とアウトバウンド操作を抑制するためのノブを提供することでパフォーマンス・チューニング機能をサポートしています。アウトバウンド操作のパフォーマンス・チューニングに使用できるパラメータも提供されます。

パフォーマンス・チューニングの詳細は、このマニュアルの「Oracle JCAアダプタ・チューニング・ガイド」を参照してください。

4.2.18 高可用性

Oracle BPEL Process Managerおよびサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能をサポートしています。この機能は、インバウンド操作とアウトバウンド操作の両方でサポートされています。

4.2.19 複数のディレクトリ

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>

図4-14 「アダプタ構成ウィザード - ファイル・ディレクトリ」ページ

4.2.20 追加モード

使用すると、既存のファイルに追加するアウトバウンド相互作用を構成できます。「既存のファイルに追加します」オプションを使用すると、アウトバウンド起動で同じファイルに書き込むことができます。ファイル名に追加するには、2つの方法があります。

- 静的 - アウトバウンドのJCAファイルに追加します。

- 動的 - ヘッダー・メカニズムを使用します。

注意:

SFTPシナリオの場合、追加モードはサポートされておらず、既存のファイルに追加されるかわりにファイルが上書きされます。

「ファイル構成」ページで「既存のファイルに追加します」オプションを選択すると、「メッセージ数の到達」、「経過時間の超過」、「ファイル・サイズの超過」などのバッチ処理オプションが無効になります。図4-15 に、「既存のファイルに追加します」オプションを示します。

図4-15 「アダプタ構成ウィザード - ファイル構成」ページ

ウィザードで「追加」を選択すると、バッチ処理オプションが無効化されます。また、静的ファイル・ネーミング規則ではなく動的ファイル・ネーミング規則を指定すると、次のエラー・メッセージが表示されます。

You cannot choose to Append Files and use a dynamic file naming convention at the same time

追加機能を使用する場合は、FTPサーバーがAPPEコマンドをサポートしていることを確認してください。

4.2.21 ディレクトリ内のファイルの再帰的処理

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: このパラメータでは、バリアントのロケール・コンストラクトを指定します。

4.2.21.1 デプロイメント・ディスクリプタのパラメータの構成

通常、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>

4.2.22 エンタープライズ情報システムの資格証明の保護

リソース・アダプタは、エンタープライズ情報システム(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へのアクセスに必要な対応する資格証明にマップされます。デプロイ済の任意のリソース・アダプタに適用可能なセキュリティ・プリンシパルについて、資格証明マッピングを構成できます。

最初にコンテナ管理のサインオンを使用するには、使用する接続プールでコンテナ管理のサインオンがサポートされていることを確認する必要があります。既存の接続プールに対してコンテナ管理のサインオンを有効にする場合、またはコンテナ管理のサインオンをサポートする新規のプールを作成する場合は、次の手順を実行します。

1. SOAアダプタ.rarファイルが含まれているOracle SOAインストール・ディレクトリ(例: </fmwhome/AS11gR1SOA>/soa/connectorsまたは<C:\Oracle\Middleware\Oracle_SOA1>\soa\connectors。大カッコ内のパスは適切なパスで置き換えてください。)に移動します。

2. weblogic-ra.xmlを変更するアダプタ.rarファイル(FtpAdapter.rarなど)のバックアップ・コピーを作成します。

3. .rarファイルからweblogic-ra.xmlを抽出し、抽出したweblogic-ra.xmlをエディタで開きます。

4. weblogic-ra.xml内の既存の接続プールについて、その接続プールの<wls:connection-properties>の下に<wls:res-auth>Container</wls:res-auth>が存在しない場合は、このプロパティを接続プールに追加します。

たとえば、FTPアダプタ内の事前構成済のeis/Ftp/FtpAdapter接続プールは、次の例のように定義されています。

例 - 事前構成済の接続プールの定義

<wls:connection-instance>
<wls:description>Ftp Adapter</wls:description>
<wls:jndi-name>eis/Ftp/FtpAdapter</wls:jndi-name>
<wls:connection-properties>
<wls:res-auth>Container</wls:res-auth>
</wls:connection-properties>

この例は、このプールでコンテナ管理のサインオンがサポートされることを示しています。

5. コンテナ管理のサインオンをサポートする新規の接続プールを作成するには、既存のインスタンスを例として使用して、新規の接続プール・インスタンスを追加します。JNDI名またはコネクション・ファクトリ名(あるいはその両方)を適切な名前に置き換える必要があります。コンテナ管理のサインオンをサポートするJMS接続プールのサンプル構成を次に示します。

(コンテナ管理のサインオンを有効にするには、java.naming.factory.initialおよびjava.naming.provider.urlが存在している必要があります。)

例 - コンテナ管理のサインオンをサポートするJMS接続プールのサンプル構成

<connection-instance>
<jndi-name>eis/jms/MyConnectionPool</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value>jms/MyConnectionFactory</value>
</property>
<property>
<name>FactoryProperties</name>
<value>java.naming.factory.initial
=weblogic.jndi.
WLInitialContextFactory;java.
naming.provider.url=
t3://ncosmidi-us5.us.
mydomain.com:8001</value>
</property>
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>true</value>
</property>
<property>
<name>IsTransacted</name>
<value>false</value>
</property>
<property>
<name>Username</name>
<value></value>
</property>
<property>
<name>Password</name>
<value></value>
</property>
</properties>
<res-auth>Container</res-auth>
</connection-properties>
</connection-instance>

6. 変更したweblogic-ra.xmlをadapter.rarに戻し、.rarファイル内で既存のweblogic-ra.xmlと置き換わっていることを確認します。

7. WebLogic Serverコンソールの「デプロイメント」に進み、アダプタ(FTPアダプタやJMSアダプタなど)を選択します。「更新」をクリックします。

8. 新規の接続プール(JMSプールなど)を作成する場合、「デプロイメント」→「JmsAdapter」→「構成」→「アウトバウンド接続プール」を順に開き、「oracle.tip.adapter.jms.IJmsConnectionFactory」を開いて新規の接続プールが存在していることを確認します。

これらの手順の実行後、Oracle WebLogic Serverコンソールを使用して次の手順を実行して、対応するプールの資格証明マッピングを構成できます。これを行うには、次の手順を実行します。

9. Oracle WebLogic Server管理コンソールにログインします。

「ドメイン構造」ペインで「デプロイメント」をクリックします。図4-16 に示すように、デプロイ済のアプリケーションとアダプタが表示されます。

図4-16 Oracle WebLogic Server管理コンソール - 「デプロイメントの概要」ページ

10. セキュリティ資格証明を作成する必要のあるアダプタをクリックします。たとえば、FtpAdapterをクリックします。図4-17 に示すように、「FtpAdapterの設定」ページが表示されます。

図4-17 Oracle WebLogic Server管理コンソール - 「FtpAdapterの設定」ページ

11. 「セキュリティ」タブをクリックします。図4-18 に示すように、「FtpAdapterの設定」ページの「スタンドアロン・リソース・アダプタ・ロール」ペインが表示されます

図4-18 Oracle WebLogic Server管理コンソール - 「FtpAdapterの設定」ページ

12. 「資格証明マッピング」タブをクリックします。

13. 「資格証明マッピング」ペインで「新規」をクリックします。図4-19 に示すように、「新しいセキュリティ資格証明マッピングの作成」ページが表示されます。

図4-19 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ

14. 図4-20に示すように、「eis/Ftp/FtpAdapter」(JNDI)を選択し、セキュリティ資格証明マップ・エントリを作成します。

図4-20 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ

15. 「次」を選択します。図4-21 に示すように、「新しいセキュリティ資格証明マッピングの作成 - WebLogic Serverユーザー」ページが表示されます。

図4-21 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ

注意:

「初期接続作成用ユーザー」および「未認証WLSユーザー」オプションの場合、資格証明マッピングはサポートされていません。

16. 図4-22 に示すように、「構成済みユーザー名」を選択し、「WebLogic Serverユーザー名」フィールドにOracle WebLogic Serverユーザー名を入力します。たとえば、weblogicと入力します。これはデフォルト・ユーザー名です。構成によっては「構成済みユーザー名」を使用できないことがあるため、その場合は「デフォルト・ユーザー」を選択します。

図4-22 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ

17. 「次」を選択します。「新しいセキュリティ資格証明マッピングの作成 - EISユーザー名およびパスワード」ページが表示されます。

18. 図4-23 に示すように、「EISユーザー名」フィールドにEISユーザー名を入力し、「EISパスワード」フィールドにEISパスワードを入力し、「パスワードの確認」フィールドにEISパスワードを再入力してパスワードを確認します。

図4-23 Oracle WebLogic Server管理コンソール - 「新しいセキュリティ資格証明マッピングの作成」ページ

19. 「終了」をクリックします。図4-24 に示すように、新しいセキュリティ資格証明マッピングが作成されます。

図4-24 Oracle WebLogic Server管理コンソール - 「FtpAdapterの設定」ページ

4.3 Oracleファイル/FTPアダプタの説明

概念については、次の項で説明しています。

- ファイル読取りの説明

- ファイル書込みの説明

- 同期読取りの説明

- ファイル・リスティングの説明

- Get Fileの説明

- Put Fileの説明

- 同期Get Fileの説明

- ファイル・リスティングの説明

- ファイル/FTPアダプタの拡張

4.3.1 ファイル読取りの説明

インバウンド方向では、ファイルシステムからのファイルのポーリングおよび読取りが行われて処理されます。この項では、インバウンド・ファイル読取り機能の概要を説明します。BPELプロセスで使用するように構成するには、アダプタ構成ウィザードを使用します。構成すると、インバウンドのWSDLおよびJCAファイルのペアが作成されます。

次の項では、ファイル読取りについて説明します。

- インバウンド操作

- インバウンド・ファイル・ディレクトリの指定

- ファイルの検索とバッチ処理

- ファイル・ポーリング

- 後処理

- ネイティブ・データ変換

- インバウンド・サービス

- インバウンド・ヘッダー

4.3.1.1 インバウンド操作

インバウンド操作では、図4-25に示すように「Read File」操作を選択します。

図4-25 「Read File」操作の選択

4.3.1.2 インバウンド・ファイル・ディレクトリの指定

図4-26 に示すアダプタ構成ウィザードの「ファイル・ディレクトリ」ページでは、インバウンド・ファイルの読取りに使用するディレクトリや、正常に処理されたファイルを配置するディレクトリの情報を指定できます。ディレクトリ内のファイルを再帰的に処理することも選択できます。さらに、複数のディレクトリも指定できます。

図4-26 アダプタ構成ウィザード - 着信ファイルの指定

次の項では、指定するファイル・ディレクトリ情報について説明します。

- SOAコンポジットでのインバウンドの物理または論理ディレクトリ・パスの指定

- 正常に処理されたファイルのアーカイブ

- 取得後のファイルの削除

4.3.1.2.1 SOAコンポジットでのインバウンドの物理または論理ディレクトリ・パスの指定

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>

4.3.1.2.2 正常に処理されたファイルのアーカイブ

このオプションでは、正常に処理されたファイルを配置するディレクトリを指定できます。また、アーカイブ・ディレクトリを論理名として指定できます。この場合は、「SOAコンポジットでのインバウンドの物理または論理ディレクトリ・パスの指定」で説明されている論理ディレクトリから物理ディレクトリへのマッピングを行う必要があります。

4.3.1.2.3 取得後のファイルの削除

このオプションでは、ファイルを正常な取得後に削除するかどうかを指定できます。このチェック・ボックスが選択されていない場合、処理済のファイルはインバウンド・ディレクトリに残りますが無視されます。最後に処理されたファイルより更新日が新しいファイルのみが取得されます。処理済のファイルと同じ名前で更新日が古いままのファイルをインバウンド・ディレクトリに配置した場合、そのファイルは取得されません。

4.3.1.3 ファイルの検索とバッチ処理

図4-27 に示すアダプタ構成ウィザードの「ファイルのフィルタ処理」ページでは、取得または無視するファイルの詳細を指定できます。

インバウンド方向のファイル・リスナーとして機能します。ローカルまたはリモートのファイルシステム上の指定したディレクトリがポーリングされ、指定したネーミング基準に一致するファイルが検索されます。

図4-27 「アダプタ構成ウィザード - ファイルのフィルタ処理」ページ

次の項では、指定するファイル・フィルタ処理情報について説明します。

- ネーミング・パターンの指定

- 処理対象ファイルと処理対象外ファイル

- メッセージのデバッチ処理

4.3.1.3.1 ネーミング・パターンの指定

インバウンド・ファイルのポーリングに使用するネーミング規則を指定します。また、処理対象外にするファイルのネーミング規則も指定できます。2つのネーミング規則を選択できます。インバウンド・ディレクトリに配置されるファイルと一致します。

- ファイル・ワイルドカード(po*.txt)
poで始まり.txtで終わるすべてのファイルが取得されます。この規則はWindowsオペレーティング・システムの標準に準拠しています。

- 正規表現(po.*\.txt)
poで始まり.txtで終わるすべてのファイルが取得されます。この規則は、Java Development Kit (JDK)の正規表現(regex)構文に準拠しています。

注意:

- 後から別のネーミング・パターンを選択する場合は、「インクルード・ファイルの名前パターン」および「処理対象外ファイルの名前パターン」フィールドで指定するネーミング規則も変更してください。アダプタ構成ウィザードにより自動的に変更されることはありません。

- ファイルを取得する際、検索対象として*.*を指定しないでください。

- オペレーティング・システムにより設定されているファイルの長さの制限に注意してください。たとえば、Windowsオペレーティング・システムでは、ファイル名(ファイル名と完全なディレクトリ・パスを合せた長さ)を256文字より長くできません。制限によりファイル名に特定の文字を使用できないオペレーティング・システムもあります。たとえば、Windowsオペレーティング・システムでは、バックスラッシュ(\)、スラッシュ(/)、コロン(:)、アスタリスク(*)、左角カッコ(<)、右角カッコ(>)または縦線(|)などの文字は許可されていません。

4.3.1.3.2 処理対象ファイルと処理対象外ファイル

正規表現を使用する場合、「インクルード・ファイルの名前パターン」および「処理対象外ファイルの名前パターン」フィールドで指定する値は、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の正規表現構文

一致対象

構文

文字

-

文字x

x

バックスラッシュ文字

\\

8進数値0n (0 <= n <= 7)を含む文字

\0n

8進数値0nn (0 <= n <= 7)を含む文字

\0nn

8進数値0mnn (0 <= m <= 3、0 <= n <= 7)を含む文字

\0mnn

16進数値0xhhを含む文字

\xhh

16進数値0xhhhhを含む文字

\uhhhh

タブ文字('\u0009')

\t

改行文字('\u000A')

\n

キャリッジ・リターン文字('\u000D')

\r

用紙送り文字('\u000C')

\f

警告(ベル)文字('\u0007')

\a

エスケープ文字('\u001B')

\e

xに対応する制御文字

\cx

-

-

文字クラス

-

a、b、またはc (単純クラス)

[abc]

a、b、c以外の文字(否定)

[^abc]

a - zまたはA - Z (範囲)

[a-zA-Z]

a - dまたはm - p: [a-dm-p] (結合)

[a-d[m-p]]

d、e、またはf (交差)

[a-z&&[def]]

a - z (bとcを除く): [ad-z] (減算)

[a-z&&[^bc]]

a - z (m - pを除く): [a-lq-z] (減算)

[a-z&&[^m-p]]

-

-

定義済の文字クラス

-

任意の文字(行の終了文字と一致する場合もある)

-

数字: [0-9]

\d

数字以外: [^0-9]

\D

空白文字: [ \t\n\x0B\f\r]

\s

空白文字以外: [^\s]

\S

単語文字: [a-zA-Z_0-9]

\w

単語以外の文字: [^\w]

\W

最長一致数量子

-

X、1回または0回

X?

X、0回以上

X*

X、1回以上

X+

X、n回

X{n}

X、n回以上

X{n,}

X、n回以上m回以下

X{n,m}

Java regex構文の詳細は、次のサイトを参照してください。

http://java.sun.com/j2se/1.5.0/docs/api

4.3.1.3.3 処理対象ファイルと処理対象外ファイル

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は変更できません。

4.3.1.3.4 メッセージのデバッチ処理

複数のメッセージが含まれるファイルを着信するかどうかを選択し、パブリッシュする1つのバッチ・ファイルに含まれるメッセージ数を指定できます。ファイルに反復要素を含むメッセージが含まれる場合、特定のバッチ数でメッセージをパブリッシュするように選択できます。図4-27を参照してください。

ファイルに複数のメッセージがありチェック・ボックスが選択されている場合は、デバッチ処理が行われます。デバッチ処理が行われないのは、ファイルのメッセージが1つのみでチェック・ボックスが選択されていない場合です。ネイティブ・ファイルとXMLファイルではデバッチ処理がサポートされています。

4.3.1.4 ファイル・ポーリング

図4-28 に示すアダプタ構成ウィザードの「ファイル・ポーリング」ページでは、次に示すインバウンド・ポーリング・パラメータを指定できます。

- 新しいファイルを取得するためにインバウンド・ディレクトリをポーリングする頻度。

- 取得するファイルの最短経過時間。たとえば、このポーリング・パラメータにより、大きなファイルが処理用に取得される前に、ディレクトリに完全にコピーできるようになります。経過時間は最終更新時のタイムスタンプで決定されます。たとえば、ファイルの書込みに3分から4分かかることがわかっている場合は、最短経過時間を5分に設定します。入力ディレクトリでファイルが検出されても、更新時間から5分経過していない場合、まだ書込みが行われている可能性があるためファイルは取得されません。

図4-28 「アダプタ構成ウィザード - ファイル・ポーリング」ページ

注意:

JCAファイル内のpollingパラメータの値を手動で変更しないでください。このパラメータを変更するには、アダプタ構成ウィザードを使用する必要があります。

4.3.1.4.1 トリガー・ファイルの使用

デフォルトでは、エンドポイントがアクティブ化されると、インバウンドのOracleファイル/FTPアダプタによるポーリングが開始されます。ただし、より厳密にポーリングを制御する場合は、ファイルベースのトリガーを使用できます。Oracleファイル/FTPアダプタでは、指定のトリガー・ファイルがローカル・ディレクトリまたはリモート・ディレクトリで検出されると、そのファイルのポーリングがインバウンド・ディレクトリ内で開始されます。

たとえば、あるBPELプロセスがファイルをディレクトリに書き込んでおり、第2のBPELプロセスが同じディレクトリでファイルをポーリングしているとします。第1のプロセスによる全ファイルの書込みが完了した後でのみ、第2のプロセスによるディレクトリのポーリングを開始するために、トリガー・ファイルを使用できます。第1のプロセスを、最後にトリガー・ファイルを作成するように構成できます。第2のプロセスは、トリガー・ファイルを検出した後でインバウンド・ディレクトリのポーリングを開始します。

注意:
トリガー・ファイルのライフサイクルは、アダプタでは管理されません。トリガー・ファイルは外部で管理する必要があります。たとえば、エンドポイントをアントリガーし、外部アプリケーションを使用してトリガー・ファイルを削除して、TriggerFileStrategyをEndpointActivationまたはEveryTimeに指定します。

トリガー・ファイル・ディレクトリは、インバウンドのポーリング・ディレクトリと同一でなくてもかまいません。ただし、トリガー・ファイル・ディレクトリおよびインバウンドのポーリング・ディレクトリが同じ場合は、図4-27 に示すように、トリガー・ファイルの名前がアダプタ構成ページで指定したファイル・フィルタに類似していないことを確認する必要があります。

トリガー・ファイルの内容が読み取られることはないため、インバウンドのreceiveアクティビティのペイロードとして使用しないでください。

表4-5 に、インバウンド・サービスのJCAファイルに指定する必要があるパラメータを示します。

表4-5 トリガー・ファイルのパラメータ

パラメータ

説明

例

TriggerFilePhysicalDirectory

または

TriggerFileLogicalDirectory

Oracleファイル/FTPアダプタがトリガー・ファイルを検索するディレクトリの物理名または論理名。

TriggerFilePhysicalDirectoryおよびTriggerFileLogicalDirectoryパラメータはオプションです。この2つのパラメータを使用する必要があるのは、トリガー・ファイル・ディレクトリがインバウンドのポーリング・ディレクトリとは異なる場合のみです。デフォルトでは、Oracleファイル/FTPアダプタはトリガー・ファイルをインバウンドのポーリング・ディレクトリ内で検索します。

TriggerFilePhysicalDirectory="C:\foo"

TriggerFileLogicalDirectory= "TriggerFileDir"

TriggerFile

トリガー・ファイル名。

TriggerFile="Purchaseorder.trg"

TriggerFileStrategy

トリガー・メカニズムとして使用される戦略。次の値をとります。

EndpointActivation: アダプタは、コンポジットがアクティブ化されるたびにトリガー・ファイルを検索します。注意: コンテナの起動、アプリケーションの再デプロイ、Fusion Middleware Controlによるコンポジット・アプリケーションのリタイアまたはアクティブ化を行うたびに、コンポジットがアクティブ化されます。

コンテナを再起動するたびに、指定されたディレクトリでトリガー・ファイルが検出されるまでコンポジット・アプリケーションはトリガーされません。

OnceOnly: アダプタは、その存続期間で1回のみトリガー・ファイルを検索します。検出されたトリガー・ファイルは、再起動後および再デプロイ後も記憶されます。

EveryTime: アダプタは、各ポーリング・サイクルでトリガー・ファイルを検索します。TriggerFileStrategyのデフォルト値はEndpointActivationです。

TriggerFileStrategy="EndpointActivation "

インバウンド・サービスにおける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.3.1.5 後処理

いくつかの後処理オプションをサポートしています。ファイルの処理後、図4-28 の「ファイル・ポーリング」ページで指定した場合はファイルが削除されます。また、図4-26 の「ファイル・ディレクトリ」ページで指定した場合は、完了(アーカイブ)ディレクトリにファイルを移動することもできます。

4.3.1.6 ネイティブ・データ変換

次に表示されるアダプタ構成ウィザードのページは、図4-29 の「メッセージ」ページです。このページでは、変換用のXSDスキーマ・ファイルを選択できます。

図4-29 スキーマの指定 - 「メッセージ」ページ

ネイティブ・フォーマット変換が不要である場合は(JPGまたはGIFイメージが処理中であるなど)、「ネイティブ・フォーマット変換は不要」チェック・ボックスを選択します。ファイルはBase64エンコーディングで渡されます。

トランスレーションにはXSDファイルが必要です。新しいスキーマの定義、または既存のデータ型定義(DTD)やCOBOLコピーブックの変換を行うには、「ネイティブ・フォーマットのスキーマの定義」を選択します。これにより、ネイティブ・フォーマット・ビルダー・ウィザードが起動されます。このウィザードは、カンマ区切り値(CSV)、固定長、DTDおよびCOBOLコピーブックなどのファイル形式を使用したネイティブ・スキーマ・ファイルの作成を支援します。ネイティブ・スキーマ・ファイルの作成後、「スキーマ・ファイルのURL」および「スキーマ要素」フィールドが入力された「メッセージ」ページが表示されます。詳細は、「サポートされているファイル形式」を参照してください。

注意:

指定するスキーマにネームスペースが含まれていることを確認してください。スキーマにネームスペースがないと、エラー・メッセージが表示されます。

4.3.1.7 インバウンド・サービス

構成が終了すると、インバウンド・サービスのJCAファイルが生成されます。ファイル名は、アダプタ構成ウィザードの「サービス名」ページで指定したサービス名と同じです。後からウィザードを再起動して、操作定義を変更できます。

ActivationSpecパラメータには、インバウンド構成情報が含まれています。ActivationSpecと一連のインバウンド・プロパティは、インバウンドJCAファイルの一部です。

表4-6 に、インバウンドJCAファイルのサンプルのプロパティを示します。

表4-6 インバウンド・サービスのサンプルのJCAプロパティ

プロパティ

サンプル値

UseHeaders

true

PhysicalDirectory

/tmp/opaque/in

Recursive

true

DeleteFile

false

IncludeFiles

.*\.xml

PollingFrequency

1

MinimumAge

0

ActivationSpecプロパティの値は、設計時にアダプタ構成ウィザードで指定されます(表4-6 を参照)。インバウンドでは次の構成プロパティを表使用します。

- PollingFrequency

- MinimumAge

- PhysicalDirectory

- LogicalDirectory

- PublishSize

- PhysicalArchiveDirectory

- LogicalArchiveDirectory

- IncludeFiles

- ExcludeFiles

- UseHeaders

- ListSorter

- ThreadCount

- Recursive

- MaxRaiseSize

これらの構成プロパティの説明は、このマニュアルの付録Aを参照してください。

4.3.1.8 インバウンド・ヘッダー

図4-30に示すように、ペイロードを除いて、次のヘッダー・メタデータをインバウンド・サービスからパブリッシュします。

- jca.file.FileName: ファイル名

- jca.file.Directory: ディレクトリ名

- jca.file.Batch: デバッチ処理におけるバッチの一意の名前

- jca.file.BatchIndex: デバッチ処理におけるバッチ内の各メッセージのバッチ索引

- jca.file.Size: ファイル・サイズ

- jca.file.LastModifiedTime: ファイルの最終変更時間

図4-30 「Invoke」ダイアログ

4.3.2 ファイル書込みの説明

アウトバウンド方向では、サービス・エンジンからのメッセージを受信し、ファイルシステムのファイルに書き込みます。この項では、アウトバウンド・ファイル書込み機能の概要を説明します。BPELプロセスまたはサービスで使用するように構成するには、アダプタ構成ウィザードを使用します。これにより、アウトバウンドのWSDLとJCAのファイルのペアが作成されます。

この項には次のトピックが含まれます:

- アウトバウンド操作

- アウトバウンド・ファイル・ディレクトリの作成

- ネイティブ・データ変換

- アウトバウンド・サービス・ファイル

- アウトバウンド・ヘッダー

4.3.2.1 アウトバウンド操作

アウトバウンド操作では、図4-31に示すように「Write File」操作を選択します。

図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.3.2.2 アウトバウンド・ファイル・ディレクトリの作成

アウトバウンド操作では、アウトバウンド・ディレクトリ、使用するアウトバウンド・ファイル・ネーミング規則、および必要な場合は使用するバッチ・ファイル規則も指定できます。

図4-32 に示すアダプタ構成ウィザードの「ファイル構成」ページでは、発信ファイルのディレクトリやアウトバウンド・ファイル・ネーミング規則を指定できます。

図4-32 アダプタ構成ウィザード - 発信ファイルのパラメータ

次の項では、指定するファイル構成情報について説明します。

- アウトバウンドの物理または論理ディレクトリ・パスの指定

- アウトバウンド・ファイル・ネーミング規則の指定

- 動的なアウトバウンド・ファイル名の指定

- 複数のアウトバウンド・メッセージのバッチ処理

4.3.2.2.1 Oracle BPEL PMでのアウトバウンドの物理または論理ディレクトリ・パスの指定

アウトバウンド・ディレクトリ名を物理または論理パスとして指定できます。物理パスは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文字など)、その名前を持つ空白のファイルがアウトバウンド・ディレクトリに作成されます。

4.3.2.2.2 アウトバウンドの物理または論理ディレクトリ・パスの指定

アウトバウンド・ディレクトリ名を物理または論理パスとして指定できます。物理パスはc:\inputDirのような値です。

図4-26 に示すように、「ファイル・ディレクトリ」ページで設計時に論理名を指定し、「エンドポイント・プロパティ」で論理/物理マッピングを指定できます。たとえば、WriteFileはアウトバウンド・アダプタ・サービスです。設計時には、論理ディレクトリ名としてOutDirを指定しています。

4.3.2.2.3 動的なアウトバウンド・ディレクトリ名の指定

アウトバウンド操作の場合は、動的なアウトバウンド・ディレクトリ名を指定できます。変数を設定すると、動的なアウトバウンド・ディレクトリ名を指定できます。

例 - 変数の設定による動的なアウトバウンド・ディレクトリ名の指定

<?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"に変更されます。

動的なアウトバウンド・ディレクトリ名を指定するには、次の手順を実行します。

1. invokeアクティビティをダブルクリックします。

2. 「変数の参照」アイコンを選択します。

3. 「変数チューザ」ダイアログで「オブジェクトの作成」アイコンをクリックします。

4. 図4-33 に示すように、タイプがxsd:stringの変数MyDirを作成します。

図4-33 「変数の作成」ダイアログ

5. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にassignアクティビティをドラッグ・アンド・ドロップします。

6. assignアクティビティをダブルクリックし、「コピー操作」タブをクリックします。

7. 「作成」をクリックし、「コピー操作」をクリックします。「コピー操作の作成」ダイアログが表示されます。

8. 図4-34 に示すように、「コピー操作の作成」ダイアログで「タイプ」から「式」を選択してディレクトリ名とパスを指定します。このディレクトリに出力ファイルが書き込まれます。

図4-34 「コピー操作の作成」ダイアログ

9. 「コピー操作の作成」ダイアログで「OK」をクリックし、「Assign」ダイアログで「OK」をクリックします。「.bpel」ページが表示されます。

10. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

11. 「プロパティ」タブをクリックします。

12. 「プロパティ」列からjca.file.Directoryプロパティを選択し、「値」をMyDir (ステップ4で作成したディレクトリ)に設定します。図4-35 に示すように、「タイプ」列がinputに設定されていることを確認してください。

図4-35 「Invoke」ダイアログ

注意:

動的ディレクトリを使用する場合は、NumberMessages、ElapsedTime、FileSizeなどのパラメータがアウトバウンド・アダプタ・サービスのWSDLファイルで定義されていないことを確認してください。これらのパラメータは、動的ディレクトリではサポートされていません。

4.3.2.2.4 アウトバウンド・ファイル・ネーミング規則の指定

発信ファイルに使用するネーミング規則を指定します。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のパターン文字

文字

日付または時刻のコンポーネント

表示内容

例

G

紀元

テキスト

AD

y

年

年

1996、96

M

年における月

月

July、Jul、07

w

年における週

数値

27

W

月における週

数値

2

D

年における日

数値

189

d

月における日

数値

10

F

月における曜日

数値

2

E

曜日

テキスト

Tuesday、Tue

a

午前/午後

テキスト

PM

H

1日における時間(0-23)

数値

0

k

1日における時間(1-24)

数値

24

K

午前/午後における時間(0-11)

数値

0

h

午前/午後における時間(1-12)

数値

12

m

1時間における分

数値

30

s

1分における秒

数値

55

S

ミリ秒

数値

978

z

タイムゾーン

一般的なタイムゾーン

Pacific Standard Time、PST、GMT-08:00

Z

タイムゾーン

RFC 822タイムゾーン

-0800

次にパターンの異なる表示内容を示します。

- テキスト
書式設定において、パターン文字が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:

GMT Sign 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の間である必要があります。その他の定義は、一般的なタイムゾーンと同じです。

解析では、一般的なタイムゾーンも使用できます。

4.3.2.2.5 動的なアウトバウンド・ファイル名の指定

アウトバウンド操作の場合は、動的なアウトバウンド・ファイル名を指定できます。変数を設定すると、動的なアウトバウンド・ファイル名を指定できます。

例 - 変数の設定による動的なアウトバウンド・ファイル名の指定

<?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"に変更されます。動的なアウトバウンド・ディレクトリ名を指定するには、次の手順を実行します。

1. invokeアクティビティをダブルクリックします。

2. 「変数の参照」アイコンを選択します。

3. 「変数チューザ」ダイアログで「オブジェクトの作成」アイコンをクリックします。

4. 図4-33 に示すように、タイプがxsd:stringの変数fileを作成します。

5. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にassignアクティビティをドラッグ・アンド・ドロップします。

6. assignアクティビティをダブルクリックし、「コピー操作」タブをクリックします。

7. 「作成」をクリックし、「コピー操作」をクリックします。「コピー操作の作成」ダイアログが表示されます。

8. 図4-34 に示すように、「コピー操作の作成」ダイアログで「タイプ」から「式」を選択してファイル名を指定します。このファイルに出力ファイルが書き込まれます。

9. 「OK」を数回クリックして、assignアクティビティのダイアログを終了します。

10. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

11. 「プロパティ」タブをクリックします。

12. 「プロパティ」列からjca.file.FileNameプロパティを選択し、「値」をfile(ステップ4で作成したファイル)に設定します。図4-36 に示すように、「タイプ」列がinputに設定されていることを確認してください。

図4-36 「Invoke」ダイアログ

注意:

動的ファイルを使用する場合は、NumberMessages、ElapsedTime、FileSizeなどのパラメータがアウトバウンド・アダプタ・サービスのWSDLファイルで定義されていないことを確認してください。これらのパラメータは、動的ファイルではサポートされていません。

4.3.2.2.6 複数のアウトバウンド・メッセージのバッチ処理

最も簡単なシナリオの場合、1つのメッセージに1つのファイルの書込みを指定します。また、バッチ・ファイル書込みに関するアウトバウンドの規則も指定できます。これにより、1つのバッチ・ファイルでパブリッシュするメッセージ数を指定できます。次に示すバッチ・ファイルの設定は、図4-32 の「ファイル構成」ページで指定されています。

- メッセージ数の到達
到達した際に新しい発信ファイルを作成する値を指定します。

- 経過時間の超過
超過した際に新しい発信ファイルを作成する値を指定します。

注意:

「経過時間の超過」バッチ処理基準が評価されて新しい発信ファイルが作成されるのは、起動の発生時のみです。

たとえば、「経過時間の超過」を15秒に指定した場合、最初に受信したメッセージは、バッチ処理条件が有効でないため15秒が経過しても書き込まれません。第2のメッセージを受信すると、第1のメッセージに対してバッチ処理条件が有効になり、経過時間が15秒を超過した時点で出力ファイルが作成されます。

- ファイル・サイズの超過
到達した際に発信ファイルを作成するファイル・サイズを指定します。たとえば、受信したメッセージ数に3を、ファイル・サイズに1MBという値を指定したとします。合計すると1MB以上になる2つのメッセージや、1MBに満たない3つのメッセージを受信した場合に、出力ファイルが作成されます。

注意:

JCAファイル内の前述のリストに指定されているファイル構成を手動で変更しないでください。これらの構成を変更するには、アダプタ構成ウィザードを使用する必要があります。

バッチ処理中に問題が発生した場合、リカバリでは中断した場所からバッチ処理が開始されます。

4.3.2.3 ネイティブ・データ変換

次に表示されるアダプタ構成ウィザードのページは、図4-37 に示す「メッセージ」ページです。このページでは、変換用のXSDスキーマ・ファイルを選択できます。

図4-37 スキーマの指定

インバウンド方向のスキーマの指定と同様に、このページでは次のタスクを実行できます。

- ネイティブ・フォーマット変換の要不要の指定

- 変換用のXSDスキーマ・ファイルの選択

- CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動

「メッセージ」ページの詳細は、「ネイティブ・データ変換」を参照してください。

4.3.2.4 アウトバウンド・サービス・ファイル

アダプタ構成ウィザードを使用した構成が完了すると、アウトバウンド操作用のWSDLとJCAのファイルのペアが生成されます。ファイル名は、図2-8 に示すアダプタ構成ウィザードの「サービス名」ページで指定したサービス名と同じです。後からウィザードを再起動して、操作定義を変更できます。

サンプルのアウトバウンドJCAファイルには、表4-8 に記載されている情報が格納されます。

表4-8 アウトバウンド・サービスのサンプルのJCAプロパティ

プロパティ

サンプル値

PhysicalDirectory

/tmp/flat/OutputDir

FileNamingConvention

address-csv%SEQ%.txt

Append

true

NumberMessages

1

ConcurrentThreshold

0

OpaqueSchema

false

アウトバウンドでは、次の構成パラメータが使用されます。

- PhysicalDirectory

- LogicalDirectory

- NumberMessages

- ElapsedTime

- FileSize

- FileNamingConvention

- Append

これらの構成プロパティの詳細は、「Oracle JCAアダプタのプロパティ」を参照してください。

4.3.2.5 アウトバウンド・ヘッダー

ペイロードを除いて、次のヘッダーをコンポーネントから受信します。

- jca.file.FileName: ファイル名

- jca.file.Directory: ディレクトリ名

4.3.3 同期読取りの説明

アウトバウンド方向では、Oracleファイル/FTPアダプタは1つのファイルのコンテンツを読み取ることができます。この項では、アウトバウンドの同期ファイル読取り機能の概要について説明します。ファイルを同期的に読み取るには、図4-38 に示すように「同期Read File」操作を選択します。

図4-38 同期読取り操作のページ

アウトバウンド方向では、Oracleファイル/FTPアダプタを使用すると、同期ファイル読取り操作を使用して1つのファイルのコンテンツを読み取ることができます。この操作により、ファイルを添付ファイルとして読み取ることができるようになりました。ファイルを添付ファイルとして読み取るためのチェック・ボックスを選択します。添付ファイルに対する残りのオプションは任意指定であり、サービス・エンジンでこれらの情報が必要な場合に役立ちます。

アダプタ構成ウィザードのページの多くは、「ファイル名」ページを除いて、ファイル読取り操作の場合と同様です。図4-39 に示すように、「ファイル名」フィールドでは読み取るファイルの名前を指定できます。

図4-39 「ファイル・ディレクトリ」ページ

4.3.4 ファイル・リスティングの説明

この機能では、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.3.4.1 リスト表示操作

ファイルのリストを表示するには、図4-40 に示すように「List Files」操作を選択する必要があります。

図4-40 List Files操作のページ

4.3.4.2 ファイル・ディレクトリの指定

図4-41 に示すアダプタ構成ウィザードの「ファイル・ディレクトリ」ページでは、リスト表示操作のファイル名の読取りに使用するディレクトリの情報を指定できます。ディレクトリ内のファイルを再帰的にリスト表示することもできます。

図4-41 アダプタ構成ウィザード - 着信ファイルの指定

次の項では、指定するファイル・ディレクトリ情報について説明します。

4.3.4.2.1 SOAコンポジットでのインバウンドの物理または論理ディレクトリ・パスの指定

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.3.4.3 ファイルの検索

図4-42 に示すアダプタ構成ウィザードの「ファイルのフィルタ処理」ページでは、取得または無視するファイルの詳細を指定できます。

ファイル・リスナーとして機能し、ローカルまたはリモートのファイルシステムの指定されたディレクトリをポーリングして、指定されたネーミング基準に一致するファイルを検索します。

図4-42 「アダプタ構成ウィザード - ファイルのフィルタ処理」

次の項では、指定するファイル・フィルタ処理情報について説明します。

- ネーミング・パターンの指定

- 処理対象ファイルと処理対象外ファイル

4.3.4.3.1 ネーミング・パターンの指定

インバウンド・ファイルのポーリングに使用するネーミング規則を指定します。また、処理対象外にするファイルのネーミング規則も指定できます。2つのネーミング規則を選択できます。インバウンド・ディレクトリに配置されるファイルと一致します。

- ファイル・ワイルドカード(po*.txt)
poで始まり.txtで終わるすべてのファイルが取得されます。この規則はオペレーティング・システムの標準に準拠しています。

- 正規表現(po.*\.txt)
poで始まり.txtで終わるすべてのファイルが取得されます。この規則は、Java Development Kit (JDK)の正規表現(regex)構文に準拠しています。

注意:

- 後から別のネーミング・パターンを選択する場合は、「インクルード・ファイルの名前パターン」および「処理対象外ファイルの名前パターン」フィールドで指定するネーミング規則も変更してください。アダプタ構成ウィザードにより自動的に変更されることはありません。

- ファイルを取得する際、検索対象として*.*を指定しないでください。

- オペレーティング・システムにより設定されているファイルの長さの制限に注意してください。たとえば、Windowsオペレーティング・システムでは、ファイル名(ファイル名と完全なディレクトリ・パスを合せた長さ)を256文字より長くできません。制限によりファイル名に特定の文字を使用できないオペレーティング・システムもあります。たとえば、Windowsオペレーティング・システムでは、バックスラッシュ(\)、スラッシュ(/)、コロン(:)、アスタリスク(*)、左角カッコ(<)、右角カッコ(>)または縦線(|)などの文字は許可されていません。

4.3.4.3.2 処理対象ファイルと処理対象外ファイル

正規表現を使用する場合、「インクルード・ファイルの名前パターン」および「処理対象外ファイルの名前パターン」フィールドで指定する値は、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

注意:

ファイルは読み取られないため、ネイティブ・データ変換は行われません。

4.3.5 Oracle FTPアダプタのGet Fileの説明

インバウンド方向では、Oracle FTPアダプタはOracleファイル・アダプタのRead File操作と同様に機能し、処理のためにファイルシステムのファイルをポーリングして取得します。主な違いは、Oracle FTPアダプタがリモートでのファイル交換に使用されることです。FTPアダプタをリモートでのファイル交換用に構成するために、図4-43 に示すように、アダプタ構成ウィザードでは後で使用するFTPサーバーへの接続情報が求められます。

図4-43 FTPサーバーの接続情報の指定

デフォルトのアダプタ・インスタンスのJNDI名はeis/Ftp/FtpAdapterです。または、カスタム名を使用します。この名前で、実行時にFTPサーバーに接続します。

注意:

Oracle FTPアダプタでは、大きなファイルの転送時にFTPコマンドのRESTARTとRECOVERYを使用できません。

ログイン後、Get File(読取り)操作と配信するファイル・タイプを選択します。図4-44 にこの選択内容を示します。

図4-44 「Get File」操作の選択

デプロイメント・ディスクリプタの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より大きな値に設定

図4-45 ファイル変更時間

このページでは、リモート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アダプタのディレクトリ内のファイルの再帰的処理」を参照してください。

4.3.6 Put Fileの説明

アウトバウンド方向では、Write File操作と同じ機能を果します。BPELプロセスまたはサービスからメッセージを受信し、ファイル内のメッセージをファイルシステム(この場合はリモート)に書き込みます。メッセージをリモート・システムに書き込む必要があるため、図4-43 に示すように、アダプタ構成ウィザードではアダプタ・インスタンスのJNDI名でFTPサーバーに接続するように求められます。

ログイン後、Put File(書込み)操作と配信するファイル・タイプを選択します。図4-46 にこの選択内容を示します。

図4-46 「Put File」操作の選択

これ以降のPut File操作のアダプタ構成ウィザードのページは、Write File操作のページと同じです。表4-10 に、表示されるページとその機能の説明が記載されている項を示します。

表4-10 Put File操作のアダプタ構成ウィザードのページ

ページ

参照先

ファイル構成(図4-32 )

アウトバウンド・ファイル・ディレクトリの作成

メッセージ(図4-37)

ネイティブ・データ変換

「アダプタ構成ウィザード」を完了すると、JDeveloperの「アプリケーション」セクションに構成ファイルが作成されます。

4.3.7 同期Get Fileの説明

アウトバウンド方向では、同期Read File操作と同様に機能し、ファイルシステムのファイルをポーリングして取得し、ファイルの現在のコンテンツを読み取ります。主な違いは、リモートでのファイル交換に使用されることです。このポーリングのため、アダプタ構成ウィザードでは後で使用するFTPサーバーへの接続情報が求められます。ファイルを同期的に読み取るには、図4-47 に示すように「同期Get File」操作を選択します。

図4-47 「同期Get File」操作の選択

4.3.8 ファイル・リスティングの説明

ファイル・リスティングの概要は、「ファイル・リスティングの説明」に記載されているファイル・リスティングの概要と似ています。ターゲット・ディレクトリのファイルをポーリングし、ファイルのリストを指定されたFTPの場所に表示します。ファイルのコンテンツは読み取られませんこの機能では、invokeアクティビティを使用してターゲット・ディレクトリからファイルのリストを取得します。このファイルのリストはXML文書として返され、ファイル名、ディレクトリ名、ファイル・サイズ、最終変更時間などの情報が記載されています。

注意:

標準Java APIには作成時間を取得するためのメカニズムがないため、FTPの場合、ファイル作成時間プロパティcreationTimeはサポートされていません。creationTimeプロパティの値は常に0として表示されます。

creationTimeプロパティは、SFTPの場合にのみサポートされています。

BPELプロセスまたはサービスで使用するように構成するには、アダプタ構成ウィザードを使用します。これにより、アウトバウンドのWSDLとJCAのファイルのペアが作成されます。

ファイルのリストを表示するには、アダプタ構成ウィザードの「操作タイプ」ページで「List Files」操作を選択します。アダプタ構成ウィザードの「ファイル・ディレクトリ」ページでは、リスト表示操作のファイル名の読取りに使用するディレクトリの情報を指定する必要があります。ディレクトリ内のファイルを再帰的にリスト表示することもできます。アダプタ構成ウィザードの「ファイルのフィルタ処理」ページでは、取得または無視するファイルの詳細を指定できます。

リスナーとして機能し、ローカルまたはリモートのファイルシステムの指定されたディレクトリをポーリングして、指定されたネーミング基準に一致するファイルを検索します。

4.3.9 ファイル/FTPアダプタの拡張

ファイル/FTPアダプタの拡張は4つあります。

- デフォルトのFTPClient実装のlogin()操作に対するFTPアダプタ拡張
MLSDコマンドをサポートするためのFTPアダプタ拡張

- LISTコマンドではなくMLSDコマンドを送信するためのリスティング操作を拡張するFTPアダプタ拡張

- MVSプラットフォームで実行されているFTPサーバーに追加の固有FTPコマンドを送信するためのFTP格納操作に対するFTPアダプタ拡張

これらの各拡張については、ファイル/FTPアダプタの使用例で詳しく説明します。

4.4 Oracleファイル/FTPアダプタの構成

次の各項では、Oracleファイル/FTPアダプタの各種構成タスクについて説明します。

- リモートFTPサーバーにアクセスするための資格証明の構成

- 高可用性のための構成

- セキュアFTPの使用

- SFTPの使用

- OracleファイルとFTPアダプタのFIPS準拠の有効化

- HTTPプロキシのための構成

- 高可用性のためのOracleファイル/FTPアダプタの構成

注意:

ftpAbsolutePathBeginパラメータを使用して、FTPアダプタが発行したFTPコマンドで使用されたディレクトリ名が、絶対ディレクトリか相対ディレクトリかをアダプタに示すことができます。ディレクトリ名がftpAbsolutePathBeginで始まっている場合は絶対ディレクトリで、それ以外の場合は相対ディレクトリとして扱われます。

4.4.1 リモートFTPサーバーにアクセスするための資格証明の構成

リモートFTPサーバーにアクセスするには、次の資格証明を構成する必要があります。

- ユーザー名: リモートFTPサーバーで使用するユーザー名

- パスワード: リモートFTPサーバーで使用するパスワード

- ポート: 21

- ホスト: リモートFTPサーバーのIPアドレス

これらの資格証明を構成するには、Oracle WebLogic Serverコンソールを使用してweblogic-ra.xmlファイルを変更する必要があります。

これを行うには、Oracle WebLogic Server管理コンソールで次の手順を実行します。

1. 左側のナビゲーション・ペインから、「デプロイメント」を選択します。

2. 右側に表示されるデプロイメントの表から、「FtpAdapter」を選択します。

3. FtpAdapterの「構成」サブタブを選択し、「アウトバウンド接続プール」を選択します。

4. javax.resource.cci.ConnectionFactoryを展開し、変更するインスタンスを選択します。(たとえば、非高可用性の使用例では、eis/Ftp/FtpAdapterインスタンスを選択します。)

4.4.2 高可用性のための構成

次の各項では、アクティブ/アクティブ・トポロジに対する高可用性のために構成する際の要件と手順について説明します。

- 可用性を高めるための前提条件

- インバウンド操作の高可用性

- アウトバウンド操作の高可用性

4.4.2.1 高可用性の前提条件

高可用性を実現するように構成するには、次の前提条件が満たされていることを確認する必要があります。

- クラスタリングされた複数のプロセスで、同じ物理ディレクトリが使用されている必要があります。

- 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は有効です。

4.4.2.2 インバウンド操作の高可用性

1つのノードのみが分散トポロジで特定のファイルを処理する必要があります。データベース表をコーディネータとして使用すると、インバウンド操作での可用性が向上します。

4.4.2.2.1 コーディネータとしてのデータベース表の使用

データベース表をコーディネータとして使用して、インバウンドのサービスの可用性を高めるには、次の手順を使用します。

注意:

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトの値を大きくする必要があります。

1. データベース表の作成
データベース・スキーマはsoainfraの一部として事前作成されているため、この手順を実行する必要はありません。

2. デプロイメント・ディスクリプタの変更
Oracle WebLogic Server管理コンソールで、eis/HAFileAdapterに対応するconnection-instanceのデプロイメント・ディスクリプタを変更します。

a. Oracle WebLogic Server管理コンソールにログインします。コンソールにアクセスするには、http://servername:portnumber/consoleにナビゲートします。

b. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

c. 右ペインの「デプロイメントのサマリー」の下にある「FileAdapter」をクリックします。

d. 「構成」タブをクリックします。

e. 「アウトバウンド接続プール」タブをクリックし、javax.resource.cci.ConnectionFactoryを開いて図4-48 に示すように構成済のコネクション・ファクトリを表示します。

図4-48 Oracle WebLogic Server管理コンソール - 「FileAdapterの設定」ページ

f. 「eis/HAFileAdapter」をクリックします。高可用性に対応する接続ファクトリの「アウトバウンド接続のプロパティ」が表示されます。

g. 図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プロパティを設定する必要があります。

h. 次の例に示すように、コネクション・ファクトリを使用するために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に設定されています。

4.4.2.3 アウトバウンド操作の高可用性

複数の参照が同じディレクトリに書き込まれた場合に相互にオーバーライドされないようにする必要があります。次のロック機能を使用すると、アウトバウンド操作での可用性が向上します。

- データベースmutex

- ユーザー定義mutex

4.4.2.3.1 データベースMutexの使用

データベース表をコーディネータとして使用して、アウトバウンドのOracleファイル/FTPアダプタ・サービスの可用性を高めるには、次の手順を使用します。

注意:

データベースをコーディネータとして使用する場合は、グローバル・トランザクション・タイムアウトを増やす必要があります。

1. データベース表の作成
データベース・スキーマはsoainfraの一部として事前作成されているため、この手順を実行する必要はありません。

2. Oracleファイル・アダプタのデプロイメント・ディスクリプタの変更
Oracle WebLogic Server管理コンソールで、eis/HAFileAdapterに対応するconnection-instanceのOracleファイル・アダプタのデプロイメント・ディスクリプタを変更します。

a. Oracle WebLogic Server管理コンソールにログインします。コンソールにアクセスするには、http://servername:portnumber/consoleにナビゲートします。

b. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。

c. 右ペインの「デプロイメントのサマリー」で「FileAdapter」をクリックします。

d. 「構成」タブをクリックします。

e. 「アウトバウンド接続プール」タブをクリックし、javax.resource.cci.ConnectionFactoryを開いて図4-48 に示すように構成済のコネクション・ファクトリを表示します。

f. 「eis/HAFileAdapter」をクリックします。高可用性に対応するコネクション・ファクトリの「アウトバウンド接続のプロパティ」ページが表示されます。

g. 図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の完全修飾クラス名の値を指定した新規バインディング・プロパティを構成する必要があります。

h. 次の例に示すように、コネクション・ファクトリを使用するために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に指定された値は無効になります。

4.4.3 セキュアFTPの使用

Windows、SolarisおよびLinuxでセキュアFTP機能を使用できます。Windowsの場合、この機能はOpenSSLを使用したFileZilla FTPサーバーで動作確認されています。この項では、セキュアFTP機能の概要と、この機能のインストールおよび構成方法を説明します。

この項には次のトピックが含まれます:

- セキュアFTPの概要

- SolarisおよびLinuxでのFTP Over SSLのインストールおよび構成

- WindowsでのFTP Over SSLのインストールおよび構成

4.4.3.1 セキュア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 に示す設定では、サーバーの証明書は信頼できる証明書として、直接クライアントの証明書ストアにインポートされます。

図4-51 信頼の確立

送信前に暗号化し、受信後に復号することで、転送するデータは盗用されなくなります。データが大量な場合、(データの暗号化と復号に同じ鍵を使用する)対称型暗号化は公開鍵と秘密鍵を使用する方法よりもはるかに高速です。対称型暗号化はFTPSで使用される方法です。ただし、クライアントとサーバーがデータの暗号化や復号に同じ鍵を使用するには、共通の鍵について合意する必要があります。通常、クライアントが次のタスクを実行することで合意が成立します。

- セッション鍵の生成(データの暗号化と復号に使用)

- サーバーの証明書の一部であるサーバーの公開鍵を使用したセッション鍵の暗号化

- サーバーへの鍵の送信

サーバーは秘密鍵を使用してこのセッション鍵を復号化し、クライアントに送信する前にそのセッション鍵を使用してファイル・データを暗号化します。

4.4.3.2 SolarisおよびLinuxでのFTP Over SSLのインストールおよび構成

次の各項では、SolarisおよびLinux用のセキュアFTPのインストールおよび構成方法について説明します。

- OpenSSLのインストールおよび構成

- vsftpdのインストールおよび構成

- Oracleファイル/FTPアダプタの設定

4.4.3.2.1 OpenSSLのインストールおよび構成

OpenSSLは、SSLプロトコルのオープン・ソースの実装です。OpenSSLは基本的な暗号機能を実装し、ユーティリティ関数を提供します。FTPサーバーとして使用するSolarisまたはLinuxのホストにOpenSSLをインストールして構成します。

1. 次のURLへ移動します。

http://www.openssl.org/source

2. 使用可能なファイルのリストでopenssl-0.9.7g.tar.gzを検索します。次に例を示します。

3132217 Apr 11 17:21:51 2005
openssl-0.9.7g.tar.gz (MD5) (PGP sign)

3. 次のファイルをダウンロードします。

- openssl-0.9.7g.tar.gz

- openssl-0.9.7g.tar.gz.md5 (MD5リンクの先)

- openssl-0.9.7g.tar.gz.asc (PGP signリンクの先)

4. gunzipを使用して次のファイルを解凍します。

gunzip openssl-0.9.7g.tar.gz

5. 次のtarファイルを解凍します。

tar xvf openssl-0.9.7g.tar

6. 次の場所にディレクトリを変更します。

cd openssl-0.9.7g

7. 次のコマンドを実行します。

./config --prefix=/usr --openssldir=/usr/local/openssl

8. Bourneシェルに変更します(使用していない場合)。

sh

9. PATH変数を構成およびエクスポートします。

PATH=${PATH}:/usr/ccs/bin; export PATH

10. 次のコマンドを実行します。

make

11. Bourneシェルを終了します。

exit

12. 次のコマンドを実行します。

make test

13. スーパーユーザーとしてログインします。

msu

14. 必要な場合にはパスワードを入力します。

15. 次のコマンドを実行します。

make install

4.4.3.2.2 vsftpdのインストールおよび構成

vsftpdサーバーは、UNIXシステム用のセキュアで高速なFTPサーバーです。FTPサーバーとして使用するSolarisまたはLinuxのホストにvsftpdをインストールして構成します。

1. 次の場所に移動します。

ftp://vsftpd.beasts.org/users/cevans/

2. vsftpd-2.0.5をダウンロードします(tarファイルおよび署名ファイル(.ascファイル)が必要です)。次に例を示します。

[BINARY]     vsftpd-2.0.5.tar.gz. . . . . . . . . . .    [Mar 19 21:26]    149K
[FILE]       vsftpd-2.0.5.tar.gz.asc. . . . . . . . .    [Mar 19 21:26]    189B

3. gunzipを使用して次のファイルを解凍します。

gunzip vsftpd-2.0.5.tar.gz

4. tarファイルを解凍します。

tar xvf vsftpd-2.0.5.tar

5. 次の場所にディレクトリを変更します。

cd vsftpd-2.0.5

6. builddefs.hファイルを次のように変更します。

#undef VSF_BUILD_SSL

変更後

#define VSF_BUILD_SSL

7. スーパーユーザーとしてログインします。

msu

8. 必要な場合にはパスワードを入力します。

9. /etcディレクトリに、vsftpd.confという名前のファイルを次の設定で作成します。

# Standalone mode
listen=YES
max_clients=200
max_per_ip=4
# Access rights
anonymous_enable=YES
#chroot_local_user=YES
#userlist_enable=YES
ftp_username=ftp
local_enable=YES
write_enable=YES
anon_upload_enable=YES
anon_mkdir_write_enable=YES
anon_other_write_enable=YES
chown_uploads=YES
chown_username=ftp
# Security
anon_world_readable_only=NO
allow_anon_ssl=YES
ssl_enable=YES
connect_from_port_20=YES
hide_ids=YES
pasv_min_port=50000
pasv_max_port=60000
# Features
ftpd_banner="Welcome to the FTP Service"
xferlog_enable=YES
ls_recurse_enable=NO
ascii_download_enable=NO
async_abor_enable=YES
# Performance
one_process_model=NO
idle_session_timeout=120
data_connection_timeout=300
accept_timeout=60
connect_timeout=60
anon_max_rate=50000

注意:

vsftpd.confファイルのコピーが、vsftpd-2.0.5ディレクトリ構造のいくつかの場所に表示されます。それらのファイルの1つを使用して/etcディレクトリにvsftpd.confファイルを作成する場合は、ステップ9で説明されているパラメータと設定のみが含まれていることを確認してください。

10. 次のコマンドを実行します。

mkdir /var/ftp
useradd -d /var/ftp ftp
chown root /var/ftp
chmod og-w /var/ftp
mkdir /usr/share/empty
mkdir /usr/share/ssl
mkdir /usr/share/ssl/certs

11. 次のコマンドを実行します。

openssl req -x509 -nodes -newkey rsa:1024 -keyout /usr/share/ssl/certs/vsftpd.pem -out /usr/share/ssl/certs/vsftpd.pem

12. vsftpd-2.0.5ディレクトリからvsftpdデーモンを実行します。

./vsftpd

4.4.3.2.3 設定

次のタスクを実行して設定します。

1. SolarisまたはLinuxのホストで次のコマンドを実行します。

mkdir /var/ftp/inDir
mkdir /var/ftp/outDir
chmod 777 /var/ftp/inDir /var/ftp/outDir

2. Oracle WebLogic Server管理コンソールを使用して、デプロイメント・ディスクリプタでFTP接続パラメータを指定します。

パラメータ

説明

useFtps

Trueに設定します。この設定は、FTP over SSLを使用する場合に必要です。デフォルト値はFalseです。

channelMask

チャネルのタイプ。制御チャネルまたはデータ・チャネル。可能な値はboth、control、dataまたはnoneです。デフォルトはbothです。

securePort

FTP over SSLのポート。デフォルトは990です。

keyStoreProviderName

キーストア・プロバイダのクラス。デフォルトはoracle.security.pki.OraclePKIProviderです。

keystoreType

キーストア・タイプ。デフォルトはPKCS12です。

keystoreAlgorithm

キーストア・アルゴリズム。デフォルトはOracleX509です。

enableCipherSuits

カンマ区切りの暗号スイートのリスト。デフォルトは空白で、暗号スイートのデフォルト・リストが使用されます。ほとんどの場合、デフォルトを変更する必要はありません。

pkiProvider

PKIプロバイダの名前。デフォルトはOraclePKIです。

jsseProvider

JSSEプロバイダの名前。デフォルトはOracleJSSEです。

これでセキュアFTPのインストールおよび構成が完了し、この機能を使用する準備ができました。

4.4.3.3 WindowsでのFTP Over SSLのインストールおよび構成

FTPS機能はOpenSSLを使用したFileZilla FTPサーバーで動作確認されています。WindowsでFileZillaを使用する場合にOpenSSLをインストールおよび構成するには、次の各項の手順に従う必要があります。

- OpenSSLのインストール

- OpenSSLのサーバー鍵およびサーバー証明書の生成

- サーバー鍵およびサーバー証明書のFileZillaサーバーへのインポート

- サーバー鍵のPEMからPKCS12フォーマットへの変換

- 新しい鍵を使用するためのOracle FTPアダプタのデプロイメント・ディスクリプタの構成

4.4.3.3.1 OpenSSLのインストール

OpenSSLは、SSLプロトコルのオープン・ソースの実装です。OpenSSLは基本的な暗号機能を実装し、ユーティリティ関数を提供します。FTPサーバーとして使用するWindowsのホストにOpenSSLをインストールして構成するには、次の手順を実行します。

1. 次のURLへ移動します。

http://www.slproweb.com/products/Win32OpenSSL.html

2. Visual C++ 2008 Redistributablesをダウンロードしてインストールします。

3. Win32 OpenSSL v0.9.8k Lightをダウンロードしてインストールします。

4.4.3.3.2 OpenSSLのサーバー鍵およびサーバー証明書の生成

(FileZillaの「新規証明書の生成」ボタンをクリックすることで、FileZillaユーティリティを使用して秘密鍵および証明書を生成し、この項の手順をスキップできます。入力する「共通名」が、FileZilla FTPサーバーが実行中のマシンの完全修飾ホスト名またはIPであることを確認します。その場合でも、「サーバー鍵のPEMからPKCS12フォーマットへの変換」の手順は実行する必要がありますが、FileZillaによって生成された秘密鍵および証明書ファイルを使用します。)

サーバー鍵ファイルおよび証明書ファイルを作成するには、次の手順を実行します。

1. コマンド・プロンプトを開いてOpenSSL\binディレクトリを参照します。

2. 次のコマンドを実行します。

openssl req -new -x509 -keyout mykey.pem -out mycert.pem -days 365

サンプルのコマンド出力は次のとおりです。

C:\OpenSSL\bin>openssl req -new -x509 -keyout mykey.pem       -out mycert.pem -days 365
Loading 'screen' into random state - done
Generating a 1024 bit RSA private key
..........++++++
.......++++++
writing new private key to 'mykey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that
will be incorporated into your certificate request.
What you are about to enter is what is called a
Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:CA
Locality Name (eg, city) []:Belmont
Organization Name (eg, company)
[Internet Widgits Pty Ltd]:Test
Organizational Unit Name (eg, section) []:Test
Common Name (eg, YOUR name) []:Test test
Email Address []:test@test.com

3. 必要な場合にはPEMパスフレーズを入力します。

4. 検証のためにステップ3で入力したPEMパスフレーズを再入力します

5. 要求された詳細を入力します。

サーバー鍵(mykey.pem)およびサーバー証明書(mycert.pem)がOpenSSL\binディレクトリに生成されます。

4.4.3.3.3 サーバー鍵およびサーバー証明書のFileZillaサーバーへのインポート

サーバー鍵およびサーバー証明書をFileZillaにインポートするには、次の手順を実行します。

1. Windowsの「スタート」メニューから、FileZillaサーバーを開きます。

2. 「Edit」を選択して「Settings」をクリックします。

「FileZilla Server Options」ダイアログが表示されます。

3. 「SSL/TLS settings」をクリックします。

4. 図4-52 に示すように、サーバー鍵およびサーバー証明書の詳細を入力します。

図4-52 「FileZilla Server Options」ダイアログ

注意:

「Key password」フィールドでは、「OpenSSLのサーバー鍵およびサーバー証明書の作成」の手順3で生成したPEMパスフレーズを使用する必要があります。

4.4.3.3.4 サーバー鍵のPEMからPKCS12フォーマットへの変換

Oracle FTPアダプタではPEMフォーマットが認識されないため、サーバー鍵およびサーバー証明書をPEMフォーマットからPKCS#12フォーマットへ変換する必要があります。サーバー鍵およびサーバー証明書をPKCS#12フォーマットに変換するには、次の手順を実行します。

1. コマンド・プロンプトを開いてOpenSSL\binディレクトリを参照します。

2. 次のコマンドを実行します。

openssl pkcs12 -export -out mykeyz.p12               -in mycert.pem  -inkey mykey.pem

コマンド出力は次のとおりです。

C:\OpenSSL\bin>openssl pkcs12            -export -out mykeyz.p12 -in mycert.pem  -inkey mykey.pem
Loading 'screen' into random state - done
Enter pass phrase for mykey.pem:
Enter Export Password:
Verifying - Enter Export Password:

3. 必要な場合にはPEMパスフレーズを入力します。このパスフレーズは、「OpenSSLのサーバー鍵およびサーバー証明書の生成」でOpenSSLのサーバー鍵およびサーバー証明書を生成中に作成したパスフレーズです。

4. PKCS#12ファイルに対するエクスポート・パスワードを入力します。

5. 検証のためにエクスポート・パスワードを再入力します。

6. 要求された詳細を入力します。

mykeyz.p12ファイルがOpenSSL\binディレクトリに生成されます。

7. mykeyz.p12ファイルをOracle FTPアダプタを実行中の管理対象のOracle WebLogic Serverインスタンスにコピーします。

例:

/scratch/$user/private/mykeyz.p12

4.4.3.3.5 新しい鍵を使用するためのOracle FTPアダプタのデプロイメント・ディスクリプタの構成

Oracle FTPアダプタのデプロイメント・ディスクリプタを構成するには、次の手順を実行します。

1. http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

3. 「ドメイン構造」ペインで「デプロイメント」を選択します。

Oracle WebLogic Server管理コンソールの「デプロイメントのサマリー」ページが表示されます。

4. FtpAdapterをクリックします。

Oracle WebLogic Server管理コンソールの「FtpAdapterの設定」ページが表示されます。

5. 「構成」タブをクリックし、「アウトバウンド接続プール」タブをクリックします。

「アウトバウンド接続プールの構成表」が表示されます。

6. 構成するFTPアダプタ・インスタンスのJNDI名を選択します。例: "eis/Ftp/FtpAdapter"。

7. 表4-11 に示すデプロイメント・ディスクリプタを構成します。

表4-11 JCAプロパティ

プロパティ名

プロパティ値

useFtps

この値にはtrueを設定します。

walletLocation

管理対象のOracle WebLogic Server ServerインスタンスのPKCS#12ファイルの場所(/scratch/$user/private/mykeyz.p12)を設定します。

walletPassword

この値には、「サーバー鍵のPEMからPKCS12フォーマットへの変換」のステップ4で生成したエクスポート・パスワードを設定します。

keyStoreProviderName

この値には、sun.security.provider.Sunを設定します。

keystoreType

この値には、PKCS12を設定します。

keystoreAlgorithm

この値には、SunX509を設定します。

pkiProvider

空白のままにしておく必要があります。

jsseProvider

空白のままにしておく必要があります。

4.4.4 SFTPの使用

SSHファイル転送プロトコル(SFTP)は、ネットワークを介したセキュアなファイル転送を可能にするネットワーク・プロトコルです。WindowsおよびLinuxでのSFTP機能の使用をサポートします。この項では、SFTP機能の概要と、この機能のインストールおよび構成方法を説明します。

この項では、次のタスクを取り上げます。

- SFTPの概要

- OpenSSH for Windowsのインストールと構成

- SFTP用の設定

4.4.4.1 SFTPの概要

FTPは、クライアントが基礎となるSSHトランスポートを介してファイルを安全に転送できるようにするネットワーク・プロトコルです。SFTPはFTP over SSHともファイル転送プロトコル(FTP)とも異なります。図4-53 に、SSHクライアントとSSHサーバーの間の通信プロセスを示します。SFTPはWindowsとLinuxでサポートされています。

図4-53 SFTP通信

SFTPの機能は、次のとおりです。

- 暗号化

- 認証

- 整合性

- データ圧縮

4.4.4.1.1 暗号化

SSHプロトコルでは、暗号化に公開鍵暗号を使用します。ここでは、データがどのように暗号化されるかについて説明します。

1. SSHサブシステムにより、Data Encryption Standard (DES)やBlowfishなどの対称鍵暗号を使用してセッション鍵が生成されます。現在、SSHプロトコルではDiffie-Hellman鍵交換アルゴリズムを使用してセッションの対称鍵が導出されています。

2. セッション鍵を使用してデータが暗号化されます。

3. 受信者の公開鍵を使用してセッション鍵が暗号化されます。受信者は秘密鍵を持っているため、Rivest-Shamir-Adleman (RSA)やDigital Signature Algorithm (DSA)など、必要なPKIアルゴリズムを使用してメッセージを復号化できます。

4.4.4.1.2 認証

本来、SSHプロトコルでは、パスワードまたはセッション鍵をネットワークでの転送時に暗号化することでパスワード認証をサポートしています。また、SSHプロトコルでは「既知のホスト」というメカニズムを使用して、IPスプーフィングなどの脅威を防止します。クライアントとサーバーの両方でこのメカニズムが使用されている場合、あらゆる種類の通信を行う前に相互にアイデンティティを証明する必要があります。

4.4.4.1.3 整合性

SSHプロトコルは、Message Digest Algorithm 5 (MD5)やSecure Hash Algorithm (SHA-1)など、広範囲に信頼されているバルク・ハッシュ・アルゴリズムを使用することで、挿入攻撃を防止します。「暗号化」で説明したアルゴリズムを使用してデータ整合性チェックサムを実装することで、送信中のデータが故意に改ざんされるのを防止できます。

4.4.4.1.4 データ圧縮

SSHプロトコルは、オープン・ソースのプラットフォーム間データ圧縮アルゴリズムであるzlibをサポートしています。SSHでは、ネットワーク帯域幅を低減するためにzlibを使用して通信中のデータが圧縮されます。

4.4.4.2 OpenSSH for Windowsのインストールと構成

OpenSSH for Windowsは、WindowsでのSSHプロトコルの無償実装です。Windows XPでOpenSSHをインストールおよび構成するには、次の手順を実行します。

1. Administrator権限を持つユーザーとしてログインします。

2. 次のサイトからsetup.exeをダウンロードします。

http://www.cygwin.com

3. setup.exeを実行します。「Cygwin Net Release Setup」ウィンドウが表示されます。

4. 「Next」をクリックします。「Choose Installation type」ウィンドウが表示されます。

5. ダウンロード・ソースとして「Install from Internet」を選択し、「Next」をクリックします。「Choose Installation Directory」ウィンドウが表示されます。

6. 「root directory」はC:\cygwinのままにしておきます。「Install For」および「Default Text File Type」フィールドも、デフォルト・オプションのままにしておきます。

7. 「Next」をクリックします。「Select Local Package Directory」ウィンドウが表示されます。

8. 「Browse」をクリックし、ローカル・パッケージ・ディレクトリとして「C:\cygwin」を選択します。

9. 「Next」をクリックします。「Select Connection Type」ウィンドウが表示されます。

10. インターネット接続の設定を選択して「Next」をクリックします。「Choose Download Site(s)」ウィンドウが表示されます。

11. 「Available Download Sites」リストからサイトを選択し、「Next」をクリックします。「Select Packages」ウィンドウが表示されます。

12. 「View」をクリックして、インストール可能な全パッケージのリストを表示します。

13. デフォルト値でない場合は「openssh」を選択します。

14. opensshの「Binaries」ボックスを選択します。

15. 「Next」をクリックしてインストールを開始します。

16. Windows XPデスクトップで、「マイ コンピュータ」を右クリックして「プロパティ」を選択します。

17. 「詳細設定」タブをクリックし、「環境変数」をクリックします。

18. 「新規」をクリックし、「変数名」フィールドにCYGWIN、「変数値」フィールドにntsecと入力します。

19. システム・パスにC:\cygwin\binを追加します。

20. 「cygwin」ウィンドウを開きます。

21. ssh-host-configと入力します。

22. 次のプロンプトが表示されます。

a. Shall privilege separation be used? (yes/no)
yesと入力します。

b. Shall this script create a local user 'sshd' on this machine?
yesと入力します。

c. Do you want to install sshd as service?
(Say "no" if it's already installed as service)(yes/no)

yesと入力します。

d. 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と入力します。

23. net start sshdと入力してsshdサービスを開始します。

24. 「cygwin」ウィンドウで次のコマンドを実行して、Windowsのローカル・ユーザー・アカウントをcygwinにレプリケートします。

mkpasswd --local > /etc/passwd
mkgroup --local > /etc/group

25. 設定をテストするために、「cygwin」ウィンドウにssh localhostと入力します。

4.4.4.3 SFTP用の設定

SFTP機能を使用するには、デプロイメント・ディスクリプタを変更する必要があります。

表4-12 に、デプロイメント・ディスクリプタで値を指定する必要があるプロパティを示します。これらのプロパティの値は、認証のタイプとOpenSSHの場所に応じて異なります。

表4-12 SFTPのプロパティ

プロパティ

説明

useSftp

trueを指定します。

必須: はい

デフォルト値: false

authenticationType

パスワードベース認証の場合はPASSWORD、公開鍵認証の場合はPUBLICKEYを指定します。

パスワードベース認証の場合は、weblogic-ra.xmlファイルに指定されているユーザー名とパスワードが使用されます。weblogic-ra.xmlファイルに指定されているのと同じ名前とパスワードを持つWindowsユーザーが存在することを確認してください。また、ユーザーには管理権限が必要です。

公開鍵認証の場合は、privateKeyFileパラメータを秘密鍵ファイルの場所に設定する必要があります。

必須: はい

preferredKey ExchangeAlgorithm

diffie-hellman-group1-sha1またはdiffie-hellman-group-exchange-sha1を指定します。

これはオプション・パラメータであり、ユーザーはメッセージ暗号化に使用するセッション鍵を交換する際にデフォルトの鍵交換プロトコルを選択できます。

必須: いいえ

デフォルト値: diffie-hellman-group1-sha1

preferred CompressionAlgorithm

noneまたはzlibを指定します。

このパラメータにより、通信中のデータを圧縮するかどうかを選択できます。

必須: いいえ

preferred DataIntegrityAlgorithm

hmac-md5またはhmac-sha1を指定します。

このパラメータにより、データ整合性チェックに使用するバルク・ハッシュ・アルゴリズムを選択できます。

必須: いいえ

デフォルト値: hmac-md5

preferredPKIAlgorithm

ssh-rsaまたはssh-dsaを指定します。

このパラメータにより、通信に使用する非対称型暗号を構成できます。

必須: いいえ

デフォルト値: ssh-rsa

privateKeyFile

秘密鍵ファイルへのパスを指定します。authenticationTypeパラメータをPUBLICKEYに設定した場合は、このパラメータが必須です。

必須: いいえ

preferredCipherSuite

次のリストから暗号を1つ指定します。

- twofish192-cbc

- cast128-cbc

- twofish256-cbc

- aes128-cbc

- twofish128-cbc

- 3des-cbc

- blowfish-cbc

- aes256-cbc

- aes192-cbc

必須: いいえ

デフォルト値: blowfish-cbc

transportProvider

socketまたはHTTPを指定します。

SSHサーバーがファイアウォールの内側にある場合はsocketを指定します。SSHサーバーがファイアウォールの外側にある場合、またはサーバーがHTTPサーバーを介して公開される場合は、HTTPを指定します。

HTTPを選択した場合は、次のパラメータの値を指定する必要があります。

- proxyHost

- proxyPort

- proxyUser

- proxyPassword

- useProxy

必須: はい

4.4.4.3.1 パスワードによる認証の構成

パスワード認証を使用するように設定するには、表4-12に示したプロパティの値をデプロイメント・ディスクリプタで指定する必要があります。authenticationTypeプロパティがpasswordに設定されていることを確認してください。

表4-13 のプロパティと値を指定します。

表4-13 サンプルのSFTPのプロパティとその値

プロパティ

値

useSftp

true

authenticationType

PASSWORD

preferredKey ExchangeAlgorithm

diffie-hellman-group1-sha1

preferred CompressionAlgorithm

none

preferred DataIntegrityAlgorithm

hmac-md5

preferredPKIAlgorithm

ssh-rsa

privateKeyFile

-

preferredCipherSuite

blowfish-cbc

transportProvider

socket

4.4.4.3.2 公開鍵認証の構成

公開鍵認証の場合は、最初にOpenSSHを構成してから設定する必要があります。

設定は、OpenSSHがファイアウォールの内側で実行されるかどうかに応じて異なります。

OpenSSHがファイアウォールの内側で実行される場合は、次の項を参照してください。

- 公開鍵認証を使用するためのOpenSSHの構成

- OpenSSHがファイアウォールの内側で実行されている場合の公開鍵認証用の構成

OpenSSHがファイアウォールの外側で実行される場合は、次の項を参照してください。

- 公開鍵認証を使用するためのOpenSSHの構成

- OpenSSHがファイアウォールの外側で実行されている場合の公開鍵認証用の構成

4.4.4.3.3 公開鍵認証を使用するためのOpenSSHの構成

次の手順を実行します。

1. C:\cygwin\etcディレクトリに移動します。必要な場合は、公開鍵認証を強制するようにsshd_configファイルを構成します。詳細は、opensshのヘルプまたはマニュアルを参照してください。

2. C:\cygwin\binディレクトリに移動します。

3. 次のコマンドを実行して鍵のペアを生成します。

ssh-keygen -t rsa

4. 鍵の保存先ファイルを求めるプロンプトに対して/etc/id_rsaと入力します。

5. パスフレーズを入力します。

6. パスフレーズを再入力します。

7. /etcディレクトリに移動し、公開鍵ファイル(id_rsa.pub)と秘密鍵ファイル(id_rsa)の両方が生成されたことを確認します。

8. 次のコマンドを実行して公開鍵ファイルのコピーを作成します。

cp id_rsa.pub authorized_keys

9. 秘密鍵ファイルのコピーを安全な場所(C:\my-secured-folder\など)に作成します。構成では、この秘密鍵ファイルが参照されます。

10. 次のコマンドを実行してOpenSSHサーバーを再起動します。

net stop sshd
net start sshd

4.4.4.3.4 OpenSSHがファイアウォールの内側で実行されている場合の公開鍵認証用の構成

公開鍵認証を使用するように設定するには、表4-12に示したパラメータの値をデプロイメント・ディスクリプタで指定する必要があります。authenticationTypeパラメータがpublickeyに、transportProviderパラメータがsocketに設定されていることを確認します。privateKeyFileパラメータには、秘密鍵ファイルの場所が含まれている必要があります。

表4-14 に、公開鍵認証プロパティとその値のサンプル・リストを示します。

表4-14 サンプルのSFTPのプロパティとその値

プロパティ

値

useSftp

true

authenticationType

publickey

preferredKey ExchangeAlgorithm

diffie-hellman-group1-sha1

preferred CompressionAlgorithm

none

preferred DataIntegrityAlgorithm

hmac-md5

preferredPKIAlgorithm

ssh-rsa

privateKeyFile

C:\my-secured-folder\id_rsa

preferredCipherSuite

blowfish-cbc

transportProvider

socket

4.4.4.3.5 OpenSSHがファイアウォールの外側で実行されている場合の公開鍵認証用の構成

OpenSSHがファイアウォールの外側で実行されている場合に、公開鍵認証用に設定するには、次の手順を実行します。

1. デプロイメント・ディスクリプタでは、表4-12に示したプロパティの値をデプロイメント・ディスクリプタで指定する必要があります。authenticationTypeプロパティがpublickeyに、transportProviderプロパティがHTTPに設定されていることを確認します。privateKeyFileプロパティでは、秘密鍵ファイルの場所が指定されています。

2. デプロイメント・ディスクリプタで、次のプロキシ関連プロパティも指定します。

- proxyHost: プロキシ・ホスト名

- proxyPort: プロキシのポート番号

- proxyUsername: プロキシのユーザー名

- proxyPassword: プロキシのパスワード

- useProxy: プロキシを使用する場合はtrue

表4-15 に、公開鍵認証プロパティおよびプロキシ・プロパティのサンプル・リストを示します。

表4-15 サンプルのSFTPのプロパティとその値

プロパティ

値

proxyHost

proxy.host.com

proxyPort

80

proxyUsername

anonymous

proxyPassword

tiger@scott.com

useProxy

true

useSftp

true

authenticationType

publickey

preferredKey ExchangeAlgorithm

diffie-hellman-group1-sha1

preferred CompressionAlgorithm

none

preferred DataIntegrityAlgorithm

hmac-md5

preferredPKIAlgorithm

ssh-rsa

privateKeyFile

C:\my-secured-folder\id_rsa

preferredCipherSuite

blowfish-cbc

transportProvider

HTTP

4.4.5 OracleファイルとFTPアダプタのFIPS準拠の有効化

この項では、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に設定されています。

1.4.44バージョンからJ2SSH Maverickライブラリを使用している場合、1.4.47にアップグレードします(FIPS準拠はこのバージョンでのみサポートされているため)。

- J2SSH Maverickライブラリは、<MW_HOME>/soa/soa/modules/maverick-all.jarで更新されます

- Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesは、<jre>/lib/securityに配置されています

FTPアダプタはJDKに依存し、現在のSun JDKは2048ビット暗号をサポートしていません。動作保証には、KeyStoreプロバイダとしてRsaJsseを使用します。また、プロバイダとしてcom.rsa.jsse.JsseProviderをセキュリティ・ポリシー・ファイルに追加します。

接続ファクトリの次のパラメータを設定します。

- 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サポートに関する項を参照してください。

4.4.6 HTTPプロキシのための構成

サポートしているプロキシはHTTPプロキシのみです。HTTPプロキシ・サポートは、プレーンFTPモードおよびSFTPモードという2つのモードで使用できます。この項では、プレーンFTPモードとSFTPモードで実行するように構成する方法について説明します。次の項目が含まれます。

- プレーンFTPモード用の構成

- SFTPモード用の構成

4.4.6.1 プレーンFTPモード用の構成

プレーンFTPモードで実行する場合は、デプロイメント・ディスクリプタで特定のパラメータの値を指定する必要があります。表4-16 に変更が必要なプロパティを示します。

表4-16 プレーンFTPモードのプロパティ

プロパティ

説明

host

リモートFTPサーバー名。

port

FTP制御ポート番号。

username

FTPユーザー名。

password

FTPパスワード。

proxyHost

プロキシ・ホスト名。

proxyPort

プロキシ・ポート番号。

proxyUsername

プロキシ・ユーザー名。

proxyPassword

プロキシ・パスワード。

proxyType

プロキシ・タイプ。サポートされるのはHTTPプロキシ・タイプのみです。

proxyDefinitionFile

プロキシ定義ファイルの絶対パス。

このパラメータはオプションです。

詳細は、「プロキシ定義ファイル」を参照してください。

useProxy

プロキシを使用する場合はtrueを指定します。

表4-17に、デプロイメント・ディスクリプタのプロパティとその値のサンプル・リストを示します。

表4-17 サンプルのプレーンFTPモードのプロパティとその値

プロパティ

値

host

my.host.com

port

21

username

user

password

password

proxyHost

proxy.host.com

proxyPort

80

proxyUsername

anonymous

proxyPassword

tiger@scott.com

proxyType

http

proxyDefinitionFile

c:\proxydefinitions.xml

useProxy

true

4.4.6.1.1 プロキシ定義ファイル

すべてのプロキシ固有情報をプロキシ定義ファイルで指定し、このファイルを使用するようにデプロイメント・ディスクリプタの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>

「例 - プロキシ定義ファイル」のファイルを使用すると、次の一連のログイン・コマンドが送信されます。

1. USER remote_username

2. 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>

4.4.6.2 SFTPモード用の構成

SFTPモードで実行する場合は、デプロイメント・ディスクリプタで特定のプロパティの値を指定する必要があります。表4-18 に変更が必要なプロパティを示します。

表4-18 SFTPモードのプロパティ

プロパティ

説明

host

リモートFTPサーバー名。

port

FTP制御ポート番号。

username

SFTPユーザー名。

password

SFTPパスワード。

proxyHost

プロキシ・サーバーのホスト名。

proxyPort

プロキシ・ポート番号。

proxyUsername

プロキシ・ユーザー名。

proxyPassword

プロキシ・パスワード。

useSftp

SFTPモードの場合はtrueを指定します。SFTP機能を使用するには、この値が必須です。

authenticationType

PASSWORDまたはPUBLICKEY.PASSWORDを指定します。

「SFTP用の設定」を参照してください

transportProvider

値httpを指定します。サポートされるのはHTTPトランスポート・プロバイダのみです。

表4-19 に、デプロイメント・ディスクリプタのプロパティのサンプル・リストを示します。

表4-19 サンプルのSFTPモードのプロパティとその値

プロパティ

値

host

my.host.com

port

22

username

user

password

password

proxyHost

proxy.host.com

proxyPort

80

proxyUsername

anonymous

proxyPassword

password

useSFTP

true

authenticationType

password

transportProvider

http

4.4.7 高可用性のためのファイル/FTPアダプタの構成

SOAとOSBの両方で、アクティブ/アクティブ・トポロジ内に高可用性のためのファイル/FTPアダプタを構成できます。高可用性は、インバウンドとアウトバウンドの両方の操作に対して構成できます。

4.4.7.1 インバウンド操作

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>

4.4.7.2 アウトバウンド操作

Oracleファイル/FTPアダプタでは、複数の参照が同じディレクトリに書き込まれた場合に相互に上書きされないことが保証されています。

アダプタは、データベース表を使用して、フォルダ内の同じファイルに対する同時書込みへのアクセスをシリアライズします。この手順はインバウンド操作の場合と同様であり、Oracle表を使用するeis/HAFileAdapterを選択するか、SQL Serverの場合はeis/HAFileAdapterMQSSQL、DB2の場合はeis/HAFileAdapterDB2をそれぞれ選択する必要があります。

ファイル/FTPアダプタでのインバウンド操作に対する高可用性と同様に、ファイル/FTPアダプタでアウトバウンド操作を実行する場合も、高可用性機能のためのCoherenceがサポートされています。設計の経験に基づいて、ファイル・アダプタの場合はeis/CoherenceHAFileAdapter、FTPアダプタの場合はeis/Ftp/CoherenceHAFtpAdapterを.jcaファイル内に指定する必要があります。

4.4.7.3 その他の考慮事項

ファイル/FTPアダプタでは、Coherenceをロッキング・メカニズムとして使用して、インバウンドとアウトバウンドの両方で高可用性をサポートしています。

4.4.7.3.1 インバウンド操作

インバウンド処理の場合、ファイル/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>

4.4.7.3.2 アウトバウンド操作

クラスタ内の同じファイルに追加する場合、アダプタが、追加先のfilename beginの名前付きキャッシュに対する明示的なロックを取得する必要があります。

また、バッチ処理を使用する場合、バッチ処理基準でアウトバウンド・フォルダへの書込みを強制するように評価される前に、バッチ処理されたコンテンツを格納するためのコントロール・ディレクトリが必要です。

アウトバウンドでのHAを実現するためには、アダプタには共有ファイル・システムに対するコントロール・ディレクトリが必要です(これはインバウンドでの機能と同様です)。

4.4.7.3.3 高可用性シナリオでのXAの構成

高可用性シナリオでXAトランザクション機能を提供する場合は、次の手順を実行します。

1. WebLogic Serverコンソールにログインし、「デプロイメント」→「ファイル・アダプタ」を選択します。

図4-54 「デプロイメント」の「ファイル・アダプタ」が表示されたWebLogicコンソール

2. 「構成」→「アウトバウンド接続プール」を選択します。

図4-55 「アウトバウンド接続プール」が表示されたWebLogicコンソール

3. 「新規」を選択します。oracle.tip.adapter.file.NonSharedConnectionFactoryを選択します。

図4-56 「oracle.tip.adapter.file.NonSharedConnectionFactory」が選択されたWebLogicコンソールのファイル・アダプタ・デプロイメント

4. 新規の接続インスタンスに指定するJNDI名前を入力します。

図4-57 新規インスタンスに指定されたJNDI名を示すWebLogicコンソール

5. 「終了」を選択して保存します。JNDIインスタンスを再び開いて、図4-58 に示すように、次のアウトバウンド接続プロパティを入力します。

図4-58 アウトバウンド接続プロパティが表示されたインスタンスを示すWebLogicコンソール

表4-20 も参照してください

表4-20 JNDIインスタンスのアウトバウンド接続プロパティ

プロパティ

プロパティ・タイプ

プロパティ値

動的索引付けのサポート

ConferenceCacheConfig

java.lang.string

config/fileadpter-cache-config.xml

False

ControlDir

java.lang.string

/scratch/ha

False

InboundCoherenceCacheName

java.lang.string

FileAdapter-inbound

False

InboundDataSource

java.lang.string

jdbc/SOADataSource

False

IsTransacted

java.lang.string

false

False

OutboundCoherenceCacheName

java.lang.string

FileAdapter-outbound

False

OutboundDataSource

java.lang.string

jdbc/SOADataSource

False

OutboundDataSourceLocal

java.lang.string

jdbc/SOALocalTxDataSource

False

OutboundLockTypeForWrite

java.lang.string

oracle

False

WorkingDirectory

java.lang.string

default

False

6. 「トランザクション」タブの「XAトランザクション」を選択します。「保存」を選択します。

図4-59 WebLogicコンソールでの「トランザクション」タブの選択

7. OSBを使用する場合は、次の追加タスクを実行する必要があります。

- jdbc/SOALocalTXDataSourceデータソースを指定します(デフォルトで使用可能になっていないため)。

- アウトバウンドXAの場合、ルーティング・オプションおよびパイプライン・トランザクションに対するQoS (Once-and-only once)が必要です。

- インバウンドのローカル・トランザクションの場合、Check Pipeline transactionは必要ありません。

4.5 Oracleファイル/FTPアダプタの使用例

この項は、次のOracleファイル/FTPアダプタの使用例で構成されています。

- Oracleファイル・アダプタのXMLデバッチ処理

- Oracle BPEL PMのフラット構造

- メディエータのフラット構造

- Oracleファイル・アダプタのスケーラブルなDOM

- Oracleファイル・アダプタのチャンク読取り

- 添付ファイルとしてのOracleファイル・アダプタのRead File

- Oracleファイル・アダプタのファイル・リスティング

- Oracleファイル・アダプタの複雑な構造

- Oracle FTPアダプタのデバッチ処理

- Oracleファイル・アダプタの動的な同期読取り

- ファイルのコピー、移動および削除

- ファイル・アダプタを使用した同期BPELコンポジットの作成

- ファイル/FTPアダプタの順序付け方法の変更

- ファイルの処理順序の制御

- FTPアダプタの拡張

4.5.1 Oracleファイル・アダプタのXMLデバッチ処理

これは、大きいXML文書を小さい個別のXMLフラグメントにデバッチするOracleファイル・アダプタ機能です。

この使用例では、XMLのデバッチ・プロセスでOracleファイル・アダプタを使用し、繰返しノードとしてXMLファイルで発生する従業員のバッチを含むXMLファイルをデバッチします。その後、アダプタによってこれらのノードが処理され、個々の各ノードが個別の出力ファイルに書き込まれます。

この使用例には、次の項目が含まれます。

- 前提条件

- 反復要素を含む大きな入力XMLドキュメントの分割

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・ファイル・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Oracle Enterprise Manager Fusion Middleware Controlコンソール(Fusion Middleware Controlコンソール)を使用した監視

4.5.1.1 前提条件

デバッチを実行するには、Adapters-102FileAdapterXMLDebatchingサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/input/emps.xml

- artifacts/schemas/employees.xsd

Adapters-102FileAdapterXMLDebatchingサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

4.5.1.2 反復要素を含む入力XMLドキュメントの分割

この項では、反復要素を含む入力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>

4.5.1.3 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 図4-60 に示すように、「アプリケーション名」フィールドにSOA-XMLDebatchingと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

図4-60 「汎用アプリケーションの作成 - アプリケーションの名前付け」ページ

3. 「プロジェクト名」フィールドにXMLDebatchingと入力します。

4. 図4-61 に示すように、「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックして、「選択済」リストに移動します。

図4-61 「汎用アプリケーションの作成 - プロジェクトの名前付け」ページ

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 図4-62 に示すように、「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

図4-62 「汎用アプリケーションの作成 - SOA設定の構成」ページ

7. 図4-63 に示すように、「名前」フィールドにBPELXMLDebatchingと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

図4-63 「BPELプロセスの作成 - BPELプロセス」ページ

8. 「OK」をクリックします。図4-64 に示すように、SOA-XMLDebatchingアプリケーションとXMLDebatchingプロジェクトが設計領域に表示されます。

図4-64 JDeveloper - composite.xml

9. employees.xsdファイルをプロジェクトのxsdディレクトリにコピーします(このファイルの場所の詳細は、「前提条件」を参照)。

4.5.1.4 インバウンド・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 図4-65 に示すように、「サービス名」フィールドにXMLDebatchingInと入力します。

図4-65 「アダプタ構成ウィザード - サービス名」ページ

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 図4-66 に示すように、「Read File」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

図4-66 「アダプタ構成ウィザード - 操作」ページ

7. 図4-67 に示すように、入力ディレクトリの物理パスを入力します。「ファイルのフィルタ処理」ページが表示されます。

図4-67 「アダプタ構成ウィザード - ファイル・ディレクトリ」ページ

8. 図4-68 に示すように、「インクルード・ファイルの名前パターン」フィールドに*.xmlと入力し、「ファイルが複数のメッセージを含む」チェック・ボックスを選択し、「バッチでメッセージをパブリッシュする数」ボックスの値として1を指定します。

図4-68 「アダプタ構成ウィザード - ファイルのフィルタ処理」ページ

9. 「次」を選択します。「ファイル・ポーリング」ページが表示されます。

10. 「次」を選択します。「メッセージ」ページが表示されます。

11. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 図4-69 に示すように、「プロジェクトのスキーマ・ファイル」、「employees.xsd」および「employees」を順番にクリックします。

図4-69 「タイプ・チューザ」ダイアログ

13. 「OK」をクリックします。図4-70 に示すように、「メッセージ」ページの「URL」フィールドにemployees.xsdファイルが移入されます。

図4-70 「アダプタ構成ウィザード - メッセージ」ページ

14. 「次」を選択します。「終了」ページが表示されます。

15. 「終了」をクリックします。図4-71に示すように、インバウンドが構成され、composite.xmlが表示されます。

図4-71 JDeveloper - composite.xml

4.5.1.5 アウトバウンド・ファイル・アダプタ・サービスの作成

ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・ファイル・アダプタ・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにXMLOutと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Write File」を選択して「次へ」をクリックします。「ファイル構成」ページが表示されます。

7. 図4-72 に示すように、出力ディレクトリの物理パスを入力し、emp_%SEQ%.xmlを「ファイル・ネーミング規則(po_%SEQ%.txt)」フィールドに入力します。

8. 選択されていない場合は、「メッセージ数の到達」オプションを選択します。デフォルト値は、1です。

図4-72 「アダプタ構成ウィザード - ファイル構成」ページ

9. 「次」を選択します。「メッセージ」ページが表示されます。

10. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 図4-73 に示すように、「プロジェクトのスキーマ・ファイル」、「employees.xsd」および「employee」を順番にクリックします。

図4-73 「タイプ・チューザ」ダイアログ

12. 「OK」をクリックします。図4-70 に示すように、「メッセージ」ページの「URL」フィールドにemployees.xsdファイルが移入されます。

13. 「次」を選択します。「終了」ページが表示されます。

14. 「終了」をクリックします。図4-74に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-74 JDeveloper - composite.xml

4.5.1.6 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるXMLDebatchingIn内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のXMLOut内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図4-75 のように表示されます。

図4-75 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.1.6.1 反復要素を含む入力XMLドキュメントの分割

この項では、反復要素を含む入力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>

4.5.1.6.2 receiveアクティビティの追加

1. 「BPELXMLDebatching」をダブルクリックします。「BPELXMLDebatching.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 図4-76 に示すように、「名前」フィールドにReceiveEmployeeと入力します。

図4-76 JDeveloper - BPELXMLDebatching.bpel

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 図4-77 に示すように、「XMLDebatchingIn」を選択して「OK」をクリックします。

図4-77 「パートナ・リンク・チューザ」ダイアログ

7. 図4-78 に示すように、「Receive」ダイアログで「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

図4-78 「Receive」ダイアログ

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。図4-79 に示すように、JDeveloperの「BPELXMLDebatching.bpel」ページが表示されます。

図4-79 JDeveloper - BPELXMLDebatching.bpel

4.5.1.6.3 invokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 図4-80 に示すように、「名前」フィールドにWriteEmployeeと入力します。

図4-80 「Invoke」ダイアログ

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 図4-81 に示すように、「XMLOut」を選択して「OK」をクリックします。

図4-81 「パートナ・リンク・チューザ」ダイアログ

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。図4-82 に示すように、Invokeダイアログが表示されます。

図4-82 「Invoke」ダイアログ

8. 「OK」をクリックします。図4-83 に示すように、JDeveloperの「BPELXMLDebatching.bpel」ページが表示されます。

図4-83 JDeveloper - BPELXMLDebatching.bpel

4.5.1.6.4 transformアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にtransformアクティビティをドラッグ・アンド・ドロップします。

2. transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。

3. 図4-84 に示すように、「名前」フィールドにTransformPayloadと入力します。

図4-84 「Transform」ダイアログ

4. 「トランスフォーメーション」タブをクリックします。図4-85 に示すように、「Transform」ダイアログが表示されます。

図4-85 「Transform」ダイアログ - 「トランスフォーメーション」タブ

5. 「作成」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

6. 「ソース変数」ボックスで「ReceiveEmployee_Read_InputVariable」を選択し、「ソース・パート」ボックスで「employees」を選択して「OK」をクリックします。「ソース」と「パート」が選択された状態で「変換」ダイアログが表示されます。

7. 図4-86 に示すように、「ターゲット変数」リストで「WriteEmployee_Write_InputVariable」を選択し、「ターゲット・パート」で「employee」を選択します。

図4-86 「Transform」ダイアログ

8. 「マッピングの作成」アイコンをクリックします。「XSLエディタ」ページが表示されます。

9. 図4-87 に示すように、ソースからemployeesをターゲットのemployeeにドラッグします。「自動マップ・プリファレンス」ダイアログが表示されます。

図4-87 JDeveloper - Transformation_2.xsl

10. 「OK」をクリックします。

11. 「ファイル」、「すべて保存」を順番にクリックします。

12. 「XSLエディタ」ページを閉じます。図4-88 に示すように、「BPELXMLDebatching.bpel」ページが表示されます。

図4-88 JDeveloper - XMLデバッチ処理の完了

4.5.1.7 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください

4.5.1.8 Oracle Enterprise Manager Fusion Middleware Controlコンソール(Fusion Middleware Controlコンソール)を使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. emps.xmlファイルを入力ディレクトリにコピーし、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。

9. アクティビティをクリックしてアクティビティ詳細を表示します。

4.5.2 Oracle BPEL PMのフラット構造

この使用例では、フラット構造のビジネス・プロセスでOracleファイル・アダプタを使用して、カンマ区切り値(CSV)ファイルのアドレス帳エントリを処理する方法について説明します。これらのエントリは、その後変換されて固定長フォーマットで別のファイルに書き込まれます。

この使用例には、次の項目が含まれます。

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Oracle Fusion Middleware Controlコンソールを使用した監視

4.5.2.1 前提条件

フラット構造のビジネス・プロセスを実行するには、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サイトにアクセスします。

4.5.2.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにSOA-FlatStructureと入力して「OK」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」にFlatStructureと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

7. 「名前」フィールドにBPELFlatStructureと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。図4-89 に示すように、SOA-FlatStructureアプリケーションとFlatStructureプロジェクトが設計領域に表示されます。

図4-89 JDeveloper - composite.xml

9. address-csv.xsdファイルおよびaddress-fixedLength.xsdファイルをプロジェクトのスキーマ・ディレクトリにコピーします(このファイルの場所の詳細は、「前提条件」を参照)。

10. addr1Toaddr2.xslをプロジェクトのxslディレクトリにコピーします(このファイルの場所の詳細は、「前提条件」を参照)。

4.5.2.3 インバウンド・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにFlatStructureInと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「次」を選択します。「操作」ページが表示されます。

6. 「Read File」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

7. 入力ディレクトリの物理パスを入力します。「処理済ファイルをアーカイブ」を選択します。

8. 処理済ファイルのアーカイブ・ディレクトリの物理パスを入力します。

9. 「次」を選択します。「ファイルのフィルタ処理」ページが表示されます。

10. 「インクルード・ファイルの名前パターン」フィールドに*.txtと入力して「次へ」をクリックします。「ファイル・ポーリング」ページが表示されます。

11. 「次」を選択します。「メッセージ」ページが表示されます。

12. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

13. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番にクリックします。

14. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが移入されます。

15. 「次」を選択します。「終了」ページが表示されます。

16. 「終了」をクリックします。図4-90に示すように、インバウンドが構成され、composite.xmlが表示されます。

図4-90 JDeveloper - composite.xml

4.5.2.4 アウトバウンド・サービスの作成

ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにFlatStructureOutと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Write File」を選択して「次へ」をクリックします。「ファイル構成」ページが表示されます。

7. 出力ディレクトリの物理パスを入力し、address_%SEQ%.dataを「ファイル・ネーミング規則(po_%SEQ%.txt)」フィールドに入力します。

8. 「次」を選択します。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番にクリックします。

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-fixedLength.xsdファイルが移入されます。

12. 「次」を選択します。「終了」ページが表示されます。

13. 「終了」をクリックします。図4-91に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-91 JDeveloper - composite.xml

4.5.2.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるFlatStructureIn内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFlatStructureOut内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図4-92 のように表示されます。

図4-92 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.2.5.1 receiveアクティビティの追加

1. 「BPELFlatStructure」をダブルクリックします。「BPELFlatStructure.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveCSVと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 「FlatStructureIn」を選択して「OK」をクリックします。

7. 「Receive」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。図4-93 に示すように、JDeveloperの「BPELFlatStructure.bpel」ページが表示されます。

図4-93 JDeveloper - BPELFlatStructure.bpel

4.5.2.5.2 invokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。「Invoke」ダイアログが表示されます。

3. 「名前」フィールドにInvokeWriteと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 「FlatStructureOut」を選択して「OK」をクリックします。

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

8. 「OK」をクリックします。図4-94 に示すように、JDeveloperの「BPELFlatStructure.bpel」ページが表示されます。

図4-94 JDeveloper - BPELFlatStructure.bpel

4.5.2.5.3 transformアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にtransformアクティビティをドラッグ・アンド・ドロップします。

2. transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。

3. 「名前」フィールドにTransformPayloadと入力します。

4. 「トランスフォーメーション」タブをクリックします。「Transform」ダイアログが表示されます。

5. 「作成」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

6. 「ソース変数」ボックスで「ReceiveCSV_Read_InputVariable」を選択し、「ソース・パート」ボックスで「body」を選択して「OK」をクリックします。「ソース」と「パート」が選択された状態で「変換」ダイアログが表示されます。

7. 「ターゲット変数」リストで「InvokeWrite_Write_InputVariable」を選択し、「ターゲット・パート」で「body」を選択します。

8. 「マッパー・ファイル」フィールドの端にある「参照」ボタンをクリックし、プロジェクトのxslディレクトリからaddr1Toaddr2.xslファイルを選択します。

9. 「OK」をクリックします。

10. 「ファイル」、「すべて保存」を順番にクリックします。図4-95 に示すように、「BPELFlatStructure.bpel」ページが表示されます。

図4-95 JDeveloper - BPELFlatStructure.bpel

4.5.2.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.2.7 Oracle Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. address-csv.txtファイルを入力ディレクトリにコピーし、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。また、アクティビティ(invoke、receiveなど)をクリックしてアクティビティ詳細を表示します。

9. 「ReceiveCSV」をクリックしてアクティビティ詳細を表示します。

4.5.3 メディエータのフラット構造

この使用例では、メディエータがReadFileというインバウンドOracleファイル・アダプタ・サービスを介して、ファイルシステムから顧客データをテキスト・ファイルとして受信します。ReadFileアダプタ・サービスから、ReadFile_RSというルーティング・サービスにメッセージが送信されます。ReadFile_RSからアウトバウンド・アダプタ・サービスWriteFTPにメッセージが送信されます。WriteFTPサービスにより、メッセージが関連外部アプリケーションに配信されます。

この使用例には、次の項目が含まれます。

- 前提条件

- アプリケーションとプロジェクトの作成

- スキーマ定義(.XSD)ファイルのインポート

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスのワイヤリング

- ルーティング・ルールの作成

- JDeveloperを使用したデプロイ

- 実行時タスク

4.5.3.1 前提条件

この例は、基本的なコンストラクト(サービスやルーティング・サービスなど)と、サービスを作成およびデプロイするJDeveloper環境を十分に理解していることを前提としています。

フラット構造のビジネス・プロセスを実行するには、Adapters-101FileAdapterFlatStructureサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/address-csv.xsd

Adapters-101FileAdapterFlatStructureサンプルを参照するには、Oracle SOA Sample Codeサイトにアクセスします。

4.5.3.2 アプリケーションとプロジェクトの作成

使用例のアプリケーションとプロジェクトを作成するには、次の手順を実行します。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにFileFTP_RWと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにFileRead_FTPWriteと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次」を選択します。「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

6. 「コンポジット・テンプレート」ボックスで「次のものを使用するコンポジット」を選択します。

7. 「終了」をクリックします。「メディエータの作成 - メディエータ・コンポーネント」ページが表示されます。

8. 「名前」フィールドにFileRead_RSと入力します。

9. 「テンプレート」リストで「インタフェースを後で定義」を選択し、「OK」をクリックします。FileFTP_RWアプリケーションとFileRead_FTPWriteプロジェクトが設計領域に表示されます。

4.5.3.3 スキーマ定義(.XSD)ファイルのインポート

メッセージの構造を定義するXSDファイルをインポートするには、次の手順を実行します。

1. Schemaディレクトリを作成し、このディレクトリにaddress-csv.xsdファイルをコピーします(このファイルの場所の詳細は、「前提条件」を参照)。

2. 「アプリケーション・ナビゲータ」で「FileRead_FTPWrite」を選択します。

3. 「ファイル」メニューから「インポート」を選択します。「インポート」ダイアログが表示されます。

4. 「インポートするものを選択」リストから「Webソース」を選択して「OK」をクリックします。「Webソース」ダイアログが表示されます。

5. 「コピー元」フィールドの右側にある「参照」をクリックします。「ディレクトリの選択」ダイアログが表示されます。

6. 「スキーマ」ディレクトリにナビゲートして「選択」をクリックします。ディレクトリが選択された状態で「Webソース」ダイアログが表示されます。

7. 「OK」をクリックします。

4.5.3.4 インバウンド・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します

1. 「コンポーネント」ウィンドウから設計領域にファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにReadFileと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「次」を選択します。「操作」ページが表示されます。

6. 「Read File」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

7. 「物理パス」オプションを選択し、「参照」をクリックしてポーリング・ディレクトリを選択します。

8. 「次」を選択します。「ファイルのフィルタ処理」ページが表示されます。

9. 「処理対象ファイルの名前パターン」フィールドに*.txtと入力して「次へ」をクリックします。「ファイル・ポーリング」ページが表示されます。

10. 「次」を選択します。「メッセージ」ページが表示されます。

11. 「URL」フィールドの端にある「スキーマ・ファイルを参照」ボタンをクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番に選択します。

13. 「OK」をクリックします。

14. 「メッセージ」ページで「次へ」をクリックします。「終了」ページが表示されます。

15. 「終了」をクリックします。ReadFileアダプタ・サービスが作成されます。

4.5.3.5 アウトバウンド・サービスの作成

FTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」から設計領域にFTPアダプタ・サービスをドラッグします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次へ」をクリックします。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにWriteFTPと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「FTPサーバー接続」ページが表示されます。

6. 「FTPサーバーのJNDI名」フィールドでFTPサーバーのJNDI名を指定して「次へ」をクリックします。「操作」ページが表示されます。

7. ファイル・タイプとして「ASCII」オプションを選択します。

8. 操作タイプとして「Put File」オプションを選択して「次へ」をクリックします。「ファイル構成」ページが表示されます。

9. 「発信ファイルのディレクトリ(物理パス)」フィールドで、ファイルの書込み先ディレクトリを指定します。

10. ファイル・ネーミング規則フィールドで、出力ファイル名のネーミング規則を指定します。たとえば、po_%SEQ%.txtを指定します。

11. 「次」を選択します。「メッセージ」ページが表示されます。

12. 「URL」フィールドの端にある「スキーマ・ファイルを参照」ボタンをクリックします。「タイプ・チューザ」ダイアログが表示されます。

13. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番に選択します。

14. 「OK」をクリックします。

15. 「メッセージ」ページで「次へ」をクリックします。「終了」ページが表示されます。

16. 「終了」をクリックします。WriteFTPアダプタ・サービスが作成されます。

4.5.3.6 サービスのワイヤリング

作成した3つのコンポーネント(インバウンド・サービス、コンポーネント、アウトバウンド参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるReadFile内の小さい三角形を、「コンポーネント」領域のメディエータ・コンポーネント内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるメディエータ・コンポーネント内の小さい三角形を、「外部参照」領域のWriteFTP内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。JDeveloperのcomposite.xmlが図4-96 のように表示されます。

図4-96 JDeveloper - composite.xml

4.5.3.7 ルーティング・ルールの作成

ルーティング・サービスを作成するには、次の手順を実行します。

1. 「ReadFile_RS」ルーティング・サービスをダブルクリックします。図4-97 に示すように、「操作」ペインに「Read」操作が表示されます。

図4-97 JDeveloper - ReadFile_RSルーティング・サービスのページ

2. 「<<フィルタ式>>」の左にある「+」記号をクリックし、ルーティング・ルールを開きます。

3. 「次を使用して変換」フィールドの端に表示されるアイコンをクリックします。図4-98 に示すように、「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

図4-98 「リクエスト・トランスフォーメーション・マップ」ダイアログ

4. 「新規マッパー・ファイルの作成」を選択し、「OK」をクリックします。

JDeveloperに「Root-Element_To_Root-Element.xsl」タブが追加されます。このタブを使用すると、ファイル・データ構造を正規のデータ構造に変換するためのドキュメント・トランスフォーメーション・ファイルをグラフィカルに作成できます。

5. 「imp1:Address」ソース要素を「imp1:Address」ターゲット要素にドラッグ・アンド・ドロップします。「自動マップ・プリファレンス」ダイアログが表示されます。

6. 「自動マップ中」オプションから、「祖先名を考慮した要素の一致」の選択を解除します。

7. 「OK」をクリックします。

8. 「ファイル」メニューから「保存」をクリックします。

4.5.3.8 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.3.9 実行時タスク

実行時に、テキスト・ファイルをポーリング・ディレクトリにコピーします。ファイルが取得されると、設計時に指定したディレクトリに書き込まれます。

4.5.4 Oracleファイル・アダプタのスケーラブルなDOM

この使用例では、スケーラブルなDOMプロセスでストリーミング機能を使用して、大型ファイルをディレクトリ間でコピーまたは移動する方法を説明します。

ストリーミング・オプションは、DB2のハイドレーション・ストアではサポートされません。

この使用例には、次の項目が含まれます。

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

4.5.4.1 前提条件

大きいペイロードのストリーミング・プロセスを実行するには、Adapters-103FileAdapterScalableDOMサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/address-csv.xsd

- artifacts/input/address-csv-large.txt

Adapters-103FileAdapterScalableDOMサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

4.5.4.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにSOA-ScalableDOMと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにScalableDOMと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。SOA-ScalableDOMアプリケーションとScalableDOMプロジェクトが「アプリケーション・ナビゲータ」に表示され、「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

7. 「名前」フィールドにBPELScalableDOMと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。SOA-ScalableDOMアプリケーションとScalableDOMプロジェクトが設計領域に表示されます。

9. address-csv.xsdファイルをプロジェクトのxsdディレクトリにコピーします(このファイルの場所の詳細は、「前提条件」を参照)。

4.5.4.3 インバウンド・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにScalableDOMInと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Read File」を選択し、「ファイル・ストリーミングを使用します」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

7. 入力ディレクトリの物理パスを入力します。「ファイルのフィルタ処理」ページが表示されます。

8. 「インクルード・ファイルの名前パターン」フィールドに*.txtと入力して「次へ」をクリックします。「ファイル・ポーリング」ページが表示されます。

9. 「次」を選択します。「メッセージ」ページが表示されます。

10. 「URL」フィールドの後に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 図4-99 に示すように、「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番にクリックします。

図4-99 「タイプ・チューザ」ダイアログ

12. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが移入されます。

13. 「次」を選択します。「終了」ページが表示されます。

14. 「終了」をクリックします。図4-100に示すように、インバウンドが構成され、composite.xmlが表示されます。

図4-100 JDeveloper - composite.xml

4.5.4.4 アウトバウンド・サービスの作成

ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにScalableDOMOutと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Write File」を選択して「次へ」をクリックします。「ファイル構成」ページが表示されます。

7. 出力ディレクトリの物理パスを入力し、address-csv_%SEQ%.xmlを「ファイル・ネーミング規則(po_%SEQ%.txt)」フィールドに入力します。

8. 「次」を選択します。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番にクリックします。

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが移入されます。

12. 「次」を選択します。「終了」ページが表示されます。

13. 「終了」をクリックします。図4-101に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-101 JDeveloper - composite.xml

4.5.4.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるScalableDOMIn内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のScalableDOMOut内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図4-102 のように表示されます。

図4-102 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.4.5.1 receiveアクティビティの追加

1. 「BPELScalableDOM」をダブルクリックします。「BPELScalableDOM.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveFileと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 図4-103 に示すように、「ScalableDOMIn」を選択して「OK」をクリックします。

図4-103 「パートナ・リンク・チューザ」ダイアログ

7. 「Receive」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。JDeveloperの「composite.xml」ページが図4-104 のように表示されます。

図4-104 JDeveloper - BPELScalableDOM.bpel

4.5.4.5.2 invokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 「名前」フィールドにWriteFileと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 「ScalableDOMOut」を選択して「OK」をクリックします。

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。「入力変数」フィールドにデフォルトの変数名が移入されます。Invokeダイアログが表示されます。

8. 「OK」をクリックします。図4-105 に示すように、JDeveloperの「BPELScalableDOM.bpel」ページが表示されます。

図4-105 JDeveloper - 「BPELScalableDOM.bpel」ページ

4.5.4.5.3 assignアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にassignアクティビティをドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「名前」フィールドにAssignPayloadと入力します。

4. 「コピー操作」タブをクリックします。図4-106 に示すように、Assignダイアログが表示されます。

図4-106 「Assign」ダイアログ - 「コピー操作」タブ

5. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

6. 図4-107 に示すように、「From」および「To」ペインで「変数」を開きます。

図4-107 「コピー操作の作成」ダイアログ

7. 「OK」をクリックします。図4-108 に示すように、Assignダイアログが表示されます。

図4-108 「Assign」ダイアログ

8. 「OK」をクリックします。図4-109 に示すように、JDeveloperの「BPELScalableDOM.bpel」ページが表示されます。

図4-109 JDeveloper - BPELScalableDOM.bpel

9. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.4.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.4.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. address-csv-large.txtファイルを入力ディレクトリにコピーし、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。また、アクティビティをクリックしてアクティビティ詳細を表示します。

4.5.5 Oracleファイル・アダプタのチャンク読取り

チャンク読取りは、whileループ内でinvokeアクティビティを使用してターゲット・ファイルを処理するOracleファイル・アダプタ機能です。この機能を使用すると、大きいファイルを適宜処理できます。

この使用例には、次の項目が含まれます。

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

4.5.5.1 前提条件

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サイトにアクセスします。

4.5.5.2 SOAコンポジットの設計

SOAコンポジット・アプリケーションを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにSOA-ChunkedReadと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにChunkedReadと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

7. 「名前」フィールドにBPELChunkedReadと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。図4-110 に示すように、SOA-ChunkedReadアプリケーションとChunkedReadプロジェクトが設計領域に表示されます。

図4-110 JDeveloper - composite.xml

9. address-csv.xsdファイルおよびaddress-fixedLength.xsdファイルをプロジェクトのxsdディレクトリにコピーします(これらのファイルの場所の詳細は、「前提条件」を参照)。

10. addr1Toaddr2.xslをプロジェクトのxslディレクトリにコピーします(これらのファイルの場所の詳細は、「前提条件」を参照)。

4.5.5.3 インバウンド・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにFileInNoPayloadInと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Read File」を選択し、「ファイルの内容を読み取らない」ボックスを選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

7. 入力ディレクトリの物理パスを入力します。「ファイルを再帰的に処理します」を選択します。

8. 「次」を選択します。「ファイルのフィルタ処理」ページが表示されます。

9. 「インクルード・ファイルの名前パターン」フィールドに*.txtと入力して「次へ」をクリックします。「ファイル・ポーリング」ページが表示されます。

10. 「次」を選択します。「終了」ページが表示されます。

11. 「終了」をクリックします。図4-111に示すように、インバウンドが構成され、composite.xmlが表示されます。

図4-111 JDeveloper - composite.xml

4.5.5.4 アウトバウンド・サービスの作成

ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにReadAddressChunkと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「同期Read File」を選択し、「操作名」フィールドにChunkedReadと入力して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

7. 出力ディレクトリの物理パスを入力し、「正常な取得後にファイルを削除」を選択します。

8. 「次」を選択します。「ファイル名」ページが表示されます。

9. 「ファイル名」フィールドにdummy.txtと入力します。

10. 「次」を選択します。「メッセージ」ページが表示されます。

11. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番にクリックします。

13. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが移入されます。

14. 「次」を選択します。「終了」ページが表示されます。

15. 「終了」をクリックします。図4-112に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-112 JDeveloper - composite.xml

16. メタデータを手動で編集して、チャンク読取り機能を組み込みます。

ReadAddressChunk_file.jcaファイルを開き、メタデータを次の例のように変更します。

例 - チャンク読取り機能を組み込むためのメタデータの変更

<?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 portType="ChunkedRead_ptt"
operation="ChunkedRead">
<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="1"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

17. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.5.4.1 別のアウトバウンドOracleファイル・アダプタ・サービスの追加

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにAppendChunkと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Write File」を選択し、「操作名」フィールドにWriteと入力して「次へ」をクリックします。「ファイル構成」ページが表示されます。

7. 出力ディレクトリの物理パスを入力し、「ファイル・ネーミング規則(po_%SEQ%.txt)」フィールドにdummy.txtと入力し、「既存のファイルに追加します」を選択します。

8. 「次」を選択します。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番にクリックします。

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-fixedLength.xsdファイルが移入されます。

12. 「次」を選択します。「終了」ページが表示されます。

13. 「終了」をクリックします。図4-113に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-113 JDeveloper - composite.xml

4.5.5.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、2つのアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるFileInNoPayloadIn内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のReadAddressChunk内に緑の三角形として表示されるドロップ・ゾーンと、「外部参照」領域のAppendChunk内の緑の三角形にドラッグします。

JDeveloperのcomposite.xmlが図4-114 のように表示されます。

図4-114 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.5.5.1 receiveアクティビティの追加

1. 「BPELChunkedRead」をダブルクリックします。「BPELChunkedRead.bpel」ページが表示されます。

2. (x)で表された「変数」アイコンをクリックします。「変数」ダイアログが表示されます。

3. 「作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

4. 図4-115 に示すように、次の変数を作成します(これらは後で使用します)。

<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"/>

図4-115 「変数」ダイアログ

注意:

すべての変数は、タイプxsd:stringの単純型です。

5. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

6. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

7. 「名前」フィールドにReceiveFileDetailsと入力します。

8. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

9. 「FileInNoPayloadIn」を選択して「OK」をクリックします。

10. 「Receive」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

11. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

12. 「インスタンスの作成」を選択します。

13. 「プロパティ」タブをクリックします。プロパティおよび対応する値の列が表示されます。

14. jca.file.Directoryプロパティを選択します。対応する値の列をダブルクリックします。「アダプタ・プロパティ値」ダイアログが表示されます。

15. 「変数の参照」アイコンをクリックします。「変数XPathビルダー」ダイアログが表示されます。

16. 「変数」を開いて「dir」を選択し、「OK」をクリックします。jca.file.Directoryの値がdirに設定されます。

17. jca.file.FileNameプロパティに対して同じ手順を繰り返し、値をfileに設定します。図4-116 に示すように、「Receive」ダイアログが表示されます。

図4-116 「Receive」ダイアログ - 「アダプタ」タブ

18. 「OK」をクリックします。図4-117 に示すように、JDeveloperの「BPELChunkedRead.bpel」ページが表示されます。

図4-117 JDeveloper - BPELChunkedRead.bpel

4.5.5.5.2 assignアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティの後にassignアクティビティをドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「名前」フィールドにAssignChunkedReadと入力します。

4. 「コピー操作」タブをクリックします。図4-106 に示すように、Assignダイアログが表示されます。

5. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

6. 図4-118 に示すように、ヘッダーのデフォルト値を設定します。

図4-118 「Assign」ダイアログ

7. 「OK」をクリックします。図4-119 に示すように、JDeveloperの「BPELChunkedRead.bpel」ページが表示されます。

図4-119 JDeveloper - BPELChunkedRead.bpel

8. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.5.5.3 invokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のassignアクティビティの下にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。「Invoke」ダイアログが表示されます。

3. 「名前」フィールドにInvokeReadAddressと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 「ReadAddressChunk」を選択して「OK」をクリックします。

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。「変数」フィールドにデフォルトの変数名が移入されます。入力変数が移入された状態で「Invoke」ダイアログが表示されます。

8. 同じ手順を繰り返して出力変数を選択します。図4-120 に示すように、Invokeダイアログが表示されます。

図4-120 「Invoke」ダイアログ

9. 「OK」をクリックします。図4-121 に示すように、JDeveloperの「BPELChunkedRead.bpel」ページが表示されます。

図4-121 JDeveloper - BPELChunkedRead.bpel

10. 「BPELChunkedRead.bpel」ページの「ソース」タブをクリックし、作成したinvokeアクティビティの次のプロパティを追加します。

例 - invokeアクティビティに追加するプロパティ

<bpelx:inputProperty name="jca.file.Directory"
variable="dir"/>
<bpelx:inputProperty name="jca.file.FileName"
variable="file"/>
<bpelx:inputProperty name="jca.file.LineNumber"
="outLineNumber"/>
<bpelx:inputProperty name="jca.file.ColumnNumber"
variable="outColumnNumber"/>
<bpelx:inputProperty name="jca.file.IsEOF"
variable="outIsEOF"/>
<bpelx:outputProperty name="jca.file.LineNumber"
variable="returnLineNumber"/>
<bpelx:outputProperty name="jca.file.ColumnNumber"
variable="returnColumnNumber"/>
<bpelx:outputProperty name="jca.file.IsEOF"
variable="returnIsEOF"/>
<bpelx:outputProperty
name="jca.file.IsMessageRejected"
variable="returnIsMessageRejected"/>
<bpelx:outputProperty
name="jca.file.RejectionReason"
variable="returnRejectionReason"/>
<bpelx:outputProperty name="jca.file.NoDataFound"
variable="returnNoDataFound"/>

これは、BPEL 2.0の場合とは異なります。そのBPELバージョンでは、これは次の例のように表示されます。

例 - BPEL 2.0を使用してinvokeに追加するプロパティ

<bpelx:toProperties>
<bpelx:toProperty name="jca.file.Directory" variable="dir"/>
<bpelx:toProperty name="jca.file.FileName" variable="file"/>
<bpelx:toProperty name="jca.file.LineNumber"
variable="outLineNumber"/>
<bpelx:toProperty name="jca.file.ColumnNumber"
variable="outColumnNumber"/>
<bpelx:toProperty name="jca.file.IsEOF"
variable="outIsEOF"/>
</bpelx:toProperties>
<bpelx:fromProperties>
<bpelx:fromProperty name="jca.file.LineNumber"
variable="returnLineNumber"/>
<bpelx:fromProperty name="jca.file.ColumnNumber"
variable="returnColumnNumber"/>
<bpelx:fromProperty name="jca.file.IsEOF"
variable="returnIsEOF"/>
<bpelx:fromProperty
name="jca.file.IsMessageRejected"
variable="returnIsMessageRejected"/>
<bpelx:fromProperty name="jca.file.RejectionReason"
variable="returnRejectionReason"/>
<bpelx:fromProperty
name="jca.file.NoDataFound"
variable="returnNoDataFound"/>
</bpelx:fromProperties

次の例のようにinvokeアクティビティが表示されます。

例 - invokeアクティビティ

<invoke name="InvokeReadAddress"
inputVariable="InvokeReadAddress_SynchRead_InputVariable"
outputVariable="InvokeReadAddress_SynchRead_OutputVariable"
partnerLink="ReadAddressChunk" portType="ns3:SynchRead_ptt"
operation="SynchRead">
<bpelx:inputProperty name="jca.file.Directory" variable="dir"/>
<bpelx:inputProperty name="jca.file.FileName" variable="file"/>
<bpelx:inputProperty name="jca.file.LineNumber"
variable="outLineNumber"/>
<bpelx:inputProperty name="jca.file.ColumnNumber"
variable="outColumnNumber"/>
<bpelx:inputProperty name="jca.file.IsEOF"
variable="outIsEOF"/>
<bpelx:outputProperty name="jca.file.LineNumber"
variable="returnLineNumber"/>
<bpelx:outputProperty name="jca.file.ColumnNumber"
variable="returnColumnNumber"/>
<bpelx:outputProperty name="jca.file.IsEOF"
variable="returnIsEOF"/>
<bpelx:outputProperty name="jca.file.IsMessageRejected" variable="returnIsMessageRejected"/>
<bpelx:outputProperty name="jca.file.RejectionReason"
variable="returnRejectionReason"/>
<bpelx:outputProperty name="jca.file.NoDataFound"
variable="returnNoDataFound"/>
</invoke>

11. 「assignアクティビティの追加」に示したように、CopyHeadersというassignアクティビティを追加し、invokeアクティビティからreturnパラメータをコピーします。図4-122 に示すように、Assignダイアログが表示されます。

図4-122 「Assign」ダイアログ

12. 「OK」をクリックします。図4-123 に示すように、JDeveloperの「BPELChunkedRead.bpel」ページが表示されます。

図4-123 JDeveloper - BPELChunkedRead.bpel

4.5.5.5.4 switchアクティビティの追加

1. switchアクティビティを「CopyHeaders」assignアクティビティの下にドラッグ・アンド・ドロップします。

2. switchアクティビティ内の「<case>」をダブルクリックします。「Switch Case」ダイアログが表示されます。

3. 「名前」フィールドにDATA FOUNDと入力し、「式」ボックスで「returnNoDataFound」式を選択します。図4-124 に示すように、「Switch Case」ダイアログが表示されます。

図4-124 「Switch Case」ダイアログ

4. invokeアクティビティをswitchアクティビティの「<Case DATA FOUND>」にドラッグ・アンド・ドロップします。

5. invokeアクティビティをダブルクリックします。「Invoke」ダイアログが表示されます。

6. 「名前」フィールドにInvokeAppendと入力します。

7. 「パートナ・リンク」フィールドで「AppendChunk」を選択します。

8. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

9. デフォルトの変数名を選択し、「OK」をクリックします。「変数」フィールドにデフォルトの変数名が移入されます。入力変数が移入された状態で「Invoke」ダイアログが表示されます。

10. 図4-125 に示すように、「プロパティ」タブをクリックしてファイル変数を選択します。

図4-125 「Invoke」ダイアログ

11. 「OK」をクリックします。

4.5.5.5.5 transformアクティビティの追加

1. transformアクティビティを、「<case DATA FOUND>」セクション内のInvokeAppendアクティビティの直前にドラッグ・アンド・ドロップします。

2. transformアクティビティをダブルクリックします。

3. 「名前」フィールドにTransformPayloadと入力します。

4. 「トランスフォーメーション」タブをクリックします。

5. 「作成」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

6. 「InvokeReadAddress_SyncRead_InputVariable」を選択して「OK」をクリックします。

7. 「ターゲット変数」リストで「InvokeAppend_Write_InputVariable」を選択します。

8. 「マッパー・ファイル」フィールドの端にある「参照」をクリックし、addr1Toaddr2.xslファイルを選択します。

9. 「OK」をクリックします。

10. emptyアクティビティをswitchアクティビティの「<otherwise>」セクションにドラッグ・アンド・ドロップします。図4-126 に示すように、「BPELChunkedRead.bpel」ページが表示されます。

図4-126 JDeveloper - BPELChunkedRead.bpel

11. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.5.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.5.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. address-csv.txtファイルを入力ディレクトリにコピーし(このファイルの場所の詳細は、「前提条件」を参照)、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。また、アクティビティをクリックしてアクティビティ詳細を表示します。

4.5.6 添付ファイルとしてのOracleファイル・アダプタのRead File

これは、ファイルシステムのソース・ディレクトリから宛先ディレクトリに大量のデータを添付ファイルとして不透明にコピーまたは移動するOracleファイル・アダプタ機能です。たとえば、大量のMS Word文書、イメージおよびPDFをコンポジット・アプリケーション内でコンテンツを処理せずに転送できます。添付ファイルとしてのファイル読取り機能は、「Read File」オプションが選択されている場合にのみ使用できます。

この使用例では、大きい*.docファイルを添付ファイルとして処理するOracleファイル・アダプタの機能について説明します。添付ファイルとしてファイルを読み取るこの機能は、Opaque変換によく似ています。ただし、GB規模の添付ファイルが可能であるかどうかはデータベースの制限によって異なります。

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

4.5.6.1 前提条件

Read Fileを添付ファイル機能として使用するには、大きいMS Word文書(*.docファイル)が必要です。

4.5.6.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにAttachmentAppと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにAttachmentと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

7. 「名前」フィールドにBPELAttachmentと入力し、「テンプレート」リストから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。図4-127 に示すように、AttachmentAppアプリケーションとAttachmentプロジェクトが設計領域に表示されます。

図4-127 JDeveloper - composite.xml

4.5.6.3 インバウンド・サービスの作成

ローカル・ディレクトリから大きいファイルを読み取るインバウンドのサービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにAttachmentInと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 図4-128 に示すように、「操作タイプ」に「Read File」を選択し、「ファイルを添付ファイルとして読取り」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

注意:

「キャラクタ・セット」、「エンコーディング」および「コンテンツ・タイプ」の各フィールドは無視してください。この添付ファイルの読取りを必要とするサード・パーティのアプリケーションを使用している場合にのみ、これらのフィールドに値を移入します。この使用例の添付ファイルは、最終的にアウトバウンドで使用されるため、これらの値は必要としません。

図4-128 「アダプタ構成ウィザード - 操作」ページ

7. 図4-67 に示すように、入力ディレクトリの物理パスを入力して「次へ」をクリックします。「ファイルのフィルタ処理」ページが表示されます。

8. 図4-68 に示すように、「インクルード・ファイルの名前パターン」フィールドに*.docと入力します。

9. 「次」を選択します。「ファイル・ポーリング」ページが表示されます。

10. 「次」を選択します。「終了」ページが表示されます。

11. 「終了」をクリックします。図4-129に示すように、インバウンドが構成され、composite.xmlが表示されます。

図4-129 JDeveloper - composite.xml

4.5.6.4 アウトバウンド・サービスの作成

ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにAttachmentOutと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Write File」を選択して「次へ」をクリックします。「ファイル構成」ページが表示されます。

7. 図4-72 に示すように、出力ディレクトリの物理パスを入力し、attachment_%SEQ%.docを「ファイル・ネーミング規則(po_%SEQ%.txt)」フィールドに入力します。

8. 「次」を選択します。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 図4-130 に示すように、「プロジェクトのWSDLファイル」、「AttachmentIn.wsdl」、「インライン・スキーマ」、「attachmentElement」を順番にクリックします。

図4-130 「タイプ・チューザ」ダイアログ

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにAttachmentIn.wsdlが移入されます。

12. 「次」を選択します。「終了」ページが表示されます。

13. 「終了」をクリックします。図4-131に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-131 JDeveloper - composite.xml

4.5.6.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるAttachmentIn内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のAttachmentOut内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図4-132 のように表示されます。

図4-132 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.6.5.1 receiveアクティビティの追加

1. 「BPELAttachment」をダブルクリックします。「BPELAttachment.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveInputと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 図4-133 に示すように、「AttachmentIn」を選択して「OK」をクリックします。

図4-133 「パートナ・リンク・チューザ」ダイアログ

7. 図4-134 に示すように、「Receive」ダイアログで「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

図4-134 「Receive」ダイアログ

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。図4-135 に示すように、JDeveloperの「BPELAttachment.bpel」ページが表示されます。

図4-135 JDeveloper - BPELXMLDebatching.bpel

4.5.6.5.2 invokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 「名前」フィールドにWrite_Attachmentと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 図4-136 に示すように、「AttachmentOut」を選択して「OK」をクリックします。

図4-136 「パートナ・リンク・チューザ」ダイアログ

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。図4-137 に示すように、Invokeダイアログが表示されます。

図4-137 「Invoke」ダイアログ

8. 「OK」をクリックします。図4-138 に示すように、JDeveloperの「BPELAttachment.bpel」ページが表示されます。

図4-138 JDeveloper - BPELXMLDebatching.bpel

4.5.6.5.3 assignアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にassignアクティビティをドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「名前」フィールドにAssignReferenceと入力します。

4. 「コピー操作」タブをクリックします。図4-139 に示すように、Assignダイアログが表示されます。

図4-139 「Assign」ダイアログ - 「コピー操作」タブ

5. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

6. 図4-140 に示すように、「From」および「To」ペインで「変数」を開きます。

図4-140 「コピー操作の作成」ダイアログ

注意:

変数が要素への参照によって定義される場合、ソースとターゲットの両方が同じ要素であることが必要です。

7. 「OK」をクリックします。図4-141 に示すように、Assignダイアログが表示されます。

図4-141 「Assign」ダイアログ

8. 「OK」をクリックします。図4-142 に示すように、JDeveloperの「BPELAttachment.bpel」ページが表示されます。

図4-142 JDeveloper - BPELScalableDOM.bpel

9. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.6.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.6.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. attachment.docファイルを入力ディレクトリにコピーし(詳細は、「前提条件」を参照)、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。また、アクティビティをクリックしてアクティビティ詳細を表示します。

4.5.7 Oracleファイル・アダプタのファイル・リスティング

これは、invokeアクティビティを使用してターゲット・ディレクトリからファイルのリストを取得するOracleファイル・アダプタ機能です。このファイルのリストはXML文書として返され、ファイル名、ディレクトリ名、ファイル・サイズ、最終変更時間などの情報が記載されています。

この使用例には、次の項目が含まれます。

- 前提条件

- SOAコンポジットの設計

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

4.5.7.1 前提条件

リスト表示を実行するには、*.txtファイルが必要です。*.txtファイルの作成および保存は、ターゲット・ディレクトリで行う必要があります。

4.5.7.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにFileListingAppと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにFileListingと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

7. 「名前」フィールドにBPELFileListingと入力し、「テンプレート」ボックスから「一方向BPELプロセス」を選択します。

8. 「OK」をクリックします。図4-143 に示すように、FileListingAppアプリケーションとFileListingプロジェクトが設計領域に表示されます。

図4-143 JDeveloper - composite.xml

4.5.7.3 アウトバウンド・サービスの作成

ターゲット・ディレクトリのファイルのリストを表示するアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにListFilesと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「List Files」を選択し、「操作名」フィールドにFileListingと入力して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

7. 図4-67 に示すように、入力ディレクトリの物理パスを入力します。

8. 「次」を選択します。「ファイルのフィルタ処理」ページが表示されます。

9. 「インクルード・ファイルの名前パターン」フィールドに*.txtと入力します。

10. 「次」を選択します。「終了」ページが表示されます。

11. 「終了」をクリックします。図4-144に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-144 JDeveloper - composite.xml

12. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.7.4 サービスとアクティビティのワイヤリング

作成した2つのコンポーネント(BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のListFiles内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図4-145 のように表示されます。

図4-145 JDeveloper - composite.xml

2. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.7.4.1 文字列変数の作成

1. 「BPELFileListing」をダブルクリックします。「BPELFileListing.bpel」ページが表示されます。

2. (x)で表された「変数」アイコンをクリックします。「変数」ダイアログが表示されます。

3. 「作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

4. 図4-146 に示すように、タイプがxsd:stringの変数MyDirを作成します(これは後で使用します)。

図4-146 「変数」ダイアログ

5. 「OK」をクリックします。図4-147 に示すように、JDeveloperの「BPELFileListing.bpel」ページが表示されます。

図4-147 JDeveloper - BPELFileListing.bpel

4.5.7.4.2 invokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティの下にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 「名前」フィールドにInvokeListFilesと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 「ListFiles」を選択して「OK」をクリックします。

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」を選択します。「変数」フィールドにデフォルトの変数名が移入されます。入力変数が移入された状態で「Invoke」ダイアログが表示されます。

8. 同じ手順を繰り返して出力変数を選択します。図4-148 に示すように、Invokeダイアログが表示されます。

図4-148 「Invoke」ダイアログ

9. 「プロパティ」タブをクリックします。プロパティおよび対応する値の列が表示されます。

10. jca.file.Directoryプロパティを選択します。対応する値の列をダブルクリックします。「アダプタ・プロパティ値」ダイアログが表示されます。

11. 「変数の参照」アイコンをクリックします。「変数XPathビルダー」ダイアログが表示されます。

12. 「変数」を開いて「MyDir」を選択し、「OK」をクリックします。jca.file.Directoryの値がMydirに設定されます。

13. 「OK」をクリックします。図4-149 に示すように、JDeveloperの「BPELFileListing.bpel」ページが表示されます。

図4-149 JDeveloper - BPELFileListing.bpel

4.5.7.4.3 assignアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にassignアクティビティをドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「名前」フィールドにAssignDirNameと入力します。

4. 「コピー操作」タブをクリックします。Assignダイアログが表示されます。

5. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

6. 図4-150 に示すように、ヘッダーの値を設定します。

図4-150 「Assign」ダイアログ

7. 「OK」をクリックします。図4-151 に示すように、JDeveloperの「BPELFileListing.bpel」ページが表示されます。

図4-151 JDeveloper - BPELFileListing.bpel

8. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.7.5 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.7.6 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. *.txtファイルを入力ディレクトリにコピーし(詳細は、「前提条件」を参照)、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。また、アクティビティをクリックしてアクティビティ詳細を表示します。

4.5.8 Oracleファイル・アダプタの複雑な構造

この使用例では、カスタム・フォーマットで定義されたネイティブ・データを処理するOracleファイル・アダプタ機能について説明します。このサンプルでは、カスタム・フォーマットはinvoice-nxsd.xsdに定義されている請求書を表します。Oracleファイル・アダプタでは、invoice.txtファイルを処理してComplexStructure BPELプロセスにパブリッシュします。その後、PurchaseOrderに変換されてxmlファイルとして書き出されます。

この使用例には、次の項目が含まれます。

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

4.5.8.1 前提条件

複雑な構造のビジネス・プロセスを実行するには、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サイトにアクセスします。

4.5.8.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにSOA-ComplexStructureと入力して「次へ」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにComplexStructureと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

7. 「名前」フィールドにBPEComplexStructureと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。図4-152 に示すように、SOA-ComplexStructureアプリケーションとComplexStructureプロジェクトが設計領域に表示されます。

図4-152 JDeveloper - composite.xml

9. invoice-nxsd.xsdファイルおよびpo.xsdファイルをプロジェクトのスキーマ・ディレクトリにコピーします(これらのファイルの場所の詳細は、「前提条件」を参照)。

10. InvToPo.xslをプロジェクトのxslディレクトリにコピーします(このファイルの場所の詳細は、「前提条件」を参照)。

4.5.8.3 インバウンド・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにComplex Structure Inと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Read File」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

7. 入力ディレクトリの物理パスを入力して「次へ」をクリックします。「ファイルのフィルタ処理」ページが表示されます。

8. 「インクルード・ファイルの名前パターン」フィールドに*.txtと入力して「次へ」をクリックします。「ファイル・ポーリング」ページが表示されます。

9. 「次」を選択します。「メッセージ」ページが表示されます。

10. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」、「invoice-nxsd.xsd」および「invoice」を順番にクリックします。

12. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにinvoice-nxsd.xsdファイルが移入されます。

13. 「次」を選択します。「終了」ページが表示されます。

14. 「終了」をクリックします。図4-153に示すように、インバウンドが構成され、composite.xmlが表示されます。

図4-153 JDeveloper - composite.xml

4.5.8.4 アウトバウンド・サービスの作成

ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにComplexStructureOutと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Write File」を選択して「次へ」をクリックします。「ファイル構成」ページが表示されます。

7. 出力ディレクトリの物理パスを入力し、「ファイル・ネーミング規則(po_%SEQ%.txt)」フィールドにinvoice_%SEQ%.txtと入力します。

8. 「次」を選択します。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「po.xsd」および「po」を順番にクリックします。

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにpo.xsdファイルが移入されます。

12. 「次」を選択します。「終了」ページが表示されます。

13. 「終了」をクリックします。図4-154に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-154 JDeveloper - composite.xml

4.5.8.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるComplexStructureInサービス内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のComplexStructureOut参照内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図4-155 のように表示されます。

図4-155 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.8.5.1 receiveアクティビティの追加

1. 「BPELComplexStructure」をダブルクリックします。「BPELComplexStructure.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveInvoiceと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 「ComplexStructureIn」を選択して「OK」をクリックします。

7. 「Receive」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。JDeveloperの「BPELComplexStructure.bpel」ページが表示されます。

4.5.8.5.2 invokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 「名前」フィールドにInvokeWriteと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 「ComplexStructureOut」を選択して「OK」をクリックします。

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. 「変数名」フィールドにInvokeWrite_Write_OutputVariableと入力し、「OK」をクリックします。「Invoke」ダイアログが表示されます。

8. 「OK」をクリックします。JDeveloperの「BPELComplexStructure.bpel」ページが表示されます。

4.5.8.5.3 transformアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にtransformアクティビティをドラッグ・アンド・ドロップします。

2. transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。

3. 「名前」フィールドにTransformPayloadと入力します。

4. 「トランスフォーメーション」タブをクリックします。「Transform」ダイアログが表示されます。

5. 「作成」アイコンを選択します。「ソース変数」ダイアログが表示されます。

6. 「ソース変数」ボックスで「ReceiveInvoice_Read_InputVariable」を選択し、「ソース・パート」ボックスで「body」を選択して「OK」をクリックします。「ソース」と「パート」が選択された状態で「変換」ダイアログが表示されます。

7. 「ターゲット変数」リストで「InvokeWrite_Write_OutputVariable」を選択し、「ターゲット・パート」で「body」を選択します。

8. 「マッパー・ファイル」フィールドの端にある「マッピングの参照」アイコンをクリックし、プロジェクトのxslディレクトリからInvToPo.xslファイルを選択します。

9. 「OK」をクリックします。

10. 「ファイル」、「すべて保存」を順番にクリックします。図4-156 に示すように、「BPELComplexStructure.bpel」ページが表示されます。

図4-156 JDeveloper - BPELComplexStructure.bpel

4.5.8.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.8.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. invoice.txtファイルを入力ディレクトリにコピーし(このファイルの場所の詳細は、「前提条件」を参照)、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。

9. 「ReceiveInvoice」をクリックしてアクティビティ詳細を表示します

4.5.9 Oracle FTPアダプタのデバッチ処理

これは、大きいXML文書を小さい個別のXMLフラグメントにデバッチするOracle FTPアダプタの機能です。この使用例では、ビジネス・プロセス・サンプルのデバッチ処理でOracle FTPアダプタを使用して、1つ以上の請求書や発注などのビジネス・レコードのバッチを含むファイルを処理する方法について説明します。これにより、発注(PO)がデバッチされて個別の出力ファイルに書き込まれます。

この使用例には、次の項目が含まれます。

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

4.5.9.1 前提条件

複雑な構造のビジネス・プロセスを実行するには、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サイトにアクセスします。

4.5.9.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにSOA-FTPDebatchingと入力して「OK」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」にFTPDebatchingと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

7. 「名前」フィールドにBPELFTPDebatchingと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。図4-157 に示すように、SOA-FTPDebatchingアプリケーションとFTPDebatchingプロジェクトが設計領域に表示されます。

図4-157 JDeveloper - composite.xml

9. container.xsdファイルおよびpo.xsdファイルをプロジェクトのxsdディレクトリにコピーします(これらのファイルの場所の詳細は、「前提条件」を参照)。

10. InvToPo.xslファイルおよびPoToPo.xslファイルをプロジェクトのxslディレクトリにコピーします(これらのファイルの場所の詳細は、「前提条件」を参照)。

4.5.9.3 インバウンド・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにFTPDebatchingInと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。図4-158 に示すように、「FTPサーバー接続」ページが表示されます。

注意:

このアプリケーションをデプロイする前に、デプロイメント・ディスクリプタでjndi-nameが構成済であることを確認してください。

図4-158 「アダプタ構成ウィザード - FTPサーバー接続」ページ

6. 「次」を選択します。「操作」ページが表示されます。

7. 図4-159 に示すように、「Get File」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

図4-159 「アダプタ構成ウィザード - 操作」ページ

8. 入力ディレクトリの物理パスを入力して「次へ」をクリックします。「ファイルのフィルタ処理」ページが表示されます。

9. 「インクルード・ファイルの名前パターン」フィールドに*.txtと入力し、「ファイルが複数のメッセージを含む」チェック・ボックスを選択し、「バッチでメッセージをパブリッシュする数」ボックスの値として1を指定します。

10. 「次」を選択します。「ファイル・ポーリング」ページが表示されます。

11. 「次」を選択します。「メッセージ」ページが表示されます。

12. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

13. 「プロジェクトのスキーマ・ファイル」、「container.xsd」および「container」を順番にクリックします。

14. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにcontainer.xsdファイルが移入されます。

15. 「次」を選択します。「終了」ページが表示されます。

16. 「終了」をクリックします。図4-160に示すように、インバウンドが構成され、composite.xmlが表示されます。

図4-160 JDeveloper - composite.xml

4.5.9.4 アウトバウンド・サービスの作成

ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにFTPアダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにPurchaseOrderOutと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「FTPサーバー接続」ページが表示されます。

6. 「次」を選択します。「操作」ページが表示されます。

7. 「Put File」を選択して「次へ」をクリックします。「ファイル構成」ページが表示されます。

8. 出力ディレクトリの物理パスを入力し、「ファイル・ネーミング規則(po_%SEQ%.txt)」フィールドにpo_%SEQ%.txtと入力します。

9. 選択されていない場合は、「メッセージ数の到達」オプションを選択します。デフォルト値は、1です。

10. 「次」を選択します。「メッセージ」ページが表示されます。

11. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「po.xsd」および「po」を順番にクリックします。

13. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにpo.xsdファイルが移入されます。

14. 「次」を選択します。「終了」ページが表示されます。

15. 「終了」をクリックします。図4-161に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-161 JDeveloper - composite.xml

4.5.9.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるFTPDebatchingInサービス内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のPurchaseOrderOut参照内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図4-162 のように表示されます。

図4-162 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.9.5.1 receiveアクティビティの追加

1. 「BPELFTPDebatching」をダブルクリックします。「BPELFTPDebatching.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 「FTPDebatchingIn」を選択して「OK」をクリックします。

7. 「Receive」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。JDeveloperの「BPELFTPDebatching.bpel」ページが表示されており、receiveアクティビティが追加されています。

4.5.9.5.2 invokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 「名前」フィールドにWriteと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 「PurchaseOrderOut」を選択して「OK」をクリックします。

6. 「Receive」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. 「変数」フィールドにWrite_Put_OutputVariableと入力し、「OK」をクリックします。Invokeダイアログが表示されます。

8. 「OK」をクリックします。JDeveloperの「BPELFTPDebatching.bpel」ページが表示されており、invokeアクティビティが追加されています。

4.5.9.5.3 switchアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にswitchアクティビティをドラッグ・アンド・ドロップします。

2. switchアクティビティを開きます。これにより、<case>および<otherwise>の値を入力するための画面が表示されます。

3. 図4-163 に示すように、「<case>」セクションで「条件式の表示」アイコンをクリックします。「条件式」ポップアップ・ウィンドウが表示されます。

図4-163 「BPELFTPDebatching.bpel」ページ

4. ポップアップ・ウィンドウ内で「XPath式ビルダー」アイコンをクリックします。「式ビルダー」ダイアログが表示されます。

5. 図4-164 に示すように、式としてstarts-with(local-name(ora:getNodes('receive_Get_InputVariable','body','/ns3:container/child::*[position()=1]')),'invoice')を入力し、「OK」をクリックします。画面が「条件式」ポップアップ・ウィンドウに戻ります。

図4-164 「式ビルダー」ダイアログ

6. 「<case>」セクションと「<otherwise>」セクションに1つずつ、2つのトランスフォーメーション・アクティビティを追加します。

a. transformアクティビティを「<case>」セクションにドラッグ・アンド・ドロップします。

b. transformアクティビティをダブルクリックします。

c. 「名前」フィールドにInvToPoと入力します。

d. 「トランスフォーメーション」タブをクリックします。

e. 「作成」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

f. デフォルトを受け入れて「OK」をクリックします。

g. 「ターゲット変数」リスト「Write_Put_OutputVariable」を選択します。

h. 「マッパー・ファイル」フィールドの端にある「マッピングの参照」アイコンをクリックし、「InvToPo.xsl」ファイルを選択します。

i. 「OK」をクリックします。

j. 同じプロセスを第2のトランスフォーメーションについて繰り返します。このtransformアクティビティの場合は、マッパー・ファイルとしてPoToPo.xslを選択します。

図4-165 に示すように、「BPELFTPDebatching.bpel」ページが表示されます。

図4-165 「BPELFTPDebatching.bpel」ページ

7. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.9.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.9.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。そのためには、次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. container.txtファイルを入力ディレクトリにコピーし(このファイルの場所の詳細は、「前提条件」を参照)、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。また、アクティビティ(invoke、receiveなど)をクリックしてアクティビティ詳細を表示します。

4.5.10 Oracle FTPアダプタの動的な同期読取り

この使用例では、invokeアクティビティを使用してプロセス途中の同期読取り操作を実行するOracle FTPアダプタの機能について説明します。この使用例で説明するアダプタ機能は、次のとおりです。

- Oracleファイル・アダプタ(読取り操作)

- Oracle FTPアダプタ(同期読取り操作)
実行時に読取り対象のファイル名を指定する機能

- Oracleファイル・アダプタ(書込み操作)

このプロセスは、インバウンドOracleファイル・アダプタによる監視対象のローカル・ディレクトリにファイルが存在することで開始されます。トリガー・ファイルには、同期読取り操作で読み取られるファイルの名前が含まれています。このファイル名は、ヘッダーを介してアダプタに渡されます。これを行うには、invokeアクティビティの「プロパティ」タブを使用します。この同期読取り操作は、FTPサーバー上のリモート・ディレクトリに対して実行されます。読取り結果は変換され、アウトバウンドOracleファイル・アダプタを介してローカル・ディレクトリに書き出されます。この項には次のトピックが含まれます:

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

4.5.10.1 前提条件

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」タブを選択します。

4.5.10.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにSOA-FTPDynamicSynchronousReadと入力して「OK」をクリックします。「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」にFTPDynamicSynchronousReadと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックして、このリストに移動します。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

7. 「名前」フィールドにBPELDynamicSynchronousReadと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。図4-166 に示すように、SOA-FTPDynamicSynchronousReadアプリケーションとFTPDynamicSynchronousReadプロジェクトが設計領域に表示されます。

図4-166 JDeveloper - composite.xml

9. address-csv.xsdファイル、address-fixedLength.xsdファイルおよびtrigger.xsdファイルをプロジェクトのxsdディレクトリにコピーします(これらのファイルの場所の詳細は、「前提条件」を参照)。

10. addr1Toaddr2.xslファイルをプロジェクトのxslディレクトリにコピーします(このファイルの場所の詳細は、「前提条件」を参照)。

4.5.10.3 インバウンド・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「公開されたサービス」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにReadTriggerと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Read File」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

7. 入力ディレクトリの物理パスを入力して「次へ」をクリックします。「ファイルのフィルタ処理」ページが表示されます。

8. 「インクルード・ファイルの名前パターン」フィールドに*.trgと入力して「次へ」をクリックします。「ファイル・ポーリング」ページが表示されます。

9. 「次」を選択します。「メッセージ」ページが表示されます。

10. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」、「trigger.xsd」および「trigger」を順番にクリックします。

12. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにtrigger.xsdファイルが移入されます。

13. 「次」を選択します。「終了」ページが表示されます。

14. 「終了」をクリックします。図4-167に示すように、インバウンドが構成され、composite.xmlが表示されます。

図4-167 JDeveloper - composite.xml

4.5.10.4 アウトバウンド・サービスの作成

ローカル・ディレクトリからFTPサーバーにファイルを書き込むアウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにFTPアダプタをドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにSyncReadと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「FTPサーバー接続」ページが表示されます。

6. 「次」を選択します。「操作」ページが表示されます。

7. 「同期Get File」を選択して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

8. 出力ディレクトリの物理パスを入力します。

9. 「次」を選択します。「ファイル名」ページが表示されます。

10. 「ファイル名」フィールドにdummy.txtと入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

11. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番にクリックします。

13. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが移入されます。

14. 「次」を選択します。「終了」ページが表示されます。

15. 「終了」をクリックします。図4-168に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-168 JDeveloper - composite.xml

4.5.10.4.1 アウトバウンドOracleファイル・アダプタ・サービスの追加

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにWriteFileと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「Write File」を選択し、「操作名」フィールドにWriteと入力して「次へ」をクリックします。「ファイル構成」ページが表示されます。

7. 出力ディレクトリの物理パスを入力し、「ファイル・ネーミング規則(po_%SEQ%.txt)」フィールドにaddress_%SEQ%.txtと入力します。

8. 「次」を選択します。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番にクリックします。

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-fixedLength.xsdファイルが移入されます。

12. 「次」を選択します。「終了」ページが表示されます。

13. 「終了」をクリックします。図4-169に示すように、アウトバウンドが構成され、composite.xmlが表示されます。

図4-169 JDeveloper - composite.xml

4.5.10.5 サービスとアクティビティのワイヤリング

作成した4つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、2つのアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるReadTrigger内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のSyncRead内に緑の三角形として表示されるドロップ・ゾーンと、WriteFile内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図4-170 のように表示されます。

図4-170 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.10.5.1 receiveアクティビティの追加

1. 「BPELDynamicSynchronousRead」をダブルクリックします。「BPELDynamicSynchronousRead.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveTriggerと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 「ReadTrigger」を選択して「OK」をクリックします。

7. 「Receive」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。JDeveloperの「BPELDynamicSynchronousRead.bpel」ページが表示されます。

4.5.10.5.2 変数の作成とinvokeアクティビティの追加

1. (x)で表された「変数」アイコンをクリックします。「変数」ダイアログが表示されます。

2. 「作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

3. 図4-171 に示すように、xsd:stringタイプのfileという変数を作成します。

図4-171 「変数の作成」ダイアログ

4. 「OK」をクリックして「BPELDynamicSynchronousRead.bpel」ページに戻ります。

5. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

6. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

7. 「名前」フィールドにInvoke_SyncReadと入力します。

8. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

9. 「SyncRead」を選択して「OK」をクリックします。

10. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

11. デフォルトの変数名を選択し、「OK」をクリックします。「入力変数」フィールドにデフォルトの変数名が移入されます。

12. 同じ手順を「出力変数」フィールドに対して繰り返します。

13. 「プロパティ」タブをクリックします。プロパティおよび対応する値の列が表示されます。

14. jca.ftp.FileNameプロパティを選択します。対応する値の列をダブルクリックします。「アダプタ・プロパティ値」ダイアログが表示されます。

15. 「変数の参照」アイコンをクリックします。「変数XPathビルダー」ダイアログが表示されます。

16. 「変数」を開いて「file」を選択し、「OK」をクリックします。jca.ftp.FileNameの値がfileに設定されます。

17. 「OK」をクリックします。JDeveloperの「BPELDynamicSynchronousRead.bpel」ページが表示されます。

4.5.10.5.3 別のinvokeアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。「Invoke」ダイアログが表示されます。

3. 「名前」フィールドにInvokeWriteと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 「WriteFile」を選択して「OK」をクリックします。

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

8. 「OK」をクリックします。JDeveloperの「BPELDynamicSynchronousRead.bpel」ページが図4-172 のように表示されます。

図4-172 JDeveloper - 「BPELDynamicSynchronousRead.bpel」ページ

4.5.10.5.4 assignアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のReceiveTriggerアクティビティとInvoke_SyncReadアクティビティの間にassignアクティビティをドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「名前」フィールドにAssignFileNameと入力します。

4. 「コピー操作」タブをクリックします。Assignダイアログが表示されます。

5. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

6. 図4-173 に示すように、トリガー・ファイル名とfile変数の間にコピー操作を作成します。

図4-173 「コピー操作の作成」ダイアログ

7. 「コピー操作の作成」ダイアログで、「OK」をクリックします。

8. 図4-174 に示すように、「OK」をクリックしてJDeveloperの「BPELDynamicSynchronousRead.bpel」ページに戻ります。

図4-174 JDeveloper - BPELDynamicSynchronousRead.bpel

9. 「ファイル」、「すべて保存」を順番にクリックします。

4.5.10.5.5 transformアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のInvoke_SyncReadアクティビティとInvokeWriteアクティビティの間にtransformアクティビティをドラッグ・アンド・ドロップします。

2. transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。

3. 「名前」フィールドにTransformPayloadと入力します。

4. 「トランスフォーメーション」タブをクリックします。「Transform」ダイアログが表示されます。

5. 「作成」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

6. 「ソース変数」ボックスで「InvokeSyncRead_SyncRead_OutputVariable」を選択し、「ソース・パート」ボックスで「body」を選択して「OK」をクリックします。「ソース」と「パート」が選択された状態で「変換」ダイアログが表示されます。

7. 「ターゲット変数」リストで「InvokeWrite_Write_InputVariable」を選択し、「ターゲット・パート」で「body」を選択します。

8. 「マッパー・ファイル」フィールドの端にある「マッピングの参照」アイコンをクリックし、プロジェクトのxslディレクトリからaddr1Toaddr2.xslファイルを選択します。

9. 「OK」をクリックします。

10. 「ファイル」、「すべて保存」を順番にクリックします。図4-175 に示すように、「BPELDynamicSynchronousRead.bpel」ページが表示されます。

図4-175 JDeveloper - BPELDynamicSynchronousRead.bpel

4.5.10.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

4.5.10.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. address-csv.txtファイルを入力ディレクトリにコピーし(このファイルの場所の詳細は、「前提条件」を参照)、処理済であることを確認します。出力ディレクトリを調べて、出力ファイルが作成されていることを確認します。

3. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

4. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

5. ステップ3でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

6. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

7. ペイロード・ノードを開いてペイロード詳細を確認します。

8. プロセス・フローを表示するには、「フロー」タブをクリックします。

9. 「ReceiveTrigger」をクリックしてアクティビティ詳細を表示します。

4.5.11 ファイルのコピー、移動および削除

使用すると、ある場所から別の場所にファイルをコピーまたは移動したり、ターゲット・ディレクトリからファイルを削除できます。さらに、ローカル・ファイルシステムとリモート・ファイルシステムの間でファイルをコピーまたは移動できます。この機能は、アウトバウンド・サービスの相互作用仕様として実装されます。そのため、BPELのinvokeアクティビティまたはメディエータのルーティング・ルールを使用してこの機能にアクセスできます。

高レベルでは、アウトバウンド・サービスを作成して、ソース・ディレクトリおよびターゲット・ディレクトリとファイル名を使用してこのサービスを構成する必要があります。

次の使用例では、アウトバウンド・サービスの使用によりファイルをコピー、移動および削除できる、サポートされている新機能を説明しています。

- ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動

- ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルのコピー

- ローカル・ファイルシステム・ディレクトリからのファイルの削除

- 大きいCSVソース・ファイルの使用

- あるリモート・ディレクトリから同じFTPサーバーの別のリモート・ディレクトリへのファイルの移動

- ファイルシステムのローカル・ディレクトリからFTPサーバーのリモート・ディレクトリへのファイルの移動

- FTPサーバーのリモート・ディレクトリからファイルシステムのローカル・ディレクトリへのファイルの移動

- あるFTPサーバーから別のFTPサーバーへのファイルの移動

4.5.11.1 ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動

ウィザードで実行できるのはこの手順の一部のみです。これは、該当するアダプタ構成ウィザードが使用可能でないためです。生成したJCAファイルを手動で構成することにより、残りの手順を完了してください。

ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリにファイルを移動するには、次の手順を実行します。

1. 空のBPELプロセスを作成します。

2. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにファイル・アダプタをドラッグ・アンド・ドロップします。「アダプタ構成ウィザード - ようこそ」ページが表示されます。

3. 「Next」をクリックします。「サービス名」ページが表示されます。

4. 「サービス名」フィールドにサービス名を入力します。

5. 「Next」をクリックします。「アダプタ・インタフェース」ページが表示されます。

6. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

7. 「同期Read File」を選択し、「操作名」フィールドにFileMoveと入力して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

注意:

同期Read Fileを選択したのは、この操作の結果として生成されるWSDLファイルが、I/O操作に必要なファイルと同様のものであるためです。

8. 着信ファイル用のディレクトリのダミー物理パスを入力し、「次へ」をクリックします。「ファイル名」ページが表示されます。

注意:

このダミー・ディレクトリは使用されません。以降の手順でこのディレクトリを手動で変更する必要があります。

9. ダミー・ファイル名を入力し、「次へ」をクリックします。「メッセージ」ページが表示されます。

注意:

入力したダミー・ファイル名は使用されません。以降の手順でこのファイル名を手動で変更する必要があります。

10. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。

11. 「終了」をクリックします。これで、アウトバウンドの構成は完了です。

12. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFileMove内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。BPELコンポーネントがアウトバウンド・サービスに接続されます。

13. デフォルト設定を選択して、先ほど作成したFileMoveサービスのinvokeアクティビティを作成します。
次の手順では、生成したWSDLファイルをMoveFileServiceサービス用に変更し、移動操作の新規の相互作用仕様で構成します。

14. 次の例に示すように、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があります。

15. 次の手順を実行して、実際のディレクトリ名とファイル名をソース・ファイルとターゲット・ファイルのパラメータにマッピングします。

a. 適切な名前を付けた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>

b. 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が移動されます。

注意:

この例では、ソースおよびターゲットの詳細がハードコードされています。これらの詳細は、ランタイム・パラメータとして指定することもできます。

c. これらのパラメータをヘッダーとして起動操作に渡します。これらの変数値によって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>

16. 最後に、最初のreceiveまたはpickアクティビティを追加します。
ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動が完了しました。

4.5.11.2 ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルのコピー

ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリにファイルをコピーするには、次の手順を実行します。

1. 「ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動」のステップ1から12に従います。

2. 次の例に示すように、「ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動」のステップ14で、エンドポイント相互作用のTYPE属性の値をMOVEからCOPYに変更します。

例 - Typeプロパティ名の値をCopyに変更

<adapter-config ...>
<connection-factory .../>
<endpoint-interaction ...>
<interaction-spec
className="oracle.tip.adapter.file.outbound.FileIoInteractionSpec">
<property .../>
<property name="Type" value="COPY"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

4.5.11.3 ローカル・ファイルシステム・ディレクトリからのファイルの削除

ファイルを削除するには、TargetPhysicalDirectoryおよびTargetFileNameパラメータが必要です。

注意:

ローカル・ファイルシステム・ディレクトリからファイルを削除する場合、SourcePhysicalDirectoryおよびSourceFileNameは必要ありません。

ファイルdelete_me.txtを/home/alexディレクトリから削除するには、次の手順を実行します。

1. 「ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動」のステップ1から12に従います

2. 次の例に示すように、「ファイルシステムのローカル・ディレクトリから別のローカル・ディレクトリへのファイルの移動」のステップ14で、エンドポイント相互作用のTYPE属性の値をDELETEに変更します。

例 - TYPE属性の値をDELETEに変更

<adapter-config name="FileDelete" adapter="File Adapter"
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/FileAdapter" adapterRef=""/>
<endpoint-interaction portType="FileDelete_ptt" operation="FileDelete">
<interaction-spec
className="oracle.tip.adapter.file.outbound.FileIoInteractionSpec">
<property name="TargetPhysicalDirectory" value="/home/alex"/>
<property name="TargetFileName" value="delete_me.txt"/>
<property name="Type" value="DELETE"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

4.5.11.4 大きいCSVソース・ファイルの使用

サイズが1GBの大きいCSVファイルをソース・ディレクトリで使用するシナリオを想定します。その場合は、次の手順を実行する必要があります。

1. CSVをXMLに変換します。

2. 結果として生じたXMLをXSLを使用して変換します。

3. 変換操作で生じたファイルを固定長ファイルに変換します。

この使用例は、BPELサンプル・ディレクトリのFlatStructureサンプルと似ています。相違点は、1つのファイルI/O相互作用で3つの手順が発生することです。

注意:

3つの手順はすべて、1つのファイルI/O相互作用で発生します。これは、データ・ファイル内のすべてのレコードが同じタイプに属している場合にのみ該当します。

大きいCSVファイルを使用して前述のシナリオに記載された操作を実行するには、次の手順を実行します。

1. address-csv.xsdファイルとaddress-fixedLength.xsdファイルを、FlatStructureサンプルからプロジェクトのxsdディレクトリにコピーします。

2. FlatStructureサンプルからプロジェクトのxslディレクトリにaddr1Toaddr2.xslをコピーします。

3. 次の例に示すように、ファイルI/O相互作用を構成します。高レベルでは、次の例に示すように、ソース・ディレクトリとターゲット・ディレクトリまたはファイルの詳細とともにソース・スキーマ、ターゲット・スキーマおよびXSLを相互作用仕様で指定する必要があります。

例 - ファイルI/O相互作用

<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="SourceSchema" value="xsd/address-csv.xsd"/>
<property name="SourceSchemaRoot value="Root-Element"/>
<property name="SourceType" value="native"/>
<property name="TargetPhysicalDirectory" value="foo2"/>
<property name="TargetFileName" value="bar2"/>
<property name="TargetSchema" value="xsd/address-fixedLength.xsd"/>
<property name="TargetSchemaRoot value="Root-Element"/>
<property name="TargetType" value="native"/>
<property name="Xsl value="xsl/addr1Toaddr2.xsl"/>
<property name="Type" value="MOVE"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

次の追加のパラメータが指定されました。

- SourceSchema: ソース・スキーマの相対パス。

- SourceSchemaRoot: ソース・スキーマのルート要素。

- SourceType: データのタイプ。使用可能な他の値はXMLです。

- TargetSchema: ターゲット・スキーマの相対パス。

- TargetSchemaRoot: ターゲット・スキーマのルート要素。

- TargetType: データのタイプ。使用可能な他の値はXMLです。

- Xsl: XSLファイルの相対パス。

4.5.11.5 あるリモート・ディレクトリから同じFTPサーバーの別のリモート・ディレクトリへのファイルの移動

I/Oの使用例は、使用例とよく似ています。ただし、注意が必要な微妙な相違点がいくつかあります。

この使用例では、同じディレクトリ内にファイルを移動しますが、これは、同じサーバー上での名前の変更操作に似ています。ほとんどのFTPサーバーは、FTPサーバーでのファイルの名前変更を行うRNFR/RNTOのFTPコマンドをサポートしています。

ただし、RNFR/RNTOコマンドをサポートしていない場合でも、バインディング・プロパティUseNativeRenameOperationを使用すれば同じディレクトリ内にファイルを移動できます。デフォルトでは、このプロパティはTRUEに設定されています。その場合は、ネイティブのRNFR/RNTOコマンドが使用されます。ただし、このプロパティをFALSEに設定すると、移動操作をエミュレートするためにGetコマンドとPutコマンド、さらにDeleteコマンドが使用されます。

ウィザードで実行できるのはこの手順の一部のみです。これは、該当するアダプタ構成ウィザードが使用可能でないためです。生成したJCAファイルを手動で構成することにより、残りの手順を完了してください。

リモート・ディレクトリから同じFTPサーバーの別のリモート・ディレクトリにファイルを移動するには、次の手順を実行します。

1. 空のBPELプロセスを作成します。

2. 「コンポーネント」ウィンドウから「外部参照」スイムレーンにFTPアダプタをドラッグ・アンド・ドロップします。「アダプタ構成ウィザード - ようこそ」ページが表示されます。

3. 「Next」をクリックします。「サービス名」ページが表示されます。

4. 「サービス名」フィールドにサービス名を入力します。

5. 「Next」をクリックします。「アダプタ・インタフェース」ページが表示されます。

6. 「Next」をクリックします。「FTPサーバー接続」ページが表示されます。

7. FTPサーバーのJNDI名を入力して「次へ」をクリックします。「操作」ページが表示されます。

8. 「同期Get File」を選択し、「操作名」フィールドにFTPMoveと入力して「次へ」をクリックします。「ファイル・ディレクトリ」ページが表示されます。

注意:

同期Get Fileを選択したのは、この操作の結果として生成されるWSDLファイルが、I/O操作に必要なファイルと同様のものであるためです。

9. 着信ファイル用のディレクトリのダミー物理パスを入力し、「次へ」をクリックします。「ファイル名」ページが表示されます。

注意:

このダミー・ディレクトリは使用されません。以降の手順でこのディレクトリを手動で変更する必要があります。

10. ダミー・ファイル名を入力し、「次へ」をクリックします。「ファイル名」ページが表示されます。

注意:

入力したダミー・ファイル名は使用されません。以降の手順でこのファイル名を手動で変更する必要があります。

11. 「Next」をクリックします。「メッセージ」ページが表示されます。

12. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。

13. 「終了」をクリックします。これで、アウトバウンドの構成は完了です。

14. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFTPMove内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。BPELコンポーネントがアウトバウンド・サービスに接続されます。

15. 「ファイル」、「すべて保存」を順番にクリックします。

16. 先ほど作成したFTPMoveサービスのinvokeアクティビティを作成します。
次の手順では、生成したWSDLファイルをFTPMoveサービス用に変更し、移動操作の新規の相互作用仕様で構成します。

17. 次の例に示すように、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があります。

18. 次の手順を実行して、実際のディレクトリ名とファイル名をソース・ファイルとターゲット・ファイルのパラメータにマッピングします。

a. 適切な名前を付けた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>

b. 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に移動または名前変更されます。

注意:

この例では、ソースおよびターゲットの詳細がハードコードされています。これらの詳細は、ランタイム・パラメータとして指定することもできます。

c. これらのパラメータをヘッダーとして起動操作に渡します。これらの変数値によって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>

19. 最後に、最初の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>

4.5.11.6 ファイルシステムのローカル・ディレクトリからFTPサーバーのリモート・ディレクトリへのファイルの移動

この使用例の手順は「あるリモート・ディレクトリから同じ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に設定されているためです。

4.5.11.7 FTPサーバーのリモート・ディレクトリからファイルシステムのローカル・ディレクトリへのファイルの移動

この使用例の手順は「ファイルシステムのローカル・ディレクトリから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に設定されているためです。

4.5.11.8 あるFTPサーバーから別のFTPサーバーへのファイルの移動

あるFTPサーバーから別のFTPサーバーにファイルを移動するには、次の項に記載されている使用例を順に実行する必要があります。

1. 「FTPサーバーのリモート・ディレクトリからファイルシステムのローカル・ディレクトリへのファイルの移動」: ローカル・ディレクトリから別のFTPサーバーにファイルをアップロード

2. 「ファイルシステムのローカル・ディレクトリからFTPサーバーのリモート・ディレクトリへのファイルの移動」: FTPサーバーからローカル・ディレクトリにファイルをダウンロード

4.5.12 ファイル・アダプタを使用した同期BPELコンポジットの作成

デフォルトでは、テクノロジ・アダプタを使用すると、JDeveloperアダプタ・ウィザードによって非同期WSDLが生成されます。通常、11gでアダプタ・シナリオを作成する場合は、次の手順に従います。

1. 「BPELを使用するコンポジット」または「空のコンポジット」を選択して、SOAアプリケーションを作成します。「空のコンポジット」を選択した場合は、「サービス・コンポーネント」ペインから「SOAコンポジット・エディタ」にBPELプロセスをドロップする必要があります。

図4-176 に示す画面が表示されたら、この画面でプロセス詳細を入力します。テンプレートとして「サービスを後で定義」を選択する必要があります。

図4-176 プロセス作成画面

2. 次に、インバウンド・サービスおよびアウトバウンド参照を作成し、それらをBPELコンポーネントと接続します。

図4-177 インバウンド・サービスおよびアウトバウンド参照の作成

3. 最後に、ペイロード取得用の開始<receive>アクティビティおよびペイロード書込み用の<invoke>アクティビティを含むBPELプロセスを作成します。

図4-178 receiveアクティビティとinvokeアクティビティ

アダプタを使用するほとんどのBPELプロセスは、この方法でモデル化されます。生成されたWSDLは一方向的であることを示しており、これによりBPELプロセスは非同期的になります。

図4-179 生成された一方向WSDL

つまり、インバウンド・ファイル・アダプタによりディレクトリ内のファイルをポーリングし、そこで見つかった各ファイルについて、コンテンツをXMLに変換してBPELにパブリッシュします。

ただし、BPELプロセスが非同期的であるため、ファイル・アダプタがパブリッシュ後すぐに戻されて、必要な後処理、たとえば、データの削除やアーカイブが実行されます。

このような非同期BPELプロセスの短所は、インバウンド・アダプタの調整が難しくなる点です。つまり、ダウンストリームのビジネス・プロセスで処理が完了するのを待機せずに、インバウンド・アダプタによってBPELにメッセージが送信され続けます。この結果、メモリー使用量の増加やCPU使用率の上昇などの問題が発生する可能性があります。

これらの問題の発生を抑制するため、WSDLおよびBPELのアーティファクトを同期プロセスに手動で変更できます。同期BPELプロセスに変更したら、インバウンド・ファイル・アダプタでは、次のファイルまたはメッセージを処理する前に<reply>でダウンストリーム・プロセスによる処理が完了するまで強制的に待機するようになり、結果的にファイル・アダプタが自動的に調整されます。

図4-180 に示されている、変更されたWSDLを参照してください。ここでは、一方向のWSDLを双方向のWSDLに変換することによって、WSDLを同期的にしています。

図4-180 双方向のWSDLに変更された非同期WSDL

次のステップでは、次の例のように、BPELプロセスの最後にあるインバウンド・アダプタのパートナ・リンクに<reply>アクティビティを追加します。

図4-181 インバウンド・アダプタへのReplyの指定

最終的なプロセスは図4-182 のようになります。

図4-182 ReceiveおよびReply BPELアクティビティを含む同期ファイル・アダプタ・プロセス

デフォルトではメディエータのルーティング・ルールは順次であるため、このタイプの作業はメディエータでは不要です。つまり、メディエータでは、ルーティング・ルールの処理にコール元のスレッド(インバウンド・ファイル・アダプタのスレッド)が使用されます。メディエータのWSDLが一方向でもこれは当てはまります。

4.5.12.1 FTPアダプタでのコネクション・ファクトリJNDIの動的な変更

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を使用する必要があります。

図4-185 予約済JCAヘッダー・プロパティjca.jndiの使用

動的パートナ・リンクを使用する場合は、次の点に注意する必要があります。

- コネクション・ファクトリをSOAサーバー上に事前構成する必要があります。BPELの例では、シナリオのデプロイ前に、FtpAdapterのWebLogic Serverデプロイメント・ディスクリプタでeis/Ftp/FtpAdater1およびeis/Ftp/FtpAdater2の両方を構成する必要があります。

- 動的パートナ・リンクはアウトバウンド起動にのみ適用可能です。

4.5.12.2 アウトバウンド書込み操作からのファイルの詳細の取得

ファイル・アダプタ構成ウィザードには「出力ヘッダーの追加」というオプションがあり、リクエスト/レスポンス操作で出力ヘッダーを取得できます。

4.5.13 ファイル/FTPアダプタの順序付け方法の変更

ファイル/FTPアダプタでは、順序番号を使用するようにアウトバウンド書込みを構成できます。たとえば、address-data_%SEQ%.txtをFileNamingConventionとして選択すると、すべてのファイルがaddress-data_1.txt、address-data_2.txtなどとして生成されます。

図4-186を参照してください。

図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を参照してください。

図4-188 SequenceNameプロパティの追加

デハイドレーション・サポートとしてDB2またはMS SQL Serverを使用するシナリオは、若干異なります。DB2では順序がネイティブでサポートされていますが、MS SQL Serverではサポートされていません。

DB2の場合、アダプタ・ランタイムは固有に生成された順序を使用しますが、MSSQL Serverの場合、アダプタは製品に付属のストアド・プロシージャを利用します。

SOA Suiteでデハイドレーション・ストアとしてDB2を実行する場合と同じ結果を得るには、JCAファイル内のコネクション・ファクトリのJNDI名をeis/HAFileAdapterDB2に変更します。

デハイドレーション・ストアとしてMSSQLを実行する場合と同じ結果を得るには、eis/HAFileAdapterMSSQLを使用します。

図4-189 に示すように、製品に付属しているストアド・プロシージャ以外のストアド・プロシージャを使用するには、バインディング・プロパティを使用してアダプタの動作をオーバーライドする必要があり、具体的にはストアド・プロシージャを使用するようにアダプタに指示する必要があります。

図4-189 ストアド・プロシージャを使用するようにアダプタに指示

ファイル/FTPアダプタを追加モードで使用する場合、アダプタ・ランタイムによってmutexの機能が下げられてペシミスティック・ロックが使用され、異なるノードのライターによって同じファイルに対して同時に追加が実行されないようになります。

4.5.14 ファイルの処理順序の制御

ファイル/FTPアダプタでは、ファイルを処理する順序を制御できます。たとえば、ファイルの変更時刻、ファイル・サイズまたは他の決定要素の順序で、ファイルを処理する必要がある場合があります。

ファイル/FTPアダプタでは、インバウンド・ファイル/FTPアダプタ・サービスのJCAファイルでFileSorter属性を定義することによって、ファイルを処理する順序を制御できます。図4-190を参照してください。

図4-190 ファイル・ソーターの指定

ファイル/FTPアダプタには、次の例に示す、最終変更時刻を使用する2つの事前定義済のソーターが備わっています。

図4-191 事前定義済ソーターの使用

ただし、ソート順序を自分で定義することが必要な場合もあります。このためには、Java Comparatorを実装し、それをファイル・アダプタに登録できます。これを行うには、次の手順を実行します。

1. Comparatorを記述します。たとえば、FileSizeSorter Comparatorでは、ファイルがファイル・サイズの降順でソートされます。図4-192を参照してください。

図4-192 FileSorterSize Comparator

2. このクラスをコンパイルするには、fileAdapter.jarをクラスパスに配置する必要があります。[FMW_HOME]/AS11gR1SOA/soa/connectorsから、たとえばjar xvf FileAdapter.rarを実行してFileAdapter.rarを展開し、fileAdapter.jarを抽出します。FileSizeSorter.javaクラスをコンパイルするには、次の例のようにfileAdapter.jarをクラスパスに配置する必要があります。

setenv CLASSPATH fileAdapter.jar
javac -d .FileSizeSorter.java

3. コンパイルの後、次の例のようにクラスをその独自のjarファイルにバンドルします。

jar cvf fileadapter-sorter.jar file

4. 次の例のように、fileadapter-sorter.jarをFileAdapter.rarにバンドルします。

jar uvf FileAdapter.rar fileadapter-sorter.jar

この手順は、FileAdapter.rarをロードするClassLoaderからfileadapter-sorter.jarが見えるようにするために必要です。fileadapter-sorter.jarおよびfileadapter.jarを[DOMAIN_HOME]/libにコピーする方法など、他の方法を使用することもできますが、前述の例が最も単純かつ簡単です。

5. JCAファイルでSingleThreadModelをtrueとして設定します(この項の最初の画像を参照してください)。

6. BPELを使用している場合は、同期プロセスをモデル化していることを確認します。

4.5.15 FTPアダプタの拡張

現在の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アダプタによってこの機能が実装されます。

4.5.15.1 FTP/ファイル・アダプタの拡張の使用例

ファイル/FTPアダプタ拡張の使用例は4セットあります。

- FTPクライアント・ログインのFTPアダプタ拡張

- MLSDコマンドに対するレスポンスを処理するためのFTPアダプタの構成

- LISTコマンドではなくMLSDコマンドを送信するためのリスティング操作の拡張

- MVSプラットフォームで実行されているFTPサーバーに追加の固有FTPコマンドを送信するための格納操作の拡張

4.5.15.2 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アダプタのコネクション・ファクトリ内にクラス名を構成する必要があります。

4.5.15.2.1 FTPClient実装の拡張によるlogin()のオーバーライド

次の手順を実行して、FTPクライアントを拡張します。

1. fileftp.jarを作成します。これは1回のアクティビティであり、コンパイルのみに必要です。fileftp.jarの作成方法については、「Manifest.MFファイルを使用したコンパイル用のfileftp.jarの生成」を参照してください。

2. 次の例に示すように、(前の手順で作成した) fileftp.jarをクラスパスに追加します。

set CLASSPATH=$ORACLE_SOA_HOME/soa/modules/oracle.soa.adapter_11.1.1/fileftp.jar

3. MyFtpClient.javaを作成します。login()メソッドをオーバーライドしてACCTコマンドのサポートを追加する方法は、「FTPClient実装のサンプル」を参照してください。

4. MyFTPClient.javaをコンパイルします。

javac -d . MyFTPClient.java

コンパイル後、jarとしてパッケージ化します(例: myftpclient.jar)。

jar cvf myftpclient.jar << compile folder>>

5. myftpclient.jarを$FMW_HOME/soa/soa/modules/oracle.adapter.ext_12.1.2にコピーします

cp myftpclient.jar $FMW_HOME/soa/soa/modules/oracle.adapter.ext_12.1.2

6. antを実行して、myftpclient.jarをアダプタ・クラスパスに追加します。

ant

7. FTPアダプタのWebLogicデプロイメント・ディスクリプタ内にコネクション・ファクトリ・エントリFtpClientClass="com.acme.MyFTPClient"を設定します。

これにより、FTPアダプタはデフォルトのFTPClientではなくMyFTPClientを使用できます。

8. サーバーを再起動します。

4.5.15.3 MLSDコマンドに対するレスポンスを処理するための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

4.5.15.3.1 MLSDの拡張

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サーバーのみでサポートされています。

4.5.15.3.2 MLSDコマンドをサポートするためのプラグイン実装の構成

MLSDコマンドをサポートするために、FtpListResponseParserおよびFtpTimestampParserのプラグイン実装を使用できます(「FtpTimestampParserインタフェース」を参照)。これを行うには、次の手順を実行します。

1. fileftp.jarを作成します。これは1回のアクティビティであり、コンパイルのみに必要です。fileftp.jarの作成の詳細は、「Manifest.MFファイルを使用したコンパイル用のfileftp.jarの生成」を参照してください。

2. たとえば、次のようにfileftp.jarをクラスパスに追加します。set CLASSPATH=$ORACLE_SOA_HOME/soa/modules/oracle.soa.adapter_11.1.1/fileftp.jar (ステップ1で作成したjar)

3. MLSDListResponseParserImpl.javaを作成します。MLSD FTPコマンドに対するレスポンスを解析するパーサーの実装の詳細は、「FtpListResponseParserインタフェース」を参照してください。

4. MLSDTimestampParserImpl.javaを作成します。MLSDのレスポンスに基づいて最終変更時刻を解析するパーサーの実装の詳細は、「FtpTimestampParserインタフェース」を参照してください

5. 2つのクラスをコンパイルし、jarとして(たとえば、my_ftpextension.jarとして)パッケージ化します。コンパイルが失敗した場合、fileftp.jarがクラスパスに存在していることを確認してください。

javac -d . MLSDListResponseParserImpl.java
javac -d . MLSDTimestampParserImpl.java
jar cvf my_ftpextension.jar <<compile folder>>

6. my_ftpextension.jarを$FMW_HOME/soa/soa/modules/oracle.adapter.ext_12.1.2にコピーします

cp my_ftpextension.jar $FMW_HOME/soa/soa/modules/oracle.adapter.ext_12.1.2

7. antを実行して、myftpclient.jarをアダプタ・クラスパスに追加します。

8. コネクション・ファクトリ・エントリlistParserKey ="com.acme.MLSDListResponseParserImp"をFTPアダプタのWebLogicデプロイメント・ディスクリプタに設定して、新しいパーサーをポイントします。

9. コネクション・ファクトリ・エントリtimeParserKey ="com.acme. MLSDTimestampParserImpl"を、FTPアダプタのWebLogicデプロイメント・ディスクリプタに追加します。

10. サーバーを再起動します

ほとんどの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に設定する必要があります。

4.5.15.3.3 LISTコマンドではなくMLSDコマンドを送信するためのリスティング操作の拡張

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>

4.5.15.4 MVSプラットフォームで実行されているFTPサーバーに追加の固有FTPコマンドを送信するための格納操作の拡張

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>

4.5.15.5 その他の構成パラメータ、実装、インタフェースおよびスキーマ

FTPアダプタを拡張する際に使用できるその他の構成パラメータは、次のとおりです。

- FtpMappingFile
これは、インバウンド相互作用とアウトバウンド相互作用のどちらのjcaファイル内にも指定できます。これにより、コンポジット・アプリケーションを基準にしたマッピング・ファイルの相対パスが格納されます。「ftpmappingスキーマ」に、ftpmappingスキーマの例を示します。

インバウンド操作とアウトバウンド操作の両方で、同じマッピング・ファイルを使用してください。

たとえば、<property name="FtpMappingFile" value="xsd/ftp_mapping.xml"/>は、マッピング・ファイルがコンポジット・アプリケーションのxsdフォルダに存在していることを意味します。

- ftpClientClass
これは、FTPアダプタのデプロイメント・ディスクリプタ内にコネクション・ファクトリ・パラメータとして指定できます。独自のFTPClient実装を指定する場合は、ここにその実装の完全修飾クラス名を挿入します。

- listParserKey
これは、FTPアダプタのデプロイメント・ディスクリプタ内にコネクション・ファクトリ・パラメータとして指定できます。独自のFtpListResponseParser実装を指定する場合は、ここにその実装の完全修飾クラス名を挿入します。

- timeParserKey
これは、FTPアダプタのデプロイメント・ディスクリプタ内にコネクション・ファクトリ・パラメータとして指定できます。

独自のFtpTimestampParser実装を指定する場合は、ここにその実装の完全修飾クラス名を挿入します。

4.5.15.5.1 FTPClient実装のサンプル

次に、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);
}
}

4.5.15.6 FtpListResponseParserインタフェース

次の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;
}

4.5.15.7 FtpTimestampParserインタフェース

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;
}
}

4.5.15.8 ftpmappingスキーマ

次の例に、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" />

4.5.15.8.1 Manifest.MFファイルを使用したコンパイル用のfileftp.jarの生成

示されている内容で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を含めるには、次の手順を実行します。

1. fileAdapter.jarおよびftpAdapter.jarを、それぞれ次の場所から抽出します

$fmwhome/soa/soa/connectors/FileAdapter.rarおよび$fmwhome/soa/soa/connectors/FTPAdapter.rar

2. これらのファイルを$fmwhome/soa/soa/modules/oracle.soa.adapter_11.1.1にコピーします。

3. 作成したMANIFEST.MFを同じフォルダにコピーします。

jar cmf fileftp.jar MANIFEST.MF

4. 生成されたfileftp.jarをコンパイルに使用します。

4.5.15.8.2 ListParserおよびTimeParserのサンプル

次の例に、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;
}

5 Oracle JCA Adapter for Sockets

この章では、外部サービスとしてOracle BPEL Process Manager (Oracle BPEL PM)およびOracle Mediator (メディエータ)で動作する、Oracle JCA Adapter for Sockets (Oracleソケット・アダプタ)の使用方法について説明します。

この章の内容は次のとおりです。

- Oracleソケット・アダプタの概要

- Oracleソケット・アダプタの機能

- 概念

- 構成

- 使用例

5.1 Oracleソケット・アダプタの概要

Oracleソケット・アダプタはJCA 1.5準拠のアダプタであり、TCP/IPソケットを介した通信用の標準または非標準プロトコルのモデル化に使用されます。Oracleソケット・アダプタを使用すると、クライアントまたはサーバー・ソケットの作成や、接続の確立が可能です。テキストまたはバイナリのデータを転送できます。

この項には次のトピックが含まれます:

- Oracleソケット・アダプタのアーキテクチャ

- Oracleソケット・アダプタとメディエータの統合

- Oracleソケット・アダプタとOracle BPEL PMの統合

- Oracleソケット・アダプタとSOAコンポジットの統合

5.1.1 アーキテクチャ

JCA 1.5アーキテクチャに基づいています。JCAでは、異機種間のエンタープライズ情報システム(EIS)の統合に標準アーキテクチャを提供します。CAバインディング・コンポーネントでは、基盤となるJCA相互作用がOracle BPEL PM統合のサービス(JCAバインディングを使用したWSDL)として公開されています。図5-1では、アーキテクチャを示しています。Oracle JCAアダプタのアーキテクチャの詳細は、「アーキテクチャ」を参照してください。

図5-1 アーキテクチャ

5.1.1.1 ソケット・アダプタのメッセージ拒否および再発行は使用されない

ソケット・アダプタは、他のJCAアダプタに適用可能なメッセージ拒否および再試行機能をサポートしていません。

ダウンストリーム・アダプタから例外が発生した場合は通常、サーバー・ソケットに接続するクライアント・ソケット・アプリケーションがエラー処理を実行します。ソケット・アダプタでのメッセージ拒否はサポートされていないため、ソケット・アダプタではthExaltessage再発行機能は使用されません。

5.1.2 メディエータとの統合

自動的にメディエータと統合されます。JDeveloperデザイナで作成すると、アダプタ構成ウィザードが起動します。このウィザードで構成できます。構成が完了すると、Oracle JDeveloper (JDeveloper)の「アプリケーション・ナビゲータ」セクションに同じ名前のWSDLファイルが作成されます。このWSDLファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。

アダプタ構成ウィザードの「操作タイプ」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。

Oracle JCAアダプタとメディエータの統合の詳細は、「アダプタとOracle Fusion Middlewareの統合」を参照してください。

5.1.3 Oracle BPEL PMとの統合

自動的にOracle BPEL PMと統合されます。「コンポーネント」ウィンドウから「ソケット・アダプタ」をドラッグ・アンド・ドロップすると、図5-2に示すように、アダプタ構成ウィザードが起動して「ようこそ」ページが表示されます。

図5-2 「アダプタ構成ウィザード - ようこそ」ページ

このウィザードで構成できます。アダプタ構成ウィザードでは、図5-3 に示すように、サービス名の入力を求められます。

図5-3 「アダプタ構成ウィザード - サービス名」ページ

構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションに同じ名前のWSDLファイルが作成されます。このWSDLファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。

アダプタ構成ウィザードの「操作タイプ」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。

Oracle JCAアダプタとOracle BPEL PMの統合の詳細は、「アダプタとOracle Fusion Middlewareの統合」を参照してください。

5.1.4 SOAコンポジットとの統合

コンポジットは、設計されて単一アプリケーションにデプロイされるサービス、サービス・コンポーネント(Oracle BPEL PMおよびメディエータ)、ワイヤおよび参照のアセンブリです。コンポジットにより、メッセージに記述された情報が処理されます。コンポジットの詳細は、composite.xmlファイルに格納されます。SOAコンポジットとの統合の詳細は、「Oracle SOAコンポジットとアダプタの統合」を参照してください。

5.2 機能

使用すると、TCP/IPソケットを介してデータの読取りおよび書込みをするようにBPELプロセスまたはメディエータ・サービスを構成できます。次の特徴があります。

- TCP/IPソケットを介した通信用の標準または非標準プロトコルのモデル化が可能

- インバウンドとアウトバウンドの両方の通信をサポート

- 複雑なプロトコル・ハンドシェイクをXSLで宣言的にモデル化可能

- プロトコル・ハンドシェイクのモデル化にカスタムJavaコードのプラグインを選択可能

- アダプタがトランスレータ・インフラストラクチャ(NXSD)と統合されているため、ソケットを介したネイティブ・データの読取りおよび書込みをサポート

- 複数のキャラクタ・エンコーディングをサポート

5.3 概念

この項では、次の概念について説明します。

- 通信モード

- プロトコル定義メカニズム

- キャラクタ・エンコーディングとバイト順

- パフォーマンス・チューニング

5.3.1 通信モード

ソケットを介したインバウンドおよびアウトバウンドの通信(単方向または双方向)をサポートしています。通信モードは、次の各項で説明します。

- インバウンド同期リクエスト/レスポンス

- アウトバウンド同期リクエスト/レスポンス

- インバウンド受信

- アウトバウンド起動

5.3.1.1 インバウンド同期リクエスト/レスポンス

インバウンド起動の一環として、サーバー・ソケットを開き、着信接続を待機します。アダプタではサーバー・ソケットへの接続を使用し、リクエスト・メッセージを読み取ります。このメッセージはBPELまたはメディエータにパブリッシュされます。次に、同じ接続を使用してレスポンスを同期的に返信します。

図5-4 に、インバウンド同期リクエスト/レスポンスのシナリオを示します。

図5-4 インバウンド同期リクエスト/レスポンスのBPELシナリオ

5.3.1.2 アウトバウンド同期リクエスト/レスポンス

アウトバウンド同期リクエスト/レスポンスの場合、リクエストはBPELまたはメディエータから行われます。サーバー・ソケットに接続し、リクエスト・メッセージをサーバー・ソケットに出力ストリームで送信します。次に、サーバー・ソケットからのレスポンスを入力ストリームでブロックし、レスポンスをBPELまたはメディエータに返信します。

図5-5 に、アウトバウンド同期リクエスト/レスポンスのシナリオを示します。

図5-5 アウトバウンド同期リクエスト/レスポンスのBPELシナリオ

5.3.1.3 インバウンド受信

インバウンド起動の一環として、サーバー・ソケットを開き、着信接続を待機します。アダプタではサーバー・ソケットへの接続を使用し、リクエスト・メッセージを読み取ります。このメッセージはBPELまたはメディエータにパブリッシュされます。このシナリオでは、リプライは送信されません。

5.3.1.4 アウトバウンド起動

アウトバウンドの一方向の起動シナリオの場合、リクエストはBPELまたはメディエータから送信されます。サーバー・ソケットに接続し、リプライを期待せずに、リクエスト・メッセージをサーバー・ソケットに出力ストリームで送信します。

5.3.2 プロトコル定義メカニズム

通信プロトコルまたはハンドシェイクは、認証手順、確認、状況に応じたデータの送受信など、異なる個別のステップで構成されます。プロトコル・ハンドシェイクを定義する次のメカニズムをサポートします。

- スタイルシートを使用したハンドシェイク・メカニズムを持つプロトコル

- カスタムJavaコードを使用したハンドシェイク・メカニズムを持つプロトコル

- ハンドシェイク・メカニズムを持たないプロトコル

5.3.2.1 スタイルシートを使用したハンドシェイク・メカニズムを持つプロトコル

アダプタによって公開されるXPath拡張関数を使用するスタイルシートで定義される、ハンドシェイク・メカニズムで設計されたプロトコルを使用するように構成できます。ソケットのI/Oストリーム上、またはストリームの最後までの細かい読取りおよび書込み操作が可能です。これらの関数によって、データの読取りおよび書込みにネイティブ・フォーマットの構成メンバーを使用することも可能になります。このハンドシェイク・メカニズムでは、XSLT構成メンバーを使用して割当て、検証、制御フローなどの操作を定義します。

XPath拡張関数はトランスレータ・インフラストラクチャで次のように使用できます。

- NXSDフレームワークで公開されるStyleReaderを使用して、次のメソッドでソケット・ストリームからの読取りおよび書込みを行います。

- socketRead(nxsdStyle:String, nxsdStyleAttributes:String):String
このメソッドを、ソケットの入力ストリームからの読取りに使用できます。

- socketWrite(value:String, nxsdStyle:String, nxsdStyleAttributes:String):String
このメソッドを、ソケットの出力ストリームへの書込みに使用できます。

図5-6 に示すXSLTは、StyleReaderを使用する拡張関数の使用方法を示しています。

図5-6 StyleReaderを使用する拡張関数を利用したXSLT

- 入力および出力変数を定義するスキーマに注釈を付け、NXSD構成メンバーを使用して、次のメソッドでソケット・ストリームからの読取りおよび書込みを行います。

- socketReadWithXlation():DocumentFragment
このメソッドを、入力用に構成されたスキーマおよびスキーマ要素を使用した、ソケットの入力ストリームからの読取りに使用できます。

- socketWriteWithXlation(xml:NodeList)
このメソッドを、出力用に構成されたスキーマを使用した、ソケットの出力ストリームへの書込みに使用できます。

図5-7 に示すXSDファイルは、NXSD構成メンバーを使用して、入力および出力変数を定義するスキーマに注釈を付け、拡張関数の使用方法を示しています。

図5-7 StyleReaderを使用しない拡張関数を利用したXSD

スタイルシートを使用してハンドシェイクを定義するには、図5-8 に示すように、「プロトコル」ページで「XSLTを使用してハンドシェイクを定義します」を選択し、参照してXSLファイルを選択する必要があります。

図5-8 スタイルシートを使用したハンドシェイク・メカニズムを持つプロトコルの定義

5.3.2.2 カスタムJavaコードを使用したハンドシェイク・メカニズムを持つプロトコル

カスタムJavaコードのプラグインによって定義される、カスタマイズされたハンドシェイク・メカニズムを持つプロトコルを使用するように構成できます。このカスタムJavaコードは、ICustomParserインタフェースoracle.tip.pc.services.translation.util.ICustomParserを実装する必要があります。このインタフェースは提供され、ハンドシェイクのカスタム実装を可能にします。

注意:

ICustomParserインタフェース・ファイルは、bpm-infra.jarファイル内にあります。このjarファイルは、次のディレクトリにあります。

$SOA_ORACLE_HOME/soa/modules/oracle.soa.fabric_11.1.1

該当する通信パラダイムに基づき、次のメソッドを実装する必要があります。

- public Element executeOutbound(InputStream in, OutputStream out, Element payLoad) throws Exception;
アウトバウンド・ハンドシェイクはこのメソッドを実装する必要があります。

例:

public Element executeOutbound(InputStream in, OutputStream out, Element payLoad) throws Exception {
BufferedReader in1 = new BufferedReader(new InputStreamReader(in));
PrintWriter out1 = new PrintWriter(new OutputStreamWriter(out));

out1.println(payLoad.getFirstChild().getNodeValue());

String retVal = in1.readLine();

StringBuffer strBuf = new StringBuffer();
strBuf.append("<?xml version='1.0' encoding='" + enc + "' ?>"
+ "<out xmlns='http://xmlns.oracle.com/EchoServer/'>");
strBuf.append(retVal + "</out>");

DOMParser parser = new DOMParser();
parser.setValidationMode(DOMParser.NONVALIDATING);
Element elem = (Element) parser.getDocument().getElementsByTagName(
"out").item(0);

return elem;
}

- public Element executeInboundRequest(InputStream in) throws Exception;
インバウンド・リクエストはこのメソッドを実装する必要があります。

例:

public Element executeInboundRequest(InputStream in) throws Exception {
BufferedReader in1 = new BufferedReader(new InputStreamReader(in));

String input = in1.readLine();

StringBuffer strBuf = new StringBuffer();
strBuf.append("<?xml version='1.0' encoding='" + enc + "' ?>"
+ "<EchoClientProcessRequest xmlns='http://xmlns.oracle.com/EchoClient'>");

strBuf.append("<input>" + input + "</input></EchoClientProcessRequest>");

DOMParser parser = new DOMParser();
parser.setValidationMode(DOMParser.NONVALIDATING);
parser.parse(new InputSource(new StringReader(strBuf.toString())));
Element elem = (Element) parser.getDocument().getElementsByTagName(
"EchoClientProcessRequest").item(0);

return elem;
}

- public void executeInboundReply(Element payLoad, OutputStream out) throws Exception;
インバウンド・リプライはこのメソッドを実装する必要があります。

例:

public void executeInboundReply(Element payLoad, OutputStream out) throws Exception {
PrintWriter out1 = new PrintWriter(new OutputStreamWriter(out));

NodeList list = payLoad.getChildNodes();
String retVal = null;
for(int i = 0; i < list.getLength(); i++) {
Node node = list.item(i);
NodeList list1 = node.getChildNodes();
for(int j = 0; j < list1.getLength(); j++) {
Node node1 = list1.item(j);
if(node1.getNodeType() == Node.TEXT_NODE) {
retVal = node1.getNodeValue();
}
}
}
out1.println(retVal);
out1.flush();
}

注意:

inはソケットの入力ストリームへのハンドルで、outはソケットの出力ストリームへのハンドルです。

カスタムJavaコードを使用してハンドシェイクを定義するには、図5-9 に示すように、「カスタムJavaコードを使用してハンドシェイクを定義します」を選択し、「Javaクラス」フィールドでハンドシェイクを実装するJavaクラスを指定する必要があります。

図5-9 カスタムJavaコードを使用したハンドシェイク・メカニズムを持つプロトコルの定義

5.3.2.3 ハンドシェイク・メカニズムを持たないプロトコル

ソケットのI/Oストリームとの間の変換に関連するハンドシェイクを必要としないプロトコルを使用するように構成できます。

ハンドシェイクを必要としないプロトコルを使用するには、図5-10 に示すように、「プロトコル」ページで「ハンドシェイクなし」を選択する必要があります。

図5-10 ハンドシェイク・メカニズムを持たないプロトコルの定義

5.3.3 キャラクタ・エンコーディングとバイト順

「エンコーディング」プロパティはネイティブ・データの格納に使用されるキャラクタ・エンコーディングを表し、「バイト順」プロパティはネイティブ・データのバイト順(BIG_ENDIANまたはLITTLE_ENDIAN)です。

キャラクタ・エンコーディングとバイト順は、ネイティブ・フォーマット・ビルダー・ウィザードを使用してスキーマ・ファイル(NXSD)内で指定できます。また、使用するエンコーディングとバイト順をアダプタ構成ウィザードで指定することもできます。エンコーディングとバイト順を指定しない場合、デフォルト値はUS-ASCIIとBIG_ENDIANです。

変換を使用する場合にのみ適用可能なエンコーディングとバイト順の値を指定するには、アダプタ構成ウィザードの「プロトコル」ページで次の手順を実行する必要があります。

1. 図5-11 に示すように、「プロトコル」ページの「エンコーディング/バイト順」セクションで「エンコーディング/バイト順の指定」オプションを選択します。

図5-11 「アダプタ構成ウィザード - プロトコル」ページ

2. 次のいずれかのタスクを実行してエンコーディングを設定します。

a. スキーマ・ファイルで指定されたエンコーディングを使用するには、「エンコーディング」の選択を解除したままにします。

b. アダプタ構成ウィザードを使用してエンコーディングを指定するには、「エンコーディング」を選択し、「エンコーディング」リストからエンコーディング・タイプを選択します。

注意:

「エンコーディング」を選択した場合、アダプタ構成ウィザードを使用して指定したエンコーディング・タイプがNXSDファイル内で指定されているエンコーディング・タイプよりも優先されます。

3. 次のいずれかのタスクを実行してバイト順を設定します。

a. スキーマ・ファイルで指定したバイト順を使用するには、「スキーマからバイト順の値を使用します」を選択します。

b. アダプタ構成ウィザードを使用してバイト順を指定するには、「バイト順」を選択し、「バイト順」リストからバイト順を選択します。

4. 「終了」をクリックします。「終了」をクリックした後で、構成ウィザードに、ソケット・アダプタの構成が完了したことを示すページが表示されます。

5.3.4 パフォーマンス・チューニング

次のパフォーマンス・チューニング機能がサポートされています。

- 接続プーリングの構成

詳細は、「Oracle JCAアダプタ・チューニング・ガイド」および「Oracle JCAアダプタのプロパティ」を参照してください。

5.3.4.1 接続プーリングの構成

パフォーマンスを最適化する方法の1つとして、接続プールの使用があります。接続先のソケット・サーバーが相互作用のたびにソケットを閉じないかぎり、接続プールを使用できます。接続プールを使用すると、ソケット接続を繰り返し使用でき、相互作用のたびに新規のソケットを作成するオーバーヘッドを回避できます。接続プールは、Oracle WebLogic Serverコンソールを使用して構成する必要があります。

注意:

接続プール機能は、アウトバウンドの対話にのみ適用できます。

5.3.4.1.1 Oracleソケット・アダプタの接続プーリングの構成方法

1. Oracle WebLogic Serverコンソールにログインします。このコンソールにアクセスするには、http://servername:portnumber/consoleにアクセスします。

2. 「ドメイン構造」の左ペインで「デプロイメント」をクリックします。「デプロイメントのサマリー」ページが表示されます。

図5-12 Oracle WebLogic Serverコンソール - 「デプロイメントの概要」ページ

3. SocketAdapterをクリックします。「SocketAdapterの設定」ページが表示されます。

4. 「構成」タブをクリックします。

5. 「アウトバウンド接続プール」タブをクリックし、javax.resource.cci.ConnectionFactoryを開いて図5-13 に示すように構成済のコネクション・ファクトリを表示します。

図5-13 Oracle WebLogic Serverコンソール - 「SocketAdapterの設定」ページ

6. 「eis/socket/SocketAdapter」をクリックします。javax.resource.cci.ConnectionFactoryの設定ページが表示されます。

7. 図5-14 に示すように、KeepAliveコネクション・ファクトリのプロパティをtrueに設定します。接続プール機能が有効になります。

図5-14 Oracle WebLogic Serverコンソール - 「javax.resource.cci.ConnectionFactoryの設定」ページ

8. 「保存」をクリックします。図5-15 に示すように、メッセージ「デプロイメント・プランが正常に更新されました。」を含む「javax.resource.cci.ConnectionFactoryの設定」ページが表示されます。

図5-15 Oracle WebLogic Serverコンソール - 「javax.resource.cci.ConnectionFactoryの設定」ページ

注意:

接続プール・パラメータは、Oracle WebLogic Server管理コンソールの「接続プール」タブを使用して変更できます。

5.4 構成

構成するには、次のタスクを実行する必要があります。

- weblogic-ra.xmlファイルの変更

- ハンドシェイクのモデル化

- XSLマッパー・ツールを使用したXSLファイルの設計

- Oracleソケット・アダプタの構成プランでのTCPポートの指定

5.4.1 weblogic-ra.xmlファイルの変更

構成するには、表5-1にリストされているプロパティの値をweblogic-ra.xmlファイルに指定する必要があります。これらのプロパティはOracle WebLogic Server管理コンソールから更新できます。詳細は、「アダプタ・コネクション・ファクトリの追加」を参照してください。

表5-1 構成プロパティ

プロパティ

説明

Host

アウトバウンド相互作用の場合は、ソケット・サーバーが実行されていて、接続先となるシステム名。インバウンド相互作用の場合は、常にlocalhostです。

Port

アウトバウンド相互作用の場合は、ソケット・サーバーが実行されていて、アダプタの接続先となるポート番号です。インバウンド相互作用の場合は、着信接続をソケット・アダプタがリスニングするポート番号です。

Timeout

この値がゼロ以外のタイムアウト間隔に設定されている場合、このソケットに関連付けられているInputStreamに対するread()コールは、このプロパティで指定された時間のみブロックされます。タイムアウト間隔に達すると、ソケットはまだ有効であっても、java.net.SocketTimeoutExceptionが発生します。このオプションは、ブロック操作が有効になる前に有効にする必要があります。タイムアウト間隔は0より大きい値を指定する必要があります。タイムアウト間隔に0を指定すると、無限タイムアウトと解釈されます。値はミリ秒単位です。

KeepAlive

アウトバウンド相互作用の場合にのみ適用可能。接続プール機能を使用するには、trueに設定する必要があります。

BacklogQueue

インバウンド相互作用の場合に適用可能。この値は、着信接続指示(接続リクエスト)の最大キュー長さを示します。キューが一杯のときに接続指示が到着すると、接続は拒否されます。

注意:

Oracleリリース11gからリリース12gにアップグレードすると、ServerSocketを作成する際の動作が変更されます。このため、hostnameがlocalhostとして構成されていると、リモート・クライアントはServerSocketに接続できなくなる可能性があります。回避策として、localhostをhostnameに変更してください。

サンプルのweblogic-ra.xmlファイルを次に示します。

<wls:connection-instance>
<wls:description>Socket Adapter</wls:description>
<wls:jndi-name>eis/socket/SocketAdapter</wls:jndi-name>
<wls:connection-properties>
<wls:pool-params>
<wls:initial-capacity>0</wls:initial-capacity>
<wls:max-capacity>200</wls:max-capacity>
<wls:capacity-increment>5</wls:capacity-increment>
<wls:shrinking-enabled>true</wls:shrinking-enabled>

<wls:shrink-frequency-seconds>60</wls:shrink-frequency-seconds>

<wls:connection-creation-retry-frequency-seconds>2</wls:connection-creation-retry
-frequency-seconds>

<wls:connection-reserve-timeout-seconds>5</wls:connection-reserve-timeout-seconds>

<wls:match-connections-supported>true</wls:match-connections-supported>
<wls:use-first-available>true</wls:use-first-available>
</wls:pool-params>

<wls:transaction-support>NoTransaction</wls:transaction-support>

<wls:reauthentication-support>true</wls:reauthentication-support>
<wls:properties>
<wls:property>
<wls:name>Host</wls:name>
<wls:value>localhost</wls:value>
</wls:property>
<wls:property>
<wls:name>Port</wls:name>
<wls:value>12110</wls:value>
</wls:property>
<wls:property>
<wls:name>Timeout</wls:name>
<wls:value>10000</wls:value>
</wls:property>
<wls:property>
<wls:name>BacklogQueue</wls:name>
<wls:value>0</wls:value>
</wls:property>
<wls:property>
<wls:name>KeepAlive</wls:name>
<wls:value>True</wls:value>
</wls:property>
</wls:properties>
<wls:res-auth>Application</wls:res-auth>
</wls:connection-properties>
</wls:connection-instance>

注意:

接続プーリングを設定するには、KeepAliveプロパティをtrueに設定する必要があります。

5.4.2 ハンドシェイクのモデル化

クライアントまたはサーバー・ソケットと接続をネゴシエートするには、ハンドシェイクが必要な場合があります。

5.4.2.1 アウトバウンド・ハンドシェイクのモデル化

アウトバウンドXSLTでは、起動されたメッセージに対応する入力を使用します。アウトバウンドXSLTでは、拡張関数を使用してソケットの出力ストリームに書き込みます。この出力は、単方向通信ではダミーであり、双方向通信ではレスポンスになります。

次の例は、同期リクエスト/レスポンス通信パラダイムのモデル化を示しています。

<xsl:stylesheet
...
xmlns:socket="http://www.oracle.com/XSL/Transform/java/oracle.tip.adapter.socket.ProtocolTranslator" />
xmlns:request="http://www.TragetNameSpace.com/Request" >

<xsl:template match="/">

<!–- Write the entire content of "books" element using translator -->
<xsl:variable name="username" select="socket:socketWriteWithXlation(.)" />

<!–- Read the stream using translator -->
<xsl:copy-of select="socket:socketReadWithXlation()" />

</xsl:template>
</xsl:stylesheet>

5.4.2.2 インバウンド・ハンドシェイクのモデル化

インバウンドXSLTでは、ダミー入力を使用し、拡張関数を通じてソケットの入力ストリームを読み取り、パブリッシュするXMLレコードを作成します。

次の例は、クライアントが、カンマ(,)で終了するユーザーIDとセミコロン(;)で終了するパスワードを検証用に送信してから、メッセージ・ペイロードを送信するハンドシェイクを示しています。

<xsl:stylesheet
...
xmlns:socket="http://www.oracle.com/XSL/Transform/java/oracle.tip.adapter.socket.ProtocolTranslator" />
<xsl:template match="/">
<!-- Read the user name -->
<xsl:variable name="username"
select="socket:socketRead('terminated','terminatedBy=,')" />
<!-- Read password if user name is correct -->
<xsl:if test="normalize-space($username)='user'">
<xsl:variable name="password"
select="socket:socketRead('terminated','terminatedBy=;')" />
<!-- If password is correct proceed to read the payload using translator
-->
<xsl:if test="normalize-space($password)='password'">
<!--  Send an OK -->
<xsl:variable name="ack1" select="socket:socketWrite('001','','')" />

<output>
<!--  Wait for the payload -->
<xsl:copy-of select="socket:socketReadWithXlation()" />
</output>

</xsl:if>
<!--  Send an error -->
<xsl:else><xsl:variable name="ack2"
select="socket:socketWrite('000','','')" /></xsl:else>
</xsl:if>
</xsl:template>
</xsl:stylesheet>

5.4.3 XSLマッパー・ツールを使用したXSLファイルの設計

XSLマッパー・ツールを使用してXSLファイルを設計できます。次の各項では、様々な通信シナリオに使用するXSLの設計手順について説明します。

- インバウンド同期リクエスト/リプライに使用するXSLの設計

- アウトバウンド同期リクエスト/リプライに使用するXSLの設計

5.4.3.1 インバウンド同期リクエスト/リプライに使用するXSLの設計

この項では、XSLマッパー・ツールを使用してインバウンド同期リクエスト/リプライのシナリオのXSLを設計する手順について説明します。

注意:

この使用例を実行するには、Adapters-101SocketAdapterHelloWorldサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/HelloWorld.xsd

Oracle SOA Sample CodeサイトでAdapters-101SocketAdapterHelloWorldサンプルにアクセスできます。

このファイルをHelloWorldCompositeプロジェクトのHelloWorldComposite\xsdフォルダにコピーします。

5.4.3.1.1 SOAコンポジットの設計

SOAコンポジットを設計するには、「SOAコンポジットの設計」で説明する手順を実行します。

注意:

「SOAコンポジットの設計」の手順は、Oracle BPEL PMを使用するコンポジットに適用可能です。または、メディエータでコンポジットを作成することもできます。

5.4.3.1.2 インバウンドOracleソケット・アダプタの作成

インバウンド・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント・パレット」から、「ソケット・アダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「Next」をクリックします。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにサービス名としてHelloWorldを入力して「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

4. 図5-16 に示すように、「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

図5-16 「アダプタ構成ウィザード - アダプタ・インタフェース」ページ

5. 「操作タイプ」として「インバウンド同期リクエスト/リプライ」を選択し、「次へ」をクリックします。「ソケット接続」ページが表示されます。

6. 図5-17 に示すように、「ソケット接続JNDI名」フィールドにeis/socket/InboundSocketAdapterと入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

図5-17 「アダプタ構成ウィザード - ソケット接続」ページ

7. 「メッセージ・スキーマのリクエスト」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

8. 図5-18 に示すように、「プロジェクトのスキーマ・ファイル」、「HelloWorld.xsd」および「HelloWorldProcessRequest」を順番にクリックします。

図5-18 「タイプ・チューザ」ダイアログ

9. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにHelloWorld.xsdファイルが移入されます。

10. 「メッセージ・スキーマのリプライ」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」、「HelloWorld.xsd」および「HelloWorldProcessResponse」を順番にクリックします。

12. 「OK」をクリックします。図5-19 に示すように、「メッセージ」ページの「URL」フィールドにHelloWorld.xsdファイルが移入されます。

図5-19 「アダプタ構成ウィザード - メッセージ」ページ

13. 「Next」をクリックします。図5-20 に示すように、「プロトコル」ページが表示されます。

図5-20 「アダプタ構成ウィザード - プロトコル」ページ

14. 「XSLTを使用してハンドシェイクを定義します」を選択します。

15. 「XSLT」フィールドの端に表示される「新規XSLファイルを作成します」アイコンをクリックします。図5-21 に示すように、「入力」ダイアログが表示されます。

図5-21 「プロトコル」ページの「入力」ダイアログ

16. 図5-21 に示すように、XSLファイル名としてデフォルト値のrequest.xslを使用し、「OK」をクリックします。

17. 「ReplyXslt」フィールドの端に表示される「新規XSLファイルを作成します」アイコンをクリックします。「入力」ダイアログが表示されます。

18. XSLファイル名としてデフォルト値のreply.xslを使用し、「OK」をクリックします。

19. 「終了」をクリックします。request.xslおよびreply.xslファイルが作成されます。
図5-22 に、「request.xsl」ページを示します。

図5-22 JDeveloper - 「request.xsl」ページ

注意:

「request.xsl」ページの左側にある「ソース」ペインにはdummy.xsdファイルが表示され、これがXSLマッパー・ツールのソースとして使用されます。

インバウンド・リクエスト・シナリオの場合、ソケットが受信するネイティブ・データを読み取ってXMLフォーマットに変換します。つまり、ソース側にXMLファイルはありません。XSLTマッパーは常にソースおよびターゲットXSDファイルを必要とするため、マッパー・ツールにはダミーのXSDファイルが表示されます。

図5-23 に、「reply.xsl」ページを示します。

図5-23 JDeveloper - 「reply.xsl」ページ

注意:

「reply.xsl」ページの右側にあるターゲット・ペインには、dummy.xsdファイルが表示されます。このdummy.xsdファイルは、XSLマッパー・ツールのターゲットとして使用されます。

20. インバウンド同期リクエスト/リプライ操作のリクエスト部分を次の手順で定義します。

a. 図5-24 に示すように、「request.xsl」ページで、「コンポーネント・パレット」の「Advanced Functions」リストからsocketReadを中央ペインにドラッグ・アンド・ドロップします。

図5-24 JDeveloper - 「request.xsl」ページ

b. socketRead拡張関数をダブルクリックします。「関数の編集 - socketRead」ダイアログが表示されます。

c. 図5-25 に示すように、「nxsdStyle」および「nxsdStyleAttributes」フィールドに関数パラメータを入力します。

図5-25 「関数の編集 - socketRead」ダイアログ

注意:

socketRead関数は、NXSDフレームワークで公開されているStyleReaderを使用してソケットの入力ストリームから読み取ります。

d. 「OK」をクリックします。「request.xsl」(XSLマッパー・ツール)ページが表示されます。

e. 中央ペインにあるsockRead関数を、右ペインにあるターゲットinputノードにリンクします。図5-26 に示すように、XSLマッピングを示すrequest.xsl (XSLマッパー・ツール)が表示されます。

図5-26 JDeveloper - 「request.xsl」ページ

21. インバウンド同期リクエスト/リプライ操作のリプライ部分を次の手順で定義します。

a. 「コンポーネント」ウィンドウのリストから「拡張」を選択し、「拡張関数」を選択します。拡張関数のリストが表示されます。

b. 「reply.xsl」ページで、「コンポーネント」ウィンドウの「拡張関数」リストからsocketWriteを中央ペインにドラッグ・アンド・ドロップします。

c. socketWrite拡張関数をダブルクリックします。「関数の編集 - socketWrite」ダイアログが表示されます。

d. 図5-27 に示すように、「valueToWrite」、「nxsdStyle」および「nxsdStyleAttributes」フィールドに関数パラメータを入力します。

図5-27 「関数の編集 - socketWrite」ダイアログ

注意:

socketWrite関数は、NXSDフレームワークで公開されているStyleReaderを使用してソケットの出力ストリームに書き込みます。

e. 「OK」をクリックします。「reply.xsl」(XSLマッパー・ツール)ページが表示されます。

f. 中央ペインにあるsockWrite関数を、右ペインにあるターゲットinputノードにリンクします。図5-28 に示すように、XSLマッピングを示すreply.xsl (XSLマッパー・ツール)が表示されます。

図5-28 JDeveloper - 「reply.xsl」ページ

22. 「ファイル」、「すべて保存」を順番にクリックします。インバウンドのrequest.xslおよびreply.xslファイルが作成されます。

5.4.3.2 アウトバウンド同期リクエスト/リプライに使用するXSLの設計

この項では、XSLマッパー・ツールを使用してアウトバウンド同期リクエスト/リプライのシナリオのXSLを設計する手順について説明します。

注意:

この使用例を実行するには、Adapters-101SocketAdapterHelloWorldサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/HellowWorld.xsd

Oracle SOA Sample CodeサイトでAdapters-101SocketAdapterHelloWorldサンプルにアクセスできます。

HelloWorld.xsdファイルをHelloWorldCompositeプロジェクトのHelloWorldComposite\xsdにコピーします。

5.4.3.2.1 SOAコンポジットの設計

SOAコンポジットを設計するには、「SOAコンポジットの設計」で説明する手順を実行します。

注意:

「SOAコンポジットの設計」の手順は、Oracle BPEL PMを使用するコンポジットに適用可能です。または、メディエータでコンポジットを作成することもできます。

5.4.3.2.2 アウトバウンドOracleソケット・アダプタの作成

アウトバウンド参照を作成する手順は、次のとおりです。

1. 「コンポーネント・パレット」から、「ソケット・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「Next」をクリックします。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにサービス名としてHelloWorldを入力して「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

4. 図5-16 に示すように、「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

5. 「操作タイプ」として「アウトバウンド同期リクエスト/リプライ」を選択し、「次へ」をクリックします。「ソケット接続」ページが表示されます。

6. 「ソケット接続JNDI名」フィールドにeis/socket/OutboundSocketAdapterと入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

7. 「メッセージ・スキーマのリクエスト」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

8. 図5-18 に示すように、「プロジェクトのスキーマ・ファイル」、「HelloWorld.xsd」および「HelloWorldProcessRequest」を順番にクリックします。

9. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにHelloWorld.xsdファイルが移入されます。

10. 「メッセージ・スキーマのリプライ」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」、「HelloWorld.xsd」および「HelloWorldProcessResponse」を順番にクリックします。

12. 「OK」をクリックします。図5-19 に示すように、「メッセージ」ページの「URL」フィールドにHelloWorld.xsdファイルが移入されます。

13. 「Next」をクリックします。「プロトコル」ページが表示されます。

14. 「XSLTを使用してハンドシェイクを定義します」を選択します。

15. 「Xslt」フィールドの端に表示される「新規XSLファイルを作成します」アイコンをクリックします。「入力」ダイアログが表示されます。

16. XSLファイル名としてデフォルト値のinvoke.xslを使用し、「OK」をクリックします。

17. 「終了」をクリックします。図5-29 に示すように、XSLマッパー・ツールにinvoke.xslファイルが表示されます。

図5-29 JDeveloper - 「invoke.xsl」ページ

18. ターゲット側で「HelloWorldProcessResponse」要素を右クリックします。図5-30 に示すように、メニューが表示されます。

図5-30 JDeveloper - 「invoke.xsl」ページ

19. 「変数の追加」をクリックします。図5-31 に示すように、「変数の追加」ダイアログが表示されます。

図5-31 「変数の追加」ダイアログ

20. 「ローカル名」フィールドにvar1と入力して「OK」をクリックします。var1変数がXSLマッパー・ツールのターゲット・ペインに追加されます。

21. 「コンポーネント」ウィンドウのリストから「拡張」を選択し、「拡張関数」を選択します。拡張関数のリストが表示されます。

22. アウトバウンド同期リクエスト/リプライ操作のリクエスト部分を、データをソケット・サーバーに書き込むように次の手順で定義します。

a. 図5-32 に示すように、「コンポーネント」ウィンドウの「拡張関数」リストからsocketWriteWithXlationを中央ペインにドラッグ・アンド・ドロップします。

図5-32 JDeveloper - 「invoke.xsl」ページ

b. var1ノードをsocketWriteWithXlation関数にドラッグします。図5-33 に示すように、リンクが作成されます。

図5-33 JDeveloper - 「invoke.xsl」ページ

c. socketWriteWithXlation拡張関数をダブルクリックします。「関数の編集 - socketWriteWithXlation」ダイアログが表示されます。

d. 図5-34 に示すように、「NodeList」フィールドにドット1個(.)を入力します。

図5-34 「関数の編集 - socketWriteWithXlation」ダイアログ

注意:

socketWriteWithXlation関数は、出力用に構成されたスキーマを使用してソケットの出力ストリームに書き込みます。

「NodeList」フィールドで指定したドット(.)は、HelloWorldProcessRequestを最上位ノードに書き込むことを示します。

e. 「OK」をクリックします。「警告」ダイアログが表示されます。

f. 「はい」をクリックします。「invoke.xsl」ページが表示されます。同期リクエスト/リプライ操作のリクエスト部分が定義されています。

23. アウトバウンド同期リクエスト/リプライ操作のリプライ部分を次の手順で定義します。

a. 図5-35 に示すように、「コンポーネント」ウィンドウの「拡張関数」リストからsocketReadWithXlationを中央ペインにドラッグ・アンド・ドロップします。

図5-35 JDeveloper - 「invoke.xsl」ページ

b. 「コンポーネント」ウィンドウのリストから「一般」を選択し、「XSLTコンストラクト」を選択します。XSLT構成メンバーのリストが表示されます。

c. copy-ofを、「コンポーネント」ウィンドウからターゲット・ペインのHelloWorldProcessResponseにドラッグします。図5-36 に示すように、「copy-ofタイプ・ダイアログ」が表示されます。

図5-36 JDeveloper - 「copy-ofタイプ・ダイアログ」が表示されている「invoke.xsl」ページ

d. 「OK」をクリックします。図5-37 に示すように、copy-of XSLT構成メンバーがターゲット・ペインに追加された状態で「invoke.xsl」(XSLマッパー・ツール)ページが表示されます。

図5-37 JDeveloper - 「invoke.xsl」ページ

e. copy-of XSLT構成メンバーをsocketReadWithXlation関数にドラッグします。図5-38 に示すように、リンクが作成されます。

図5-38 JDeveloper - 「invoke.xsl」ページ

24. 「ファイル」、「すべて保存」を順番にクリックします。アウトバウンド同期リクエスト/リプライのハンドシェイクが定義されます。

5.4.4 Oracleソケット・アダプタの構成プランでのTCPポートの指定

Oracleソケット・アダプタの構成プランでTCPポートを指定するには、次の手順を実行します(<service-name>はサービス名です)。

1. <service-name>_tcp.jcaファイルにポート・プロパティを追加します。

<property name="Port" value="Port"/>

2. 構成プランXMLファイルに次のコードを追加します。

<service_name=<XXXXXX">
<property>
<property name="Port">
<replace>2222</replace>
</property>
<binding type'"jca"/>
</service>

3. .xmlファイルのサービス要素の下にポート・プロパティを追加し、デフォルト値(この例では1111)を指定します

<service name="XXXXX" ui:wsdlLocation
<interface.wsdl.interface="..."/>
<binding.jca config="XXXX_tcp.jca"/>
<property name="Port" type=xs:string" many="false"
override="may">1111</property>
</service>

4. 構成プランでコンポジットをデプロイします。

デプロイすると、Oracleソケット・アダプタは構成プランで指定されたポート2222でリスニングします。

構成プランなしでコンポジットをデプロイする場合、または構成プランがPortプロパティをオーバーライドしない場合、Oracle Socketアダプタはcomposite.xmlファイルのデフォルトのPortプロパティで指定されたソケット(この例ではポート1111)でリスニングします。

5.4.5 JavaScriptのサポート

ソケット・アダプタは現在、インバウンドとアウトバウンドの両方のトランザクションに対して複雑なハンドシェイクを定義する方法として、XSLTおよびカスタムJavaプラグインを使用しています。

ただし現在は、これらのトランザクションに対してハンドシェイクを定義する別の方法として、JavaScriptサポートを使用できます。この機能により、インバウンドとアウトバウンドの両方のトランザクションに対してシンプルでリクエスト-リプライのハンドシェイクを定義するためにコール可能な独自のJavaScriptを記述できます。

5.4.5.1 SOCKETアダプタ構成ウィザードによる、使用するスクリプトの定義

トランザクションのハンドシェイクを定義するには、JavaScriptを使用して次の準備を行います。

1. 「プロトコル」画面で、「Javaスクリプトを使用してハンドシェイクを定義します」を選択します。

図5-39 JavaScriptが選択されているSOCKETアダプタ構成ウィザード

2. 「終了」をクリックします。リフレッシュされた「プロトコル」画面で、スクリプトが定義されている場所を追加するか参照します。図5-40 に、リクエストとリプライのスクリプトが表示されています。画面の残りの部分は変換に使用します。

図5-40 ハンドシェイク定義のための追加選択が表示されたSOCKETアダプタ構成ウィザードの「プロトコル」画面

3. 「次へ」または「終了」をクリックします。ソケット通信の提供に役立つJavaScriptを使用したソケット・アダプタの構成が完了しました。

5.4.5.2 レポート

ソケット・アダプタXSLTおよびJavaScriptの使用例では、クライアント/サーバーのソケットと通信するための通信プロトコルを定義します。NXSDベースの使用例と比較した場合、通常はこの通信では多くのデータ転送は行われません。これらの使用例ではメッセージ・サイズを取得する意味があまりないため、ソケット・アダプタをデプロイし、Fusion Middleware Controlで提供されているスナップショット・レポート・オプションを有効化した場合、メッセージの統計は取得されません。

アダプタ・レポート統計は、NXSDとXSDの変換に対してのみ収集されることに注意してください。これらの統計は、XSLT、JavaScriptおよびカスタム・プロトコルに対してはサポートされていません。

5.4.5.3 サンプル・スクリプト

次のJavaScriptは、この機能で使用するサンプルのJavaScriptです。

importPackage(java.io);
importPackage(java.lang);
importPackage(javax.xml.parsers);

println("=====> Under Script Execution");
var inputStream = InputStreamKey;
var outputStream = OutputStreamKey;
var requestPayloadElement = RequestPayloadElementKey;
var ReplyDOMResult = ReplyDOMResultKey;

var isr = new InputStreamReader(inputStream);
var osw = new OutputStreamWriter(outputStream);
var br = new BufferedReader(isr);

println("=====> starting handshake");

var reply = doHandshake();

createDOM(reply);

function writeToServer(request) {
println("=====> Under writeToServer");
var bw = new BufferedWriter(osw);
bw.write(request);
bw.newLine();
bw.flush();
}

function doHandshake() {
println("=====> Under extractPayload ");
var nodeList = requestPayloadElement.getChildNodes();
var length = nodeList.getLength();
println("=====> Length :" +  length);
//var i = 0;
var name = "";
var empId = "";
for(var i=0 ; i < length; i++){
println("===> Name" + i + "=" + nodeList.item(i).getNodeName()); // +  "; Value=" + nodeList.item(i).getFirstChild().getNodeValue());
if(nodeList.item(i).getNodeName().indexOf("Name")!= -1){
name = nodeList.item(i).getFirstChild().getNodeValue();
}
else if(nodeList.item(i).getNodeName().indexOf("EmpId")!= -1){
empId = nodeList.item(i).getFirstChild().getNodeValue();
}
}
/*println("=====> name: "+ nodeList.item(0).getNodeName());
name = nodeList.item(0).getFirstChild().getNodeValue();

println("=====> name: "+nodeList.item(1).getNodeName());
empId = nodeList.item(1).getFirstChild().getNodeValue();*/

println("=====> name :"+name);
println("=====> empId :"+empId);

var xmlPayload = "Hello World";/*"<ns1:Inbound-Element xmlns:ns1=\"http://xmlns.oracle.com/pcbpel/demoSchema/csv\"><ns1:Name>" + name + "</ns1:Name>" +
"<ns1:EmpId>" + empId +"</ns1:EmpId></ns1:Inbound-Element>";*/
println("=====> xmlPayload :"+xmlPayload);
writeToServer(name);
writeToServer(empId);
osw.close();
var code = readFromServer();
return code;
}

function readFromServer() {
println("=====> Under readFromServer ");
var str = ""; //= br.readLine();
var tmpStr = "";
while (true){
tmpStr = br.readLine();
if(tmpStr == -1 ||  tmpStr == null)
break;
println("tmpStr=" + tmpStr);
str += tmpStr;
}

println("=====> Reply from Server :"+str);
return  str;
}

function createDOM(code){
println("=====> Under createDOM "); ;
var fRootNode = null;
var fDocument = null;
var fTempNode = null;
var NAMESPACE = "http://xmlns.oracle.com/pcbpel/demoSchema/csv";
var ROOT_NODE = "Result";
var dbf = DocumentBuilderFactory.newInstance();
var db = dbf.newDocumentBuilder();
fDocument = db.newDocument();

fRootNode = fDocument.createElementNS(NAMESPACE, ROOT_NODE);
fRootNode.appendChild(fDocument.createTextNode(code));

ReplyDOMResult.setNode(fRootNode);
}

5.4.6 ソケット・アダプタNIOのサポート

現在のソケット・アダプタでは、インバウンド接続に対して、接続ごとにスレッドのアプローチが使用されます。接続ごとにスレッドのアプローチでは、接続ごとに排他的なワーカー・スレッドを使用します。処理ループ内で、ワーカー・スレッドは新規の受信データを待機し、リクエストを処理して、レスポンス・データを返します。この動作により、相互作用が完了するまでスレッドがブロックされます。

ただし、多くの同時ユーザーがインバウンド・ソケット・アダプタを使用しているシナリオでは、オペレーティングシステム/スレッド・プールの制限に達すると、スレッドの待機が発生します。多くのスレッドに独自のメモリー・フットプリントがありますが、このため特定の場合にメモリ不足の例外が発生することがあります。

ソケット・アダプタは(新規I/O) NIO APIを使用します。NIOのAPIは、最近のオペレーティング・システムの低レベルI/O操作にアクセスできるように設計されています。

NIO APIにより、スレッド数がユーザーによる構成が可能な値にまで削減されます。これにより、システムがロードされているシナリオで、ソケット・アダプタはより優れたパフォーマンスおよびスループットを得ることができます。

ソケット・アダプタは、NXSD変換モードに対してのみNIO APIをサポートしていることに注意してください。これを他のモードでサポートしない理由は、NIOが、リクエストの後に常にリプライが続くシナリオである、固有のリクエスト-リプライ・モデルを前提としているためです。

他の変換モードでは、リクエストの後にリプライが続かないこともあります。たとえば、ソケット・サーバーが、クライアント接続を受信した後にようこそメッセージを送信するシナリオがあります。

または、複数のハンドシェイク(複数の読取りの後に書込みが続く)が存在するシナリオもあります。このようなシナリオでは、ソケット・アダプタは、最初の読取りの全データが到着したかどうかを認識しません。

アダプタは、処理中のNIOイベントに対するNIOプロセッサ・スレッド数の構成をサポートします。このプロパティのデフォルト値は1です。

プロパティNioProcessorThreadCountにデフォルト値である1以外の値を指定する場合は、適切なJCAファイルにプロパティNioProcessorThreadCountを手動で追加する必要があります。次の例では、NioProcessorThreadCountの値は2に設定されます。

例 - jcaファイル内のプロパティNioProcessorThreadCountの値の手動設定

<adapter-config name="inboundRequestReplyService" adapter="Socket Adapter" wsdlLocation="inboundRequestReplyService.wsdl"
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/socket/SocketAdapter" adapterRef=""/>
<endpoint-activation portType="InboundRequestReply_ptt" operation="InboundRequestReply"
UITransmissionPrimitive="InboundRequestReply">
<activation-spec className=
"oracle.tip.adapter.socket.SocketActivationSpec">
<property name="TransMode" value="NXSD"/>
<property name="NioProcessorThreadCount" value="2"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

スレッド数が相互作用ごとに作成される古い実装を使用する場合は、JCAファイルで次を使用します。

例 - 相互作用ごとにスレッド数を指定するサンプルjcaファイル

<adapter-config name="inboundRequestReplyService"
adapter="Socket Adapter"
wsdlLocation="inboundRequestReplyService.wsdl"
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/socket/SocketAdapter" adapterRef=""/>
<endpoint-activation portType="InboundRequestReply_ptt"
operation="InboundRequestReply"
UITransmissionPrimitive="InboundRequestReply">
<activation-spec className=
"oracle.tip.adapter.socket.SocketActivationSpec">
<property name="TransMode" value="NXSD"/>
<property name="SupportNIO" value="false"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

5.4.7 ソケット・アダプタに対するSSLのサポート

SSL (Secure Socket Layer)は、インターネット上での通信セキュリティを提供する暗号化プロトコルです。鍵交換の非対称型暗号化およびプライバシの対称型暗号化を提供し、トランスポート・レイヤーでネットワーク接続のセグメントを暗号化します。

Oracle Platform Security Service (OPSS)キーストア・サービスでは、SSL、メッセージ・セキュリティ、暗号化および関連タスク用のキーおよび証明書を管理できます。キーストア・サービスは、キー、証明書およびその他のアーティファクトを含むキーストアを作成および管理するために使用します。

KSSを使用するときにTrustStoreNameおよびTrustStoreStripeNameを指定しない場合は、ドメイン・レベル・トラスト・ストア(システム/トラスト)が使用されます。

5.4.7.1 ソケット・アダプタでのSSLのサポート

セキュア・ソケット接続を介してデータを送受信する場合は、ソケット・アダプタでSSLをサポートする必要があります。これにより、ベースとなるネットワーク・トランスポート・プロトコル上に次のようなセキュリティ保護層が追加されます。

- 整合性の保護

- 認証

- 機密性(プライバシの保護)

SSLは非NIOのシナリオでのみサポートされます。

KSSの詳細は、『Oracle® Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』のOracle Platform Security Services (OPSS)の設定方法に関する説明を参照してください。

SSLは、NXSD変換モードを使用したリクエスト-リプライ・シナリオではサポートされていません。トランスレータ(NXSDまたは不透明ペイロード用)は、ネイティブ・フォーマットからXML SSLに変換する前に、ストリームの終了を探します。ソケット・アダプタAPIではストリームの終了がサポートされないため、NXSD変換を使用したソケット・アダプタはリクエスト-リプライの使用例ではサポートされません。

表5-2 に、ソケット・アダプタSSLコネクション・ファクトリのプロパティを示します。これには、KSS (Oracle PSS)モードでSSLを構成するときのSSLコネクション・ファクトリのプロパティのリストも含まれます。

表5-2 KSSモードで構成するときのSSLコネクション・ファクトリのプロパティ

値

説明

SslEnable

コネクション・ファクトリがSSLであるかどうかを指定します。

KeyStorePassword

キーストアのパスワード。

TrustStorePassword

トラスト・ストアのパスワード。

SslProtocol

SSLプロトコルのバージョン(SSLv3)。

KeyStoreProviderName

キーストアのプロバイダ

KeyStoreType

キーストアのタイプ(=KSS)。

KeyStoreAlgorithm

キー・マネージャ・ファクトリのアルゴリズム。

TrustStoreProviderName

トラスト・ストアのプロバイダ

TrustStoreType

トラスト・ストアのタイプ(=KSS)。

TrustStoreAlgorithm

キー・マネージャ・ファクトリのアルゴリズム。

NeedClientAuthentication

クライアント認証が必須かどうかを指定します(インバウンド)。

KeyStoreStripeName

キーストアが作成されるストライプの名前。

KeyStoreStripeName

特定のストライプの下のキーストアの名前。

TrustStoreName

特定のストライプの下のトラスト・ストアの名前。

TrustStoreStripeName

トラスト・ストアが作成されるストライプの名前。

5.5 使用例

この項には、次の使用例が含まれます。

- Oracleソケット・アダプタHello World

- フライト情報表示システム

5.5.1 Oracleソケット・アダプタHello World

これは単純なHelloWorldの使用例であり、Oracleソケット・アダプタを使用した通信の同期インバウンド・リクエスト/レスポンス・モードと同期アウトバウンド・リクエスト/レスポンス・モードを示しています。HelloWorldビジネス・プロセスはOracleソケット・アダプタのインバウンド・サービスから入力文字列を取得し、メッセージをBPELプロセスにパブリッシュします。

BPELプロセスはOracleソケット・アダプタのアウトバウンド・サービス(入力文字列に接頭辞?Hello?を追加して戻す単純なHelloWorldサーバー)を起動し、同期リプライを使用して受信した文字列を戻します。

この使用例には、次の項目が含まれます。

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Oracle Enterprise Manager Fusion Middleware Controlコンソール(Fusion Middleware Controlコンソール)を使用した監視

5.5.1.1 前提条件

この使用例を実行するには、Adapters-101SocketAdapterHelloWorldサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/HelloWorld.xsd

- artifacts/xsl/request.xsl

- artifacts/xsl/reply.xsl

- artifacts/xsl/invoke.xsl

Oracle SOA Sample CodeサイトでAdapters-101SocketAdapterHelloWorldサンプルにアクセスできます。

5.5.1.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 図5-41 に示すように、「アプリケーション名」フィールドにhelloworld-socketと入力して「次へ」をクリックします。「プロジェクトの名前付け」ページが表示されます。

図5-41 「SOAアプリケーションの作成」ダイアログ

3. 「OK」をクリックします。「プロジェクトの名前付け」ダイアログが表示されます。

4. 図5-42 に示すように、「プロジェクト名」フィールドにHelloWorldCompositeと入力してから「プロジェクト・テクノロジ」の下で「SOA」を選択し、右矢印をクリックして「選択済」ボックスに移動します。

HelloWorldアプリケーションとHelloWorldCompositeプロジェクトが「アプリケーション・ナビゲータ」に表示されます。

図5-42 「プロジェクトの作成」ダイアログ

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 図5-43 に示すように、「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

図5-43 「SOA設定の構成」ダイアログ

7. 図5-44 に示すように、「名前」フィールドにHelloWorldFlowと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

図5-44 「BPELプロセスの作成」ダイアログ

8. 「OK」をクリックします。図5-45 に示すように、HelloWorldアプリケーションとHelloWorldCompositeプロジェクトが設計領域に表示されます。

図5-45 JDeveloper - composite.xml

9. HelloWorld.xsdファイルをプロジェクトのxsdディレクトリにコピーします(このファイルの場所は、「前提条件」を参照)。

10. request.xsl、reply.xslおよびinvoke.xslファイルをプロジェクトのxslディレクトリにコピーします(これらのファイルの場所は、「前提条件」を参照)。

5.5.1.3 インバウンド・サービスの作成

インバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」から、「ソケット・アダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 図5-46 に示すように、「サービス名」フィールドにHelloWorldClientと入力します。

図5-46 「アダプタ構成ウィザード - サービス名」ページ

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 図5-47 に示すように、「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

図5-47 「アダプタ構成ウィザード - アダプタ・インタフェース」ページ

6. 図5-48 に示すように、「操作タイプ」として「インバウンド同期リクエスト/リプライ」を選択します。

図5-48 「アダプタ構成ウィザード - 操作」ページ

7. 「次」を選択します。「ソケット接続」ページが表示されます。

8. 図5-49 に示すように、「ソケット接続JNDI名」フィールドにeis/socket/InboundSocketAdapterと入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

図5-49 「アダプタ構成ウィザード - ソケット接続」ページ

9. 「メッセージ・スキーマのリクエスト」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 図5-50 に示すように、「プロジェクトのスキーマ・ファイル」、「HelloWorld.xsd」および「HelloWorldProcessRequest」を順番にクリックします。

図5-50 「タイプ・チューザ」ダイアログ

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにHelloWorld.xsdファイルが移入されます。

12. 「メッセージ・スキーマのリプライ」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

13. 「プロジェクトのスキーマ・ファイル」、「HelloWorld.xsd」および「HelloWorldProcessRequest」を順番にクリックします。

14. 「OK」をクリックします。図5-51 に示すように、「メッセージ」ページの「URL」フィールドにHelloWorld.xsdファイルが移入されます。

図5-51 「アダプタ構成ウィザード - メッセージ」ページ

15. 「次」を選択します。「プロトコル」ページが表示されます。

16. 「XSLTを使用してハンドシェイクを定義します」を選択します。

17. 「Xslt」フィールドの端に表示される「参照してXSLファイルを選択します」をクリックします。「SOAリソース・ブラウザ」ダイアログが表示されます。

18. 図5-52 に示すように、ファイル名として「request.xsl」を選択して「OK」をクリックします。「Xslt」フィールドに移入が行われます。

図5-52 「SOAリソース・ブラウザ」ダイアログ

19. 「ReplyXslt」フィールドの端に表示される「参照してXSLファイルを選択します」をクリックします。「SOAリソース・ブラウザ」ダイアログが表示されます。

20. ファイル名として「reply.xsl」を選択して「OK」をクリックします。図5-53 に示すように、「Xslt」フィールドに移入が行われます。

図5-53 「アダプタ構成ウィザード - プロトコル」ページ

21. 「終了」をクリックします。「composite.xml」ページが図5-54 のように表示されます。

図5-54 JDeveloper - 「composite.xml」ページ

5.5.1.4 アウトバウンド・サービスの作成

アウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから、「ソケット・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにHelloWorldServerと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 図5-55 に示すように、「操作タイプ」として「アウトバウンド同期リクエスト/リプライ」を選択します。

図5-55 「アダプタ構成ウィザード - 操作タイプ」ページ

7. 「次」を選択します。「ソケット接続」ページが表示されます。

8. 図5-56 に示すように、「ソケット接続JNDI名」フィールドにeis/socket/OutboundSocketAdapterと入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

図5-56 「アダプタ構成ウィザード - ソケット接続」ページ

9. 「メッセージ・スキーマのリクエスト」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 図5-50 に示すように、「プロジェクトのスキーマ・ファイル」、「HelloWorld.xsd」および「HelloWorldProcessRequest」を順番にクリックします。

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにHelloWorld.xsdファイルが移入されます。

12. 「メッセージ・スキーマのリプライ」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

13. 「プロジェクトのスキーマ・ファイル」、「HelloWorld.xsd」および「HelloWorldProcessResponse」を順番にクリックします。

14. 「OK」をクリックします。図5-51 に示すように、「メッセージ」ページの「URL」フィールドにHelloWorld.xsdファイルが移入されます。

15. 「次」を選択します。「プロトコル」ページが表示されます。

16. 「XSLTを使用してハンドシェイクを定義します」を選択します。

17. 「Xslt」フィールドの端に表示される「参照してXSLファイルを選択します」をクリックします。「SOAリソース・ブラウザ」ダイアログが表示されます。

18. 図5-57 に示すように、「ファイル名」として「invoke.xsl」を選択して「OK」をクリックします。「Xslt」フィールドに移入が行われます。

図5-57 「SOAリソース・ブラウザ」ダイアログ

19. 「終了」をクリックします。「composite.xml」ページが図5-58 のように表示されます。

図5-58 JDeveloper - 「composite.xml」ページ

5.5.1.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるHelloWorldClientの小さい三角形を、「コンポーネント」領域のHelloWorldFlow BPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるHelloWorldFlow BPELプロセス内の小さい三角形を、「外部参照」領域のHelloWorldServerに緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図5-59 のように表示されます。

図5-59 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

5.5.1.5.1 receiveアクティビティの追加

1. 「HelloWorldFlow」をダブルクリックします。「BPELHelloWorld.bpel」ページが表示されます。

2. 図5-60 に示すように、「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

図5-60 JDeveloper - HelloWorldFlow.bpel

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 図5-61 に示すように、「名前」フィールドにReceiveInputと入力します。

図5-61 「Receive」ダイアログ

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 図5-62 に示すように、「HelloWorldClient」を選択して「OK」をクリックします。

図5-62 「パートナ・リンク・チューザ」ダイアログ

7. 図5-63 に示すように、「Receive」ダイアログで「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

図5-63 「Receive」ダイアログ

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。図5-64 に示すように、JDeveloperの「HelloWorldFlow.bpel」ページが表示されます。

図5-64 JDeveloper - HelloWorldFlow.bpel

5.5.1.5.2 invokeアクティビティの追加

1. 図5-65 に示すように、「コンポーネント」ウィンドウから設計領域に、receiveInputアクティビティの後にinvokeアクティビティをドラッグ・アンド・ドロップします。

図5-65 JDeveloper - HelloWorldFlow.bpel

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 図5-66 に示すように、「名前」フィールドにWriteHelloWorldと入力します。

図5-66 JDeveloper - HelloWorldFlow.bpel

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 図5-67 に示すように、「HelloWorldServer」を選択して「OK」をクリックします。

図5-67 「パートナ・リンク・チューザ」ダイアログ

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

8. 同じ手順を繰り返して出力変数を選択します。図5-68 に示すように、Invokeダイアログが表示されます。

図5-68 「Invoke」ダイアログ

9. 「OK」をクリックします。図5-69 に示すように、JDeveloperの「HelloWorldFlow.bpel」ページが表示されます。

図5-69 JDeveloper - HelloWorldFlow.bpel

5.5.1.5.3 replyアクティビティの追加

1. 図5-70 に示すように、「コンポーネント」ウィンドウから設計領域にreplyアクティビティをドラッグ・アンド・ドロップします。

図5-70 JDeveloper - HelloWorldFlow.bpel

2. replyアクティビティをダブルクリックします。「Reply」ダイアログが表示されます。

3. 「名前」フィールドにReplyと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 図5-62 に示すように、「HelloWorldClient」を選択して「OK」をクリックします。

6. 「Reply」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。図5-71 に示すように、「変数」フィールドにデフォルトの変数名が移入されます。

図5-71 「Reply」ダイアログ

8. 「OK」をクリックします。図5-72 に示すように、JDeveloperの「HelloWorldFlow.bpel」ページが表示されます。

図5-72 JDeveloper - HelloWorldFlow.bpel

5.5.1.5.4 assignアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域のreceiveアクティビティとinvokeアクティビティの間にassignアクティビティをドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「コピー操作」タブをクリックします。図5-73 に示すように、Assignダイアログが表示されます。

図5-73 「Assign」ダイアログ - 「コピー操作」タブ

4. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

5. 左ペインで、「ReceiveInput_InboundRequestReply_InputVariable」変数の下にある「ns3:input」を選択します。

6. 図5-74 に示すように、右ペインで「WriteHelloWorld_OutboundRequestReply_InputVariable」変数の下にある「ns3:input」を選択します。

図5-74 「コピー操作の作成」ダイアログ

7. 「OK」をクリックします。Assignダイアログが表示されます。

8. 「OK」をクリックします。JDeveloperの「HelloWorldFlow.bpel」ページが表示されます。

9. invokeアクティビティとreplyアクティビティの間に別のassignアクティビティを追加します。

10. assignアクティビティをダブルクリックします。

11. 「コピー操作」タブをクリックして「コピー操作」を選択します。

12. 左ペインで、「WriteHelloWorld_OutboundRequestReply_OutputVariable」の下にある「ns3:result」を選択します。

13. 右ペインで、「Reply_InboundRequestReply_OutputVariable」の下にある「ns3:result」を選択して「OK」をクリックします。

14. 「OK」をクリックします。図5-75 に示すように、JDeveloperの「HelloWorldFlow.bpel」ページが表示されます。

図5-75 JDeveloper - HelloWorldFlow.bpel

15. 「ファイル」、「すべて保存」を順番にクリックします。

5.5.1.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

5.5.1.7 Oracle Enterprise Manager Fusion Middleware Controlコンソール(Fusion Middleware Controlコンソール)を使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

3. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

4. ステップ2でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

5. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

6. ペイロード・ノードを開いてペイロード詳細を確認します。

7. プロセス・フローを表示するには、「フロー」タブをクリックします。また、アクティビティ(invoke、receiveなど)をクリックしてアクティビティ詳細を表示します。

5.5.2 フライト情報表示システム

フライト情報表示システムの使用例では、Oracleソケット・アダプタを使用してハンドシェイクを定義する際の各種モードについて説明します。フライト情報表示サーバー(FIDS)は、特定のソース(JFKまたはSFO)からのフライトに関してフライト・ステータス情報をリクエストするFIDSクライアントにより起動されます。起動したFIDSは、3つのエアライン(Airline1、Airline 2およびAirline 3)に関するフライト・データ・リクエストを起動します。次に、受信した情報を収集し、HTTPプロトコルを使用してFIDSクライアントにリプライします。

この使用例には、次の項目が含まれます。

- 前提条件

- SOAコンポジットの設計

- インバウンド・サービスの作成

- アウトバウンド・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

5.5.2.1 前提条件

この使用例を実行するには、Adapters-102SocketAdapterFlightInformationDisplaySystemサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/Airline1.xsd

- artifacts/schemas/Airline2.xsd

- artifacts/schemas/Airline3.xsd

- artifacts/schemas/FIDS.xsd

- artifacts/xsl/request.xsl

- artifacts/xsl/reply.xsl

- artifacts/xsl/invoke.xsl

Adapters-102SocketAdapterFlightInformationDisplaySystemサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

5.5.2.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにFIDSAppと入力して「次へ」をクリックします。「プロジェクトの名前付け」ページが表示されます。

3. 「OK」をクリックします。「プロジェクトの名前付け」ダイアログが表示されます。

4. 「プロジェクト名」フィールドにFIDSCompositeと入力してから「プロジェクト・テクノロジ」の下で「SOA」を選択し、右矢印をクリックして「選択済」ボックスに移動します。

FIDSAppアプリケーションとFIDSCompositeプロジェクトが「アプリケーション・ナビゲータ」に表示されます。

5. 「次」を選択します。「SOA設定の構成」ダイアログが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

7. 「名前」フィールドにBPEL_FIDSと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。図5-76 に示すように、FIDSAppアプリケーションとFIDSCompositeプロジェクトが設計領域に表示されます。

図5-76 JDeveloper - composite.xml

9. Airline1.xsd、Airline2.xsd、Airline3.xsdおよびFIDS.xsdファイルをプロジェクトFIDSCompositeのFIDSComposite\xsdにコピーします(これらのファイルの場所は、「前提条件」を参照)。

10. invoke.xsl、request.xslおよびreply.xslをプロジェクトFIDSCompositeのFIDSComposite\xslにコピーします(これらのファイルの場所は、「前提条件」を参照)。

5.5.2.3 インバウンド・サービスの作成

次の手順を実行し、FIDSAppアプリケーションの公開に使用するインバウンド・サービスを作成します。

1. 「コンポーネント」から、「ソケット・アダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにFIDSと入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「操作タイプ」として「インバウンド同期リクエスト/リプライ」を選択します。

7. 「次」を選択します。「ソケット接続」ページが表示されます。

8. 図5-77 に示すように、「ソケット接続JNDI名」フィールドにeis/socket/InboundSocketAdapterと入力し、「ホストおよびポートの指定」を選択します。

図5-77 「アダプタ構成ウィザード - ソケット接続」ページ

9. 「ポート番号」フィールドに9000と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

10. 「メッセージ・スキーマのリクエスト」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 図5-78 に示すように、「プロジェクトのスキーマ・ファイル」、「FIDS.xsd」および「FIDSProcessRequest」を順番にクリックします。

図5-78 「タイプ・チューザ」ダイアログ

12. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにFIDS.xsdファイルが移入されます。

13. 「メッセージ・スキーマのリプライ」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

14. 「プロジェクトのスキーマ・ファイル」、「FIDS.xsd」および「FIDSProcessReply」を順番にクリックします。

15. 「OK」をクリックします。図5-79 に示すように、「メッセージ」ページの「URL」フィールドにFIDS.xsdファイルが移入されます。

図5-79 「アダプタ構成ウィザード - メッセージ」ページ

16. 「次」を選択します。「プロトコル」ページが表示されます。

17. 「XSLTを使用してハンドシェイクを定義します」を選択します。

18. 「Xslt」フィールドの端に表示される「参照してXSLファイルを選択します」アイコンをクリックします。「SOAリソース・ブラウザ」ダイアログが表示されます。

19. ファイル名として「request.xsl」を選択して「OK」をクリックします。「Xslt」フィールドに移入が行われます。

20. 「ReplyXslt」フィールドの端に表示される「参照してXSLファイルを選択します」アイコンをクリックします。「SOAリソース・ブラウザ」ダイアログが表示されます。

21. ファイル名として「reply.xsl」を選択して「OK」をクリックします。図5-80 に示すように、「Xslt」フィールドに移入が行われます。

図5-80 「アダプタ構成ウィザード - プロトコル」ページ

22. 「終了」をクリックします。「composite.xml」ページが図5-81 のように表示されます。

図5-81 JDeveloper - 「composite.xml」ページ

5.5.2.4 アウトバウンド・サービスの作成

次の手順に従って、Airline1サーバー・ソケットのアウトバウンド・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「ソケット・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「Next」をクリックします。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにAirline1と入力します。

4. 「Next」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「操作タイプ」として「アウトバウンド同期リクエスト/リプライ」を選択します。

7. 「Next」をクリックします。「ソケット接続」ページが表示されます。

8. 図5-82 に示すように、「ソケット接続JNDI名」フィールドにeis/socket/OutboundSocketAdapterと入力し、「ホストおよびポートの指定」を選択します。

図5-82 「アダプタ構成ウィザード - ソケット接続」ページ

9. 「ホスト名」フィールドにAirline1ソケット・サーバー・プログラムを実行する必要のあるシステムの名前を入力し、「ポート番号」フィールドに9001と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

10. 「メッセージ・スキーマのリクエスト」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」、「Airline1.xsd」および「Source」を順番にクリックします。

12. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにAirline1.xsdファイルが移入されます。

13. 「メッセージ・スキーマのリプライ」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

14. 「プロジェクトのスキーマ・ファイル」、「Airline1.xsd」および「Flight-Details」を順番にクリックします。

15. 「OK」をクリックします。図5-83 に示すように、「メッセージ」ページの「URL」フィールドにAirline1.xsdファイルが移入されます。

図5-83 「アダプタ構成ウィザード - メッセージ」ページ

16. 「Next」をクリックします。「プロトコル」ページが表示されます。

17. 「XSLTを使用してハンドシェイクを定義します」を選択します。

18. 「Xslt」フィールドの端に表示される「参照してXSLファイルを選択します」をクリックします。「SOAリソース・ブラウザ」ダイアログが表示されます。

19. 図5-84 に示すように、「ファイル名」として「invoke.xsl」を選択して「OK」をクリックします。「Xslt」フィールドに移入が行われます。

図5-84 「SOAリソース・ブラウザ」ダイアログ

20. 「終了」をクリックします。「composite.xml」ページが図5-85 のように表示されます。

図5-85 JDeveloper - 「composite.xml」ページ

次の手順に従って、Airline2サーバー・ソケットのアウトバウンド・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「ソケット・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「Next」をクリックします。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにAirline2と入力します。

4. 「Next」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「操作タイプ」として「アウトバウンド同期リクエスト/リプライ」を選択します。

7. 「Next」をクリックします。「ソケット接続」ページが表示されます。

8. 「ソケット接続JNDI名」フィールドにeis/socket/OutboundSocketAdapterと入力して「ホストおよびポートの指定」を選択します。

9. 「ホスト名」フィールドにAirline2ソケット・サーバー・プログラムを実行するシステムの名前を入力し、「ポート番号」フィールドに9002と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

10. 「メッセージ・スキーマのリクエスト」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」、「Airline2.xsd」および「Source」を順番にクリックします。

12. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにAirline2.xsdファイルが移入されます。

13. 「メッセージ・スキーマのリプライ」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

14. 「プロジェクトのスキーマ・ファイル」、「Airline2.xsd」および「flight-details」を順番にクリックします。

15. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにAirline2.xsdファイルが移入されます。

16. 「Next」をクリックします。「プロトコル」ページが表示されます。

17. 「ハンドシェイクなし」を選択します。

18. 「終了」をクリックします。「composite.xml」ページが図5-86 のように表示されます。

図5-86 JDeveloper - 「composite.xml」ページ

次の手順に従って、Airline3サーバー・ソケットのアウトバウンド・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「ソケット・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにAirline3と入力します。

4. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

6. 「操作タイプ」として「アウトバウンド同期リクエスト/リプライ」を選択します。

7. 「次」を選択します。「ソケット接続」ページが表示されます。

8. 「ソケット接続JNDI名」フィールドにeis/socket/OutboundSocketAdapterと入力して「ホストおよびポートの指定」を選択します。

9. 「ホスト名」フィールドにAirline3ソケット・サーバー・プログラムを実行するシステムの名前を入力し、「ポート番号」フィールドに9003と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

10. 「メッセージ・スキーマのリクエスト」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」、「Airline3.xsd」および「src」を順番にクリックします。

12. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにAirline3.xsdファイルが移入されます。

13. 「メッセージ・スキーマのリプライ」ボックスの「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

14. 「プロジェクトのスキーマ・ファイル」、「Airline3.xsd」および「airline」を順番にクリックします。

15. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにAirline3.xsdファイルが移入されます。

16. 「次」を選択します。「プロトコル」ページが表示されます。

17. 「カスタムJavaコードを使用してハンドシェイクを定義します」を選択します。

18. 「Javaクラス」フィールドにcom.oracle.socket.fids.custom.Airline3Customと入力します。

19. 「終了」をクリックします。「composite.xml」ページが図5-87 のように表示されます。

図5-87 JDeveloper - 「composite.xml」ページ

5.5.2.5 サービスとアクティビティのワイヤリング

作成したコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるFIDSクライアント内の小さい三角形を、「コンポーネント」領域のBPEL_FIDSプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPEL_FIDSプロセス内の小さい三角形を、「外部参照」領域のAirline1、Airline2およびAirline3サーバー内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlファイルが図5-88 のように表示されます。

図5-88 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

5.5.2.5.1 receiveアクティビティの追加

1. 「BPEL_FIDS」をダブルクリックします。「BPELFIDS.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドでデフォルト名のReceive_1を保持します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 図5-89 に示すように、「FIDS」を選択して「OK」をクリックします。

図5-89 「パートナ・リンク・チューザ」ダイアログ

7. 図5-90 に示すように、「Receive」ダイアログで「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

図5-90 「Receive」ダイアログ

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。図5-91 に示すように、JDeveloperの「BPEL_FIDS.bpel」ページが表示されます。

図5-91 JDeveloper - BPEL_FIDS.bpel

5.5.2.5.2 replyアクティビティの追加

1. 図5-92 に示すように、「コンポーネント」ウィンドウから設計領域にreplyアクティビティをドラッグ・アンド・ドロップします。

図5-92 JDeveloper - BPEL_FIDS.bpel

2. replyアクティビティをダブルクリックします。「Reply」ダイアログが表示されます。

3. 「名前」フィールドでデフォルト名のReply_1を保持します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 図5-89 に示すように、「FIDS」を選択して「OK」をクリックします。

6. 「Reply」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。図5-93 に示すように、「変数」フィールドにデフォルトの変数名が移入されます。

図5-93 「Reply」ダイアログ

8. 「OK」をクリックします。図5-94 に示すように、JDeveloperの「BPEL_FIDS.bpel」ページが表示されます。

図5-94 JDeveloper - BPEL_FIDS.bpel

5.5.2.5.3 flowアクティビティの追加

1. 図5-95 に示すように、設計領域で、receiveアクティビティとreplyアクティビティの間に「コンポーネント」ウィンドウからflowアクティビティをドラッグ・アンド・ドロップします。

図5-95 JDeveloper - BPEL_FIDS.bpel

2. Flow_1アクティビティを開きます。シーケンスの作成画面が表示されます。

5.5.2.5.4 Airline1サーバーのフローの設計

1. 図5-96 に示すように、「コンポーネント」ウィンドウからSequence_1にswitchアクティビティをドラッグ・アンド・ドロップします。

図5-96 JDeveloper - 「BPEL_FIDS.bpel」ページ

2. switchアクティビティを開きます。これにより、<case>および<otherwise>の値を入力するための画面が表示されます。

3. 図5-97 に示すように、「<case>」セクションで「条件式の表示」アイコンをクリックします。「条件式」ポップアップ・ウィンドウが表示されます。

図5-97 JDeveloper - 「BPEL_FIDS.bpel」ページ

4. ポップアップ・ウィンドウ内で「XPath式ビルダー」アイコンをクリックします。「式ビルダー」ダイアログが表示されます。

5. 図5-98 に示すように、式としてboolean(bpws:getVariableData('Receive_1_InboundRequestReply_InputVariable','FIDSProcessRequest','/ns5:FIDSProcessRequest/ns5:AirlineName')='Airline1')と入力し、「OK」をクリックします。
画面が「条件式」ポップアップ・ウィンドウに戻ります。

注意:

この式により、Airline1の情報がリクエストされた場合にのみ、このフローが確実に実行されます。

図5-98 「式ビルダー」ダイアログ

6. 「<case>」セクションにinvokeアクティビティを追加します。

a. invokeアクティビティを「<case>」セクションにドラッグ・アンド・ドロップします。

b. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

c. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

d. 「Airline1」を選択して「OK」をクリックします。

e. 「Invoke」ダイアログで、「入力」および「出力」変数フィールドの右にある「入力変数の自動作成」および「出力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

f. デフォルトの変数名を選択して「OK」をクリックします。「変数」フィールドにデフォルトの変数名が移入されます。「Invoke」ダイアログが表示されます。

g. 「OK」をクリックします。図5-99 に示すように、JDeveloperの「BPEL_FIDS.bpel」ページが表示されます。

図5-99 JDeveloper - BPEL_FIDS.bpel

7. 「<case>」セクションにassignアクティビティを追加します。

a. <case>セクションで、Invoke_1アクティビティの前に「コンポーネント」ウィンドウからassignアクティビティをドラッグ・アンド・ドロップします。

b. Assign_1アクティビティをダブルクリックします。Assignダイアログが表示されます。

c. 「コピー操作」タブをクリックします。Assignダイアログが表示されます。

d. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

e. 図5-100 に示すように、Receive_1アクティビティの入力変数のソースとInvoke_1アクティビティの入力変数のソースの間にコピー操作を作成します。

図5-100 「コピー操作の作成」ダイアログ

f. ダイアログで「OK」をクリックします。「コピー操作の作成」ダイアログが表示されます。

g. 「OK」をクリックします。

図5-101 に示すように、「BPEL_FIDS.bpel」ページが表示されます。

図5-101 JDeveloper - BPELFIDS.bpel

8. 「<case>」セクションにtransformアクティビティを追加します。

a. transformアクティビティを「<case>」セクションのInvoke_1アクティビティの後にドラッグ・アンド・ドロップします。

b. transformアクティビティをダブルクリックします。

c. 「トランスフォーメーション」タブをクリックします。

d. 「作成... (Alt + N)」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

e. 「ソース変数」リストから「Invoke_1_OutboundRequestReply_OutputVariable」を選択し、「OK」をクリックします。

f. 「ターゲット変数」リストから「Reply_1_InboundRequestReply_OutputVariable」を選択します。

g. 「OK」をクリックします。XSLマッパー・ツールが表示されます。

h. 左ペインのソースから、「tns:Flight」ノードを右ペインにあるターゲットの「FlightDetails」ノードにリンクします。「自動マップ・プリファレンス」ダイアログが表示されます。

i. 「OK」をクリックします。図5-102 に示すように、「Transformation_1.xsl」(XSLマッパー・ツール)が表示されます。

図5-102 JDeveloper - 「Transformation_1.xsl」ページ

9. 「ファイル」、「すべて保存」を順番にクリックします。図5-103 に示すように、Airline1サーバーのフローが定義された状態で「BPEL_FIDS.bpel」ページが表示されます。

図5-103 JDeveloper - BPEL_FIDS.bpel

5.5.2.5.5 Airline2サーバーのフローの設計

1. 空のsequenceアクティビティをダブルクリックし、「名前」フィールドにSequence_2と入力します。

2. 「コンポーネント」ウィンドウからSequence_2にswitchアクティビティをドラッグ・アンド・ドロップします。

3. switchアクティビティを開きます。これにより、<case>および<otherwise>の値を入力するための画面が表示されます。

4. 「<case>」セクションで「条件式の表示」アイコンをクリックします。「条件式」ポップアップ・ウィンドウが表示されます。

5. ポップアップ・ウィンドウ内で「XPath式ビルダー」アイコンをクリックします。「式ビルダー」ダイアログが表示されます。

6. 式としてboolean(bpws:getVariableData('Receive_1_InboundRequestReply_InputVariable','FIDSProcessRequest','/ns5:FIDSProcessRequest/ns5:AirlineName')='Airline2')と入力し、「OK」をクリックします。画面が「条件式」ポップアップ・ウィンドウに戻ります。

注意:

この式により、Airline2の情報がリクエストされた場合にのみ、このフローが確実に実行されます。

7. 「<case>」セクションにinvokeアクティビティを追加します。

a. invokeアクティビティを「<case>」セクションにドラッグ・アンド・ドロップします。

b. Invoke_2アクティビティをダブルクリックします。「Invoke」ダイアログが表示されます。

c. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

d. 「Airline2」を選択して「OK」をクリックします。

e. 「Invoke」ダイアログで、「入力」および「出力」変数フィールドの右にある「入力変数の自動作成」および「出力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

f. デフォルトの変数名を選択して「OK」をクリックします。「入力変数」および「出力変数」フィールドにデフォルトの変数名が移入されます。「Invoke」ダイアログが表示されます。

g. 「OK」をクリックします。invokeアクティビティがJDeveloperの「BPEL_FIDS.bpel」ページのSequence_2の下に追加されます。

8. 「<case>」セクションにassignアクティビティを追加します。

a. <case>セクションで、invokeアクティビティの前に「コンポーネント」ウィンドウからassignアクティビティをドラッグ・アンド・ドロップします。

b. Assign_2アクティビティをダブルクリックします。Assignダイアログが表示されます。

c. 「コピー操作」タブをクリックします。Assignダイアログが表示されます。

d. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

e. 図5-104 に示すように、Receive_1アクティビティの入力変数のソースとInvoke_2アクティビティの入力変数のソースの間にコピー操作を作成します。

図5-104 「コピー操作の作成」ダイアログ

f. 「コピー操作の作成」ダイアログで「OK」をクリックします。

g. 「OK」をクリックします。

9. 一時変数を作成し、「<case>」セクションにtransformアクティビティを追加します。

注意:

一時変数は、Airline2サーバーからのフライト詳細の格納に使用されます。この情報は後でリプライ変数に追加されます。

a. (x)で表された「変数」アイコンをクリックします。図5-105 に示すように、「変数」ダイアログが表示されます。

図5-105 「変数」ダイアログ

b. 「作成」アイコンをクリックします。図5-106 に示すように、「変数の作成」ダイアログが表示されます。

図5-106 「変数の作成」ダイアログ

c. 変数タイプとして「メッセージ・タイプ」を選択します。

d. 「メッセージ・タイプ」フィールドの端にある「メッセージ・タイプの参照」アイコンをクリックします。「タイプ・チューザ」ダイアログが表示されます。

e. 図5-107 に示すように、「メッセージ・タイプ」、「パートナ・リンク」、「FIDS」、「FIDS.wsdl」、「メッセージ・タイプ」および「FIDSProcessReply_msg_reply」を順番にクリックします。

図5-107 「タイプ・チューザ」ダイアログ

f. 「OK」をクリックします。「変数の作成」ダイアログの「メッセージ・タイプ」フィールドにFIDSProcessReply_msg_replyパートナ・リンクが移入されます。

g. 「OK」をクリックします。「変数」ダイアログの「変数」リストに「メッセージ・タイプ」タイプの変数Variable_1が追加されます。

h. 「OK」をクリックして「BPEL_FIDS.bpel」ページに戻ります。

i. transformアクティビティを「<case>」セクションのInvoke_2アクティビティの後にドラッグ・アンド・ドロップします。

j. Transform_2アクティビティをダブルクリックします。

k. 「トランスフォーメーション」タブをクリックします。

l. 「作成」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

m. 「ソース変数」リストから「Invoke_2_OutboundRequestReply_OutputVariable」を選択し、「OK」をクリックします。

n. 「ターゲット変数」リストで「Variable_1」を選択します。

o. 「OK」をクリックします。XSLマッパー・ツールが表示されます。

p. 左ペインのソースから、「tns:Flight」ノードを右ペインにあるターゲットの「FlightDetails」ノードにリンクします。図5-108 に示すように、「自動マップ・プリファレンス」ダイアログが表示されます。

図5-108 「自動マップ・プリファレンス」ダイアログが表示されている「Transformation_2.xsl」ページ

q. 「OK」をクリックします。XSLマッピングを含むTransformation_2.xsl (XSLマッパー・ツール)ファイルが表示されます。

10. 「ファイル」、「すべて保存」を順番にクリックします。
図5-109 に示すように、Airline2サーバーのフローが定義された状態で「BPEL_FIDS.bpel」ページが表示されます。

図5-109 JDeveloper - BPEL_FIDS.bpel

5.5.2.5.6 Airline3サーバーのフローの設計

1. Flow_1アクティビティを右クリックします。メニューから「シーケンスの追加」をクリックします。Sequence_3が追加されます。

2. 「コンポーネント」ウィンドウからSequence_3にswitchアクティビティをドラッグ・アンド・ドロップします。

3. switchアクティビティを開きます。これにより、<case>および<otherwise>の値を入力するための画面が表示されます。

4. 「<case>」セクションで「条件式の表示」アイコンをクリックします。「条件式」ポップアップ・ウィンドウが表示されます。

5. ポップアップ・ウィンドウ内で「XPath式ビルダー」アイコンをクリックします。「式ビルダー」ダイアログが表示されます。

6. 式としてboolean(bpws:getVariableData('Receive_1_InboundRequestReply_InputVariable','FIDSProcessRequest','/ns5:FIDSProcessRequest/ns5:AirlineName')='Airline3')と入力し、「OK」をクリックします。画面が「条件式」ポップアップ・ウィンドウに戻ります。

注意:

この式により、Airline3の情報がリクエストされた場合にのみ、このフローが確実に実行されます。

7. 「<case>」セクションにinvokeアクティビティを追加します。

a. invokeアクティビティを「<case>」セクションにドラッグ・アンド・ドロップします。

b. Invoke_3アクティビティをダブルクリックします。Invokeダイアログが表示されます。

c. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

d. 「Airline3」を選択して「OK」をクリックします。

e. 「Invoke」ダイアログで、「入力」および「出力」変数フィールドの右にある「入力変数の自動作成」および「出力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

f. デフォルトの変数名を選択して「OK」をクリックします。「入力変数」および「出力変数」フィールドにデフォルトの変数名が移入されます。「Invoke」ダイアログが表示されます。

g. 「OK」をクリックします。invokeアクティビティがJDeveloperの「BPEL_FIDS.bpel」ページのSequence_3の下に追加されます。

8. 「<case>」セクションにassignアクティビティを追加します。

a. <case>セクションで、invokeアクティビティの前に「コンポーネント」ウィンドウからassignアクティビティをドラッグ・アンド・ドロップします。

b. Assign_3アクティビティをダブルクリックします。Assignダイアログが表示されます。

c. 「コピー操作」タブをクリックします。Assignダイアログが表示されます。

d. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

e. 図5-110 に示すように、Receive_1アクティビティの入力変数のソースとInvoke_3アクティビティの入力変数のソースの間にコピー操作を作成します。

図5-110 「コピー操作の作成」ダイアログ

f. 「コピー操作の作成」ダイアログで「OK」をクリックします。

g. 「OK」をクリックします。

9. 一時変数を作成し、「<case>」セクションにtransformアクティビティを追加します。

注意:

一時変数は、Airline3サーバーからのフライト詳細の格納に使用されます。この情報は後でリプライ変数に追加されます。

a. (x)で表された「変数」アイコンをクリックします。図5-111 に示すように、「変数」ダイアログが表示されます。

図5-111 「変数」ダイアログ

b. 「作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

c. 変数タイプとして「メッセージ・タイプ」を選択します。

d. 「メッセージ・タイプ」フィールドの端にある「メッセージ・タイプの参照」アイコンをクリックします。「タイプ・チューザ」ダイアログが表示されます。

e. 図5-107 に示すように、「メッセージ・タイプ」、「パートナ・リンク」、「FIDS」、「FIDS.wsdl」、「メッセージ・タイプ」および「FIDSProcessReply_msg_reply」を順番にクリックします。

f. 「OK」をクリックします。「変数の作成」ダイアログの「メッセージ・タイプ」フィールドにFIDSProcessReply_msg_replyパートナ・リンクが移入されます。

g. 「OK」をクリックします。「変数」ダイアログの「変数」リストに「メッセージ・タイプ」タイプの変数Variable_2が追加されます。

h. 「OK」をクリックして「BPEL_FIDS.bpel」ページに戻ります。

i. transformアクティビティを「<case>」セクションのInvoke_3アクティビティの後にドラッグ・アンド・ドロップします。

j. Transform_3アクティビティをダブルクリックします。

k. 「トランスフォーメーション」タブをクリックします。

l. 「作成」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

m. 「ソース変数」リストから「Invoke_3_OutboundRequestReply_OutputVariable」を選択し、「OK」をクリックします。

n. 「ターゲット変数」リストで「Variable_2」を選択します。

o. 「OK」をクリックします。XSLマッパー・ツールが表示されます。

p. 左ペインのソースから、「tns:Flight」ノードを右ペインにあるターゲットの「FlightDetails」ノードにリンクします。「自動マップ・プリファレンス」ダイアログが表示されます。

q. 「OK」をクリックします。図5-112 に示すように、XSLマッピングを含むTransformation_3.xsl (XSLマッパー・ツール)ファイルが表示されます。

図5-112 「Transformation_3.xsl」ページ

10. 「ファイル」、「すべて保存」を順番にクリックします。図5-113 に示すように、Airline3サーバーのフローが定義された状態で「BPEL_FIDS.bpel」ページが表示されます。

図5-113 JDeveloper - BPEL_FIDS.bpel

5.5.2.5.7 assignアクティビティの追加

1. 設計領域で、replyアクティビティとreceiveアクティビティの間に「コンポーネント」ウィンドウからassignアクティビティをドラッグ・アンド・ドロップします。

2. Assign_4アクティビティをダブルクリックします。「Assign」ダイアログが表示されます。

3. 「コピー操作」タブをクリックします。図5-114 に示すように、Assignダイアログが表示されます。

図5-114 「Assign」ダイアログ - 「コピー操作」タブ

4. 「追加操作」を選択します。「追加操作の作成」ダイアログが表示されます。

5. 図5-115 に示すように、一時変数Variable_1に格納されている情報をリプライ変数Reply_1_InboundRequestReply_OutputVariableに追加する追加操作を作成します。

図5-115 「追加操作の作成」ダイアログ

6. 「OK」をクリックします。「Assign」ダイアログが表示されます。

7. 「追加操作」を選択します。「追加操作の作成」ダイアログが表示されます。

8. 図5-116 に示すように、一時変数Variable_2に格納されている情報をリプライ変数Reply_1_InboundRequestReply_OutputVariableに追加する、別の追加操作を作成します。

図5-116 「追加操作の作成」ダイアログ

9. 「OK」をクリックします。Assignダイアログが表示されます。

10. 「OK」をクリックします。図5-117 に示すように、JDeveloperの「BPEL_FIDS.bpel」ページが表示されます。

図5-117 JDeveloper - HelloWorldFlow.bpel

11. 「ファイル」、「すべて保存」を順番にクリックします。

5.5.2.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

ServerおよびClient Javaプログラムを実行して、アプリケーションをテストする必要があります。詳細は、関連するREADMEファイルを参照してください。

5.5.2.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. デプロイしたSOAコンポジットをクリックします。「ダッシュボード」が表示されます。

「最新のインスタンス」領域で「インスタンスID」の値をメモします。

3. 「インスタンス」タブをクリックします。SOAコンポジットのインスタンスIDがリスト表示されます。

4. ステップ2でメモしたインスタンスIDをクリックします。「フローのトレース」ページが表示されます。

5. BPELプロセス・インスタンスをクリックします。BPELプロセス・インスタンスの「監査証跡」が表示されます。

6. ペイロード・ノードを開いてペイロード詳細を確認します。

7. プロセス・フローを表示するには、「フロー」タブをクリックします。また、アクティビティ(invoke、receiveなど)をクリックしてアクティビティ詳細を表示します。

5.5.3 ソケット・アダプタのクラスタ・サポート

クラスタ化環境とは、単一のIPアドレスを持つ単一のマシンで複数の管理対象サーバーが実行される環境のことです。インバウンドOracleソケット・アダプタをクラスタ化環境にデプロイしようとすると、管理対象サーバーの1つで、サーバーのポートがすでに使用されているというエラー・メッセージが表示されます。

ただし、ソケット・アダプタではクラスタ化環境のサポートが提供されています。クラスタ化環境で例外をスローしないようにソケット・アダプタを構成できます。

垂直クラスタ環境でのみ、単一の物理マシン上で複数の管理対象サーバーを実行できることに注意してください。水平クラスタ環境では、これは該当しません。

垂直クラスタ・トポロジには、カンマ区切りのポートが必要です。

5.5.3.1 ソケット・アダプタをクラスタ化環境で使用するための構成

ソケット・アダプタをクラスタ化環境で使用するように構成するには、該当するコネクション・ファクトリ内で、ソケット・アダプタが使用するポートをカンマ区切りリストで指定する必要があります。

ポートのカンマ区切りリストを構成すると、アダプタはリスト内の最初のポートでサーバー・ソケットを開始しようとします。

ソケット・アダプタは、サーバー・ソケットの開始に失敗すると、リスト内の次のポートを試行します。ソケット・アダプタは、いずれかのポートでサーバー・ソケットを開始するまで、引き続きソケットの開始を試行します。

指定したいずれのポートでもサーバー・ソケットを開始できない場合、ソケット・アダプタはoracle.tip.adapter.socket.SocketServerCreationExceptionをスローします。

5.5.3.1.1 Coherenceによるパフォーマンスの最適化

ソケット・アダプタは、Coherenceレイヤーを使用してポート・リストからポートを取得します。管理対象サーバー上のインバウンド・ソケット・アダプタの各インスタンスは、リストからポートをフェッチし、フェッチしたポートをソケット・アダプタの他のインスタンスから見えないようにします。

インバウンド・ソケット・アダプタは、フェッチしたポートを正常に開いた場合、フェッチしたポートをリストから削除します。

それ以外の場合、フェッチしたポートはインバウンド・ソケット・アダプタの他のインスタンスから可視になります。管理対象サーバー上のインバウンド・ソケット・アダプタの他のインスタンスは、リストの同じポートを開こうとしません。

5.5.3.1.2 クラスタ化環境でソケット・アダプタのサポートを有効化するための、JNDIコネクション・ファクトリの「ポート」プロパティの更新

クラスタ化環境でソケット・アダプタのサポートを有効化するには、インバウンド・ソケット・アダプタに対してポートのリストを指定する必要があります。リストを指定するには、図5-118 に示すように、WebLogicコンソールを開き、ポートのカンマ区切り値でJNDIコネクション・ファクトリの「ポート」プロパティを更新する必要があります。

図5-118 インバウンド・ソケット・アダプタに対するインバウンド・ポートのリストの指定

6 ネイティブ・フォーマット・ビルダー・ウィザード

この章では、トランスレーションに使用されるネイティブ・スキーマを作成できる、ネイティブ・フォーマット・ビルダー・ウィザードを説明します。スキーマの使用例やコンストラクトも用意されています。

この章の内容は次のとおりです。

- ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ・ファイルの作成

- ネイティブ・スキーマ・コンストラクト

- トランスレータXPath関数

- ネイティブ・フォーマット・ビルダーの使用例

6.1 ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ・ファイルの作成

様々なエンタープライズ情報システム(EIS)とOracle BPEL Process Manager (Oracle BPEL PM)、Oracle MediatorまたはOracle Service Bus (OSB)の統合を可能にするソフトウェア・コンポーネントです。アダプタは、ネイティブ・メッセージをXMLまたは非XMLフォーマットで受け取り、Oracle BPEL PMにXMLメッセージとしてパブリッシュします。また、XMLメッセージを受け取り、ネイティブEISフォーマットに変換することもできます。このネイティブ・データ・フォーマットとXMLの間の変換は、定義ファイル(非XMLスキーマ定義)を使用して実行され、定義ファイル自体はXMLスキーマ・フォーマットで定義されます。ネイティブ・フォーマット・ビルダー・ウィザードを使用すると、サンプル・ネイティブ・データを使用し、ネイティブXSD (NXSD)構文をネイティブ・データの変換用に作成できます。

図6-1 に示すように、アダプタ構成ウィザードの「メッセージ」ページで「ネイティブ・フォーマットのスキーマの定義」ボタンをクリックすると、ネイティブ・フォーマット・ビルダー・ウィザードが表示されます。「メッセージ」ページは、アダプタ構成ウィザードで「終了」ページの前に表示される最後のページです。

図6-1 ネイティブ・フォーマット・ビルダー・ウィザードの起動

6.1.1 サポートされているファイル形式

ネイティブ・フォーマット・ビルダー・ウィザードでは、図6-2 に示されているファイル形式からのネイティブ・スキーマ・ファイルの作成を支援します。ネイティブ・スキーマを作成するには、選択されたタイプのサンプル・データのファイル形式が必要です。また、このウィザードを使用して作成された既存のネイティブ・スキーマ(Document Type Definition (DTD)またはCOBOLコピーブック・ファイル・タイプから生成されたものを除く)を編集することもできます。ネイティブ・スキーマ・ファイルの編集の詳細は、「ネイティブ・スキーマ・ファイルの編集」を参照してください。

図6-2 ネイティブ・フォーマット・ビルダー・ウィザード

6.1.1.1 デリミタ

このオプションを選択すると、フィールドがカンマや番号記号(#)などの値で区切られているレコードのネイティブ・スキーマを作成できます。

6.1.1.2 固定長(位置固定)

このオプションを選択すると、フィールドがすべて固定長であるレコードのネイティブ・スキーマを作成できます。

6.1.1.3 複合タイプ

このオプションを選択すると、レコード用のネイティブ・スキーマを作成できます。この場合、フィールドそのものがレコードで複数のデリミタ・タイプを持つ可能性があります。

6.1.1.4 DTD

このオプションを選択すると、ユーザーが指定したDTDからネイティブ・スキーマを生成できます。DTDには、XMLドキュメントの構造に関する情報が含まれています。

6.1.1.5 COBOLコピーブック

このオプションを選択すると、ユーザーが指定したCOBOLコピーブック定義からネイティブ・スキーマを生成できます。

COBOLメインフレーム・アプリケーションでは、通常COBOLコピーブック・ファイルを使用してデータ・レイアウトを定義します。実行時トランスレータが、関連するデータ・ファイルを解析できるように、コンバータがCOBOLコピーブックからネイティブ・スキーマを作成します。

COBOLコピーブックは、グループ・アイテム(構造)のコレクションです。これらのグループ・アイテムには、グループまたは基本アイテムであるその他のアイテムが含まれます。基本アイテムはそれ以上分割できないアイテムです。次に例を示します。

01 Purchase-Order
05 Buyer
10 BuyerName PIC X(5) USAGE DISPLAY.
04 Seller
08 SellerName PICTURE XXXXX.

Purchase-orderは、2つの子グループ・アイテム(Buyer、Seller)を持つグループ・アイテムです。01、05、04などの数値は、グループのレベル(そのグループ内のデータの階層)を示します。

グループは、階層の同じレベルに異なるレベル番号を持つように定義することもできます。たとえば、BuyerおよびSellerには異なるレベル番号がありますが、階層内では同じレベルです。グループ・アイテムには、そのグループのレベル番号以下のレベル番号が発生するまで続く、すべてのグループと基本アイテムが含まれます。

各グループ・アイテム(BuyerおよびSeller)には子の基本アイテムがあります。PICまたはPICTURE句でデータ・レイアウトが定義されています。たとえば、BuyerNameではサイズが5文字の英数字が定義されています。SellerNameのデータ・レイアウトはBuyerNameと同じです。

COBOLのグループ・アイテムは、XMLスキーマのcomplexTypeタイプの要素にマップできます。同様に、基本アイテムは、実行時トランスレータが対応するデータ・ファイルを解析するのに役立つ特定のネイティブ・フォーマットの注釈が付けられたsimple typeタイプの要素にマップできます。たとえば、Buyerアイテムは次の定義にマップできます。

<!--COBOL declaration : 05 Buyer-->
<element name="Buyer">
<complexType>
<sequence>
<!--COBOL declaration : 10 Name PIC X(5)-->
<element name="Name" type="string" nxsd:style="fixedLength"
nxsd:padStyle="tail" nxsd:paddedBy=" " nxsd:length="5"/>
</sequence>
</complexType>
</element>

6.1.1.5.1 ユーザー入力

次の情報を指定する必要があります。

- 生成されるネイティブ・スキーマのターゲット・ネームスペース。

- データ・ファイルが生成されたホスト・コンピュータのキャラクタ・セット。デフォルトではEBCDICに設定されます(ebcdic-cp-us)。

- データ・ファイルが生成されたホスト・コンピュータのバイト順。デフォルトではビッグ・エンディアンに設定されます。

- レコード・デリミタ(通常は改行文字)、デリミタなし、またはユーザー指定の文字列。

- 生成されたネイティブ・スキーマのコンテナ・タグの名前。デフォルトではRoot-Elementに設定されます。

6.1.1.5.2 COBOL句

表6-1 に、COBOL句を示します。表6-1に出現する数値タイプは、1桁ごとに1文字として保存されます。句のサポートは次のように定義されています。

- Yは、句がサポートされていることを意味します。

- Nは、句がサポートされていないことを意味します。

- Iは、句が無視されることを意味します。

表6-1 COBOL句(数値タイプを1桁ごとに1文字として保存)

COBOL句

設計時のサポート

実行時のサポート

サポートされているシノニム

コメント

PIC X(n)

Y

Y

XXX…

英数字 - コンピュータのキャラクタ・セットで許可されている文字。Xはそれぞれ1バイトに対応します。

PIC A(n)

Y

Y

AA…

アルファベット - アルファベットまたは空白の任意の文字。Aはそれぞれ1バイトに対応します。

PIC 9(n) DISPLAY

Y

Y

9999…

数字を含む任意の文字位置。9はそれぞれアイテムのサイズに含められます。

OCCURS n TIMES

Y

Y

固定長配列

JUSTIFIED

Y

Y

AおよびXタイプの場合。空白で右寄せします。データは右端の文字位置に揃えられます。

REDEFINES

Y

Y

同じコンピュータのメモリー領域を異なるデータ・アイテムで表すことができます。

PIC 9(m)V9(n) DISPLAY

Y

Y

サイズは、n+mバイトです。

OCCURS DEPENDING ON

Y

Y

該当なし

BLANK WHEN ZERO

I

I

無視されます

RENAMES

N

N

COBOLコピーブックではあまり使用されません。

INDEX

N

N

4バイトの索引です

SYNCHRONIZED

I

I

SYNC

該当なし

POINTER

N

N

該当なし

PROCEDURE-POINTER

該当なし

FILLER

Y

Y

該当なし

表6-1に出現する数値タイプは、1桁ごとに1文字として保存されます。表6-2 に、より効率的に保存される数値タイプを示します。

表6-2 COBOL句(より効率的に保存される数値タイプ)

COBOL句

設計時のサポート

実行時のサポート

サポートされているシノニム

コメント

USAGE [IS]

Y

Y

これらのキーワードはどちらもオプションです。

PIC 9(n) COMP

Y

Y

COMPUTATIONAL、BINARY、COMP-4

nで長さが変わります。

- n = 1-4 (2バイト)

- n = 5-9 (4バイト)

- n = 10-18 (8バイト)

COMP-1

Y

Y

COMPUTATIONAL-1

4バイトの長さの単精度の浮動小数点数。

COMP-2

Y

Y

COMPUTATIONAL-2

8バイトの長さの倍精度の浮動小数点数。

PIC 9(n) COMP-3

Y

Y

PACKED-DECIMAL、COMPUTATIONAL-3

2つの数字は各バイトに保存されます。最後のその他の半バイトは、値が無署名でも署名用に割り当てられます。

PIC 9(n) COMP-4

Y

Y

COMPUTATIONAL-4

COMPタイプと同じように処理され、カスタマイズ要件にあわせて独自のデータ型を与えられます。

PIC 9(n) COMP-5

N

N

ネイティブ・バイナリ表現の容量。

PIC S9(n) DISPLAY

Y

Y

PIC S99…

デフォルトで、最も右端のニブルに署名します。Sはサイズには含まれません。

PIC S9(n) COMP

Y

Y

COMPと同じです。負の数値は2の補数として表されます。

PIC S9(n) COMP-3

Y

Y

該当なし

PIC 9(m)V9(n) COMP

Y

Y

長さはCOMPと同じです。

PIC 9(m)V9(m) COMP-3

Y

Y

長さは、Ceiling ((n+m+1)/2)です。

次の句を追加して署名の位置を変更できます。

- SIGN IS LEADING
署名されたゾーンの数値とともに使用します。

- SIGN IS TRAILING
署名されたゾーンの数値とともに使用します。

- SIGN IS LEADING SEPARATE
文字Sがサイズに含まれます。

- SIGN IS TRAILING SEPARATE
文字Sがサイズに含まれます。

注意:

数値がIBM COBOLフォーマットで保存されることを前提としています。異なるデータ保存フォーマットのその他のプラットフォーム用に生成されている場合は、そのタイプのカスタム・データ・ハンドラを記述する必要があります。

6.1.1.5.3 ピクチャ編集タイプ

表6-3 に、ピクチャ編集タイプを示します。

表6-3 編集済ピクチャ

編集済ピクチャ

サポートされている編集タイプ

サポートされていない編集タイプ

編集済英数字

単純な挿入: B(空白)0 / ,

編集済浮動数値

特殊な挿入: . (ピリオド)

編集済数値

- 単純な挿入: B(空白)0 / ,

- 特殊な挿入: . (ピリオド)

- 固定挿入: cs + - CR DB(最初または最後に記号を挿入)

- 浮動挿入: cs + -

- ゼロの抑止: Z *

- 置換挿入: Z * + - c

編集済ピクチャは、プレゼンテーション目的でデータ・ファイルではほとんど使用されません。記号の編集もデータで行うことを前提としています。たとえば、次のようなフィールドがあるとします。

05   AMOUNT     PIC 999.99

このフィールドの幅は6バイトで、データに小数点があります。

単純、特殊および固定挿入はこの方法で処理されます。浮動挿入、ゼロ抑止および置換挿入はサポートされていません。

6.1.1.6 XSDに変換されるMFL

MFLファイルをXSD形式に変換できます。詳細は、「MFLフォーマット・ファイルからスキーマ・フォーマットへの変換」を参照してください。

6.1.1.7 JSON Interchangeフォーマット

指定の場所で、JSONサンプル・ファイルまたはJSONファイルからNXSDスキーマを生成します。JSONは、人間が判読可能なデータの交換を行うためのテキストベースのオープン・スタンダードです。JSONは、オブジェクトと呼ばれる、単純なデータ構造および連想配列を表現するためのJavaScriptスクリプト言語から導出されます。

このオプションを選択すると、ネイティブ・フォーマット・ビルダー・ウィザードに「JSONファイルの説明」画面が表示されます。次の項目を入力できます。

- ファイル名: JSONファイルの名前。

- ターゲット・ネームスペース: ターゲット・ネームスペースが表示されます。

- ルート要素: JSONルート・レベルを指定します。

- キャラクタ・セット: 使用するキャラクタ・セットを選択します。

JSONの使用の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteでのSOAアプリケーションの開発 12c Release 1 (12.1.3.0)』を参照してください。

6.1.2 ネイティブ・スキーマ・ファイルの編集

デリミタ付き、固定長または複合タイプのファイルをサンプリングすることで、ネイティブ・フォーマット・ビルダー・ウィザードを使用して生成された既存のネイティブ・スキーマを編集できます。既存のネイティブ・スキーマを編集するには、ネイティブ・フォーマット・ビルダー・ウィザードの「タイプの選択」ページで「既存ファイルの編集」オプションを選択し、「参照」をクリックして既存のスキーマ・ファイルの場所にナビゲートし、編集対象のネイティブ・スキーマ・ファイルを選択します。ネイティブ・フォーマット・ビルダー・ウィザードに表示される指示に従って、ネイティブ・スキーマ・ファイルを編集します。

注意:

Document Type Definition (DTD)またはCOBOLコピーブック・ファイル・タイプから生成されたネイティブ・スキーマは編集できません。

図6-3 に、「ネイティブ・フォーマット・ビルダー - タイプの選択」ページで「既存ファイルの編集」オプションが選択されている様子を示します。

図6-3 「ネイティブ・フォーマット・ビルダー・ウィザード - タイプの選択」ページ

ネイティブ・スキーマ・ファイルを編集する前に、スキーマ内の注釈で指定されているサンプル・ファイルが存在することを確認する必要があります。この注釈は、ネイティブ・スキーマがサンプル・ファイルから初めて生成される際に自動的に追加されます。

次の例に、生成される注釈を示します。

例 - 生成される注釈

<xsd:annotation>
<xsd:appinfo>NXSDSAMPLE=/scratch/bob/sample.txt</xsd:appinfo>
<xsd:appinfo>USEHEADER=true</xsd:appinfo>
</xsd:annotation>

たとえば、注釈で指定されたサンプル・ファイルのパスが<!--NXSDWIZ:C:\Temp\Book1Out.csv:-->の場合に、このファイルが指定のパスに存在しなければ、ウィザードでエラーが表示されます。

6.2 ネイティブ・スキーマ・コンストラクト

この項では、ネイティブ・フォーマット・データをXMLに変換するために使用するネイティブ・スキーマの各種コンストラクトの概要と、これらのネイティブ・スキーマ・コンストラクトの使用方法について説明します。

この項には次のトピックが含まれます:

- ネイティブ・スキーマ・コンストラクトの理解

- ネイティブ・スキーマ・コンストラクトの使用

6.2.1 ネイティブ・スキーマ・コンストラクトについて

表6-4 に、<schema>タグにのみ適用可能なコンストラクトを示します。

表6-4 <schema>タグにのみ適用可能なコンストラクト

タグにのみ適用可能なコンストラクト" width="100%">

構文

説明

byteOrder

ネイティブ・データのバイト順。bigEndianまたはlittleEndianです。

encoding

実際のデータが格納されるエンコーディング。通常は、相互運用性とUnicodeがサポートされているため、UTF-8をお薦めします。Javaランタイム環境でサポートされている有効なエンコーディングは、いずれも指定できます。サポートされているエンコーディングの完全な一覧については、http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.htmlを参照してください。エンコーディングは、アダプタ・プロキシ・メタデータに関連付けられた(N)XSDで指定できます。例: nxsd:encoding="iso-8859-1

nxsd:alwaysQuote

アウトバウンドでネイティブの非xmlデータを強制的に引用符で囲む必要がある場合は、trueに設定します。

headerLines

ネイティブ・データの変換前にスキップする行数を指定する正の整数。

headerLinesTerminatedBy

ネイティブ・データの変換前に指定された文字列までスキップします。

standalone

宣言されている場合、nxsd:standaloneで指定された実際の値とともに、変換されたXMLのXML宣言のプロローグにスタンドアロン属性を追加します。許可された値はtrueおよびfalseです。

stream

データが文字とバイトのどちらで保存されるかを示します。許可された値はCHARSおよびBYTESです。

uniqueMessageSeparator

大量のメッセージにおいて、ネイティブ・データの一意のメッセージ・セパレータを指定する文字列。

version

ネイティブ・データのタイプ。可能な値はNXSD、DTD、XSDおよびOPAQUEです。

xmlversion

宣言されている場合、nxsd:xmlversionで指定された実際の値とともに、変換されたXMLにXML宣言のプロローグを追加します。許可された値は1.0および1.1です。

outboundHeader

アウトバウンド・メッセージに挿入するヘッダー値を指定する文字列。

dataLines

ネイティブ・ファイルで処理する行数を指定する整数。

fieldValidation

trueに設定すると、トランスレータではネイティブから読み取ったトークンのデータ型検証が実行されます。

フィールドValidationコンストラクトは組込みの単純型でのみサポートされています。

validation

trueに設定すると、トランスレータではインバウンドとアウトバウンドの両方で結果の検証が実行されます。

validateNxsd

trueに設定すると、詳細なネイティブ構文の検証が実行されます。このコンストラクトはデフォルトでオフになっており、本番環境ではパフォーマンスを向上させるためにオフにする必要があります。

useArrayIdentifiers

trueに設定すると、ネイティブ・フレームワークは配列識別子を処理するために最適化されます。これにより、非常に大きなペイロードの場合にパフォーマンス・ヒットになる場合があります。デフォルトでは、arrayIdentifiersはサポートされていません。

parseBom

trueに設定すると、ネイティブ・ストリーム内でバイト順マークが検索され、ここからエンコーディングが導出されます。

encodeLineTerminators

trueに設定すると、${eol}のセマンティックが\nのかわりに\r\nと解釈されます。

表6-5 に、<schema>タグ以外のすべてのタグに適用可能なコンストラクトを示します。

表6-5 <schema>タグ以外のすべてのタグに適用可能なコンストラクト

タグ以外のすべてのタグに適用可能なコンストラクト" width="100%">

構文

説明

arrayIdentifierLength

指定された長さを占有しているネイティブ・データに保存される配列の長さ。

arrayLength

このコンストラクトの値は、配列の長さとして使用されます。また、有効な数値に解決される変数の場合もあります。この値は、それが指定されているパーティクルのminOccursおよびmaxOccurs属性をオーバーライドします。この機能は次のように使用します。

nxsd:style="array" nxsd:arrayLength="10"

これは、配列の長さが10であることを意味します。

arrayTerminatedBy

指定された文字列で終了する配列の最後のアイテム。

assign

宣言されている変数に値を割り当てます。

cellSeparatedBy

指定された文字列で区切られるネイティブ・データの配列のセル。

choiceCondition

fixedLengthまたはterminatedです。

conditionValue

choiceConditionコンストラクトのネイティブ・ストリームから読み取られる文字列を、conditionValueコンストラクトの指定された文字列に対して一致させます。

dataLines

このコンストラクトに指定された値は、データ全体ではなくデータの一部のみを変換するために使用されます。

dateFormat

ネイティブ・データの日付を表すJava日付フォーマット。

identifierLength

実際のデータの長さが保存されている文字数およびバイト数。

itemSeparatedBy

指定された文字列で区切られているリストのアイテム。

leftSurroundedBy,

rightSurroundedBy

囲まれているネイティブ・データ。

length

読み取られるネイティブ・データの長さ。固定長スタイルで使用されます。

listTerminatedBy

指定された文字列で終了するリストの最後のアイテム。

lookAhead

入力ストリームの現在の位置よりも先の一致を検索します。一致が検出されると、このコンストラクトが指定されているノードが処理され、検出されない場合はスキップされます。この機能は次のように使用します。

nxsd:lookAhead="20" nxsd:lookFor="abc"

これは、20文字をスキップし、その位置から文字列abcを検索することを意味します。検出されるとそのノードが処理され、検出されない場合はスキップされます。

paddedBy

余白に使用される文字列。

padStyle

head、tailまたはnone。

quotedBy

指定された文字列で囲まれるネイティブ・データ。

デフォルトでは、指定された文字列は&quot;(")です。データにこの文字が含まれている場合は、フィールドが引用符で囲まれていない場合にも、このデフォルトをオーバーライドする必要があります。詳細は、「終了データの定義」の「変換されるネイティブ・データ・フォーマット: デフォルトの引用符文字を含むデータ」を参照してください。

skip

指定されたバイト数または文字数をスキップします。

skipLines

指定された行数をスキップします。

skipUntil

指定された文字列までスキップします。

startsWith

ネイティブ・データの指定された文字列を検索します。存在する場合は、それが指定されている要素の処理を続行し、存在しない場合はスキップして次の要素を処理します。

style

入力ストリームからのネイティブ・データの読取りに使用されるスタイル。許可された値はfixedLength、surrounded、terminated、listおよびarrayです。

surroundedBy

指定された文字列で囲まれるネイティブ・データ。

terminatedBy

指定された文字列で終了するネイティブ・データ。

variable

単一の変数を宣言します。

variables

一連の変数を宣言するか、宣言されている変数に値を割り当てます。

6.2.2 ネイティブ・スキーマ・コンストラクトの使用

この項には次のトピックが含まれます:

- 固定長データの定義

- 終了データの定義

- 囲みデータの定義

- リストの定義

- 配列の定義

- 条件付き処理

- 日付の定義

- 変数の使用

- 接頭辞と接尾辞の定義

- スキップするデータの定義

- fixedおよびdefault値の定義

- writeの定義

- LookAheadの定義

- outboundHeaderの定義

- conditionValueでの複雑な条件の定義

- choiceConditionでの複雑な条件の定義

- dataLinesの定義

- タイムゾーンを使用した日付書式の定義

- 変換中の検証の実装

- BOMを使用したファイルの処理

6.2.2.1 固定長データの定義

ネイティブ・フォーマットの固定長データは、固定長スタイルを使用してネイティブ・スキーマに定義できます。固定長には次の3つのタイプがあります。

- 余白あり

- 余白なし

- ネイティブ・データから実際の長さも読み取られるタイプ

変換されるネイティブ・データ・フォーマット: 余白あり

実際のデータが指定された長さに満たない場合があります。この場合には、headまたはtailとしてpaddedByおよびpadStyleを指定できます。データが読み取られると、余白はそれに従って削除されます。変換対象のサンプルのネイティブ・データを次に示します。

GBP*UK000012550.00

ネイティブ・スキーマ: 余白あり

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="fixedlength">
<complexType>
<sequence>
<element name="currency_code" nxsd:style="fixedLength" nxsd:length="4"
nxsd:padStyle="tail" nxsd:paddedBy="*">
<simpleType>
<restriction base="string">
<maxLength value="4" />
</restriction>
</simpleType>
</element>
<element name="country_code" nxsd:style="fixedLength" nxsd:length="2"
nxsd:padStyle="none">
<simpleType>
<restriction base="string">
<length value="2" />
</restriction>
</simpleType>
</element>
<element name="to_usd_rate" nxsd:style="fixedLength" nxsd:length="12"
nxsd:padStyle="head" nxsd:paddedBy="0">
<simpleType>
<restriction base="string">
<maxLength value="12" />
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML: 余白あり

<fixedlength xmlns="http://www.oracle.com/ias/processconnect">
<currency_code>GBP</currency_code>
<country_code>UK</country_code>
<to_usd_rate>12550.00</to_usd_rate>
</fixedlength>

変換されるネイティブ・データ・フォーマット: 余白なし

ネイティブ・スキーマに固定長データを定義するには、固定長スタイルを使用できます。実際のデータが指定された長さに満たない場合、空白は削除されません。変換対象のサンプルのネイティブ・データを次に示します。

GBP*UK000012550.00

ネイティブ・スキーマ: 余白なし

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="fixedlength">
<complexType>
<sequence>
<element name="currency_code" nxsd:style="fixedLength" nxsd:length="4">
<simpleType>
<restriction base="string">
<maxLength value="4" />
</restriction>
</simpleType>
</element>
<element name="country_code" nxsd:style="fixedLength" nxsd:length="2">
<simpleType>
<restriction base="string">
<length value="2" />
</restriction>
</simpleType>
</element>
<element name="to_usd_rate" nxsd:style="fixedLength" nxsd:length="12">
<simpleType>
<restriction base="string">
<maxLength value="12" />
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML: 余白なし

<fixedlength xmlns="http://www.oracle.com/ias/processconnect">
<currency_code>GBP*</currency_code>
<country_code>UK</country_code>
<to_usd_rate>000012550.00</to_usd_rate>
</fixedlength>

変換されるネイティブ・データ・フォーマット: ネイティブ・データから実際の長さも読み取られる場合

データの長さもネイティブ・ストリームに保存される場合、まず長さの読取り、次に読み取られた長さに応じたデータの読取りにこのスタイルが使用されます。変換対象のサンプルのネイティブ・データを次に示します。

03joe13DUZac.1HKVmIY

ネイティブ・スキーマ: ネイティブ・データから実際の長さも読み取られる場合

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="fixedlength">
<complexType>
<sequence>
<element name="user" type="string" nxsd:style="fixedLength"
nxsd:identifierLength="2" />
<element name="encr_user" type="string" nxsd:style="fixedLength"
nxsd:identifierLength="2" />
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML: ネイティブ・データから実際の長さも読み取られる場合

<fixedlength xmlns="http://www.oracle.com/ias/processconnect">
<user>joe</user>
<encr_user>DUZac.1HKVmIY</encr_user>
</fixedlength>

6.2.2.2 終了データの定義

このフォーマットは、終了マーク自体をデリミタではなく、実際のデータとして処理する場合に使用されます。マークが実際のデータの一部であるかどうかが不明な場合は、念のためにnxsd:quotedByを使用できます。nxsd:quotedByを指定すると、対応するネイティブ・データが引用符で囲まれる場合と囲まれない場合があります。囲まれている場合、実際のデータは、nxsd:quotedByでの指定に応じて開始の引用符から終了の引用符まで読み取られます。囲まれていない場合は、terminatedBy文字が検出されるまで読み取られます。

デフォルトでは、終了マークは&quot;(")です。データにこの文字が含まれている場合は、フィールドが引用符で囲まれていない場合にも、このデフォルトをオーバーライドする必要があります。詳細は、後述の「変換されるネイティブ・データ・フォーマット: デフォルトの引用符文字を含むデータ」を参照してください。

以降の各項では、引用符付き(オプション)と引用符なしのシナリオ、およびデフォルトの引用符文字を含むシナリオを示します。

変換されるネイティブ・データ・フォーマット: 引用符付き(オプション)

変換対象のサンプルのネイティブ・データを次に示します。

Fred,"2 Old Street, Old Town,Manchester",20-08-1954,0161-499-1718

ネイティブ・スキーマ: 引用符付き(オプション)

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="terminated">
<complexType>
<sequence>
<element name="PersonName" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</sequence>
</complexType>
</element>

ネイティブ・スキーマを使用して変換したXML: 引用符付き(オプション)

<terminated xmlns="http://www.oracle.com/ias/processconnect">
<PersonName>Fred</PersonName>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</terminated>

変換されるネイティブ・データ・フォーマット: 引用符なし

データが特定の文字列または文字で終了する場合に使用されます。変換対象のサンプルのネイティブ・データを次に示します。

1020,16,18,,1580.00

ネイティブ・スキーマ: 引用符なし

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="terminated">
<complexType>
<sequence>
<element name="product" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="ordered" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="inventory" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="backlog" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="listprice" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML: 引用符なし

<terminated xmlns="http://www.oracle.com/ias/processconnect">
<product>1020</product>
<ordered>16</ordered>
<inventory>18</inventory>
<backlog></backlog>
<listprice>1580.00</listprice>
</terminated>

変換されるネイティブ・データ・フォーマット: デフォルトの引用符文字を含むデータ

変換対象のサンプルのネイティブ・データを次に示します。

aaa,"bbbbb,[cccc

この場合、フィールドはカンマで終了し、"文字は2番目のフィールドのデータに含まれ、[文字は3番目のフィールドのデータに含まれています。

デフォルトのnxsd:quotedBy終了マークは&quot;(")であるため、このフィールドがカンマ文字で終了すると指定しても、フィールド2の変換に失敗します。このデータを正常に変換するには、デフォルトのnxsd:quotedBy終了マークを、このフィールドのデータに含まれていない任意の文字にオーバーライドする必要があります。この例では、&lt;(<)はフィールド2に含まれることがないため、デフォルトのnxsd:quotedBy終了マークをこの文字にオーバーライドします。

<element name="FieldTwo" type="string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="&lt;"/>

対照的に、フィールド3については、[文字はデフォルトのnxsd:quotedBy終了マークと競合しないため、指定する必要があるのはnxsd:terminatedBy=","のみとなります。

<element name="FieldThree" type="string" nxsd:style="terminated" nxsd:terminatedBy="," />

ネイティブ・スキーマ: デフォルトの引用符文字を含むデータ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="terminated">
<complexType>
<sequence>
<element name="FieldOne" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="FieldTwo" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&lt;"/>
<element name="FieldThree" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
</sequence>
</complexType>
</element>

ネイティブ・スキーマを使用して変換したXML: デフォルトの引用符文字を含むデータ

<terminated xmlns="http://www.oracle.com/ias/processconnect">
<FieldOne>aaa</FieldOne>
<FieldTwo>"bbbbb</FieldTwo>
<FieldThree>[cccc</FieldThree>
</terminated>

6.2.2.3 囲みデータの定義

ネイティブ・データがマークで囲まれている場合に使用されます。

囲みデータには次のタイプがあります。

- 左右の囲みマークが異なる場合

- 左右の囲みマークが同じ場合

変換されるネイティブ・データ・フォーマット: 左右の囲みマークが異なる場合

左右の囲みマークが異なる場合に変換対象となるサンプルのネイティブ・データを次に示します。

(Ernest Hemingway Museum){Whitehead St.}

ネイティブ・スキーマ: 左右の囲みマークが異なる場合

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://www.oracle.com/ias/processconnect"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">
<element name="limstring">
<complexType>
<sequence>
<element name="Landmark" type="string" nxsd:style="surrounded" nxsd:leftSurroundedBy="(" nxsd:rightSurroundedBy=")" />
<element name="Street" type="string" nxsd:style="surrounded" nxsd:leftSurroundedBy="{" nxsd:rightSurroundedBy="}" />
</sequence>
</complexType>
</element>
</schema>

ネイティブ・スキーマを使用して変換したXML: 左右の囲みマークが異なる場合

<limstring xmlns="http://www.oracle.com/ias/processconnect">
<Landmark>Ernest Hemingway Museum</Landmark>
<Street>Whitehead St.</Street>
</limstring>

変換されるネイティブ・データ・フォーマット: 左右の囲みマークが同じ場合

左右の囲みマークが同じ場合に変換対象となるサンプルのネイティブ・データを次に示します。

.FL..Florida Keys.+Key West+

ネイティブ・スキーマ: 左右の囲みマークが同じ場合

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://www.oracle.com/ias/processconnect"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">
<element name="limstring">
<complexType>
<sequence>
<element name="State" type="string" nxsd:style="surrounded" nxsd:surroundedBy="."/>
<element name="Region" type="string" nxsd:style="surrounded" nxsd:surroundedBy="." />
<element name="City" type="string" nxsd:style="surrounded" nxsd:surroundedBy="+" />
</sequence>
</complexType>
</element>
</schema>

ネイティブ・スキーマを使用して変換したXML: 左右の囲みマークが同じ場合

<limstring xmlns="http://www.oracle.com/ias/processconnect">
<State>FL</State>
<Region>Florida Keys</Region>
<City>Key West</City>
</limstring>

6.2.2.4 リストの定義

このフォーマットは、次の特性のあるリストに適用されます。

- すべてのアイテムが同じマークで区切られているが最後のアイテムが異なるマークで終了している場合(バインド済)

- 最後のアイテムを含みすべてのアイテムが同じマークで区切られている場合(バインドなし)

6.2.2.4.1 すべてのアイテムが同じマークで区切られているが最後のアイテムが異なるマークで終了している場合(バインド済)

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

125,200,255

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="list" type="tns:Colors" />

<complexType name="Colors" nxsd:style="list" nxsd:itemSeparatedBy=","
nxsd:listTerminatedBy="${eol}">

<sequence>
<element name="Red" type="string" />
<element name="Green" type="string" />
<element name="Blue" type="string" />
</sequence>
</complexType>

</schema>

ネイティブ・スキーマを使用して変換したXML

<list xmlns="http://www.oracle.com/ias/processconnect">
<Red>125</Red>
<Green>200</Green>
<Blue>255</Blue>
</list>

6.2.2.4.2 最後のアイテムを含みすべてのアイテムが同じマークで区切られている場合(バインドなし)

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

configure;startup;runtest;shutdown;

ネイティブ・スキーマ:

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="list" type="tns:CommandSet" />

<complexType name="CommandSet" nxsd:style="list" nxsd:itemSeparatedBy=";">
<sequence>
<element name="Cmd1" type="string" />
<element name="Cmd2" type="string" />
<element name="Cmd3" type="string" />
<element name="Cmd4" type="string" />
</sequence>
</complexType>

</schema>

ネイティブ・スキーマを使用して変換したXML

<list xmlns="http://www.oracle.com/ias/processconnect">
<Cmd1>configure</Cmd1>
<Cmd2>startup</Cmd2>
<Cmd3>runtest</Cmd3>
<Cmd4>shutdown</Cmd4>
</list>

6.2.2.5 配列の定義

これは、個々のセルが区切り文字で区切られていて、配列の最後のセルが終了文字で終了している複合型の配列用です。

配列タイプの例を次に示します。

- すべてのセルが同じマークで区切られているが最後のセルが異なるマークで終了している場合(バインド済)

- 最後のセルを含み、すべてのセルが同じマークで区切られている場合(バインドなし)

- セルはマークで区切られていないが最後のセルがマークで終了している場合(バインド済)

- ネイティブ・データからセルの数が読み取られる場合

- 明示的な配列長

6.2.2.5.1 すべてのセルが同じマークで区切られているが最後のセルが異なるマークで終了している場合(バインド済)

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

"Smith, John","1 Old Street, Old Town, Manchester",,"0161-499-1717".
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718".
"Smith, Bob",,,0161-499-1719.#

ネイティブ・スキーマ:

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
>
<element name="array">
<complexType>
<sequence>
<element name="Member" maxOccurs="unbounded"
nxsd:style="array" nxsd:cellSeparatedBy="${eol}"
nxsd:arrayTerminatedBy="#">
<complexType>
<sequence>
<element name="Name" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="." nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<array xmlns="http://www.oracle.com/ias/processconnect">
<Member>
<Name>Smith, John</Name>
<Address>1 Old Street, Old Town, Manchester</Address>
<DOB></DOB>
<Telephone>0161-499-1717</Telephone>
</Member>
<Member>
<Name>Fred</Name>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</Member>
<Member>
<Name>Smith, Bob</Name>
<Address></Address>
<DOB></DOB>
<Telephone>0161-499-1719</Telephone>
</Member>
</array>

6.2.2.5.2 最後のセルを含み、すべてのセルが同じマークで区切られている場合(バインドなし)

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

"Smith, John","1 Old Street, Old Town, Manchester",,"0161-499-1717".
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718".
"Smith, Bob",,,0161-499-1719.

ネイティブ・スキーマ:

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="array">
<complexType>
<sequence>
<element name="Member" maxOccurs="unbounded"
nxsd:style="array" nxsd:cellSeparatedBy="\r\n">
<complexType>
<sequence>
<element name="Name" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="." nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<array xmlns="http://www.oracle.com/ias/processconnect">
<Member>
<Name>Smith, John</Name>
<Address>1 Old Street, Old Town, Manchester</Address>
<DOB></DOB>
<Telephone>0161-499-1717</Telephone>
</Member>
<Member>
<Name>Fred</Name>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</Member>
<Member>
<Name>Smith, Bob</Name>
<Address></Address>
<DOB></DOB>
<Telephone>0161-499-1719</Telephone>
</Member>
</array>

6.2.2.5.3 セルはマークで区切られていないが最後のセルがマークで終了している場合(バインド済)

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

"Smith, John","1 Old Street, Old Town, Manchester",,"0161-499-1717"
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718"
"Smith, Bob",,,0161-499-1719
#

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="array">
<complexType>
<sequence>
<element name="Member" maxOccurs="unbounded"
nxsd:style="array" nxsd:arrayTerminatedBy="#">
<complexType>
<sequence>
<element name="Name" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="\r\n" nxsd:quotedBy='"'/>          </sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<array xmlns="http://www.oracle.com/ias/processconnect">
<Member>
<Name>Smith, John</Name>
<Address>1 Old Street, Old Town, Manchester</Address>
<DOB></DOB>
<Telephone>0161-499-1717</Telephone>
</Member>
<Member>
<Name>Fred</Name>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</Member>
<Member>
<Name>Smith, Bob</Name>
<Address></Address>
<DOB></DOB>
<Telephone>0161-499-1719</Telephone>
</Member>
</array>

6.2.2.5.4 ネイティブ・データからセルの数が読み取られる場合

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

3"Smith, John","1 Old Street, Old Town, Manchester",,"0161-499-1717"
Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718"
"Smith, Bob",,,0161-499-1719

ネイティブ・スキーマ:

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="arrayidentifierlength">
<complexType>
<sequence>
<element name="Member" maxOccurs="unbounded" nxsd:style="array"
nxsd:arrayIdentifierLength="1">
<complexType>
<sequence>
<element name="Name" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="\r\n" nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<arrayidentifierlength xmlns="http://www.oracle.com/ias/processconnect">
<Member>
<Name>Smith, John</Name>
<Address>1 Old Street, Old Town, Manchester</Address>
<DOB></DOB>
<Telephone>0161-499-1717</Telephone>
</Member>
<Member>
<Name>Fred</Name>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</Member>
<Member>
<Name>Smith, Bob</Name>
<Address></Address>
<DOB></DOB>
<Telephone>0161-499-1719</Telephone>
</Member>
</arrayidentifierlength>

6.2.2.5.5 明示的な配列長

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

3;John;Steve;Paul;Todd;

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="array">
<annotation>
<appinfo>
<nxsd:variables>
<nxsd:variable name="len" />
</nxsd:variables>
</appinfo>
</annotation>

<complexType>
<sequence>
<element name="TotalMembers" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";">
<annotation>
<appinfo>
<nxsd:variables>
<nxsd:assign name="len" value="${0}" />
</nxsd:variables>
</appinfo>
</annotation>
</element>
<element name="Member" type="string" minOccurs="0" maxOccurs="unbounded"
nxsd:style="array,terminated" nxsd:arrayLength="${len}"
nxsd:terminatedBy=";" />
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<array xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<TotalMembers>3</TotalMembers>
<Member>John</Member>
<Member>Steve</Member>
<Member>Paul</Member>
</array>

6.2.2.6 条件付き処理

この項では、条件付き処理に関する次のような例が用意されています。

- 条件に基づきchoiceモデル・グループ内の1つの要素を処理する場合

- 条件に基づきsequenceモデル・グループ内の複数の要素を処理する場合

6.2.2.6.1 条件に基づきchoiceモデル・グループ内の1つの要素を処理する場合

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

PO28/06/2004^|ABCD Inc.|Oracle
OracleApps025070,000.00
Database  021230,000.00
ProcessCon021040,000.00
PO01/07/2004^|EFGH Inc.|Oracle
DB2       021230,000.00
Eclipse   021040,000.00
SO29/06/2004|Oracle Apps|5
Navneet Singh
PO28/06/2004^|IJKL Inc.|Oracle
Weblogic  025070,000.00
Tuxedo    021230,000.00
JRockit   021040,000.00
IN30/06/2004;Navneet Singh;Oracle;Oracle Apps;5;70,000.00;350,000.00

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://www.oracle.com/ias/processconnect"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="container">

<complexType>
<choice maxOccurs="unbounded" nxsd:choiceCondition="fixedLength"
nxsd:length="2">

<element ref="tns:PurchaseOrder" nxsd:conditionValue="PO" />

<element ref="tns:SalesOrder" nxsd:conditionValue="SO" />

<element ref="tns:Invoice" nxsd:conditionValue="IN" />

</choice>
</complexType>
</element>

<!-- PO -->
<element name="PurchaseOrder" type="tns:POType"/>

<complexType name="POType">
<sequence>

<element name="Date" type="string" nxsd:style="terminated"
nxsd:terminatedBy="^" />
<element name="Buyer" type="string" nxsd:style="surrounded"
nxsd:surroundedBy="|" />
<element name="Supplier" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
<element name="Items">
<complexType>
<sequence>
<element name="Line-Item" minOccurs="3" maxOccurs="3">
<complexType>
<group ref="tns:LineItems" />
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>

<group name="LineItems">
<sequence>
<element name="Id" type="string" nxsd:style="fixedLength" nxsd:length="10"
nxsd:padStyle="none"/>
<element name="Quantity" type="string" nxsd:style="fixedLength"
nxsd:identifierLength="2" />
<element name="Price" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</sequence>
</group>

<!-- SO -->
<element name="SalesOrder" type="tns:SOType" />

<complexType name="SOType">
<sequence>
<element name="Date" type="string" nxsd:style="terminated"
nxsd:terminatedBy="|" />
<element name="Item" type="string" nxsd:style="terminated"
nxsd:terminatedBy="|" />
<element name="Quantity" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
<element name="Buyer" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</sequence>
</complexType>

<!-- INV -->
<element name="Invoice" type="tns:INVType" />

<complexType name="INVType">
<sequence>
<element name="Date" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Purchaser" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Seller" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Item" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Price" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Quantity" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="TotalPrice" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</sequence>
</complexType>

</schema>

ネイティブ・スキーマを使用して変換したXML

<container xmlns="http://www.oracle.com/ias/processconnect">
<PurchaseOrder>
<Date>28/06/2004</Date>
<Buyer>ABCD Inc.</Buyer>
<Supplier>Oracle</Supplier>
<Items>
<Line-Item>
<Id>OracleApps</Id>
<Quantity>50</Quantity>
<Price>70,000.00</Price>
</Line-Item>
<Line-Item>
<Id>Database  </Id>
<Quantity>12</Quantity>
<Price>30,000.00</Price>
</Line-Item>
<Line-Item>
<Id>ProcessCon</Id>
<Quantity>10</Quantity>
<Price>40,000.00</Price>
</Line-Item>
</Items>
</PurchaseOrder>
<PurchaseOrder>
<Date>01/07/2004</Date>
<Buyer>EFGH Inc.</Buyer>
<Supplier>Oracle</Supplier>
<Items>
<Line-Item>
<Id>DB2       </Id>
<Quantity>12</Quantity>
<Price>30,000.00</Price>
</Line-Item>
<Line-Item>
<Id>Eclipse   </Id>
<Quantity>10</Quantity>
<Price>40,000.00</Price>
</Line-Item>
</Items>
</PurchaseOrder>
<SalesOrder>
<Date>29/06/2004</Date>
<Item>Oracle Apps</Item>
<Quantity>5</Quantity>
<Buyer>Navneet Singh</Buyer>
</SalesOrder>
<PurchaseOrder>
<Date>28/06/2004</Date>
<Buyer>IJKL Inc.</Buyer>
<Supplier>Oracle</Supplier>
<Items>
<Line-Item>
<Id>Weblogic  </Id>
<Quantity>50</Quantity>
<Price>70,000.00</Price>
</Line-Item>
<Line-Item>
<Id>Tuxedo    </Id>
<Quantity>12</Quantity>
<Price>30,000.00</Price>
</Line-Item>
<Line-Item>
<Id>JRockit   </Id>
<Quantity>10</Quantity>
<Price>40,000.00</Price>
</Line-Item>
</Items>
</PurchaseOrder>
<Invoice>
<Date>30/06/2004</Date>
<Purchaser>Navneet Singh</Purchaser>
<Seller>Oracle</Seller>
<Item>Oracle Apps</Item>
<Price>5</Price>
<Quantity>70,000.00</Quantity>
<TotalPrice>350,000.00</TotalPrice>
</Invoice>
</container>

6.2.2.6.2 条件に基づきsequenceモデル・グループ内の複数の要素を処理する場合

以降の各項では、変換されるデータのフォーマット、ネイティブ・スキーマおよび変換済XMLについて説明します。

変換されるネイティブ・データ・フォーマット

PO28/06/2004^|ABCD Inc.|Oracle
OracleApps025070,000.00
Database  021230,000.00
ProcessCon021040,000.00
PO01/07/2004^|EFGH Inc.|Oracle
DB2       021230,000.00
Eclipse   021040,000.00
SO29/06/2004|Oracle Apps|5
Navneet Singh
PO28/06/2004^|IJKL Inc.|Oracle
Weblogic  025070,000.00
Tuxedo    021230,000.00
JRockit   021040,000.00
IN30/06/2004;Navneet Singh;Oracle;Oracle Apps;5;70,000.00;350,000.00

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://www.oracle.com/ias/processconnect"
targetNamespace="http://www.oracle.com/ias/processconnect"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="container">

<complexType>
<sequence maxOccurs="unbounded">

<element ref="tns:PurchaseOrder" minOccurs="0" nxsd:startsWith="PO" />

<element ref="tns:SalesOrder" minOccurs="0" nxsd:startsWith="SO" />

<element ref="tns:Invoice" minOccurs="0" nxsd:startsWith="IN" />

</sequence>
</complexType>
</element>

<!-- PO -->
<element name="PurchaseOrder" type="tns:POType"/>

<complexType name="POType">
<sequence>

<element name="Date" type="string" nxsd:style="terminated"
nxsd:terminatedBy="^" />    <element name="Buyer" type="string" nxsd:style="surrounded"
nxsd:surroundedBy="|" />
<element name="Supplier" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
<element name="Items">
<complexType>
<sequence>
<element name="Line-Item" minOccurs="3" maxOccurs="3">
<complexType>
<group ref="tns:LineItems" />
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>

<group name="LineItems">
<sequence>
<element name="Id" type="string" nxsd:style="fixedLength" nxsd:length="10"
nxsd:padStyle="none"/>
<element name="Quantity" type="string" nxsd:style="fixedLength"
nxsd:identifierLength="2" />
<element name="Price" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</sequence>
</group>

<!-- SO -->
<element name="SalesOrder" type="tns:SOType" />

<complexType name="SOType">
<sequence>
<element name="Date" type="string" nxsd:style="terminated"
nxsd:terminatedBy="|" />
<element name="Item" type="string" nxsd:style="terminated"
nxsd:terminatedBy="|" />
<element name="Quantity" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
<element name="Buyer" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />  </sequence>
</complexType>

<!-- INV -->
<element name="Invoice" type="tns:INVType" />

<complexType name="INVType">
<sequence>
<element name="Date" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Purchaser" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Seller" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Item" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />    <element name="Price" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="Quantity" type="string" nxsd:style="terminated"
nxsd:terminatedBy=";" />
<element name="TotalPrice" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</sequence>
</complexType>

</schema>

ネイティブ・スキーマを使用して変換したXML

<container xmlns="http://www.oracle.com/ias/processconnect">
<PurchaseOrder>
<Date>28/06/2004</Date>
<Buyer>ABCD Inc.</Buyer>
<Supplier>Oracle</Supplier>
<Items>
<Line-Item>
<Id>OracleApps</Id>
<Quantity>50</Quantity>
<Price>70,000.00</Price>
</Line-Item>
<Line-Item>
<Id>Database  </Id>
<Quantity>12</Quantity>
<Price>30,000.00</Price>
</Line-Item>
<Line-Item>
<Id>ProcessCon</Id>
<Quantity>10</Quantity>
<Price>40,000.00</Price>
</Line-Item>
</Items>
</PurchaseOrder>
<PurchaseOrder>
<Date>01/07/2004</Date>
<Buyer>EFGH Inc.</Buyer>
<Supplier>Oracle</Supplier>
<Items>
<Line-Item>
<Id>DB2       </Id>
<Quantity>12</Quantity>
<Price>30,000.00</Price>
</Line-Item>
<Line-Item>
<Id>Eclipse   </Id>
<Quantity>10</Quantity>
<Price>40,000.00</Price>
</Line-Item>
</Items>
</PurchaseOrder>
<SalesOrder>
<Date>29/06/2004</Date>
<Item>Oracle Apps</Item>
<Quantity>5</Quantity>
<Buyer>Navneet Singh</Buyer>
</SalesOrder>
<PurchaseOrder>
<Date>28/06/2004</Date>
<Buyer>IJKL Inc.</Buyer>
<Supplier>Oracle</Supplier>
<Items>
<Line-Item>
<Id>Weblogic  </Id>
<Quantity>50</Quantity>
<Price>70,000.00</Price>
</Line-Item>
<Line-Item>
<Id>Tuxedo    </Id>
<Quantity>12</Quantity>
<Price>30,000.00</Price>
</Line-Item>
<Line-Item>
<Id>JRockit   </Id>
<Quantity>10</Quantity>
<Price>40,000.00</Price>
</Line-Item>
</Items>
</PurchaseOrder>
<Invoice>
<Date>30/06/2004</Date>
<Purchaser>Navneet Singh</Purchaser>
<Seller>Oracle</Seller>
<Item>Oracle Apps</Item>
<Price>5</Price>
<Quantity>70,000.00</Quantity>
<TotalPrice>350,000.00</TotalPrice>
</Invoice>
</container>

6.2.2.7 日付の定義

この例では日付の定義方法を示します。

変換されるネイティブ・データ

11/16/0224/11/02
11-20-2002
23*11*2002
01/02/2003 01:02
01/02/2003 03:04:05

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="dateformat">
<complexType>
<sequence>
<element name="StartDate" type="dateTime" nxsd:dateFormat="MM/dd/yy"
nxsd:style="fixedLength" nxsd:length="8" />
<element name="EndDate" type="dateTime"   nxsd:dateFormat="dd/MM/yy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
<element name="Milestone" type="dateTime" nxsd:dateFormat="MM-dd-yyyy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
<element name="DueDate" type="dateTime"   nxsd:dateFormat="dd*MM*yyyy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
<element name="Date" type="dateTime"   nxsd:dateFormat="MM/dd/yyyy hh:mm"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
<element name="Date" type="dateTime"   nxsd:dateFormat="MM/dd/yyyy hh:mm:ss"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<dateformat xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<StartDate>2002-11-16T00:00:00</StartDate>
<EndDate>2002-11-24T00:00:00</EndDate>
<Milestone>2002-11-20T00:00:00</Milestone>
<DueDate>2002-11-23T00:00:00</DueDate>
<Date>2003-01-02T01:02:00</Date>
<Date>2003-01-02T03:04:05</Date>
</dateformat>

注意:

既存の日付フォーマットにnxsd:dateParsingMode="lax/strict"およびロケール・サポートが追加されています。

6.2.2.7.1 日付の定義: ローカル・サポートあり

次の例に、nxsd:dateParsingMode="lax/strict"およびロケール・サポートの使用方法を示します。

変換されるネイティブ・データ・フォーマット

11/16/0224/11/02
11-20-2002
23*11*2002
01/02/2003 01:02
01/02/2003 03:04:05
Thu, 26 May 2005 15:50:11 India Standard Time
Do, 26 Mai 2005 15:43:10 Indische Normalzeit
20063202

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="dateformat">
<complexType>
<sequence>
<element name="StartDate" type="date" nxsd:dateFormat="MM/dd/yy"
nxsd:localeLanguage="en" nxsd:style="fixedLength" nxsd:length="8" />
<element name="EndDate" type="date"   nxsd:dateFormat="dd/MM/yy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
<element name="Milestone" type="dateTime" nxsd:dateFormat="MM-dd-yyyy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
<element name="DueDate" type="dateTime"   nxsd:dateFormat="dd*MM*yyyy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />

<element name="Date" type="dateTime"   nxsd:dateFormat="MM/dd/yyyy hh:mm"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
<element name="Date" type="dateTime"   nxsd:dateFormat="MM/dd/yyyy hh:mm:ss"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />

<element name="LongDateInEnglish" type="dateTime"   nxsd:dateFormat="EEE, d
MMM yyyy HH:mm:ss zzzz" nxsd:localeLanguage="en" nxsd:localeCountry="US"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />
<element name="LongDateInGerman" type="dateTime"   nxsd:dateFormat="EEE, d
MMM yyyy HH:mm:ss zzzz" nxsd:localeLanguage="de" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />

<element name="InvalidDate" type="dateTime"   nxsd:dateParsingMode="lax"
nxsd:dateFormat="yyyyMMdd" nxsd:style="terminated" nxsd:terminatedBy="${eol}" />

</sequence>
</complexType>
</element>

</schema>

変換済のXML

<dateformat xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<StartDate>2002-11-16</StartDate>
<EndDate>2002-11-24</EndDate>
<Milestone>2002-11-20T00:00:00</Milestone>
<DueDate>2002-11-23T00:00:00</DueDate>
<Date>2003-01-02T01:02:00</Date>
<Date>2003-01-02T03:04:05</Date>
<LongDateInEnglish>2005-05-26T15:50:11</LongDateInEnglish>
<LongDateInGerman>2005-05-26T15:43:10</LongDateInGerman>
<InvalidDate>2008-08-02T00:00:00</InvalidDate>
</dateformat>

6.2.2.8 変数の使用

この例では変数の使用方法を示します。

変換されるネイティブ・データ・フォーマット

{,;}Fred,"2 Old Street, Old Town,Manchester","20-08-1954";"0161-499-1718"
phone-2
phone-3

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">
<element name="variable">
<annotation>
<documentation>
1. var1 - variable declaration
2. var2 - variable declaration with default value
3. EOL - variable declaration with referencing a system variable
</documentation>
<appinfo>
<junkies/>
<nxsd:variables>
<nxsd:variable name="var1" />
<nxsd:variable name="var2" value="," />
<nxsd:variable name="SystemEOL" value="${system.line.separator}" />
</nxsd:variables>
<junkies/>
<junkies/>
<junkies/>
</appinfo>
</annotation>

<complexType>
<sequence>
<element name="delims" type="string" nxsd:style="surrounded"
nxsd:leftSurroundedBy="{" nxsd:rightSurroundedBy="}" >
<annotation>
<appinfo>
<junkies/>
<junkies/>
<junkies/>
<nxsd:variables>
<nxsd:assign name="var1" value="${0,1}"/>
<nxsd:assign name="var2" value="${1}" />
</nxsd:variables>
</appinfo>
</annotation>
</element>

<element name="PersonName" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${var1}" nxsd:quotedBy="&quot;" />
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${var1}" nxsd:quotedBy="&quot;"/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${var2}" nxsd:quotedBy='"'/>
<element name="Telephone1" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
<element name="Telephone2" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
<element name="Telephone3" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<variable xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<delims>,;</delims>
<PersonName>Fred</PersonName>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone1>0161-499-1718</Telephone1>
<Telephone2>phone-2</Telephone2>
<Telephone3>phone-3</Telephone3>
</variable>

6.2.2.9 接頭辞と接尾辞の定義

ネイティブ・フォーマットでは、データが読み取られるときに、次の例に示すように、指定のデータに接頭辞または接尾辞、あるいはその両方が追加されます。

変換されるネイティブ・データ

Fred,  "2 Old Street, Old Town,Manchester","20-08-1954",0161-499-1718

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
>

<element name="terminated">
<complexType>
<sequence>
<element name="PersonName" type="string" nxsd:prefixWith="Mr."
nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
<element name="Address" type="string" nxsd:suffixWith="]]"
nxsd:prefixWith="[[" nxsd:style="terminated" nxsd:terminatedBy=","
nxsd:quotedBy="&quot;"/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<PersonName>Mr.Fred</PersonName>
<Address>[[2 Old Street, Old Town,Manchester]]</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</terminated>

6.2.2.10 スキップするデータの定義

トランスレータは、次の例に示すように、skipModeコンストラクトに応じてデータの読取り前または読取り後にスキップします。

変換されるネイティブ・データ

Fred,   "2 Old Street, Old Town,Manchester","20-08-1954",0161-499-1718

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
>

<element name="terminated">
<complexType>
<sequence>
<element name="PersonName" type="string" nxsd:skip="5"
nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
<element name="Address" type="string" nxsd:skipMode="before" nxsd:skip="3"
nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
<element name="DOB" type="string" nxsd:skipMode="after" nxsd:skip="6"
nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<PersonName>Fred</PersonName>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>99-1718</Telephone>
</terminated>

6.2.2.11 fixedおよびdefault値の定義

nxsd注釈を付けずに要素を宣言し、値fixedまたはdefaultを指定すると、トランスレータは指定された値を使用し、例外をスローしません。

変換されるネイティブ・データ

Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718"

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="terminated">
<annotation>
<appinfo>
<nxsd:variables>
<nxsd:variable name="x" value="hello" />
</nxsd:variables>
<junkies/>
<junkies/>
<junkies/>
</appinfo>
</annotation>

<complexType>
<sequence>
<element name="PersonName" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
<element name="Age" type="string" fixed="16"  />
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="salutation" type="string" default="${x}"  />
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<PersonName>Fred</PersonName>
<Age>16</Age>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<salutation>hello</salutation>
<Telephone>0161-499-1718</Telephone>
</terminated>

6.2.2.12 writeの定義

writeコンストラクトは、実際のデータの書込み前または書込み後に、出力ストリームの現在位置にリテラルを書き込みます。

入力XML

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<PersonName>Fred</PersonName>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</terminated>

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
>

<element name="terminated">
<complexType>
<sequence>
<element name="PersonName" type="string" nxsd:writeMode="before"
nxsd:write="Mr." nxsd:style="terminated" nxsd:terminatedBy=","
nxsd:quotedBy="&quot;" />
<element name="Address" type="string" nxsd:writeMode="after"
nxsd:write="Over." nxsd:style="terminated" nxsd:terminatedBy=","
nxsd:quotedBy="&quot;"/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したデータ

Mr.Fred,"2 Old Street, Old Town,Manchester",Over.20-08-1954,0161-499-1718

6.2.2.13 LookAheadの定義

LookAheadコンストラクトには次のタイプがあります。

- タイプ1: LookAhead X charsは、スタイルを使用して位置から値を読み取り、指定のリテラルと照合します。

- タイプ2: LookAhead X charsは、スタイルを使用して位置から値を読み取り、その値を後で使用できるように変数に格納します。

6.2.2.13.1 LookAhead: タイプ1

LookAhead X charsは、スタイルを使用して位置から値を読み取り、指定のリテラルと照合します。

変換されるネイティブ・データ・フォーマット

Fred,"2 Old Street, Old Town,Manchester","20-08-1954","0161-499-1718",YES

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="LookAhead">
<complexType>
<sequence minOccurs="0" nxsd:lookAhead="70" nxsd:lookFor="YES">
<element name="PersonName" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<LookAhead xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<PersonName>Fred</PersonName>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</LookAhead>

6.2.2.13.2 LookAhead: タイプ2

ネイティブ・スキーマではLookAhead X charsは、スタイルを使用して位置から値を読み取り、その値を後で使用できるように変数に格納します。

変換されるネイティブ・データ・フォーマット

Name1,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES
Name2,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO
Name3,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO
Name4,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<!--
nxsd:lookAhead="70" nxsd:scan="3"
-->

<element name="LookAhead">
<complexType>
<choice maxOccurs="unbounded" nxsd:choiceCondition="${x}" nxsd:lookAhead="70"
nxsd:scanLength="3" nxsd:assignTo="${x}">
<element name="Record1" type="string" nxsd:conditionValue="YES"
nxsd:style="terminated" nxsd:terminatedBy="," nxsd:skipMode="after"
nxsd:skipUntil="${eol}" />
<element name="Record2" type="string" nxsd:conditionValue="NO "
nxsd:style="terminated" nxsd:terminatedBy="," nxsd:skipMode="after"
nxsd:skipUntil="${eol}" />
</choice>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<LookAhead xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<Record1>Name1</Record1>
<Record2>Name2</Record2>
<Record2>Name3</Record2>
<Record1>Name4</Record1>
</LookAhead>

6.2.2.14 正規表現を使用したレコードの条件付き処理に対する複雑なlookAhead戦略の定義

NXSDウィザードは、固定長レコードと可変長レコードの両方をフィルタリングするための正規表現パターンを指定できるlookahead属性を提供します。

固定長、デリミタ付きおよび複合ファイル・タイプでlookahead属性を使用することで、条件付き処理がサポートされます。

この条件付き処理を使用すると、正規表現を満たすレコードのみがXMLでパブリッシュされる結果を取得できます。

また、レコードが正規表現を満たさない場合に例外を発生するオプションも指定できます。選択条件を指定することによって条件付き処理がサポートされます。

正規表現のサポートによって、正規表現と照合する文字列を指定できます。文字列はレコード境界を超えることはできません。

固定長レコードでは、レコード長とレコードの様々なフィールドがあらかじめわかっています。このことは、正規表現と照合するストリームの開始位置と長さを指定する際に役立ちます。

固定長レコードのnxsdコンストラクトとその定義のリストは、表6-6 を参照してください。

コンストラクトは、nxsd:の形式で提供されますが、ネイティブ・フォーマット・ビルダーのユーザー・インタフェースと同等の役割を果たし、ネイティブ・フォーマット・ビルダー・ウィザードの該当する画面の説明で参照されます。

表6-6 固定長レコードのLookAheadコンストラクト

構文

説明

nxsd:lookAhead

入力ストリームの現在の位置よりも先の一致を検索します。一致が検出されると、このコンストラクトが指定されているレコードが処理され、検出されない場合はスキップされます。この機能は次のように使用します。

nxsd:lookAhead="20" nxsd:lookForPattern=".*Pattern.*" nxsd:scanLength="30"

これは、20文字をスキップし、次の30文字の中でjava.util.regex.Pattern ".*Pattern.*"を検索することを意味します。パターンが検出されるとそのレコードが処理され、検出されない場合はスキップされます。

このコンストラクトは、lookForおよびlookForPatternの両方を持つユーザーになります。

nxsd:lookForPattern

入力ストリームと照合する正規表現java.util.regex.Patternを指定します。

nxsd:scanLength

lookAheadの後の入力ストリームのデータ長を指定します。このデータはlookForPatternと照合されます。

nxsd:reportLookAheadError

データとlookForPatternが一致しないとエラーを発生するかどうかについて、ブール値を指定します。デフォルト値はfalseで、データとlookForPatternが一致しない場合にエラーを発生せず、不一致のレコードをスキップします。この場合、不一致のレコードは処理されず、データの喪失としてユーザーに表示されることがあります。

次の使用例を参照してください。

- nxsd:scanLengthを指定しない場合は、uniqueMessageSeparatorを使用して文字列が特定されます。
uniqueMessageSeparatorは、大量のメッセージにおいて、ネイティブ・データの一意のメッセージ・セパレータを指定する文字列です。uniqueMessageSeparatorが指定されていない場合、デフォルトの${eol}が使用されます。

次のシナリオでは、nxsd:scanLengthが指定されていないため、トランスレータはuniqueMessageSeparatorを使用して正規表現と照合する文字列を特定します。

- アドレスがNew Townのすべてのレコードをスキャンします。ネイティブ・データは次のとおりです。

#Fred,"2 Old Street, Old Town, Manchester","17-08-1954","0161-498-1718", YES
#Tred,"2 Old Street, Old Town, Manchester","16-08-1974","0161-486-1718", YES
John,"2 Old Street, New Town, Manchester","20-08-2004","0161-497-1718", NO
#

これに対するNXSDは次のとおりで、文字列を特定するためにuniqueMessageSeparatorを使用します。

<schema …
nxsd:uniqueMessageSeparator="#">
<sequence minOccurs="0" maxOccurs="unbounded" nxsd:lookAhead="0" nxsd:lookForPattern="*New Town*">

- アドレスがNew Townで、nxsd:uniqueMessageSeparatorが指定されていないすべてのレコードをスキャンします。トランスレータは${eol}を使用して、正規表現と照合する文字列を特定します。

Fred,"2 Old Street, Old Town, Manchester","17-08-1954","0161-498-1718", YES
Tred,"2 Old Street, Old Town, Manchester","16-08-1974","0161-486-1718", YES
John,"2 Old Street, New Town, Manchester","20-08-2004","0161-497-1718", NAH

これに対するNXSDは次のとおりです。

<sequence minOccurs="0" maxOccurs="unbounded" nxsd:lookAhead="0" nxsd:lookForPattern="*New Town*">

- 次の使用例では、nxsd:uniqueMessageSeparatorを使用しません。
2つ目の使用例では、文字列を特定するためにnxsd:scanLengthを指定します。

Fred,"2 Old Street, New Town, Manchester","17-08-1954","0161-498-1718", YES
Tred,"2 Old Street, Old Town, Manchester","16-08-1974","0161-486-1718", YES
John,"2 Old Street, New Town, Manchester","20-08-2004","0161-497-1718", NAH

このデータに対して使用するNXSDは次のとおりです。

<sequence minOccurs="0" maxOccurs="3" nxsd:lookAhead="0" nxsd:lookForPattern=".*New Town.*" nxsd:scanLength="73">

- 2つ目のフィールドが数字のみで構成されるすべてのレコードをスキャンします。ネイティブ・データは次のとおりです。

Fred, add, 20-08-1954, 0161-498-1718", YES
Tred, 100, 20-08-1954, 0161-486-1718", YES
John, add, 20-08-1954, 0161-497-1718", NAH

2つ目のフィールドが数字のみで構成されるかどうかを特定するNXSDは次のとおりです。

<sequence minOccurs="0" maxOccurs="3" nxsd:lookAhead="0" nxsd:lookForPattern=".*,\d+,.*" nxsd:scanLength="38">

- zipに5桁の数字のみが含まれるすべてのレコードをスキャンします。ネイティブ・データは次のとおりです。

Fred, zipID, 20-08-1954, 0161-498-1718", YES
Tred, 90210, 20-08-1954, 0161-486-1718", YES
John, 9021Z, 20-08-1954, 0161-497-1718", NAH

適切なパターンを検索し、5桁の数字を特定するNXSDは次のとおりです。

<sequence minOccurs="0" maxOccurs="3" nxsd:    lookAhead="0" nxsd:lookForPattern=".*,\d{5},.*" nxsd:scanLength="40">

- 名前に数字が含まれず、2つ目のフィールドに5桁のzipコードが含まれるすべてのレコードをスキャンします。ネイティブ・データは次のとおりです。

JohnBrown, zipID, 20-08-1954, 0161-498-1718", YES
Sweety101, 90210, 20-08-1954, 0161-486-1718", YES
CrowyBowy, 90210, 20-08-1954, 0161-497-1718", NAH

正規表現の使用に対するこのNXSDは次のとおりです。

<sequence minOccurs="0" maxOccurs="4" nxsd:lookAhead="0" nxsd:lookForPattern="[a-zA-Z]*,\d{5},.*" nxsd:scanLength="45">

スキャンの長さの使用は固定長レコードで適切に機能しますが、可変長レコードには、長さが事前にわからないという制限があります。そのため、nxsd:scanLength属性をこのようなシナリオで使用することはできません。トランスレータには、正規表現と照合する文字列を特定する方法が必要です。

可変長レコードのこの制限に対処するには、複雑なlookaheadを実行するときに、nxsd:scanLengthを使用するのではなく、2つの属性(nxsd:LookFromおよびnxsd:lookTill)を使用できます。

パターンが一致する文字列は、nxsd:lookFrom属性およびnxsd:lookTill属性を介して導出できます。可変長レコードのlookaheadスキャンに対する基本NXSDは、次のとおりです。

nxsd:lookFrom="FirstInstanceOfString" nxsd:lookTill="firstInstanceOfString after lookFrom"
nxsd:lookForPattern="java.util.regex.Pattern" [nxsd:skipUntill="${eol} or Literal"]

可変長レコードのlookaheadコンストラクトのリストは、表6-7 を参照してください。

コンストラクトは、nxsd:の形式で提供されますが、ネイティブ・フォーマット・ビルダーのユーザー・インタフェースと同等の役割を果たし、該当する画面の説明で参照されます。

表6-7 可変長レコードのlookaheadコンストラクト

構文

定義

nxsd:lookFrom

リテラルを定義します。lookFromリテラルが入力ストリームに見つかった後にのみ、データが照合されます。

nxsd:lookForPattern

入力ストリームと照合するjava.util.regex.Pattern (正規表現)を指定します。

nxsd:lookTill

入力ストリームのデータ照合の終点となるリテラルを指定します。nxsd:lookFrom (除外)とlookTill (除外)の間にある入力ストリームのデータが、lookForPatternと照合されます。

nxsd:skipUntil

データがlookForPatternと一致しないときに、入力ストリームのデータのスキップの終点となるリテラルを指定します。

nxsd:reportLookAheadError

データがlookForPatternと一致しないときにエラーを発生する場合のブール値を指定します。デフォルト値はfalseで、データがlookForPatternと一致しない場合にエラーを発生せず、不一致のレコードもスキップします。

ネイティブ・ファイルを変換するためのNXSDを作成する場合、スキーマでlookAheadを指定すると、lookForPatternを使用して指定した正規表現に基づいて値を抽出できます。

ただし、可変長レコードを抽出する場合は、レコードの長さがわからないため、NXSD要素でlookFrom属性とlookTill属性を使用できます。JDeveloperネイティブ・フォーマット・ビルダーのユーザー・インタフェース・ウィンドウで、skipUntilを使用するか、または使用せずにlookFromおよびlookTillに値を指定します。

複雑なlookaheadを可変長レコードとともに使用する場合、これらのコンストラクトの理解に関連する使用例がいくつかあります。

- 1つ目の使用例では、nxsd:lookTillがレコードの終わりであり、New Townにアドレスがあるレコードをすべてスキャンします。この例では、スキーマ要素のカーディナリティを超過せず、nxsd:lookForPatternが一致しない場合に、トランスレータがスキップ位置を認識している必要があります。

Tred,"2 Old Street, NEW Town,Manchester",@NAH
Bred,"2 Old Street, Old Town,Manchester",@NAH
dred,"2 Old Street, New Town,Manchester",@YES
Hred,"2 Old Street, Old Town,Manchester",@YES
Bred,"2 Old Street, Old Town,Manchester",@YES

この使用例に対するNXSDは次のとおりです。nxsd:lookTill="${eol}によってレコードの最後を示し、New Townを検索することを示しています。

<sequence minOccurs="0" maxOccurs="3" nxsd:lookFrom="Street" nxsd:lookTill="${eol}" nxsd:lookForPattern=".*New Town.*">

- nxsd:lookTillがレコードの終わりではない使用例もあります。この例では、トランスレータは、レコードが一致しない場合にスキップ位置を認識していません。
nxsd:skipUntil属性を使用すると、レコードが情報と一致しない場合にスキップ位置を指定できます。

nxsd:lookTill句とともにnxsd:skipUntil句を明示的に定義する必要があります。

nxsd:skipUntilを使用する場合は、次のようにレコードの終わりを指定します。

nxsd:skipUntil=" ${eol} or Literal"

- この使用例では、New Townにアドレスがあるすべてのレコードをスキャンします。ネイティブ・データは次のとおりです。

Tred,"2 Old Street, NEW Town, Manchester", @NAH
Bred,"2 Old Street, Old Town, Manchester", @NAH
Dred, "2 Old Street, New Town, Manchester", @YES
Hred,"2 Old Street, Old Town, Manchester", @YES
Bred,"2 Old Street, Old Town, Manchester", @YES

次のNXSDは、レコードが一致しない場合にファイルの終わりまでスキップしますが、Manchesterが見つかるまで検索を行うことを示しています。

<sequence minOccurs="0" maxOccurs="3" nxsd:lookFrom="Street" nxsd:lookTill=" Manchester" nxsd:lookForPattern=".*New Town.*" nxsd:skipUntil="${eol}">

- 事前定義された位置から、特定の文字列が見つかる位置まで正規表現を照合することもできます。そのためには、nxsd:lookTill属性とともにnxsd:lookAheadを使用して開始位置を指定します。
これは、nxsd:lookFrom属性については不明であるが、レコードの終わりがわかっているシナリオで役立ちます。

そのようなシナリオでは、nxsd:lookAhead="0"とnxsd:lookTill="end of record"を指定できます。この場合、レコードの終わりまでnxsd:lookTillを指定する必要があります。

次の例では、New Townにアドレスがあるすべてのレコードをスキャンします。ネイティブ・データは次のとおりです。

Tred,"2 Old Street, NEW Town, Manchester", @NAHBred,"2 Old Street, Old Town, Manchester", @NAHDred,"2 Old Street, New Town, Manchester", @YESHred,"2 Old Street, Old Town, Manchester", @YESBred,"2 Old Street, Old Town, Manchester", @YES

レコードの終わりがわかっているこの使用例のNXSDは、次のとおりです。

<sequence minOccurs="0" maxOccurs="3" nxsd:lookAhead="0" nxsd:lookForPattern=".*New Town.*" nxsd:lookTill="${eol}">

- nxsd:lookTillがレコードの終わりではない例もあります。nxsd:skipUntilを指定する必要があります。これは、特定の正規表現と一致しないレコードをトランスレータがスキップする必要があるポイントを示します。
次の例では、New Townにアドレスがあるすべてのレコードをスキャンします。

- Tred,"2 Old Street, NEW Town, Manchester", @NAH
Bred,"2 Old Street, Old Town, Manchester", @NAH
Dred,"2 Old Street, New Town, Manchester", @YES
Hred,"2 Old Street, Old Town, Manchester", @YES
Bred,"2 Old Street, Old Town, Manchester", @YES

nxsd:skipUntilがレコードの終わりを定義している場合のNXSDは、次のとおりです。

<sequence minOccurs="0" maxOccurs="3" nxsd:lookAhead="0" nxsd:lookForPattern=".*New Town.*" nxsd:lookTill="Manchester" nxsd:skipUntil="${eol}">

- JDeveloperネイティブ・フォーマット・ビルダーのユーザー・インタフェース・ウィンドウで、skipUntilを使用するか、使用せずにlookAheadとlookTillに値を指定できますが、JDeveloper UIでそれらを選択して次に進み、NXSDソースを表示すると、スキーマにlookTill属性が含まれません。この問題を防ぐには、lookAhead属性とともに<namespace>:lookTill="literal"を明示的に記述します。

6.2.2.14.1 パターンの検索時に改行文字を含める

改行文字があるレコードの各行では、文の最後の単語を見つけるために複雑なLookAheadパターンを定義する場合に、改行文字をcharとして含める必要があります。

たとえば、次のレコードを検索する場合、

canvas,"1 17th Cross, North
London,England","17-08-1954","0161-498-1718",YES

検索用のパターンとして次を使用できると考えるかもしれません。

nxsd:lookAhead="73" nxsd:scanLength="3"
nxsd:lookForPattern=".ES"

しかし、検索するレコードが実際は改行文字を含む次の内容の場合、

canvas,"1 17th Cross, North
London,England","17-08-1954","0161-498-1718",YES\n

このレコードを検索するlookForPattern句は、次のようにする必要があります。

nxsd:lookForPattern=".ES\n"

または、デリミタに対応する場合は、次のようにします。

nxsd:lookForPattern=".ES."

そのため、属性は次のようになります。

nxsd:lookAhead="73" nxsd:scanLength="4"
nxsd:lookForPattern=".ES\n" or nxsd:lookForPattern=".ES."

6.2.2.15 outboundHeaderの定義

outboundHeaderの実際の内容には変数(特に${eol})を使用できます。headerLinesおよびoutboundHeaderの両方が使用可能な場合、アウトバウンドではoutboundHeaderが優先されます。

注意:

インバウンド方向では、ヘッダー・スキップ機能がサポートされています。他の変数はアクセスできないか、リテラルのみが含まれているため、ヘッダーで使用できるのは事前定義済の変数のみです。

入力XML

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<PersonName>Fred</PersonName>
<Address>2 Old Street, Old Town,Manchester</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</terminated>

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
nxsd:hasHeader="true"
nxsd:outboundHeader="This is a header ${eol}">

<element name="terminated">
<complexType>
<sequence>
<element name="PersonName" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;" />
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;"/>
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>

</schema>

変換されたデータ

This is a header
Fred,"2 Old Street, Old Town,Manchester",20-08-1954,0161-499-1718

6.2.2.16 conditionValueでの複雑な条件の定義

choiceConditionコンストラクトとともにconditionValueコンストラクトを使用すると、ブール演算子ANDおよびORとともに「等しい」(==)または「等しくない」(!=)などの一致基準を指定して、読み取った値とconditionValueコンストラクトに指定した値を比較できます。

変換されるネイティブ・データ・フォーマット

Order, ID41678, 20May2000
Item1, GigaWidget, 60, $75
Item2, MegaBucket, 48, $125
Cust1, Hopkins Associates, ID26490
Order, ID41680, 20May2000
Item3, Rt.Clopper, 40, $100
Item4, Lt.Clopper, 50, $100
Cust2, Jersey WebInovaters, ID46786

ネイティブ・スキーマ

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/extensions/SampleNS"
xmlns:tns="http://xmlns.oracle.com/pcbpel/nxsd/extensions/SampleNS"
elementFormDefault="qualified"
attributeFormDefault="unqualified" nxsd:encoding="US-ASCII"
nxsd:stream="chars" nxsd:version="NXSD">

<xsd:element name="Container">
<xsd:complexType>
<xsd:choice minOccurs="1" maxOccurs="unbounded"
nxsd:choiceCondition="terminated" nxsd:terminatedBy=",">
<xsd:element name="Customer" nxsd:conditionValue="(== Cust1) or (== Cust2)
and (!= emp)">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="C1" type="xsd:string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="C2" type="xsd:string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy="&quot;">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Item" nxsd:conditionValue="(== Item1) or (== Item2) or
(==Item3) or (== Item4)">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="C1" type="xsd:string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="C2" type="xsd:string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="C3" type="xsd:string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy="&quot;">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Order" nxsd:conditionValue="Order">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="C1" type="xsd:string" nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="C2" type="xsd:string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy="&quot;">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:schema>

ネイティブ・スキーマを使用して変換したXML

<Container xmlns="http://xmlns.oracle.com/pcbpel/nxsd/extensions/SampleNS">
<Order>
<C1> ID41678</C1>
<C2> 20May2000</C2>
</Order>
<Item>
<C1> GigaWidget</C1>
<C2> 60</C2>
<C3> $75</C3>
</Item>
<Item>
<C1> MegaBucket</C1>
<C2> 48</C2>
<C3> $125</C3>
</Item>
<Customer>
<C1> Hopkins Associates</C1>
<C2> ID26490</C2>
</Customer>
<Order>
<C1> ID41680</C1>
<C2> 20May2000</C2>
</Order>
<Item>
<C1> Rt.Clopper</C1>
<C2> 40</C2>
<C3> $100</C3>
</Item>
<Item>
<C1> Lt.Clopper</C1>
<C2> 50</C2>
<C3> $100</C3>
</Item>
<Customer>
<C1> Jersey WebInovaters</C1>
<C2> ID46786</C2>
</Customer>
</Container>

6.2.2.17 choiceConditionでの複雑な条件の定義

choiceConditionコンストラクトは、フィールドが複数タイプのデリミタで区切られている複雑なレコードに対し、conditionValueコンストラクトとともに使用されます。複数タイプ以外にchoiceConditionに使用できるタイプは、FixedLength、VariableおよびAd hocです。次の例に、variableタイプのchoiceConditionを示します。

変換されるネイティブ・データ・フォーマット

Name1,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES
Name2,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO

ネイティブ・スキーマ

<element name="LookAhead">
<complexType>
<choice maxOccurs="unbounded" nxsd:choiceCondition="${x}" nxsd:lookAhead="70" nxsd:scanLength="3" nxsd:assignTo="${x}">
<element name="Record1" type="string" nxsd:conditionValue="YES" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:skipMode="after" nxsd:skipUntil="${eol}" />
<element name="Record2" type="string" nxsd:conditionValue="NO " nxsd:style="terminated" nxsd:terminatedBy="," nxsd:skipMode="after" nxsd:skipUntil="${eol}" />
</choice>
</complexType>
</element>

ネイティブ・スキーマを使用して変換したXML

<LookAhead xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<Record1>Name1</Record1>
<Record2>Name2</Record2>
</LookAhead>

6.2.2.18 dataLinesの定義

データ全体ではなくデータの一部のみを変換することが要件の場合は、dataLinesコンストラクトを使用して、ファイルの先頭を基準として無視する行数とその位置から変換する行数を指定できます。

変換されるネイティブ・データ・フォーマット

Fred,addr,20-08-1954,0161-499-1718
Tam,addr,20-08-1954,0161-499-1718
Albert,addr,20-08-1954,0161-499-1718
Bill,addr,20-08-1954,0161-499-1718
Phil,addr,20-08-1954,0161-499-1718

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"

nxsd:headerLines="1"
nxsd:dataLines="1">

<element name="terminated">
<complexType>
<sequence maxOccurs="unbounded">
<element name="PersonName" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="Address" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="DOB" type="string" nxsd:style="terminated"
nxsd:terminatedBy="," />
<element name="Telephone" type="string" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<terminated xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<PersonName>Tam</PersonName>
<Address>addr</Address>
<DOB>20-08-1954</DOB>
<Telephone>0161-499-1718</Telephone>
</terminated>

6.2.2.19 タイムゾーンを使用した日付書式の定義

トランスレータでは、日付または時刻がタイムゾーンに関連付けられている必要があります。トランスレータでは、ネイティブ・データの日付とXMLの日付の両方について、タイムゾーンを使用した日付書式がサポートされています。

日付/時間文字列の変換時には、2つの部分があります。第1の部分はネイティブ・データの日付の書式(dateformat)で、第2の部分は第1の部分の解析に使用するタイムゾーン(timeZoneまたはuseTimeZone)です。トランスレータでは、これらの詳細が日付/時間文字列の解析中に使用されます。

デフォルトでは、解析後に日付文字列がXMLのISO-8601フォーマットに変換されます。このデフォルトは、XMLDateFormatとXMLTimeZoneまたはuseTimeZoneを使用してオーバーライドできます。

変換されるネイティブ・データ・フォーマット

11/16/0224/11/02
11-20-2002
23*11*2002
01/02/2003 01:02
01/02/2003 03:04:05
Thu, 26 May 2005 15:50:11 India Standard Time
Do, 26 Mai 2005 15:43:10 Indische Normalzeit
20063202
11/16/02

ネイティブ・スキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="dateformat">
<complexType>
<sequence>
<element name="StartDate" type="date" nxsd:dateFormat="MM/dd/yy"
nxsd:localeLanguage="en" nxsd:style="fixedLength" nxsd:length="8" />

<element name="EndDate" type="date"   nxsd:dateFormat="dd/MM/yy"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />

<element name="Milestone" type="dateTime" nxsd:useTimeZone="UTC"
nxsd:dateFormat="MM-dd-yyyy" nxsd:style="terminated"        nxsd:terminatedBy="${eol}" />

<element name="DueDate" type="dateTime" nxsd:useTimeZone="UTC"
nxsd:dateFormat="dd*MM*yyyy" nxsd:style="terminated" nxsd:terminatedBy="${eol}" />

<element name="Date" type="dateTime" nxsd:useTimeZone="UTC"
nxsd:dateFormat="MM/dd/yyyy hh:mm" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />

<element name="Date" type="dateTime" nxsd:useTimeZone="UTC"
nxsd:dateFormat="MM/dd/yyyy hh:mm:ss" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />

<element name="LongDateInEnglish" type="dateTime"
nxsd:displayTimeZone="true" nxsd:useTimeZone="IST" nxsd:dateFormat="EEE, d MMM
yyyy HH:mm:ss zzzz" nxsd:localeLanguage="en" nxsd:localeCountry="US"
nxsd:style="terminated" nxsd:terminatedBy="${eol}" />

<element name="LongDateInGerman"  type="dateTime"
nxsd:displayTimeZone="true" nxsd:useTimeZone="IST" nxsd:dateFormat="EEE, d MMM
yyyy HH:mm:ss zzzz" nxsd:localeLanguage="de" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />

<element name="InvalidDate" type="dateTime" nxsd:useTimeZone="UTC"
nxsd:dateParsingMode="lax" nxsd:dateFormat="yyyyMMdd" nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />

<element name="MyFormatDate" type="string" nxsd:dateFormat="MM/dd/yy"
nxsd:xmlDateFormat="dd-MM-yyyy" nxsd:localeLanguage="en" nxsd:style="fixedLength"
nxsd:length="8" />

</sequence>
</complexType>
</element>

</schema>

ネイティブ・スキーマを使用して変換したXML

<dateformat xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<StartDate>2002-11-16</StartDate>
<EndDate>2002-11-24</EndDate>
<Milestone>2002-11-20T00:00:00</Milestone>
<DueDate>2002-11-23T00:00:00</DueDate>
<Date>2003-01-02T01:02:00</Date>
<Date>2003-01-02T03:04:05</Date>
<LongDateInEnglish>2005-05-26T15:50:11+05:30</LongDateInEnglish>
<LongDateInGerman>2005-05-26T15:43:10+05:30</LongDateInGerman>
<InvalidDate>2008-08-02T00:00:00</InvalidDate>
<MyFormatDate>16-11-2002</ MyFormatDate >
</dateformat>

6.2.2.20 変換中の検証の実装

変換中の検証を実装するように構成する必要があります。検証により、変換中に無効なメッセージがパブリッシュされないことを保証できます。

次のタイプの検証の一方または両方を実装できます。

- ペイロード検証

- スキーマ検証

6.2.2.20.1 ペイロード検証

ペイロード検証では、Oracle JCAアダプタにより処理される入力と出力のXMLメッセージを検証する必要があります。ペイロード検証は、次のいずれかのレベルで設定できます。

- トップレベル検証

- フィールドレベル検証
NXSDレイヤー(nxsd:validateのトップレベルのフラグを使用)またはサービス・エンジン・レイヤーのいずれかで検証を実行できます。サービス・エンジン・レイヤー検証の詳細は、『Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

トップレベル検証

トップレベル検証では、DOMResult (Document Object Model形式の結果)がXMLスキーマと対照して検証されます。この形式の検証は、インバウンド・ペイロードとアウトバウンド・ペイロードの両方について実装されます。また、この形式の検証では、無効なレコードのパブリッシュを制御してXML検証エラーに関する情報を提供できます。ただし、変換コンテキストは提供されません。たとえば、ネイティブ・ストリーム内でエラーが発生した行と列の情報は、トップレベル検証では提供されません。

XMLメッセージのトップレベル検証を実装するには、次のようにします。

- メッセージのnxsdネームスペースを次のように設定する必要があります。

xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"

- 検証フラグを次のようにtrueに設定する必要があります。

nxsd:validation="true"

次に例を示します。

<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
nxsd:validation="true"
>

フィールドレベル検証

フィールドレベル検証では、個々のフィールドがXMLスキーマと対照して検証されます。この形式の検証はインバウンド・ペイロードについてのみ実装され、アウトバウンド・ペイロードについては実装されません。

XMLメッセージがXMLスキーマに準拠していない場合は、エラーが発生した正確な行と文字に関する情報が表示されます。

XMLメッセージのフィールドレベル検証を実装するには、次のようにします。

- メッセージのnxsdネームスペースを次のように設定する必要があります。

xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"

- 検証フラグを次のようにtrueに設定する必要があります。

nxsd:fieldValidation="true"

次に例を示します。

<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
nxsd:fieldValidation="true"
>

6.2.2.20.2 スキーマ検証

スキーマ検証では、変換対象のネイティブまたはXMLデータ・フォーマットに対して定義したスキーマ(ネイティブ・スキーマまたはXMLスキーマ)を検証する必要があります。

スキーマ検証を有効化するには、次のようにします。

- メッセージのnxsdネームスペースを次のように設定する必要があります。

xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"

- nxsd検証フラグを次のようにtrueに設定する必要があります。

nxsd:validateNxsd="true"

次に例を示します。

<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
nxsd: validateNxsd ="true"
>

注意:

nxsd:validateNxsd="true"検証フラグは、ペイロード・レベルの検証に影響しません。

6.2.2.21 BOMを使用したファイルの処理

バイト順マーク(BOM)は、バイト・シーケンスのエンコーディングを記述する特殊なU+FEFF Unicode文字です。ネイティブ・フォーマット・トランスレータは、ネイティブ入力データのキャラクタ・エンコーディングの判別にBOMを使用するように構成できます。デフォルトでは、BOMは使用されません。入力データにBOMが使用される場合は、ネイティブ・スキーマ内でnxsd:parseBom属性をtrueに設定します。このように設定しなければ、トランスレータでは解析エラーがスローされます。

サンプルのnxsdファイルを次に示します。

<?xml version= '1.0' encoding= 'UTF-8' ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://TargetNamespace.com/InboundService"
targetNamespace="http://TargetNamespace.com/InboundService"
elementFormDefault="qualified" attributeFormDefault="unqualified"
nxsd:parseBom="true" nxsd:version="NXSD" nxsd:stream="chars"
nxsd:encoding="UTF8">
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="mydata" minOccurs="1" maxOccurs="unbounded"
nxsd:style="array"
nxsd:cellSeparatedBy="${eol}">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="C1" type="xsd:string"
nxsd:style="fixedLength"
nxsd:length="3"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

6.2.3 インバウンドおよびアウトバウンド・ネイティブ・データのマルチバイト変換

ネイティブ・フォーマット・ビルダーは、文字でインバウンドの固定長ネイティブ・データを処理します。トランスレータは、内部で文字データを使用します。12cのマルチバイト・ストリーミングのサポートにより、文字ではなくバイトでフィールドの長さを指定できます。これにより、インバウンドOracleトランスレータは、バイトとしてデータを読取り、使用されるエンコーディングに基づいて文字に変換できます。同様に、アウトバウンド・トランスレータはXMLデータを(文字ではなく)バイトに変換し、出力ストリームに書き込みます。

6.2.3.1 初期の問題

しかし、バイトとしてフィールド長を指定したり、バイトによる長さの指定が必要な固定長データを処理することが必要な場合もあります。固定長バイナリ・データでは、文字の長さを指定しても意味がないため、バイトでの指定はとても役に立ちます。

これは、シングルバイト・キャラクタ・セットでは問題になりませんが、バイト単位の長さは文字単位の長さとは等しくないため、マルチバイト・キャラクタ・セットでは問題になります。

6.2.3.2 解決策

この問題を解決してバイトでフィールド長を指定できるようにするために、NXSDトランスレータはバイトでのフィールド長の指定をサポートしています。特に、長さの単位は、ByteまたはCharのいずれかで指定できます。デフォルト値はCharです。この単位の長さを指定するには、次の規則を使用します。

nxsd:lengthUnits="Byte|Char"

Byteではフィールド長がバイトによって変換されるように指定され、Charではフィールド長が文字によって指定されることが示されています。

インバウンドとアウトバウンドの両方のマルチバイト変換に指定するファイルは、手動で変更する必要があります。ネイティブ・フォーマット・ビルダーのユーザー・インタフェースからは実行できません。

6.2.3.3 パディング・データの指定

インバウンド・データをパディング・データとして指定することもできます。これを行うと、トランスレータによってパディング・データの発生がすべて取り除かれます。

この機能を使用するには、取り除かれるパディング・バイト・データの書式をトランスレータで把握できるようにする必要があります。そのためには、次の規則を使用します。

nxsd:paddedDataType="decimal|binary|octal|hexbinary|string" nxsd:paddedBy="XYZ"

次の表に、入力として指定できるパディング・データ型の書式の説明を示します。

書式

説明

10進

パディング・データを10進数の書式で指定します。パディングされるバイトに対応する10進数の値を指定する必要があります。

各10進数は、nnnの書式で表します(例: 32は032と表します)。複数の数字を指定する場合は、各数字を同じ書式にする必要があります(例: 001002123は3バイト(1、2および123)を意味します)。

nxsd:paddedDataType="decimal" nxsd:padStyle="head"
nxsd:paddedBy='032032'

バイナリ

パディング・データを2進数の書式で指定します。パディングされるバイトに対応する2進数の値を指定する必要があります。パディング・データを1バイトを超えて指定する場合は、各バイトに対応する長さを8にする必要があります。次に例を示します。

nxsd:paddedDataType="binary" nxsd:padStyle="head" nxsd:paddedBy='0010000000100000'/

8進

パディング・データを8進数の書式で指定します。パディングされるバイトに対応する8進数の値を指定する必要があります。パディング・データを1バイトを超えて指定する場合は、各バイトに対応する長さを3にする必要があります。例:

nxsd:paddedDataType="octal" nxsd:padStyle="head" nxsd:paddedBy='040040'

16進

パディング・データを16進数の書式で指定します。パディングされるバイトに対応する16進数の値を指定する必要があります。パディング・データを1バイトを超えて指定する場合は、各バイトに対応する長さを2にする必要があります。例:

nxsd:paddedDataType="hexBinary" nxsd:padStyle="head" nxsd:paddedBy='2020'

string

パディング・データを文字列の書式で指定します。トランスレータは、スキーマ・レベルで指定されたエンコーディング(nxsd:encoding)を使用します。例:

nxsd:paddedDataType="string" nxsd:padStyle="head"nxsd:paddedBy='

注意:

paddedDataType="string"の場合のみ、パディングでSJIS文字を使用できることに注意してください。

6.2.3.4 接頭辞または接尾辞の指定

受信データに追加される可能性がある接頭辞および接尾辞は、XMLにパブリッシュされる前に指定することもできます。これを行うには、次の規則を使用します。

nxsd:prefixWith="XXXX" nxsd:suffixWith="YYYY"

注意:

FixedLengthスタイルのバイト・モードでデータの読取り/書込みをする間は、base64BinaryデータおよびhexBinaryデータを使用した接頭辞と接尾辞の指定がトランスレータではサポートされません。

6.2.3.5 マルチストリーム・データによるトランスレータの動作

トランスレータの動作は、XMLにパブリッシュされるデータのタイプに依存します。たとえば、次のようにタイプを指定できます。

type="xsd:string|xsd:hexBinary|xsd:base64Binary"

データ・タイプがstringに指定されている場合は、入力ストリームに対して指定されたバイト数がトランスレータによって読み取られます。

ただし、入力ストリームに十分なデータが含まれていない場合は、トランスレータによって例外がスローされます。

指定されたバイト数がトランスレータによって読み取られると、その読み取ったバイトからパディング・データがすべて取り除かれます。パディング・データを削除した後に、トランスレータは残りのバイトを文字に変換します。

残りのバイトが文字境界に一致しないか、または残りのバイトがなんらかの理由で文字に変換できない場合は、トランスレータにより例外がスローされます。

データを文字に変換することに成功した場合、それらの文字はXMLにパブリッシュされます。

指定するデータ・タイプがhexBinaryまたはbase64Binaryの場合は、パディング・データの削除後に、トランスレータによって残りのバイトが指定されたデータ・タイプに変換され、さらにXMLにパブリッシュされます。

6.2.3.6 アウトバウンド変換の動作

アウトバウンド変換では、バイトでフィールド長を指定できます。トランスレータにより、XML内で指定されたデータに対応するバイトが生成されます。

データがバイトに変換されると、トランスレータではまず接頭辞または接尾辞(存在する場合)が削除されます。

文字列タイプ(スキーマでxsd:hexBinaryまたはxsd:base64Binaryとして定義されていない要素)では、パディングおよび書出しのために値をバイトに変換する前に接頭辞と接尾辞が削除されます。

バイナリ・タイプでは、接頭辞と接尾辞は前述のとおり使用できません。

トランスレータは、スキーマで指定された長さに従って生成されたバイト数をチェックします。生成されたバイト数がスキーマで指定されたものより大きい場合は、トランスレータによって例外がスローされます。

生成されたバイトが長さで指定されたものより小さい場合は、トランスレータにより、生成されたバイトの開始位置または終了位置にpaddedByデータがスキーマの指定に従って追加されます。

6.2.3.7 例

次の例は、変換を表すXSD、XMLおよびテキスト・ファイルを示しています。

6.2.3.7.1 Base 64バイナリ・パディング・データ

次の例は、Base 64バイナリ・パディング・データの変換を示しています。XSDで、トランスレータはnxsd:paddedDataType=を使用して文字列を削除するよう指示されます

<?xml version="1.0" encoding="SJIS"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/test"
xmlns:tns="http://xmlns.oracle.com/test"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="bytes" nxsd:version="NXSD"
nxsd:encoding="SJIS" >
<xsd:element name="root">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:length="14"
nxsd:lengthUnit="byte" nxsd:paddedDataType="string"
nxsd:padStyle="head" nxsd:paddedBy="‚Ì"/>
<xsd:element name="field2" type="xsd:base64Binary"
nxsd:style="fixedLength" nxsd:length="13"
nxsd:lengthUnit="byte"
nxsd:paddedDataType="string"
nxsd:padStyle="tail"
nxsd:paddedBy="‚Ì"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

XMLは次のとおりです

<root xmlns="http://xmlns.oracle.com/test">
<field1>g32Di4Ngg2+DQ4Nn</field1>
<field2>IILMg1SDfIFbg2c=</field2>
</root>

6.2.3.7.2 バイナリ

次の例は、複数フィールドのバイナリ・データの変換を示しています。

XSDは次のとおりです。フィールド長を示すnxsd:lengthUnits="Byte"はバイトで変換されます。

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://style.onron.com/pcbpel/demo"
xmlns:tns="http://style.onron.com/pcbpel/demo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"              nxsd:stream="bytes" nxsd:version="NXSD"
nxsd:encoding="SJIS"
>
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:length="10"
nxsd:lengthUnit="Byte"/>
<xsd:element name="field2"
type="xsd:base64Binary" nxsd:style="fixedLength"
nxsd:length="10"
nxsd:lengthUnit="Byte"/>
<xsd:element name="field3" type="xsd:hexBinary"
nxsd:style="fixedLength" nxsd:length="20"
nxsd:lengthUnit="Byte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

XMLは次のとおりです。

<Root-Element xmlns="http://style.onron.com/pcbpel/demo">
<field1>gqCCooKkICAgIA==</field1>
<field2>gqmCq4KtICAgIA==</field2>
<field3>82BD82BF82C282C482C620202020202020202020
</field3>
</Root-Element>

6.2.3.7.3 シフトJISエンコーディング

次の例は、バイトでのシフトJISエンコーディングを示しています。

XSDは次のとおりです。

<?xml version="1.0" encoding="SJIS"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/
pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/
test"
xmlns:tns="http://xmlns.oracle.com/test"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="bytes"
nxsd:version="NXSD"
nxsd:encoding="SJIS" >
<xsd:element name="root">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1"
type="xsd:hexBinary"
nxsd:style="fixedLength"
nxsd:length="14" nxsd:lengthUnit="byte"
nxsd:paddedDataType="string"
nxsd:padStyle="head"
nxsd:paddedBy="‚Ì"/>
<xsd:element name="field2"
type="xsd:hexBinary"
nxsd:style="fixedLength"
nxsd:length="13"
nxsd:lengthUnit="byte"
nxsd:paddedDataType="string"
nxsd:padStyle="tail"                   nxsd:paddedBy="‚Ì"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

対応するXMLは次のとおりです。

<root xmlns="http://xmlns.oracle.com/test">
<field1>837D838B8360836F83438367</field1>
<field2>2082CC8354837C815B8367</field2>
</root>

6.2.3.7.4 識別子の長さの例

IdentifierLengthコンストラクトは実際のデータの長さが保存される文字数およびバイト数を示し、lengthUnitによりバイトでフィールド長を指定できます。

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://style.onron.com/pcbpel/demo"
xmlns:tns="http://style.onron.com/pcbpel/demo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="bytes" nxsd:version="NXSD"
nxsd:encoding="SJIS"
>

<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1" type="xsd:string"
nxsd:style="fixedLength"
nxsd:identifierLength="2"
nxsd:lengthUnit="Byte"/>
<xsd:element name="field3" type="xsd:string"
nxsd:style="fixedLength"
nxsd:identifierLength="2"
nxsd:lengthUnit="Byte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

6.2.3.7.5 識別子の例(base64BInary)

次の例は類似したIdentifierlength文を示していますが、タイプがbase64Binaryである部分が異なります。

XSDは次のとおりです。

<?xml version="1.0" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://style.onron.com/pcbpel/demo"
xmlns:tns="http://style.onron.com/pcbpel/demo"
elementFormDefault="qualified"
attributeFormDefault="unqualified" nxsd:stream="bytes" nxsd:version="NXSD"
nxsd:encoding="SJIS"
>

<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1" type="xsd:base64Binary"                  nxsd:style="fixedLength" nxsd:identifierLength="2"
nxsd:lengthUnit="Byte"/>
<xsd:element name="field3" type="xsd:hexBinary"
nxsd:style="fixedLength"
nxsd:identifierLength="2" nxsd:lengthUnit="Byte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

XMLは次のとおりです。

<Root-Element xmlns="http://style.onron.com/pcbpel/demo">
<field1>gqCCooKkICAgIA==</field1>
<field3>82BD82BF82C282C482C620202020202020202020</field3>
</Root-Element>

6.2.3.7.6 識別子: SJISを使用したパディング・データ

次に類似した識別子の例を示しますが、パディング・データ(32文字にパディング)を使用し、SJISエンコーディングに変換する部分が異なります。

XSDは次のとおりです。

<?xml version="1.0" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://style.onron.com/pcbpel/demo"
xmlns:tns="http://style.onron.com/pcbpel/demo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="bytes" nxsd:version="NXSD"
nxsd:encoding="SJIS"
>
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1" type="xsd:string"
nxsd:style="fixedLength" nxsd:identifierLength="2" nxsd:lengthUnit="Byte" nxsd:padStyle="head" nxsd:paddedBy='32'/>
<xsd:element name="field3" type="xsd:string"
nxsd:style="fixedLength"
nxsd:identifierLength="2"
nxsd:lengthUnit="Byte"
nxsd:padStyle="tail"
nxsd:paddedBy='32'/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

6.2.3.7.7 識別子: バイナリのパディング

もう1つの識別子の例は、パディングされるバイナリ・データを示しています。

この例のXSDは次のとおりです。

<?xml version="1.0" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://style.onron.com/pcbpel/demo"
xmlns:tns="http://style.onron.com/pcbpel/demo"
elementFormDefault="qualified"
attributeFormDefault="unqualified" nxsd:stream="bytes" nxsd:version="NXSD"
nxsd:encoding="SJIS"
>
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:identifierLength="2"
nxsd:lengthUnit="Byte" nxsd:padStyle="head"
nxsd:paddedBy='32'/>
<xsd:element name="field3" type="xsd:hexBinary"
nxsd:style="fixedLength" nxsd:identifierLength="2" nxsd:lengthUnit="Byte" nxsd:padStyle="tail"
nxsd:paddedBy='32'/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

XMLは次のとおりです。

<Root-Element xmlns="http://style.onron.com/pcbpel/demo">
<field1>gqmCq4KC</field1>
<field3>82BD82BF82C282C482C6</field3>
</Root-Element>

6.2.3.7.8 マルチバイト・バイナリ要素のパディング

マルチバイト・バイナリのパディングのXSDは次のとおりです。

<?xml version="1.0" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://style.onron.com/pcbpel/demo"
xmlns:tns="http://style.onron.com/pcbpel/demo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="bytes"
nxsd:version="NXSD"
nxsd:encoding="SJIS"
nxsd:validateNxsd="true">

<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:length="10" nxsd:lengthUnit="Byte" nxsd:paddedDataType="binary" nxsd:padStyle="head" nxsd:paddedBy='0010000000100000'/>

<xsd:element name="field2" type="xsd:hexBinary"
nxsd:style="fixedLength" nxsd:length="20"
nxsd:lengthUnit="Byte" nxsd:padStyle="tail"
nxsd:paddedDataType="binary"
nxsd:paddedBy='0010000000100000'/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

XMLは次のとおりです。

<Root-Element xmlns="http://style.onron.com/pcbpel/demo">
<field1>gqmCq4Kt</field1>
<field2>82BD82BF82C282C482C6</field2>
</Root-Element>

6.2.3.7.9 マルチバイトの10進数のパディング

マルチバイトの10進数のパディングのXMLは次のとおりです。

<?xml version="1.0" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://style.onron.com/pcbpel/demo"
xmlns:tns="http://style.onron.com/pcbpel/demo"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="bytes"
nxsd:version="NXSD"
nxsd:encoding="SJIS">

<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="field1" type="xsd:base64Binary" nxsd:style="fixedLength" nxsd:length="10"
nxsd:lengthUnit="Byte"
nxsd:paddedDataType="decimal"
nxsd:padStyle="head"
nxsd:paddedBy='032032'/>
<xsd:element name="field2" type="xsd:hexBinary"
nxsd:style="fixedLength" nxsd:length="20"
nxsd:lengthUnit="Byte" nxsd:padStyle="tail"
nxsd:paddedDataType="decimal"
nxsd:paddedBy='032032'/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

6.2.4 SOSIサポート

トランスレータは、入力ストリームからバイト(SHIFT_OUT、SHIFT_IN)をエスケープするためのサポートも提供しています。

このサポートは、特にSJISエンコーディングをサポートするために提供されており、このエンコーディングでは、混在2バイト・キャラクタ・セット・モードで、モードの変更(1バイトから2バイト)を示すために、SHIFT_OUTバイトおよびSHIFT_INバイトがデータに挿入されます。

トランスレータでSOSIサポートを使用するには、次の規則を使用します。

nxsd:escapeBytes="sosi"

paddedDataType="string"の場合のみ、パディングでSJIS文字を使用できることに注意してください。

6.3 トランスレータXPath関数

トランスレータXPath関数では、データをネイティブ・フォーマット(CSV、固定長、タブ区切り、COBOLコピーブックなどのフォーマット)からXMLフォーマットに、およびXMLフォーマットからネイティブ・フォーマットに変換できます。トランスレータXPath関数には、ストリーミングと非ストリーミングの2タイプがあります。

違いは、ストリーミング・トランスレータXPath関数はバッチ処理によるトランスフォーメーション・アプローチを実行するのに対して、非ストリーミングXPath関数はこのアプローチを実行しないことです。バッチ処理によるトランスフォーメーション・アプローチでは、数GB程度のファイルをメモリー問題が発生することなく処理できます。

この項には次のトピックが含まれます:

- 用語

- トランスレータXPath関数

6.3.1 用語

この項では、トランスレータXPath関数の使用について理解しておく必要のある用語を説明します。

添付要素

他の場所にあり"href"属性で参照される実際のコンテンツを、添付要素と呼ぶことがあります。実際のコンテンツは、ファイルシステムやデータベース表などに存在します。

添付は通常、次のスキーマ・コンストラクトを使用して表現されます。

<element name="hrefelement">
<complexType>
<attribute name="href" type="string"/>
</complexType>
</element>

"href"属性には、参照されるデータの実際の場所を指定します。ファイルシステム内のファイルへのパスや、データベース・エンティティへのポインタ(主キー)を指定できます。

スケーラブルなDOM

スケーラブルなDOM (SDOM)は、Oracle XML Developer Kit (Oracle XDK)に含まれていて、DOMがスケーラブルかつプラガブルにサポートされます。このため、メモリーの不足およびスケーラビリティの制限という問題が解消され、DOM構成の制御が可能になります。

Oracle XDKは、遅延実体化メカニズムを使用して、アクセスされるノードを作成し、未使用のノードをメモリーから解放するだけです。スケーラビリティが向上するため、非常に大きなXML文書も処理可能です。

6.3.2 トランスレータXPath関数

ファイルの読取りおよび書込み中にトランスレータが必要になる場合があります。この項では、次のトランスレータXPath関数について説明します。

- doTranslateFromNative関数

- doTranslateToNative関数

- doStreamingTranslate関数

6.3.2.1 doTranslateFromNative関数

doTranslateFromNative XPath関数は、入力データをXMLに変換します。入力データとしては、文字列、添付要素またはbase64Binary要素を使用できます。

ora:dotranslateFromNative('input','nxsdTemplate','nxsdRoot','targetType','attachment element?')

次の表では、前述の構文で使用されているこの関数のパラメータについて説明します。

パラメータ

説明

input

XPath関数の入力データ。データとしては、変換する必要がある文字列データ、添付、外部ファイル・パスを参照する添付、またはbase64Binary要素を使用できます。

nxsdTemplate

入力データからXMLフォーマットへの変換に使用するNXSDスキーマ。

nxsdRoot

NXSDスキーマ内のルート要素。

targetType

このパラメータは、XPath関数がネイティブ・データをXMLに変換する方法を指定します。'DOM'、'ATTACHMENT'または'SDOM'に設定する必要があります。次のように、targetTypeパラメータの設定に応じた処理が行われます。

- 'DOM': 変換したデータをDOMとして返します。

- 'ATTACHMENT': 変換したデータを添付として返します。XPath関数にオプション・パラメータ(attachmentElement)が指定されている場合、XPath関数は対応するhref属性を使用して、変換したXMLを書き込みます。これに対して、このパラメータが未指定の場合は、XPath関数はデータベース・ベースの新しい添付を作成し、これを返します。詳細は、次の例を参照してください。

- 'SDOM': 変換したデータをSDOMとして返します。これは、返されるXMLファイルが非常に大きい場合は使用が必須です。

attachmentElement

このパラメータはオプションです。これは、返されるXMLファイルの添付です。

例 - XPath関数の構成: 入力データが文字列タイプで、XML DOMに変換する必要がある場合

<variables>
<variable…/>
<variable name="csv_data" type="xsd:string"/>
</variables>
<assign name="assignCSVData">
<copy>
<from expression="'this, is, csv, data…'"/>
<to variable="csv_data"/>
</copy>
</assign>

<assign name="doTranslateFromNativeCall">
<copy>
<from expression="ora: doTranslateFromNative               (bpws:getVariableData('csv_data'),                  'xsd/address-csv.xsd',                    'Root-Element','DOM')"/>
<to variable="returnVariable" query="/ns1:Root-Element"/>
</copy>
</assign>

この例の説明は、次のとおりです。

- csv_dataは、XMLに変換するCSVデータを含んでいるBPEL変数です。

- xsd/address-csv.xsdは、プロジェクト内のNXSDスキーマへの相対パスです。

- Root-Elementは、NXSDスキーマ内のルート要素です(オプション)。

- returnVariableは、DOMとして返されるXMLデータです。

例 - 入力データが添付で、DOMに変換する必要がある場合

1. attachmentElementをBPELプロセスのスキーマに次のように定義します。

<schema targerNamespace="…">
<element name="attachmentElement">
<complexType>
<attribute name="href" type="string"/>
</complexType>
</element>
</schema>

2. タイプが添付要素の変数をBPELプロセスのスキーマに次のように作成します。

<variables>
<variable…/>
<variable name="attachmentVariable"          type="client:attachmentElement"/>
</variables>

3. 変換する必要があるソース・ファイルのパスを次のように割り当てます。

<assign name="AssignAttachmentReference">
<copy>
<from expression="'/tmp/xpath/in/address.csv'"/>
<to variable="attachmentVariable"
query="/client:attachmentElement/@href"/>
</copy>
</assign>

4. XPath関数を次のようにコールします。

<assign name="xlateFromNative">
<copy>
<from expression="ora:doTranslateFromNative        (bpws:getVariableData('attachmentVariable'),          'xsd/address-csv.xsd', 'Root-Element', 'DOM')"/>
<to variable="returnVariable" query="/ns1:Root-Element"/>
</copy>
</assign>

この例の説明は、次のとおりです。

- attachmentVariableは、ソース・ファイルのパスを参照するBPEL内の添付変数です。

- xsd/address-csv.xsdは、プロジェクト内のNXSDスキーマへの相対パスです。

- Root-Elementは、NXSDスキーマ内のルート要素です。

- returnVariableは、DOMとして返されるXMLデータです。

例 - XPath関数の構成: 入力データがBase64でエンコードされていて、DOMに変換する必要がある場合

1. base64でエンコードされている要素をBPELプロセスのスキーマに次のように定義します。

<schema targerNamespace="…">
<element name="mtomElement" type="base64Binary"/>
</schema>

2. タイプがmtom要素の変数をBPELプロセスのスキーマに次のように作成します。

<variables>
<variable…/>
<variable name="encodedData" type="client:mtomElement"/>
</variables>

3. 変換する必要があるソース・ファイルのパスを次のように割り当てます。

<assign name="assignBase64EncodedData">
<copy>
<from expression="'b3JhY2xl'"/>
<to variable="encodedData"              query="/client:mtomElement"/>
</copy>
</assign>

<assign name="doTranslateFromNativeCall">
<copy>
<from expression="ora: doTranslateFromNative         (bpws:getVariableData('encodedData'), 'xsd/address-csv.xsd','Root-Element','DOM')"/>
<to variable="returnVariable"
query="/ns1:Root-Element"/>
</copy>
</assign>

この例の説明は、次のとおりです。

- mtomElementは、XMLに変換するbase64エンコード・データを含んでいるBPEL変数です。

- xsd/address-csv.xsdは、プロジェクト内のNXSDスキーマへの相対パスです。

- Root-Elementは、NXSDスキーマ内のルート要素です。

- returnVariableは、DOMとして返されるXMLデータです。

例 - XPath関数の構成: 入力データが文字列タイプで、ファイル・パスで参照される添付に変換する必要がある場合

1. attachmentElementをBPELプロセスのスキーマに次のように定義します。

<schema targerNamespace="…">
<element name="attachmentElement">
<complexType>
<attribute name="href" type="string"/>
</complexType>
</element>
</schema>

2. タイプが文字列の入力変数と、タイプが添付の出力変数を、BPELプロセスのスキーマに次のように作成します。

<variables>
<variable…/>
<variable name="csv_data" type="xsd:string"/>
<variable name="returnAttachmentVariable"
type="client:attachmentElement"/>
</variables>

3. 変換する必要があるCSVデータを次のように割り当てます。

<assign name="assignCSVData">
<copy>
<from expression="'this, is, csv, data…'"/>
<to variable="csv_data"/>
</copy>
</assign>

4. 変換したデータを格納するファイルのパスを次のように添付に移入します。

<assign name="AssignAttachmentReferenceForOutput">
<copy>
<from expression="'/tmp/xpath/output/address.xml'"/>
<to variable=" returnAttachmentVariable "
query="/client:attachmentElement/@href"/>
</copy>
</assign>

5. XPath関数を次のようにコールします。

<assign name="doTranslateFromNativeCall">
<copy>
<from expression="ora: doTranslateFromNative
(bpws:getVariableData('csv_    data'),'xsd/address-csv.xsd','Root-Element','ATTACHMENT',   bpws:getVariableData('returnAttachmentVariable'))"/>
<to variable="returnAttachmentVariable"/>
</copy>
</assign>

この例の説明は、次のとおりです。

- csv_dataは、XMLに変換するCSVデータを含んでいるBPEL文字列変数です。

- xsd/address-csv.xsdは、プロジェクト内のNXSDスキーマへの相対パスです。

- Root-Elementは、NXSDスキーマ内のルート要素です。

- returnAttachmentVariableは、返された添付です。

注意: この例では、targetTypeはATTACHMENTに設定され、returnAttachmentVariableは変換したXMLが書き込まれるファイル・パスを指しています。

ただし、5つ目のパラメータ(bpws:getVariableData('returnAttachmentVariable'))はオプションです。このパラメータが未指定の場合、XPath関数ではデータベース・ベースの添付を作成し、これを返します。これを行うには、XPath関数を次のように構成します。

1. attachmentElementをBPELプロセスのスキーマに次のように定義します。

<schema targerNamespace="…">
<element name="attachmentElement">
<complexType>
<attribute name="href" type="string"/>
</complexType>
</element>
</schema>

2. タイプが文字列の入力変数と、タイプが添付の出力変数を、BPELプロセスのスキーマに次のように作成します。

<variables>
<variable…/>
<variable name="csv_data" type="xsd:string"/>
<variable name="returnAttachmentVariable"
type="client:attachmentElement"/>
</variables>

3. 変換する必要があるCSVデータを次のように割り当てます。

<assign name="assignCSVData">
<copy>
<from expression="'this, is, csv, data…'"/>
<to variable="csv_data"/>
</copy>
</assign>

<assign name="doTranslateFromNativeCall">
<copy>
<from expression="ora: doTranslateFromNative (bpws:getVariableData('csv_data'),'xsd/address-csv.xsd','Root-Element','ATTACHMENT')"/>
<to variable="returnAttachmentVariable"/>
</copy>
</assign>

XPathコールが返された後、データベース・ベースの添付を表すGUIDを指すhref属性がreturnAttachmentVariable変数に移入されます。

注意: 変換中のデータが大きい場合は、XPath関数のtargetTypeパラメータとしてATTACHMENTまたはSDOMを使用する必要があります。

6.3.2.2 doTranslateToNative関数

doTranslateToNative XPath関数は、入力DOMを文字列データまたは添付に変換します。

構文

ora:dotranslateToNative('input','nxsdTemplate','nxsdRoot','targetType','attachmentElement?')

次の表では、前述の構文で使用されているこの関数のパラメータについて説明します。

表6-8 doTranslateToNative関数のパラメータ

パラメータ

説明

input

XPath関数の入力データ。データとしては、CSVなどのネイティブ・フォーマットに変換する必要があるDOMまたはSDOMデータを使用できます。

nxsdTemplate

入力データからXMLフォーマットへの変換に使用するNXSDスキーマ。

nxsdRoot

NXSDスキーマ内のルート要素の名前。

targetType

このパラメータは、XPath関数がXMLデータをネイティブ・フォーマットに変換する方法を指定します。'STRING'または'ATTACHMENT'に設定する必要があります。次のように、targetTypeパラメータの設定に応じた処理が行われます。

- STRING: 変換したデータを文字列として返します。

- ATTACHMENT: 変換したデータを添付として返します。XPath関数にオプション・パラメータ(attachmentElement)が指定されている場合、XPath関数は対応するhref属性を使用して、変換したネイティブ・データを書き込みます。これに対して、このパラメータが未指定の場合は、XPath関数はデータベース・ベースの新しい添付を作成し、これを返します。詳細は、次の例を参照してください。

attachmentElement

このパラメータはオプションです。これは、変換したデータが書き込まれる添付です。

例 - XPath関数の構成: 入力データがXMLフォーマットで、CSV文字列フォーマットに変換する必要がある場合

<variables>
<variable…/>
<variable name="inputDOM" type="ns1:Root-Element"/>
<!- - data that must be translated into native - ->
<variable name="returned_csv_data"
type="xsd:string"/>
</variables>

<assign name="doTranslateToNativeCall">
<copy>
<from expression="ora: doTranslateToNative (bpws:getVariableData('inputDOM'),
'xsd/address-csv.xsd','Root-Element','STRING')"/>
<to variable="returned_csv_data"/>
</copy>
</assign>

この例の説明は、次のとおりです。

- inputDOMは、変換したCSVを表す文字列データに変換するXMLデータを含んでいるBPEL DOM変数です。

- xsd/address-csv.xsdは、プロジェクト内のNXSDスキーマへの相対パスです。

- Root-Elementは、NXSDスキーマ内のルート要素です。

- return_csv_dataは、変換されたCSVデータを含んでいる文字列変数です。

例 - XPath関数の構成: 入力XML DOMを、変換したCSVのターゲット・ファイルのパスを表す添付に変換する場合

1. attachmentElementをBPELプロセスのスキーマに次のように定義します。

<schema targerNamespace="…">
<element name="attachmentElement">
<complexType>
<attribute name="href"
type="string"/>
</complexType>
</element>
</schema>

2. タイプがattachmentElementの入力変数をBPELプロセスのスキーマに次のように作成します。

<variables>
<variable…/>
<variable name="inputDOM"
type="ns1:Root-Element"/>
<variable name="attachmentVariable"
type="client:attachmentElement"/>
</variables>

3. 変換したCSVを書き込むターゲット・ファイルのパスを次のように割り当てます。

<assign name="AssignAttachmentReference">
<copy>
<from expression=
"'/tmp/xpath/out/address.csv'"/>
<to variable="attachmentVariable"
query="/client:attachmentElement/@href"/>
</copy>
</assign>

4. XPath関数を次のようにコールします。

<assign name="xlateToNative">
<copy>
<from expression="ora:doTranslateToNative
(bpws:getVariableData('inputDOM'),'xsd/address-csv.xsd'        'Root-Element', 'ATTACHMENT', bpws:getVariableData
(' attachmentVariable'))"/>
<to variable="attachmentVariable"/>
</copy>
</assign>

この例の説明は、次のとおりです。

- inputDOMは、/tmp/xpath/out/address.csvで表されるCSV出力ファイルに変換するXMLデータを含んでいるBPEL DOM変数です。

- xsd/address-csv.xsdは、プロジェクト内のNXSDスキーマへの相対パスです。

- Root-Elementは、NXSDスキーマ内のルート要素です。

- AttachmentElementは、/tmp/xpath/out/address.csvで表されるターゲット出力ファイルへのパスです。

注意: この例では、targetTypeはATTACHMENTに設定され、AttachmentVariableは変換したCSVファイルが書き込まれるファイル・パスを指しています。

ただし、5つ目のパラメータ(bpws:getVariableData('attachmentVariable'))はオプションです。このパラメータが未指定の場合、XPath関数ではデータベース・ベースの添付を作成し、これを返します。これを行うには、XPath関数を次のように構成します。

1. attachmentElementをBPELプロセスのスキーマに次のように定義します。

<schema targerNamespace="…">
<element name="attachmentElement">
<complexType>
<attribute name="href" type="string"/>
</complexType>
</element>
</schema>

2. タイプがattachmentElementの入力変数をBPELプロセスのスキーマに次のように作成します。

<variables>
<variable…/>
<variable name="inputDOM" type="ns1:Root-Element"/>
<variable name="attachmentVariable"
type="client:attachmentElement"/>
</variables>

3. XPath関数を次のようにコールします。

<assign name="xlateToNative">
<copy>
<from expression="ora:doTranslateToNative
(bpws:getVariableData('inputDOM'),
'xsd/address-csv.xsd', 'Root-Element',
'ATTACHMENT')"/>
<to variable="attachmentVariable"/>
</copy>
</assign>

XPathコールが返された後、データベース・ベースの添付を表すGUIDを指すhref属性がattachmentVariableに移入されます。

6.3.2.3 doStreamingTranslate関数

XPath関数は、バッチ処理によるトランスフォーメーション・アプローチを実行します。このアプローチでは、数GB程度のファイルをメモリー問題が発生することなく処理できます。トランスフォーメーション・エンジンはトランスフォーメーションの結果をそのメモリーに格納しないため、任意の大きさのペイロードを処理できます。トランスフォーメーション・エンジンは、大きなファイルの要素のバッチ処理後に、メモリーをフラッシュします。デフォルトのバッチ・サイズは要素数10000で、トランスフォーメーション・エンジンはこの数の要素を処理するとメモリーをフラッシュします。このパラメータはオプションであり、内部で使用されます。

注意:

バッチ処理によるトランスフォーメーション・アプローチは、繰返し構造のXMLドキュメントに対してのみサポートされています。

構文

ora:doStreamingTranslate('input','streamingXpathContext','targetType','attachmentElement?')

表6-9 に、前述の構文で使用されているこの関数のパラメータを示します。

表6-9 doStreamingTranslateのパラメータ

パラメータ

説明

input

XPath関数の入力データ。データとしては、SDOMまたは添付要素を使用できます。

streamingXpathContext

XPathコンテキストを表すDOM。

targetType

このパラメータは、XPath関数が入力データを添付に変換する方法を指定します。SDOMまたはATTACHMENTに設定する必要があります。

attachmentElement

このパラメータはオプションです。これは、データがストリームされる添付です。

sourceDocumentType

ソース要素がattachmentElementを指している場合は、ATTACHMENTに設定します。

streamingXPathContextパラメータは、ストリーミング・トランスフォーメーションのコンテキストを指定し、次のスキーマ要素に一致する必要があります。

例 - streamingXPathContextが一致する必要のあるスキーマ要素

<schema targetNamespace="…">
<element name="streamingcontext">
<complexType>
<sequence>
<element name="sourceSchema"
type="string"/>
<element name="sourceRootElement"
type="string"/>
<element name="sourceType"
type="string"/>
<element name="sourceDocumentType"
type="string"/>
<element name="xsl"
type="string"/>
<element name="targetSchema"
type="string"/>
<element name="targetRootElement"
type="string"/>
<element name="targetType" type="string"/>
<element name="batchSize" type="string"/>
</sequence>
</complexType>
</element>
</schema>

表6-10 streamingXPathContextパス・パラメータ

パラメータ

説明

sourceSchema

ネイティブ・データからXMLへの変換に使用するソースNXSDスキーマ。

sourceRootElement

ネイティブ・データからXMLへの変換に使用するソースNXSDスキーマ。

sourceType

入力データに応じてxmlまたはnativeに設定します。

xsl

XSLの相対パス。

targetSchema

XMLからネイティブ・データへの変換に使用するターゲットNXSDスキーマ。

targetRootElement

ターゲットNXSDスキーマ内のルート要素の名前。

targetType

出力データに応じてxmlまたはnativeに設定します。

batchSize

トランスフォーメーション・エンジンがメモリーをフラッシュするまでに処理する要素数。

6.3.2.4 バッチ処理によるトランスフォーメーションの特徴

この項では、バッチ処理によるトランスフォーメーションが持つ次の特徴を説明します。

適用性

バッチ処理によるトランスフォーメーションの適用対象は次のとおりです。

- 繰返し構造のドキュメント

- ドキュメント全体の集計が不要なXSLT

XSLTエンジンのバッチ起動

XSLTエンジンのバッチ起動の主な手順は次のとおりです。

1. ソース・ドキュメントを、1つ以上のレコードを含む複数のバッチに分割します。

2. 1度に1つのバッチについてXSLTトランスフォーメーションを実行します。

3. XSLT起動の結果を単一のターゲット・ドキュメントに結合します。

分割または結合の即時実行

ソース・ドキュメントの分割と分割結果のターゲット・ドキュメントへの結合は、次のように実行されます。

- 中間メモリーやディスク記憶域は使用しません。

- SAXイベントのパイプラインまたはインターセプトが行われます。

小さくて済む、メモリーでのフットプリント

バッチ処理によるトランスフォーメーションでは、次のタスクにメモリーをあまり使用しません。

- 任意の大きさ(ターゲット・システムによって制約あり)のXMLドキュメントの変換

- スタンドアロン・テストでは、540MBの変換は3分未満で完了

次の例では、ストリーミング・トランスフォーメーションXPath関数を使用して、FlatStructureファイル・アダプタのサンプルを実装します。このサンプルの使用例では、インバウンドのネイティブ添付をCSVフォーマットからXMLフォーマットに変換してから、生成されたXMLファイルにユーザー指定のXSLファイルを適用します。これにより、変換済XMLファイルは、添付が表す固定長コンテンツに変換されます。

例 - ストリーミング・トランスフォーメーションXPath関数の使用

1. attachmentElementを次のように定義します。
例 - attachmentElementの定義

<schema targerNamespace="…">
<element name="attachmentElement">
<complexType>
<attribute name="href"
type="string"/>
</complexType>
</element>
</schema>

2. インバウンドcsvファイルを参照する入力添付と、出力固定長ファイルを参照する出力添付に使用する、変数を作成します。ストリーミング・コンテキストに対応する変数を作成します。この変数への移入は、XPath関数をコールする前に行う必要があります。
例 - 入力添付の変数の作成

<variables>
<variable name="xlationContext"
element="client:streamingcontext"/>
<variable name="inputAttachment"
element="client:attachmentElement"/>
<variable name="returnAttachment"
element="client:attachmentElement"/>
</variables>

<!- - Assign the input and output attachments - ->
<assign name="assignValuesForAttachments">
<copy>
<from expression="'/tmp/xpath/in/address.csv' "/>
<to variable="inputAttachment"
query="/client:attachmentElement/@href"/>
</copy>
<copy>
<from expression="
'/tmp/xpath/out/address_fixedLength.txt' "/>
<to variable="returnAttachment"
query=
"/client:attachmentElement/@href"/>
</copy>
</assign>
<!- - Assign the streaming context - ->
<assign name="AssignStreamingContext">
<copy>
<from expression="'xsd/address-csv.xsd'"/>
<to variable="xlationContext"
query="/client:streamingcontext
/client:sourceSchema"/>
</copy>
<copy>
<from expression="'Root-Element'"/>
<to variable="xlationContext"
query="/client:streamingcontext/
client:sourceRootElement"/>
</copy>
<copy>
<from expression="'native'"/>
<to variable="xlationContext"
query="/client:streamingcontext/client:
sourceType"/>
</copy>
<copy>
<from expression=
"'xsd/address-fixedLength.xsd'"/>
<to variable="xlationContext"
query="/client:streamingcontext/
client:targetSchema"/>
</copy>
<copy>
<from expression="'Root-Element'"/>
<to variable="xlationContext"
query="/client:streamingcontext/client:
targetRootElement"/>
</copy>
<copy>
<from expression="'native'"/>
<to variable="xlationContext"
query="/client:streamingcontext/client:
targetType"/>
</copy>
<copy>
<from expression="'xsl/addr1Toaddr2.xsl'"/>
<to variable="xlationContext"
query="/client
:streamingcontext/client:xsl"/>
</copy>
<copy>
<from expression="'10000'"/>
<to variable="xlationContext"
query="/client:streamingcontext/client:
batchSize"/>
</copy>
</assign>
<!- - call the XPath function - ->
<assign name="executeStreamingXPath">
<copy>
<from expression=
"ora:doStreamingTranslate
(bpws:getVariableData('inputAttachment',
'/client:attachmentElement'),
bpws:getVariableData('xlationContext'),
'ATTACHMENT',
bpws:getVariableData('returnAttachment'))"/>
<to variable="returnAttachment"
query="/client:attachmentElement"/>
</copy>
</assign>

6.4 ネイティブ・フォーマット・ビルダーの使用例

この説では、次の使用例について説明します。

- デリミタ付きファイル構造のスキーマの定義

- 固定長ファイル構造のスキーマの定義

- 複雑なファイル構造のスキーマの定義

- ネームスペースのないXMLのネームスペースの削除または追加

- 複雑なファイル構造の選択条件スキーマの定義

- 複雑なファイル構造のlookAheadを使用する選択条件の定義

- 複雑なファイル構造の配列タイプ・スキーマの定義

- DTDファイル構造のスキーマの定義

- COBOLコピーブック・ファイル構造のスキーマの定義

注意:

現在、ネイティブ・フォーマット・ビルダーでは、複数文字のデリミタを含むデータのサンプリングはサポートされていません。この種のデータをサンプリングするには、適切なDelimited By文字列を使用してNXSDをハンド・コーディングします。

6.4.1 デリミタ付きファイル構造のスキーマの定義

カンマ区切り値(CSV)ファイルは、一般的なXML以外のファイル構造です。

このネイティブ・ファイルのXMLスキーマを作成する際には、ネイティブ・フォーマット・ビルダー・ウィザードの「デリミタ」オプションを使用します。

nxsd:headerLines="1"スキーマ属性は、ネイティブ・データの1行目をヘッダー行として処理してスキップしてから、残りのデータに対して実際の変換を行う必要があることを意味します。nxsd:stream="chars"スキーマ属性は、データが文字として読み取られることを意味します。nxsd:stream="bytes"のようにnxsd:streamがbytesに設定されている場合は、このスキーマ属性は、ネイティブ・データがバイトとして読み取られることを意味します。対応するスカラー・データを持つName、Street、City、State、Countryの各要素の宣言では、nxsd:style="terminated"属性によって対応するデータがterminatedスタイルで保存されていることが定義されています。実際の終了文字は、コンストラクトに指定されているnxsd:terminatedBy=","属性で定義されています。terminatedスタイルの詳細は、「終了データの定義」を参照してください。

この使用例では、ネイティブ・フォーマット・ビルダーにより、名前、番地、市区町村、都道府県および国などの住所詳細を含んだデリミタ付きサンプル・ファイル・タイプが使用されます。このサンプル・ネイティブ・ファイル内の要素は、すべてカンマ(,)で区切られています。対応するNXSDを生成し、同様にテストできます。この使用例を実行する手順は、次のとおりです。

1. サンプル・テキスト・ファイルaddress-csv.txt内のデータは、次のとおりです。

Name,Street1,Street2,City,State,Country
Oracle India Private Limited, Lexington Towers Prestige
St. John's Woods, 2nd Cross Road Chikka Audugodi,
Bangalore,Karnataka, India
Intel Technology India Private Limited, Survey #23-56 P Devarabeesanahalli Village, Outer Ring Road Varthur Hobli, Bangalore, Karnataka, India

2. 図6-4 に示すように、アダプタ構成ウィザードの「メッセージ」ページにナビゲートし、「ネイティブ・フォーマットのスキーマの定義」ボタンをクリックします。

図6-4 ネイティブ・フォーマット・ビルダー・ウィザードの起動

図6-5 に示すように、「ネイティブ・フォーマット・ビルダー: ようこそ」ページが表示されます。

図6-5 「ネイティブ・フォーマット・ビルダー・ウィザード - ようこそ」ページ

3. 「次」を選択します。図6-6 に示すように、「タイプの選択」ページが表示されます。

図6-6 「ネイティブ・フォーマット・ビルダー・ウィザード - タイプの選択」ページ

4. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「ファイルの説明」ページが表示されます。

5. 図6-7 に示すように、「参照」をクリックしてaddress-csv.txtファイルを選択します。

図6-7 「ネイティブ・フォーマット・ビルダー・ウィザード - ファイルの説明」ページ

6. 「次」を選択します。図6-8 に示すように、「レコード編成」ページが表示されます。

図6-8 「ネイティブ・フォーマット・ビルダー・ウィザード - レコード編成」ページ

7. 「ファイルはマルチ・レコード・インスタンスを含む」を選択してから「1つのタイプの複数レコード」を選択し、「次へ」をクリックします。「要素の指定」ページが表示されます。

8. 図6-9 に示すように、「複数レコードを含む要素名の入力」フィールドにAddressBookと入力し、「レコードを表す要素名の入力」フィールドにAddressと入力します。

図6-9 「ネイティブ・フォーマット・ビルダー・ウィザード - 要素の指定」ページ

9. 「次」を選択します。図6-10 に示すように、「デリミタの指定」ページが表示されます。(複雑なlookAhead戦略の詳細は、「正規表現を使用したレコードの条件付き処理に対する複雑なlookAhead戦略の定義」を参照してください)。

図6-10 「ネイティブ・フォーマット・ビルダー・ウィザード - デリミタの指定」ページ

10. 「デリミタ」フィールドで「カンマ(,)」オプションが選択されていることを確認し、「次へ」をクリックします。図6-11 に示すように、「フィールド・プロパティ」ページが表示されます。

図6-11 「ネイティブ・フォーマット・ビルダー・ウィザード - フィールド・プロパティ」ページ

11. 「フィールド名として最初のレコードを使用」を選択し、「次へ」をクリックします。図6-12 に示すように、「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

注意:

最初のレコードはフィールド名として使用され、変換時にはヘッダー・レコードとして処理されてスキップされます。

図6-12 「ネイティブ・フォーマット・ビルダー・ウィザード - 生成されたネイティブ・フォーマット・ファイル」ページ

対応するネイティブ・スキーマの定義は次のとおりです。

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://TargetNamespace.com/Read"
targetNamespace="http://TargetNamespace.com/Read"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:version="NXSD"
nxsd:stream="chars"
nxsd:encoding="ASCII"
nxsd:hasHeader="true"
nxsd:headerLines="1"
nxsd:headerLinesTerminatedBy="${eol}"
>
<xsd:element name="AddressBook">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Address" minOccurs="1"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;" />
<xsd:element name="Street1"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;" />
<xsd:element name="Street2"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;" />
<xsd:element name="City" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;" />
<xsd:element name="State"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;" />
<xsd:element name="Country"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}"
nxsd:quotedBy="&quot;" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

12. 「テスト」をクリックします。図6-13に示すように、「NXSDスキーマのテスト」 ダイアログが表示されます。

図6-13 「NXSDスキーマのテスト」ダイアログ

13. 「XMLの生成」アイコンをクリックします。図6-14 に示すように、生成されたXMLが「NXSDスキーマのテスト」ダイアログの「結果XML」ペインに表示されます。

図6-14 「NXSDスキーマのテスト」ダイアログ

対応するネイティブ・スキーマ・フォーマットを使用したネイティブ・データは、次のXMLに変換されます。

<?xml version = '1.0' encoding = 'UTF-8'?>
<AddressBook xmlns="http://TargetNamespace.com/ReadFile">
<Address>
<Name>Oracle India Private Limited</Name>
<Street1> Lexington Towers Prestige St. John's Woods</Street1>
<Street2> 2nd Cross Road Chikka Audugodi</Street2>
<City> Bangalore</City>
<State> Karnataka</State>
<Country> India</Country>
</Address>
<Address>
<Name>Intel Technology India Private Limited</Name>
<Street1> Survey #23-56 P Devarabeesanahalli Village</Street1>
<Street2> Outer Ring Road Varthur Hobli</Street2>
<City> Bangalore</City>
<State> Karnataka</State>
<Country> India</Country>
</Address>
</AddressBook>

14. 「OK」をクリックします。図6-12 に示すように、「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページが表示されます。

15. 「次」を選択します。図6-15 に示すように、「ネイティブ・フォーマット・ビルダー: 終了」ページが表示されます。

図6-15 「ネイティブ・フォーマット・ビルダー・ウィザード - 終了」ページ

16. 「終了」をクリックします。図6-16 に示すように、生成されたNXSDを含んだアダプタ構成ウィザードの「メッセージ」ページが表示されます。

図6-16 「アダプタ構成ウィザード - メッセージ」ページ

6.4.1.1 アスタリスク(*)区切り値ファイルの構造の定義

前述の例で定義された使用例は、*SVクラスの一例です。ワイルド・カードは、任意の文字または文字列に置き換えられます。たとえば、プラス(+)で区切られた値を含むネイティブ・データの場合、ワイルド・カードをプラス(+)文字で置き換えます。

このネイティブ・ファイルのXMLスキーマを作成する際には、ネイティブ・フォーマット・ビルダー・ウィザードの「デリミタ」タイプ・オプションを使用します。

変換されるネイティブ・データ・フォーマット

次のようなネイティブ・データ・フォーマットがあります。

a+b+c+d+e
f+g+h+i+j

ネイティブ・スキーマ

nxsd:terminatedBy=","のかわりにterminated byフォーマットをnxsd:terminatedBy="+"として定義することを除き、対応するネイティブ・スキーマ定義は前の使用例と似ています。terminatedスタイルの詳細は、「終了データの定義」を参照してください。

6.4.2 固定長ファイル構造のスキーマの定義

この例では、使用されるネイティブ・データはCSVの場合と同じですが、データのタイプはCSVではなく固定長です。

このネイティブ・ファイルのXMLスキーマを作成するには、ネイティブ・フォーマット・ビルダー・ウィザードの「固定長」オプションを使用します。

この使用例では、ネイティブ・フォーマット・ビルダーにより、名前、番地、市区町村、都道府県および国などの住所詳細を含んだaddressという固定長ファイル・タイプが使用されます。このaddressネイティブ・ファイル内の要素は、すべて固定長です。対応するNXSDを生成し、同様にテストできます。この使用例を実行する手順は、次のとおりです。

1. サンプル・テキスト・ファイルaddress.txt内のデータは、次のとおりです。

Name                  Street    City      State     Country
ABC Private Limited   Street1   Bangalore Karnataka India
XYZ Private Limited   Street1   Bangalore Karnataka India

2. 図6-4 に示すように、アダプタ構成ウィザードを起動し、「メッセージ」ページにナビゲートして「ネイティブ・フォーマットのスキーマの定義」をクリックします。図6-5 に示すように、「ネイティブ・フォーマット・ビルダー: ようこそ」ページが表示されます。

3. 「次」を選択します。「タイプの選択」ページが表示されます。

4. 図6-17 に示すように、ファイル・タイプとして「固定長」を選択します。

図6-17 「ネイティブ・フォーマット・ビルダー・ウィザード - タイプの選択」ページ

5. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「ファイルの説明」ページが表示されます。

6. 図6-18 に示すように、「参照」をクリックしてaddress.txtファイルを選択します。

図6-18 「ネイティブ・フォーマット・ビルダー・ウィザード - ファイルの説明」ページ

7. 「次」を選択します。図6-19 に示すように、「レコード編成」ページが表示されます。

図6-19 「ネイティブ・フォーマット・ビルダー・ウィザード - レコード編成」ページ

8. 「1つのタイプの複数レコード」を選択して「次へ」をクリックします。「要素の指定」ページが表示されます。

9. 図6-20 に示すように、「複数レコードを含む要素名の入力」フィールドにAddressBookと入力し、「レコードを表す要素名の入力」フィールドにAddressと入力します。

図6-20 「ネイティブ・フォーマット・ビルダー・ウィザード - 要素の指定」ページ

10. 「次」を選択します。「マルチ・レコード・ファイルのフィールド長」ページが表示されます。

11. 図6-21 に示すように、必要な位置でルーラーをクリックしてサンプル・テキスト領域のフィールドをマーク付けし、「次へ」をクリックします。「フィールド・プロパティ」ページが表示されます。

図6-21 「ネイティブ・フォーマット・ビルダー・ウィザード - マルチ・レコード・ファイルのフィールド長」ページ

12. 図6-22 に示すように、「フィールド名として最初のレコードを使用」を選択します。

図6-22 「ネイティブ・フォーマット・ビルダー・ウィザード - フィールド・プロパティ」ページ

13. 「次」を選択します。図6-23 に示すように、「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページが表示されます。

図6-23 「ネイティブ・フォーマット・ビルダー・ウィザード - 生成されたネイティブ・フォーマット・ファイル」ページ

対応するネイティブ・スキーマ定義はCSVファイルの定義と似ていますが、固定長スタイルの関連する属性とともに、styleがnxsd:style="terminated"からnxsd:style="fixedLength"に変わります。固定長スタイルでは、必須属性はlength: nxsd:lengthです。nxsd:lengthの値は、読み取られる実際のデータの長さです。

例 - 固定長スタイルのネイティブ・スキーマ定義の例

<?xml version="1.0" encoding="UTF-8" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://TargetNamespace.com/FileIn_1"
targetNamespace="http://TargetNamespace.com/FileIn_1"
elementFormDefault="qualified"
attributeFormDefault="unqualified"

nxsd:version="NXSD"
nxsd:stream="chars"
nxsd:encoding="ASCII"
nxsd:hasHeader="true"
nxsd:headerLines="1"
nxsd:headerLinesTerminatedBy="${eol}"

<xsd:element name="AddressBook">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Address" minOccurs="1"
maxOccurs="unbounded"
nxsd:style="array"
nxsd:cellSeparatedBy="${eol}">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:length="22" />
<xsd:element name="Street"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:length="8" />
<xsd:element name="City"
type="xsd:string"
nxsd:style="fixedLength" nxsd:length="12" />
<xsd:element name="State"
type="xsd:string" nxsd:style="fixedLength"
nxsd:length="10" />
<xsd:element name="Country" type="xsd:string" nxsd:style="fixedLength" nxsd:length="7" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

</xsd:schema>

14. 「テスト」をクリックします。図6-24に示すように、「NXSDスキーマのテスト」 ダイアログが表示されます。

図6-24 「NXSDスキーマのテスト」ダイアログ

15. 「XMLの生成」アイコンをクリックします。図6-25 に示すように、生成されたXMLが「NXSDスキーマのテスト」ダイアログの「結果XML」ペインに表示されます。

図6-25 「NXSDスキーマのテスト」ダイアログ

対応するネイティブ・スキーマ・フォーマットを使用したネイティブ・データは、次の例のようなXMLに変換されます。

例 - ネイティブ・スキーマFormatTranslated XMLを使用したネイティブ・データ

<?xml version = '1.0' encoding = 'UTF-8'?>
<AddressBook xmlns="http://TargetNamespace.com/Read">
<Address>
<Name>ABC Private Limited</Name>
<Street>Street1  </Street>
<City> Bangalore </City>
<State>Karnataka </State>
<Country>India</Country>
</Address>
<Address>
<Name>XYZ Private Limited</Name>
<Street>Street1  </Street>
<City> Bangalore </City>
<State>Karnataka </State>
<Country>India </Country>
</Address>
</AddressBook>

16. 「OK」をクリックします。図6-23 に示すように、「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

17. 「次」を選択します。図6-15 に示すように、「ネイティブ・フォーマット・ビルダー: 終了」ページが表示されます。

18. 「終了」をクリックします。図6-16 に示すように、生成されたNXSDを含んだアダプタ構成ウィザードの「メッセージ」ページが表示されます。

6.4.3 複雑なファイル構造のスキーマの定義

請求書のファイル構造は、前述の使用例で説明したCSV、*SVおよび固定長のファイルの構造よりも複雑です。通常、請求書には購入者の情報、販売者の情報および明細項目が含まれます。これらの各要素には、複合タイプを使用できます。たとえば、購入者要素をpartner-typeとして定義し、partner-typeをid、nameおよびaddressという3つの要素で構成できます。

このネイティブ・ファイルのXMLスキーマを作成する際には、ネイティブ・フォーマット・ビルダー・ウィザードの「複合タイプ」オプションを使用します。

この使用例では、ネイティブ・フォーマット・ビルダーにより、buyer、seller、itemsなどの複数のレコードを含んだinvoiceという複合ファイル・タイプのinvoice.txtが使用されます。この使用例を使用すると、NXSDを生成してテストすることもできます。この使用例を実行する手順は、次のとおりです。

1. サンプル・テキスト・ファイルinvoice.txt内のデータは、次のとおりです。

6335722^Company OnêFirst Street   999       San Jose       95129USCA650-801-6250
^OraclêBridge Parkway 1600      Redwood Shores 94065USCA650-506-7000
001|BPEL Process Manager Enterprise Edition|20000,2,+40000+
002|BPEL Process Manager Standard Edition|10000,5,+50000+
003|BPEL Process Manager Developer Edition|1000,20,+20000+#110000

2. 図6-4 に示すように、アダプタ構成ウィザードを起動し、「メッセージ」ページにナビゲートして「ネイティブ・フォーマットのスキーマの定義」をクリックします。図6-5 に示すように、「ネイティブ・フォーマット・ビルダー: ようこそ」ページが表示されます。

3. 「Next」をクリックします。図6-26 に示すように、「タイプの選択」ページが表示されます。

図6-26 「ネイティブ・フォーマット・ビルダー・ウィザード - タイプの選択」ページ

4. 「複合タイプ(フィールドそのものがレコードで複数のデリミタ・タイプを持つ可能性があるレコードが含まれています)」を選択します。

5. 「Next」をクリックします。ネイティブ・フォーマット・ビルダーの「ファイルの説明」ページが表示されます。

6. 図6-27 に示すように、「参照」をクリックしてinvoice.txtファイルを選択し、「ルート要素」フィールドにInvoiceと入力します。

図6-27 「ネイティブ・フォーマット・ビルダー・ウィザード - ファイルの説明」ページ

7. 「Next」をクリックします。図6-28 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」が表示されます。

図6-28 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ

partner-type複合タイプの作成

invoice.txtサンプルを使用して作成できるスキーマ構造は、次のとおりです。

Invoice

Buyer => partner-type

Seller => partner-type

Items => item-type

Invoice-total => double

ネイティブ・データの1行目は購入者の詳細で構成され、販売者の詳細、明細項目および明細項目の合計が続きます。購入者要素と販売者要素の両方が、次のように同じ複雑な構造を持っています。

- 最初の7文字はUIDです。

- これには、「^」で囲まれた購入者/販売者の名前が続きます。

- この後には、行末まで住所が続きます。

これをネイティブ・フォーマット・ビルダーで作成するには、次の手順を実行します。

1. 「複合タイプの追加」アイコンをクリックします。図6-29 に示すように、「スキーマ・ツリー」でInvoiceの下に複合タイプ<new_complex_type>が作成されます。

図6-29 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ

2. 「サンプル・ファイル」セクションの右ペインからサンプル・テキストの1行目を選択し、「<new_complex_type>」ノードにドラッグ・アンド・ドロップします。「複合タイプ詳細」ダイアログが表示されます。

3. 図6-30 に示すように、「複合タイプ名」フィールドにpartner-typeと入力します。

図6-30 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ: 「複合タイプ詳細」ダイアログ

4. 必要な位置でルーラーをクリックしてサンプル・テキスト領域のフィールドをマーク付けし、「フィールドの生成」ボタンをクリックします。システムが定義済フィールドのデータのスタイルを解釈します。

注意:

「固定長」または「混在」デリミタ・タイプ・オプションを選択した場合は、ルーラー・ベースのテキスト領域が表示されます。ルーラーを使用して、サンプル・テキスト内のフィールドを識別する必要があります。デリミタ付きデータの場合は、「デリミタ」フィールドで該当するデリミタを選択または入力します。

5. 図6-31 に示すように、「名前」フィールドにid、nameおよびaddressと入力します。

図6-31 「複合タイプ詳細」ダイアログ

6. 各フィールドの横にある鉛筆アイコンをクリックし、フィールド・プロパティを編集可能な対応する「フィールド詳細の編集」ダイアログを表示します。たとえば、「名前」フィールドの横にある鉛筆アイコンをクリックします。図6-32に示すように、「フィールド詳細の編集」 ダイアログが表示されます。

図6-32 「フィールド詳細の編集」ダイアログ

7. 図6-32 に示すように、次のフィールド・プロパティを編集します。

- タイプ: サンプル・テキストのデータ型。「タイプ」リストで「String」を選択します。

- スタイル: 複合タイプ要素のスタイルを表します。次の4つのオプションから選択できます。

- 固定長

- surrounded

- terminated

- 左囲み/右囲み

この例では、surroundedを選択します。

- 囲み: このオプションが表示されるのは、「スタイル」オプションでsurroundedを選択した場合です。この例では、「囲み」フィールドにカレット(^)を入力します。

このパネルに表示されるフィールド・プロパティは、スキーマに使用されているNXSD属性に対応しています。

8. 「OK」をクリックします。選択したフィールド・プロパティを含んだ「複合タイプ詳細」ダイアログが表示されます。

9. 「名前」フィールドのidおよびaddressのフィールド・プロパティを確認または編集します。

10. 「複合タイプ詳細」ダイアログで「OK」をクリックします。図6-33 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページが表示されます。

図6-33 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ: partner-type複合タイプ

address-type複合タイプの作成

address要素を、さらに固定長の番地、市区町村などのフィールドを含んだ別のcomplex-typeとして定義できます。

これを行うには、次の手順を実行します。

1. 「スキーマ・ツリー」で別の<noncompliant>ノードを作成します。「partner-type複合タイプの作成」のステップ1を参照してください。

2. サンプル・テキストの1行目のaddressパートを複合タイプ<noncompliant>にドラッグ・アンド・ドロップします。「複合タイプ詳細」ダイアログが表示されます。

3. 「複合タイプ名」フィールドにaddress-typeと入力します。

4. ルーラーをクリックしてサンプル・テキスト領域のフィールドをマーク付けし、「フィールドの生成」ボタンをクリックします。次に、図6-34 に示すように、「名前」フィールドにstreet1、street2、city、zip、country、stateおよびphoneと入力します。

図6-34 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ: 「複合タイプ詳細」ダイアログ

5. 「OK」をクリックします。図6-35 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページが表示されます。

図6-35 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ

partner-type複合タイプのaddressフィールドへのaddress-type複合タイプの割当て

partner-type複合タイプのaddressフィールドに、address-type複合タイプを割り当てる必要があります。次のいずれかの方法で要素に複合タイプを割り当てることができます。

- address-typeノードをpartner-type複合タイプのaddressフィールド・ノードにドラッグ・アンド・ドロップします。これにより、addressフィールド要素にaddress-typeが即時に割り当てられます。または

- partner-type複合タイプのaddressフィールド・ノードを選択し、鉛筆アイコンをクリックします。
図6-36 に示すように、「フィールド詳細の編集」ダイアログが表示されます。

図6-36 「フィールド詳細の編集」ダイアログ

2. 「タイプ」リストで「address-type」オプションを選択し、「OK」をクリックします。図6-37 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページでaddressフィールド要素にaddress-typeオプションが割り当てられます。

図6-37 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ

buyerおよびsellerグローバル要素の作成

1. 「Invoice」を選択し、「要素の追加」アイコンをクリックします。「スキーマ・ツリー」で、ルート要素「Invoice」の下に要素<new_element>が作成されます。

2. 名前をbuyerに変更します。

3. 再び「Invoice」を選択し、「要素の追加」アイコンをクリックします。「スキーマ・ツリー」で、「Invoice」の下に要素<new_element>が作成されます。

4. 名前をsellerに変更します。
各buyerおよびsellerノード上にpartner-typeノードをドラッグ・アンド・ドロップして、これらのノードにpartner-type複合タイプを割り当てます。図6-38 に示すように、「スキーマ・ツリー」が表示されます。

図6-38 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ

item-type複合タイプとitemsおよびinvoice-total要素ノードの作成

items要素はitem-typeの配列とみなすことができます。ネイティブ・ファイル内の最後の明細項目では、番号記号(#)の後に明細項目の合計が続いて終了しています。

1. 「Invoice」を選択し、「要素の追加」アイコンをクリックします。「スキーマ・ツリー」で、「Invoice」の下に要素<new_element>が作成されます。

2. 名前をitemsに変更します。

3. 図6-39 に示すように、item-type複合タイプを作成してフィールド・プロパティを定義します。

図6-39 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ

4. item-type複合タイプをitems要素にドラッグ・アンド・ドロップして、この要素にitem-typeを割り当てます。

5. items - item-typeを選択して鉛筆アイコンをクリックします。「要素の詳細」ダイアログが表示されます。

図6-40 「要素の詳細」ダイアログ

6. 図6-40 に示すように、「要素の詳細」ダイアログで次のプロパティを設定します。

a. 「最大発生数」を「バインドなし」に設定します。

b. 「配列」を選択します。「セル・セパレータ」および「配列セパレータ」が有効になります。

c. 「セル・セパレータ」を「${eol}」に設定します。

d. 「配列セパレータ」を「#」に設定します

注意:

要素itemsはitem-typeの配列として定義されます。

7. 「OK」をクリックします。

8. invoice-total要素を作成し、サンプル・テキスト(110000)を<new_element>ノードにドラッグ・アンド・ドロップします。「要素の詳細」ダイアログが表示されます。

9. 「要素名」フィールドにinvoice-totalと入力し、「フィールドの生成」をクリックします。図6-41 に示すように、「アラート」メッセージが表示されます。

図6-41 「要素の詳細」ダイアログ - 「アラート」メッセージ

グローバル要素のサンプル・データで単一フィールドが識別されている場合、このデータのプロパティがグローバル要素自体に適用されます。

10. 「アラート」メッセージで「OK」をクリックします。「要素の詳細」ダイアログが表示されます。

11. 「データ型」リストで「double」を選択し、「OK」をクリックします。図6-42 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページが表示されます。

図6-42 「ネイティブ・フォーマット・ビルダー・ウィザード - 設計スキーマ」ページ: 完成したスキーマ・ツリー

12. 「Next」をクリックします。図6-43 に示すように、「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページが表示され、ネイティブ・フォーマット・ファイルが表示されます。

図6-43 「ネイティブ・フォーマット・ビルダー・ウィザード - 生成されたネイティブ・フォーマット・ファイル」ページ

前述のネイティブ・データに対応するネイティブ・スキーマの定義は、次のように定義できます。

例 - ネイティブ・スキーマの定義

<schema attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace=
"http://xmlns.oracle.com/ias/pcbpel
/fatransschema/demo"
xmlns:tns="http://xmlns.oracle.com
/ias/pcbpel/
fatransschema/demo"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/
nxsd"
nxsd:version="NXSD" nxsd:stream="chars">

<element name="invoice" type="tns:invoiceType" />

<complexType name="invoiceType">
<sequence>
<element name="purchaser"
type="tns:partnerType" />
<element name="seller"
type="tns:partnerType" />
<element name="line-item"
type="tns:line-itemType"
maxOccurs="unbounded" nxsd:style="array"
nxsd:cellSeparatedBy="${eol}"
nxsd:arrayTerminatedBy="#"/>
<element name="total" type="double"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}"/>
</sequence>
</complexType>

<complexType name="partnerType">
<sequence>
<element name="uid" type="string"
nxsd:style="fixedLength"
nxsd:length="7" nxsd:padStyle="tail"
nxsd:paddedBy=" "/>
<element name="name" type="string"
nxsd:style="surrounded"
nxsd:surroundedBy="^"/>
<element name="address"
type="tns:addressType" />
</sequence>
</complexType>

<complexType name="addressType">
<sequence>
<element name="street1"
type="string"
nxsd:style="fixedLength"
nxsd:length="15"
nxsd:padStyle="tail"
nxsd:paddedBy=" "/>
<element name="street2" type="string"
nxsd:style="fixedLength"
nxsd:length="10"
nxsd:padStyle="tail"
nxsd:paddedBy=" "/>
<element name="city" type="string"
nxsd:style="fixedLength"
nxsd:length="15" nxsd:padStyle="tail"
nxsd:paddedBy=" "/>
<element name="postal-code" type="string"
nxsd:style="fixedLength"
nxsd:length="5"
nxsd:padStyle="none"/>
<element name="country" type="string"
nxsd:style="fixedLength"
nxsd:length="2"
nxsd:padStyle="none"/>
<element name="state" type="string"
nxsd:style="fixedLength"
nxsd:length="2" nxsd:padStyle="none"/>
<element name="phone" type="string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}"/>
</sequence>
</complexType>

<complexType name="line-itemType">
<sequence>
<element name="uid" type="string"
nxsd:style="fixedLength"
nxsd:length="3" nxsd:padStyle="none"/>
<element name="description" type="string"
nxsd:style="surrounded"
nxsd:surroundedBy="|"/>
<element name="price" type="double"
nxsd:style="terminated"
nxsd:terminatedBy=","/>
<element name="quantity" type="integer"
nxsd:style="terminated"
nxsd:terminatedBy=","/>
<element name="line-total" type="double"
nxsd:style="surrounded"
nxsd:surroundedBy="+"/>
</sequence>
</complexType>

</schema>

13. 「テスト」をクリックします。図6-44に示すように、「NXSDスキーマのテスト」 ダイアログが表示されます。

図6-44 「NXSDスキーマのテスト」ダイアログ

14. 「XMLの生成」アイコンをクリックします。図6-45 に示すように、「NXSDスキーマのテスト」ダイアログの右ペインに「結果XML」が表示されます。

図6-45 「NXSDスキーマのテスト」ダイアログ - 結果XML

次の例に、変換済のXMLを示します。

例 - 変換済のXML

<invoice xmlns="http://xmlns.oracle.com/pcbpel/
demoSchema/invoice-nxsd">
<purchaser>
<uid>6335722</uid>
<name>Company One</name>
<address>
<street1>First Street</street1>
<street2>999</street2>
<city>San Jose</city>
<postal-code>95129</postal-code>
<country>US</country>
<state>CA</state>
<phone>650-801-6250</phone>
</address>
</purchaser>
<seller>
<uid/>
<name>Oracle</name>
<address>
<street1>Bridge Parkway</street1>
<street2>1600</street2>
<city>Redwood Shores</city>
<postal-code>94065</postal-code>
<country>US</country>
<state>CA</state>
<phone>650-506-7000</phone>
</address>
</seller>
<line-item>
<uid>001</uid>
<description>BPEL Process Manager Enterprise
Edition</description>
<price>20000</price>
<quantity>2</quantity>
<line-total>40000</line-total>
</line-item>
<line-item>
<uid>002</uid>
<description>BPEL Process Manager Standard
Edition</description>
<price>10000</price>
<quantity>5</quantity>
<line-total>50000</line-total>
</line-item>
<line-item>
<uid>003</uid>
<description>BPEL Process Manager Developer
Edition</description>
<price>1000</price>
<quantity>20</quantity>
<line-total>20000</line-total>
</line-item>
<total>110000</total>
</invoice>

15. 「OK」をクリックします。図6-43 に示すように、「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

16. 「Next」をクリックします。図6-15 に示すように、「ネイティブ・フォーマット・ビルダー: 終了」ページが表示されます。

17. 「終了」をクリックします。図6-16 に示すように、生成されたNXSDを含んだアダプタ構成ウィザードの「メッセージ」ページが表示されます。

6.4.4 ネームスペースのないXMLのネームスペースの削除または追加

ネイティブ・データがXMLでありそのXMLにネームスペースがない場合は、ネイティブ・フォーマット・トランスレータを使用してインバウンドXMLドキュメントにネームスペースを追加したりアウトバウンドXMLドキュメントからネームスペースを削除したりできます。

次のいずれかに該当する場合、XMLにはネームスペースがありません。

- XMLに対応するXMLスキーマがあり、そのXMLスキーマにターゲット・ネームスペースが指定されていない場合。

- XMLに対応するDTDがあり、それがXMLスキーマに変換されたDTDである場合。

どちらの場合も、targetNamespaceが指定されたラッパー・スキーマを作成し、そのラッパー・スキーマに実際のスキーマを含める必要があります。また、ラッパー・スキーマにはDTDに設定されたnxsd:version属性も必要です。次に例を示します。

--wrapper.xsd
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="myNamespace"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
nxsd:version="DTD">
<include schemaLocation="actual.xsd"/>
</schema>

注意:

実際のスキーマにelementFormDefault="qualified"が指定されていることを確認してください。

元の.xsdファイルのかわりにこのwrapper.xsdファイルを使用すると、インバウンドXMLにmyNamespaceネームスペースが追加され、アウトバウンドXMLからmyNamespaceネームスペースが削除されます。

6.4.5 複雑なファイル構造の選択条件スキーマの定義

この使用例では、ネイティブ・フォーマット・ビルダーにより、order、customer、itemsなどの複数のレコード・タイプを含んだorder.txtという複合タイプのファイルが使用されます。この使用例を使用すると、NXSDを生成してテストすることもできます。この使用例を実行する手順は、次のとおりです。

1. サンプル・テキスト・ファイルorder.txt内のデータは、次のとおりです。

Order, ID41678, 20May2000
Item1, GigaWidget, 60, $75
Item2, MegaBucket, 48, $125
Cust1, Hopkins Associates, ID26490
Order, ID41680, 20May2000
Item3, Rt.Clopper, 40, $100
Item4, Lt.Clopper, 50, $100
Cust2, Jersey WebInovaters, ID46786

2. order、customerおよびitemのネイティブ・データごとに1行をドラッグして、次の複合タイプを作成します。

- OrderType

- ItemType

- CustomerType

複合タイプの作成の詳細は、「複雑なファイル構造のスキーマの定義」を参照してください。

図6-46 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページが表示されます。

図6-46 「ネイティブ・フォーマット・ビルダー - 設計スキーマ」ページ

3. 「選択ノードの追加」をクリックします。「選択オプション・タイプ」ダイアログが表示されます。

4. 「選択オプション・タイプ」ダイアログで、図6-47 に示すようにオプションを設定して「OK」をクリックします。

図6-47 「選択オプション・タイプ」ダイアログ

5. 「choice」を選択し、「要素の追加」アイコンをクリックします。choiceノードに「<new_element>」が追加されます。

6. 新規に追加した要素の名前をOrderChoiceに変更し、「OrderType」複合タイプ要素を「OrderChoice」にドラッグ・アンド・ドロップします。

7. 「OrderChoice - string」を選択して「ノードの編集」アイコンをクリックします。「要素の詳細」ダイアログが表示されます。

8. 図6-48 に示すように、「選択値」フィールドにOrderと入力して「OK」をクリックします。

注意:

「長さ」フィールドの値が4に設定されているため、「選択値」フィールドでは4文字を指定する必要があります。

図6-48 「要素の詳細」ダイアログ

9. ステップ5から8に従って、ItemTypeデータ型のItemChoice選択複合タイプとCustomerTypeデータ型のCustomerChoice選択複合タイプを作成します。図6-49 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ダイアログが表示されます。

図6-49 「ネイティブ・フォーマット・ビルダー - 設計スキーマ」ページ

10. 「次」を選択します。図6-50 に示すように、「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページが表示され、ネイティブ・フォーマット・ファイルが表示されます。

図6-50 「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページ

ネイティブ・スキーマ

前述のネイティブ・データに対応するネイティブ・スキーマの定義は、次の例のように定義できます。

例 - ネイティブ・スキーマの定義

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd=
"http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://TargetNamespace.com/test"
targetNamespace=
"http://TargetNamespace.com/test"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:version="NXSD"
nxsd:stream="chars"
nxsd:encoding="ASCII"
>
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:choice minOccurs="1"
maxOccurs="unbounded"
nxsd:choiceCondition="fixedLength"
nxsd:length="4">
<xsd:element name="OrderChoice"
type="tns:OrderType"
nxsd:conditionValue="Orde" />
<xsd:element name="ItemChoice"
type="tns:ItemType"
nxsd:conditionValue="Item" />
<xsd:element name="CustomerChoice"
type="tns:customerType"
nxsd:conditionValue="Cust" />
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="customerType">
<xsd:sequence>
<xsd:element name="C1"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C2" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C3" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ItemType">
<xsd:sequence>
<xsd:element name="C1"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C2"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C3"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C4"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="OrderType">
<xsd:sequence>
<xsd:element name="C1" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C2" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C3" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

11. 「テスト」をクリックします。「NXSDスキーマのテスト」ダイアログが表示されます。

12. 「XMLの生成」アイコンをクリックします。図6-51 に示すように、「NXSDスキーマのテスト」ダイアログの右ペインに「結果XML」が表示されます。

図6-51 「NXSDスキーマのテスト」ダイアログ

ネイティブ・スキーマを使用して変換したXML

次の例に、変換済のXMLを示します。

例 - ネイティブ・スキーマを使用して変換したXML

<?xml version = '1.0' encoding = 'UTF-8'?>
<Root-Element xmlns="http://TargetNamespace.com/test">
<OrderChoice>
<C1>r</C1>
<C2> ID41678</C2>
<C3> 20May2000</C3>
</OrderChoice>
<ItemChoice>
<C1>1</C1>
<C2> GigaWidget</C2>
<C3> 60</C3>
<C4> $75</C4>
</ItemChoice>
<ItemChoice>
<C1>2</C1>
<C2> MegaBucket</C2>
<C3> 48</C3>
<C4> $125</C4>
</ItemChoice>
<CustomerChoice>
<C1>1</C1>
<C2> Hopkins Associates</C2>
<C3> ID26490</C3>
</CustomerChoice>
<OrderChoice>
<C1>r</C1>
<C2> ID41680</C2>
<C3> 20May2000</C3>
</OrderChoice>
<ItemChoice>
<C1>3</C1>
<C2> Rt.Clopper</C2>
<C3> 40</C3>
<C4> $100</C4>
</ItemChoice>
<ItemChoice>
<C1>4</C1>
<C2> Lt.Clopper</C2>
<C3> 50</C3>
<C4> $100</C4>
</ItemChoice>
<CustomerChoice>
<C1>2</C1>
<C2> Jersey WebInovaters</C2>
<C3> ID46786</C3>
</CustomerChoice>
</Root-Element>

13. 「OK」をクリックします。「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

14. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「終了」ページが表示されます。

6.4.6 複雑なファイル構造のlookAheadを使用する選択条件の定義

この使用例では、ネイティブ・フォーマット・ビルダーにより、異なるaddressを持つ複数のレコードを含んだaddress.txtという複合タイプのファイルが使用されます。この使用例では2つのレコード・タイプを持つスキーマを作成します。RecOneレコードはテキスト「YES」で終わるレコードのデータを取得し、RecTwoレコードはテキスト「NO」で終わるレコードのデータを取得します。

この使用例を使用すると、NXSDを生成してテストすることもできます。

この使用例を実行する手順は、次のとおりです。

1. サンプル・テキスト・ファイルaddress.txt内のデータは、次のとおりです。

Name1,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES
Name2,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO
Name3,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", NO
Name4,"2 Old Street, Old Town,Manchester",20-08-1954,"0161-499-1718", YES

2. アダプタ構成ウィザードを起動し、「メッセージ」ページにナビゲートして「ネイティブ・フォーマットのスキーマの定義」をクリックします。「ネイティブ・フォーマット・ビルダー: ようこそ」ページが表示されます。

3. 「次」を選択します。「タイプの選択」ページが表示されます。

4. 「複合タイプ」を選択して「次へ」をクリックします。ネイティブ・フォーマット・ビルダーの「ファイルの説明」ページが表示されます。

5. 「参照」をクリックしてaddress.txtファイルを選択し、「ルート要素」フィールドにAddressと入力します。

6. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページが表示されます。

7. 「複合タイプの追加」アイコンをクリックします。「スキーマ・ツリー」で、「Address」の下に複合タイプ<new_complex_type>が作成されます。

8. 「サンプル・ファイル」セクションの右ペインからサンプル・テキストの1行目を選択し、「<new_complex_type>」ノードにドラッグ・アンド・ドロップします。「複合タイプ詳細」ダイアログが表示されます。

9. 「複合タイプ名」フィールドにRECORD1と入力し、「デリミタ」リストで「カンマ(,)」を選択します。

10. 「OK」をクリックします。図6-52 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページが表示されます。

図6-52 「ネイティブ・フォーマット・ビルダー - 設計スキーマ」ページ

11. 同様に、RECORD2という別の複合タイプ・ノードを作成します。図6-53 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページが表示されます。

図6-53 「ネイティブ・フォーマット・ビルダー - 設計スキーマ」ページ

12. 「選択ノードの追加」をクリックします。「選択オプション・タイプ」ダイアログが表示されます。

13. 「選択オプション・タイプ」ダイアログで、図6-54 に示すようにオプションを設定して「OK」をクリックします。

図6-54 「選択オプション・タイプ」ダイアログ

14. 「choice」を選択し、「要素の追加」アイコンをクリックします。choiceノードに「<new_element>」が追加されます。

15. 「ノードの編集」アイコンをクリックします。「要素の詳細」ダイアログが表示されます。

16. 「要素名」フィールドにRECONEと入力し、データ型として「RECORD1」を選択し、選択条件として「YES」を設定し、「OK」をクリックします。

17. ステップ14から16に従って、choiceノードのRECTWO選択要素を作成し、選択条件としてNOを設定します。

注意:

合計文字数を3文字にする必要があるため、文字NOの後に空白を1個挿入しています。

図6-55 に示すように、ネイティブ・フォーマット・ビルダーの「設計スキーマ」ダイアログが表示されます。

図6-55 「ネイティブ・フォーマット・ビルダー - 設計スキーマ」ページ

18. RECORD1複合タイプをchoiceの下のRECONE要素にドラッグ・アンド・ドロップし、RECORD2複合タイプをchoiceの下のRECTWO要素にドラッグ・アンド・ドロップします。ネイティブ・フォーマット・ビルダーの「設計スキーマ」ダイアログが表示されます。

19. 「次」を選択します。図6-56 に示すように、「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページが表示され、ネイティブ・フォーマット・ファイルが表示されます。

図6-56 「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページ

ネイティブ・スキーマ

前述のネイティブ・データに対応するネイティブ・スキーマの定義は、次のように定義できます。

例 - 複雑なファイル構造のlookAheadを使用して選択条件を定義するためのネイティブ・スキーマ

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd=
"http://www.w3.org/2001/XMLSchema"
xmlns:nxsd=
"http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://TargetNamespace.com/tesNew"
targetNamespace=
"http://TargetNamespace.com/tesNew"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:version="NXSD"
nxsd:stream="chars"
nxsd:encoding="ASCII"
>
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:choice minOccurs="1"
maxOccurs="unbounded"
nxsd:choiceCondition="${X}" nxsd:lookAhead="70"
nxsd:scanLength="3"
nxsd:assignTo="${X}">
<xsd:element name="RECTWO"
type="tns:RECORD2"
nxsd:conditionValue="NO "
/>
<xsd:element name="RECONE"
type="tns:RECORD1"
nxsd:conditionValue="YES"
/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="RECORD2">
<xsd:sequence>
<xsd:element name="C1"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C2"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C3"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C4"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C5"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RECORD1">
<xsd:sequence>
<xsd:element name="C1"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C2"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C3"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C4"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," />
<xsd:element name="C5"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

20. 「テスト」をクリックします。「NXSDスキーマのテスト」ダイアログが表示されます。

21. 「XMLの生成」アイコンをクリックします。図6-57 に示すように、「NXSDスキーマのテスト」ダイアログの右ペインに「結果XML」が表示されます。

図6-57 「NXSDスキーマのテスト」ダイアログ

ネイティブ・スキーマを使用して変換したXML

次の例に、変換済のXMLを示します。

例 - ネイティブ・スキーマを使用して変換したXML

<?xml version = '1.0' encoding = 'UTF-8'?>
<Root-Element xmlns="http://TargetNamespace.com/tesNew">
<RECONE>
<C1>Name1</C1>
<C2>2 Old Street, Old Town,Manchester</C2>
<C3>20-08-1954</C3>
<C4>0161-499-1718</C4>
<C5> YES</C5>
</RECONE>
<RECTWO>
<C1>Name2</C1>
<C2>2 Old Street, Old Town,Manchester</C2>
<C3>20-08-1954</C3>
<C4>0161-499-1718</C4>
<C5> NO </C5>
</RECTWO>
<RECTWO>
<C1>Name3</C1>
<C2>2 Old Street, Old Town,Manchester</C2>
<C3>20-08-1954</C3>
<C4>0161-499-1718</C4>
<C5> NO </C5>
</RECTWO>
<RECONE>
<C1>Name4</C1>
<C2>2 Old Street, Old Town,Manchester</C2>
<C3>20-08-1954</C3>
<C4>0161-499-1718</C4>
<C5> YES</C5>
</RECONE>
</Root-Element>

注意:

RECONEおよびRECTWOという2つのレコード・タイプがあります。RECONEは文字YESで終わるレコードを取得し、RECTWOは文字NOで終わるレコードを取得します。

22. 「OK」をクリックします。「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

23. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「終了」ページが表示されます。

6.4.7 複雑なファイル構造の配列タイプ・スキーマの定義

この使用例では、ネイティブ・フォーマット・ビルダーにより、項目の配列を含んだarray.txtという複合タイプのファイルが使用されます。サンプル・データには、4つの名前をセミコロンで区切って末尾にピリオド1個を付けたものが含まれています。この使用例では、メンバー名がセミコロンで区切られて配列がピリオド1個で終了する配列タイプを使用したスキーマを作成します。この使用例を使用すると、NXSDを生成してテストすることもできます。

この使用例を実行する手順は、次のとおりです。

1. サンプル・テキスト・ファイルarray.txt内のデータは、次のとおりです。

John;Steve;Paul;Todd.

2. アダプタ構成ウィザードを起動し、「メッセージ」ページにナビゲートして「ネイティブ・フォーマットのスキーマの定義」をクリックします。「ネイティブ・フォーマット・ビルダー: ようこそ」ページが表示されます。

3. 「次」を選択します。「タイプの選択」ページが表示されます。

4. 「複合タイプ」を選択して「次へ」をクリックします。ネイティブ・フォーマット・ビルダーの「ファイルの説明」ページが表示されます。

5. 図6-58 に示すように、「参照」をクリックしてarray.txtファイルを選択します。ネイティブ・フォーマット・ビルダーの「ファイルの説明」ページが表示されます。

図6-58 「ネイティブ・フォーマット・ビルダー - ファイルの説明」ページ

6. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「設計スキーマ」ページが表示されます。

7. NewArrayというグローバル要素を作成し、このグローバル要素にネイティブ・データをドラッグ・アンド・ドロップします。

8. 図6-59 に示すように、「NewArray」を選択して「ノードの編集」アイコンをクリックします。「要素の詳細」ダイアログが表示されます。

図6-59 「ネイティブ・フォーマット・ビルダー - 設計スキーマ」ページ

9. 「要素の詳細」ダイアログで、図6-60 に示すようにオプションを設定して「OK」をクリックします。

図6-60 「要素の詳細」ダイアログ

ネイティブ・フォーマット・ビルダーの「設計スキーマ」ダイアログが表示されます。

10. 「次」を選択します。図6-61 に示すように、「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページが表示され、ネイティブ・フォーマット・ファイルが表示されます。

図6-61 「生成されたネイティブ・フォーマット・スキーマ・ファイル」ページ

ネイティブ・スキーマ

前述のネイティブ・データに対応するネイティブ・スキーマの定義は、次のように定義できます。

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:tns="http://TargetNamespace.com/testnewArray"
targetNamespace="http://TargetNamespace.com/testnewArray"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:version="NXSD"
nxsd:stream="chars"
nxsd:encoding="ASCII"
>
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="NewArray" type="xsd:string" maxOccurs="unbounded"
nxsd:style="array" nxsd:cellSeparatedBy=";" nxsd:arrayTerminatedBy="." />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

11. 「テスト」をクリックします。「NXSDスキーマのテスト」ダイアログが表示されます。

12. 「XMLの生成」アイコンをクリックします。図6-62 に示すように、「NXSDスキーマのテスト」ダイアログの右ペインに「結果XML」が表示されます。

図6-62 「NXSDスキーマのテスト」ダイアログ

ネイティブ・スキーマを使用して変換したXML

変換されたXMLは次のようになります。

<?xml version = '1.0' encoding = 'UTF-8'?>
<Root-Element xmlns="http://TargetNamespace.com/testnewArray">
<NewArray>John</NewArray>
<NewArray>Steve</NewArray>
<NewArray>Paul</NewArray>
<NewArray>Todd</NewArray>
</Root-Element>

13. 「OK」をクリックします。「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

14. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「終了」ページが表示されます。

6.4.8 DTDファイル構造のスキーマの定義

この使用例では、DTDファイルというネイティブ・データ・タイプのスキーマを定義する手順を説明します。

このネイティブ・ファイルのXMLスキーマを作成する際には、ネイティブ・フォーマット・ビルダー・ウィザードの「XSDに変換するDTD」オプションを使用します。

この使用例では、ネイティブ・フォーマット・ビルダーにより、DTDファイル・タイプ*.dtdが使用されます。対応するNXSDを生成し、同様にテストできます。この使用例を実行する手順は、次のとおりです。

1. 任意のDTDファイルを使用します。

2. 図6-4 に示すように、アダプタ構成ウィザードを起動し、「メッセージ」ページにナビゲートして「ネイティブ・フォーマットのスキーマの定義」をクリックします。図6-5 に示すように、「ネイティブ・フォーマット・ビルダー: ようこそ」ページが表示されます。

3. 「次」を選択します。図6-26 に示すように、「タイプの選択」ページが表示されます。

4. 「XSDに変換するDTD」を選択します。図6-63 に示すように、「タイプの選択」ページが表示されます。

図6-63 「ネイティブ・フォーマット・ビルダー・ウィザード - タイプの選択」ページ

5. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「DTDの説明」ページが表示されます。

6. 図6-64 に示すように、「参照」をクリックしてdb.dtdファイルを選択し、「ルート要素」リストから「DatabaseInventory」を選択します。

図6-64 「ネイティブ・フォーマット・ビルダー・ウィザード - ファイルの説明」ページ

7. 「次」を選択します。図6-65 に示すように、「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

図6-65 「ネイティブ・フォーマット・ビルダー・ウィザード - フィールド・プロパティ」ページ

次の例に、生成されたネイティブ・フォーマット・ファイルの結果を示します。

例 - 生成されたネイティブ・フォーマット・ファイル

<?xml version="1.0" encoding="UTF-8" ?>
<!--This Schema has been generated from a DTD.
A target namespace has beenadded to the schema.-->
<xs:schema xmlns:
xs="http://www.w3.org/2001/XMLSchema"
targetNamespace=
"http://TargetNamespace.com/ReadUI"
xmlns="http://TargetNamespace.com/ReadUI"
nxsd:version="DTD"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd">
<xs:element name="GlobalDatabaseName"
type="xs:string"/>
<xs:element name="DatabaseAttributes">
<xs:complexType>
<xs:attribute name="Type"
use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration
value="Production"/>
<xs:enumeration
value="Development"/>
<xs:enumeration
value="Testing"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="Version"
use="optional" default="9i">
<xs:simpleType>
<xs:restriction base=
"xs:NMTOKEN">
<xs:enumeration value="7"/>
<xs:enumeration value="8"/>
<xs:enumeration value="8i"/>
<xs:enumeration value="9i"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="Comments" type="xs:string"/>
<xs:element name="Administrator">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="EmailAlias"
use="required"
type="xs:string"/>
<xs:attribute name="Extension"
use="optional" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="OracleSID"
type="xs:string"/>
<xs:element name="DatabaseName">
<xs:complexType>
<xs:sequence>
<xs:element
ref="GlobalDatabaseName"/>
<xs:element
ref="OracleSID"/>
<xs:element
ref="DatabaseDomain"/>
<xs:element
maxOccurs="unbounded" ref="Administrator"/>
<xs:element
ref="DatabaseAttributes"/>
<xs:element
ref="Comments"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DatabaseDomain"
type="xs:string"/>
<xs:element name="DatabaseInventory">
<xs:complexType>
<xs:sequence>
<xs:element
maxOccurs="unbounded"
ref="DatabaseName"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

8. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「終了」ページが表示されます。

9. 「終了」をクリックします。生成されたNXSDを含んだアダプタ構成ウィザードの「メッセージ」ページが表示されます。

6.4.9 COBOLコピーブック・ファイル構造のスキーマの定義

この使用例は、変換用のネイティブ・スキーマ・ファイルを作成するために、(ネイティブ・フォーマット・ビルダー・ウィザードを使用して) COBOLコピーブック・フォーマットのファイルをどのように処理するかを示しています。

次のCOBOLコピーブックの例も提供されています。

- 複数のルート・レベル

- 単一のルート・レベル、仮想小数点、固定長配列

- 可変長配列

- 数値のタイプ

6.4.9.1 複数のルート・レベル

COBOLコピーブックには、複数のルート・レベルを含めることができます。すべてのルート・レベルが01のレベルの場合、各グループは暗黙的に他のグループを再定義します。

この使用例では、ネイティブ・フォーマット・ビルダーにより、購入者名、住所および項目などの注文書詳細を含んだpo-ccb.cpyという固定長ファイル・タイプが使用されます。このpo-ccb.cpyネイティブ・ファイル内の要素は、すべて固定長です。サンプル・テキスト・ファイルpo-ccb.cpy内のデータは、次のとおりです。

05 PO-RECORD.
10 PO-BUYER.
15 PO-UID PIC 9(7).
15 PO-NAME PIC X(15).
15 PO-ADDRESS.
20 PO-STREET PIC X(15).
20 PO-CITY PIC X(10).
20 PO-ZIP PIC 9(5).
20 PO-STATE PIC X(2).
10 PO-ITEM.
15 POITEM OCCURS 3 TIMES.
20 PO-LINE-ITEM.
25 PO-ITEM-ID PIC 9(3).
25 PO-ITEM-NAME PIC X(40).
25 PO-ITEM-QUANTITY PIC 9(2).
25 PO-ITEM-PRICE PIC 9(5)V9(2).
10 PO-TOTALPIC 9(7)V9(2).

対応するNXSDを生成し、同様にテストできます。この使用例を実行する手順は、次のとおりです。

1. Adapters-105CobolCopyBookサンプルに含まれているartifacts.zipファイルから次のファイルを取得します。

- artifacts/samples/po-ccb.cpy

- artifacts/samples/po-ebcdic.data

Adapters-105CobolCopyBookサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

これらのファイルをサンプル・ディレクトリにコピーします。

2. 図6-4 に示すように、アダプタ構成ウィザードを起動し、「メッセージ」ページにナビゲートして「ネイティブ・フォーマットのスキーマの定義」をクリックします。図6-5 に示すように、「ネイティブ・フォーマット・ビルダー: ようこそ」ページが表示されます。

3. 「次」を選択します。図6-26 に示すように、「タイプの選択」ページが表示されます。

4. 「ネイティブ・フォーマットに変換するCOBOLコピーブック」を選択します。図6-66 に示すように、「タイプの選択」ページが表示されます。

図6-66 「ネイティブ・フォーマット・ビルダー・ウィザード - タイプの選択」ページ

5. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「COBOLコピーブックの説明」ページが表示されます。

6. 図6-67 に示すように、「参照」をクリックしてpo-ccb.cpyファイルを選択します。

図6-67 「ネイティブ・フォーマット・ビルダー・ウィザード - ファイルの説明」ページ

7. 「Root-Element」フィールドにPurchaseOrderと入力して「次へ」をクリックします。図6-68 に示すように、「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

図6-68 「ネイティブ・フォーマット・ビルダー・ウィザード - 生成されたネイティブ・フォーマット・ファイル」ページ

最上位のペイロード・レコードは、choiceモデル・グループに囲まれています。各ペイロード・レコードには、実行時のデータ・ファイルの処理中におけるレコード・タイプの識別に役立つnxsd:lookAheadおよびnxsd:lookForの2つの属性もあります。そのため、これらの属性に値を追加する必要があります。たとえば、PAYROLL-F-TRANS-CODEフィールドの値がFRのときに、PAYROLL-F-RECORDが発生するとします。その後、レコード要素は次のようになります。

<xsd:element name="PAYROLL-F-RECORD" nxsd:lookAhead="10" nxsd:lookFor="FR">

値10はlookaheadフィールドの位置を示します。次のCOBOLコピーブックでは、05レベルに複数のルート要素があります。

05 ORG-NUM           PIC 99.
05 EMP-RECORD.
10 EMP-SSN       PIC 9(4)V(6).
10 EMP-WZT       PIC 9(6).

次の例に、ネイティブ・スキーマを示します。

例 - ネイティブ・スキーマ

<?xml version="1.0" encoding="UTF-8" ?>
<!--Native format was generated from COBOL copybook : C:\Documents and
Settings\vdinesh\Desktop\sample_files\po-ccb.cpy-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:extn="http://xmlns.oracle.com/pcbpel/nxsd/extensions"
targetNamespace="http://TargetNamespace.com/Read"
xmlns:tns="http://TargetNamespace.com/Read"
elementFormDefault="qualified"
attributeFormDefault="unqualified" nxsd:version="NXSD"
nxsd:encoding="cp037"
nxsd:byteOrder="bigEndian" nxsd:stream="chars">
<xsd:element name="PurchaseOrder">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration : 05 PO-RECORD-->
<xsd:element name="PO-RECORD"
minOccurs="1"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration : 10 PO-BUYER-->
<xsd:element name="PO-BUYER">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :
15 PO-UID PIC 9(7)-->
<xsd:element name="PO-UID"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0"
nxsd:length="7"/>
<!--COBOL declaration :
15 PO-NAME PIC X(15)-->
<xsd:element name="PO-NAME"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="15"/>
<!--COBOL declaration :
15 PO-ADDRESS-->
<xsd:element name="PO-ADDRESS">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :
20 PO-STREET PIC X(15)-->
<xsd:element name="PO-STREET"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="15"/>
<!--COBOL declaration :
20 PO-CITY PIC X(10)-->
<xsd:element name="PO-CITY"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="10"/>
<!--COBOL declaration : 20 PO-ZIP PIC 9(5)-->
<xsd:element name="PO-ZIP"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0" nxsd:length="5"/>
<!--COBOL declaration : 20 PO-STATE PIC
X(2)-->
<xsd:element name="PO-STATE"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" " nxsd:length="2"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!--COBOL declaration : 10 PO-ITEM-->
<xsd:element name="PO-ITEM">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :
15 POITEM OCCURS 3 TIMES-->
<xsd:element name=
"POITEM" minOccurs="3" maxOccurs="3">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration
: 20 PO-LINE-ITEM-->
<xsd:element name="PO-LINE-ITEM">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :
25 PO-ITEM-ID PIC 9(3)-->
<xsd:element name="PO-ITEM-ID"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0" nxsd:length="3"/>
<!--COBOL declaration :
25 PO-ITEM-NAME PIC X(40)-->
<xsd:element name="PO-ITEM-NAME"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy="
" nxsd:length="40"/>
<!--COBOL declaration :
25 PO-ITEM-QUANTITY PIC 9(2)-->
<xsd:element name=
"PO-ITEM-QUANTITY"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0"
nxsd:length="2"/>
<!--COBOL declaration :
25 PO-ITEM-PRICE PIC 9(5)V9(2)-->
<xsd:element name=
"PO-ITEM-PRICE"
type="xsd:decimal"
nxsd:style="virtualDecimal"
extn:assumeDecimal="5"
extn:picSize="7"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!--COBOL declaration :
10 PO-TOTAL PIC 9(7)V9(2)-->
<xsd:element name="PO-TOTAL"
type="xsd:decimal"
nxsd:style="virtualDecimal"
extn:assumeDecimal="7" extn:picSize="9"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

8. 「テスト」をクリックします。「NXSDスキーマのテスト」ダイアログが表示されます。

9. 「参照」をクリックし、「ファイル名」フィールドでpo-ebcdic.dataファイルを選択します。図6-69 に示すように、「NXSDスキーマのテスト」ダイアログが表示されます。

図6-69 「NXSDスキーマのテスト」ダイアログ

10. 「XMLの生成」アイコンをクリックします。図6-70 に示すように、「NXSDスキーマのテスト」ダイアログの右ペインに「結果XML」が表示されます。

図6-70 「NXSDスキーマのテスト」ダイアログ

対応するネイティブ・スキーマ・フォーマットを使用したネイティブ・データは、次の例に示すように、次のXMLに変換されます。

例 - 対応するネイティブ・スキーマを使用したネイティブ・データ

<?xml version = '1.0' encoding = 'UTF-8'?>
<PurchaseOrder
xmlns="http://TargetNamespace.com/Read">
<PO-RECORD>
<PO-BUYER>
<PO-UID>6335722</PO-UID>
<PO-NAME>Company One</PO-NAME>
<PO-ADDRESS>
<PO-STREET>First Street</PO-STREET>
<PO-CITY>San Jose</PO-CITY>
<PO-ZIP>95129</PO-ZIP>
<PO-STATE>CA</PO-STATE>
</PO-ADDRESS>
</PO-BUYER>
<PO-ITEM>
<POITEM>
<PO-LINE-ITEM>
<PO-ITEM-ID>1</PO-ITEM-ID>
<PO-ITEM-NAME>
BPEL Process Manager Enterprise
Edition</PO-ITEM-NAME>
<PO-ITEM-QUANTITY>2
</PO-ITEM-QUANTITY>
<PO-ITEM-PRICE>40000.0
</PO-ITEM-PRICE>
</PO-LINE-ITEM>
</POITEM>
<POITEM>
<PO-LINE-ITEM>
<PO-ITEM-ID>2</PO-ITEM-ID>
<PO-ITEM-NAME>
BPEL Process Manager Standard
Edition</PO-ITEM-NAME>
<PO-ITEM-QUANTITY>5
</PO-ITEM-QUANTITY>
<PO-ITEM-PRICE>50000.0
</PO-ITEM-PRICE>
</PO-LINE-ITEM>
</POITEM>
<POITEM>
<PO-LINE-ITEM>
<PO-ITEM-ID>3</PO-ITEM-ID>
<PO-ITEM-NAME>
BPEL Process Manager Developer
Edition</PO-ITEM-NAME>
<PO-ITEM-QUANTITY>20
</PO-ITEM-QUANTITY>
<PO-ITEM-PRICE>20000.0
</PO-ITEM-PRICE>
</PO-LINE-ITEM>
</POITEM>
</PO-ITEM>
<PO-TOTAL>730000.0</PO-TOTAL>
</PO-RECORD>
</PurchaseOrder>

この場合(01レベル以外の場合)、バインドされていない一連のルート・レベル・アイテムが生成されます。

11. 「OK」をクリックします。「生成されたネイティブ・フォーマット・ファイル」ページが表示されます。

12. 「次」を選択します。ネイティブ・フォーマット・ビルダーの「終了」ページが表示されます。

13. 「終了」をクリックします。生成されたNXSDを含んだアダプタ構成ウィザードの「メッセージ」ページが表示されます。

6.4.9.2 単一のルート・レベル、仮想小数点、固定長配列

次のCOBOLコピーブックには、単一のルート・レベル・アイテムPO-RECORDがあります。単一のルート・レベルの場合には、コンバータの動作は同じであるためレベル番号は問題ではありません。このCOBOLコピーブックでは、仮想小数点として宣言されたフィールド(PO-ITEM-PRICE)の例も示しています。

05 PO-RECORD.
10 PO-BUYER.
15 PO-UID    PIC 9(7).
15 PO-NAME   PIC X(15).
15 PO-ADDRESS.
20 PO-STREET PIC X(15).
20 PO-CITY   PIC X(10).
20 PO-ZIP    PIC 9(5).
20 PO-STATE  PIC X(2).
10 PO-ITEM.
15 POITEM OCCURS 3 TIMES.
20 PO-LINE-ITEM.
25 PO-ITEM-ID       PIC 9(3).
25 PO-ITEM-NAME     PIC X(40).
25 PO-ITEM-QUANTITY PIC 9(2).
25 PO-ITEM-PRICE    PIC 9(5)V9(2).
10 PO-TOTAL PIC  9(7)V9(2).

生成されるスキーマは次のようになります。

例 - 生成されたスキーマ

<?xml version="1.0" encoding="UTF-8" ?>
<!--Native format was generated from COBOL copybook:D:\work\
jDevProjects\CCB\Copybooks\po-ccb.cpy-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:extn="http://xmlns.oracle.com/
pcbpel/nxsd/extensions"
targetNamespace=
"http://TargetNamespace.com/ccb/singleRoot"
xmlns:tns="http://TargetNamespace.com/ccb/singleRoot"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:version="NXSD" nxsd:encoding=
"cp037" nxsd:byteOrder="bigEndian"
nxsd:stream="chars">
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration : 05 PO-RECORD -->
<xsd:element name="PO-RECORD"
minOccurs="1"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration : 10 PO-BUYER-->
<xsd:element name="PO-BUYER">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration : 15 PO-UID PIC 9(7)-->
<xsd:element name="PO-UID"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0" nxsd:length="7"/>
<!--COBOL declaration :
15 PO-NAME PIC X(15)-->
<xsd:element name="PO-NAME"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="15"/>
<!--COBOL declaration : 15 PO-ADDRESS-->
<xsd:element name="PO-ADDRESS">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :
20 PO-STREET PIC X(15)-->
<xsd:element name="PO-STREET"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail" nxsd:paddedBy=" "
nxsd:length="15"/>
<!--COBOL declaration :
20 PO-CITY PIC X(10)-->
<xsd:element name="PO-CITY"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="10"/>
<!--COBOL declaration :
20 PO-ZIP PIC 9(5)-->
<xsd:element name="PO-ZIP"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0"
nxsd:length="5"/>
<!--COBOL declaration :
20 PO-STATE PIC X(2)-->
<xsd:element name="PO-STATE"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="2"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!--COBOL declaration : 10 PO-ITEM-->
<xsd:element name="PO-ITEM">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :
15 POITEM OCCURS 3 TIMES-->
<xsd:element name="POITEM" minOccurs="3"
maxOccurs="3">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration : 20 PO-LINE-ITEM-->
<xsd:element name="PO-LINE-ITEM">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :
25 PO-ITEM-ID PIC 9(3)-->
<xsd:element name="PO-ITEM-ID"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0"
nxsd:length="3"/>
<!--COBOL declaration :
25 PO-ITEM-NAME PIC X(40)-->
<xsd:element name="PO-ITEM-NAME"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="40"/>
<!--COBOL declaration :
25 PO-ITEM-QUANTITY
PIC 9(2)-->
<xsd:element name="PO-ITEM-QUANTITY"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0"
nxsd:length="2"/>
<!--COBOL declaration :
25 PO-ITEM-PRICE PIC
9(5)V9(2)-->
<xsd:element name="PO-ITEM-PRICE"
type="xsd:decimal"
nxsd:style="virtualDecimal"
extn:assumeDecimal="5"
extn:picSize="7"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!--COBOL declaration : 10 PO-TOTAL PIC 9(7)V9(2)-->
<xsd:element name="PO-TOTAL" type="xsd:decimal"
nxsd:style="virtualDecimal"
extn:assumeDecimal="7"
extn:picSize=" "/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

6.4.9.3 可変長配列

05 EMP-RECORD .
10 EMP-NAME         PIC X(30).
10 EMP-DIV-NUM      PIC 9(5).
10 DIV-ENTRY OCCURS 1 TO 50 TIMES
DEPENDING ON EMP-DIV-NUM.
20 DIV-CODE             PIC X(30).

次の例に、生成されたスキーマを示します。

例 - 可変長配列の生成されたスキーマ

<?xml version="1.0" encoding="UTF-8" ?>
<!--Native format was generated from COBOL copybook:D:\work\
jDevProjects\CCB\Copybooks\odo.cpy-->
<xsd:schema xmlns:xsd=
"http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:extn="http://xmlns.oracle.com/
pcbpel/nxsd/extensions"
targetNamespace=
"http://TargetNamespace.com/
ccb/varLengthArray"
xmlns:tns="http://TargetNamespace.com/
ccb/varLengthArray"
elementFormDefault="qualified"
attributeFormDefault=
"unqualified"
nxsd:version="NXSD" nxsd:encoding="cp037"
nxsd:byteOrder="bigEndian"
nxsd:stream="chars">
<xsd:element name="Root-Element">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :05 EMP-RECORD -->
<xsd:element name="EMP-RECORD"
minOccurs="1"
maxOccurs="unbounded">
<xsd:annotation>
<xsd:appinfo>
<nxsd:variables>
<nxsd:variable name="DIV-ENTRY_var0"/>
</nxsd:variables>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration:10 EMP-NAME PIC X(30)-->
<xsd:element name="EMP-NAME"
type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="30"/>
<!--COBOL declaration:10 EMP-DIV-NUM PIC 9(5)-->
<xsd:element name="EMP-DIV-NUM"
type="xsd:long"
nxsd:style="fixedLength"
nxsd:padStyle="head"
nxsd:paddedBy="0"
nxsd:length="5">
<xsd:annotation>
<xsd:appinfo>
<nxsd:variables>
<nxsd:assign name="DIV-ENTRY_var0"
value="${0}"/>
</nxsd:variables>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<!--COBOL declaration :10 DIV-ENTRY OCCURS 1 TO 50 TIMES DEPENDING ON
EMP-DIV-NUM-->
<xsd:element name="DIV-ENTRY"
nxsd:style="array"
nxsd:arrayLength=
"${DIV-ENTRY_var0}"
minOccurs="1"
maxOccurs="50">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration : 20 DIV-CODE PIC X(30)-->
<xsd:element name=
"DIV-CODE" type="xsd:string"
nxsd:style="fixedLength"
nxsd:padStyle="tail"
nxsd:paddedBy=" "
nxsd:length="30"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

6.4.9.4 数値のタイプ

01   NUMERIC-FORMATS.
05    Salary         PIC 9(5) COMP-3.
05    Rating         PICTURE S9(5).
05    Age            PIC 9(3) USAGE COMP.
05    Revenue        PIC 9(3)V9(2).
05    Growth         PIC S9(3) SIGN IS LEADING.
05    Computation    COMP-1.

次の例に、生成されたスキーマを示します。

例 - 数値タイプの生成されたスキーマ

<?xml version="1.0" encoding="UTF-8" ?>
<!--Native format was generated from COBOL copybook :
D:\work\jDevProjects\CCB\Copybooks\numeric.cpy-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
xmlns:extn="http://xmlns.oracle.com/pcbpel/nxsd/extensions"
targetNamespace="http://TargetNamespace.com/ccb/numeric"
xmlns:tns="http://TargetNamespace.com/ccb/numeric"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:version="NXSD" nxsd:encoding="cp037"
nxsd:byteOrder="bigEndian"
nxsd:stream="bytes">
<xsd:element name="Numerics">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration :01 NUMERIC-FORMATS-->
<xsd:element name="NUMERIC-FORMATS"
minOccurs="1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<!--COBOL declaration : 05 Salary PIC 9(5) COMP-3-->
<xsd:element name="Salary"
type="xsd:long" nxsd:style="comp3"
extn:sign="unticked" extn:picSize="5"/>
<!--COBOL declaration:05 Rating PICTURE S9(5)-->
<xsd:element name="Rating"
type="xsd:string"
nxsd:style="signZoned" extn:sign="ticked"
extn:picSize="5"
extn:signPosn="tailUpperNibble"/>
<!--COBOL declaration:05 Age PIC 9(3) USAGE COMP-->
<xsd:element name="Age" type="xsd:long"
nxsd:style="comp"
extn:picSize="3" extn:sign="unticked"/>
<!--COBOL declaration:05 Revenue PIC 9(3)V9(2)-->
<xsd:element name="Revenue" type="xsd:decimal"
nxsd:style="virtualDecimal"
extn:assumeDecimal="3"
extn:picSize="5"/>
<!--COBOL declaration : 05 Growth PIC S9(3) SIGN IS LEADING-->
<xsd:element name="Growth" type="xsd:string"
nxsd:style="signZoned"
extn:sign="ticked"
extn:picSize="3"
extn:signPosn="headUpperNibble"/>
<!--COBOL declaration : 05 Computation COMP-1-->
<xsd:element name="Computation"
type="xsd:float"
nxsd:style="comp1" extn:sign="ticked"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

この場合、すべての数値のタイプはIBM COBOLフォーマットに応じて指定されたフォーマットに従います。異なるレイアウトを使用して異なるシステムで作成されたデータ・ファイルの場合は、生成されたスキーマを変更する必要があります。

6.5 nXSDトランスレータのテスト用コマンドライン・ツール

nXSD注釈が正しいことや、生成されたXML/ネイティブ・データがビジネス・セマンティクスに準拠していることを確認するために、nXSDスキーマのテストが必要になる場合があります。現在この作業を行うには、インバウンドまたはアウトバウンド、あるいはその両方のファイル・アダプタ・パートナ・リンクを含んだBPELプロセスを記述し、適切なnXSDスキーマで構成した後、SOAサーバー上でそれらをテストする必要があります。この場合、作業に時間がかかり、エラーも起こりやすくなります。

単純なスタンドアロン・テスト・クライアントを使用することで、NXSDスキーマを検証できるようになります。テスト・ツールjarは、http://download.oracle.com/otndocs/test-translator.jarからダウンロードできます

6.5.1 前提条件

テスト・クライアントを使用してnXSDスキーマを検証する前に、次のjarをクラスパスに追加します。これらのjar (test-translator.jarを除く)は、SOAインストールに含まれています。テスト・クライアントを実行するには、Java 6を使用する必要があります。

- bpm-infra.jar。これはnXSDランタイムjarで、$SOA_HOME/soa/modules/oracle.soa.fabric_11.1.1にあります

- xmlparserv2.jar。これは解析用のOracle XDKライブラリで、$FMW_HOME/oracle_common/modules/oracle.xdk_11.1.0にあります

- xml.jar これはスキーマ検証用のOracle XDKライブラリで、$FMW_HOME/oracle_common/modules/oracle.xdk_11.1.0にあります

- mail.jar。これはJavaメールAPIです。

- test-translator.jar。jarrからjarに拡張子を変更する必要があります。

6.5.2 テスト・ツールの実行

java xlator.util.Translate -helpを実行すると、図6-71 に示すように使用方法が表示されます。-helpオプションを指定することで、ツールのオプションおよびデフォルトのリストを表示できます。

図6-71 java xlator.util.Translate -helpの実行

次の例では、テスト・クライアントを実行してaddress-csv.txtファイルをaddress-csv.xmlに変換しています。

コマンドは、java xlator.util.Translate -inbound -schema address-csv.xsd -root Root-Element -input address-csv.txt -output address-csv.xmlです

図6-72 テスト・ツールを使用したtxtからxmlへの変換

テスト・クライアントを実行してaddress-csv.xmlをaddress-csv.txtに変換する例は、次のとおりです。

java xlator.util.Translate -outbound -schema address-csv.xsd -root Root-Element -input address-csv.xml -output address-csv.txt

図6-73 テスト・ツールを使用したxmlからtxtへの変換

次のテスト・クライアントの実行例では、デバッチ処理を使用してaddress-csv.txtを一連のaddress-csv.xml_batch_%SEQ%.xmlファイルに変換します。

java xlator.util.Translate -inbound -debatch 1 -schema address-csv.xsd -root Root-Element -input address-csv.txt -output address-csv.xml

図6-74 テスト・ツールを使用したaddress-csv.txtから一連のバッチxmlファイルへの変換

6.5.3 ネイティブ・フォーマット・ビルダーを使用したMFL変換の実行

Oracle WebLogic統合では、ネイティブ・データを記述する固有の言語である特定のXMLファイル形式(MFLフォーマット言語と呼ばれます)を使用します。MFLはXMLですがスキーマ・ファイルではないため、nXSDファイルを使用しないでSOAトランスフォーメーションおよびマッピングにMFLを使用することはできません。

MFL変換機能により、既存のフレームワークでのMFLのプラガビリティが向上し、MFLフォーマットに対応するスキーマが生成されます。その後、生成されたスキーマを実行時に使用できます。

MFLの詳細は、Open Service Busのドキュメント『Oracle Service Busでのサービスの開発』のメッセージ・フォーマット言語を使用したデータの変換に関する説明を参照してください。

6.5.3.1 MFLフォーマット・ファイルからスキーマ・フォーマットへの変換

最初のステップを実行するには、MFLをNXSDスキーマ・ファイルに変換するようJDeveloperに指示します。

6.5.3.2 スキーマ・ファイルの生成およびSOAコンポジット・プロセスへの追加

JDeveloperを使用して、ネイティブ・フォーマット・ビルダーのトランスレータが使用するスキーマ・ファイルを生成します。MFLファイルにはそれらに関連するターゲット・ネームスペースがないため、生成されたスキーマ・ファイルにターゲット・ネームスペースを指定する必要があります。

MFLからスキーマ・ファイルに変換するときに、生成されたスキーマ・ファイルをSOAプロジェクトのXSDディレクトリに保存した場合は、この手順をスキップできます。

SOAプロジェクト以外のディレクトリでスキーマ・ファイルを生成した場合、ステップ1で生成したスキーマ・ファイルをSOAコンポジット・プロジェクトのXSDフォルダに追加する必要があります。

スキーマ・ファイルをSOAプロジェクトに追加すると、変数へのペイロード・トランスフォーメーションまたはペイロード・マッピングにプロジェクトのスキーマ・ファイルを使用する場合と同様に、このスキーマ・ファイルを使用できます。実行時トランスレータは、スキーマ・ファイルで定義した属性を使用して、実行時にMFLトランスレータを起動します。

6.5.3.2.1 MFLファイルの例

MFLファイルの例は次のとおりです。

<?xml version='1.0' encoding='windows-1252'?>
<!DOCTYPE MessageFormat SYSTEM 'mfl.dtd'>
<MessageFormat name='Root-Element' version='2.01'>
<StructFormat name='Address' repeat='*'>
<FieldFormat name='Name' type='String' delim=',' codepage='windows-1252'/>
<FieldFormat name='Street1' type='String' delim=','            codepage='windows-1252'/>
</StructFormat>
</MessageFormat>

6.5.3.2.2 MFLファイルの例から作成されるスキーマ・ファイルの例

MFLファイルから作成されるスキーマ・ファイルには、次の2つの新しいネームスペースがあります。

- xmlns:mfl="http://www.bea.com/mfl"

- xmlns:nxsd=http://xmlns.oracle.com/pcbpel/nxsd

さらに、スキーマのNXSDトランスレータのバージョンが、次のようにMFLに設定されます(nxsd:version="MFL")。

MFLファイルから作成されるスキーマ・ファイルの例を次に示します。

例 - MFLファイルから作成されるスキーマ・ファイルの例

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://MyTNS1"
targetNamespace="http://MyTNS1"
xmlns:mfl="http://www.bea.com/mfl" xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
elementFormDefault="qualified"
nxsd:version="MFL">
<xsd:import namespace="http://www.bea.com/mfl"
schemaLocation="mfl.xsd"/>
<xsd:element name="Root-Element">
<xsd:annotation>
<xsd:appinfo>
<mfl:MessageFormat encoding="windows-1252"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Address" minOccurs="1"
maxOccurs="unbounded">
<xsd:annotation>
<xsd:appinfo>
<mfl:StructFormat repeat="*"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name" type="mfl:String">
<xsd:annotation>
<xsd:appinfo>
<mfl:FieldFormat delim=","
codepage="windows-1252"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<xsd:element name=
"Street1" type="mfl:String">
<xsd:annotation>
<xsd:appinfo>
<mfl:FieldFormat delim=","
codepage="windows-1252"/>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

6.5.3.3 ネイティブ・フォーマット・ビルダー・ウィザードでのMFLファイル変換のフロー

ネイティブ・フォーマット・ビルダー・ウィザードを使用してMFLファイルの変換およびMFLファイルからのスキーマ・ファイルの生成を行うには、次の手順を実行します。

1. 「タイプの選択」ページで、「新規作成」→「NXSDに対するMFLの作成」を選択します。

図6-75 「XSDに変換するMFL」が選択されているネイティブ・フォーマット・ビルダーの「タイプの選択」画面

2. ネイティブ・フォーマット・ビルダー・ウィザードに、「説明」画面が表示されます。XSDに変換するMFLファイルの場所とスキーマ・ファイルに指定するターゲット・ネームスペースを指定します。「次へ」をクリックします。

図6-76 ネイティブ・フォーマット・ビルダー・ウィザードの「MFLの説明」画面

3. ファイルの場所とターゲット・ネームスペースを指定すると、生成されたスキーマ・ファイルがウィザードに表示されます。必要に応じて、生成されたスキーマ・ファイルを編集して希望の場所に保存できますが、通常は、SOAコンポジット・プロジェクトのXSDフォルダの場所に保存します。

図6-77 ネイティブ・フォーマット・ビルダーの「生成されたネイティブ・フォーマット・スキーマ・ファイル」画面

4. 「次へ」をクリックすると、スキーマ・ファイルが存在する場所を示す「ネイティブ・フォーマット・ビルダー: 終了」画面が表示されます。

図6-78 「ネイティブ・フォーマット・ビルダー: 終了」画面

「終了」をクリックすると、MFLファイルからのスキーマ・ファイルの生成が完了します。生成されたスキーマ・ファイルは、希望の場所に保存されます。

6.5.4 マルチキャラクタ・ストリーミングのサポート

多くの場合、固定長のデータ長は文字ではなくバイトで使用できます。フィールド・データは、マルチバイト・キャラクタ・エンコーディングです。

この場合、バイト数はフィールドの文字数と等しくなりません。このタイプのデータの読取りは、NXSDトランスレータではサポートされていません。

現在、トランスレータでは文字の長さのみが想定されています。トランスレータは、文字リーダーを使用して指定の文字数を読み取ります。

マルチバイト・ストリーミングのサポートによって、フィールドの長さをバイトで指定できます。トランスレータはバイト・リーダーを使用して指定のバイト数を読み取り、読み取ったバイトを文字に変換します。これらの文字は生成されたXMLに配置されます。

同様に、アウトバンド・トランスレータはXMLデータを指定のバイト長に変換し、これらのバイトを出力ストリームに書き込みます。

6.5.5 共有デリミタ

ネイティブ・フォーマット・ビルダーを使用するときは、多くの場合デリミタを使用します。ネイティブ・フォーマット・ビルダー内でのデリミタの動作は、使用するコンテキストによって異なります。

たとえば、スキーマ・ドキュメントにオプション・ノードがある場合、親のデリミタの存在は、ネイティブ・ストリームにこれらのオプション・ノードに対応するデータがない可能性があることを示しています。または、親のデリミタ自体がオプション・ノードのデータの一部である可能性があります。すべては、コンテキストに依存します。

同様に、アウトバウンド・シナリオでは、グループの最終フィールドを処理するときに、グループ・デリミタが後に続く最終フィールドのデリミタを配置するのか、単にグループ・デリミタを配置するだけで十分なのかといったヒントをNXSDトランスレータに示す必要がある場合があります。

共有デリミタのアプローチによって、NXSDトランスレータは、コンテキストに基づいてデリミタが暗示するこのような微妙な相違に対応し、コンテキスト内のデリミタの意味を制御するためのカスタム注釈を提供します。

6.5.5.1 インバウンドの共有デリミタ処理を使用するNXSDトランスレータの基本概念

共有デリミタは、デリミタがデータ・グループの最後とグループの最終フィールドの最後の両方にマーク付けすることを意味します。デリミタは、グループの最終フィールドとグループの最後の間で共有されます。

6.5.5.1.1 セルおよび配列の終了

NXSDフレームワークでは、配列を使用して繰返し構造を定義します。nxsd:cellSeparatedByコンストラクトは、配列の各セルのデリミタを定義します。このデリミタは、この構造の最終フィールドのデリミタより前に検出された場合に、構造のセルと最終フィールドの両方を終了するために使用します。

nxsd:arrayTerminatedByコンストラクトは、配列自体の最後にマーク付けします。cellSeparatedByデリミタよりも前に検出された場合に、セルと配列を終了するために使用します。

6.5.5.1.2 重要な用語

次の用語は、共有デリミタの概念を理解する上で重要です。

- 最終の非オプション・ノード: 配列でラップされた列構造に存在するノード。このノードは必須で、これより後ろの後続ノードはすべてオプションです。

- 後続のオプション・ノード: 配列でラップされた列構造に存在するノード。このノードはオプションで、このノードより後ろの後続ノードはすべてオプションです。

- 保留中のデリミタのリスト: 隣接した親配列デリミタ(これ自体が、共有デリミタを含む配列の最後の必須ノードである場合があります)から始まるすべてのデリミタを含むリスト。

- 配列: セルの集合。

- 配列の終端文字: 配列の最後にマーク付けします。

- セル・セパレータ: 配列の各セルの最後にマーク付けします。

- 各セルには構造を含めることができます(一般的に構造は繰り返されるため、配列で囲まれます)。

- 構造には、必須要素とオプション要素を含めることができます。

- デリミタは、次の異なるレベルで存在できます。

- フィールド・レベル

- グループ・レベル

6.5.5.1.3 セル・セパレータおよび配列の終端文字の共有

セル・セパレータまたは配列の終端文字のいずれか、またはその両方をグループの要素と共有できます。セル・セパレータは、セルの共有境界を定義します。配列の終端文字は配列を定義し、配列に後続のオプション・フィールドがあるかどうかを指定します。

次の2つの注釈を使用して、グループの要素と共有される終端文字を指定できます。

- nxsd:cellSeparator="shared" 配列のセル・セパレータを、最後の非オプション・フィールドのデリミタまたは後続オプション・フィールドのデリミタと共有することを定義します。この注釈のデフォルト値はnonsharedです。この場合、共有モードで、トランスレータが配列内の最後の非オプション・フィールドまたは後続オプション・フィールドの処理中にセル・セパレータを検出すると、トランスレータはこのフィールドが終了し、配列に後続オプション・フィールドが含まれないとみなします。フィールドが終了し、後続オプション・フィールドがない場合、トランスレータはセルとともに現在のフィールドを閉じます。

- nxsd:arrayTerminator="shared" 配列の終端文字は、セル・セパレータおよび最後の非オプション・フィールドと共有されるか、後続オプション・フィールドと共有されます。
この属性のデフォルト値はnonsharedです。この場合、トランスレータが最後の非オプション・フィールドまたは後続オプション・フィールドの処理中に配列の終端文字を検出すると、トランスレータは現在のフィールドが終了し、配列に後続オプション・フィールドが含まれないとみなします。

配列が終了し、後続オプション・フィールドがない場合、トランスレータは現在のフィールド、現在のセルおよび配列を閉じます。

6.5.5.1.4 動作

共有デリミタの動作もセルの性質に依存します。その他のタイプに加えて、次の3つの主要な動作タイプがあります。

- 終了

- 固定長

- 囲み

終了動作は、後続オプションの子にデリミタがあるかどうか、親デリミタの1つが検出されるかどうかに依存します。

- 後続オプションの子が終了している場合、トランスレータはネイティブ・データから読み取り、子の終端文字と保留中のデリミタの両方を検索します。

- 後続オプションの子の終端文字が検出された場合、オプションの子を生成します。

- ただし、親デリミタの1つが検出された場合、読み取ったデータを現在のオプションの子にマップし、それをXMLで生成し、すべての後続オプションを無視し、親デリミタが検出されたレベルまで親構造を閉じます。

固定長動作は、固定長である後続オプションの子、または保留中のデリミタが存在するかどうかに関連します。

- 後続オプションの子が固定長の場合、子を処理する前に保留中のデリミタを検索します。

- 親デリミタの1つが検出された場合、後続オプションを無視して、親デリミタ構造まで構造を閉じます。

- 保留中のデリミタが存在しない場合、トランスレータはこのオプション・ノードに対応する固定長の文字数を読み取り、固定長の一部となる場合は保留中のデリミタをバイパスし、XMLでオプション・ノードを生成します。

注意:

NXSDトランスレータは、固定長データの最初に共有デリミタが実際に存在するシナリオに対応していません(固定長データを引用としてエスケープできません)。

囲み動作は、子が囲まれているかどうか、surroundedByデリミタの動作および親デリミタの存在に依存します。

- 後続オプションの子が囲まれている場合、子を処理する前に保留中のデリミタを検索します。

- 保留中のデリミタが存在しない場合、このオプション・ノードに対応する囲まれているネイティブ・データを読み取り、surroundedByの前にある場合は保留中のデリミタをバイパスし、XMLでオプション・ノードを生成します。次の後続オプション・ノードに対してこのロジックを繰り返します。

- 親デリミタの1つが検出された場合、後続オプションを無視して、親デリミタ構造が特定されるまで構造を閉じます。
カンマは、NXSDスキーマで共有のセル・セパレータと配列セパレータの両方として使用される場合、出力内の最初で唯一の要素になります。

たとえば、入力ネイティブ・データがField1、Field2、Field3、Field4、Field5で、

cellSeparatedBy=','とarrayTerminatedBy=','、およびその両方を共有すると、結果は最初のフィールドのみになります。例:

<sharedDelim xmlns="http://xmlns.mydomain.com/pcbpel/nxsd/test">
<Group1>
<Group2>
<Field1>Field1</Field1>
</Group2>
</Group1>
</sharedDelim>

6.5.5.2 終了の使用例

この項の使用例は、後続オプションの子が終了しているかどうか、後続オプションの子の終端文字が検出されるかどうか、親デリミタの1つが検出されるかどうかといった、終了動作に関連しています。

使用例のスキーマの図は図6-79 、使用例の説明は表6-11 を参照してください。説明にはフィールドのリストが含まれています。

図6-79 終了の使用例のスキーマ

表6-11 終了の使用例

番号

名前

使用例の説明

出力

1

Terminated_example_1.xsd

Field1#Field2$@Field11#Field22$^Field3%!

---

後ろにfield3が続くgroup2の2つのセルは、group1のセル1つのみで構成されます。

<sharedDelim>
<Group1>
<Group2>
<Field1>Field1</Field1>
<Field2>Field2</Field2>
</Group2>
<Group2>
<Field1>Field11</Field1>
<Field2>Field22</Field2>
</Group2>
<Field3>Field3</Field3>
</Group1>
</sharedDelim>

2

Terminated_example_2.xsd

Field1@Field11#Field22$^Field3%!

---

group2の2つのセル。1つ目にはオプションのField2がなく、2つ目にはオプションのField2があります。Field3とともに、配列Group1の1つのセルで構成されます。

<sharedDelim>
<Group1>
<Group2>
<Field1>Field1</Field1>
</Group2>
<Group2>
<Field1>Field11</Field1>
<Field2>Field22</Field2>
</Group2>

3

Terminated_example_3.xsd

Field1@Field11#Field22!

---

group2の2つのセル。1つ目にはオプションのField2がなく、2つ目にはオプションのField2があります。オプションのField3がなく、これはGroup1の1つのセルで構成されます。

<sharedDelim>
<Group1>
<Group2>
<Field1>Field1</Field1>
</Group2>
<Group2>
<Field1>Field11</Field1>
<Field2>Field22</Field2>
</Group2>
</Group1>
</sharedDelim>

4

Terminated_example_4.xsd

Field1!

---

オプションのField2がないGroup2の1つのセルは、Group1の1つのセルで構成され、オプションのField3はありません。

<sharedDelim>     <Group1>         <Group2>             <Field1>Field1</Field1>         </Group2>     </Group1> </sharedDelim>

5

Terminated_example_5.xsd

Field0!Field1#Field2$@Field11#Field22$^Field3%!Field111!

---

Group1の3つのセル。1つ目のセルには、オプションのField2とオプションのField3がないGroup2のセルが1つあります。2つ目のセルには両方のフィールドがあるGroup2のセルが2つあり、オプションのField3が含まれています。

3つ目のセルは、1つ目のセルと同じです。

<sharedDelim>
<Group1>
<Group2>
<Field1>Field0</Field1>
</Group2>
</Group1>
<Group1>
<Group2>
<Field1>Field1</Field1>
<Field2>Field2</Field2>
</Group2>
<Group2>
<Field1>Field11</Field1>
<Field2>Field22</Field2>
</Group2>
<Field3>Field3</Field3>
</Group1>
<Group1>
<Group2>
<Field1>Field111</Field1>
</Group2>
</Group1>
</sharedDelim>

6.5.5.3 固定長の使用例

この項の使用例は、すべて固定長の使用例です。

使用例のスキーマの図は図6-80 、使用例の説明は表6-12 を参照してください。説明にはフィールドのリストが含まれています。

図6-80 固定長の使用例のスキーマ

表6-12 に、固定長の使用例の名前、使用例の説明および結果の出力を示します。

表6-12 固定長の使用例

番号

名前

使用例の説明

出力

1

Fixed_length_example1.xsd

Field01#Field02@Field11#Field12^! --- Group1のセル1つにGroup2のセルが2つあります。Group2の各セルには、必須で終了のField1要素とオプションで固定長のField2の両方があります。Group1グループに、オプションで固定長のField3はありません。

<fo_1>
<Group1>
<Group2>
<Field1>Field01</Field1>
<Field2>Field02</Field2>
</Group2>
<Group2>
<Field1>Field11</Field1>
<Field2>Field12</Field2>
</Group2>
</Group1>
</fo_1>

2

Fixed_length_example2.xsd

Field01! --- Group2の1つ目のセルには必須で固定長のField01があり、オプションで固定長のField2はありません。Group1には、オプションで固定長のField3はありません。

<fo_1>    <Group1>    <Group2>             <Field1>Field01</Field1>      </Group2>     </Group1> </fo_1>

3

Fixed_length_example3.xsd

Field01!Field11Field02@Field21Field12^Field03!Field31! --- Group1には3つのセルがあります。1つ目のセルには必須で固定長のField1のみが含まれます。2つ目のセルには、Group2のセルが2つ含まれます。2つのセルのそれぞれには、固定長フィールドのField1とField2の両方が含まれます。Group1の2つ目のセルには、固定長でオプションのField3も含まれます。Group1の3番目のセルは1つ目のセルと同じです。

<fo_1>
<Group1>
<Group2>
<Field1>Field01</Field1>
</Group2>
</Group1>
<Group1>
<Group2>
<Field1>Field11</Field1>
<Field2>Field02</Field2>
</Group2>
<Group2>
<Field1>Field21</Field1>
<Field2>Field12</Field2>
</Group2>
<Field3>Field03</Field3>
</Group1>
<Group1>
<Group2>
<Field1>Field31</Field1>
</Group2>
</Group1>
</fo_1>

6.5.5.4 囲みの使用例

囲みの使用例には、トランスレータが検索する場所が含まれています。

後続オプションの子が囲まれている場合は保留中のデリミタを検索し、保留中のデリミタが存在しない場合は、このオプション・ノードに対応する囲まれたデータを読み取り、保留中のデリミタがsurroundedByデリミタより前にある場合は保留中のデリミタをバイパスし、最終的にXMLでオプション・ノードを生成します。

使用例のスキーマの図を示す図6-81 、および表6-13 を参照してください。

図6-81 共有デリミタの囲みスキーマ

表6-13 囲みの使用例

番号

名前

使用例の説明

出力

1

Surrounded_example_1.xsd

Field01#Field02@Field11#Field12^[Field03]! --- Group1には、繰返し構造のGroup2とオプションで囲みのField3で構成されるセルが1つあります。Group2には、必須で終了のField1とオプションで囲みのField2の両方があるセルが2つあります。

<sharedDelim>
<Group1>
<Group2>
<Field1>Field1</Field1>
<Field2>Field2</Field2>
</Group2>
<Group2>
<Field1>Field11</Field1>
<Field2>Field22</Field2>
</Group2>
<Field3>Field3</Field3>
</Group1>
</sharedDelim>

2

Surrounded_example_2.xsd

Field01#@Field11#Field12^! |--- Group1は繰返し構造のGroup2で構成された1つのセルで、オプションで囲みのField3はありません。Group2にはセルが2つあります。1つ目のセルには必須で終了のField1がありますが、オプションで囲みのField2はありません。2つ目のセルには両方のフィールドが含まれます。

<fo_1>     <Group1>         <Group2>             <Field1>Field01</Field1>         </Group2>         <Group2>             <Field1>Field11</Field1>             <Field2>Field12</Field2>         </Group2>     </Group1> </fo_1>

3

Surrounded_example_3.xsd

Field01! --- Group1には1つのセルがあり、必須で固定長のField1があり、オプションで囲みのField2はないGroup2のセル1つで構成されています。Group1には、オプションで囲みのField2もありません。

<fo_1> <Group1> <Group2> <Field1>Field01</Field1> </Group2> </Group1> </fo_1>

4

Surrounded_example_4.xsd

Field01!Field11-Field02-@Field21-Field12-^[Field03]!Field31!

---

Group1にはセルが3つあります。1つ目のセルには必須で固定長のField1のみを含むGroup2のセルが1つあり、オプションで囲みのField2はありません。Group1の2つ目のセルには、Group2 (両方のフィールドを含む)のセルが2つとField3が含まれています。Group1の3番目のセルは1つ目と同じです。

<fo_1>
<Group1>
<Group2>
<Field1>Field01</Field1>
</Group2>
</Group1>
<Group1>
<Group2>
<Field1>Field11</Field1>
<Field2>Field02</Field2>
</Group2>
<Group2>
<Field1>Field21</Field1>
<Field2>Field12</Field2>
</Group2>
<Field3>Field03</Field3>
</Group1>
<Group1>
<Group2>
<Field1>Field31</Field1>
</Group2>
</Group1>
</fo_1>

6.5.5.5 その他の使用例

次の使用例は、共有デリミタの様々なタイプの使用方法を集めたものです。

6.5.5.5.1 Shared_array_Terminator.xsd

この共有配列の終端文字の使用例のサンプル・データは、次のとおりです。

"Smith, John","0161-499-1717"
Fred,"0161-499-1718"#^"Smith, John","0161-499-1717"
#*

次に、この使用例のXSDを示します。

例 - 共有配列の終端文字のサンプルXSD

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="arrayTerminator">
<complexType>
<sequence>
<element name="arrayOfMembers" maxOccurs="unbounded"
nxsd:style="array" nxsd:cellSeparator="nonshared" nxsd:cellSeparatedBy="^"  nxsd:arrayTerminatedBy="*">
<complexType>
<sequence>
<element name="Member" maxOccurs="unbounded"
nxsd:style="array" nxsd:arrayTerminatedBy="#" nxsd:arrayTerminator="shared">
<complexType>
<sequence>
<element name="Name" type="string" nxsd:style="terminated"          nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated" nxsd:terminatedBy="${eol}" nxsd:quotedBy='"'/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>

</schema>

生成されるXMLは次のとおりです。

例 - 共有配列の終端文字に対して生成されるXMLのサンプル

<arrayTerminator xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<arrayOfMembers>
<Member>
<Name>Smith, John</Name>
<Telephone>0161-499-1717</Telephone>
</Member>
<Member>
<Name>Fred</Name>
<Telephone>0161-499-1718</Telephone>
</Member>
</arrayOfMembers>
<arrayOfMembers>
<Member>
<Name>Smith, John</Name>
<Telephone>0161-499-1717</Telephone>
</Member>
</arrayOfMembers>
</arrayTerminator>

6.5.5.5.2 Shared_trailing_array.xsd

shared.trailingArray.xsdのサンプル・データは次のとおりです。

"Smith, John","0161-499-1717"
Fred,"0161-499-1718"^"Smith, John","0161-499-1717"
#*

この使用例のサンプルNXSDスキーマを次に示します。

例 - 共有の後続配列のサンプルNXSDスキーマ

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="trailingArray">
<complexType>
<sequence>
<element name="arrayOfMembers" maxOccurs="unbounded"
nxsd:style="array" nxsd:cellSeparator="shared" nxsd:cellSeparatedBy="^"  nxsd:arrayTerminatedBy="*">
<complexType>
<sequence>
<element name="Member" maxOccurs="unbounded"
nxsd:style="array" nxsd:arrayTerminatedBy="#"                       nxsd:arrayTerminator="shared">
<complexType>
<sequence>
<element name="Name type="string" nxsd:style="terminated"               nxsd:terminatedBy="," nxsd:quotedBy='"'/>
<element name="Telephone" type="string" nxsd:style="terminated"               nxsd:terminatedBy="${eol}" nxsd:quotedBy='"' minOccurs="0"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
</schema>

次の例に、この使用例の生成されたXMLを示します。

例 - 共有の後続配列の使用例に対して生成されるXML

<trailingArray xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<arrayOfMembers>
<Member>
<Name>Smith, John</Name>
<Telephone>0161-499-1717</Telephone>
</Member>
<Member>
<Name>Fred</Name>
<Telephone>0161-499-1718</Telephone>
</Member>
</arrayOfMembers>
<arrayOfMembers>
<Member>
<Name>Smith, John</Name>
<Telephone>0161-499-1717</Telephone>
</Member>
</arrayOfMembers>
</trailingArray>
</element>

6.5.5.5.3 Shared_trailing_OptionalArray.xsdの使用例

この共有のtrailingOptionalArrayの使用例のサンプル・データを次の例に示します。

例 - 共有の後続オプション配列の使用例のサンプル・データ

"Smith, John","0161-499-1717"
Fred^"Smith, John","0161-499-1717"#*

例 - 共有の後続オプション配列の使用例のNXSD

<?xml version="1.0" encoding="US-ASCII"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace=
"http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD">

<element name="trailingOptionalArray">
<complexType>
<sequence>
<element name="arrayOfMembers"
maxOccurs="unbounded"
nxsd:style="array" nxsd:cellSeparator=
"shared" nxsd:cellSeparatedBy="^"              nxsd:arrayTerminatedBy="*">
<complexType>
<sequence>
<element name="Member"
maxOccurs="unbounded"
nxsd:style="array"
nxsd:arrayTerminatedBy="#"
nxsd:arrayTerminator="shared">
<complexType>
<sequence>
<element name=
"Name" type="string"
nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy='"'/>
<element name="Telephone"
type="string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}"                       nxsd:quotedBy='"' minOccurs="0"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
</schema>

例 - 共有の後続オプション配列の使用例に対して生成されるXML

<trailingOptionalArray xmlns="http://xmlns.oracle.com/pcbpel/nxsd/smoketest">
<arrayOfMembers>
<Member>
<Name>Smith, John</Name>
<Telephone>0161-499-1717</Telephone>
</Member>
<Member>
<Name>Fred</Name>
</Member>
</arrayOfMembers>
<arrayOfMembers>
<Member>
<Name>Smith, John</Name>
<Telephone>0161-499-1717</Telephone>
</Member>
</arrayOfMembers>
</trailingOptionalArray>

第II部 メッセージ・アダプタ

第II部は、次の章で構成されます。

- Oracle JCA Adapter for AQ

- Oracle JCA Adapter for JMS

- Oracle JCA Adapter for Database

- Oracle JCA Adapter for MQ Series

- Oracle JCA Adapter for UMS

- Oracle JCA Adapter for LDAP

- Oracle JCA Adapter for Microsoft Message Queueing

- Oracle JCA Adapter for Coherence

- Oracle JCAアダプタのプロパティ

- Oracle JCAアダプタ・バルブ

- Oracle MQ Seriesアダプタでサポートされるエンコーディング

7 Oracle JCA Adapter for AQ

この章では、Oracle BPEL Process Manager (Oracle BPEL PM)またはOracle Mediatorによるシングル・コンシューマまたはマルチ・コンシューマ・キューの操作を可能にする、Oracle JCA Adapter for AQ (Oracle AQアダプタ)の使用方法について説明します。

この章の内容は次のとおりです。

- Oracle AQアダプタの概要

- Oracle AQアダプタの機能

- Oracle JCA Adapter for AQのデプロイメント

- 使用例

7.1 Oracle AQアダプタの概要

Oracle Streams Advanced Queuing (AQ)では、関連するアプリケーション間の双方向の非同期通信用に柔軟なメカニズムが提供されています。アドバンスト・キューはOracleデータベースの機能であるため、高いスケーラビリティと信頼性を備えています。バックアップとリカバリ(Point-in-Timeリカバリも含む)、ロギング、トランザクション・サービスおよびシステム管理など、Oracleデータベースの他の機能もアドバンスト・キューによって継承されます。また、単一のアプリケーションを複数のキューで処理できるため、メッセージを様々な方法で分割したり、ロード・バランシングを介して別のレベルのスケーラビリティを提供したりできます。

この節の内容は以下のとおりです。

- Oracle AQアダプタとOracle BPEL Process ManagerおよびOracle Mediatorの統合

- Oracle Mediatorとの統合

Oracle AQの詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』のOracle Streams AQの概要に関する項を参照してください。

7.1.1 Oracle AQアダプタの次のコンポーネントとの統合

JCA 1.5リソース・アダプタを双方向に統合するのに使用されます。規格に準拠しており、基盤となるJCA相互作用をWebサービスとして公開するためのWeb Service Invocation Framework (WSIF)テクノロジが使用されています。

アーキテクチャ、アダプタとの統合およびアダプタのデプロイの詳細は、「アダプタとOracle Application Serverコンポーネントの統合」を参照してください。

7.1.2 Oracle Mediatorとの統合

メディエータ・サーバーはサポートしており、それぞれのインバウンドおよびアウトバウンドのアダプタ・サービスを定義できます。インバウンド・アダプタ・サービスでは、データが受信されてXMLメッセージに変換されます。アウトバウンド・アダプタ・サービスでは、XMLメッセージが特定のアダプタのネイティブ・フォーマットに変換され、データがターゲット・アプリケーションに送信されます。

サーバーを使用すると、Oracle Advanced Queuingのシングル・コンシューマ・キューまたはマルチ・コンシューマ・キューとの間でメッセージを送受信できます。

注意:

Oracle BPEL PMの後継であり、このガイドのほとんどの部分およびサンプルはOracle BPEL PMを使用することを想定しています。ただし、動作はOracle BPEL PMでも同じです。ここでOracle BPEL PMに言及している箇所は、置き換えてかまいません。

7.2 Oracle AQアダプタの機能

Oracle AQアダプタは、AQメッセージのプロデューサでもありコンシューマでもあります。エンキュー操作は、JCAアウトバウンド相互作用として公開されています。デキュー操作は、JCAインバウンド相互作用として公開されています。

Oracle AQアダプタでは、ペイロードとしてADT (Oracleオブジェクト・タイプ)、XMLTypeおよびRAWキューをサポートしています。また、1つのADTメンバー列からのペイロードの抽出もサポートしています。

Oracle AQアダプタでは、エンキューおよびデキュー操作用として正規化されたプロパティがサポートされています。

Oracle AQアダプタでサポートされているプロパティの詳細は、「Oracle AQアダプタのプロパティ」を参照してください。

Oracle AQアダプタのサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

この項には次のトピックが含まれます:

- エンキュー固有の機能(メッセージ生成)

- デキューおよびエンキューの機能

- 同期リクエスト/レスポンス

- 同期デキュー

- サポートされているADTペイロード・タイプ

- ネイティブ・フォーマット・ビルダー・ウィザード

- 正規化されたメッセージのサポート

- DOM2準拠

- メッセージ・サイズ対応

- 複数の受信者スレッド

- DequeueTimeoutプロパティ

- デキュー・タイムアウトおよび複数のインバウンド・ポーリング・スレッドの制御

- ストリーム・ペイロードのサポート

- インバウンドの再試行

- エラー処理のサポート

- パフォーマンス・チューニング

7.2.1 エンキュー固有の機能(メッセージ生成)

Oracle Streams AQの次の機能をサポートしています。

- 相関識別子
アダプタ構成ウィザードでは、特定メッセージの取得に使用するエンキュー操作の定義時に相関識別子を指定できます。

- マルチ・コンシューマ・キュー
Oracle Streams AQでは、複数のコンシューマで1つのメッセージの処理と消費を実行できます。この機能を使用するには、マルチ・コンシューマ・キューを作成し、そのキューにメッセージをエンキューする必要があります。この構成では、デフォルトのサブスクリプション・リストまたはオーバーライド受信者リストのいずれかを使用して、単一のメッセージが複数のAQコンシューマによって消費(デキュー操作)されます。このシナリオでは、指定したすべてのコンシューマ・エージェントによって消費されるまで、メッセージはキューに残ります。Oracle AQアダプタのエンキュー・ヘッダー・プロパティ(jca.aq.RecipientList)を使用すると、キューからのメッセージ取得が可能なオーバーライド受信者リスト(カンマ区切りの文字列値)を指定できます。サブスクライバとしてマルチ・コンシューマ・キューに追加されたすべてのコンシューマでは、Recipientパラメータに一意の値が必要です。2つのサブスクライバでNAME、ADDRESSおよびPROTOCOL属性に同じ値を使用することはできません。

- メッセージの優先度
エンキュー済のメッセージに優先度を指定すると、メッセージは優先度に従ってデキューされます。2つのメッセージの優先度が同じ場合、デキューの順番はエンキュー時間で決定されます。また、メッセージのソート順としてエンキュー時間の優先度を指定することで、優先度が格納順の取出し(FIFO)のキューを作成することもできます。この優先度は、エンキュー・ヘッダーのプロパティです。エンキュー時間は、基礎となるAQアプリケーションによって自動的に設定されます。

次に、FIFOキューの作成方法の例を示します。

EXECUTE DBMS_AQADM.CREATE_QUEUE_TABLE( \
queue_table => 'OE_orders_pr_mqtab', \
sort_list =>'priority,enq_time', \
comment => 'Order Entry Priority \
MultiConsumer Orders queue table',\
multiple_consumers => TRUE, \
queue_payload_type => 'BOLADM.order_typ', \
compatible => '8.1', \
primary_instance => 2, \
secondary_instance => 1);
EXECUTE DBMS_AQADM.CREATE_QUEUE ( \
queue_name => 'OE_bookedorders_que', \
queue_table => 'OE_orders_pr_mqtab');

- 時間の指定とスケジュール
Oracle Streams AQでは、遅延間隔と有効期限の間隔を指定できます。遅延間隔は、メッセージのエンキュー後に、エンキュー済のメッセージがデキュー元で使用可能とマークされる時期を決定します。遅延時間の設定されたメッセージがエンキューされると、メッセージはWAIT状態とマークされます。WAIT状態のメッセージは、デフォルトのデキュー・コールからマスクされます。有効期限のプロパティは有効期限の指定に使用され、メッセージが有効期限の前に消費されない場合、メッセージは自動的に例外キューに移動されます。

7.2.2 デキューおよびエンキューの機能

Oracle Streams AQには、次のデキュー・オプションがあります。

- ポーリング・オプション

- 通知オプション

ポーリング・オプションは、着信の都度のメッセージの処理や、メッセージの継続的なポーリングに関連します。Oracle AQアダプタでは、AQメッセージ消費のポーリング・メカニズムをサポートしています。

Oracle AQアダプタでは、Oracle Streams AQの次の機能をサポートしています。

- マルチ・コンシューマ・キュー
Oracle AQアダプタは、マルチ・コンシューマ・キューからメッセージを取得できます。

- デキュー処理用のメッセージの移動
メッセージをエンキューと同じ順序でデキューする必要はありません。相関識別子を使用してデキューの順序を指定できます。アダプタ構成ウィザードで、デキュー操作の相関IDを定義できます。

- 遅延を伴う再試行
再試行回数は、Oracle AQアダプタのデキュー・ヘッダーのプロパティです。再試行回数が制限を超えると、メッセージは指定の例外キューに移動されます。この例外キューは、Oracle AQアダプタのエンキュー・ヘッダーのプロパティです。

- ルールベースのサブスクリプション
Oracle Streams AQでは、コンテンツベースおよびサブジェクトベースのメッセージのフィルタ処理が可能です。ルールには、そのルールに一致するメッセージのサブスクライブを目的とした1つ以上のコンシューマが定義されます。サブジェクトベースのルールの場合、SQL問合せのWHERE句に似た構文を使用してブール式を指定します。このブール式には、メッセージ・プロパティの条件(現状では優先度と相関ID)、ユーザー・データ・プロパティ(オブジェクト・ペイロードのみ)および関数(SQL問合せのWHERE句の指定と同様)を含めることができます。

- Oracle AQアダプタのヘッダー・プロパティ
Oracle AQアダプタのヘッダー・プロパティの詳細は、「Oracle AQアダプタのプロパティ」を参照してください。

- デキュー条件
デキュー条件は、Oracle AQアダプタで使用されるアドバンスト・キューイング製品の機能です。デキュー条件が指定され、指定された条件を満たすメッセージがない場合は、デキューが実行されません。

デキュー条件要素は、SQL問合せのWHERE句に似た構文を使用するブール式です。このブール式には、メッセージ・プロパティ、ユーザー・オブジェクトのペイロード・データ・プロパティおよびPL/SQLまたはSQL関数に関する条件を含めることができます。メッセージ・プロパティには、priority、corridおよびキュー表の他の列などがあります。

マルチ・サブスクライバ・キューでデキューが実行される際には、メッセージを選別して特定の条件を満たすもののみを着信することが必要な場合があります。これらの条件は、優先度1のメッセージのみを選択する場合などはヘッダー情報に、$100,000を超えるローン・アプリケーションのみを選択する場合などはメッセージ・ペイロードの一部に関係します。

マルチ・サブスクライバ・キューを選択した場合は、ステップ15で「メッセージ・セレクタ・ルール」フィールドが表示されます。priority = 1またはTAB.USER_DATA.amount > 1000など、SQLのWHERE句に似た構文を使用したブール式でサブスクリプション・ルールを入力します。アダプタにより、このブール式がtrueのメッセージのみがデキューされます。

ヘッダー情報にアクセスするには、「ペイロード以外のフィールドへのアクセスも必要」チェック・ボックスを選択する必要があります。

このチェック・ボックスを選択すると、生成されるWSDLファイルのtypeセクションにコードが追加されます。

<?xml version = '1.0' encoding = 'UTF-8'?>
<?binding.jca Inbound_aq.jca?>
<definitions name="Inbound"   targetNamespace="http://xmlns.oracle.
com/pcbpel/adapter/aq/Inbound/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:obj1="http://xmlns.oracle.com/xdb/SCOTT" xmlns:imp1="http://www.oracle.com/ipdemo">
<types>
<schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns:hdr="http://xmlns.oracle.com/pcbpel/adapter/aq/inbound/" xmlns:obj1="http://xmlns.oracle.com/xdb/SCOTT">
<import namespace="http://xmlns.oracle.com/xdb/SCOTT" schemaLocation="xsd/SCOTT_MAGAZINE_TYPE.xsd"/>
<import namespace="http://xmlns.oracle.com/pcbpel/adapter/aq/inbound/" schemaLocation="xsd/aqAdapterInboundHeader.xsd"/>
<complexType name="HeaderCType">
<sequence>
<element name="QueueHeader"
type="hdr:HeaderType"/>
<element name="PayloadHeader"
type="obj1:MAGAZINE_TYPE"/>
</sequence>
</complexType>
<element name="Header" type="tns:HeaderCType"/>
</schema>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.oracle.com/ipdemo" schemaLocation="xsd/simpleMagazine.xsd"/>
</schema>
</types>
<message name="simpleMagazine_msg">
<part name="simpleMagazine"
element="imp1:simpleMagazine"/>
</message>
<message name="Header_msg">
<part name="Header" element="tns:Header"/>
</message>
<portType name="Dequeue_ptt">
<operation name="Dequeue">
<input message="tns:simpleMagazine_msg"/>
</operation>
</portType>
<plt:partnerLinkType name="Dequeue_plt">
<plt:role name="Dequeue_role">
<plt:portType name="tns:Dequeue_ptt"/>
</plt:role>
</plt:partnerLinkType>
</definitions>

PayloadHeaderは、キューのADT全体のタイプであることに注意してください。ペイロードには選択したペイロード・フィールドのみが含まれます。「ペイロード以外のフィールドへのアクセスも必要」を選択した場合、PayloadHeader(. jca.aq.HeaderDocument)にはADT全体が含まれます(ヘッダーにも存在しアダプタでは無視されるペイロード・フィールドも含まれます)。

Oracle AQアダプタのアーキテクチャ、アダプタとOracle BPEL Process ManagerおよびOracle Mediatorの統合およびアダプタのデプロイの詳細は、「Oracle JCAアダプタの概要」を参照してください。

7.2.3 同期リクエスト/レスポンス

AQアダプタ構成ウィザードを使用すると、Oracle AQアダプタを同期リクエスト/レスポンス相互作用パターンに使用できるプロセスをモデル化できます。

このシナリオでは、Oracle AQアダプタはリクエスト・キューにリクエストを送信し、リプライ・キューからのレスポンスを待ってから実行を継続します。内部では、Oracle AQアダプタにより新規の相互作用パターンAQRequestReplyInteractionSpecが使用されます。この相互作用の仕様では、リクエストとリプライの宛先名を構成できます。

バリエーションにより、リプライ・キューの一部として一時的な宛先を使用できます。その後、アダプタはAQReplyToヘッダーをリプライの宛先に設定します。

7.2.3.1 AQ同期リクエスト/レスポンス相互作用パターンの構成ウィザード・フロー

次の手順に従って、AQアダプタ構成ウィザードを使用して、同期リクエスト/レスポンス用にAQアダプタを構成します。

1. AQアダプタ構成ウィザードを開き、各初期手順に進みます。AQアダプタの「操作」ページで、「エンキュー/デキュー」を選択します。ページの「操作名」セクションは有効です。

「同期」を選択し、指定された操作名Enqueue_Dequeueを使用するか、独自の名前に変更します。

図7-1 「エンキュー/デキュー」と「同期」操作が選択されたAQアダプタ構成ウィザードの「操作」画面

2. 「キュー名」画面で、「アウトバウンド・キュー情報」および「インバウンド・キュー情報」を指定します。データベース・スキーマを参照して適切な「キュー名」を選択するか、デフォルト・スキーマを使用して、選択したデフォルト・スキーマで使用可能なリストから「キュー名」を選択します。

図7-2 AQアダプタ構成ウィザードの「キュー名」画面

3. 「キュー・パラメータ」画面が表示されます。次の情報を指定してから、「次へ」を選択します。次の点に注意してください

- 「コンシューマ」フィールドで、マルチ・コンシューマ・キューのコンシューマ名を指定します。

- 「メッセージ・セレクタ・ルール」フィールドで、メッセージ・セレクタ・ルールを指定します。メッセージ・セレクタ・ルールの使用方法の詳細は、「デキューおよびエンキューの機能」を参照してください。

- 「デキュー条件」で、メッセージに関する条件を指定します。デキュー条件の使用方法の詳細は、「デキューおよびエンキューの機能」を参照してください。

図7-3 AQアダプタ構成ウィザードの「キュー・パラメータ」ページ

4. AQアダプタ構成ウィザードの「オブジェクト・ペイロード」画面が表示されます。この画面では、インバウンド・キューとアウトバウンド・キューの両方のオブジェクト・ペイロードに関する情報を入力できます。

図7-4 AQアダプタ構成ウィザードの「オブジェクト・ペイロード」画面

- 上部のテキストは、構造化されたオブジェクト・ペイロードを指定します。残りのテキストは、ペイロードに関する追加情報を提供します。「ビジネス・ペイロード」の場合は、オブジェクト全体または「オブジェクト内のフィールド」です。

- 「オブジェクト内のフィールド」を選択した場合は、「ペイロード・フィールド・オプション」セクションが有効になります。ここで、直接入力するか、「参照」を選択して、フィールド名を入力します。
「参照」を選択した場合は、「ペイロード・フィールドの選択」ブラウザが開きます。ビジネス・ペイロードが含まれるフィールド(1つまたは複数)を選択し、「OK」をクリックして、「オブジェクト・ペイロード」画面でフィールド名を移入します。

「ペイロードの検証」を選択して、デキュー操作のペイロードを検証することもできます。このオプションが選択されている場合は、他の処理を行う前に、結果のXMLペイロードがスキーマに対して検証されます。失敗した場合、メッセージは拒否されます。

図7-5 AQアダプタ構成ウィザードの「ペイロード・フィールドの選択」ブラウザ

スキーマがこれらのフィールドに生成されるようにする必要もある場合は、「ペイロード以外のフィールドへのアクセスが必要」チェック・ボックスを選択します。ADTオブジェクト属性がヘッダー・プロパティとして使用できるようにする場合は、このチェック・ボックスを選択します。たとえば、ペイロードがJPGイメージであるとします。ペイロード以外のフィールドで人物の名前を指定することが必要な場合があります。これにより、追加のヘッダー・スキーマ・ファイル(object_name.xsd、object_nameはキューで使用する構造化されたペイロード・オブジェクト)が生成されます。xsd名には、スキーマによって接頭辞が追加で付けられ、スキーマscottに接続すると、その名前はSCOTT_object_name.xsdになります。「オブジェクト」ページでADTフィールドを選択した場合、またはADT全体のペイロードが選択されている場合、スキーマを指定するための「メッセージ」ページが表示されます。構造化されたオブジェクト内のADTフィールドを指定した場合、アウトバウンドADTフィールド名はインバウンドADTフィールド名と同じである必要があります。

- AQアダプタ構成ウィザードの「オブジェクト・ペイロード」画面の残り半分でのアウトバウンド・キューの場合と同じ方法で情報を入力します。

- 「Next」をクリックします。

5. AQアダプタ構成ウィザードの「メッセージ」画面が表示されます。

- この画面で、指定した両方のキューのフィールドに含まれるメッセージを定義するように求められます。このアダプタおよび他のアダプタの他のメッセージ画面と同様、メッセージが不透明であるかどうか、ネイティブ・フォーマット変換が必要であるかどうかを示したり、スキーマおよびURLとスキーマ要素を提供してスキーマを指定することができます。

- 「次へ」をクリックして、同期リクエスト/レスポンス相互作用パターンでのAQアダプタの構成を完了します。

図7-6 AQアダプタ構成ウィザードの「メッセージ」画面

7.2.3.1.1 同期リクエスト/リプライ相互作用パターンを使用したAQアダプタの編集

SOAコンポジット・エディタを使用し、AQアダプタ・ウィザードを編集モードで起動して、前に構成したAQアダプタを選択することもできます。ただし、この方法を使用した場合、すでに定義している操作タイプは変更できませんが、選択したキューとキュー・パラメータの変更や、ペイロード・スキーマの変更は可能です。

7.2.4 同期デキュー

AQの「操作タイプ」ページで「同期デキュー」操作タイプを選択して、AQアダプタのアウトバウンド同期デキューを構成できます。

7.2.4.1 AQ同期デキューの構成ウィザード・フロー

次の手順に従って、AQアダプタ構成ウィザードを使用して、同期デキュー用にAQを構成します。

1. 操作タイプとして「同期デキュー」を選択します。同期デキューに付けられる操作名はデフォルトでSync_Dequeueに設定されます。ただし、必要な場合はこの名前を上書きできます。

図7-7 「同期デキュー」操作が選択され、「操作名」が「Sync_Dequeue Shown」のAQアダプタ構成ウィザードの「操作」画面

2. 「次」を選択します。AQアダプタ構成ウィザードの「キュー名」画面が表示されます。この画面で、このサービスに使用されるデータベース・スキーマとインバウンドおよびアウトバウンド・キューを指定できます。「次へ」をクリックします。

図7-8 「データベース・スキーマ」がデフォルト設定され、「キュー名」が選択されたAQアダプタ構成ウィザードの「キュー名」画面

3. 「キュー・パラメータ」画面では、デキュー操作(「コンシューマ」、「メッセージ・セレクタ・ルール」および「デキュー条件」)を指定し、「次へ」をクリックします。(マルチ・コンシューマ・キューを選択した場合にのみ、4つのフィールドを示すこの画面が表示されることに注意してください。)シングル・コンシューマ・キューのみを選択した場合は、2つのフィールド(「相関ID」と「デキュー条件」)のみが含まれた画面が表示されます。その場合、構成ウィザードに「コンシューマ」と「メッセージ・セレクタ・ルール」は表示されません。

- コンシューマ: マルチ・コンシューマ・キューのコンシューマ名を指定します。

- 相関ID: 1文字から30文字までの長さでオプションの相関IDを入力します。

- メッセージ・セレクタ・ルール: メッセージ・セレクタ・ルールを指定します。メッセージ・セレクタ・ルールの使用方法の詳細は、「デキューおよびエンキューの機能」を参照してください。

- デキュー条件: 「操作」ページでデキューを選択した場合にのみ表示され、メッセージに関する条件を指定できます。デキュー条件の使用方法の詳細は、「デキューおよびエンキューの機能」を参照してください。

図7-9 AQアダプタ構成ウィザードの「キュー・パラメータ」画面

7.2.4.2 同期リクエスト/リプライのJCAファイル

次の項では、同期リクエスト/リプライと同期デキューの両方のファイル・アーティファクトを指定します。次の例では、同期リクエスト/リプライ・シナリオのjcaファイルを示します。

<adapter-config name="AQService" adapter="AQ" wsdlLocation="../WSDLs/AQRequestReply.wsdl" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/AQ/slc01gid" UIConnectionName="slc01gid"/>
<endpoint-interaction portType="Enqueue_Dequeue_ptt" operation="Enqueue_Dequeue" UITransmissionPrimitive="Request-response">
<interaction-spec className="oracle.tip.adapter.aq.v2.jca.AQRequestReplyInteractionSpec">
<property name="EnqueueQueue" value="EDN_OAOO_QUEUE"/>
<property name="RecipientList" value="recp1"/>
<property name="DequueQueue" value="EDN_EVENT_QUEUE"/>
<property name="ObjectFieldName" value="PAYLOAD"/>
<property name="Consumer" value="cons1"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

7.2.4.3 同期デキューのJCAファイル

次の例では、同期デキュー・シナリオのjcaファイルを示します。

<adapter-config name="AQSyncDequeue" adapter="AQ" wsdlLocation="../WSDLs/AQSyncDequeue.wsdl" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/AQ/slc01gid" UIConnectionName="slc01gid"/>
<endpoint-interaction portType="Sync_Dequeue_ptt" operation="Sync_Dequeue">
<interaction-spec className="oracle.tip.adapter.aq.v2.jca.AQReceiveNoWaitInteractionSpec">
<property name="Consumer" value="cons1"/>
<property name="SchemaValidation" value="false"/>
<property name="QueueName" value="EDN_OAOO_QUEUE"/>
<property name="ObjectFieldName" value="PAYLOAD"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

7.2.5 サポートされているADTペイロード・タイプ

次のRAWタイプをサポートしています。

- BLOB

- CHAR

- CLOB

- DATE

- DECIMAL

- DOUBLE PRECISION

- FLOAT

- INTEGER

- NUMBER

- REAL

- SMALLINT

- TIMESTAMP

- VARCHAR2

前述のリストに示したRAWタイプ以外にも、プリミティブ型およびオブジェクトの配列もサポートしています。

注意:

現在、ADT列のTIMESTAMP WITH LOCAL TIMEZONEデータ型およびTIMESTAMP WITH TIMEZONEデータ型がサポートされていません。

ADT全体ではなくペイロード・フィールドを選択する場合は、ペイロード・フィールドとして次のデータ型の1つを選択します。

- CLOB (XSDまたは不透明(Opaque)スキーマのいずれか)

- VARCHAR2 (XSDまたは不透明(Opaque)スキーマのいずれか)

- BLOB(不透明(Opaque)スキーマのみ)

- XMLTYPE (XSDまたは不透明(Opaque)スキーマのいずれか)

7.2.6 ネイティブ・フォーマット・ビルダー・ウィザード

ネイティブ・フォーマット・ビルダー・ウィザードを使用して、AQ RAWペイロード用のファイルを含む様々なフォーマットのXSDファイルを定義できます。

ネイティブ・フォーマット・ビルダー・ウィザードの詳細は、「ネイティブ・フォーマット・ビルダー・ウィザード」を参照してください。

ネイティブ・フォーマット・ビルダーの使用方法を示すサンプル・コードを取得するには、「開発者および管理者のサンプル・コード」ページの「ミドルウェアおよびツール」の下にある最新のSOAサンプル・コードにアクセスします。

ペイロード・スキーマ

ペイロード・スキーマはペイロード・タイプに依存します。ADT全体の場合、スキーマはアダプタ構成ウィザードによって完全に生成されます。ペイロードとしてBLOBが選択されたADTの場合、次のように定義された不透明(Opaque)スキーマを使用する必要があります。

<element name="opaqueElement" type="base64Binary" />

その他すべての場合には、表7-1 に示すように、スキーマを指定するか不透明(Opaque)スキーマを使用できます。

表7-1 ペイロード・スキーマ

ペイロード・タイプ

サポートされているスキーマ

RAW

ユーザー指定のスキーマまたは不透明(Opaque)スキーマ。

ADT全体

アダプタ構成ウィザードによって生成された、キュー構造に基づくスキーマを使用する必要があります。

ペイロードとしてVARCHAR2が選択されたADT

ユーザー指定のスキーマまたは不透明(Opaque)スキーマ。

ユーザー指定のスキーマまたは不透明(Opaque)スキーマのペイロードとしてCLOBが選択されたADT

ユーザー指定のスキーマまたは不透明(Opaque)スキーマ。

不透明(Opaque)スキーマのペイロードとしてBLOBが選択されたADT

不透明(Opaque)スキーマ。

XMLTYPE

ユーザー指定のスキーマまたは不透明(Opaque)スキーマ。

XSDファイルはないがペイロード・データが(カンマ区切り値(CSV)形式などで)書式設定されている場合は、ネイティブ・フォーマット・ビルダー・ウィザードを使用して適切なXSDを生成できます。アダプタ構成ウィザードは、ネイティブ・フォーマット・ビルダー・ウィザードと統合されています。「アダプタ構成ウィザード - メッセージ」ウィンドウで、「ネイティブ・フォーマットのスキーマの定義」をクリックしてネイティブ・フォーマット・ビルダー・ウィザードにアクセスします。

7.2.7 正規化されたメッセージのサポート

ヘッダーの操作と伝播は、重要なビジネス統合メッセージング要件です。Oracle BPEL PM、、Oracle JCAおよびB2Bは、顧客の統合ニーズを解決する上でヘッダー・サポートに大きく依存しています。たとえば、メッセージ・ヘッダーを介してファイル名を伝播することで、そのファイル名をソース・ディレクトリからターゲット・ディレクトリに保存できます。Oracle BPEL PMでは、様々なUIサポート・レベルでヘッダーにアクセスし、操作して設定できます。

注意:

リリース10.1.3でサポートされているAQアダプタのインバウンド・ヘッダーとアウトバウンド・ヘッダーは、リリース11gでは正規化されたメッセージ・プロパティを介してサポートされています。

詳細は、「アダプタ内での相関サポート」を参照してください

正規化されたメッセージのヘッダーの伝播

正規化されたメッセージは、プロパティとペイロードという2つの部分のみを持つように簡素化されています。通常、プロパティはスカラー型の名前/値ペアです。既存の複雑なヘッダーをプロパティに合せるために、プロパティはスカラー型にフラット化されています。

設計時のヘッダーの操作

複雑なプロパティは事前に決定されているため、設計時にヘッダーを操作する際のユーザー操作は合理化されています。メディエータまたはBPELデザイナでは、なんらかの予約済キーワードを使用してヘッダーを操作できます。たとえば、現在、メディエータでは、次の式を使用してインバウンド・ファイル・アダプタのfileNameヘッダーにアクセスできます。

$nmproperty.InboundFileHeaderType.fileName

ただし、この方法はユーザー入力に基づいて動的に生成されるプロパティに対処していません。たとえば、AQアダプタ・ウィザードでは、AQオブジェクトからの一部のフィールドをヘッダーとして伝播できます。選択内容に基づいてヘッダーが定義されます。これらの定義はあらかじめ決まらないため、あらかじめ決められたプロパティ定義のリストでは対応できません。動的プロパティが定義される前に、動的プロパティのヘッダー操作を設計することはできません。この制限に対応するには、必要なすべてのサービス(コンポジット・エントリ・ポイント)と参照を生成する必要があります。この制約は、動的プロパティを生成することが想定されるサービスに適用されます。動的プロパティが生成された後、コンポジットごとに格納される必要があります。その後にのみ、メディエータまたはBPELデザイナで動的プロパティを操作できます。

正規化されたメッセージのライフサイクル中に伝播する必要のあるプロパティの識別

プロパティには、メッセージのライフサイクル全体にわたって伝播される必要があるものもあれば、伝播されてはいけないものもあります。伝播される必要があるプロパティは伝播可能プロパティと呼ばれ、伝播されてはいけないプロパティは伝播不可プロパティと呼ばれます。

7.2.8 DOM2準拠

Document Object Model Level 2 (DOM 2)に準拠しているため、AQアダプタではDOM2仕様に準拠する文書オブジェクトを生成できます。

7.2.9 メッセージ・サイズ対応

メッセージ・サイズ対応です。つまり、メッセージ・サイズが計算され、サイズがレポートされます。公開されるサイズ関連APIは、レポート処理に使用できます。

7.2.10 複数の受信者スレッド

アクティブ化エンドポイント・プロパティadapter.aq.dequeue.threadsをサポートしています。アダプタとエンタープライズ情報システム(EIS)間のインバウンド・メッセージ・フロー用として複数のスレッドを生成するには、このプロパティを設定することをお薦めします。以前のバージョンでは、複数のエンドポイントを開始するために使用されていたactivationInstancesに依存していました。

7.2.11 DequeueTimeoutプロパティ

DequeueTimeOutプロパティは、複数のインバウンド・デキュー・スレッドをサポートしています。このプロパティの値により、dequeue() APIがメッセージを待機する秒数が決まります。この秒数が経過すると、このAPIが返されて次のポーリング・サイクルが開始されます。

次の例に示すように、このプロパティをcomposite.xmlファイルに追加します。

<service name="Inbound" ui:wsdlLocation="Inbound.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/aq/AQ_InboundRetry_Mediator/AQ2JMSInboundRetry/Inbound%2F#wsdl.interface(Dequeue_ptt)"/>
<binding.jca config="Inbound_aq.jca">
<property name="DequeueTimeOut" type="xs:integer" many="false"override="may">10
</property>
</binding.jca>
</service>

7.2.12 デキュー・タイムアウトおよび複数のインバウンド・ポーリング・スレッドの制御

プロセスごとではなくJava仮想マシン(JVM)ごとにシステム全体単位でデキュー・タイムアウトおよび複数のインバウンド・ポーリング・スレッドを制御するためのシステム・プロパティが用意されています。

デキュー・タイムアウトを制御するために用意されているシステム・プロパティは、oracle.adapter.aq.waitです。インバウンド・ポーリング・スレッドを制御するプロパティは、adapter.aq.dequeue.threadsです。

7.2.13 ストリーム・ペイロードのサポート

ストリーム・ペイロードのサポートが用意されています。この機能を有効化すると、ペイロードはメモリーDOM内のSOAランタイムで操作されるかわりにデータベースにストリーミングされます。この機能は、大きなペイロードの処理中に使用します。ストリーム・ペイロードのサポートを有効化するには、Oracle JDeveloper (JDeveloper)でデキュー操作パラメータを定義する際に「ストリーミングの有効化」チェック・ボックスを選択する必要があります。「ストリーミングの有効化」チェック・ボックスを選択すると、次の例に示すように、対応するブール・プロパティEnableStreamingがそれぞれの.jcaファイルに定義されているActivationSpecプロパティに追加されます。EnableStreamingプロパティが存在しない場合は、デフォルト値のfalseとみなされます。このプロパティは、Rawメッセージ、XMLTypeメッセージおよびADT属性を介してペイロードが指定されるADTタイプのメッセージを処理する際に適用可能です。

<activation-spec className="oracle.tip.adapter.aq.inbound.AQDequeueActivationSpec">
<property name="QueueName" value="RAW_IN_QUEUE"/>
<property name="DatabaseSchema" value="SCOTT"/>
<property name="EnableStreaming" value="true"/>
</activation-spec>

7.2.14 インバウンドの再試行

再試行可能な例外にjca.retry.countサービスのバインディング・プロパティを使用して6回以上再試行するように、インバウンドの再試行を構成する場合は、キューの作成にjca.retry.countに使用される値よりも大きいmax_retries値が使用されることを確認してください。何も指定しなければ、キューはmax_retries値5を使用して作成されますが、これは、メッセージが5回の再試行後に例外キューに送られ、以降の処理のためにアダプタに配信されないことを意味します。5以下の値を使用してjca.retry.countを指定すれば、キューのmax_retriesプロパティを変更する必要はありません。

キューの作成時に、次のコードを使用してmax_retriesプロパティを変更します。

begin
DBMS_AQADM.CREATE_QUEUE_TABLE ( queue_table => 'RAW_IN_QUEUE_TABLE',queue_payload_type => 'RAW');
DBMS_AQADM.CREATE_QUEUE ( queue_name => 'RAW_IN_QUEUE',queue_table=> 'RAW_IN_QUEUE_TABLE', max_retries=>1500);
DBMS_AQADM.START_QUEUE ( queue_name => 'RAW_IN_QUEUE');
DBMS_AQADM.CREATE_QUEUE_TABLE ( queue_table => 'RAW_OUT_QUEUE_TABLE', queue_payload_type => 'RAW');
DBMS_AQADM.CREATE_QUEUE ( queue_name  => 'RAW_OUT_QUEUE', queue_table => 'RAW_OUT_QUEUE_TABLE');
DBMS_AQADM.START_QUEUE ( queue_name => 'RAW_OUT_QUEUE');
end;

7.2.15 エラー処理のサポート

エラー処理については、「エラー処理」を参照してください。

7.2.16 パフォーマンス・チューニング

パフォーマンス・チューニング機能をサポートしています。

詳細は、「Oracle JCAアダプタ・チューニング・ガイド」および「Oracle JCAアダプタのプロパティ」を参照してください。

7.3 Oracle AQアダプタのデプロイメント

Oracle AQアダプタは、インストールの一部としてアプリケーション・サーバーにデプロイされます。これには、データソースjdbc/aqSampleを指す単一アダプタ・インスタンス・エントリeis/AQ/aqSampleが含まれています。データソースはインストールの一部として作成されないため、手動で作成する必要があります。データベースへの接続情報は、データソース定義内にあります。

インストールの時点で存在するOracle AQアダプタ・インスタンスeis/AQ/aqSampleを使用するSOAプロジェクトをデプロイする場合は、最初にデータソースjdbc/aqSampleを作成する必要があります。一方、新しいアダプタ・インスタンスを使用する場合は、新しいアダプタ・インスタンスを追加してアプリケーション・サーバーを再起動する必要があります。これは、既存のアダプタ・インスタンスjdbc/aqSampleで参照されるデータソースとは別のデータソースを指すようにする場合や、まだ存在しないアダプタ・インスタンスの名前を選択した場合などです。たとえば、JDeveloperでDBConnection1という名前の接続を作成した場合、図7-15に示すように、AQアダプタ・サービスはデフォルトでeis/AQ/DBConnection1 を指します。

また、次のコード・スニペットに示すように.jca ファイルを確認することによって、サービスがどのアダプタ・インスタンスを指しているかを確認できます。

<connection-factory location="eis/AQ/aqSample" … />

前述の例では、場所は実行時のアダプタ・インスタンスのJNDI名です。

新しいAQアダプタ・インスタンスを作成するには、「アダプタ・コネクション・ファクトリの追加」の説明に従ってOracle WebLogic管理コンソールを使用するか、weblogic-ra.xmlファイルを直接編集します。weblogic-ra.xmlを編集する手順は、次のとおりです。

1. fmwhome/でAqAdapter.rarを検索します。

2. ファイルを解凍します。

3. META-INF/weblogic-ra.xml(および、場合によってはra.xml)を編集します。

4. このファイルから再びJARを作成します。

5. アプリケーション・サーバーを再起動します。

weblogic-ra.xmlに含まれるサンプルAQアダプタ・インスタンスを次に示します。

例 - weblogic-ra.xmlに含まれるサンプルAQアダプタ・インスタンス

<connection-instance>
<jndi-name>eis/AQ/aqSample</jndi-name>
<connection-properties>
<properties>
<property>
<name>XADataSourceName</name>
<value>jdbc/aqSample</value>
</property>
<property>
<name>DataSourceName</name>
<value></value>
</property>
<property>
<name>ConnectionString</name>
<value></value>
</property>
<property>
<name>UserName</name>
<value></value>
</property>
<property>
<name>Password</name>
<value></value>
</property>
<property>
<name>DefaultNChar</name>
<value>false</value>
</property>
<property>
<name>UseDefaultConnectionManager</name>
<value>false</value>
</property>
</properties>
</connection-properties>
</connection-instance>

必須プロパティは、jndi-name、XADataSourceNameまたはDataSourceNameです。jndi-nameプロパティは、.jcaファイル内の場所属性に一致している必要があり、アダプタ・インスタンスの名前を表しています。XADataSourceNameまたはDataSourceNameプロパティは、基礎となるデータソース(接続情報が設定されている)の名前です。XADataSourceNameまたはDataSourceNameのいずれかのプロパティを指定します。使用方法は、シナリオに関与していてアダプタもグローバル・トランザクションに加える必要があるかどうか、またはローカル・トランザクション・セマンティクスが十分かどうかに応じて異なります。前者の場合にはXADataSourceNameを指定する必要があり、後者の場合にはDataSourceNameを指定する必要があります。XADataSourceNameプロパティを指定する場合は、プロパティによって参照される物理データソースでXAが有効化されていることを確認します。ただし、DataSourceNameプロパティを指定する場合は、プロパティによって参照される物理データソースでXAが有効化されている場合もされていない場合もあります。

最も一般的なミス

デプロイメントに関する最も一般的なミスとして、次の2つがあります。

- .jcaファイル内の場所属性に一致するアダプタ・インスタンス・エントリが作成されていません(または、インスタンスが1つも作成されていません)。

- .jcaファイル内の場所属性にデータソース名を直接設定しています。

後者の場合は、アダプタ・インスタンス名(eis/AQ/...)を指定し、このインスタンス名がデータソース・プール(jdbc/...)を指すというように間接的に指定する必要があります。一般的なミスは、このように間接的に指定せず、名前jdbc/...を場所属性に直接指定することです。

その他のアダプタ・インスタンス・プロパティ

AQアダプタ・インスタンスには、xADataSourceNameやdataSourceName以外にもプロパティがあります。

Oracle AQアダプタ・インスタンス・プロパティの詳細は、「Oracle AQアダプタのプロパティ」を参照してください。

7.4 使用例

この項には次のトピックが含まれます:

- 一般的な使用例

- ADTキュー

- Oracle AQアダプタのRAWキュー

7.4.1 一般的な使用例

次の使用例には、アダプタ構成ウィザードの概要が含まれ、様々な状況において通常の手順を変更する方法の例も示します。それぞれの例では、生成されるWSDLファイルとJCAファイルの関連部分を示しています。

この項には次のトピックが含まれます:

- アダプタ構成ウィザードの概要

- オブジェクトとADTペイロードのデキューおよびエンキュー

- オブジェクト・ペイロードの1つの列のデキュー

- エンキュー/デキュー操作タイプの構成

- デキュー中のメッセージのフィルタ処理に対する相関IDの使用

- マルチ・サブスクライバ・キューからのエンキューおよびデキュー

7.4.1.1 アダプタ構成ウィザードの概要

この例では、service_typeオブジェクト内の1つのフィールドであるペイロードとユーザー定義スキーマを設定して、メッセージをservice_in_queueキューにデキューするサービスを作成します。

この項では、JDeveloperでアダプタ構成ウィザードを使用して構成する際の必須タスクについて説明します。

この項には次のトピックが含まれます:

- 前提条件の確認

- アプリケーションおよびSOAプロジェクトの作成

- サービスの定義

- 生成されたWSDLおよびJCAファイル

7.4.1.1.1 前提条件の確認

この例は、基本的なBPELコンストラクト(アクティビティやパートナ・リンクなど)と、BPELコンポジットを作成およびデプロイするJDeveloper環境をよく理解していることを前提としています。

SCOTTスキーマを持つデータベースへのアクセス権限が必要です。

この使用例を実行するには、adapters-aq-103-adtclobpayloadサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/sql/setup_user.sql

- artifacts/sql/create_type_service.sql

- artifacts/sql/create_queues.sql

- artifacts/sql/dequeue_service.sql

- artifacts/sql/enqueue_service.sql

adapters-aq-103-adtclobpayloadサンプルを入手するには、Oracle Sample SOA Codeサイトにアクセスします。

7.4.1.1.2 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従ってアプリケーションとSOAプロジェクトを作成します。

1. JDeveloperを開きます。

2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。図7-10 に示すように、「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

3. 「アプリケーション名」フィールドにアプリケーションの名前を入力します。

4. 「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。

図7-10 「汎用アプリケーションの作成 - アプリケーションの名前付け」ページ

5. 「次へ」をクリックします。

図7-11 に示すように、「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

6. 「プロジェクト名」フィールドにわかりやすい名前を入力します。

例: SOAComposite。

7. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

図7-11 「汎用アプリケーションの作成 - 汎用プロジェクトの名前付け」ページ

8. 「次へ」をクリックします。

図7-12 に示すように、「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

図7-12 「汎用アプリケーションの作成 - SOA設定の構成」ページ

9. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して、「終了」をクリックします。

新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

図7-13 に示すように、「BPELプロセスの作成」ページが表示されます。

図7-13 「BPELプロセスの作成」ページ

10. 「名前」フィールドにBPELプロセスの名前を入力します。たとえば、CustomerDetailsです。

11. 「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。

CustomerDetails BPELプロセスが作成されました。

7.4.1.1.3 サービスの定義

次のステップは、サービスを定義することです。サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「サービス・アダプタ」リストから「AQアダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。

3. 「Next」をクリックします。
図7-14 に示すように、アダプタ構成ウィザードの「サービス名」ページが表示されます。

図7-14 「アダプタ構成ウィザード - サービス名」ページ

4. サービス名を指定して「次へ」をクリックします。
図7-15 に示すように、アダプタ構成ウィザードの「サービス接続」ページが表示されます。

図7-15 「アダプタ構成ウィザード - サービス接続」ページ

5. プラス・アイコンをクリックしてデータベース接続を作成します。
「データベース接続の作成」ページが表示されます。

注意:

Oracle Applicationsを実行中のデータベースに接続する必要があります。

6. 次の情報を入力します。

a. 「接続の作成場所」で、「アプリケーション・リソース」を選択します。

b. 「接続名」フィールドで、データベース接続に使用する一意の名前を指定します。
この例では、DBConnection1と入力します。

c. 「接続タイプ」ボックスから「Oracle (JDBC)」を選択します。

d. 「ユーザー名」フィールドで、データベースへのアクセスが認証されているユーザー名を指定します。
この例では、scottと入力します。

e. 「ロール」フィールドで、必要に応じてロールを入力します。
これは、データベースに指定されているSYSDBAなどの特定のデータベース・ロールである必要があります。このフィールドはオプションです。この例では、「ロール」フィールドは空白にしておきます。

f. 「パスワード」フィールドで、指定されたユーザー名に関連付けるパスワードを指定します。
この例では、tigerと入力します。

g. 「パスワードの保存」と「パスワードのデプロイ」を順番に選択します。

h. 「ドライバ」リストから「thin」を選択します。

i. 「ホスト名」フィールドで、Oracleサーバーを実行するシステムを識別する値を入力します。
TCP/IPで解決できるIPアドレスまたはホスト名(myserverなど)を使用します。デフォルト値はlocalhostです。

j. 「JDBCポート」フィールドで、TCP/IPポートを識別する値を入力します。デフォルトは1521です。

k. 「SID」フィールドで、Oracleデータベース・インスタンスの一意のシステム識別子(SID)の値を入力します。
デフォルトはXEです。

l. 「接続のテスト」をクリックし、指定した情報によりデータベースとの接続が確立されるかどうかを確認します。
成功メッセージが表示されます。

m. 「OK」をクリックします。
作成した接続が「サービス名」ページの「接続」フィールドに表示されます。

データベース接続の作成を完了すると、「JNDI名」フィールドにJava Naming and Directory Interface (JNDI)名が移入されます。JNDI名は、サービスがBPELサーバーにデプロイされるときに使用される接続のプレースホルダとなります。JNDIをプレースホルダとして使用すると、開発とその後の本番に異なるデータベースを使用できます。

アダプタが管理モードで確実に実行されるように、JNDI名で指定した値がweblogic-ra.xmlファイルに存在する必要があります。デフォルトの接続インスタンスeis/AQ/aqSampleが用意されており、このフィールドのデフォルト値として使用できます。この接続インスタンスを使用するには、JNDI名jdbc/aqSampleを使用してデータソースを作成する必要もあります。

7. 「Next」をクリックします。
図7-16 に示すように、「アダプタ構成ウィザード - アダプタ・インタフェース」ページが表示されます。

8. 「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択します。

図7-16 「アダプタ構成ウィザード - アダプタ・インタフェース」ページ

9. 「Next」をクリックします。
「操作」ページが表示されます。

10. 次の3つのオペレーションがサポートされます。

- デキュー: キューから受信するメッセージをポーリングします。

- エンキュー: 発信メッセージをキューに置きます。

- エンキュー/デキュー: 発信メッセージをキューに置き、キュー上でレスポンス・メッセージを待機します。

この例では、図7-17 に示すように「デキュー」を選択します。

操作には、選択した操作名に基づいて名前が自動的に付けられます。ただし、「操作名」フィールドは編集できます。

図7-17 「アダプタ構成ウィザード - 操作」ページ

注意:

ADT (Oracleオブジェクト)データ型に基づいてキューからデキューするインバウンドOracle AQアダプタを使用するSOAコンポジットを作成したときに、.jca構成ファイル内のSchemaValidationプロパティがtrueに設定されている場合は、デキューされたメッセージ内にADTペイロードの空(NULL)のメンバーが存在すると、AQ_INVALID_PAYLOADエラーが発生し、さらにはメッセージが拒否されることになります。メッセージが拒否されないようにするには、SchemaValidationプロパティをfalseに設定する必要があります。

11. 「Next」をクリックします。
図7-18 に示すように、アダプタ構成ウィザードの「キュー名」ページが表示されます。

図7-18 「アダプタ構成ウィザード - キュー名」ページ

12. 「データベース・スキーマ」リストからデータベース・スキーマを選択するか、「参照」をクリックしてスキーマを参照します。この例では、「参照」をクリックします。
図7-19 に示すように、「キューの選択」ダイアログが表示されます。

図7-19 「キューの選択」ダイアログ

13. 必要なキューを選択して「OK」をクリックします。
この例では、「SERVICE_IN_QUEUE」を選択します。図7-20 に示すように、「キュー名」フィールドにSERVICE_IN_QUEUEが移入された状態で「キュー名」ページが再表示されます。

図7-20 「アダプタ構成ウィザード - キュー名」ページ

14. 「Next」をクリックします。
図7-21 に示すように、アダプタ構成ウィザードの「キュー・パラメータ」ページが表示されます。

図7-21 「アダプタ構成ウィザード - キュー・パラメータ」ページ

15. パラメータ値を入力して「次へ」をクリックします。

- 相関ID: 1文字から30文字までの長さでオプションの相関IDを入力します。これは、同じ相関IDを使用したデキュー・アクティビティによって後から取得されるメッセージの識別に使用されます。
入力する値は、非同期通信のためにエンキューの送信元とデキューの受信先で同意されています。相関IDはAQヘッダー・プロパティにマップされます。インバウンド方向の相関IDにより、デキューするメッセージの選択が可能になります。このフィールドはオプションです。値を入力しない場合は、キューにあるすべてのメッセージが処理されます。

アウトバウンド方向の相関IDの値を入力した場合、適切なIDを持つすべてのアウトバウンド・メッセージが入力した値に設定されます。この値はアウトバウンド・ヘッダーの相関フィールドで、メッセージごとにオーバーライドできます。

- デキュー条件: 「操作」ページでデキューを選択した場合にのみ表示されます。
SQL問合せのWHERE句に似たブール式を入力します。このブール式には、メッセージ・プロパティ、ユーザー・データ・プロパティ(オブジェクト・ペイロードのみ)およびPL/SQLまたはSQL関数に関する条件を含めることができます。複数のメッセージがデキュー条件を満たす場合、デキュー順序は不定になり、キューのソート順は考慮されません。

このフィールドは、インバウンド・シングル・コンシューマおよびマルチ・コンシューマ・キューに対して表示されます。

16. 「Next」をクリックします。

図7-22 に示すように、アダプタ構成ウィザードの「オブジェクト・ペイロード」ページが表示されます。

図7-22 「アダプタ構成ウィザード - オブジェクト・ペイロード」ページ

a. 「ビジネス・ペイロード」で、「オブジェクト内のフィールド」を選択します。

b. 「ペイロード・フィールド・オプション」セクションで「参照」をクリックし、ビジネス・ペイロードが含まれるフィールドを選択します。
図7-23 に示すように、「ペイロード・フィールドの選択」ダイアログが表示されます。

図7-23 「ペイロード・フィールドの選択」ダイアログ

17. フィールドを選択して「OK」をクリックします。
この例では、「PAYLOAD (CLOB)」を選択します。

図7-24 に示すように、すべてのペイロード詳細が入力された状態で「オブジェクト・ペイロード」フィールドが表示されます。

図7-24 「アダプタ構成ウィザード - オブジェクト・ペイロード」ページ

18. 「ペイロード以外のフィールドへのアクセスも必要」を選択して「次へ」をクリックします。
「メッセージ」ページが表示されます。

「メッセージ」ページには、次のオプションが表示されます。

- ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする): スキーマを指定しない場合は、このオプションを選択します。このオプションを選択すると、「メッセージ・スキーマ」の他のフィールドがすべて無効化されます。

- ネイティブ・フォーマットのスキーマの定義: ネイティブ・フォーマットの定義プロセスを支援するネイティブ・フォーマット・ビルダー・ウィザードを起動するには、これをクリックします。

- URL: スキーマ・ファイルURLのパスを入力するか、「参照」をクリックしてパスを参照できます。

- スキーマ要素: スキーマ要素名。

19. この例では、「スキーマ・ファイルを参照」をクリックしてスキーマ・ファイルURLを参照します。
図7-25 に示すように、「タイプ・チューザ」ダイアログが表示されます。

図7-25 「タイプ・チューザ」ダイアログ

20. 図7-25 に示すように、リストから「SERVICE」を選択して「OK」をクリックします。
図7-26 に示すように、「スキーマの場所」および「スキーマ要素」のフィールドに移入済の「メッセージ」ページが表示されます。

図7-26 「アダプタ構成ウィザード - メッセージ」ページ

21. 「Next」をクリックします。
「終了」画面が表示されます。このページには、ウィザードにより作成されるアダプタ・ファイルのパスと名前が表示されます。

22. 「終了」をクリックします。
デキュー操作を持つAQアダプタ・サービスの作成を完了しました。

23. 「OK」をクリックします。

7.4.1.1.4 生成されたWSDLおよびJCAファイル

アダプタ・サービスにより、定義済のアダプタ・インタフェースとして機能するWSDLおよびJCAファイルが生成されます。

デキュー操作用に生成されたWSDLファイルを次に示します。

<definitions name="Inbound" targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:obj1="http://xmlns.oracle.com/xdb/SCOTT" xmlns:imp1="http://www.oracle.com/service/contract">
<types>
<schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns:hdr="http://xmlns.oracle.com/pcbpel/adapter/aq/inbound/" xmlns:obj1="http://xmlns.oracle.com/xdb/SCOTT">
<import namespace="http://xmlns.oracle.com/xdb/SCOTT" schemaLocation="xsd/SCOTT_SERVICE_TYPE.xsd"/>
<import namespace="http://xmlns.oracle.com/pcbpel/adapter/aq/inbound/" schemaLocation="xsd/aqAdapterInboundHeader.xsd"/>
<complexType name="HeaderCType">
<sequence>
<element name="QueueHeader" type="hdr:HeaderType"/>
<element name="PayloadHeader" type="obj1:SERVICE_TYPE"/>
</sequence>
</complexType>
<element name="Header" type="tns:HeaderCType"/>
</schema>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.oracle.com/service/contract" schemaLocation="xsd/service.xsd"/>
</schema>
</types>
<message name="SERVICE_msg">
<part name="SERVICE" element="imp1:SERVICE"/>
</message>
<message name="Header_msg">
<part name="Header" element="tns:Header"/>
</message>
<portType name="Dequeue_ptt">
<operation name="Dequeue">
<input message="tns:SERVICE_msg"/>
</operation>
</portType>
<plt:partnerLinkType name="Dequeue_plt">
<plt:role name="Dequeue_role">
<plt:portType name="tns:Dequeue_ptt"/>
</plt:role>
</plt:partnerLinkType>
</definitions>

7.4.1.2 オブジェクトとADTペイロードのデキューおよびエンキュー

デキューとエンキューについては、「ADTキュー」を参照してください。

オブジェクト全体をペイロードとしてエンキューまたはデキューするには、次の手順を実行します。

- ステップ10で「エンキュー」または「デキュー」を選択します。

- 「オブジェクトCUSTOMER_TYPE全体」を選択し、ステップ16に進みます。

ADTペイロードの使用例の実例を参照するには、次のサンプルのいずれかを参照してください。

- adapters-aq-102-adt

- adapters-aq-110-supportedadttypes

これらのサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

注意:

ALTER OBJECTなどの展開コマンドを使用してADTタイプを修正した場合は、AQアダプタによりORA-25215 SQL例外がスローされます。

この例外の回避するには、CREATE OBJECTのみを使用して(ALTER OBJECTなどの展開コマンドを発行することなく)ADT TYPESに属性を追加します。

7.4.1.3 オブジェクト・ペイロードの1つの列のデキュー

概要では、オブジェクト・ペイロード内の単一のフィールドまたは列をデキューする例を示しました。

オブジェクト内の1つのフィールドをデキューするアダプタを作成するには、アダプタ構成ウィザードの「オブジェクト・ペイロード」ページで次の手順を実行する必要があります。

1. 「オブジェクト内のフィールド」を選択します。

2. 「フィールド名」フィールドの端にある「参照」をクリックします。

「ペイロード・フィールドの選択」ダイアログが表示されます。

3. ビジネス・ペイロードを格納するフィールドを選択して「OK」をクリックします。

図7-27 に示すように、「フィールド名」フィールドに選択したフィールドが移入された状態でアダプタ構成ウィザードの「オブジェクト・ペイロード」ページが表示されます。

図7-27 「アダプタ構成ウィザード - オブジェクト・ペイロード」ページ

4. 「ペイロード以外のフィールドへのアクセスも必要」を選択して「次へ」をクリックします。

生成されたJCAファイルの次のセグメントには、ペイロード・ヘッダー・フィールド以外に、1つのフィールド(この場合はPAYLOADという名前のフィールド)がデキューされることが指定されています。

<adapter-config name="Inbound" adapter="AQ Adapter" xmlns="http://platform.integration.oracle/blocks
/adapter/fw/metadata">
<connection-factory location="eis/AQ/aqSample"
UIConnectionName="Connection1" adapterRef=""/>
<endpoint-activation portType="Dequeue_ptt" operation="Dequeue">
<activation-spec    className="oracle.tip.adapter.aq.inbound.AQDequeueActivationSpec">
<property name="QueueName" value="SERVICE_IN_QUEUE"/>
<property name="ObjectFieldName" value="PAYLOAD"/>
<property name="PayloadHeaderRequired" value="true"/>
<property name="SchemaValidation" value="false"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

オブジェクト・ペイロード内の1つのフィールドまたは列がデキューされるADT CLOBの使用例の実例を参照するには、次のサンプルを参照してください。

- adapters-aq-103-adtclobpayload

- adapters-aq-105-adtclobopaquepayload

これらのサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

7.4.1.4 エンキュー/デキュー操作タイプの構成

この使用例では、発信メッセージをキューに蓄積し、別のキュー上のレスポンス・メッセージを待機する、エンキュー/デキュー操作タイプを構成する手順について説明します。

この項には次のトピックが含まれます:

- 前提条件の確認

- アプリケーションおよびSOAプロジェクトの作成

- サービスの定義

- サービスとアクティビティのワイヤリング

- デプロイ

- 監視

- 生成されたWSDLおよびJCAファイル

7.4.1.4.1 前提条件の確認

この使用例を実行するには、SCOTTスキーマを持つデータベースへのアクセス権限が必要です。また、adapters-aq-104-requestreplyサンプルに含まれているartifacts.zipファイルの次のファイルも必要となります。

- create_queues.sql

- drop_queues.sql

- enqueue.sql

- SendReply.sql

- setup_user.sql

adapters-aq-104-requestreplyサンプル・コードを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

7.4.1.4.2 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。「アプリケーションおよびSOAプロジェクトの作成」に記載された手順に従って、アプリケーションおよびSOAプロジェクトを作成します。

7.4.1.4.3 Oracle AQアダプタ・サービスの定義

発信メッセージをキューに蓄積し、キューのレスポンス・メッセージを待機するOracle AQアダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「サービス・アダプタ」リストから「AQアダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。

3. 「Next」をクリックします。
図7-14 に示すように、アダプタ構成ウィザードの「サービス名」ページが表示されます。

4. サービス名を指定して「次へ」をクリックします。
アダプタ構成ウィザードの「サービス接続」ページが表示されます。

5. プラス・アイコンをクリックしてデータベース接続を作成します。
「データベース接続の作成」ページが表示されます。

注意:

Oracle Applicationsを実行中のデータベースに接続する必要があります。

6. 次の情報を入力します。

a. 「接続の作成場所」で、「アプリケーション・リソース」を選択します。

b. 「接続名」フィールドで、データベース接続に使用する一意の名前を指定します。

c. 「接続タイプ」ボックスから「Oracle (JDBC)」を選択します。

d. 「ユーザー名」フィールドで、データベースへのアクセスが認証されているユーザー名を指定します。
この例では、scottと入力します。

e. 「ロール」フィールドで、必要に応じてロールを入力します。
これは、データベースに指定されているSYSDBAなどの特定のデータベース・ロールである必要があります。このフィールドはオプションです。この例では、「ロール」フィールドは空白にしておきます。

f. 「パスワード」フィールドで、指定されたユーザー名に関連付けるパスワードを指定します。
この例では、tigerと入力します。

g. 「パスワードの保存」と「パスワードのデプロイ」を順番に選択します。

h. 「ドライバ」リストから「thin」を選択します。

i. 「ホスト名」フィールドで、Oracleサーバーを実行するシステムを識別する値を入力します。
TCP/IPで解決できるIPアドレスまたはホスト名(myserverなど)を使用します。デフォルト値はlocalhostです。

j. 「JDBCポート」フィールドで、TCP/IPポートを識別する値を入力します。デフォルトは1521です。

k. 「SID」フィールドで、Oracleデータベース・インスタンスの一意のシステム識別子(SID)の値を入力します。
デフォルトはXEです。

l. 「接続のテスト」をクリックし、指定した情報によりデータベースとの接続が確立されるかどうかを確認します。
成功メッセージが表示されます。

m. 「OK」をクリックします。
作成した接続が「サービス接続」ページの「接続」フィールドに表示されます。

また、データベース接続を作成した後、「JNDI名」フィールドに移入が行われます。

アダプタが管理モードで確実に実行されるように、JNDI名で指定した値がOracle AQアダプタのweblogic-ra.xmlファイルに存在する必要があります。デフォルトの接続インスタンスeis/AQ/aqSampleが用意されており、このフィールドのデフォルト値として使用できます。この接続インスタンスを使用するには、JNDI名jdbc/aqSampleを使用してデータソースを作成する必要もあります。

7. 「Next」をクリックします。
アダプタ構成ウィザードの「アダプタ・インタフェース」ページが表示されます。

8. 「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択します。

9. 「Next」をクリックします。
「操作」ページが表示されます。

10. 図7-17 に示すように「エンキュー/デキュー」を選択します。

図7-28 「アダプタ構成ウィザード - 操作」ページ

11. 「Next」をクリックします。
図7-18 に示すように、アダプタ構成ウィザードの「キュー名」ページが表示されます。

図7-29 「アダプタ構成ウィザード - キュー名」ページ

12. リクエスト・キューを参照するには、「参照」をクリックします。

図7-30 に示すように、「キューの選択」ダイアログが表示されます。

図7-30 「キューの選択」ダイアログ

13. 必要なキューを選択して「OK」をクリックします。

この例では、「CORRELATION_REQUEST」を選択します。図7-31 に示すように、「キュー名」フィールドにCORRELATION_REQUESTが移入された状態で「キュー名」ページが表示されます。

14. ステップ12と13を繰り返して、キュー情報をエンキューします。
図7-31 に示すように、「キュー名」ページが表示されます。

図7-31 「アダプタ構成ウィザード - キュー名」ページ

15. 「Next」をクリックします。
図7-32 に示すように、アダプタ構成ウィザードの「キュー・パラメータ」ページが表示されます。

図7-32 「アダプタ構成ウィザード - キュー・パラメータ」ページ

16. 「Next」をクリックします。
図7-33 に示すように、アダプタ構成ウィザードの「オブジェクト・ペイロード」ページが表示されます。

図7-33 「アダプタ構成ウィザード - オブジェクト・ペイロード」ページ

17. 「ビジネス・ペイロード」オプション、「オブジェクトCORRELATIONREQUEST_TYPE全体」および「オブジェクトCORRELATIONREPLY_TYPE全体」を選択します。

18. 「Next」をクリックします。
「終了」画面が表示されます。このページには、ウィザードにより作成されるアダプタ・ファイルのパスと名前が表示されます。

19. 「終了」をクリックします。
同期エンキュー/デキュー操作に対して、AQアダプタ・サービスの作成を完了しました。

20. 「OK」をクリックします。

7.4.1.4.4 サービスとアクティビティのワイヤリング

BPELプロセスおよびアウトバウンド・アダプタ参照をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のRequestReply内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
JDeveloperのcomposite.xmlが図7-34 のように表示されます。

図7-34 JDeveloper - composite.xml

2. 「ファイル」、「すべて保存」を順番にクリックします。

invokeアクティビティの追加

1. 「BPELProcess1」をダブルクリックします。「BPELProcess1.bpel」ページが表示されます。

2. 「コンポーネント」ウィンドウから設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

3. invokeアクティビティをダブルクリックします。「Invoke」ダイアログが表示されます。

4. 「名前」フィールドにinvokeアクティビティの名前を入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。図7-35 に示すように、「パートナ・リンク・チューザ」ダイアログが表示されます。

図7-35 「パートナ・リンク・チューザ」ダイアログ

6. 「RequestReply」を選択して「OK」をクリックします。

7. 図7-36 に示すように、「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

図7-36 「Invoke」ダイアログ

8. デフォルトの変数名を選択し、「OK」をクリックします。「変数」フィールドにデフォルトの変数名が移入されます。

9. 「OK」をクリックします。図7-37 に示すように、JDeveloperの「BPELProcess1.bpel」ページが表示されます。

図7-37 JDeveloper - 「BPELProcess1.bpel」ページ

assignアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にassignアクティビティをドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。

3. 「名前」フィールドにassignアクティビティの名前を入力します。

4. 「コピー操作」タブをクリックします。

5. 「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

6. 図7-38 に示すように、inputVariableからoutputVariableへのコピー操作を作成します。

図7-38 「コピー操作の作成」ダイアログ

7. 「コピー操作の作成」ダイアログで「OK」をクリックします。

8. 図7-39 に示すように、inputVariableからInvoke_1_Enqueue_InputVariableへの別のコピー操作を作成します。

図7-39 「コピー操作の作成」ダイアログ

9. 「コピー操作の作成」ダイアログで「OK」をクリックします。

10. 図7-40 に示すように、「OK」をクリックしてJDeveloperの「BPELProcess1.bpel」ページに戻ります。

図7-40 JDeveloper - BPELProcess1.bpel

11. 「ファイル」、「すべて保存」を順番にクリックします。

receiveアクティビティの追加

1. 「コンポーネント」ウィンドウから設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

2. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

3. 「名前」フィールドにreceiveアクティビティの名前を入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 「RequestReply」を選択して「OK」をクリックします。

6. 「Receive」ダイアログで、「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

8. 「インスタンスの作成」を選択して、「OK」をクリックします。図7-41 に示すように、JDeveloperの「BPELProcess1.bpel」ページが表示されます。

図7-41 JDeveloper - BPELProcess1.bpel

7.4.1.4.5 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする手順は、次のとおりです。

1. 「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」に示す手順を使用して、アプリケーション・サーバー接続を作成します。

2. 「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

7.4.1.4.6 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. インスタンスをクリックします。「フローのトレース」ページが表示されます。

3. 「BPEL」コンポーネント・インスタンスをクリックします。「監査」ページが表示されます。

4. 「フロー - デバッグ」タブをクリックしてインスタンスをデバッグします。

7.4.1.4.7 生成されたWSDLおよびJCAファイル

エンキュー/デキュー操作用に生成されたWSDLファイルを次に示します。

<?xml version = '1.0' encoding = 'UTF-8'?>
<?binding.jca Inbound_aq.jca?>
<definitions name="Inbound" targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:obj1="http://xmlns.oracle.com/xdb/SCOTT" xmlns:imp1="http://www.oracle.com/ipdemo">
<types>
<schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/" xmlns:hdr="http://xmlns.oracle.com/pcbpel/adapter/aq/inbound/" xmlns:obj1="http://xmlns.oracle.com/xdb/SCOTT">
<import namespace="http://xmlns.oracle.com/xdb/SCOTT" schemaLocation="xsd/SCOTT_MAGAZINE_TYPE.xsd"/>
<import namespace="http://xmlns.oracle.com/pcbpel/adapter/aq/inbound/" schemaLocation="xsd/aqAdapterInboundHeader.xsd"/>
<complexType name="HeaderCType">
<sequence>
<element name="QueueHeader" type="hdr:HeaderType"/>
<element name="PayloadHeader" type="obj1:MAGAZINE_TYPE"/>
</sequence>
</complexType>
<element name="Header" type="tns:HeaderCType"/>
</schema>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.oracle.com/ipdemo"       schemaLocation="xsd/simpleMagazine.xsd"/>
</schema>
<?xml version = '1.0' encoding = 'UTF-8'?>
<?binding.jca Inbound_aq.jca?>
<definitions name="Inbound"
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/"
xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:obj1="http://xmlns.oracle.com/xdb/SCOTT"
xmlns:imp1="http://www.oracle.com/ipdemo">
<types>
<schema attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/aq/Inbound/"
xmlns:hdr="http://xmlns.oracle.com/pcbpel/adapter/aq/inbound/"

xmlns:obj1="http://xmlns.oracle.com/xdb/SCOTT">
<import namespace="http://xmlns.oracle.com/xdb/SCOTT"
schemaLocation="xsd/SCOTT_MAGAZINE_TYPE.xsd"/>
<import namespace="http://xmlns.oracle.com/pcbpel/adapter/aq/inbound/"

schemaLocation="xsd/aqAdapterInboundHeader.xsd"/>
<complexType name="HeaderCType">
<sequence>
<element name="QueueHeader" type="hdr:HeaderType"/>
<element name="PayloadHeader" type="obj1:MAGAZINE_TYPE"/>
</sequence>
</complexType>

<element name="Header" type="tns:HeaderCType"/>
</schema>

<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://www.oracle.com/ipdemo"
schemaLocation="xsd/simpleMagazine.xsd"/>
</schema>
</types>
<message name="simpleMagazine_msg">

<part name="simpleMagazine" element="imp1:simpleMagazine"/>
</message>
<message name="Header_msg">
<part name="Header" element="tns:Header"/>
</message>
<portType name="Dequeue_ptt">
<operation name="Dequeue">
<input message="tns:simpleMagazine_msg"/>
</operation>
</portType>
<plt:partnerLinkType name="Dequeue_plt">
<plt:role name="Dequeue_role">
<plt:portType name="tns:Dequeue_ptt"/>
</plt:role>
</plt:partnerLinkType>
</definitions>

エンキュー/デキュー操作用に生成されたJCAファイルを次に示します。

<adapter-config name="RequestReply" adapter="AQ Adapter" wsdlLocation="RequestReply.wsdl" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">

<connection-factory location="eis/AQ/aqSample" UIConnectionName="aqSample" adapterRef=""/>
<endpoint-activation portType="Dequeue_ptt" operation="Dequeue" UITransmissionPrimitive="Request-response">
<activation-spec className="oracle.tip.adapter.aq.inbound.AQDequeueActivationSpec">
<property name="QueueName" value="CORRELATION_REPLY"/>
</activation-spec>
</endpoint-activation>

<endpoint-interaction portType="Enqueue_ptt" operation="Enqueue" UITransmissionPrimitive="Request-response">
<interaction-spec className="oracle.tip.adapter.aq.outbound.AQEnqueueInteractionSpec">
<property name="QueueName" value="CORRELATION_REQUEST"/>
</interaction-spec>
</endpoint-interaction>

</adapter-config>

7.4.1.5 デキュー中のメッセージのフィルタ処理に対する相関IDの使用

特定の相関IDのメッセージのみをデキューするアダプタを設定するには、次の手順を実行します。

- ステップ10で「デキュー」操作を選択します。

- ステップ15で相関IDを入力します。

アダプタにより、それと同様の相関IDでエンキューされたメッセージのみがデキューされます。

この使用例(Oracle AQアダプタにより、それと同様の相関IDでエンキューされたメッセージがデキューされる例)の実例を参照するには、次のサンプルを参照してください。

- adapters-aq-106-messagerejection

- adapters-aq-109-nativecorrelation

- adapters-aq-112-prioritymessageselector

- adapters-aq-113-payloadbasedmessageselector

これらのサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

7.4.1.6 マルチ・サブスクライバ・キューからのエンキューおよびデキュー

マルチ・サブスクライバ・キューには、複数のユーザーがアクセスできます。また、それらのユーザーがキュー内の特定のタイプのメッセージのみを対象とする場合もあります。たとえば、$100,000を超えるローンには監督者の承認が必要であるのに対して、$100,000未満のローンは通常のローン承認スタッフが承認できるローン・アプリケーションがあり、そのアプリケーションにマルチ・ユーザー・キューがあるとします。この場合、BPELプロセスでは、1つのアダプタが監督者用の巨額ローンのローン・アプリケーションのエンキューに使用され、もう1つのアダプタが同じマルチ・サブスクライバ・キューにある一般スタッフ用の小額ローンのローン・アプリケーションのエンキューに使用されます。

マルチ・サブスクライバ・キューにエンキューするアダプタを指定し、「受信者」フィールドでキュー・パラメータを指定します。

ステップ15で、「受信者」フィールドにBobを指定します。

次に、受信者リストBobを使用してエンキューするアダプタを定義して生成されたJCAファイルのコードを示します。

<adapter-config name="Inbound" adapter="AQ Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/AQ/aqSample" UIConnectionName="aqSample" adapterRef=""/>
<endpoint-interaction portType="Enqueue_ptt" operation="Enqueue">
<interaction-spec className="oracle.tip.adapter.aq.outbound.AQEnqueueInteractionSpec">
<property name="QueueName" value="PURCHASEORDER_APPROVAL"/>
<property name="RecipientList" value="Bob"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

マルチ・サブスクライバ・キューからデキューすると、「キュー・パラメータ」ウィンドウが表示されます。

「コンシューマ」フィールドは、コンシューマ名またはキュー・サブスクライバ名を指定するフィールドです。デキューするメッセージのエンキュー・プロセスの「受信者」エントリと一致する必要があります。マルチ・コンシューマ・キューへのサブスクライブには、このフィールドが必要です。

次に、コンシューマ名を使用するアダプタを定義して生成されるJCAファイルのコードを示します。

<adapter-config name="Dequer_Bob" adapter="AQ Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/AQ/manas" UIConnectionName="aqSample" adapterRef=""/>
<endpoint-activation portType="Dequeue_ptt" operation="Dequeue">
<activation-spec className="oracle.tip.adapter.aq.inbound.AQDequeueActivationSpec">
<property name="QueueName" value="PURCHASEORDER_APPROVAL"/>
<property name="Consumer" value="Bob"/>
<property name="SchemaValidation" value="false"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

マルチ・サブスクライバ・キューからのエンキューとデキューを示す、この使用例の実例を参照するには、次のサンプルを参照してください。

- adapters-aq-114-multiconsumeroutbound

これらのサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

7.4.2 ADTキュー

このサンプルでは、ビジネス・プロセスはAQアダプタからメッセージを受信し、ペイロードをアウトバウンド・メッセージにコピーし、アウトバウンド・メッセージを使用してAQアダプタを起動します。関係するキューはADTキューです。このシナリオでは、ユーザーがADT全体をペイロードとして使用するように選択しており、AQアダプタ・ウィザードではキュー構造に従ってSCOTT_CUSTOMER_TYPE.xsdにスキーマが生成されています。実行時には、アダプタによりスキーマに一致するXMLファイルがメッセージごとに作成されます。

この項には次のトピックが含まれます:

- 前提条件の確認

- アプリケーションおよびSOAプロジェクトの作成

- インバウンドOracle AQアダプタの作成

- アウトバウンドOracle AQアダプタの作成

- サービスとアクティビティのワイヤリング

- ルーティング・サービスの構成

- デプロイ

- データソースの構成

7.4.2.1 前提条件の確認

SCOTTスキーマを持つデータベースへのアクセス権限が必要です。

この使用例を実行するには、adapters-aq-102-adtサンプルに含まれているartifacts.zipファイルの次のSQLファイルが必要です。これらのファイルは、artifacts.zipファイルのartifacts/sqlサブディレクトリにあります。次に示す順序でSQLファイルを実行します。

- setup_user.sql

- create_type_customer.sql

- create_queues.sql

- enqueue_customer.sql

- dequeue_customer.sql

adapters-aq-102-adtサンプル・コードを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

7.4.2.2 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従ってアプリケーションとSOAプロジェクトを作成します。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。

「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにADTと入力して「次へ」をクリックします。

「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにADTと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次へ」をクリックします。

「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

6. 「コンポジット・テンプレート」リストから「メディエータを使用するコンポジット」を選択して「終了」をクリックします。

新規アプリケーションおよびSOAプロジェクトが作成されました。

図7-42 に示すように、「メディエータの作成」ページが表示されます。

図7-42 「メディエータの作成」ページ

7. 「名前」フィールドにメディエータ・コンポーネントの名前を入力します。この例では、デフォルト名のMediator1を保持します。

8. 「テンプレート」リストで「インタフェースを後で定義」を選択し、「OK」をクリックします。

メディエータ・コンポーネントが作成されました。

7.4.2.3 インバウンドOracle AQアダプタの作成

次の手順に従ってインバウンドOracle AQアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「コンポーネント」ウィンドウの「サービス・アダプタ」リストから、「AQアダプタ」をcomposite.xmlページ内の「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。
「アダプタ構成ウィザード」が表示されます。

3. 「Next」をクリックします。
「サービス名」ページが表示されます。

4. 「サービス名」ページでサービスの名前を指定します。この例では、dequeueと入力します。

5. 「Next」をクリックします。
「サービス接続」ページが表示されます。Oracle AQアダプタを構成するにはデータベース接続が必要です。新規接続を作成するか、既存のデータベース接続を選択できます。

6. 「新規データベース接続を作成します。」アイコンをクリックしてデータベース接続を作成します。
「データベース接続の作成」ページが表示されます。

7. 「サービスの定義」のステップ6の説明に従ってデータベース接続を作成します。

8. 「OK」をクリックして新規データベース接続の作成プロセスを完了します。
「サービス接続」ページが表示され、データベース接続のサマリーが示されます。

9. 「Next」をクリックします。
「アダプタ・インタフェース」ページが表示されます。

10. 「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択します。

11. 「Next」をクリックします。
「操作」ページが表示されます。

12. 「デキュー」を選択します。

13. デフォルトの操作名を受け入れて「次へ」をクリックします。
「キュー名」ページが表示されます。

14. リストからデータベース・スキーマを選択するか、「参照」をクリックしてスキーマを参照します。この例では、「参照」をクリックします。
「キューの選択」ダイアログが表示されます。

15. 「キューの選択」ダイアログで、次の手順を実行します。

a. 「キュー・タイプ」で「すべてのタイプ」を選択します。

b. 「データベース・スキーマ」で「Scott」を選択します。

c. 他の設定はデフォルト値のままにします。

d. 「キュー」で「CUSTOMER_IN_QUEUE」を選択します。

図7-43 に、「キューの選択」ダイアログを示します。

図7-43 インバウンド操作用のキューの選択

16. 「OK」をクリックします。
図7-44 に示すように、すべてのフィールドに移入済の「キュー名」ダイアログが表示されます。

図7-44 「キュー名」ページ

17. 「Next」をクリックします。
「キュー・パラメータ」ページが表示されます。

18. 「キュー・パラメータ」ページで、各フィールドを空白にしたままで「次へ」をクリックします。
「オブジェクト・ペイロード」ページが表示されます。

19. 「ビジネス・ペイロード」で、オブジェクト全体またはオブジェクト内の1つのフィールドのみのいずれかを選択します。
この例では「オブジェクトCUSTOMER_TYPE全体」を選択します。

20. 「Next」をクリックします。
「終了」画面が表示されます。このページには、ウィザードにより作成されるアダプタ・ファイルのパスと名前が表示されます。

21. 「終了」をクリックします。
インバウンドOracle AQアダプタの定義が完了しました

7.4.2.4 アウトバウンドOracle AQアダプタの作成

次の手順に従ってアウトバウンド・サービスを作成します。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「コンポーネント」ウィンドウの「サービス・アダプタ」リストから、「AQアダプタ」をcomposite.xmlページ内の「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。
「アダプタ構成ウィザード」が表示されます。

3. 「Next」をクリックします。
「サービス名」ページが表示されます。

4. 「サービス名」フィールドにenqueueと入力し、「次へ」をクリックします。
「サービス接続」ページが表示されます。

5. 「接続」で、「MyConnection」を選択して「次へ」をクリックします。
「アダプタ・インタフェース」ページが表示されます。

6. 「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。
「操作」ページが表示されます。

7. 「操作」ページで、「エンキュー」を選択してデフォルトの操作名を受け入れます。

8. 「Next」をクリックします。
「キュー名」ページが表示されます。

9. 「キュー名」ページで、リストからデータベース・スキーマを選択するか、「参照」をクリックしてスキーマを参照します。この例では、「参照」をクリックします。
「キューの選択」ダイアログが表示されます。

10. 「キューの選択」ダイアログで、次の手順を実行します。

a. 「キュー・タイプ」で「すべてのタイプ」を選択します。

b. 「データベース・スキーマ」で「Scott」を選択します。

c. 他の設定はデフォルト値のままにします。

d. 図7-45 に示すように、「キュー」で「CUSTOMER_OUT_QUEUE」を選択します。

図7-45 アウトバウンド操作用のキューの選択

11. 「OK」をクリックします。
図7-46 に示すように、すべてのフィールドに移入済の「キュー名」ページが表示されます。

図7-46 「キュー名」ページ

12. 「Next」をクリックします。
「キュー・パラメータ」ページが表示されます。

13. 「キュー・パラメータ」ページで、各フィールドを空白にしたままで「次へ」をクリックします。
「オブジェクト・ペイロード」ページが表示されます。

14. 「ビジネス・ペイロード」で、オブジェクト全体またはオブジェクト内の1つのフィールドのみのいずれかを選択します。この例では「オブジェクトCUSTOMER_TYPE全体」を選択します。

15. 「Next」をクリックします。
「終了」画面が表示されます。このページには、ウィザードにより作成されるアダプタ・ファイルのパスと名前が表示されます。

16. 「終了」ウィンドウで「終了」をクリックします。
アウトバウンドの定義が完了しました。

7.4.2.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、メディエータ・コンポーネントおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるインバウンド・アダプタ内の小さい三角形を、「コンポーネント」領域のメディエータ・コンポーネント内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるメディエータ・コンポーネント内の小さい三角形を、「外部参照」領域のアウトバウンド・アダプタ内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図7-47 のように表示されます。

図7-47 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

7.4.2.6 ルーティング・サービスの構成

次の手順に従ってルーティング・サービスを構成します。

1. 「Mediator1」をダブルクリックします。

「Mediator1.mplan」ウィンドウが表示されます。

2. 「次を使用して変換」フィールドの端に表示される「既存のマッパー・ファイルを選択するか、新規マッパー・ファイルを作成します。」アイコンをクリックします。

図7-48 に示すように、「リクエスト・トランスフォーメーション・マップ」ダイアログが表示されます。

図7-48 「リクエスト・トランスフォーメーション・マップ」ダイアログ

3. 「新規マッパー・ファイルの作成」を選択して「OK」をクリックします。

図7-49 に示すように、「トランスフォーメーション」ウィンドウが表示されます。

図7-49 「トランスフォーメーション」ウィンドウ

4. マッパーの左側でソース・ルート要素を選択し、右側の宛先ルート要素へドラッグしてマップ・プリファレンスを設定します。

図7-50 に示すように、「自動マップ・プリファレンス」ダイアログが表示されます。

図7-50 「自動マップ・プリファレンス」ダイアログ

5. 「OK」をクリックします。

「アプリケーション」ウィンドウの中央ペインは、図7-51 のようになります。

図7-51 マップ・プリファレンス設定後の「アプリケーション」ウィンドウ

6. マッパーの設定を保存してタブを閉じます。

7. ルーティング・サービスの設定を保存してタブを閉じます。

7.4.2.7 Oracle WebLogic Server管理コンソールでのデータソースの構成

1. http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

図7-52 に示すように、Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

図7-52 Oracle WebLogic Server管理コンソールのホーム・ページ

3. 「ドメイン構造」で、「サービス」、「JDBC」を選択し、「データ・ソース」をクリックします。

図7-53 に示すように、「JDBCデータ・ソースの概要」ページが表示されます。

図7-53 「JDBCデータ・ソースの概要」ページ

4. 「新規」をクリックします。「新しいJDBCデータ・ソースの作成」ページが表示されます。

5. 図7-54 に示すように、新しいJDBCデータソースの識別に使用するプロパティの値を入力します。

図7-54 「新しいJDBCデータ・ソースの作成」ページ

6. 「次」を選択します。図7-55 に示すように、「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページが表示されます。

図7-55 「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページ

7. 「次」を選択します。図7-56 に示すように、「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページが表示されます。

図7-56 「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページ

8. 「接続プロパティ」ページで接続プロパティを入力します。

9. 「次」を選択します。図7-57 に示すように、「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページが表示されます。

図7-57 「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページ

10. 「構成のテスト」をクリックし、データベースの可用性および指定した接続プロパティをテストします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページの上部に接続テストに成功したことを示すメッセージが表示されます。

11. 「次」を選択します。図7-58 に示すように、「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページ」ページが表示されます。

図7-58 「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページ

12. ターゲットを選択して「終了」をクリックします。

図7-59 に示すように、「JDBCデータ・ソースの概要」ページが表示されます。このページは、このドメインで作成されたJDBCデータ・ソース・オブジェクトについて要約しています。このリストには、作成したデータソースが表示されます。

図7-59 「JDBCデータ・ソースの概要」ページ

13. Oracle WebLogic Server管理コンソールを閉じます。

7.4.2.8 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする手順は、次のとおりです。

1. 「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」に示す手順を使用して、アプリケーション・サーバー接続を作成します。

2. 「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

7.4.2.9 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. 「最後の5つのインスタンス」ペインに、新規インスタンスのエントリがあります。この新規インスタンスは、メッセージをエンキューするときにトリガーされたインスタンスです。

3. インスタンスをクリックします。「フローのトレース」ページが表示されます。

4. 「Mediator1」コンポーネント・インスタンスをクリックします。「監査」ページが表示されます。

5. 「フロー - デバッグ」タブをクリックしてインスタンスをデバッグします。

7.4.3 Oracle AQアダプタのRAWキュー

この使用例では、Oracle AQアダプタを使用してAQ RAWキューとの間のデキューとエンキューを実行する方法について説明します。

この項には次のトピックが含まれます:

- 前提条件

- アプリケーションおよびSOAプロジェクトの作成

- インバウンド・アダプタ・サービスの作成

- アウトバウンド・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Oracle WebLogic Server管理コンソールでのデータソースの構成

- Fusion Middleware Controlコンソールを使用した監視

7.4.3.1 前提条件

SCOTTスキーマを持つデータベースへのアクセス権限が必要です。

この使用例を実行するには、adapters-aq-101-rawサンプルに含まれているartifacts.zipファイルの次のSQLファイルが必要です。これらのファイルは、artifacts.zipファイルのartifacts/sqlサブディレクトリにあります。次に示す順序でSQLファイルを実行します。

- setup_user.sql

- create_queues.sql

- enqueue_raw.sql

- dequeue_raw.sql

- artifacts/schemas/emp.xsd

adapters-aq-101-rawサンプル・コードに含まれているartifacts.zipを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

adapters-aq-101-rawサンプル・コードを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

7.4.3.2 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。アプリケーションとSOAプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperを開きます。

2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。

「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

3. 「アプリケーション名」フィールドにRawqueueと入力します。

4. 「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。

5. 「次へ」をクリックします。

「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

6. 「プロジェクト名」フィールドにわかりやすい名前(Rawなど)を入力します。

7. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

8. 「次へ」をクリックします。

「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

9. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して、「終了」をクリックします。

新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

「BPELプロセスの作成」ページが表示されます。

10. 「名前」フィールドにBPELプロセスの名前を入力します。たとえば、BPELRawqueueのように指定します。

11. 「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。

RawqueueアプリケーションとRawプロジェクトが設計領域に表示されます。

12. emp.xsdファイルをプロジェクトのXSDフォルダにコピーします(このファイルの場所の詳細は、「前提条件」を参照)。

7.4.3.3 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューにデキューするインバウンドOracle AQアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「コンポーネント」ウィンドウの「サービス・アダプタ」リストから、「AQアダプタ」をcomposite.xmlページ内の「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。

「アダプタ構成ウィザード」が表示されます。

3. 「次へ」をクリックします。

「サービス名」ページが表示されます。

4. 「サービス名」フィールドにRaw-Dequeuerと入力し、「次へ」をクリックします。

「サービス接続」ページが表示されます。

5. 「サービスの定義」のステップ6の説明に従ってデータベース接続を作成します。

6. 「次へ」をクリックします。

「アダプタ・インタフェース」ページが表示されます。

7. 「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。

「操作」ページが表示されます。

8. 図7-60 に示すように、「操作」ページで「デキュー」を選択します。

9. デフォルトの操作名を受け入れて「次へ」をクリックします。

「キュー名」ページが表示されます。

図7-60 「アダプタ構成ウィザード - 操作」ページ

10. 図7-61 に示すように、データベース・スキーマとしてSCOTTを選択し、キュー名としてRAW_IN_QUEUEを選択します。

図7-61 「アダプタ構成ウィザード - キュー名」ページ

11. 「次へ」をクリックします。

「キュー・パラメータ」ページが表示されます。

12. 相関IDとデキュー条件を入力し、「次へ」をクリックします。

「メッセージ」ページが表示されます。

13. 「URL」フィールドの端にある「参照」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

14. 図7-62 に示すように、「プロジェクトのスキーマ・ファイル」、「emp.xsd」および「AQRaw_End2End」を順番に選択します。

図7-62 「タイプ・チューザ」ダイアログ

15. 「OK」をクリックします。

図7-63 に示すように、「メッセージ」ダイアログの「URL」フィールドにemp.xsdスキーマ・ファイルが表示されます。

図7-63 「アダプタ構成ウィザード - メッセージ」ページ

16. 「次」を選択します。「終了」ページが表示されます。

17. 「終了」をクリックします。Oracle AQアダプタ・サービスの構成が完了し、図7-64 に示すように「composite.xml」ページが表示されます。

図7-64 JDeveloperウィンドウ: 「composite.xml」ページ

7.4.3.4 アウトバウンド・アダプタ・サービスの作成

リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウの「サービス・アダプタ」リストから、「AQアダプタ」をcomposite.xmlページ内の「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにRaw-Enqueuerと入力して「OK」をクリックします。

「サービス接続」ページが表示されます。

4. 「XAデータ・ソース」を選択して「次へ」をクリックします。

「操作」ページが表示されます。

5. 「エンキュー」を選択します。

6. デフォルトの操作名を受け入れて「次へ」をクリックします。

「キュー名」ページが表示されます。

7. 図7-65 に示すように、「データベース・スキーマ」としてSCOTTを選択し、「キュー名」としてRAW_OUT_QUEUEを選択します。

図7-65 「アダプタ構成ウィザード - キュー名」ページ

8. 「次へ」をクリックします。

「キュー・パラメータ」ページが表示されます。

9. 相関IDを入力して「次へ」をクリックします。

「メッセージ」ページが表示されます。

10. 「URL」フィールドの端にある「スキーマ・ファイルを参照」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

11. 図7-62 に示すように、「プロジェクトのスキーマ・ファイル」、「emp.xsd」および「AQRaw_End2End」を順番に選択します。

12. 「次へ」をクリックします。

図7-63 に示すように、「メッセージ」ダイアログの「URL」フィールドにemp.xsdスキーマ・ファイルが表示されます。

13. 「次へ」をクリックします。

「終了」ページが表示されます。

14. 「終了」をクリックします。

サービスの構成が完了し、図7-66に示すように、「composite.xml」ページが表示されます。

図7-66 JDeveloperウィンドウ: 「composite.xml」ページ

7.4.3.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるRaw-Dequeuer内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のRaw-Enqueuer内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

同様に、「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundService内のドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlファイルが図7-67 のように表示されます。

図7-67 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4. 「BPELRawqueue」をダブルクリックします。

「BPELRawqueue.bpel」ページが表示されます。

5. 「コンポーネント」ウィンドウから、receive、assignおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。

図7-68 に示すように、JDeveloperの「BPELRawqueue.bpel」ページが表示されます。

図7-68 「BPELRawqueue.bpel」ページ

6. receiveアクティビティをダブルクリックします。

「Receive」ダイアログが表示されます。

7. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。

「パートナ・リンク・チューザ」ダイアログが表示されます。

8. 「Raw-Dequeuer」を選択して「OK」をクリックします。

「パートナ・リンク」フィールドに値Raw-Dequeuerが移入された状態で「Receive」ダイアログが表示されます。

9. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。

「変数の作成」ダイアログが表示されます。

10. デフォルト値を受け入れて「OK」をクリックします。

11. 図7-69 に示すように、「インスタンスの作成」ボックスを選択して「OK」をクリックします。

図7-69 「Receive」ダイアログ

12. invokeアクティビティをダブルクリックします。

「Invoke」ダイアログが表示されます。

13. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。

「パートナ・リンク・チューザ」ダイアログが表示されます。

14. 「Raw-Enqueuer」を選択して「OK」をクリックします。

「パートナ・リンク」フィールドに値Raw-Enqueuerが移入された状態で「Invoke」ダイアログが表示されます。

15. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。

16. デフォルト値を受け入れて「OK」をクリックします。

図7-70 に示すように、「Invoke」ダイアログが表示されます。

図7-70 「Invoke」ダイアログ

17. 「OK」をクリックします。

18. assignアクティビティをダブルクリックします。

「Assign」ダイアログが表示されます。

19. 「+」アイコンをクリックして「コピー操作」を選択します。

「コピー操作の作成」ダイアログが表示されます。

20. 図7-71 に示すように、変数を選択して「OK」をクリックします。

図7-71 「コピー操作の作成」ダイアログ

21. 「Assign」ダイアログで「OK」をクリックします。

図7-72 に示すように、JDeveloperの「BPELRawqueue.bpel」ページが表示されます。

図7-72 「BPELRawqueue.bpel」ページ

22. 「ファイル」、「すべて保存」を順番にクリックします。

7.4.3.6 Oracle WebLogic Server管理コンソールでのデータソースの構成

1. http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

3. ホーム・ページの「ドメイン構造」で、「サービス」、「JDBC」を選択し、「データ・ソース」をクリックします。

「JDBCデータ・ソースのサマリー」ページが表示されます。

4. 「新規」をクリックします。「新しいJDBCデータ・ソースの作成」ページが表示されます。

5. 新しいJDBCデータ・ソースを識別するのに使用するプロパティ値を入力します。

6. 「次」を選択します。「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページが表示されます。

7. 「次」を選択します。「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページが表示されます。

8. 「接続プロパティ」ページで接続プロパティを入力します。

9. 「次」を選択します。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページが表示されます。

10. 「構成のテスト」をクリックし、データベースの可用性および指定した接続プロパティをテストします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページの上部に接続テストに成功したことを示すメッセージが表示されます。

11. 「次」を選択します。「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページが表示されます。

12. ターゲットを選択して「終了」をクリックします。

「JDBCデータ・ソースのサマリー」ページが表示されます。このページは、このドメインで作成されたJDBCデータ・ソース・オブジェクトについて要約しています。このリストには、作成したデータソースが表示されます。

13. Oracle WebLogic Server管理コンソールを閉じます。

7.4.3.7 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. 「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」に示す手順を使用して、アプリケーション・サーバー接続を作成します。

2. 「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

7.4.3.8 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。

デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. 「最後の5つのインスタンス」ペインに、新規インスタンスのエントリがあります。

これは、メッセージをエンキューするときにトリガーされたインスタンスです。

3. インスタンスをクリックします。

「フローのトレース」ページが表示されます。

4. 「BPELRawqueue」コンポーネント・インスタンスをクリックします。

「監査」ページが表示されます。

5. 「フロー - デバッグ」タブをクリックしてインスタンスをデバッグします。

8 Oracle JCA Adapter for JMS

この章では、Oracle BPELプロセスまたはOracle MediatorコンポーネントとJava Messaging Service間の通信を可能にする、Oracle JCA Adapter for JMS (Oracle JMSアダプタ)の使用方法について説明します。

この章の内容は次のとおりです。

- Oracle JMSアダプタの概要

- Oracle JCA Adapter for JMSの機能

- Oracle JMSアダプタの概念

- Oracle JMSアダプタの使用例

8.1 Oracle JMSアダプタの概要

JMSアーキテクチャでは、多数のメッセージ・サーバーに対して1つのクライアント・インタフェースが使用されます。JMSモデルには、Point-to-Pointおよびパブリッシュ・サブスクライブという2つのメッセージ・ドメインがあります。Point-to-Pointドメインでは、メッセージはキューを介して交換され、各メッセージは1人の受信者にのみ配信されます。パブリッシュ・サブスクライブ・モデルでは、メッセージはトピックに送信され、複数のサブスクライブ・クライアントによって読み取られます。

JMSアダプタ・サンプル・ファイルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

この項には次のトピックが含まれます:

- Oracle BPEL Process Managerとの統合

- Oracle JMSアダプタとOracle Mediatorの統合

8.1.1 Oracle BPEL Process Managerとの統合

JCA 1.5リソース・アダプタとBPEL Process Managerを双方向で統合するために、JCAバインディング・コンポーネントが使用されています。JCAバインディング・コンポーネントは規格に準拠しており、基盤となるJCA相互作用をWebサービスとして公開するためのWeb Service Invocation Framework (WSIF)テクノロジが使用されています。

Oracle JMSアダプタのアーキテクチャ、アダプタとOracle BPEL Process Manager (Oracle BPEL PM)の統合およびアダプタのデプロイの詳細は、「アダプタとOracle Application Serverコンポーネントの統合」を参照してください。

8.1.2 Oracle JMSアダプタとOracle Mediatorの統合

Oracle JCAアダプタをサポートしており、それぞれのインバウンドおよびアウトバウンドのアダプタ・サービスを定義できます。インバウンド・アダプタ・サービスでは、外部メッセージ・システムからデータが受信されてXMLメッセージに変換されます。アウトバウンド・アダプタ・サービスでは、XMLメッセージが特定のアダプタのネイティブ・フォーマットに変換され、データがターゲット・アプリケーションに送信されます。

サービスの場合、使用してJMSキューまたはトピックからのメッセージを送受信できます。

Oracle BPEL PMの後継であり、このガイドのほとんどの部分およびサンプルはOracle BPEL PMを使用することを想定しています。ただし、アダプタの動作はOracle BPEL PMでも同じです。この章でOracle BPEL PMに言及している箇所は、置き換えてかまいません。

8.2 Oracle JMSアダプタの機能

Oracle JMSアダプタには次の特徴があります。

- JMSバージョン1.0.2bがベース

- 汎用Oracle JMSアダプタ
任意のJMSプロバイダで機能します。ただし、Oracle JMSアダプタの場合、AQ JMS (JMSプロバイダOJMS 8.1.7、9.0.1.4および9.2)、TIBCO JMS、IBM WebSphere MQSeries (IBM MQSeries JMS 6.0)、Weblogic JMS、ApacheおよびActive MQで動作確認されています。その他のプロバイダの動作保証についての追加情報は、Oracleサポートに問い合せてください。

- JMSトピックおよびキューをサポートしています。

- バイト、テキストおよびマップ・メッセージ・タイプをサポートしています。
これらのデータ・タイプは、このリリースでのみサポートされています。アダプタ構成ウィザードにより、実行時のネイティブ・データ・ペイロードの消費にネイティブ・フォーマット・ビルダー・ウィザードが提供されます。ネイティブ・フォーマット・ビルダー・ウィザードでは、基礎となるネイティブ・データのXSD定義が作成されます。

- JMSヘッダーおよびプロパティをサポートしています。

- WebLogic Serverの順序単位機能をサポートしています。
WebLogic Serverの順序単位機能では、JMSメッセージ・プロデューサや単体として動作するメッセージ・プロデューサのグループが、複数のメッセージを1つの単位にグループ化してメッセージを作成順に処理することが可能になります。単一のメッセージのメッセージ処理は、メッセージが確認応答、コミット、回復またはロールバックされたときに完了します。メッセージのメッセージ処理が完了するまでは、その順序単位の残りの未処理メッセージがブロックされます。

この拡張により、SOA JMSアダプタでWebLogic Serverの順序単位サポートが有効化されます。SOA JMSアダプタを介して生成されたメッセージによって、ユーザーは特定の順序単位を指定できるようになります。

- jca.message.encodingプロパティをサポートしています。
Oracle JMSアダプタでは、インバウンド・ペイロードとアウトバウンド・ペイロードのjca.message.encodingプロパティがサポートされます。jca.message.encodingプロパティがadapter.jms.encodingプロパティおよびnxsd:encoding属性とともに使用される場合、jca.message.encodingプロパティはadapter.jms.encodingプロパティよりも優先され、nxsd:encoding属性の優先度は最も低くなります。nxsd:encoding値にはUTF-8が指定可能で、通常は相互運用性とUnicodeサポートのためにこれをお薦めします。ただし、Java Runtime Environmentでサポートされている任意の有効なエンコーディングを指定できます。サポートされているエンコーディングの完全なリストは、http://docs.oracle.com/javase/7/docs/technotes/guides/intl/encoding.doc.htmlを参照してください。エンコーディングは、アダプタ・プロキシ・メタデータに関連付けられた(N)XSDで指定できます。たとえば、nxsd:encoding="iso-8859-1"のように属性を指定できます。

jca.message.encodingプロパティは、composite.xmlで定義されたエンドポイントとしてサポートされています。このプロパティは、アダプタ構成ウィザードの「プロパティ」タブを使用するか、composite.xmlファイルを編集して定義できます。jca.message.encodingプロパティは、インバウンド相互作用とアウトバウンド相互作用の両方で正規化されたメッセージ・プロパティとして渡すことができます。

次のコード・スニペットは、インバウンド・サービスに関するメッセージ・エンコーディングについてcomposite.xmlファイルに値を設定する一例です。

<service name="jms_inbound" ui:wsdlLocation="jms_inbound.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel/adapter
/jms/utf8/jcamessageencoding/
jms_inbound#wsdl.interface(Consume_Message_ptt)"/>
<binding.jca config="jms_inbound_jms.jca">
<property name="jca.message.encoding"
type="xs:string" many="false"
override="may">GBK</property>
</binding.jca>
</service>

次のコード・スニペットは、アウトバウンド・サービスに関するメッセージ・エンコーディングについてcomposite.xmlファイルに値を設定する一例です。

<reference name="jms_outbound" ui:wsdlLocation=
“jms_outbound.wsdl">
<interface.wsdl
interface="http://xmlns.oracle.com/pcbpel/adapter/jms/utf8/jcamessageencoding/
jms_outbound#wsdl.interface(Produce_Message_ptt)"/>
<binding.jca config="jms_outbound_jms.jca">
<property name="jca.message.encoding" type="xs:string" many="false"
override="may">GBK</property>
</binding.jca>
</reference>

- JMSメッセージ・セレクタのサポート
JMSトピックおよびキューへのサブスクライブ中のフィルタ処理の実行用にJMSメッセージ・セレクタをサポートしています。このパラメータは、JMSヘッダーおよびプロパティのセクションに存在するフィールドに基づくメッセージをフィルタ処理するためのSQL 92言語に基づいています。

- DOM2準拠
Oracle JMSアダプタでは、DOM2仕様に準拠するドキュメント・オブジェクトを処理および生成できます。

- 正規化されたメッセージのサポート。
ヘッダーの操作と伝播は、重要なビジネス統合メッセージング要件です。Oracle BPEL PM、メディエータ、Oracle JCAおよびOracle B2Bでは、顧客の統合要件を解決する場合にヘッダー・サポートに広範に依存しています。たとえば、メッセージ・ヘッダーを介して伝播させることで、ファイル名をソース・ディレクトリからターゲット・ディレクトリに保存できます。また、アウトバウンドOracle JMSアダプタでは、correlationIdおよびJMSReplyToのアドレスをJMSヘッダーとして伝播することで、非同期リクエスト/レスポンスが容易になります。Oracle BPEL Process ManagerとMediatorでは、様々なUIサポート・レベルでヘッダーにアクセスし、操作して設定できます。

詳細は、「アダプタ内での相関サポート」を参照してください。

正規化されたメッセージのヘッダーの伝播

正規化されたメッセージは、プロパティとペイロードという2つの部分のみを持つように簡素化されています。通常、プロパティはスカラー型の名前/値ペアです。既存の複雑なヘッダーがプロパティに収まるように、プロパティはスカラー型にフラット化されます。

設計時のヘッダーの操作

複雑なプロパティは事前に決定されているため、設計時にヘッダーを操作する際のユーザー操作は合理化されています。メディエータまたはOracle BPELデザイナでは、なんらかの予約済キーワードを使用してヘッダーを操作できます。たとえば、現在、メディエータ・デザイナでは、次の式を使用してインバウンドOracleファイル・アダプタのfileNameヘッダーにアクセスできます。

$nmproperty.InboundFileHeaderType.fileName

ただし、この方法はユーザー入力に基づいて動的に生成されるプロパティに対処していません。たとえば、Oracle AQアダプタ・ウィザードでは、AQオブジェクトからの一部のフィールドをヘッダーとして伝播できます。この選択内容に基づいてヘッダー定義が生成されます。これらの定義はあらかじめ決まらないため、あらかじめ決められたプロパティ定義のリストでは対応できません。動的プロパティのヘッダー操作は、定義するまで設計できません。この制限に対応するには、必要なすべてのサービス(コンポジット・エントリ・ポイント)と参照を生成する必要があります。この制限は、動的プロパティを生成する必要のあるサービスにのみ適用されます。動的プロパティが生成された後、コンポジットごとに特定の場所で取得される必要があります。その後にのみ、Oracle MediatorまたはOracle BPELデザイナで動的プロパティを操作できます。

- 永続JMSサブスクライバの指定をサポートしています。

- JMSパブリッシャの永続および非永続モードをサポートしています。

- SolarisでのAQJMSに対するアウトバウンド再試行機能はサポート対象外

注意:

Oracle JMSアダプタを使用してAQ-JMSプロバイダに接続する際に、AQの宛先をホストするデータベースが10.1.0.4の場合、データベース・サーバーが停止すると、アウトバウンド方向のアダプタ再試行メカニズムはデータベース・サーバーへの再接続に失敗します。これは、クライアントJDBCとojdbc14.jarとの問題によるものです。これを解決するには、10.1.0.4のJDBCドライバをダウンロードし、$MIDTIER_ORACLE_HOME/jdbcにあるライブラリ(特にojdbc14.jar)を置き換えて、中間層で使用する必要があります。この問題の解決方法の詳細は、MetaLink Note 317385.1を参照してください。

- JMS APIでは、JMSパブリッシャによって送信される3つの確認情報を指定します。

- DUPS_OK_ACKNOWLEDGE: メッセージの重複に関連のないコンシューマ用

- AUTO_ACKNOWLEDGE: セッションがメッセージの受信を自動的に確認

- CLIENT_ACKNOWLEDGE: クライアントがメッセージの確認メソッドを呼び出してメッセージを確認

- メッセージ・サイズの追跡のサポート
Oracle JMSアダプタはメッセージ・サイズ対応です。Oracle JMSアダプタではメッセージ・サイズが計算され、JCAバインディング・コンポーネントにレポートされます。JCAバインディング・コンポーネントにより公開されるサイズ関連APIは、レポート処理に使用できます。

- JMSアダプタのMapMessageデータ型でのMapMessageサポートの構成
MapMessageは、名前/値ペアを送信するために使用されます。名前は文字列で、値はJavaプリミティブ型です。このエントリには、名前を指定して順次的またはランダムにアクセスできます。エントリの順序は定義されません。これはメッセージから継承し、マップ・メッセージ本文を追加します。

Oracle JMSアダプタでは、MapMessageの処理がサポートされます。現在では、JmsMapMessageConsumeActivationSpecおよびJmsMapMessageProduceInteractionSpecという新しいActivationSpecおよびInteractionSpecプロパティがサポートされています。

次の使用例がサポートされています。

- 使用例1。JMS MapMessageオブジェクト全体がペイロードとして処理されます。
PayloadEntryプロパティとAttachmentListプロパティが両方とも定義されていない場合は、JMS MapMessage全体がXMLに変換され、そのXMLファイルがペイロードとして転送されます。この使用例の場合、PayloadEntryプロパティとAttachmentListプロパティは両方ともオプションです。変換には、次のスキーマが使用されます。

<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/jms/MapMessage"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/jms/MapMessage"
elementFormDefault="qualified">
<element name="MapMessage">
<complexType>
<choice maxOccurs="unbounded">
<element name="entry">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="name" type="string"/>
<attribute name="dt" type="string"/>
</extension>
</simpleContent>
</complexType>
</element>
</choice>
</complexType>
</element>
</schema>

属性nameは、JMS MapMessageエントリの名前/値ペアの名前部分です。

属性dtには、次のいずれか1つの文字列値を指定できます。

- Boolean

- Byte

- Short

- Integer

- Long

- Float

- Double

- 文字列

- Char

- ByteArray

- 使用例2。MapMessageエントリ(名前/値ペア)がペイロードとして処理されます。

PayloadEntryプロパティでは、ペイロードとして使用されるJMS MapMessageエントリ名(処理される必要がある名前/値ペアを参照)を指定します。PayloadEntryではなくAttachmentListプロパティが定義されている場合は、ペイロードを添付として送信することもできます。この使用例の場合、PayloadEntryプロパティまたはAttachmentListプロパティのいずれかを指定する必要がありますが、両方は指定しないでください。

他のすべてのMapMessageエントリは、jca.jms.Map.xxxxにより識別されるアダプタ・プロパティに変換されます。xxxxは、JMS MapMessageエントリの名前です(名前/値ペア)。

JMS MapMessageサンプルは、「開発者および管理者のサンプル・コード」ページから「ミドルウェアおよびツール」の下にある最新のSOAサンプル・コードにアクセスして、次のサンプルを参照します: adapters-jms-104-wlsjms-mapmessage。

- エンタープライズ情報システム(EIS)の資格証明のサポート
Oracle JMSアダプタでは、EISとのアウトバウンド接続の確立時の、エンタープライズ情報システム(EIS)の資格証明(ユーザー名やパスワードなど)の保護がサポートされています。Oracle JMSアダプタのユーザー名とパスワードは、Oracle WebLogic Serverのコンテナ管理のサインオンを使用して保護できます。

エンタープライズ情報システム(EIS)の資格証明の保護のサポートの詳細は、「エンタープライズ情報システムの資格証明の保護」を参照してください。

- 大きなペイロードのストリーミングのサポート

Oracle JMSアダプタには、ストリーム・ペイロードのサポートが用意されています。この機能を有効化すると、ペイロードはメモリーDOM内のSOAランタイムで操作されるかわりにデータベースにストリーミングされます。この機能は、大きなペイロードの処理中に使用できます。ストリーム・ペイロードのサポートを有効化するには、Oracle JDeveloperの「消費操作のパラメータ」ページで消費操作のパラメータを定義する際に必ず「ストリーミングの有効化」チェック・ボックスを選択します。「ストリーミングの有効化」チェック・ボックスを選択すると、次の例に示すように、対応するブール・プロパティEnableStreamingがそれぞれの.jcaファイルに定義されているActivationSpecプロパティに追加されます。EnableStreamingプロパティが存在しない場合は、デフォルト値のfalseとみなされます。

<activation-spec className="oracle.tip.adapter.jms.inbound.
JmsConsumeActivationSpec">
<property name="DestinationName" value="jms/DemoInQueue"/>
<property name="UseMessageListener" value="false"/>
<property name="PayloadType" value="TextMessage"/>
<property name="EnableStreaming" value="true"/>
</activation-spec>

- トランザクションのサポート
送信または受信されたメッセージを1つの単位として扱うことで、アプリケーションは、1つのトランザクションで発行および消費のメッセージのグループを調整できます。アプリケーションがトランザクションをコミットすると、そのトランザクション内で受信したすべてのメッセージが、JMSプロバイダにより削除されます。そのトランザクション内で送信したメッセージは、1つの単位としてすべてのJMSコンシューマに配信されます。アプリケーションがトランザクションをロールバックすると、そのトランザクション内で受信したメッセージはメッセージ・システムに戻され、送信したメッセージは破棄されます。Oracle JMSアダプタはJMSトランザクションをサポートします。JMSで処理されたセッションは、そのセッション内に配置されたトランザクションをサポートします。JMSで処理されたセッションのトランザクションは、そのセッション以外には影響しません。

- エラー処理のサポート
エラー処理については、「エラー処理」を参照してください。

- 複数のコンシューマ・スレッドのサポート
Oracle JMSアダプタは、アクティブ化エンドポイント・プロパティadapter.jms.receive.threadsをサポートしています。アダプタとエンタープライズ情報システム(EIS)間のインバウンド・メッセージ・フロー用として複数のポーラー・スレッドを生成するには、composite.xmlでこのプロパティを設定することをお薦めします。これにより、複数のポーラー・スレッドがラウンド・ロビン形式でメッセージをデキューするため、パフォーマンスが向上します。これは、分散シナリオでもサポートされています。

- パフォーマンス・チューニングのサポート
Oracle JMSアダプタはパフォーマンス・チューニングをサポートしています。詳細は、「Oracle JCAアダプタ・チューニング・ガイド」および「Oracle JCAアダプタのプロパティ」を参照してください。

注意:

Oracle JMSアダプタをEJBまたはJMSクライアントのプログラムで使用することはできません。

8.3 Oracle JMSアダプタの概念

メッセージ機能はプログラム間の通信を可能にするメカニズムです。メッセージは、あるアプリケーションが別のアプリケーションに送信する構造化データです。メッセージ指向ミドルウェア(MOM)は、スケーラブルなエンタープライズ・メッセージング機能をサポートするインフラストラクチャです。MOMにより、高速で信頼できる非同期の通信、保証付きメッセージ配信、受信通知およびトランザクション制御が実現されます。

JMSは、エンタープライズ・メッセージング・システムのメッセージの発行、送信および受信を目的として開発されたSun Javaインタフェースです。JMSはJMSベンダーが実装するAPIです。オラクル社では、WLS JMSとOracleアドバンスト・キューに基づいたOracle JMSの2つのJMS実装を提供しています。JMSプロデューサによりJMSメッセージが作成され、JMSコンシューマによってJMSメッセージが消費されます。

JMSでは、Point-to-Point(キュー)およびパブリッシュ・サブスクライブ(トピック)という2つのメッセージ・パラダイムをサポートしています。

この項には次のトピックが含まれます:

- Point-to-Point

- パブリッシュ/サブスクライブ

- 宛先、接続、コネクション・ファクトリおよびセッション

- JMSメッセージの構造

- Oracle JMSアダプタのヘッダー・プロパティ

8.3.1 Point-to-Point

Point-to-Pointメッセージでは、メッセージは消費されるまでキューに格納されます。1つ以上のプロデューサがキューに書き込み、1つ以上のコンシューマがキューからメッセージを抽出します。JMSコンシューマにより、メッセージの消費後に確認情報が送信されるため、キューからメッセージがパージされます。

8.3.2 パブリッシュ/サブスクライブ

パブリッシュ・サブスクライブ・メッセージでは、プロデューサがメッセージをトピックにパブリッシュし、コンシューマが特定のトピックにサブスクライブします。複数のパブリッシャが同じトピックを公開でき、複数のコンシューマが同じトピックにサブスクライブできます。プロデューサによってトピックに公開されたすべてのメッセージは、そのトピックにサブスクライブしたすべてのコンシューマによって受信されます。デフォルトでは、サブスクライバがメッセージを受信できるのはアクティブなときのみです。ただし、JMS APIでは、サブスクライバが稼働中ではなくても、パブリッシュされたメッセージをコンシューマが受信できる永続サブスクリプションをサポートしています。永続サブスクリプションでは、コンシューマがアクティブではないときに送信されたメッセージを受信するために、コンシューマを一意のIDで登録します。これらのメッセージはJMSプロバイダにより保存され、コンシューマが再度アクティブになった際に送信されるか、メッセージが失効した場合には記憶域からパージされます。JMSプロデューサは、永続モードまたは非永続モードに設定できます。非永続モードではメッセージは保存されず、非永続サブスクリプションにのみ使用できます。

Oracle WebLogic Serverで永続サブスクリプションの操作を必要とするシナリオでは、次の例に示すように、ClientIDプロパティを定義済のコネクタ・ファクトリが必要です。

<FactoryProperties>ClientID=uniquename</FactoryProperties>

複数の永続サブスクライバを定義する際には、それぞれ一意のClientIDプロパティを指定して複数のコネクタ・ファクトリを定義する必要があります。Oracle WebLogic Serverではclientidのバインドが1回しか許可されないため、他のアダプタ相互作用(インバウンド・メッセージの処理に使用する場合のアウトバウンド相互作用など)には同じコネクタ・ファクトリを使用しないように注意してください。ClientIdを定義済のコネクタ・ファクトリをインバウンドで使用して着信メッセージを処理するシナリオの場合、アウトバウンド・アダプタ相互作用には異なるコネクタ・ファクトリを使用する必要があります。

注意:

BPELパートナ・リンクで使用されない永続サブスクライバは、手動で削除する必要があります。これらの永続サブスクリプションは自動的に削除されません。

JMS APIでは、メッセージ消費のための同期および非同期通信の両方をサポートしています。同期の場合、コンシューマはトピックまたはキューのreceive()メソッドを明示的に呼び出します。非同期の場合、JMSクライアントによりトピックまたはキューにメッセージ・リスナーが登録され、メッセージはそのリスナーのonMessage()メソッドを呼び出すことで配信されます。

8.3.3 宛先、接続、コネクション・ファクトリおよびセッション

宛先プロパティには、JMSキューまたはトピックのアドレス情報が含まれます。接続は、JMSプロバイダへの物理接続を表します。コネクション・ファクトリは、JMS接続の作成に使用されます。セッションは、キューまたはトピックの宛先、JMSプロデューサ、およびJMSコンシューマのオブジェクトの作成に使用されます。

8.3.4 JMSメッセージの構造

JMSメッセージには、必須の標準ヘッダー要素、オプションのプロパティ要素およびオプションの標準ペイロード要素があります。ペイロードはテキスト・メッセージ、バイト・メッセージ、マップ・メッセージ、ストリーム・メッセージまたはオブジェクト・メッセージのいずれかになります。プロパティ要素はJMSプロバイダ固有で、JMSプロバイダごとに異なります。

8.3.5 Oracle JMSアダプタのヘッダー・プロパティ

Oracle JMSアダプタのヘッダー・プロパティの詳細は、「Oracle JMSアダプタのプロパティ」を参照してください。

8.3.6 サード・パーティ・サービス・プロバイダとの接続

JMSアダプタは、TIBCO、IBM MQ Seriesおよびその他の動作保証されているサード・パーティ・サービス・プロバイダと通信できます。これらのサービス・プロバイダが停止した後に再起動した場合、JMSアダプタは、これらのサービス・プロバイダに正常に接続し、保留中のメッセージを処理できます。

適切に接続されるようにするには、次の手順を実行します。

1. SOAおよびWebLogicコンソールの起動スクリプトであるsetDomainEnv.shで、次を設定します。

-Dweblogic.transaction.blocking.commit=false

および

-Dweblogic.transaction.blocking.rollback=false

2. WebLogicコンソールで、-->「domain」--- >「JTA」----- >「詳細」---->「CompletionTimeoutSeconds」に進み、CompletionTimeoutSecondsを0に設定します。

8.3.6.1 バインディング

プロパティ

adapter.jms.DistributedDestinationConnectionEveryMemberは、JMSアダプタのサービスのバインディング・プロパティとして使用可能です。

このプロパティには、ブール値[true | false]を使用できます。デフォルト値はtrueです。

trueの場合、JMSアダプタでは、分散宛先の各メンバーのコンシューマ/サブスクライバが作成されます。falseに設定すると、JMSアダプタでは、分散宛先のローカル・メンバーのみのコンシューマ/サブスクライバが作成されます。JMSアダプタがリモート・クラスタまたはリモート・ドメインのサーバーの分散宛先に接続されている場合、プロパティ

adapter.jms.DistributedDestinationConnectionEveryMemberを常にtrueに設定する必要があります。JMSアダプタがローカル・クラスタの分散宛先に接続している場合、このプロパティはtrueまたはfalseに設定できます。trueに設定すると、JMSアダプタは以前と同じままとなります(つまり、分散宛先ごとにコンシューマが作成されます)。falseに設定すると、JMSアダプタでは、ローカル・メンバーのコンシューマ/サブスクライバのみが作成されます。

JDeveloperのユーザー・インタフェースでは、このプロパティがサービス側のバインディング・プロパティとして表示されません。このため、次に示すように、<service>/<binding.jca>タグの下にこのプロパティを手動で追加する必要があります。

<property name="adapter.jms.DistributedDestinationConnectionEveryMember" type="xs:string" many="false" override="may">false</property>

8.4 Oracle JMSアダプタの使用例

この項には次のトピックが含まれます:

- Oracle JMSアダプタの構成

- TIBCO JMSを使用したOracle JMSアダプタの構成

- IBM WebSphere MQ JMSを使用したOracle JMSアダプタの構成に関する説明

- WebLogic Server JMSテキスト・メッセージ

- リモートOracle WebLogic Serverドメイン内のWLS JMSサーバーからのキューとトピックへのアクセス

- 同期/非同期リクエスト-リプライ相互作用パターン

- AQ JMSテキスト・メッセージ

- OC4J 10.1.3.4サーバーから11gで作成されたキューとトピックへのアクセス

- 10.1.3.X OC4Jに存在するキューにアクセスするための11G以降のサーバーの構成。

- WebLogic Server JMS上の分散宛先(キューとトピック)へのアクセス。

- IBM WebSphereのデフォルトのJMSプロバイダを使用したOracle JMSアダプタの構成

- JMSアダプタでのリクエスト-リプライの構成。

- JMSアダプタでのWLS JMS順序単位の使用。

8.4.1 Oracle JMSアダプタの構成

次の使用例では、Oracle JMSアダプタの構成手順を説明し、結果のWSDLファイルおよび関連するweblogic-ra.xmlファイルを検証します。

この項には次のトピックが含まれます:

- アプリケーションおよびSOAプロジェクトの作成

- アダプタ構成ウィザードを使用したOracle JMSアダプタの構成

- 生成されるファイル

- weblogic-ra.xmlファイル

- メッセージ発行手順

8.4.1.1 アプリケーションおよびSOAプロジェクトの作成

最初に、SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従って新規アプリケーションとSOAプロジェクトを作成します。

1. JDeveloperを開きます。

2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。

図8-1 に示すように、「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

3. 「アプリケーション名」フィールドにアプリケーションの名前を入力します。例: AQQueue2Queue。

4. 「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。

図8-1 「汎用アプリケーションの作成 - アプリケーションの名前付け」ページ

5. 「次へ」をクリックします。

図8-2 に示すように、「プロジェクトの名前付け」ダイアログが表示されます。

6. 「プロジェクト名」フィールドにわかりやすい名前を入力します。例: AQQueue2Queue。

7. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

図8-2 「汎用アプリケーションの作成 - 汎用プロジェクトの名前付け」ページ

8. 「次へ」をクリックします。

図8-3 に示すように、「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

図8-3 「汎用アプリケーションの作成 - SOA設定の構成」ページ

9. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して、「終了」をクリックします。

新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

図8-4 に示すように、「BPELプロセスの作成」ページが表示されます。

図8-4 「BPELプロセスの作成」ページ

10. 「名前」フィールドにBPELプロセスの名前を入力します。この例では、デフォルト名を使用します。

11. 「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。

BPELプロセスが作成されました。

8.4.1.2 アダプタ構成ウィザードを使用した構成

アダプタ構成ウィザードを使用して構成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウで、「SOA」を選択します。

2. 「サービス・アダプタ」リストから「JMSアダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。

「アダプタ構成ウィザード」が表示されます。

3. 「次へ」をクリックします。

図8-5 に示すように、アダプタ構成ウィザードの「サービス名」ページが表示されます。

図8-5 「サービス名」ページ

4. サービス名を入力して「次へ」をクリックします。

図8-6 に示すように、アダプタ構成ウィザードの「JMSプロバイダ」ページが表示されます。

図8-6 「アダプタ構成ウィザード - JMSプロバイダ」ページ

5. 操作を1つ選択します。この例では「Oracle Weblogic JMS」を選択します。

- Oracle Enterprise Messaging Service (OEMS): WebLogicサービスまたはアドバンスト・キューイング・メッセージ・サービスと統合できます。

- サード・パーティ: このオプションを選択すると、サード・パーティのプロバイダと統合できます。

6. 「次へ」をクリックします。

アダプタ構成ウィザードの「サービス接続」ページが表示されます。

7. 設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。

「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明した手順を実行して、アプリケーション・サーバー接続を作成します。

8. 「次」を選択します。図8-7 に示すように、「アダプタ・インタフェース」ページが表示されます。

9. 「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択します。

図8-7 「アダプタ構成ウィザード - アダプタ・インタフェース」ページ

10. 「次へ」をクリックします。

アダプタ構成ウィザードの「操作」ページが表示されます。

11. 「メッセージ消費」、「メッセージ発行」、「リクエスト/リプライ」または「同期消費メッセージ」を選択します。この例では「メッセージ消費」を選択します。

図8-8 に示すように、操作名は自動的に入力されます。

図8-8 「アダプタ構成ウィザード - 操作」ページ

「メッセージ消費」オプションを選択すると、JMS宛先からのインバウンド・メッセージをアダプタで消費(受信)できます。

12. 「次へ」をクリックします。

図8-9 に示すように、アダプタ構成ウィザードの「消費操作のパラメータ」ページが表示されます。

図8-9 「アダプタ構成ウィザード - 消費操作のパラメータ」ページ

13. 次のフィールドの値を入力します。

- 接続先名
メッセージの送信元であるJMSキューまたはトピックのJNDI名です。このフィールドは編集できません。「参照」をクリックしてキューまたはトピックを参照する必要があります。使用しているJMSプロバイダのタイプに基づいて、キューまたはトピックを選択します。

詳細は、次の項を参照してください。

- TIBCO JMSを使用したOracle JMSアダプタの構成

- IBM WebSphere MQ JMSを使用したOracle JMSアダプタの構成に関する説明

- メッセージ本文のタイプ
サポートされている値は「TextMessage」、「BytesMessage」または「MapMessage」です。このリリースでは、「StreamMessage」メッセージ・タイプはサポートされていません。

- 永続サブスクライバID
このフィールドはオプションです。永続サブスクライバを設定する場合には、永続サブスクライバIDが必要です。接続が解除されるとサブスクライバは通常メッセージを失いますが、永続サブスクライバは再接続の際に保存されているメッセージをダウンロードします。

注意:

JMSプロバイダがOracle Weblogic JMSまたはOracleアドバンスト・キューイング・メッセージ・サービスの場合、トピックが選択されている場合にのみ、永続サブスクライバ・オプションが表示されます。ただし、JMSプロバイダがサード・パーティの場合、永続サブスクライバ・オプションは常に表示されます。

- メッセージ・セレクタ
このフィールドもオプションです。ヘッダーおよびプロパティの情報に基づいてメッセージをフィルタ処理します。メッセージ・セレクタ・ルールはブール式です。式がtrueの場合には、メッセージが消費されます。式がfalseの場合には、メッセージが拒否されます。

たとえば、次のような式を入力できます。

- JMSPriority > 3。これに基づき、優先度が3より高いメッセージが消費され、それ以外のメッセージはすべて拒否されます。

- JMSType = 'car' AND color = 'blue' AND weight > 2500。

- Country in ('UK', 'US', 'France')。

- MessageListenerを使用
このフィールドは、デフォルトで常に「False」に設定されます。

- JNDI名
アダプタが管理モードで確実に実行されるように、JNDI名で指定した値がweblogic-ra.xmlファイルに存在する必要があります。

注意:

この例ではメッセージ消費操作が示されています。メッセージ発行操作の場合は、このページは異なります。この部分の手順の違いは、「メッセージ発行手順」を参照してください。

適切なパラメータを入力したら、「次へ」をクリックします。

14. 図8-10 に示すように、アダプタ構成ウィザードの「メッセージ」ページが表示されます。このページでの設定により、メッセージ・ペイロードの適切なスキーマが定義されます。

次のいずれかを実行できます。

- 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択します。これにより残りのフィールドが使用できなくなります。

- ネイティブ・フォーマットの定義プロセスを支援するネイティブ・フォーマット・ビルダー・ウィザードを起動するには、「ネイティブ・フォーマットのスキーマの定義」をクリックします。

- スキーマ・ファイルURLのパスを入力します(またはパスを参照します)。

次に、最後に示した、スキーマ・ファイルURLを参照するオプションの手順を示します。

図8-10 「アダプタ構成ウィザード - メッセージ」ページ

15. 「参照」ボタンをクリックします。

図8-11 に示すように、「タイプ・エクスプローラ」ナビゲーション・ツリーを含む「タイプ・チューザ」ダイアログが表示されます。

16. ツリーを参照し、適切なスキーマ・タイプを選択して「OK」をクリックします。

図8-11 「タイプ・チューザ」ダイアログからのスキーマの選択

今度は、図8-12 に示すように、「スキーマ・ファイルのURL」フィールドおよび「スキーマ要素」フィールドが入力された状態で、「メッセージ」ページが再表示されます。

図8-12 入力が完了した「メッセージ」ダイアログ

17. 「次へ」をクリックします。

「終了」ページが表示されます。このボックスには、ウィザードにより作成されるアダプタ・ファイルのパスと名前が表示されます。

18. 「終了」をクリックします。

composite.xmlページが表示されます。

8.4.1.3 生成されるファイル

アダプタ構成ウィザードにより次のコンポジット・ファイルが生成されます。

<composite name="AQQueue2Queue"revision="1.0"
label="2007-09-04_11-58-50_914"mode="active"state="on"
xmlns="http://xmlns.oracle.com/sca/1.0"           xmlns:xs="http://www.w3.org/2001/XMLSchema"           xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"           xmlns:orawsp="http://schemas.oracle.com
/ws/2006/01/policy">
<import namespace="http://xmlns.oracle.com/pcbpel/adapter
/jms/Inbound/"location="Inbound.wsdl"
importType="wsdl"/>
<import namespace="http://xmlns.oracle.com/pcbpel/
adapter/jms/Outbound/"location="Outbound.wsdl"
importType="wsdl"/>
<service name="Inbound">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/
adapter/jms/Inbound/#wsdl.interface
(Consume_Message_ptt)"/>
<binding.jca config="Inbound_jms.jca"/>
</service>
<component name="BPELProcess1">
<implementation.bpel src="BPELProcess1.bpel"/>
</component>
<reference name="Outbound">
<interface.wsdl interface=
"http://xmlns.oracle.com/pcbpel/adapter
/jms/Outbound/#wsdl.interface (Produce_Message_ptt)"/>
<binding.jca config="Outbound_jms.jca"/>
</reference>
<wire>
<source.uri>Inbound</source.uri>
<target.uri>BPELProcess1/Inbound</target.uri>
</wire>
<wire>
<source.uri>BPELProcess1/Outbound</source.uri>
<target.uri>Outbound</target.uri>
</wire>
</composite>

次のコード・セグメントでは、アダプタの名前、様々な必要なスキーマの場所およびその他の定義ファイルが定義されています。

<import namespace="http://xmlns.oracle.com/pcbpel
/adapter/jms/Inbound/"location="Inbound.wsdl"
importType="wsdl"/>
<import namespace="http://xmlns.oracle.com
/pcbpel/adapter/jms/Outbound/"location=
"Outbound.wsdl" importType="wsdl"/>

このコード・セグメントでは必要なネームスペースをインポートしています。

<definitions name="Inbound" targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/jms/Inbound/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/jms/Inbound/" xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:imp1="http://xmlns.oracle.com/pcbpel/samples/expense">
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://xmlns.oracle.com/pcbpel/samples/expense" schemaLocation="xsd/expense.xsd"/>
</schema>
</types>
<message name="ExpenseRecord_msg">
<part name="ExpenseRecord" element="imp1:ExpenseRecord"/>
</message>
<portType name="Consume_Message_ptt">
<operation name="Consume_Message">
<input message="tns:ExpenseRecord_msg"/>
</operation>
</portType>

このコード・セグメントでは、メッセージ・タイプ、メッセージ名およびパートナ・リンクのポート・タイプが定義されています。

<adapter-config name="dequeue" adapter="Jms Adapter   xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/wls/Queue" UIConnectionName="wls3"
UIJmsProvider="WLSJMS" adapterRef=""/>
<endpoint-activation portType="Consume_Message_ptt" operation="Consume_
Message">
<activation-spec
className="oracle.tip.adapter.jms.inbound.JmsConsumeActivationSpec">
<property name="DestinationName" value="jms/DemoInQueue"/>
<property name="UseMessageListener" value="false"/>
<property name="PayloadType" value="TextMessage"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

8.4.1.4 weblogic-ra.xmlファイル

weblogic-ra.xmlファイルでは、JMSコネクション・ファクトリのエンドポイントが定義されます。コネクション・ファクトリには、各エンドポイントの構成プロパティが含まれます。後続の項で示すように、エンドポイントは、タイプの異なる接続に対応するために追加されます。次の例に、汎用weblogic-ra.xmlファイルの内容を示します。

<connection-instance>
<jndi-name>eis/wls/Queue</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value>weblogic.jms.XAConnectionFactory</value>
</property>
<property>
<name>FactoryProperties</name>
<value></value>
</property>
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>false</value>
</property>
<property>
<name>IsTransacted</name>
<value>false</value>
</property>
<property>
<name>Username</name>
<value></value>
</property>
<property>
<name>Password</name>
<value></value>
</property>
</properties>
</connection-properties>
</connection-instance>

8.4.1.4.1 Oracle WebLogic Server管理コンソールを使用した新規接続の作成

新規接続は、Oracle WebLogic Server管理コンソールを使用して作成する方法もあります。次の手順に従って、Oracle WebLogic Server管理コンソールで新規接続を作成します。

1. Oracle WebLogic Server管理コンソール: http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

3. 「ドメイン構造」ペインで「デプロイメント」を選択します。

Oracle WebLogic Server管理コンソールの「デプロイメントのサマリー」ページが表示されます。

4. 「デプロイメント」で、デプロイしたJMSアダプタをクリックします。たとえば、JmsAdapterをクリックします。

Oracle WebLogic Server管理コンソールの「JmsAdapterの設定」ページが表示されます。

5. 「構成」タブをクリックし、「アウトバウンド接続プール」タブをクリックします。

「アウトバウンド接続プールの構成表」が表示されます。

6. 「次へ」をクリックします。

「新しいアウトバウンド接続の作成」ページが表示されます。

7. デフォルトのアウトバウンド接続グループを選択して「次へ」をクリックします。

8. 「次へ」をクリックします。

9. 「JNDI名」フィールドに、新規接続インスタンスの取得に使用するJNDI名を入力します。例: eis/wls/Queue。

JNDIフィールドには任意の名前を指定できます。ただし、JDeveloperで消費操作または発行操作のパラメータを定義する際に同じJNDI名を使用する必要があります。

10. 「終了」をクリックします。

「デプロイメント・プラン保存アシスタント」ページが表示されます。

構成の変更内容は、新規デプロイメント計画に格納する必要があります。

11. 「パス」フィールドで、デプロイメント計画ファイルのパスを選択または入力します。パスは「.xml」で終了する必要があります。

12. 「OK」をクリックします。

新規接続が作成されました。この操作の完了後に、作成したプロパティが正しいかどうかを確認する必要があります。

13. 「JmsAdapterの設定」ページで、「構成」タブをクリックし、「プロパティ」タブをクリックします。

作成した接続はこのページに表示されます。この値が正しいかどうかを確認します。たとえば、サード・パーティのJMSサーバーに接続する場合は、「コネクション・ファクトリの位置」フィールドにサード・パーティのJMSサーバーに適用可能な正しい値が設定されていることを確認します。

注意:

この例では、Oracle WebLogic Server管理コンソールを使用してOracle JMSアダプタ用の新規接続を作成しました。他のアダプタ用の接続を作成するには、同じ手順に従う必要があります。ただし、ステップ4では接続の作成対象として適切なアダプタを選択します。

14. 「保存」をクリックします。

8.4.1.4.2 サード・パーティのJMSプロバイダの追加

weblogic-ra.xmlファイルでFactoryPropertiesパラメータに値を指定することで、アダプタで非Web Logic Server JMSおよび非AQJMSの接続インスタンスにサード・パーティのJMSプロバイダを使用することを指定できます。具体的には、ThirdPartyJMSProvider値をFactoryPropertiesパラメータに指定できます。このプロパティは、WebLogic Serverにアダプタをデプロイする場合にのみ必要です。

この値をtrueに設定した場合、JMSアダプタではJMSメッセージを処理するコンシューマの作成にDestinationAvailabilityListenerを使用しません。デフォルトはfalseです。次のスニペットのようなコードを使用する必要があります。

<property>
<name>FactoryProperties</name>
<value>ThirdPartyJMSProvider=true</value>
</property>

注意:

WebLogic Serverに事前に移入されているすべての接続インスタンスは変更を反映するため、それらのインスタンスに対してそれ以上チューニングは不要です。新規の非WLS JMSまたは非AQJMSプロバイダ・アクセスが必要な場合にのみ、新規接続インスタンスを追加する必要があるため、ThirdPartyJMSProviderプロパティが必要です。

8.4.1.5 メッセージ発行手順

メッセージ発行操作では、特に「アダプタ構成ウィザードを使用した構成」のステップ13において、定義の手順が異なります。消費操作パラメータを指定するかわりに、次の発行操作パラメータを指定します。これにより、JMS宛先へのアウトバウンド・メッセージをアダプタで発行(送信)できます。図8-13 に、「発行操作のパラメータ」ページを示します。

- 接続先名:
メッセージの配信先にする必要のあるJMSキューまたはトピックのJNDI名。入力する名前は、使用するJMSプロバイダのタイプに基づきます。

接続先名の詳細は、次の項を参照してください。

- TIBCO JMSを使用したOracle JMSアダプタの構成

- IBM WebSphere MQ JMSを使用したOracle JMSアダプタの構成に関する説明

- メッセージ本文のタイプ:
サポートされている値は、TextMessage、BytesMessageおよびMapMessageです。このリリースでは、StreamMessageメッセージ・タイプはサポートされていません。

- 配信モード:
値は「永続」または「非永続」です。永続配信モードでは、今後の使用に備えて、永続サブスクライバによりメッセージを保存するパブリッシャである永続JMSパブリッシャを指定します。永続サブスクライバは、「アダプタ構成ウィザードを使用した構成」のステップ15の対応するフィールドに永続サブスクライバIDのあるメッセージ消費です。非永続サブスクライバでは、アダプタがアクティブではないときに発行されたメッセージは失われます。永続サブスクライバでは、永続パブリッシャに保存されていたメッセージをダウンロードするため、すべてのメッセージを受信するために常にアクティブである必要はありません。

- 優先度:
優先度の値を選択します。9は最も高い優先度を、0は最も低い優先度を表します。デフォルトは4です。

- TimeToLive:
メッセージが失効して消費できなくなるまでの期間です。

- 順序単位
このパラメータは、選択されたJMSプロバイダがWebLogic Server JMSプロバイダの場合にのみ適用されます。これにより、メッセージ・プロデューサや単体として動作するメッセージ・プロデューサのグループが、複数のメッセージを1つの単位にグループ化してメッセージを作成順に処理することが可能になります。単一のメッセージのメッセージ処理は、メッセージが確認応答、コミット、回復またはロールバックされたときに完了します。メッセージのメッセージ処理が完了するまでは、その順序単位の残りの未処理メッセージがブロックされます。このUnit of orderプロパティにより、メッセージの作成時にMessageProducerの順序単位値を設定できます。この使用例は、『Oracle® Fusion Middleware Oracle WebLogic Server JMSのプログラミング』のJMSアダプタでのWLS JMS順序単位の使用に関する項およびメッセージ順序単位に関する項を参照してください。

- JNDI名
このフィールドでは、JMS接続のJNDI名を指定できます。JMSアダプタのデプロイ済インスタンスのデプロイメント・ディスクリプタは、JMSアダプタが実行時にJNDI宛先にアクセスするために必要な一連の構成プロパティとともにこのJNDI名に関連付けられている必要があります。

図8-13 「発行操作のパラメータ」ページ

8.4.2 TIBCO JMSを使用したOracle JMSアダプタの構成

この項では、直接接続と非直接接続用にTibco JMSを使用する構成方法について説明します。

注意:

各サブセクションにすべての情報が記載されているわけではないため、構成を変更する前にこの項全体をお読みください。TIBCO Enterprise Message Serviceに関連する情報は、TIBCO Enterprise Message Serviceユーザー・ガイド、ソフトウェア・リリース6.3(2012年2月)に基づいています。最新の更新は、TIBCOのドキュメントを参照してください。

また、次の説明のEMS_HOMEは、Tibco Enterprise Message Serviceのインストール・ディレクトリを表しています。

8.4.2.1 非SSL接続での事前構成済のTibcoコネクション・ファクトリの使用

TIBCO Enterprise Message Service管理ツールを使用して、コネクション・ファクトリおよびキュー/トピックを作成します。

1. 例:

create factory QueueConnectionFactory queue url=tcp://localhost:7222
create queue TibcoQueue

2. Weblogic管理コンソールを開き、Tibcoサーバーに接続する既存の接続プールを変更します。「デプロイメント」→「JMSAdapter」→「構成」→「oracle.tip.adapter.jms.IJmsConnectionFactory」→「アウトバウンド接続プール」→「eis/tibjms/Queue」にナビゲートします

3. ConnectionFactoryLocationをQueueConnectionFactoryに設定します。これは、先ほどTIBCO Enterprise Message Service管理ツールを使用して作成したコネクション・ファクトリの名前です。

4. FactoryPropertiesを次のように設定します(読みやすいように複数行に区切ってあります)。

java.naming.factory.initial=com.tibco.tibjms.naming.   TibjmsInitialContextFactory;
java.naming.provider.url=tibjmsnaming://localhost:7222;
java.naming.security.principal=<user name on Tibco server>;
java.naming.security.credentials=<password>;
ThirdPartyJMSProvider=true

5. また、独自の接続プールを作成するには、AS11gR1SOA/soa/connectors/JmsAdapter.rarのweblogic-ra.xmlファイルを次の例に示すように変更します。(この図は、トピック接続プールを作成する例としても使用できます。)

例 - 独自の接続プールの作成

<connection-instance>
<jndi-name>eis/tibjms/QueueConnectionPool</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value>QueueConnectionFactory</value>
</property>
<property>
<name>FactoryProperties</name>
<value>java.naming.factory.initial=com.
tibco.tibjms.naming.
TibjmsInitialContextFactory;
java.naming.provider.
url=tibjmsnaming://localhost:7222;
java.naming
.security.principal=<user name on
Tibco server>;
java.naming.security.credentials=
<password>;
ThirdPartyJMSProvider=true
</value>
</property>
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>false</value>
</property>
<property>
<name>IsTransacted</name>
<value>true</value>
</property>
<property>
<name>Username</name>
<value></value>
</property>
<property>
<name>Password</name>
<value></value>
</property>
</properties>
</connection-properties>
</connection-instance>

6. これらの変更後に、JMSAdapter接続プールのデプロイメントを更新します。EMS_HOME/lib/tibjms.jarを<SOA Installation>/user_projects/domains/<DOMAIN_NAME>/libディレクトリにコピーします。Weblogicサーバーを再起動します。

7. デプロイするプロジェクト内で、JMSアダプタのJMS jcaファイルは次のようになります。DestinationNameの値は、TIBCO Enterprise Message Service管理ツールを使用して作成したキューであるTibcoQueueです。

<connection-factory UIJmsProvider="THIRDPARTY"
location="eis/tibjms/Queue"
UIConnectionName="SOADEV"/>
<endpoint-interaction portType="Produce_Message_ptt"
operation="Produce_Message">
<interaction-spec
className="oracle.tip.adapter.jms.                  outbound.JmsProduceInteractionSpec">
<property name="TimeToLive" value="0"/>
<property name="PayloadType" value="TextMessage"/>
<property name="DeliveryMode" value="Persistent"/>
<property name="DestinationName" value="TibcoQueue"/>
</interaction-spec>
</endpoint-interaction>

8. メッセージの公開後に、TIBCO Enterprise Message Service管理ツールを使用して、次のように、Tibcoキュー内のメッセージ数を確認できます。

show queue TibcoQueue
Queue:                 TibcoQueue
Type:                  static
Properties:            *prefetch=5
JNDI Names:            <none>
Bridges:               <none>
Receivers:             0
Pending Msgs:          2, (2 persistent)
Delivered Msgs:        0
Pending Msgs Size:     1.2 Kb, (1.2 Kb persistent)

8.4.2.2 非SSL接続での動的に作成されたTibcoコネクション・ファクトリの使用

通常、事前構成済のコネクション・ファクトリが推奨されるメカニズムですが、Tibcoは、動的に作成されたコネクション・ファクトリのサポートも提供しています。これらを使用するには、次の手順を実行します。

1. TIBCO Enterprise Message Service管理ツールを使用して、キューまたはトピックを作成します。

create queue TibcoQueue

2. ConnectionFactoryLocationをcom.tibco.tibjms.TibjmsQueueConnectionFactoryに設定します。

3. FactoryPropertiesをServerUrl=tcp://<HOST>:<PORT>;UserName=<USERNAME>;UserPassword=<PASSWORD>に設定します

4. Tibcoサーバーに接続するのにユーザー名とパスワードが必要ない場合は、ユーザー名とパスワードのフィールドを削除します。

5. JMSアダプタ接続プールのデプロイメントを保存および更新します。

6. EMS_HOME/lib/tibjms.jarおよびEMS_HOME/lib/jms-2.0.jarを<SOA Installation>/user_projects/domains/<DOMAIN_NAME>/libディレクトリにコピーします。

7. 管理対象のWeblogicサーバーを再起動します。

8. デプロイするプロジェクトで、JMSアダプタのJMS jcaファイルは次の例のようになります。

DestinationNameの値は、TIBCO Enterprise Message Service管理ツールを使用して作成したキューであるTibcoQueueです。

例 - 動的に作成されたコネクション・ファクトリを持つJMSアダプタのJMS jcaファイル

<connection-factory UIJmsProvider="THIRDPARTY"
location="eis/tibjmsDirect/Queue" UIConnectionName="SOADEV"/>
<endpoint-interaction portType="Produce_Message_ptt"
operation="Produce_Message">
<interaction-spec
className="oracle.tip.adapter.jms.outbound.JmsProduceInteractionSpec">
<property name="TimeToLive" value="0"/>
<property name="PayloadType" value="TextMessage"/>
<property name="DeliveryMode" value="Persistent"/>
<property name="DestinationName" value="TibcoQueue"/>
</interaction-spec>
</endpoint-interaction>

8.4.2.3 SSL接続での事前構成済のTibcoコネクション・ファクトリの使用

SSL接続に事前構成済のTibcoコネクション・ファクトリを使用できます。これを行うには、SSLをサポートするようにTibcoサーバーを構成する必要があります。

1. EMS_HOME/binの下にcertsディレクトリを作成します。

2. サーバーSSL証明書をEMS_HOME/bin/certsディレクトリにコピーします。Tibcoは、テストの目的で、自己署名付きサーバー証明書および秘密鍵をEMS_HOME\bin\samples\certsに提供しています。

3. EMS_HOME/bin/tibemsd.confで、次の行を追加します。

listen = ssl://localhost:7243
ssl_server_identity = certs/server.cert.pem
ssl_server_key = certs/server.key.pem
ssl_password = password
listen = tcp://localhost:7222

これらの行によって、TCPおよびSSLリスニング・ポートが明示的に設定され、サーバー側の3つの必要なSSLパラメータ(identity、private keyおよびpassword)が指定されます。

4. ファイルを保存し、TIBCO Enterprise Message Serviceサーバーを終了します。

5. -ssl_debug_traceオプションのtibemsd -ssl_debug_traceを使用して、TIBCO EMSサーバーを起動します。

6. サーバーがサーバー・コンソールのSSLポートでリスニングしていることを確認します。

2014-04-29 16:14:20.997 Secure Socket Layer is enabled, using OpenSSL 0.9.8y5
Feb 2013
2014-04-29 16:14:20.998 Accepting connections on ssl://localhost/[::]:7243.
2014-04-29 16:14:20.998 Accepting connections on
ssl://localhost/0.0.0.0:7243.
2014-04-29 16:14:20.998 Accepting connections on tcp://localhost/[::]:7222.
2014-04-29 16:14:20.998 Accepting connections on
tcp://localhost/0.0.0.0:7222.

7. TIBCO Enterprise Message Service管理ツールを使用して、SSLコネクション・ファクトリを作成し、ホスト検証を無効にして(クライアント・ホストを検証する場合はホスト検証を無効にしないでください)、キューを作成します。

create factory SSLQueueConnectionFactory queue url=ssl://localhost:7243
setprop factory SSLQueueConnectionFactory ssl_verify_host=disabled
create queue TibcoQueue

8. Weblogic管理コンソールを開き、Tibcoサーバーに接続する既存の接続プールを変更します。「デプロイメント」→「JMSAdapter」→「構成」→「oracle.tip.adapter.jms.IJmsConnectionFactory」→「アウトバウンド接続プール」→「eis/tibjms/Queue」にナビゲートします。

9. ConnectionFactoryLocationをSSLQueueConnectionFactoryに設定します。これは、先ほどTIBCO Enterprise Message Service管理ツールを使用して作成したコネクション・ファクトリの名前です。

10. FactoryPropertiesを次のように設定します(読みやすいように複数行に区切ってあります)。

java.naming.factory.initial=com.tibco.tibjms.naming.     TibjmsInitialContextFactory;
java.naming.provider.url=tibjmsnaming://localhost:7243;
java.naming.security.principal=<user name on Tibco server>;
java.naming.security.credentials=<password>;ThirdPartyJMSProvider=true;
com.tibco.tibjms.naming.security_protocol=ssl;
com.tibco.tibjms.naming.ssl_enable_verify_host=false;
com.tibco.tibjms.naming.ssl_vendor=j2se-default

11. これにより、クライアントは証明書なしで接続できるようになります。デプロイした接続プールを保存および更新します。

12. EMS_HOME\libに配置されている次のjarファイルを<SOA Installation>/user_projects/domains/<DOMAIN_NAME>/libディレクトリにコピーします。

tibcrypt.jar
slf4j-api-1.4.2.jar
slf4j-simple-1.4.2.jar
tibjms.jar

13. Weblogic Serverを再起動します。

14. デプロイするプロジェクトで、JMSアダプタのJMS jcaファイルは次の例のようになります。

DestinationNameの値は、TIBCO Enterprise Message Service管理ツールを使用して作成したキューであるTibcoQueueです。

例 - 事前構成済TIBCOコネクション・ファクトリ・シナリオのJMS jcaファイル

<connection-factory UIJmsProvider="THIRDPARTY" location="eis/tibjms/Queue"
UIConnectionName="SOADEV"/>
<endpoint-interaction portType="Produce_Message_ptt"
operation="Produce_Message">
<interaction-spec
className="oracle.tip.adapter.jms.outbound.JmsProduceInteractionSpec">
<property name="TimeToLive" value="0"/>
<property name="PayloadType" value="TextMessage"/>
<property name="DeliveryMode" value="Persistent"/>
<property name="DestinationName" value="TibcoQueue"/>
</interaction-spec>
</endpoint-interaction>

15. クライアント証明書検証を有効にするには、EMS_HOME\bin\tibemsd.confを変更して、クライアント証明書の署名に使用されたCA証明書を追加する必要があります。たとえば、ssl_server_trusted = certs/test_client_ca.pemの場合、test_client_ca.pemは、クライアントのcertificate test_client_identity.p12の署名に使用される、Tibcoが提供するテストCA証明書です。ファイルは両方ともEMS_HOME\bin\samples\certsにあります。変更されたEMS_HOME\bin\tibemsd.confは、次のようになります。

listen = ssl://localhost:7243
ssl_server_identity = certs/server.cert.pem
ssl_server_key = certs/server.key.pem
ssl_password = password
ssl_server_ciphers = all
ssl_server_trusted = certs/test_client_ca.pem
listen = tcp://localhost:7222

16. -ssl_debug_traceオプションのtibemsd -ssl_debug_traceを使用して、TIBCO EMSサーバーを起動します

17. FactoryPropertiesを変更します(読みやすいように複数行に区切ってあります)。

java.naming.factory.initial=com.tibco.tibjms.naming.   TibjmsInitialContextFactory;
java.naming.provider.url=tibjmsnaming://localhost:7243;
java.naming.security.principal=<user name on Tibco server>;
java.naming.security.credentials=<password>;
ThirdPartyJMSProvider=true;
com.tibco.tibjms.naming.security_protocol=ssl;
com.tibco.tibjms.naming.ssl_enable_verify_host=false;
com.tibco.tibjms.naming.ssl_vendor=j2se-default;
com.tibco.tibjms.naming.ssl_identity=<EMS_HOME>/bin/certs/     test_client_identity.p12;
com.tibco.tibjms.naming.ssl_trusted=<EMS_HOME>/bin/certs/test_client_ca.pem;
com.tibco.tibjms.naming.ssl_ciphers=all

18. これらの変更によって、クライアントは、サーバー・コンソールに表示される次のような証明書を使用してサーバーに接続できます。

2014-04-30 13:39:47.485 Peer certificate:
2014-04-30 13:39:47.485 Certificate=[/C=US/ST=California/L=us-english/O=Test
Company/OU=test_client
Unit/CN=test_client/emailAddress=test_clienttestcompany.com]
Issuer=[/C=US/ST=California/L=us-english/O=Test Company/OU=test_client_root
Unit/CN=test_client_root/emailAddress=test_client_roottestcompany.com]
2014-04-30 13:39:47.485 Peer certificate chain:
2014-04-30 13:39:47.485 Certificate=[/C=US/ST=California/L=us-english/O=Test
Company/OU=test_client_root
Unit/CN=test_client_root/emailAddress=test_client_roottestcompany.com]
Issuer=[/C=US/ST=California/L=us-english/O=Test Company/OU=test_client_root
Unit/CN=test_client_root/emailAddress=test_client_roottestcompany.com]
2014-04-30 13:39:47.485 SSL accepted cipher=RC4-SHA

19. SSL接続のみを受け入れるようにサーバーを制限するには、EMS_HOME\bin\tibemsd.confに次を追加します。

ssl_require_client_cert = enable

8.4.2.4 SSL接続での動的に作成されたTibcoコネクション・ファクトリの使用

Oracle JMSアダプタでは、現在、この機能はサポートされていません。

8.4.3 IBM WebSphere MQ JMSを使用したOracle JMSアダプタの構成

この項では、非XAおよびXAデータソース用にIBM WebSphere MQ JMSを使用する構成方法について説明します。

8.4.3.1 非XAデータソース

次の手順を実行します。

1. 次のファイルを<SOAInstall_DIR>/user_projects/domains/<DOMAIN_NAME>/libフォルダにコピーします。

- /<YOUR-MQSERIES-INSTALL-LOCATION>/java/lib/com.ibm.mq.jar

- /<YOUR-MQSERIES-INSTALL-LOCATION>/java/lib/com.ibm.mqjms.jar

- /<YOUR-MQSERIES-INSTALL-LOCATION>/java/lib/dhbcore.jar

2. 次の例に示すように、AS11gR1SOA/soa/connectors/JmsAdapter.rarにあるweblogic-ra.xmlファイルを変更してコネクタ・ファクトリを構成します。

<connection-instance>
<jndi-name>eis/webspheremq/Queue</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value>com.ibm.mq.jms.
MQQueueConnectionFactory</value>
</property>
<property>
<name>FactoryProperties</name>
<value>QueueManager=<QUEUEMANAGER>;
TransportType=1;HostName=
<YOUR-HOST>;Port=<YOUR-PORT>;Channel=<CHANNEL>;
ThirdPartyJMSProvider=true
</value>
</property>
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>false</value>
</property>
<property>
<name>IsTransacted</name>
<value>true</value>
</property>
<property>
<name>Username</name>
<value><USERNAME></value>
</property>
<property>
<name>Password</name>
<value><PASSWORD></value>
</property>
</properties>
</connection-properties>
</connection-instance>

デフォルトの<USERNAME>および<PASSWORD>がそれぞれMUSR_MQADMINおよびpasswordであることに注意してください。

または、Oracle WebLogic Server管理コンソールを使用して新規コネクション・ファクトリを構成するには、「アダプタ・コネクション・ファクトリの追加」で説明する手順に従います。

8.4.3.1.1 マルチインスタンス・キュー・マネージャの使用

IBM WebSphere MQ JMSに接続し、マルチインスタンス・キュー・マネージャを使用するようにJMSアダプタを構成できます。

これを行うには、カスタム・プロパティconnectionNameListを使用します。このプロパティを使用して、様々なインスタンスの名前とポートを指定できます。

QueueManager=QM1;TransportType=1;
ConnectionNameList=slj01aml.us.domain.com(141
4),acb113114.us.domain.com(1414);
Channel=SYSTEM.DEF.SVRCONN;ThirdPartyJMSProv
ider=true;ClientReconnectOptions=0

8.4.3.2 XAデータソース

次の手順を実行します。

1. 次のファイルを<SOAInstall_DIR>/user_projects/domains/<DOMAIN_NAME>/libフォルダにコピーします。

- /<YOUR-MQSERIES-INSTALL-LOCATION>/java/lib/com.ibm.mq.jar

- /<YOUR-MQSERIES-INSTALL-LOCATION>/java/lib/com.ibm.mqjms.jar

- /<YOUR-MQSERIES-INSTALL-LOCATION>/java/lib/dhbcore.jar

- com.ibm.mqetclient.jar
このIBM拡張トランザクション・クライアント(com.ibm.mqetclient.jar)は、IBM MQ Seriesの7.5In v7.5よりも前のバージョンのMQ Seriesに必要です。このcom.ibm.mqetclient.jar JARファイルは、XAトランザクションの実行には必要ありません。XAトランザクションは、このJARファイルなしで適切に機能します。

2. 次の例に示すように、AS11gR1SOA/soa/connectors/JmsAdapter.rarにあるweblogic-ra.xmlファイルを変更してコネクタ・ファクトリを構成します。

<connection-instance>
<jndi-name>eis/webspheremq/Queue</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value>com.ibm.mq.jms.                    MQXAQueueConnectionFactory</value>
</property>
<property>
<name>FactoryProperties</name>
<value>QueueManager=<QUEUEMANAGER>;                  TransportType=1;
HostName=<YOUR-HOST>;
Port=<YOUR-PORT>;                  Channel=<CHANNEL>;    |
ThirdPartyJMSProvider
=true</value>
</property
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>false</value>
</property
<property>
<name>IsTransacted</name
<value>false</value>
</property
<property>
<name>Username</name>
<value><USERNAME></value>
</property>
<property>
<name>Password</name>
<value><PASSWORD></value>
</property>
</properties>
</connection-properties>
</connection-instance>

デフォルトの<USERNAME>および<PASSWORD>がそれぞれMUSR_MQADMINおよびpasswordであることに注意してください。

または、Oracle WebLogic Server管理コンソールを使用して新規コネクション・ファクトリを構成するには、「アダプタ・コネクション・ファクトリの追加」で説明する手順に従います。

8.4.4 Active MQ JMSを使用したOracle JMSアダプタの構成

この項では、Active MQ JMSを使用するOracle JMSアダプタの構成方法について説明します(非XAのみ)。

次の手順を実行します: 次のファイルを<SOAInstall_DIR>/user_projects/domains/<DOMAIN_NAME>/libフォルダにコピーします。

- /<YOUR-ACTIVEMQ-INSTALL-LOCATION>//activemq-all-5.8.0.jar

次の例に示すように、AS11gR1SOA/soa/connectors/JmsAdapter.rarにあるweblogic-ra.xmlファイルを変更してコネクタ・ファクトリを構成します。

<connection-instance>
<jndi-name>eis/activemq/Queue</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value>org.apache.activemq.
ActiveMQConnectionFactory</value>
</property>
<property>
<name>FactoryProperties</name>                   <value>BrokerURL=tcp://<YOUR-HOST>:
<YOUR-PORT>;ThirdPartyJMSProvider=true</value>
</property>
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>false</value>
</property>
<property>
<name>IsTransacted</name>
<value>true</value>
</property>
<property>
<name>Username</name>
<value></value>
</property>
<property>
<name>Password</name>
<value></value>
</property>
</properties>
</connection-properties>
</connection-instance>

または、Oracle WebLogic Server管理コンソールを使用して新規コネクション・ファクトリを構成するには、「アダプタ・コネクション・ファクトリの追加」で説明する手順に従います。

ActiveMQ Series v5.8の場合、XAサポートがあり、XA用に構成されるコネクション・ファクトリは、org.apache.activemq.ActiveMQXAConnectionFactoryです。これはJMSアダプタの現在のリリースで動作確認済です。

8.4.5 WebLogic Server JMSテキスト・メッセージ

Oracle BPEL PMのこのWebLogic Server JMSテキスト・メッセージの使用例では、Oracle JMSアダプタでWebLogic Server JMSキューとの間のエンキューおよびデキューを実行する方法について説明します。

メディエータ・ビジネス・プロセスのWLS JMSテキスト・メッセージ・シナリオの場合、adapters-jms-101-wlsjms-textmessageusingqueuesサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/expense.xsd

adapters-jms-101-wlsjms-textmessageusingqueuesサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

この項には次のトピックが含まれます:

- 前提条件の確認

- アプリケーション・サーバー接続の作成

- アプリケーションおよびSOAプロジェクトの作成

- インバウンド・アダプタ・サービスの作成

- アウトバウンド・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

8.4.5.1 前提条件の確認

Oracle BPEL PMのWebLogic Server JMSテキスト・メッセージの使用例では、前提条件として次のタスクを実行する必要があります。

8.4.5.1.1 Oracle WebLogic Server管理コンソールでのキューの作成

次の手順を実行して、この使用例で必要となるキューを作成します。

1. Oracle WebLogic Server管理コンソール: http://servername:portnumber/consoleにナビゲートします

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

図8-14 に示すように、Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

図8-14 Oracle WebLogic Server管理コンソールのホーム・ページ

3. 「ドメイン構造」ペインで、「サービス」、「メッセージング」、「JMSモジュール」の順にナビゲートします。

Oracle WebLogic Server管理コンソールの「JMSモジュール」ページが表示されます。

4. 既存のモジュールのいずれかをクリックします。この例では、「SOAJMSModule」をクリックします。

Oracle WebLogic Server管理コンソールの「SOAJMSModuleの設定」ページが表示されます。

5. 「リソースのサマリー」セクションで、「新規作成」をクリックします。

Oracle WebLogic Server管理コンソールの「新しいJMSシステム・モジュール・リソースの作成」ページが表示されます。

6. 「キュー」を選択して「次」をクリックします。

7. 次のキューの詳細を入力します。

- 名前

- JNDI名

- テンプレート

8. 「次へ」をクリックします。

9. 「サブデプロイメント」リストから、使用するサブデプロイメントを選択します。

10. 「終了」をクリックします。

ReceiveQueueという名前のキューが作成されました。

11. ステップ1から10を繰り返して、SendQueueという名前のキューを作成します。

8.4.5.1.2 Q2Qorders.xsdファイルの作成

次のコードを使用してQ2Qorders.xsdファイルを作成します。

<?xml version="1.0" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/
pcbpel/nxsd/extensions/FileInbound"
xmlns:tns="http://xmlns.oracle.com/
pcbpel/nxsd/extensions/FileInbound"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:encoding="US-ASCII" nxsd:stream="chars"
nxsd:version="NXSD">
<xsd:element name="Items">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="item" minOccurs="1"
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="Type" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="," nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="Quantity"
type="xsd:string" nxsd:style="terminated"
nxsd:terminatedBy=","
nxsd:quotedBy="&quot;">
</xsd:element>
<xsd:element name="Rate"
type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy="${eol}" nxsd:quotedBy="&quot;">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
<!--NXSDWIZ:C:\errors\inputFiles\orders.txt:-->

8.4.5.2 アプリケーション・サーバー接続の作成

設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明した手順を実行して、アプリケーション・サーバー接続を作成します。

8.4.5.3 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従ってアプリケーションとSOAプロジェクトを作成します。

1. JDeveloperを開きます。

2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「新規ギャラリ」ダイアログが表示されます。

3. 「SOAアプリケーション」を選択し、「OK」をクリックします。「アプリケーション名」フィールドにアプリケーションの名前を入力します。例: queue2queue。

4. 「次へ」をクリックします。

「プロジェクトの名前付け」ページが表示されます。

5. 「プロジェクト名」フィールドにわかりやすい名前を入力します。例: queue2queue。

6. 「次」を選択します。「SOA設定の構成」ページが表示されます。

7. 「コンポジット・テンプレート」リストからBPELプロセスを使用するコンポジットを選択して「終了」をクリックします。

新規アプリケーションおよびSOAプロジェクトが作成されました。

「BPELプロセスの作成」ページが表示されます。

8. 「名前」フィールドにBPELプロセスの名前を入力します。例: queue2queue。

9. 「テンプレート」リストで「インタフェースを後で定義」を選択し、「OK」をクリックします。

BPELプロセスが作成されました。

設計領域に、queue2queueアプリケーション、queue2queueプロジェクトおよびSOAコンポジットが表示されます。

10. Q2Qorders.xsdファイルをプロジェクトのXSDフォルダにコピーします。

8.4.5.4 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューにデキューするアダプタ・サービスを作成します。

1. 「サービス・アダプタ」リストから「JMSアダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。

「アダプタ構成ウィザード - ようこそ」ページが表示されます。

2. 「次へ」をクリックします。

「サービス名」ページが表示されます。

3. 「サービス名」フィールドにInboundと入力して「OK」をクリックします。

「JMSプロバイダ」ページが表示されます。

4. 図8-15 に示すように、「Oracle Enterprise Messaging Service (OEMS)」ボックスで「Oracle Weblogic JMS」を選択し、「次へ」をクリックします。「サービス接続」ページが表示されます。

図8-15 「アダプタ構成ウィザード - JMSプロバイダ」ページ

5. 図8-16 に示すように、「アプリケーション・サーバー接続の作成」で作成した接続を選択します。

図8-16 「アダプタ構成ウィザード - サービス接続」ページ

6. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

7. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

8. 図8-17 に示すように、「メッセージ消費」を選択して「次へ」をクリックします。

「消費操作のパラメータ」ページが表示されます。

図8-17 「アダプタ構成ウィザード - 操作」ページ

9. 「参照」をクリックし、「接続先」フィールドで「ReceiveQueue」を選択します。

「消費操作のパラメータ」ページが表示されます。

10. 消費操作のパラメータを入力して「次へ」をクリックします。

「メッセージ」ページが表示されます。

注意:

アダプタが管理モードで確実に実行されるように、JNDI名で指定した値がOracle JMSアダプタのweblogic-ra.xmlファイルに存在する必要があります。

11. 「URL」フィールドの端にある「参照」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

12. 図8-18 に示すように、「プロジェクトのスキーマ・ファイル」、「Q2Qorders.xsd」および「Items」を順番に選択します。

図8-18 「タイプ・チューザ」ダイアログ

13. 「次」を選択します。図8-19 に示すように、「メッセージ」ページの「URL」にQ2Qorders.xsdスキーマ・ファイルが表示されます。

図8-19 「アダプタ構成ウィザード - メッセージ」ページ

14. 「次」を選択します。「終了」ページが表示されます。

15. 「終了」をクリックします。JMSインバウンド・アダプタ・サービスの構成を完了しました。

8.4.5.5 アウトバウンド・アダプタ・サービスの作成

リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから、「JMSアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにOutboundと入力して「OK」をクリックします。「JMSプロバイダ」ページが表示されます。

4. 「Oracle Enterprise Messaging Service (OEMS)」ボックスで「Oracle Weblogic JMS」を選択し、「次へ」をクリックします。「サービス接続」ページが表示されます。

5. 「アプリケーション・サーバー接続の作成」で作成した接続を選択し、「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

6. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

7. 「メッセージ発行」を選択して「次へ」をクリックします。「発行操作のパラメータ」ページが表示されます。

8. 「参照」をクリックし、「接続先」フィールドで「SendQueue」を選択します。「発行操作のパラメータ」ページが表示されます。

9. 「次」を選択します。「メッセージ」ページが表示されます。

10. 「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」、「Q2Qorders.xsd」および「Items」を順番に選択します。

12. 「次」を選択します。「メッセージ」ダイアログの「URL」にQ2Qorders.xsdスキーマ・ファイルが表示されます。

13. 「次」を選択します。「終了」ページが表示されます。

14. 「終了」をクリックします。JMSアダプタ・サービスの構成が完了し、composite.xmlページが表示されます。

8.4.5.6 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)を接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるインバウンド・コンポーネント内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のアウトバウンド内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図8-20 のように表示されます。

図8-20 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4. 「queue2queue」をダブルクリックします。

「queue2queue.bpel」ページが表示されます。

5. 図8-21 に示すように、「コンポーネント」ウィンドウから、receive、assignおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。

図8-21 「queue2queue.bpel」ページ

6. 「Receive」をダブルクリックします。

「Receive」ダイアログが表示されます。

7. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。

「パートナ・リンク・チューザ」ダイアログが表示されます。

8. 「Inbound」を選択して「OK」をクリックします。

「パートナ・リンク」フィールドに値Inboundが移入された状態で「Receive」ダイアログが表示されます。

9. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。

「変数の作成」ダイアログが表示されます。

10. デフォルトを受け入れて「OK」をクリックします。

11. 図8-22 に示すように、「インスタンスの作成」ボックスを選択して「OK」をクリックします。

図8-22 「Receive」ダイアログ

12. invokeアクティビティをダブルクリックします。

Invokeダイアログが表示されます。

13. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。

「パートナ・リンク・チューザ」ダイアログが表示されます。

14. 「Outbound」を選択して「OK」をクリックします。

「パートナ・リンク」フィールドに値Outboundが移入された状態で「Invoke」ダイアログが表示されます。

15. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。

「変数の作成」ダイアログが表示されます。

16. デフォルトを受け入れて「OK」をクリックします。

図8-23 に示すように、「Invoke」ダイアログが表示されます。

図8-23 「Invoke」ダイアログ

17. 「OK」をクリックします。

18. assignアクティビティをダブルクリックします。

「Assign」ダイアログが表示されます。

19. 「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

20. 図8-24 に示すように、変数を選択して「OK」をクリックします。

図8-24 「コピー操作の作成」ダイアログ

21. 「Assign」ダイアログで「OK」をクリックします。

22. 「ファイル」、「すべて保存」を順番にクリックします。

8.4.5.7 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. 「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」に示す手順を使用して、アプリケーション・サーバー接続を作成します。

2. 「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

8.4.5.8 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。

デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. 「最後の5つのインスタンス」ペインに、新規インスタンスのエントリがあります。これは、queue2queue.javaを使用してメッセージをエンキューするときにトリガーされたインスタンスです。

3. インスタンスのいずれかをクリックします。「フローのトレース」ページが表示されます。

4. 「TextMessage」コンポーネント・インスタンスをクリックします。「監査」ページが表示されます。

5. 「フロー - デバッグ」タブをクリックしてインスタンスをデバッグします。

8.4.6 リモートOracle WebLogic Serverドメイン内のWLS JMSサーバーからのキューとトピックへのアクセス

使用してリモートWLS JMS宛先にアクセスできます。リモート宛先は、リモートOracle WebLogic Serverドメインの一部であるWLS JMSサーバー内で定義されているキューまたはトピックを指します。

このようなアクセスを実行するには、リモートWLS JMSサーバーと通信するように構成されたコネクタ・ファクトリを使用する必要があります。そのためには、次の例に示すように、weblogic-ra.xml内で定義されているコネクタ・ファクトリの<FactoryProperties>プロパティをリモート・サーバー構成に設定します。

<property>
<name>FactoryProperties</name>
<value>java.naming.factory.initial
=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url= t3://<HOST>:<PORT>;
java.naming.security.principal=
<USERNAME>;java.naming.security.credentials
=<PASSWORD>
</value>
</property>

リモートWLS JMSサーバーにあるリモート・キューから読み取れるようにするには、次のように構成する必要があります。

1. 両方のサーバーに一意のドメイン名とJMSサーバー名が必要です。

2. 2つのサーバー間でグローバルな信頼を有効化する必要があります。
サーバー間でグローバルな信頼を有効化する方法については、次のリンクを参照してください。

http://download.oracle.com/docs/cd/E13222_01/wls/docs100/ConsoleHelp/taskhelp/security/EnableGlobalTrustBetweenDomains.html

この構成は、WLS9.2サーバーにあるキューまたはトピックに接続する際にも適しています。

注意:

JMSアダプタを使用してWebLogic Serverのセキュアなキュー(ローカルまたはリモートのドメイン)にアクセスする場合は、FactoryPropertiesプロパティのjava.naming.security.principalおよびjava.naming.security.credentialsがWLSのセキュアなキューへのアクセス権を持つユーザーで適切に設定されていることを確認してください。

8.4.6.1 リモート・サーバーが使用される場合のJMSアダプタの制限

JMSアダプタを使用すると、SOAがインストールされているWebLogicServerドメインに対してリモートになっている、ドメイン内のWebLogic Server JMSの宛先の場所と対話できます。

JMSアダプタを使用してリモートの宛先にアクセスできるようにする2つのオプションがサポートされています。

- アクセス・パラメータにリモート・ドメインを指定したweblogic-ra.xmlファイルのFactoryPropertiesの指定による直接アクセス。

- リモート・ドメインにアクセスするように外部サーバーを構成。

インバウンドの使用例では、両方のオプションがサポートされます。アウトバウンドの使用例の場合のみ、直接アクセスはサポートされますが、外部サーバーの構成はサポートされません。

8.4.7 同期/非同期リクエスト-リプライ相互作用パターン

同期と非同期のリクエスト-リプライ相互作用パターンの両方がサポートされています。

8.4.7.1 同期リクエスト-リプライ・パターン

アダプタ構成ウィザードを使用すると、Oracle JMSアダプタを同期リクエスト-リプライ相互作用パターンに使用できるプロセスをモデル化できます。この場合、Oracle JMSアダプタはリクエスト・キューにリクエストを送信し、リプライ・キューからのレスポンスを待ってから実行を継続します。

下位では、Oracle JMSアダプタにより新規の相互作用パターンJmsRequestReplyInteractionSpecが使用されます。このインタラクション仕様では、リクエストとリプライの宛先名の構成が許可されています。

バリエーションでは、リプライ・キューの一部として一時返信先の使用が許可されます。基本的に、このパターンではOracle JMSアダプタはJMS宛先にメッセージを送信できます。その後、アダプタはJMSReplyToヘッダーをリプライの宛先に設定します。

この値を使用してサード・パーティ・クライアントからリプライの宛先にメッセージが送信され、その後にメッセージがOracle JMSアダプタによりデキューされます。

Oracle JMSアダプタを同期パターンで使用する場合は、JMSまたはBPEL受信イベントにXA ConnectionFactoryを使用し、コネクタ・ファクトリのisTransactedプロパティをweblogic-ra.xmlでtrueに設定できます。ただし、Webサービスを使用する場合は、非XA ConnectionFactoryを使用し、コネクタ・ファクトリのisTransactedプロパティをweblogic-ra.xmlでtrueに設定してください。

Oracle WebLogic Server JMSとの同期パターンでOracle JMSアダプタを使用する場合、コネクション・ファクトリはweblogic.jms.ConnectionFactoryまたはその他任意の非XAコネクション・ファクトリにする必要があります。また、Oracle WebLogic Server JMSをアダプタと同じローカルJVMで実行する場合は、コネクタ・ファクトリのisTransactedプロパティがweblogic-ra.xmlでfalseに設定されていることを確認する必要があります。次のサンプルを入手するには、Oracleサンプル・コード・サイトにアクセスします。

- adapters-jms-106-wlsjms-syncrequestreply

- adapters-jms-107-wlsjms-syncrequestreplywithtemporaryreplydestination

8.4.7.2 非同期リクエスト-リプライ・パターン

アダプタ構成ウィザードを使用すると、非同期リクエスト-リプライ相互作用パターンに使用できるプロセスをモデル化できます。

基本的に、このパターンではJMS宛先にメッセージを送信できます。メッセージがリプライ・キューで受信されると、メッセージを正しいコンポジットまたはコンポーネント・インスタンスにルーティングできます。相関付けはリクエスト・メッセージのJMSMessageIDに基づいて実行され、このIDはリプライ・メッセージのJMSCorrelationIDおよび基礎となるコンポーネントの対話IDとなります。

詳細は、Oracleサンプル・コード・サイトにアクセスして次のサンプルを参照してください。

- adapters-jms-105-wlsjms-nativecorrelation

8.4.8 AQ JMSテキスト・メッセージ

この使用例では、Oracle JMSアダプタでAQ JMSキューとの間のエンキューおよびデキューを実行する方法について説明します。

adapters-jms-108-aqjms-textmessageusingqueuesサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

この項には次のトピックが含まれます:

- 前提条件の確認

- アプリケーション・サーバー接続の作成

- アプリケーションおよびSOAプロジェクトの作成

- インバウンド・アダプタ・サービスの作成

- アウトバウンド・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

8.4.8.1 前提条件の確認

この使用例を実行するには、前提条件として次のタスクを実行する必要があります。

- Oracle WebLogic Server管理コンソールでのAQ JMSの構成

- Oracleデータベースでのキューの作成

8.4.8.1.1 Oracle WebLogic Server管理コンソールでのAQ JMSの構成

Oracle WebLogic Server管理コンソールでAQ JMSを構成するには、次の手順を実行する必要があります。

- Oracle WebLogic JMSモジュールの追加

- JMSモジュールへのAQ JMS外部サーバーの追加

- AQ JMS外部サーバーの構成

- AQ JMS外部サーバーへのコネクション・ファクトリの追加

- AQ JMS外部サーバーへの宛先の追加

Oracle WebLogic JMSモジュールの追加

Oracle WebLogic JMSモジュールの追加はオプションです。AQ JMS外部サーバーを既存のJMSモジュールに作成することもできます。

1. Oracle WebLogic Server JMS: http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

3. 「ドメイン構造」ペインで、「サービス」、「メッセージング」、「JMSモジュール」の順にナビゲートします。
Oracle WebLogic Server管理コンソールの「JMSモジュール」ページが表示されます。

4. 「新規作成」をクリックして新規のWebLogic JMSモジュールを作成します。
Oracle WebLogic Server管理コンソールの「JMSシステム・モジュールの作成」ページが表示されます。

5. JMSモジュール名を入力して「次へ」をクリックします。
Oracle WebLogic Server管理コンソールの「JMSシステム・モジュールの作成」ページが表示されます。

6. SOAコンポーネントが実行中のターゲット・サーバーを選択し、「次へ」をクリックします。
Oracle WebLogic Server管理コンソールの「JMSシステム・モジュールの作成」ページが表示されます。

7. 「終了」をクリックします。
JMSモジュールが作成されました。

JMSモジュールへのAQ JMS外部サーバーの追加

次のステップは、次の手順に従ってJMSモジュールにAQ JMS外部サーバーを追加することです。

1. 作成したJMSモジュールをクリックします。
Oracle WebLogic Server管理コンソールの「AQJMSモジュールの設定」ページが表示されます。

2. 「リソースの概要」表で、「新規作成」をクリックして新規のJMSシステム・モジュール・リソースを作成します。
Oracle WebLogic Server管理コンソールの「新しいJMSシステム・モジュール・リソースの作成」ページが表示されます。

3. 「作成するリソースのタイプを選択してください。」で、「外部サーバー」を選択して「次へ」をクリックします。
Oracle WebLogic Server管理コンソールの「新しいJMSシステム・モジュール・リソースの作成」ページが表示されます。

4. 「名前」フィールドに外部サーバー名を入力し、「終了」をクリックします。
Oracle WebLogic Server管理コンソールの「<JMSモジュール名>の設定」ページが表示されます。

AQ JMS外部サーバーの構成

次のステップは、作成したAQ JMS外部サーバーを構成することです。

1. 「リソースの概要」表に表示されるAQ JMS外部サーバーをクリックします。
Oracle WebLogic Server管理コンソールの「TestAQJMS_ForeignServerの設定」ページが表示されます。

2. 以下の値を入力します。

- JNDI初期コンテキスト・ファクトリ: oracle.jms.AQjmsInitialContextFactory
AQ JMS外部サーバーがWebLogicサーバー側コンポーネントで使用される場合は、次の値を指定して、このAQ JMS外部サーバーを使用してデータソースを構成する必要があります。

「JNDIプロパティ」フィールドにdatasource=<datasource jndi location>と入力します。プレースホルダをデータソースのJNDIロケーションで置き換えます。

ただし、AQ JMS外部サーバーがWebLogicアプリケーション・クライアントで使用される場合は、作成したAQ JMS外部サーバーを指定してJDBC URLを構成する必要があります。

- JNDI接続URL: WebLogicサーバーでJNDIプロバイダへの接続に使用するURLを指定します。
この値は、AQ JMS外部サーバーがWebLogicアプリケーション・クライアントで使用される場合にのみ必須です。

- JNDIプロパティ資格証明: JNDIプロバイダ用に設定する必要のある資格証明を指定します。
この値は、AQ JMS外部サーバーがWebLogicアプリケーション・クライアントで使用される場合にのみ必須です。

注意:

Oracle RACデータベースをアダプタ・エンドポイントとして使用する場合は、前述の手順で説明したJNDIプロパティが指すデータソースでマルチ・データソースを指す必要があります。

このようなエンドポイントに使用される個別データソースとマルチ・データソースには、「Oracle JCAアダプタで使用するデータソースの推奨設定」に示す推奨設定を使用する必要があります。

AQ JMS外部サーバーへのコネクション・ファクトリの追加

AQJMS外部サーバーにコネクション・ファクトリを追加する手順は、次のとおりです。

1. 「<外部サーバー名>の設定」ページの「接続ファクトリ」タブで、作成したAQJMS外部サーバーを選択します。

2. 「新規」をクリックします。
Oracle WebLogic Server管理コンソールの「新しい外部JMS接続ファクトリの作成」ページが表示されます。

3. 「名前」フィールドに、このコネクション・ファクトリの名前を入力します。これは、Oracle WebLogic Serverで参照される論理名です。

4. 「ローカルJNDI名」フィールドに、このコネクション・ファクトリを参照するためにアプリケーションで使用するローカルJNDI名を入力します。

注意:

サンプルの使用例AQQueuetoQueueで提供されるJNDI名がeis/aqjms/Queueのキューに接続する場合は、ローカルJNDI名にaqjms/XAQueueConnectionFactoryを指定してください。

また、JNDI名がeis/aqjms/Topicのトピックに接続する場合は、aqjms/XATopicConnectionFactoryを指定します。

5. 「リモートJNDI名」フィールドに、要件に応じて次のいずれかの値を入力します。このコネクション・ファクトリをグローバル変換に使用する場合はXAベースのコネクション・ファクトリを使用し、それ以外の場合は非XAベースのコネクション・ファクトリを使用します。

- QueueConnectionFactory

- TopicConnectionFactory

- ConnectionFactory

- XAQueueConnectionFactory

- XATopicConnectionFactory

- XAConnectionFactory

6. 「OK」をクリックします。

AQ JMS外部サーバーへの宛先の追加

AQJMS外部サーバーに宛先を追加する手順は、次のとおりです。

1. 「<外部サーバー名>の設定」ページの「宛先」タブをクリックします。

2. 「新規」をクリックし、この宛先の名前を指定します。これは、Oracle WebLogic Serverによって参照される論理名で、宛先名とは関係ありません。

3. 「ローカルJNDI名」フィールドに、この宛先を参照するためにアプリケーションで使用するローカルJNDI名を入力します。

4. 「リモートJNDI名」フィールドに、宛先がキューの場合はQueues/<queue name>、宛先がトピックの場合はTopics/<topic name>と入力します。

5. 「OK」をクリックします。

6. Oracle WebLogic Server管理コンソールを再起動します。

Oracle WebLogic ServerでAQJMSの構成を完了しました。

8.4.8.1.2 Oracleデータベースでのキューの作成

キューを作成する手順は、次のとおりです。

1. setup_user.sqlスクリプトを実行します。

2. create_start_queues.sqlスクリプトを実行します。

これらのスクリプトは、adapters-jms-108-aqjms-textmessageusingqueuesサンプルのartifacts/sqlディレクトリにあります。adapters-jms-108-aqjms-textmessageusingqueuesサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

8.4.8.2 アプリケーション・サーバー接続の作成

設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明した手順を実行して、アプリケーション・サーバー接続を作成します。

8.4.8.3 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従って新規アプリケーションとSOAプロジェクトを作成します。

1. JDeveloperを開きます。

2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ダイアログが表示されます。

3. 「アプリケーション名」フィールドにアプリケーションの名前を入力します。例: AQQueue2Queue。

4. 「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。

5. 「次へ」をクリックします。

「プロジェクトの名前付け」ページが表示されます。

6. 「プロジェクト名」フィールドにわかりやすい名前を入力します。例: AQQueue2Queue。

7. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

8. 「次」を選択します。「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

9. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して、「終了」をクリックします。

新規アプリケーションおよびSOAプロジェクトが作成されました。

「BPELプロセスの作成」ページが表示されます。

10. 「名前」フィールドにBPELプロセスの名前を入力します。

11. 「テンプレート」リストで「インタフェースを後で定義」を選択し、「OK」をクリックします。

BPELプロセスが作成されました。

AQQueue2Queueアプリケーション、AQQueue2QueueプロジェクトおよびSOAコンポジットが設計領域に表示されます。

12. expense.xsdファイルをプロジェクトのXSDフォルダにコピーします。

このファイルは、adapters-jms-108-aqjms-textmessageusingqueuesサンプルのartifacts/schemasディレクトリにあります。adapters-jms-108-aqjms-textmessageusingqueuesサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

8.4.8.4 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューにデキューするアダプタ・サービスを作成します。

1. 「サービス・アダプタ」リストから「JMSアダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにInboundと入力して「OK」をクリックします。「JMSプロバイダ」ページが表示されます。

4. 「Oracle Enterprise Messaging Service (OEMS)」ボックスで「Oracle Advanced Queueing」を選択し、「次へ」をクリックします。「サービス接続」ページが表示されます。

5. 「アプリケーション・サーバー接続の作成」で作成した接続を選択します。

6. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

7. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

8. 「メッセージ消費」を選択して「次へ」をクリックします。「消費操作のパラメータ」ページが表示されます。

9. 「参照」をクリックし、「接続先」フィールドで「testInQueue」を選択します。

10. 「次」を選択します。「メッセージ」ページが表示されます。

11. 「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」と「expense.xsd」を順番に選択します。

13. 「次」を選択します。「メッセージ」ページの「URL」フィールドにexpenses.xsdスキーマ・ファイルが表示されます。

14. 「次」を選択します。「終了」ページが表示されます。

15. 「終了」をクリックします。JMSインバウンド・アダプタ・サービスの構成を完了しました。

8.4.8.5 アウトバウンド・アダプタ・サービスの作成

リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから、「JMSアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにOutboundと入力して「OK」をクリックします。「JMSプロバイダ」ページが表示されます。

4. 「Oracle Enterprise Messaging Service (OEMS)」ボックスで「Oracle Advanced Queueing」を選択し、「次へ」をクリックします。「サービス接続」ページが表示されます。

5. 「アプリケーション・サーバー接続の作成」で作成した接続を選択し、「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

6. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作」ページが表示されます。

7. 「メッセージ発行」を選択して「次へ」をクリックします。「発行操作のパラメータ」ページが表示されます。

8. 「参照」をクリックし、「接続先」フィールドで「testOutQueue」を選択します。「発行操作のパラメータ」ページが表示されます。

9. 「次」を選択します。「メッセージ」ページが表示されます。

10. 「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

11. 「プロジェクトのスキーマ・ファイル」と「expense.xsd」を順番に選択します。

12. 「次」を選択します。「メッセージ」ダイアログの「URL」フィールドにexpense.xsdスキーマ・ファイルが表示されます。

13. 「次」を選択します。「終了」ページが表示されます。

14. 「終了」をクリックします。JMSアダプタ・サービスの構成が完了し、composite.xmlページが表示されます。

8.4.8.6 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)を接続する必要があります。

コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるインバウンドOracle JMSアダプタ・コンポーネント内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のアウトバウンドOracle JMSアダプタ内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図8-25 のように表示されます。

図8-25 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4. BPELプロセスをダブルクリックします。「BPELProcess1.bpel」ページが表示されます。

5. 「コンポーネント」ウィンドウから、receive、assignおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。

6. receiveアクティビティをダブルクリックします。

「Receive」ダイアログが表示されます。

7. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。

「パートナ・リンク・チューザ」ダイアログが表示されます。

8. 「Inbound」を選択して「OK」をクリックします。

「パートナ・リンク」フィールドに値Outboundが移入された状態で「Receive」ダイアログが表示されます。

9. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

10. デフォルトを受け入れて「OK」をクリックします。

11. 「インスタンスの作成」ボックスを選択します。

12. Outboundのためのinvokeアクティビティをダブルクリックします。

Invokeダイアログが表示されます。

13. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。

14. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。

「パートナ・リンク・チューザ」ダイアログが表示されます。

15. 「Outbound」を選択して「OK」をクリックします。

「パートナ・リンク」フィールドに値Outboundが移入された状態で「Invoke」ダイアログが表示されます。

16. デフォルトを受け入れて「OK」をクリックします。

17. 「OK」をクリックします。

18. assignアクティビティをダブルクリックします。

「Assign」ダイアログが表示されます。

19. 「+」アイコンをクリックして「コピー操作」を選択します。

「コピー操作の作成」ダイアログが表示されます。

20. 変数を選択して「OK」をクリックします。

21. 「Assign」ダイアログで「OK」をクリックします。

22. 「ファイル」、「すべて保存」を順番にクリックします。

注意:

Oracle JMSアダプタを使用して永続サブスクリプションを使用するAQ JMSトピックからデキューする際に、デキュー操作が低パフォーマンスであることに気づいた場合は、アダプタ・サービスごとに複数のインバウンド・スレッドを使用することでパフォーマンス全体を高速化できます。

Oracle JMSアダプタでは、エンドポイント・プロパティadapter.jms.receive.threadsを指定すると複数のインバウンド・スレッドが許可されます。

ただし、非永続サブスクリプションを使用する場合、そのシナリオでこの解決策を使用するとメッセージが重複するため、この解決策は機能しません。

注意:

レジリエンシが有効であり、Oracle Event Delivery Network (EDN)サブスクライバが静止モードである場合、EDNコンシューマ・スレッドはスリープ・モードになります。MaxStuckThreadTime = 600 (秒)などの構成に基づき、構成されたMaxStuckThreadTimeが経過すると、スリープEDNコンシューマ・スレッドはSTUCKとマークされます。サーバー・ログのこれらのSTUCKロギング文は一時的な警告であり、機能に影響しません。静止モードが終了し、レジリエンシが受信リクエスト処理を再開した後、これらのSTUCK警告はなくなり、通常の処理が再開されます。

SOA_Request_WMおよびSOA_EDN_WMも同じ最大制約を共有します。EDNサブスクライバのスレッド数が最大制約よりも大きい場合、SOA_Request_WMのパフォーマンスは影響を受けます。回避策は、EDNサブスクライバのスレッド数を削減するか、またはSOAIncomingRequests_maxThreadsで定義された最大制約を増加します

8.4.8.7 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. 「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」に示す手順を使用して、アプリケーション・サーバー接続を作成します。

2. 「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

8.4.8.8 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. 「最後の5つのインスタンス」ペインに、新規インスタンスのエントリがあります。これは、AQQueue2Queue.javaを使用してメッセージをエンキューするときにトリガーされたインスタンスです。

3. インスタンスのいずれかをクリックします。「フローのトレース」ページが表示されます。

4. 「TextMessage」コンポーネント・インスタンスをクリックします。「監査」ページが表示されます。

5. 「フロー - デバッグ」タブをクリックしてインスタンスをデバッグします。

8.4.9 OC4J 10.1.3.4サーバーからリリース11gで作成されたキューとトピックへのアクセス

この項では、Oracle Application Server 11gまたは12.1.3で作成されたキューとトピックにOC4J 10.1.3.4からアクセスする手順について説明します。

このことを行うには、Oracle WebLogic Serverを使用してOracle BPEL PM JMSアダプタを構成する必要があります。

Oracle WebLogic Serverを使用してOracle BPEL PM JMSアダプタを構成する手順は、次のとおりです。

1. 次の手順に従ってwlfullclient.jarファイルを作成します。

a. 次の例に示すようにserver/libディレクトリに移動します。

cd WL_HOME/server/lib

b. 次のコマンドを使用して、server/libディレクトリにwlfullclient.jarファイルを作成します。

java -jar ../../../modules/com.bea.core.jarbuilder_X.X.X.X.jar

X.X.X.Xは、WL_HOME/server/libディレクトリにあるjarbuilderモジュールのバージョン番号です。次に例を示します。

java -jar ../../../modules/com.bea.core.jarbuilder_1.0.1.0.jar

2. wlfullclient.jarファイルを、次の場所にある10.1.3.4サーバーにコピーします。

<ORACLEAS_HOME>/j2ee/<OC4J_INSTANCE>/connectors/
JmsAdapter/JmsAdapter

3. 次の例に示すように、oc4j-ra.xmlファイル内のコネクタ・ファクトリ設定を構成します。

<connector-factory location="eis/wlsjms/Queue"
connector-name="Jms Adapter">
<config-property name="connectionFactoryLocation"
value="weblogic.jms.ConnectionFactory"/>
<config-property name="factoryProperties"
value="java.naming.factory.initial=weblogic.jndi.
WLInitialContextFactory;java.naming.provider.url=t3:
//<WLS-SERVER-NAME>: <WLS-SERVER-PORT>;
java.naming.security.principal=<USER>;
java.naming.security.credentials=
<PASSWORD>"/>
<config-property name="acknowledgeMode"
value="AUTO_ACKNOWLEDGE"/>
<config-property name="isTopic" value="false"/>
<config-property name="isTransacted" value="false"/>
<config-property name="username" value=""/>
<config-property name="password" value=""/>
<connection-pooling use="none">
</connection-pooling>
<security-config use="none">
</security-config>
</connector-factory>

注意:

isTransacted構成プロパティの値は、通常はFALSEに設定する必要があります。現在、XAとWebLogic JMSの統合は、アダプタがOracle WebLogic Serverにデプロイされていないかぎりサポートされていません。また、<WLS-SERVER-NAME>はキューをホストする実際のWeblogic Server名で置き換える必要があること、さらに<WLS-SERVER-PORT>はキューをホストするWeblogic Serverの実際のポート値で置き換える必要があることに注意してください。

4. 次の例に示すように、10.1.3.4サーバーのserver.xmlファイルを変更し、environment-naming-url-factory-enabled="true"プロパティを追加します。

<application-server
...
...
environment-naming-url-factory-enabled="true"
...
>

5. 10.1.3.4サーバーを再起動して、変更されていることを確認します。

8.4.10 10.1.3.X OC4Jに存在するキューにアクセスするための11G以降のサーバーの構成

次の手順に従って、10.1.3.x OC4Jに存在するキューにアクセスするように11G以降のサーバーを構成できます。

8.4.10.1 Web Logic ServerのdomainsフォルダへのJarファイルのコピー

次のjarファイルをWebLogic Serverのdomains/<DOMAIN_NAME>/libフォルダにコピーします。

- $J2EE_HOME/lib/jms.jar

- $J2EE_HOME/lib/jta.jar

- $J2EE_HOME/oc4jclient.jar

- $AS_HOME/opmn/lib/optic.jar

8.4.10.2 weblogic-ra.xmlファイルへのコネクタ・ファクトリの追加

次の手順は、weblogic-ra.xmlファイルへのコネクタ・ファクトリの追加です。

<connection-instance>
<jndi-name>eis/oc4jjms/Queue</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value>jms/XAQueueConnectionFactory</value>
</property>
<property>
<name>FactoryProperties</name>
<value>java.naming.factory.initial=com.            evermind.server.rmi.RMIInitialContextFactory;             java.naming.provider.url= <PROVIDER_URL>; java.naming.security.principal=oc4jadmin;
java.naming.security.credentials=welcome1</value>
</property>
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>false</value>
</property>
<property>
<name>IsTransacted</name>
<value>false</value>
</property>
<property>
<name>Username</name>
<value>oc4jadmin</value>
</property>
</property>
<property>
<name>Password</name>
<value>welcome1</value>
</property>
</properties>
</connection-properties>
</connection-instance>

<PROVIDER_URL>=opmn://localhost:6003またはormi://localhost:12401は特定のノードに使用し、opmn:ormi://localhost:6003:oc4j_soaはoc4j_soaインスタンスに使用します。

8.4.11 WebLogic Server JMS上の分散宛先(キューとトピック)へのアクセス

分散宛先は、単一の論理的な宛先としてクライアントからアクセスできる宛先のセット(キュー、物理的なJMSキュー・メンバーのセット、またはトピック、物理的なJMSトピック・メンバーのセット)です。

注意:

分散宛先の詳細およびこのコンテキストで使用されている用語の定義は、http://download.oracle.com/docs/cd/E13222_01/wls/docs103//jms/dds.htmlにある分散宛先の使用に関するページを参照してください

JMSアダプタは、使用可能通知の受信後に分散宛先メンバーにアドレス指定されたメッセージを処理できます。分散宛先メンバーに関連する使用可能通知、使用不能通知および障害通知を処理できます。分散トピックの使用時にJMSアダプタでこのようなメッセージを処理するには、追加のプロパティを指定する必要があります。

追加のプロパティを指定する場合は、複数のFactoryProperty値をセミコロンで区切ることができます。次の例を参照してください。

<property>
<name>FactoryProperties</name>
<value>ClientID=SOACLient2;TopicMessageDistributionAll=true</value>
</property>

また、クラスタ内でJMSアダプタがWLSの複数の管理対象サーバーと対話するシナリオでは、すべてのサーバーをFactoryPropertiesプロパティの一部として指定する必要があります。これらを使用して、次の例のように、JMSアーティファクトを参照するための適切なコンテキストを確立します。

<property>
<name>FactoryProperties</name>
<value> java.naming.factory.initial=weblogic.jndi.
WLInitialContextFactory;
java.naming.provider.url=t3://<server1>:<port1>,
<server2>:<port2>;
java.naming.security.principal=
<username>;java.naming.security.credentials
=<password>
</value>
</property>

山カッコ<>は自身の環境で使用可能な値に置き換えます。

8.4.11.1 分散トピックにアクセスするためのJMSアダプタの指定

3つのFactoryPropertyパラメータ値を使用して、分散トピックにアクセスするアダプタの指定、複数の接続で共有するクライアントIDの明示的な有効化、複数のサブスクライバ間での永続サブスクリプションの共有の有効化を行う他、アプリケーションごとまたはエンドポイントごとに1つのメッセージのコピーが必要かどうかを指定します。次のプロパティがあります。

- ClientIDPolicy
複数の接続でクライアントIDを共有できるようにするには、FactoryPropertiesパラメータのClientIDPolicyプロパティにUNRESTRICTEDという値を使用します。値が指定されていない場合、デフォルトはUNRESTRICTEDです。デフォルト以外の値はRESTRICTEDです。ほぼすべてのケースでデフォルトが使用されるため、通常はこのプロパティを設定する必要はありません。次の例を参照してください。

</property>
<name>FactoryProperties</name>
<value>ClientIDPolicy=UNRESTRICTED</value>

</property>

- SubscriptionSharingPolicy
複数のサブスクライバ間で永続サブスクリプションを共有できるようにするには、FactoryPropertiesパラメータにSHARABLEという値を使用します。

SubscriptionSharingPolicyの値EXCLUSIVEは、複数のサブスクライバ間で永続サブスクリプションを共有できないことを意味します。値を指定しない場合、デフォルトはSHARABLEです。ほとんどの場合、値を変更する必要はありません。

<property>
<name>FactoryProperties</name>
<value>SubscriptionSharingPolicy=
SHARABLE</value>
</property>

- TopicMessageDistributionAll
TopicMessageDistributionAll FactoryPropertiesパラメータの詳細は、分散トピックに関する項を参照してください。次の例のように設定できます。

<property>
<name>FactoryProperties</name>
<value>TopicMessageDistributionAll=true</value>
</property>

8.4.11.2 分散キューと分散トピックを使用したJMSアダプタ

特定のインバウンドおよびアウトバウンド・キューおよびエラー処理の動作は、WebLogic Server JMSの分散キューおよび分散トピックを使用したJMSアダプタに適用されます。

インバウンド・キューの場合、JMSアダプタはインバウンド・ポーラー・スレッドを作成し、エンドポイント・アクティブ化時にWebLogic Server JMSに通知リスナーを登録します。エンドポイントの非アクティブ化時に通知リスナーを登録解除します。

注意:

内部では、コンシューマが分散キューのメンバーに固定されます。多数のスレッドを使用してアダプタをデプロイすることで、分散キューのすべてのメンバーを考慮できるようにする必要があります。

SOA 11.1.1.4.0以降のバージョンから、JMSアダプタでは分散キューと分散トピックの両方を完全にサポートしています。JMSアダプタの新しいバージョンでは、WebLogic Server JMSからの通知に依存して、分散宛先のメンバーに対するコンシューマの作成および削除を行います。

SOA 11.1.1.3.0以前のバージョンのJMSアダプタの動作(ここでは分散キューの2つ以上のメンバーにコンシューマがランダムに作成されます)とSOA 11.1.1.4.0以降の新しい動作を比較すると、アクティブ化の際に多数のポーラー・スレッドを使用してJMSアダプタを起動することに依存しなくてもすべてのメンバーを考慮できるようになったこと以外に変更はありません。

JMSアダプタは、非分散環境のエラーが処理されるのと同じ方法で分散環境のエラーを処理します。再試行可能例外ではメッセージが再試行されます。再試行不能例外ではメッセージが拒否されます。

アダプタが分散キューへのメッセージを生成するときに、他のアダプタの動作からJMSアダプタの動作への変更は行われません。

分散宛先に対するJMSメッセージは、分散宛先に対してMessageProducerを作成し、特定のメンバーに対しては作成しないことで生成されます。

アウトバウンド・エラーは、アウトバウンド参照に対して以前に定義されたフォルト・ポリシーに基づいて処理されます。

分散トピックを使用したインバウンド・アダプタの場合、JMSアダプタはエンドポイントのアクティブ化時に通知リスナーをWebLogic Server JMSに登録します。JMSアダプタは、分散トピック・メンバーに対してWebLogic Server JMSから受信した使用可能通知ごとにインバウンド・ポーラー・スレッドを作成します。

ポーラー・スレッドが作成されたメンバーに対する使用不能通知が受信された場合は、インバウンド・ポーラー・スレッドが作業を停止し、必要なクリーン・アップが実行されます。恒久サブスクリプションは、非分散トピック・シナリオの場合と同様に保持されます。

アダプタは、エンドポイントの非アクティブ化時に通知リスナーを登録解除します。分散トピックに到着したメッセージは、使用されている様々な設定と使用中の分散宛先のタイプ(アプリケーションごとにメッセージのコピーが1つ、またはアダプタ・エンドポイントごとにメッセージのコピーが1つ)に基づいて処理されます。

これらの各タイプの分散宛先の動作を次に示します。

8.4.11.3 アプリケーションごとに1つのメッセージのコピー(デフォルトの動作)

JMSアダプタで使用される場合のWebLogic Serverパーティション分散トピックのデフォルトの動作では、アプリケーションごとにメッセージのコピーが1つ提供されます。各メッセージは必ず1回のみ処理する(つまり、重複する処理がない)必要があります。アプリケーションごとにメッセージのコピーが1つあるこのシナリオでは、クライアントIDとサブスクリプション名はすべての分散宛先に対して 同じ であり、 各 アダプタ・インスタンスが すべての メンバーにサブスクリプションを作成します。サーバーの再起動後も名前は一意であり不変です。パーティション分散トピックを使用する場合、無制限のクライアントIDと共有サブスクリプション・ポリシーを使用するようにJMSアダプタを構成する必要があります。この2つはJMSアダプタのデフォルト設定です。複製された分散トピックを使用している場合は、無制限のクライアントIDと共有サブスクリプションのポリシーを使用するようにJMSアダプタを構成する必要があります(これはデフォルト設定です)。また、アクティブ化の仕様を定義するときに、NOT JMS_WL_DDForwardedのようにメッセージ・セレクタを指定する必要があります。

パフォーマンスを向上させるには、パーティション分散トピックを使用する必要があります。

ローカル・クラスタのweblogic-ra.xmlファイルの接続インスタンスのスニペットから構成される例については、次を参照してください。

<property>
<name>FactoryProperties</name>
<value>ClientID=SOAClient1;</value>
</property>

8.4.11.4 アダプタ・エンドポイントごとに1つのメッセージのコピー

分散トピックで使用できる2番目の使用例では、アダプタ・エンドポイントごとに1つのメッセージのコピーを使用します。この場合、クライアントIDまたはサブスクリプション名は、アダプタ・インスタンスごとに一意です。メンバー名の一意の 部分 は、サーバーの再起動後も変わりません。

パーティション分散トピックを使用する場合は、無制限のクライアントIDと共有サブスクリプションのポリシーを使用するようにJMSアダプタを構成する必要があります(これはデフォルト設定です)。

同時に、サブスクリプション名を一意にするには、JMSアダプタではプロパティTopicMessageDistributionAll (デフォルト値はfalse)がtrueに設定されている必要があります。このプロパティは、weblogic-ra.xmlファイルで接続インスタンスのFactoryPropertiesプロパティを設定することで定義できます。

使用例(ローカル・クラスタのweblogic-ra.xmlファイルの接続インスタンスのスニペット)を次に示します。

<name>FactoryProperties</name>
<value>ClientID=SOAClient2;
TopicMessageDistributionAll=true</value>
</property>

パフォーマンスを向上させるには、パーティション分散トピックを使用する必要があります。

複製された分散トピックを使用している場合は、無制限のクライアントIDと共有サブスクリプションのポリシーを使用するようにJMSアダプタを構成します(これはデフォルト設定です)。

同時に、サブスクリプション名を一意にするには、JMSアダプタではプロパティTopicMessageDistributionAll (デフォルト値はfalse)がtrueに設定されている必要があります。このプロパティは、weblogic-ra.xmlで接続インスタンスのFactoryPropertiesプロパティを設定することで定義できます。使用例(ローカル・クラスタのweblogic-ra.xmlの接続インスタンスのスニペット)を次に示します。

<name>FactoryProperties</name>
<value> ClientID=SOAClient2;
TopicMessageDistributionAll=true</value>
</property>

また、アクティブ化の仕様を定義するときに、メッセージ・セレクタNOT JMS_WL_DDForwardedを指定する必要があります。

8.4.11.4.1 アクティブ化の仕様を定義するときのメッセージ・セレクタの指定

アクティブ化の仕様を定義するときに、メッセージ・セレクタを指定します。メッセージ・セレクタは、アダプタ・エンドポイントごとにメッセージのコピーを1つ作成する場合に必要です。

セレクタを指定するには、重複する分散トピックから読み取ったコンポジット・アプリケーションをモデリングするときにJMSアダプタ・ウィザードを使用します。指定するメッセージ・セレクタのメタデータは、.jcaファイルに取得されます。

アクティブ化の仕様で定義されているメッセージ・セレクタの例を次に示します。このメッセージ・セレクタは、メッセージを宛先サブスクライバに送信するときに、転送されたメッセージのコピーを除外します。

このメッセージ・セレクタは、複製された分散トピックを使用する場合のみ適用できます。

<activation-spec className="oracle.tip.adapter.jms.inbound.JmsConsumeActivationSpec">
<property name="DestinationName" value="jms/DemoInTopic"/>
<property name="UseMessageListener" value="false"/>
<property name="DurableSubscriber" value="dsub1"/>
<property name="MessageSelector"
value="NOT JMS_WL_DDForwarded"/>
<property name="PayloadType" value="TextMessage"/>
</activation-spec>

分散トピックでは、再試行可能例外によりメッセージが再試行され、再試行不能例外によりメッセージが拒否されます。

使用可能/使用不能/障害通知は、アウトバウンド・アダプタ参照の処理には影響しません。メッセージは特定メンバーではなく分散宛先を対象とするMessageProducerを作成することによって作成されます。

分散トピック環境では、他の環境と同様に、エラーはアウトバウンド参照に対して定義されているフォルト・ポリシーに基づいて処理されます。

8.4.11.4.2 互換性と移行

リモート分散キューのサポートは、新しいDestinationAvailabilityListener APIを使用したWLS JMSバージョン9.0までさかのぼって実現されています。リモート分散トピックは、WebLogic 10.3.4より古い場合には、共有サブスクリプション、無制限のクライアントID、非転送セレクタ、およびパーティション化分散トピックもサポートされていないため、サポートできません。かわりにDTメンバーJNDI名を直接参照して、サブスクリプションの制限ごとに1つのサブスクライバを処理する必要があります。

8.4.12 IBM WebSphereのデフォルトのJMSプロバイダを使用したOracle JMSアダプタの構成

この項では、IBM WebSphere 7.x JMSに対するOracle JMSアダプタの構成方法について説明します。

1. 次のファイルを<WAS_INSTALL DIR>/fmwwas-nd/websphere/runtimesディレクトリの下からSOAInstall_DIR>/user_projects/domains/<DOMAIN_NAME>//libフォルダにコピーします。

- com.ibm.jaxws.thinclient_7.0.0.jar

- com.ibm.ws.admin.client_7.0.0.jar

- com.ibm.ws.ejb.thinclient_7.0.0.jar

- com.ibm.ws.jpa.thinclient_7.0.0.jar

- com.ibm.ws.messagingClient.jar

- com.ibm.ws.orb_7.0.0.jar

- com.ibm.ws.sib.client.thin.jms_7.0.0.jar

- com.ibm.ws.sib.client_ExpeditorDRE_7.0.0.jar

- com.ibm.ws.webservices.thinclient_7.0.0.jar

- ejb3exceptions.jar

- sibc.jmsra.rar

- sibc.nls.zip

2. 次の例に示すように、soa/connectors/JmsAdapter.rarにあるweblogic-ra.xmlファイルを変更してコネクタ・ファクトリを構成します
例 - コネクション・ファクトリの構成

<connection-instance>
<jndi-name>eis/webspherejms/Queue</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value><QUEUE_CONECTION_FACTORY></value>
</property>
<property>
<name>FactoryProperties</name>
<value>java.naming.provider.
url=iiop://<HOST_NAME>:<PORT>;
java.naming.factory.initial=com.ibm.
websphere.naming.WsnInitialContextFactory;
java.naming.security.principal=<USERNAME>;
java.naming.security.credentials=<PASSWORD>;
ThirdPartyJMSProvider=true
</value>
</property>
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>false</value>
</property>
<property>
<name>IsTransacted</name>
<value>true</value>
</property>
<property>
<name>Username</name>
<value><USERNAME></value>
</property>
<property>
<name>Password</name>
<value><PASSWORD></value>
</property>
</properties>
</connection-properties>
</connection-instance>

<connection-instance>
<jndi-name>eis/webspherejms/Topic</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value><TOPIC_CONECTION_FACTORY></value>
</property>
<property>
<name>FactoryProperties</name>
<value>java.naming.provider.url=
iiop://<HOST_NAME>:<PORT>;
java.naming.factory.initial=com.ibm.websphere.
naming.WsnInitialContextFactory;
java.naming.security.principal=<USERNAME>;
java.naming.security.credentials=<PASSWORD>;
ThirdPartyJMSProvider=true
</value>
</property>
<property>
<name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property>
<property>
<name>IsTopic</name>
<value>true</value>
</property>
<property>
<name>IsTransacted</name>
<value>true</value>
</property>
<property>
<name>Username</name>
<value><USERNAME></value>
</property>
<property>
<name>Password</name>
<value><PASSWORD></value>
</property>
</properties>
</connection-properties>
</connection-instance>

<QUEUE_CONECTION_FACTORY>および<TOPIC_CONECTION_FACTORY>は、デフォルトのJMSプロバイダのWebSphere 7.0でそれぞれ作成されているキューおよびトピック・コネクション・ファクトリのJNDI名を参照しています。

または、Oracle WebLogic Server管理コンソールを使用して新規コネクション・ファクトリを作成し、「アダプタ・コネクション・ファクトリの追加」で説明する手順を使用することもできます。

注意:

WebSphere 7.x JMSと対話する際は、XA以外のモードでのみJMSアダプタを使用できます。

8.4.13 JMSアダプタでのリクエスト-リプライの構成

リクエスト-リプライ構成機能では、次のことを実行できます。

- 単一の構成手順でのリクエストとリプライの結合。Oracle SOA Suiteの以前のリリースでは、2つの異なるアダプタを構成する必要がありました。

- BPEL相関セットの手動構成を必要としない自動相関付け。これはメディエータMediatorおよびBPMNでもシームレスに機能します。

JMSアダプタのリクエスト-リプライ機能を構成するには、次の手順を実行します。

1. JDeveloperコンポジット・エディタで、JMSアダプタを「外部参照」スイムレーンにドラッグ・アンド・ドロップします。

図8-26 「外部参照」スイムレーンへのJMSアダプタのドラッグ・アンド・ドロップ

2. JMSアダプタ構成ウィザードの最初のいくつかの画面でデフォルト値を入力し、操作名の入力を求める画面まで進みます。「操作タイプ」として「リクエスト/リプライ」を、「操作名」として「非同期」を選択します。

図8-27 「リクエスト/リプライ」に関する「操作」画面

3. ウィザードの後続の画面で、リクエスト・キューおよびリプライ・キューを選択します。メッセージはリクエスト・キューでエンキューされ、リプライはリプライ・キューで返されます。

図8-28 「リクエスト操作パラメータ」画面

図8-29 「リプライ操作パラメータ」画面

リクエスト・キューから読み取りレスポンス・キューにレスポンスを生成するバックエンド・システムは、実際には複数のレスポンスを生成します。そのため、このようなセレクタを使用することによって、不要なレスポンスをフィルタして除外する必要があります。

4. レスポンスのメッセージ・スキーマを選択します。

図8-30 リクエストおよびレスポンスのメッセージ・スキーマの選択

5. JMS Adapterパートナ・リンクに対応するBPELの<invoke>アクティビティを追加します。使用するサード・パーティ・アプリケーションで必要となるため、追加ヘッダーが設定されています。

図8-31 JMS Adapterリンクに対応するBPELのInvokeプロパティ・ダイアログ

<invoke>アクティビティの直後に<receive>アクティビティを追加し、「リプライ」操作を選択します。「インスタンスの作成」オプションが選択されていないことを確認します。

図8-32 「リプライ」操作に関する「Receive」ダイアログ

8.4.14 JMSアダプタでのWLS JMS順序単位の使用

SOA JMSアダプタを使用して、メッセージの特定の順序単位を作成したメッセージを生成できます。アダプタのInteractionSpecでは、JMSアダプタ構成ウィザードの操作の生成ページを使用してアダプタ参照をモデル化する際に構成したUnitOfOrderという名前のプロパティがサポートされます。「メッセージ発行手順」の当該ページの説明を参照してください。

このUnitOfOrderプロパティを使用して、メッセージの生成時にMessageProducerの順序単位値を設定します。新しいフィールドは、JMSプロバイダがWebLogic Server JMSの場合にのみ表示できます。

JMSアダプタにより、WLS宛先へのメッセージの生成時に使用されるこの順序単位をオーバーライドできるようになります。

このオーバーライドを実行するには、JMSアダプタでjca.jms.WeblogicUnitOfOrderという名前の正規化されたメッセージ・プロパティをサポートします。この値により、JmsProduceInteractionSpecのUnitOfOrderプロパティを使用して指定された値がオーバーライドされます。

UnitOfOrder指定プロパティの値はEMコンソールで変更できます。その時点以降のアウトバウンド相互作用ではすべて、指定する新しい値が使用されます。

当該プロパティのjca.jms.WeblogicUnitOfOrderも、JmsProduceInteractionSpecプロパティのUnitOfOrderも定義されていない場合は、JMSアダプタで順序単位値は設定されません。デフォルトの順序単位がコネクション・ファクトリおよび宛先で管理者によって指定されている場合は、それが有効化されます。

JMSの順序単位機能は、WebLogic Serverとのみ動作します。WebLogic Server以外の宛先では、当該プロパティのjca.jms.WeblogicUnitOfOrder(存在する場合)は無視されます。

8.4.14.1 順序単位プロパティの取得

相互作用仕様のインスタンスからユーザー指定の値を取得できます。

すべてのJMSメッセージ・プロパティは、正規化されたメッセージ・プロパティとして使用できます。配信されたメッセージ上で正規化されたメッセージ・プロパティのjca.jms.JMSProperty.JMS_BEA_UnitOfOrderを検索することによって、順序単位プロパティを取得できます。

8.4.15 JMS同期消費

Oracle JMSアダプタでは、同期消費(中間プロセス受信)相互作用パターンがサポートされています。

アダプタ構成ウィザードを使用すると、Oracle JMSアダプタをこのような同期消費相互作用パターンに使用できるプロセスをモデル化できます。この場合、Oracle JMSアダプタでは、プロセスの実行中に指定されたキューからのメッセージがデキューされます(このため、中間プロセス受信と呼ばれます)。

キューが空の場合は、実行が継続されます。下位では、Oracle JMSアダプタにより新規の相互作用パターンJmsReceiveNoWaitInteractionSpecが使用されます。

JMSアダプタ構成ウィザードを使用してJMS同期消費をモデル化する場合は、デキューに使用するキュー名を指定する必要があります。この操作の場合、JMSアダプタでは、現在の消費操作が構成されたときに構成されたその他すべてのjcaプロパティがサポートされます。

この操作を使用するシナリオでは、JMSアダプタにデキューするキューに関するメッセージがない場合、BPELプロセスによって、引き続きプロセスの次の手順が実行されます。

8.4.15.1 JMS同期消費の構成

JMSアダプタ構成ウィザードを使用してJMS同期消費操作を構成するには、次の手順を実行します。

1. 「JMSアダプタ構成ウィザード」画面で「同期消費メッセージ」を選択します。

図8-33 「同期消費メッセージ」が選択されたJMSアダプタ構成ウィザードの「操作」画面

2. JMSアダプタ構成ウィザードの「同期消費パラメータ」画面が表示され、同期消費画面のパラメータを入力できます。メッセージを入力します

- 「接続先名」に入力するか、または「参照」を選択して、接続先ブラウザを開きます。

- チューザからメッセージ本文のタイプを選択します。選択肢は次のとおりです。

- TextMessage

- BytesMessage

- MapMessage

- 「メッセージ・セレクタ」に入力します。
このフィールドはオプションです。ヘッダーおよびプロパティの情報に基づいてメッセージをフィルタ処理します。メッセージ・セレクタ・ルールはブール式です。式がtrueの場合には、メッセージが消費されます。式がfalseの場合には、メッセージが拒否されます。

画面では、一部の例が提供されます。その他の例については、次のようにロジックを入力できます。

- JMSPriority > 3。これに基づき、優先度が3より高いメッセージが消費され、それ以外のメッセージはすべて拒否されます。

- JMSType = 'car' AND color = 'blue' AND weight > 2500

- Country in ('UK', 'US', 'France')。

- JNDI名を指定します。接続先名を選択した場合にも入力します。

図8-34 JMSアダプタ構成の同期消費画面

3. 「参照」を選択して接続先ブラウザを開いた場合は、ブラウザで次を実行します。

- 「接続先タイプ」の「すべてのタイプ」、「キュー」または「トピック」を選択して、接続先タイプを選択します。

- 接続先を指定するか、「検索」をクリックして、ブラウザに移入される接続先を検索します。「すべて表示」をクリックして、接続先のリストを展開します。

- 接続先を選択し、「OK」をクリックして、同期パラメータ・ページの選択を使用します。

注意:

Oracle JMSアダプタを同期パターンで使用する場合は、JMSまたはBPEL受信イベントにXA ConnectionFactoryを使用し、コネクタ・ファクトリのisTransactedプロパティをweblogic-ra.xmlでtrueに設定できます。ただし、Webサービスを使用する場合は、非XA ConnectionFactoryを使用し、コネクタ・ファクトリのisTransactedプロパティをweblogic-ra.xmlでtrueに設定してください。

図8-35 JMSアダプタ構成ウィザードの接続先ブラウザの選択画面

4. JMSアダプタ構成ウィザードにJMSアダプタ・メッセージ画面が表示されます。この画面で、ネイティブ・フォーマットは不要(スキーマを不透明にする)を選択するか、ネイティブ・フォーマット・ビルダーを開きます。

9 Oracle JCA Adapter for Database

この章では、Oracle JCA Adapter for Databaseについて説明します。また、Oracleデータベース・アダプタおよびストアド・プロシージャの使用例も参照できます。

この章の内容は次のとおりです。

- 概要

- データベース・アダプタ構成ウィザードの概要

- 機能

- 概念

- データベース・アダプタ・デプロイメント

- JDBCドライバとデータベース接続の構成

- ストアド・プロシージャおよびファンクションのサポート

- Oracleデータベース・アダプタの使用例

9.1 概要

Oracleデータベース・アダプタを使用すると、SOAコンポジット・アプリケーションでJDBCを介してOracle Databaseまたはサード・パーティ・データベースと通信できます。

この項には次のトピックが含まれます:

- 機能概要

- 設計の概要

9.1.1 機能概要

この項では、Oracleデータベース・アダプタの機能概要について説明します。使用すると、Oracle SOA SuiteおよびOracle Fusion Middlewareとデータベース・エンドポイントとの通信が可能になります。データベース・エンドポイントとしては、ANSI SQL標準に準拠し、JDBCドライバを備えたOracleデータベース・サーバーおよびリレーショナル・データベースがあげられます。

表やビューは原則的に、できるかぎり透過的でノン・イントルーシブにSOA表およびSQLに対して公開されます。表およびSQLはリレーショナル・データベース製品に必ず備わっているため、統合の観点からは、標準にフォーカスした一般的なソリューションを作成すると、最も大きな影響を及ぼすことができます。データベースをSOAに対して公開する場合、一般的なソリューションとは、情報の問合せに最適なSQLのテクノロジと、情報の転送および表現に最適なXMLのテクノロジを統合することです。ストアド・プロシージャのサポートは各種データベースの中ではそれほど標準的ではありませんが、このガイドで説明するように、ストアド・プロシージャがサポートされています。

Oracle WebLogic Server上で動作するJCA 1.5コネクタです。これは、データベース通信を実現するために、基礎となるJDBCコネクタ/ドライバに依存します。JDBCとは対照的に、それは非プログラム的です。相互作用(一連のSELECT、UPDATE、INSERT)の概略は、アダプタ構成ウィザードを使用してモデル化されます。入力/出力はXMLであり、XMLが入力パラメータとして使用されたり、XMLに変換された結果セットという形式が最もよく見られます。これらのXMLの入出力により、サービスをOracle Fusion Middlewareにプラグインできるようになります。

既存のリレーショナル・スキーマにアクセスするには、アプリケーションおよびSOAプロジェクトを作成し、アダプタ構成ウィザードを使用して次の手順を実行します。

- リレーショナル・スキーマ(1つ以上の関連表)をインポートしXMLスキーマ(XSD)としてマップ
詳細は、「リレーショナルからXMLへのマッピング」を参照してください。

- SELECT、INSERTおよびUPDATEなどのSQL操作をWebサービスとして抽出
詳細は、「WebサービスとしてのSQL操作」を参照してください。

- データベース・イベントによるOracle Fusion Middlewareプロセスの開始

Oracle Streams Advanced Queuing (Oracle AQ)はOracle Databaseの機能ですが、Oracle AQと統合するには、個別に特化されたものを使用します。詳細は、「Oracle JCA Adapter for AQ」を参照してください。

非リレーショナル・データベースとレガシー・システム(AS/400上のDB2など少数の例外は除く)の場合は、アプリケーション・アダプタおよびメインフレーム・アダプタを使用できます。アプリケーション・アダプタおよびメインフレーム・アダプタの詳細は、次の各項を参照してください。

- レガシー・アダプタ

- パッケージ・アプリケーション・アダプタ

- Oracle E-Business Suiteアダプタ

詳細は、次を参照してください。

- 機能

- 概念

- データベース・アダプタ構成ウィザードの概要

9.1.1.1 Oracle BPEL PMとの統合

データベース・イベントのポーリング(通常は入力表に対するINSERT操作)とプロセスの開始を行うために使用される場合、公開サービスと呼ばれます。Oracle BPELプロセスでは、Oracleデータベース・アダプタはreceiveアクティビティに関連付けられるパートナ・リンクです。通常は、式inbound(データベースからSOAへ)が使用されます。

INSERTまたはSELECTなどの1回かぎりのDML文の起動用として使用される場合、メディエータ・コンポーネントまたはSOAコンポジットでは、サービス参照と呼ばれます。Oracle BPELプロセスでは、Oracleデータベース・アダプタはinvokeアクティビティに関連付けられたパートナ・リンクです。式outbound (SOAからデータベースへ)が使用されます。

9.1.2 設計の概要

この項では、Oracleデータベース・アダプタの設計の概要について説明します。図9-1に、様々な設計時成果物およびデプロイ成果物とどのように対話するかを示します。

図9-1 動作

インストール時にアプリケーション・サーバーにデプロイされるJCA 1.5コネクタです。

複数のインスタンスで構成されており、各インスタンスはデータベース・エンドポイントへの接続を表します。異なるSOAプロセスが同じアダプタ・インスタンス(データベース)を指し示すことがある一方、SOAプロセス内の異なるサービス・エンドポイントが異なるアダプタ・インスタンス(データベース)を指し示すこともあります。

各アダプタ・インスタンスは単一のデータベースを指し示すため、アダプタ・インスタンス対アプリケーション・サーバー・データソースは1対1の対応があります。データソースjdbc/SOADataSourceを指し示す、eis/DB/SOADemoという名前の単一のインスタンスが、デフォルトで使用できます。

アダプタ・インスタンスのリストは、Oracle WebLogic Server上のデプロイメント・ディスクリプタ・ファイルweblogic-ra.xmlに格納されています。(このディスクリプタ・ファイルはDbAdapter.rar内にあります。この.rarファイルには、DBAdapter.jarが含まれ、さらにその中にJavaクラス・ファイルが含まれています。)インスタンスを構成するには、基礎となるデータソースの作成、つまり、正しいJDBCドライバおよび接続URLの取得が必要です。

詳細は、「JDBCドライバとデータベース接続の構成」を参照してください。

ただし、場合によっては、weblogic-ra.xmlエントリには、基礎となるデータソースの単なる名前以外のものも含まれます。これらのプロパティの詳細は、「データベース・アダプタ・デプロイメント」を参照してください。

実行時にはインスタンスを使用しますが、設計時にはアダプタ構成ウィザード(リンク)を使用します。このウィザードを1回実行して1つのアダプタ・サービス・エンドポイントを生成した後で、さらにこのウィザードを編集モードで複数回実行して、それぞれを徐々に変更できます。これにより、表9-1 に示すように、SOAコンポジットのデプロイ時に必要となるすべてのアダプタ関連成果物が生成されます。

表9-1 アダプタ構成ウィザードによって生成されるSOAコンポジットのアダプタ成果物

ファイル

説明

<serviceName>.wsdl

これは、操作および入出力XML要素の名前によってサービス・エンドポイントを定義する抽象WSDLです。

<serviceName>_table.xsd

これには、これらの入出力XML要素のXMLファイル・スキーマが含まれます。これらの両ファイルは、SOAプロジェクトの残りへのインタフェースを形成します。

<serviceName>_or-mappings.xml

これは内部ファイルです。リレーショナル・スキーマとXMLスキーマ間のマッピングを記述するために使用されるTopLink固有のファイルです。これは実行時に使用されます。

<serviceName>_db.jca

これには、抽象WSDLの内部実装詳細が含まれます。これには、場所と操作に関する2つのメイン・セクションがあります。場所は、アダプタ・インスタンスのJNDI名(eis/DB/SOADemo)です。操作は、エンドポイントに対して実行するアクション(INSERT、UPDATE、SELECTおよびPOLLなど)です。db.jcaファイルの内容は、アダプタ構成ウィザードの実行時に行った選択によってすべて決定されます。

<serviceName>.properties

これも内部ファイルです。表のインポート時に作成され、表に関する情報が保存されます。設計時にのみ使用されます。

実行時には、前述の場所を使用して、サービスを実行するアダプタ・インスタンスが参照されます。db.jcaファイルおよびリンクされているor-mappings.xmlファイルのプロパティに基づいて、<seviceName>.propertiesにより実行対象として正しいSQLが生成され、入力XMLが解析されて、XSDファイルに一致する出力XMLファイルが作成されます。SQLを実行するために、プールされているSQL接続が基礎となるデータソースから取得されます。

9.2 データベース・アダプタ構成ウィザードの概要

この項では、アダプタ構成ウィザードの概要とアダプタ構成ウィザードを使用してOracleデータベース・アダプタを定義する方法について説明します。

この項では、Oracleデータベース・アダプタの様々な概念を使用例を通じて説明します。これにより、アダプタ構成ウィザードの概要を示します。さらに、この使用例では、アダプタ構成ウィザードを使用して、データベースからの表のインポート、複数の表にわたるリレーションシップの指定、対応するXMLスキーマ定義の生成、および必要なSQLまたはデータベース操作を公開するサービスの作成を行う方法についても説明します。これらのサービスは、BPELプロセスで使用されるパートナ・リンクの定義に使用されます。アダプタ・サービスの作成および編集のどちらにもアダプタ構成ウィザードを使用します。

- アプリケーションおよびSOAプロジェクトの作成

- Oracleデータベース・アダプタの定義

- データベースへの接続

- 操作タイプの選択

- 表の選択およびインポート

- 主キーの定義

- リレーションシップの作成

- 属性フィルタの作成

- WHERE句の定義

- 読取り後計画の選択

- ポーリング・オプションの指定

- 詳細オプションの指定

- Pure SQL操作に必要なSQL文字列の入力

9.2.1 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだOracle JDeveloper (JDeveloper)アプリケーションを作成する必要があります。次の手順に従ってアプリケーションとSOAプロジェクトを作成します。

1. JDeveloperを開きます。

2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。

図9-2 に示すように、「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

3. 「アプリケーション名」フィールドにアプリケーションの名前を入力します。

4. 「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。

図9-2 「汎用アプリケーションの作成 - アプリケーションの名前付け」ページ

5. 「次へ」をクリックします。

図9-3 に示すように、「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

6. 「プロジェクト名」フィールドにわかりやすい名前を入力します。

7. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

図9-3 「汎用アプリケーションの作成 - 汎用プロジェクトの名前付け」ページ

8. 「次」を選択します。図9-4 に示すように、「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

図9-4 「汎用アプリケーションの作成 - SOA設定の構成」ページ

9. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して、「終了」をクリックします。

新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

図9-5 に示すように、「BPELプロセスの作成」ページが表示されます。

図9-5 「BPELプロセスの作成」ページ

10. 「名前」フィールドにBPELプロセスの名前を入力します。

11. 「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。

BPELプロセスが作成されました。

9.2.2 定義

次のステップは、サービスを定義することです。サービスを作成するには、次の手順を実行します。

1. 「コンポーネント・パレット」で「SOA」を選択します。

2. 「サービス・アダプタ」リストから、「データベース・アダプタ」を「composite.xml」ページの公開されたコンポーネント・スイムレーンにドラッグ・アンド・ドロップします。

「アダプタ構成ウィザード」が表示されます。

注意:

サービスをBPELプロセスの一部として作成するには、「サービス・コンポーネント」から「コンポーネント」にBPELプロセスをドラッグ・アンド・ドロップします。それをダブルクリックします。次に、BPELの「コンポーネント・パレット」で、「データベース・アダプタ」を「BPELサービス」から「パートナ・リンク」スイムレーンにドラッグ・アンド・ドロップします。

3. 「次」を選択します。図9-6 に示すように、「サービス名」ページが表示されます。次の情報を入力します。

図9-6 サービス名の指定

4. 「サービス名」フィールドにサービス名を入力し、「次へ」をクリックします。「サービス接続」ページが表示されます。

アダプタ構成ウィザードの使用を続行するには、「データベースへの接続」を参照してください。

9.2.3 データベースへの接続

図9-7 に、サービスで使用するデータベース接続を選択する場所を示します。これは、サービスを構成する表をインポートするデータベースです。これは、サービスを構成する表をインポートするデータベースです。ここで、作成する新しいJDeveloperアプリケーションごとにデータベースを再作成できます。

データベース接続を識別するJava Naming and Directory Interface (JNDI)の名前を指定できます。デフォルト名はeis/DB/<ConnectionNameInJDev>です。

詳細は、「データベース・アダプタ・デプロイメント」を参照してください。

図9-7 「アダプタ構成ウィザード - サービス接続」ページ

次の点に注意してください。

- 本番環境では、アダプタのデプロイメント・ディスクリプタ(weblogic-ra.xml)にJNDIエントリを追加することをお薦めします。この場合、管理モードで作業することでパフォーマンスが向上します。
データソースとアウトバウンド接続プールの作成の詳細は、「アダプタ・コネクション・ファクトリの追加」を参照してください。

- 「次へ」をクリックすると、データベースへの接続が試行されます。接続できない場合は、既存のパートナ・リンクを編集している場合でも、次のウィンドウには進めません。

アダプタ構成ウィザードの使用を続行するには、「操作タイプの選択」を参照してください。

9.2.4 操作タイプの選択

図9-8 に、このサービスに構成する操作タイプを指定する場所を示します。

図9-8 「アダプタ構成ウィザード - 操作タイプ」ページ

次の操作タイプを使用できます。

- ストアド・プロシージャまたはファンクションの呼出し
サービスでストアド・プロシージャまたはファンクションを実行する場合にこのオプションを選択します。詳細は、「ストアド・プロシージャおよびファンクションのサポート」を参照してください。

- 表に対して操作を実行
このオプションは、アウトバウンド操作に対して選択します。「挿入/更新」、「挿入のみ」、「更新のみ」、「削除」、「選択」またはこの6つのオプションを任意に組み合せて選択できます。これらの操作は、同等のSQL操作であるMERGE、INSERT、UPDATE、DELETEおよびSELECTに変換されます。

詳細は、「DML操作」を参照してください。

注意:

「更新のみ」操作では、子レコードに対する挿入または削除が実行されることがあります。これは、マスターの更新に伴い、ディテールが追加または削除されることがあるためです。したがって、更新対象の入力に含まれるディテール・レコードが1つのみの場合は、表内の他のディテール・レコードが削除されます。

- 表の新規レコードまたは更新されたレコードをポーリング
この操作は、インバウンド操作(つまり、receiveアクティビティと関連付けられている操作)に対して選択します。この操作タイプでは、指定された表がポーリングされ、追加された任意の新しい行の処理用に返されます。また、ポーリング間隔も指定できます。

詳細は、「ポーリング戦略」を参照してください。

図9-9 に示すように、データベースからデータが読み取られた後に実行できるポーリング操作は次のとおりです。

- 読取り済の行の削除

- [Table_Name]表のフィールドの更新 (論理削除)

- 順序表の更新

- 異なるデータベースにある外部順序表の更新

- 制御表戦略

図9-9 ポーリング操作

- Pure SQLの実行
任意の複雑な文、集計問合せ(結果は行ベースではありません)およびXMLType列を処理する場合に役立ちます。アダプタ構成ウィザードのこの使用方法は、「Pure SQL - XMLタイプのサポート」を参照してください。

注意:

スキーマ・バインドXML表はサポートされていません。

アダプタ構成ウィザードのこれ以外の使用方法は、「表の選択およびインポート」を参照してください。

9.2.5 表の選択およびインポート

図9-10 に、操作のルート・データベース表を選択する場所を示します。複数の関連する表を使用している場合は、これがリレーションシップ・ツリーの最上位の表(または最上位の親表)になります。

図9-10 アダプタ構成ウィザード - 表の選択

「表のインポート」を選択すると、サブウィザードが起動します。このウィザードで、データベースからインポートする複数の表を検索および選択できます。表を削除すると、残された関連する表にあるリレーションシップが削除されます(元に戻されます)。このウィザードを編集モードで実行している間に基礎となる表が変更された場合、その変更内容を示す警告が表示されます。調整するには、表を再度インポートします。「表のインポート」をクリックして複数の表を選択すると、外部キーの制約に基づいてそれらの表の間のリレーションシップが推測されます。ただし、インポートした表ごとに「表のインポート」を起動する場合は、リレーションシップは推測されません。

注意:

表を再インポートすると、その表に対して任意で定義したカスタムのリレーションシップとカスタムWHERE句はすべて失われます(インポートする表がルート表の場合)。

アダプタ構成ウィザードの使用を続行するには、「主キーの定義」を参照してください。

9.2.6 主キーの定義

インポートした表にデータベースで定義された主キーがない場合、図9-11 に示すように、各表に主キーを指定するよう求められます。インポートしたすべての表に主キーを指定する必要があります。複数のフィールドを選択すると、マルチパートの主キーを指定できます。

図9-11 「アダプタ構成ウィザード - 主キーの定義」ページ

ここで指定する主キーは、オフライン・データベース表に記録され、データベース・スキーマには保存されないため、データベース・スキーマは変更されません。

アダプタ構成ウィザードの使用を続行するには、「リレーションシップの作成」を参照してください。

注意:

主キーが定義されている表のみがサポートされることに注意してください。表で主キー制約が明示的に定義されていない場合は、設計時にアダプタ構成ウィザードを使用して定義する際に指定する必要があります。有効な主キーを指定しなければ、一意の制約は保証されず、これにより実行時にメッセージが失われる可能性があります。つまり、重複する主キー値を持つ行が失われる可能性があります。また、主キーが100バイト未満であることを確認する必要があります。

注意:

主キー列にはcharではなくvarcharを使用することをお薦めします。charを使用する場合は、weblogic-ra.xmlプロパティのshouldTrimStringsをfalseに設定する必要があります。後続のスペースが切り捨てられることによって主キーが不適切に読み取られ、読取り行を処理済として更新できなくなることがあります。

9.2.6.1 主キーとしてのROWIDの使用

Oracleデータベース・アダプタのROWIDサポートによって、ROWIDを特定のサポート対象の操作の主キーとして選択できます。

主キー制約がない表をインポートすると、行を一意に識別するために使用できる一連の列を選択するよう求められます(図9-12 を参照)。統合シナリオの場合、ターゲット・スキーマに関する知識がより必要となることがあり、エラーが発生する可能性があります。たとえば、ここで一意でない列を選択すると、意図しない複数の行を更新する操作、または一部の行を2回返しその他の行は返さない選択となる可能性があります。

Oracle Databaseでは、エラーが発生しにくいROWID疑似列を主キーとして使用するよう選択できます。ROWIDは直接物理アドレスであるため、通常の索引よりも高速である場合があります。

ROWIDは、Oracle表の疑似列です。疑似列は、ユーザーが直接更新できない列であり、ユーザーが作成した列ではありません。また、疑似列は列のメタデータ・ビューに表示されず、select *問合せから返されます。

ROWIDの使用には、特定の制限があります。このような場合は、ユーザー・インタフェースのオプションがグレー表示され、選択できません。

ROWIDは、行を一意に識別する必要がない操作(挿入、選択)または同じトランザクションですでに読み取られている行のみを識別する必要がある操作(ほとんどのポーリング操作)に対してのみ使用できます。物理アドレスはデータベースの外部で意味を持たず、行の一部ではない(値がトランザクション内で安定している)ため、行自体の列を使用して行を一意に識別する必要がある操作では使用できません(マージ、削除、主キーによる選択)。

表間のリレーションシップでは行に明示的な主キーが必要なため、ROWIDは、単一の表との組合せでのみ使用できます。

ROWIDサポートは、Pure SQLまたはストアド・プロシージャには適用されません。

9.2.6.1.1 「主キー」ページでのROWIDの使用

主キー・セットのない表をインポートすると、ウィザードに「主キー」ページが表示されます。図9-12を参照してください。

図9-12 ROWIDを使用した主キーの定義

このページでは、次のいずれかを実行できます。

- 主キーを構成する列を選択するラジオ・ボタンをクリックして、主キーを作成する列を選択します。

- 主キーとして、疑似列ROWIDを使用するラジオ・ボタンをクリックして、主キーとしてROWIDを選択します。

この場合も、ROWIDは、インバウンド・ポーリング、挿入または選択操作でのみ使用できます。

主キーを構成する列を選択する場合は、各列の横に、NOT NULL、INDEXED、AUTO INCREMENT、UNIQUE INDEXEDなどの可能なヒントが表示されます。

後者の場合、列のチェック・ボックスがデフォルトで自動的に選択され、確認するよう求められます。

9.2.7 リレーションシップの作成

図9-13 に、ルート・データベース表およびその他の関連する表に定義されたリレーションシップを示します。「リレーションシップの作成…」をクリックして2つの表の間にリレーションシップを作成したり、「リレーションシップの削除」をクリックしてリレーションシップを削除できます。リレーションシップの名前を変更するには、「リレーションシップの名前変更」をクリックします。

図9-13 「アダプタ構成ウィザード - リレーションシップ」ページ

リレーションシップの作成に関して次の事項に注意してください。

- データベース上に表間の外部キー制約が存在する場合、表をインポートすると、ソース表(外部キー制約を含む表)からターゲット表に1対1 (1:1)、ターゲット表からソース表に1対多(1:M)の2つのリレーションシップが自動的に作成されます。

- 図9-13 に示すように、ルート・データベース表からアクセス可能なリレーションシップのみが表示されます。リレーションシップを1つ削除すると、他のリレーションシップがルート表からアクセスできなくなり、「リレーションシップ」ウィンドウに表示されなくなります。次に示す一連のリレーションシップがあるとします。
A --1:1--> B --1:1--> C --1:M--> D --1:1--> E --1:M--> F

(1) (2) (3) (4) (5)

リレーションシップ3を削除すると、表示されるリレーションシップは次のようになります。

A --1:1--> B

B --1:1--> C

リレーションシップ2を削除すると、表示されるリレーションシップは次のようになります。

A --1:1--> B

リレーションシップ1を削除すると、リレーションシップは表示されなくなります。

図9-14 に、リレーションシップを作成する場所を示します。

図9-14 「リレーションシップの作成」ダイアログ

リレーションシップを作成する手順は次のとおりです。

1. 親表と子表を選択します。

2. マッピング・タイプ(1対多、1対1または子表に外部キーのある1対1)を選択します。

3. 外部キー・フィールドを主キー・フィールドに関連付けます。

4. オプションでリレーションシップに名前を付けます(デフォルト名が生成されます)。

注意:

親表として選択できるのは、ルート表からアクセス可能な表のみです。

9.2.7.1 リレーションシップが作成または削除された際の動作

アダプタ構成ウィザードに最初に表がインポートされると、データベースの各フィールドに対応する、TopLinkのフィールドへの直接的なマッピングが作成されます。図9-15 および図9-16 に示すスキーマがあるとします。

図9-15 EMPLOYEEスキーマ

図9-16 ADDRESSスキーマ

これら2つの表をインポートするとすぐに、Employeeディスクリプタに次のマッピングが作成されます。

Employee:

- id (IDフィールドへのダイレクト・マッピング。たとえば、151)

- name (NAMEフィールドへのダイレクト・マッピング。たとえば、Stephen King)

- addrId (ADDR_IDフィールドへのダイレクト・マッピング。たとえば、345)

リレーションシップ・マッピングを作成すると、外部キー・フィールドへの直接的なマッピングは削除され、単一のリレーションシップ(1対1、1対多)マッピングと置き換えられます。そのため、EmployeeとhomeAddressと呼ばれるAddressの間に1対1リレーションシップを作成した後には、Employeeディスクリプタは次の例のようになります。

Employee:

- id

- name

- homeAddress (ADDRESS表への1対1マッピング。この属性はAddressオブジェクト全体を表します。)

リレーションシップが削除されると、外部キーへのダイレクト・マッピングがリストアされます。

9.2.7.2 様々なタイプの1対1マッピング

リレーションシップが自動的に作成される場合、1対多リレーションシップは、外部キーを持たない表からのものになります。ただし、このマッピング(技術的には1対多)を1対1として宣言できます。このためには、1対1(外部キーはターゲット上)を選択します。

9.2.7.3 外部キーが主キーである場合

インポートされるすべての表が第3正規形(3NF)であるとはかぎりません。まれに、複数の表が同じ主キーを共有しており、個別の外部キー列が存在しない場合があります。ルート表から関連するすべての表への1対1(外部キーはターゲット上)リレーションシップを作成することをお薦めします。これには、2つの理由があります。1つ目は、ルート上の主キーを外部キーとして(ソース上に1対1で)宣言する場合、マッピングが削除されるため、主キーはルート・レコードには存在せず、子レコードにのみ存在することになるためです。2つ目は、外部キーは単一の表のみを指すことができるためです。ある列を外部キーの一部として宣言すると、外部キーは削除されるため、新しいリレーションシップで再使用できなくなります。ルート表に1対1リレーションシップ(外部キーはソース上)を作成すると、主キー列が表示されなくなります。また、ルート表をその他の表に結合できなくなる可能性があります。

9.2.8 属性フィルタの作成

図9-17 に、インポートされた表の定義から作成された属性フィルタを示します。これには定義したリレーションシップも含まれます。

図9-17 「アダプタ構成ウィザード - 属性のフィルタ処理」ページ

オブジェクト・フィルタにセルフ・リレーションシップ(従業員対従業員の管理者のリレーションシップなど)が含まれる場合、ツリーではループとして表示されます。XSDファイルではループは表示されません。これはディスクリプタ・オブジェクト・モデルであり、XSDファイルではありません。

このページでは、入力(MERGE、INSERT)であるか出力(SELECT)であるかに関係なく、XMLファイルに表示する列を選択します。不要な列や読取り専用(変更不可)の列の選択をここで解除できます。

アダプタ構成ウィザードの使用を続行するには、「WHERE句の定義」を参照してください。

9.2.9 WHERE句の定義

サービスにSELECT問合せ(インバウンド・ポーリング・サービスまたはSELECTを含むアウトバウンド・サービスなど)が含まれる場合、SELECT文のWHERE句をカスタマイズできます。

注意:

Sequencing Table/Update an External Sequencing Tableによるポーリングを使用する場合は、SELECT問合せの表名が順序表のデータの大/小文字区別と一致することを確認してください。

図9-18 に、アウトバウンド・サービスのWHERE句を定義する場所を示します。

図9-18 「アダプタ構成ウィザード - 選択条件の定義」ページ

注意:

WHERE句はSELECT操作(新規または変更されたレコードのポーリング、または表におけるSELECT操作の実行)にのみ適用されます。INSERT、UPDATEおよびDELETE操作には適用されません。

WHERE句の最も基本的な式は、式の右側(RHS)の内容に応じて、次に示す3つのいずれかになります。

1. EMP.ID = 123

この場合、RHSはリテラル値です。このRHSは、図9-19 に示す「リテラル」オプションです。

2. EMP.ADDR_ID = ADDR.ID

この場合、RHSは別のデータベース・フィールドです。このRHSは、図9-19 に示す「問合せキー」オプションです。

3. EMP.ID = ?

この場合、実行時にRHS値を指定する必要があります。これは、図9-19 に示す「パラメータ」オプションです。

WHERE句の作成を開始する前に「追加」をクリックして、WHERE句で必要なパラメータを作成します。WHERE句を作成するには、図9-19 に示すように、「編集…」をクリックして「式ビルダー」を起動します。

図9-19 式ビルダー

より複雑なWHERE句(サブSELECT文およびFUNCTION文)をモデル化する場合、およびORDER BY句を追加する場合は、SQLプロシージャを編集して「次へ」をクリックします。ただし、この場合、ハードコードされたSQLによって後からメンテナンス・オーバーヘッドが発生し、プラットフォーム非依存性を失う可能性があります。

列の名前を含むshouldOrderRowsおよびsequencingFieldプロパティをmapping.xmlファイルに追加することでも、ORDER BY句を実行することができます。

if ((this.sequencingField != null) && (shouldOrderRows()))
{
ReadAllQuery raPollingQuery = (ReadAllQuery)this.pollingQuery; raPollingQuery.addOrdering(raPollingQuery.getExpressionBuilder().getField(this.sequencingField).ascending());
}

FROM句に記述されている列の変更は、列数と各列の列型が変更されなければ可能です。より複雑な変更については、任意のSQLを直接入力できる「Pure SQLの実行」オプションの使用を検討してください。

単一結果セットを戻す方法

複数の関連表の問合せ時にTopLinkで使用される文の合計数に影響する拡張機能を使用するには、「選択条件の定義」ページで「外部結合を使用してマスター表とディテール表の両方の単一結果セットを返す」を選択する必要があります。最も安全な方法はデフォルト(表ごとに1)を使用することで、この機能ではすべての関連表が単一の結果セットに外部結合されることで合計が1になります。

アダプタ構成ウィザードの使用を続行するには、「読取り後戦略の選択」を参照してください。

9.2.10 読取り後戦略の選択

「表に対して操作を実行」を選択した場合は、手順を省略して「詳細オプションの指定」に進んでください。

インバウンド操作の構成時には、1つ以上の行が読み取られた後の処理に関して次のオプションがあります。

- 読取り済の行の削除

- 表のフィールドの更新(論理削除)

- 順序表の更新

- 異なるデータベースにある外部順序表の更新

- 順序ファイルの更新

図9-20 にこれらのオプションを示します。

図9-20 「アダプタ構成ウィザード - 読取り後」ページ

アダプタ構成ウィザードの使用を続行するには、「ポーリング戦略」を参照してください。

9.2.10.1 読取り済の行の削除

このオプションでは、アダプタ・サービスによる読取りおよび処理後に、行はデータベースから削除されます。

9.2.10.2 表のフィールドの更新(論理削除)

このオプションでは、ルート・データベース表のフィールドを更新して、その行が読取り済であることを示します。図9-21 に示すように、構成の完了後に問合せのWHERE句が自動的に更新されます。

図9-21 「アダプタ構成ウィザード - 論理削除」ページ

この方法を使用すると、データベース表は図9-22 のようになります。

図9-22 表のフィールドの更新

次の点に注意してください。

- 行150および153はすでに読み取られて処理されています。

- STATUS列にUNPROCESSEDと表示されているため、次のポーリング・イベントで、行152が読み取られて処理されます。Unread Valueが明示的に指定されているため、行151は読み取られません。

- 行154にはLOCKEDというフラグが付いているため読み取られません。表が他のプロセスに使用されている場合、この予約値を使用できます。

9.2.10.3 順序表の更新

このオプションでは、別の順序表の最終読取り行を追跡します。図9-23 に指定する情報を示します。構成が完了すると、問合せのWHERE句が自動的に更新されます。

図9-23 「アダプタ構成ウィザード - 順序表」ページ

これらの設定を使用すると、順序表は図9-24 のようになります。

図9-24 順序表の更新

行が読み取られるたびに、この表は読み取られたIDで更新されます。次のポーリング・イベントが発生すると、最終読取りID (154)より大きなIDの行が検索されます。

使用される一般的な列は、event_id、transaction_id、scn(システム変更番号)、idまたはlast_updatedです。通常、これらの列には順序番号またはsysdateが移入され、値は(一定量で)増加します。

9.2.10.4 異なるデータベースにある外部順序表の更新

この操作は、順序表: 最終更新戦略を採用するときに選択します。図9-25 に、アダプタ構成ウィザードの「外部順序表」ページを示します。このページで、この操作の実行に必要な詳細を指定します。

図9-25 「アダプタ構成ウィザード - 外部順序表」ページ

9.2.10.5 順序ファイルの更新

このオプションは、順序ファイルを更新する場合に使用します。図9-26 に、アダプタ構成ウィザードの「順序ファイルの更新」ページを示します。このページで、この操作の実行に必要な詳細を指定します。

図9-26 「アダプタ構成ウィザード - 順序ファイルの更新」ページ

9.2.11 ポーリング・オプションの指定

追加のポーリング・オプションがある場合は、このページで指定できます。図9-27 に、アダプタ構成ウィザードの「ポーリング・オプション」ページを示します。

図9-27 ポーリング・オプションの指定

このページでは、新規の行またはイベントに関してデータベース表をポーリングする方法の詳細を指定します。

「ポーリング頻度」リストから、新規のレコードまたはイベントのポーリング頻度を選択します。

「XML文書ごとのデータベース行数」フィールドで、Oracle BPEL PMにイベントを送信する際の、XML文書ごとの行数を指定します。これは、データベース・アダプタとコンシューマ(Oracle BPEL PM)の間のバッチ設定です。

「トランザクションごとのデータベース行数」フィールドで、「無制限」を選択するか、または1回のトランザクションで処理する表の行数を示す値を入力します。

イベントに関してデータベースをポーリングする場合は、「ソート順」リストを使用して、戻される行を選択した列でソートできます。ベスト・プラクティスは、追加の構成なしではメッセージの順序付けが保証されないため、「<順序付けなし>」を選択することです。

「SQL」フィールドには、SQL構文が正しくない場合にメッセージが赤で表示されます。

ポーリング・オプションの指定の詳細は、「ポーリング・オプション」ページで「ヘルプ」をクリックするか、[F1]を押します。

9.2.12 詳細オプションの指定

詳細オプションを指定できます。図9-28 に、アダプタ構成ウィザードの「詳細オプション」ページを示します。このページでは、JDBCおよびDBアダプタの詳細オプションを指定し、再試行を構成し、ネイティブ順序付けを構成できます。

図9-28 詳細オプションの指定

「JDBCオプション」セクションでJDBCオプションを指定する必要があります。下位レベルのJDBCオプションはデータベースへのコール時に設定します。このページに表示されるオプションは、選択した操作によって決まります。

「自動再試行」セクションでは、タイムアウト時の自動再試行の値を指定します。接続関連のフォルトが発生した場合は、invokeアクティビティを回数制限付きで自動的に再試行できます。このセクションのフィールドでは、次の値を指定できます。

- 無限に再試行するには、「試行」フィールドにunlimitedと入力します。

- 「間隔」は、再試行間の遅延です。

- 「バックオフ係数: x」を指定すると、再試行間の待ち時間を延長できます。開始間隔に1、バックオフに2を指定して9回再試行すると、1、2、4、8、16、32、64、128および256 (2^8)秒後に再試行されます。

「相互作用オプション」では、相互作用オプションを次のように指定します。

- GetActiveUnitOfWork。同じSOAインスタンスの複数の起動間で同じレコードに対して複数の増分変更を行うときは、GetActiveUnitOfWorkをtrueに設定します。GetActiveUnitOfWorkによって、データベース・アダプタの起動(オプションをtrueに設定することで関与し、同じJTAトランザクション内に存在し、同じeis/DB/インスタンスに対して起動する)ですべての操作に対して同じEclipseLinkセッションが使用されるようになります。EclipseLinkベースの操作(ストアド・プロシージャおよびPure SQLは除く)では、すべての書込みがJTAが完了する前まで遅延されます。
つまり、2つの起動で同じオブジェクトを挿入/マージする場合、書込みは1回になります。EclipseLinkベースの書込みは遅延されるため、すべて選択では、書込みを実行した前の起動と一致しない可能性があります。しかし、主キーによる選択では一致します。書込みはJTAコールバック内で発生するため、その時点で発生する例外や、BPELのグローバル・トランザクションが予期せずに失敗した場合の例外を処理する方法がありません。2つの起動の操作が同じ物理SQL接続を使用したことを保証するためにGetActiveUnitOfWorkが頻繁に使用されるのは、トランザクションの間はEclipseLinkセッションに対する接続が固定されるためです。ただし、ほとんどのアプリケーション・サーバーのデータ・ソースでは同じ保証が提供されます。WebLogicにも同様の「スレッドに固定」プロパティがあり、GridLinkにはXAアフィニティがあります。これにより、XAトランザクションのすべての書込みはRACクラスタ内の同じノードで発生することになります。これを設定すると、異なるSOAインスタンス間のロック競合が解決されなくなります。

関連データ(親と子など)に複数の操作がある場合は、同じSOAインスタンスまたは起動でもそれらが発生するようにします。これもまた、2つの起動がトランザクション境界にある場合に接続再使用を保証するものではありません。BPELにおいて第2のDbAdapter起動がサブプロセス内にある場合は、コール先のコンポジット・レベルでBPELプロパティのbpel.config.transactionがrequiredに設定されていることを確認してください。

- 「省略の検出」を選択すると、MERGEおよびINSERT操作で入力ペイロード内の空または欠落しているXML要素を無視できます。MERGE操作の場合は、これにより有効だが未指定の値がNULLで上書きされなくなります。INSERT操作の場合は、これらの値がINSERT文から省略され、デフォルト値を有効にすることができます。

- 「マージの最適化」は、MERGEのパフォーマンス全般の強化であるため(主キーの存在チェックの問合せに使用)、常に選択する必要があります。

「ネイティブ順序付け(Oracleのみ)」では、すべてのINSERT時に順序から主キーが割り当てられるように指定できます。「検索」をクリックして「順序」リストから順序を選択するか、または名前を入力して「作成」をクリックします。

詳細オプションの指定の詳細は、「詳細オプション」ページで「ヘルプ」をクリックするか、[F1]を押します。

9.2.13 Pure SQL操作に必要なSQL文字列の入力

「カスタムSQL」ページで、「Pure SQLの実行」操作を実行するためのSQL文字列を入力できます。図9-29 に、アダプタ構成ウィザードの「カスタムSQL」ページを示します。

図9-29 SQL文字列の入力

「SQL」フィールドにカスタムSQL文字列を入力します。SQL入力のXSDスキーマが「XSD」フィールドに自動的に作成されます。

「XSD」フィールドには、入力したカスタムSQL文字列のXSDスキーマが表示されます。結果のXSDは直接編集できます。ただし、以降にSQL文字列を変更すると、XSDの変更内容が失われます。

SQL文字列の入力の詳細は、「カスタムSQL」ページで「ヘルプ」をクリックするか、[F1]を押します。

9.3 機能

この項では、機能について説明します。

次のトピックが含まれています:

- トランザクション・サポート

- Pure SQL - XMLタイプのサポート

- 強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート

- プロキシ認証のサポート

- 大きなペイロードのストリーミング

- スキーマ検証

- 高可用性

- スケーラビリティ

- パフォーマンス・チューニング

- detectOmissions機能

- OutputCompletedXml機能

- インバウンドおよびアウトバウンド・トランザクションのQueryTimeout

- BPELへの同期ポストの実行(順序配信の許可)

9.3.1 トランザクション・サポート

固有のデータ処理とともにトランザクション・サポートが可能になります。これにより、それぞれの変更の結果が明確に定義されており、結果は成功か失敗のいずれかになるため、潜在的なデータ破損が防止され、他の変更から独立して実行され、完了後は別のトランザクションが発生するまで基礎となるデータが同じ状態で維持されることが保証されます。

トランザクション・サポートには、XAトランザクション・サポートとローカル・トランザクション・サポートの2つのタイプがあります。XAトランザクション・サポートでは、トランザクションをリソース・アダプタの外部にあるトランザクション・マネージャで管理できます。これに対して、ローカル・トランザクション・サポートでは、アプリケーション・サーバーでリソース・アダプタに対してローカルなリソースを管理できます。

2つのアダプタによりコミットまたはロールバックが1単位として確実に起動されるようにするには、次を実行する必要があります。

- 両方のアダプタの起動を、グローバル・トランザクションに関与するように構成する必要があります。

- 両方のアダプタの起動が、同じグローバル・トランザクションに関与する必要があります。

- いずれかの起動に失敗した場合は、グローバル・トランザクションをロールバックする必要があります。

注意:

XA以外のドライバはSOALocalTxDataSourceパラメータとともに使用する必要があります。XAドライバに切り替えると、製品の機能が破損します。

9.3.1.1 グローバル・トランザクションへの関与のための構成

デプロイメント・ディスクリプタ(weblogic-ra.xmlファイル)で、xADataSourceNameパラメータを設定する必要があります。また、Oracle WebLogic Serverコンソールでデータソースを作成して、参照されるDataSourceをトランザクションに関与するように構成する必要があります。

データソースを作成し、リストからXAデータソースを選択する必要があります。

注意:

実際のデータベースXAは、Oracle 10.2.0.4または11.1.0.7でのみ動作確認済です。以前のリリースでは、非XAデータソース実装を選択して次のページで「2フェーズ・コミットのエミュレート」を選択する方が安全です。

使用する非XAおよびXAデータソースの推奨設定については、「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。

Oracle WebLogic Serverではdata-sources.xmlファイルを編集できません。「データソースの作成」の説明に従って、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。

9.3.1.2 両方を同じグローバル・トランザクションで起動

両方のアダプタの起動が1単位としてコミットまたはロールバックするためにグローバル・トランザクションに関与する場合は、同じグローバル・トランザクションに関与する必要があります。BPELでは、そのためにトランザクション境界の位置、つまりチェックポイントでデハイドレーション・ストアに書き込み、現行のグローバル・トランザクションをコミットし、新規トランザクションを開始する位置を認識する必要があります。

BPELプロセスでのトランザクション境界は、ReceiveアクティビティまたはReceiveアクティビティの前、あるいはonMessageまたはPickアクティビティの前に発生します。次のサンプル・コードに示すように、パートナ・リンク上でbpel.config.transactionプロパティが設定されていないかぎり、これは同期の子BPELプロセスの起動時にも発生することがあります。

<property name="bpel.config.transaction">required</property>

それ以外の場合は、親プロセスが2つのトランザクションに分割され、子プロセスは固有のトランザクションで実行されます。

9.3.1.3 失敗時のロールバックが必須

最後に、両方の起動が同じグローバル・トランザクションに関与していても、一方の起動に失敗するとグローバル・トランザクションをロールバックできない場合があります。

失敗により実際にグローバル・ロールバックが発生可能なのは、次の場合のみです。

- ある書込みには成功しても他の書込みに失敗した後で、1回の起動の一部として複数の表を挿入または更新する操作に失敗した場合。この場合、起動操作はアトミックでなく、コミットするとデータが破損する可能性があるため、グローバル・トランザクションをロールバックのみとしてマーク付けします。

- データベース停止のシナリオで、グローバル・トランザクションがタイムアウトしてロールバックされるまで、起動が数回再試行される場合。

- BPELプロセス内で明示的なbpelx:rollbackフォルトがスローされる場合。

9.3.1.3.1 両方の起動に対する同一セッションの使用

両方の起動に同じセッションまたは接続を使用可能にするには、GetActiveUnitOfWork JCAパラメータをtrueに設定する必要があります。

GetActiveUnitOfWorkは、すべてのDBInteractionSpecに設定できる拡張JCAプロパティです。これにより、2フェーズ・コミット・コールバックに自己登録する起動とデータベースへのすべての書込みが、2フェーズ・コミットの一部として実行されます。障害発生時にこのプロパティを設定することで、この段階でフォルトを処理する方法がないため、トランザクションが自動的にロールバックされます。同様に、両方の起動には同じ基礎となるTopLinkセッションが使用されます。これは、同じオブジェクトを2回マージする場合、挿入または更新されるのは1回であることを意味します。GetActiveUnitOfWorkがtrueに設定されているすべてのマージの起動は、累積的です。

9.3.1.4 トランザクション/XAサポート

2つの起動が1単位としてコミットまたはロールバックされるようにするには、両方の起動がグローバル・トランザクションに関与するよう構成されていること、両方の起動が同じグローバル・トランザクションに関与していること、およびいずれかの起動に失敗した場合はグローバル・トランザクションがロールバックされるようになっていることが必要です。

9.3.1.4.1 グローバル・トランザクションへの関与のための構成

デプロイメント・ディスクリプタ(weblogic-ra.xml)で、xADataSourceNameを設定する必要があります。対応するデータソース・エントリは、グローバル・トランザクションに関与するように構成する必要があります。

実際のXA: 2フェーズ(XA)コミットと1フェーズ(エミュレート)コミットの違い

XAは2フェーズ・コミット・プロトコルで、1フェーズ・コミット/エミュレート・プロトコルよりも堅牢です。その違いは、1フェーズ・プロトコルでは、メッセージが消失したりロールバック/コミットの不整合が発生することは非常にまれではありますが、その割合は通常、1000当たり1程度はある点です。

Oracle RACの構成

Oracle RACの構成の詳細は、『Oracle Database高可用性概要』を参照してください。

サード・パーティのドライバを使用した実際のXA構成

サード・パーティのドライバ(Microsoft SQL Server 2008やIBM DB2など)に対して実際のXA構成を構成する場合、javax.sql.XADataSourceを実装するクラスがドライバのJarに含まれることを確認します。

データ直接ドライバの場合、ネーミングはcom.oracle.ias.jdbcx.db2.DB2DataSourceまたはcom.oracle.ias.jdbcx.sqlserver.SQLServerDataSourceである可能性があります。

9.3.1.4.2 失敗時のロールバックが必須

最後に、両方の起動が同じグローバル・トランザクションに関与していても、一方の起動に失敗するとグローバル・トランザクションをロールバックできない場合があります。

失敗により実際にグローバル・ロールバックが発生可能なのは、次の場合のみです。

- ある書込みには成功しても他の書込みに失敗した後で、1回の起動の一部として複数の表を挿入または更新する操作に失敗した場合。この場合、起動操作はアトミックでなく、コミットするとデータが破損する可能性があるため、アダプタはグローバル・トランザクションをロールバックのみとしてマーク付けします。

- データベース停止のシナリオで、グローバル・トランザクションがタイムアウトしてロールバックされるまで、起動が数回再試行される場合。

- BPELプロセス内で明示的なbpelx:rollbackフォルトがスローされる場合。WSDL内のGetActiveUnitOfWork="true"。

9.3.2 Pure SQL - XMLタイプのサポート

Pure SQLアダプタは、SQL文字列を直接入力してXSD/Webサービスを自動的に生成できるようにする、ウィザードのオプションです。データベース表はアダプタ構成ウィザードで動的にイントロスペクトされ、SQLがテストされてXSDファイルに適切に(有効な戻り型が)移入されます。

Pure SQLのサポートにより、表やビューをエンティティとして処理し、SQLで直接処理できます。Pure SQLを次の目的で使用できます。

- 単純なデータ予測スタイルのレポート問合せ

- select count(*)のように結果セットが表指向でない場合

- update allまたはdelete allを実行する場合

- XMLType列とxqueryで作業する場合

- アダプタ構成ウィザードの式ビルダーでモデル化されていない複雑なSQLを使用する場合

Pure SQLアダプタはOracle XMLTypeで使用できます。XMLをXMLType表および列に挿入し、xquery selectを使用してXMLを取得する操作に適しています。Pure SQLは、XML DB(XDB)サポートと並行するリレーショナル-xmlマッピングを提供するアダプタに適しています。そのため、XDBを使用する場合、XDBとXQueryに専念できるように、アダプタをできるかぎり軽量かつ透過的にする必要があります。

データがXML(非構造化/半構造化)形式で、データをマップできるリレーショナル・スキーマが存在しない場合は、XDBを使用できます。従来では、既存のリレーショナル・スキーマをWebサービスで使用するXMLスキーマとしてインポートできます。XDBのXML断片化アルゴリズムでは、永続的記憶域について既存のXMLスキーマからリレーショナル・スキーマを生成できます。

注意:

スキーマ・バインドXMLTypeを使用するにはociドライバが必要ですが、このドライバの動作はリリース11gでは確認されていません。そのため、実行時には非スキーマ・バインドXMLTypeを使用する必要がありますが、設計時にはスキーマ・バインドXMLTypeを使用して代表的なXSDをインポートできます。

詳細は、次を参照してください。

- 操作タイプの選択

9.3.3 強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート

REF CURSORはどのような結果セットもサポートできるため、設計時に生成されるXSDでもこれが許可され、次の例に示すようなXSDになります。

注意:

Oracle Databaseのストアド・プロシージャによって返される結果セットは、RefCursorsとして参照されるのに対し、サード・パーティ・データベースの場合、返される結果セットはRowSetsとして参照されます。

例 - 弱い型指定のXSD

<refCursorOutputParam>
<Row>
<Column name="DEPTNO" sqltype="NUMBER">20</Column>
...
</Row>
</refCursorOutputParam>

ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。

行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。強い型指定のXSDは、次の例に示すようなXSDになります。

例 - 強い型指定のXSD

<refCursorOutputParam>
<dept>
<deptno>20</deptno>
...
</dept>
</refCursorOutputParam>

アダプタ構成ウィザードを使用して、ストアド・プロシージャまたはファンクションのREF CURSOR変数によって返される行セットのための、強い型指定のXSDを作成できます。Oracle Databaseのファンクションは、常に1つの出力があり、かつ、select文内などにインラインで組み込むことができる特別なストアド・プロシージャです。このため、通常は更新を行いません。

この機能を使用すると、ストアド・プロシージャ(またはストアド・ファンクション)を選択してその引数を入力し、テスト実行を行って実際の行セットを取得できます。その後、返された行セットがアダプタ構成ウィザードでイントロスペクションされ、強い型指定のXSDが生成されます。引数はウィザードから簡単に入力できます。たとえば、数値や文字列を直接入力でき、日付をリテラルとして(2009/11/11)入力できます。また、MYOBJ('a', 'b')のような構造体を入力することもできます。

注意:

IBM DB2 UDBでは、ファンクションはサポートされていません。サポートされるのはSQLストアド・プロシージャのみです。

アダプタ構成ウィザードでの強い型指定のXSDの使用に関する行セットのサポートには、次の制限があります。

- Oracle Database PL/SQLのrecord型およびboolean型はサポートされていません。

- Oracle Database PL/SQLのvarrayはサポートされていません。

- Oracle Database PL/SQLの%rowtypeはサポートされていません。

- Oracle Database PL/SQLのtable型はサポートされていません。

- Oracle Database PL/SQLプロシージャでは、INのみのREF CURSORパラメータはサポートされていません。
REF CURSORをIN/OUTパラメータとして使用するOracle Database PL/SQLプロシージャの場合、アダプタ構成ウィザードではINが無視され、OUTパラメータに基づいて強い型指定のXSDが生成されます。

- refを使用したXSDの要素の参照はサポートされていません。

- SQL Server 2008のテーブル値関数およびCLR関数はサポートされていません。

次のサード・パーティ・データベースに対して強い型指定のXSDがサポートされています。

- Microsoft SQL Server 2005

- Microsoft SQL Server 2008

- IBM DB2 UDB 9.7

次のサード・パーティ・データベースに対して強い型指定のXSDはサポートされていません。

- IBM DB2 AS/400

- MySQL

- Informix Dynamic Server

- Sybase 15.0.2

詳細は、次を参照してください。

- ストアド・プロシージャおよびファンクションのサポート

- 強い型指定のXSDを使用した行セットのサポート

- 弱い型指定のXSDを使用した行セットのサポート

9.3.4 プロキシ認証のサポート

このリリースでは、プロキシ認証を使用してOracleデータ・ストアに接続できます。起動ごとに、次の新しいヘッダー・プロパティの組合せを設定できます。

- jca.db.ProxyUserName: OracleConnection.PROXYTYPE_USER_PASSWORDプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ・ユーザー名に設定します。

- jca.db.ProxyPassword: OracleConnection.PROXYTYPE_USER_PASSWORDプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ・ユーザー・パスワードに設定します。

- jca.db.ProxyCertificate: OracleConnection.PROXYTYPE_CERTIFICATEプロキシ・タイプを使用するには、このプロパティをbase64Binaryでエンコードされた、有効な証明書を含むbyte[]配列に設定します。
これは、プロキシされるユーザーの資格証明をデータベースに渡す、より暗号化された方法です。証明書には、エンコードされた識別名が含まれます。証明書を生成する1つの方法として、ウォレットを作成した後、そのウォレットをデコードして証明書を取得する方法があります。ウォレットはrunutl mkwalletを使用して作成できます。その後、生成した証明書を使用して認証を受ける必要があります。

- jca.db.ProxyDistinguishedName: OracleConnection.PROXYTYPE_DISTINGUISHED_NAMEプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ識別名に設定します。
この識別名は、プロキシされるユーザーのパスワードにかわるグローバル名です。

- jca.db.ProxyRoles: 使用するプロキシ・タイプに関係なく、このプロパティを必要に応じて設定し、プロキシ・ユーザーに関連付けられるロールをString[]配列として定義できます。この配列内の各java.lang.Stringがロール名に対応します。

- jca.db.ProxyIsThickDriver: OCIドライバを使用している場合、JDBCレベルのAPIにおけるthickドライバとthinドライバの差異に対応するには、このプロパティを値trueに設定します。

起動を実行するには、プロキシ接続をデータソースから取得する必要があります。

詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』の第10章「プロキシ認証」を参照してください。

9.3.5 大きなペイロードのストリーミング

ペイロードのストリーミングのサポートを有効化するには、図9-27 に示すように、ポーリング・オプションを指定する際に「ストリーミングの有効化」チェック・ボックスを選択する必要があります。この機能を有効化すると、ペイロードはメモリーDOM内のSOAランタイムで操作されるかわりにデータベースにストリーミングされます。この機能は、大きなペイロードの処理中に使用します。「ストリーミングの有効化」チェック・ボックスを選択すると、対応するブール・プロパティStreamPayloadがそれぞれの.jcaファイルに定義されているActivationSpecプロパティに追加されます。

9.3.6 スキーマ検証

SchemaValidation [false/true]プロパティは、新しく追加されたアクティブ化仕様プロパティで、.jcaファイルで構成できます。trueに設定すると、アダプタ(receiveアクティビティ用)により生成されたXMLファイルはすべて、XSDファイルと対照して検証されます。失敗時には、XMLレコードは拒否されますが、引き続き処理済としてマーク付けされます。

データベースには構造化された記憶域が用意されており、XSDファイルはウィザード自体により生成されます。ただし、自動生成XSDを編集して独自の制限を追加する場合、検証を開始する必要があります。たとえば、VARCHAR(50)フィールドをインポートする場合、自動生成XSDには最大長が50という制限があります。ただし、なんらかの理由でBPELプロセスで固定長22の値の処理のみが可能な場合は、XMLファイルを検証する必要があります。

9.3.7 高可用性

アクティブ/アクティブ設定で高可用性がサポートされます。アクティブ/アクティブ設定では、インバウンド・データベース・アダプタに対して分散ポーリング技術を使用して、同一データが重複して取得されないようにできます。詳細は、「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE(SKIP LOCKED)」を参照してください。他のアダプタと同様、Oracle Databaseアダプタをアクティブ/パッシブ設定内でのシングルトン動作に対して構成することもできます。これにより、アクティブ/パッシブ設定で動作するパフォーマンスの高いマルチスレッドのインバウンドインスタンスは、展開パターンに従ってクラスタ全体で複数のコンポジット・インスタンスを起動できます。データベース障害時や再起動時にも、高可用性機能をサポートします。DBアダプタは、メッセージを損失することなく、再度メッセージを取得します。

9.3.8 スケーラビリティ

次の各項では、複数のOracle BPEL PMまたはードに複数のプロセス・インスタンスをデプロイするためのベスト・プラクティスについて説明します。

- 分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE (SKIP LOCKED)

- 分散ポーリングのベスト・プラクティス2: 最初に単一ノードをチューニングする

9.3.8.1 分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE (SKIP LOCKED)

複数のOracle BPEL PMまたはノードに複数のプロセス・インスタンスをデプロイするための1つ目のベスト・プラクティスは、アダプタ構成ウィザードを使用して、アダプタ構成ウィザードの「分散ポーリング」チェック・ボックスを設定し、さらにMaxTransactionSizeを設定することです。

adapter _db.JCAプロパティNumberOfThreadsを設定することによって、アダプタ同時実行性が向上します。

この場合、Oracle Databaseでは、自動的に構文SELECT FOR UPDATE SKIP LOCKEDが使用されます。Microsoft SQLServerデータベースでは、構文はWITH (UPDLOCK,READPAST)になります。

SELECT FOR UPDATE SKIP LOCKEDでは、同時スレッドにより、使用可能な行の選択およびロックがそれぞれ試行されますが、ロックはフェッチ時にのみ取得されます。フェッチしようとしている行がロックされている場合、かわりに次のロックされていない行がロックおよびフェッチされます。複数のスレッドがすべて同じポーリング問合せを同時に実行する場合、各スレッドは、処理されていない行の非結合サブセットを比較的迅速に取得する必要があります。

9.3.8.1.1 SKIP LOCKEDの詳細

ロックのスキップに固有な点は、各スレッドが、その他のスレッドがすでに取得しているロックをスキップし、各スレッドが独自にロック済行のセットを取得できることです。その他のロック方法では、Selectが最初のロックを検出して待機するか、または即時に失敗します。これにより、データベース・アダプタでスケーリングできます。

これがSKIP LOCKED機能の概要ですが、SKIP LOCK機能を次のプロパティ、相互作用および依存関係の設定に関して詳細に検討することも重要です。

- NumberOfThreads: 同時スレッド数。

- PollingInterval: Oracleデータベース・アダプタがOracle Databaseに対するポーリング文を実行する間隔(秒単位)。

- MaxTransactionSize: 1つのトランザクションでDBからデータベース・アダプタにフェッチされる行の数。

- MaxRaiseSize: データベース・アダプタからBPELに1つのメッセージとして送信される行の最大数。

- RowsPerPollingInterval: 1ポーリング間隔で処理できるレコード数に対する制限。

データベース・アダプタの.jcaファイルがデプロイされると、NumberOfThreadsプロパティに基づいてポーリング・スレッドが作成されます。このようなスレッドは、相互に独立してポーリングされ、トランザクションを開始して、SELECT FOR UPDATE SKIP LOCKを開始します。

次に、すべての使用可能な行のデータベース・カーソルが返され、SELECTに一致するレコードがない場合、スレッドはトランザクションをリリースし、PollingIntervalプロパティに指定されている期間スリープします。

SELECTポーリング文に一致するレコードがデータベースに表示されると、各スレッドはスリープ後にウェイクアップし、トランザクションを開始して、SELECT FOR UPDATE SKIP LOCKを発行します。

この時点で、データベース・カーソルは返されていますが、今回は、SELECT基準に一致する行があります。各スレッドによって、MaxTransactionSizeプロパティで定義されている行数に対するFETCHが発行されます。

データベース(SKIP LOCKED)の行をロックし、他のFETCHがこれらの行を取得しないようにするのは、このFETCHです。これにより、各ポーリング・スレッドがSELECT、FETCHにのみ焦点を当てて、処理の重複を考慮せずに処理できます。

これにより、各スレッドに処理対象の独自の行セットが含まれるため、スレッドはフェッチした行に対するループ処理を実行し、MaxRaiseSizeプロパティに基づいてグループ化します。

各グループは構成された宛先に配信され、すべての行が正常に配信されると、トランザクションがコミットされます。

次に、各スレッドでは、配信された行数とRowsPerPollingIntervalプロパティで指定されている値が比較されます。配信された行数がRowsPerPollingIntervalプロパティの値以上である場合、スレッドはスリープします。配信された行数がRowsPerPollingInterval未満の場合、スレッドはプロセス全体を繰り返します。

ロッキングのスキップに関するPollingIntervalとMaxTransactionSizeの計算は、「PollingInterval、MaxTransactionSizeおよびActivationInstancesの詳細な構成」を参照してください

9.3.8.1.2 Oracle以外のデータベース

Oracle以外のデータベースでは、SELECT FOR UPDATEによって、同じ行が複数回処理できないことが安全に保証されますが、スケーラビリティが低下する場合があります。パーティション・フィールドを追加して使用するか、または2つ目のベスト・プラクティス、つまり、基本的には単一ノード上でマルチスレッド処理と展開を使用するかを検討する必要があります(「分散ポーリングのベスト・プラクティス2: 最初に単一ノードでチューニングする」を参照)。

注意:

分散アプローチによって、複数のアクティブ化インスタンスで同じ行が処理されないようにします。

このベスト・プラクティスを構成する場合は、次の各項も参照してください。

- PollingInterval、MaxTransactionSizeおよびActivationInstancesの詳細な構成

- パーティション・フィールド

- activationInstances

- 索引付けおよびNULL値

- ロッキングのスキップの無効化

- MarkReservedValueとロッキングのスキップ

- SequencingPollingStrategy (最終読取りまたは最終更新)

9.3.8.1.3 PollingInterval、MaxTransactionSizeおよびActivationInstancesの詳細な構成

分散シナリオの場合、各ポーリング・インスタンスでは、処理されていないすべての行をそのインスタンス単独で処理しようと試みるのではなく、負荷の分散が試行されます。このため、1つのインスタンスで一度にフェッチされる行数が、最大でもMaxTransactionSizeの行数のみとなります。

ロッキングのスキップを使用すると、完全なMaxTransactionSize行がフェッチされた場合、次のMaxTransactionSize行をただちに連続してフェッチできます。

これは、ロッキングのスキップを使用する場合、同時スレッドは相互にブロックされないので、1つのインスタンスがすべての行をフェッチする危険がないためです。

ただし、ロッキングのスキップを無効にしている場合は、すべてのスレッドが同じ行をロックしようとし、そのうちの1つだけがロックに成功します。その後、そのスレッドがMaxTransactionSizeの行数を処理し終えると、そのスレッドは次のポーリング間隔まで一時停止し、他のスレッドが行のロックと処理を行えるようになります。

したがって、分散ポーリングを有効にし、ロッキングのスキップを無効にしている場合の最大スループットは次のようになります。

NumberOfThreads x MaxTransactionSize/PollingInterval

注意:

MaxTransactionSizeを増やすことが必要となる場合がありますが、この値が大きすぎると、トランザクション・タイムアウトが発生するようになることがあります。表9-2 に、MaxTransactionSizeの安全な値を示します。

ロード・バランシングが目的である場合は、ロッキングのスキップを無効化した状態で分散環境のMaxTransactionSize設定を小さくしすぎると、MaxTransactionSizeによって速度が制限されるため、適切ではありません。MaxTransactionSizeは、ビジネス・プロセス全体の各CPUスループットに近い値に設定するのが最適です。このようにすると、ロード・バランシングは必要なときにのみ発生します。

表9-2 MaxTransactionSize値とMaxRaiseSize値

MaxTransactionSize

MaxRaiseSize

説明

10

1

順次ルーティングを使用する場合。

10行の場合、個別のインスタンスが10個使用され、10個のXMLレコードがSOAを通過します。

100

-

パラレル・ルーティングを使用する場合。

>= 100

MaxTransactionSize

アダプタを使用してできるかぎり迅速に行をストリーミングする場合。

ロード・バランシングが目的である場合は、1つの分散環境でMaxTransactionSizeの設定が小さすぎると、その分散環境によって速度が制限されるため、適切ではありません。MaxTransactionSizeは、ビジネス・プロセス全体の各CPUスループットに近い値に設定するのが最適です。このようにすると、ロード・バランシングは必要なときにのみ発生します。

分散ポーリングが設定されていない場合、アダプタでは、処理されていないすべての行を単一のポーリング間隔で処理しようとします。

9.3.8.1.4 パーティション・フィールド

分散シナリオでは、複数のサーバー上にポーリング・インスタンスが存在しますが、サーバーごとに複数のスレッドを構成することもできます。これらのアクティブ化インスタンスを構成すると、個別に行を処理することによって、ある程度の連携が可能となり、スケーリングが向上する場合があります。

そのためには、単に次のプロパティPartitionFieldをdb.jcaファイルに追加します。

<property name="PartitionField" value="ID"/>

activationInstancesを2に設定すると、アクティブ化インスタンス1および2(または0および1)はそれぞれ次のように実行されます。

SELECT ... WHERE ... AND MOD (ID, 2) = 0 FOR UPDATE SKIP LOCKED

および

SELECT ... WHERE ... AND MOD (ID, 2) = 1 FOR UPDATE SKIP LOCKED

アクティブ化インスタンス0は、依然として、他のサーバーでこのIDを持つその他のアクティブ化インスタンスと競合しますが、少なくともID 1を持つその他のアクティブ化インスタンスとは競合しません。

パーティション・フィールドが数値であり、modを適用することによって、行が均等に分散されることを確認します(つまり、この場合は、すべてのIDが偶数または奇数でないことを確認します)。

Oracle Databaseでは、db.jcaファイル・プロパティPartitionFieldを次のように設定することによって、パーティション・フィールドがrowidとなるように設定できます。

<property name="PartitionField" value="rowid"/>

これにより、SQLが実際に次のように変換されます。

SELECT ... WHERE ... AND MOD (dbms_rowid.rowid_row_number(rowid), 2) = [0/1] FOR UPDATE SKIP LOCKED

スケーラビリティはOracle Databaseのロッキングのスキップによってもたらされるため、パーティション・フィールドを設定することはお薦めしません。これは、より複雑なSQLを使用してデータベースのCPU使用率が増加することによって、コストがかかるためです。

9.3.8.1.5 activationInstances

T

アダプタ・フレームワーク・レベル・プロパティactivationInstances (composite.xml内で構成)は、分散シナリオ用のNumberOfThreadsと置換え可能です。

activationInstancesを5に、NumberOfThreadsを5に設定することは、一方を25に、もう一方を1に設定するのと同じです。追加の作業インスタンスはデータベース・アダプタの外部に作成されるため、これらはいかなる方法でも連携しません。したがって、マルチスレッドの単一ノード・シナリオでは、常にNumberOfThreadsのみを構成してください。分散ポーリングを有効化することによるデータベース・レベルの同時実行性制御がない場合は、重複が読み取られます。

注意:

分散クラスタ・シナリオでは、NumberOfThreadsとactivationInstancesのどちらを構成しても効果は同じです。非分散シナリオでは、NumberOfThreadsを使用する必要があります。したがって、常にNumberOfThreadsを使用し、activationInstancesは使用しないようにするのが無難と言えます。

詳細は、「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」を参照してください。

9.3.8.1.6 索引付けおよびNULL値

主キー、および結合表へのすべての外部キーに索引付け(および/またはこれらのキーに対してデータベース上に明示的な制約を追加)します。論理削除ポーリングを使用する場合は、状態列に索引付けします。NULL以外のMarkUnreadValueおよびMarkReadValueを構成します。

アウトバウンド・データベース・アダプタ上の最適なパフォーマンスのすべての操作(INSERTを除く)において、データベース・アダプタの主キーとして選択されている列のデータベースに索引を作成する必要があります。

索引がなく、かつ索引を作成しないことが適切である場合は、単一ノードのマルチスレッドのアプローチを使用できます(「分散ポーリングのベスト・プラクティス2: 最初に単一ノードをチューニングする」を参照)。この方法では、ポーリング問合せの1度の実行で全表スキャンが行われることがありますが、その場合、複数のスレッドで、すべての行を処理するまで結果セット全体が使用されます。分散アプローチを使用する場合は、行が排他的にロックされている(つまり、時間が指定されたトランザクションでロックされている)間にすべての作業が完了する必要があります。分散シナリオでは、選択が何度も繰り返して実行されるため、選択ごとに全表スキャンが実行されると、パフォーマンスに悪影響を及ぼす場合があります。

注意:

MarkUnreadValueがNULLとして構成されている場合は、パフォーマンスが著しく低下します。

9.3.8.1.7 ロッキングのスキップの無効化

Oracle Databaseでは、Oracle 8以降にロッキングのスキップを使用できるようになりましたが、ドキュメント化はOracle 11で行われました。互換性のない機能を無効化することが必要となる状況はほとんど発生しません。このような状況が発生した場合は、次の例に示すように、アプリケーションでデプロイしたra.xmlファイルでコネクタ・プロパティusesSkipLockingをfalseに設定できます。

例 - ra.xmlでのusersSkipLockingの構成

<?xml version="1.0" encoding="UTF-8"?>
<connector xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd" version="1.5">
...
<resourceadapter>
<outbound-resourceadapter>
<connection-definition>
...
<config-property>
<config-property-name>usesSkipLocking</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
...
</connection-definition>
...
</outbound-resourceadapter>
</resourceadapter>
</connector>

コネクタレベルのプロパティを構成する方法の詳細は、次の各項を参照してください。

- 『Oracle WebLogic Serverリソース・アダプタの開発』のra.xmlファイルの構成に関する項

- 『Oracle WebLogic Serverリソース・アダプタの開発』のリソース・アダプタのパッケージ化およびデプロイに関する項

注意:

データベース・アダプタ構成ウィザードおよびデータベース・アダプタ・ランタイムにより、次の条件のいずれかの下で、AND ROWNUM <= ?句がSQL文に追加されます。

- usesSkipLockingが"false"に設定されている

- MarkReservedValueが使用されている

- ReturnSingleResultSetが"true"に設定されている

追加されたAND ROWNUM <= ?により、SQL問合せから戻される行数が制限されます。ただし、AND ROWNUM <= ?句により、戻される行は、行が挿入された順番になっていない場合があります。AND ROWNUM <= ?句が問合せに追加されるのを防ぐために、アダプタdb.jcaファイルにプロパティを追加することができます。

<property name="UseRowNumClause" value="false"/>

AND ROWNUM <= ?句がない場合、戻される行は、行が挿入された順番になります。

9.3.8.1.8 MarkReservedValueとロッキングのスキップ

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。

以前は、複数のOracle BPEL Process ManagerまたはOracle Mediatorノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするための基本的なベスト・プラクティスは、ポーリング・ノードごとに一意のMarkReservedValueを指定してLogicalDeletePollingStrategyまたはDeletePollingStrategyを使用し、MaxTransactionSizeを設定することでした。

ただし、ロッキングのスキップが導入されたことによって、このアプローチは現在使用されなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけで、ロックが自動的にスキップされるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

- ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。

- 更新/予約した後、コミットし、新しいトランザクションで選択、という手順とは対照的に、すべての作業が1つのトランザクションに含まれます。このため、HA環境においてリカバリ不能の状況が発生するリスクが最小化されます。

- 一意のMarkReservedValueを指定する必要がありません。この指定を有効にするには、R${weblogic.Name-2}-${IP-2}-${instance}などの複雑な変数を構成する必要があります。

9.3.8.1.9 SequencingPollingStrategy (最終読取りまたは最終更新)

この分散アプローチは、削除または論理削除に基づくポーリング戦略で機能します。

順序付けポーリングに基づく戦略の作業は、最初にレコードが順番に処理されるため、分散できません。

たとえば、2つ目の行が1つ目の行よりも先に処理済としてマークされることはありません(最終読取りIDを2に設定することは、2だけでなく、1も処理済であることを意味します)。

ただし、順序付けポーリング戦略は、ソース表に対して更新後または削除後の処理を行う必要がなく簡潔であるため、非常に高速です。

順序付けポーリング戦略は、単一ノードでクラスタ上の展開とともに使用します。クラスタでの使用は引き続き安全ですが、ヘルパー表の最終読取りIDにアクセスするときには、かわりにSELECT FOR UPDATEが適用されます。

9.3.8.2 分散ポーリングのベスト・プラクティス2: 最初に単一ノードをチューニングする

複数のOracle BPEL PMまたはノードに複数のプロセス・インスタンスをデプロイするための次のベスト・プラクティスは、最初に単一ノードをチューニングする方法です。

Oracleデータベース・アダプタに高い負荷がかかるプロセス(データベース同士の統合など)では、単一Java仮想マシン(JVM)をチューニングして|NumberOfThreads|を大きくし、MaxTransactionSizeおよびMaxRaiseSizeに高い値を設定するのみで、パフォーマンスを10から100倍に向上できます。

「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE (SKIP LOCKED)」で説明するように、単一ノードでのパフォーマンスを向上させ、必要に応じてクラスタ内の複数のノードに展開することが最適である場合があります。データベースの同時実行性制御機能(ロックなど)への依存性が高くなる可能性がありますが、これらの機能は、通常、パフォーマンスの高いスケーラビリティよりもデータ整合性を保持することを重視して設計されています。

クラスタ内の単一ノード上でポーリングを行うことが最適となるケースとして、煩雑でない順序付けポーリング戦略、索引付けされていない大規模な表のポーリング、または同時実行性が高いロック(ロックのスキップなど)が備えられていないOracle以外のバックエンド・データベースを使用するケースなどがあります。

注意:

クラスタ環境でポーリング操作を使用する場合は、アダプタ構成ウィザードで「分散ポーリング」チェック・ボックスを選択して、分散ポーリングのオプションを使用する必要があります。

必要であれば、「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」も参照してください。

9.3.9 パフォーマンス・チューニング

多くのパフォーマンス最適化で事前構成されています。ただし、パフォーマンス・チューニングを実装することで、変更を加えてデータベースへのラウンドトリップの回数を減らせます。

パフォーマンス・チューニングの詳細は、次の各項を参照してください。

- パフォーマンスのチューニングのOracle JCA Adapter for Databaseのチューニングに関する項

- パフォーマンスのチューニングのインバウンド・データベース・アダプタのチューニングに関する項

9.3.10 detectOmissions機能

detectOmission機能の特長は、次のとおりです。

使用可能なリリース

リリース10.1.3以上

構成可能

はい

デフォルト値

設計時: true(明示的にfalseに設定しない場合)

使用例

ユーザーは、マージ、更新または挿入対象とする不完全または部分的なXMLを渡して、XMLで未指定の各列がデータベースでNULLに設定されていることを確認できます。

この機能により、DBAdapterのmerge、insertまたはupdateでは、XML文書内のnull値と欠落値(省略)を区別できます。XML内のどの情報が有効で、どの情報が無効であるかは、事例ごとに判別されます。このようにして、XMLは完全な表現ではなくデータベース行の部分表現とみなされます。次の表に、NULL値と省略可能な値の例を示します。

表9-3 NULL値の例

要素タイプ

省略

NULL

列

<director></director>

<director />

<!-- director>…</director -->

<director xsi:nil="true" />

1-1

<!-- dept> … </dept -->

<dept xsi:nil="true" />

1-M

<!-- empCollection>…

</empCollection -->

</empCollection>

</empCollection>(空)

注意:

1-1の表現<dept />は空の部門オブジェクトであり、使用しないことを示します。1-Mの場合、<empCollection />は実際には0要素のコレクションを意味し、有効な値とみなされます。列の場合、空の文字列を表す<director></director>は省略とはみなされません。

省略と見なされた値は、UPDATEまたはINSERT SQLから省略されます。更新操作の場合、データベース上の既存の(有効な)値は上書きされません。挿入操作の場合、SQL文字列では明示的な値が提供されないため、データベース上のデフォルト値が使用されます。

DBAdapter receiveでは、省略を含むXMLを生成できず、xsi:nil="true"が使用されます。xsi:nil="true"に設定して入力XMLを生成できない場合、または<director />と<director></director>の違いが問題になる場合は、JCAファイルでDetectOmissions="false"に設定するのが最善の方法です。

更新を予期している場合は、1-1および1-M関係を省略することでパフォーマンスを改善できます。merge操作ではディテール・レコードの考慮を完全にスキップできます。

または、必要な列のみをマップし、起動ごとに個別のマッピングを作成できます。2つのupdateで2つの異なる列セットを更新する場合は、2つの個別partnernlinksを作成します。

パフォーマンス

デフォルトでは、省略を含むXMLは入力として使用されません。省略を含むXMLが検出されるまで、パフォーマンス上のオーバーヘッドは存在しません。

省略が検出されると、TopLink descriptor event listenerが追加されます。このevent listenerはなんらかのオーバーヘッドを伴い、SQLUpdateまたはSQLInsertになろうとする各modifyRowは省略をチェックするために繰り返される必要があります。したがって、データベースに送信される各列値がチェックされます。入力XMLの大部分が省略の場合、コストのオーバーヘッドはデータベースに送信する値を減らすことで補正する場合よりも大きくなります。

互換性のない相互作用

DirectSQL="true"およびDetectOmissions="true" - DetectOmissionsが優先されます。互換性のない相互作用の例を次に示します。

- DetectOmissionsMerge

- IgnoreNullsMerge

- OptimizeMerge

注意:

古いBPELプロジェクトを移行した場合は、JCAファイルを再生成するためにデータベース・アダプタ・ウィザードを再実行する必要があります。データベース・アダプタ・ウィザードを再実行すると、JCAファイルにDetectOmissionsおよびOptimizeMergeオプションが表示され、デフォルト値としてDetectOmissions="false"およびOptimizeMerge="false"が設定されます。

詳細は、次を参照してください:

また、Oracle Technology Networkからもフォーラムにアクセスできます。

- Oracle BPEL Process Managerフォーラム

http://forums.oracle.com/forums/forum.jspa?forumID=212

- TopLinkフォーラム

http://forums.oracle.com/forums/forum.jspa?forumID=48

このサイトには、ネイティブ順序付けの実装、オプティミスティック・ロック、およびTopLinkを使用したJTA管理の接続プーリングなど、2,000を超えるトピックがあります

http://www.oracle.com/technology

9.3.11 OutputCompletedXml機能

OutputCompletedXmlは、アウトバウンドのinsertアクティビティの機能です。OutputCompletedXml機能の特長は、次のとおりです。

使用可能なリリース

リリース10.1.2.0.2以上

構成可能

OutputCompletedXmlは、デフォルトがtrueの場合にのみJCAファイルに表示されます。

デフォルト値

OutputCompletedXmlは、TopLinkの順序付けがデータベース順序からのinsertに主キーを割り当てるように構成されている場合はtrue、それ以外の場合はfalseです。

問題点

データベース順序からのinsertに主キーを自動割当てできます。ただし、insert/mergeには出力メッセージがなく、どの主キーが割り当てられたかを指示する手段がないため、この機能の有用性は減少しています。

注意:

順序付け(リンク)の構成後にアダプタ構成ウィザードを再実行してください。これにより、出力メッセージとWSDLプロパティOutputCompletedXml="true"を使用してinsert/merge WSDL操作を再生成できます。

パフォーマンス

output XMLが提供されるのは、output XMLが大幅に異なる場合のみです。そのため、TopLinkの順序付けが使用されない場合、この機能は無効化され、パフォーマンス・ヒットはありません。また、この機能は明示的に無効化することも可能です。同様に、オリジナルの入力XMLが更新されて戻され、まったく新しいXMLが作成されることはありません。また、主キーがディテール・レコードに割り当てられている場合は、XMLのシャロー・アップデートのみが実行され、出力XMLには反映されません。

互換性のない相互作用

DirectSQL="true"およびOutputCompletedXmlが存在する場合は、OutputCompletedXmlが優先されます。

9.3.12 インバウンドおよびアウトバウンド・トランザクションのQueryTimeout

アダプタ構成ウィザードの「詳細オプション」ページでQueryTimeoutを構成できます。この機能により、同じ名前のjava.sql.Statementレベル・プロパティが公開されます。基本的には、QueryTimeoutを使用するとコール時のタイムアウトを構成できます。

9.3.13 BPELへの同期ポストの実行(順序配信の許可)

この機能では、起動全体が単一スレッドとグローバル・トランザクションで実行されます。デフォルトでは、開始は非同期で、BPELプロセスは別のグローバル・トランザクションで起動されます。これはOracle BPELプロセスにのみ固有であるため、Oracle Mediatorを使用する場合、これは通常は同期起動です。

この機能を有効化するには、アダプタ構成ウィザードの「操作」ページで「BPELへの同期ポストの実行(順序配信の許可)」オプションをクリックします。

9.4 概念

この項には、Oracleデータベース・アダプタの概念に関する次の項目が含まれます。

- リレーショナルからXMLへのマッピング

- WebサービスとしてのSQL操作

9.4.1 リレーショナルからXMLへのマッピング

この項には、リレーショナルからXMLへのマッピングに関する次の項目が含まれます。

- リレーショナル型からXMLスキーマ型へ

- 任意のリレーショナル・スキーマの任意のXMLスキーマへのマッピング

- 複数の表の問合せ

フラット表またはスキーマでは、リレーショナルからXMLへのマッピングを簡単に参照できます。表の各行は複合XML要素になります。各列の値はXML要素のテキスト・ノードになります。列値およびテキスト要素のどちらもプリミティブ型です。

表9-4 に、MOVIES表の構造を示します。この表は、この章で説明する使用例で使用されます。詳細は、「Oracleデータベース・アダプタの使用例」を参照してください。

表9-4 MOVIES表の説明

名前

NULLかどうか

タイプ

TITLE

NULL以外

VARCHAR2(50)

DIRECTOR

--

VARCHAR2(20)

STARRING

--

VARCHAR2(100)

SYNOPSIS

--

VARCHAR2(255)

GENRE

--

VARCHAR2(70)

RUN_TIME

--

NUMBER

RELEASE_DATE

--

DATE

RATED

--

VARCHAR2(6)

RATING

--

VARCHAR2(4)

VIEWER_RATING

--

VARCHAR2(5)

STATUS

--

VARCHAR2(11)

TOTAL_GROSS

--

NUMBER

DELETED

--

VARCHAR2(5)

SEQUENCENO

--

NUMBER

LAST_UPDATED

--

DATE

対応するXMLスキーマ定義(XSD)を次の例に示します。

例 - 映画コレクションのXSD

<?xml version = '1.0' encoding = 'UTF-8'?>
<xs:schema targetNamespace="http://xmlns.oracle.com/
pcbpel/adapter/db/top
/ReadS1" xmlns="http://xmlns.oracle.com/pcbpel/
adapter/db/top/ReadS1" elementFormDefault=
"qualified" attributeFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="MoviesCollection"
type="MoviesCollection"/>
<xs:complexType name="MoviesCollection">
<xs:sequence>
<xs:element name="Movies" type="Movies"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Movies">
<xs:sequence>
<xs:element name="title">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="50"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="director" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="20"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="starring" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="100"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="synopsis" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="genre" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="70"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="runTime" type="xs:decimal"
minOccurs="0"
nillable="true"/>
<xs:element name="releaseDate" type="xs:dateTime"
minOccurs="0"
nillable="true"/>
<xs:element name="rated" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="rating" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="4"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="viewerRating" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="5"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="status" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="11"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="totalGross"
type="xs:decimal" minOccurs="0"
nillable="true"/>
<xs:element name="deleted" minOccurs="0"
nillable="true">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="5"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="sequenceno" type="xs:decimal"
minOccurs="0"
nillable="true"/>
<xs:element name="lastUpdated" type="xs:dateTime"
minOccurs="0"
nillable="true"/>
</xs:sequence>
</xs:complexType>
</xs:schema>

前述のコード例が示すように、MOVIESは、XML文字列全体を含む単一のCLOBまたはXMLTYPE列ではありません。そのかわり、XML complexType要素で構成されており、それぞれの要素はMOVIES表の各列に対応しています。フラット表の場合、リレーショナルからXMLへのマッピングは簡単です。

表9-5 と表9-6 に、EMPおよびDEPT表の構造をそれぞれ示します。これらの表は、MasterDetailの使用例で使用されます。詳細は、「Oracleデータベース・アダプタの使用例」を参照してください。

表9-5 EMP表の説明

名前

NULLかどうか

タイプ

EMPNO

NULL以外

NUMBER(4)

ENAME

--

VARCHAR2(10)

JOB

--

VARCHAR2(9)

MGR

--

NUMBER(4)

HIREDATE

--

DATE

SAL

--

NUMBER(7,2)

COMM

--

NUMBER(7,2)

DEPTNO

--

NUMBER(2)

表9-6 DEPT表の説明

名前

NULLかどうか

タイプ

DEPTNO

NULL以外

NUMBER(2)

DNAME

--

VARCHAR2(14)

LOC

--

VARCHAR2(13)

前の表定義が示すように、典型的な正規化されたリレーショナル・スキーマであるため、EMP表には従業員の部門番号が格納されていません。そのかわり、EMPの列の1つ(DEPTNO)は外部キーで、DEPTの主キー(DEPTNO)に相当します。

ただし、対応するXMLファイルには主キーおよび外部キーに類似の概念はありません。このため、結果のXMLファイルでは同一のデータが階層で表されます。したがって、リレーションシップは、マスター内部に埋め込まれたディテール・レコードを取得することで保持します。

XML要素には、プリミティブ型(stringやdecimal)または別のXML要素である複合型のいずれかの要素を含めることができます。そのため、従業員の要素に部門の要素を含めることができます。

対応するXMLで、リレーションシップがどのように表現され、インラインでどのように表示されるかを示します。EMPからはDEPTNOが削除され、DEPT自体が表示されています。

<EmpCollection>
<Emp>
<comm xsi:nil = "true" ></comm>
<empno >7369.0</empno>
<ename >SMITH</ename>
<hiredate >1980-12-17T00:00:00.000-08:00</hiredate>
<job >CLERK</job>
<mgr >7902.0</mgr
<sal >800.0</sal>
<dept>
<deptno >20.0</deptno>
<dname >RESEARCH</dname>
<loc >DALLAS</loc>
</dept>
</Emp>
...
</EmpCollection>

リレーションシップを表現することで人間がXMLを読み取ることが可能になり、データを情報の1つのパケットとして送信できます。XMLファイルでは循環が許可されていないため、要素はそれ自体を含むことはできません。これは自動的に処理されます。

ただし、重複の可能性があります(つまり、異なるマスター・レコードで、同じXMLディテール・レコードが2回以上出現するということです)。たとえば、問合せで同じ部門で働く2人の従業員が返された場合、返されたXMLではどちらのEMPレコードにも同じDEPTレコードがインラインで出現します。

そのため、表をインポートしてXMLとしてマッピングする際には、アダプタ内の要素は出力されませんが、過剰な重複は避ける必要があります。次を出力します。

<Emp>
<name>Bob</name>
<spouse>
<name>June</name>
</spouse
</Emp>

次のようには出力されません。

<Emp>
<name>Bob</name>
<spouse>
<name>June</name>
<spouse>
<name>Bob</name>
<spouse>
...
</spouse>
</spouse>
</spouse>
</Emp>

重複を回避するには、次のようにします。

- 複数の表をインポートします。EMPのみをインポートすると、DEPTが表示されません。

- アダプタ構成ウィザードで、EMPとDEPTのリレーションシップを削除します。これでリレーションシップは削除されますが、外部キー列が元に戻ります。

どちらの場合も、対応するXMLは次のとおりです。

<EmpCollection>
<Emp>
<comm xsi:nil = "true" ></comm>
<empno >7369.0</empno>
<ename >SMITH</ename>
<hiredate >1980-12-17T00:00:00.000-08:00</hiredate>
<job >CLERK</job>
<mgr >7902.0</mgr>
<sal >800.0</sal>
<deptno >20.0</deptno>
</Emp>
...
</EmpCollection>

前述のどちらの解決策も、ディテール・レコードを完全に元に戻すのではなく、外部キーを元に戻すことで十分な場合にのみ適切です。

9.4.1.1 リレーショナル型からXMLスキーマ型へ

表9-7 に、データベースから表をインポートする際に、データベースのデータ型がどのようにXMLのプリミティブ型に変換されるかを示します。

表9-7 データベースのデータ型のXMLのプリミティブ型へのマッピング

データベース・タイプ

XMLタイプ(接頭辞はxs:)

VARCHAR、VARCHAR2、CHAR、NCHAR、NVARCHAR、NVARCHAR2、MEMO、TEXT、CHARACTER、CHARACTER VARYING、UNICHAR、UNIVARCHAR、SYSNAME、NATIONAL CHARACTER、NATIONAL CHAR、NATIONAL CHAR VARYING、NCHAR VARYING、LONG、CLOB、NCLOB、LONGTEXT、LONGVARCHAR、NTEXT

string

BLOB、BINARY、IMAGE、LONGVARBINARY、LONG RAW、VARBINARY、GRAPHIC、VARGRAPHIC、DBCLOB、BIT VARYING

base64Binary

BIT、NUMBER(1) DEFAULT 0、SMALLINT DEFAULT 0、SMALLINT DEFAULT 0

boolean

TINYINT、BYTE

byte

SHORT、SMALLINT

short

INT、SERIAL

int

INTEGER、BIGINT

integer

NUMBER、NUMERIC、DECIMAL、MONEY、SMALLMONEY、UNIQUEIDENTIFIER

decimal

FLOAT FLOAT16、FLOAT(16)、FLOAT32、FLOAT(32)、DOUBLE、DOUBLE PRECIS、REAL

double

TIME、DATE、DATETIME、TIMESTAMP、TIMESTAMP(6)、SMALLDATETIME、TIMESTAMPTZ、TIMESTAMPLTZ、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE

dateTime

NUMBERは最も用途の広い数値用のXMLデータ型であるdecimalに、VARCHAR2とCLOBはstringに、BLOBはbase64Binary(プレーン・テキスト要件を満たすため)に、DATE型はdateTimeに変換されます。

ここで説明されていない型は、デフォルトでjava.lang.Stringおよびxs:stringになります。

サポートされているのがxs:dateTime形式のみであるため、タイムスタンプのサポートは基本的です。BFILE型は明確にサポートされていません。

注意:

ユーザー定義のObject、Struct、VARRAYおよびREF型は、リリース11gおよび12でサポートされています。

XMLはプレーン・テキストであるため、BLOBおよびbyteの値はbase 64/MIMEでエンコードされ、文字データとして渡されます。

9.4.1.2 任意のリレーショナル・スキーマの任意のXMLスキーマへのマッピング

リレーショナル・データベース上の任意のリレーショナル・スキーマの、任意のXMLスキーマへのマッピングがサポートされています。ただし、要素のレイアウトに対する明確なユーザー制御がない状態でアダプタ構成ウィザードによりXMLスキーマが生成されるため、ユーザーはXMLスキーマを選択できません。

スキーマのマッピング方法は、「アダプタ構成ウィザード」で制御することも、後からTopLink Workbenchで制御することもできます。トランスフォーメーション・ステップと関連付けることで、任意のリレーショナル・スキーマを任意のXMLスキーマにマッピングできます。

9.4.1.3 複数の表の問合せ

複数の関連表に対するSQL select文を実行する場合、SQLを作成するには次の3つの方法があります。これらの方法は、マスター・レコードに対する問合せ時にディテール・レコードを取り込む方法に関係しています。

- リレーションシップの問合せを使用する方法(TopLinkのデフォルト)

- オリジナルのselectを利用する方法(TopLinkのバッチ属性読取り)

- 単一結果セットを戻す方法(TopLinkの結合属性読取り)

- 複数の表の問合せに使用した方法の比較

以降の各項では、この3つの方法を比較しながら説明します。単一表から行を選択する場合は、複数の表から選択する場合のような問題が存在しません。

9.4.1.3.1 リレーションシップの問合せを使用する方法(TopLinkのデフォルト)

単一のMaster行を選択すると、TopLinkでは常に個別に問合せを行い、そのMaster表に属するディテールをすべて取得できます。このような隠れた問合せ(リレーションシップの問合せ)はTopLinkのメタデータで捕捉され、準備するのは1回のみです。

次のサンプル・シナリオのSQL文を考えてみます。

SELECT DIRECTOR, ..., VIEWER_RATING
FROM MOVIES
WHERE RATING = 'A';

このSQL文はマスターごとに次のようになります。

SELECT CRITIC, ..., TITLE
FROM MOVIE_REVIEWS
WHERE (TITLE = ?)

問合せを1+n回実行してすべてのデータを取り込むことができます。nは、1回目の問合せで戻されるマスターの行数です。

このアプローチは安全ですが、すべてのデータを取得するためにデータベースへのラウンドトリップが多数必要になるため低速です。

リレーションシップの問合せを使用するアプローチ(TopLinkのデフォルト)を使用して構成する場合は、JDeveloperの外部でor_mappings.xmlを編集する必要があります。また、batch-reading要素の値をfalseに変更してください。

9.4.1.3.2 オリジナルのselectを利用する方法(TopLinkのバッチ属性読取り)

これはデフォルト機能で、次の例に示すように、TopLinkは第2のselect文ですべてのディテールを読み取るように、オリジナルのSQL select文を変更できます。

SELECT DIRECTOR, ..., VIEWER_RATING
FROM MOVIES
WHERE RATING = 'A'
SELECT DISTINCT t0.CRITIC, ..., t0.TITLE
FROM MOVIE_REVIEWS t0, MOVIES t1
WHERE ((t1.RATING = 'A') AND (t0.TITLE = t1.TITLE))

オリジナルのselect文でディテールを取得することを考慮して、問合せを合計2回(1+1=2)実行する必要があります。

メリット

バッチ属性読取りには、次のメリットがあります。

- すべてのデータがデータベースへの2回のラウンドトリップで読み取られます。

- これは、リリース10.1.2.0.2のデフォルト機能です。

デメリット

バッチ属性読取りには、次のデメリットがあります。

- maxTransactionSize (RECEIVEのポーリング時)またはmaxRows (SELECTの起動時)を使用してメモリーに1回にロードされる行数を制限する場合、この設定ではバッチ属性問合せの持ち越しが容易ではありません。結果セットが1つのみの場合は、カーソル付きの結果を操作する方が容易です。(オリジナルの問合せにORDER BY句があると、複数カーソルの使用が困難な場合があります)。

- TopLinkでSQL文を変更できるのは、認識可能なフォーマットが使用されている場合のみです。ハイブリッドSQLアプローチを使用し、ルートselectにカスタムSQLを設定すると、TopLinkでは、そのSQLを解析してバッチselectを作成できません。

- バッチ問合せでは、2つのマスターがどちらも同じディテールを指している場合に、同じディテールが2回戻されないように、DISTINCT句を使用します。結果セットでLOBを戻す場合、DISTINCT句は使用できません。

構成

構成は、1-1または1-Mマッピングに基づきます。リリース10.1.2.0.2以降は、これらのマッピングすべてにデフォルトでこのプロパティが設定されています。構成するには、JDeveloperの外部でor_mappings.xmlを編集し、<batch-reading>要素をtrue (デフォルト)またはfalseに編集します。

9.4.1.3.3 単一結果セットを戻す方法(TopLinkの結合属性読取り)

ディテール表はオリジナルのSQL select文に外部結合され、次の例に示すようにマスターとディテールの両方を1つの結果セットで戻します。

SELECT DISTINCT t1.DIRECTOR, ..., t1.VIEWER_RATING, t0.CRITIC, ..., t0.TITLE
FROM MOVIE_REVIEWS t0, MOVIES t1
WHERE ((t1.RATING = 'A') AND (t0.TITLE (+) = t1.TITLE))

このため、実行する必要のある問合せは合計1回となります。

メリット

次のようなメリットがあります。

- ポーリング中にmaxTransactionSizeを使用する場合、単一カーソルの処理によるメリットが大きくなります。

- ハイブリッドSQLのルートをたどってカスタムSQL文に入る場合、処理する必要のあるSQL文は1つのみですが、通常、TopLinkでは非表示の一連のSQL文をさらに使用して関連行を取り込みます。

- read一貫性: 様々な表について異なるインスタンスで読み取るのではなく、同時にすべての関連行を読み取ることができます。

- データベースへのラウンドトリップが1回のみですむためパフォーマンスは理想的ですが、バッチ属性読取りは問合せ対象の表ごとに1回ずつ必要です。

デメリット

ただし、重複データを戻すコストなど、デメリットもいくつかあります。たとえば、Master表とDetail表を読み取る場合に、Masterには各行に100列、Detailには各行に2列が含まれているとします。Master表の各行には、通常、関連するDetail行も100行含まれています。

各表で1回問合せすると、前述の例の結果セットは次の例のようになります。

Master
Column1 column2 ….. column100

Master1 ...

Detail

Detail
Column1 column2
Detail1   ...
Detail2
...
Detail100 ...

この例では、300列の値が次のように戻されます。

(columns in master + columns in detail x details per master) =
(           100             +            2                x              100         )  =  300

すべての表に対して1回問合せすると、結果セットは次の例のようになります。

Master                                             Detail

Column1 Column2 ... Column100                      Column1  Column2
Master1    ...                                     Detail1     ...
Master1    ...                                     Detail2     ...
Master1    ...                                     Detail100   ...

2つの結果セットでは300列の値が戻されるのに対して、すべての表を1回問合せすると、次のように単一の結果セットで10,200列の値が戻されます。

((columns in master + columns in detail) x details per master) =
((          100     +            2     ) x       100         ) =  10,200

この場合、戻されるデータの97パーセントは重複データであるため、ネットワーク通信量と計算の重大な浪費となる可能性があります。また、マスターに2つの関連表detail1およびdetail2があり、各マスターに100列があると、戻される列値の数はマスター行ごとに1,000万以上になります。

通常は、次の単純な算式を使用して、単一の結果セットですべての行を戻す場合の相対コストを予想できます。

(Master columns + Detail1 columns + Detail2 columns + ... ) x
Detail1s per Master x
Detail2s per Master x ...
bloat = ___________________________________________________________

(Master columns + Detail1 columns X Detail1s per Master +
Detail2 columns X Detail2s per Master + ...)

1-1関係の場合、この値は常に1であり、同じ例でマスター行ごとに2列のみで、ディテールに100列があり、マスター各行にそれぞれ3または4行のディテールしかなければ、膨張度は次のようになります。

(2 + 100) x 4        408
bloat =        ____________  = ___________  ~=  1
(2 + 100 x 4)        402

もう1つのデメリットは、この設定ではアウトバウンドSELECTのmaxRows設定の意味に歪みが生じることです。

構成

構成するには、アダプタ構成ウィザードの「選択条件の定義」ページで「外部結合を使用してマスター表とディテール表の両方の単一結果セットを返す」を選択します。

注意:

TopLinkの式ビルダーを使用して次のようなSQL問合せを作成すると、予期した結果が得られない場合があります。

SELECT DISTINCT t1.TABLE1_ID, t1.COLUMN_A FROM TABLE2 t0,
TABLE1 t1 WHERE ((t0.STATUS = 1) AND (t0.TABLE1_ID = t1.
TABLE1_ID))

この問合せに予期される結果は、表1とそれが所有する表2でstatus = 1の行のみが戻されることです。

ただし、この問合せでの実際の意味は「表2のいずれかがstatus = 1であれば表1」となり、選択基準に一致する表1と、表1が所有するすべて(ALL)の表2が、status = 1かどうかに関係なく他のステータスのものも含めて戻されます。DISTINCTキーワードにより、表1が繰り返されず、表2にまたがって結合が発生することが保証されます。

解釈の誤りは、TopLinkの動作に発生します。式ビルダーでは、表1の選択基準しか指定できず、表1が所有する表2は制御されないため、この部分は自動的に実行されます。

ただし、次の2つのアプローチのいずれかを使用すると、予期した結果を取得できます。

1.)選択基準にstatus = 1を使用して表2を直接問い合せます。つまり、表1を通過して表1が所有する表2を取得することはしません。

2.)次の例のように直接(カスタムSQL)を使用します。

SELECT TABLE1.TABLE1_ID, TABLE1.COLUMN_A, TABLE2.STATUS
FROM TABLE2, TABLE1 WHERE TABLE2.STATUS=1 AND TABLE1.
TABLE1_ID = TABLE2.TABLE1_ID

9.4.1.3.4 複数の表の問合せに使用した方法の比較

表面上は、単一結果セットを戻すのが最善の方法(1回の問合せ)で、次にバッチ属性読取り(select文の変更、2回の問合せ)、最後にデフォルトのリレーションシップの読取り(n+1回の問合せ)となります。ただし、より高度なオプションにはどちらもいくつか問題があります。

ユーザー定義SQLの変更

custom/hybrid SQLを指定すると、TopLinkでは、そのSQL文字列を変更してディテールのselectを作成することができません。このため、hybrid SQLを使用せず、できるだけ頻繁にウィザードのvisual expression builderを使用してselectsを作成する必要があります。

SQLの表示

デフォルトおよびバッチ属性読取りでは、どちらの場合も、TopLinkにより実行される追加の問合せがユーザーにとってわかりにくくなることがあります。このため、アダプタ構成ウィザードでユーザーに表示されるraw SQLは、わかりやすく管理しやすいように単一の結果セットを戻すことを想定しています。

1度に戻される行数が多すぎる

データベースには膨大な情報を格納でき、select文には1度に戻される情報が多すぎるという共通の問題があります。データベース・アダプタのreceiveでは、maxTransactionSizeプロパティを設定して、一度にカーソル付き結果セットから読み取られてメモリー内で処理される行数を制限できます。select文の1回の起動用に、類似のmax-rows設定が存在します。ただし、この設定は大きなリスクを伴います。

9.4.2 WebサービスとしてのSQL操作

リレーショナル・スキーマをXMLとしてマッピングした後、基本的なSQL操作もWebサービスとしてマッピングする必要があります。いくつかの操作では直接SQL等価に変換されますが、その他はより複雑です。

この項には次のトピックが含まれます:

- DML操作

- ポーリング戦略

9.4.2.1 DML操作

データ操作言語(DML)の操作は、基本的なSQLのINSERT、UPDATEおよびSELECT操作と同等です。SQLのINSERT、UPDATE、DELETEおよびSELECTは、すべて同じ名前のWebサービス操作にマッピングされます。MERGEは、存在チェックの結果に基づき、INSERTまたはUPDATEのいずれかになります。アウトバウンド書込みと呼ばれるデータ操作とアウトバウンド読取りと呼ばれるSELECT操作とで区別されます。merge(アウトバウンド書込みのデフォルト)およびqueryByExampleに関するWebサービスとSQLとの関係は、基本的なSQLのINSERT、UPDATEおよびSELECTとの関係ほど明確ではありません。

この項には次のトピックが含まれます:

- Merge

- querybyExample

Merge

Mergeでは、まずデータベースの対応するレコードが読み取られて変更箇所が算出され、最低限の更新が実行されます。INSERT、UPDATEおよびMERGEは、単一の行および表が作業対象の場合に最も適切です。ただし、XMLには複合型が含まれ、複数の表の複数の行にマッピングされます。たとえば、DEPTに多数のEMPSがあり、それらのそれぞれにADDRESSがあるとします。この場合、変更された可能性のある行がどのくらいで、どの行を挿入、更新または削除すればよいかを算出する必要があります。特定の行が変更されなかったか、1つのフィールドのみが変更された場合、DMLコールは最小限になります。

querybyExample

SELECT操作とは異なり、queryByExampleには設計時に指定する選択基準はありません。そのかわり、各invokeでは、典型的な入力XMLレコードから選択基準が推測されます。

たとえば、出力のxmlRecordが従業員レコードで、入力がlastName = "Smith"を含むサンプルのxmlRecordである場合、実行時には姓がSmithの従業員がすべて返されます。

queryByExampleのサブセットは、主キーで問合せを行うためのもので、主キー属性のみが設定されているサンプルのXMLレコードに渡すことで実装できます。

視覚的なクエリー・ビルダーを使用して問合せを作成する必要がない場合や、出力レコードと同様に入力レコードでも同じXMLスキーマを共有する柔軟性が必要な場合にqueryByExampleを使用します。

queryByExample操作では、実行ごとに新しいSELECTを準備する必要があるため、ややパフォーマンスが低下します。これは、サンプルのXMLレコードに設定されている属性が毎回異なり、選択基準が変わるためです。

入力xmlRecord:

<Employee>
<id/>
<lastName>Smith</lastName>
</Employee>

出力xmlRecord:

<EmployeeCollection>
<Employee>
<id>5</id>
<lastName>Smith</lastName>
....
</Employee>
<Employee>
<id>456</id>
<lastName>Smith</lastName>
....
</Employee>
</EmployeeCollection>

9.4.2.2 ポーリング戦略

インバウンドのreceive操作では、データベース内のイベントや変更のリスニングおよび検出が可能で、言い換えればビジネス・プロセスを起動させる役割を果たします。これは一度のみのアクションではなく、アクティブ化です。新しい行またはイベントに関してデータベース表をポーリングする、ポーリング・スレッドが開始されます。

MOVIES表に新しい行が挿入されるたびに、ポーリング操作によりSCAランタイムに伝達されます。戦略はすべてのレコードを一度ポーリングすることです。開始時に存在する行、および一定期間にわたり新しい行が挿入されるたびにそれらをすべて受信するには、最初のSELECTを一定期間繰り返す必要があります。ただし、一度読み取られた新しい行は削除されないため、各ポーリングで繰り返し読み取られる可能性があります。

イベントをポーリングする様々な方法は、ポーリング戦略、読取り後戦略またはパブリッシュ戦略とも呼ばれ、単純で変更を伴うものから複雑で変更を伴わないものまで多岐にわたります。各戦略では、行やイベントの読取り後に次のポーリング間隔で再度検索しないためにはどうしたらよいかという問題に対して異なる解決策が採用されています。最も簡単(および変更を伴う)解決策は、行を削除して再度問い合せないようにすることです。

この項では、データベースからデータが読み取られた後に実行できるポーリング操作について説明します。また、この項では、特定の状況でどの戦略を採用するかを判断するために役立つ方針と要因についても説明します。

- 読取り済の行の削除

- [Table_Name]表のフィールドの更新 (論理削除)

- 順序表の更新

- 異なるデータベースにある外部順序表の更新

- 制御表戦略

- 順序ファイルの更新

読取り済の行の削除

この操作は、物理削除ポーリング戦略を採用するときに選択します。この操作は、データベース表でレコードをポーリングし、処理後に削除します。この戦略は、INSERT操作に関連するイベントの取得に使用でき、親表のDELETEおよびUPDATE操作に関連するデータベース・イベントの取得には使用できません。この戦略は、子表イベントのポーリングには使用できません。この戦略では、複数のアダプタ・インスタンスで同じソース表にアクセスできます。データが重複することはありません。

事前条件: 削除ポーリング戦略を使用するには、親表および関連する子表に対する削除権限を持っている必要があります。表9-8 に、削除ポーリング戦略を使用するための要件を示します。

表9-8 削除ポーリング戦略の事前条件

一致する要件

競合

挿入のポーリング

ソースでの削除は不可

シャロー・デリート

ソースでの更新は不可

カスケード削除

更新のポーリング

最小SQL

削除のポーリング

データの重複なし

子の更新のポーリング

デフォルト

--

実際のSQLの許可

--

同時ポーリング

--

注意:

シャロー・デリートとカスケード削除の場合、最上位行の削除、すべてカスケードまたは状況に応じたカスケードを行うように削除操作を構成できます。

同時ポーリングは、削除と論理削除の両方のポーリング戦略用に構成できます。

構成: 削除ポーリング戦略は、最上位行の削除、すべてカスケードまたは状況に応じたカスケードを行うように構成できます。この戦略により、状況に応じて、子行ではなく親行のみの削除、カスケード削除およびオプションのカスケード削除が可能になります。設計時にイベント公開を実行するためのポーリング間隔を構成できます。

削除カスケード・ポリシー: オプションの高度な構成では、DELETE操作のカスケード・ポリシーを指定します。たとえば、住所と複数の電話番号を持つ従業員をポーリングすると、電話番号(デフォルトでは1対多)は個人的に所有されるため削除されますが、住所(デフォルトでは1対1)は削除されません。次の例に示すように、or_mappings.xmlを構成することで変更できます。

<database-mapping>
<attribute-name>orders</attribute-name>
<reference-class>taxonomy.Order</reference-class>
<is-private-owned>true</is-private-owned>

また、アクティブ化自体を構成し、最上位(マスター行)のみの削除、またはすべての削除を実行することもできます。

注意:

PrivateOwned注釈を使用して、リレーションシップが私有されることが指定されます。リレーションシップが私有されるとは、ターゲット・オブジェクトがソース・オブジェクトの依存部分であり、その他のオブジェクトから参照されず、単独では存在できないことを意味します。私有によって、操作が、削除、挿入、リフレッシュ、ロック(ロックがカスケードされる場合)を含むリレーションシップ間でカスケードされます。

また、PrivateOwnedは、コレクションから除去されるプライベート・オブジェクトが削除され、追加されるオブジェクトが挿入されたことも確認します。

receive操作はインバウンドJCAでは次のように表示されます。

例 - インバウンドJCAのreceive操作

<connection-factory location="eis/DB/Connection1"
UIConnectionName="Connection1" adapterRef=""/>
<endpoint-activation portType="dd_ptt" operation="receive">
<activation-spec className="oracle.tip.adapter.db.
DBActivationSpec">
<property name="DescriptorName" value="dd.Emp"/>
<property name="QueryName" value="ddSelect"/>
<property name="MappingsMetaDataURL" value="dd-or-mappings.xml"/>
<property name="PollingStrategy"
value="LogicalDeletePollingStrategy"/>
<property name="MarkReadColumn" value="STATUS"/>
<property name="MarkReadValue" value="PROCESSED"/>
<property name="MarkReservedValue" value="RESERVED-1"/>
<property name="MarkUnreadValue" value="UNPROCESSED"/>
<property name="PollingInterval" value="5"/>
<property name="MaxRaiseSize" value="1"/>
<property name="MaxTransactionSize" value="10"/>
<property name="ReturnSingleResultSet" value="false"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

[Table_Name]表のフィールドの更新 (論理削除)

この操作は、論理削除ポーリング戦略を採用するときに選択します。この戦略には、処理された各行の特別なフィールドの更新、および処理済の行を除外するための実行時のWHERE句の更新が関連します。

アプリケーション行はほとんど削除されないが、状態列isDeletedがtrueに設定されている論理削除に似ています。状態列と読取り値は指定する必要がありますが、変更されたWHERE句と読取り後の更新は自動的に処理されます。

事前条件: ソース表の論理削除権限またはスキーマを1度のみ変更(列追加)する権限を持っている必要があります。表9-9 に、論理削除ポーリング戦略を使用するための要件を示します。

表9-9 論理削除ポーリング戦略の事前条件

一致する要件

競合

挿入のポーリング

ソースでの更新は不可

ソースでの削除は不可

削除のポーリング

最小SQL

--

データの重複なし

--

最小構成

--

実際のSQLの許可

--

更新のポーリング

--

子の更新のポーリング

--

同時ポーリング

--

注意:

要件を満たす方法は、次のとおりです。

- 更新のポーリング: トリガーの追加

- 子の更新のポーリング: トリガーの追加

- 同時ポーリング: 追加のマーク未読取り値および予約値の指定

構成: 論理削除ポーリング戦略には最小構成が必要です。マーク読取り列および処理済レコードを示す値を指定する必要があります。

receive操作はインバウンドWSDLでは次のように表示されます。

<operation name="receive">
<jca:operation
ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
…
PollingStrategyName="LogicalDeletePollingStrategy"
MarkReadField="STATUS"
MarkReadValue="PROCESSED"

論理削除の構成を指定すると、次のWHERE句がすべてのポーリング問合せに追加されます。

AND (STATUS IS NULL) OR (STATUS <> 'PROCESSED')

データベース構成: ポーリングする表には状態列が存在する必要があります。存在しない場合は、既存の表に追加できます。

更新のポーリングのサポート: 各読取りで行が削除されない場合、行は何度でも読み取れます。レコードが変更されるたびにマーク読取りフィールドをリセットするには、次のように、トリガーを追加する必要があります。

create trigger Employee_modified
before update on Employee
for each row
begin
:new.STATUS := 'MODIFIED';
end;

同時アクセス・ポーリングのサポート: 単一のインスタンスでイベントを処理するのは1度のみであるように、インスタンスが複数の場合にも同じことが当てはまります。そのため、インスタンスでレコードを処理する前に、そのレコードを一意の値で予約しておく必要があります。前の例と同様に、状態列を次のように使用できます。

<operation name="receive">
<jca:operation
ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
…
PollingStrategyName="LogicalDeletePollingStrategy"
MarkReadField="STATUS"
MarkUnreadValue="UNPROCESSED"
MarkReservedValue="RESERVED${IP-2}-${weblogic.Name-1}-${instance}"
MarkReadValue="PROCESSED"

ポーリング問合せは次の例のようになります。

Update EMPLOYE set STATUS = 'RESERVED65-1-1' where (CRITERIA) AND (STATUS = 'UNPROCESSED');

Select … from EMPLOYEE where (CRITERIA) AND (STATUS = 'RESERVED65-1-1');

読取り後のUPDATEは、すべてを更新できるため、より高速です。

Update EMPLOYEE set STATUS = 'PROCESSED' where (CRITERIA) AND (STATUS = 'RESERVED65-1-1');

順序表の更新

この操作は、「順序表: 最終読取りID」戦略を採用するときに選択します。このポーリング戦略では、順序値の保存にヘルパー表の使用が関連します。ソース表は変更されませんが、別のヘルパー表で読取り済の行が記録されます。たとえば、順序値1000は、順序値がそれより小さいすべてのレコードが処理済であることを意味します。多くの表には、常に増加しトリガーやアプリケーションによって維持されているカウンタ・フィールドがあるため、この戦略は変更を伴わないポーリングに使用されます。処理済の行のフィールドを変更する必要はありません。

事前割当てサイズが1のネイティブ順序付けでは、時間とともに増加し続ける主キーと一緒に行が挿入されることが保証されます。

この戦略ではソース行が更新されないため、変更を伴わない削除とも呼ばれます。また、sequenceフィールドなどの順序付け戦略は、行を処理順に順序付けるために使用できます。

複数の行が1行に順序付けされている場合、処理対象の行と対象外の行が1つの情報単位で認識されます。

事前条件: ソース・スキーマの表の順序付け権限または表の作成権限を持っている必要があります。ソース表には、INSERT(ネイティブ順序付けされたOracleの主キー)またはUPDATE(最終変更タイムスタンプ)ごとに一定量増加する列があります。表9-10 に、順序付けポーリング戦略を使用するための要件を説明します。

表9-10 順序付けポーリング戦略の事前条件

一致する要件

競合

挿入のポーリング

削除のポーリング

更新のポーリング

実際のSQLの許可

ソースでの削除は不可

同時ポーリング

ソースでの更新は不可

--

追加のSQLを1つ選択

--

データの重複なし

--

中程度の構成

--

子の更新のポーリング

--

構成: 別のヘルパー表を定義する必要があります。ソース表では、増加し続ける列を指定する必要があります。

例 - 順序付けの指定

<adapter-config name="ReadS" adapter="Database Adapter"
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/DB/DBConnection1"
UIConnectionName="DBConnection1" adapterRef=""/>
<endpoint-activation portType="ReadS_ptt" operation="receive">
<activation-spec className="oracle.tip.adapter.db.DBActivationSpec">
<property name="DescriptorName" value="ReadS.PerfMasterIn"/>
<property name="QueryName" value="ReadSSelect"/>
<property name="MappingsMetaDataURL" value="ReadS-or-mappings.xml"/>
<property name="PollingStrategy" value="SequencingPollingStrategy"/>
<property name="SequencingTable" value="PC_SEQUENCING"/>
<property name="SequencingColumn" value="PK"/>
<property name="SequencingTableKeyColumn" value="TABLE_NAME"/>
<property name="SequencingTableValueColumn" value="LAST_READ_ID"/>
<property name="SequencingTableKey" value="PERF_MASTER_IN"/>
<property name="PollingInterval" value="60"/>
<property name="MaxRaiseSize" value="1"/>
<property name="MaxTransactionSize" value="10"/>
<property name="ReturnSingleResultSet" value="false"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

順序付けフィールドの型が実際には数値の場合は除外できます。

データベース構成: 指定されたデータベースに対して、順序付け表を一度構成する必要があります。複数のプロセスで同じ表を共有できます。前述の例でActivationSpecが指定されていた場合、CREATE TABLEコマンドは次のようになります。

CREATE TABLE SEQUENCING_HELPER
(
TABLE_NAME VARCHAR2(32) NOT NULL,
LAST_READ_DATE DATE
)
;

更新のポーリング: 前述の例では、オブジェクトが変更されるたびに変更時間が更新されるため、ポーリングは新しいオブジェクトまたは更新を対象としています。

insertまたはupdateごとの変更時間を設定するサンプルのトリガーは次のようになります。

create trigger Employee_modified
before insert or update on Employee
for each row
begin
:new.modified_date := sysdate;
end;

順序番号の使用: 順序番号は挿入または更新のポーリングに使用できます。ネイティブ順序付けでは、増分値1が使用されている場合、単調に増加する主キーが返されます。また、マテリアライズド・ビュー・ログの順序番号も使用できます。

異なるデータベースにある外部順序表の更新

この操作は、順序表: 最終更新戦略を採用するときに選択します。このポーリング戦略では、last_updated値の保存にヘルパー表の使用が関連します。たとえば、2005-01-01 12:45:01 000というlast_updated値は、最終更新がその時間またはそれより前のすべてのレコードは処理済であることを意味します。

多くの表には、トリガーやアプリケーションによって維持されているlast_updatedまたはcreation_time列があるため、この戦略は変更を伴わないポーリングに使用されます。処理済の行のフィールドを変更する必要はありません。

この戦略ではソース行が更新されないため、変更を伴わない削除とも呼ばれます。また、last_updatedフィールドなどの順序付け戦略は、行を処理順に順序付けるために使用できます。複数の行が1行に順序付けされている場合、処理対象の行と対象外の行が1つの情報単位で認識されます。

事前条件および構成の詳細は、「順序表の更新」を参照してください。

順序ファイルの更新

この戦略の動作は「異なるデータベースにある外部順序表の更新」と同様で、唯一の相違点は制御情報が表ではなくファイルに格納されることです。

制御表戦略

この操作は、制御表ポーリング戦略を採用するときに選択します。このポーリング戦略には、まだ処理されていないすべての行の主キーの保存に制御表の使用が関連します。(主キーにより)制御表とソース表が自然結合しているため、制御表に対するポーリングは、実際にはソース表を直接ポーリングすることと同じです。ただし、追加のインダイレクション層により次のことが可能になります。

- 削除ポーリング戦略などの変更を伴うポーリング戦略を制御表の行にのみ適用できます。これにより、ソース表の行を保護できます。

- 処理対象の行の主キーのみが制御表に表示されます。行自体にない情報は、処理する行の制御に使用できます(WHERE句のみでは不十分です)。

- 制御表には行全体はコピーされず、ディテール行などのソース表の任意の構造をコピーせずに呼び出せます。

ストリームおよびマテリアライズド・ビュー・ログにより適切な制御表が作成されます。

事前条件: ソース表に対するトリガーの作成/変更権限を持っている必要があります。表9-11 に、制御表ポーリング戦略を使用するための要件を示します。

表9-11 制御表ポーリング戦略の事前条件

一致する要件

競合

挿入のポーリング

高度な構成: データベースのネイティブXMLには制御ヘッダーがあり、トリガーが必要です。

更新のポーリング

--

削除のポーリング

--

子の更新のポーリング

最小のデータ重複(主キーは制御表に格納)。

ソースでの削除は不可

--

ソースでの更新は不可

--

追加のSQL選択は不可

--

同時ポーリング

--

実際のSQLの許可

--

監査

--

行が変更されるたびにトリガーを使用すると、マスター表の名前と主キーを含む制御表にエントリが追加されます。設計時、制御表は、一致する主キーに基づきマスター表への1対1マッピングで、ルート表として定義されます。制御表には、タイムスタンプなどの追加の制御情報および操作タイプ(INSERT、UPDATEなど)が含まれます。

この設定では、"削除"ポーリング戦略が便利です。制御表を小さく保つことが重要であり、shouldDeleteDetailRows="false"オプションが使用されている場合は、制御行のみが削除され、変更を伴わない削除が実行されます(DELETEは実際の表にはカスケードされません)。

複数のマスター表に同じ制御表を再利用できます。TopLinkでは、制御表を複数の子を持つ1つの抽象クラスとしてマッピングすることで、同じ表を複数のディスクリプタにマッピングできます。各子には、異なるマスター表への一意の1対1マッピングがあります。この方法の利点は、各子にクラス・インジケータ・フィールドおよび値を指定できるため、各ポーリング問合せに明示的なWHERE句が不要なことです。

部門表および子の従業員行の両方への変更のポーリングに使用するサンプル・トリガーを次に示します。

CREATE OR REPLACE TRIGGER EVENT_ON_DEPT
AFTER INSERT OR UPDATE ON DEPARTMENT
REFERENCING NEW AS newRow
FOR EACH ROW
DECLARE X NUMBER;
BEGIN
SELECT COUNT(*) INTO X FROM DEPT_CONTROL WHERE (DEPTNO = :newRow.DEPTNO);
IF X = 0 then
insert into DEPT_CONTROL values (:newRow. DEPTNO);
END IF;
END;
CREATE OR REPLACE TRIGGER EVENT_ON_EMPLOYEE
AFTER INSERT OR UPDATE ON EMPLOYEE
REFERENCING OLD AS oldRow NEW AS newRow
FOR EACH ROW
DECLARE X NUMBER;
BEGIN
SELECT COUNT(*) INTO X FROM DEPT_CONTROL WHERE (DEPTNO = :newRow.DEPTNO);
IF X = 0 then
INSERT INTO DEPT_CONTROL VALUES (:newRow.DEPTNO);
END IF;
IF (:oldRow.DEPTNO <> :newRow.DEPTNO) THEN
SELECT COUNT(*) INTO X FROM DEPT_CONTROL WHERE (DEPTNO = :oldRow.DEPTNO);
IF (X = 0) THEN
INSERT INTO DEPT_CONTROL VALUES (:oldRow.DEPTNO);
END IF;
END IF;
END;

9.5 データベース・アダプタ・デプロイメント

Oracleデータベース・アダプタは、インストールによってアプリケーション・サーバーにデプロイされます。これには、データソースjdbc/SOADataSourceを指す単一アダプタ・インスタンス・エントリeis/DB/SOADemoが含まれています。データベースへの接続情報は、データソース定義内にあります。

OracleAS Adapter for Databasesを使用するSOAプロジェクトをデプロイするとき、最初に新しいアダプタ・インスタンスを追加し、アプリケーション・サーバーを再起動することが必要となる場合があります。これは、jdbc/SOADataSourceで参照されるデータベースとは別のデータベースを指す場合や、まだ存在しない名前をアダプタ・インスタンスに付けた場合などに必要となります。たとえば、JDeveloperでConnection1という名前の接続を作成した場合、図9-7 に示すように、DBアダプタ・サービスはデフォルトでeis/DB/Connection1を指します。

また、次のコードスニペットに示すようにdb.jcaファイルを確認することによって、サービスがどのアダプタ・インスタンスを指しているかを確認できます。

<connection-factory location="eis/DB/Connection1" UIConnectionName="Connection1"
adapterRef="" />

前述の例では、場所は実行時のアダプタ・インスタンスのJNDI名で、UIConnectionNameはJDeveloperで使用されている接続の名前です。

データベース・アダプタ・インスタンスを作成するには、「アダプタ・コネクション・ファクトリの追加」の説明に従ってOracle WebLogic Server管理コンソールを使用するか、weblogic-ra.xmlファイルを直接編集します。次の手順に続く各スクリーンショットは、Oracle WebLogic管理コンソールによるアダプタ・インスタンスの作成方法を示しています。weblogic-ra.xmlを編集する手順は、次のとおりです。

1. fmwhome/でDbAdapter.rarを検索します。

2. ファイルを解凍します。

3. META-INF/weblogic-ra.xml(および、場合によってはra.xml)を編集します。

4. このファイルから再びJARを作成します。

5. アプリケーション・サーバーを再起動します。

次の例は、weblogic-ra.xmlのサンプル・アダプタ・インスタンスです。

例 - weblogic-ra.xmlのサンプル・アダプタ・インスタンス

<connection-instance>
<jndi-name>eis/DB/SOADemo</jndi-name>
<connection-properties>
<properties>
<property>
<name>xADataSourceName</name>
<value>jdbc/SOADataSource</value>
</property>
<property>
<name>dataSourceName</name>
<value> </value>
</property>
<property>
<name>platformClassName</name>
<value>Oracle10Platform</value>
</property>
</properties>
</connection-properties>
</connection-instance>

4つの必須プロパティは、jndi-name、xADataSourceName、dataSourceNameおよびplatformClassNameです。jndi-nameプロパティは、db.jcaファイル内の場所属性に一致している必要があり、アダプタ・インスタンスの名前を表しています。

xADataSourceNameプロパティは、基礎となるデータソースの名前です(接続情報を含みます)。

platformClassNameは、どのSQLを生成するかを示します。PlatformClassNameの詳細は、表9-13 を参照してください。

次の各スクリーンショットは、Oracle WebLogic管理コンソールを使用したデータベース・アダプタのプロパティの編集方法を示しています。

最初のスクリーンショットは、WebLogic管理コンソール内での「アウトバウンド接続プール」へのナビゲーションを示しています。これが実際のデータベース・アダプタ構成ページであり、ここから後続のページに移動してデータベース・アダプタのプロパティを編集できます。

図9-30 WebLogicコンソールの「アウトバウンド接続プール」タブ

2つ目のスクリーンショットは、必要に応じて編集する、WebLogicコンソールの編集プロパティを示しています。プロパティごとに名前、タイプおよび値が表示されます。

図9-31 Oracle WebLogic管理コンソールのデータベース・アダプタのプロパティ

最も一般的なミス

デプロイメントに関する最も一般的なミスとして、次の2つがあります。

- db.jcaファイル内の場所属性に一致するアダプタ・インスタンス・エントリが作成されていません(または、エントリが1つも作成されていません)。

- db.jcaファイル内の場所属性にデータソース名を直接設定しています。

- Oracle以外のデータベースに接続する際、platformClassNameを変更していません。

後者の場合は、アダプタ・インスタンス名(eis/DB/...)を指定し、このインスタンス名がデータソース・プール(jdbc/...)を指すというように間接的に指定する必要があります。一般的なミスは、このように間接的に指定せず、名前jdbc/...を場所属性に直接指定することです。

データソースの構成

アプリケーション・サーバーの関連データソース構成の詳細は、「JDBCドライバとデータベース接続の構成」を参照してください。Oracleデータソースを構成するときには、必ずthin XAオプションを使用してください。

その他のアダプタ・インスタンス・プロパティ

この項では、xADataSourceName、dataSourceNameおよびplatformClassName以外のデータベース・アダプタ・インスタンスのプロパティについて簡単に説明します。

weblogic-ra.xmlにプロパティを追加するときには、そのプロパティがra.xml(およびDbAdapter.rar)でも宣言されていることを確認する必要があります。例として、weblogic-ra.xmlのxADataSourceNameプロパティに関するra.xmlファイルのコードスニペットを次に示します。

<config-property>
<config-property-name>xADataSourceName </config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>

Oracleデータベース・アダプタのインスタンス・プロパティの詳細は、「Oracleデータベース・アダプタのプロパティ」を参照してください。

そこに記載されているプロパティの他に、表9-12 に示すプロパティも追加できます。

表9-12 Toplink DatabaseLoginオブジェクトに表示されるOracleデータベース・アダプタのプロパティ

プロパティ名

タイプ

usesNativeSequencing

Boolean

usesSkipLocking

Boolean

usesStringBinding

Boolean

usesByteArrayBinding

Boolean

usesStreamsForBinding

Boolean

eventListenerClass

文字列

logTopLinkAll

Boolean

maxBatchWritingSize

Integer

nonRetriableSQLErrorCodes

文字列

shouldOptimizeDataConversion

Boolean

shouldTrimStrings

Boolean

driverClassName

文字列

sequencePreallocationSize

Integer

tableQualifier

文字列

usesBatchWriting

Boolean

前述のプロパティは、oracle.toplink.sessions.DatabaseLoginオブジェクトに出現します。

DBConnectionFactory JavadocおよびDatabaseLogin Javadocの情報は、「TopLink API Reference」(http://download.oracle.com/docs/cd/B10464_02/web.904/b10491/index.html)を参照してください。

9.5.1 サード・パーティ・データベースを使用したデプロイメント

表9-13 は、各データベースとそれらの高度なプロパティ(データベース・プラットフォーム変数)を一覧に示したものです。

platformClassName名は、一覧にあるいずれかの変数に設定してください。platformClassNameの設定は、データベース間で統一されていない高度なデータベース機能(ネイティブ順序付けやストアド・プロシージャなど)を使用している場合には必須です。

たとえば、ストアド・プロシージャをDB2とSQL Serverで実行する場合、DbAdapterは異なるSQLを生成し、送信する必要があります。SQLServerプラットフォームで使用する場合は、次の例を使用してください。

execute <procedure> @<arg1>=? ...

DB2 Platformの場合は次の例を使用してください。

call <procedure>(?, ...)

platformClassName設定は、生成するSQLを示します。ほとんどのデータベースは不均一な機能(つまり、ANSI SQL 92言語仕様のバリアント)を提供するため、platformClassNameを正確に構成するのが最も安全な方法です。デフォルト値はOracle10Platformで、別のデータベース・ベンダーに接続している場合は適切な変数に変更する必要があります。

注意:

パッケージに修飾クラス名を付けることは、名前がorg.eclipse.persistence.platform.databaseで始まっている場合には必要ありません。

表9-13 データベース・プラットフォーム名

データベース

PlatformClassName

Oracle10以上(11gを含む)

org.eclipse.persistence.platform.database.Oracle10Platform

Oracle9以上(オプション)

org.eclipse.persistence.platform.database.Oracle9Platform

DB2

org.eclipse.persistence.platform.database.DB2Platform

DB2 (AS400e上)

oracle.tip.adapter.db.toplinkext.DB2AS400Platform

Informix

org.eclipse.persistence.platform.database.InformixPlatform

SQLServer

org.eclipse.persistence.platform.database.SQLServerPlatform

MySQL

org.eclipse.persistence.platform.database.MySQLPlatform

Derby

org.eclipse.persistence.platform.database.DerbyPlatform

z/OS上のDB2

org.eclipse.persistence.platform.database.DB2MainframePlatform

その他のデータベース

org.eclipse.persistence.platform.database.DatabasePlatform

9.6 JDBCドライバとデータベース接続の構成

今回のリリースで、Oracle WebLogic Serverタイプ4 JDBCドライバを使用する次のサード・パーティ・データベースに対して動作保証されています。

- Microsoft SQL Server 2005および2008 (すべてのSPレベルを含む)

- Sybase 15

- Informix 11.5

- DB2 9.7およびそれ以降のFixPaks

- MySQL 5.x以上

注意:

主要なデータベースおよびバージョンのみが動作確認されています。他のデータベースでの作業は、作業用のJDBCドライバが用意されており、コアANSI SQLリレーショナル機能(表やビューに対する作成、読取り、更新および削除(CRUD)の各操作など)に依存している場合、実行可能です。問題の多くは、データベース・メタデータ・イントロスペクションが、必ずしもすべてのJDBCドライバで同じように実装されていないことによって、発生する傾向があります。ただし、動作確認されたデータベース上に一致する表をインポートした後、動作確認されていないデータベースを実行時に参照することができます。動作確認されていないデータベースに関してこの項で説明する情報は、ガイドとしてのみ参照してください。

詳細は、以下のトピックを参照してください。

- ネイティブまたはバンドルされたJDBCドライバを使用したデータベース接続の作成

- サード・パーティJDBCドライバを使用したデータベース接続の作成

- サード・パーティJDBCドライバおよびデータベース接続情報の概要

- JDBCドライバJARファイルの場所とクラスパスの設定

9.6.1 ネイティブまたはバンドルされたOracle WebLogic Server JDBCドライバを使用したデータベース接続の作成

ネイティブまたはバンドルされたOracle WebLogic Server JDBCドライバを使用している場合にデータベース接続を作成するには、次のようにします。

1. 適切なJDBCドライバJARファイルがインストールされてクラスパスが設定されていることを確認します。

詳細は、次を参照してください。

- Oracle WebLogic ServerのJDBCデータ・ソースの管理

- Oracle WebLogic Server JDBCアプリケーションの開発

2. 「ファイル」メニューの「新規」をクリックします。

「新規ギャラリ」ページが表示されます。

3. 「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。

「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。

4. 「データベース接続」を選択し、「OK」をクリックします。

「データベース接続の作成」ページが表示されます。

5. 「接続の作成場所」で、「IDE接続」を選択します。

6. 「接続名」フィールドにこの接続の名前を入力します。

例: SQLServer。

7. 「接続タイプ」メニューから適切なドライバを選択します。

8. 資格証明(必要に応じてユーザー名、パスワードおよびロールなど)を入力します。

9. 接続情報を入力します。

たとえば、jdbc:sqlserver://HOST-NAME:PORT;databaseName=DATABASE-NAMEと入力します。

詳細は、次を参照してください。

- 表9-14

- デプロイメント・ディスクリプタ・ファイル(weblogic-ra.xml)のサンプルのエントリ。

10. 「接続のテスト」をクリックします。

11. 正常に接続した場合は、「OK」をクリックします。

9.6.2 サード・パーティJDBCドライバを使用したデータベース接続の作成

サード・パーティJDBCドライバを使用している場合にデータベース接続を作成するには、次のようにします。

1. 適切なJDBCドライバJARファイルをインストールしてクラスパスを設定します。

詳細は、「JDBCドライバJARファイルの場所とクラスパスの設定」を参照してください。

2. 「ファイル」メニューの「新規」をクリックします。

「新規ギャラリ」ページが表示されます。

3. 「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。

「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。

4. 「データベース接続」を選択し、「OK」をクリックします。

「データベース接続の作成」ページが表示されます。

5. 「接続の作成場所」で、「IDE接続」を選択します。

6. 「接続名」フィールドにこの接続の名前を入力します。

例: SQLServer。

7. 「接続タイプ」から「汎用JDBC」を選択します。

8. ユーザー名、パスワードおよびロール情報を入力します。

9. 「ドライバ・クラス」で「新規」をクリックします。

「JDBCドライバの登録」ダイアログが表示されます。

「JDBCドライバの登録」ダイアログでステップ10、11および19を実行します。

10. 「ドライバ・クラス」にドライバ名(some.jdbc.Driverなど)を入力します。

例: com.microsoft.sqlserver.jdbc.SQLServerDriver。

11. 「ライブラリ」で「参照」をクリックします。

「ライブラリの選択」ダイアログが表示されます。

「ライブラリの選択」ダイアログでステップ12および18を実行します。

12. 「新規作成」をクリックしてライブラリを作成します。

「ライブラリの作成」ダイアログが表示されます。

「ライブラリの作成」ダイアログでステップ13から17を実行します。

13. 「ライブラリ名」フィールドに名前を入力します。

例: SQL Server JDBC。

14. 「クラスパス」をクリックしてから「エントリの追加」をクリックしてドライバの各JARファイルをクラスパスに追加します。

「パス・エントリの選択」ダイアログが表示されます。

15. JDBCクラス・ファイルを選択して「選択」をクリックします。

たとえば、「sqljdbc.jar」を選択します。

16. すべてのクラス・ファイルを「クラスパス」フィールドに追加した後、「OK」をクリックします。

17. 「OK」をクリックして「ライブラリの作成」ダイアログを終了します。

18. 「OK」をクリックして「ライブラリの選択」ダイアログを終了します。

19. 「OK」をクリックして「JDBCドライバの登録」ダイアログを終了します。

20. 「JDBC URL」に接続文字列名を入力して、「次へ」をクリックします。

たとえば、jdbc:sqlserver://HOST-NAME:PORT;databaseName=DATABASE-NAMEと入力します。

詳細は、次を参照してください。

- 表9-14

- デプロイメント・ディスクリプタ・ファイル(weblogic-ra.xml)のサンプルのエントリ。

21. 「接続のテスト」をクリックします。

22. 正常に接続した場合は、「OK」をクリックします。

9.6.3 サード・パーティJDBCドライバおよびデータベース接続情報の概要

表9-14 に、一般的なサード・パーティ・データベースの接続情報の概要を示します。

Oracle、IBM DB2、Informix、Sybase、SQLServer、MySQLおよびDerbyのドライバ・ファイルは、SOAインストールにバンドルされます。

Oracleでは、これらのWebLogic Serverドライバ(Oracleドライバ)のこれらのデータベースでの動作を保証しています。DB2/AS400、DB2/ZOS、ProgressDBなど、その他のデータベースについては、適切なネイティブ・ドライバを取得する必要があります。

PlatformClassNameの詳細は、表9-13 を参照してください。

詳細は、次を参照してください。

- Microsoft SQL Serverの使用方法

- Sybaseデータベースの使用方法

- Informixデータベースの使用方法

- IBM DB2データベースの使用方法

- MySQLデータベースの使用方法

表9-14 (Weblogic Serverコンソールからの)データベース・ドライバの選択

データベース

JDBCドライバ

Microsoft SQL Server

- OracleのMS SQL Serverドライバ(タイプ4 XA)

- OracleのMS SQL Serverドライバ(タイプ4)

Sybase

- OracleのSybaseドライバ(タイプ4 XA)

- OracleのSybaseドライバ(タイプ4)

Informix

- OracleのInformixドライバ(タイプ4 XA)

- OracleのInformixドライバ(タイプ4)

IBM DB2

- OracleのDB2ドライバ(タイプ4 XA)

- OracleのDB2ドライバ(タイプ4)

MySQL

MySQLのドライバ(タイプ4)

バージョン: com.mysql.jdbc.Driverを使用

Derby

Derbyのドライバ(タイプ4 XA)

DB2/AS400

オンラインのドライバjt400Native.jarをダウンロードして、user_projects/domains/<domain_name>/lib/にコピーします。

注意: WLSからのjndiの作成中にotherオプションを選択します。

DB2/ ZOS

オンラインのドライバdb2jcc4.jar、db2jcc_license_cu.jarおよびdb2jcc_license_cisuz.jarをダウンロードして、user_projects/domains/<domain_name>/lib/にコピーします。

注意: WebLogic ServerからのJNDIの作成中にotherオプションを選択します。

ProgressDb

Progressインストールのドライバopenedge.jar、pool.jarおよびschema.jarをuser_projects/domains/<domain_name>/lib/にコピーします。

注意: WebLogic ServerからのJNDIの作成中にotherオプションを選択します。

9.6.3.1 Microsoft SQL Serverの使用方法

SQL Serverデータベースに接続する際は次の点に注意する必要があります。

XAトランザクションを有効にするには、次の手順を実行します。

1. <install_dir>/oracle_common/modules/datadirectのすべてのファイルをMSSQLインストールのProgram Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binnにコピーします。

2. <Install_dir>/oracle_common/modules/datadirectのinstjdbc.sqlをMSSQLインストール・マシンのcディレクトリ(c:/)などにコピーします。

3. オペレーティング・システムに基づいて、必要なDLLをSQL Server Binディレクトリにコピーし、名前をsqljdbc.dllに変更します。次に例を示します。

- sqljdbc.dll: 32ビットOSの場合

- 64sqljdbc.dll: Itaniumベースの64ビットOSの場合

- x64sqljdbc.dll: Intelベースの64ビットOSの場合

4. SQLコマンドラインで次のコマンドを実行します。そのコマンドは、エラーなしで完了する必要があります。

sqlcmd -Usa -Pwelcome1! -Slocalhost -iC:\instjdbc.sql

5. SQLサーバー・サービスを再起動します。

XAトランザクションを正常に実行するには、次の手順も実行する必要があります。

1. 「run」→「dcomcnfg」に進みます

2. その後、「component servies」→「Mycomp」→「DTC」→「LocalDTC」→「Properties」に進みます(「Properties」を右クリック)。

3. さらに「Security」に進み、「Enable xa transaction」を選択します

4. 最後に、すべての関連サービスを再起動します(trxn、sqlserver)。

9.6.3.2 SQLSERVER Weblogic JDBCドライバの使用方法

URL: jdbc:weblogic:sqlserver://<host>:<port>

ドライバ・クラス: weblogic.jdbcx.sqlserver.SQLServerDataSource

ドライバJar: wlsqlserver.jarはWebLogic Serverにバンドルされており、インストール時に提供されます。

その場所は、/<install_dir>/oracle_common/modules/datadirectです。

9.6.3.3 Sybaseデータベースの使用方法

この項には次のトピックが含まれます:

- Sybase JConnect JDBCドライバの使用方法

9.6.3.3.1 Sybase JConnect JDBCドライバの使用方法

URL: jdbc:weblogic:sybase://<host>:<port>

ドライバ・クラス: weblogic.jdbcx.sybase.SybaseDataSource

ドライバJar: wlsybase.jarはWebLogic Serverにバンドルされており、インストール時に提供されます。

その場所は、/<install_dir>/oracle_common/modules/datadirectです。

Sybase JConnect JDBCドライバの詳細は、次のリンクを参照してください。

http://www.sybase.com/products/middleware/jconnectforjdbc

9.6.3.4 Informixデータベースの使用方法

この項には次のトピックが含まれます:

- Informix JDBCドライバの使用方法

9.6.3.4.1 Informix JDBCドライバの使用方法

URL: jdbc:weblogic:informix://<host>:<port>;informixServer=<server_name>;databaseName=<db_name>

ドライバ・クラス: weblogic.jdbcx.informix.InformixDataSource

ドライバJar: wlinformix.jarはサーバーにバンドルされており、インストール時に提供されます。その場所は、/<install_dir>/oracle_common/modules/datadirectです。

Informix JDBCドライバの詳細は、次のリンクを参照してください。

http://www-01.ibm.com/software/data/informix/tools/jdbc/

9.6.3.5 IBM DB2データベースの使用方法

この項には次のトピックが含まれます:

- IBM DB2ドライバ

- JT400ドライバ(AS400 DB2)

- IBM Universalドライバ

9.6.3.5.1 IBM DB2ドライバ

URL: jdbc:weblogic:db2://<host>:<port>ドライバ・クラス: weblogic.jdbcx.db2.DB2DataSourceDriver Jar: wldb2.jarはサーバーでバンドルされています。インストールとともに提供されます。場所: /<install_dir>/oracle_common/modules/datadirect

DataDirectドライバについては、次のリンクを参照してください。

http://www.datadirect.com/techres/jdbcproddoc/index.ssp

9.6.3.5.2 JT400ドライバ(AS400 DB2)

URL: jdbc:as400://hostname;translate binary=true

ドライバ・クラス: com.ibm.as400.access.AS400JDBCDriver/

com.ibm.as400.access.AS400JDBCXADataSource

ドライバJar: jt400.jar/jt400Native.jar

キャラクタ・セットを適切に変換するには、translate binary=trueを使用します。

9.6.3.5.3 IBM Universalドライバ

(ZOS)

URL: jdbc:db2://hostname:port/schemaname

ドライバ・クラス: weblogic.jdbcx.db2.DB2DataSource

ドライバJar: wldb2.jarはサーバー内でバンドルされています。インストールとともに提供されます。場所: /<install_dir>/oracle_common/modules/datadirect

9.6.3.6 MySQLデータベースの使用方法

次の情報を使用します。

URL: jdbc:mysql://hostname:3306/dbname

ドライバ・クラス: com.mysql.jdbc.Driver / com.mysql.jdbc.jdbc2.optional.MysqlXADataSource

ドライバJar: mysql-connector-java-<version_number>-bin.jar

9.6.3.7 Derbyデータベースの使用方法

次の情報を使用します。

URL: jdbc:derby://<host>:<port><location of schema>

ドライバ・クラス: org.apache.derby.jdbc.ClientXADataSource

ドライバJar: Derby.jar, derbyclient.jar

9.6.3.8 Progressデータベースの使用方法

次の情報を使用します。

URL: jdbc:datadirect:openedge://<host>:<port>;databaseName=<dbname>

ドライバ・クラス: com.ddtek.jdbc.openedge.OpenEdgeDriver

ドライバJar: openedge.jar, pool.jar, schema.jar

9.6.4 JDBCドライバJARファイルの場所とクラスパスの設定

この項では、JDBC JARファイルの場所と、実行時および設計時のクラスパスの設定について説明します。

実行時

WindowsとLinuxの場合は、どちらも次の手順を実行する必要があります。

1. ベンダー固有のドライバJARファイルをuser_projects/domains/soainfra/libディレクトリに移動します。

2. ベンダー固有のドライバJARファイルを<Weblogic_Home>/server/libに移動します。

3. クラスパスを編集し、ベンダー固有のjarファイルを<Weblogic_HOME>/common/bin/commEnv.shに含めます

設計時

WindowsとLinuxの場合は、どちらもJDBC JARをOracle/Middleware/jdeveloper/jdev/lib/patchesディレクトリに移動します。

9.7 ストアド・プロシージャおよびファンクションのサポート

この項では、ストアド・プロシージャとファンクションの使用がどのようにサポートされているかについて説明します。

この項には次のトピックが含まれます:

- 設計時: アダプタ構成ウィザードの使用

- サポートされるサード・パーティ・データベース

- 設計時: 成果物の生成

- 実行時: ストアド・プロシージャの起動前

- 実行時: ストアド・プロシージャの起動後

- 実行時: サード・パーティ・データベースの共通機能

- 高度なトピック

9.7.1 設計時: アダプタ構成ウィザードの使用

「アダプタ構成ウィザード - ストアド・プロシージャ」は、アダプタ・サービスWSDLおよび必要なXSDの生成に使用されます。アダプタ・サービスWSDLは、基礎となるストアド・プロシージャまたはファンクションをWSIF JCAバインディングのあるWebサービスとしてカプセル化します。XSDファイルには、すべてのパラメータおよびそのタイプを含む、プロシージャまたはファンクションが記述されています。このXSDには、実行時に発行されるインスタンスXMLの作成に使用される定義が指定されています。

この項には次のトピックが含まれます:

- 最上位のスタンドアロンAPIの使用

- パッケージ化されたAPIの使用およびオーバーロード

9.7.1.1 最上位のスタンドアロンAPIの使用

この項では、PL/SQLパッケージに定義されていないAPIを持つアダプタ構成ウィザードの使用方法を説明します。「アダプタ構成ウィザード - ストアド・プロシージャ」を使用し、プロシージャまたはファンクションを選択してXSDファイルを生成します。アダプタ構成ウィザードの起動方法については、「Oracleデータベース・アダプタの使用例」を参照してください。

アダプタ構成ウィザードを使用してストアド・プロシージャまたはファンクションを選択するには、次の手順を実行します。

1. 「サービス・アダプタ」リストから「データベース・アダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。

図9-32 に示すように、アダプタ構成ウィザードが表示されます。

図9-32 アダプタ構成ウィザード

2. 「次」を選択します。図9-33 に示すように、「サービス名」ページが表示されます。

注意:

データベースまたはユーザー定義データ型を参照するストアド・プロシージャまたはパッケージの名前には、文字$を使用できないことに注意してください。名前に$が含まれていると、XSDファイルの生成に失敗します。

図9-33 サービス名の指定

3. 「サービス名」フィールドにサービス名を入力し、「次へ」をクリックします。「サービス接続」ページが表示されます。

図9-34 に示すように、接続をサービスに関連付けます。アダプタ・サービスを構成するにはデータベース接続が必要です。リストから既存の接続を選択するか、新規の接続を作成してください。

図9-34 アダプタ構成ウィザードにおけるデータベース接続の設定

4. 「次」を選択します。「操作タイプ」ページが表示されます。

5. 図9-35 に示すように、「操作タイプ」に「ストアド・プロシージャまたはファンクションの呼出し」を選択します。

図9-35 アダプタ構成ウィザードにおけるストアド・プロシージャまたはファンクションの呼出し

6. 「次」を選択します。図9-36 に示すように、「ストアド・プロシージャの指定」ページが表示されます。このページで、ストアド・プロシージャまたはファンクションを指定します。

図9-36 「ストアド・プロシージャの指定」ページ

7. 次に、スキーマと、プロシージャまたはファンクションを選択します。リストからスキーマを選択するか、「<デフォルト・スキーマ>」を選択します。この場合、接続に関連付けられているスキーマが使用されます。プロシージャ名がわかっている場合は、「プロシージャ」フィールドに入力します。プロシージャがパッケージ内に定義されている場合は、EMPLOYEE.GET_NAMEのようにパッケージ名を含める必要があります。

スキーマ名およびプロシージャ名が不明である場合は、「参照」をクリックして、図9-37 に示すように、「ストアド・プロシージャ」ウィンドウにアクセスします。

図9-37 プロシージャまたはファンクションの検索

リストからスキーマを選択するか、「<デフォルト・スキーマ>」を選択します。使用可能なプロシージャのリストが左側のウィンドウに表示されます。APIの長いリストから特定のAPIを検索するには、「検索」フィールドに検索基準を入力します。たとえば、XXで始まるすべてのAPIを検索するには、XX%と入力し「検索」ボタンをクリックします。「すべて表示」ボタンをクリックすると、使用可能なすべてのAPIが表示されます。

図9-38 に、FACTORIALファンクションの選択方法を示します。「引数」タブには、ファンクションのパラメータが表示されます。表示されるパラメータは、名前、型、モード(IN、IN/OUTまたはOUT)およびプロシージャの定義におけるパラメータの数値位置です。ファンクションの戻り値は、名前がなく、常に位置がゼロ(0)のOUTパラメータです。

図9-38 選択したプロシージャの引数の表示

図9-39 に、ファンクションを実装するコードが「ソース」タブでどのように表示されるかを示します。ファンクション名に一致するテキストが強調表示されています。

図9-39 選択したプロシージャのソース・コードの表示

8. ストアド・プロシージャまたはファンクションを選択して、「OK」をクリックします。図9-40 に示すように、APIに関する情報が表示されます。修正するには、「戻る」または「参照」をクリックします。

図9-40 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示

9. 「次」を選択します。ストアド・プロシージャまたはファンクションに、行セット・タイプの出力パラメータ(Oracle DatabaseではREF CURSOR)が含まれる場合、図9-41 に示すように、このREF CURSORに対して強い型指定のXSDまたは弱い型指定のXSDを定義できます。

図9-41 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示: 行セット・タイプの場合

詳細は、次を参照してください。

- 強い型指定のXSDを使用した行セットのサポート

- 弱い型指定のXSDを使用した行セットのサポート

10. 「次」を選択します。図9-42 に示すように、「詳細オプション」ページが表示されます。JDBCの「問合せタイムアウト」の値など、任意の詳細オプションを入力します。その他のオプションとしては、再試行回数や再試行間隔などの再試行パラメータがあります。

図9-42 「詳細オプション」ページ

11. すべてのオプションを指定した後、「次へ」をクリックし、「終了」をクリックしてアダプタ構成ウィザードを終了します。

アダプタ構成ウィザードの使用が終了すると、次の3つのファイルが既存のプロジェクトに追加されます。

- servicename.wsdl (Factorial.wsdlなど)

- service_name_db.jca (Factorial_db.jcaなど)

- schema_package_procedurename.xsd (SCOTT_FACTORIAL.xsdなど)

9.7.1.2 パッケージ化されたAPIの使用およびオーバーロード

パッケージで定義されたAPIの使用は、スタンドアロンAPIの使用と似ています。唯一の違いは、図9-43 に示すように、パッケージ名を開いて、パッケージに定義されているすべてのAPIのリストを参照できることです。

同じ名前でパラメータが異なるAPIは、オーバーロードされたAPIと呼ばれます。図9-43 に示すように、PACKAGEというパッケージには、OVERLOADというオーバーロードされたプロシージャが2つあります。

図9-43 オーバーロードされたプロシージャが2つあるパッケージ

図9-44 に示すように、「ソース」タブを参照する際にはパッケージのどのAPIが選択されているかにかかわらず、PL/SQLパッケージ全体のコードが表示されます。プロシージャ名に一致するテキストが強調表示されています。

図9-44 オーバーロードされたプロシージャのソース・コードの表示

プロシージャまたはファンクションを選択して「OK」をクリックすると、図9-45 に示すように、APIの情報が表示されます。スキーマ、プロシージャ名およびパラメータのリストが表示されます。プロシージャ名がパッケージ名でどのように修飾されているかに注意してください(PACKAGE.OVERLOAD)。「戻る」または「参照」をクリックして修正するか、「次へ」をクリックします。任意の詳細オプションの値を入力します。「次へ」をクリックし、「終了」をクリックして終了します。

図9-45 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示

アダプタ構成ウィザードの使用が終了すると、次のファイルが既存のプロジェクトに追加されます。

- Overload.wsdl、Overload_db.jca

- SCOTT_PACKAGE_OVERLOAD_2.xsd
XSDファイル名ではプロシージャ名の後に_2が追加され、オーバーロードされたAPIと区別されています。数値索引は、オーバーロードされたAPIをそれぞれ区別するために使用されます。

9.7.2 サポートされるサード・パーティ・データベース

ストアド・プロシージャの場合、Oracle、DB2、Informix Dynamic Server、MySQL、Microsoft SQL ServerおよびSybase Adaptive Server Enterpriseのデータベースがサポートされています。認証されている特定のバージョンについては、サポートに問い合せてください。特定のバージョンがここに記載されているバージョンよりも新しい場合、そのバージョンがサポートされている可能性があります。

サード・パーティJDBCおよびデータベースに対するサポートの詳細は、「JDBCドライバとデータベース接続の構成」を参照してください。

この項には次のトピックが含まれます:

- 使用される用語。

- 重要な注意点

- データベース接続の作成

9.7.2.1 使用される用語

ProductName

これはデータベースの名前です。

データベース名

サポート対象データベース

IBM DB2

IBM DB2 v 10.1

Microsoft SQL Server

SQLServer 2012

MySQL

MySQL v5.6*

DriverClassName

これはJDBCドライバ・クラスの名前です。

データベース名

JDBCドライバ

IBM DB2

weblogic.jdbcx.db2.DB2DataSource

Microsoft SQL Server

weblogic.jdbcx.sqlserver.SQLServerDataSource

MySQL

com.mysql.jdbc.Driver / com.mysql.jdbc.jdbc2.optional.MysqlXADataSource

ConnectionString

これはJDBC接続URLです。

データベース名

接続文字列

IBM DB2

jdbc:weblogic:db2://<host>:<port>

Microsoft SQL Server

jdbc:weblogic:sqlserver://<host>:<port>

MySQL

jdbc:mysql://host:port/database-name

Username

データベース・ユーザー名です。

Password

ユーザー名に関連付けられているパスワードです。

ProcedureName

ストアド・プロシージャ名またはファンクション名です。

ServiceName

必要な操作のサービス名です。

DatabaseConnection

接続のJNDI名です。たとえば、eis/DB/<DatabaseConnection>です。

Destination

これは、生成されるファイルの接続先ディレクトリです。たとえば、C:\Tempなどです。

Parameters

ストアド・プロシージャのパラメータです(バージョン5.2.6より前のMySQLのみ)。

QueryTimeout

JDBC問合せタイムアウト値(秒単位)です。QueryTimeoutプロパティは、JDBCドライバが、指定されたストアド・プロシージャまたはファンクションの実行を待機する最大秒数を指定します。しきい値に達すると、SQLExceptionがスローされます。値が0の場合は、ドライバは無期限で待機します。

9.7.2.2 重要な注意点

アダプタ構成ウィザードでは、Oracle Database、IBM DB2、AS/400、DB2/ZOS、Microsoft SQL Server、Sybase 15.7、Informix 11.7+、Progress Db 10およびMySQL v5.6以上がサポートされます。

この項には次のトピックが含まれます:

- Microsoft SQL Server

- DB2のデータ型

- IBM DB2 AS/400

9.7.2.2.1 Microsoft SQL Server

表9-15 に、SQL Serverのストアド・プロシージャおよびファンクションでサポートされるデータ型を示します。

表9-15 SQL Serverのストアド・プロシージャおよびファンクションのデータ型

SQLデータ型

XMLスキーマ型

BIGINT

long

BINARY

IMAGE

TIMESTAMP

VARBINARY

base64Binary

BIT

boolean

CHAR

SQL_VARIANT

SYSNAME

TEXT

UNIQUEIDENTIFIER

VARCHAR

XML (2005のみ)

string

DATETIME

SMALLDATETIME

dateTime

DECIMAL

MONEY

NUMERIC

SMALLMONEY

decimal

FLOAT

REAL

float

INT

int

SMALLINT

short

TINYINT

unsignedByte

9.7.2.2.2 DB2のデータ型

表9-16 に、DB2 SQLのストアド・プロシージャでサポートされるデータ型を示します。

表9-16 DB2 SQLのストアド・プロシージャのデータ型

SQLデータ型

XMLスキーマ型

BIGINT

long

BLOB

CHAR FOR BIT DATA

VARCHAR FOR BIT DATA

base64Binary

CHARACTER

CLOB

VARCHAR

string

DATE

TIME

TIMESTAMP

dateTime

DECIMAL

decimal

DOUBLE

double

INTEGER

int

REAL

float

SMALLINT

short

他のデータ型の名前も暗黙的にサポートされています。たとえば、NUMERICは(DECおよびNUMと同様に)DECIMALに相当します。

IBM DB2は、構造化されたデータ型(ユーザー定義)をサポートしています。ただし、JDBCドライバではこれらの型に対するサポートがありません。したがって、構造化されたデータ型をストアド・プロシージャのパラメータのデータ型として使用することはできません。IBM DB2では、ユーザー定義ファンクションもサポートしています。ただし、アダプタではこれらのファンクションがサポートされません。

アダプタ構成ウィザードではストアド・プロシージャはデータベース・ユーザーごとにグループ化されます。IBM DB2のスキーマは、Oracleのスキーマと同等のものです。どちらも、データベース・ユーザーの名前を表します。

IBM DB2の場合、<Default Schema>は現在のデータベース・ユーザーを指します。

別のデータベース・ユーザーを選択するには、「<デフォルト・スキーマ>」をクリックします。「参照」ページには、JDBC接続URLの<database>で指定されたデータベースにデータベース・ユーザーが作成したストアド・プロシージャが表示されます。

アダプタ構成ウィザードでは、別のデータベースへの変更はサポートされていません。

図9-46 に示すように、「ストアド・プロシージャ」ダイアログでストアド・プロシージャを選択します。引数は「引数」タブに表示されます。指定のデータベース内でユーザーが作成したデータベース・ストアド・プロシージャを検索するには、「検索」をクリックします。たとえば、d%とD%のどちらによってもDEMOストアド・プロシージャが検索されます。「すべて表示」をクリックすると、指定のデータベース内で現在のユーザーが作成したすべてのストアド・プロシージャが表示されます。

図9-46 「ストアド・プロシージャ」ダイアログ

図9-47 に示すように、「ソース」タブをクリックすると、ストアド・プロシージャのソース・コードを表示できます。

図9-47 ストアド・プロシージャのソース・コード

9.7.2.2.3 IBM DB2 AS/400

表9-17 に、IBM DB2 AS/400のストアド・プロシージャでサポートされるデータ型を示します。

表9-17 IBM DB2 AS/400のストアド・プロシージャのデータ型

SQLデータ型

XMLスキーマ型

BINARY

BINARY LARGE OBJECT

BINARY VARYING

base64Binary

CHARACTER

CHARACTER LARGE OBJECT

CHARACTER VARYING

string

DATE

TIME

TIMESTAMP

dateTime

DECIMAL

NUMERIC

decimal

DOUBLE PRECISION

double

BIGINT

long

INTEGER

int

REAL

float

SMALLINT

short

個別データ型も、CREATE DISTINCT TYPE文を使用して作成されるデータ型でサポートされています。これらのデータ型は、IBM DB2の場合と同様の振舞いをします。

IBM DB2 AS/400の実装は、QSYS2スキーマのカタログ表からの問合せをベースにしています。アダプタで、QSYS2.SCHEMATA表が存在するかどうかが確認されます。存在する場合は、アダプタ構成ウィザードでQSYS2スキーマの表に問合せが行われます。したがって、IBM DB2 AS/400データベースでQSYS2スキーマがサポートされている場合は、アダプタ構成ウィザードとアダプタ・ランタイムの両方が機能します。

アダプタ構成ウィザードでは、最初にSYSCATスキーマがチェックされ、次にQSYS2スキーマがチェックされます。アダプタでは、SYSIBMスキーマのカタログ表はサポートされていません。

9.7.2.3 データベース接続の作成

アダプタ構成ウィザードを機能させるために必要なカタログ表にアクセスするには、JDeveloperでデータベース接続を作成する必要があります。

JDeveloperを使用してデータベース接続を作成する手順は、次のとおりです。

1. 「表示」から「データベース・ナビゲータ」を選択します。

2. アプリケーション名を右クリックして「新規」と「接続」を順番にクリックします。「データベース接続」を選択します。
図9-48 に示すように、「データベース接続の作成」ページが表示されます。

図9-48 データベース接続の作成

3. 「接続名」フィールドに接続名を入力します。例: sqlserver。

4. 「接続タイプ」リストから、「接続タイプ」として「汎用JDBC」を選択します。

5. 「ユーザー名」、「パスワード」およびロール情報を入力します。

6. 「ドライバ・クラス」で「新規」をクリックします。図9-49 に示すように、「JDBCドライバの登録」ダイアログが表示されます。

図9-49 「JDBCドライバの登録」ダイアログ

7. ドライバ・クラスを入力します(たとえば、com.microsoft.sqlserver.jdbc.SQLServerDriver)。

8. 次の手順に従って、ライブラリを作成するか、既存のライブラリを編集します。

a. 「JDBCドライバの登録」ダイアログで「参照」をクリックします。

b. 「ライブラリの選択」ダイアログで「新規」をクリックします。
図9-50 に示すように、「ライブラリの選択」ダイアログが表示されます。

図9-50 「ライブラリの選択」ダイアログ

c. 既存のライブラリを選択するか、「新規」をクリックしてライブラリを作成します。
「ライブラリの作成」ダイアログが表示されます。

d. ライブラリ名を入力します。たとえば、SQL Server JDBCと入力します。

e. 「エントリの追加」をクリックして、JDBC JARファイルをクラスパスに追加します。

f. 「OK」を2回クリックして「ライブラリの作成」ウィンドウを終了します。

g. 「OK」をクリックして「JDBCドライバの登録」ウィンドウを終了します。

9. 「JDBC URL」に接続文字列名を入力します。

10. 「接続のテスト」をクリックします。

11. 接続が成功すると、図9-51 に示す画面が表示されます。

図9-51 「データベース接続の作成」ダイアログ

12. 「OK」をクリックし、「終了」をクリックします。

9.7.3 設計時: 成果物の生成

「アダプタ構成ウィザード - ストアド・プロシージャ」では、ストアド・プロシージャまたはファンクションのシグネチャを説明するWSDLファイルおよび有効なXSDファイルを作成できます。次の項では、WSDLファイルとXSDファイル両方の関連する構造およびコンテンツと、それぞれのリレーションシップを説明します。

この項には次のトピックが含まれます:

- WSDLとXSDのリレーションシップ

- JCAファイル

- Oracleデータ型

- 生成されたXSD属性

- ユーザー定義型

- 複雑なユーザー定義タイプ

- オブジェクト型の継承

- オブジェクト参照

- 別のスキーマのタイプの参照

- XSDプルーニングの最適化

9.7.3.1 WSDLとXSDのリレーションシップ

後続の段落では、前述の例で引用された操作名Factorialおよびプロシージャ名Factorialを使用します(図9-40 を参照)。生成されたWSDLにより、XSDファイルがインポートされます。

<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/FACTORIAL/"
schemaLocation="xsd/SCOTT_FACTORIAL.xsd"/>
</schema>
</types>

ネームスペースはスキーマ、パッケージおよびプロシージャ名から導出され、生成されたXSDではtargetNamespaceと表示されます。

InputParametersというルート要素が、ストアド・プロシージャのINおよびIN/OUTパラメータに対応する要素を指定するためにXSDファイルに作成されます。OutputParametersという別のルート要素も、IN/OUTまたはOUTパラメータがある場合にのみ、要素を指定するためにXSDファイルに作成されます。IN/OUTパラメータはどちらのルート要素にも出現します。

これらのルート要素は、XSDファイルでは無名のcomplexType定義として表現されます。定義の順序には、各パラメータの要素が1つ含まれます。INパラメータもIN/OUTパラメータもない場合は、InputParametersルート要素が作成されますが、complexTypeは空になります。XSDファイルのコメントで、そのようなパラメータはないことが示されます。ルート要素の例を次に示します。

<element name="InputParameters"
<complexType>
<sequence>
<element …>
…
</sequence>
</complexType>
</element>

WSDLでは、パートがこれら2つのルート要素によって定義されるメッセージ・タイプが定義されます。

<message name="args_in_msg"
<part name="InputParameters" element="InputParameters"/>
</message>
<message name="args_out_msg"
<part name="OutputParameters" element="OutputParameters"/>
</message>

dbネームスペースは、生成されたXSDのtargetNamespaceと同じです。args_out_msgはXSDファイルでOutputParametersルート要素が生成された場合にのみ含まれるのに対し、args_in_msgメッセージ・タイプは、常にWSDLに含まれます。

操作はWSDLで定義されます。このWSDLは、アダプタ・サービスと同じ名前で、入力および出力メッセージがこれら2つのメッセージ・タイプに関して定義されます。

<portType name="Factorial_ptt">
<operation name="Factorial">
<input message="tns:args_in_msg"/>
<output message="tns:args_out_msg"/>
</operation>
</portType>

出力メッセージはXSDファイルでのOutputParametersルート要素の存在に依存しますが、入力メッセージは常に表示されます。tnsネームスペースは操作名から導出され、WSDLで次のように定義されます。

xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/db/Factorial/"

XSDファイルのルート要素は、メッセージで使用されるパートの構造を定義します。このメッセージは、WSDLでカプセル化されたWebサービスで送受信されます。

WSDLの入力メッセージは、XSDファイルのInputParametersルート要素に対応します。インスタンスXMLは、ストアド・プロシージャのINおよびIN/OUTパラメータの値を提供します。出力メッセージは、OutputParametersルート要素に対応します。これは、ストアド・プロシージャが実行された後に生成されるXMLファイルです。任意のIN/OUTおよびOUTパラメータの値が保持されます。

9.7.3.2 JCAファイル

JCAファイルは、サービス用のアダプタ構成情報を提供します。コネクション・ファクトリが指定されているため、次の例に示すようにアダプタ・ランタイムがデータベースに接続できます。JCAファイルで管理対象外の接続プロパティを直接指定しないでください。かわりに、アプリケーション・サーバー上にコネクション・ファクトリを作成し、JCAファイルで名前を指定して参照します(<connection-factory location)。

<connection-factory location="eis/DB/oracle" UIConnectionName="oracle"
adapterRef="">
</connection-factory>

JNDI名eis/DB/oracleをアダプタ構成ウィザードでサービス接続として指定しています。

相互作用のエンドポイント・プロパティも指定されます。次の例に示すように、スキーマ、パッケージおよびプロシージャの名前が指定されます。操作名により、JCAファイルがサービスWSDLに関連付けられます。

<connection-factory location="eis/db/oracle" UIConnectionName="oracle"
adapterRef=""/>
<endpoint-interaction portType="Factorial_ptt" operation="Factorial">
<interaction-spec
className="oracle.tip.adapter.db.DBStoredProcedureInteractionSpec">
<property name="ProcedureName" value="FACTORIAL"/>
<property name="GetActiveUnitOfWork="false"/>
</interaction-spec>
</output>
</endpoint-interaction>

操作名とプロシージャ名に注意してください。明示的なスキーマが選択されている場合、またはパッケージ内でプロシージャが定義されている場合は、これらのプロパティの値もここに示されます。

注意:

JDeveloperを通常モードで起動すると、管理対象外の接続の詳細はDBAdapter.jcaファイルに作成されません。ただし、JDeveloperをプレビュー・モードで起動すると、管理対象外の接続の詳細がDBAdapter.jcaファイルに作成されます。

9.7.3.3 Oracleのデータ型

多くのプリミティブ・データ型には、詳細に定義されたマッピングが用意されているため、設計時および実行時のコンポーネントのどちらでもサポートされています。また、VARRAY、ネストされた表およびOBJECTなどのユーザー定義タイプを使用できます。

表9-18 に、Oracleのストアド・プロシージャおよびファンクションでサポートされるデータ型を示します。

表9-18 Oracleのストアド・プロシージャおよびファンクションのデータ型

SQLまたはPL/SQLタイプ

XMLスキーマ型

BINARY_DOUBLE

DOUBLE PRECISION

double

BINARY_FLOAT

FLOAT

REAL

float

BINARY_INTEGER

INTEGER

PLS_INTEGER

SMALLINT

int

BLOB

LONG RAW

RAW

base64Binary

CHAR

CLOB

LONG

STRING

VARCHAR2

string

DATE

TIMESTAMP

TIMESTAMPWITHTIMEZONE

dateTime

DECIMAL

NUMBER

decimal

9.7.3.4 生成されたXSD属性

表9-19 に、生成されたXSDで使用される属性をリスト表示します。

表9-19 生成されたXSD属性

属性

例

意味

name

name="param"

要素の名前

type

type="string"

XMLスキーマ型

db:type

db:type="VARCHAR2"

SQLまたはPL/SQLタイプ

db:index

db:index="1"

パラメータの位置

db:default

db:default="true"

デフォルト句がある場合

minOccurs

minOccurs="0"

最小発生数

maxOccurs

maxOccurs="1"

最大発生数

nillable

nillable="true"

NULL値の許可

dbネームスペースは、実行中に使用される属性と標準のXMLスキーマ属性の区別に使用されます。db:type属性は、データベース・タイプの特定に使用されるため、実行時に適切なJDBCタイプ・マッピングを取得できます。db:index属性は、設計時および実行時のコンポーネントの両方で最適化として使用され、パラメータが適切な順序に配置されていることを確認できます。パラメータ索引は、プロシージャでは1から、ファンクションでは0から開始されます。ファンクションの戻り値は、nameがファンクションの名前で、db:indexが0のOutputParameter要素として表現されます。db:default属性は、パラメータにデフォルト句があるかどうかを特定するために使用されます。

minOccurs値は、XMLファイルからのINパラメータの削除を可能にするために0に設定されます。これは、パラメータにパラメータの値を定義するデフォルト句(X IN INTEGER DEFAULT 0など)がある場合に便利です。実行時にXMLファイルのパラメータに要素が指定されていない場合、そのパラメータはストアド・プロシージャの起動から除外されるため、デフォルト値の使用が可能になります。各パラメータを、ストアド・プロシージャまたはファンクションの起動に使用できるのは最大で一度です。そのため、デフォルト値が常に1のmaxOccursは、パラメータを表す要素から常に除外されます。

nillable属性は、インスタンスXMLの対応する要素にNULL値(<X/>または<X></X>など)を許可するために、常にtrueに設定されています。ただし、NULL値のあるこのような要素を渡すには、(<X xsi:nil="true"/>のように)明示的に宣言する必要がある場合があります。nillable属性に使用されるネームスペースxsiは、インスタンスXMLに(xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"のように)明示的に宣言する必要があります。

9.7.3.5 ユーザー定義タイプ

アダプタ構成ウィザードでも、コレクション(VARRAYおよびネストされた表)およびOBJECTなどのユーザー定義タイプに有効な定義を生成できます。XSDファイルではcomplexType定義として作成されます。

VARRAYの場合、complexType定義によりその順序内にname_ITEMという単一の要素が定義されます。ここでnameはVARRAY要素の名前です。XMLファイルのすべての配列要素でそのように名前が付けられます。次のようなVARRAYタイプ定義があるとします。

SQL> CREATE TYPE FOO AS VARRAY (5) OF VARCHAR2 (10);

タイプがFOOのVARRAY要素Xの場合、次のようなcomplexTypeが生成されます。

<complexType name="FOO">
<sequence>
<element name="X_ITEM" db:type="VARCHAR2"
minOccurs="0" maxOccurs="5"
nillable="true"/>
<simpleType>
<restriction base="string">
<maxLength value="10"/>
</restriction>
</simpleType>
</sequence>
</complexType>

空のコレクションを許可するため、minOccurs値は0です。maxOccurs値は、コレクションで保持できる最大のアイテム数に設定されます。db:index属性は使用されていません。nillableをtrueに設定すると、VARRAYの個々のアイテムでNULL値を使用できます。

VARRAYの要素FOOで指定されている制限の使用に注意してください。これは、VARRAY(またはネストされた表)の宣言で長さがわかる、CHARおよびVARCHAR2などのタイプに使用されます。要素のタイプや最大長が指定されます。指定された長さを超える要素値は、スキーマ検証中にインスタンスXMLが停止する原因になります。

タイプFOOとして宣言されたパラメータの属性値は、生成されたXSDでは次のようになります。

<element name="X" type="db:FOO" db:type="Array" db:index="1"
minOccurs="0"
nillable="true"/>

typeおよびdb:typeの値は、パラメータがXSDファイルでFOOというcomplexTypeによって定義済の配列として表現されていることを示します。db:indexの値は、ストアド・プロシージャにおけるそのパラメータの位置です。

ネストされた表は、VARRAYとほぼ同じように処理されます。次にネストされた表のタイプ定義を示します。

SQL> CREATE TYPE FOO AS TABLE OF VARCHAR2 (10);

これは、その順序に単一の要素を含む、name_ITEMというcomplexTypeとしても生成されます。ネストされた表が任意のサイズであるためバインドされていないmaxOccurs値を除き、その要素にはVARRAYの例と同じ属性があります。

<complexType name="FOO">
<sequence>
<element name="X_ITEM" … maxOccurs="unbounded" nillable="true">
…
</element>
</sequence>
</complexType>

VARRAYのX_ITEM要素には同じ制限が生成されます。このタイプとして宣言されたXパラメータの属性は、VARRAYの例と同じです。

PL/SQLパッケージ仕様の内側で定義されたcollections (Varrayおよびネストした表)はサポートされません。次に例を示します。

SQL> create package pkg as
>   type vary is varray(10) of number;
>   type ntbl is table of varchar2(100;
>   procedure test(v in vary, n in ntbl);
> end;
> /

ユーザーがアダプタ構成ウィザードでストアド・プロシージャについてtestプロシージャを選択すると、そのタイプがサポートされていないことを示すエラーが発生します。ただし、パッケージ外部のルート・レベルでvaryおよびntblタイプ定義が定義されている場合は、testプロシージャを選択しても問題なく動作します。次の例に、コレクション・タイプ(Varrayおよびネストした表)についてサポートされている使用方法を示します。

SQL> create type vary as varray(10) of number;
SQL> create type ntbl as table of varchar2(10);
SQL> create package pkg as
>   procedure test(v in vary, n in ntbl);
> end;
/

OBJECT定義もcomplexTypeとして生成されます。その順序には、OBJECTの各属性に1つの要素が保持されています。

次にOBJECTを示します。

SQL> CREATE TYPE FOO AS OBJECT (X VARCHAR2 (10), Y NUMBER);

これは、順序要素が2つあるFOOというcomplexType定義として表現されています。

<complexType name="FOO">
<sequence>
<element name="X" db:type="VARCHAR2" minOccurs="0"
nillable="true"/>
<simpleType>
<restriction base="string">
<maxLength value="10"/>
</restriction>
</simpleType>
<element name="Y" type="decimal" db:type="NUMBER"
minOccurs="0"
nillable="true"/>
</sequence>
</complexType>

XMLファイルからの要素の削除を許可するため、minOccurs値は0です。これにより、OBJECTの対応する属性の値が実行時にNULLに設定されます。XMLファイルに空の要素を許可するためnillable値はtrueであり、要素の値がNULLであることを示すためにxsi:nil属性で注釈が付けられています。ここでも、db:index属性は使用されていません。

VARCHAR2属性の制限の使用に注意してください。OBJECTの属性の宣言から長さがわかります。

9.7.3.6 複雑なユーザー定義タイプ

ユーザー定義タイプは、必要に応じて複雑に定義できます。OBJECTには、前述の任意のユーザー定義タイプとして定義されているタイプの属性を含めることができます。OBJECTの属性のタイプが別のOBJECT、VARRAYまたはネストされた表などになります。VARRAYまたはネストされた表のベース・タイプも、OBJECTになる可能性があります。コレクションのベース・タイプが別のコレクションになることを許可することで、多次元のコレクションがサポートされます。

9.7.3.7 オブジェクト・タイプの継承

アダプタ構成ウィザードでは、OBJECTタイプの継承を使用してタイプが定義されているパラメータの有効なXSDを生成できます。次のようなタイプの階層があるとします。

SQL> CREATE TYPE A AS OBJECT (A1 NUMBER, A2 VARCHAR2 (10)) NOT FINAL;
SQL> CREATE TYPE B UNDER A (B1 VARCHAR2 (10));

また、プロシージャにはタイプがBのパラメータXが含まれるとします。

SQL> CREATE PROCEDURE P (X IN B) AS BEGIN … END;

アダプタ構成ウィザードでは、パラメータXにInputParameters要素が次のように生成されます。

<element name="X" type="db:B" db:index="1" db:type="Struct"
minOccurs="0"
nillable="true"/>

ここで、XSDファイルのOBJECTタイプBの定義は、次に示すcomplexTypeとして生成されます。

<complexType name="B">
<sequence>
<element name="A1" type="decimal" db:type="NUMBER" minOccurs="0"
nillable="true"/>
<element name="A2" db:type="VARCHAR2" minOccurs="0"  nillable="true">
...
</element>
<element name="B1" db:type="VARCHAR2" minOccurs="0"  nillable="true">
...
</element>
</sequence>
</complexType>

属性A2およびB1の最大長の制限が適切に追加されています。OBJECTタイプの階層が、階層全体のすべての属性に対応する要素の単一の順序にフラット化されていることに注意してください。

9.7.3.8 オブジェクト参照

アダプタ構成ウィザードでは、OBJECTタイプへの参照(オブジェクト参照など)であるパラメータや、定義にオブジェクト参照が含まれるユーザー定義タイプのパラメータの有効なXSDも生成できます。次に例を示します。

SQL> CREATE TYPE FOO AS OBJECT (…);
SQL> CREATE TYPE BAR AS OBJECT (F REF FOO, …);
SQL> CREATE PROCEDURE PROC (X OUT BAR, Y OUT REF FOO) AS BEGIN … END;

アダプタ構成ウィザードでは、FOOおよびBARのcomplexType定義が前述したように生成されます。ただし、BARでは、属性の要素Fは次のように生成されます。

<element name="F" type="db:FOO" db:type="Ref" minOccurs="0" nillable="true"/>

ここで、typeおよびdb:type属性値は、FがOBJECTタイプFOOへの参照であることを示します。

プロシージャPROCでは、XSDファイルのOutputParametersルート要素に次の要素が生成されます。

<element name="X" type="db:BAR" db:index="1" db:type="Struct" minOccurs="0"
nillable="true"/>
<element name="Y" type="db:FOO" db:index="2" db:type="Ref" minOccurs="0"
nillable="true"/>

Yでは、db:type属性の値がRefになっています。type属性とともに、要素定義ではYがFOOへの参照であることが示されています。

オブジェクト参照の使用には、パラメータ・モードがOUTのみに限られる制限があります。直接的なREFのAPI、またはパラメータ・タイプがユーザー定義の場合はそのタイプの定義にREFが含まれているAPIに、INまたはIN/OUTパラメータを渡すことはできません。

9.7.3.9 別のスキーマのタイプの参照

アクセスに必要な権限が付与されている場合には、別のスキーマに定義されているタイプを参照できます。たとえば、SCHEMA1でタイプOBJが宣言されたとします。

SQL> CREATE TYPE OBJ AS OBJECT (…);

SCHEMA2で宣言されているストアド・プロシージャのパラメータ・タイプを、SCHEMA1のタイプOBJにすることも可能です。

CREATE PROCEDURE PROC (O IN SCHEMA1.OBJ) AS BEGIN … END;

これは、SCHEMA1によりSCHEMA2にタイプOBJにアクセスする権限が付与された場合にのみ可能です。

SQL> GRANT EXECUTE ON OBJ TO SCHEMA2;

必要な権限が付与されていない場合には、SCHEMA2にプロシージャPROCの作成を試行するとエラーが発生します。

PLS-00201: identifier "SCHEMA1.OBJ" must be declared

権限が付与されていないので、SCHEMA1のOBJ型はSCHEMA2からは見えません。したがって、SCHEMA2はパラメータOの宣言においてこれを参照することはできません。

9.7.3.10 XSDプルーニングの最適化

一部のユーザー定義オブジェクト・タイプは、多数の属性を持つ場合があります。これらの属性は、同じく多数の属性を持つ他のオブジェクト・タイプによって定義することもできます。つまり、あるオブジェクト・タイプが、その定義の深さと複雑度によっては極端に大きくなる場合があります。

状況によっては、ラージ・オブジェクト・タイプの多数の属性が不要な場合もあります。これらの属性をオブジェクトのスキーマ定義から省略することが望ましい場合があります。そのためには、オブジェクト・タイプの定義から不要なXSD要素を物理的に削除します。

次の例では、ストアド・プロシージャが複雑なユーザー定義型のパラメータを持っています。

SQL> CREATE TYPE OBJ AS OBJECT (A, NUMBER, B <SqlType>, C <SqlType>, ...);
SQL> CREATE PROCEDURE PROC (O OBJ) AS BEGIN ... END;

InputParametersルート要素には、APIのシグネチャからのパラメータOの単一要素が含まれます。complexType定義は、次のコード・スニペットに示すようにオブジェクト・タイプの生成XSDに追加されます。

<complexType name="OBJ">
<sequence>
<element name="A" type="decimal" db:type="NUMBER" minOccurs="0"
nillable="true"/>
<element name="B" .../>
<element name="C" .../>
...
</sequence>
</complexType>

属性BおよびCが不要な場合は、OBJのcomplexType定義から対応する要素をタイプに関係なく削除できます。これらの属性の値は、インスタンスXMLでは不要です。パラメータOが出力パラメータだった場合、プルーニングされた属性に対応する要素も生成XMLでは省略されます。

パラメータAのタイプがユーザー定義オブジェクト・タイプでもあり、次の例に示すようにOBJの定義がそれに従って変更されたとします。

SQL> CREATE TYPE FOO AS OBJECT (X NUMBER, Y NUMBER, Z NUMBER);
SQL> CREATE TYPE OBJ AS OBJECT (A FOO, B <SqlType>, C <SqlType, ...);

その場合、APIに変更はありません。FOOの定義内で不要な属性に対応する要素も、そのタイプに関係なく削除できます。そのため、たとえばYが不要であれば、FOOのcomplexType定義内で対応する要素をXSDファイルから削除できます。

この方法でXSDファイルをプルーニングすると、アダプタの実行時パフォーマンスが向上し、メモリー使用量も大幅に削減できます。

注意:

プルーニングできるのは、ユーザー定義オブジェクト・タイプの属性のみです。対応する要素をInputParametersルート要素から削除することでストアド・プロシージャのパラメータをプルーニング(削除)することはできません。対応する要素を削除すると、パラメータにデフォルト句がない場合は実行時エラーになる可能性があります。

9.7.4 実行時: ストアド・プロシージャの起動前

この項では、ストアド・プロシージャのサポートに関する重要事項と、ストアド・プロシージャまたはファンクションの起動前に発生する動作に関する重要事項の概要を説明します。

この項には次のトピックが含まれます:

- 値のバインディング

- データ型の変換

9.7.4.1 値のバインディング

XMLファイルからの値の抽出と、それらの値が実行時にどのように作用するかを検討します。タイプがサポートされているプリミティブ・データ型であるパラメータ値に対応するXMLファイルのデータの場合、次の状況が想定されます。

1. 要素の値が指定されています(<X>100</X>など、この例ではX=100)。

2. 要素の値が指定されていません(<X/>など、この例ではX=NULL)。

3. 値がNULLとして明示的に指定されています(<X xsi:nil="true"/>など、この例ではX=NULL)。

4. 要素がXMLファイルで指定されていません(X = <default value>など)。

注意:

Microsoft SQL ServerとIBM DB2、MySQLおよびAS/400には、顕著な違いが1つあります。SQL Serverでは、ストアド・プロシージャの定義にデフォルト値を含めることのできるパラメータがサポートされています。IBM DB2、MySQLおよびAS/400ではパラメータのデフォルトがサポートされていないため、すべてのパラメータはインスタンスXMLで要素として表現する必要があります。

1つ目のケースでは、値はXMLファイルからそのまま取得され、タイプに応じて適切なオブジェクトに変換されます。そのオブジェクトは、ストアド・プロシージャ起動の準備中に、対応するパラメータにバインドされます。

2つ目と3つ目のケースでは、XMLファイルから抽出された実際の値はNULLです。タイプ・コンバータではNULLが許容され、変換されずに返されます。NULL値はタイプにかかわらず対応するパラメータにバインドされます。基本的に、これはパラメータXにNULLを渡すのと同じです。

4つ目のケースには2つの可能性があります。パラメータにデフォルト句がある場合とない場合です。パラメータにデフォルト句がある場合、そのパラメータをストアド・プロシージャの起動から除外できます。これにより、パラメータにデフォルト値が使用されます。パラメータを指定した場合は、かわりにそのパラメータの値が使用されます。パラメータにデフォルト句がない場合は、プロシージャの起動にパラメータを追加指定する必要があります。ファンクションのすべてのパラメータの要素を指定する必要があります。インスタンスXMLの要素に欠落がある場合、ファンクションは予想よりも少数の引数を使用して起動されます。

NULL値はデフォルトでパラメータにバインドされます。

SQL> CREATE PROCEDURE PROC (X IN INTEGER DEFAULT 0) AS BEGIN … END;

ここでは、パラメータにバインドされる値はありません。実際に、パラメータはストアド・プロシージャの起動から除外できます。これにより、0値がパラメータXのデフォルトに設定されます。

内容をまとめるため、次のPL/SQLが3つのケースのそれぞれで実行されたとします。

1. "BEGIN PROC (X=>?); END;" - X = 100

2. "BEGIN PROC (X=>?); END;" - X = null

3. 2つの可能性があります。

a. "BEGIN PROC (); END;" - X = 0 (Xにはデフォルト句がある)

b. "BEGIN PROC (X=>?); END;" - X = null (Xにはデフォルト句がない)

デフォルト句の処理を例外として、これらの一般的なセマンティクスは、コレクションのアイテム値、またはタイプがサポートされているプリミティブ・データ型であるOBJECTの属性値にも適用されます。ただし、タイプがユーザー定義の場合、<X/>のセマンティクスは大きく異なります。

コレクションの場合、次のタイプ定義だと仮定すると、VARRAYまたはネストされた表のいずれでも、後続の動作が予測されます。

SQL> CREATE TYPE ARRAY AS VARRAY (5) OF VARCHAR2 (10);

また、タイプがARRAYのパラメータXのXMLは次のようになります。

<X>
<X_ITEM xsi:nil="true"/>
<X_ITEM>Hello</X_ITEM>
<X_ITEM xsi:nil="true"/>
<X_ITEM>World</X_ITEM>
</X>

VARRAYの1つ目と3つ目の要素はNULLに設定されています。2つ目と4つ目には、それぞれの値が割り当てられています。XMLファイルでは5つ目の要素が指定されていないため、VARRAYインスタンスにある要素は4つのみです。

次のようなOBJECT定義であると仮定します。

SQL> CREATE TYPE OBJ AS OBJECT (A INTEGER, B INTEGER, C INTEGER);

また、タイプがOBJのパラメータXのXMLは次のようになります。

<X>
<A>100</A>
<C xsi:nil="true"/>
</X>

値100が属性Aに、NULLが属性BおよびCに割り当てられています。属性BのインスタンスXMLには要素がないため、NULL値が割り当てられています。

2つ目のケースでは、Xのタイプがユーザー定義の場合、<X/>の動作は異なります。XにNULLが割り当てられるのではなく、ユーザー定義タイプの初期化されたインスタンスが作成されてバインドされます。

前述のVARRAYの例では、<X/>または<X></X>が指定されている場合、Xにバインドされる値はVARRAYの空のインスタンスです。PL/SQLで、タイプ・コンストラクタを呼び出してXに値を割り当てるのと同等です。例:

X := ARRAY();

同様に、前述のOBJECTの例では、属性値すべてにNULLが割り当てられているOBJの初期化されたインスタンスは、Xにバインドされます。VARRAYのケースと同様に、タイプ・コンストラクタの呼出しと同等です。例:

X := OBJ(NULL, NULL, NULL);

Xのタイプがユーザー定義の場合にXに明示的にNULL値を割り当てるには、次のようにしてXMLファイルの要素にxsi:nil属性を追加します。

<X xsi:nil="true"/>

9.7.4.2 データ型の変換

この項では、CLOB、DATE、TIMESTAMPなどのデータ型、RAW、LONG RAW、BLOBなどのバイナリ・データ型、およびサード・パーティ・データベースでサポートされている類似のデータ型の変換について説明します。

Microsoft SQL Server、IBM DB2、AS/400およびMySQLでは、様々な書式のバイナリおよび日付データ型をストアド・プロシージャのパラメータにバインドする操作がサポートされています。これを表9-20 にまとめます。

表9-20 サード・パーティ・データベース: バイナリ値および日付値とストアド・プロシージャのパラメータとのバインディング

XMLスキーマ型

IBM DB2のデータ型

AS/400のデータ型

Microsoft SQL Server Serverデータ型

MySQLデータ型

base64Binary

BLOB

CHAR FOR BIT DATA

VARCHAR FOR BIT DATA

BINARY

BINARY LARGE OBJECT

BINARY VARYING

BINARY

IMAGE

TIMESTAMP

VARBINARY

BINARY

TINYBLOB

BLOB

MEDIUMBLOB

LONGBLOB

VARBINARY

dateTime

DATE

TIME

TIMESTAMP

DATE

TIME

TIMESTAMP

DATETIME

SMALLDATETIME

DATE

DATETIME

TIMESTAMP

CLOBパラメータについては、CLOBパラメータの長さが4KB未満の場合、XMLファイルから抽出されたテキストが追加の処理なしでString型としてこのパラメータにバインドされます。CLOBパラメータの長さが4KBより大きい場合、またはこのパラメータのモードがIN/OUTの場合は、一時CLOBパラメータが作成されます。その後、CLOBが対応するパラメータにバインドされる前に、XMLファイルのデータが一時CLOBに書き込まれます。一時CLOBパラメータは相互作用が完了すると解放されます。CHARおよびVARCHAR2など、その他のキャラクタ・タイプの場合には、データが必要に応じて抽出されてバインドされます。XMLドキュメントはCLOBパラメータ(または、十分な大きさの場合にはVARCHAR2)にバインドできます。ただし、まず<、>などを適切に置き換える必要があります(たとえば、<は&lt;に、>は&gt;に)。

値を対応するパラメータにバインドする前に、特別な処理を必要とするデータ型がいくつかあります。たとえば、XMLスキーマ型base64BinaryおよびdateTimeで表されるデータ型などです。

XMLスキーマ型dateTimeは、TIME、DATEおよびTIMESTAMPを表しています。これらのデータ型のXML値はdateTimeのXMLスキーマ表現に準拠する必要があります。そのため、単純なDATE文字列01-JAN-05は無効です。XMLスキーマでは、dateTimeはYYYY-MM-DDTHH:mm:ssとして定義されます。そのため、適切なDATE値は2005-01-01T00:00:00です。これらのパラメータの値は、この書式を使用してインスタンスXML内で指定する必要があります。

バイナリ・データ型のデータは、人間が理解できる方法で表現する必要があります。バイナリ・データの選択されたXMLスキーマ表現はbase64Binaryです。タイプ・コンバータでは、javax.mail.internet.MimeUtilityエンコードおよびデコードAPIを使用してバイナリ・データが処理されます。エンコードAPIは、すべてのバイナリ・データのbase64Binary形式へのエンコードに使用する必要があるため、XMLファイルでも使用できます。タイプ・コンバータでは、XMLデータのバイト配列へのデコードにデコードAPIが使用されます。base64Binaryデータのバイト配列への変換には、デコードAPIが使用されます。

BLOBパラメータについては、デコード値を含む長さが2KB未満である場合、バイト配列は追加の処理なしでそのパラメータにバインドされます。バイト配列の長さが2KBより大きい場合、またはパラメータのモードがIN/OUTの場合は、一時BLOBが作成されます。バイト配列はその後、対応するパラメータにバインドされる前に、BLOBに書き込まれます。一時BLOBは相互作用が完了すると解放されます。その他のバイナリ・データ型(RAWやLONG RAWなど)については、base64Binaryデータはバイト配列へとデコードされ、必要に応じてバインドされます。

その他のデータ型の変換は簡単なため、追加情報は必要ありません。

9.7.5 実行時: ストアド・プロシージャの起動後

プロシージャ(またはファンクション)を実行すると、任意のIN/OUTおよびOUTパラメータの値が取得されます。これらは、生成されたXSDのOutputParametersルート要素の要素値に対応します。

この項には次のトピックが含まれます:

- データ型の変換

- NULL値

- ファンクションの戻り値

9.7.5.1 データ型の変換

取得されたデータの変換は簡単です。ただし、CLOB(および他の文字データ)、RAW、LONG RAWおよびBLOBの変換と、サード・パーティ・データベースでサポートされている類似のデータ型の変換には特別な注意が必要です。

CLOBが取得されると、そのCLOBのコンテンツ全体が生成されたXMLの対応する要素に書き込まれます。標準のDOM APIを使用してXMLファイルが構成されます。したがって、CLOB、CHARおよびVARCHAR2などのタイプに関しては、値が有効であり後続の処理でXMLファイルに使用できるようにするため、必要に応じて文字データが伝達され、必要な置換えが行われます。そのため、たとえば、CLOBで保存されたXMLドキュメントの<および>の置換えが行われ、関連するパラメータの生成されたXML内の要素に使用された値は有効になります。

RAWおよびLONG RAWデータ型などのRAWデータは、バイト配列として取得されます。BLOBの場合、まずBLOBが取得され、そのコンテンツはバイト配列として取得されます。バイト配列は、javax.mail.internet.MimeUtilityエンコードAPIを使用してbase64Binary形式にエンコードされます。エンコードされた値は、すべて対応する要素のXMLファイルに配置されます。この値をバイト配列にデコードするには、MimeUtilityデコードAPIを使用する必要があります。

その他のデータ型の変換は簡単なため、追加情報は必要ありません。

9.7.5.2 NULL値

値がNULLの要素は、生成されたXMLでは空の要素として表示され、xsi:nil属性で注釈が付けられます。したがって、生成されるXMLファイルではxsiネームスペースが宣言されます。単一のOUTパラメータXがあり、値がNULLのプロシージャPROCの生成されたXMLは次のようになります。

<OutputParameters … xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<X xsi:nil="true"/>
</OutputParameters>

任意のタイプ(ユーザー定義タイプも含む)のパラメータのXML要素は、値がNULLの場合にはこのように表示されます。

9.7.5.3 ファンクションの戻り値

ファンクションの戻り値は、nameがファンクション自体の名前で、位置が0のOUTパラメータとして処理されます。例:

CREATE FUNCTION FACTORIAL (X IN INTEGER) RETURN INTEGER AS
BEGIN
IF (X <= 0) THEN RETURN 1;
ELSE RETURN FACTORIAL (X - 1);
END IF;
END;

たとえば、値が5のこのファンクションの起動は、値が120になり、生成されたXMLのOutputParametersルート要素では<FACTORIAL>120</FACTORIAL>と表示されます。

9.7.6 実行時: サード・パーティ・データベースの共通機能

実行時のサード・パーティ・データベースの共通機能は、次のとおりです。

- ResultSetsの処理

- INTEGERステータス値の戻し

9.7.6.1 ResultSetsの処理

すべてのサード・パーティ・データベースは、ResultSetsの処理について同じ機能を共有しています。ResultSetを戻すAPIのSQL Serverの例を次に示します。

1> create procedure foo ... as select ... from ...;
2> go

生成されたXSDで定義されているRowSetはResultSetを表します。RowSetは、それぞれ1列以上を含む0(ゼロ)行以上で構成されます。行は問合せで戻される行に対応します。列は問合せの列項目に対応します。次の例に、前述の例に示したAPIの実行後に生成されたXMLを示します。

<RowSet>
<Row>
<Column name="<column name>" sqltype="<sql datatype">value</Column>
...
</Row>
...
</RowSet>
…

name属性には問合せに表示される列の名前が格納されますが、sqltype属性にはその列のSQLデータ型(INTなど)が格納されます。valueは、その列の値となります。

APIでは複数のResultSetsが戻される場合があります。その場合、RowSetは生成されたXML内のResultSetごとに1つずつとなります。生成されたXMLでは、すべてのRowSetsが常に先頭に表示されます。

9.7.6.2 INTEGERステータス値の戻し

一部のデータベースでは、ストアド・プロシージャでRETURN文を使用してINTEGERステータス値を戻すことができます。Microsoft SQL ServerとAS/400は、両方ともこの機能をサポートしています。いずれの場合も、アダプタ構成ウィザードでは、ストアド・プロシージャがステータス値を戻すかどうかを決定できません。このため、ストアド・プロシージャが値を戻すことを指定する必要があります。これはチェック・ボックスを使用して指定できます。

「ストアド・プロシージャ」ダイアログでストアド・プロシージャを選択すると、図9-52 に示す「ストアド・プロシージャの指定」ページが表示されます。前述のチェック・ボックスはページの下部にあります。このチェック・ボックスを選択して、プロシージャにRETURN文を含めることを指定します。RETURN文が存在するかどうかを確認するには、プロシージャのソース・コードを表示します。

このチェック・ボックスは、この機能をサポートするデータベースのストアド・プロシージャに対してのみ表示されます。ファンクションに対しては、このチェック・ボックスは表示されません。ストアド・プロシージャによって戻された値は、生成されたXSDのOutputParametersルート要素内の要素として表示されます。要素の名前は、ストアド・プロシージャの名前になります。このチェック・ボックスを選択しない場合は、return文の値がストアド・プロシージャの実行後に消失します。

図9-52 「ストアド・プロシージャの指定」ページ

9.7.7 高度なトピック

この項では、提供されているストアド・プロシージャ機能を使用して、直接にはサポートされていないタイプのシナリオを説明します。次の各項では、これらのデータ型を使用する必要がある場合に取り組む解決策を説明します。

- 強い型指定のXSDを使用した行セットのサポート

- 弱い型指定のXSDを使用した行セットのサポート

- PL/SQLブール、PL/SQLレコードおよびPL/SQL表タイプのサポート

9.7.7.1 強い型指定のXSDを使用した行セットのサポート

REF CURSORはどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。

ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。

行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。アダプタ構成ウィザードを使用して、REF CURSORに対して強い型指定のXSDを生成できます。

使用例において、弱い型指定のXSDで十分である場合は、「弱い型指定のXSDを使用した行セットのサポート」を参照してください。

この項には次のトピックが含まれます:

- 設計時

- 実行時

詳細は、「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

9.7.7.1.1 設計時

選択したストアド・プロシージャまたはファンクションに、タイプがRowSetの出力パラメータが含まれる場合、このREF CURSORに対して強い型指定のXSDを次のように定義できます。

1. アダプタ構成ウィザードを使用して、タイプがRowSetの出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。
「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。

2. 「Next」をクリックします。図9-53 に示すように、「RowSets」ページが表示されます。
デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。次の例は、このデフォルトの弱い型指定のXSDを示しています。

図9-53 「RowSets」ページ

例 - デフォルトの弱い型指定のXSD

<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/SYS/MOVIES_
CURSORS/MOVIES_QUERY/" xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/SYS/MOVIES_CURSORS/MOVIES_QUERY/"
elementFormDefault="qualified">
<element name="InputParameters">
<complexType>
<sequence>
<element name="EXAMPLE" type="db:SYS.MOVIESOBJ" db:index="1" db:type="Struct"
minOccurs="0" nillable="true"/>
</sequence>
</complexType>
</element>
<element name="OutputParameters">
<complexType>
<sequence>
<element name="MOVIES" type="db:RowSet" db:index="2" db:type="RowSet"
minOccurs="0" nillable="true"/>
</sequence>
</complexType>
</element>
<complexType name="RowSet">
<sequence>
<element name="Row" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="Column" maxOccurs="unbounded" nillable="true">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="name" type="string" use="required"/>
<attribute name="sqltype" type="string" use="required"/>
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="SYS.MOVIESOBJ">
<sequence>
<element name="TITLE" db:type="VARCHAR2" minOccurs="0" nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="30"/>
</restriction>
</simpleType>
</element>
<element name="DIRECTOR" db:type="VARCHAR2" minOccurs="0" nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="30"/>
</restriction>
</simpleType>
</element>
<element name="STARRING" db:type="VARCHAR2" minOccurs="0" nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="30"/>
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
</schema>

3. ストアド・プロシージャまたはファンクションの各引数に対して、次の手順を実行します。

- 対応する「値」の列をダブルクリックします。

- 引数の値を入力します。
数値や文字列を直接入力したり、日付をリテラルとして(2009/11/11など)入力したり、MYOBJ('a', 'b')のような構造体を入力します。

- [Enter]を押します。

注意:

引数のタイプに対して有効であり、かつデータベース内に存在する値を選択する必要があります。

適切なストアド・プロシージャまたはファンクションのシグネチャが確実に実行されるようにするために、すべての引数に対して値を指定することをお薦めします。

4. 「イントロスペクト」をクリックします。
アダプタ構成ウィザードによって、指定した引数を使用するストアド・プロシージャまたはファンクションが実行されます。

a. ストアド・プロシージャまたはファンクションによって少なくとも1行を含む行セットが返される場合、「RowSets」ページが更新され、「XSD」テキスト・フィールドに強い型指定のXSDが表示されます。次の例に、前の例に示されているデフォルトの弱い型指定のXSDを置換する、強い型指定のXSDを示します。

図9-54 「RowSets」ページ: 正常なイントロスペクション

例 - 強い型指定のXSD

<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/SYS/MOVIES_
CURSORS/MOVIES_QUERY/" xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/SYS/MOVIES_CURSORS/MOVIES_
QUERY/" elementFormDefault="qualified">
<element name="InputParameters">
<complexType>
<sequence>
<element name="EXAMPLE" type="db:SYS.MOVIESOBJ" db:index="1"
db:type="Struct" minOccurs="0" nillable="true"/>
</sequence>
</complexType>
</element>
<element name="OutputParameters">
<complexType>
<sequence>
<element name="MOVIES" type="db:MOVIES_RowSet" db:index="2"
db:type="RowSet" minOccurs="0" nillable="true"/>
</sequence>
</complexType>
</element>
<complexType name="MOVIES_RowSet">
<sequence>
<element name="MOVIES_Row" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="TITLE" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="50"/>
</restriction>
</simpleType>
</element>
<element name="DIRECTOR" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="20"/>
</restriction>
</simpleType>
</element>
<element name="STARRING" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="100"/>
</restriction>
</simpleType>
</element>
<element name="SYNOPSIS" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="255"/>
</restriction>
</simpleType>
</element>
<element name="GENRE" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="70"/>
</restriction>
</simpleType>
</element>
<element name="RUN_TIME" type="decimal" db:type="NUMBER"
minOccurs="0" nillable="true"/>
<element name="RELEASE_DATE" type="dateTime" db:type="DATE"
minOccurs="0" nillable="true"/>
<element name="RATED" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="6"/>
</restriction>
</simpleType>
</element>
<element name="RATING" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="4"/>
</restriction>
</simpleType>
</element>
<element name="VIEWER_RATING" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="5"/>
</restriction>
</simpleType>
</element>
<element name="STATUS" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="11"/>
</restriction>
</simpleType>
</element>
<element name="TOTAL_GROSS" type="decimal" db:type="NUMBER"
minOccurs="0" nillable="true"/>
<element name="DELETED" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="5"/>
</restriction>
</simpleType>
</element>
<element name="SEQUENCENO" type="decimal" db:type="NUMBER"
minOccurs="0" nillable="true"/>
<element name="LAST_UPDATED" type="dateTime" db:type="DATE"
minOccurs="0" nillable="true"/>
<element name="POLLING_STRATEGY" db:type="VARCHAR2"
minOccurs="0" nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="30"/>
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="SYS.MOVIESOBJ">
<sequence>
<element name="TITLE" db:type="VARCHAR2" minOccurs="0" nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="30"/>
</restriction>
</simpleType>
</element>
<element name="DIRECTOR" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="30"/>
</restriction>
</simpleType>
</element>
<element name="STARRING" db:type="VARCHAR2" minOccurs="0"
nillable="true">
<simpleType>
<restriction base="string">
<maxLength value="30"/>
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
</schema>

ステップ5に進みます。

b. 行が返されない場合、図9-55 に示すように、「イントロスペクトに失敗しました」ダイアログが表示されます。

図9-55 「イントロスペクトに失敗しました」ダイアログ

アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。

ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。

c. ストアド・プロシージャまたはファンクションによって例外がスローされると、図9-56 に示すように、イントロスペクション・エラー・ダイアログが表示されます。

図9-56 イントロスペクション・エラー・ダイアログ

アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。

ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。

5. 必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、強い型指定のXSDを微調整します。

6. 「最上位のスタンドアロンAPIの使用」のステップ10に進みます。

9.7.7.1.2 実行時

次のパッケージがあるとします。

CREATE PACKAGE PKG AS
TYPE REF_CURSOR IS REF CURSOR;
PROCEDURE TEST(C OUT REF_CURSOR);
END;

CREATE PACKAGE BODY PKG AS
ROCEDURE TEST(C OUT REF_CURSOR) AS
BEGIN
OPEN C FOR SELECT DEPTNO, DNAME FROM DEPT;
END;
END;

アダプタ構成ウィザードを使用して強い型指定のXSDを定義し、プロシージャを実行した後、パラメータCについて次のXMLが生成されます。

<C>
<C_Row>
<DEPTNO>10</DEPTNO>
<DNAME>ACCOUNTING</DNAME>
</C_Row>
<C_Row>
<DEPTNO>11</DEPTNO>
<DNAME>DEVELOPMENT</DNAME>
</C_Row>
…
</C>

実行時に使用する場合、強い型指定のREF CURSORを記述するXSDがインライン化されるかインポートされるかは問題ではありません。

強い型指定のXSDがSOAランタイムによって適用され、適切な場所に表示されます。たとえば、図9-57 に、強い型指定のXSDを使用したREF CURSORペイロードを返すinvokeの監査証跡を示します。

図9-57 強い型指定のペイロードの監査証跡

9.7.7.2 弱い型指定のXSDを使用した行セットのサポート

REF CURSORはどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。デフォルトでは、アダプタ構成ウィザードによってREF CURSORに対して弱い型指定のXSDが生成されます。

ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。

行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。

使用例において、強い型指定のXSDがより適している場合は、「強い型指定のXSDを使用した行セットのサポート」を参照してください。

この項には次のトピックが含まれます:

- 設計時

- 実行時

詳細は、「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

9.7.7.2.1 設計時

選択したストアド・プロシージャまたはファンクションに、タイプがResultSetである出力パラメータが含まれている場合は、このREF CURSORのための弱い型指定のXSDを次のように定義できます。

1. アダプタ構成ウィザードを使用して、タイプがResultSetの出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。

「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。

2. 「次」を選択します。図9-58 に示すように、「RowSets」ページが表示されます。

デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。

図9-58 「RowSets」ページ

3. 必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、弱い型指定のXSDを微調整します。

4. 「最上位のスタンドアロンAPIの使用」のステップ10に進みます。

9.7.7.2.2 実行時

次のパッケージがあるとします。

CREATE PACKAGE PKG AS
TYPE REF_CURSOR IS REF CURSOR;
PROCEDURE TEST(C OUT REF_CURSOR);
END;

CREATE PACKAGE BODY PKG AS
ROCEDURE TEST(C OUT REF_CURSOR) AS
BEGIN
OPEN C FOR SELECT DEPTNO, DNAME FROM DEPT;
END;
END;

REF_CURSORは、問合せが指定されていないため弱い型指定のカーソル変数です。プロシージャの実行後、パラメータCについて次のXMLが生成されます。

<C>
<Row>
<Column name="DEPTNO" sqltype="NUMBER">10</Column>
<Column name="DNAME" sqltype="VARCHAR2">ACCOUNTING</Column>
</Row>
<Row>
<Column name="DEPTNO" sqltype="NUMBER">20</Column>
<Column name="DNAME" sqltype="VARCHAR2">RESEARCH</Column>
</Row>
…
</C>

合計4行があり、各行が2つの列DEPTNOおよびDNAMEで構成されています。

REF CURSORは、Java ResultSetsで表されます。JDBCドライバで提供されるAPIを使用してResultSetをプログラムで作成することはできません。したがって、REF CURSORをストアド・プロシージャにINとして渡すことはできません。IN/OUTおよびOUTパラメータとしてのみ渡すことができますが、1つ注意点があります。IN/OUT REF CURSORは、OUTパラメータとしてのみ処理されます。IN/OUTパラメータではIN値を提供できないため、そのパラメータにはストアド・プロシージャの起動時にNULLがバインドされます。

9.7.7.3 PL/SQLブール、PL/SQLレコードおよびPL/SQL表タイプのサポート

アダプタ構成ウィザードには、これらのタイプが使用され、Oracle JPublisherが起動して必要なラッパーが自動的に生成される時期を検出するメカニズムがあります。Oracle JPublisherでは、スキーマ・オブジェクトの生成用とその削除用の2つのSQLファイルが生成されます。スキーマ・オブジェクトを作成するSQLはアダプタ構成ウィザード内で自動的に実行され、XSDファイルが生成される前にデータベース・スキーマにスキーマ・オブジェクトが作成されます。たとえば、次のパッケージ仕様が宣言されたとします。

CREATE PACKAGE PKG AS
TYPE REC IS RECORD (X NUMBER, Y VARCHAR2 (10));
TYPE TBL IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
PROCEDURE PLSQL (R REC, T TBL, B BOOLEAN);
END;

図9-59 に、PKGパッケージのPROCプロシージャが選択されると表示されるアダプタ構成ウィザードでの手順を示します。

図9-59 アダプタ構成ウィザードにおけるストアド・プロシージャの指定

図9-59 に示すように、元のプロシージャ名は完全修飾され、PKG.PLSQLとなっています。パラメータ・タイプRはRECORDの名前です。タイプTはTABLEの名前です。タイプBはBooleanです。生成されているラッパー・パッケージの名前は、サービス名bpel_ServiceName(bpel_UseJPubなど)から導出されます。これは、生成されたパッケージの名前で、ラッパー・プロシージャが含まれています。チェック・ボックスは、スキーマ・オブジェクトの作成時に、アダプタ構成ウィザードで既存のパッケージの上書きを強制する際に使用できます。

図9-60 に示すように、「次へ」をクリックすると、アダプタ構成ウィザードの「終了」ページが表示されます。

図9-60 データベース・アダプタ・サービスの定義: 「終了」ページ

このページのコンテンツでは、アダプタ構成ウィザードで検出されたものと、「終了」ボタンがクリックされると実行される処理が説明されます。次に、このページのコンテンツをまとめます。

1. 生成されたWSDLの名前はUseJPub.wsdlです。

2. JCAファイルの名前はUseJPub_db.jcaです。

3. 2つのSQLスクリプトが作成され、BPELプロセス・プロジェクトに追加されます。

a. BPEL_USEJPUB.sql - スキーマ・オブジェクトが作成されます。

b. BPEL_USEJPUB_drop.sql - スキーマ・オブジェクトが削除されます。

4. 生成されたXSDの名前はSCOTT_USEJPUB_PKG-24PLSQL.xsdです。

「終了」をクリックすると、Oracle JPublisherが起動され、SQLファイルが生成されてデータベースにスキーマ・オブジェクトがロードされます。ラッパーの生成プロセスは、完了に時間がかかります。初期ラッパーが同じパッケージ内の別のプロシージャに生成された後は、通常、同じパッケージに生成されるラッパーの処理時間は短くなります。

注意:

Oracleデータベース・アダプタを再作成するときには、BPEL_XXXX_drop.sqlを実行する必要があります。これは、キャッシュを使用してラッパーを生成するJPublisher機能に備えて実行します。

次に示すユーザー定義タイプは、PL/SQLタイプを元のプロシージャから置き換えるために生成されます。

SQL> CREATE TYPE PKG_REC AS OBJECT (X NUMBER, Y VARCHAR2 (10));
SQL> CREATE TYPE PKG_TBL AS TABLE OF NUMBER;

これらのタイプのネーミング規則は、OriginalPackageName_OriginalTypeNameです。Booleanは、ラッパー・プロシージャでINTEGERに置き換えられます。

現在はINTEGERである、元のBooleanパラメータの許容値は、FALSEが0でTRUEが0以外のINTEGER値です。1以外の値はfalseとみなされます。生成されたラッパー・プロシージャでは、SYS.SQLJUTLパッケージのAPIが使用され、INTEGERとBooleanが相互に変換されます。

PKG$PPLSQLというプロシージャPLSQLのラッパー、およびPL/SQLタイプとユーザー定義タイプの相互変換を行う変換APIが含まれる、BPEL_USEJPUBという新しいラッパー・パッケージが作成されます。元のプロシージャがルートレベルのプロシージャの場合、生成されたラッパー・プロシージャの名前はTOPLEVEL$OriginalProcedureNameです。

生成されたXSDは、元のプロシージャではなく、ラッパー・プロシージャPKG$PLSQLのシグネチャを表します。XSDファイルの名前はURLエンコードされ、$が-24に置き換えられます。

生成された成果物のネーミング規則を示します。

- サービス名は、WSDLおよびSQLファイルの名前に使用されます。ラッパー・パッケージの名前にも使用されます。

- 生成されたXSDの名前は、スキーマ名、サービス名、および元のパッケージ名とプロシージャ名から導出されます。

- SQLオブジェクトまたはコレクション・データ・タイプの名前は、元のパッケージ名および対応するPL/SQLタイプの名前から導出されます。

- ラッパー・プロシージャの名前は、元のパッケージ名とプロシージャ名から導出されます。TOPLEVEL$は、ルートレベルのプロシージャに使用されます。

注意:
アダプタ構成を使用する前に、JCAファイルを調べて、それを生成されたSQLスクリプトと比較してください。JCAファイルのパラメータの値が、生成されたSQLファイルにあることを確認してください。たとえば、パラメータは次のような値を持つ必要があります。

<property name="PackageName" value="BEPL_USEJPUB"/>
<property name="ProcedureName" value="PKG$PLSQL"/>

生成されたラッパー・パッケージの名前は30文字に制限されます。ラッパー・プロシージャの名前は29文字に制限されます。Oracle JPublisherで生成された名前がこれらの制限よりも長い場合は、切り捨てられます。

プロシージャに関連付けられたサービスに対応するPartnerLinkが起動されると、生成されたラッパー・プロシージャは元のプロシージャのかわりに実行されます。

9.7.7.3.1 ラッパー・プロシージャのデフォルト句

プロシージャにラッパーの生成を必要とする特殊な型が含まれている場合は、いずれのパラメータのデフォルト句もラッパーには持ち越されません。たとえば、次のようなプロシージャがあるとします

SQL> CREATE PROCEDURE NEEDSWRAPPER (
>     B BOOLEAN DEFAULT TRUE, N NUMBER DEFAULT 0) IS BEGIN … END;

これがルートレベルのプロシージャであると仮定すると、生成されるラッパー・プロシージャのシグネチャは次のようになります。

TOPLEVEL$NEEDSWRAPPER (B INTEGER, N NUMBER)

BooleanタイプがINTEGERに置き換えられています。生成されたラッパーには、どちらのパラメータのデフォルト句もありません。元のプロシージャにデフォルト句があったとしても、生成されるラッパー・プロシージャのパラメータには、デフォルト句はありません。

この例で、いずれかのパラメータの要素がインスタンスXMLに指定されていない場合、指定した引数の数が正しくないことを示すエラーが発生します。元のプロシージャに指定されているパラメータのデフォルト値は使用されません。

この状況に対応するには、デフォルト句をラッパー・プロシージャのパラメータにリストアして、ラッパーを作成する生成されたSQLファイルを編集する必要があります。その後、ラッパーおよびその他のスキーマ・オブジェクトをデータベース・スキーマにリロードする必要があります。SQLファイルの編集後、ラッパー・プロシージャのシグネチャは次のようになります。

TOPLEVEL$NEEDSWRAPPER (B INTEGER DEFAULT 1, N NUMBER DEFAULT 0)

Booleanパラメータの場合、trueのデフォルト値は1で、falseのデフォルト値は0です。

最後の手順として、ラッパーに生成されたXSDファイルを編集する必要があります。デフォルト句を持つパラメータを表す要素に、特別な属性を追加する必要があります。デフォルト句を持つパラメータを表す各要素にdb:default="true"を追加します。例:

<element name="B" … db:default="true" …/>
<element name="N" … db:default="true" …/>

この属性は、インスタンスXMLに要素がない場合、プロシージャ・コールから対応するパラメータを除外する必要があることを示すために実行時に使用されます。これらの要素のその他の属性は元のままです。

9.8 Oracleデータベース・アダプタの使用例

この項では、Oracleデータベース・アダプタとOracleデータベース・アダプタ - ストアド・プロシージャの使用例について説明します。

この項には次のトピックが含まれます:

- Oracleデータベース・アダプタの使用例

- Oracleデータベース・アダプタ - ストアド・プロシージャの使用例

- データベース・アダプタ/Coherence統合

9.8.1 使用例

使用例を入手するには、Oracle SOA Sample Codeサイトにアクセスします。

表9-21 には、そのサンプル・コード・サイトのデータベース・アダプタの例をまとめています。

表9-21 サンプル・ページ・サイトのアダプタの例

サンプル

説明

adapters-db-101-MasterDetail.zip

MasterDetailチュートリアルは、1つのデータベースの1セットの表のデータを同じ/別のデータベースの表にレプリケートする単純なシナリオを示しています。

adapters-db-103-File2StoredProcedure.zip

この例は、ストアド・プロシージャの起動とのインタフェースとなるファイル・アダプタの使用について説明しています。

adapters-db-102-Select.zip

Selectチュートリアルは、より大きなBPELプロセスの一部として、あるいはWebサービス呼出しとして独立してDMLの選択/挿入/更新/削除を起動する方法を示しています。

adapters-db-104-InformixStoredProcedure.zip

このシナリオは、Informixインスタンスでストアド・プロシージャを起動するデータベース・アダプタのパートナ(アウトバウンド・アダプタ・サービス)を示しています。

adapters-db-105-SybaseStoredProcedure.zip

このシナリオは、Sybaseインスタンスでストアド・プロシージャを起動するデータベース・アダプタのパートナ(アウトバウンド・アダプタ・サービス)を示しています。

adapters-db-107-Polling.zip

この例は、3つの基本ポーリング戦略や、データベース上のイベントをBPELプロセスまたはSOAプロセスの開始インスタンスに変換する方法を示しています。

adapters-db-201-MovieImages.zip

この例では、SOAを使用してJPGなどのバイナリ・ファイルをデータベース内のBLOB列に読み込む方法と、その表からファイルに読み戻す方法が示されています。

adapters-db-203-RefCursors.zip

Ref Cursorチュートリアルは、行セットを返すストアド・プロシージャの使用方法を示しています。

adapters-db-207-AdvancedPolling.zip

この例は107-Pollingの続きで、コア・ポーリング戦略のより現実的かつ高度なバージョンが示されています。

adapters-db-307-ExpertPolling.zip

このボーナス・サンプルは207-AdvancedPollingの続きで、イベントのポーリングをUI内で公開されるもの以外でカスタマイズするいくつかの方法が示されています。

9.8.2 Oracleデータベース・アダプタ - ストアド・プロシージャの使用例

この項には、次の項目が含まれます。

- BPELデザイナにおけるストアド・プロシージャの作成および構成

- ファイルからストアド・プロシージャへの使用例

この項で説明する使用例の他に、Oracle SOA Sample Codeサイトにアクセスして入手できるサンプルの使用例も参照してください。

表9-22に、Oracle BPEL PMで提供されているOracleデータベース・アダプタのストアド・プロシージャのサンプルを示します。

表9-22 使用例 - ストアド・プロシージャ

チュートリアル名

説明

JPublisherWrapper

PL/SQL RECORDタイプの使用に関する解決策を説明します。JPublisherは、属性がRECORDのフィールドに一致する対応するOBJECT型、およびRECORDとOBJECTの相互変換を行う変換APIの作成に使用されます。また、JPublisherではOBJECTを許可し、両方向で変換APIを使用して基礎となるメソッドを起動するラッパー・プロシージャ(またはファンクション)が生成されます。起動されたメソッドが、(Oracle Liteではない)Oracleデータベースにインストールされている必要があります。

RefCursors

強い型指定のXSDまたは弱い型指定のXSDを使用したREF CURSORを使用する方法について説明します。アダプタ構成ウィザードを使用して、Oracleデータベースのストアド・プロシージャまたはファンクションのREF CURSOR変数によって返される行セットのための、強い型指定のXSDを作成できます。詳細は、「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

ResultSetConverter

REF CURSORの使用に関する解決策を説明します。解決策には、対応するjava.sql.ResultSetをOBJECTの集合(VARRAYまたはNESTED TABLE)に変換するJavaストアド・プロシージャの使用が関連します。

使用例の多くで使用されているMOVIES表の構造は、表9-4 を参照してください。ほとんどのサンプルに含まれているreadme.txtファイルには、説明が記載されています。

9.8.2.1 JDeveloper BPELデザイナにおけるストアド・プロシージャの作成および構成

この使用例では、JDeveloper BPELデザイナを使用したBPEL Process Managerへのストアド・プロシージャの統合方法について説明します。

この使用例には、次の項目が含まれます。

- 前提条件

- アプリケーションおよびSOAコンポジットの作成

- アウトバウンド・サービスの作成

- invokeアクティビティの追加

- リクエスト・メッセージのメッセージ・パートの変更

- レスポンス・メッセージのメッセージ・パートの変更

- 入力変数のassignアクティビティの追加

- 出力変数のassignアクティビティの追加

- JDeveloperを使用したデプロイ

- Oracle WebLogic Server管理コンソールでのデータソースの作成

- Fusion Middleware Controlコンソールを使用した監視

9.8.2.1.1 前提条件

この使用例を実行するには、SCOTTスキーマ内で次のストアド・プロシージャを定義する必要があります。

SQL> CREATE PROCEDURE hello (name IN VARCHAR2, greeting OUT VARCHAR2) AS
2  BEGIN
3     greeting := 'Hello ' || name;
4  END;
5/

9.8.2.1.2 アプリケーションおよびSOAコンポジットの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。

「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにMyHelloAppと入力して「次へ」をクリックします。

「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにHelloProjectと入力します。

4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

5. 「次へ」をクリックします。

「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ページが表示されます。

7. 「名前」フィールドにGreetと入力し、「テンプレート」ボックスから「同期BPELプロセス」を選択します。

8. 「OK」をクリックします。

図9-61 に示すように、MyHelloAppのHelloProject内のGreet BPELプロセスが設計領域に表示されます。

図9-61 JDeveloper - composite.xml

9.8.2.1.3 アウトバウンド・サービスの作成

アウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント・パレット」から、「データベース・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「Next」をクリックします。
「サービス名」ページが表示されます。

3. 「サービス名」フィールドにHelloと入力します。

4. 「Next」をクリックします。
「サービス接続」ページが表示されます。

注意:

このアプリケーションをデプロイする前に、weblogic-ra.xmlファイル内でJNDI名を構成していることを確認してください。

詳細は、「データソースの作成」および「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。

5. 「新規データベース接続を作成します。」アイコンをクリックします。
「データベース接続の作成」ダイアログが表示されます。

6. 「データベース接続の作成」ダイアログで次の詳細を入力します。

a. 「接続名」フィールドに接続名を入力します。例: Myconnection。

b. 接続タイプとして「Oracle (JDBC)」を選択します。

c. ユーザー名およびパスワードとしてscott/tigerと入力します。

d. 「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。

e. 「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。

f. 「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。

g. 「OK」をクリックします。

「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。

7. 「Next」をクリックします。
「操作タイプ」ページが表示されます。

8. 「ストアド・プロシージャまたはファンクションの呼出し」を選択して、「次へ」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。

9. 「参照」をクリックします。「ストアド・プロシージャ」ペインでHELLOを選択します。
「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。

10. 「OK」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。「プロシージャ」フィールドにHELLOストアド・プロシージャが移入され、HELLOストアド・プロシージャの引数も表示されます。

11. 「Next」をクリックします。
「詳細オプション」ページが表示されます。

12. 任意の追加の詳細オプションを指定して、「次へ」をクリックします。
アダプタ構成ウィザードの「終了」ページが表示されます。

13. 「終了」をクリックします。
「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。パートナ・リンク名は、サービス名と同じHelloです。

14. 「OK」をクリックします。
アウトバウンドOracleデータベース・アダプタが構成され、Greet BPELプロセスが表示されます。

9.8.2.1.4 invokeアクティビティの追加

次の手順に従ってinvokeアクティビティを追加します。

1. 「コンポーネント・パレット」から、invokeアクティビティを設計領域のreceiveInputアクティビティとreplyOutputアクティビティの間にドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。

「Invokeの編集」ダイアログが表示されます。

3. 「名前」フィールドにInputと入力します。

4. 「Invoke」ボックスで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。

「変数の作成」ダイアログが表示されます。

5. デフォルトの変数名を選択し、「OK」をクリックします。

「入力変数」フィールドにデフォルトの変数名が移入されます。「Invoke」ダイアログが表示されます。

6. 同じ手順を繰り返して、「出力変数」フィールドで出力変数を選択します。

「Invokeの編集」ダイアログの「変数」セクションに、入力変数名と出力変数名が表示されます。

7. 「OK」をクリックします。

図9-62 に示すように、Helloパートナ・リンクに接続された右矢印付きの線が表示されます。

図9-62 「Greet.bpel」ページ

9.8.2.1.5 リクエスト・メッセージのメッセージ・パートの変更

リクエストのペイロードがInputParametersと一致する場合、すべてのINパラメータがリクエストに含まれます。この例では、INパラメータはnameのみです。

次の手順に従って、GreetRequestMessageメッセージのメッセージ・パートを変更します。

1. Greet BPELプロセスの「構造」ペイン(「アプリケーション」ペインの下)で、「メッセージ・タイプ」、「プロセスWSDL - Greet.wsdl」および「GreetRequestMessage」を順番に開きます。

2. 「payload」を選択して「編集」アイコンをクリックします。

「メッセージ・パートの編集 - payload」ダイアログが表示されます。

3. 「要素」を選択して「検索」アイコンをクリックします。

「タイプ・チューザ」ダイアログが表示されます。

4. 「プロジェクトのスキーマ・ファイル」と「SCOTT_HELLO.xsd」を順番に開き、「InputParameters」を選択します。

5. 「OK」をクリックします。

「メッセージ・パートの編集 - payload」ダイアログが表示されます。

6. 「OK」をクリックします。

9.8.2.1.6 レスポンス・メッセージのメッセージ・パートの変更

レスポンスのペイロードがOutputParametersと一致する場合、すべてのOUTパラメータがレスポンスに含まれます。この例では、OUTパラメータはgreetingのみです。

GreetResponseMessageメッセージ・パートに関する手順はGreetRequestMessageの場合と同じですが、次の例外があります。

1. 「GreetResponseMessage」メッセージ・タイプを開き、「payload」を選択します。

2. 「タイプ・チューザ」ダイアログで「SCOTT_HELLO.xsd」を開き、「OutputParameters」を選択します。

3. 「OutputParameters」を選択します。

9.8.2.1.7 入力変数のassignアクティビティの追加

次の手順に従って入力変数のassignアクティビティを追加します。

1. 「コンポーネント・パレット」から、assignアクティビティを設計領域のreceiveInputおよびGreetというinvokeアクティビティの間にドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。

「Assign」ダイアログが表示されます。

3. 「一般」をクリックし、「名前」フィールドで名前をNAMEに変更します。

4. 「コピー操作」タブでプラス・アイコンをクリックし、表示された操作リストから「コピー操作」を選択します。

「コピー操作の作成」ダイアログが表示されます。

5. 「From」領域で、「変数」、「inputVariable」および「payload」を順番に開いて「ns2:InputParameters」を選択します。

6. 「To」領域で、「変数」、「Input_Hello_InputVariable」および「InputParameters」を順番に開いて「ns2:InputParameters」を選択します。

7. 「OK」をクリックします。

入力パラメータへの値の割当てを完了しました。

図9-63 に示すように、「Assign」ダイアログが表示されます。このダイアログには、inputVariableのペイロードからInput_Hello_InputVariableのペイロードへの割当てが表示されます。

図9-63 「コピー操作の作成」ダイアログ

8. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.1.8 出力変数のassignアクティビティの追加

2つ目のassignアクティビティでは、出力パラメータに値を割り当てます。

出力パラメータに値を割り当てる手順は、入力パラメータに値を割り当てる場合と同じですが、次の例外があります。

1. 「コンポーネント・パレット」から、assignアクティビティを設計領域のGreet invokeアクティビティとreplyOutputアクティビティの間にドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。

「Assign」ダイアログが表示されます。

3. 「名前」フィールドにGreetingと入力します。

4. 「コピー操作」タブでプラス・アイコンをクリックし、表示された操作リストから「コピー操作」を選択します。

「コピー操作の作成」ダイアログが表示されます。

5. 図9-64 に示すように、「From」ペインで「Input_Hello_OutputVariable」および「OutputParameters」を順番に開いて「ns2:OutputParameters」を選択します。

6. 図9-64 に示すように、「To」ペインで「outputVariable」および「payload」を順番に開いて「ns2:OutputParameters」を選択します

図9-64 「コピー操作の作成」ダイアログ

7. 「OK」をクリックします。

出力パラメータへの値の割当てを完了しました。

8. 「ファイル」、「すべて保存」を順番にクリックします。

BPELプロセスのモデル化を完了しました。図9-65 に示すように、最終的なBPELプロセスが表示されます。

図9-65 最終的なBPELプロセスの画面

9.8.2.1.9 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. 「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明されている手順を使用して、アプリケーション・サーバー接続を作成します。

2. 「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

9.8.2.1.10 Oracle WebLogic Server管理コンソールでのデータソースの作成

HelloProjectをテストする前に、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。

手順は次のとおりです。

1. Webブラウザにhttp://<hostname>:<port>/consoleと入力します。

2. ユーザー名とパスワードを入力して「ログイン」をクリックします。

管理コンソールが表示されます。

3. 「JDBC」の下の「サービス」領域で「データ・ソース」をクリックします。

「JDBCデータ・ソースの概要」が表示されます。

4. 「新規」をクリックします。

「新しいJDBCデータ・ソースの作成」ページが表示されます。

5. 「新しいJDBCデータ・ソースの作成」ページで、次の詳細を入力します。

- 「名前」フィールドにMyDataSourceと入力します。

- 「JNDI名」フィールドにjdbc/MyDataSourceと入力します。

- 「データベースのタイプ」はOracleです。

- 「データベース・ドライバ」は、Oracle's Driver (Thin XA) for Instance Connections; Versions 9.0.1, 9.2.0, 10, 11です。

6. 「次へ」をクリックします。

別のトランザクション構成オプションはないことを示すメッセージが表示されます。

7. 「次へ」をクリックします。

「新しいデータ・ソースの作成」ページが表示されます。

8. 次の詳細を入力します。

- データベース名: 通常はSIDです。

- ホスト名: ホスト・コンピュータ名を入力します。

- ポート番号: ポート番号を入力します。
デフォルト・ポートは1521です。

- データベース・ユーザー名: SCOTTと入力します。

- パスワード: TIGERと入力します。

- パスワードの確認: TIGERと入力します。

9. 「次へ」をクリックします。

データソース構成の概要が表示されます。

10. 「構成のテスト」をクリックします。

「メッセージ」領域に、接続テストに成功したことが示されます。

11. 「次」を選択します。「AdminServer」チェック・ボックスを選択してターゲットとして選択します。

12. 「終了」をクリックします。

これで、前述の手順で作成したMyDataSourceデータソースがJDBCデータソースの概要に含まれます。

9.8.2.1.11 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。前述の手順で作成したHelloProject[1.0]を含めて、SOAコンポジットのリストが表示されます。

2. 「HelloProject[1.0]」リンクをクリックします。図9-66 に示すように、「ダッシュボード」タブが表示されます。

図9-66 HelloProject[1.0]プロジェクトの「ダッシュボード」タブ

3. 「テスト」をクリックします。新規のブラウザ・ウィンドウが表示されます。

4. xsd:stringでマーク付けされている「NAME」フィールドに名前を入力し、「呼出し」をクリックします。

ブラウザ・ウィンドウにテスト結果が表示されます。

5. 読取り可能な書式のXMLファイルを表示するには、「フォーマット済XML」をクリックします。図9-67 に、フォーマット済XMLファイルを示します。

図9-67 フォーマット済XMLファイル

9.8.2.2 ファイルからストアド・プロシージャへの使用例

この使用例では、Oracleストアド・プロシージャの実行について説明します。ストアド・プロシージャへの入力は、ファイル・アダプタを使用してファイルを読み取ることで取得されます。ストアド・プロシージャが実行されると、表に入力パラメータからのデータが移入されます。

adapter-db-101-file2storedprocedureの使用例を入手するには、Oracle SOA Sample Codeサイトにアクセスします。

この使用例には、次の項目が含まれます。

- 前提条件

- アプリケーションおよびSOAプロジェクトの作成

- アウトバウンド・サービスの作成

- Invokeアクティビティの作成

- インバウンド・ファイル・アダプタ・サービスの作成

- receiveアクティビティの追加

- assignアクティビティの追加

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- データソースの作成

- 接続インスタンスの追加

- ファイル・アダプタ・サービスとSQL*Plusを使用したテスト

- Fusion Middleware Controlコンソールを使用した監視

9.8.2.2.1 前提条件

ファイルからストアド・プロシージャへの使用例を実行するには、JDeveloperを使用してBPELコンポジットをモデル化する前に、次のスキーマ・オブジェクトとストアド・プロシージャをSCOTT/TIGERスキーマ内で定義する必要があります。

create type address as object
(
street varchar2(20),
city   varchar2(15),
state  char(2),
zip    char(5)
);
create type customer as object
(
fname varchar2(10),
lname varchar2(10),
loc   address,
email varchar2(25),
phone varchar2(15)
);
create type collection as table of customer;
create table customers
(
name  varchar2(25),
loc   varchar2(45),
email varchar2(25),
phone varchar2(15)
);
create procedure add_customers(c in collection) as
begin
for i in c.first .. c.last loop
insert into customers values (
c(i).lname || ', ' || c(i).fname,
c(i).loc.street || ', ' || c(i).loc.city || ', ' || c(i).loc.state || ' ' ||
c(i).loc.zip,
c(i).email,
c(i).phone    );
end loop;
end;

これらのスキーマ・オブジェクトとストアド・プロシージャは、Oracle SOA Sample Codeサイトにアクセスして入手できるadapters-db-101-file2storedprocedureサンプルのadapters-db-101-file2storedprocedure/artifacts/sql/customers.sqlファイルを使用して定義できます。

9.8.2.2.2 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従って新規アプリケーションとSOAプロジェクトを作成します。

1. JDeveloperを開きます。

2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

3. 「アプリケーション名」フィールドにFile2SPAppと入力します。

4. 「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。

5. 「次へ」をクリックします。

「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

6. 「プロジェクト名」フィールドにわかりやすい名前を入力します。例: File2SPProject。

7. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

8. 「次」を選択します。「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。

9. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して、「終了」をクリックします。

新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

「BPELプロセスの作成」ページが表示されます。

10. 「名前」フィールドにBPELプロセスの名前を入力します。例: File2SP。

11. 「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。

File2SPAppのFile2SPProject内のFile2SP BPELプロセスが設計領域に表示されます。

9.8.2.2.3 アウトバウンド・サービスの作成

アウトバウンド・サービスを作成するには、次の手順を実行します。

1. 「データベース・アダプタ」を、「サービス・アダプタ」リストから「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「Next」をクリックします。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにFile2SPServiceと入力します。

4. 「Next」をクリックします。
「サービス接続」ページが表示されます。

5. 「新規データベース接続を作成します。」アイコンをクリックします。
「データベース接続の作成」ダイアログが表示されます。

6. 「データベース接続の作成」ダイアログで次の詳細を入力します。

a. 「接続名」フィールドに接続名を入力します。例: MyConnection。

b. 接続タイプとして「Oracle (JDBC)」を選択します。

c. ユーザー名およびパスワードとしてscott/tigerと入力します。

d. 「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。

e. 「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。

f. 「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。

g. 「OK」をクリックします。

「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。

7. 「Next」をクリックします。
「アダプタ・インタフェース」ページが表示されます。

8. 「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。
「操作タイプ」ページが表示されます。

9. 図9-68 に示すように、「ストアド・プロシージャまたはファンクションの呼出し」を選択して「次へ」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。

図9-68 「アダプタ構成ウィザード - 操作タイプ」ページ

10. 「参照」をクリックします。「ストアド・プロシージャ」ペインでADD_CUSTOMERSを選択します。
「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。

11. 「OK」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。

「プロシージャ」フィールドにADD_CUSTOMERSストアド・プロシージャが移入され、ADD_CUSTOMERSストアド・プロシージャの引数も表示されます。

12. 「Next」をクリックします。
「詳細オプション」ページが表示されます。

13. 任意の追加のオプションを指定して、「次へ」をクリックします。
「終了」ページが表示されます。

14. 「終了」をクリックします。
「パートナ・リンクの作成」ダイアログが表示されます。

パートナ・リンク名は、サービス名と同じFile2SPServiceです。

15. 「OK」をクリックします。
アウトバウンドOracleデータベース・アダプタが構成され、File2SP BPELプロセスが表示されます。

9.8.2.2.4 Invokeアクティビティの作成

invokeアクティビティを作成してBPELプロセスを完成する必要があります。これにより、入力変数が作成されます。

次の手順に従ってinvokeアクティビティを作成します。

1. 「ファイル」、「すべて保存」を順番にクリックします。

2. 「コンポーネント・パレット」から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

3. invokeアクティビティの右にある右矢印をドラッグし、File2SPServiceパートナ・リンクに接続します。

「Invokeの編集」ダイアログが表示されます。

4. 「名前」フィールドにInvokeと入力します。

5. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。

「変数の作成」ダイアログが表示されます。

6. デフォルトの変数名を選択し、「OK」をクリックします。

「Invokeの編集」ダイアログの「変数」領域に入力変数名が表示されます。

7. 「OK」をクリックします。

File2SPServiceパートナ・リンクに接続されている右矢印付きの線が表示されます。

9.8.2.2.5 インバウンド・ファイル・アダプタ・サービスの作成

次の手順に従ってインバウンド・ファイル・アダプタ・サービスを作成します。これにより、ファイル・ディレクトリから入力XMLを読み取るサービスが作成されます。

1. 「コンポーネント・パレット」から、「ファイル・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにReadCustomersと入力します。

4. 「次へ」をクリックします。

「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。「操作」ページが表示されます。

6. 操作タイプとして「Read File」を選択し、操作名として「Read」を選択します。他のチェック・ボックスは選択しないでください。

7. 「次へ」をクリックします。

「ファイル・ディレクトリ」ページが表示されます。

8. 「物理パス」を選択して、「着信ファイル用のディレクトリ(物理パス)」フィールドに物理パスを入力します。

9. 「ファイルを再帰的に処理します」および「正常な配信後にファイルを削除」を選択して、「次へ」をクリックします。

「ファイルのフィルタ処理」ページが表示されます。

10. ファイル・ワイルドカードを指定して、customers.xmlを「インクルード・ファイルの名前パターン」フィールドに入力し、次に、「次へ」をクリックします。

「ファイル・ポーリング」ページが表示されます。

11. 「ポーリング頻度」フィールドで任意の値を指定して「次へ」をクリックします。

「メッセージ」ページが表示されます。

12. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。

「タイプ・チューザ」ダイアログが表示されます。

13. 「プロジェクトのスキーマ・ファイル」、「SCOTT_ADD_CUSTOMERS.xsd」および「InputParameters」を順番にクリックします。

14. 「OK」をクリックします。

「メッセージ」ページが再表示されます。URLはxsd/SCOTT_ADD_CUSTOMERS.xsdで、「スキーマ要素」はInputParametersとなっています。

15. 「次へ」をクリックします。

「終了」ページが表示されます。

16. 「終了」をクリックします。

インバウンド・ファイル・アダプタ・サービスが終了します。

17. 「OK」をクリックしてパートナ・リンクを完了します。

18. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.6 receiveアクティビティの追加

ファイル・アダプタ・サービスはreceiveアクティビティに入力を提供し、receiveアクティビティは残りのBPELプロセスを開始します。

次の手順に従ってreceiveアクティビティを追加します。

1. 「File2SP」をダブルクリックします。「File2SP.bpel」ページが表示されます。

2. 「コンポーネント・パレット」から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティの左にある左矢印をドラッグし、ReadCustomersパートナ・リンクに接続します。

「Receiveの編集」ダイアログが表示されます。

4. 「名前」フィールドにReceiveと入力します。

5. 「Receiveの編集」ダイアログで、「変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。

「変数の作成」ダイアログが表示されます。

6. デフォルトの変数名を選択し、「OK」をクリックします。

「変数」フィールドにデフォルトの変数名が移入されます。

7. 「インスタンスの作成」を選択して「OK」をクリックします。JDeveloperの「File2SP.bpel」ページが表示されます。

receiveアクティビティを追加した後、図9-69 に示すようにJDeveloperウィンドウが表示されます。

図9-69 receiveアクティビティの追加

8. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.7 assignアクティビティの追加

次に、入力パラメータに値を割り当てる必要があります。

次の手順に従ってassignアクティビティを追加します。

1. 「コンポーネント・パレット」から、assignアクティビティを設計領域のreceiveアクティビティとinvokeアクティビティの間にドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。

「Assign」ダイアログが表示されます。

3. 「一般」をクリックし、「名前」フィールドでCUSTOMERをクリックします。

4. 「コピー操作」タブをクリックします。

図9-70 に示すように、「Assign」ダイアログが表示されます。

図9-70 「Assign」ダイアログ - 「コピー操作」タブ

5. 図9-70 に示すように、プラス記号付きのアイコンをクリックして「コピー操作」を選択します。

「コピー操作の作成」ダイアログが表示されます。

6. 「From」領域で、「プロセス」、「変数」、「Receive_Read_InputVariable」および「body」を順番に開きます。

7. 「ns3:InputParameters」を選択します。

8. 「To」領域で、「プロセス」、「変数」、「Invoke_File2SPService_InputVariable」および「InputParameters」を順番に開きます。

9. 「ns3:InputParameters」を選択します。

10. 「OK」をクリックします。図9-71 に示すように、「Assign」ダイアログが表示されます。

図9-71 「Assign」ダイアログ

11. 「OK」をクリックします。

図9-72 に示すように、JDeveloperの「File2SP.bpel」ページが表示されます。

図9-72 JDeveloper - File2SP.bpel

12. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.8 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるReadCustomer内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFile2SPService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

3. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.9 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. 「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明されている手順を使用して、アプリケーション・サーバー接続を作成します。

2. 「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

9.8.2.2.10 データソースの作成

File2SPProjectをテストする前に、Oracle WebLogic Server管理コンソールを使用して、次の手順でデータソースを作成する必要があります。

1. http://servername:portnumber/consoleにナビゲートします。

2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

図9-73 に示すように、Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

図9-73 Oracle WebLogic Server管理コンソールのホーム・ページ

3. 「ドメイン構造」で、「サービス」、「JDBC」を選択し、「データ・ソース」をクリックします。

図9-74 に示すように、「JDBCデータ・ソースの概要」ページが表示されます。

図9-74 「JDBCデータ・ソースの概要」ページ

4. 「新規」をクリックします。

「新しいJDBCデータ・ソースの作成」ページが表示されます。

5. 新しいJDBCデータソースの識別に使用するプロパティについて次の値を入力します。

- 「名前」フィールドにMyDataSourceと入力します。

- 「JNDI名」フィールドにjdbc/MyDataSourceと入力します。

- 「データベースのタイプ」にはデフォルト値のOracleを保持します。

- 「データベース・ドライバ」には、デフォルト値のOracle's Driver (Thin XA) for Instance Connections; Versions 9.0.1, 9.2.0, 10, 11を保持します。

6. 「次へ」をクリックします。

「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページが表示されます。他のトランザクション構成オプションがないことを示すメッセージが表示されます。

7. 「次へ」をクリックします。

「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページが表示されます。

8. 「接続プロパティ」ページで、次の接続プロパティを入力します。

- 「データベース名」フィールドに名前(通常はSID)を入力します。

- 「ホスト名」フィールドにホスト名を入力します。

- 「ポート」フィールドにポート番号を入力します。

- 「データベース・ユーザー名」フィールドにSCOTTと入力します。

- 「パスワード」フィールドにTIGERと入力します。

- 「パスワードの確認」フィールドにTIGERと入力します。

9. 「次」を選択します。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページが表示されます。

10. 「構成のテスト」をクリックし、データベースの可用性および指定した接続プロパティをテストします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページの上部に「接続テストが成功しました。」という内容のメッセージが表示されます。

11. 「次へ」をクリックします。

「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページが表示されます。

12. ターゲットとして「AdminServer」を選択し、「終了」をクリックします。

「JDBCデータ・ソースのサマリー」ページが表示されます。このページは、このドメインで作成されたJDBCデータ・ソース・オブジェクトについて要約しています。作成したデータ・ソースがこのリストに表示されます。

9.8.2.2.11 接続インスタンスの追加

データベース・アダプタには、データソースを指すインスタンス・エントリが必要です。

次の手順に従って接続インスタンスを追加します。

1. beahome/でDbAdapter.rarを検索します。

2. ファイルを解凍します。

3. 次の例に示すように、META-INF/weblogic-ra.xml(および、場合によってはra.xml)を編集します。

<connection-instance>
<jndi-name>eis/DB/MyConnection</jndi-name>
<connection-properties>
<properties>
<property>
<name>xADataSourceName</name>
<value>jdbc/MyDataSource</value>
</property>
</properties>
</connection-properties>
</connection-instance>

4. JNDI名と同じデータベース接続名MyConnectionを使用します。

5. xADataSourceNameと同じデータソース名MyDataSourceを使用します。

6. このファイルから再びJARを作成します。

7. アプリケーション・サーバーを再起動します。

新規データベース・アダプタ・インスタンスは、Oracle WebLogic Server管理コンソールを使用して作成することもできます。

9.8.2.2.12 ファイル・アダプタ・サービスとSQL*Plusを使用したテスト

ファイル・アダプタの入力ファイルを用意して、BPELプロセスをテストする必要があります。BPELプロセスの結果は、表からの単純な問合せを使用して表示されます。customers.xmlファイルには、次の入力が含まれています。

<InputParameters xmlns="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/ADD_CUSTOMERS/">
<C>
<C_ITEM>
<FNAME>John</FNAME>
<LNAME>Doe</LNAME>
<LOC>
<STREET>123 Main Street</STREET>
<CITY>Anytown</CITY>
<STATE>CA</STATE>
<ZIP>12345</ZIP>
</LOC>
<EMAIL>john.smith@gmail.com</EMAIL>
<PHONE>567-123-9876</PHONE>
</C_ITEM>
<C_ITEM>
<FNAME>Jane</FNAME>
<LNAME>Doe</LNAME>
<LOC>
<STREET>987 Sunset Blvd</STREET>
<CITY>Sometown</CITY>
<STATE>CA</STATE>
<ZIP>34567</ZIP>
</LOC>
<EMAIL>JaneDoe@yahoo.com</EMAIL>
<PHONE>567-123-9876</PHONE>
</C_ITEM>
</C>
</InputParameters>

次の手順に従って、作成したBPELプロセスをテストします。

1. customers.xmlのコピーを、インバウンド・ファイル・アダプタ・サービスの作成時に指定した入力ディレクトリに置きます。

2. 新規ファイルについてディレクトリがポーリングされます。ファイル・アダプタ・サービスによりファイルが受信されると、receiveアクティビティによりBPELプロセスが開始されます。

3. すべての顧客に関するデータは、ストアド・プロシージャのInputParametersに割り当てられます。

4. ストアド・プロシージャが実行されます。各顧客のデータが変換され、顧客データが表に挿入されます。

5. 表を問い合せると、次の結果が表示されます。

SQL> select * from customers;

NAME                      LOC
------------------------- ---------------------------------------------
EMAIL                     PHONE
------------------------- ---------------
Doe, John                 123 Main Street, Anytown, CA 12345
john.smith@gmail.com      567-123-9876

Doe, Jane                 987 Sunset Blvd, Sometown, CA 34567
JaneDoe@yahoo.com         567-123-9876

9.8.2.2.13 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のEMコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。

前述の手順で作成したFile2SPProject[1.0]を含めて、SOAコンポジットのリストが表示されます。

2. 「File2SPProject[1.0]」をクリックします。

「ダッシュボード」が表示されます。「最新のインスタンス」領域で「インスタンスID」の値をメモします。

3. 「インスタンス」タブをクリックします。

「検索」ダイアログが表示されます。デフォルトの検索では、すべてのインスタンスがインスタンスIDで表示されます。

4. 書き留めた「インスタンスID」を選択します。

新規ウィンドウが開きます。フォルトがあればそれ(または「フォルトが見つかりません」)が表示され、インスタンスの「監査証跡」を表示できます。インスタンスのトレースが新規ウィンドウに表示されます。

5. インスタンス・ツリーは、「ReadCustomers」(サービス)、「File2SP」(BPELコンポーネント)、「File2SPService」(参照)へと順番に開かれています。

6. 「File2SP」 BPELコンポーネントをクリックします。

プロセスの「監査証跡」が表示されます。

7. 図9-75 に示すように、「<payload>」ノードを開いて、ストアド・プロシージャに提供された入力を確認します。

図9-75 「監査証跡」タブ

8. さらに、図9-76に示すように、「フロー」 タブをクリックしてプロセス・フローを表示します。

図9-76 プロセス・フローの表示

9.8.3 データベース・アダプタ/Coherence統合

Exalogicシステム上のCoherenceキャッシュとともにデータベース・アダプタを使用するとパフォーマンスが向上します。このパフォーマンス向上をもたらす機能は、データベース・アダプタ/Coherence統合と呼ばれます。

Exalogicシステム上のCoherenceキャッシュとともにデータベース・アダプタを使用した場合、2つの特定の使用例で効果が得られます。具体的には、次の操作の実行時にパフォーマンスを向上させることができます。

- データベースに対する挿入/更新

- 主キーによる選択

9.8.3.1 データベースに対する挿入/更新

データベース・アダプタおよびCoherenceキャッシュを使用してデータベースに対して挿入および更新を実行した場合、仲介サービスであるCoherenceデータソースが内部的に使用されてパフォーマンスが向上します(このデータソースはCoherenceキャッシュと呼ばれ、基本的にはインメモリー・データベースに該当します)。

通常、挿入/削除/更新の各操作はデータベースに対して直接実行します。パフォーマンスを向上させるには、この前面に配置されたCoherenceのインメモリー・データベース(write-behindマップ)に対して最初にこれらの操作を実行することで、キャッシュを利用した読取り/書込み操作を有効にします。

注意:

Coherence Write-Behindでのアウトバウンド挿入にデータベース・アダプタを使用する場合は、データベース表に主キー列の索引があることを確認してください。

このようなCoherenceマップを使用すると、挿入/削除/更新の各操作を実行するBPEL/OSBプロセスによって、データベースとのやりとりが行われることなくすぐにコール元に結果が返されるため、これらのプロセスの待機時間が改善します(実際には、かわりにCoherenceキャッシュ仲介サービスによってデータベースが集中的に更新されます)。

大量のレコードをまとめて処理する場合には、この方法でCoherenceを使用して、レコードの更新をより簡単かつ効率的に行うことができます。

注意:

Coherenceキャッシュによる効果が見込めないデータベース・アダプタの使用例には、インバウンド・ポーリング、Pure SQLの起動、ストアド・プロシージャ・コール、複数の行を返す通常のSELECTなどの操作があります。

9.8.3.1.1 選択の最適化

データベース・アダプタ/Coherence統合によって改善する2つ目の使用例は、問合せパフォーマンスであり、特にSELECT文の使用例が最適化されます。データベース・アダプタ/Coherence統合では、多数の異なるプロセス・インスタンスによって頻繁にアクセスされる可能性があるデータをキャッシュすることによって、問合せパフォーマンスを向上させています。

データベース・アダプタ/Coherence統合による選択の最適化を使用した場合、データベース・アダプタでは、問合せを最適化するために、データベースに進む前にまず読取り専用のCoherenceキャッシュ(L2読取りキャッシュ)を使用してキャッシュ・ヒットの有無をチェックします。つまり、問い合せるデータがCoherenceキャッシュ内に存在するかどうかを最初にチェックしてそこに見つからなかった場合に同じデータをデータベース内でチェックする方法によって、問合せを最適化しています。

Coherenceでキャッシュ・ミスが発生した場合、そのデータがデータベースから読み取られてCoherenceキャッシュにロードされます。一般的にキャッシュ・ミスに対するキャッシュ参照の比率は高いため、データベースに対して問合せを実行するよりもCoherenceキャッシュをチェックする方が高速になるということがこの処理の前提になっています。

9.8.3.1.2 Coherenceとデータベース・アダプタの統合による効果が得られない問合せ

すべての問合せにおいてキャッシュ参照、つまりCoherenceとデータベース・アダプタの統合による効果が得られるわけではありません。Coherenceキャッシュにヒットした場合でも、指定した問合せ条件を満たすすべてのレコードがそこに含まれていたかどうかは不明であり、データベース内にヒットする追加のレコードが存在していてもそれがキャッシュ内に存在しなかったために返されなかった可能性もあります。

このため、問合せ最適化機能では、「主キーによる選択」という新しい種類のデータベース・アダプタ操作を利用できます。既存の「選択」およびqueryByExample操作とは異なり、「主キーによる選択」の使用時には1行のみを返すことができます。主キーを選択して1行を返すことで、実際には、より具体的なレコードがCoherenceキャッシュから返されるようにリクエストしていることになるため、キャッシュに対して機能のパフォーマンスが向上します。

9.8.3.2 データベース・アダプタ/Coherence統合のアーキテクチャ

データベース・アダプタ/Coherence統合を使用するかどうかは、データベース・アダプタ・ウィザードの「操作タイプ」画面で「なし」、「読取り」または「読取り-書込み」を選択することによって簡単に指定できます。ただし、データベース・アダプタ/Coherence統合のアーキテクチャに関するいくつかの背景を知っておくことは有益であるため、次の各項ではそれらの詳細について説明します。

EclipseLinkの詳細は、http://www.oracle.com/technetwork/middleware/toplink/documentation/index.htmlを参照してください

Coherenceに関するいくつかの背景は、http://www.oracle.com/technetwork/middleware/coherence/overview/index.htmlに記載されています

9.8.3.2.1 WebLogic Server 10.3.5とのCoherenceデータベース・アダプタ統合の使用

WebLogic Server 10.3.5とともにCoherenceデータベース・アダプタを使用するには、次の手順を実行する必要があります。

1. WebLogic Server 10.3.5とともにOracle 11.1.1.7.1 SOA Suiteをインストールします。

2. SOAインストールでDbAdapter.rarを検索します。

cd $BEAHOME/AS11gR1SOA/soa/connectors
mkdir tmp

3. バンドルされた10.3.6バージョンのtoplink-grid.jarをDbAdapter.rarから次のように削除します。

unzip DbAdapter.rar -d tmp
cd tmp
rm toplink-grid.jar

4. 既存のマニフェストとともにDbAdapter.rarを再構築します。これにより、共有ライブラリのTopLink Gridを検索します。

cd $BEAHOME/AS11gR1SOA/soa
cd $BEAHOME/AS11gR1SOA/soa/connectors
mkdir tmp
jar cvmf META-INF/MANIFEST.MF DbAdapter.rar *
mv DbAdapter.rar ..
cd ..
rm -rf tmp

5. $BEAHOME/modules/com.oracle.toplinkgrid_1.0.0.0_11-1-1-5-0.jarをtoplink-gridという名前の共有ライブラリとしてWebLogic Serverホスト・コンソールからデプロイします。

toplink-gridという名前の共有ライブラリ(「デプロイメント」→「インストール」)から行います。

6. WebLogic Serverを再起動します。

9.8.3.2.2 データベース・アダプタの現在の設計(Coherenceキャッシュなし)

データベース・アダプタの現在の設計では、アダプタによって選択および挿入をEclipseLinkレイヤーに対して実行し、そこからCoherenceキャッシュなしで直接データソースと通信します。

データベース構成ウィザードの「操作タイプ」画面で「キャッシュの使用方法」ドロップダウンから「なし」を選択することで、キャッシュを使用しないように指定できます。

9.8.3.2.3 読取り/書込み用Coherenceキャッシュとデータベース・アダプタの統合

データベース・アダプタ・ウィザードの「操作タイプ」画面で「キャッシュの使用方法」ドロップダウンから「読取り-書込み」を選択すると、読取り/書込みキャッシュを使用できます。

EclipseLinkは2つのレイヤー内にあり、これらの2つのレイヤー間にCoherenceキャッシュ(Coherenceキャッシュ・ストア)があります。実際にはEclipseLinkプロジェクトは1つだけですが、そのプロジェクトのコピーが2つ存在します。

- EclipseLinkの上側のコピーでは、データ・ストアからの挿入/選択の問合せはすべてCoherenceキャッシュにリダイレクトされます。

- EclipseLinkの下側のコピーでは、Coherenceキャッシュからのリクエストを処理し、IDに基づいてデータベースから特定のレコードをロードするかデータベースに特定のレコードを格納します。

読取り/書込みシナリオで選択を実行する場合、取得する行が一意に識別されない可能性があります。

たとえば、SELECT *またはSELECT where total gross > ?などがこれに該当します

write-behind Coherenceキャッシュでは、IDに基づいてレコードをロードするためのリクエストのみを受信できます。そのため、これらのいずれの場合においても、すべての問合せがCoherenceキャッシュに向けられると、返される結果が0になります。この場合は、問合せがデータソースに対して直接行われ、その後Coherenceキャッシュが更新されます。

9.8.3.2.4 読取り用Coherenceキャッシュとデータベース・アダプタの統合

データベース・アダプタ・ウィザードの「操作タイプ」画面で「キャッシュの使用方法」ドロップダウンから「読取り」を選択すると、読取りキャッシュを使用できます。

読取りキャッシュでは、データベース・アダプタによってデータベースにレコードを挿入する場合、またはデータベースからレコードを選択する場合に、Coherenceキャッシュが更新されます。行を識別する(つまり、主キーを指定する)すべての問合せにおいて、まずCoherenceキャッシュがチェックされ、可能な場合にデータベースとのやりとりが回避されます。Coherenceキャッシュは分散型の単なるハッシュ・マップとみなすことができるため、特定の主キーを選択することで、Coherenceキャッシュ・マップを通じたルックアップの高速化が可能になります。

9.8.3.2.5 「操作タイプ」画面を使用したキャッシュなしの有効化

図9-77 は、データベース・アダプタ・ウィザードの「操作タイプ」画面に表示されたキャッシュなしオプション(「なし」を選択)を示しています。

図9-77 キャッシュなしが選択されたデータベース・アダプタ構成ウィザードの「操作タイプ」画面

この画面では「なし」オプションが選択されており、すべてのアウトバウンド操作が有効です。このオプションを選択して「次へ」または「終了」を選択すると、選択した操作のいずれにもプロパティCacheUsageは含まれなくなります。このプロパティが存在しない状態は、JCAアクティブ化プロパティCacheUsageが値noneになっているのと同じです。

「キャッシュの使用方法」として「なし」オプションを選択した場合、次のオプションの操作のみが事前に選択されます。

- マージ

- 挿入のみ

- 選択

9.8.3.2.6 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化

「操作タイプ」画面では、読取り/書込みキャッシュを有効化できます。図9-78を参照してください。このオプションを選択して「次へ」または「終了」を押すと、JCAプロパティCacheUsageの値がread-writeに設定されます。

図9-78 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化

この画面で「キャッシュの使用方法」ドロップダウンから「読取り-書込み」オプションを選択した場合の各操作の使用方法を理解するには、次のリストを参照してください。

- 「挿入または更新(マージ)」は有効であり、ラベルの末尾には「キャッシュの使用」という文字列が付加されます。

- 「挿入のみ」は無効であり、基礎となるキャッシュ・ストアによって常にマージが実行されます。

- 「更新のみ」は無効であり、基礎となるキャッシュ・ストアによって常にマージが実行されます。

- 「削除」は選択可能ですが、事前には選択されておらず、選択すると末尾に「キャッシュの使用」という文字列が付加されます。

- 「選択」は無効であり、この問合せは、Coherenceマップで実行されるCoherenceフィルタに変換されます。

- 「例による問合せ」は無効であり、データベース・アダプタ/Coherence統合の問合せは、Coherenceマップで実行されるCoherenceフィルタに変換されます。

- 「主キーによる選択」のラベルの末尾には、「キャッシュの使用」という文字列が付加されます。

9.8.3.2.7 「操作タイプ」画面を使用した読取りキャッシュの有効化

「操作タイプ」画面の「キャッシュの使用方法」オプションを使用すると、読取りキャッシュを有効化できます。図9-79を参照してください。画面上でこのオプションを選択して「次へ」または「終了」を押すと、JCAプロパティCacheUsageの値がreadに設定されます。

図9-79 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化

読取りキャッシュ・オプションでは、「主キーによる選択」操作のみが事前に選択されています。他の操作でキャッシュを更新することは可能ですが、キャッシュを通じたCoherenceとデータベース・アダプタの統合機能によって実行する意味がある操作は「主キーによる選択」のみです。読取りキャッシュはキャッシュの変更を伴わないため、この画面の「操作タイプ」の各操作は無効になります。

「選択」および「例による問合せ」は無効にはなりませんが、キャッシュは直接更新されません。データベース・アダプタ/Coherence統合機能では「選択」をデータベースに対して実行しますが、返される任意の行でCoherenceキャッシュを更新します。

読取りキャッシュの一般的な操作では、返されたオブジェクトがCoherenceキャッシュに存在した場合、データベース・アダプタ/Coherence統合機能により結果セットから新しいコピーが作成されるのではなくキャッシュ内のオブジェクトが返されます。

この操作により、マスター・データベース・レコードに複数の詳細がある場合に、その詳細に対する問合せを再度行う必要がないため、パフォーマンスが向上します。

問合せの動作は「選択」と同じになります。たとえば、主キーが設定されている(キャッシュ・ヒットが得られない)XMLデータにこれが当てはまります。

9.8.3.2.8 Coherence/データベース・アダプタ統合でのXAトランザクション、読取り/書込みおよび読取り操作

データベース・アダプタ/Coherence統合を使用している場合、XAトランザクションを読取り/書込み操作とともに使用することはできません。これは、データベース・アダプタをCoherenceと統合した場合、挿入がCoherenceキャッシュ、データベースの順に実行されますが、この順番がXAトランザクションの規定に違反するためです。

ただし、データベース・アダプタ/Coherence統合を使用して、XAトランザクションを読取り操作とともに使用することはできます。

データベース・アダプタ/Coherence統合を伴わない、データベース・アダプタを使用したデータベース・トランザクションでも、引き続きXAトランザクション・モデルを使用できます。

9.8.3.2.9 Coherenceキャッシュのライフサイクルおよび構成

cacheUsageの「読取り」または「読取り-書込み」を使用してコンポジット・アプリケーションを含むデータベース・アダプタをデプロイする場合は、専用のCoherenceキャッシュが作成されます。その名前は、DbAdapter/WriteBehindCache/<serviceName>/<tableName>(「読取り-書込み」キャッシュの場合)またはDbAdapter/L2Cache/<serviceName>/<tableName>(「読取り」キャッシュの場合)になります。

このキャッシュ名は、次のとおり、or-mappings.xmlに適切に格納されます。

<properties>
<property name="eclipselink.coherence.cache.name">
<value>DBAdapter/WriteBehindCache/insertReference.Movies</value>
</property>
</properties>

2つのキャッシュ構成テンプレートは、fabric-runtime.jarにあるsoa-coherence-cache-config.xmlで定義されています。1つのテンプレートはDbAdapter/WriteBehindCache/(読取り-書込み)で始まるすべてのキャッシュ名に対応し、もう1つのテンプレートはDbAdapter/L2Cache (読取り)で始まるすべてのキャッシュ名に対応します。

これらの定義を編集するか、or-mappings.xml内のキャッシュ名を変更することで、新しい定義を作成できます。次の例に、soa-coherence-cache-config.xmlで定義されている2つのテンプレートを示します。

例 - soa-coherence-cache-conifg.xmlのテンプレート

<cache-mapping>
<cache-name>DBAdapter/WriteBehindCache/*</cache-name>
<scheme-name>db-adapter-write-behind-cache</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>DBAdapter/L2Cache/*</cache-name>
<scheme-name>db-adapter-l2-cache</scheme-name>
</cache-mapping>

<distributed-scheme>
<scheme-name>db-adapter-write-behind-cache</scheme-name>
<backup-count-after-write-behind>0</backup-count-after-write-behind>
<!-- for DbAdapter must be true on SOA nodes and false on dedicated Coherence nodes.-->
<local-storage>true</local-storage>
<thread-count>1</thread-count>
<task-hung-threshold>20000</task-hung-threshold>
<backing-map-scheme>
<read-write-backing-map-scheme>

<internal-cache-scheme>
<local-scheme>
<eviction-policy>HYBRID</eviction-policy>
<high-units>10000</high-units>
<low-units></low-units>
<unit-calculator>FIXED</unit-calculator>
<expiry-delay>120s</expiry-delay>
</local-scheme>
</internal-cache-scheme>
<cachestore-scheme>
<class-scheme>
<class-name>oracle.tip.adapter.db.toplinkext.coherence.DBAdapterCacheStore</class-name>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>
</class-scheme>
</cachestore-scheme>
<write-delay>5s</write-delay>
<write-batch-factor>0.1</write-batch-factor>
<write-requeue-threshold>1000</write-requeue-threshold>
</read-write-backing-map-scheme>
</backing-map-scheme>
<autostart>false</autostart>
</distributed-scheme>

<distributed-scheme>
<scheme-name>db-adapter-l2-cache</scheme-name>
<!-- for DbAdapter must be true on SOA nodes and false on dedicated Coherence nodes.-->
<local-storage>true</local-storage>
<thread-count>4</thread-count>
<task-hung-threshold>500</task-hung-threshold>
<backing-map-scheme>
<local-scheme>
<eviction-policy>HYBRID</eviction-policy>
<high-units>1000</high-units>
<low-units>1000</low-units>
<unit-calculator>FIXED</unit-calculator>
<expiry-delay>120s</expiry-delay>
</local-scheme>

</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>

独自の定義を定義している場合は、local-storage trueを設定する必要があります。

オブジェクトのライフサイクルは、CacheUsageか有効化されたプロジェクトによって異なります。第1に、更新されたor-mappings.xmlファイルで同じコンポジットが再デプロイされたとしても、コンポジット・アプリケーションと関連付けられたEclipseLinkプロジェクト(or-mappings.xml)がロードされるのは1回のみです。通常、コンポジットの各デプロイメントは、すべてのアーティファクトをクリーンに再デプロイしたものとなります。

第2に、CacheUsageコンポジットをアンデプロイしてもCoherenceキャッシュは破棄されません。手動で行う必要があります。つまり、コンポジットは再デプロイが可能で、基礎となるCoherenceキャッシュも、再デプロイの前に所有していたコンテンツとともに残すことができます。他のデータベース・アダプタのユース・ケースとは異なるため、複数のデータベース・アダプタ参照を1つまたは複数のコンポジット間で所有して、同じCoherence名のキャッシュに接続できます。

したがって、EclipseLinkプロジェクトのライフサイクル(or-mappings.xml)およびCoherenceキャッシュは、コンポジットのリビジョン/デプロイメントではなくWebLogic Applicationサーバーの再起動に基づきます。

最後に、データベース・アダプタでは、データ・ストアに挿入するオブジェクトの表示に実際のJavaクラスではなくバイトコード生成を使用します。これにより、データベース・アダプタの外部で、同じCoherence NamedCacheにプログラムで直接接続することが難しくなります。これは、クラスの定義がデシリアライゼーションに簡単に使用できないためです。ただし、前述のとおり、類似したor-mappings.xmlプロジェクトを持つ複数のデータベース・アダプタ参照では同じCoherenceキャッシュを共有できます。

9.8.3.3 例による問合せ

例による問合せを使用すると、問合せで使用する属性のみを移入したサンプル・オブジェクト・インスタンスの形式で、問合せ選択基準を指定できます。EclipseLinkの例による問合せサポートには、ユーザーが変更できる例による問合せポリシーも含まれています。EclipseLinkユーザーは、このポリシーを編集して、例による問合せのデフォルト動作を変更できます。

データベース・アダプタは、基本的に、例による問合せ操作の基本セットを提供して、例による問合せポリシーの実装またはカプセル化を提供します。次の操作のタイプが含まれます。

- LIKEなどの演算子を使用して、属性を比較する場合。デフォルトでは、例による問合せで使用できるのはEQUALSのみです。

- 例による問合せで無視される値のセット(IGNOREセット)を変更する場合。デフォルトで無視される値は、ゼロ(0)、空の文字列およびFALSEです。

- 属性の値がIGNOREセットに含まれるものであっても、例による問合せでその値を強制的に考慮する場合。

- 属性値としてisNullまたはnotNullを使用する場合。(ただし、「使用に関する制約事項」を参照)。

データベース・アダプタでは、データベース・アダプタ構成ウィザードの高度な操作画面で使用可能な既存の操作と値に、追加の操作と値を追加して、この機能が提供されます。

データベース・アダプタ構成ウィザードで「例による問合せ」オプションを選択すると、追加の問合せを使用するか、または問合せと作成した他の問合せを組み合せることができます。

注意:

QueryByExampleでは、複数の表の使用はサポートされません。関連表の場合は、例による問合せに対してPureSQLを使用する方が適切です。

図9-80 「例による問合せ」が選択されたデータベース・アダプタ構成ウィザードの「操作タイプ」画面

DBReadinteractionSpecにdb.jca.propertiesが追加されている次のタイプの問合せ内で、次の問合せを示されているとおりに使用できます。

- QueryByExampleTextOperator

- QueryByExampleNumericOperator

- QuerybyExampleDateOperator

これらのタイプの各問合せに、次の例による問合せの値のいずれか1つを設定できます。

- equal

- notEqual

- equalsIgnoreCase

- lessThan

- lessThanEqual

- greaterThan

- greaterThanEqual

- like

- likeIgnoreCase

- containsAllKeyWords

- containsAnyKeyWords

- containsSubstring

- containsSubstringIgnoringCase

JDeveloper UIで、任意の問合せおよび問合せが実行できる操作を選択できます。高度な操作画面の各操作には、比較演算子のドロップダウン・リストがあります。図9-81を参照してください。

図9-81 「例による問合せ比較演算子」に「lessThan」が指定されたデータベース・アダプタ構成ウィザードの高度な操作画面

数値のlikeIgnoreCaseなど、一部の組合せは意味をなしていませんが、使用に対する制限は設定されていません。

リストされているパラメータ演算子だけでなく、org.eclipse.persistence.expressions.Expressionにある単一のパラメータ演算子を選択できます。これらの演算子のいずれか1つを設定するには、JCAファイルを直接編集します。

「equal」はデフォルトであるため、終了を選択したときに値がJCAファイルに表示されません。これらのプロパティがない古いプロジェクトには、自動的に追加されます。

9.8.3.3.1 例による問合せと通常の問合せの組合せ

JDev式ビルダーと例による問合せを組み合せて使用できます。たとえば、問合せがWHERE some_column IS NOT NULL操作を実行する場合は、この最初の操作を通常のSelectを使用してモデル化し、例による問合せ操作も選択できます。JCAファイルで、次の選択操作のQueryNameプロパティを例による問合せ操作にコピーします。

<property name="IsQueryByExample" value="true"/>
<property name="QueryName" value="dbReferenceSelect"/>

例による問合せとは異なり、アクティブ化ファイルに操作をコピーする必要はありません。

9.8.3.3.2 使用に関する制約事項

レコード例に次が含まれる場合、

<someOtherColumn>someOtherValue</someOtherColumn>

生成されるSQLは次のようになります。

WHERE some_column IS NOT NULL AND some_other_column = 'someOtherValue'

これは、通常のSelect文に入力パラメータがない場合にのみ使用できます。

オブジェクト例の特定の列に重要なNULLを指定できるQueryByExampleポリシーは、現在サポートされていません。

NULL属性は無視されますが、EclipseLinkサポートによって、その他の2つのAPIの組合せによってIS NULLおよびIS NOT NULLを生成できます。これらのAPIは公開されませんが、これらの文を通常の問合せと組み合せて使用できます。重要な値(NULL以外)が含まれている場合でも、特定の列を常に除外するAPIはありません。明示的な問合せを作成する方が適切です。

9.8.3.4 UTF16文字データ挿入のor-mappings.xmlファイルの変更

UTF16でデータベース・アダプタを使用して、WE8DEなど、AL16UTF16以外の文字セットを使用するデータベースにデータを挿入する場合、自動文字変換によって誤ったデータがデータベースに挿入されます。解決策は、JDeveloperアダプタ構成ウィザードで生成された-or-mappings.xmlファイルを変更することです。制限の1つとして、使用しているOracle DatabaseのバージョンがOracle 9 Database以降である必要があります。

示されている解決策を実行するには、次の手順を実行します。

1. プロジェクトのファイル・システムで-or-mappings.xmlファイルを検索し、エディタで開きます(デフォルトではJDeveloperを使用してこのファイルを変更することはできません)。

2. <attribute-name>field name</attribute-name>でUTF16文字が含まれているデータベース・ファイルを検索します。

3. 次の属性があります

<attribute-classification>java.lang.String</attribute-classification>

これを次のように置換します

<attribute-classification>org.eclipse.persistence.platform.database.oracle. NString</attribute-classification>

4. プロジェクトを保存し、再デプロイします。

-or-mappings.xmlファイルは、データベース・アダプタ構成ウィザードによって自動的に生成されるため、データベース・アダプタ構成ウィザードの実行時にこれらの手順を繰り返す必要があります。

10 Oracle JCA Adapter for MQ Series

この章では、外部サービスとしてOracle BPEL Process Manager (Oracle BPEL PM)およびOracle Mediator (メディエータ)とともに動作する、Oracle JCA Adapter for MQ Series (Oracle MQ Seriesアダプタ)の使用方法について説明します。この章では、JCA Adapter for MQ Seriesの概念、機能、構成および使用例について説明します。

この章の内容は次のとおりです。

- MQ Seriesメッセージ・キューイングの概要

- ネイティブOracle MQ Seriesアダプタの概要

- 機能

- 概念

- Oracle MQ Seriesアダプタの構成

- 使用例

10.1 MQ Seriesメッセージ・キューイングの概要

メッセージ・キューイングは、非同期プログラム間通信のためのテクニックです。分散システム上の独立したアプリケーションの相互通信を可能にすることによりアプリケーションを統合できます。あるアプリケーションがキュー・マネージャ所有のキューにメッセージを送信し、別のアプリケーションがキューからメッセージを取り出します。各アプリケーションが異なる時期に実行されたり一時的に使用できなくなっても、アプリケーション間の通信は維持されます。

次のリストに、メッセージ・キューイングの基本的な概念を示します。

- メッセージング
メッセージングは、2つのエンティティがメッセージを送受信することで通信できるようにするメカニズムです。メッセージングには、同期と非同期の2つのタイプがあります。同期メッセージングでは、メッセージの送信元がメッセージをメッセージ・キューに入れ、そのメッセージに対するリプライを待ってから自身の処理を再開します。非同期メッセージングでは、メッセージの送信元がリプライを待たずに自身の処理を続行します。

- メッセージ
メッセージは、あるプログラムから別のプログラム宛に送信される構造化データです。

- メッセージ・キュー
メッセージ・キューは、アプリケーションでメッセージが格納されるオブジェクトです。アプリケーションでは、メッセージをキューに蓄積し、キューからメッセージを取得できます。キューはキュー・マネージャにより管理されます。

- キュー・マネージャ
キュー・マネージャは、アプリケーション・プログラム・インタフェースを介してアプリケーションにメッセージ・サービスとキューイング・サービスを提供します。キューへのアクセスを提供するのみでなく、メッセージ・チャネルを介して他のキュー・マネージャにメッセージを転送します。

- メッセージ・チャネル
メッセージ・チャネルは、2つのキュー・マネージャ間の通信パスを提供します。キュー・マネージャが接続されます。メッセージ・チャネルによるメッセージの転送送信方向は一方向のみです。

- 転送キュー
転送キューは、リモート・キュー・マネージャ宛のメッセージを一時的に格納するために使用されます。

- メッセージ・セグメント
メッセージがきわめて大きい場合は、セグメントと呼ばれる複数の小型メッセージに分割できます。各セグメントにはグループIDとオフセットがあります。メッセージのすべてのセグメントは、同じグループIDを持ちます。メッセージの最終セグメントはフラグでマークされます。

- メッセージ・グループ
メッセージ・グループは、同じグループIDを持つ一連の関連メッセージで構成されます。メッセージ・グループ内の各メッセージには、メッセージ順序番号が付いています。メッセージ・グループ内の最後のメッセージはフラグでマークされます。

- クラスタ
クラスタは、論理的に関連付けられたキュー・マネージャのグループです。

- エンキュー/デキュー
図10-1 に示すように、エンキューとはメッセージをキューに蓄積することで、デキューとはキューからメッセージを取得することです。

図10-1 エンキュー/デキュー

- リクエスト/レスポンス
リクエスト/レスポンス相互作用では、プログラムは別のプログラムにリプライを求めるメッセージを送信します。リクエスト・メッセージには、リプライの送信先情報が含まれています。受信側プログラムは、リクエスト・メッセージへのレスポンスとしてリプライ・メッセージを送信します。図10-2 にリクエスト/レスポンス相互作用を示します。

図10-2 リクエスト/レスポンス相互作用

サポートされている相互作用のシナリオの詳細は、「メッセージのデキュー」を参照してください。

10.1.1 MQ Seriesの概要

Messaging and Queuing Seriesは、IBM社が開発した製品および標準のセットです。保証されたメッセージ配信、セキュリティおよび優先度ベースのメッセージングを提供するキューイング・インフラストラクチャを備えています。

注意:

IBM MQ V7.5で動作確認済です。

図10-3に、アプリケーションとサーバー間の通信プロセスを示します。クライアントにより、アプリケーションからリモート・コンピュータ上のキュー・マネージャに接続できます。

図10-3 通信プロセス

各キューはキュー・マネージャに属しています。キュー・マネージャには一意の名前があり、Message Queue Interface (MQI)チャネルを介してアプリケーションにメッセージ・サービスとキューイング・サービスを提供します。また、キュー・マネージャは作成されたキューへのアクセスを提供し、メッセージ・チャネルを介してメッセージを他のキュー・マネージャに転送します。

データはメッセージ形式で送信されます。送信側アプリケーションではメッセージを作成し、APIコールを使用してキューに送信します。メッセージは、受信側アプリケーションの受信準備ができるまでキューに保持されます。受信側アプリケーションでは、APIコールを使用してキューからメッセージを取得します。

メッセージをリモート・キューに送信する場合は、リモート・キュー定義をローカルに定義する必要があります。リモート・キュー定義は、宛先キュー名と転送キュー名で構成されます。

図10-4に、メッセージのメッセージ構造を示します。

図10-4 メッセージ

メッセージは、図10-4に示すパートで構成されます。

- メッセージ・ヘッダー
メッセージ・ヘッダーには、一意のメッセージID、メッセージ・タイプ、メッセージ優先度およびルーティング情報などが含まれています。各メッセージには、メッセージ・ヘッダーが必要です。

- オプション・ヘッダー
オプション・ヘッダーは、特定のアプリケーション(CICSアプリケーションなど)との通信に必須です。

詳細は、「CICSとの統合」を参照してください。

- アプリケーション・データ
これには実際のデータが含まれます(索引付きファイルまたはフラット・ファイルからのレコードや、DB2の表からの行または列など)。

注意:

重要なトラブルシューティング: インバウンドMQプロセスは、相互に排他的なMessageSelectorが各インバウンド・プロセスに対して定義されていないかぎり、同じキューを使用できません。MessageSelectorが定義されていない場合、または2つ以上のインバウンド・プロセスの選択条件が重複している場合は、あるプロセスが、別のプロセス向けのメッセージを読み取ることが原因で問題が発生する可能性があります。

また、MQ Seriesアダプタのログに記録された次のメッセージはエラーではありません。これは、そのキューで使用できるメッセージがないことを示します。

com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2033at com.ibm.mq.MQQueue.get(MQQueue.java:1033)

10.2 ネイティブOracle MQ Seriesアダプタの概要

Oracle BPEL Process ManagerおよびOracle Mediatorとメディエータには、Oracle MQ Seriesアダプタが組み込まれています。Oracle MQ Seriesアダプタにより、アプリケーションはMQ Seriesキュー・マネージャに接続し、MQ Seriesメッセージをキューに蓄積したりキューから削除できます。

この項では、次の項目について説明します。

- Oracle MQ Seriesアダプタの必要性

- Oracle MQ SeriesアダプタとOracle BPEL Process ManagerおよびOracle Mediatorの統合

- Oracle MQ Seriesアダプタとメディエータの統合

注意:

MQ Seriesアダプタのテスト接続スレッドが永久にブロックされることを防ぐには、KeepAliveオプションがMQ Seriesキュー・マネージャで有効になっていることを確認します。KeepAliveオプションの設定方法の詳細は、IBM MQのドキュメントを参照してください。

10.2.1 必要性

すべてのネイティブ機能を提供します。プロバイダとともに構成することはできますが、提供されるのは提供されるJMS機能のみで、ネイティブの機能は提供されません。次のリストに、上回るメリットを示します。

- 肯定アクション通知(PAN)および否定アクション通知(NAN)をサポートしています。

- 送信時の確認、着信時の確認、例外レポートおよび有効期限レポートなどのレポート・メッセージをサポートしています。

- 不要なメッセージや破損したメッセージのデッドレター・キューへの送信をサポートしています。

- グループに属するメッセージのフィルタリングなど、高度なフィルタ・オプションが用意されています。

- 高速で、使用が容易です。

注意:

動作が確認されたMQ Seriesのバージョンは、WindowsでもLinuxでも7.5です。

10.2.2 次のコンポーネントとの統合

自動的に統合されます。Oracle JDeveloper (JDeveloper)でパートナ・リンクまたはMQアダプタ・サービスを作成する際に、アダプタ構成ウィザードが起動します。

このウィザードで選択して構成できます。または他のOracle JCAアダプタを選択して構成できます。アダプタ構成ウィザードでは、図10-5 に示すように、サービス名の入力を求められます。

図10-5 「サービス名」ページ

構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションに同じ名前のWSDLファイルが作成されます。このWSDLファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。

アダプタ構成ウィザードの「操作」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。

表10-1 に実行可能な操作と、これらの操作に関する情報が記載されている項を示します。

表10-1 Oracle BPEL Process Managerについてサポートされている操作

操作

参照先

メッセージのエンキュー

メッセージのエンキュー

メッセージのデキュー

メッセージのデキュー

リクエスト-レスポンス

非同期リクエスト-レスポンス(クライアントの場合)

同期リクエスト-レスポンス(サーバーの場合)

非同期リクエスト-レスポンス(サーバーの場合)

同期リクエスト-レスポンス(サーバーの場合)

同期リクエスト-レスポンス(クライアントの場合)

同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

非同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

アウトバウンド・デキュー

アウトバウンド・デキューのシナリオ

10.2.3 次のコンポーネントとの統合

自動的に統合されます。JDeveloperメディエータ・デザイナでMQアダプタ・サービスを作成すると、アダプタ構成ウィザードが起動します。

このウィザードで選択して構成できます。構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションに同じ名前のWSDLファイルが作成されます。このWSDLファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。

アダプタ構成ウィザードの「操作」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。表10-2 に実行可能な操作と、指定する必要がある構成情報が記載されている項を示します。

表10-2 Oracle Mediatorについてサポートされている操作

操作

参照先

メッセージのエンキュー

メッセージのエンキュー

メッセージのデキュー

メッセージのデキュー

リクエスト-レスポンス

同期リクエスト-レスポンス(サーバーの場合)

同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

非同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

アウトバウンド・デキュー

アウトバウンド・デキューのシナリオ

10.3 機能

この項では、次の機能について説明します。

- RFHバージョン2 (RFH2)ヘッダー

- SSLの有効化

- XAトランザクション

- 高可用性

- スケーラビリティ

- エンタープライズ情報システムの資格証明の保護

- フォルト・ポリシー

- インバウンド拒否ハンドラ

- JCAインバウンド再試行メカニズム

- メッセージ・バックアウト・キュー

- パフォーマンス・チューニング

10.3.1 RFHバージョン2 (RFH2)ヘッダー

RFH2ヘッダーは拡張可能なヘッダーです。RFH2ヘッダーでは、より多くのヘッダー・プロパティをペイロードに追加できます。RFH2は、メッセージ・コンテンツに関連するJMS固有データを送信します。JMSに直接関連しない追加情報も送信できます。

RFH2ヘッダーは、固定部分と可変部分の2つの部分で構成されます。同じメッセージに複数のRFH2ヘッダーが存在する場合があります。

10.3.1.1 固定部分

固定部分は、standardのMQヘッダー・パターンをモデルにして作成されており、次のフィールドで構成されています。

StrucId (MQCHAR4)

構造識別子。

初期値では、MQRFH_STRUC_ID(値: "RFH ")になります。

MQRFH_STRUC_ID_ARRAY(値: "R"、"F"、"H"、" ")を通常の方法で定義することもできます。

Version (MQLONG)

構造バージョン番号。

初期値では、MQRFH_VERSION_2(値: 2)になります。

StrucLength (MQLONG)

NameValueDataフィールドを内容としたMQRFH2の長さの合計。

StrucLengthに設定する値は、4の倍数である必要があります(このために、NameValueDataフィールドのデータをパディングできます)。

Encoding (MQLONG)

データのエンコーディング。

メッセージのうち、MQRFH2の後の部分(次のヘッダー、またはこのヘッダーの後のメッセージ・データ)に含まれているすべての数値データのエンコーディング。

CodedCharSetId (MQLONG)

コード化キャラクタ・セット識別子。

メッセージのうち、MQRFH2の後の部分(次のヘッダー、またはこのヘッダーの後のメッセージ・データ)に含まれているすべての文字データの表現。

Format (MQCHAR8)

フォーマット名。

メッセージのうち、MQRFH2の後の部分のフォーマット名。

Flags (MQLONG)

フラグ。

MQRFH_NO_FLAGS =0。フラグは設定されません。

NameValueCCSID (MQLONG)

このヘッダーに含まれているNameValueData文字列のコード化キャラクタ・セット識別子(CCSID)。NameValueDataは、ヘッダーに含まれている他の文字列(StrucIDおよびFormat)とは異なるキャラクタ・セットでコード化できます。

NameValueCCSIDフィールドが2バイトのUnicodeのCCSID (1200、13488または17584)である場合、Unicode CCSIDのバイト順は、MQRFH2の数値フィールドのバイト順と同じです(数値フィールドの例は、Version、StrucLengthまたはNameValueCCSID自体など)。

NameValueCCSIDフィールドに指定できる値は、表10-3 に示す値のみです。

表10-3 NameValueCCSIDフィールドに指定できる値

値

意味

1200

拡張UCS2

1208

UTF8

13488

UCS2 2.0サブセット

17584

UCS2 2.1サブセット(ユーロ記号を含む)

10.3.1.2 可変部分

固定部分の後に、可変部分が続きます。可変部分には、不特定数のMQRFH2フォルダが含まれます。同じRFH2ヘッダーに各フォルダが複数回出現する場合もあります。mqext、mq_usr、mqpsなどの他のフォルダはRFH2フォルダに追加することもできます。詳細は、MQ RFH2ヘッダーに関するIBM社ドキュメントを参照してください。

関連するプロパティは、グループにまとめられます。MQRFH2ヘッダーには、次のメッセージ・サービス・フォルダを含めることができます。

<mcd>フォルダ

このフォルダには、メッセージの形またはフォーマットを記述するプロパティを指定します。たとえば、Msdプロパティはメッセージをテキスト、バイト、ストリーム、マップ、オブジェクトまたはNullであるとして識別します。このフォルダは、常にJMS MQRFH2に含まれています。

<jms>フォルダ

このフォルダは、JMSヘッダーのフィールドを転送する目的と、MQMDでは完全には表現できないJMSXプロパティを転送する目的に使用されます。このフォルダは、常にJMS MQRFH2に含まれています。

<usr>フォルダ

このフォルダは、メッセージに関連付けられているすべてのアプリケーション定義プロパティを転送するために使用されます。このフォルダは、アプリケーションにアプリケーション定義プロパティが設定されている場合にのみ含まれています。

<psc>フォルダ

このフォルダは、パブリッシュ/サブスクライブ・コマンド・メッセージをブローカに伝達するために使用されます。NameValueDataフィールドに許可されるpscフォルダは1つのみです。

<pscr>フォルダ

このフォルダは、パブリッシュ/サブスクライブ・コマンド・メッセージへのレスポンスとしてブローカからの情報を含めるために使用されます。レスポンス・メッセージに使用できるpscrフォルダは1つのみです。

表10-4 に、すべてのプロパティ名のリストを示します。

表10-4 JMSで使用されるMQRFH2フォルダとプロパティ

JMSフィールド名

Javaタイプ

MQRFH2フォルダ名

プロパティ名

タイプ/値

JMSDestination

Destination

jms

Dst

string

JMSExpiration

long

jms

Exp

i8

JMSPriority

int

jms

Pri

i4

JMSDeliveryMode

int

jms

Dlv

i4

JMSCorrelationID

文字列

jms

Cid

string

JMSReplyTo

Destination

jms

Rto

string

JMSTimestamp

long

jms

Tms

i8

JMSType

文字列

mcd

Type、Set、Fmt

string

JMSXGroupID

文字列

jms

Gid

string

JMSXGroupSeq

int

jms

Seq

i4

xxx (ユーザー定義)

任意

usr

xxx

任意

mcd

Msd

jms_none

jms_text

jms_bytes

jms_map

jms_stream

jms_object

可変部分でプロパティを表現するには、次の構文を使用します。

NameValueLength (MQLONG)

この長さフィールドの直後に指定するNameValueData文字列のバイト単位の長さ。長さ自体の長さは含みません。NameValueLengthに設定する値は、常に4の倍数である必要があります。このために、NameValueDataフィールドをパディングできます。

NameValueData (MQCHARn)

直前のNameValueLengthフィールドによってバイト長を指定した単一文字列。これには、プロパティの順序を格納するフォルダを指定します。各プロパティは名前/タイプ/値の3つからなるセット(トリプレットと呼ばれる)で構成されており、次に示すように、これらのプロパティはフォルダ名と同じ名前のXML要素内に含まれています。

<フォルダ名> triplet1 triplet2 ..... tripletn </フォルダ名>

10.3.2 SSLの有効化

Secure Sockets Layer (SSL)は、インターネットまたは内部ネットワークを介して暗号化されたデータを転送するプロトコルです。SSLは、公開鍵と秘密鍵を使用して、SSL接続を介して転送されるデータを暗号化することによって機能します。公開鍵を使用して暗号化されたデータは、対応する秘密鍵でのみ復号化できます。逆に、秘密鍵を使用して暗号化されたデータは、対応する公開鍵でのみ復号化できます。

SSLを使用したクライアントとのセキュアな通信がサポートされています。この機能の一環として、SSLを使用したメッセージのエンキューがアダプタでサポートされます。SSL用に有効化するには、次のプロパティを指定する必要があります。

- SSLEnable: このプロパティのtrue/false値は、SSL有効化/無効化を示します。

- KeyStoreLocation: これは、秘密鍵を格納するキーストアです。このプロパティは、アダプタがサーバーから認証を受ける必要があるため必要です。

- KeyStorePassword: このパスワードは、キーストアへのアクセスで必要になります。

- TrustStoreLocation: これは、アダプタが信頼できる証明書情報を格納する場所です。この情報は、アダプタがサーバーから認証を受ける場合に必要になります。

- Protocol: キー管理のアルゴリズム。

- KeyStoreProviderName: キーストア・プロバイダの名前。

- KeyStoreType: キーストアのタイプ。

- KeyStoreAlgorithm: キーストアで使用されるアルゴリズム。

- CipherSuite: CipherSuiteは、SVRCONNチャネルで設定されているCipherSpecと一致する名前に設定します。NULL(デフォルト)に設定すると、SSL暗号化は実行されません。

- SSLPeerName: 識別名パターン。CipherSuiteが設定されている場合、この変数を使用することによって、常に正しいキュー・マネージャが使用されるようにできます。NULL(デフォルト)に設定すると、キュー・マネージャの識別名はチェックされません。sslCipherSuiteがNULLの場合は、この変数は無視されます。

10.3.3 XAトランザクション

注意:
IBM社によると、WebSphere MQトランザクション・マネージャ以外によるWebSphere MQ Java Transaction API (JTA)の使用はサポートされません。IBM社では、XAトランザクションではかわりにWebSphere MQ JMS APIの使用を推奨しています。つまり、IBM MQとの対話にXAトランザクションが必要な場合、ユーザーはOracle JCA Adapter for MQ SeriesのかわりにOracle JCA Adapter for JMSを使用する必要があるということです。MQアダプタがXAトランザクションに使用されていると、XAトランザクションにロールバックする必要があるときに、アダプタにエラーが発生する可能性があります。その場合、ユーザーはインダウト・トランザクションを手動で解決する必要があります。

Oracle MQ Seriesアダプタにより、固有のデータ処理とともにトランザクション・サポートが可能になり、これにより、それぞれの変更の結果が明確に定義されており、結果は成功か失敗のいずれかになるため、潜在的なデータ破損が防止され、他の変更から独立して実行され、完了後は別のトランザクションが発生するまで基礎となるデータが同じ状態で維持されることが保証されます。

Oracle MQ Seriesアダプタでは、インバウンドとアウトバウンドの両方のXAトランザクションがサポートされています。XAトランザクションを有効化するには、Oracle WebLogic Server管理コンソールでXATransactionプロパティを設定する必要があります。XAトランザクションを有効化する手順は、次のとおりです。

1. パスワード資格証明を使用して、Oracle WebLogic Server管理コンソールにログインします。

2. 左ペインの「ドメイン構造」で、「デプロイメント」をクリックします。「デプロイメントのサマリー」ページが表示されます。

3. 「MQSeriesAdapter」をクリックします。「MQSeriesAdapterの設定」ページが表示されます。

4. 「構成」タブをクリックします。「構成」サブメニュー・オプションが表示されます。

5. 「アウトバウンド接続プール」をクリックします。「アウトバウンド接続プールの構成表」が表示されます。

6. javax.resource.cci.ConnectionFactoryの横にある「+」アイコンをクリックし、「eis/MQ/MQAdapter」を選択します。「アウトバウンド接続のプロパティ」ページが表示されます。

注意:

コンソールでオプションを有効化するには、「ロックして編集」をクリックします。

7. 「XATransaction」オプションを選択し、「XATransaction」の端にある「プロパティ値」の行をクリックします。

8. 図10-6 に示すように、テキスト・フィールドにtrueと入力して「保存」をクリックします。

図10-6 「アウトバウンド接続のプロパティ」ページ

9. 「トランザクション」タブをクリックします。javax.resource.cci.ConnectionFactoryの設定ページが表示されます。

10. 「トランザクションのサポート」リストから「XAトランザクション」を選択します。

11. 「保存」をクリックして、設定を保存します。「デプロイメント・プラン保存アシスタント」ページが表示されます。

12. 「OK」をクリックします。

Oracle MQ Seriesアダプタに対してXAトランザクションが正常に有効化されました。

同期インバウンド・リクエスト-リプライのシナリオで、MQ SeriesのXAトランザクション機能をBPELで使用するには、bpel.config.transactionパラメータをrequiredに設定する必要があります。このパラメータを設定しなければ、トランザクションはBPEL境界で分割され、MQはMQRC_SYNCPOINT_NOT_AVAILABLEエラー・コードを戻します。

<property name="bpel.config.transaction">required
</property>

10.3.3.1 XAリカバリ

prepare phaseが正常に完了した後、ミドルウェアに障害が発生するなどの、フェイルオーバーが関係するシナリオでは、メッセージはMQSeriesサーバーを再起動しないでアダプタ内でリカバリされる必要があります。インダウト・トランザクションは手動で解決する必要があります。

キュー・マネージャのインダウト・トランザクションをすべて表示するには、コマンド・プロンプトで次のコマンドを実行する必要があります。

dspmqtrn -m[ourQueueManager]

メッセージをバックアウトするには、次のコマンドを使用します。

rsvmqtrn -m[ourQueueManager] -b [Transaction],[Number]

メッセージをコミットするには、次のコマンドを使用します。

rsvmqtrn -m[ourQueueManager] -c [Transaction],[Number]

注意:

dspmqtrnコマンドの出力から[Transaction]および[Number]を使用できます。

10.3.3.2 ActiveMQ Series 5.8と通信するためにJMSアダプタで使用可能なXAサポート

JMSアダプタとActiveMQ Series 5.8間のXA通信のサポートを使用できます。この通信を提供するには、次の手順を実行します。

1. WebLogicコンソールで、次を指定してJNDIエントリを作成します。

eis/activemq/XAQueue

ConnectionFactoryLocationを次のように指定します。

org.apache.activemq.ActiveMQXAConnectionFactory

2. FactoryPropertiesを指定します

BrokerURL=tcp://<YOUR_HOST>:<YOUR_PORT>;ThirdPartyJMSProvider=true

3. IsTransacted : falseと設定します

10.3.4 高可用性

Oracle BPEL Process Manager (Oracle BPEL PM)およびサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能をサポートしています。この機能は、インバウンド操作とアウトバウンド操作の両方でサポートされています。

10.3.4.1 高可用性の前提条件

高可用性を実現するように構成するには、次の前提条件が満たされていることを確認する必要があります。

- クラスタリングされた複数のプロセスで、同じキューが使用されている必要があります。

- 再試行は、断続的なエラーが自動的に解決されるようにするために、バインディング・レベルで、またはフォルト・ポリシーを使用して、構成される必要があります。

10.3.4.2 インバウンド/アウトバウンド操作での高可用性

XAトランザクションに関与する必要があります。XAトランザクションの詳細は、「XAトランザクション」を参照してください。

10.3.5 スケーラビリティ

インバウンド操作にのみスケーラビリティ機能がサポートされます。インバウンド・キューからメッセージをデキューするスレッドの数を制御するパラメータが用意されています。次のプロパティを.jcaファイルで指定する必要があります。

InboundThreadCount='N'

ここで、Nは、インバウンド・キューからメッセージをデキューするために制御するスレッドの数を表しています。デフォルト設定は2です。

Oracle MQアダプタは、デプロイ時、つまりアダプタ・エンドポイントがポーリングを開始したときにバックエンド接続を作成します。接続の作成によって全体的なデプロイ・タスク自体が遅延することはありませんが、アプリケーション・サーバーで接続プールを事前にウォームアップするとわずかに利点があります。

.jcaファイルでInboundThreadCountを使用する場合の構文例を次に示します。

<adapter-config name="ExpressDeathEventListener" adapter="MQSeriesAdapter" wsdlLocation="ExpressDeathEventListener.wsdl" <xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/MQ/MQAdapter" adapterRef=""/>
<endpoint-activation portType="Dequeue_ptt" operation="Dequeue"          UITransmissionPrimitive="Dequeue">
<activation-spec className="oracle.tip.adapter.mq.inbound.ActivationSpecImpl">
<property name="QueueName" value="BPMPOC_EXPCLAIMQ"/>
<property name="InboundThreadCount" value="10"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

10.3.6 エンタープライズ情報システムの資格証明の保護

EISとのアウトバウンド接続の確立時の、エンタープライズ情報システム(EIS)の資格証明(ユーザー名やパスワードなど)の保護がサポートされています。ユーザー名とパスワードは、Oracle WebLogic Serverのコンテナ管理のサインオンを使用して保護できます。

詳細は、「エンタープライズ情報システムの資格証明の保護」を参照してください。

10.3.7 フォルト・ポリシー

フォルト・ポリシー・ファイルには、フォルト条件および対応するフォルト・リカバリ・アクションを定義します。それぞれのフォルト条件で、処理を試みる特定のフォルトまたは一連のフォルトを指定し、それに対応するアクションを指定します。フォルト・ポリシー・ファイルでは一連のアクションがIDで識別されます。

フォルト・ポリシーを使用した拒否ハンドラの定義がサポートされています。

フォルト・ポリシーの詳細は、「拒否ハンドラの構成」を参照してください。

10.3.8 インバウンド拒否ハンドラ

インバウンドのメッセージ拒否処理がサポートされています。メッセージ拒否ハンドラは、変換エラーを処理して修正処理を実行するように構成できます。

拒否ハンドラの詳細は、「拒否ハンドラの構成」を参照してください。

10.3.9 再試行メカニズム

次の2つのインバウンド再試行メカニズムがサポートされています。

- JCAインバウンド再試行メカニズム

- メッセージ・バックアウト・キュー

通常、JCAインバウンド再試行メカニズムはすべてのアダプタで共通して使用されますが、メッセージ・バックアウト・キュー・メカニズムはこれでのみ使用されます。.jcaファイルでBackoutQueueNameプロパティを指定した場合にのみ、再試行にメッセージ・バックアウト・キュー・メカニズムが使用されます。デフォルトでは、再試行にはJCAインバウンド再試行メカニズムが使用されます。

注意:

この2つの再試行方法は相互に排他的な操作であり、アダプタで一度に使用できるメカニズムは一方のみです。両方のオプションを指定した場合は、バックアウト・キュー・オプションが優先されます。

10.3.9.1 JCAインバウンド再試行メカニズム

バックエンド・アプリケーションに接続してイベントを受信するためのプル・モデルがサポートされています。接続関連の問題はリカバリ可能とみなされ、ほとんどのインバウンド・アダプタはEISとの接続を確立できるまで再試行を続けます。

この場合、メッセージをキューに蓄積できない場合も再試行可能です。

再試行メカニズムの詳細は、「エラー処理」を参照してください。

10.3.9.2 メッセージ・バックアウト・キュー

バックアウト・キューは、インバウンド・キューから拒否されたメッセージが蓄積されるキューです。インバウンド・アダプタはメッセージのバックアウト数をチェックし、この数がMaximumBcakoutCount値を超えた場合、指定されたバックアウト・キューにメッセージを蓄積します。このメカニズムを使用して、拒否されたメッセージのインバウンド再試行が処理されます。

.jcaファイルでBackoutQueueNameプロパティを指定すると、再試行にメッセージのバックアウト数が使用されます。MaximumBackoutCountプロパティを使用して最大再試行回数を指定できます。このプロパティのデフォルト値はinfiniteです。MaximumBackoutCount値をBackoutQueueNameとともに指定しない場合、アダプタは無制限に再試行します。バックアウト・キュー・プロパティが指定されている場合、アダプタは(composite.xmlで指定された)JCA再試行を考慮しません。

BackoutRetriesプロパティを設定して、メッセージをバックアウト・キューに配信する再試行の回数を指定する必要があります。この再試行の間隔はBackoutRetryIntervalを使用して設定されます。BackoutRetriesのデフォルト値は3で、BackoutIntervalは5秒です。

MaximumBackoutCount値に達した後もメッセージが拒否される場合、アダプタはメッセージをバックアウト・キューに蓄積します。メッセージをバックアウト・キューに蓄積できなければ、BackoutIntervalの時間遅延を使用してBackoutRetries数になるまで試行します。BackoutRetriesの後もメッセージをバックアウト・キューに蓄積できない場合、アダプタはエンドポイントを非アクティブ化します。

BackoutQueueManagerNameプロパティで、バックアウト・キューのキュー・マネージャの名前も指定する必要があります。BackoutQueueがインバウンド・キューQueueManagerにある場合、このプロパティは使用できません。

注意:

バックアウト・キューを使用する場合は、次の点を考慮してください。

- バックアウト・キュー・オプションは、変換の失敗には使用できません。

- JCA再試行とBackOut再試行の両方が指定されている場合は、BackOut再試行が優先されます。

バックアウト・キューの構成の詳細は、「バックアウト・キューの構成」を参照してください。

10.3.10 パフォーマンス・チューニング

パフォーマンス・チューニング・オプションをサポートしています。

10.4 概念

この項では、次の概念について説明します。

- メッセージングのシナリオ

- メッセージ・プロパティ

- 相関スキーマ

- 配布リストのサポート

- レポート・メッセージ

- メッセージ配信失敗オプション

- メッセージのセグメンテーション

- CICSとの統合

- MQ Seriesのクライアント・チャネル定義表機能の使用

10.4.1 メッセージングのシナリオ

次のメッセージング・シナリオをサポートしています。

- メッセージのエンキュー

- メッセージのデキュー

- 非同期リクエスト-レスポンス(クライアントの場合)

- 同期リクエスト-レスポンス(サーバーの場合)

- 非同期リクエスト-レスポンス(サーバーの場合)

- 同期リクエスト-レスポンス(サーバーの場合)

- 同期リクエスト-レスポンス(クライアントの場合)

- 同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

- 非同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

- アウトバウンド・デキューのシナリオ

10.4.1.1 メッセージのエンキュー

このシナリオではキュー・マネージャにより管理されている特定のキューに接続してメッセージを書き込みます。Oracle BPEL PMから送信されるアウトバウンド・メッセージの場合、次の操作が実行されます。

1. Oracle BPEL PMからメッセージを受信します。

2. 設計時の指定に従ってXMLコンテンツがフォーマットされます。

3. メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
メッセージのプロパティの詳細は、「メッセージ・タイプ」を参照してください。

4. 設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。

図10-7 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。

図10-7 アダプタ構成ウィザード: メッセージ発行の選択

図10-8 に、「MQにメッセージを蓄積」操作タイプを選択した後に表示されるページを示します。

図10-8 メッセージ蓄積オプション

このページで次のプロパティを指定できます。

- キュー名: メッセージをエンキューするキューの名前。これは必須フィールドです。

- キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。

- 一部配信: このオプションを適用できるのは、アウトバウンド操作用のキューを複数指定した場合(配布リストのシナリオ)のみです。「一部配信」の値は、trueまたはfalseです。trueを割り当てると、一部のキューでメッセージの配信に失敗しても、メッセージは配布リストで指定した残りのキューに入れられて蓄積されます。falseを割り当てると、メッセージの1つに失敗しても、そのメッセージはキューに蓄積されません。

- メッセージの書式: メッセージのフォーマット。

注意:

メッセージをエンキューする場合は、特定のフォーマットに必要な各種の必須値を正しく指定していることを確認してください。

- 優先度: 0(最低)から9(最高)までのメッセージの優先度。

- 永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。

- 配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。

- 必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。

- 有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。

これらのプロパティの詳細は、「メッセージ・プロパティ」を参照してください。

次に表示されるアダプタ構成ウィザードのページは、図10-9 の「メッセージ」ページです。このページでは、変換用のXMLスキーマ定義(XSD)ファイルを選択できます。

図10-9 「メッセージ」ページ

ネイティブ・フォーマット変換が不要である場合は(JPGまたはGIFイメージが処理中であるなど)、「ネイティブ・フォーマット変換は不要」チェック・ボックスを選択します。ファイルはBase64エンコーディングで渡されます。

トランスレーションにはXSDファイルが必要です。新しいスキーマの定義、または既存のデータ型定義(DTD)やCOBOLコピーブックの変換を行うには、「ネイティブ・フォーマットのスキーマの定義」を選択します。これにより、ネイティブ・フォーマット・ビルダー・ウィザードが起動されます。このウィザードは、特殊文字区切り、カンマ区切り値(CSV)、固定長、DTDおよびCOBOLコピーブックなどのファイル・フォーマットを使用したネイティブ・スキーマ・ファイルの作成を支援します。ネイティブ・スキーマ・ファイルの作成後、「スキーマ・ファイルのURL」および「スキーマ要素」フィールドが入力された「メッセージ」ページが表示されます。

詳細は、「ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ・ファイルの作成」を参照してください。

注意:

指定するスキーマにネームスペースが含まれていることを確認してください。スキーマにネームスペースが含まれていない場合は、エラー・メッセージが表示されます。

10.4.1.2 メッセージのデキュー

このシナリオでは、キュー・マネージャにより管理されている特定のキューに接続し、そのキューからメッセージを削除します。Oracle BPEL PMに送信されるインバウンド・メッセージの場合、次の操作が実行されます。

1. 設計時に指定したキューに接続されます。

2. メッセージの着信時にキューからメッセージがデキューされます。

3. 設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。

4. メッセージがXMLメッセージとしてOracle BPEL PMにパブリッシュされます。
図10-10 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。

図10-10 アダプタ構成ウィザード: メッセージ消費の選択

図10-11 に、「MQからメッセージを取得」操作タイプを選択した後に表示されるページを示します。

図10-11 「MQからメッセージを取得」ページ

このページで次のプロパティを指定できます。

- キュー名: メッセージをデキューするキューの名前。これは必須フィールドです。

- スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。

- 他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。

- 事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。

次に表示されるアダプタ構成ウィザードのページは、図10-9 の「メッセージ」ページです。このページでは、変換用のXSDスキーマ・ファイルを選択できます。

メッセージ発行操作のスキーマの指定と同様に、このページでは次のタスクを実行できます。

- ネイティブ・フォーマット変換の要不要の指定

- 変換用のXSDスキーマ・ファイルの選択

- CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動

「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。

10.4.1.3 非同期リクエスト-レスポンス(Oracle BPEL PMがクライアントの場合)

このシナリオでは、Oracle BPEL PMがリクエスト・メッセージを送信し、非開始のreceiveアクティビティを使用して対応するレスポンスを受信します。invokeアクティビティによりアダプタのアウトバウンド起動が開始され、リクエストが送信されます。次の操作を実行します。

1. Oracle BPEL PMからのメッセージが受信されます。

2. 設計時にアダプタ構成ウィザードで指定したXMLコンテンツがフォーマットされます。

3. リクエスト・メッセージのプロパティと相関スキーマが設定されます。

4. 設計時に指定したキューにメッセージが送信されます。サード・パーティ・アプリケーションはメッセージを受信して処理し、レスポンスを生成してから、リクエスト・メッセージで指定されたreplyToキューにレスポンス・メッセージをエンキューします。レスポンス・メッセージの相関IDとメッセージIDは、リクエスト・メッセージで指定された相関スキーマに基づいて生成されます。

5. replyToキューからメッセージがデキューされます。

6. レスポンスがメディエータの非開始のreceiveアクティビティに送信されます。レスポンスが正しいBPELインスタンスに確実に送信されるように、相関スキーマが使用されます。

図10-12 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。

図10-12 操作タイプの選択

図10-13 に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。

図10-13 「MQにメッセージを送信し、リプライ/レポートを取得」ページ

このページで次のプロパティを指定できます。

- メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。

- レポートの取得: なんらかのレポートが必要な場合は、このオプションを選択します。レポートのタイプは、図10-14 に示す次のページで指定できます。

- キュー名: メッセージをエンキューするキューの名前。これは必須フィールドです。

- キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションです。

- メッセージの書式: メッセージのフォーマット。

- 優先度: 0(最低)から9(最高)までのメッセージの優先度。

- 永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。

- 配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。

- 必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。

- 有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。

これらのプロパティの詳細は、「メッセージ・プロパティ」および「レポート・メッセージ」を参照してください。

「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、「レポート」ページ(図10-14 )または「レスポンス」ページ(図10-15 )が表示されます。

図10-14 に示す「レポート」ページが表示されるのは、図10-13 に示した「MQにメッセージを送信し、リプライ/レポートを取得」ページで「レポートの取得」オプションを選択した場合のみです。

図10-14 「レポート」ページ

このページで次のレポート・タイプを選択できます。

- 着信時の確認

- 送信時の確認

- 例外レポート

- 有効期限レポート

これらのレポート・タイプの詳細は、「レポート・メッセージ」を参照してください。

「レポート」ページで「次へ」をクリックすると、図10-15 に示す「レスポンス」ページが表示されます。

図10-15 「レスポンス」ページ

「レスポンス」ページで次のプロパティを指定できます。

- 返信先キュー名: 返信先キューの名前。

- 「相関スキーム」: 必要な相関スキーマ。
相関スキーマの詳細は、「相関スキーマ」を参照してください。

- スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。

- 他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。

- 事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。

注意:

非同期アウトバウンド・リクエスト/リプライのシナリオ(このシナリオでは、リクエスト・メッセージはキューに蓄積され、このリクエストに対するリプライはreplyToQueueから非同期でデキューされます)の場合、プロパティは(Enqueue)または(Dequeue)ラベルによって区別されます。この区別は、エンキューとデキューのプロパティ名を区別するために必要です。たとえば、QueueName(Enqueue)はメッセージの蓄積に使用され、QueueName(Dequeue)はリプライのデキューに使用されます。

使用してこのシナリオのプロパティを編集する場合は、次の点に注意してください。

- リクエスト・メッセージのreplyToQueueは、リプライのデキュー元と同じであるため、ReplyToQueueName(Enqueue)プロパティを変更する場合は、QueueName(Dequeue)プロパティも同じ値に変更する必要があります。

- 同様に、MessageId(Dequeue)プロパティを変更する場合は、MessageId(Enqueue)プロパティも同じ値に変更する必要があります。

- 同様に、CorrelationId(Dequeue)プロパティを変更する場合は、CorrelationId(Enqueue)プロパティも同じ値に変更する必要があります。

「レスポンス」ページで「次へ」をクリックすると、図10-16 に示す「メッセージ」ページが表示されます。このページでは、リクエスト・メッセージとレスポンス・メッセージの変換に使用するXSDスキーマ・ファイルを選択できます。

図10-16 「メッセージ」ページ

このページで次のタスクを実行できます。

- ネイティブ・フォーマット変換の要不要の指定

- 変換用のXSDスキーマ・ファイルの選択

- CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動

「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。

請求-リクエスト-レスポンスのシナリオでは、リクエスト・メッセージを介して提供される、なんらかの相関スキームで指定されたリプライ・キュー内でリプライ・メッセージが予期されます。このリプライ・キューは特定のプロセス(BPEL/メディエータ)により使用され、他のプロセスでは使用されません。

同じリプライ・キューが他のなんらかのアプリケーションで使用される場合は、リプライ・メッセージの相関付けが正しいかどうかに関係なくメッセージが取得され、最終的にはメッセージが消失します。

10.4.1.4 同期リクエスト-レスポンス(Oracle BPEL PMがサーバーの場合)

このシナリオでは、Oracle BPEL PMがリクエストを受信して処理し、replyアクティビティを使用してレスポンスを同期的に送信します。次の操作を実行します。

1. メッセージの着信時にキューからリクエスト・メッセージがデキューされます。

2. 設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。

3. メッセージがXMLメッセージとしてOracle BPEL PMにパブリッシュされます。Oracle BPEL PMでは、リクエストが処理されてレスポンスが送信されます。

4. Oracle BPEL PMからのレスポンス・メッセージが受信されます。

5. 設計時の指定に従ってXMLコンテンツがフォーマットされます。

6. メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。

7. 設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。

図10-17 に、このシナリオのサンプルBPELプロセスを示します。

図10-17 同期リクエスト-レスポンスのサンプル(Oracle BPEL PMがサーバーの場合)

図10-18 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。

図10-18 同期リクエスト-レスポンス相互作用の「操作タイプ」ページでの選択

図10-19 に、「MQからメッセージを取得し、リプライ/レポートを送信」操作タイプを選択した後に表示されるページを示します。このページで、メッセージがデキューされるキュー名を指定します。

図10-19 「MQからメッセージを取得し、リプライ/レポートを送信」ページ

「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、図10-20 に示す「レスポンス」ページが表示されます。

図10-20 同期リクエスト-レスポンスの「レスポンス」ページ

「レスポンス」ページで次のプロパティを指定できます。

- メッセージ・タイプ: デキューするメッセージのタイプ。このオプションは返信メッセージ・タイプに影響します。

- メッセージの書式: メッセージのフォーマット。

- 優先度: メッセージの優先度。

- 永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。

- 配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。

- 必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。

- 有効期限: メッセージの有効期限。

これらのプロパティの詳細は、「メッセージ・プロパティ」を参照してください。

「レスポンス」ページで「次へ」をクリックすると、図10-16 に示す「メッセージ」ページが表示されます。このページで次のタスクを実行できます。

- ネイティブ・フォーマット変換の要不要の指定

- 変換用のXSDスキーマ・ファイルの選択

- CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動

「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。

10.4.1.5 非同期リクエスト-レスポンス(Oracle BPEL PMがサーバーの場合)

Oracle BPEL PMがリクエスト-レスポンス相互作用を開始すると、BPELプロセスはリクエストをインバウンド・メッセージとして受信し、処理してからinvokeアクティビティを介してレスポンスを送信します。非同期リクエスト-リプライのシナリオでは、次の操作が実行されます。

1. メッセージの着信時にキューからメッセージがデキューされます。

2. 設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。

3. メッセージがXMLメッセージとしてOracle BPEL PMにパブリッシュされます。Oracle BPEL PMでは、リクエストが処理されてレスポンスが送信されます。

4. Oracle BPEL PMからのメッセージが受信されます。

5. 設計時の指定に従ってXMLコンテンツがフォーマットされます。

6. メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。

7. 設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。

図10-21 に、このシナリオのサンプルBPELプロセスを示します。

図10-21 非同期リクエスト-レスポンスのサンプル(Oracle BPEL PMがサーバーの場合)

図10-22 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。

図10-22 非同期リクエスト-レスポンス相互作用の「操作タイプ」ページでの選択

図10-19 に、「MQからメッセージを取得し、リプライ/レポートを送信」操作タイプを選択した後に表示されるページを示します。このページで、メッセージがデキューされるキュー名を指定します。

「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、図10-20 に示す「レスポンス」ページが表示されます。

「レスポンス」ページで次のプロパティを指定できます。

- メッセージ・タイプ: デキューするメッセージのタイプ。このオプションは返信メッセージ・タイプに影響します。

- メッセージの書式: メッセージのフォーマット。

- 優先度: メッセージの優先度。

- 永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。

- 配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。

- 必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。

- 有効期限: メッセージの有効期限。

これらのプロパティの詳細は、「メッセージ・プロパティ」を参照してください。

「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、「レスポンス」ページ(図10-23 および図10-24 )が表示されますが、これらのページのオプションのセットは互いに異なります。

図10-23 「レスポンス」ページ(「リクエスト」メッセージ・タイプを選択した場合)

図10-24 に示す「レスポンス」ページが表示されるのは、「MQからメッセージを取得し、リプライ/レポートを送信」ページの「メッセージ・タイプ」フィールドで「標準」オプションを選択した場合のみです。

図10-24 「レスポンス」ページ(「標準」メッセージ・タイプを選択した場合)

「レスポンス」ページで次のプロパティを指定できます。

- (オプション)フォールバック返信先キュー: レスポンス・フォールバック・キュー名を入力します。レスポンス・メッセージは、リクエスト・メッセージのreplyToQueueプロパティで指定されたキューにエンキューされます。ただし、リクエスト・メッセージでreplyToQueueプロパティが設定されていない場合、ここに名前を入力することにより、プロセスがレスポンスをエンキューできるようになります。

- (オプション)フォールバック返信先キュー・マネージャ: セカンダリ・キュー名を入力します。この名前が使用されるのは、JNDI接続名の指定時に設定したプライマリ・キュー・マネージャが、「キュー名」フィールドに入力されているキュー名にアクセスできない場合です。これは、「フォールバック返信先キュー」フィールドの説明にある機能に類似しています。
「レスポンス」ページでの他のプロパティの指定方法は、図10-23 で説明されているプロパティを参照してください。

「レスポンス」ページで「次へ」をクリックすると、図10-25 に示す「メッセージ」ページが表示されます。このページで次のタスクを実行できます。

- ネイティブ・フォーマット変換の要不要の指定

- 変換用のXSDスキーマ・ファイルの選択

- CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動

図10-25 「メッセージ」ページ

「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。

非同期リクエスト-リプライ相互作用では、インバウンド・メッセージ・ヘッダーからアウトバウンド・メッセージ・ヘッダーに次のプロパティをマップする必要があります。

- MsgID: メッセージIDを指します。

- CorrelID: メッセージの相関IDを指します。

- CorrelationScheme: リクエスト・メッセージのmsgidとcorrelidの組合せを指します。
詳細は、「相関スキーマ」を参照してください。

- ReplyToQ: レスポンス・キューの名前を指します。

- ReplyToQueueManager: レスポンス・キュー・マネージャの名前を指します。

これらのプロパティはassignアクティビティを使用してマップできます。

1. BPELプロセスを作成してダブルクリックし、「BPELデザイナ」ページを開きます。

2. 表示される垂直メニューで、(x)としてグレー表示されている「変数」アイコンをクリックします。図10-26 に示すように、「変数」ダイアログが表示されます。

図10-26 「変数」ダイアログ

3. 図10-27 および図10-28 に示すように、これらの変数にインバウンド・ヘッダー・メッセージを取得します。

図10-27 「Receive」ダイアログ

4. 図10-28 および図10-23 に示すように、アウトバウンド・リプライ・メッセージについてステップ2で取得した変数を割り当てます。

図10-28 「Invoke」ダイアログ

10.4.1.6 同期リクエスト-レスポンス(サーバーの場合)

このシナリオでは、リクエストを受信して処理し、レスポンスを同期的に送信します。次の操作を実行します。

1. メッセージの着信時にキューからリクエスト・メッセージがデキューされます。

2. 設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。

3. メッセージがXMLメッセージとしてパブリッシュされます。リクエストが処理されてレスポンスが送信されます。

4. レスポンス・メッセージが受信されます。

5. 設計時の指定に従ってXMLコンテンツがフォーマットされます。

6. メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。

7. 設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。

図10-19 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。

これ以降のページは、すべて「同期リクエスト-レスポンス(サーバーの場合)」で説明したページと同様です。

注意:

メディエータの場合、非同期リクエスト-レスポンス・パターンはサポートされていません。

10.4.1.7 同期リクエスト-レスポンス(Oracle BPEL PMがクライアントの場合)

アウトバウンドの同期-請求-リクエスト-レスポンスのシナリオがサポートされています。このシナリオでは、アダプタにより同期的に通常/リクエスト・メッセージがキューにエンキューされてレポート/リプライが予想されます。レポート/リプライ・メッセージは、通常/リクエスト・メッセージのReplyToQueueNameキューに着信します。

注意:

グローバル・トランザクションに参加している場合、リクエスト・メッセージはエンキューされないため、非XAモードでアウトバウンド同期-請求-レスポンスを実行する必要があります。

図10-29 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。

図10-29 「操作タイプ」ダイアログ

図10-13 に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。

このページで次のプロパティを指定できます。

- メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。

- キュー名: メッセージをエンキューするキューの名前。これは必須フィールドです。

- キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。

- メッセージの書式: メッセージのフォーマット。

- 優先度: 0(最低)から9(最高)までのメッセージの優先度。

- 永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。

- 配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。

- 必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。

- 有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。

「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、図10-30 に示す「レスポンス」ページが表示されます。

図10-30 「レスポンス」ページ

同期リクエスト-レスポンスのシナリオでは、「レスポンス」ページで次のプロパティも編集する必要があります。

- 返信先キュー名: 返信先キューの名前。

- 「相関スキーム」: 使用される必要がある相関スキーマ。
相関スキーマの詳細は、「相関スキーマ」を参照してください。

- スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。

- 他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。

- 事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。

- レスポンス待機間隔: このプロパティに有効な値は、任意の間隔値(>= 0)です。これは、アダプタがreplyToQueueNameへのレポート/リプライの着信を待機するミリ秒数です。デフォルトでは、このプロパティの値は0(ゼロ)ミリ秒です。この値は変更できますが、アウトバウンド・アクティビティのタイムアウト間隔よりも小さい値に設定する必要があります。レポート/リプライ・メッセージが規定の時間内に着信しなければ、アダプタにより例外がスローされます。このプロパティはオプションです。

注意:

ResponseWaitIntervalは、アウトバウンド・アクティビティのタイムアウト間隔よりも小さい値に設定する必要があります。ResponseWaitIntervalの値がアウトバウンド・アクティビティのタイムアウトを超えると、アダプタの動作が曖昧になる可能性があります。

10.4.1.8 同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

アウトバウンドの同期-請求-リクエスト-レスポンスのシナリオもサポートされています。このシナリオでは、アダプタにより同期的に通常/リクエスト・メッセージがキューにエンキューされてレポート/リプライが予想されます。レポート/リプライ・メッセージは、通常/リクエスト・メッセージのReplyToQueueNameキューに着信します。

同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)のシナリオは、同期リクエスト-レスポンス(Oracle BPELがクライアントの場合)と同じです。同期リクエスト-レスポンスのシナリオの詳細は、「同期リクエスト-レスポンス(クライアントの場合)」を参照してください。

10.4.1.9 非同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)

このシナリオでは、Oracle Mediatorがリクエスト・メッセージを送信し、Mediatorコールバック・ハンドラから対応するレスポンスを受信します。Oracle Mediatorでは、アウトバウンド起動が送信されてリクエストが送信されます。次の操作を実行します。

1. Oracle Mediatorからのメッセージが受信されます。

2. 設計時にアダプタ構成ウィザードで指定したXMLコンテンツがフォーマットされます。

3. リクエスト・メッセージのプロパティと相関スキーマが設定されます。

4. 設計時に指定したキューにメッセージが送信されます。サード・パーティ・アプリケーションはメッセージを受信して処理し、レスポンスを生成してから、リクエスト・メッセージで指定されたreplyToキューにレスポンス・メッセージをエンキューします。レスポンス・メッセージの相関IDとメッセージIDは、リクエスト・メッセージで指定された相関スキーマに基づいて生成されます。

5. replyToキューからメッセージがデキューされます。

6. メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。

7. レスポンスがBPELプロセスの非開始のreceiveアクティビティに送信されます。レスポンスが正しいBPELインスタンスに確実に送信されるように、相関スキーマが使用されます。

図10-12 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。

図10-13 に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。

このページで次のプロパティを指定できます。

- メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。

- キュー名: メッセージをエンキューするキューの名前。これは必須フィールドです。

- メッセージの書式: メッセージのフォーマット。

- キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。

- 優先度: 0(最低)から9(最高)までのメッセージの優先度。

- 永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。

- 配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。

- 必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。

- 有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。

これらのプロパティの詳細は、「メッセージ・プロパティ」および「レポート・メッセージ」を参照してください。

「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、「レポート」ページ(図10-14 )または「レスポンス」ページ(図10-15 )が表示されます。

図10-14 に示す「レポート」ページが表示されるのは、図10-13 に示した「MQにメッセージを送信し、リプライ/レポートを取得」ページで「レポートの取得」オプションを選択した場合のみです。

図10-15 に示す「レスポンス」ページは、「リクエスト」オプションと「標準」オプションのどちらを選択したかに関係なく表示されます。唯一の違いは、「リクエスト」オプションを選択すると、「レスポンス」ページの「メッセージ・タイプ」フィールドにREPLYと表示されることです。これに対して、「標準」オプションを選択すると、「レスポンス」ページの「メッセージ・タイプ」フィールドにはREPORTSと表示されます。

図10-14 に示すように、次のレポート・タイプを選択できます。

- 着信時の確認

- 送信時の確認

- 例外レポート

- 有効期限レポート

これらのレポート・タイプの詳細は、「レポート・メッセージ」を参照してください。

「レポート」ページで「次へ」をクリックすると、図10-15 に示す「レスポンス」ページが表示されます。

「レスポンス」ページで次のプロパティを指定できます。

- 返信先キュー名: 返信先キューの名前。

- 「相関スキーム」: 使用される相関スキーマ。
相関スキーマの詳細は、「相関スキーマ」を参照してください。

- スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。

- 他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。

- 事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。

注意:

非同期のアウトバウンド・リクエスト/リプライ・シナリオでは、プロパティは(Enqueue)または(Dequeue)ラベルによって区別されます。たとえば、QueueName(Enqueue)はメッセージの蓄積に使用され、QueueName(Dequeue)はリプライのデキューに使用されます。

使用してこのシナリオのプロパティを編集する場合は、次の点に注意してください。

- ReplyToQueueName(Enqueue)プロパティを変更する場合は、QueueName(Dequeue)プロパティも同じ値に変更する必要があります。

- MessageId(Dequeue)プロパティを変更する場合は、MessageId(Enqueue)プロパティも同じ値に変更する必要があります。

- CorrelationId(Dequeue)プロパティを変更する場合は、CorrelationId(Enqueue)プロパティも同じ値に変更する必要があります。

「レスポンス」ページで「次へ」をクリックすると、図10-16 に示す「メッセージ」ページが表示されます。このページでは、リクエスト・メッセージとレスポンス・メッセージの変換に使用するXSDスキーマ・ファイルを選択できます。

「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。

10.4.1.10 アウトバウンド・デキューのシナリオ

アウトバウンド・デキューのシナリオでは、アダプタ構成ウィザードの「操作タイプ」ページで「MQからメッセージを取得」オプションを使用し、アウトバウンドを使用してキューから単一メッセージをデキューします。アウトバウンド・デキュー・オプションを有効化するには、図10-29 に示すように「同期」オプションを選択する必要があります。

「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、図10-30 に示す「レスポンス」ページが表示されます。「レスポンス」ページで次のプロパティを設定する必要があります。

- QueueName: メッセージのデキュー元のキュー名です。このプロパティは必須です。

- レスポンス待機間隔: メッセージがキューにない場合にアダプタが待機するミリ秒数です。このプロパティのデフォルト値は0(ゼロ)ミリ秒です。このプロパティはオプションです。このプロパティに有効な値は、任意の整数値(>= 0)です。このプロパティには、アウトバウンド・アクティビティのタイムアウトよりも小さい値を設定する必要があります。

注意:

ResponseWaitIntervalは、アウトバウンド・アクティビティのタイムアウト間隔よりも小さい値に設定する必要があります。ResponseWaitIntervalの値がアウトバウンド・アクティビティのタイムアウトを超えると、アダプタの動作が曖昧になる可能性があります。

オプションで、次の2つのヘッダー・プロパティを使用して、デキューされるメッセージをメッセージIDおよび相関IDに基づいてフィルタ処理できます。

- jca.mq.MQMD.MsgId: このプロパティは、messageIdに基づいてメッセージ・フィルタ・オプションを設定します。このプロパティに設定する値は、特定のmessageIdの16進数エンコード値である必要があります。

- jca.mq.MQMD.CorrelId: このプロパティは、correlationIdに基づいてメッセージ・フィルタ・オプションを設定します。このプロパティに設定する値は、特定のcorrelationIdの16進数エンコード値である必要があります。

10.4.2 メッセージ・プロパティ

次のメッセージ・プロパティをサポートしています。

- メッセージ・タイプ

- メッセージのフォーマット

- メッセージの有効期限

- メッセージの優先度

- メッセージの永続性

10.4.2.1 メッセージ・タイプ

次の4タイプのメッセージをサポートしています。

- 通常メッセージ
通常メッセージは、あるプログラムから別のプログラムに送信されますが、レスポンスは期待されません。

- リクエスト・メッセージ
リクエスト・メッセージは、あるプログラムから別のプログラムに送信され、レスポンスが必要です。

- リプライ・メッセージ
リプライ・メッセージは、リクエスト・メッセージに対するレスポンスとしてプログラムにより送信されます。

- レポート・メッセージ
レポート・メッセージは、受信側プログラムから送信側プログラムに、メッセージ配信の成功または失敗の確認として送信されます。レポート・メッセージはすべてのメッセージ・タイプ(通常メッセージ、リクエスト・メッセージまたはリプライ・メッセージ)について生成できます。

サポートされている確認メッセージの詳細は、「レポート・メッセージ」を参照してください。

10.4.2.2 メッセージのフォーマット

図10-8 のように、アダプタ構成ウィザードを介して送信メッセージのフォーマットを指定できます。次のメッセージ・フォーマットがサポートされています。

- フォーマット名なし(デフォルト)

- コマンド・サーバー・リクエスト/リプライ・メッセージ

- タイプ1コマンド・リプライ・メッセージ

- タイプ2コマンド・リプライ・メッセージ

- 配信不能ヘッダー

- イベント・メッセージ

- プログラム可能なコマンド・フォーマットによるユーザー定義メッセージ

- 文字のみで構成されるメッセージ

- トリガー・メッセージ

- 転送キュー・ヘッダー

10.4.2.3 メッセージの有効期限

図10-8 のように、アダプタ構成ウィザードを使用して送信メッセージの有効期限を指定できます。メッセージの有効期限後は、キュー・マネージャによりメッセージが破棄されます。

メッセージに有効期限通知が設定されている場合は、メッセージが破棄されるときに通知が生成されます。この通知は、replyToQueueパラメータで指定されたキューに送信されます。デフォルトでは、expiryフィールドにNEVERが設定されます。

10.4.2.4 メッセージの優先度

図10-8 のように、アダプタ構成ウィザードを介して送信メッセージの優先度を指定できます。優先度の範囲は0(最低)から9(最高)までです。また、メッセージの優先度を、宛先キューで定義されているデフォルトの優先度属性から取得するように指定することも可能です。デフォルトでは、メッセージ優先度としてAS_Q_DEFが設定されます。

10.4.2.5 メッセージの永続性

図10-8 のように、アダプタ構成ウィザードを介して送信メッセージの永続性を指定できます。メッセージの永続性が設定されていない場合は、キュー・マネージャの再起動時またはシステム障害の発生時にメッセージが消失します。メッセージの永続性をtrueに設定すると、システム障害が発生したりキュー・マネージャが再起動してもメッセージは消失しません。メッセージの永続性を、宛先キューで定義されているデフォルトの優先度属性から取得するように指定することも可能です。永続メッセージは、アダプタによってログ・ファイルとキュー・データ・ファイルに書き込まれます。障害後にキュー・マネージャが再起動すると、これらの永続メッセージが各ファイルからリカバリされます。

注意:

前述のメッセージ・プロパティはすべて、実行時にメッセージ・ヘッダーを介して指定できます。これらのプロパティにはassignアクティビティを使用して値を割り当てることができます。

10.4.3 相関スキーマ

リクエスト-リプライ相互作用でリクエストにレスポンスをマッピングするには、相関付けが必要です。各リクエスト・メッセージには、メッセージIDと相関IDが含まれています。アプリケーションは、Oracle BPEL PMからリクエスト・メッセージを受信すると、レスポンス・メッセージに対して定義されている相関スキーマをチェックします。アプリケーションでは、相関スキーマに基づいてレスポンス・メッセージのメッセージIDと相関IDが生成されます。

図10-15 に示すアダプタ構成ウィザードの「レスポンス」ページでは、レスポンス・メッセージの相関スキーマを指定できます。

図10-15 に示す「メッセージID」ボックスには、レスポンス・メッセージのメッセージIDについて次のオプションが用意されています。

- レスポンス・メッセージの新規メッセージIDの生成

- リクエスト・メッセージのメッセージIDを使用

同様に、図10-15 に示す「相関ID」ボックスには、レスポンス・メッセージの相関IDについて次のオプションが用意されています。

- リクエスト・メッセージのメッセージIDを使用

- リクエスト・メッセージの相関IDを使用

10.4.4 配布リストのサポート

メッセージを複数のキューにエンキューできます。

「操作タイプ」ページで「MQにメッセージを蓄積」オプションを選択した場合に、複数のキューがあると、自動的にJCAファイルにDistributionListパラメータが追加されます。

10.4.5 レポート・メッセージ

送信メッセージに各種の確認メッセージを設定できます。これらの確認メッセージはレポート・メッセージと呼ばれます。レポート・メッセージが生成されるのは、その生成基準が満たされる場合のみです。メッセージをキューにエンキューするときに、複数タイプのレポート・メッセージをリクエストできます。レポート・メッセージをリクエストする場合は、レポート・メッセージの送信先となるキュー名を指定する必要があります。このキューはreplyToキューと呼ばれます。レポート・メッセージは、キュー・マネージャ、メッセージ・チャネルまたはアプリケーションで生成できます。

次のメッセージ・レポートをサポートしています。

- 着信時の確認
「着信時の確認」(COA)メッセージは、メッセージがターゲット・キュー・マネージャに送信されたことを示します。COAメッセージはキュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14 に示したアダプタ構成ページの「レポート」ページで選択できます。

- 送信時の確認
「送信時の確認」(COD)メッセージは、メッセージが受信側アプリケーションにより受信されたことを示します。CODメッセージはキュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14 に示した「レポート」ページで選択できます。

- 例外レポート
例外レポートが生成されるのは、メッセージを指定の宛先キューに送信できない場合です。例外レポートは、メッセージ・チャネルにより生成されます。このメッセージ・レポートは、図10-14 に示したアダプタ構成ページの「レポート」ページで選択できます。

- 有効期限レポート
有効期限レポートは、メッセージが取得される前に指定の有効期限が経過したために、メッセージが破棄されたことを示します。有効期限レポートは、キュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14 に示したアダプタ構成ページの「レポート」ページで選択できます。

- 肯定アクション通知
肯定アクション通知(PAN)は、リクエストが正常に処理されたことを示します。つまり、メッセージでリクエストされたアクションが正常に実行されたことを意味します。このタイプのレポートは、アプリケーションにより生成されます。

- 否定アクション通知
否定アクション通知(NAN)は、リクエストが正常に処理されなかったことを示します。つまり、メッセージでリクエストされたアクションが正常に実行されなかったことを意味します。このタイプのレポートは、アプリケーションにより生成されます。

PANとNANを除き、前述のすべてのレポート・メッセージについて、オリジナル・メッセージの全体または一部を含めるか、まったく含めないかを指定できます。アダプタ構成ウィザードで次のいずれかのオプションを選択できます。

- オリジナル・メッセージのデータなし

- オリジナル・メッセージの最初の100バイトのデータ

- オリジナル・メッセージ全体

10.4.6 メッセージ配信失敗オプション

メッセージ配信失敗オプションは、リモート・キューに対してのみサポートされ、通常のキューではサポートされません。メッセージを宛先キューに配信できなかった場合に実行するアクションを指定できます。次のいずれかを指定できます。

- メッセージを配信不能キューに蓄積します
これはデフォルトのアクションです。宛先キューに配信できなかったメッセージは配信不能キューに蓄積されます。送信者からリクエストされた場合は、レポート・メッセージが生成されます。

- メッセージの破棄
これは、宛先キューに配信できないメッセージを破棄する必要があることを示します。送信者からリクエストされた場合は、レポート・メッセージが生成されます。

アダプタ構成ウィザードで「MQにメッセージを蓄積」オプションを選択すると、これらのオプションを指定できます。

10.4.7 メッセージのセグメンテーション

インバウンド相互作用とアウトバウンド相互作用の両方でメッセージのセグメンテーションがサポートされています。セグメンテーションが必要になるのは、メッセージ・サイズがキューの許容メッセージ・サイズよりも大きい場合です。物理メッセージは2つ以上の論理メッセージに分割されます。すべての論理メッセージには、同じグループIDと順序番号およびオフセットが付きます。

インバウンド相互作用の場合、セグメンテーションは本来サポートされています。すべての論理メッセージが順序番号順にデキューされてから、単一メッセージがXMLとしてOracle BPEL PMにパブリッシュされます。

「必要な場合、メッセージをセグメント化できます」オプションを使用すると、アウトバウンド相互作用についてメッセージをセグメント化できます。このオプションは、アダプタ構成ウィザードの「レスポンス」ページに表示されます。

メッセージは、サイズがキューに設定された上限を超えるかどうかに基づいてセグメント化されます。

配信リストを使用する場合、メッセージのセグメンテーションはサポートされません。この原因は、MQアダプタで使用されるIBM MQ Series製品のJava APIにおける制限です。

10.4.8 CICSとの統合

CICSサーバーからのメッセージの送受信をサポートします。インバウンド方向では、CICSサーバーからのインバウンド・メッセージは通常メッセージと同様にデキューされます。アウトバウンド方向では、メッセージにCICSフォーマットを使用する必要があります。次のXSD例に、アウトバウンドCICSメッセージ・フォーマットのサンプル・スキーマ・ファイルを示します。「Oracle MQ Seriesアダプタのエンコーディング」で、サポートされているOracle MQ Seriesアダプタのエンコーディングのリストも参照してください。

<?xml version="1.0" ?><schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/cics_mqcih"
elementFormDefault="qualified"
attributeFormDefault="unqualified"

xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
nxsd:version="NXSD"

nxsd:encoding="UTF8"
nxsd:stream="bytes"
nxsd:byteOrder="bigEndian"

xmlns:nxsd_extn="http://xmlns.oracle.com/pcbpel/nxsd/extensions"

<element name="MSGForMQCICSBridge">
<complexType>
<sequence>
<element name="MQCIH">
<complexType>
<sequence>
<!--
MQCHAR4   StrucId;
Structure identifier
-->
<element name="StrucId" type="string"
nxsd:style="fixedLength" nxsd:length="4" nxsd:padStyle="tail"/>

<!--
MQLONG    Version;
Structure version number 1 or 2
-->
<element name="Version" type="string"
nxsd:style="integer" nxsd_extn:octet="4"
nxsd_extn:align="0" nxsd_extn:sign="unticked" />
<!--
MQLONG    StrucLength;
Length of MQCIH structure V1=164 V2=180
-->
<element name="StrucLength" type="string"
nxsd:style="integer" nxsd_extn:octet="4"
nxsd_extn:align="0" nxsd_extn:sign="unticked" />

<!--
MQLONG    Encoding;
Reserved
-->
<element name="Encoding" type="string"
nxsd:style="integer" nxsd_extn:octet="4"
nxsd_extn:align="0" nxsd_extn:sign="unticked" />

<!--
MQLONG    CodedCharSetId;
Reserved              -->
<element name="CodedCharSetId" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQCHAR8   Format;
MQ Format name
-->
<element name="Format" type="string"
nxsd:style="fixedLength" nxsd:length="8" />

<!--
MQLONG    Flags;
Reserved
-->
<element name="Flags" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"

nxsd_extn:sign="unticked" />

<!--
MQLONG   ReturnCode;
Return code from bridge
-->
<element name="ReturnCode" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   CompCode;
MQ completion code or CICS EIBRESP
-->
<element name="CompCode" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   Reason;
MQ reason or feedback code, or CICS EIBRESP2
-->
<element name="Reason" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   UOWControl;
Unit-of-work control
-->
<element name="UOWControl" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   GetWaitInterval;
Wait interval for MQGET call issued by bridge
-->
<element name="GetWaitInterval" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="ticked" />

<!--
MQLONG   LinkType;
Link type
-->
<element name="LinkType" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   OutputDataLength;
Output commarea data length
-->
<element name="OutputDataLength" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="ticked" />

<!--
MQLONG   FacilityKeepTime;
Bridge facility release time
-->
<element name="FacilityKeepTime" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   ADSDescriptor;
Send/receive ADS descriptor
-->
<element name="ADSDescriptor" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   ConversationalTask;
Whether task can be conversational
-->
<element name="ConversationalTask" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />
<!--
MQLONG   TaskEndStatus;
Status at end of task
-->
<element name="TaskEndStatus" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQBYTE   Facility[8];
BVT token value. Initialise as required.
-->
<element name="Facility" type="string"
nxsd:style="integer" nxsd_extn:octet="8" nxsd_extn:align="0"
nxsd _extn:sign="unticked" />

<!--
MQCHAR4  Function;
MQ call name or CICS EIBFN function name
-->
<element name="Function" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR4  AbendCode;
Abend code
-->
<element name="AbendCode" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR8  Authenticator;
Password or passticket
-->
<element name="Authenticator" type="string"
nxsd:style="fixedLength" nxsd:length="8" />

<!--
MQCHAR8  Reserved1;
Reserved
-->
<element name="Reserved1" type="string"
nxsd:style="fixedLength" nxsd:length="8" />

<!--
MQCHAR8  ReplyToFormat;
MQ format name of reply message
-->
<element name="ReplyToFormat" type="string"
nxsd:style="fixedLength" nxsd:length="8" />

<!--
MQCHAR4  RemoteSysId;
Remote sysid to use
-->
<element name="RemoteSysId" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR4  RemoteTransId;
Remote transid to attach
-->
<element name="RemoteTransId" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR4  TransactionId;
Transaction to attach
-->
<element name="TransactionId" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR4  FacilityLike;
Terminal emulated attributes
-->
<element name="FacilityLike" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR4  AttentionId;
AID key
-->
<element name="AttentionId" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR4  StartCode;
Transaction start code
-->
<element name="StartCode" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR4  CancelCode;
Abend transaction code
-->
<element name="CancelCode" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR4  NextTransactionId;
Next transaction to attach
-->
<element name="NextTransactionId" type="string"
nxsd:style="fixedLength" nxsd:length="4" />

<!--
MQCHAR8  Reserved2;
Reserved
-->
<element name="Reserved2" type="string"
nxsd:style="fixedLength" nxsd:length="8" />
<!--
MQCHAR8  Reserved3;
Reserved
-->
<element name="Reserved3" type="string"
nxsd:style="fixedLength" nxsd:length="8" />

<!--
MQLONG   CursorPosition;
Cursor position
-->
<element name="CursorPosition" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   ErrorOffset;
Error offset
-->
<element name="ErrorOffset" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   InputItem;
Input item
-->
<element name="InputItem" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />

<!--
MQLONG   Reserved4;
Reserved
-->
<element name="Reserved4" type="string"
nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0"
nxsd_extn:sign="unticked" />
</sequence>
</complexType>
</element>

<!--
Application data
-->
<element name="ApplicationData" type="string"
fixed="Nothing" />

</sequence>
</complexType>
</element>
</schema>

10.4.9 MQ Seriesのクライアント・チャネル定義表機能の使用

このCCDTを使用すると、MQ SeriesアダプタにJNDIを構成している間にプロパティを定義する際に複数の利点があります。

クライアント・チャネル定義表の機能を理解しておくと役に立ちます。

クライアント・チャネル定義表の構成を理解するには、次の基本用語と基本概念を理解しておく必要があります。

- チャネル名および接続名: 表内の各定義のチャネル名は、指定された接続名で実行されるリスナーを持つキュー・マネージャのサーバー接続チャネルとまったく同一にする必要があります。たとえば、CCDT内の第1の定義であるchannel.ccdt_qm1は、localhost(1414)で実行されるリスナーを持つキュー・マネージャのサーバー接続チャネル名になっています。

- キュー・マネージャ名: CCDTで定義済のキュー・マネージャ名は、定義されたチャネル名および接続名を持つキュー・マネージャの実際の名前と異なる可能性があります。次の可能性が考えられます。

- クライアント・チャネルで定義されているキュー・マネージャ名は、表の第3の定義にあるように実際のキュー・マネージャ名となっています。したがって、ccdt_qm3は、サーバー接続チャネルとしてchannel.ccdt_qm3を所有し、さらにlocalhost(3414)でリスニングするリスナーを所有するキュー・マネージャの実際の名前となります。

- クライアント・チャネル定義にキュー・マネージャ名が定義されていません。図10-31 では、定義されたキュー・マネージャ名を持たない表内の第4の定義においてこの状況を確認できます。

- CCDT内の2つ以上のクライアント・チャネル・エントリに、定義された同一のキュー・マネージャ名が存在します。この名前は、どのエントリの実際のキュー・マネージャ名とも一致できます。図10-31 の第1と第2の定義には、QMとして定義された同じキュー・マネージャ名がありますが、実際は異なるキュー・マネージャをポイントしています。
図10-31 は、ccdt_qm1からccdt_qm4までの4つのキュー・マネージャに対する接続に定義されたクライアント・チャネルを持つ標準のCCDTを示しています。

図10-31 CCDTの例

一度定義されると、このCCDTはデフォルトで次の場所に存在します。

- Windowsの場合、<C:\Program Files\IBM\ MQ\qmgrs\QM_NAME\@ipcc\AMQCLCHL.TAB>

- Unixベースのシステムの場合、<var/mqm/qmgrs/QM_NAME/@ipcc/AMQCLCHL.TAB>

この機能により、MQ SeriesアダプタへのJNDIの構成中にConnectionFactoryプロパティのHostname、PortNumber、ChannelNameおよびQueueManagerNameの定義を要する、以前のタスクが単純化されます。

- クライアント・チャネル定義表(CCDT)は、構成の一部としてCCDTファイルの他、QueueManagerNameをポイントするURLでのみ使用できます。MQ Seriesアダプタは、CCDTから残りの接続の詳細を読み取り、MQ Seriesアダプタに必要な接続を作成できます。

- MQ Seriesアダプタは、キュー・マネージャのリスト(いくつかは停止中の場合もある)で使用可能なキュー・マネージャに動的に接続するよう構成できます。

- コンポジット・プロセスでMQアダプタに使用するJNDIを変更する必要はなく、MQアダプタによる接続を要求されていたキュー・マネージャを変更するためにコンポジットを再デプロイする必要もありません。

- キュー・マネージャに必要なConnectionFactory JNDIエントリは1つのみで、MQアダプタは、使用可能な最初のキュー・マネージャに動的に接続されます。

- CCDTを使用して、クライアント・チャネル定義で同じキュー・マネージャ名のプロパティを持つキュー・マネージャのリストを定義できます。このリストは、いかなる構成の変更や再デプロイも要求されることなく、MQ Seriesアダプタが実行時に使用可能な最初のキュー・マネージャへの動的な接続をするために使用されます。

IBM MQおよびMQアダプタの使用方法の基本理解とCCDTの作成の詳細は、IBM MQ Seriesドキュメントを参照してください。

IBM MQバージョン6は、CCDT機能が動作するための最低要件となっています。

10.4.10 大きなペイロードのサポート

MQアダプタは、MQメッセージとしての大きなペイロードの読取りおよび書込みをサポートするようになりました。大きなペイロード用にインバウンドおよびアウトバウンドMQ Seriesアダプタを構成する方法については、次の項を参照してください。

10.4.10.1 大きなペイロード用のインバウンドMQアダプタの構成

インバウンド処理の場合、MQ Seriesアダプタ構成ウィザードを使用したインバウンド・アダプタの構成中に「大きいメッセージの使用のサポート」チェック・ボックスを選択して、大きなペイロード用のインバウンドMQアダプタを構成できます。次のスクリーンショットにこれを示します。

図10-32 MQ Seriesアダプタのインバウンドでの大きいメッセージのサポートの構成

10.4.10.2 大きなペイロード用のアウトバウンドMQアダプタの構成

アウトバウンドでは、大きなペイロード・サポート用に必要な構成はありません。ただし、次の2つのオプションの構成が、アウトバウンド処理で重要となります。

1. SegmentIfRequiredプロパティ: デフォルトではこのプロパティはTRUEに設定されていますが、アウトバウンドMQアダプタの構成中に「必要な場合、メッセージをセグメント化できます」チェック・ボックスを使用して構成することもできます。MQアダプタが大きなメッセージを小さなセグメントに分割できるようにする場合は、このブール・プロパティをtrueに設定する必要があります。このプロパティがfalseに設定され、メッセージのサイズがキュー、チャネルまたはキュー・マネージャで許可されている最大メッセージ・サイズを超えている場合、MQサーバーは、キューにそのメッセージを格納することを許可せず、MQアダプタは例外をスローします。

2. MaximumSegmentLength: デフォルトでは「最大許容」に設定されており、ウィザードを使用したアウトバウンドMQアダプタの構成中に「最大セグメント長」ラジオ・ボタンを使用して、このプロパティを構成できます。「カスタム」ラジオ・ボタンを選択して、ユーザー定義のメッセージ・セグメント長を構成でき、アダプタはそのサイズにメッセージをセグメント化します。「最大許容」ラジオ・ボタンが選択されている場合、MQアダプタは、アウトバウンド・キュー、チャネルおよびキュー・マネージャが許可している最大セグメント・サイズにメッセージをセグメント化します。

指定されたカスタム・セグメント値がMQサーバーで許可されている値より大きい場合は、サーバーで指定されている値が適用されます。

次の図は、2つの構成を示しています。

図10-33 MQ Seriesアダプタのアウトバウンドでの大きいメッセージのサポートの構成

10.4.11 添付のサポート

MQアダプタは、添付としてメッセージを処理することをサポートしています。インバウンド・メッセージを添付として処理する場合、MQアダプタは、ペイロードの変換を無視し、メッセージを次のコンポーネントに直接転送します。同様に、アウトバウンドでは、添付として書き込む場合、MQアダプタはペイロードの変換を無視し、キューにメッセージを不透明に書き込みます。この機能は、あるキューから別のキューに大きなメッセージを不透明に転送する場合に役立ちます。

構成ウィザードを使用したインバウンド・アダプタの構成中に、「メッセージを添付ファイルとして読取り」チェック・ボックスを選択して、メッセージを添付ファイルとして処理するようにMQアダプタを構成できます。詳細は、第10.6.9項の使用例を参照してください。

図10-34 メッセージを添付ファイルとして読み取るようにインバウンドMQアダプタを構成

10.5 構成

使用するための前提条件は次のとおりです。

- IBM MQサーバーがインストール済で稼働している必要があります。

- キュー・マネージャとサーバー接続チャネルを作成する必要があります。

注意:

キューはアプリケーションの要件に基づいて作成する必要があります。

構成するには、次の手順を実行します。

- クラスパスへのjarファイルの追加: MQ Series 6および7

- JNDIエントリの追加

- 接続のバインディング・モードの有効化

10.5.1 クラスパスへのjarファイルの追加: MQ Series 6および7

この項で説明する手順は、使用前に1度実行します。

クラスパスに正しいjarプロパティを追加するには、次のjarを<DOMAIN_HOME>/libフォルダにコピーします

- com.ibm.mq.jar

クラスパスに正しいjarプロパティを追加するには、次のjarを<DOMAIN_HOME>/libフォルダにコピーします

- com.ibm.mq.commonservices.jar

- com.ibm.mq.jar

- com.ibm.mq.pcf.jar

- com.ibm.mq.headers.jar

- com.ibm.mq.jmqi.jar

- com.ibm.mqetclient.jar (XAによる方法の場合。7.5より前のバージョンでは、XAトランザクション・シナリオでこのcom.ibm.mqetclient.jarが含まれる必要があります。jarは、IBM MQ Seriesの標準インストールでは提供されません。このJARを入手するには、IBMから追加のライセンスを取得する必要があります。)

また、使用している場合は、サーバー接続チャネルの新しい会話の共有プロパティをゼロに設定する必要があります。

7.5バージョンのIBM MQ Seriesの場合、次のjarが必要となります。

- com.ibm.mq.jar

- com.ibm.mq.jmqi.jar

- com.ibm.mqjms.jar

- dhbcore.jar

com.ibm.mqetclient.jarは、MQ Series 7.5サーバーでは必要ありません。XAトランザクションの実行は、MQ Series 7.5を使用している場合、そのjarが存在しなくても機能します。

10.5.2 JNDIエントリの追加

次の手順に従って、Oracle WebLogic Server管理コンソールに新しいJNDIエントリを追加できます。

1. ユーザー名とパスワードを使用して次のURLにログインし、Oracle WebLogic Server管理コンソールを開きます。

http://<localhost>:port/console

図10-35 に示すように、ホーム・ページが表示されます。

図10-35 Oracle WebLogic管理コンソールのホーム・ページ

2. 左ペインの「ドメイン構造」で、「デプロイメント」をクリックします。「デプロイメントのサマリー」ページが表示されます。

3. 「MQSeriesAdapter」をクリックします。図10-36 に示すように、「MQSeriesAdapterの設定」ページが表示されます。

図10-36 「MQSeriesAdapterの設定」ページ

4. 「構成」タブをクリックします。図10-37 に示すように、「構成」サブメニュー・オプションが表示されます。

図10-37 「MQSeriesAdapterの設定」ページ - 「構成」サブメニュー・オプション

5. 「アウトバウンド接続プール」をクリックします。図10-38 に示すように、「アウトバウンド接続プールの構成表」が表示されます。

図10-38 アウトバウンド接続プールの構成表

6. 「新規」をクリックします。図10-39 に示すように、「新しいアウトバウンド接続の作成」ページが表示されます。

図10-39 「新しいアウトバウンド接続の作成」ページ

7. 「javax.resource.cci.ConnectionFactory」オプションを選択し、「次へ」をクリックします。

8. 図10-40 に示すように、「JNDI名」フィールドに値(eis/MQ/MQAdapterなど)を入力します。

図10-40 「新しいアウトバウンド接続の作成」ページ - JNDI名

9. 「終了」をクリックします。「デプロイメント・プラン保存アシスタント」ページが表示されます。

10. 「OK」をクリックします。JNDI名が正常に作成されました。

10.5.3 接続のバインディング・モードの有効化

Oracle WebLogic Server管理コンソールでプロパティをいくつか変更して、接続のバインディング・モードを有効化できます。

バインディング・モードを有効化する手順は、次のとおりです。

1. パスワード資格証明を使用して、Oracle WebLogic Server管理コンソールにログインします。

2. 左ペインの「ドメイン構造」で、「デプロイメント」をクリックします。「デプロイメントのサマリー」ページが表示されます。

3. 「MQSeriesAdapter」をクリックします。「MQSeriesAdapterの設定」ページが表示されます。

4. 「構成」タブをクリックします。「構成」サブメニュー・オプションが表示されます。

5. 「アウトバウンド接続プール」をクリックします。「アウトバウンド接続プールの構成表」が表示されます。

6. 「javax.resource.cci.ConnectionFactory」の横にある「+」アイコンをクリックします。JNDIのリストが表示されます。

7. 「eis/MQ/MQAdapter」を選択します。これは、「JNDIエントリの追加」で作成したJNDIです。図10-41 に示すように、24のプロパティのリストを含んだ「アウトバウンド接続のプロパティ」ページが表示されます。

図10-41 「アウトバウンド接続のプロパティ」ページ

8. 次のパラメータを設定します。

- hostName: この値は常に空白にする必要があります。

- portNumber: この値には未使用のポート番号を指定する必要があります。たとえば、44888を指定します。

- channelName: この値は常に空白にする必要があります。

- queueManagerName: この値は有効なキュー・マネージャ名です。

接続用のバインディング・モードが有効化されました。

10.5.4 メッセージ・セレクタを使用したメッセージの選択的デキュー

2つ以上のBPELプロセスが同じキューからメッセージを受信すると、それらのメッセージが正しいBPELプロセスに配信される確証はなく、そのキューでリスニングするあらゆるBPELプロセスに関連付けられる可能性があります。

ただし、1つのプロセスのみが特定のキューからのメッセージをリスニングするようにプロセスを設定できます。

これを行うために、メッセージ選択条件を満たすメッセージのみをデキューし、条件を満たさないメッセージは破棄するようにMQアダプタを構成できます。

その後、これらのメッセージは、メッセージがその選択条件を満たせば、同じキューからメッセージをリスニングする他のBPELプロセスで受信できます。

メッセージ・セレクタに関連付けられた構文とルールを調べる前に、MQアダプタ構成ウィザードのコンテキストでメッセージ・セレクタを確認すると役立ちます。

同じキューからメッセージを受信するすべてのBPELプロセスのメッセージ・セレクタは、相互に排他的である必要があります。

10.5.4.1 MQアダプタ構成ウィザードでのメッセージ・セレクタ

メッセージ・セレクタ機能が、MQアダプタ・ウィザードの「MQからメッセージを取得」画面に表示されます。メッセージ・セレクタを指定すると、activation-specで指定したセレクタの情報がウィザードによって入れられます。図10-42 に示すように、「メッセージ・セレクタ」フィールドは「キュー名」フィールドの直下にあります。

図10-42 MQアダプタ構成ウィザードの「MQからメッセージを取得」画面上の「メッセージ・セレクタ」フィールド

10.5.4.2 MQでのメッセージ・セレクタの使用

メッセージ・セレクタを使用すると、セレクタがどのメッセージをMQキューからのデキュー対象とするかを指定できます。ヘッダーとプロパティがセレクタに一致するメッセージのみがデキューされます。

メッセージのヘッダー・フィールドおよびプロパティ値がセレクタの対応する識別子に代入された場合にセレクタがtrueと評価すると、メッセージはセレクタに一致します。

メッセージ・セレクタは、MQ構成ウィザード・アダプタを使用してインバウンドMQアダプタを構成するときに、アクティブ化仕様プロパティとして定義されます。サンプルのメッセージ・セレクタは次のとおりです。

例 - インバウンドMQアダプタのサンプル・メッセージ・セレクタ

<property name="MessageSelector" value="((jca.mq.MQMD.Priority BETWEEN 0 AND 3) AND NOT(jca.mq.MQMD.Priority = 1)) AND jca.mq.MQMD.PutApplName LIKE 'WebSph_re MQ%' AND jca.mq.MQMD.MsgType NOT IN (0, 1) AND (jca.mq.MQMD.ReplyToQ = 'test_q2' OR jca.mq.MQMD.ReplyToQ IS NULL) AND name = 'Joe'"/>

MessageSelectorが定義されていない場合、MQアダプタはメッセージの選択を行わず、キューに到達したすべてのメッセージをデキューします。

10.5.4.2.1 メッセージ・セレクタ構文: リテラル

この項では、MessageSelector構文について詳細に説明します。メッセージ・セレクタを作成するオプションを提供するMQメッセージ取得画面のセレクタ・ボックスにセレクタ情報を入力するために、この構文を理解する必要があります。

メッセージ・セレクタの評価は、優先順位レベル内で左から右の順に行われます。カッコを使用して、この順序を変更できます。

セレクタには次のリテラルを含めることができます。

- 文字列: 文字列リテラルは一重引用符で囲む必要があります。Java文字列リテラルと同様、Unicode文字エンコーディングを使用します。

- 正確な数値: 正確な数値リテラルは、小数点を含まない数値です。Java longの範囲内の数値がサポートされます。

- 近似の数値: 近似の数値リテラルは、小数点を含む数値です。Java doubleの範囲内のすべての数値がサポートされます。

- ブール: TrueまたはFalse。

10.5.4.2.2 メッセージ・セレクタ識別子

識別子を使用して、メッセージ・セレクタでメッセージ・ヘッダーおよびプロパティ値を識別します。メッセージ・ヘッダー・プロパティは、MQMDプロパティ、ユーザー定義プロパティ、およびRFH2ヘッダーのUSRフォルダで定義されているプロパティです。他のRFH2フォルダで定義されているプロパティは、メッセージ・セレクタではサポートされていません。識別子に関して次のことに注意してください

- 大文字と小文字は区別されます

- AND、OR、NOT、TRUE、FALSE、IN、LIKE、BETWEEN、IS、NULL、ESCAPEまたはdivは使用できません。

- ネーミング規則があります。「jca.mq.MQMD.」で始まらない識別子名はすべて、RFH2ヘッダーのUSRフォルダ・プロパティ識別子であるとみなされます。

次のものが識別子を構成します。

- MQMDヘッダー・フィールド。表10-5を参照してください。

- RFH2 USRフォルダ。MQメッセージのRFH2ヘッダーのUSRフォルダで定義されているプロパティ名はすべて、識別子として使用できます。プロパティ名は、Java識別子開始文字で始まり、後に続く文字がJava識別子部分文字(「.」、「_」および「$」を含めることができます)である必要がある、長さが無制限の文字列とすることができます。
メッセージ・セレクタ内でのその他のRFH2フォルダ・プロパティの使用はサポートされていません。表10-5 に、MQMDヘッダーおよびメッセージ・セレクタ識別子を示します。

表10-5 MQMDヘッダーおよびメッセージ・セレクタ識別子

MQMDヘッダー・フィールド

識別子

アカウンティング・トークン

jca.mq.MQMD.AccountingToken

アプリケーションIDデータ

jca.mq.MQMD.ApplIdentityData

アプリケーション送信元データ

jca.mq.MQMD.ApplOriginData

バックアウト・カウント

jca.mq.MQMD.BackoutCount

コード化キャラクタ・セットID

jca.mq.MQMD.CodedCharSetId

相関ID

jca.mq.MQMD.CorrelId

エンコーディング

jca.mq.MQMD.Encoding

有効期限

jca.mq.MQMD.Expiry

フィードバック

jca.mq.MQMD.Feedback

書式

jca.mq.MQMD.Format

グループID

jca.mq.MQMD.GroupId

メッセージ・フラグ

jca.mq.MQMD.MsgFlags

メッセージID

jca.mq.MQMD.MsgId

メッセージ・シーケンス番号

jca.mq.MQMD.MsgSeqNumber

メッセージ・タイプ

jca.mq.MQMD.MsgType

オフセット

jca.mq.MQMD.Offset

元の長さ

jca.mq.MQMD.OriginalLength

永続性

jca.mq.MQMD.Persistence

優先度

jca.mq.MQMD.Priority

蓄積アプリケーション名

jca.mq.MQMD.PutApplName

蓄積アプリケーション・タイプ

jca.mq.MQMD.PutApplType

蓄積日時

jca.mq.MQMD.PutDateTime

返信先キュー・マネージャ名

jca.mq.MQMD.ReplyToQMgr

返信先キュー名

jca.mq.MQMD.ReplyToQ

レポート

jca.mq.MQMD.Report

ユーザー識別子

jca.mq.MQMD.UserIdentifier

10.5.4.2.3 メッセージ・セレクタの式

メッセージ・セレクタ内の式は、次のタイプになります。

- 算術: 式自体、算術演算子および数値リテラルで構成されます。

- 条件付き: 式自体、比較演算子、論理演算子およびブール・リテラルで構成されます。

10.5.4.2.4 メッセージ・セレクタの演算子

メッセージ・セレクタの演算子には、次の2つのタイプがあります。

- カッコで囲む: 標準のカッコ()を使用して式評価を順序付けします。

- 論理: 優先順の論理演算子は、NOT、AND、ORです。

10.5.4.2.5 メッセージ・セレクタの比較

メッセージ・セレクタの比較演算子には、=、>、>=、<、<=、<> (等しくない)が含まれます。

次の点に注意してください。

- likeタイプの値のみを比較対象とすることができます。1つの例外として、正確な数値と近似の数値の比較は有効です。

- 文字列とブールの比較は、=および<>に制限されています。2つの文字列は、同じ文字のシーケンスが含まれる場合にのみ等しくなります。

10.5.4.2.6 メッセージ・セレクタの算術

優先順の算術演算子は、次のとおりです。

- +、- (単項)

- *、/ (乗算および除算)

- +、- (加算および減算)

10.5.4.2.7 メッセージ・セレクタの高度な演算子

メッセージ・セレクタの高度な演算子のリストを参照してください。

表10-6 メッセージ・セレクタの高度な演算子

演算子

構文と例

[NOT] BETWEEN

構文: Identifier [NOT] BETWEEN arithmetic-expr1 AND arithmetic-expr2

- 例: jca.mq.MQMD.Priority BETWEEN 0 AND 3は、メッセージの優先度が>= 0および<= 3であることを意味します。

- 例: jca.mq.MQMD.Priority NOT BETWEEN 2 AND 4は、メッセージの優先度が2より小さいか4より大きいことを意味します。

[NOT] IN

構文: Identifier [NOT] IN (literal1, literal2, …)

- 例: jca.mq.MQMD.MsgType IN (0, 1)は、メッセージ・タイプが0または1である必要があることを意味します。

- 例: jca.mq.MQMD.MsgType NOT IN (0, 1, 2)は、メッセージ・タイプが0、1または2でない必要があることを意味します。

[NOT] LIKE

構文: Identifier [NOT] LIKE pattern-value

pattern-valueは文字列リテラルで、「_」は任意の単一文字を表し、「%」は文字の任意のシーケンス(空のシーケンスを含む)を表し、その他のすべての文字はその文字自体を表します。

- phone LIKE '12%3'は、「123」または「12993」に対してはtrue、「1234」に対してはfalseになります。

- word LIKE 'l_se'は、「lose」に対してはtrue、「loose」に対してはfalseになります。

- phone NOT LIKE '12%3'は、「123」および「12993」に対してはfalse、「1234」に対してはtrueになります。

IS [NOT] NULL

構文: Identifier IS [NOT] NULL

- prop_name IS NULLは、prop_nameがnullの場合はtrue、prop_nameがnullでない場合はfalseになります。

- prop_name IS NOT NULLは、prop_nameがnullでない場合はtrue、prop_nameがnullの場合はfalseになります。

10.5.4.2.8 メッセージ・セレクタの例

追加のセレクタを含むメッセージ・セレクタの例は、次のとおりです。その後、このセレクタをサンプル・メッセージに対して適用した結果を確認できます。

例 - 追加のセレクタを含むメッセージ・セレクタの例

<property name="MessageSelector" value="((jca.mq.MQMD.Priority BETWEEN 0 AND 3) AND NOT(jca.mq.MQMD.Priority = 1)) AND jca.mq.MQMD.PutApplName LIKE 'WebSph_re MQ%' AND jca.mq.MQMD.MsgType NOT IN (0, 1) AND (jca.mq.MQMD.ReplyToQ = 'test_q2' OR jca.mq.MQMD.ReplyToQ IS NULL) AND name = 'Joe'"/>

サンプル・メッセージをリストし、このセレクタに一致するメッセージおよび一致しないメッセージを示す、表10-7 を参照してください。

表10-7 メッセージ・セレクタ例のサンプル・メッセージ

メッセージ・プロパティ

メッセージ1

メッセージ2

メッセージ3

メッセージ4

優先度

2

2

3

1

蓄積アプリケーション名

WebSphere MQ7

WebSphere MQ6

WebSphere MQ6

WebSphere MQ

メッセージ・タイプ

8

8

2

4

返信先キュー名

test_q2

test_q2

USR RFH2フォルダ

名前 = Ankur

年齢 = 24

電話番号 = 123456

名前 = Bob

年齢 = 42

電話番号 = 654321

名前 = Ankur

従業員ID = 3321

色 = Red

テーマ = old

MessageSelectorは成功したか

True

False

False

False

コメント

USRフォルダ内の名前プロパティがセレクタに一致しません。

蓄積アプリケーション名プロパティが一致しません。

USRフォルダ内の優先度と名前プロパティが一致しません。

10.5.4.2.9 メッセージ・セレクタ使用例: メッセージ・セレクタを使用してMQキューからメッセージを選択的に受信する1つのBPELプロセス

この例では、MQ Seriesアダプタを使用してMQ Seriesキューからメッセージを選択的にデキューする方法を示します。たとえば、次の条件をすべて満たすメッセージのみをデキューするとします。

- 414D51206C6F63616C5F716Dで始まるメッセージID

- 優先度 > 4

- メッセージ・タイプが2以外

- 返信先キュー名がqueue12またはqueue49のいずれか
この条件セット用のメッセージ・セレクタ(各条件セットがメッセージ・セレクタ・テキストに一致する)の作成に役立つ分析については、表10-8 を参照してください。

表10-8 1つのBPELプロセス使用例のメッセージ・セレクタ表

条件

メッセージ・セレクタ・テキスト

414D51206C6F63616C5F716Dで始まるメッセージID

jca.mq.MQMD.MsgId LIKE '414D51206C6F63616C5F716D%'

優先度 > 4

jca.mq.MQMD.Priority > 4

メッセージ・タイプが2以外

NOT (jca.mq.MQMD.MsgType = 2)

返信先キュー名はqueue12またはqueueu49

jca.mq.MQMD.ReplyToQ IN ('queue12', 'queue49')

したがって、MQ Seriesアダプタ構成ウィザードに完全なメッセージ文字列を入力すると、メッセージを取得画面は次のようになります。

jca.mq.MQMD.MsgId LIKE '414D51206C6F63616C5F716D%'
AND jca.mq.MQMD.Priority >
AND NOT (jca.mq.MQMD.MsgType = 2)
AND jca.mq.MQMD.ReplyToQ IN ('queue12', 'queue49')

このため、ウィザードにより作成されるInboundAdapter.jca JCAファイルには、次のタグ内のメッセージ・セレクタを<activation-spec>タグの子として示すために、次が含まれます。

<property name="MessageSelector" value=
" jca.mq.MQMD.MsgId LIKE '414D51206C6F63616C5F716D%'
AND jca.mq.MQMD.Priority > 4 AND NOT
(jca.mq.MQMD.MsgType = 2) AND jca.mq.MQMD.ReplyToQ
IN ('queue12', 'queue49')"/>

10.5.4.2.10 サンプル・メッセージでの使用方法

メッセージ・セレクタを使用して構成されたMQアダプタは、定義されているメッセージ・セレクタに一致するメッセージのみをデキューします。いくつかの例では、デキューするメッセージとデキューしないメッセージを明確にすることができます。

表10-9 に、メッセージ番号とメッセージID別にサンプル・メッセージをリストします。

表10-9 1つのBPELプロセス使用例に使用されるサンプル・メッセージ

メッセージ番号

メッセージID

メッセージ1

414D51206C6F63616C5F716D2020202023595B4D20002802

メッセージ2

414D51206C6F63616C5F716D2020202023595B4D20002D04

メッセージ3

414D51268A6C63618C5D516D2020202023595B4D20002A0D

表10-10 に、サンプル・メッセージ・セットに対してメッセージ・セレクタを使用した結果をリストします。

表10-10 サンプル・メッセージに対してメッセージ・セレクタを使用した結果

メッセージ・プロパティ

メッセージ1

メッセージ2

メッセージ3

優先度

6

6

9

メッセージ・タイプ

8

2

8

返信先キュー名

queue12

queue49

queue12

メッセージがデキューされる

はい

いいえ

いいえ

コメント

完全なメッセージ・セレクタはtrueを返すため、メッセージがデキューされます。

10.5.4.2.11 同じMQキューからメッセージを受信する2つのBPELプロセス。両方のプロセスに相互排他メッセージ・セレクタが定義されている

2つのBPELプロセス(BPEL 1およびBPEL 2)があり、両方とも同じMQキューからMQメッセージを受信するように構成されています。各BPELプロセスがそのプロセスのみに向けたメッセージを確実に受信するように、インバウンドMQアダプタをこれら両方のアダプタに構成する必要があります。

第1のプロセスであるBPEL 1では、次の条件を満たすメッセージのみを受信するようにします。

- 414D51206C6F63616C5F716D20202020で始まる相関ID

- メッセージ・タイプは2

BPEL 2では、次の条件を満たすメッセージのみを受信するようにします。

- 414D5120514D5F616E6B7072616B615Fで始まる相関ID

- メッセージ・タイプは2

- 優先度 > 5

10.5.4.2.12 2つのBPELプロセス使用例のメッセージ・セレクタの作成

第1のプロセスであるBPEL 1では、MessageSelector文字列は次のようになります。

jca.mq.MQMD.CorrelId LIKE
'414D51206C6F63616C5F716D20202020%'
AND jca.mq.MQMD.MsgType = 2

第2のプロセスであるBPEL 2では、MessageSelector文字列は次のようになります。

jca.mq.MQMD.CorrelId LIKE
'414D5120514D5F616E6B7072616B615F%' AND jca.mq.MQMD.MsgType
= 2 AND jca.mq.MQMD.Priority > 5

次の手順は、インバウンド・アダプタを構成することです。BPELプロセスの各インバウンドMQアダプタそれぞれにこれを行うには、「MQからメッセージを取得」画面で各アダプタのメッセージ・セレクタを指定します。

MQ Seriesアダプタ・ウィザードでは、「メッセージ・セレクタ」フィールドへの入力内容に基づいて次が実行されます。

BPEL 1では、ウィザードにより、<activation-spec>タグの子として次のタグが追加されます。

<property name="MessageSelector" value="
jca.mq.MQMD.CorrelId LIKE
'414D51206C6F63616C5F716D20202020%'
AND jca.mq.MQMD.MsgType = 2"/>

BPEL 2では、ウィザードにより、<activation-spec>タグの子として次のタグが追加されます。

<property name="MessageSelector" value="        jca.mq.MQMD.CorrelId LIKE           '414D5120514D5F616E6B7072616B615F %            ' AND jca.mq.MQMD.MsgType = 2               AND jca.mq.MQMD.Priority > 5"/>

10.5.4.2.13 2つのBPELプロセス使用例でのサンプル・メッセージの使用方法

両方のBPELプロセスが同じキューでメッセージを同時にリスニングするようにデプロイされている場合、メッセージは各プロセスにより選択的に受信されます。

両方のプロセスは、それぞれに向けられたメッセージのみを受信し、メッセージがBPELプロセスのいずれかの条件を満たさない場合、そのメッセージはキューに残ります。表10-11 に、使用されるサンプル・メッセージをリストし、表10-12 に、特定のサンプル・メッセージに関する結果をリストします。

表10-11 2つのBPELプロセス使用例に使用されるサンプル・メッセージ

メッセージ番号

メッセージID

メッセージ1

414D51206C6F63616C5F716D2020202023595B4D20004B06

メッセージ2

414D5120514D5F616E6B7072616B615F1E4B5A4D20094202

メッセージ3

414D5120514D325F616E6B7072616B61FD4A5A4D2006BE04

表10-12 2つのBPELプロセス使用例のサンプル・メッセージに対してメッセージ・セレクタを使用した結果

メッセージ・プロパティ

メッセージ1

メッセージ2

メッセージ3

優先度

1

5

8

メッセージ・タイプ

2

2

2

メッセージの移動先

BPEL1

BPEL2

キューに残る

コメント

相関IDがいずれのBPELプロセスのpattern-valueとも一致しませんでした。

10.6 使用例

この項では、次の項目について説明します。

- デキュー/エンキュー

- インバウンド同期リクエスト-リプライ

- インバウンド/アウトバウンド同期リクエスト-リプライ

- 非同期リクエスト-リプライ

- アウトバウンド・デキュー

- バックアウト・キューの構成

- CCDTのユース・ケース

- 単一または複数のRFH2ルールの読取りおよびヘッダー・バージョン2ヘッダーの書式設定

10.6.1 デキュー/エンキュー

この使用例では、MQアダプタでメッセージをデキューし、MQ Seriesキューからトランスフォーメーション後の同じメッセージをエンキューするエンドツーエンドの方法について説明します。この項では、次の項目について説明します。

- 前提条件

- SOAコンポジットの設計

- インバウンド・アダプタ・サービスの作成

- アウトバウンド・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

10.6.1.1 前提条件

デキュー/エンキューの使用例を実行するには、Adapters-101MQAdapterDequeueEnqueueサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/address-csv.xsd

- artifacts/schemas/address-fixedLength.xsd

- artifacts/input/data.txt

Adapters-101MQAdapterDequeueEnqueueサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

次のキューも作成する必要があります。

- test_in

- test_out

10.6.1.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックして「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。

4. 図10-43 に示すように、「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにDe-queueEn-queueと入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

図10-43 「アプリケーションの名前付け」ページ

5. 図10-44 に示すように、「プロジェクト名」フィールドにDe-queueEn-queueCompositeと入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。

図10-44 「プロジェクトの名前付け」ページ

6. 「次」を選択します。「SOA設定の構成」画面が表示されます。

7. 図10-45 に示すように、「コンポジット・テンプレート」リストで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

図10-45 「SOA設定の構成」ページ

8. 図10-46 に示すように、「名前」フィールドにBPELdequeueenqueueと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

図10-46 「BPELプロセスの作成」ダイアログ

9. 「OK」をクリックします。図10-47 に示すように、De-queueEn-queueアプリケーションとDe-queueEn-queueプロジェクトが設計領域に表示されます。

図10-47 JDeveloper - composite.xml

10. address-csv.xsdファイルおよびaddress-fixedLength.xsdファイルをプロジェクトのxsdフォルダにコピーします(これらのファイルの場所は、「前提条件」を参照)。

10.6.1.3 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 図10-48 に示すように、「サービス名」フィールドにInboundServiceと入力して「OK」をクリックします。「接続」画面が表示されます。

図10-48 「サービス名」ページ

4. 図10-49に示すように、接続のデフォルトのJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

図10-49 「MQ Series接続」ページ

5. 図10-50 に示すように、「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

図10-50 「アダプタ・インタフェース」ページ

6. 図10-51 に示すように、「MQからメッセージを取得」を選択して「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。

図10-51 「操作タイプ」ページ

7. 図10-52 に示すように、「キュー名」フィールドにtest_inと入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

図10-52 「MQからメッセージを取得」ページ

8. 「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

9. 図10-53 に示すように、「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番にクリックします。

図10-53 「タイプ・チューザ」ダイアログ

10. 「OK」をクリックします。図10-54 に示すように、「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが表示されます。

図10-54 「メッセージ」ページ

11. 「次」を選択します。「終了」ページが表示されます。

12. 「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-55に示すように、「composite.xml」 ページが表示されます。

図10-55 JDeveloperページ - 「composite.xml」ページ

10.6.1.4 アウトバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをエンキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにOutboundServiceと入力して「OK」をクリックします。「接続」ページが表示されます。

4. 図10-49に示すように、接続のデフォルトのJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 図10-50 に示すように、「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQにメッセージを蓄積」を選択して「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。

7. 「キュー名」フィールドにtest_outと入力して「次へ」をクリックします。図10-56 に示すように、「詳細オプション」ページが表示されます。

図10-56 「詳細オプション」ページ

8. デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-fixedLength.xsdファイルが表示されます。

11. 「次」を選択します。「終了」ページが表示されます。

12. 「終了」をクリックします。アウトバウンド・アダプタ・サービスの構成が完了し、図10-57に示すように、composite.xml ページが表示されます。

図10-57 JDeveloperページ - 「composite.xml」ページ

10.6.1.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるInboundService内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図10-58 のように表示されます。

図10-58 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4. 「BPELdequeueenqueue」をダブルクリックします。「BPELdequeueenqueue.bpel」ページが表示されます。

5. 「コンポーネント」ウィンドウから、receive、transformおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。

図10-59 に示すように、JDeveloperの「BPELdequeueenqueue.bpel」ページが表示されます。

図10-59 「BPELdequeueenqueue.bpel」ページ

6. receiveアクティビティをInboundServiceにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。

7. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトを受け入れて「OK」をクリックします。

9. 「インスタンスの作成」ボックスを選択して「OK」をクリックします。

10. invokeアクティビティをOutboundServiceにドラッグ・アンド・ドロップします。Invokeダイアログが表示されます。

11. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。

12. デフォルトを受け入れて「OK」をクリックします。Invokeダイアログが表示されます。

13. 「OK」をクリックします。

14. transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。

15. 「作成... (Alt + N)」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

16. デフォルトを受け入れて「OK」をクリックします。

17. ターゲットとしてinvoke変数を選択して「OK」をクリックします。「Transformation_xsl」ページが表示されます。

18. 「ソース」ペインのtns:Root-Elementを「ターゲット」ペインのfix:Root-Elementにドラッグ・アンド・ドロップします。「自動マップ・プリファレンス」ダイアログが表示されます。

19. 「OK」をクリックします。図10-60 に示すように、「Transformation_xsl」ページが表示されます。

図10-60 「Transformation_xsl」ページ

図10-61 に示す「BPELdequeueenqueue.bpel」ページが表示されます。

図10-61 「BPELdequeueenqueue.bpel」ページ

10.6.1.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

10.6.1.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。Fusion Middleware Controlページが表示されます。

2. 左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。

3. 「De-queueEn-queueComposite[1.0]」をクリックします。「De-queueEn-queueComposite[1.0]」ページが表示されます。

4. data.txtファイルをコピーしてtest_inキューに入れます。

5. 少し待ってからFusion Middleware Controlコンソールをリフレッシュします。インスタンスがコンソールに表示されます。これは、発生した処理のためトリガーされたインスタンスです。

6. 「インスタンス」タブをクリックします。

7. このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。

8. 「BPELdequeueenqueue」コンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。

9. 「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。

10. アクティビティをクリックして関連するペイロードの詳細を表示します。

10.6.2 インバウンド同期リクエスト-リプライ

この使用例では、インバウンドのOracle MQ SeriesアダプタがMQ Seriesのインバウンド・キューtest_inからリクエスト・メッセージをデキューして、BPELプロセスにパブリッシュします。Oracle MQ Seriesアダプタは、BPELプロセスからのレスポンスを待機します。レスポンスを受信すると、Oracle MQ Seriesアダプタはリクエスト・メッセージのreplyToQueueNameキューで指定されたMQ Seriesキューにレスポンス・メッセージをエンキューします。この使用例は、次の項で構成されています。

- 前提条件

- SOAコンポジットの設計

- インバウンド・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

10.6.2.1 前提条件

この例は、基本的なBPELコンストラクト(アクティビティやパートナ・リンクなど)と、BPELプロセスを作成およびデプロイするJDeveloper環境をよく理解していることを前提としています。

「Oracle MQ Seriesアダプタの構成」の指定に従ってOracle MQ Seriesアダプタを構成し、キューtest_inを作成する必要があります。

インバウンド同期リクエスト-リプライの使用例を実行するには、Adapters-101MQAdapterDequeueEnqueueサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/address-csv.xsd

- artifacts/schemas/address-fixedLength.xsd

- artifacts/input/data.txt

Adapters-101MQAdapterDequeueEnqueueサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

次のキューも作成する必要があります。

- test_in

- test_reply

10.6.2.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックして「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにSyncReqResと入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

5. 「プロジェクト名」フィールドにSync_ReqResと入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。

6. 「次」を選択します。「SOA設定の構成」画面が表示されます。

7. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

JDeveloperのアプリケーション・ナビゲータに新しいアプリケーションとプロジェクトが反映され、「設計」タブに空白のパレットが表示されます。

8. 「名前」フィールドにBPELsyncreqresと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

9. 「OK」をクリックします。図10-62 に示すように、SyncReqResアプリケーションとSync_ReqResプロジェクトが設計領域に表示されます。

図10-62 JDeveloper - composite.xml

10.6.2.3 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにinbound_reqresと入力して「次へ」をクリックします。「接続」ページが表示されます。

4. 接続JNDI名のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 図10-18 に示すように、「MQからメッセージを取得し、リプライ/レポートを送信」を選択し、「同期」を選択して「次へ」をクリックします。「MQからメッセージを取得し、リプライ/レポートを送信」ページが表示されます。

7. 「メッセージ・タイプ」ボックスで「標準」を選択し、「キュー名」フィールドにtest_inと入力します。

8. 「次」を選択します。「レスポンス」ページが表示されます。

9. デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが表示されます。

11. 「メッセージ・スキーマの送信」グループで、「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-fixedLength.xsdファイルが表示されます。

13. 「次」を選択します。「終了」ページが表示されます。

14. 「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-63に示すように、「composite.xml」 ページが表示されます。

図10-63 JDeveloperページ - 「composite.xml」ページ

15. 「ファイル」、「すべて保存」を順番にクリックします。

10.6.2.4 サービスとアクティビティのワイヤリング

コンポーネントを接続する手順は、次のとおりです。

1. inbound_reqresアダプタ・サービスをBPELsyncreqres BPELプロセスにドラッグ・アンド・ドロップします。

2. 「BPELsyncreqres」をダブルクリックします。「BPELsyncreqres.bpel」ページが表示されます。

3. 「コンポーネント」ウィンドウから、receive、transformおよびreplyアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。

4. receiveアクティビティをinbound_reqresアダプタ・サービスにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。

5. 「名前」フィールドにReadMsgと入力します。

6. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトを受け入れて「OK」をクリックします。

8. 「Receive」ダイアログで、「インスタンスの作成」ボックスを選択して「OK」をクリックします。

9. replyアクティビティをinbound_reqresアダプタ・サービスにドラッグ・アンド・ドロップします。「Reply」ダイアログが表示されます。

10. 「名前」フィールドにReplyMsgと入力します。

11. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

12. デフォルトを受け入れて「OK」をクリックします。この変数が「Reply」ダイアログに表示されます。

13. 「OK」をクリックします。

14. transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。

15. 「+」アイコンをクリックします。「ソース変数」ダイアログが表示されます。

16. 「ソース変数」リストで、「ReadMsg_DequeueEnqueue_InputVariable」を選択して「OK」をクリックします。

17. 「ターゲット変数」リストで「ReplyMsg_DequeueEnqueue_OutputVariable」を選択します。

18. 「マッピングの作成」アイコンをクリックします。図10-64 に示すように、「Transformation.xsl」ページが表示されます。

図10-64 「Transformation.xsl」ページ

19. 「<sources>」パネルから、「tns:Root-Element」を「<target>」パネルの「fix:Root-Element」にドラッグします。「自動マップ・プリファレンス」ダイアログが表示されます。

20. 「OK」をクリックします。図10-65 に示すように、JDeveloperの「BPELsyncreqres.bpel」 ページが表示されます。

図10-65 「BPELsyncreqres.bpel」ページ

10.6.2.5 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

10.6.2.6 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。Fusion Middleware Controlページが表示されます。

2. 左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。

3. 「Sync_ReqRes[1.0]」をクリックします。「Sync_ReqRes[1.0]」ページが表示されます。

4. data.txtファイルのコンテンツでMQメッセージを作成し、replyToQueueNameをtest_replyに設定します。このメッセージをtest_inキューに蓄積します。

5. 少し待ってからFusion Middleware Controlコンソールをリフレッシュします。インスタンスがコンソールに表示されます。これは、発生した処理のためトリガーされたインスタンスです。

6. 「インスタンス」タブをクリックします。

7. このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。

8. 「BPELsyncreqres」コンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。

9. 「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。

10. アクティビティをクリックして関連するペイロードの詳細を表示します。

10.6.3 インバウンド/アウトバウンド同期リクエスト-リプライ

この使用例では、MQアダプタの同期-請求-リクエスト-リプライのエンドツーエンドのシナリオについて説明します。この使用例では、コンポジットによりインバウンド・キューからメッセージがデキューされます。次に、リプライ・メッセージがインバウンド・メッセージで指定されたreplyToQueueキューにエンキューされます。この項では、次の項目について説明します。

- 前提条件

- SOAコンポジットの設計

- インバウンド・アダプタ・サービスの作成

- アウトバウンド・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

10.6.3.1 前提条件

インバウンド同期リクエスト-リプライの使用例を実行するには、Adapters-101MQAdapterDequeueEnqueueサンプルに含まれているartifacts.zipファイルの次のファイルが必要です。

- artifacts/schemas/address-csv.xsd

- artifacts/schemas/address-fixedLength.xsd

次の名前のキューも作成する必要があります。

- test_in

- test1

- ReplyQ

- test_reply

Adapters-101MQAdapterDequeueEnqueueサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

10.6.3.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックして「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにSync-Req-Repと入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

5. 「プロジェクト名」フィールドにSync-Req-RepCompositeと入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。

6. 「次」を選択します。「SOA設定の構成」画面が表示されます。

7. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

8. 「名前」フィールドにBPELSyncreqrepと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

9. 「OK」をクリックします。図10-66 に示すように、Sync-Req-RepアプリケーションとSync-Req-RepCompositeプロジェクトが設計領域に表示されます。

図10-66 JDeveloper - composite.xml

10.6.3.3 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにInboundReqRepServiceと入力して「次へ」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 図10-18 に示すように、「MQからメッセージを取得し、リプライ/レポートを送信」を選択し、「操作名」ボックスで「同期」を選択して「次へ」をクリックします。「MQからメッセージを取得し、リプライ/レポートを送信」ページが表示されます。

7. 「メッセージ・タイプ」リストで「標準」を選択し、「キュー名」フィールドにtest_inと入力し、「スキーマ・オプション」ボックスで「他のスキーマを選択します」を選択して「次へ」をクリックします。「レスポンス」ページが表示されます。

8. デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

9. 「メッセージ・スキーマの取得」ボックスで、「URL」フィールドの端に表示される「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「メッセージ・スキーマの取得」ボックスにaddress-csv.xsdファイルが移入されます。

11. 「メッセージ・スキーマの送信」ボックスで、「URL」フィールドの端に表示される「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「メッセージ・スキーマの送信」ボックスにaddress-fixedLength.xsdファイルが移入されます。

13. 「次」を選択します。「終了」ページが表示されます。

14. 「終了」をクリックします。InboundReqRepServiceアダプタ・サービスの構成が完了し、図10-67 に示すように、「composite.xml」ページが表示されます。

図10-67 JDeveloperページ - 「composite.xml」ページ

10.6.3.4 アウトバウンド・アダプタ・サービスの作成

リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにOutboundReqRepServiceと入力して「OK」をクリックします。「接続」ページが表示されます。

4. デフォルトを受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQにメッセージを送信し、リプライ/レポートを取得」を選択し、「操作名」ボックスで「同期」を選択して「次へ」をクリックします。「MQにメッセージを送信し、リプライ/レポートを取得」ページが表示されます。

7. 「キュー名」フィールドにtest1と入力して「次へ」をクリックします。「レスポンス」ページが表示されます。

8. 「返信先キュー名」フィールドにキュー名(ReplyQなど)を入力し、「レスポンス待機間隔」オプションを選択して値を入力し、「空のレスポンス・メッセージを許可」オプションを選択します。

9. 「次」を選択します。「詳細オプション」ページが表示されます。

10. デフォルトの値を受け入れ、「次へ」をクリックします。「メッセージ」ページが表示されます。

11. 「メッセージ・スキーマの取得」ボックスで、「URL」フィールドの端に表示される「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「メッセージ・スキーマの取得」ボックスにaddress-csv.xsdファイルが移入されます。

13. 「メッセージ・スキーマの送信」ボックスで、「URL」フィールドの端に表示される「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

14. 「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「メッセージ・スキーマの送信」ボックスにaddress-fixedLength.xsdファイルが移入されます。

15. 「次」を選択します。「終了」ページが表示されます。

16. 「終了」をクリックします。OutboundReqRepServiceサービスの構成が完了し、図10-68 に示すように、「composite.xml」ページが表示されます。

図10-68 JDeveloperページ - 「composite.xml」ページ

10.6.3.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(InboundReqRepService、BPELSyncreqrepおよびOutboundReqRepService)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるInboundReqRepServiceサービス内の小さい三角形を、「コンポーネント」領域のBPELSyncreqrep内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELSyncreqrep内の小さい三角形を、「外部参照」領域のOutboundReqRepService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

3. 同様に、「コンポーネント」領域にあるBPELSyncreqrep内の小さい三角形を、「外部参照」領域のOutboundReqRepService内のドロップ・ゾーンにドラッグします。

JDeveloperの「composite.xml」ページが図10-69 のように表示されます。

図10-69 JDeveloper - composite.xml

4. 「ファイル」、「すべて保存」を順番にクリックします。

5. 「BPELSyncreqrep」をダブルクリックします。「BPELSyncreqrep.bpel」ページが表示されます。

6. 「コンポーネント」ウィンドウから、receive、transform、invoke、assignおよびreplyアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。図10-70 に示すように、JDeveloperの「BPELSyncreqrep.bpel」ページが表示されます。

図10-70 「BPELSyncreqrep.bpel」ページ

7. receiveアクティビティをInboundReqRepServiceにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。

8. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

9. デフォルトを受け入れて「OK」をクリックします。

10. 図10-71 に示すように、「インスタンスの作成」ボックスを選択して「OK」をクリックします。

図10-71 「Receive」ダイアログ

11. replyアクティビティをInboundReqRepServiceにドラッグ・アンド・ドロップします。「Reply」ダイアログが表示されます。

12. 「変数の自動作成」アイコンをクリックして変数を作成し、「OK」をクリックします。図10-72 に示すように、「Reply」ダイアログが表示されます。

図10-72 「Reply」ダイアログ

13. invokeアクティビティをOutboundReqRepServiceサービスにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。

14. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

15. 「OK」をクリックします。

16. 同様に、出力変数を作成します。デフォルトを受け入れて「OK」をクリックします。図10-73 に示すように、Invokeダイアログが表示されます。

図10-73 「起動」ダイアログ

17. 「OK」をクリックします。

18. transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。

19. 「+」アイコンをクリックし、ソース変数として「Receive_1_DequeueEnqueue_InputVariable」を選択します。また、図10-74に示すように、ターゲット変数としてInvoke_1_EnqueueDequeue_InputVariable を選択します。

図10-74 「Transform」ダイアログ

20. 「マッピングの作成」をクリックします。「Transformation_1.xsl」ページが表示されます。

21. 「<sources>」パネルから、「tns:Root-Element」を「<target>」パネルの「fix:Root-Element」にドラッグ・アンド・ドロップします。「自動マップ・プリファレンス」ダイアログが表示されます。

22. 「OK」をクリックします。図10-75 に示すように、「Transformation.xsl」ページにマッピングが表示されます。

図10-75 マッピングを示す「Transformation.xsl」ページ

23. 「BPELSyncreqrep.bpel」タブをクリックします。

24. assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。

25. 「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

26. 図10-76 に示すように、変数を選択して「OK」をクリックします。

図10-76 「コピー操作の作成」ダイアログ

27. 「Assign」ダイアログで「OK」をクリックします。図10-77 に示すように、JDeveloperの「BPELSyncreqrep.bpel」ページが表示されます。

図10-77 「BPELSyncreqrep.bpel」ページ

10.6.3.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

10.6.3.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。Oracle Fusion Middleware Controlページが表示されます。

2. 左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。

3. 「Sync-Req-RepComposite[1.0]」をクリックします。「Sync-Req-RepComposite[1.0]」ページが表示されます。

4. data.txtファイルのコンテンツでMQメッセージを作成し、replyToQueueNameをtest_replyに設定します。このメッセージをtest_inキューに蓄積します。

5. 少し待ってからFusion Middleware Controlコンソールをリフレッシュします。インスタンスがコンソールに表示されます。これは、発生した処理のためトリガーされたインスタンスです。

6. 「インスタンス」タブをクリックします。

7. このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。

8. 「BPELSyncreqrep」コンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。

9. 「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。

10. アクティビティをクリックして関連するペイロードの詳細を表示します。

10.6.4 非同期リクエスト-リプライ

この使用例では、非同期リクエスト-リプライのエンドツーエンドのシナリオについて説明します。この使用例では、最初にコンポジットによりインバウンド・キューからメッセージがデキューされます。次に、リクエスト・メッセージがエンキューされ、リプライ・メッセージがデキューされます。最後に、コンポジットによりリプライ・メッセージが他のキューにエンキューされます。この項では、次の項目について説明します。

- 前提条件

- SOAコンポジットの設計

- インバウンド・アダプタ・サービスの作成

- 非同期アウトバウンド・リクエスト-リプライ・アダプタ・サービス・アウトバウンドの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

10.6.4.1 前提条件

「Oracle MQ Seriesアダプタの構成」の指定に従ってOracle MQ Seriesアダプタを構成し、キューtest_in、test_outおよびtest_demoを作成する必要があります。

10.6.4.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックして「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにAsynchronousRequestReplyと入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

5. 「プロジェクト名」フィールドにAsync-Req-RepCompositeと入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。

6. 「次」を選択します。「SOA設定の構成」画面が表示されます。

7. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

8. 「名前」フィールドにBPELAsyncreqrepと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

9. 「OK」をクリックします。図10-78 に示すように、AsynchronousRequestReplyアプリケーションとAsync-Req-RepCompositeプロジェクトが設計領域に表示されます。

図10-78 JDeveloper - composite.xml

10.6.4.3 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにInboundServiceと入力して「次へ」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQからメッセージを取得」を選択して「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。

7. 「キュー名」フィールドにtest_inと入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

8. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。

9. 「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-79 に示すように、「composite.xml」ページが表示されます。

図10-79 JDeveloperページ - 「composite.xml」ページ

10.6.4.4 非同期アウトバウンド・リクエスト-リプライ・アダプタ・サービス・アウトバウンドの作成

リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにasyn-Req-Resと入力して「OK」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQにメッセージを送信し、リプライ/レポートを取得」を選択し、「操作名」ボックスで「非同期」を選択して「次へ」をクリックします。「MQにメッセージを送信し、リプライ/レポートを取得」ページが表示されます。

7. 「メッセージ・タイプ」ボックスで「標準」を選択し、「キュー名」フィールドにtest_outと入力し、「レポートの取得」チェック・ボックスを選択して「次へ」をクリックします。「レポート」ページが表示されます。

8. 図10-80 に示すように、「着信時の確認」を選択して「次へ」をクリックします。「レスポンス」ページが表示されます。

図10-80 「アダプタ構成ウィザード - レポート」ページ

9. 「返信先キュー名」フィールドにtest_outと入力して「次へ」をクリックします。「詳細オプション」ページが表示されます。

10. デフォルト値を受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

11. 「メッセージ・スキーマの取得」ボックスと「メッセージ・スキーマの送信」ボックスで、「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」をそれぞれ選択して「次へ」をクリックします。「終了」ページが表示されます。

12. 「終了」をクリックします。async-Req-Resサービスの構成が完了し、図10-81 に示すように、「composite.xml」ページが表示されます。

図10-81 JDeveloperページ - 「composite.xml」ページ

10.6.4.5 もう1つのアウトバウンド・アダプタ・サービスの作成

次の手順を実行し、レスポンス(レポート)メッセージをエンキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにOutboundServiceと入力して「OK」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQにメッセージを蓄積」を選択して「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。

7. 「キュー名」フィールドにtest_demoと入力して「次へ」をクリックします。「詳細オプション」ページが表示されます。

8. デフォルト値を受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

9. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。

10. 「終了」をクリックします。OutboundServiceサービスの構成が完了し、図10-82 に示すように、「composite.xml」ページが表示されます。

図10-82 JDeveloperページ - 「composite.xml」ページ

10.6.4.6 サービスとアクティビティのワイヤリング

作成した4つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、async-Req-Resおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるInboundServiceサービス内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のasync-Req-Res内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

3. 同様に、「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundService内のドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図10-83 のように表示されます。

図10-83 JDeveloper - composite.xml

4. 「ファイル」、「すべて保存」を順番にクリックします。

5. 「BPELAsyncreqrep」をダブルクリックします。「DequeueEnqueueRFH2.bpel」ページが表示されます。

6. 「コンポーネント」ウィンドウから、receive、assign、invoke、receive、assignおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。図10-84 に示すように、JDeveloperの「BPELAsyncreqrep.bpel」ページが表示されます。

図10-84 「BPELAsyncreqrep.bpel」ページ

7. 1つ目のreceiveアクティビティをInboundServiceアダプタ・サービスにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。

8. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

9. デフォルトを受け入れて「OK」をクリックします。

10. 「インスタンスの作成」ボックスを選択して「OK」をクリックします。

11. 1つ目のinvokeアクティビティをasync-Req-Resサービスにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。

12. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。

13. デフォルトを受け入れて「OK」をクリックします。「Invoke」ダイアログが表示されます。

14. 「OK」をクリックします。

15. 2つ目のreceiveアクティビティをasync-Req-Repサービスにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。

16. 「変数の自動作成」アイコンをクリックして変数を作成します。

注意:

「インスタンスの作成」ボックスは選択しないでください。

17. 「Receive」ダイアログで「OK」をクリックします。

18. 2つ目のinvokeアクティビティをOutboundServiceにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。

19. 「入力変数の自動作成」アイコンをクリックして変数を作成します。

20. 「Invoke」ダイアログで「OK」をクリックします。

21. 1つ目のassignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。

22. 「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

23. 図10-85 に示すように、変数を選択して「OK」をクリックします。

図10-85 「コピー操作の作成」ダイアログ

24. 「Assign」ダイアログで「OK」をクリックします。

25. 2つ目のassignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。

26. 「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

27. 図10-86 に示すように、変数を選択して「OK」をクリックします。

図10-86 「コピー操作の作成」ダイアログ

28. 「Assign」ダイアログで「OK」をクリックします。図10-87 に示すように、JDeveloperの「BPELAsyncreqrep.bpel」ページが表示されます。

図10-87 「BPELAsyncreqrep.bpel」ページ

10.6.4.7 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

10.6.4.8 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。Oracle Fusion Middleware Controlページが表示されます。

2. 左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。

3. 「Async-Req-RepComposite[1.0]」をクリックします。「Async-Req-RepComposite[1.0]」ページが表示されます。

4. address-csv.xsdに準拠するコンテンツを含み、ヘッダーとしてReply Queueも含んでいるメッセージを、test_inキューに蓄積します。

5. 少し待ってからFusion Middleware Controlコンソールをリフレッシュします。インスタンスがコンソールに表示されます。これは、発生した処理のためトリガーされたインスタンスです。

6. 「インスタンス」タブをクリックします。

7. このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。

8. 「BPELAsyncreqrep」コンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。

9. 「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。

10. アクティビティをクリックして関連するペイロードの詳細を表示します。

10.6.5 アウトバウンド・デキュー

この使用例では、MQアダプタでメッセージを1度に1つデキューするエンドツーエンドの方法について説明します。この項では、次の項目について説明します。

- 前提条件

- SOAコンポジットの設計

- アウトバウンド・デキュー・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

10.6.5.1 前提条件

アウトバウンド・デキューの使用例を実行するには、Adapters-101MQAdapterDequeueEnqueueサンプルの次のファイルが必要です。

- De-queueEn-queue/De-queueEn-queueComposite/xsd/singleString.xsd

また、Adapters-101MQAdapterDequeueEnqueueサンプルに含まれているartifacts.zipファイルの次のファイルも必要です。

- artifacts/input/data.txt

Adapters-101MQAdapterDequeueEnqueueサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。

test_outという名前のキューも作成する必要があります。

10.6.5.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックして「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにOutboundDequeueと入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

5. 「プロジェクト名」フィールドにOutboundDequeueCompositeと入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。

6. 「次」を選択します。「SOA設定の構成」画面が表示されます。

7. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

8. 「名前」フィールドにBPELOutboundDequeueと入力し、「テンプレート」ボックスで「同期BPELプロセス」を選択します。

9. 「入力」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。

11. 「出力」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。

13. 「OK」をクリックします。図10-88 に示すように、OutboundDequeueアプリケーションとOutboundDequeueCompositeプロジェクトが設計領域に表示されます。

図10-88 JDeveloper - composite.xml

10.6.5.3 アウトバウンド・デキュー・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューにデキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにOutboundDequeueServiceと入力して「OK」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQからメッセージを取得」および「同期」を選択し、「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。

7. 「キュー名」フィールドにtest_outと入力し、「待機間隔」フィールドに10と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

8. 「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

9. 「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。「メッセージ」ページの「URL」フィールドにsingleString.xsdファイルが表示されます。

10. 「次」を選択します。「終了」ページが表示されます。

11. 「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-89に示すように、「composite.xml」 ページが表示されます。

図10-89 JDeveloperページ - 「composite.xml」ページ

12. 「ファイル」、「すべて保存」を順番にクリックします。

10.6.5.4 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(クライアント、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundDequeueService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「BPELOutboundDequeue」をダブルクリックします。「BPELOutboundDequeue.bpel」ページが表示されます。

3. 「コンポーネント」ウィンドウから、invokeおよびassignアクティビティを「コンポーネント」領域にあるreceiveInputアクティビティとreplyOutputアクティビティの間にこの順序でドラッグ・アンド・ドロップします。

図10-90 に示すように、「composite.xml」ページが表示されます。

図10-90 JDeveloper - 「composite.xml」ページ

図10-91 に示すように、JDeveloperの「BPELOutboundDequeue.bpel」ページが表示されます。

図10-91 「BPELOutboundDequeue.bpel」ページ

4. invokeアクティビティをOutboundDequeueServiceアダプタ参照にドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。

5. 「入力変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

6. デフォルトを受け入れて「OK」をクリックします。

7. 同じ手順を出力変数について繰り返し、「OK」をクリックします。

8. assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。

9. 「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

10. 図10-92 に示すように、変数を選択して「OK」をクリックします。

図10-92 「コピー操作の作成」ダイアログ

11. 「Assign」ダイアログで「OK」をクリックします。

図10-93 に示すように、「BPELOutboundDequeue.bpel」ページが表示されます。

図10-93 「BPELOutboundDequeue.bpel」ページ

10.6.5.5 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

10.6.5.6 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。

2. 左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。

3. 「OutboundDequeueComposite[1.0]」をクリックします。「OutboundDequeueComposite[1.0]」ページが表示されます。

4. 「テスト」ボタンをクリックします。「Webサービスのテスト」ページが表示されます。

5. 「リクエスト」タブをクリックし、「引数を入力」ペインにスクロールします。

6. 「入力」フィールドにTest Outbound Dequeueと入力し、「Webサービスのテスト」ボタンをクリックします。

7. 少し待ってから「レスポンス」タブをクリックします。指定したsingleString xsd内のメッセージが「レスポンス」タブに表示されます。

8. 「インスタンス」タブをクリックします。

9. このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。

10. 「BPELOutboundDequeue」コンポーネント・インスタンスをクリックします。図10-94 に示すように、「監査証跡」ページが表示されます。

図10-94 「監査証跡」ページ

11. 「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。

12. アクティビティをクリックして関連するペイロードの詳細を表示します。

10.6.6 バックアウト・キューの構成

この使用例では、Oracle MQ Seriesアダプタに対してバックアウト・キューを構成する方法について説明します。Oracle MQ Seriesアダプタはメッセージをデキューし、MQ Seriesキューからのトランスフォーメーション後に同じメッセージをエンキューします。このプロセスでは、invokeアクティビティ中またはレスポンスの送信時に失敗が発生する可能性があります。拒否されたメッセージを、デフォルトの拒否されたメッセージ・フォルダではなく、バックアウト・キューに送信するようにバックアウト・キューを構成する必要があります。この項では、次の項目について説明します。

- 前提条件

- SOAコンポジットの設計

- インバウンド・アダプタ・サービスの作成

- アウトバウンド・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

- Fusion Middleware Controlコンソールを使用した監視

10.6.6.1 前提条件

バックアウト・キューの構成の使用例を実行するには、アダプタJNDIがXA用に構成されている必要があります。また、singleString.xsdファイルが必要です。このファイルは、次のコードを使用して作成できます。

<schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com/singleString"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="singleString">
<complexType>
<sequence>
<element name="input" type="string"/>
</sequence>
</complexType>
</element>
</schema>

10.6.6.2 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックして「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにMQ_BackoutQ_Retryと入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

5. 「プロジェクト名」フィールドにSOA_BackoutQ_Retryと入力し、「選択可能」リストからSOAを選択して右矢印ボタンをクリックします。

6. 「次」を選択します。「SOA設定の構成」画面が表示されます。

7. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

8. 「名前」フィールドにBPELProcess_BackoutQ_Retryと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

9. 「OK」をクリックします。MQ_BackoutQ_RetryアプリケーションとSOA_BackoutQ_Retryプロジェクトが設計領域に表示されます。

10.6.6.3 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにInboundServiceと入力して「次へ」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQからメッセージを取得し、リプライ/レポートを送信」(同期)を選択して「次へ」をクリックします。「MQからメッセージを取得し、リプライ/レポートを送信」ページが表示されます。

7. 「キュー名」フィールドにINBOUND_QUEUEと入力して「次へ」をクリックします。「レスポンス」ページが表示されます。

8. デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択します。

11. 「OK」をクリックします。「メッセージ」ページの「URL」フィールドにsingleString.xsdファイルが表示されます。

12. 「次」を選択します。「終了」ページが表示されます。

13. 「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、インバウンド・アダプタが追加された「composite.xml」ページが表示されます。

14. 次の例に示すように、バックアウト・キュー・プロパティを対応するJCAファイル(ReqReply_mq.jca)に追加します。

<property name="BackoutQueueName" value="BACKOUT.QUEUE"/>
<property name="MaximumBackoutCount" value="5"/>
<property name="BackoutRetries" value="3"/>

10.6.6.4 アウトバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをエンキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにEQと入力して「次へ」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQにメッセージを蓄積」を選択して「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。

7. 「キュー名」フィールドにtest_outと入力して「次へ」をクリックします。「詳細オプション」ページが表示されます。

8. デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。「メッセージ」ページの「URL」フィールドにsingleString.xsdファイルが表示されます。

11. 「次」を選択します。「終了」ページが表示されます。

12. 「終了」をクリックします。アウトバウンド・アダプタ・サービスの構成が完了し、図10-95に示すように、composite.xml ページが表示されます。

図10-95 JDeveloperページ - 「composite.xml」ページ

10.6.6.5 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるInboundService内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図10-96 のように表示されます。

図10-96 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4. 「BPELProcess_BackoutQ_Retry」をダブルクリックします。「BPELProcess_backoutQ_Retry.bpel」ページが表示されます。

5. 「コンポーネント」ウィンドウから、receive、assign、invokeおよびreplyアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。

6. receiveアクティビティをReqReplyにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。

7. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトを受け入れて「OK」をクリックします。

9. 「インスタンスの作成」ボックスを選択して「OK」をクリックします。

10. replyアクティビティをReqReplyにドラッグ・アンド・ドロップします。「Reply」ダイアログが表示されます。

11. 「名前」フィールドにReplyOutputと入力します。

12. 「変数」フィールドの端に表示される「変数の参照」アイコンをクリックします。「変数チューザ」ダイアログが表示されます。

13. replyOutput_DequeueEnqueue_OutputVariableを選択し、「OK」をクリックします。この変数が「Reply」ダイアログに表示されます。

14. 「OK」をクリックします。

15. invokeアクティビティをEQにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。

16. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。

17. デフォルトを受け入れて「OK」をクリックします。「Invoke」ダイアログが表示されます。

18. 「OK」をクリックします。

19. assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。

20. 「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。

21. 「コピー操作の作成」ダイアログで、「タイプから」としてreceiveInput_DequeueEnqueue_InputVariableを選択し、コピー操作の作成先の「To」ペインで変数を選択します。

次に、コピー操作が定義されたBPELProcess_BackoutQ_Retry.bpelファイルのコード・スニペットを示します。

<assign name="Assign_1">
<copy>
<from variable="receiveInput_DequeueEnqueue_InputVariable"
part="singleString" query="/ns3:singleString/ns3:input"/>
<to variable="Invoke_1_Enqueue_InputVariable" part="body"
query="/ns3:singleString/ns3:input"/>
</copy>
<copy>
<from variable="receiveInput_DequeueEnqueue_InputVariable"
part="singleString" query="/ns3:singleString/ns3:input"/>
<to variable="replyOutput_DequeueEnqueue_OutputVariable"
part="singleString" query="/ns3:singleString/ns3:input"/>
</copy>
</assign>

22. 「OK」をクリックします。図10-97 に示す「BPELdequeueenqueue.bpel」ページが表示されます。

図10-97 「BPELProcess_BackoutQ_Retry.bpel」ページ

10.6.6.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

10.6.6.7 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

1. http://servername:portnumber/emにナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。

2. インバウンド・メッセージが出力されるtest_outキューまたはリプライ・キューを無効に(蓄積を抑制)し、メッセージをINBOUND_QUEUEに蓄積します。

3. 少し待ってからFusion Middleware Controlコンソールをリフレッシュします。処理のためトリガーされるインスタンスがコンソールに表示されます。

注意:

トリガーされるインスタンスの数は、BackoutRetries + 1と同じである必要があります。

4. 「インスタンス」タブをクリックします。

5. このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。

6. BPELProcess_BackoutQ_Retryコンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。

7. 「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。

8. アクティビティをクリックして関連するペイロードの詳細を表示します。

10.6.7 CCDTのユース・ケース

MQ Seriesアダプタは、接続の詳細にCCDTを使用するように構成できます。このCCDTを使用すると、キュー・マネージャのリストで使用可能な最初のキュー・マネージャに接続できます。

たとえば、このユース・ケースでは、後述の表に示すように、基本プロパティを持つQM1、QM2およびQM3の3つのキュー・マネージャがあります。

MQアダプタは、実行時に3つのキュー・マネージャのいずれにも動的に接続可能で、どれが使用可能であるかによって決定されます(たとえば、QM1が停止中の場合、MQアダプタはQM2に自動接続され、さらにQM2も停止中の場合は、QM3に接続される必要があります)。

10.6.7.1 キュー・マネージャのプロパティおよびCCDTの構成の例

キュー・マネージャのプロパティの例を次の表に示します。

キュー・マネージャ名

QM1

QM2

QM3

Hostname

localhost

localhost

10.177.255.25

PortName

1414

2414

1414

サーバー接続チャネル名

channel.QM1

channel.QM2

channel.QM3

これを実現するには、CCDTを次のように構成する必要があります。

チャネル名

キュー・マネージャ名

接続名

channel.QM1

MyQM_group

localhost(1414)

channel.QM2

MyQM_group

localhost(2414)

channel.QM3

MyQM_group

10.177.255.25(1414)

10.6.7.2 ConnectionFactory JNDIの構成

CCDTを作成した後、このCCDTを使用するように単一のConnectionFactory JNDIを構成する必要があります。そのJNDIで、次のConnectionFactoryプロパティを構成する必要があります。

- CCDTurl

- QueueManagerName

10.6.7.3 CCDTurlの構成

CCDTurlは、クライアント接続の詳細を指定するために、MQ Seriesアダプタで使用されるCCDTファイルのURLをポイントする必要があります。たとえば、指定される値は次のいずれかにできます。

- file:/scratch/username/ccdt/AMQCLCHL.TAB

- ftp://userName:password@myServer/definitionPath/AMQCLCHL.TAB

10.6.7.4 QueueManagerNameの構成

この使用例では、QueueManagerNameプロパティの値をMyQM_groupに設定する必要があります。

この名前は、MyQM_groupというキュー・マネージャ名を含むCCDTでクライアント定義エントリを所有する使用可能な最初のキュー・マネージャに対してMQ Seriesアダプタの接続が必要なことを示しています。

QueueManagerNameプロパティは、CCDTで定義されたキュー・マネージャ名と一致し、実際のキュー・マネージャ名とは一致しません。通常、QueueManagerNameには、次に示す考慮事項に従って適切な値が指定されます。

- QM_defaultなどの1つのキュー・マネージャ名のみを指定した場合は、指定された名前と正確に(大/小文字の区別も含めて)一致するキュー・マネージャ名を定義内に含むクライアント・チャネルにおいてCCDTがアルファベット順で検索されます。

- QM_defaultなどの指定されたキュー・マネージャ名の始めにアスタリスクが付加されている場合は、アスタリスクの有無にかかわらずキュー・マネージャ名と一致するエントリに対してCCDTがチャネル名のアルファベット順で検索されます。2つ以上のクライアント・チャネル定義にQM_defaultと定義されたキュー・マネージャ名がある場合は、使用可能な最初のキュー・マネージャに接続されます。

- CCDTにキュー・マネージャ名が指定されていない場合は、JNDI内のキュー・マネージャ名を"*"に指定する必要があります。

前述の2つのプロパティは、接続の詳細にCCDTを使用するようMQ Seriesアダプタに通知する場合にのみ必要な構成です。CCDTを使用しても、SSL、ExitsまたはXAのサポートなど、他のMQアダプタの機能に必要な構成には影響がありません。

Hostname、PortNumber、ChannelNameなどの他のConnectionFactoryプロパティを構成した上で、CCDTも構成する場合は、それらのプロパティよりもCCDTが優先されます。

これらのConnectionFactoryプロパティが設定され、いずれかのコンポジット・プロセスでこのJNDIが使用されると、MQアダプタは、QM1、QM2およびQM3のうち使用可能な最初のキュー・マネージャに接続されます。

10.6.8 単一または複数のRFH2ルールの読取りおよびヘッダー・バージョン2ヘッダーの書式設定

単一または複数のRFH2ヘッダーを含むMQメッセージのデキューと読取りに加えて、複数のRFH2ヘッダーを持つメッセージをエンキューすることもできます。この機能には、次の機能が含まれます。

- RFH2ヘッダーの固定部分でのプロパティの読取りおよび書込み

- 任意のRFH2ヘッダー内の任意の個別フォルダが複数回出現した場合の読取りおよび書込み

- 単一メッセージでRFH2ヘッダーが複数回出現した場合の読取りおよび書込み

RFH2ヘッダーにより、メッセージ・プロデューサは、ペイロードにより多くのヘッダー・プロパティを追加して他の追加情報を提供できるようになります。

ヘッダー・プロパティとしてこの情報を読み取り、書き込む機能をMQアダプタに提供することで、RFH2ヘッダー・プロパティに依存するメッセージ・ペイロードの特定の処理を実行できます。

次のユース・ケースでは、2つのタイプのシナリオ例を示します。

- 両側の複数のRFH2ヘッダーを含むインバウンドおよびアウトバウンド

- 複数のRFH2ヘッダーを含むアウトバウンド・デキュー

10.6.8.1 両側の複数のRFH2ヘッダーを含むインバウンドおよびアウトバウンド

この例は、1つまたは複数のRFH2ヘッダーを含むMQメッセージを処理するためのMQアダプタの使用方法を示しています。

2つのRFH2ヘッダーを含むMQメッセージは、キューおよび同じペイロードを含む新しいメッセージからデキューされますが、更新済のRFH2ヘッダーは別のキューにエンキューされます。

このユース・ケースの例を作成する手順は次のとおりです。

- SOAコンポジットの設計

- インバウンド・アダプタ・サービスの作成

- アウトバウンド・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

10.6.8.1.1 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックして「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにDequeueEnqueueRFH2と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

5. 「プロジェクト名」フィールドにDequeueEnqueueRFH2と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。

6. 「次」を選択します。「SOA設定の構成」画面が表示されます。

7. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

8. 「名前」フィールドにDequeueEnqueueRFH2と入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

9. 「OK」をクリックします。DequeueEnqueueRFH2アプリケーションとDequeueEnqueueRFH2プロジェクトが設計領域に表示されます。

10.6.8.1.2 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをデキューし、キューに蓄積するアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにInboundMQと入力して「次へ」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQからメッセージを取得」を選択し(「同期」は選択しません)、「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。

7. 「キュー名」フィールドにqueue1と入力し、「他のスキーマを選択します」を選択して「次へ」をクリックします。「メッセージ」ページが表示されます。

8. ネイティブ・フォーマットは不要(スキーマを不透明(Opaque)にする)を選択し、「次へ」をクリックします。「終了」ページが表示されます。

9. 「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、インバウンド・アダプタが追加された「composite.xml」ページが表示されます。

10.6.8.1.3 アウトバウンド・アダプタ・サービスの作成

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにOutboundMQと入力して「次へ」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQにメッセージを蓄積」を選択します。「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。

7. 「キュー名」フィールドにqueue2と入力します。「次へ」をクリックします。「詳細オプション」ページが表示されます。

8. デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

9. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。

10. 「終了」をクリックします。アウトバウンド・アダプタ・サービスの構成が完了し、図10-95 に示すように、composite.xmlページが表示されます。

図10-98 JDeveloperページ - 「composite.xml」ページ

10.6.8.1.4 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるInboundMQ内の小さい三角形を、「コンポーネント」領域のDequeueEnqueueRFH2内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるDequeuEnqueueRFH2内の小さい三角形を、「外部参照」領域のOutboundMQ内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
図10-90 に示すように、「composite.xml」ページが表示されます。

図10-99 JDeveloper - 「composite.xml」ページ

3. 「ファイル」、「すべて保存」を順番にクリックします。

4. 「DequeueEnqueueRFH2」をダブルクリックします。「DequeueEnqueueRFH2.bpel」ページが表示されます。

5. 「コンポーネント」ウィンドウから、receive、assignおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。JDeveloperの「DequeueEnqueueRFH2.bpel」ページが表示されます。

図10-100 「DequeueEnqueueRFH2.bpel」ページ

6. receiveアクティビティをインバウンド・サービスにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。

7. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトを受け入れて「OK」をクリックします。

9. 「インスタンスの作成」ボックスをクリックし、「OK」をクリックします。

10. invokeアクティビティをアウトバウンド・サービスにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。

11. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。

12. デフォルトを受け入れて「OK」をクリックします。Invokeダイアログが表示されます。

13. 「OK」をクリックします。

14. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

15. 変数を選択して、「プラス」アイコンをクリックします。

図10-101 アクティビティの割当てダイアログ

16. Assignダイアログで「OK」をクリックします。JDeveloperの「DequeueEnqueueRFH2.bpel.html」が表示されます。

図10-102 「DequeueEnqueueRFH2.bpel」ページ

17. RFH2のヘッダー部分を格納する一時変数を作成します。

a. 「DequeueEnqueueRFH2.bpel」ページの「ソース」タブを開きます。

b. <variables>タブの下に、次の新規変数を追加します。

<variable name="RFH2.StructId" type="xsd:string"/>
<variable name="RFH2.Version" type="xsd:string"/>
<variable name="RFH2.Encoding" type="xsd:string"/>
<variable name="RFH2.CodedCharSetId" type="xsd:string"/>
<variable name="RFH2.Format" type="xsd:string"/>
<variable name="RFH2.Flags" type="xsd:string"/>
<variable name="RFH2.NameValueCCSID" type="xsd:string"/>
<variable name="RFH2.JMSFolder" type="xsd:string"/>
<variable name="RFH2.MCDFolder" type="xsd:string"/>
<variable name="RFH2.USRFolder" type="xsd:string"/>
<variable name="RFH2.USRFolder_2" type="xsd:string"/>
<variable name="RFH2.PSCFolder" type="xsd:string"/>
<variable name="RFH2extrafolder" type="xsd:string"/>
<variable name="RFH2_2.StructId" type="xsd:string"/>
<variable name="RFH2_2.Version" type="xsd:string"/>
<variable name="RFH2_2.Encoding" type="xsd:string"/>
<variable name="RFH2_2.CodedCharSetId" type="xsd:string"/>
<variable name="RFH2_2.Format" type="xsd:string"/>
<variable name="RFH2_2.Flags" type="xsd:string"/>
<variable name="RFH2_2.NameValueCCSID" type="xsd:string"/>
<variable name="RFH2_2.JMSFolder" type="xsd:string"/>
<variable name="RFH2_2.JMSFolder_2" type="xsd:string"/>
<variable name="RFH2_2.MCDFolder" type="xsd:string"/>
<variable name="RFH2_2.USRFolder" type="xsd:string"/>
<variable name="RFH2_2.USRFolder_2" type="xsd:string"/>
<variable name="RFH2_2.PSCFolder" type="xsd:string"/>
<variable name="TotalRFH2" type="xsd:string"/>

18. receiveアクティビティは、作成した一時変数でRFH2ヘッダー・プロパティを受け入れるように構成します。

a. 「DequeueEnqueueRFH2.bpel」ページの「ソース」タブを開きます。

b. <receive>タグの下に、次のエントリを追加します。

<bpelx:property name="jca.mq.RFH2.StructId" variable="RFH2.StructId"/>
<bpelx:property name="jca.mq.RFH2.Version" variable="RFH2.Version"/>
<bpelx:property name="jca.mq.RFH2.Encoding" variable="RFH2.Encoding"/>
<bpelx:property name="jca.mq.RFH2.CodedCharSetId"     variable="RFH2.CodedCharSetId"/>
<bpelx:property name="jca.mq.RFH2.Format" variable="RFH2.Format"/>
<bpelx:property name="jca.mq.RFH2.Flags" variable="RFH2.Flags"/>
<bpelx:property name="jca.mq.RFH2.NameValueCCSID"     variable="RFH2.NameValueCCSID"/>
<bpelx:property name="jca.mq.RFH2.JMSFolder" variable="RFH2.JMSFolder"/>
<bpelx:property name="jca.mq.RFH2.MCDFolder" variable="RFH2.MCDFolder"/>
<bpelx:property name="jca.mq.RFH2.USRFolder" variable="RFH2.USRFolder"/>
<bpelx:property name="jca.mq.RFH2.USRFolder_2" variable="RFH2.USRFolder_2"/>
<bpelx:property name="jca.mq.RFH2.PSCFolder" variable="RFH2.PSCFolder"/>
<bpelx:property name="jca.mq.RFH2.mq_usr" variable="RFH2extrafolder"/>
<bpelx:property name="jca.mq.RFH2_2.StructId" variable="RFH2_2.StructId"/>
<bpelx:property name="jca.mq.RFH2_2.Version" variable="RFH2_2.Version"/>
<bpelx:property name="jca.mq.RFH2_2.Encoding" variable="RFH2_2.Encoding"/>
<bpelx:property name="jca.mq.RFH2_2.CodedCharSetId"      variable="RFH2_2.CodedCharSetId"/>
<bpelx:property name="jca.mq.RFH2_2.Format" variable="RFH2_2.Format"/>
<bpelx:property name="jca.mq.RFH2_2.Flags" variable="RFH2_2.Flags"/>
<bpelx:property name="jca.mq.RFH2_2.NameValueCCSID" variable=     "RFH2_2.NameValueCCSID"/>
<bpelx:property name="jca.mq.RFH2_2.JMSFolder" variable="RFH2_2.JMSFolder"/>
<bpelx:property name="jca.mq.RFH2_2.JMSFolder_2"      variable="RFH2_2.JMSFolder_2"/>
<bpelx:property name="jca.mq.RFH2_2.MCDFolder" variable="RFH2_2.MCDFolder"/>
<bpelx:property name="jca.mq.RFH2_2.USRFolder" variable="RFH2_2.USRFolder"/>
<bpelx:property name="jca.mq.RFH2_2.PSCFolder" variable="RFH2_2.PSCFolder"/>
<bpelx:property name="jca.mq.RFH2_2.USRFolder_2"     variable="RFH2_2.USRFolder_2"/>
<bpelx:property name="jca.mq.RFH2.Total.Headers" variable="TotalRFH2"/>

19. invokeアクティビティは、変更済のRFH2ヘッダー・プロパティをアウトバウンド・メッセージにプッシュするように構成します。

a. 「DequeueEnqueueRFH2.bpel」ページの「ソース」タブを開きます。

b. <invoke>タグの下に、次のエントリを追加します。

<bpelx:inputProperty name="jca.mq.MQMD.Format" expression="'RF_HDR_2'"/>
<bpelx:inputProperty name="jca.mq.RFH2.StructId" variable="RFH2.StructId"/>
<bpelx:inputProperty name="jca.mq.RFH2.Version" variable="RFH2.Version"/>
<bpelx:inputProperty name="jca.mq.RFH2.CodedCharSetId" variable="RFH2.CodedCharSetId"/>
<bpelx:inputProperty name="jca.mq.RFH2.Encoding" variable="RFH2.Encoding"/>
<bpelx:inputProperty name="jca.mq.RFH2.Flags" variable="RFH2.Flags"/>
<bpelx:inputProperty name="jca.mq.RFH2.Format" expression="'MQHRF2  '"/>
<bpelx:inputProperty name="jca.mq.RFH2.NameValueCCSID" variable="RFH2.NameValueCCSID"/>
<bpelx:inputProperty name="jca.mq.RFH2.JMSFolder" variable="RFH2.JMSFolder"/>
<bpelx:inputProperty name="jca.mq.RFH2.MCDFolder" variable="RFH2.MCDFolder"/>
<bpelx:inputProperty name="jca.mq.RFH2.USRFolder" variable="RFH2.USRFolder"/>
<bpelx:inputProperty name="jca.mq.RFH2.mq_usr" variable="RFH2extrafolder"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.StructId" expression="'RFH '"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.Version" expression="'2'"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.CodedCharSetId" expression="'819'"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.Encoding" expression="'273'"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.Flags" expression="'0'"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.Format" expression="'MQSTR   '"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.NameValueCCSID" expression="'1208'"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.JMSFolder" expression="'&lt;jms>&lt;Dst>MYTOPIC&lt;/Dst>&lt;Exp>2000&lt;/Exp>&lt;Pri>4&lt;/Pri>&lt;Cid>22344&lt;/Cid>&lt;Rto>REPLY.QUEUE&lt;/Rto>&lt;Gid>3334&lt;/Gid>&lt;Seq>2&lt;/Seq>&lt;Dlv>1&lt;/Dlv>&lt;xxx>UserSpace&lt;/xxx>&lt;/jms>'"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.JMSFolder_2" variable="RFH2_2.JMSFolder_2"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.MCDFolder" expression="'&lt;mcd>&lt;Msd>jms_object&lt;/Msd>&lt;/mcd>'"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.USRFolder" variable="RFH2_2.USRFolder"/>
<bpelx:inputProperty name="jca.mq.RFH2_2.USRFolder_2" variable="RFH2_2.USRFolder_2"/>

20. 「ファイル」、「すべて保存」を順番にクリックします。

10.6.8.1.5 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

適切なRFH2ヘッダーを含むMQメッセージをインバウンド・キューに配置する必要があります。

この例は、インバウンド・メッセージから2つのRFH2ヘッダーを取得するように構成されています(これは、必要に応じてBPELプロセスを構成することで変更できます)。MQメッセージのテスト入力は次のように行います。

- ペイロード: すべてのメッセージ(Opaqueを使用しているためすべての書式が受入れ可能です)。

- RFH2ヘッダー1: 2つのUSRフォルダ、1つのJMSフォルダ、1つのPSCフォルダ、1つのMCDフォルダおよび1つのmq_usrフォルダを含む必要があります。

- RFH2ヘッダー2: 2つのUSRフォルダ、2つのJMSフォルダ、1つのPSCフォルダおよび1つのMCDフォルダを含む必要があります。

サンプルをデプロイし、メッセージをインバウンド・キューに格納します。変更済のRFH2ヘッダーを含む新しいメッセージのアウトバウンド・キューをチェックします(BPELのinvokeアクティビティでの構成に応じて)。

10.6.8.2 複数のRFH2ヘッダーを含むアウトバウンド・デキュー

この例は、アウトバウンド・デキュー・シナリオで1つまたは複数のRFH2ヘッダーを含むMQメッセージを取得するためのMQアダプタの使用方法を示しています。

このサンプルでは、2つのRFH2ヘッダーを含むMQメッセージがアウトバウンド・キュー・シナリオのキューからデキューされます。

このユース・ケースの例を作成する手順は次のとおりです。

- SOAコンポジットの設計

- アウトバウンド・デキュー・アダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- JDeveloperを使用したデプロイ

10.6.8.2.1 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックして「新規」を選択します。

「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにOutboundDequeueRFH2と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

5. 「プロジェクト名」フィールドにOutboundDequeueRFH2と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。

6. 「次」を選択します。「SOA設定の構成」画面が表示されます。

7. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。

8. 「名前」フィールドにOutboundDequeueRFH2と入力し、「テンプレート」ボックスで「同期BPELプロセス」を選択します。

9. 「入力」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。

11. 「出力」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

12. 「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。

13. 「OK」をクリックします。「OutboundDequeueRFH2」アプリケーションおよび「OutboundDequeueRFH2」コンポジット・プロジェクトが設計領域に表示されます。

10.6.8.2.2 アウトバウンド・デキュー・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューにデキューするアダプタ・サービスを作成します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにOutboundDQと入力して「OK」をクリックします。「接続」ページが表示されます。

4. 接続のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQからメッセージを取得」および「同期」を選択し、「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。

7. 「キュー名」フィールドにqueue1と入力し、「待機間隔」フィールドに10 secondsと入力して「次へ」をクリックします。「メッセージ」ページが表示されます。

8. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「OK」をクリックします。

9. 「次」を選択します。「終了」ページが表示されます。

10. 「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-103に示すように、「composite.xml」 ページが表示されます。

図10-103 JDeveloper-composite.xml

11. 「ファイル」、「すべて保存」を順番にクリックします。

10.6.8.2.3 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(クライアント、BPELプロセスおよびOutboundDQアダプタ参照)をアセンブルまたは接続する必要があります。

コンポーネントを接続する手順は、次のとおりです。

1. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundDequeueService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「OutboundDequeueRFH2」BPELプロセスをダブルクリックします。「OutboundDequeueRFH2.bpel」ページが表示されます。
JDeveloperのcomposite.xmlが図10-106 のように表示されます。

図10-104 JDeveloper - composite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4. 「OutboundDequeueRFH2.bpel」をダブルクリックします。「OutboundDequeueRFH2.bpel」ページが表示されます。

5. 「コンポーネント」ウィンドウからreceiveInputアクティビティとreplyOutputアクティビティ間にある「コンポーネント」領域に、invokeおよびassignの各アクティビティをこの順序でドラッグ・アンド・ドロップします。

6. invokeアクティビティをOutboundDQアダプタ参照にドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。

7. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトを受け入れて「OK」をクリックします。

9. 出力変数にも同じ手順を繰り返して「OK」をクリックします。

10. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

11. 変数を選択して、「プラス」アイコンをクリックします。

図10-105 アクティビティの割当てダイアログ

12. Assignダイアログで「OK」をクリックします。JDeveloperの「BPELOutboundDequeue.bpel」ページが表示されます。

図10-106 JDeveloperの「BPELOutboundDequeue.bpel」ページ

13. RFH2のヘッダー部分を格納する一時変数を作成します。

a. 「DequeueEnqueueRFH2.bpel」ページの「ソース」タブを開きます。

b. <variables>タブの下に、次の新規変数を追加します。

<variable name="RFH2.StructId" type="xsd:string"/>
<variable name="RFH2.Version" type="xsd:string"/>
<variable name="RFH2.Encoding" type="xsd:string"/>
<variable name="RFH2.CodedCharSetId" type="xsd:string"/>
<variable name="RFH2.Format" type="xsd:string"/>
<variable name="RFH2.Flags" type="xsd:string"/>
<variable name="RFH2.NameValueCCSID" type="xsd:string"/>
<variable name="RFH2.JMSFolder" type="xsd:string"/>
<variable name="RFH2.MCDFolder" type="xsd:string"/>
<variable name="RFH2.USRFolder" type="xsd:string"/>
<variable name="RFH2.USRFolder_2" type="xsd:string"/>
<variable name="RFH2.PSCFolder" type="xsd:string"/>
<variable name="RFH2extrafolder" type="xsd:string"/>
<variable name="RFH2_2.StructId" type="xsd:string"/>
<variable name="RFH2_2.Version" type="xsd:string"/>
<variable name="RFH2_2.Encoding" type="xsd:string"/>
<variable name="RFH2_2.CodedCharSetId" type="xsd:string"/>
<variable name="RFH2_2.Format" type="xsd:string"/>
<variable name="RFH2_2.Flags" type="xsd:string"/>
<variable name="RFH2_2.NameValueCCSID" type="xsd:string"/>
<variable name="RFH2_2.JMSFolder" type="xsd:string"/>
<variable name="RFH2_2.JMSFolder_2" type="xsd:string"/>
<variable name="RFH2_2.MCDFolder" type="xsd:string"/>
<variable name="RFH2_2.USRFolder" type="xsd:string"/>
<variable name="RFH2_2.USRFolder_2" type="xsd:string"/>
<variable name="RFH2_2.PSCFolder" type="xsd:string"/>
<variable name="TotalRFH2" type="xsd:string"/>

14. invokeアクティビティは、アウトバウンド・デキュー・メッセージからRFH2ヘッダー・プロパティを受け入れるように構成します。

a. 「DequeueEnqueueRFH2.bpel」ページの「ソース」タブを開きます。

b. <invoke>タグの下に、次のエントリを追加します。

<bpelx:outputProperty name="jca.mq.RFH2.StructId" variable="RFH2.StructId"/>
<bpelx:outputProperty name="jca.mq.RFH2.Version" variable="RFH2.Version"/>
<bpelx:outputProperty name="jca.mq.RFH2.Encoding" variable="RFH2.Encoding"/>
<bpelx:outputProperty name="jca.mq.RFH2.CodedCharSetId" variable="RFH2.CodedCharSetId"/>
<bpelx:outputProperty name="jca.mq.RFH2.Format" variable="RFH2.Format"/>
<bpelx:outputProperty name="jca.mq.RFH2.Flags" variable="RFH2.Flags"/>
<bpelx:outputProperty name="jca.mq.RFH2.NameValueCCSID" variable="RFH2.NameValueCCSID"/>
<bpelx:outputProperty name="jca.mq.RFH2.JMSFolder" variable="RFH2.JMSFolder"/>
<bpelx:outputProperty name="jca.mq.RFH2.MCDFolder" variable="RFH2.MCDFolder"/>
<bpelx:outputProperty name="jca.mq.RFH2.USRFolder" variable="RFH2.USRFolder"/>
<bpelx:outputProperty name="jca.mq.RFH2.USRFolder_2" variable="RFH2.USRFolder_2"/>
<bpelx:outputProperty name="jca.mq.RFH2.PSCFolder" variable="RFH2.PSCFolder"/>
<bpelx:outputProperty name="jca.mq.RFH2.mq_usr" variable="RFH2extrafolder"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.StructId" variable="RFH2_2.StructId"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.Version" variable="RFH2_2.Version"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.Encoding" variable="RFH2_2.Encoding"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.CodedCharSetId" variable="RFH2_2.CodedCharSetId"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.Format" variable="RFH2_2.Format"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.Flags" variable="RFH2_2.Flags"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.NameValueCCSID" variable="RFH2_2.NameValueCCSID"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.JMSFolder" variable="RFH2_2.JMSFolder"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.JMSFolder_2" variable="RFH2_2.JMSFolder_2"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.MCDFolder" variable="RFH2_2.MCDFolder"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.USRFolder" variable="RFH2_2.USRFolder"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.PSCFolder" variable="RFH2_2.PSCFolder"/>
<bpelx:outputProperty name="jca.mq.RFH2_2.USRFolder_2" variable="RFH2_2.USRFolder_2"/>
<bpelx:outputProperty name="jca.mq.RFH2.Total.Headers" variable="TotalRFH2"/>

15. 「ファイル」、「すべて保存」を順番にクリックします。

10.6.8.2.4 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。

JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

適切なRFH2ヘッダーを含むMQメッセージをアウトバウンド・デキュー・キューに格納する必要があります。この例は、メッセージから2つのRFH2ヘッダーを取得するように構成されています(これは、必要に応じてBPELプロセスを構成することで変更できます)。MQメッセージのテストは次のように行います。

- ペイロード: すべてのメッセージ(Opaqueを使用しているためすべての書式が有効です)。

- RFH2ヘッダー1: 2つのUSRフォルダ、1つのJMSフォルダ、1つのPSCフォルダ、1つのMCDフォルダおよび1つのmq_usrフォルダを含む必要があります。

- RFH2ヘッダー2: 2つのUSRフォルダ、2つのJMSフォルダ、1つのPSCフォルダおよび1つのMCDフォルダを含む必要があります。

サンプルをデプロイし、メッセージをアウトバウンド・デキュー・キューに格納します。Fusion Middleware Controlコンソールを開き、テスト・ユーティリティを使用してサンプルを起動します。しばらく待機してからインスタンス監査証跡を調査します。

10.6.9 メッセージを添付ファイルとして処理

この項では、メッセージを添付ファイルとして処理するようにインバウンドおよびアウトバウンドMQアダプタを構成する方法について説明します。

10.6.9.1 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperで、「ファイル」をクリックし、「新規」を選択し、「アプリケーション」を選択します。「新規ギャラリ」ダイアログが表示されます。

2. 「一般」ノードを開いて「アプリケーション」カテゴリを選択します。

3. 「項目」リストで「SOAアプリケーション」を選択し、「OK」をクリックします。SOAアプリケーションの作成ウィザードが表示されます。

4. 「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにMQAsAttachmentと入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。

5. 「プロジェクト名」フィールドにMQAsAttachmentと入力し、「次へ」をクリックします。「SOA設定の構成」画面が表示されます。

6. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。ウィザードに、「BPELプロセスの作成」ダイアログが表示されます。

7. 「名前」フィールドにMQAsAttachmentと入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。

8. 「OK」をクリックします。MQAsAttachmentアプリケーションとMQAsAttachmentプロジェクトが設計領域に表示されます。

10.6.9.2 インバウンド・アダプタ・サービスの作成

次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。

1. 「コンポーネント・パレット」から、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます

2. 「次」を選択します。「サービス名」ページが表示されます。

3. 「サービス名」フィールドにmqServiceと入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。

4. MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQからメッセージを取得」を選択し(「同期」は選択しません)、「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。

7. 「キュー名」フィールドにqueue1と入力します。

8. 図10-107 に示すように、「メッセージを添付ファイルとして読取り」チェック・ボックスを選択し、「次へ」をクリックします。

注意: この使用例では、「文字セット」、「エンコーディング」および「コンテンツ・タイプ」フィールドは無視します。この添付ファイルの読取りを必要とするサード・パーティのアプリケーションを使用している場合にのみ、これらのフィールドに値を移入します。現在の使用例の添付ファイルは、サード・パーティのアプリケーションではなく、アウトバウンドOracle MQアダプタによって最終的に使用されるため、これらの値は必要としません。

図10-107 「メッセージを添付ファイルとして読取り」チェック・ボックスの選択

9. 「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、インバウンド・アダプタが追加された「composite.xml」ページが表示されます。

10.6.9.3 アウトバウンド・アダプタ・サービスの作成

アウトバウンド・アダプタ・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」ウィンドウから、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。ウィザードに、アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「次へ」をクリックします。ウィザードに、「参照名」ページが表示されます。

3. 「サービス名」フィールドにmqReferenceと入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。

4. MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます

5. 「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。

6. 「MQにメッセージを蓄積」を選択して「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。

7. 「キュー名」フィールドにqueue2と入力して「次へ」をクリックします。「詳細オプション」ページが表示されます。

8. デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。

9. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。

10. 図10-108 に示すように、「プロジェクトのWSDLファイル」、「mqService.wsdl」、「Inline Schemas」、「attachmentElement」を順番にクリックします。

図10-108 attachmentElementの選択

11. 「OK」を選択します。ウィザードは、AttachmentIn.wsdlを使用して「メッセージ」ページにURLフィールドを移入します。

12. 「次」を選択します。「終了」ページが表示されます。

13. 「終了」を選択します。アウトバウンド・アダプタ・サービスの構成が完了し、図10-109に示すように、composite.xml ページが表示されます。

図10-109 アウトバウンド・アダプタ・サービスを構成した後のcomposite.xml

10.6.9.4 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるmqService内の小さい三角形を、「コンポーネント」領域のMQAsAttachment内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「コンポーネント」領域にあるMQAsAttachment内の小さい三角形を、「外部参照」領域のmqReference内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

JDeveloperのcomposite.xmlが図10-110 のように表示されます。

図10-110 アクティビティとサービスがワイヤリングされたcomposite.xml

3. 「ファイル」、「すべて保存」を順番にクリックします。

4. 「MQAsAttachment」をダブルクリックします。「MQAsAttachment.bpel」ページが表示されます。

5. 「コンポーネント・パレット」から、receive、assignおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。

次の図10-111 に示すように、JDeveloperの「MQAsAttachment.bpel」ページが表示されます。

図10-111 JDeveloperの「MQAsAttachment.bpel」ページ

6. receiveアクティビティをmqServiceにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。

7. 「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

8. デフォルトを受け入れて「OK」をクリックします。

9. 「インスタンスの作成」ボックスを選択して「OK」をクリックします。

10. invokeアクティビティをmqReferenceにドラッグ・アンド・ドロップします。Invokeダイアログが表示されます。

11. 「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。

12. デフォルトを受け入れて「OK」をクリックします。Invokeダイアログが表示されます。

13. 「OK」をクリックします。

14. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

15. 図10-112 に示すように、変数を選択し、「+」アイコンを選択します。

図10-112 アクティビティの割当てダイアログ

16. Assignダイアログで「OK」をクリックします。図10-113 に示すように、JDeveloperの「MQAsAttachment.bpel」ページが表示されます。

図10-113 「MQAsAttachment.bpel」ページ

17. 「ファイル」、「すべて保存」を順番にクリックします。

10.6.9.5 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションをデプロイします。詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

11 Oracle JCA Adapter for UMS

この章は、Oracle User Messaging Serviceアダプタの使用方法について説明します。このアダプタは、ユーザーとアプリケーション間の通信を可能にするOracle Fusion MiddlewareコンポーネントのOracle User Message Service (UMS)をラップするJCAアダプタを提供します。また、この章では、UMSアダプタの概念、機能、構成およびエラー処理に関する情報を提供します。

この章の内容は次のとおりです。

- UMSおよびUMSアダプタの概念

- Oracle User Messaging Service機能

11.1 UMSおよびUMSアダプタの概念

この項には次のトピックが含まれます:

- User Messaging Service

- Oracle UMSアダプタ

- UMSアダプタの概念

- トランザクション・サポート

- Oracle UMSアダプタの構成

11.1.1 User Messaging Service

User Messaging Serviceは、ユーザーとアプリケーション間の通信を可能にするOracle Fusion Middlewareコンポーネントです。内容は次のとおりです。

- UMSサーバー: UMSサーバーは、アプリケーションとユーザー間のメッセージ・フローを統合します。サーバーは、アウトバウンド・メッセージをクライアント・アプリケーションから適切なドライバにルーティングし、インバウンド・メッセージを適切なクライアント・アプリケーションにルーティングします。また、サーバーは、すでに送信されたメッセージのリポジトリを永続ストアに保持し、すでに送信されたメッセージに配信ステータス情報を関係付けます。

- UMSドライバ: UMSドライバは、UMSをメッセージング・ゲートウェイに接続し、UMSでサポートされている様々なプロトコルに対してコンテンツを適合させます。これらのドライバは、特定のインストールで使用できるメッセージング・チャネルに従って、相互に独立してデプロイまたはアンデプロイできます。

- UMSクライアント・アプリケーション: UMSクライアント・アプリケーションは、メッセージの送受信に関するビジネス・ロジックを実装します。UMSクライアント・アプリケーションは、BPELワークフローの1手順としてメッセージを送信するSOAアプリケーション、またはWebインタフェースからメッセージを送信できるWebCenterスペース・アプリケーションの場合があります。

UMSサーバーのコンテキストの詳細は、図11-1 を参照してください。

図11-1 コンテキスト内のユーザー・メッセージング・サーバー

UMSでは、電子メール、SMS、インスタント・メッセージ、ボイスなどの様々なメッセージング・チャネルがサポートされます。UMSでは、Oracle BPELまたはMediator製品と外部間のメッセージング・プロキシが提供されます。User Messaging Serviceでは、インバウンド・メッセージングとアウトバウンド・メッセージングの2通りのメッセージングが提供され、配信ステータスの配信などの強固なメッセージ配信と、エンタープライズ・メッセージを使用したメッセージの再送信が可能です。また、UMSでは、フェイルオーバー・アドレスをサポートできます。つまり、UMSでは、ユーザーとアプリケーション間の通信に対して、スケーラブルで可用性の高いソリューションが提供されます。

User Messaging Serviceの詳細は、『Oracle® Fusion Middleware Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。

11.1.2 Oracle UMSアダプタ

User Messaging Serviceアダプタには、Java Enterprise Edition Connector Architecture (JCA)バージョン1.5が実装されています。UMSアダプタは、実質的にUser Messaging Serviceをラップしているため、電子メールを含むメッセージング・チャネルを超えた通信が可能です。

UMSアダプタは、アダプタのアーキテクチャ全体に含まれます。J2EEアプリケーション、MediatorおよびBPELの各プロセスはOracle WebLogic Serverと通信します。次の図を参照してください。

図11-2 アダプタ・アーキテクチャの一部としてのUMSアダプタ

11.2 Oracle User Messaging Service機能

UMSアダプタには、次のアウトバウンド機能が含まれます

- 電子メール・メッセージング、IMおよびSMSチャネルのサポート。

- メッセージ・フィルタの使用。UMSアダプタでは、内容、受信者、送信者および件名を使用してIMおよびSMSメッセージをフィルタできます。

- 件名と本文および1つ以上の添付を含む電子メール・メッセージの送信。ユーザーはIM、SMSメッセージも送信できます。

- UMSからのメッセージ配信ステータス情報の受信。

- メッセージの本文の変換サポート。

- アウトバウンドSMTPサーバーのSSL/TLSセキュリティ(Java Messaging Serviceの使用が必要です)。

- アウトバウンド・トランザクションのXAまたはグローバル・トランザクションのサポート。

UMSアダプタには、次のインバウンド機能があります。

- 電子メール、IMおよびSMSメッセージング・チャネルのサポート。

- メッセージ・フィルタの使用。UMSアダプタでは次の2つの方法で電子メール・メッセージをフィルタできます。

1. アダプタ構成ウィザードの「メッセージ・フィルタ」画面を使用したメッセージ・フィルタの設定。これには、メッセージ・フィルタ、ブラックリスト・フィルタおよびホワイトリスト・フィルタが含まれます。メッセージ・フィルタでは、電子メール宛先アドレス、送信元アドレス、CCアドレス、件名およびメール・ヘッダーを基準にして受信メッセージをフィルタする機能が提供されます。同様に、このフィルタリングを使用してメールを無視することもできます。BCCアドレスを基準にして使用できるフィルタはないことに注意してください。

2. Javaコールアウトの作成およびパッケージング、ならびにアダプタ構成ウィザードを使用したコールアウト名の指定。詳細は、「カスタムJavaコールアウト」を参照してください。

- 件名、本文および1つ以上の添付ファイルを含むメッセージの他、インターネット・メールおよびMIMEヘッダーの受信。

- ポーリング/リスナー・インタフェース。UMSアダプタでは、作成した様々なスケジュール上の受信電子メールのメールボックスがポーリング(順次とパラレルのどちらも指定可能)されます。

- メッセージの本文の変換サポート。

- インバウンドのXAまたはグローバル・トランザクションのサポート(ポーリングおよびリスナー・モードの両方に適用可能)。UMSアダプタのフローがアウトバウンドの場合は、UMSアダプタでXAトランザクションがFalseに設定されている場合でも、フローがBPELまたはインバウンド・アダプタからすでに開始済のトランザクションの一部であれば、同じアウトバウンドUMSアダプタはXAトランザクションを実行している場合と同様に動作します。

- SSLを使用したIMAP/POP3サーバー(UMSサーバーの使用が必要)。

注意:

UMSアダプタを使用したMS-2010メール・サーバーの使用時は、キーワード・ヘッダーを含むヘッダーの設定および取得はできません。

11.2.1 UMSアダプタのメッセージの概要

UMSアダプタでは、異なるメッセージの書式を指定できます。

多くの電子メールのユース・ケースでは、メッセージ・ペイロードが平文に指定されているため、スキーマを指定する必要がなく、そのままで受信することが必要な場合もあります。このケースでは、「メッセージ」画面で「文字列タイプのメッセージ」チェック・ボックスを選択できます。

メッセージの変換には、XSDファイルが必要です。新しいスキーマを定義するか、あるいは既存のデータ型の定義(DTD)またはCOBOLコピーブックを変換する場合は、「ネイティブ・フォーマットのスキーマの定義」を選択してXSDファイルを指定する必要があります。

「ネイティブ・フォーマットのスキーマの定義」を選択すると、ネイティブ・フォーマット・ビルダー・ウィザードが起動します。このウィザードは、カンマ区切り値(CSV)、固定長、DTDおよびCOBOLコピーブックなどのファイル形式を使用したネイティブ・スキーマ・ファイルの作成を支援します。

ネイティブ・スキーマ・ファイルの作成後、「スキーマ・ファイルのURL」および「スキーマ要素」フィールドが入力された「メッセージ」ページが表示されます。詳細は、「ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ・ファイルの作成」を参照してください。

他のアダプタとは異なり、UMSアダプタでは、使用するメッセージの表示に、事前定義済のメッセージ・スキーマを使用します。

UMSアダプタで使用するメッセージ・スキーマの例は次のとおりです。

<?xml version= "1.0" encoding= "UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://platform.integration.oracle/blocks
/adapter/fw/metadata/Inbound_UMS"
targetNamespace="http://platform.integration.oracle/
blocks/adapter/              fw/metadata/Inbound_UMS"
xmlns:imp1="http://xmlns.oracle.com/pcbpel/adapter/opaque/"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:import namespace="http://xmlns.oracle.com/pcbpel/adapter/opaque/"   schemaLocation="opaque.xsd"/>
<xsd:complexType name="MessageType">
<xsd:sequence>
<xsd:element ref="imp1:opaqueElement"/>
<xsd:element name="attachment"
type="AttachmentType" minOccurs="0"                  maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AttachmentType">
<xsd:attribute name="href" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="ResponseType">
<xsd:sequence>
<xsd:element name="MessageId"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="message" type="MessageType"/>
<xsd:element name="response" type="ResponseType"/>
</xsd:schema>Status OpenFixedClosed

スキーマの定義は、UMSアダプタ構成ウィザードの「メッセージ」画面を介した変換要件とメッセージ本文のコンテンツの定義に従って行います。UMSアダプタでは、指定されたXSDがUMSアダプタで使用するメッセージ・スキーマにインポートされます。

たとえば、次の例のスキーマ・スニペットを参照すると、ユーザー定義スキーマのsingleString.xsdがUMSアダプタ構成ウィザードでインポートされ、さらにUMSアダプタ構成ウィザードを介してsingleString.xsdの下に定義されたsingleString要素を参照します。

例 - SingleString.xsdのスキーマ・スニペット

<?xml version= '1.0' encoding= 'UTF-8' ?>
<xsd:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com
/singleString"
xmlns="http://xmlns.oracle.com/singleString"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
nxsd:encoding="US-ASCII" nxsd:
useArrayIdentifiers="true"
nxsd:stream="chars" nxsd:version="NXSD">
<xsd:complexType name="singleString">
<xsd:sequence>
<xsd:element name="input" type="xsd:string"
nxsd:style="terminated"
nxsd:terminatedBy=";"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="payload" type="singleString"/>
</xsd:schema

11.2.1.1 カスタムJavaコールアウト

「Javaコールアウト」画面では、電子メール、SMSまたはIMメッセージがUMSアダプタで処理される前に起動可能なカスタム・ロジックを使用してカスタムJavaクラスを指定できます。

11.2.1.1.1 カスタムJavaコールアウトのユース・ケース

カスタムJavaコールアウトのユース・ケースとして、送信者のアドレスをLDAP内のアドレス、またはステージング領域に存在し以前に記録されていたアドレスに一致させる例があります。このユース・ケースを作成するには、インタフェースのoracle.tip.pc.services.translation.util.ICustomCalloutを実装する必要があります。

このインタフェースでは、booleanの戻り値で単一のメソッド実行が定義されます。戻り値に応じて、メッセージは処理されるか、または拒否されます。

public Inteface CustomCallout{
public boolean execute (Message message) throws exception;
}

ここでのMessageは、UMSセッション記述プロトコル(SDP)というJava APIのMessageクラスを示し、これは、UMSサーバーで指定され、適切に定義されたJava APIで、$MW_HOME./oracle_common/modules/oracle.sdp.client_12.1.2/messaging-api.jarで検索できます。戻されるブール値によって、メッセージを受け入れて処理するか、またはメッセージを拒否するかが指定されます。

package oracle.adapter.custom;

import java.io.File;
import oracle.sdp.messaging.Message;
import oracle.tip.pc.services.translation.
util.ICustomCallout;

public class UMSAdapter_CustomCall implements          ICustomCallout{

@Override
public boolean execute(Message message)              throws exception {
String emailFromAddress = message.
getSenders()[0].getValue();

String fileName = "/tmp/OracleStore/staging/".
concat(emailFromAddress).concat(".usr");
File file = new File(fileName);
if(file.exists()) {
return true;
}
return false;
}
}

もう1つのユース・ケースでは、サンプル・コードに示すように、scott.tiger@example.comという電子メールIDを持つユーザーがインターネット・ストアのWebサイトを使用した登録をしています。このユーザーは、ステージング領域の下にscott.tiger@example.comというファイル名を使用して記録されます。

送信されてきた電子メールに返信するには、そのユーザーの電子メールIDに直接電子メールが送信されます。

ユーザーが電子メールに返信すると、UMSアダプタがその電子メールを受信します。その後は、Javaコールアウトを使用してステージング領域の下のユーザー・ファイルを確認し、ユーザーのWebサイトでの登録を確認できます。

11.2.1.1.2 カスタム・コールアウト・ファシリティの使用

カスタム・コールアウト・ファシリティを使用するには、次を実行する必要があります。

1. UMSアダプタ構成ウィザードの「Javaコールアウト」画面でクラス名を指定します。

2. そのクラスおよび他の必要なカスタム・クラスをjarファイルにバンドルします。

3. SCA-INF/libディレクトリにあるコンポジット・アプリケーションの下にそのjarファイルを置きます。

4. コンパイル済のJavaクラス(.classファイル)がコンポジット・プロジェクト・フォルダの\SCA-INF\classesの下に直接配置されていることを確認します。

11.2.2 トランザクション・サポート

UMSアダプタは、デフォルトで、ポーリング・モードとリスナー・モードの両方に対してインバウンド・シナリオとともにXAトランザクションを使用します。そのために、アダプタは、プロパティXATransactionをtrueに設定してコネクション・ファクトリ・インスタンスを構成します。デフォルトでXAを使用するように構成されたデフォルトJNDIインスタンスを使用できます。このデフォルトJNDIインスタンスの名前はeis/ums/UMSAdapterInboundです。アウトバウンド・シナリオでは、UMSアダプタはUMSからのXAサポートを活用します。UMSは、BPELなどを介してすでに開始されている場合、グローバル・トランザクションに参加します。独自のJNDIインスタンスを定義して使用することを選択できますが、前述の説明に留意する必要があります。

11.2.2.1 インバウンド・エラー処理

UMSアダプタでは、悪質なメッセージを拒否するために、アダプタのインバウンド側でデフォルトの拒否処理メカニズムを使用します。たとえば、変換関連のエラーが生じると、メッセージ拒否が発生します。フォルト・ポリシーおよびアダプタの詳細は、このガイドの「フォルト・ポリシーの作成」を参照してください。

再試行可能なエラー状態で、再試行関連のエンドポイント・プロパティを指定している場合は、UMSアダプタにより、メッセージの拒否前に構成されていた再試行数でインバウンド・メッセージを再発行します。次に、前述のJNDIおよびXAの説明に従って、XAの下にあるロールバックにトランザクションが設定されます。

11.2.2.2 アウトバウンド・エラー処理

UMSアダプタは、接続エラーなどの一時(リカバリ可能)エラー状態に対して例外をスローします。再試行可能なエラーでは、アダプタ・フレームワークでサポートされている再試行ポリシーを使用できます。これを実行するには、必要な再試行カウントに対してバインディング・プロパティのjca.retry.countを設定できます。さらに、他のアダプタにおいて、プロパティを設定していない場合は、フォルト・ポリシーに従って再試行が実行されます。

アウトバウンド・トランザクションには、フォルト・ポリシーを使用して再試行不可能な接続エラーを定義できます。再接続の試行の最大数は、fault-policy.xmlを使用して定義できます。

アダプタでは、アダプタ構成ウィザードを使用して、設計時の作業で取得したメタデータに基づき、データをネイティブ表現と標準XML形式間で変換します。変換の実行によりスローされる例外が発生すると、変換エラーがスローされ、さらに対応するバインディング・フォルトもスローされます。

表11-1 に示すように、アウトバウンド再試行可能エラーに関連するエンドポイント・プロパティを設定できます

表11-1 UMSアダプタのアウトバウンド・エンドポイント・プロパティ

プロパティ

説明

jca.retry.count

再試行可能エラー状態をスローして起動中のサービス・エンジンに戻す前の再試行の最大数を示します。

jca.retry.interval

再試行の時間間隔(秒単位)を示します。

jca.retry.backoff

再試行間隔の増分ファクタ(正の整数)を示します。

jca.retry.maxInterval

再試行の間隔の最大値(値が1より大きい場合の上限)を示します。

jca.retry.maxPeriod

再試行の合計最大期間を示します。このパラメータに指定した値を超えて、再試行が発生することはありません。

11.2.2.2.1 ステータス・レポートでの失敗した送信通知の再試行メカニズム

UMSアダプタでは、UMSが提供する既存のインフラストラクチャを使用して、失敗した送信の例外を再試行します。現行のUMSサーバーでは、Fusion Middleware Controlからの通知の失敗の確認に加えて、メッセージの再送信もサポートしています。

11.2.2.2.2 クラスタでのインバウンド受信通知(ポーリングまたはリスナーを使用)

UMS APIは、クラスタ環境内でUMSサーバーとそのクライアントがデプロイされている環境をサポートします。また、UMSアダプタは、アクティブ/アクティブ設定での高可用性もサポートしています。

クラスタ化環境で適切に動作するUMSアダプタの構成の詳細は次のとおりです。クラスタでのUMSデプロイメントも同じようにする必要があります。クラスタのノードには、UMSアダプタ、UMSサーバーEARおよびすべてのドライバEARがあります。すべてがノード上に共存する必要があります。たとえば、クラスタを作成する場合にアダプタ構成ウィザードで、UMSアダプタとすべてのUMSをクラスタに対してターゲット指定します。後の手順では、構成ウィザードでクラスタの一部になるすべてのサーバーを表示します。

同じコンポジット・アプリケーションのすべてのUMSアダプタのアクティブ化において、同じ独自のApplicationName構成パラメータが使用されます。UMSアダプタでは、特定のエンドポイントがリッスンされている受信アドレスからアプリケーション名パラメータを合成します。

この合成により、クラスタ内の特定のコンポジットのすべてのアクティブ化において、アクセス・ポイントやメッセージ・フィルタなど、すべての構成およびアーティファクトの共有が可能になります。

ApplicationInstanceName構成パラメータはUMS API実装を使用して自動合成され、UMSアダプタはその合成に依存します。

さらに、UMSアダプタのAPI実装では、クラスタ環境内で2つのアプリケーションが同じメッセージを受信しないことが保証されます。

UMSアダプタは、クラスタ化環境でアクティブ/パッシブであるインバウンド・サービスのアクティブ・フェイルオーバーもサポートします。このアクティブ・フェイルオーバーは、JCAサービスのバインディング・プロパティ(composite.xml)シングルトンをtrueに設定することで、UMSアダプタ・サポートにおいて有効化できます。

リスニングおよびポーリングは、クラスタ化環境でもUMSアダプタを使用して非クラスタ化環境と同じ方法で動作します。

11.2.2.2.3 UMSアダプタのプロパティおよびMIMEタイプの構成

追加構成を指定するために使用可能なUMSアダプタと関連付けられたプロパティがいくつか存在します。これらの一部は、UMSアダプタ構成のアダプタ・ウィザードを使用する際にすでに設定されています。適用可能なすべてのインターネット・メール・ヘッダーおよびMIMEヘッダーは、正規化されたメッセージ・プロパティ/ヘッダーを使用して構成できます。

表11-2 には、UMSアダプタに適用可能なアクティブ化仕様プロパティがリストされています。

表11-2 UMSアダプタのアクティブ化仕様プロパティ

プロパティ名

説明

JavaCalloutImpl

メッセージ・フィルタまたはその他のチェックにカスタム・ロジックを定義するJavaクラス名。このクラスは、ICustomCalloutインタフェースの具体的な実装です。

ConsumeMode

アダプタによってUMSからメッセージを受信する方法を指定します。ポーリング・モードではポーラーに設定され、リスナー・モードではリスナーに設定されます。

To

受信メッセージの受信元となるアドレス。IM、SMSまたは電子メール配信タイプにおける1つまたは複数のカンマ区切りのIM、SMSまたは電子メール・アドレスです。

Delivery Type

送信メッセージの受信および送信用に電子メール・サポートを提供します。

PollingInterval

ポーラー・コンシューム・モードでのポーリング間隔(秒)です。

MessageFilters

1つまたは複数のメッセージ・フィルタが指定されます。単一フィルタの場合は、フィールド・タイプおよび取得されるアクション(同意または拒否)に対して受信メッセージを適合させるため、Javaのパターン文字列で構成されます。

表11-3 には、使用可能な相互作用仕様プロパティのリストが示されています。

表11-3 UMSアダプタの相互作用仕様プロパティ

プロパティ名

説明

Delivery Type

送信メッセージの受信および送信用の電子メール、IMおよびSMSサポート。

Subject

送信メッセージの件名。

From

送信メッセージの送信者アドレス。

To

1つ以上の受信者アドレス。

Reply-to

返信先アドレス。

CC

電子メール配信の1つまたは複数のCCアドレス。

Bcc

電子メール配信の1つ以上のBccアドレス。

SendEmailAsAttachment

添付ファイルとして電子メールを送信するにはTrueにします。

UMSアダプタでは、適用可能なすべてのインターネット・メッセージ・ヘッダーおよびMIMEメッセージ・ヘッダー、さらにMIMEパート・ヘッダー(マルチパート構成内)が公開されます。

MIMEヘッダーは、メッセージ本文の最初の部分であるUMSアダプタのペイロードにのみ適用できます。

添付ファイルのMIMEヘッダーは、BPELプロセス内から操作可能な正規化されたメッセージ・プロパティとして、添付ファイルとともに格納されます。

表11-4 では、インターネット・メッセージ・フォーマットで定義された適用可能なすべてのヘッダーの他、アダプタ・ヘッダーのマッピングおよび対応関係について説明します。

表11-4 メッセージ・ヘッダー

ヘッダー・フィールド名

最小発生数

最大発生数

Return-path

0

1

Received

0

無制限

Resent-Date

0

無制限

Resent-From

0

無制限

Resent-Sender

0

1

Resent-To

0

無制限

Resent-Cc

0

無制限

Resent-Bcc

0

無制限

Resent-Message-ID

0

無制限

Date

1

無制限

From

1

無制限

Sender

0

1

Reply-to

0

1

To

0

1

Cc

0

1

Bcc

0

1

Message-ID

0

1

In-Reply-To

0

1

References

0

1

Subject

0

1

Comments

0

無制限

Keywords

0

無制限

注意:

多くの場合は、BPELのinvokeアクティビティのプロパティ・タブを使用してjca.propertiesを選択し、その起動アクティビティから値を設定できます。ただし、jca.ums.message-idは、このメッセージIDが自動生成のため、設定できません。

表11-5 は、適用可能なすべてのMIMEメッセージ・ヘッダーについて説明しています。

アウトバウンドUMSアダプタの場合、JCA.UMS.MSG.CONTENT-TYPEプロパティを使用して、エンコーディングを指定できます。値を設定しない場合、アウトバウンドUMSアダプタでは、デフォルトで電子メールにUTF-8エンコーディングが使用されます。

表11-5 MIMEパート・メッセージ・ヘッダー

ヘッダー・フィールド名

マップされたアダプタのヘッダー・フィールド名

ノート

Content-Type

jca.ums.part.content-type

-

Content-Transfer-Encoding

jca.ums.part.content-transfer-encoding

-

Content-ID

jca.ums.part.content-id

-

Content-Description

jca.ums.part.content- description

-

Content-Disposition

jca.ums.part.content-disposition

-

Content-Language

jca.ums.msg.content-language

-

Mime-Extension-field

jca.ums.part.mime-extension-headers

その他のMIMEヘッダー・フィールドは、文字列のContent-で開始されます。次のように2つ以上のヘッダーを追加できます。Content-* : value CRLF Content*- : value

CRLF - \r\n

11.2.2.2.4 固有のヘッダー

.

UMSアダプタでは、固有のヘッダーを任意に追加できます。表11-6 に、必要な情報を示します。

表11-6 固有のヘッダー

ヘッダー名

ノート

jca.ums.msg.proprietary-headers

2つ以上の固有のヘッダーを次の書式で追加できます。

Header Name : value CRLF Header Name : value

(ヘッダー名は、ums.adapter.xxxxxのCRLF - \r\nに類似させる必要があります。)

11.2.2.3 電子メールの添付ファイル

UMSメッセージのXMLには、href属性を持つ添付要素のリストを含めることができます。Attachment Managerでは、MIMEタイプ、コンテンツIDの他、ストリーム・オブジェクト(アタッチメント・コンテンツ)などの添付ファイルと関連付けられた他のMIMEの詳細を格納します。

現在は、UMSアダプタでインバウンドとアウトバウンドの両方の添付ファイルがサポートされています。

添付要素を含むXMLメッセージの例は、次の例を参照してください。

例 - 添付要素を含むXMLメッセージの例

<Receive1_ReceiveEmail_InputVariable>
<part name="body" >
<Email>
<payload>This is a test mail.-Sagar</payload>
<attachment href=
"0DF86C104BF511EoAF5977BAA7C7CFD9"/>
</Email>
</part>
</Receive1_ReceiveEmail_InputVariable>

インバウンド側では、UMSアダプタにより、Attachment Managerに添付ファイルを渡す前にすべてのMIMEの詳細が設定されます。Attachment Managerは、Fabric Attachment Managerの内部コンポーネントで、添付コンテンツおよびMIMEヘッダーをデータベースに格納します。この機能により、異なるSOAコンポーネント間でリンク/href IDを渡すことができるようになります。

11.2.2.4 メールの添付ファイルの処理

UMSアダプタでは、Fabric Attachment Managerを使用して、添付ファイルの格納および取得が行われます。

UMSメッセージ・スキーマでは、href属性を使用して添付要素が定義されます。

例 - href要素を使用して添付要素を定義するUMSメッセージ・スキーマ

<Receive1_ReceiveEmail_InputVariable>
<part name="body" >
<Email>
<payload>This is a test mail.-Sagar</payload>
<attachment href=
"0DF86C104BF511EoAF5977BAA7C7CFD9"/>
</Email>
</part>
</Receive1_ReceiveEmail_InputVariable>

UMSメッセージのXMLには、href属性を持つ添付要素のリストを含めることができます。Attachment Managerでは、MIMEタイプ、コンテンツIDの他、ストリーム・オブジェクト(アタッチメント・コンテンツ)などの添付ファイルと関連付けられた他のMIMEの詳細を格納します。添付要素を含むXMLメッセージの例。

インバウンド側では、UMSアダプタにより、添付ファイルをAttachment Managerに渡す前にすべてのMIMEの詳細を設定し、アウトバウンド側では、UMSアダプタにより、添付オブジェクトと一緒に受信したすべてのMIMEの詳細を抽出し、送信SDPメッセージ通知の作成中に使用します。

Fabric Attachment Managerでは、添付ファイルをデータベースに格納した後に、キーを使用してhref属性を更新します。このキーを使用して、後でアタッチメント・コンテンツを取得できます。

正規化メッセージ・ペイロードのマップの例では、UMSアダプタからBPEL/Mediatorのサービス・エンジンに渡される添付要素を含むXML構造を使用します。

添付要素を含むXMLメッセージの例は次のとおりです。

<Receive1_ReceiveEmail_InputVariable>
<part name="body" >
<Email>
<payload>This is a test mail</payload>
<attachment href=
"0DF86C104BF511EoAF5977BAA7C7CFD9"/>
</Email>
</part>
</Receive1_ReceiveEmail_InputVariable>

11.2.2.4.1 BPEL内の添付ファイルと関連付けられたMIME情報の取得

次の例に、BPELでの添付ファイルの取得方法を示します。最初に、添付ファイルと関連付けられたMIME情報を取得します。

例 - 添付ファイルと関連付けられたMIME情報の取得

<assign name"Assign1">
<copy>
<from exporession="oraReadBnaryFromFileWithMimeHeaders
('/home/testuser/oracle_  sig_logo.gif','one',
'image/gif', ", '7bit',
'oracle_logo_gif_file', 'en/ja')"/>
<to variable="invoke="1_SendNotification_InputVariable"
part="body"
query='/ns3:message/ns3:attachment[1]"/>
</copy>
<bpelx:InsertAfter>
<bpelx:from variable=Invoke1_SendNotification
_InputVariable"
part="body" query=/ns3:message:
/ns3:attachment"/>
<bpelx:to variable=Invoke1_SendNotification_InputVariable"
part="body"
part="body" query=/ns3:message:/ns3:
attachment"/>

</bpelx:insertAfter>
<copy>
<from expression="ora.
readBinaryFromFileWithMimeHeaders
{'/home/testuser/
install-mq-7.0.txt',",","," '
install_mq_file',''}"/>
<to variable="Invoke1_SendNotification_InputVariable"
part="body"
query="/ns3:message/ns3:attachment[2]"/>
</copy>

11.2.2.4.2 BPEL内の複数の添付ファイルに対するMIME情報の設定

次のスニペットでは、BPEL内の複数の添付ファイルに対するMIME情報の設定方法を示します。

<assign name="Assign1">
<copy>
<from exporession="oraReadBnaryFromFileWithMimeHeaders
('/home/testuser/oracle_sig_logo.gif','one',
'image/gif', ", '7bit',
'oracle_logo_gif_file', 'en/ja')"/>
<to variable="invoke="1_SendNotification_InputVariable"
part="body"
query='/ns3:message/ns3:attachment[1]"/>

</copy>
<bpelx:InsertAfter>
<bpelx:from variable=Invoke1_SendNotification_InputVariable"
part="body" query=/ns3:message:/ns3:attachment"/>
<bpelx:to variable=Invoke1_SendNotification_InputVariable"
part="body"
part="body" query=/ns3:message:/ns3:attachment"/>

</bpelx:insertAfter>
<from exporession=
"oraReadBnaryFromFileWithMimeHeaders('/home/             testuser/oracle_  sig_logo.gif','one',
'image/gif', ", '7bit',    'oracle_logo_gif_file', 'en/ja')"/>
<copy>
<to variable="invoke="1_SendNotification_InputVariable"
part="body"
query='/ns3:message/ns3:attachment[2]"/>
</copy>

11.2.2.5 UMSアダプタのインバウンド操作およびアウトバウンド操作

UMSアダプタ構成ウィザードを使用して構成する操作には、次のインバウンド操作およびアウトバウンド操作が含まれます。

- Inbound Receive Notification

- Outbound Send Notification

- Outbound Send Notification (Message ID as Reply)

- アウトバウンド取得メッセージ・ステータス (UMSからメッセージ配信ステータス情報を受信するためにメッセージIDおよびオプションの受信者情報を指定するアウトバウンド同期リクエスト/リプライ)

11.2.2.5.1 Oracle UMSアダプタのインバウンド通知の受信の概念

このシナリオでは、UMSアダプタにより、UMSサーバーのアクセス・ポイントを登録し、受信通知の消費と処理を実行します。この項では、Oracle UMSアダプタのインバウンド受信通知に関連付けられた様々な構成と概念の概要を示します。

11.2.2.5.2 Oracle UMSのアウトバウンド通知の送信の概念

このシナリオでは、UMSアダプタにより、送信通知の送信を処理します。この項では、Oracle UMSアダプタのアウトバウンド送信通知に関連付けられた様々な構成と概念の概要を示します。この送信通知には、通常送信と、メッセージIDのリプライ・リクエストとしての受信を使用した送信の2種類があります。

11.2.2.5.3 メッセージIDのリプライ・リクエストとしての受信

アウトバウンド同期リクエストのタイプとして、「メッセージIDをリプライ・リクエストとして受信」があります。これは、起動方法の1つのバリエーションですが、メッセージIDをリプライ・リクエストとして受信を使用する場合は、UMSサーバーから一意のメッセージIDが返信されます。このメッセージIDを取得してメッセージの配信状態の情報をチェックする場合は、当該タイプのリクエストを使用できます。UMSは、メッセージング・ゲートウェイから受信したすべての配信ステータス情報を格納します。Fusion Middleware Controlを使用すると、メッセージIDを使用してこのステータス情報を取得できます。

このタイプのリクエストを使用する場合は、操作の選択時にメッセージIDをリプライ・リクエストとして受信チェック・ボックスを選択します。

11.2.3 Oracle UMSアダプタの構成

UMSアダプタを構成するには、Fusion Middleware ControlコンソールおよびJDeveloperの電子メール・アダプタ構成ウィザードを使用してユーザー・メッセージ・サービスを構成します。

ユーザー・メッセージング・サービス・ドライバを構成するには、Fusion Middleware Controlコンソールを使用します。特に、電子メール・メッセージング・チャネルを使用するには、特定のプロパティを構成する必要があります。次の項では、UMSアダプタの電子メール・ドライバの構成に関する情報を示します。

SMPP、XMPPおよびVoiceXMLドライバの構成の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle User Messaging Serviceの構成に関する項を参照してください。

11.2.3.1 UMSアダプタの電子メール・ドライバの構成 - アウトバウンド接続性

このプロシージャでは、必要な入力を指定して、電子メール・サーバーでのアウトバウンド接続性のためにUMSの電子メール・ドライバを設定します。

1. Fusion Middleware Controlを使用して電子メール・ドライバを構成するには、「ユーザー・メッセージング電子メール・ドライバ」→「電子メール・ドライバ・プロパティ」の順にクリックします。

2. OutgoingMailServerの場所にSMTPサーバー名を入力します。

3. OutgoingMailServerPortにSMTPサーバーのポート番号を入力します。通常は25です。

4. SMTPサーバーで使用するセキュリティのタイプを入力します。設定可能な値は「なし」、「TLS」および「SSL」です。デフォルト値は、Noneです。

5. OutgoingDefaultFromAddrでSMTP認証に使用するユーザー名を入力します。SMTP認証がSMTPサーバーでサポートされている場合のみ必要です。(かわりにOutgoingUsernameフィールドも使用できます。)

6. OutgoingPasswordにSMTP認証で使用するパスワードを指定します。これは、SMTP認証がSMTPサーバーでサポートされている場合に必要です。

図11-3 Fusion Middleware Controlコンソールの「電子メール・ドライバ・プロパティ」画面

11.2.3.2 UMSアダプタの電子メール・ドライバの構成 - インバウンド接続性

インバウンド・シナリオにおいて、UMSの電子メール・ドライバの設定で使用する必要がある最小構成は次のとおりです。

1. MailAccessProtocolと入力します。これは、電子メールの受信プロトコルです。設定可能な値はIMAPおよびPOP3です。この値は、電子メールの受信がドライバ・インスタンスでサポートされている場合のみ必要です。

2. ReceiveFolderの値を入力します。ドライバがメッセージをポーリングするフォルダの名前。デフォルト値はINBOXです。

3. IncomingMailServerの値を入力します。これは、受信メール・サーバーのホスト名です。電子メールの受信がドライバ・インスタンスでサポートされている場合のみ必要です。

4. IncomingMailServerPortの値を入力します。これは、IMAP4サーバー(143または993)あるいはPOP3サーバー(110または995)のポート番号です。

5. IncomingMailServerSSLの値を入力します。これにより、IMAP4サーバーまたはPOP3サーバーへの接続時にSSLを有効にするかどうかを指定します。デフォルト値は無効です。

6. IncomingMailIDsに電子メール・アドレスを入力します。これらは、ユーザー名に対応する電子メール・アドレスです。電子メールの受信がドライバ・インスタンスでサポートされている場合のみ必要です。

7. IncomingUserIDsにユーザー名のリストを入力します。これは、ドライバ・インスタンスのポーリング元のメール・アカウントにおけるユーザー名のリストです。各名前はカンマで区切られている必要があります(例: foo,bar)。電子メールの受信がドライバ・インスタンスでサポートされている場合のみ必要です。

8. IncomingUserPasswordsと入力します。これは、ユーザー名に対応するパスワードのリストです。ドライバ・インスタンスで電子メールの受信をサポートする場合にのみ必要となります。

注意:

電子メールIDのリストを指定する場合は、同じ順序でユーザーIDとパスワードを指定します。FMWコントロールで指定したのと同じ順序で1対1で対応する必要があります。

構成の詳細は、『Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。

11.2.3.3 ユーザー・メッセージングXMPPドライバの構成

UMS側では、図11-4 に示すように、Fusion Middleware ControlコンソールからXMPPドライバを構成する必要があります。

図11-4 ユーザー・メッセージングXMPPドライバの構成

11.2.3.4 ユーザー・メッセージングSMPPドライバの構成

UMS側では、次のように、Fusion Middleware ControlコンソールからSMPPドライバを構成する必要があります。

図11-5 ユーザー・メッセージングSMPPドライバの構成

11.2.3.5 ファイアウォール・トラバースのためのHTTPプロキシの構成

電子メール/XMPPまたはSMPPサーバーがファイアウォールの外側にあり、HTTPプロキシを構成する必要がある場合、UMSアダプタを構成する以外にトラバースを構成する必要があります。

たとえば、このようなトラバースは、setDomainEnv.sh.ファイルでJVM引数として構成できます。例:

JAVA_OPTIONS="${JAVA_OPTIONS} -Dhttp.proxySet=true
-Dhttp.proxyHost=www.proxy.myserver.com  -Dhttp.proxyPort=80

11.2.3.6 インバウンド接続性のためのアダプタ・サービスおよびBPELプロセスの設計

JDeveloper内のUMSアダプタ構成ウィザードを使用して、インバウンドUMSアダプタ参照を設計します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンに「UMSアダプタ」をドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。UMSアダプタには、必要に応じて、変更するために選択できるサービス名または参照名も表示されます。

図11-6 UMSアダプタ構成ウィザードの「ようこそ」画面

2. 「UMSアダプタ接続」ページで、「接続JNDI名」を入力します。ここでは、インバウンド接続のデフォルトJNDI名であるeis/ums/UMSAdapterInboundをJNDI名として指定します。

3. 図11-7 UMSアダプタ構成ウィザードの「接続」画面

4. UMSアダプタ構成ウィザードの「操作タイプ」画面で、実行する操作を選択します。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。インバウンド接続性の場合は、「操作」画面で、操作タイプとして「インバウンド受信通知」を選択し、「次へ」をクリックします。

図11-8 UMSアダプタ構成ウィザードの「操作」画面でのインバウンド受信操作タイプの選択

5. アダプタ構成ウィザードの「通知の詳細」ページでは、「ポーリング」または「リスナー」のモードを指定して、UMSサーバーから受信通知を受け取ることができます。

図11-9 UMSアダプタ構成ウィザードの「通知の詳細」画面

6. 「ポーリング」モードを選択すると、インバウンド・ポーリング・パラメータを指定できます。

- 「ポーリング頻度」。新規通知を取得するためにUMSをポーリングする頻度です。表示されるデフォルト値は、「ポーリング頻度」は6、「頻度単位」はseconds、「インバウンド・スレッド数」は1です。

- 「頻度単位」。頻度の単位として秒、時間、日または週を指定します。

- 「インバウンド・スレッド数」。ポーリング・スレッド数を指定します。

UMSアダプタは、受信ボックスでメッセージが使用可能になるまでメッセージを受信します。メッセージがまったくない場合にのみ、UMSアダプタは、この画面で指定するポーリング間隔においてスリープします。このスリープ・アクティビティにより、受信の多いメッセージ・ボリューム・シナリオにおいて、受信ボックスに大量のメッセージがマウントされることを回避します。各ポーリング・スレッドでは、1回に1つのメッセージが取得され、その処理と公開が実行されます。

7. 「リスナー」モードを選択すると、「リスナー・スレッドのメッセージ」の数を指定できます。このプロパティでは、UMSサーバー側のリスナー・ワーカー・スレッド数が制御されます。デフォルト値は1です。このプロパティを指定すると、UMSサーバーでは、受信通知を受け取るマルチスレッド非同期が指定されます。
ポーリング・モードは、メッセージを断続的にフェッチするために使用できるプル・メカニズムです。リスニング・モードを使用すると、メッセージが到着したときにリアルタイムで取得できます。どちらを使用するかは、ビジネスの実施シナリオによって変わります。

図11-10 UMSアダプタ構成ウィザードの「通知の詳細」での「リスナー」モードの選択

8. UMSアダプタ構成ウィザードの「通知の詳細」の第2ページでは、通知エンドポイント構成を使用して受信する通知のタイプを選択できます。通知のタイプに電子メール、SMSまたはIMを選択した後に、エンドポイント属性を構成します。たとえば、電子メールを選択した場合は、1つ以上の受信メール・アドレスとして他の属性の詳細を入力します。電子メール通知の受信元となるカンマ区切りの電子メール・メールボックス・アドレスを2つ以上指定できます。

図11-11 UMSアダプタ構成ウィザードの「インバウンド通知の詳細」画面の第2ページ

SMSを選択した場合、受信者アドレスは携帯電話番号になります。携帯電話番号の範囲も指定可能で、たとえば「16501230000, 16501234999」は16501230000から16501234999 (これを含む)までのすべての番号を意味します。

図11-12 SMSが選択された「インバウンド通知の詳細」画面

インスタント・メッセージングのインバウンド通知では、インスタント・メッセージングIDを指定できます。

図11-13 インスタント・メッセージングが選択された「インバウンド通知の詳細」

9. 「次へ」をクリックして続行するか、または「終了」をクリックし、受信メッセージに対してメッセージ・フィルタを構成せずに、UMSアダプタ構成ウィザードの使用を終了します。

10. 受信メッセージに対してメッセージ・フィルタを使用できます。メッセージ・フィルタには、一致基準とアクションが含まれています。一連のメッセージ・フィルタの指定が可能です。これは、指定された基準がメッセージと一致し、アクションを取得した場合に、着信(受信)メッセージに順番に適用されます。
たとえば、任意の必要なブラックリストを実装すると、指定した送信者アドレスからのすべてのメッセージを拒否できます。

この画面では、3つの異なるタイプのフィルタを指定できます。(Javaパターンまたは正規表現の詳細は、http://download.oracle.com/javase/7/docs/api/java/util/regex/Pattern.htmlで参照を参照し、http://download.oracle.com/javase/tutorial/essential/regexでチュートリアルを参照してください。)

a. ブラックリスト・フィルタ: ブラックリスト・フィルタは、受信メッセージの送信者アドレスを照合し、その送信者アドレスが指定のJavaパターンと一致した場合にそのメッセージを拒否します。(つまり、Java正規表現です。)

b. ホワイトリスト・フィルタ: ホワイトリスト・フィルタは、受信メッセージの送信者アドレスを照合し、その送信者アドレスが指定のJavaパターンと一致した場合にそのメッセージを承認します。

c. メッセージ・フィルタ: メッセージ・フィルタは、指定のパターンで示した任意のフィールドを照合し、指定したアクションに応じてメッセージを承認または拒否します。このフィールドには、CONTENT、HEADER、RECIPIENT、REPLYTO、SENDER、SUBJECTが含まれます。

メッセージ・フィルタに適用されるアクションは、メッセージのACCEPTまたはREJECTの2種類のみです。メッセージ・フィルタは、「メッセージ・フィルタ」ページで定義した順番と同じ順番で適用されます。

「終了」をクリックしてウィザードを使用した構成を完了するか、「次へ」をクリックして「Javaコールアウト」画面を続行し、追加フィルタの適用に使用可能なJavaクラスを指定します。

図11-14 UMSアダプタの「メッセージ・フィルタ」画面

11. 「Javaコールアウト」ページで、UMSアダプタによって呼び出し、指定したカスタム・ロジックを実行するJavaクラスの名前を指定します。

図11-15 UMSアダプタ構成ウィザードの「カスタムJavaコールアウト」画面

12. カスタムJavaコールアウトを指定する場合は、チェック・ボックスを選択し、テキスト・ボックスにクラス名を指定します。詳細は、この章のカスタムJavaコールアウト・クラスに関する項を参照してください。

13. 後に示すページで「終了」をクリックし、UMSアダプタ・サービスの構成を完了します。Oracle UMSアダプタの構成が終了すると、インバウンド・サービスにJCAファイルが生成されます。ファイル名は、アダプタ構成ウィザードの「サービス名」ページで指定したサービス名と同じです。後からウィザードを再起動して、操作定義を変更できます。

11.2.3.7 アウトバウンド接続性のためのアダプタ・サービスおよびBPELプロセスの設計

JDeveloper内のUMSアダプタ構成ウィザードを使用して、アウトバウンドUMSアダプタ参照を設計します。

1. 「コンポーネント」ウィンドウから「外部参照」スイムレーンに「UMSアダプタ」をドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「サービス」および「参照」ページが表示されます。

図11-16 UMSアダプタ構成ウィザードの「参照」の「ようこそ」画面

2. UMSアダプタの「サービス名」画面が表示されます。たとえば、アウトバウンド・サービス名にSendMailと入力します。

図11-17 UMSアダプタ構成ウィザードの「サービス名」画面のアウトバウンド送信メール操作

3. 「操作」画面で、「操作タイプ」としてOutboundを選択します。「操作名」のデフォルトはSendNotificationです。ここでは、SendEmailに変更します。メッセージがアウトバウンドの場合、これによって外部通知は同期または一方向で起動され、アウトバウンド通知リクエストを受け入れた後にUMSサーバーによって戻されるリプライとして一意のメッセージを受信するオプションが含まれます。

図11-18 UMSアダプタ構成ウィザードの「操作」画面でのアウトバウンド送信操作の選択

4. 「アウトバウンド通知の詳細」画面が表示されます。「電子メール」ボタンを選択します。「エンドポイントの構成」の詳細項目を入力するか、参照してそれらを検索します。また、指定したプライマリ・アドレスにフェイルオーバー・アドレスを指定できます。たとえば、scott.tiger@sport.com:failover-id@example.comなどです。このフェイルオーバー・アドレッシングは、To、CCおよびBccの各アドレスに適用されます。

「参照」ボタンをクリックし、「アイデンティティ・ルックアップ・ダイアログ」を使用してアイデンティティ・サービスを参照した上で、必要に応じてアドレス属性を検索および入力できます。「次へ」をクリックして続行するか、「終了」をクリックしてウィザードの使用を完了します。

図11-19 電子メールが選択された「アウトバウンド通知の詳細」画面

5. 「メッセージ」画面を使用して、UMS送信操作にメッセージを定義します。「不透明なメッセージ(Base64Binary)」または「文字列タイプのメッセージ」を選択する場合は、スキーマの「URL」および「スキーマ要素」を指定する必要はありません。スキーマの「URL」を選択する場合は、「スキーマ要素」を指定する必要があります。

アウトバウンド通知を作成する場合、SMSまたはインスタント・メッセージングも使用できます。この例では、電子メール通知を使用しています。

次のスクリーン・ショットでは、「インスタント・メッセージ」を選択しています。この場合、エンドポイント・アドレスはインスタント・メッセージ・アドレスになります。アドレスはカンマで区切ることができます。IM通知の受信元となるカンマ区切りのIMアドレスを2つ以上指定できます。指定するアドレスは、インスタント・メッセージングの形式にする必要があります。「参照」ボタンを使用して「アイデンティティ・ルックアップ」画面を表示し、選択するIMアドレスのルックアップを実行できます。

図11-20 IMが選択された「アウトバウンド通知の詳細」画面

次のスクリーン・ショットは、「SMS」が選択された「アウトバウンド通知の詳細」画面です。エンドポイントは携帯電話番号です。電子メール通知の受信元となるカンマ区切りのSMSメール・メールボックス・アドレスを2つ以上指定できます。必ずアドレスをカンマで区切ります。携帯電話番号の範囲も指定可能で、たとえば「16501230000, 16501234999」は16501230000から16501234999 (これを含む)までのすべての番号を意味します。

図11-21 SMSが選択された「アウトバウンド通知の詳細」画面

表示されている拡大鏡アイコンを使用すると、「アイデンティティ・ルックアップ・ダイアログ」を使用してアイデンティティ・サービスを参照し、アドレス属性を検索および入力できます。

すべてのメッセージング・チャネルに対して、デバイス・アドレスではなくユーザーまたはグループを指定することを選択できます。たとえば、USER:weblogicまたはGROUP:adminsと指定できます。

図11-22 UMSアダプタ構成ウィザードの「メッセージ」画面

6. 「終了」をクリックし、UMSアダプタ構成ウィザードの使用を完了します。

7. 「終了」画面が表示されます。UMSアダプタ構成ウィザードの使用を完了しておきます。「終了」をクリックして、画面上の指定された場所でのXSDおよびWSDLの作成を完了します。

注意:

Fusion Middleware Control内で、他のデプロイ済アダプタと同様にUMSアダプタの監視レポートを使用できます。ただし、Fusion Middleware Control内のUMSアダプタでは、EIS接続は接続が停止しているにもかかわらず接続済と表示されることに注意してください。

12 Oracle JCA Adapter for LDAP

Oracle LDAPアダプタは、LDAP V3準拠ディレクトリ・サーバーとの双方向接続を提供します。この章では、CRUD (作成、読取り、更新および削除)操作を実行するための参照としてLDAPアダプタをモデル化する方法と、ディレクトリ・サーバーでインバウンド公開サービスとしてLDAPアダプタをモデル化する方法について説明します。多くの場合、様々なユーザー、アプリケーション、ファイル、プリンタ、およびネットワークからアクセス可能なその他のリソースを記述する情報は、LDAPディレクトリという特殊なデータベース内に収集されます。LDAPディレクトリへのアクセスは、エンタープライズ・ワークフローの基本的な要件です。LDAPアダプタ構成ウィザードには、LDAPサーバーとの間でリクエストの送信やレスポンスの受信を行うLDAPサービスをモデル化するためのグラフィカルで直感的なインタフェースが備わっています。

図12-1 LDAPアダプタのアーキテクチャの図

図12-1 は、Oracle LDAPアダプタがCRUD操作の実行に使用できる同期/非同期サービス・インタフェースをターゲット・ディレクトリ・サーバーに公開する方法を示しています。ここでは、Oracle LDAPアダプタがソース・ディレクトリ・サーバーからの変更イベントをポーリングして、公開サービスとして使用できるようにこれらのイベントをパブリッシュする方法を示しています。また、LDAPアダプタは、DSMLv2リクエストを受け取ってターゲット・ディレクトリ・サーバーで実行し、DSMLv2レスポンスを返す、DSML同期サービスも提供します。

LDAPアダプタは、SOA SCA環境でのLDAPサーバーの構成とLDAPサーバーへの接続のための拡張ソリューションを提供します。ランタイム・コンポーネントでは、外部LDAPサーバーへの物理的な接続を提供します。これは参照として機能し、LDAPサーバーへのリクエストを送信するアウトバウンド・サービスをサポートします。また、LDAPサーバーで変更イベントをポーリングするインバウンド・サービスをサポートするサービスとしても機能します。

この章の内容は次のとおりです。

- LDAPの概念

- LDAPアダプタの構成

- Oracle LDAPアダプタの機能

- LDAPアダプタのサンプル

12.1 LDAPの概念

LDAP (Lightweight Directory Access Protocol)は、情報ディレクトリにアクセスするためのインターネット・プロトコルです。ディレクトリ・サービスとは、エントリと属性をディレクトリ内で管理するように設計された分散データベース・アプリケーションです。LDAPは、TCP/IP経由で実行されます。LDAPを使用すると、クライアントはエントリに基づいて様々なディレクトリ・サービスにアクセスできます。これにより、エントリおよびその属性は、アクセス制御に基づいてユーザーや他のアプリケーションに対して使用可能になります。

Oracle Adapter for LDAPは、LDAPv3定義の操作に対する豊富なサポートおよび拡張機能のサポートを提供しています。また、DSMLv2もサポートされているため、DSMLゲートウェイ・サービスとして使用できます。ソース・ディレクトリ・サーバーからの変更イベントをリスニングしてパブリッシュするようにアダプタを構成できます。また、アダプタでは、1回かぎりのメッセージ配信、高可用性、ポリシー・ベースの再試行とフォルト処理、自動フェイルオーバー、およびその他のいくつかの機能も保証しています。

この項には、次の項目が含まれます。

- LDAPのエントリ、属性および値

- LDAPのディレクトリ構造

- 識別名と相対識別名

- LDAPサービスおよびサービス・クライアント

- リフェラル

- エイリアス

- コントロール

12.1.1 LDAPのエントリ、属性および値

LDAPディレクトリには、エンティティに関連する情報を含むエントリが含まれます。エントリの各属性には、1つの名前と1つ以上の値が存在します。属性の名前は、一般名がcn、電子メール・アドレスがmailのように、一般的にニーモニック文字列となります。たとえば、ある会社が従業員ディレクトリを所有しているとします。この従業員ディレクトリの各エントリは従業員を表しています。従業員エントリには、名前、電子メール・アドレス、電話番号などの情報が含まれます。次の例を参照してください。

cn: John Doe
mail: johndoe@mydomain.com
mail: jdoe@mydomain.com
telephoneNumber: 471-6000 x.1234

記述情報のそれぞれの部分(従業員の名前など)は、属性と呼ばれます。例では、一般名(cn)属性が従業員の名前を表しています。この他に、mail属性とtelephoneNumber属性があります。

各属性には1つ以上の値が存在します。たとえば、1つの従業員エントリに、johndoe@mydomain.comおよびjdoe@oracle.comの値を持つmail属性が含まれることがあります。前述の例では、mail属性に2つのmail値が含まれています。

12.1.2 LDAPのディレクトリ構造

ディレクトリの編成はツリー構造になっています。ディレクトリ内の最上位のエントリは、ルート・エントリと呼ばれます。このエントリは通常、ディレクトリを所有する組織を表します。

階層レベルが高いエントリほど、大きいグループまたは組織を表します。大きい組織より下のエントリは、その大きい組織を構成する小さい組織を表しています。

ツリー構造のリーフ・ノード(エントリ)は、個々の個人またはリソースを表しています。

12.1.3 識別名と相対識別名

エントリは属性の集合で構成され、これらの属性は識別名(DN)と呼ばれる一意の識別子を持ちます。DNは、その階層レベルでエントリを一意に識別する名前です。

次の例では、John DoeとJane Doeは、同じレベルにある異なるエントリを識別する別々の一般名(cn)です。

また、DNは、エントリをツリーのルートまで遡ってトレースする名前の完全修飾パスでもあります。たとえば、John Doeエントリの識別名は次のようになります。

cn=John Doe, ou=People, dc=mydomain.com

相対識別名(RDN)は、識別名のコンポーネントです。たとえば、cn=John Doe, ou=Peopleは、ルートRDN dc=mydomain.comに対するRDNです。

DNはエントリの完全修飾パスを記述するために使用し、RDNはツリー内の別のエントリを基準にしたエントリのパスの一部を記述するために使用します。図12-2 に、識別名と相対識別名を含むLDAPディレクトリ構造の例を示します。

図12-2 LDAP階層ツリー

12.1.4 LDAPサービスおよびサービス・クライアント

ディレクトリ・サービスとは、エントリと属性をディレクトリ内で管理するように設計された分散データベース・アプリケーションです。また、ディレクトリ・サービスは、エントリおよび属性をユーザーや他のアプリケーションに対して使用可能にします。Oracle Internet Directoryサーバーは、ディレクトリ・サービスの一例です。他に、Oracle Directory Server Enterprise EditionやMicrosoft Active Directoryなどのディレクトリ・サービスがあります。

ディレクトリ・クライアントは、LDAPプロトコルを使用してディレクトリ・サービスにアクセスします。ディレクトリ・クライアントは、ディレクトリ・サービスにアクセスするために、使用可能なクライアントAPIのいずれかを使用できます。

12.1.5 リフェラル

Oracle LDAPアダプタAPIは、未指定のリフェラル基準に基づいて検索結果を問い合せます。検索結果には多数のリフェラルが含まれることがあります。リフェラルとは、クライアントのリクエストを別のサーバーにリダイレクトするために使用されるエンティティです。リフェラルには他のオブジェクトの名前と場所が含まれています。

たとえば、LDAPサーバーは、クライアントがリクエストした情報が別の場所(別のサーバーまたは複数のサーバーなど)に見つかる可能性があることを示すために、クライアントにリフェラルを送信します。

リフェラルには、実際のエントリが存在するLDAPサーバーのURLが含まれます。LDAP URLには、サーバーのホスト/ポートおよびオブジェクトのDNが含まれます。

12.1.6 エイリアス

Oracle LDAPアダプタAPIは、指定されたエイリアス遅延処理基準に基づいて検索結果を問い合せます。

エイリアスとは、現在のディレクトリ情報ツリー内のエントリの位置を定義するために使用されるエンティティです。エイリアスは、情報を含むエントリのDNを保持します。

12.2 LDAPアダプタの構成

次の各項では、LDAPアダプタの構成について説明します。

12.2.1 コントロール

コントロールは、LDAPで既存の操作を拡張するためのメカニズムを提供します。LDAPアダプタでは、コントロールをリクエスト操作とともに渡すことができます。

コントロールを操作リクエスト・メッセージとともに含めると、コントロール情報を使用して、操作の処理方法に関する追加情報を指定できます。

12.2.1.1 リクエスト・コントロールの形式

リクエスト・コントロールの形式は、name-criticality-valueのタプルです。

requestControls="controlName1|controlOID:criticality:prop1:value1:prop2:value2;

controlName|controlOidは、リクエスト操作とともに渡す必要のあるコントロールの一意の名前/OIDです。

criticalityは、リクエストとともに渡されたコントロールがターゲット・ディレクトリ・サーバーでサポートされていない場合の動作を指定するブール属性です。オプションで、リクエスト・コントロールに渡すことができる値を表す値文字列を指定できます。

12.2.1.2 LDAPコントロールの制限事項

LDAPアダプタでLDAPコントロールを使用する際には、いくつかの制限事項があります。

- criticalityをtrueとしてサポート対象外のコントロールを使用すると、例外が発生し、ターゲット・ディレクトリ・サーバーでLDAP操作は実行されません。

- 操作に適用可能なコントロールのみが実行されます。適用可能でないコントロールが操作とともに渡された場合、そのコントロールは無視されます。

- 1つの操作にのみ適用可能なコントロールもあれば、複数の操作に関連するコントロールもあります。たとえば、subtreeDeleteRequestControlは削除操作にのみ適用可能ですが、assertionRequestControlはすべての操作に適用可能です。

- LDAPアダプタが認識できないコントロールは汎用として処理されます。このようなコントロールの動作は明確に定義されていません。

- リクエスト・コントロールのみがサポートされています。LDAPアダプタでは、レスポンス・コントロールはサポートされていません。

ディレクトリ・サーバー、コントロールおよびLDAPアダプタ操作のリストは、表12-1 を参照してください。

表12-1 サポートされているディレクトリ・サーバー・コントロールおよびLDAPアダプタ操作

操作

コントロール(名前)

コントロール(OID)

Microsoft Active Directory

ODSEE (Oracle Directory Server Enterprise Edition)

OID

検索

ManageDsaITRequestControl

2.16.840.1.113730.3.4.2

サポートされていない

サポートされている

サポートされている

-

ServerSideSortRequestControl

1.2.840.113556.1.4.473

サポートされている

サポートされている

サポートされている

-

GetEffectiveRightsRequestControl

1.3.6.1.4.1.42.2.27.9.5.2

サポートされていない

サポートされている

サポートされていない

-

MatchedValuesRequestControl

1.2.826.0.1.3344810.2.3

サポートされていない

サポートされていない

サポートされていない

-

-

-

-

-

-

削除

SubtreeDeleteRequestControl

1.2.840.113556.1.4.805

サポートされている

サポートされていない

サポートされていない

-

-

-

-

-

-

変更

PermissiveModifyRequestControl

1.2.840.113556.1.4.1413

サポートされている

サポートされていない

サポートされていない

-

-

-

-

-

-

DNの変更

ウィザードに表示されるコントロールはありません。

-

-

-

-

12.2.1.3 設計時ウィザードでのデフォルト以外のコントロールの構成

LDAPアダプタ構成ウィザードでは、操作とともにリクエスト・コントロールを添付できます。「コントロールの添付」画面の動作は次のとおりです。

- デフォルトでは、操作に適用可能な、接続先のディレクトリ・サーバーでサポートされているコントロールのみがウィザードに表示されます。

- 例: 削除操作に適用可能なコントロールはassertionRequestおよびSubtreeDeleteですが、ターゲット・ディレクトリ・サーバーでサブツリー削除操作がサポートされていない場合、assertionRequestのみが表示されます。

- サポートされている他のコントロールを追加するように選択できます。これらのコントロールは汎用として処理されますが、これらのコントロールの実行時動作は明確に定義されていないため、これらのコントロールを十分にテストする必要があります。

12.2.1.3.1 コントロールの可用性

デフォルトでは、LDAP構成ウィザードには頻繁に使用される数個のコントロール名のみが表示されます。名前のないコントロールのコントロール名をウィザードに表示する場合は、次の手順に従ってコントロール定義を更新し、適切な名前と詳細を指定する必要があります。

1. ターミナル・ウィンドウで、SOAアダプタのJDeveloperプラグイン・ライブラリ・ディレクトリに移動します。

cd <install-dir>/soa/plugins/jdeveloper/integration/adapters/lib

2. LDAPアダプタjarを解凍します。

cd <install-dir>/soa/plugins/jdeveloper/integration/adapters/lib oracle/tip/adapter/ldap/config/control-oid.properties

3. oracle/tip/adapter/ldap/config/control-oid.propertiesを編集して、指定するコントロールおよび関連する詳細を入力します。

4. ファイルを再び圧縮して変更を含めます。

jar -uvf LdapAdapter.jar  oracle/tip/adapter/ldap/config/control-oid.properties

5. JDeveloperを再起動します。

12.2.2 LDAPブラウザ

「LDAPブラウザ」ページを使用して、ディレクトリ情報ツリー(DIT)を表示します。このブラウザは、LDAPアダプタ構成ウィザードで「参照」を選択すると呼び出されます。図12-3を参照してください。

図12-3 コンテキスト内で表示されるLDAPブラウザ

エントリを選択するには、DIT内のエントリを選択し、「OK」ボタンをクリックします。選択したエントリは、LDAPアダプタ構成ウィザードで以降に実行する検索操作やエントリ変更通知操作でベースDNとして使用したり、追加操作でテンプレートとして使用します。

12.2.2.1 属性ビューア

あるアイテムに関連する属性を表示するには、選択したエントリをダブルクリックします。

属性ビューアが2列のレイアウトで表示されます。左側の列には属性の説明(または名前)が含まれ、右側の列には属性値が含まれます。各行は名前と値のペアを表しています。直前のセクションの属性表に、現在のエントリの識別名が表示されます。図12-4を参照してください。

図12-4 LDAP構成ウィザードのブラウザの属性ビューア

12.2.2.1.1 折りたたみ

LDAPディレクトリのディレクトリ情報ツリーは、固有の階層構造で表示されます。階層の第1レベルにはベース・エントリが含まれます。エントリを展開すると、その直接の子がディレクトリからフェッチされます。ディレクトリの参照中、LDAPブラウザはフェッチされたエントリに子があるかどうかを調べます。子のないエントリは展開できません。

デフォルトでは、大きな参照結果は、それぞれ100個のエントリからなる仮想フォルダに折りたたまれます。このため、表示されるツリーは比較的小さくなります。パフォーマンスを向上させるため、フェッチされるアイテムの数は1000アイテムに制限されます。レコードが1000を超えるフォルダを操作する場合は、検索操作を使用できます。図12-5を参照してください。

図12-5 LDAPアダプタ構成ウィザードのLDAPブラウザのディレクトリ折りたたみ

12.2.2.1.2 検索

ブラウザで必要なエントリがロードされない場合は、代替アプローチとして検索操作を使用できます。1つの検索属性および値を指定することにより、DITを検索できます。検索はサブツリー全体にわたって処理されます。検索結果の量に関する制限はありません。

左側のコンボ・ボックスで、よく使用される属性のリスト(cn、givenName、mail、member、objectClass、sn、telephoneNumber、uniqueMember)から検索属性を選択できます。

グループであるエントリにわたって検索を処理することを指定するには、オプション「グループ」を使用します。

個人、アカウントまたはユーザーであるエントリにわたって検索を処理することを指定するには、オプション「ユーザー」を使用します。

右側の入力フィールドに検索値を入力します。必要に応じて、ワイルドカードとして'*'を使用します。

図12-6 LDAP構成ウィザードのLDAPブラウザ内で検索操作に対してワイルドカードを指定

検索操作を開始するには、右側にある緑色の三角形ボタンを選択します。左側のコンボ・ボックスで「FilterType.LDAPFilter」を選択して、右側のフィールド内に手動でLDAP検索フィルタを設定します。

図12-7 LDAP構成ウィザードのLDAPブラウザ内で検索操作に対してフィルタを指定

12.3 Oracle LDAPアダプタの機能

LDAPプロトコルおよびLDAPアダプタは、ディレクトリ情報への高速な読取りアクセスを提供します。この項で詳しく説明するように、LDAPアダプタではインバウンド・メッセージとアウトバウンド・メッセージの両方がサポートされており、次の機能が組み込まれています。

- LDAPアダプタの構成

- アウトバウンド操作

- インバウンドLDAPアダプタの機能

- LDAPブラウザ

注意:

LDAPアダプタでは、アウトバウンド・メッセージに対するトランザクション・サポートを提供していません。

12.3.1 LDAPアダプタの構成

LDAP構成ウィザードを使用してLDAPアダプタを構成し、コンテキスト・メニューからオプションを選択したり、LDAPディレクトリ・スキーマを参照することにより、LDAPサービスをモデル化します。LDAPアダプタ・ウィザードでは、ターゲットLDAPディレクトリ・サーバーへの接続が必要であり、その構成方法は次のとおりです。

1. 「コンポーネント」ウィンドウから「公開されたサービス」または「外部参照」スイムレーンにLDAPアダプタ・コンポーネントをドラッグ・アンド・ドロップします。LDAP構成ウィザードで「ようこそ」画面の「サービス名」が表示されます。

2. 「ようこそ」画面の「サービス名」が表示されます。サービスの名前を入力します。「次へ」をクリックします。「サービス接続」画面が表示されます

接続が使用可能でない場合は、「新規接続の作成」を使用して新しい接続を作成します。図12-22 LDAPアダプタ構成ウィザードの「サービス接続」画面

3. 「新規接続の作成」ダイアログでは、ユーザーはターゲットLDAPサーバーに接続できます。

この画面では、ターゲット・ディレクトリ・サーバーに接続するために必要なネットワーク・パラメータを指定できます。次のように入力します。

- 接続名: この情報をバインドするために使用するこの接続の文字列値。

- 接続タイプ: 現在、LdapV3 (デフォルト)のみがサポートされています。

- ホスト名: LDAPサーバーが実行されているマシンの名前またはIPアドレス。

- ポート: LDAPサービスが実行されている場所。暗号化メソッドがSSLの場合は、SSLポートを使用します。

- 暗号化メソッド:

- 暗号化なし: 暗号化されていないチャネル

- SSLの使用: SSL接続

- startTLSの使用: 暗号化されていない接続を介したセキュアなチャネル

- トラストストア: サーバー認証に使用されるトラスト・ストアのパス

- トラストストア・パスワード: トラストストアにアクセスするためのパスワード

特定のディレクトリ・サーバーにバインドするための認証パラメータ

- 匿名: ネットワーク・パラメータが指し示しているディレクトリ・サーバーに匿名でバインドします。ほとんどのLDAPサーバーの構成では匿名バインドがデフォルトになっていないため、ターゲット・ディレクトリ・サーバーで匿名バインドを有効にする必要があります。

- 簡易認証: ユーザー名とパスワードの認証。

接続のテスト。LDAPアダプタ構成ウィザードで接続構成をテストします。テスト接続により、構成済のネットワーク・パラメータを使用してディレクトリ・サーバーへの接続が確立され、構成済の認証パラメータを使用してディレクトリ・サーバーにバインドされます。

12.3.2 LDAPアダプタのJNDI接続プール・プロパティ

表12-2 に、LDAPアダプタのJNDI接続プール・プロパティを示します。

表12-2 LDAPアダプタのJNDI接続プール・プロパティ

プロパティ名

説明

デフォルト

必須

bindDN

ディレクトリ・サーバーにバインドする必要のある識別名。例: cn=orcladmin

cn=Directory Manager

はい(匿名以外の認証方式を使用する場合に必要です。)

hostName

ディレクトリ・サーバーのホスト名。

localhost

はい

inboundDataSource

有効なXAデータソースを指すJNDI文字列の場所。例: jdbc/SOADataSource

なし

はい(インバウンド方向でLDAPアダプタを使用する必要がある場合)

operationTimeout

操作のタイムアウトを設定します。レスポンスがタイムアウト期間にディレクトリ・サーバーから受信されない場合、操作は中止され、例外が発生します。例: 1000

False

いいえ

password

ディレクトリ・サーバーのパスワード。

welcome

はい(匿名以外の認証方式を使用する場合に必要です。)

port

ディレクトリ・サーバーが稼働しているポート。

389

はい

hostName

ディレクトリ・サーバーのホスト名。

Localhost

はい

port

LDAPサービスが実行されているポート。

389

はい

securityProvider

SecurityProviderはSSLコンテキストで使用されるプロバイダURLです。例: ldaps://myhost.example.com:636

なし

いいえ

SSLContextProtocol

キー管理プロトコル。例: SSLl

なし

いいえ。useSSLまたはstartTLSを選択した場合のみ必須です。

trustAll

trueに設定した場合、クライアントは、サーバーが提示する証明書を無条件に信頼します。

ture

いいえ。useSSLまたはstartTLSを選択した場合のみ必須です。サーバー証明書をトラスト・ストアで検証する必要がある場合は、falseに設定します。

trustStorePassword

トラスト・ストアのコンテンツにアクセスするために必要なパスワードを指定します。

なし

いいえ

trustStorePath

クライアントがサーバー認証に使用するトラスト・ストア・ファイルへのファイル・システム・パスを指定します。

false

いいえ。SSLまたはstartTLSを使用する場合のみ必須です。

trustStoreProvider Name

Javaプロバイダ名。例: JKS

なし

いいえ、SSLまたはstartTLSを使用する場合のみ必須です。

UseSSL

セキュアなチャネルを確立する必要があるかどうかを指定します。

False

いいえ

useStartTLS

プレーンな非SSL接続において、後でセキュアな接続のためにstartTLSを有効にする場合に指定します。

False

いいえ、useSSLがtrueに設定してある場合はtrueに設定しません。これは非SSLプレーン・ポートをサーバー接続に使用する場合に有効にする必要があります。

注意:
デフォルト値をサポートされているターゲット・ディレクトリ・サーバーのインストールから取得した実際の値と置き換え、最新のデプロイメント・プランでLdapAdapterを再デプロイします。

12.3.3 アウトバウンド操作

LDAPアダプタでは、LDAPアダプタからの次のアウトバウンド操作をサポートしています。

- 追加

- 削除

- 変更

- DNの変更

- 比較

- 検索

- DSML

注意:
LDAPアダプタでは、アウトバウンド操作に対するトランザクション・サポートを提供していません。

12.3.3.1 追加操作

追加操作では、特定のDNおよび一連の属性を持つエントリを追加します。追加するエントリがすでに存在する場合や、指定された操作を完了できなかった場合は、エラーが返されます。

LDAP構成ウィザードの追加操作を使用するには、次の手順を実行します。

1. 「操作タイプ」画面で、「追加」操作を選択します。LDAPアダプタ構成ウィザードの「追加」画面が表示されます。

図12-8 LDAPアダプタ構成ウィザードの「追加」画面

2. 「既存エントリをテンプレートとして使用」または「追加するエントリの構造の定義」(デフォルト)を選択します。「既存エントリをテンプレートとして使用」を選択した場合、右側にある四角形をクリックして既存のテンプレートを参照します。「既存エントリをテンプレートとして使用」を選択した場合、既存のエントリのすべてのオブジェクト・クラスおよび属性を使用して追加リクエストが定義されます。オブジェクト・クラスおよび属性を追加または削除して、追加リクエストの形式を変更できます。

3. 「追加するオブジェクト・クラスの選択」セクション内の左側のリストに、追加するすべてのオブジェクト・クラスが表示されます。左側の列で追加するオブジェクト・クラスを選択して、右側の列に移動します。1つ以上のオブジェクト・クラスを選択できます。「追加」では、選択したオブジェクト・クラスが右側に表示されます。削除するオブジェクト・クラスを選択するには、そのオブジェクト・クラスを選択してそのクラスの「削除」矢印ボタンをクリックします。

4. 「属性」リストからさらに属性を選択できます。選択したオブジェクト・クラスの必須属性を、選択した属性に自動的に追加できます。選択したオブジェクト・クラスからアイテムを選択すると、そのオブジェクト・クラスに属する属性が使用可能な属性アイテム・リストに表示されます。

対応するオブジェクト・クラスが含まれていない属性は、自動的に削除されます。「削除」矢印ボタンを使用すると、属性を削除できます。

5. 抑止エントリの追加画面が表示されます。抑止エントリの追加画面を使用して、エントリが存在するのに再びそのエントリを追加しようとした場合に、このようなエラーを抑止できるようにします。

6. 「次へ」をクリックします。

7. 「終了」画面に、LDAPサービスのWSDLファイル、xsdファイルおよびjcaファイルの名前が表示されます。

12.3.3.2 削除操作

LDAPの削除操作では、特定のDNを持つエントリを削除します。オプションで、LDAP削除リクエストとともにコントロールを追加できます。削除操作では、指定されたエントリを削除できない場合やエントリが存在しない場合、エラーが返されます。また、リクエスト・メッセージに添付されたクリティカル・コントロールがターゲット・ディレクトリ・サーバーでサポートされていない場合にもエラーが返されます。

削除操作を使用するには、次の手順を実行します。

1. 「操作タイプ」画面で、「削除」操作を選択します。「削除」(抑止エントリ)画面が表示されます。

図12-9 LDAPアダプタ構成ウィザードの「削除」画面

2. 「削除」画面が表示されます。削除するエントリが存在しない場合にエラーが表示されないようにするには、「抑止エントリは存在しません」チェック・ボックスを選択します。「次へ」をクリックします。

3. 「コントロールの添付」画面が表示されます。図12-10を参照してください。

「コントロールの添付」画面では、削除操作に対して追加の制約を提供するためのコントロールを添付できます。コントロールを添付するか、「次へ」をクリックできます。LDAPアダプタとターゲット・ディレクトリ・サーバーでサポートされているコントロールを添付する場合は、「添付」チェック・ボックスを選択して、削除要求操作とともにコントロールを組み込みます。コントロールの詳細は、「LDAPアダプタ構成」の「コントロール」の項を参照してください。

図12-10 LDAP構成ウィザードの削除操作の「コントロールの添付」画面で追加された削除コントロール

4. 「次」を選択します。「終了」画面に、LDAPサービスのWSDLファイル、xsdファイルおよびjcaファイルの名前が表示されます。

12.3.3.3 変更操作

LDAPの変更操作では、ディレクトリ・サーバーの既存のエントリを変更します。

変更で実行できる変更のタイプは、「追加」、「削除」および「置換」です。

- 追加: 属性が存在しない場合は属性を作成し、指定した値を追加します。属性がすでに存在する場合、指定した値が属性値に追加されます。追加操作では少なくとも1つの値が存在する必要があり、また属性のすべての値が一意である必要があります。

- 削除: 指定した値を属性から削除します。値が指定されていない場合、または属性のすべての既存値が指定されている場合、その属性は削除されます。必須の属性を削除することはできません。

- 置換: 必要に応じて属性を作成し、属性のすべての既存値を指定した値で置き換えます。複数の値を持つ属性の既存の値を保持する場合は、それらの値を置換操作で指定する必要があります。値を指定せずに置換操作を実行すると、属性が存在していれば属性全体が削除され、属性が存在していなければ無視されます。すべての操作が成功するまで、ディレクトリに対する変更は行われません。変更中に接続が失敗した場合、変更が行われたかどうかは予測できません。

LDAP構成ウィザードの変更操作を使用するには、次の手順を実行します。

1. 「操作タイプ」画面で、「変更」操作を選択します。「変更」操作画面が表示されます。

図12-11 LDAP構成ウィザードの変更操作のオブジェクト・クラス選択ページ

2. このページで、「オブジェクト・クラス」のリストから選択します。変更する属性の「選択可能」リストから、変更可能な属性を選択して「選択済」に移動します。左矢印キーを使用して、選択済リストから削除することもできます。「次へ」をクリックします。

3. 「コントロールの添付」ページが表示されます。図12-12を参照してください。
緑色の＋を使用して、カスタム・コントロールか、ターゲット・ディレクトリ・サーバーで提供されているコントロールを追加します。次に例を示します。必要なコントロールを選択し、「値」列に値を入力して指定します。

注意:

サポートされているコントロールについては、ターゲット・ディレクトリ・サーバーのドキュメントを参照してください。コントロールを添付する前に、この章の関連操作を確認してください。ターゲット・ディレクトリ・サーバーでサポートされているすべてのコントロールがLDAPアダプタでサポートされているとはかぎりません。

図12-12 LDAP構成ウィザードの変更操作の「コントロールの添付」ページ

4. 「Next」をクリックします。変更の「終了」画面に、LDAPサービスのWSDLファイル、xsdファイルおよびjcaファイルの名前が表示されます。

12.3.3.4 DNの変更操作

LDAPのDNの変更操作は、ディレクトリ・サーバーのエントリの識別名を変更するために使用できます。また、エントリのRDNを変更したり、エントリを新しい親の下に移動できます。ターゲット・エントリが下位エントリを保有する場合は、サブツリーの移動または名前の変更に使用する場合があります。

DNの変更操作を使用するには、次の手順を実行します。

1. 「操作タイプ」画面で、「DNの変更」操作を選択します。LDAPアダプタ構成ウィザードの「DNの変更」画面が表示されます。図12-13を参照してください。

図12-13 LDAPアダプタ構成ウィザードの「DNの変更」画面

2. 古いRDNを削除する場合は、「古いRDNの削除」チェック・ボックスを選択します。DNを変更するが、古いRDNを削除しない場合は、このチェック・ボックスを選択しないでください。どちらかを選択した後、「次へ」をクリックします。

3. ステップ2でどちらかを選択すると、「コントロールの添付」ページが表示されます。図12-14を参照してください。

「コントロールの添付」画面では、DNの変更に対して追加の制約を提供するためのコントロールを選択して添付できます。

使用可能なコントロールは、ディレクトリ・サーバーによって異なります。コンソールを添付するように選択した場合は、緑色の+記号を選択してコントロールを追加します。必要なコントロールを選択し、「値」列に値を入力して指定します。サポートされているコントロールについては、ターゲット・ディレクトリ・サーバーのドキュメントを参照してください。コントロールを添付する前に、「LDAPアダプタ構成」の「コントロール」の項で関連操作を確認してください。ターゲット・ディレクトリ・サーバーでサポートされているすべてのコントロールがLDAPアダプタでサポートされているとはかぎりません。

4. 選択画面が表示されたら、ターゲット・ディレクトリ・サーバーでサポートされているコントロールを追加するか、カスタム・コントロールを追加するかを選択できます。

図12-14 LDAPアダプタ構成ウィザードの「コントロールの添付」の選択画面

5. ターゲット・ディレクトリ・サーバーでサポートされているコントロールか、カスタム・コントロールを選択します。

コントロールを添付するように選択した場合は、次のようなページが表示されます。

図12-15 では、新しいカスタム・コントロールとディレクトリ・サーバーで使用可能なコントロール("MatchedValues...")と一致するコントロールの両方がコントロールとして追加されています。

図12-15 LDAP構成ウィザードの「コントロールの添付」ページ

6. 「次へ」をクリックします。

7. 「終了」画面に、LDAPサービスのWSDLファイル、xsdファイルおよびjcaファイルの名前が表示されます

12.3.3.5 比較操作

LDAPの比較操作では、指定したエントリに特定の属性値が含まれるかどうかを判別します。

LDAPアダプタの比較操作を使用するには、次の手順を実行します。

1. LDAPアダプタの「操作タイプ」画面で、「比較」操作を選択します。

図12-16 「比較」が選択されたLDAP構成ウィザードの「操作タイプ」画面

2. 「次へ」をクリックします。

3. 「終了」画面に、LDAPサービスのWSDLファイル、xsdファイルおよびjcaファイルの名前が表示されます。

12.3.3.6 検索操作

LDAPアダプタの検索操作は、ディレクトリ・サーバーで特定の基準セットに一致するエントリを特定するために使用できます。0個以上のエントリ、また0個以上のリフェラルを返す場合があります。検索操作では次の基準が使用されます。

- ベースDN: 検索を実行するDIT内の位置を指定します。

- 検索スコープ: 検索処理の対象として考慮する、ベースDNのエントリまたはその下のエントリのスコープを指定します。

- 処理中に別名を検出した場合に使用する間接参照ポリシー。

- 検索で返されるエントリの最大数を指定するサイズ制限です(–1の場合、検索結果は制限されません)。

- 時間制限: サーバーが検索処理に費やす時間の最大の長さを(エントリの最大数を指定しない場合はゼロ)を秒単位で指定します。

- タイプのみフラグ: 返されたエントリに属性タイプのみを含めるか、タイプと値の両方を含めるかを示します。

- 検索フィルタ: 一致するエントリを特定するために使用する基準を指定します。

- 検索属性: 一致するエントリに含める属性を指定します。

- 検索リクエストとともに添付可能なコントロール: リクエスト・メッセージとともに添付されたクリティカル・メッセージがターゲット・ディレクトリ・サーバーでサポートされていない場合、エラーが返されます。

注意:

現在のバージョンでは、バイナリ型はサポートされず、属性値はutf8文字列として必ずエンコードされます。

アウトバウンド検索操作を使用するには、次の手順を実行します。

1. 「操作タイプ」画面で、「検索」操作を選択します。図12-17を参照してください。

図12-17 「検索」が選択されたLDAP構成ウィザードの「操作タイプ」ページ

2. LDAP構成ウィザードの検索構成ページが表示されます。図12-18を参照してください。

「リクエスト構成の検索」ページを使用して、検索スコープ、検索リフェラルおよび検索エイリアス遅延処理に関連する検索情報を指定します。

図12-18 LDAPアダプタ構成ウィザードの検索構成での「リクエスト構成の検索」ページ

3. 画面上部には、他の各セクションの上にデフォルト検索ベースおよびデフォルト検索フィルタが表示されます。「デフォルト検索ベース」テキスト・ボックスで、検索ベースを指定します。デフォルト検索ベースDNとデフォルト検索フィルタが考慮されるのは、これらの属性がLdapSearchRequestで定義されていない場合のみです。
検索操作スキーマxsdに次が追加されます。

<element name="searchRequest">
<complexType>
<sequence>
<element name="baseDN" type="string" default="dc=oracle,dc=com"/>
<element name="searchFilter" type="string" default="(objectClass=*)"/>
</sequence>
</complexType>
</element>

「参照」ボタンを選択すると、検索ベースを指定できるディレクトリ情報ツリー・ブラウザ・ダイアログが開きます。詳細は、「LDAPブラウザ」を参照してください。

これは、イベントのソースを定義するベースDNです。このDNを選択すると、その下のイベントを通知することを指定します。

4. 「デフォルト検索フィルタ」テキスト・ボックスで、検索操作で返されるエントリをフィルタで絞り込むための検索フィルタを指定します。このフィルタは、検索フィルタの文字列表記にすることができます。LDAP検索フィルタに関するドキュメントの詳細は、Oracle Fusion Middleware Oracle Directory Server Enterprise EditionリファレンスのLDAP検索フィルタの項を参照してください。

5. 「検索スコープ」は、ツリー内の検索スコープを定義します。これは、制御側サーバー・リソースからの不正な検索リクエストを制御するためにサービス・デプロイで定義する必要があります。

このオプションを使用する前に、ディレクトリ・サーバーをチェックしてください。次のスコープを指定できます。

- サブツリー全体: サブツリー内のすべてのエントリのスコープを指定する場合は、これを選択します。

- 最初の子のみ: 検索ベースの1レベル下のスコープのみを指定する場合は、これを選択します。

- ルートのみ: 検索ベースの1イベントのみを指定する場合は、これを選択します。

6. 次のセクションは「リフェラルの検索」です。リフェラルとは、LDAPアダプタがリクエストした検索操作を実行するために別のLDAPサーバーに接続するように指示する、LDAPアダプタに返されるレスポンスです。

リフェラル・セクションで、次のいずれかを選択します。

- 無視: これを選択すると、LDAPアダプタはリフェラルを無視し、ローカル・サーバーの検索操作で返された結果をそのまま返します。

- 例外のスロー: これを選択すると、LDAPサーバーはリフェラルを追跡せず、ローカル・サーバーからの結果を返して検索を完了することもしません。サーバーはこのかわりに例外をスローし、それに基づいてアクションを開始できます。

- フォロー: これを選択すると、リフェラル・サーバーをフォローします。これらは、検索リクエストの一部として追加エントリを検索/照合できる代替の場所です。デフォルトでは、LDAPアダプタは、フォローまたは例外をスローするように明示的に要求された場合を除き、リフェラルのすべての提案を無視します。(この検索には時間がかかる可能性があるため、ノンブロッキング・アクティビティにする必要があります。)

- ホップ制限: これを選択して、検索リフェラルに参加する代替場所の数を指定します。これは正の整数にする必要があります。デフォルト値は1です。

7. 次のセクションは「エイリアス遅延処理の検索」であり、検索処理中にエイリアス・エントリを処理するLDAPサーバーの動作(具体的にはエイリアス遅延処理エントリに関連する動作)を指定します。次のいずれかを選択します。

- なし: サーバーで見つかったエイリアスの遅延処理を行わないように指定する場合は、これを選択します。

- 検索: サーバーでエントリ候補の調査中に見つかったエイリアスの遅延処理を行うが、それがエイリアス・エントリであったときにはベース・エントリの遅延処理を行わないように指定する場合は、これを選択します。

- 検出: ベース・エントリがエイリアス・エントリであったときにはサーバーでその遅延処理を行うが、エントリ候補の調査中に見つかったエイリアス・エントリの遅延処理は行わないように指定する場合は、これを選択します。

- 常に: ベース・エントリがエイリアス・エントリであったときにはサーバーでその遅延処理を行い、候補の調査中に見つかったエントリの遅延処理も行うように指定する場合は、これを選択します。

「次へ」をクリックして次のページに進むか、「終了」をクリックして検索操作の構成を終了します。

8. 「次へ」をクリックすると、LDAP検索(レスポンス属性)ページが表示されます。詳細は、図12-19を参照してください。

「検索」(レスポンス属性)ページを使用して、ターゲットのLDAPディレクトリ・サーバーで使用可能なオブジェクト・クラスを使用して検索操作レスポンスのパラメータを構成します。

図12-19 LDAPアダプタ構成ウィザードの「検索」(レスポンス属性)ページ

9. 接続先のターゲット・ディレクトリ・サーバーのスキーマで選択可能なすべてのオブジェクト・クラスが表示された「選択可能」オブジェクト・クラス・リスト・ボックスからオブジェクト・クラスを選択します。

10. 「選択可能」属性リスト・ボックスに、選択したオブジェクト・クラスに属するすべての属性が表示されます。「選択可能」属性から選択し、矢印をクリックして使用可能な属性を「選択済」に移動します。

2つ以上のオブジェクト・クラスを選択した場合、すべての属性の集合が表示され、共通の属性は2回表示されません。

図12-20 に例を示します。

図12-20 LDAPアダプタ構成ウィザードの「検索」(レスポンス属性)ページの使用例

11. 「次」を選択します。「検索」の「構成パラメータ」ページが表示されます。図12-21を参照してください。

図12-21 LDAPアダプタ構成ウィザードの「検索」の「構成パラメータ」ページ

12. このページで、次の構成パラメータを指定します。

- 属性デリミタ: ユーザーにより選択された属性を区切る文字列リテラル値を指定します。

- 時間制限: 結果が返されるまでサーバーが待機する最大時間。整数値(秒数) (デフォルト値は0で時間無制限)です。

- サイズ制限: 検索結果に返されるイベントまたはエントリの最大数。整数値(デフォルト値は1000)です。検索結果でイベントまたはエントリの数を制限しない場合は–1を設定します。

- タイプのみ: 属性の名前と値の両方ではなく属性の名前のみを返す場合は、このチェック・ボックスを選択します。

「次へ」をクリックして、次のページに進みます。

13. 「コントロールの添付」ページが表示されます。ここで、LDAP検索操作に対して追加の制約を指定するためのコントロールを添付できます。+を使用して、カスタム・コントロールか、ターゲット・ディレクトリ・サーバーで提供されているコントロールを追加します。必要なコントロールを添付し、「値」列に値を入力して指定します。

注意:
サポートされているコントロールについては、ターゲット・ディレクトリ・サーバーのドキュメントを参照してください。コントロールを添付する前に、「LDAPアダプタ構成」の「コントロール」の項で関連操作を確認してください。ターゲット・ディレクトリ・サーバーでサポートされているすべてのコントロールがLDAPアダプタでサポートされているとはかぎりません。

14. 「終了」画面に、LDAPサービスのWSDLファイル、xsdファイルおよびjcaファイルの名前が表示されます。

12.3.3.7 DSML操作

DSML操作では、LDAPリクエストおよびレスポンスをXMLドキュメント・フラグメントとして表示します。LDAPアダプタの「Dsml」画面を使用して、DSMLリクエストを実行するように指定し、オプションでLDAPの操作画面でそのDSMLリクエストの最大リクエスト・サイズを入力します。

DSML実行リクエストを使用するには、次の手順を実行します。

1. LDAPの「操作タイプ」画面で、「Dsml」を指定します。

2. 「Dsml」画面が表示されます。図12-22を参照してください。
この画面で、オプションで「最大DSMLリクエスト・サイズ」を入力します。DSMLバッチ・リクエストに関与できる最大リクエスト数を制御する場合は、このプロパティを設定します。着信DSMLリクエストは、含まれているリクエストの合計数がこの数字未満の場合にのみ実行されます。

図12-22 LDAPアダプタ構成の「DSML構成」ページ

3. 「Next」をクリックします。DSML操作の「終了」画面に、LDAPのWSDLファイル、jcaファイルおよびxsdファイルが表示されます。

12.3.4 インバウンドLDAPアダプタの機能

LDAPアダプタでは、ディレクトリ・サーバーからのイベントのパブリッシュをサポートしています。具体的には、一方向のインバウンド相互作用、非同期通知モデルを介したディレクトリ・サーバーからの非同期イベントのパブリッシュをサポートしています。

LDAPアダプタは、ディレクトリ情報ツリー内のエントリの追加、削除、変更などのイベントをリスニングして、このようなイベントをパブリッシュします。LDAPイベント・コンシューマ・シングルトンは、選択された計画に従ってディレクトリ・サーバーに接続して変更をリスニングし、このようなイベントを処理してLDAPアダプタ・クライアントにパブリッシュします。

デフォルトでは、LDAPアダプタはイベントをディレクトリ・サーバーから受信した順にパブリッシュします。

LDAPアダプタには、2つのタイプのインバウンド・アクティビティがあります。

- LDAPアダプタのエントリ変更通知

- LDAPアダプタの変更ログ通知

12.3.4.1 LDAPアダプタのエントリ変更通知

エントリ変更通知を使用すると、ソース・ディレクトリ・サーバーで作成または変更されたエントリを取得できます。結果には、変更されたエントリおよび変更タイプに関する情報が含まれます。

このメカニズムはタイムスタンプ・ベースの検索に基づいているため、外部構成を必要とせず、ほとんどのディレクトリ・サーバーでサポートされています。時間ベースの検索では、ベース・タイムスタンプ以降のすべてのエントリに対して検索が実行されます。ベース・タイムスタンプは、後続のタイムスタンプ・ベースの検索のために更新されます。

検索では、LDAPアダプタが最後のタイムスタンプまでの結果を返し、その後、ベース・タイムスタンプを最後のタイムスタンプに更新します。構成した時間間隔は、すべてのイベントに対するタイムスタンプ・ベースの検索の繰返しが次に行われる日時を示します。

タイムスタンプ・ベースの検索では、追加または変更されたエントリの通知のみが行われます。エントリ変更通知では、削除されたエントリを検出することはできません。このメカニズムでは、変更されたエントリに関する通知のみが行われ、エントリが変更されたかどうかは示されますが、行われた変更の詳細は公開されません。

削除されたエントリを検出するためのプロビジョニングはないため、変更操作とDN変更操作を区別する方法はありません。

具体的には、エントリ変更通知では、DNの変更操作によってエントリが結果セットのスコープに入ったときやスコープから出たとき、または検索フィルタで使用されている属性値に対する変更操作が実行されたときの通知は行われません。

タイムスタンプは各サーバーのクロックを使用して生成されるため、特定のレプリカに非線形順序で表示される可能性があることから、タイムスタンプ・ベースの検索をディレクトリ・サーバーのマルチマスター設定で実行することはできません。

エントリ変更通知では、操作属性createTimestampおよびmodifyTimestampに基づいたタイムスタンプ・ベースの検索が使用されるため、タイムスタンプ・ベースの検索を正常に実行するためには、ディレクトリ・サーバーでこれらの属性を使用可能にし、索引付けして有効にする必要があります。

これらの属性のいずれかが索引付けされていなかったり、正常に機能していない場合、LDAPアダプタ・クライアントのログにUnavailable Critical Extensionという例外が書き込まれることがあります。

これらの属性がタイムスタンプ検索時に使用できるように適切に索引付けされていることを確認するには、ディレクトリ・サーバーのドキュメントを参照してください。

注意:

PageSize構成はOracle Internet Directoryサーバーへの接続時には機能しないため、Oracle Internet Directoryサーバーでは使用しないでください。構成した場合、pageSize制限を超えて発生したイベントの数は処理されません。

12.3.4.1.1 LDAPアダプタのエントリ変更通知構成ウィザードのフロー

エントリ変更通知を構成するには、次の手順を実行します。

1. 接続を作成した後(「LDAPアダプタの構成」を参照)、「次へ」ボタンをクリックします。「操作タイプ」画面が表示されます。図12-5を参照してください。「エントリ変更通知」を選択します。

図12-23 LDAPアダプタ構成ウィザードの「操作タイプ」画面

2. 「次」を選択します。「エントリ変更通知」画面が表示されます。図12-6を参照してください。

ここでは、アダプタがリスニングするイベントのスコープを定義できます。

3. 「エントリ変更通知」画面で、「参照」ボタンをクリックして、ディレクトリ情報ツリー・ブラウザ・ダイアログを開きます。詳細は、「LDAPブラウザ」を参照してください。

4. 検索フィールド領域では、検索対象を絞り込むための検索フィルタを文字列形式で入力できます。LDAP検索フィルタの詳細は、Oracle Fusion Middleware Oracle Directory Server Enterprise Editionリファレンスを参照してください。

5. 「イベント・ソース」ラジオ・ボタンを使用して、次の選択肢から選択します(検索スコープによって、検索ベース内のどのレベルまで検索するかを定義します)。

- サブツリー全体: ベース・オブジェクトと、ベース・オブジェクトの識別名が最上位オブジェクトになっているサブツリー全体を検索することを示します。

- サブツリーのみ: このサブツリーのみを検索します。

- 最初の子のみ: ルートから最初の子までのみを検索します。

- ルートのみ: LDAP階層のルートのみを検索します。

6. 「イベント・タイプ」で、「追加」、「変更」または「すべて」を選択します。

図12-24 LDAPアダプタ構成ウィザードの「エントリ変更通知」画面

7. 「次」を選択します。次の画面では、変更されたエントリの一部として返される属性を選択できます。図12-7を参照してください。

図12-25 LDAPアダプタ構成ウィザードの「エントリ変更通知」画面

8. 「オブジェクト・クラス」リスト・ボックスに、使用可能なオブジェクト・クラスのテキスト・フィールドで指定した文字から始まるすべてのオブジェクト・クラスが表示されます。リストからオブジェクト・クラスを選択します。(複数のオブジェクト・クラスは、[Ctrl]を押しながら選択します。)

次の「選択可能」属性リスト・ボックスに、オブジェクト・クラスに属するすべての属性が表示されます。複数のオブジェクト・クラスに属している同じ属性は、1回のみ表示されます。

9. 1つ以上の属性を選択し、移動ボタン(> <)を使用してリターン属性を選択/選択解除します([Ctrl]を押しながら選択)。レスポンス属性を選択した場合、その属性に重複は含まれません。ウィザードでは、すでに追加した要素を追加すると無視されます。

「Next」をクリックします。次の画面では、属性のデリミタ、ポーリング間隔、timeLimit、sizeLimit、pageSizeおよびその他のオプションを指定できます。

10. 「,」をデリミタとして使用できない場合は、「属性デリミタ」フィールドに、選択した属性を区切るために使用できる正規表現値を指定します。

11. 「ポーリング間隔」フィールドでは、後続の新しいイベントの検索を実行するまでの間隔を示すポーリング間隔を整数で指定できます(デフォルト値は10秒です)。

12. 「時間制限」フィールドに、整数値を指定します(デフォルト値は0秒です)。これは、LDAPサーバーが結果を返すまでに待機する最大時間です。

13. 「サイズ制限」フィールドに、整数値を指定します。この値は、検索操作の一部として返される最大エントリ数を表します。また、この属性はディレクトリ・サーバーにも構成できます。2つの値のうち低い値が有効になります。SizeLimit値は単一のページ内で適用されます。デフォルト値は1000です。0以下の値を指定すると、サーバーでsizeLimitが適用されません。

14. 「ページ・サイズ」フィールドに、1ページ内にパブリッシュする最大イベント数を入力します。sizeLimit属性は、検索のすべてのページで返された合計エントリ数ではなく、1ページ内のイベントを示します。この値のデフォルト値は-1であり、pageSizeが無制限であることを示します。
検索から12,000エントリが返されると想定され、「サイズ制限」が1000に設定されている場合、合計1000のエントリのみが返されます。このシナリオでは、「サイズ制限」がゼロ、「ページ・サイズ」が500に設定されている場合、検索では12,000のエントリすべてが500エントリずつのページと、200エントリの最後のページで返されます。

15. 「タイプのみ」を選択しない場合、LDAPアダプタでは属性の名前と値が返され、選択した場合、属性の名前のみが返されます。

16. 「次」を選択します。「終了」画面が表示されます。

図12-26 LDAPアダプタ構成ウィザードの変更通知の「終了」画面

12.3.4.2 LDAPアダプタの変更ログ通知

変更ログ通知イベントは、ディレクトリ・サーバーのエントリで実行された変更の詳細ログを提供します。

イベントには変更詳細が含まれ、この変更を発生させたソース・サーバーで実行されたリクエスト・メッセージを再構成します。このイベントは、同じリクエストをターゲット・サーバー上で再現する必要がある場合に特に有用です。変更ログ通知は、アクティビティの詳細を提供するという点で非常に強力な機能です。

変更ログ通知を使用して、ソースLDAPディレクトリを他のサブシステムと増分的に同期できます。このメカニズムはLDAP仕様の一部ではなく、この機能の使用前にはソース・ディレクトリ・サーバーで特定の構成が必要になることがあるため、使用前にディレクトリ・サーバーの実装およびOracle認証マトリクスをチェックする必要があります。

変更ログ通知は、専用ディレクトリ・サーバーまたは専用レプリケーション・サーバーのいずれかとして構成されているサーバー・インスタンスでは使用できません。

12.3.4.2.1 LDAPアダプタ構成ウィザードの変更ログ通知のフロー

変更ログ通知を構成するには、次の一般的な手順を実行します。ここでは、一般的なフローにおける前の手順をすでに実行し、「操作タイプ」画面が表示されていることを前提としています。

1. 「操作タイプ」画面で、「変更ログ通知」を選択します。「次へ」をクリックします。

2. ディレクトリ・サーバーで変更ログ通知メカニズムがサポートされていない場合は、警告ダイアログが表示されます。

3. 「変更ログ通知」画面が表示されます。

- オプションから「通知方法」を選択します。通知計画は、変更ログの問合せに使用する変更ログ・プラグインを示します。この選択では、現在接続されているディレクトリ・サーバーがデフォルトとして設定されます。

- 既存の「通知方法」を選択しない場合は、「カスタム・プラグイン」オプションを選択します。これを選択すると、カスタムの変更ログ・プラグインのクラス名、ポーリング間隔、SizeLimit、TimeLimitを指定するためのテキストボックスが開きます。

- 次の「変更タイプ」オプションから選択します。

- 追加: 指定したポーリング間隔で、changeNumber、changeType(Add)およびソース・ディレクトリ・サーバーで実行されたDSML追加リクエストを返します。

- 削除: 指定したポーリング間隔で、changeNumber、changeType(Delete)およびソース・ディレクトリ・サーバーで実行されたDSML削除リクエストを返します。

- 変更: 指定したポーリング間隔で、changeNumber、changeType(Modify)およびソース・ディレクトリ・サーバーで実行されたDSML削除リクエストを返します。

- DNの変更: 指定したポーリング間隔で、changeNumber、changeType(moddn)およびソース・ディレクトリ・サーバーで実行されたDSML DNの変更リクエストを返します。

- すべて: 指定したポーリング間隔で、changeNumber、changeType(Add、Delete、Modify、moddn)およびソース・ディレクトリ・サーバーで実行された追加、削除、変更、DN変更のDSMLリクエストが返されます。

- ポーリング間隔: 後続の新しいイベントの検索を実行するまでのポーリング時間の間隔(秒)。

- 時間制限: 結果が返されるまでサーバーが待機する最大時間(秒)。

- サイズ制限: 1回の試行でパブリッシュする最大イベント数。デフォルトの整数値は1000です。

- ページ・サイズ: 1ページに公開されるイベントの最大数。デフォルトの整数値は0 (ページングなし)です。

4. 「次」を選択します。「終了」画面が表示されます。

12.3.4.2.1.1 変更ログ通知のエラー

次の表に、変更ログ通知のエラーを示します。

エラー名

説明

ステータス

InboundConnectionDown

インバウンド・アダプタ・サービスからディレクトリ・サーバーへの接続が停止しています。これはLdapConnectionExceptionです。

適切なエラー・メッセージを伴うリモート・フォルト。アダプタはディレクトリ・サーバーへの接続を再試行する必要があります。

ChangeLogNotSupported

変更ログ・メカニズムはターゲット・ディレクトリ・サーバーでサポートされていません。これはLdapValidationExceptionです。

致命的な例外であり、インバウンド・サービスは停止します。

InvalidChangeNumber

変更番号が無効であるか、ディレクトリ・サーバーにより認識されません。ディレクトリ・サーバーの管理者に連絡してください。有効な変更番号を指定してください。変更番号が無効であるか、パージされて認識されなくなった可能性があります。手動で新しい変更番号をデータベース内に指定できます。

これはLdapValidationExceptionです。

この場合、インバウンド・サービスにより初期変更番号が特定されず、処理を開始できないため、致命的な例外が発生します。

EndpointActivationError

エンドポイントのアクティブ化中に、1つ以上のアクティブ化仕様エラーによって検証が失敗しました。

これはLdapValidationExceptionです。

バインディング・フォルト。

SizeLimitExceededException

指定されたサイズ制限を超えました。

-

TimeLimitExceededException

指定された時間制限を超えました。

-

注意:

実行時、LDAPサーバーで発生したエラー/ステータス・コードは、クライアントに送信されることも、サーバーで表示されることもありません。

12.3.4.3 エントリ変更通知のエラー条件

次の表に、LDAPアダプタを使用したエントリ変更通知に関連して発生する可能性のあるエラーを示します。エラー名、エラー名の説明、エラーがレポートされた後の構成のステータス、および再試行可能性を示しています。

表12-3 エントリ変更通知のエラー条件

エラー名

説明

ステータス

InboundConnectionDown

インバウンド・アダプタ・サービスからDSへの接続が停止しています。これはLdapConnectionExceptionです。

適切なエラー・メッセージを伴うリモート・フォルト。LDAPアダプタはDSへの接続を再試行する必要があります。

MalformedDN

イベント・スコープ内のbaseDNが不正です。これはLdapValidationExceptionです。

バインディング・フォルト。

MalformedFilter

検索フィルタはLDAPフィルタの文字列表記に対して不正です。http://www.ietf.org/rfc/ rfc2254.txtを参照してください

LdapValidationException

バインディング・フォルト。

InvalidAdapterConfiguration

アダプタ・インバウンド・サービス構成は、1つ以上の理由で無効です。

LdapValidationException

違反を示す適切なメッセージを伴うバインディング・フォルト。

EndpointActivationError

エンドポイントのアクティブ化中に、1つ以上のアクティブ化仕様エラーによって検証が失敗しました。

LdapValidationException

バインディング・フォルト。

EventProcessingError

ディレクトリ・サーバーから受信したイベントの処理中にエラーがあった場合に発生します。

LdapRetriableResourceException

フォルトは構成済の再試行パラメータに従って再試行され、適切な再試行が実行された後は拒否されます。

12.3.5 ロギング

LDAPアダプタでは、次のログが使用可能です。これらのランタイム・ロガーは、WebLogicコンソールで表示できます。それぞれのロギング・レベルは親から継承されます。

- oracle.soa.adapter.ldap.inbound

- oracle.soa.adapter.ldap.outbound

- oracle.soa.adapter.ldap.connection

- oracle.soa.adapter.ldap.transaction

12.3.6 セキュリティ

LDAPアダプタは、有効なセキュリティ資格証明を使用してサインオンする必要があります。これを可能にするために、Oracle WebLogic Serverではコンテナ管理のサインオンとアプリケーション管理のサインオンの両方がサポートされています。

コンテナ管理のサインオンでは、ユーザーがOracle WebLogic Serverにサインオンし、エンタープライズ情報システムに個別にサインインしなくてもリソース・アダプタを介してアクセスできます。

Oracle WebLogic ServerとLDAPエンタープライズ情報システムでは独立したセキュリティ・レルムが保守されているため、これは資格証明マッピングを使用して実現されます。Oracle WebLogic Serverのセキュリティ・プリンシパルは、エンタープライズ情報システムへのアクセスに必要な対応する資格証明にマップされます。アダプタのデプロイメント・ディスクリプタで機密性の高い資格証明情報を格納する必要はありません。

12.3.6.1 アウトバウンド資格証明マッピングの作成

アウトバウンド資格証明マッピングを使用すると、WebLogic Serverのユーザー名を、リソース・アダプタを使用して接続するエンタープライズ情報システム(EIS)のユーザー名にマップできます。リソース・アダプタ内のすべてのアウトバウンド接続プールに対してデフォルトのアウトバウンド資格証明マッピングを使用することも、個々の接続プールに特定のアウトバウンド資格証明マッピングを指定することもできます。

次の方法を実行すると、ConnectionFactoryプロパティでbindDNおよびpasswordを指定しなくても、資格証明マッピングを作成できます。

1. WebLogicコンソールで「接続プール」を開きます。

2. 「デプロイメント」、「LdapAdapter」、「構成」、「アウトバウンド接続プール」とナビゲートし、javax.resource.cci.ConnectionFactoryを開いて作成したプールを選択します。

3. 「認証」タブをクリックし、「リソース認証のソース」が「コンテナ」に設定されていることを確認します。
「コンテナ」ではない場合、ここで設定して「保存」をクリックします。

4. 「デプロイメント」、「LdapAdapter」、「セキュリティ」、「アウトバウンド資格証明マッピング」とナビゲートします。

5. 「新規」をクリックし、資格証明を構成するConnectionFactory JNDIをチェックします。

6. 「デフォルト・ユーザー」を選択して「次へ」を選択します。

7. bindDN情報としてエンタープライズ情報システムのユーザー名(cn=Directory Managerなど)を入力し、bindDNのパスワード(welcomeなど)を入力します。

8. 「終了」をクリックします。

9. LdapAdapterデプロイメントを更新します。

資格証明マッピングを指定した場合、その資格証明マッピングはConnectionFactoryで構成したbindDNおよびpasswordプロパティよりも優先されます。このコネクション・ファクトリは、LDAPコネクション・ファクトリと同様の方法で使用してください。

最後の手順を完了すると、WebLogic Serverユーザーのマッピングに使用するエンタープライズ情報システムのユーザー名とパスワードの構成は完了です。

12.3.7 SSLを介したLDAP

Secure Sockets Layer (SSL)は、クライアントとサーバー間の通信に対して暗号化されたセキュアな通信を提供します。SSLを介したLDAPの環境におけるSSLの概要は、図12-27 を参照してください。

図12-27 SSLを介したLDAP

機密データがリモート・サーバーへ転送される環境(クレジット・カード情報のHTTPサーバーへの送信など)では、セキュリティの問題は非常に重要です。このような場合、セキュリティには主に次の2つの要件があります。

- データ交換をしているリモート・サーバーの信頼性

- データの傍受を試みる第三者からの保護

LDAPアダプタでSSL証明書および暗号化を使用すると、この2つのセキュリティ要件が満たされます。

SSL環境でクライアントの信頼を得るために、サーバーは認識済の認証局から証明書(X.509証明書など)を取得します。どのクライアントも、少数のパーティしか信頼しません。サーバーが信頼されているパーティの1つである場合、またはサーバーの証明書がそれらの信頼されているパーティのいずれかで発行されたものである場合は、間接的であるにしても信頼性があります。これは、サーバー認証とも呼ばれます。LDAPアダプタは、このタイプのサーバー認証SSLハンドシェイクを提供します。

LDAPアダプタでは、拒否されたメッセージという概念がないため、再試行不可能な例外を発生させる必要があります。

注意:
LDAPアダプタは、server authenticationまたはserver-side authenticationのみをサポートします。LDAPサーバー認証クライアントがクライアント証明書をそのトラスト・ストアで認証する二重認証はサポートしません。

証明書およびトラスト・ストアの使用を示す図は、図12-28 を参照してください。

図12-28 SSLでの証明書およびトラスト・ストアの使用

12.3.8 ペイロード・サイズしきい値

アダプタ・サービスのバインディング・プロパティとして、composite.xml内にペイロード・サイズしきい値を設定できます。

デフォルトでは、ペイロード・サイズしきい値に制限はありません。ただし、LDAPアダプタでは、Fusion Middlewareにパブリッシュされるメッセージはいずれもペイロード・サイズしきい値制限を下回っている必要があるというルールを適用しています。違反しているメッセージは拒否されます。LDAPアダプタでは、拒否されたメッセージという概念がないため、このかわりに再試行不可能な例外を発生させます。再試行シナリオにおける結果は変わらないため、payloadSizeThresholdを再試行しても意味がありません。

12.3.9 高可用性

LDAPアダプタは可用性が高く、メッセージの損失なしで変更を1回かぎり伝播します。LDAPアダプタは、アクティブなクラスタ内にシングルトンとしてデプロイされます。これは、常にLDAPアダプタのシングル・インスタンスのみがディレクトリ・サーバーからの通知を受信することを意味します。高可用性サポートは、インバウンド操作にのみ適用されます。LDAPアダプタでは、アウトバウンド操作に対するトランザクション・サポートを提供していません。

12.3.10 LDAPアダプタの例外処理

LDAPアダプタの例外には、次のタイプの例外があります。

- インバウンド再試行可能例外

- インバウンド再試行不可例外

- アウトバウンド再試行可能例外

- アウトバウンド再試行不可例外

12.3.10.1 インバウンド再試行可能例外

インバウンド再試行可能例外は通常、接続に関連しています。LDAPアダプタは、接続または再試行可能例外条件が修正されるまで再試行します。

このような例外には、次のバインディング・プロパティが適用されます。再試行プロパティが指定されていない場合、再試行は無限に行われます。

表12-4 インバウンド再試行可能JCA LDAPアダプタ・プロパティ

プロパティ名

指定できる値

説明

Jca.retry.count

-

拒否までの最大再試行回数を示します。

Jca.retry.interval

秒単位

再試行の時間間隔を示します。

Jca.retry.backoff

正の整数

再試行間隔の増分ファクタを示します。

Jca.retry.maxInterval

-

再試行間隔の最大値を示します。

Jca.retry.maxPeriod

-

すべての再試行の累積時間合計の上限(強い制限)です。

12.3.10.2 インバウンド再試行不可例外

この場合、拒否ハンドラによってアクションの行程が定義されます。

12.3.10.3 アウトバウンド再試行可能例外

LDAPアダプタは、構成済のバインディング・プロパティに従って再試行を実行します。これらのバインディング・プロパティが指定されていない場合、コンポジットの一部としてフォルト・ポリシーが組み込まれていれば、フォルト・ポリシーによって再試行が実行されます。

アウトバウンド再試行可能例外は、次のプロパティによって制御します。

表12-5 アウトバウンド再試行可能LDAPアダプタJCAプロパティ

プロパティ名

指定できる値

説明

Jca.retry.count

-

拒否するまでの最大再試行回数を示します。

Jca.retry.interval

秒単位

再試行の時間間隔を示します。

Jca.retry.backoff

正の整数

再試行間隔の増分ファクタを示します。

Jca.retry.maxInterval

-

再試行間隔の最大値を示します。

Jca.retry.maxPeriod

-

すべての再試行の累積時間合計の上限(強い制限)です。

Jca.retry.count

-

拒否までの最大再試行回数を示します。

Jca.retry.interval

秒単位

再試行の時間間隔を示します。

12.3.10.4 アウトバウンド再試行不可例外

再試行不可のアウトバウンド例外が発生した場合、フォルト・ポリシーが実行されます。

12.4 LDAPアダプタのサンプル

LDAPアダプタのサンプルについては、SOAサンプルのサイトを参照してください。次の表に、LDAPアダプタで使用可能なサンプルを示します。

表12-6 LDAPアダプタのサンプル

サンプル

説明

Ldap_Search

ディレクトリ・サーバーでエントリを検索し、特定のソート・キーで結果をソートします。

Ldap_Modify

LDAPアダプタを使用してエントリを変更、削除または名前変更します。

Ldap_Incremental_Sync

ソース・ディレクトリ・サーバー上のイベントを取得し、これらのイベントをターゲット・ディレクトリ・サーバーにレプリケートします。

Ldap_DSML_Service

LDAPアダプタを使用するDSMLゲートウェイ・サービス。

13 Oracle JCA Adapter for Microsoft Message Queueing

この章では、概念、機能、構成および使用例について説明します。

この章では、MSMQ機能へのアクセスを可能にし、Oracle BPEL Process Manager (Oracle BPEL PM)およびOracle Service Bus (OSB)と連携して動作するOracle JCA Adapter for Microsoft Message Queueingの使用方法について説明します。このアダプタは、MSMQからネイティブ・フォーマット変換フレームワーク(nXSD)まで、様々なメッセージ・フォーマットの処理もサポートしています。

この章の項目は次のとおりです。

- Oracle JCA Adapter for MSMQの概念と機能

- MSMQアダプタ構成ウィザードのフロー

- MSMQの使用例

13.1 Oracle JCA Adapter for MSMQの概念と機能

Microsoftメッセージ・キュー(MSMQ)は、Microsoft Windowsオペレーティング・システム用の疎結合の分散メッセージング・アプリケーションを作成するためのメッセージ・インフラストラクチャおよび開発プラットフォームです。

メッセージ・キューイング・アプリケーションは、メッセージ・キューイングを使用して、異なるネットワーク間で、オフラインである可能性があるコンピュータと通信します。Microsoftメッセージ・キューは、保証付きメッセージ配信、ルーティング、セキュリティ、トランザクション・サポートおよび優先度ベース・ルーティングを提供します。

メッセージ・キューは、MSMQがメッセージを保存し、その後転送するために使用する論理コンテナであり、メッセージ・キューイングの疎結合的側面の基盤を提供します。キューイング・アプリケーションは、キューにメッセージを送信する際に、メッセージが処理されるタイミング、およびそのメッセージを実際に処理する受信アプリケーションについて認識する必要はありません。

MSMQを使用するアプリケーションは、キューの作成/検索、キューへの接続、キューの移動、キューに対するメッセージの送受信を行い、MSMQキュー・プロパティを使用して該当するキューの動作を定義します。

この項の内容は、次のとおりです。

- MSMQの用語

- Windows Server 2008でのMSMQの設定

- Oracle Weblogic Server for COMの設定

- MSMQアダプタの機能

- サポートされるMSMQプロパティ

13.1.1 MSMQの用語

MSMQの基本概念について理解することに加え、MSMQアダプタを使用するための背景知識としてMSMQの基本用語を理解することが重要です。MSMQの用語についてよく理解するには、関連のMicrosoftドキュメントを参照する必要がありますが、MSMQアダプタの使用を補完するレベルでMSMQ製品について理解するには、次の定義が役立ちます。

- パブリック・キュー: すべてのメッセージ・キューイング・アプリケーションが検出できる、ディレクトリ・サービスに登録されているキュー。これにより、MSMQアプリケーションはそのドメイン内の任意の場所にあるキューを検出して開くことができます。パブリック・キューにより、メッセージがActive Directoryサービス全体にレプリケートされるマルチホップ・シナリオを実現できます。

- プライベート・キュー: 通常は他のアプリケーションが検出できない、(ディレクトリ・サービスではなく)ローカル・コンピュータ上に登録されているキュー。

- MSMQキュー: 条件が許せば、メッセージを確実に送受信できる一時記憶域の場所。

- MSMQユーザー・メッセージ・キュー: プライベートまたはパブリックのいずれかであるキュー。

- リモート・キュー: キュー・マネージャは、メッセージの配信、受信、認証、ルーティングを行い、ディレクトリ・サービス内の情報を保持するメッセージ・キューイング・サービスです。アプリケーションの場合、リモート・キューは、アプリケーションが通信するキューではなく、キュー・マネージャがホストするキューです。

- 配信リスト: 配信リストは、Active Directoryドメイン・サービス(ADDS)に保存されている宛先のパブリック・リストです。

- ADDS: Active Directoryドメイン・サービスは、Windowsドメイン・ネットワーク用にMicrosoftにより実装されているディレクトリ・サービスです。ほとんどのWindows Serverオペレーティング・システムに含まれています。

- トランザクション・キュー: トランザクション・メッセージを含むキュー。トランザクション・キューには、トランザクション内で送信されるメッセージであるトランザクション・メッセージのみを含めることができます。トランザクション・メッセージを使用して、メッセージの送信または受信を、別の操作のアクションと組み合せることができます。トランザクション・メッセージを使用すると、作業ユニットがアトミック操作として確実に実行されます。

- 非トランザクション・キュー: 非トランザクション・メッセージのみを含むキュー。メッセージ・キューイングでは、非トランザクション・キュー内にトランザクション・メッセージを含めることはできません。

- 外部キュー: メッセージ・キューイングを実行していないコンピュータ(外部コンピュータ)上にあるキュー。

13.1.1.1 jCOMおよびMSMQアダプタ

MSMQアダプタは、Oracle WebLogic jCOMを使用して、MSMQ v5.0との相互作用を可能にします。jCOMにより、Java-to-COMの統合がサポートされます。

13.1.1.1.1 背景

具体的には、WebLogic jCOMは、分散コンピューティング環境リモート・プロシージャ・コール上のCOM/DCOMの分散コンポーネント・インフラストラクチャと、Java Remote Method Protocol/Internet Inter-ORB Protocol上のRemote Method Invocation (RMI)の分散コンポーネント・インフラストラクチャの両方を実装するランタイム・コンポーネントを提供します。これにより、相互作用の反対側にあるオブジェクトが、各環境のネイティブ・オブジェクトであるかのように見えます。

分散コンポーネント・オブジェクト・モデル(Distributed Component Object Model: DCOM)モードは、コンポーネント・オブジェクト・モデル(Component Object Model: COM)を使用して異なるコンピュータ上のオブジェクト間の通信をサポートします。

DCOMモードで実行されているWebLogic jCOMアプリケーションでは、COMクライアントはWebLogic Server DCOMプロトコルと通信します。

ネイティブ・モードの場合、COMクライアントはWebLogic Serverにネイティブ呼出しを行い(COM-to-WLS)、WebLogic ServerはCOMアプリケーションにネイティブ呼出しを行います。

ネイティブ・モードでは、ローカルのオペレーティング・システムとCPU用に特にコンパイルおよび最適化された、ネイティブ・コードの動的にロードされるライブラリ(DLL)が使用されるため、COM-to-WLSアプリケーションとWLS-to-COMアプリケーションでは、ネイティブ・モードを使用するとパフォーマンスが向上します。

13.1.1.1.2 MSMQアダプタの影響

MSMQアダプタを使用する理由は、MSMQサーバーとSOAサーバーが同じマシン上にインストールされている場合にネイティブ・モードを使用できるためです。インストールされているSOAサーバーは、Windowsプラットフォームである必要があり、Linuxプラットフォームなど、別のプラットフォームであってはなりません。MSMQアダプタとMSMQが同じシステム上にインストールされている場合、jCOMプロトコル・レベルとMSMQアダプタ・レベルの両方でネイティブ・モードを有効にできます。ネイティブ・モードを使用している場合、MSMQアダプタは、MSMQサーバーと同じシステム上にあるためMSMQサーバーと直接通信でき、(MSMQアダプタとMSMQサーバーが2つの異なるマシン上にある場合に使用される)DCOMプロトコルを通信に使用する必要はありません。MSMQアダプタがMSMQ COMコンポーネントとの通信にDCOMプロトコルを使用しないようにすることで、パフォーマンス上の利点がもたらされます。

13.1.1.2 セキュリティ

MSMQアダプタがMSMQサーバーへのアウトバウンド接続を確立する必要がある場合は、有効なセキュリティ資格証明を使用してサインオンする必要があります。J2CA 1.5仕様に従って、WebLogic Serverではアウトバウンド接続についてコンテナ管理のサインオンとアプリケーション管理のサインオンの両方がサポートされています。MSMQアダプタは、これらの方法のいずれかを利用して、エンタープライズ情報システムにサインオンできます。

13.1.1.2.1 コンポーネント管理のサインオン

コンポーネント管理のサインオンでは、コンポーネント自体が、エンタープライズ情報システムへの接続を取得するためのコール時に、必要なセキュリティ資格証明を提供します。アプリケーション・サーバーは、nullのサブジェクト・インスタンスを渡して、ManagedConnectionFactoryのcreateManagedConnectionメソッドを起動します。

13.1.1.2.2 コンテナ管理のサインオン

コンテナ管理のサインオンでは、ユーザーはOracle WebLogic Serverにサインオンすると、リソース・アダプタを通してエンタープライズ情報システムにもアクセスでき、エンタープライズ情報システムに個別にサインインする必要がなくなります。

Oracle WebLogic ServerとMSMQは独立したセキュリティ・レルムを保守しているため、このことは資格証明マッピングを使用して実現されます。Oracle WebLogic Serverのセキュリティ・プリンシパルは、エンタープライズ情報システムへのアクセスに必要な対応する資格証明にマップされます。

13.1.1.3 ロギングおよび診断能力

MSMQアダプタは、アダプタ・フレームワーク・コンポーネントにより提供されるMSMQアダプタ・ロギング・フレームワークを使用して、ランタイム・ログを取得します。

MSMQアダプタは、次のログを生成します。

- oracle.soa.adapter.msmq

- oracle.soa.adapter.msmq.transaction

- oracle.soa.adapter.msmq.connection

- oracle.soa.adapter.msmq.inbound

- oracle.soa.adapter.msmq.outbound

これらのログの詳細は、『Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。

各ログ出力をTRACE:32に設定して、その領域のデバッグ・ロギングを有効にしたり、oracle.soa.adapter.msmqログ出力をTRACE:32に設定して、MSMQアダプタの完全ロギングを有効にすることができます。MSMQアダプタで発生する例外には、対応するエラー・コードとエラー・メッセージがあります。

13.1.1.4 MSMQアダプタおよび高可用性

MSMQアダプタは、アクティブ/アクティブ・トポロジでデプロイ可能です。MSMQアダプタは、その実装の一部として、各ポーラー・スレッドが次に使用可能なメッセージのキューをポーリングできるようにします。各ポーラー・スレッドは受信APIを使用し、読込みが正常に終了するとメッセージがキューから削除されます。これにより、MSMQアダプタがアクティブ/アクティブ・トポロジでデプロイされた場合にメッセージの重複がなくなります。

13.1.2 Windows Server 2008でのMSMQの設定

Windows Server 2008のインストール環境でMSMQを使用するには、MSMQをインストールするWindows Serverの次の機能を有効にします。設定と構成の詳細は、関連のMicrosoftドキュメントを参照してください。

- メッセージ・キュー・サーバー。インストールの詳細は、http://msdn.microsoft.com/en-us/library/aa967729.aspxにあるMicrosoftのドキュメント「Installing Message Queuing (MSMQ)」を参照してください。

- ディレクトリ・サービス統合(パブリック・キューと配信リストの場合)。具体的な前提条件として、Windows 2008 Serverシステム上にActive Directoryドメイン・サービス(AD_DS)が構成されている必要があります。Active Directoryドメイン・サービスはMSMQパブリック・キューにアクセスする必要があり、アクセスできない場合、MSMQアダプタ使用例で使用できるのはプライベート・キューのみとなります。

- メッセージ・キューDCOMプロキシ

インストールが正常に行われると、メッセージ・キューがMicrosoftサーバー・マネージャ・コンソール・ウィンドウの機能リンクの下に表示されます。

13.1.3 Oracle Weblogic Server for COMの設定

COMで使用するようにOracle WebLogic Serverを設定するには、次の手順を実行します。

- SOA MSMQアダプタをデプロイするサーバーのjCOMを有効にします。jCOMの有効化の詳細は、オンライン・バージョンのヘルプ(Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプ12cリリース1 (12.1.3))を参照してください。
jCOMがSOAサーバーで有効になっている場合は、MSMQアダプタをアクティブ化するときに、そのアダプタがデプロイされるターゲットはSOAサーバー自体である必要があります。jCOMは、アダプタのターゲットとなる管理対象サーバー上で有効になっている必要があります。

- Weblogicが、Microsoftメッセージ・キューを実行しているWindowsマシン上にインストールされている場合、次のドキュメントの説明に従って、構成オプション「ネイティブ・モードの有効化」によりネイティブ・モードを有効にできます。http://docs.oracle.com/cd/E24329_01/apirefs.1211/e24401/pagehelp/Corecoreserverserverprotocolsjcomtitle.html
jCOMのネイティブ・モードを有効化します。jCOMのネイティブ・モードの有効化の詳細は、http://docs.oracle.com/cd/E15051_01/wls/docs103/jcom/comtowls.html#wp1074435を参照してください。

- 最後に、jCOMを有効化するには、SOA MSMQアダプタをデプロイする該当サーバーの再起動、およびWebLogic Serverの再起動が必要です。

13.1.3.1 トランザクション管理およびエラー処理

アダプタに通常適用される、トランザクション管理およびエラー処理の詳細は、「アダプタ・フレームワーク」を参照してください。

13.1.3.1.1 トランザクション管理

MSMQアダプタ・トランザクション・サポートはデフォルトでLocalTransactionに設定されます。MSMQアダプタは、XAトランザクションをサポートしていません。トランザクション・キューは、ローカル・トランザクション・セマンティクスで使用される場合にサポートされます。

インバウンドとアウトバウンドの両方のエラーの場合において、MSMQアダプタは、JCA管理対象コネクション・ファクトリのTransactionModeプロパティがSingleに設定されていると、内部MSMQトランザクションを開始します。

JCA管理対象コネクション・ファクトリのTransactionModeプロパティがNoneに設定されている場合、MSMQアダプタは、MSMQ側でトランザクションを開始せず、メッセージはトランザクションではない方法で生成および消費されます。

TransactionModeプロパティ値のNoneは、非トランザクション・キューに対してメッセージを送受信する場合に必要となります。

13.1.3.1.2 フォルト処理

MSMQアダプタは、MSMQキューに対するメッセージの生成や消費の実行時に発生したフォルトを処理できます。

フォルトが発生した場合、フォルトの性質に基づいて、またエラーが再試行可能であるか再試行不可であるかに応じて、メッセージはBPELリカバリ・キューに配信されるか、再試行されます。アダプタ・フォルトの処理方法の詳細は、「エラー処理」を参照してください。

MSMQアダプタはXAトランザクションをサポートしていないため、XA再試行可能エラーはサポートされていません。

XA再試行可能エラーは、XAトランザクションのコンテキストで発生したエラーを指しています。アダプタは、PCRetriable例外またはXARetriable例外をスローできます。ただし、MSMQアダプタで使用する場合はXAがないため、MSMQアダプタではXAエラーは許可されていません。

13.1.3.1.3 アウトバウンド再試行可能エラー

MSMQアダプタは、構成されたバインディング・プロパティに応じて再試行を実行します。これらのバインディング・プロパティが指定されていない場合は、デフォルト・ポリシーがコンポジット・アプリケーションの一部として含まれていれば、デフォルト・ポリシーによって再試行が実行されます。

MSMQバインディング・プロパティの詳細は、アダプタのプロパティの章の表13-3 を参照してください。

13.1.3.1.4 アウトバウンド再試行不可エラー

アウトバウンド再試行不可フォルトが発生した場合は、フォルト・ポリシーが実行されます。

13.1.4 MSMQアダプタの機能

Oracle MSMQアダプタには、次の機能があります。

- MSMQプライベート・キューへのメッセージの送信

- MSMQアダプタにより、ローカル・プライベート・キューにメッセージを送信できます。MSMQアダプタ構成ウィザードを使用してMSMQアダプタ参照をモデル化する場合は、MSMQキューへのメッセージの送信(またはプット)に使用されるエンキュー操作をモデル化できます。

- MSMQアダプタにより、ローカル・トランザクション・プライベート・キューにメッセージを送信できます。MSMQアダプタ構成ウィザードを使用してMSMQアダプタ参照をモデル化する場合は、ローカル・トランザクションMSMQキューへのメッセージの送信に使用されるエンキュー操作をモデル化できます。

注意:

メッセージの送受信時に接続がトランザクションに関与するかどうかを示す、MSMQのTransactionModeプロパティの関連性を理解することが重要です。このプロパティの値は[Single|None]です。

値がSingleの場合、メッセージの送信先となるローカルおよびリモートのMSMQキューはトランザクションである必要があります。値がSingleの場合、メッセージの取得元となるローカルMSMQキューはトランザクションである必要があります。

値がNoneで、かつメッセージの送信先となるキューがトランザクションの場合は、ResourceExceptionが発生します。

- MSMQパブリック・キューへのメッセージの送信

- MSMQアダプタにより、ローカル・パブリック・キューにメッセージを送信できます。MSMQアダプタ構成ウィザードを使用してMSMQアダプタ参照をモデル化する場合は、エンキュー操作をモデル化できます。このエンキュー操作を使用して、パブリックMSMQキューにメッセージを送信できます。

- MSMQアダプタにより、ローカル・トランザクション・パブリック・キューにメッセージを送信できます。MSMQアダプタ構成ウィザードを使用してMSMQアダプタ参照をモデル化する場合は、エンキュー操作をモデル化できます。このエンキュー操作を使用して、MSMQキューにメッセージを送信できます。

- MSMQ配信リストへのメッセージの送信

- MSMQアダプタにより、配信リストにメッセージを送信できます。MSMQアダプタ構成ウィザードを使用してMSMQアダプタ参照をモデル化する場合は、MSMQ配信リストにメッセージを送信するようにエンキュー操作を構成できます。

- プライベートMSMQキューからのメッセージの消費または受信

- MSMQアダプタにより、ローカル・プライベートMSMQキューからのメッセージの消費または受信が可能になります。デフォルトの動作は、消費可能なキュー上の、次に使用可能なメッセージに対して適用されます。
これを行うには、MSMQアダプタ構成ウィザードを使用して、MSMQプライベート・キューからのメッセージの消費を可能にするデキュー操作をモデル化します。MSMQアダプタは、ローカル・プライベート・トランザクションMSMQキューからのメッセージ消費を可能にし、デキューと呼ばれる操作をサポートします。

これを行うには、構成ウィザードを使用して、トランザクションMSMQキューからメッセージを消費または受信するデキューを作成します。

- パブリックMSMQキューからのメッセージの受信

- MSMQアダプタにより、パブリックMSMQキューからメッセージを受信できます。MSMQアダプタは、アダプタ・サービスのモデル化時に構成し、MSMQキューからのメッセージの消費または受信に使用される、デキューと呼ばれる操作をサポートします。

- MSMQアダプタにより、パブリック・トランザクションMSMQキューからメッセージを受信できます。トランザクションMSMQキューからのメッセージの受信に使用される、デキューと呼ばれるMSMQアダプタ構成ウィザードの操作を使用できます。

13.1.5 サポートされるMSMQプロパティ

MSMQアダプタには、いくつかのJCAプロパティがあります。簡単に参照できるよう、これらをここで示し、プロパティの付録でも示します。

JCAプロパティのリストは、表13-1 を参照してください。

表13-1 MSMQアダプタのJCAプロパティ

プロパティ

説明

デフォルト値

必須

DestinationType

メッセージが、配信リスト名で識別されるパブリック・キュー、プライベート・キュー、またはキューのグループに送信されるかどうかを示します。値は次のとおりです。

PUBLIC_QUEUE

PRIVATE_QUEUE

DISTRIBUTION_LIST

なし

はい

DestinationName

MSMQキューの名前。

なし

はい(UseActiveDirectoryPathがFalseの場合)

DestinationPath

ActiveDirectoryで表されるDistributionListキューまたはPublicキューを識別する文字列。文字列の例を次に示します。

LDAP://MyLDAPServer/CN=MyQueue,CN=msmq,CN=MyComputer,CN=Computers,DC=MyDomain,DC=MyCompany,DC=COM

なし

はい(UseActiveDirectoryPathがTrueの場合)

UseActiveDirectoryPath

パブリック・キューの識別に、キュー名ではなくActive Directoryパスを使用することを許可するブール。このプロパティは、DestinationTypeがDISTRIBUTION_LISTまたはPUBLIC_QUEUEである場合に適用可能です

False

-

UseDirectFormatName

パブリックおよびプライベートのキューに直接フォーマット名を使用することを許可するブール。

False

-

Priority

優先度は7から0までの任意の整数値に設定できます(デフォルトは3)。7は高い優先度を意味します。0は最も低い優先度を意味します。最も高い優先度は、高速な処理を意味します。

3

-

TimeToLive

このプロパティは、ターゲット・キューからメッセージを取得する時間制限(秒)を指定します。値は、指定したMSMQメッセージのMaxTimeToReceiveプロパティに割り当てられます。

-1 (無限)

-

Delivery

このプロパティは、式(非永続)またはリカバリ可能なメッセージング(永続)の指定に使用します。高速メッセージングでは、スループットが高速になります。リカバリ可能メッセージングでは、メッセージがキューに到達する途中にコンピュータがクラッシュした場合でもメッセージが配信されることを保証します。値は、Persistent、Non-Persistentです。

Persistent

-

OperationType

実行する操作。サポートされるOperationTypeの値は、enqueueおよびdequeueです。

なし

はい

BodyType

値は、String (デフォルト)およびByteArrayです。不透明(スキーマ)処理オプションが選択されている場合は、ByteArrayのBodyType値を意味します。

文字列

はい

EnableStreaming

ペイロードのストリーミングを可能にするブール

False

-

MSMQアダプタに関連する正規化されたプロパティのリストについては、表13-2 を参照してください。各プロパティのアダプタ処理の方向も示されています。

表13-2 MSMQアダプタの正規化されたプロパティ

プロパティ名

説明

方向

jca.msmq.message.SentTime

このプロパティは、メッセージが送信されたときを示します。

インバウンド

jca.msmq.message.Priority

このプロパティは、メッセージの優先度を指定します。これにより、MSMQInteractionSpecのPriorityがオーバーライドされます。

インバウンド/アウトバウンド

jca.msmq.message.TimeToLive

このプロパティは、ターゲット・キューからメッセージを取得する時間制限(秒)を指定します。これにより、MSMQInteractionSpec.のTimeToLiveがオーバーライドされます。

インバウンド/アウトバウンド

jca.msmq.message.MaxTimeToReachQueue

このプロパティは、メッセージがキューに到達する時間制限(秒)を指定します。ここで何も指定しない場合、メッセージ・キューイングでは、キューへの到達時間間隔に企業全体の設定が使用されます。

インバウンド/アウトバウンド

jca.msmq.message.Id

MSMQにより生成されたメッセージ識別子を使用して、メッセージを識別します。

インバウンド

jca.msmq.message.Delivery

このプロパティは、メッセージ・キューイングがメッセージを配信する方法を指定します。これにより、MSMQInteractionSpecのDeliveryがオーバーライドされます。

インバウンド/アウトバウンド

jca.msmq.message.BodyLength

このプロパティは、メッセージ本文の長さ(バイト)を指定します。

インバウンド

jca.msmq.message.ArrivedTime

このプロパティは、メッセージがキューに到達したときを示します。

インバウンド

MSMQアダプタに適用されるバインディング・プロパティのリストについては、表13-3 を参照してください。

表13-3 MSMQアダプタのバインディング・プロパティ

プロパティ名

説明

adapter.msmq.receive.timeout

別のポーリング・サイクルを開始する前にメッセージ・キューイングがメッセージの到着を待機する時間(ミリ秒)。デフォルト値は1秒(1)です。

adapter.msmq.dequeue.threads

エンドポイントのアクティブ化が発生すると初期化されるポーラー・スレッドの数。これにより、アダプタは次のポーリング・サイクルが開始されるまでメッセージの受信を指定された時間待機することができます。指定した場合、adapter.msmq.dequeue.threadsの値は、複数のインバウンド・ポーラー・スレッドを生成するために使用されます。複数のインバウンド・スレッドは、パフォーマンスを向上させるために使用できます。デフォルト値は1です。

MSMQアダプタのコネクション・ファクトリを構成する場合は、コネクション・ファクトリ構成プロパティを使用します。表13-4を参照してください。各プロパティの処理方向も示されています。

表13-4 MSMQアダプタのコネクション・ファクトリ構成

プロパティ名

説明

デフォルト

Host

MSMQホストのIPアドレス。

-

AccessMode

コネクション・ファクトリがネイティブ・アクセスを許可するかどうかを識別します。値は[Native | DCOM]です。Nativeの場合、Oracle WebLogic ServerはMSMQと同じホストにインストールされている必要があります。

DCOM

TransactionMode

メッセージを送信および受信する場合に接続がトランザクションに参加するかどうかを識別します。値は[Single|None]です。Singleの場合、メッセージの送信先となるローカルおよびリモートのMSMQキューはトランザクションである必要があります。Singleの場合、メッセージの取得元となるローカルMSMQキューはトランザクションである必要があります。Noneの場合に、メッセージの送信先となるキューがトランザクションであると、ResourceExceptionが発生します。

-

User

ユーザーを識別します。

-

Password

指定したユーザーのパスワードです。

-

Domain

MSMQホストのドメイン。

-

13.2 MSMQアダプタ構成ウィザードのフロー

MSMQアダプタ構成ウィザードを使用して、MSMQアダプタを作成および構成します。

13.2.1 エンキュー操作の作成

このウォークスルー例では、エンキュー操作を作成します。

1. 「コンポーネント・パレット」から「MSMQアダプタ」をドラッグ・アンド・ドロップすると、アダプタ構成ウィザードが起動して、アダプタ構成ウィザードの「ようこそ」ページが表示されます。「次へ」をクリックします。

2. MSMQアダプタ構成ウィザードでは、図13-1 に示すように、サービス名または参照名を入力するように求められます

図13-1 MSMQ構成ウィザードの「サービス名」画面または「参照名」画面

3. 次に、図13-2 に示すように、MSMQサービス接続のJNDI名を指定します。

図13-2 MSMQアダプタ構成ウィザードの「MSMQ接続」画面

4. MSMQ構成ウィザードの「アダプタ・インタフェース」ページで、選択した操作を使用して新しいMSMQアダプタWSDLファイルを作成するか、操作がすでに指定された既存のWSDLをインポートすることができます。

図13-3 MSMQアダプタ構成ウィザードの「アダプタ・インタフェース」画面

5. MSMQアダプタ構成ウィザードの「操作タイプ」ページで、MSMQアダプタ構成の有効な操作を選択できます。操作を更新する場合、操作はこのページで事前選択され、操作名は事前移入されます。既存のWSDLをインポートした場合、このページの操作名は事前移入されます。

図13-4 MSMQアダプタの「操作タイプ」画面

6. 次のステップでは、エンキュー操作を作成します。このページでは、エンキュー操作の構成パラメータを取得します。

図13-5 エンキュー操作

次のように入力します。

- 「接続先タイプ」フィールドで、「パブリック・キュー」、「プライベート・キュー」または「配信リスト」を指定します。

- Public queueまたはDistribution Listが選択された場合、「Active Directoryパスの使用」チェック・ボックスは有効となり、「プライベート・キュー」は無効になります。

- 「Active Directoryパスの使用」チェック・ボックスが選択されている場合は、キューの「接続先パス」を指定でき、そうでない場合は、キューの「接続先名」を指定できます。

- 「メッセージ本文のタイプ」は、String (デフォルト)およびByteArrayです。

- 「優先度」の値は、0 (最も低い優先度)から7 (最も高い優先度)です。デフォルトの優先度は3です。

- 「永続性」の値は、Yes (デフォルト)またはNoです。

- 「有効期限」の単位は、秒、分、時間および日です。MSMQアダプタ構成ウィザードは、TimeToLive相互作用の仕様プロパティ値の値の設定中に、秒以外の単位を秒に変換します。

7. DequeueまたはGet Message操作を選択した場合、「デキュー・メッセージ」が表示されます。この画面で、メッセージをデキューするためのパラメータを入力できます。

直接フォーマット名用のチェック・ボックスがあります。直接フォーマット名を使用すると、ディレクトリ・サービスにアクセスすることなく、パブリック・キューまたはプライベート・キューを参照できます。直接フォーマット名は、メッセージをコンピュータに直接送信する場合、インターネットを介してコンピュータに送信する場合、ドメイン、ワークグループまたはオフライン・モードでの操作中に任意のキューにメッセージを送信する場合、ドメイン、ワークグループまたはオフライン・モードでの操作中にメッセージを読み取る場合、またはフォレスト境界を越えてメッセージを送信する場合に使用されます。

図13-6 デキュー操作(「MSMQからメッセージを取得」)画面

この画面で、次を指定できます。

- 「接続先タイプ」(「パブリック・キュー」または「プライベート・キュー」)を指定します。

- キューの「接続先名」を指定します。

- 「メッセージ本文のタイプ」としてString (デフォルト)またはByteArrayを選択します。

- 「ストリーミングの有効化」チェック・ボックスを選択して、ストリーミングを有効化します。この機能を有効化すると、ペイロードはメモリーDOM内のSOAランタイムで操作されるかわりにデータベースにストリーミングされます。この機能は、大きなペイロードの処理中に使用します。「ストリーミングの有効化」チェック・ボックスを選択すると、対応するブール・プロパティStreamPayloadがそれぞれの.jcaファイルに定義されているアクティブ化仕様プロパティに追加されます。

8. アダプタ構成ウィザードに、「スキーマ」ページが表示されます。特定のスキーマを使用してメッセージ・ペイロードを変換する必要がある場合は、着信通知本文のコンテンツを定義するスキーマ詳細を入力します。ネイティブ・フォーマット・ビルダーを使用して、ネイティブ・フォーマットのスキーマを定義します。メッセージ・ペイロードが不透明である場合は、スキーマを不透明(Opaque)にするオプションを選択できます。

図13-7 MSMQアダプタ構成ウィザードの「メッセージ」画面

9. 「次」を選択します。MSMQアダプタの「終了」ページが表示されます。「終了」をクリックして、指定したファイルをプロジェクト・ディレクトリに作成します。

図13-8 MSMQアダプタ構成ウィザードの「終了」ページ

13.2.2 サンプルのMSMQアダプタ・コネクション・ファクトリ・プロパティ

Fusion Middleware Control内のサンプルのMSMQアダプタ・コネクション・ファクトリ・プロパティを次に示しますが、これらを確認するには、「ホーム」→「デプロイメントのサマリー」→「MSMQAdapter」→「構成」→「アウトバウンド接続プール」に進みます。「新規」オプションを選択し、eis/MSMQ/MSMQAdapter_NonTrans1などの名前をJNDIに指定します。

プロパティは次のとおりです。

MSMQ_AccessMode=DCOM
MSMQ_Domain=adapter.test.msmq
MSMQ_Host=slc04lya.us.mydomain.com
MSMQ_Password=Welcome12
MSMQ_TransactionMode= NONE
MSMQ_User=Administrator

13.2.3 MSMQアダプタ設計時アーティファクト

アダプタ構成ウィザードでは、相互作用およびメッセージ定義に基づいて、JCA、WSDLおよびXMLスキーマのアーティファクトを生成します。

13.2.3.1 MSMQエンキュー操作のサンプルJCAファイル

次に、MSMQエンキュー操作のWSDLを指定する、サンプルJCAファイルを示します。

例 - MSMQエンキュー操作のサンプルJCAファイル

<adapter-config name="enqueueOp" adapter="msmq" wsdlLocation="../WSDLs/enqueueOp.wsdl"
xmlns="http://platform.integration.oracle/
blocks/adapter/fw/metadata">
<connection-factory location="eis/MSMQ/MSMQAdapter"/>
<endpoint-interaction portType="EnqueueOperation_ptt" operation="EnqueueOperation">
<interaction-spec
className="oracle.tip.adapter.msmq.v2.jca.
MSMQInteractionSpec">
<property name="BodyType" value="ByteArray"/>
<property name="DestinationPath" value="dest"/>
<property name="TimeToLive" value="-1"/>
<property name="Delivery" value="Persistent"/>
<property name="DestinationType" value="PUBLIC_QUEUE"/>
<property name="UseDirectFormatName" value="true"/>
<property name="OperationType" value="Enqueue"/>
<property name="Priority" value="5"/>
<property name="UseActiveDirectoryPath" value="true"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

13.2.3.2 MSMQデキュー操作のサンプルJCA

次のサンプルJCAでは、デキュー操作用のWSDLを指定します。

例 - MSMQデキュー操作のサンプルJCA

<adapter-config name="dequeueOp" adapter="msmq"
wsdlLocation="../WSDLs/dequeueOp.wsdl"
xmlns="http://platform.integration.oracle/blocks/adapter/
fw/metadata">
<connection-factory location="eis/MSMQ/MSMQAdapter"/>
<endpoint-activation portType="DequeueOperation_ptt"
operation="DequeueOperation">
<activation-spec
className="oracle.tip.adapter.msmq.v2.
jca.MSMQActivationSpec">
<property name="BodyType" value="String"/>
<property name="DestinationType"
value="PUBLIC_QUEUE"/>
<property name="UseDirectFormatName" value="false"/>
<property name="DestinationName" value="dest"/>
<property name="OperationType" value="Dequeue"/>
<property name="EnableStreaming" value="false"/>
</activation-spec>
</endpoint-activation>
</adapter-config>

13.2.3.3 設計時WSDLアーティファクト

WSDLファイルは、MSMQアダプタ構成ウィザードで「終了」をクリックすると生成されます。「スキーマ」ページで指定したスキーマは、生成されたWSDLにインポートされます。

13.2.3.3.1 MSMQエンキュー操作のWSDL

Base64Binaryエンキュー操作用に生成されたWSDLを次に示します。

例 - エンキュー操作のMSMQアダプタWSDL

<wsdl:definitions
name="msmqService"      targetNamespace="http://xmlns.oracle.com/
pcbpel/adapter/msmq/         MSMQAdapterUseCases/Project1/msmqReference"
xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/          msmq/MSMQAdapterUseCases/Project1/msmqReference"
xmlns:opaque="http://xmlns.oracle.com/
pcbpel/adapter/opaque/"
xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/
partner-link/">
<plt:partnerLinkType name="Enqueue_plt" >
<plt:role name="Enqueue_role" >
<plt:portType name="tns:Enqueue_ptt" />
</plt:role>
</plt:partnerLinkType>
<wsdl:types>
<schema targetNamespace="http://xmlns.oracle.com/
pcbpel/adapter/opaque/"
xmlns="http://www.w3.org/2001/XMLSchema" >
<element name="opaqueElement"
type="base64Binary" />
</schema>
</wsdl:types>
<wsdl:message name="Enqueue_msg">
<wsdl:part name="opaque" element=
"opaque:opaqueElement"/>
</wsdl:message>
<wsdl:portType name="Enqueue_ptt">
<wsdl:operation name="Enqueue">
<wsdl:input message="tns:Enqueue_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

13.2.3.3.2 MSMQアダプタのデキュー操作のWSDL

次の例は、MSMQアダプタのデキュー操作用のWSDLを示しています。

MSMQアダプタのデキュー操作のWSDL

<wsdl:definitions
name="mqService"
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter
/msmq/MSMQAdapterUseCases/Project1/msmqService"
xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter           /msmq/MSMQAdapterUseCases/
Project1/msmqService"
xmlns:pc="http://xmlns.oracle.com/pcbpel/"
xmlns:imp1="http://platform.integration.oracle/
blocks/adapter/fw/metadata/
msmqSchema"
xmlns:plt="http://schemas.xmlsoap.org/ws/
2003/05/partner-link/">
<plt:partnerLinkType name="Dequeue_plt" >
<plt:role name="Dequeue_role" >
<plt:portType name="tns:Dequeue_ptt" />
</plt:role>
</plt:partnerLinkType>
<wsdl:types>
<schema xmlns="http://www.w3.org/
2001/XMLSchema" >
<import namespace="http://platform.integration.oracle/
blocks/adapter             /fw/metadata/msmqSchema"
schemaLocation="../Schemas/msmqSchema.xsd" />
</schema>
</wsdl:types>
<wsdl:message name="Dequeue_msg">
<wsdl:part name="body" element="imp1:message"/>
</wsdl:message>
<wsdl:portType name="Dequeue_ptt">
<wsdl:operation name="Dequeue">
<wsdl:input message="tns:Dequeue_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

13.3 MSMQの使用例

次の使用例は、MSMQアダプタの様々な用途の説明およびウォークスルーを示しています。次のような使用例があります。

- パブリック・キューでのメッセージのエンキュー/デキュー

- プライベート・キューでのメッセージのエンキュー/デキュー

- 配信リストへのメッセージのエンキュー

13.3.1 パブリック・キューでのメッセージのエンキュー/デキュー

この使用例は、次の手順で構成されています。

- SOAコンポジットの設計

- インバウンドOracle MSMQアダプタ・サービスの作成

- アウトバウンドOracle MSMQアダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- receiveアクティビティの追加

- invokeアクティビティの追加

- assignアクティビティの追加

13.3.1.1 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「SOAアプリケーション - アプリケーションの名前付け」選択ページが表示されます。

2. 「アプリケーション名」フィールドにEnq_Deq_PublicAppと入力して、「次へ」をクリックします。 「プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにEnq_Deq_Publicと入力し、「次へ」をクリックします。

4. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。MSMQアダプタ構成ウィザードに、「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

5. 「名前」フィールドにBPELPublicと入力し、「テンプレート」リストから「サービスを後で定義」を選択します。

6. 「OK」をクリックします。図13-9 に示すように、Enq_Deq_PublicAppアプリケーションとEnq_Deq_Publicプロジェクトが設計領域に表示されます。

図13-9 Enq_Deq_PublicAppアプリケーションおよびEnq_Deq_Publicプロジェクト

13.3.1.2 インバウンドOracle MSMQアダプタ・サービスの作成

インバウンドOracle MSMQアダプタ・サービスを作成し、Microsoftメッセージング・キューからメッセージをデキューするには、次の手順を実行します。

1. 「コンポーネント」から、「MSMQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「サービス名」フィールドにPublicInと入力します。

3. 「次」を選択します。「アダプタ接続」ページが表示されます。

4. MSMQサーバーのJNDI接続名を指定します。トランザクション・キューまたは非トランザクション・キューへの接続に使用できます。たとえば、この使用例では、非トランザクション・キューに使用されるJNDIはeis/MSMQ/MSMQAdapter_NonTransです。

5. 「次」を選択します。MSMQアダプタ構成ウィザードに、「アダプタ・インタフェース」ページが表示されます。

6. 「次」を選択します。アダプタ操作タイプ・ページが表示されます。

7. 「操作タイプ」として「MSMQからメッセージを取得」を、「操作名」として「デキュー」を選択します。

8. 「次」を選択します。MSMQアダプタ構成ウィザードの「MSMQからメッセージを取得」ページが表示されます。

9. 「接続先タイプ」として「パブリック・キュー」を選択します。「接続先名」フィールドにPublic_Queue_Deqと入力します。

10. 「次」を選択します。ウィザードに、「メッセージ」ページが表示されます。

11. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択します。注意: スキーマがある場合は、変換用のスキーマを指定できます。

12. 「次」を選択します。ウィザードに、「終了」ページが表示されます。

13. 「終了」をクリックします。インバウンドOracle MSMQアダプタの構成が完了し、図13-10 に示すように、composite.xmlが表示されます。

図13-10 パブリック・キュー使用例でのエンキュー/デキューのcomposite.xml

13.3.1.3 アウトバウンドOracle MSMQアダプタ・サービスの作成

アウトバウンドOracle MSMQアダプタ・サービスを作成し、あるMicrosoftメッセージング・キューから他のMicrosoftメッセージング・キューにメッセージをエンキューするには、次の手順を実行します。

1. 「コンポーネント」から、「MSMQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「参照名」フィールドに、PublicOutと入力します。

3. 「次」を選択します。MSMQアダプタ構成ウィザードに「接続」と示されます。

4. MSMQサーバーのJNDI接続名を指定します。トランザクション・キューまたは非トランザクション・キューへの接続に使用できます。たとえば、この使用例では、非トランザクション・キューに使用されるJNDIはeis/MSMQ/MSMQAdapter_NonTransです。

5. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

6. 「次」を選択します。アダプタ操作タイプ・ページが表示されます。

7. 「操作タイプ」に「MSMQにメッセージを格納」を、「操作名」に「エンキュー」を選択します。

8. 「次へ」をクリックします。アダプタの「MSMQにメッセージを格納」ページが表示されます。

9. 「接続先タイプ」として「パブリック・キュー」を選択します。「接続先名」フィールドにPublic_Queue_Enqと入力します。

注意:

キューのActive Directoryパスがある場合は、「Active Directoryパスの使用」チェック・ボックスを選択し、適切な値を指定します。また、キューの直接フォーマット名がある場合は、「直接フォーマット名の使用」チェック・ボックスを選択して、キューの直接フォーマット名を指定する必要があります。

10. 「次」を選択します。MSMQアダプタの「メッセージ」ページが表示されます。

11. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択します。スキーマがある場合は、変換のスキーマを指定できることに注意してください。

12. 「次」を選択します。アダプタ構成ウィザードに、「終了」ページが表示されます。

13. 「終了」をクリックします。図13-11 に示すように、アウトバウンドのOracle MSMQアダプタが構成され、composite.xmlが表示されます。

図13-11 MSMQアダプタのエンキュー/デキュー使用例でのアウトバウンドMSMQアダプタ

13.3.1.4 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、アウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントをワイヤリングするには、次の手順を実行します。

1. 「公開されたサービス」領域にあるPublicIn内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 配信タイプとして「async.persist」を選択します。

3. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のPublicOut内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。JDeveloperのcomposite.xmlが図13-12 のように表示されます。

図13-12 composite.xmlのワイヤリング

4. 「ファイル」、「すべて保存」を順番にクリックします。

13.3.1.5 receiveアクティビティの追加

次の手順に従ってreceiveアクティビティを追加します。

1. BPELPublicをダブルクリックします。「BPELPublic.bpel」ページが表示されます。

2. 「コンポーネント」領域から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveInputと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 図13-13 に示すように、PublicInを選択して「OK」をクリックします。

図13-13 「パートナ・リンク・チューザ」での「PublicIn」の選択

7. 図13-14 に示すように、「Receive」ダイアログで「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

図13-14 「Receive」ダイアログの「変数の自動作成」アイコンのクリック

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。JDeveloperの「BPELPublic.bpel」ページが図13-15 のように表示されます。

図13-15 JDeveloperの「BPELPublic.bpel」ページ

13.3.1.6 invokeアクティビティの追加

次のステップでは、invokeアクティビティを追加します。

1. 「コンポーネント」領域から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 「名前」フィールドにEnqueue_Messageと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 図13-16 に示すように、PublicOutを選択して「OK」をクリックします。

図13-16 「PublicOut」が選択された「パートナ・リンク・チューザ」ダイアログ

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。図13-17 に示すように、Invokeダイアログが表示されます。

図13-17 メッセージのエンキューの「Invoke」ダイアログ

8. 「OK」をクリックします。JDeveloperの「BPELPublic.bpel」ページが表示されます。図13-18を参照してください。

図13-18 invokeが追加された後の「BPELPublic.bpel」ページ

13.3.1.7 assignアクティビティの追加

次に、assignアクティビティを追加します。これを行うには、次の手順を実行します。

1. 「コンポーネント」領域から、assignアクティビティを設計領域のreceiveアクティビティとinvokeアクティビティの間にドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「一般」タブをクリックして、「名前」フィールドにAssignReferenceと入力します。

4. 「コピー・ルール」タブをクリックします。

5. 図13-19 に示すように、変数ReceiveInput_Dequeue_InputVariableの不透明要素と、変数Enqueue_Message_Enqueue_InputVariableの不透明要素との間をワイヤリングします。

図13-19 「Assign」ダイアログを使用した要素のワイヤリング

6. 「OK」をクリックします。図13-20 に示すように、JDeveloperの「BPELPublic.bpel」ページが表示されます。

図13-20 ワイヤリングされた要素が「Assign」ダイアログに追加された後の「BPELPublic.bpel」ページ

13.3.2 プライベート・キューでのメッセージのエンキュー/デキュー

この使用例では、MSMQプライベート・キューに対してメッセージをエンキューおよびデキューするアプリケーションを作成します。

- SOAコンポジットの設計

- インバウンドOracle MSMQアダプタ・サービスの作成

- アウトバウンドOracle MSMQアダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- receiveアクティビティの追加

- invokeアクティビティの追加

- assignアクティビティの追加

13.3.2.1 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。次に、「SOAアプリケーション」を選択します。「アプリケーションの名前付け」ページが表示されます。「アプリケーション名」フィールドにEnq_Deq_PrivateAppと入力して、「次へ」をクリックします。

2. 「プロジェクトの名前付け」ページが表示されます。「プロジェクト名」フィールドにEnq_Deq_Privateと入力して、「次へ」をクリックします。

3. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

4. 「名前」フィールドにBPELPrivateと入力し、「テンプレート」リストから「サービスを後で定義」を選択します。

5. 「OK」をクリックします。図13-21 に示すように、Enq_Deq_PrivateAppアプリケーションとEnq_Deq_Privateプロジェクトが設計領域に表示されます。

図13-21 設計領域のEnq_Deq_PrivateAppおよびEnq_Deq_Privateプロジェクト

13.3.2.2 インバウンドOracle MSMQアダプタ・サービスの作成

インバウンドOracle MSMQアダプタ・サービスを作成し、Microsoftメッセージング・キューからメッセージをデキューするには、次の手順を実行します。

1. 「コンポーネント」領域から、「MSMQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「サービス名」フィールドにPrivateInと入力します。

3. 「次」を選択します。「アダプタ接続」ページが表示されます。

4. MSMQサーバーのJNDI接続名を指定します。トランザクション・キューまたは非トランザクション・キューへの接続の場合があります。この使用例では、非トランザクション・キューに使用されるJNDIはeis/MSMQ/MSMQAdapter_NonTransです。

5. 「次」を選択します。「アダプタ・インタフェース」ページが表示されます。

6. 「次」を選択します。アダプタ操作タイプ・ページが表示されます

7. 「操作タイプ」として「MSMQからメッセージを取得」を、「操作名」として「デキュー」を選択します。参照してください

8. 「次」を選択します。アダプタの「MSMQからメッセージを取得」ページが表示されます。

図13-22 MSMQアダプタ構成ウィザードのメッセージを取得画面

9. 「接続先タイプ」として「プライベート・キュー」を選択します。「接続先名」フィールドにPrivate_Queue_Deqと入力します。(MSMQアダプタがプライベート・キューへのアクセスに直接フォーマット名を使用するように指定している場合があります。)このオプションを優先する場合は、「直接フォーマット名の使用」チェック・ボックスを選択する必要があります。

10. 「次」を選択します。アダプタ構成ウィザードに、「メッセージ」ページが表示されます。

11. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択します。注意: スキーマがある場合は、変換用のスキーマを指定できます。

12. 「次」を選択します。MSMQアダプタ構成ウィザードに、「終了」ページが表示されます。

13. 「終了」をクリックします。インバウンドOracle MSMQアダプタの構成が完了し、図13-23 に示すように、composite.xmlが表示されます

図13-23 composite.xmlで構成されたインバウンドMSMQアダプタ

13.3.2.3 アウトバウンドOracle MSMQアダプタ・サービスの作成

アウトバウンドOracle MSMQアダプタ・サービスを作成し、あるMicrosoftメッセージング・キューから他のMicrosoftメッセージング・キューにメッセージをエンキューするには、次の手順を実行します。

1. 「コンポーネント」領域から、「MSMQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「参照名」フィールドに、PrivateOutと入力します。

3. 「次へ」をクリックします。「アダプタ接続」ページが表示されます。

4. MSMQサーバーのJNDI接続名を指定します。トランザクション・キューまたは非トランザクション・キューへの接続の場合があります。たとえば、この使用例では、非トランザクション・キューに使用されるJNDIはeis/MSMQ/MSMQAdapter_NonTransです。

5. 「次」を選択します。「インタフェース」ページが表示されます。

6. 「次」を選択します。「操作タイプ」ページが表示されます。

7. 「操作タイプ」として「MSMQにメッセージを格納」を、「操作名」として「エンキュー」を選択します。

8. 「次」を選択します。アダプタの「MSMQにメッセージを格納」ページが表示されます。

9. 「接続先タイプ」として「プライベート・キュー」を選択します。「接続先名」にPrivate_Queue_Enqと入力します。注意: キューの直接フォーマット名がある場合は、「直接フォーマット名の使用」チェック・ボックスを選択して、キューの直接フォーマット名を指定します。

図13-24 MSMQアダプタ構成ウィザードの「MSMQにメッセージを格納」画面

10. 「次」を選択します。「メッセージ」ページが表示されます。

11. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択します。注意: スキーマがある場合は、変換用のスキーマを指定できます。

12. 「次」を選択します。MSMQアダプタ構成ウィザードに、「終了」ページが表示されます。

13. 「終了」をクリックします。図13-25 に示すように、アウトバウンドのOracle MSMQアダプタが構成され、composite.xmlが表示されます。

図13-25 PrivateOut外部参照で構成されたMSMQアウトバウンド・アダプタ

13.3.2.4 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたはワイヤリングする必要があります。コンポーネントをワイヤリングするには、次の手順を実行します。

1. 「公開されたサービス」領域にあるPrivateIn内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 「配信タイプ」に「async.persist」を選択します。

3. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のPrivateOut内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。JDeveloperのcomposite.xmlが図13-26 のように表示されます。

図13-26 ワイヤリングされたMSMQアダプタJDeveloperのcomposite.xml

4. 「ファイル」、「すべて保存」を順番にクリックします。

13.3.2.5 receiveアクティビティの追加

次のステップでは、receiveアクティビティをコンポジット・アプリケーションに追加します。

1. 「BPELPrivate」をダブルクリックします。「BPELPrivate.bpel」ページが表示されます。

2. 「コンポーネント」領域から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveInputと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。構成ウィザードに、「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 図13-27 に示すように、PrivateInを選択して「OK」をクリックします。

図13-27 「パートナ・リンク」としてPrivateInが選択された「パートナ・リンク・チューザ」ダイアログ

7. 図13-28 に示すように、「Receive」ダイアログで「変数」フィールドの右にある「変数の自動作成」アイコンをクリックします。アダプタ構成ウィザードに、「変数の作成」ダイアログが表示されます。

図13-28 「Receiveの編集」の「変数の作成」ダイアログ

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。JDeveloperの「BPELPrivate.bpel」ページが図13-29 のように表示されます。

図13-29 receiveアクティビティにワイヤリングされたPrivateInパートナ・リンクを示す、「BPELPrivate.bpel」ページ

13.3.2.6 invokeアクティビティの追加

次のステップでは、invokeアクティビティを追加します。

1. 「コンポーネント」領域から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 「名前」フィールドにEnqueue_Messageと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます

5. 図13-30 に示すように、PrivateOutを選択して「OK」をクリックします。

図13-30 PrivateOutが選択された「パートナ・リンク・チューザ」ダイアログ

6. Invokeダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。図13-31 に示すように、Invokeダイアログが表示されます。

図13-31 「Invokeの編集」ダイアログ

8. 「OK」をクリックします。JDeveloperの「BPELPrivate.bpel」ページが図13-32 のように表示されます。

図13-32 invokeアクティビティが追加された後の「BPELPrivate.bpel」ページ

13.3.2.7 assignアクティビティの追加

最後のステップでは、assignアクティビティを追加します。

1. 「コンポーネント」領域から、assignアクティビティを設計領域のreceiveアクティビティとinvokeアクティビティの間にドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「一般」タブをクリックして、「名前」フィールドにAssignReferenceと入力します。

4. 「コピー・ルール」タブをクリックします。

5. 図13-33 に示すように、変数ReceiveInput_Dequeue_InputVariableの不透明要素と、変数Enqueue_Message_Enqueue_InputVariableの不透明要素との間をワイヤリングします。

図13-33 変数をワイヤリングするようにassignアクティビティを編集

6. 「OK」をクリックすると、JDeveloperの「BPELPrivate.bpel」ページが表示されます。

図13-34 変数が割り当てられた後の「BPELPrivate.bpel」ページ

7. 「ファイル」、「すべて保存」を順番にクリックします。

13.3.3 配信リストへのメッセージのエンキュー

次の手順に従って、配信リストへのMSMQメッセージのエンキューを含む使用例を設計します。

- SOAコンポジットの設計

- インバウンドOracleファイル・アダプタ・サービスの作成

- アウトバウンドOracle MSMQアダプタ・サービスの作成

- サービスとアクティビティのワイヤリング

- receiveアクティビティの追加

- invokeアクティビティの追加

- assignアクティビティの追加

13.3.3.1 SOAコンポジットの設計

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。次に、「SOAアプリケーション」を選択します。アダプタ構成ウィザードに、「アプリケーションの名前付け」ページが表示されます。

2. 「アプリケーション名」フィールドにEnq_DistListAppと入力して「次へ」をクリックします。アダプタ構成ウィザードに、「プロジェクトの名前付け」ページが表示されます。

3. 「プロジェクト名」フィールドにEnq_DistListと入力して「次へ」をクリックします。

4. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成 - BPELプロセス」ページが表示されます。

5. 「名前」フィールドにBPELDistListと入力し、「テンプレート」リストから「サービスを後で定義」を選択します。

6. 「OK」をクリックします。図13-35 に示すように、Enq_DistListAppアプリケーションとEnq_DistListプロジェクトが設計領域に表示されます。

図13-35 設計領域のEnq_DistListAppアプリケーションとEnq_DistListプロジェクト

13.3.3.2 インバウンドOracleファイル・アダプタ・サービスの作成

ローカル・ディレクトリからファイルを読み取るインバウンドOracleファイル・アダプタ・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」領域から、「ファイル・アダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。

2. 「サービス名」フィールドにFileInと入力します。

3. 「次」を選択します。ファイル・アダプタ構成ウィザードに、「ファイル・サーバーの接続」ページが表示されます。

4. 「次」を選択します。ファイル・アダプタ構成ウィザードに、「操作」ページが表示されます。

5. 「操作タイプ」として「Read File」を選択します。

6. 「次」を選択します。「ファイル・ディレクトリ」ページが表示されます。

7. 図13-36 に示すように、入力ディレクトリの物理パスを入力します。

図13-36 ファイル・アダプタ構成ウィザードの「ファイル・ディレクトリ」ページ

8. 「次」を選択します。ファイル・アダプタ構成ウィザードに、「ファイルのフィルタ処理」ページが表示されます。

9. 「インクルード・ファイルの名前パターン」フィールドに*.txtと入力します。

10. 「次」を選択します。ファイル・アダプタ構成ウィザードに、「ファイル・ポーリング」ページが表示されます。

11. 「次」を選択します。ファイル・アダプタ構成ウィザードに、「メッセージ」ページが表示されます。

12. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択します。

13. 「次」を選択します。ファイル・アダプタ構成ウィザードに、「終了」ページが表示されます。

14. 「終了」をクリックします。図13-37 に示すように、インバウンドOracleファイル・アダプタが構成され、composite.xmlが表示されます。

図13-37 composite.xmlで構成されたインバウンド・ファイル・アダプタ

13.3.3.3 アウトバウンドOracle MSMQアダプタ・サービスの作成

ローカル・ディレクトリから配信リストにメッセージをエンキューするアウトバウンドOracle MSMQアダプタ・サービスを作成するには、次の手順を実行します。

1. 「コンポーネント」領域から、「MSMQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードに、「ようこそ」ページが表示されます。

2. 「参照名」フィールドに、DistListOutと入力します。

3. 「次」を選択します。アダプタ構成ウィザードに、「接続」ページが表示されます。

4. MSMQサーバーのJNDI接続名を指定します。この名前を使用して、トランザクション・キューまたは非トランザクション・キューに接続できます。この使用例では、非トランザクション・キューに使用されるJNDIはeis/forMSMQ/MSMQAdapter_NonTransです。

5. 「次」を選択します。アダプタ構成ウィザードに、「インタフェース」ページが表示されます。

6. 「次」を選択します。アダプタ構成ウィザードに、「操作タイプ」ページが表示されます。

7. 「操作タイプ」として「MSMQにメッセージを格納」を、「操作名」として「エンキュー」を選択します。

8. 「次」を選択します。アダプタ構成ウィザードに、「MSMQにメッセージを格納」ページが表示されます。

9. 「接続先タイプ」として「配信リスト」を選択します。「接続先名」にDistList_Enqと入力します。

注意:

配信リストのActive Directoryパスがある場合は、「Active Directoryパスの使用」チェック・ボックスを選択し、値を指定する必要があります。また、配信リストの直接フォーマット名がある場合は、「直接フォーマット名の使用」チェック・ボックスを選択して、キューの直接フォーマット名を指定できます。

10. 「次」を選択します。アダプタ構成ウィザードに、「メッセージ」ページが表示されます。

11. 「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」チェック・ボックスを選択します。注意: スキーマがある場合は、変換用のスキーマを指定できます。

12. 「次」を選択します。アダプタ構成ウィザードに、「終了」ページが表示されます。

13. 「終了」をクリックします。アウトバウンドOracle MSMQアダプタの構成が完了し、図13-38 に示すように、composite.xmlが表示されます。

図13-38 composite.xmlで構成されたアウトバウンド・ファイル・アダプタ

13.3.3.4 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたはワイヤリングする必要があります。コンポーネントを接続する手順は、次のとおりです。

1. 「公開されたサービス」領域にあるFileIn内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

2. 配信タイプとして「async.persist」を選択します。

3. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のDistListOut内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。JDeveloperのcomposite.xmlが図13-39 のように表示されます。

図13-39 ワイヤリング後の配信リスト使用例のcomposite.xml

4. 「ファイル」、「すべて保存」を順番にクリックします。

13.3.3.5 receiveアクティビティの追加

次の手順に従ってreceiveアクティビティを追加します。

1. 「BPELDistList」をダブルクリックします。「BPELDistList.bpel」ページが表示されます。

2. 「コンポーネント」領域から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

3. receiveアクティビティをダブルクリックします。MSMQアダプタ構成ウィザードに、「Receive」ダイアログが表示されます。

4. 「名前」フィールドにReceiveInputと入力します。

5. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

6. 図13-40 に示すように、FileInを選択して「OK」をクリックします。

図13-40 インバウンド・ファイル・アダプタが選択された「パートナ・リンク・チューザ」ダイアログ

7. 図13-41 に示すように、「Receive」ダイアログで「変数」フィールドの右にある「変数の自動作成」アイコンを選択します。「変数の作成」ダイアログが表示されます。

図13-41 「Receive」ダイアログ

8. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。

9. 「インスタンスの作成」を選択して、「OK」をクリックします。JDeveloperの「BPELDistList.bpel」ページが図13-42 のように表示されます。

図13-42 ReceiveInput作成後の「BPELDistList.bpel」ページ

13.3.3.6 invokeアクティビティの追加

次の手順に従ってinvokeアクティビティを追加します。

1. 「コンポーネント」領域から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

2. invokeアクティビティをダブルクリックします。Invokeダイアログが表示されます。

3. 「名前」フィールドにEnqueue_Messageと入力します。

4. 「パートナ・リンク」フィールドの端にある「パートナ・リンクの参照」をクリックします。「パートナ・リンク・チューザ」ダイアログが表示されます。

5. 図13-43 に示すように、DistListOutを選択して「OK」をクリックします。

図13-43 DistListOutが選択された「パートナ・リンク・チューザ」

6. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンを選択します。「変数の作成」ダイアログが表示されます。

7. デフォルトの変数名を選択し、「OK」をクリックします。デフォルトの変数名が「変数」フィールドに移入されます。JDeveloperのInvokeダイアログが図13-44 のように表示されます

図13-44 Enqueue_Message_Enqueue_inputVariableが指定されたJDeveloperの「Invoke」ダイアログ

8. 「OK」をクリックします。JDeveloperの「BPELDistList.bpel」ページが図13-47 のように表示されます。

図13-45 invokeアクティビティが作成された後の「BPELDistList.bpel」ページ

13.3.3.7 assignアクティビティの追加

次の手順に従ってassignアクティビティを追加します。

1. 「コンポーネント」領域から、assignアクティビティをJDeveloper設計領域のreceiveアクティビティとinvokeアクティビティの間にドラッグ・アンド・ドロップします。

2. assignアクティビティをダブルクリックします。Assignダイアログが表示されます。

3. 「一般」タブをクリックして、「名前」フィールドにAssignReferenceと入力します。

4. 「コピー・ルール」タブをクリックします。

5. 図12に示すように、変数ReceiveInput_Dequeue_InputVariableの不透明要素と、変数Enqueue_Message_Enqueue_InputVariableの不透明要素との間をワイヤリングします。

図13-46 ReceiveInput_Dequeue_InputVariableをEnqueue_Message_Enqueue_InputVariableにワイヤリングした、Jdeveloperの「assignの編集」ダイアログ

6. 「OK」をクリックすると、図13に示すように、JDeveloperの「BPELDistList.bpel」ページが表示されます

図13-47 完了した「BPELDistList.bpel」ページ

7. 「ファイル」、「すべて保存」を順番にクリックします。

14 Oracle JCA Adapter for Coherence

この章では、Oracle JCA Adapter for Coherenceの使用方法について説明します。アダプタの使用の基本的原理、概念およびコヒーレンス・アダプタ構成ウィザード・フローについて説明します。

この章の内容は次のとおりです。

- Oracle CoherenceおよびOracle JCA Coherenceアダプタの概念

- Oracle Coherenceアダプタの機能

- コヒーレンス・アダプタの構成

- Coherenceキャッシュ内のアイテムの問合せ

- 「XML」が選択されている場合のPut操作、Get操作および問合せ操作のメッセージの定義

- 「POJO」が選択されている場合のPut操作、Get操作および問合せ操作のメッセージの定義

- コヒーレンス・アダプタのファイルおよびアーティファクト

14.1 Oracle CoherenceおよびOracle JCA Coherenceアダプタの概念

Coherenceは、信頼のおけるスケーラビリティの高いピア・ツー・ピアのクラスタリング・プロトコル上で、複製および配布した(パーティション化した)データの管理とキャッシュ・サービスを行います。

14.1.1 Coherenceキャッシュ

Coherenceキャッシュは、データベースとクライアント・アプリケーション間の仲介として機能するデータ・オブジェクトのコレクションです。データベース・データをキャッシュにロードして、異なるアプリケーションで使用できます。このようにしてCoherenceキャッシュはデータベースに対する負荷を軽減し、データベース・データへのアクセスを高速化します。キャッシュのオブジェクトはXMLまたはPOJO (Plain Old Java Object)型にできます。

注意:

POJO Javaクラスは、コヒーレンス・アダプタとともに使用するためにシリアライズされている必要があります。つまり、コヒーレンス・アダプタとともに使用するJavaクラスは、java.io.Serializableまたはcom.tangosol.io.pof.PortableObjectを実装する必要があります。

Coherenceの詳細は、Oracle Coherenceライブラリを参照してください。Coherenceのセキュリティ関連の情報は、Oracle Coherenceセキュリティ・ガイドを参照してください。

14.1.2 コヒーレンス・アダプタ

コヒーレンス・アダプタは、Oracle CoherenceのJCA 1.5準拠のリソース・アダプタです。SOA環境にデプロイする場合、コヒーレンス・アダプタは、SOAコンポジット・アプリケーションがOracle Coherenceと統合されている場合、SOAコンポジット・アプリケーションによる統合手段として使用されます。

コヒーレンス・アダプタにより、Coherenceキャッシュへのアイテムの追加、Coherenceキャッシュからのアイテムの取得、Coherenceキャッシュに対するアイテムの削除や問合せなど、有用なCoherence操作を実行できます。

14.1.3 互換性

コヒーレンス・アダプタを12.1.3で使用する場合、バージョン12.1.3以外、または新しいバージョンのリモートCoherenceクラスタと相互作用することはできません。

これは、Coherence Extendクライアントを古いバージョンの拡張プロキシと使用する場合の、Coherence製品の制限によるものです。

具体的には、CoherenceサーバーとExtendクライアント間の互換性に関して、Extendクライアントからクラスタ・プロキシ・サーバーへの上位互換のみが維持されます。つまり、Extendクライアントは、同じバージョン番号以上のクラスタ・サーバーと接続可能ですが、低いバージョン番号のクラスタ・サーバーとは接続できません。

Coherence製品での制限については、次のリンクを参照してください。

http://docs.oracle.com/cd/E24290_01/coh.371/e22839/gs_install.htm#CBHJGGBG

14.1.4 Oracle Coherenceアダプタの機能

Oracle Coherenceアダプタを使用して、Oracle Coherenceに関連付けられている次のアクティビティを実行できます。

- キャッシュ・エントリの追加: 新しいエントリをCoherenceキャッシュに作成します。

- キャッシュ・エントリの削除: キャッシュから削除するアイテムを特定すると、システムによりそのエントリがキャッシュから削除されます。キャッシュ内の複数のレコードに一致するフィルタや条件を指定して、複数のエントリをキャッシュから削除することもできます。

- キャッシュ・エントリ値の取得: 関連付けられた値を取得するエントリを指定すると、システムによりそのエントリの値が返されます。

- 問合せキャッシュ: キャッシュを特定し、検索条件を指定すると、システムにより検索条件に一致するエントリが返されます。

14.1.4.1 基本的な使用例

コヒーレンス・アダプタには、2つの基本的な使用例があります。

- ローカル・クラスタに接続するコヒーレンス・アダプタ。この構成では、トランザクション・キャッシュがサポートされます。

- スタンドアロンCoherenceクラスタまたはWebLogic Serverに接続するコヒーレンス・アダプタ。この構成では、トランザクション・キャッシュはサポートされません。
この章で説明しているローカル・コヒーレンス・アダプタの操作は、リモート・キャッシュに関して類似しており、前述の制限を持つことに注意してください。主な違いは、リモート・キャッシュに対して操作を行うときに指定するキャッシュの名前が、ローカル・クラスタに関連する名前ではなく、リモート・キャッシュの名前であることです。

コヒーレンス・アダプタは、Coherence Extendクライアントを使用して、リモート・クラスタに接続します。コヒーレンス・アダプタを使用してアクセスできるリモート・キャッシュの構成を説明している次の項を参照してください。

14.1.4.1.1 リモート・クラスタへのコヒーレンス・アダプタ接続の構成

SOAコヒーレンス・アダプタを使用して、リモート・キャッシュにアクセスできます。

リモート・キャッシュの名前は、次の例の構成ファイルに記録され、このファイルはextend-config.xmlファイルと呼ばれます。この構成ファイルの場所は、プロパティCacheConfigLocationの値として指定する必要があります。キャッシュ名を含めることに加えて、構成ファイルには、リモートCoherenceクラスタに接続するための情報も必要です。

ここでのManagedConnectionFactoryの例では、PojoJarFileの場所も指していることに注意してください。

詳細は、Coherence Extendの構成および使用に関するホワイトペーパーを参照してください。

また、第3章「Coherence*Extendの設定」も参照してください。

例 - リモート・クラスタのManagedConnectionFactory

<connection-instance>
<jndi-name>eis/Coherence/Remote</jndi-name>
<connection-properties>
<properties>
<property>
<name>CacheConfigLocation</name>
<value>/scratch/amahajan/Temp/coherence/dhqa/extend-config.xml</value>
</property>
<property>
<name>ClassLoaderMode</name>
<value>CUSTOM</value>
</property>
<property>
<name>PojoJarFile</name>
<value>/scratch/amahajan/Temp/coherence/dhqa/book.jar</value>
</property>
<property>
<name>WLSExtendProxy</name>
<value>false</value>
</property>
</properties>
</connection-properties>
</connection-instance>

例 - リモート・キャッシュを定義するためのサンプルextend-config

この例では、拡張構成によって、アダプタはアドレス10.240.82.123で実行され、ポート14777上でリスニングする拡張プロキシに接続できます。

<?xml version="1.0"?>

<!DOCTYPE cache-config SYSTEM "cache-config.dtd">

<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>samples-cache</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>samples-cache-binxml</cache-name>
<scheme-name>extend-dist</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<remote-cache-scheme>
<scheme-name>extend-dist</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>10.240.82.123</address>
<port>14777</port>
</socket-address>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
</cache-config>

14.1.4.1.2 ローカル・クラスタへのコヒーレンス・アダプタ接続

-

コヒーレンス・アダプタはデフォルトのコネクション・ファクトリを提供して、即時利用可能なCoherenceキャッシュに接続し、adapter-localと呼ばれるキャッシュにも接続します。

14.2 コヒーレンス・アダプタの構成

コヒーレンス・アダプタ構成ウィザードを使用するには、次の手順を実行します。

1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」を選択します。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

2. 「コンポーネント」ウィンドウから「コヒーレンス・アダプタ」をドラッグ・アンド・ドロップします。コヒーレンス・アダプタの「ようこそ」画面が表示されます。「次へ」をクリックします。

3. 「コヒーレンス接続」画面で、コヒーレンス接続のJNDI名を指定します。「次へ」を選択します。

図14-1 コヒーレンス・アダプタ構成ウィザードの「サービス名」画面

4. 「操作タイプ」ページで、Coherenceキャッシュに対して実行する有効な操作を指定します。既存のWSDLをインポートした場合、操作名は事前移入されます。操作は、「Put」(「キャッシュにアイテムを格納」)、「Get」(「キャッシュからアイテムを取得」)、「削除」(「キャッシュからアイテムを削除」)または「問合せ」(「キャッシュからアイテムを問合せ」)です。下の画面例では、「Put」が選択されています。

図14-2 「Put」が選択されたコヒーレンス・アダプタ構成ウィザードの「操作タイプ」ページ

5. 「Put」を選択した場合は、「Put」ページが表示されます。このページでは、Put操作の構成パラメータを取得します。この画面で、次のフィールドを指定します。

- キャッシュ・タイプ: 値(「XML」、「POJO」)を含むドロップダウン・コンボ・ボックス。キャッシュに格納するアイテムのタイプに対応する値を使用します。

- キャッシュ名: このテキスト・フィールドにキャッシュ名を入力します。これは、Coherenceキャッシュを一意に識別する名前です。

- キー: テキスト・フィールドにキーを入力するか、自動生成チェック・ボックスを選択してキーが生成されるようにします。選択した場合、キーはCoherenceランタイムによって自動的に生成されます。キーの自動生成プロセスでは、「キー・タイプ」が「文字列」に設定されます。

- キー・タイプ: 「キー・タイプ」および「キー」は、フィルタの入力を選択した場合は無効になり、キー・タイプとキーの入力を選択した場合は有効になります。ここでの「キー・タイプ」コンボ・ボックスには、Java単純型(string、integer、long、float、double)のリストが含まれています。

- 自動生成キー: コヒーレンス・アダプタ構成ウィザードでキーを生成する場合は、このボックスを選択します。

- 存続時間: 「デフォルト」、「常に」または「カスタム」を選択します。「カスタム」を選択した場合は、ミリ秒単位の値を指定できます。この値は、エントリがCoherenceキャッシュ内に残る時間を示します。デフォルトでは、メッセージは期限切れになりません。「存続時間」プロパティは、ローカル・キャッシュではなくリモート・キャッシュに適用可能です。ローカル・キャッシュの場合、エントリは、削除しないかぎり、またはSOAサーバーが終了しないかぎり、常にキャッシュに残ります。

図14-3 コヒーレンス・アダプタ構成ウィザードの「Put操作の構成」ページ

6. コヒーレンス・アダプタの「操作タイプ」ページで、「キャッシュからアイテムを取得」操作を選択した場合、「Get操作の構成」画面が表示されます。

図14-4 コヒーレンス・アダプタの「Get操作の構成」ページ

次のフィールドに入力して、キャッシュからアイテムを取得します。

- キャッシュ・タイプ: 値(「XML」、「POJO」)を含むドロップダウン・コンボ・ボックス。取得するエントリのタイプに対応する値を選択します。

- キャッシュ名: アイテムの取得元となるキャッシュ名を入力します。

- キー・タイプ: Get操作の場合、このフィールドは常に有効になっています。

- キー: キャッシュ・エントリのキーをこのテキスト・フィールドに入力します。

7. 「操作タイプ」画面でキャッシュから削除オプションを選択すると、「キャッシュからアイテムを削除」画面が表示されます。

図14-5 コヒーレンス・アダプタ構成の「削除操作の構成」画面

キャッシュからアイテムを削除するための構成パラメータを入力し、「次へ」をクリックします。

- キャッシュ名: キャッシュ・アイテムの名前。

- キー・タイプ: 削除操作を実行する場合に有効になります。

- キー: キャッシュ・アイテムのキー。

- フィルタ: キャッシュ名の文字列フィルタ。キーまたはフィルタを指定できますが、両方を指定することはできません。

注意:

削除操作でフィルタを使用する場合、コヒーレンス・アダプタは、削除操作が成功したかどうかにかかわらず、削除操作による影響を受けるエントリ数を報告しません。

特定のエントリの削除にキーを使用する場合、コヒーレンス・アダプタは数を報告しますが、Coherenceでの削除操作が成功した場合、常に1になります。

14.3 Coherenceキャッシュ内のアイテムの問合せ

Coherenceキャッシュ内のアイテムを問い合せることもできます。

1. これを行うには、「操作」画面から「問合せ」を選択します。コヒーレンス・アダプタの「問合せ操作の構成」画面が表示されます。

図14-6 コヒーレンス・アダプタの「問合せ操作の構成」画面

2. 「問合せ操作の構成」画面で、次を入力します。

- キャッシュ・タイプ: ドロップダウン・リストから「XML」または「POJO」を選択します。

- キャッシュ名: キャッシュの名前。

- フィルタ: Coherenceの問合せ言語のフィルタ式を手動で入力できます。フィルタを指定しない場合、コヒーレンス・アダプタ構成ウィザードにより、すべてのアイテムが返されることが警告されます。

- アイテム数: 問合せから返されるアイテム数の制限を指定する整数。

- 索引名: (オプション)キャッシュに作成される索引名。ソートされた索引を作成するには、「ソート」チェック・ボックスを選択します。

- キーのみを返す: このボックスを選択し、返すキーのタイプを指定します。このボックスが選択されている場合、問合せから返されたエントリと値が一致するキーのみが返されます。
POJOキャッシュ・タイプの場合、索引および順序付きフィールドのキー・タイプのみが有効です。XMLキャッシュ・タイプの場合、key()トークンのみをフィルタ式で使用できます。

つまり、フィルタ式を指定する場合、キャッシュ・オブジェクト・キーを意味する特殊なトークン・キー()のみを使用できます。たとえば、次のキーのいずれかを使用できます。

key() = 1234
key() = 5678

POJOキャッシュ・タイプを使用する場合、POJOオブジェクトからのトークンと、特殊な組込みkey()トークンの両方を使用するフィルタ式を作成できます。

14.4 「XML」が選択されている場合のPut操作、Get操作および問合せ操作のメッセージの定義

Put、Getまたは問合せのいずれかの操作でキャッシュ・タイプとして「XML」を選択した場合、「スキーマの指定」ページが表示されます。このページで、Coherenceキャッシュ・オブジェクトのスキーマを選択します。図14-7を参照してください。

図14-7 コヒーレンス・アダプタ構成ウィザードのメッセージ(「スキーマの指定」)画面

1. 「URL」フィールドでスキーマ・ファイルの場所を指定して、着信ファイルの要素を定義するスキーマ要素を選択します。既存のスキーマ定義を検索するには、「参照」ボタンを使用します。

2. この時点での選択に適用される考慮事項を次に示します。

- Put操作の場合、指定した値タイプに生成されたスキーマ、または「スキーマ」ページで指定したスキーマに対応するリクエスト・メッセージが生成されます。レスポンス・メッセージには、Coherenceサーバーで作成されたキャッシュ・エントリのReturnIdentifierが含まれます。

- Get操作の場合、リクエスト・メッセージは、値タイプのスキーマ、または「スキーマ」ページで指定したスキーマを指します。空のリクエスト・メッセージが作成されます。

- 問合せ操作の場合、フィルタ式にバインド変数がある場合、これらのバインド変数の要素が含まれたリクエスト・メッセージが生成されます。レスポンス・メッセージは、値タイプに生成されたスキーマであるか、「スキーマ」ページで指定したスキーマです。

14.4.1 「POJO」が選択されている場合のPut操作、Get操作および問合せ操作のメッセージの定義

Get操作、Put操作または問合せ操作でキャッシュ・タイプとして「POJO」を選択した場合、「値タイプ・クラスの指定」画面が表示されます。

図14-8 コヒーレンス・アダプタ構成ウィザードの値タイプ・クラス画面

キャッシュ・タイプとして「POJO」を選択した場合のメッセージを定義するには、次の手順を実行します。

1. PUT操作のPOJOキャッシュ・タイプの値タイプを「値タイプ」ボックスに入力します。ブラウザを使用して値タイプを検索できます。

2. オプションで、スキーマのメタデータ・マッピング・ファイルをメタデータ・マッピング・フィールドに入力します。

メタデータ・マッピング・ファイルは、POJOからXMLへの変換、およびXMLからPOJOへの変換に役立ちます。指定したマッピング・ファイルはJDeveloperプロジェクトにコピーされます。ブラウザを使用して、メタデータ・マッピング・ファイルを検索できます。マッピング・ファイルはJDeveloperプロジェクトに格納されます。(XMLを指定すると、アダプタは、XMLをオブジェクトに変換してからキャッシュに追加します。この逆が、キャッシュ内のオブジェクトを問い合せた場合に発生します。アダプタは、キャッシュ内に格納されているオブジェクトをXMLに変換し、それを出力として渡します。)

マッピング・ファイルが指定されている場合、コヒーレンス・アダプタによりスキーマが自動的に生成されます。

メタデータ・ファイルを指定しない場合、コヒーレンス・アダプタ構成ウィザードにより、値タイプ・クラスがイントロスペクトされ、マッピング・ファイルが自動的に生成されます。

注意:

: 問合せ操作タイプでは、「キーを返す」を選択した場合、XMLまたはPOJOキャッシュ・タイプの「メッセージ」ページは表示されません。

14.5 コヒーレンス・アダプタのファイルおよびアーティファクト

この項では、コヒーレンス・アダプタの設計時アーティファクトの例を示します。

14.5.1 JCAファイル

JCAファイルには、サポートされている各操作のJCAプロパティ値が格納されます。

例 - 作成されたJCAファイル

<adapter-config name="cohPut1" adapter="Coherence Adapter"               wsdlLocation="../WSDLs/cohPut1.wsdl"            xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/coherence"/>
<endpoint-interaction portType="Put_ptt" operation="Put">
<interaction-spec className=      "oracle.tip.adapter.coherence.CoherenceInteractionSpec">
<property name="CacheName" value="TestCache"/>
<property name="Key" value="ABC12345678"/>
<property name="KeyType" value="String"/>
<property name="ValueType" value="com.coherence.vt.Book"/>
<property name="TimeToLive" value="60"/>
<property name="MappingsMetadataFile" value="book-oxm-mappings.xml"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

14.5.2 Put操作のWSDL

次の例に、コヒーレンス・アダプタのPut操作のWSDLを示します

例 - コヒーレンス・アダプタのPut操作のWSDL

<wsdl:definitions name="cohPut1" targetNamespace=   "http://xmlns.oracle.com/pcbpel/adapter/coherence/Application1/Project1/cohPut1"
xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns=http://xmlns.oracle.com/pcbpel/adapter/coherence/Application1/             Project1/cohPut1
xmlns:imp1=" http://xmlns.oracle.com/pcbpel/adapter/coherence"
xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
<plt:partnerLinkType name="Put_plt">
<plt:role name="Put_role">
<plt:portType name="tns:Put_ptt"/>
</plt:role>
</plt:partnerLinkType>
<wsdl:types>
<schema targetNamespace= “http://xmlns.oracle.com/pcbpel/adapter/coherence/Application1/Project1/cohPut1"  xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace=" http://xmlns.oracle.com/pcbpel/adapter/coherence " schemaLocation="xsd/book_cache.xsd"/>
</schema>
<schema <schema targetNamespace= “http://xmlns.oracle.com/pcbpel         /adapter/coherence/Application1/Project1/cohPut1"  xmlns="http://www.w3.org/2001/XMLSchema">
<element name="returnId" type="xsd:string"/>
</schema>
</wsdl:types>
<wsdl:message name="Request_msg">
<wsdl:part name="body" element="imp1:book"/>
</wsdl:message>
<wsdl:message name="Response_msg">
<wsdl:part name="body" element="tns: returnId "/>
</wsdl:message>
<wsdl:portType name="Put_ptt">
<wsdl:operation name="Put">
<wsdl:input message="tns:Request_msg"/>
<wsdl:output message="tns:Response_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

14.5.3 バインド変数が含まれるフィルタ式による削除のWSDL

Coherenceでのフィルタ式による削除操作のWSDLを示します。

例 - Coherenceでのフィルタ式による削除操作のWSDL

<wsdl:definitions name="cohRem1"
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter
/coherence/Application1/Project1/cohRem1"
xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns=http://xmlns.oracle.com/pcbpel/adapter/coherence
/Application1/Project1/cohRem1
xmlns:plt="http://schemas.xmlsoap.org/ws/
2003/05/partner-link/">
<plt:partnerLinkType name="Remove_plt">
<plt:role name="Remove_role">
<plt:portType name="tns:Remove_ptt"/>
</plt:role>
</plt:partnerLinkType>
<wsdl:types>
<schema targetNamespace=
“http://xmlns.oracle.com/pcbpel/adapter
/coherence/Application1/Project1/cohRem1"      xmlns="http://www.w3.org/2001/XMLSchema">
<element name="RemoveRequest">
<complexType>
<element name="bind1" type="string"/>
<element name="bind2" type="string"/>
</complexType>
</element>
</schema>
<schema targetNamespace= “http://xmlns.oracle.com/
pcbpel/adapter/coherence
/Application1/Project1/cohRem1"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="ReturnCount" type="integer"/>
</schema>
</wsdl:types>
<wsdl:message name="Request_msg">
<wsdl:part name="body" element="tns:RemoveRequest "/>
</wsdl:message>
<wsdl:message name="Response_msg">
<wsdl:part name="body" element="tns: ReturnCount "/>
</wsdl:message>
<wsdl:portType name="Remove_ptt">
<wsdl:operation name="Remove">
<wsdl:input message="tns:Request_msg"/>
<wsdl:output message="tns:Response_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

14.5.4 Get操作のWSDL

次の例に、CoherenceでのGet操作用に生成されたWSDLを示します。

例 - Get操作のWSDL

<wsdl:definitions name="cohRem1" targetNamespace=
"http://xmlns.oracle.com/
pcbpel/adapter/coherence/Application1/Project1/cohGet1"
xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns=http://xmlns.oracle.com/pcbpel/
adapter/coherence/Application1/Project1/cohGet1
xmlns:imp1=" http://xmlns.oracle.com/pcbpel/              adapter/coherence"
xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
<plt:partnerLinkType name="Get_plt">
<plt:role name="Get_role">
<plt:portType name="tns:Get_ptt"/>
</plt:role>
</plt:partnerLinkType>
<wsdl:types>
<schema targetNamespace=            “http://xmlns.oracle.com/pcbpel/adapter
/coherence/Application1/Project1/cohGet1"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="empty"><complexType/></element>
</schema>
<schema targetNamespace=
“http://xmlns.oracle.com/pcbpel/adapter/
coherence/Application1/Project1/cohGet1"  xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace=
"http://xmlns.oracle.com/pcbpel/adapter/coherence
"schemaLocation="xsd/book_cache.xsd"/>
</schema>
</wsdl:types>
<wsdl:message name="Request_msg">
<wsdl:part name="body" element="tns:empty "/>
</wsdl:message>
<wsdl:message name="Response_msg">
<wsdl:part name="body" element="imp1:book "/>
</wsdl:message>
<wsdl:portType name="Get_ptt">
<wsdl:operation name="Get">
<wsdl:input message="tns:Request_msg"/>
<wsdl:output message="tns:Response_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

14.5.5 バインド変数が含まれるフィルタ式による問合せのWSDL

次の例は、バインド変数が含まれるフィルタ式による問合せ操作のWSDLを示しています。

例 - バインド変数が含まれるフィルタ式による問合せのWSDL

<wsdl:definitions name="cohQuery1"         targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/coherence    /Application1/Project1/cohQuery1"
xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns=http://xmlns.oracle.com/pcbpel/adapter            /coherence/Application1/Project1/cohQuery1
xmlns:imp1=" http://xmlns.oracle.com/pcbpel/
adapter/coherence"
xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/">
<plt:partnerLinkType name="Query_plt">
<plt:role name="Query_role">
<plt:portType name="tns:Query_ptt"/>
</plt:role>
</plt:partnerLinkType>
<wsdl:types>
<schema targetNamespace= “http://xmlns.oracle.com/
pcbpel/adapter/coherence
/Application1/Project1/cohQuery1"                    xmlns="http://www.w3.org/2001/XMLSchema">
<element name="QueryRequest">
<complexType>
<element name="bind1" type="string"/>
<element name="bind2" type="string"/>
</complexType>
</element>
</schema>
<schema targetNamespace= “http://xmlns.oracle.com/
pcbpel/adapter/coherence
/Application1/Project1/cohQuery1"  xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace=" http://xmlns.oracle.com/
pcbpel/adapter/coherence"
schemaLocation="xsd/book_cache.xsd"/>
</schema>
</wsdl:types>
<wsdl:message name="Request_msg">
<wsdl:part name="body" element="tns:QueryRequest "/>
</wsdl:message>
<wsdl:message name="Response_msg">
<wsdl:part name="body" element="imp1:book "/>
</wsdl:message>
<wsdl:portType name="Query_ptt">
<wsdl:operation name="Query">
<wsdl:input message="tns:Request_msg"/>
<wsdl:output message="tns:Response_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

14.6 コヒーレンス・アダプタ使用のヒント

次のエラーが表示される場合があります。

Execute of operation 'Put' failed due to: Service "TransactionalCache" has been started by a different configurable cache factory.; nested exception is:  java.lang.IllegalStateException: Service "TransactionalCache" has been started by a different configurable cache factory.

このメッセージは、サービスTransactionalCacheが複数の場所で定義されていることを意味します。このエラーが発生するのは、コヒーレンス・アダプタのPut操作のみに限定されません。この例外は、コヒーレンス・アダプタがサポートするすべての操作で発生する可能性があります。

この問題は、次のような構成ファイルがある場合に発生します。

最初の構成ファイルa-config.xmlに、次が含まれます。

<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>adapter-local</cache-name>
<scheme-name>transactional</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<transactional-scheme>
<scheme-name>transactional</scheme-name>
<service-name>TransactionalCache</service-name>
<autostart>true</autostart>
</transactional-scheme>
</caching-schemes>
</cache-config>

2つ目の構成ファイルb-config.xmlに、次が含まれます。

<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>movie-local</cache-name>
<scheme-name>transactional</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<transactional-scheme>
<scheme-name>transactional</scheme-name>
<service-name>TransactionalCache</service-name>
<autostart>true</autostart>
</transactional-scheme>
</caching-schemes>
</cache-config>

あるjndiにa-config.xmlを、別のjndiにb-config.xmlを使用し、2つのコンポジットでこれら2つの異なるjndiを使用します。最初の構成をデプロイすると、問題なく完了しますが、2つ目のデプロイメントは、サービスTransactionalCacheが最初の構成によりすでに開始されているため、失敗します。

解決方法は、1つのconfig.xmlファイルのみを持つようにし、異なるジョブ間で同じconfig.xmlを使用することです。たとえば、次のconfig.xmlファイルを異なるjndi間で使用できます。

<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>adapter-local</cache-name>
<scheme-name>transactional</scheme-name>
</cache-mapping>
<cache-mapping>
<cache-name>movie-local</cache-name>
<scheme-name>transactional</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<transactional-scheme>
<scheme-name>transactional</scheme-name>
<service-name>TransactionalCache</service-name>
<autostart>true</autostart>
</transactional-scheme>
</caching-schemes>
</cache-config>

15 Oracle JCA Adapter for JDE Edwards World

この章では、Oracle JCA Adapter for JDE Edwards Worldの使用方法について説明し、設計時構成情報と実行時構成情報、および概念の概要を示します。JDE Worldシステムは、IBMのミニコンピュータで実行されるERP (エンタープライズ・リソース・プランニング)製品です。JD Edwards Worldアダプタでは、IBMシステムへの新しいJDBCドライバ・ベースの接続を使用し、SOA統合ユーザーが通常のデータベースとしてのJDE Worldシステムとやり取りできるようにします。

JD Edwards Worldシステムの詳細は、Oracle JD Edwards Worldドキュメント・ページを参照してください。

この章の内容は次のとおりです。

- JD Edwards WorldシステムとJDE Edwards Worldアダプタの概念

- JD Edwards Worldアダプタの機能

- JD Edwards Worldアダプタの構成

- JD Edwards Worldアダプタ構成ウィザードのフロー: 挿入操作

- JD Edwards Worldアダプタ: 選択操作

15.1 JD Edwards WorldシステムとJDE Edwards Worldアダプタの概念

J.D. Edwards Worldシステムでは、相互運用性フレームワークによってエンタープライズ・システムと統合できます。Oracle JD Edwards Worldアダプタでは、アダプタ・フレームワークを使用し、様々な統合アクセス方法を活用して最大限の柔軟性および機能性が提供されます。

JDE Edwards Worldシステムはデータベースベースの統合です。J.D.Edwardsアプリケーションは、本質的にはデータベースです。そのレポートおよび情報抽出はSQL問合せに基づきます。同様に、JDE Edwards Worldシステムとの書込み対話は特殊表への挿入に基づきます。特殊表はZ表と呼ばれ、外部ソース(フラット・ファイル、スプレッドシートまたは別のタイプのファイル)からインポートしたデータを一時的に保存するために使用されます。JD Edwards Worldシステムではこのデータが処理され、実際のデータベース表にインポートされます。Z表は、インポート・データの形式およびプロセスをできるだけ一貫させるのに役立ちます。

Zファイルには、JD Edwardsシステムでのトランザクションの処理に必要なすべての情報が含まれており、各Zファイルには、関連付けられているバッチ処理プログラムがあります。

Zファイルは、販売注文や住所など、様々なタイプのトランザクションに対応しています。JD Edwards Worldシステム・ドキュメントには、様々なタイプのファイルおよびJD Edwards Worldシステム内でのそれらのファイルの使用について記載されています。

JD Edwards Worldアダプタでは、次を実行して、統合のフィルタによって、基礎となるJD Edwards Worldシステム・データベース表が公開されます。

- 表/列の代替記述名である統合点のみの公開。JD Edwards Worldアダプタでは、JD Edwards World表の実際の名前は公開されません。

- 適切な統合タッチ・ポイントを検索できる強力なUIの提供。

- 特定の信頼できるコール元のみが制限された一連の表にデータを挿入できるようにするJDBCドライバの提供。

JD Edwards Worldシステムでは情報は、データベース・アダプタで使用できない形式で表内にあります。数値は小数点以下の桁数なしで保存され、日付には特定の書式が使用され、接続はtranslate binary=trueを使用して行う必要があります(AS/400 DB2に固有)。

JD Edwards Worldアダプタのために、これらの形式は、環境設定やデータ変換など、一般的な実行時アダプタ機能のほとんどを処理するJD Edwards World JDBCドライバによって処理されます。このため、JDBCドライバでは、JD Edwards WorldアダプタとJD Edwards WorldシステムのZ表の間の通信手段が提供されます。

15.2 機能

JD Edwards Worldアダプタの機能は、次のとおりです。

- JDE World接続の作成テンプレート。アダプタでは、構成ウィザードによって、JD Edwards Worldシステムとの接続を支援する接続テンプレートを使用できます。

- JDE Worldカスタム接続パラメータ。JD Edwards Worldアダプタでは、構成ウィザードによって、JDE Worldシステムに固有の接続パラメータを使用できます。

- 選択された表によって決定される操作。JD Edwards Worldアダプタを使用すると、選択されている表によって決定される操作を選択できます。

- 表の選択ブラウザ。この機能を使用すると、JD Edwardsアダプタを使用してZ表に対する選択を実行するための支援および前提条件として、JD Edwards WorldのZ表を参照できます。

- ビジネス・モジュールによってグループ化されたJD Edwards World システムのZ表。挿入を実行し、選択を行う表の決定を支援するため、JD Edwards Worldアダプタでは、Z表のJD Edwards Worldシステム・ビジネス・モジュールによるグループ化が提供されます。このようなビジネス・モジュールには、エンタープライズ内での用途を明確に示すわかりやすい名前が付いています。

- JD Edwards Worldアダプタでは、統合エンドポイントとして使用されるZ表のみが公開されます。統合エンドポイントではないZ表は公開されません。

- JD Edwards Worldアダプタでは、接続プール・サポートが提供されます。

- Z表挿入サポート。JD Edwards WorldシステムのZ表に挿入するには、JDE World JCAアダプタによって取得されたSQL接続に、挿入文を実行する権限がある必要があります。
この場合も、JD World Systemアダプタによって操作を実行する機能が提供されたZ表は、ステージング表となります。つまり、J D Edwardsとの間でデータをインポート/エクスポートするためのデータ・インタフェースとなります。外部アプリケーションは、常にZ表とのインタフェースをとります。Z表のデータは、バッチ・プログラミングおよびバックエンドJD Edwards Worldシステムのその他のインタフェースを使用して実際のJDEdwards Worldシステムの表に移動できます。異なる機能領域の異なるトランザクションには、実際のJDEdwards Worldの表に移動するための独自の定義済Z表および構成があります。各Z表からのデータ移動が可能になる処理オプションに関する情報が記載されている、垂直方向の(財務、製造、人事管理) JD Edwards Worldドキュメント・セットをそれぞれ参照してください。

- ポーリング・サポートなし。JD Edwards Worldアダプタには、ポーリング・サポートがありません。

- トランザクション・サポートなし。数多くのアダプタでは、通常、XAトランザクションがサポートされていますが、JDEdwards Worldアダプタではサポートされません。理由の1つは、JDE Worldシステムが非トランザクションであるためです。JD Edwards Worldシステムの基礎となるAS/400 DB2データベースでは、通常、ジャーナル処理を実行できません。つまり、XAトランザクションのみでなく、ローカル・トランザクションの開始とコミットもサポートされていません。
また、JD Edwards Worldアダプタで使用可能なのは、選択と挿入の2つのデータベース・オプションのみです。選択は、トランザクションである必要がありません。挿入もZ表に対してのみであり、常に非トランザクションのRPGコールに関連付けられます。

15.3 JD Edwards Worldアダプタの構成

JD Edwards Worldアダプタには、複数の準備構成手順が関係しています。アダプタをデプロイする前に、実行時構成および設計時構成の両方を提供する必要があります。

15.3.1 JDEdwards Worldアダプタの接続プーリングの構成

JCAコネクタでは、プーリング・サポートが提供される必要があります。データベース・アダプタによって、データソースからSQL接続が取得されます。これにより、プーリング要件が基礎となるJDBCドライバおよびそのデータソース実装に委任されます。

JD Edwards World JCAアダプタはOracleデータベース・アダプタに基づいているため、JD Edwards Worldアダプタのプーリング・サポートを構成するプロセスは、Oracleデータベース・アダプタにプーリング・サポートを提供するプロセスと似ています。

JD Edwards Worldアダプタの接続プーリングを提供するには、次の手順を実行します。

1. JD Edwards Worldアダプタが含まれているビルドにOracle WebLogic Serverがインストールされていることを確認します。次に、WebLogicコンソールの検索パネルで、JD Edwards Worldアダプタを検索して見つけます。
アダプタの名前を「検索」フィールドに入力します。検索パネルに、検索結果としてJDEdwards WorldアダプタとそのタイプAppDeploymentが表示されます。図15-1 を参照してください。

図15-1 WebLogicコンソールでのJDEdwards Worldアダプタの検索

2. JDEdwards Worldアダプタはオプションのアダプタであるため、初期のJDeveloper状態は「アクティブ」ではなく「インストール済み」です。JDEdwards Worldアダプタの状態をアクティブにする必要があります。状態をアクティブにするには、次の手順を実行します。

a. WebLogicコンソールで、「ターゲット」タブを選択します。

b. アダプタをデプロイするサーバーを選択します。「保存」をクリックします。

図15-2 WebLogicコンソールでのサーバーの選択

3. Sourceforgeからjt400.jarファイルを取得する必要があります(jt400.jarファイルは、その場所ではJTOpen 7.9と呼ばれています)。JTOpenは、IBM Toolbox for Java Licensed Program Product (LPP)のオープン・ソース・バージョンです。
jt400.jarファイルを<middleware_home>/user_projects/domains/WLS_SOA/lib/に配置します。

4. アダプタがアクティブであることを確認するには、「制御」タブを選択します。アダプタを手動でアクティブにする必要がある場合があります。これを行うには、JDBCWorldAdapterの横のチェック・ボックスを選択して、「開始」を選択します。

図15-3 JD Edwards Worldアダプタがアクティブ状態であることの確認

5. 次の手順では、WebLogicコンソールで「データ・ソース」→「サービス」に進み、「汎用データ・ソース」を選択して、データソース接続を作成します。

図15-4 汎用データソースの選択

6. 名前としてjdbc/JDEWorldDataSourceを指定します。この名前はデフォルトのJCA eis/JDEWorld/JDEWorldDemoインスタンスが参照している用語を表しています。データベース・タイプOtherを使用します。

図15-5 JDBCデータソースJDEWorldDataSourceの定義

7. 「トランザクション」タブで、「グローバル・トランザクションのサポート」が選択されていないことを確認して、XAを無効にします。図15-6を参照してください。

図15-6 WebLogicの「トランザクション」タブで「グローバル・トランザクションのサポート」が選択されていないことの確認

8. 「接続プール」ページに進み、接続プール情報を構成します。図15-7を参照してください。
接続プールURLは、次のようになる必要があります。「接続プール」ページでは、プロパティとして3つの設定(「ユーザー」、「ServerName」および「JDEWEnvironment」)も指定します(3つのすべての設定がすでに接続URLに表示されているか、またはデータソースの構成時に入力されている場合でも)。

jdbc:jdew://JDED;JDEWEnvironment=QA92;JDEWTableNomenclature=OBJN_OBJT;JDEWColumnNomenclature=FDFT_FDFN;translate binary=true;date format=mdy;prompt=false;auto commit=true;

user=BPELTEST
serverName=JDED2.us.mydomain.com
JDEWEnvironment=A93BPELTEST
JDEWTableNomenclature=OBJN_OBJT
JDEWColumnNomenclature=FDFT_FDFN

図15-7 WebLogicコンソールでの接続プールURLの構成

9. 「詳細」を選択し、接続予約済タイムアウトを180に設定します。アダプタの接続プールを使用した最初の接続時に、接続の作成に3分かかるため、この値が必要です。

図15-8 接続予約済タイムアウトの値の設定

10. 次に、「制御」タブを選択して、JDBCデータソースの各インスタンスを手動で制御します。

図15-9 「制御」タブを使用したデプロイ済データソースの各インスタンスの手動管理

15.4 JD Edwards Worldアダプタ構成ウィザードのフロー: 挿入操作

JD Edwardsアダプタ構成ウィザードを使用して、JDEdwards WorldのZ表への挿入操作を実行するようにJD Edwardsアダプタを構成できます。

これを行うには、次の手順を実行します。

1. JDeveloperデザイン・ビューの「参照」セクションのコンポジットまたはBPELプロセスにドラッグ・アンド・ドロップして、JDE Worldアダプタ構成ウィザードを起動します。JD Edwards Worldアダプタ構成ウィザードの「ようこそ」画面が表示されます。

2. 「サービス接続」画面を使用して、サービス接続を確立します。既存の接続を参照するか、またはこのページで新しい接続情報を指定して、既存の接続を編集します。「次へ」をクリックします。

3. JDE Worldアダプタ構成ウィザードの「表の選択」画面が表示されます。この画面では、JD Edwards WorldのZ表に対して実行できる2つの操作(「Z-表挿入」または「選択」)のいずれか1つを選択できます。この例では、「Z-表挿入」が選択されています。「次へ」をクリックします。

図15-10 JDE Worldアダプタ構成ウィザードの「表の選択」画面

4. 「サービス接続」ページが開き、このサービスの問合せのためのルート・データベースを選択できます。

これを行うには、操作およびルート・データベース表を実行するZ表の基本について理解している必要があります。これは、挿入の実行または問合せを行うJD Edwards Worldシステムのビジネス・モジュールの理解にも役立ちます。

このページでは、ページの下部にある「表のインポート」ボタンをクリックして、Z表をインポートできます。このリストからZ表を選択すると、操作のルート・データベースとなる表が選択されます。追加したZ表を削除することもできます。

これを行うには、次の手順を実行します。

- 「表のインポート」ボタンを選択して、Z表をインポートし、ルート・データベース表にする表を選択します。

- インポート後に、表を削除できます。表をリストから削除するには、適切な表を選択し、「表の削除」ボタンを選択して、インポートする表のリストからZ表を削除します。

- 「次へ」を選択します。

図15-11 ルート・データベース表の選択

5. JD Edwards Worldアダプタ構成ウィザードに、「リレーションシップ」画面が表示されます。この画面には、ルート・データベースから使用可能なリレーションシップのリストが表示されます。

新しいリレーションシップを定義するには、画面下部に表示されている「作成」ボタンをクリックします。このボタンを使用して、ルート・データベースからアクセス可能な表を提供できます。「作成」ボタンの横の「削除」ボタンを使用すると、表をルート・データベース表からアクセスできないようにすることができます。

また、リレーションシップ表をクリックして、名前を変更できます。単に次の画面に移動することもできます。

オプションの作成または削除の完了後、または何も実行しなかった後に、例に示すように「次へ」を選択します。

図15-12 JDE Worldアダプタ構成ウィザードの「リレーションシップ」画面

6. JDE Worldアダプタ構成ウィザードの「属性のフィルタ処理」画面が表示されます。この画面には、インポートされた表の定義から作成された属性フィルタが表示されます。これには定義したリレーションシップも含まれます。

また、実行するデータベース問合せから除外する属性を選択解除できます。主キー属性は除外できません。すべての属性を選択するには「すべて選択」を、すべての属性を選択解除するには「すべて選択解除」を選択します。

「次へ」を選択します。

図15-13 JDE Worldアダプタ構成ウィザードの「属性のフィルタ処理」画面

7. JDE Worldアダプタ構成ウィザードの「詳細オプション」画面が表示されます。このページでは、JDBCオプション問合せタイムアウトオプションが提供されます。この値をデフォルトの0から変更するか、または「次へ」を選択して、デフォルト値を受け入れることができます。

図15-14 JDE Worldアダプタ構成ウィザードの「詳細オプション」画面

8. JDE Worldアダプタ構成ウィザードの「JCAエンドポイント・プロパティ」画面が表示されます。

「自動再試行」セクションでは、操作のタイムアウト時の自動再試行の値を指定します。接続関連のフォルトが発生した場合はこの値を使用し、invokeアクティビティを回数制限付きで自動的に再試行できます。このセクションのフィールドでは、次の値を指定できます。

- 無限に再試行するには、「試行」フィールドにunlimitedと入力します。

- 「間隔」は、再試行間の遅延です。

- 「バックオフ係数: x」を指定すると、再試行間の待ち時間を延長できます。開始間隔に1、バックオフに2を指定して9回再試行すると、1、2、4、8、16、32、64、128および256 (2^8)秒後に再試行されます。

- 「最大間隔」は、再試行間の遅延の間隔数です。

図15-15 JDE Worldアダプタ構成ウィザードの「JCAエンドポイント・プロパティ」

15.5 JD Edwards Worldアダプタ: 選択操作

JDEWorldアダプタでは、JD Edwards WorldのZ表からの選択または問合せを実行する機能が提供されます。この操作を構成するには、JD Edwards Worldアダプタ構成ウィザードを使用します。

これを行うには、次の手順を実行します。

1. 「表の選択」画面で「選択」操作タイプを選択し、「次へ」を選択します。

図15-16 JD Edwards Worldアダプタの「表の選択」画面

ここでは、「選択」が選択されています。

図15-17 選択操作が選択されているJDE Worldアダプタ構成ウィザード

2. 「サービス接続」ページが開き、このサービスの問合せのためのルート・データベースを選択できます。これを行うには、操作およびルート・データベース表を実行するZ表の基本について理解している必要があります。これは、挿入の実行または問合せを行うJD Edwards Worldシステムのビジネス・モジュールの理解にも役立ちます。

このページでは、ページの下部にある「表のインポート」ボタンを選択して、Z表をインポートできます。このリストからZ表を選択すると、操作のルート・データベースとなる表が選択されます。

追加したZ表を削除することもできます。これを行うには、次の手順を実行します。

- 「表のインポート」ボタンをクリックして、Z表をインポートし、ルート・データベース表にする表を選択します。

- インポート後に、表を削除できます。表をリストから削除するには、適切な表を選択し、「表の削除」ボタンを選択して、インポートする表のリストからZ表を削除します。

- 「Next」をクリックします。

図15-18 JDE Worldアダプタ構成ウィザードの「サービス接続」画面

3. JD Edwards Worldアダプタのシステム・ブラウザが表示されます。ここでは、インポートする表を参照できます。

図15-19 JDE Worldシステム・ブラウザ

4. システム表をクリックして、JDE Worldシステム・ブラウザのシステム表を選択します。

図15-20 JDE Worldシステム・ブラウザでのシステム表の選択

5. システム表を選択すると、表示で表のノードを展開して、表内の列を検索できます。「OK」をクリックして、インポート用の選択内容を選択します。

図15-21 JDE Worldシステム・ブラウザを使用した列およびタイプ情報の表示

6. インポート用のルート・データベース表を選択すると、「サービス接続」画面が再表示され、このサービスの問合せ用の表を選択するよう指示されます。ルート・データベース表を選択し、「次へ」をクリックしてインポートします。また、「表の削除」ボタンをクリックして、インポートしない表を将来の「インポート」リストから削除することもできます。

図15-22 表をインポートする準備ができたJDE Worldアダプタ構成ウィザードの「サービス接続」画面

7. 主キーを定義する必要がある場合は、「主キーの定義」画面が表示されます。この画面では、主キーを定義できます。アダプタでは、指定された行を一意に識別できる必要があります。ROWIDオプションは、Oracle Database、単一の表、ポーリング操作、挿入操作または選択操作の場合にのみ構成できます。この画面では、主キーの定義に関する追加情報が提供されます。この画面を使用するには、1つまたは複数の主キーの候補を選択し、「次へ」をクリックします。

図15-23 JDEアダプタ構成ウィザードの「主キーの定義」画面

8. 表を選択し、「インポート」を選択すると、JDE Edwards Worldアダプタでは、その表を問合せ操作のルート表として使用して、JDE Worldアダプタ構成ウィザードの「リレーションシップ」画面が表示されます。

この画面には、前の画面で示したルート・データベース表からアクセス可能なリレーションシップが表示されます。表と表の間にアクセス可能なリレーションシップがない場合は、画面に「アクセス可能なリレーションシップがありません」と表示されます。

この画面を使用するには、次の手順を実行します。

- 新しいリレーションシップを定義するには、「作成」ボタンを選択します。

- リレーションシップを削除するには、「削除」を選択します。

- リレーションシップの名前を変更するには、リレーションシップを選択し、「名前の変更」をクリックします。

リレーションシップの定義、名前の変更または削除が終了したか、作成または変更するリレーションシップがない場合は、「次へ」を選択します。

図15-24 JDE Worldアダプタ構成ウィザードの「リレーションシップ」画面

9. JD Edwards Worldアダプタ構成ウィザードの「属性のフィルタ処理」画面が表示されます。図15-25を参照してください。

この画面を使用して、データベース問合せから属性を除外できます。これを行うには、次の手順を実行します。

- 問合せで使用しない属性の選択を解除します。

- すべての属性を選択するには、画面下部の「すべて選択」ボタンを使用します。

- 属性の選択を解除するには、「すべて選択解除」ボタンを使用します。

- 「Next」をクリックします。

図15-25 JD Edwards Worldアダプタ構成ウィザードの「属性のフィルタ処理」画面

10. JD Edwards Worldアダプタ構成ウィザードの「選択条件の定義」画面が表示され、JD Edwards Worldアダプタ参照の選択条件を定義できます。図15-26を参照してください

- 最上部のフィールドにパラメータを入力するか、または「追加」ボタンを選択してSQL条件を追加するか、あるいはその両方を実行します。

図15-26 JDE Worldアダプタ構成ウィザードの「選択条件の定義」画面

- 「編集」を選択し、SQL式ビルダーを使用して、SQL式を作成または変更します。画面の例は、図15-27 を参照してください。

図15-27 式ビルダー

- SQLの独自のカスタムSelectを定義するには、式ビルダーで事前に生成されたSQL文字列を変更し、「OK」をクリックして、変更したSQLを使用します。

- 「選択条件の定義」画面に戻り、「外部結合を使用してマスター表とディテール表の両方の単一結果セットを返す」を選択して、関連する複数の表を問い合せる際に使用される文の合計数に影響を与える拡張機能を使用します。最も安全な方法はデフォルト(表ごとに1)を使用することで、この機能ではすべての関連表が単一の結果セットに外部結合されることで合計が1になります。

11. JD Edwards Worldアダプタ構成ウィザードの「詳細オプション」画面が表示されます。図15-28を参照してください。

この画面では、提供されているJDBCオプションの片方または両方に新しい値を入力するか、または「次へ」を選択してデフォルト値の0を受け入れることができます。

- 問合せタイムアウト: 選択操作のタイムアウト値を構成できます。

- 最大行数: 選択操作から返される行の最大数。

- 終了後に「次へ」をクリックします。

図15-28 JD Edwards Worldアダプタ構成ウィザードのアダプタ詳細オプション画面

12. JDE Worldアダプタ構成の「JCAエンドポイント・プロパティ」画面が表示されます。図15-29を参照してください。この画面では、アダプタ・フレームワークレベルのプロパティを指定できます。

推奨値を使用するには、「次へ」を選択します。次のようなプロパティがあります。

- 試行: 再試行回数。デフォルトは4です。

- 「間隔」: 再試行間の遅延または間隔。この値のデフォルトは1です。

- バックオフ係数: x: 再試行間の期間の増加を待機できます。たとえば、開始間隔に1、バックオフに2を指定して9回再試行すると、1、2、4、8、16、32、64、128および256 (2^8)秒後に再試行されます。この値のデフォルトは2です。

- 「最大間隔」: 再試行の最大間隔。この値のデフォルトは120秒です。

図15-29 JDE Worldアダプタ構成ウィザードの「JCAエンドポイント・プロパティ」画面

13. JDEdwards Worldアダプタの「終了」画面が表示されます。JD Edwards Worldアダプタの定義が終了しました。

15.5.1 構成ファイル

この章のAddressbook表を使用した構成済JD Edwardsアダプタの各例のWSDLおよび.jca構成ファイルを、参照のために示します。

15.5.1.1 挿入操作のWSDLおよび.jcaファイルの例

次の例では、挿入操作のWSDLファイルの例を示しています。

例 - 挿入操作のWSDLファイル

<wsdl:definitions
name="jdeworldReference"
targetNamespace="http://xmlns.oracle.com/pcbpel/
adapter/jdeworld/JDEW_selectAll/Insert/jdeworldReference"
xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/jdeworld/JDEW_selectAll/Insert/jdeworldReference"
xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:top="http://xmlns.oracle.com/pcbpel/adapter/
db/top/jdeworldReference"
>
<plt:partnerLinkType name="jdeworldReference_plt" >
<plt:role name="jdeworldReference_role" >
<plt:portType name="tns:jdeworldReference_ptt" />
</plt:role>
</plt:partnerLinkType>
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema" >
<import namespace="http://xmlns.oracle.com/pcbpel/
adapter/db/top/jdeworldReference" schemaLocation="../Schemas/jdeworldReference_table.xsd" />
</schema>
</wsdl:types>
<wsdl:message name="F01018Z____Address_Book_Email_URL_Z_FileCollection_msg">
<wsdl:part name="F01018Z____Address_Book_Email_URL_Z_FileCollection" element="top:F01018Z____Address_Book_Email_URL_Z_FileCollection"/>
</wsdl:message>
<wsdl:portType name="jdeworldReference_ptt">
<wsdl:operation name="zFileInsert">
<wsdl:input message="tns:F01018Z____Address_Book_Email_URL_Z_FileCollection_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

次の例では、挿入操作の.jcaファイルの例を示しています。

例 - サンプル挿入操作の.jcaファイル

<adapter-config name="jdeworldReference" adapter="jdeworld"
wsdlLocation="../WSDLs/jdeworldReference.wsdl"
xmlns="http://platform.integration.oracle/blocks/
adapter/fw/metadata">
<connection-factory UIConnectionName="JDEWConnection1"
location="eis/JDEWorld/JDEWConnection1"/>
<endpoint-interaction portType="jdeworldReference_ptt" operation="zFileInsert">
<interaction-spec className="oracle.tip.adapter.jdeworld.
JDEWorldZTableInteractionSpec">
<property name="DescriptorName"
value="jdeworldReference.F01018Z____Address_Book_Email_URL_Z_File"/>
<property name="MappingsMetaDataURL" value="jdeworldReference-or-
mappings.xml"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

15.5.1.2 選択操作のWSDLおよび.jcaファイルの例

次の例では、サンプル選択操作のWSDLファイルの例を示しています。

例 - サンプル挿入操作のWSDLファイル

<wsdl:definitions
name="jd"
targetNamespace="http://xmlns.oracle.com/pcbpel/
adapter/jdeworld/JDEW_selectAll/JDED_select1/jd"
xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://xmlns.oracle.com/
pcbpel/adapter/jdeworld/JDEW_selectAll/JDED_select1/jd"
xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
xmlns:top="http://xmlns.oracle.com/pcbpel/adapter/db/top/jd"
>
<plt:partnerLinkType name="jd_plt" >
<plt:role name="jd_role" >
<plt:portType name="tns:jd_ptt" />
</plt:role>
</plt:partnerLinkType>
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema" >
<import namespace=
"http://xmlns.oracle.com/pcbpel/adapter/db/top/jd"          schemaLocation="../Schemas/jd_table.xsd" />
</schema>
</wsdl:types>
<wsdl:message name="jdSelect_inputParameters">
<wsdl:part name="jdSelect_inputParameters" element="top:jdSelectInputParameters"/>
</wsdl:message>
<wsdl:message name=
"F0101______Address_Book_MasterCollection_msg">
<wsdl:part name=
"F0101______Address_Book_MasterCollection" element="top:F0101______Address_Book_MasterCollection"/>
</wsdl:message>
<wsdl:portType name="jd_ptt">
<wsdl:operation name="jdSelect">
<wsdl:input message="tns:jdSelect_inputParameters"/>
<wsdl:output message=
"tns:F0101______Address_Book_MasterCollection_msg"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

次の例では、サンプル選択操作の.jcaファイルの例を示しています

例 - サンプル選択操作の.jcaファイル

<adapter-config name="jd" adapter="jdeworld"
wsdlLocation="../WSDLs/jd.wsdl" xmlns="http://platform.integration.oracle/blocks/
adapter/fw/metadata">
<connection-factory UIConnectionName="JDEWConnection1" location="eis/JDEWorld/JDEWConnection1"/>
<endpoint-interaction portType="jd_ptt" operation="jdSelect">
<interaction-spec className="oracle.tip.adapter.jdeworld.JDEWorldReadInteractionSpec">
<property name="DescriptorName"
value="jd.F0101______Address_Book_Master"/>
<property name="QueryName" value="jdSelect"/>
<property name="MappingsMetaDataURL"
value="jd-or-mappings.xml"/>
<property name="ReturnSingleResultSet" value="false"/>
</interaction-spec>
</endpoint-interaction>
</adapter-config>

16 Oracle JCA Adapter for Siebel

この章では、Oracle JCA Adapter for Siebel.の概念、機能、構成について説明します。

トピック

この章のトピックは、次のとおりです:

- Oracle JCA Adapter for Siebelの概要

- Oracle JCA Adapter for Siebelの概念

- Oracle JCA Adapter for Siebel機能

- Oracle JCA Adapter for Siebelのデザイン・タイムおよびランタイム機能

- Oracle JCA Adapter for Siebelの構成

- JDeveloperを使用したアダプタのデプロイ

- Oracle JCA Adapter for Siebelのアクティブ化

- Oracle JCA Adapter for Siebelの接続プーリングの構成

- Oracle JCA Adapter for Siebelアーティファクト

16.1 Oracle JCA Adapter for Siebelの概要

Oracle JCA Adapter for Siebelは、Siebel用の最も完全な接続ソリューションを提供します。実装のための労力を最小限に抑える固有の機能を提供して、ソリューションの効果を最大化します。

Oracle JCA Adapter for Siebelは、Siebelアプリケーション・システムへの包括的な標準ベースのリアルタイム接続を提供します。アダプタは、オープンで再利用可能なサービス指向アプリケーション(SOA)を作成するJCAおよびWebサービス標準をサポートします。アダプタは、使いやすい堅牢でスケーラブルな接続プラットフォームを提供して、統合エンタープライズを作成するためにSiebelに含まれるクリティカル・ビジネス・ロジックおよびデータに簡潔にアクセスして公開します。

Oracle JCA Adapter for Siebelには、次の2つのコンポーネントが含まれます。

- SOAスイート・コンポジット・アプリケーション設計者用のJDeveloper拡張プラグイン。
プラグインにより、開発者は、Siebelシステムのアクセス、ビジネス・オブジェクト、ビジネス・コンポーネント、ビジネス・サービスと統合オブジェクトの参照およびXSD、関連付けられたオブジェクトのWSDL、実行時に使用するJCAプロパティなどのSCAアーティファクトの生成を実行できます。

- SOAスイートの実行環境。
アダプタにより、デプロイされたSOAコンポジットがリアルタイム・ビジネス・データをSiebelシステムと交換できます。Siebelビジネス・サービス、ビジネス・コンポーネントおよび統合オブジェクトの同期および非同期双方向メッセージをサポートします。アダプタは、HTTPトランスポート・プロトコルもサポートします。

16.2 Oracle JCA Adapter for Siebelの概念

この項では、Oracle JCA Adapter for Siebelの概念について説明します。

Siebelビジネス・コンポーネント: 1つ以上のデータベース表の列の論理表現を定義するSiebelオブジェクト・タイプ。ビジネス・コンポーネントは、ビジネス・コンポーネントの実表、拡張表および結合表から単一の構造に列を収集します。ビジネス・コンポーネントは、表に抽象化レイヤーを提供します。Siebel Business Applicationsのアプレットは、ビジネス・コンポーネントを参照します。基礎となる表を直接参照しません。

Siebelビジネス・オブジェクト: Siebelビジネス・オブジェクトは、一連の相互に関連付けられたビジネス・コンポーネントを使用したエンタープライズ内の論理ビジネス・モデルです。

Siebelビジネス・サービス: Siebelビジネス・サービスは、ビジネス機能を実行するために起動できる一連の機能で構成されます。

Siebel統合オブジェクト: Siebel統合オブジェクトは、Siebelビジネス・オブジェクト、XMLおよび他の外部データ構造の統合メタデータを表します。

Siebel統合コンポーネント: Siebelビジネス・コンポーネントを表すSiebel統合オブジェクトの構成部分。

Siebel統合コンポーネント・フィールド: Siebel統合コンポーネントの1つのデータ要素を含むデータ構造。Siebelビジネス・コンポーネント・フィールドを表します。

16.3 Oracle JCA Adapter for Siebel機能

この項では、Oracle JCA Adapter for Siebelの様々な機能について説明します。

Oracle JCA Adapter for Siebelのこれらの機能は、追加のソフトウェア要件なしですぐに使用できます。

包括的なSiebel接続

Oracle JCA Adapter for Siebelは、Siebelへの接続を提供します。Siebel COMおよびJava Data Bean APIを使用して、Siebelトランザクション - Siebelビジネス・オブジェクトおよびビジネス・サービスを非同期に起動します。

簡単で使いやすいデザイン・タイム・グラフィカル・インタフェース

Oracle JCA Adapter for Siebelのデザインタイム・ツールを使用すると、コーディングせずにSiebelビジネス・レイヤーと接続して様々なSiebelビジネス・オブジェクト、ビジネス・サービスおよび統合オブジェクトを動的に参照できます。デザインタイム・ツールでは、数回クリックするだけでWebサービスとしてアダプタ・サービスを公開し、迅速な実装を実現します。このイントロスペクションは動的であるため、すべてのカスタム記述または拡張Siebelインタフェースおよびオブジェクトを使用できます。

標準のサポート

Oracle JCA Adapter for Siebelはオープン・スタンダードに基づき、JCAおよびWebサービスとして基礎となるSiebel機能を公開します。Oracle Fusion Middleware製品コンポーネントは、これらの標準インタフェースを介してSiebelシステムとシームレスかつ迅速に統合されます。

Oracle Application Serverを介した完全な管理

Oracle JCA Adapter for Siebelは、Oracle Application Server上にデプロイされ、スケーラビリティおよび可用性のためにそれを利用します。Oracle Application Serverにより、ユーザーはアダプタのライフサイクルを監視および管理できます。

Siebel例外処理

Oracle JCA Adapter for Siebel例外は、再試行できる例外または再試行できない例外です。リモート例外は、通常再試行できる例外です。Oracle JCA Adapter for Siebelは、アウトバウンド起動からSiebelシステムへのエラーに基づいて、これらのタイプの例外をスローします。JCAフレームワークはリモート例外を捕捉し、再試行アクションを開始します。ビジネス例外(またはバインディング例外)は、再試行できない例外です。メッセージがリカバリ・キューに格納され、呼出し元のサービス・エンジンはリカバリ処理を実行します。

16.4 Oracle JCA Adapter for Siebelのデザイン・タイムおよびランタイム機能

このトピックでは、Oracle JCA Adapter for Siebelのデザイン・タイムおよびランタイム機能について説明します。

Oracle JCA Adapter for Siebelのデザイン・タイムおよびランタイム機能は、次のとおりです。

デザインタイム機能

Oracle JCA Adapter for Siebelは、SOAコンポジット設計者用のJDeveloperプラグインのSiebelアダプタ・ウィザードを提供します。Oracle JCA Adapter for Siebelでは次を実行できます

- Siebelアダプタ・ウィザードを介したSiebelシステムへの接続。

- Siebelビジネス・オブジェクト、Siebelビジネス・サービスおよびSiebel統合オブジェクトの参照。

- Siebelオブジェクトの起動およびテスト。

- Siebelビジネス・オブジェクト、Siebelビジネス・サービスおよびSiebel統合オブジェクトのアーティファクト(XSD、WSDLおよびJCAプロパティ)の生成。

- SiebelからXMLベースのイベントを取得するランタイム・オプションの構成。

ランタイム相互作用機能

実行時に、Oracle JCA Adapter for Siebel では次を実行できます。

- Siebel固有の情報を使用したSiebel EAIオブジェクト・マネージャへの接続。

- Siebelビジネス・コンポーネントおよびSiebelビジネス・サービスを使用したSOAからSiebelへの操作
アダプタは次もサポートします。

- Siebel統合オブジェクトを使用したSOAからSiebelへの非同期操作。

- アウトバウンド操作のメッセージ配信。

- 例外処理および管理。

- アダプタ診断能力レポートおよびアラートのアダプタ診断フレームワーク。

16.5 Oracle JCA Adapter for Siebelの構成

この項では、Oracle JCA Adapter for Siebel構成パラメータおよび構成ウィザードに関連するトピックについて説明します。

この項では、次の項目について説明します。

- Oracle JCA Adapter for Siebel構成ウィザードの接続パラメータ

- Oracle JCA Adapter for Siebel構成ウィザードのフロー

16.5.1 Oracle JCA Adapter for Siebel構成ウィザードの接続パラメータ

Oracle JCA Adapter for Siebelを構成するには、Siebelアダプタ構成ウィザードの「接続」画面を介して接続情報を指定します。Oracle JCA Adapter for SiebelをSiebelサーバーに接続するために使用するパラメータの詳細は、次の表を参照してください。

表16-1 Oracle JCA Adapter for Siebel構成ウィザードの接続パラメータ

パラメータ

定義

必須/オプション

ゲートウェイ・サーバー

Siebelゲートウェイ・サーバーのIPアドレス

必須

ゲートウェイ・ポート

Siebelゲートウェイ・サーバーのポート

必須

エンタープライズ名

Siebelエンタープライズ・サーバー名

必須

Siebelサーバー

SiebelサーバーIP

オプション

ユーザー名

必須

Siebelのバージョン

JDBバージョンはSiebelのバージョンごとに異なります

n Siebel 7.7以上(デフォルト)

n

必須

パスワード

マスク

必須

言語

言語キーのデフォルト値はEnglishで、enuとして表されます。

Siebelシステム・バージョンに応じて、異なる言語がサポートされている可能性があります。

必須

オブジェクト・マネージャ

Siebel 7.0.3の場合、デフォルトのオブジェクト・マネージャはEAIObjMgrです。

Siebel 7.7の場合、デフォルトはEAIObjMgr_enuです。Siebel 7.7では、オブジェクト・マネージャ名の末尾に言語拡張子(_enuなど)を追加する必要があります。

必須

リポジトリ名

リポジトリを指定しない場合、利用可能なすべてのリポジトリからオブジェクトの全リストが戻されます。指定したリポジトリが見つからない場合は、空のオブジェクト・リストが戻されます。

オプション

暗号化

暗号化の値は、Siebelシステムへの接続を暗号化する必要があるかどうかを決定します。値は、次のどちらかになります。

- n なし – 暗号化なし

- n RSA – RSAで暗号化されます

オプション

16.5.2 Oracle JCA Adapter for Siebel構成ウィザードのフロー

この項では、Oracle JCA Adapter for Siebelを構成する手順について説明します

Oracle JCA Adapter for Siebelを構成するには、次のタスクを実行します。

1. JDeveloperデザイン・ビューの「参照」セクションのコンポジットまたはBPELプロセスにドラッグ・アンド・ドロップして、Siebelアダプタ構成ウィザードを起動します。

Siebelアダプタ構成ウィザードの「ようこそ」ページが表示されます。

図16-1 Siebelアダプタ構成ウィザード - 「ようこそ」画面

2. 「名前」フィールドで、Siebelアダプタ・サービスのサービス名を入力し、「次へ」をクリックします。

「接続情報」画面が表示されます。

図16-2 Siebelアダプタ構成ウィザード - 「接続情報」画面

3. 「接続情報」画面を使用して、サービス接続を確立します。新しいSiebel接続を定義するか、既存の接続定義を選択できます。

- 既存の接続定義を選択します。

a. 「接続」リストから接続を選択します。

b. オプションから「コンポーネントの表示」を選択します。

c. パスとともにJNDI名を入力します。

- 新しい接続を定義します。

a. プラス記号(+)をクリックして、「Siebel接続の作成」画面を開きます。

図16-3 Siebelアダプタ構成ウィザード — 「Siebel接続の作成」画面

b. 接続パラメータを入力します。

- 接続名: 新しい名前を入力します。

- Siebelシステム・パラメータ: ゲートウェイ・サーバー、ゲートウェイ・ポート、エンタープライズ・サーバーおよびオブジェクト・マネージャなどのSiebelシステム・パラメータを入力します。

- Siebelログオン・パラメータ: ユーザー名およびパスワードを入力します。

- 「接続のテスト」をクリックし、「OK」をクリックして接続を保存します。

注意:
既存の接続定義を編集するには、接続リストから既存の接続定義を選択して、鉛筆記号をクリックします。「Siebel接続の編集」画面が表示され、接続パラメータを変更できます。

4. オブジェクト選択ページを使用して、オブジェクトを選択します。Siebelオブジェクトの項目を選択すると、「定義」パネルで画面の右側に定義が表示されます。

図16-4 Siebelアダプタ構成ウィザード — 「オブジェクト選択」画面

- 定義: 右パネルに、選択したSiebelビジネス・オブジェクト、サービスまたは統合オブジェクトの定義を示します。選択したSiebelオブジェクトのフィールド、タイプおよび名前が含まれます。

- 操作: 問合せ、QueryEx、挿入、更新および削除からビジネス・コンポーネント操作を選択します。QueryExビジネス・コンポーネント操作を選択して「オプション」ボタンをクリックすると、「フィールド選択」ダイアログからオプションを選択するよう求められます。オプションを選択し、「OK」をクリックします。

5. 「次へ」をクリックします。
「JCAエンドポイント・プロパティ」画面が表示されます。デフォルトのプロパティを使用するか、または変更します。

図16-5 アダプタ構成ウィザード - 「JCAエンドポイント・プロパティ」画面

6. 「終了」をクリックします。

Siebelアダプタ・ウィザード:

- 必要なJCAプロパティを定義します。

- 次を含むSiebelエンドポイントを表すSCAアーティファクトを更新します。

- JCAプロパティ・ファイル。

- 選択したオブジェクトのXSDおよびWSDLファイル。

- SCAコンポジット・アーティファクトを更新して変更を反映します。

.

16.6 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

1. アプリケーション・サーバー接続を作成します。詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。

2. アプリケーションのデプロイ詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。

16.7 Oracle JCA Adapter for Siebelのアクティブ化

Oracle JCA Adapter for Siebelはオプションのアダプタであるため、初期状態はアクティブではなくデプロイメント・サマリーにインストールされます。Oracle JCA Adapter for Siebelの状態をアクティブにする必要があります。

Oracle JCA Adapter for Siebelが含まれているビルドにOracle WebLogic Serverがインストールされていることを確認します。

状態をアクティブにするには、次の手順を実行します。

1. WebLogicコンソールで、Oracle JCA Adapter for Siebelを検索して見つけます。

図16-6 WebLogicコンソールのSiebelAdapterの検索

2. SiebelAdapterをクリックします。
SiebelAdapterの設定画面が開きます。

3. 「ターゲット」タブを選択します。

4. 図16-7 SiebelAdapterアクティブ化設定画面

5. 「サーバー」を選択して、Siebelアダプタをデプロイします。

6. 「保存」をクリックします。

Oracle JCA Adapter for Siebelがサーバーでアクティブになります。

16.8 Oracle JCA Adapter for Siebelの接続プーリングの構成

JCAコネクタでは、プーリング・サポートが提供される必要があります。この項では、Oracle JCA Adapter for Siebelの接続プーリングを作成するプロセスについて説明します。

Oracle JCA Adapter for Siebelの接続プーリングを提供するには、次の手順を実行します。

1. WebLogicコンソールで、Oracle JCA Adapter for Siebelを検索して見つけます。

図16-8 WeblogicコンソールのSiebelAdapterの検索

2. SiebelAdapterをクリックします。
SiebelAdapterの設定画面が開きます。

図16-9 Siebelアダプタのアウトバウンド接続プール構成画面

3. 「構成」、「アウトバウンド接続プール」タブの順に選択します。

4. javax.resource.ConnectionFactoryを展開し、eis/SIEBEL/FMWDEMO JNDI名をクリックします。
Javax.resource.cci.ConnectionFactoryの設定画面が開きます。

図16-10 Siebelアダプタのアウトバウンド接続プロパティ画面

5. Siebel接続情報の詳細を指定します。

6. 「保存」をクリックします。

7. plan.xmlを更新して、行われた変更を有効にします。

8. Siebel.jarおよびSiebelJI_enu.jarファイルを<MWHOME>/user_projects/domains/<DOMAINNAME>/lib/ディレクトリにコピーします。

9. サーバーを再起動します。

16.9 Oracle JCA Adapter for Siebelアーティファクト

Oracle JCA Adapter for Siebelを構成すると、次のアーティファクトが作成されます。

ビジネス・コンポーネントのXSD

XSDは、ビジネス・コンポーネント・メソッド用に生成されます。たとえば、アカウント・ビジネス・コンポーネントのリクエスト/レスポンス・スキーマを次に示します。

ビジネス・コンポーネントのリクエスト・スキーマの例は、次のとおりです。

<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema …>
<xsd:element name="SiebelRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="insert" type="ns1:record" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="record">
<xsd:sequence>
<xsd:element name="_nb52_0x20_Week_0x20_High" type="xsd:string"
minOccurs="0" />
<xsd:element name="_nb52_0x20_Week_0x20_Low" type="xsd:string"
minOccurs="0" />
<xsd:element name="ADL_0x20_Status" type="xsd:string"
minOccurs="0" />
<xsd:element name="ATM_0x20_Flag" type="xsd:string"
minOccurs="0" />
<xsd:element name="Access_0x20_Level" type="xsd:string"
minOccurs="0" />
<xsd:element name="Account_0x20_Competitors" type="xsd:string"
minOccurs="0" />
<xsd:element name="Account_0x20_Condition" type="xsd:string"
minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

ビジネス・コンポーネントのレスポンス・スキーマの例は、次のとおりです。

<xsd:schema …>
<xsd:element name="SiebelResponse">
<xsd:complexType>
<xsd:attribute name="ROW_ID" type="xsd:string" use="required" />
</xsd:complexType>
</xsd:element>
</xsd:schema>

WSDL

WSDLは、ビジネス・コンポーネント・メソッドに生成されます。WSDL操作名はアクション名です。たとえば、次のWSDLがアカウント/アカウントの挿入メソッド用に生成されます。

SiebelアダプタのWSDLアーティファクトの挿入メソッドの例は、次のとおりです

<definitions …>
<types>
<!—import the request and response schema
</types>
<message name="response">
<part element=”ns1:SiebelResponse" name="output_insert"/>
</message>
<message name="request">
<part element=" ns1:Siebel" name="input_insert"/>
</message>
<portType name="insertPortType">
<operation name="insert">
<input message="ns2:request" name="Input_insert"/>
<output message="ns2:response" name="Output_insert"/>
</operation>
</portType>
<plt:partnerLinkType name="insertPartnerLinkType">
<plt:role name="insertRole">
<plt:portType name="ns2:insertPortType"/>
</plt:role>
</plt:partnerLinkType>
</definitions>

JCA

JCAプロパティは、Siebel統合エンドポイント用に生成されます。connection-factory、endpoint-interaction、interaction-spec、interaction-specのプロパティなどが含まれます。

JCAプロパティ・ファイルの例を次に示します

<connection-factory location="eis/MySiebel"/>
<endpoint-interaction portType="Internal_0x20_Contact_0x20_Interface_PT">
<interaction-spec className="oracle.tip.adapter.siebel.SeblBCInteractionSpecImpl">
<property name="BusinessObjectName" value="Contact"/>
<property name="BusinessComponentName" value="Account"/>
<property name="Action" value="insert"/>
<property name="ExecutionTimeout" value="50000000"/>
</interaction-spec>
</endpoint-interaction>

ビジネス・サービスのXSD

リクエスト・スキーマは、ビジネス・サービス・メソッドの入力パラメータを表します。たとえば、次のリクエスト・スキーマは、アカウント・ビジネス・サービスのCreateAccountメソッドを表します。

CreateAccountメソッドのビジネス・サービスのXSDのリクエスト・スキーマの例は、次のとおりです。

<xsd:schema …>
<xsd:element name="AdapterParams">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Account_0x20_IO" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

レスポンス・スキーマは、ビジネス・サービスの出力パラメータを表します。ただし、レスポンス・スキーマには、エラー・メッセージおよび成功フラグが含まれません。エラー・メッセージは、例外でラップされます。

CreateAccountメソッドのビジネス・サービスのXSDのリクエスト・スキーマの例は、次のとおりです。

<xsd:schema …>
<xsd:element name="Response">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Account_0x20_Id" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

ビジネス・サービスのWSDL

WSDLは、ビジネス・サービス・メソッド用に生成されます。WSDL操作名はメソッド名です。次の例に、CreateAccountメソッドのビジネス・サービスのWSDLを示します。

CreateAccountメソッドのビジネス・サービスのWSDLの例は、次のとおりです。

<definitions …>
<types>
<!—import the request and response schema
</types>
<message name="request">
<part element="ns1:AdapterParams" name="input_CreateAccount"/>
</message>
<message name="response">
<part element="ns1:Response" name="output_CreateAccount"/>
</message>
<portType name="CreateAccountPortType">
<operation name="CreateAccount">
<input message="ns2:request" name="Input_CreateAccount"/>
<output message="ns2:response" name="Output_CreateAccount"/>
</operation>
</portType>
<plt:partnerLinkType name="CreateAccountPartnerLinkType">
<plt:role name="CreateAccountRole">
<plt:portType name="ns2:CreateAccountPortType"/>
</plt:role>
</plt:partnerLinkType>
</definitions>

ビジネス・サービスのJCAプロパティ

JCAプロパティは、Siebel統合エンドポイント用に生成されます。connection-factory、endpoint-interaction、interaction-spec、interaction-specのプロパティなどを含める必要があります。アダプタは、ビジネス・サービスのJCAプロパティ・ファイルを生成します。次にファイルの例を示します。

CreateAccountメソッドのビジネス・サービスのJCAファイルの例は、次のとおりです。

<connection-factory location="eis/MySiebel"/>
<endpoint-interaction portType="Account_0x20_PT">
<interaction-spec className="oracle.tip.adapter.siebel.SeblBSInteractionSpecImpl">
<property name="BusinessServiceName" value="Account"/>
<property name="MethodName" value="CreateAccount"/>
<property name="ExecutionTimeout" value="50000000"/>
</interaction-spec>
</endpoint-interaction>

17 Oracle JCAアダプタ・チューニング・ガイド

この章では、Oracle JCAアダプタ・フレームワークおよび一連のJCAアダプタの最も重要なチューニングおよびパフォーマンスに関する考慮事項と、問題をチューニングする場合の症状の検出および問題の解決に役立つ推奨事項の概要について説明します。推奨事項は、アダプタに関する最も重要なチューニング・パラメータまたはプロパティの説明で構成され、パラメータに関連した特定のチューニング・プラクティスが含まれることもあります。

アダプタのリストは、次のとおりです。

- Oracle JCAアダプタ・フレームワークのパフォーマンスおよびチューニング

- JMSアダプタ

- AQアダプタ

- ファイル/FTPアダプタ

- データベース・アダプタ

各項には、一般的なフレームワークまたは特定のアダプタに関連した各チューニング・ガイド・パラメータについて、次の内容が示されます。

- プラクティスまたはパラメータの一般的な説明。

- 適切にチューニングされていない場合の症状: このパラメータまたはプラクティスに関連するチューニングが不適切な場合、どのような症状が発生するか。

- チューニングのデメリット: これらのパラメータおよびプラクティスに関連して、どのような問題に注意する必要があるか。

- 症状が発生した場合の対処: パフォーマンスを改善するために、パラメータまたはプラクティスをどのように調整するか。

17.1 Oracle JCAアダプタ・フレームワークのパフォーマンスおよびチューニング

Oracle JCAアダプタ・フレームワークの最も重要なプラクティスおよびパラメータは、次のとおりです。

- payloadSizeThreshold

- minimumDelayBetweenMessages

17.1.1 payloadSizeThreshold

このパラメータは、データを消費する際にJCAアダプタが許容する最大サイズ(バイト単位)を制御します。つまり、エンドポイントのポーリング中に非同期的に受信するか(JCAサービス)、JCA参照を使用して同期的に読み取るかを制御します。

消費する(ネイティブ)メッセージのサイズが構成済のpayloadSizeThreshold (SCAサービスまたは参照ベースで構成)を上回る場合、メッセージは拒否されます。

Oracle XDK XMLへのネイティブ・メッセージを解析する場合、メッセージにはネイティブ・メッセージが使用する10から15倍のメモリー量が必要です。たとえば、サイズが1MBのファイル・システム内のフラット・ファイルは、JVMヒープでは(DOMとして)10から15MBを消費します。

このプロパティのデフォルト値は-1で、無制限を意味します。

Fusion Middleware Controlを使用して設定可能なグローバルのpayloadSizeThreshold が(AdapterConfigMBeanに)あり、payloadSizeThresholdに対して特定の値が明示的に構成されていないすべてのJCAエンドポイントのデフォルトの制限となります。

つまり、エンドポイント設定は常にグローバル設定よりも優先されます。

この設定は一般的に、予測されるメッセージ・サイズについて疑いがある場合に構成する必要があります。

消費されるメッセージをアプリケーション自体が生成している場合、このアプリケーションについて、このプロパティを構成する必要性が減少すると想定できます。

このプロパティの目的は、受信アダプタ・メッセージに使用されるJVMヒープ・スペースの量を制限することです。値は、同期または非同期のビジネス・フロー内で(少なくとも)次のファクタから影響を受けます。

- 同期フロー。消費される各インバウンド・メッセージは、同期インスタンスの実行中、長い間JVMヒープにとどまる必要があります。アダプタ・ポーリング・スレッドの数によって、同時にJVMに存在するメッセージ・インスタンスの数が特定されます。ポーリング・スレッドが多いほど、payloadSizeThresholdは小さくなります。

- 非同期フロー。インバウンド・メッセージは、アダプタが受信メッセージを読み取って変換する間、および最初のダウンストリーム・サービス・エンジンがメッセージを受信して保持するまでの短い期間、ヒープに存在します。ただし、これらのダウンストリーム・サービス・エンジンのスレッド・モデル(BPELワーカー・スレッドなど)によって、ヒープに同時に存在できるインスタンスの数が決定され、これに応じて妥当なpayloadSizeThreshold値を考慮する必要があります。

17.1.1.1 DOMまたはスケーラブルなDOM

ストリーミングが有効な場合、つまりアダプタがSDOM (スケーラブルなDOM)インスタンスを生成している場合、Oracle XDKはページング・ストレージにほとんどのXMLを維持するため、より大きい値をpayloadSizeThresholdに使用できます。これは、インスタンスで実行されるXpath、XsltおよびXQueryで使用するDOMアクセス・パターンに依存します。

SDOMインスタンスで使用されるメモリーがどれだけ少なくなるかはビジネス・ロジックに大きく依存するため、実験的なテスト・データがこのパラメータの設定に役立ちます。

17.1.1.2 同期消費

この使用例は、ビジネス・ロジックによってアダプタが起動され、同期読取り操作(ファイルの読取りまたは表からのデータの選択)が実行される状況を示しています。たとえば、SQL選択操作によって非常に多くの(ネストされた)行が戻されるリスクがある場合は、payloadSizeThresholdに妥当な値を設定することをお薦めします。サイズが超過している場合は、ビジネス・フォルトがスローされ、ビジネス・ロジックによって補完的なアクションが決定され、自動的には拒否されません。

17.1.1.3 payloadSizeThresholdが適切にチューニングされていない場合の症状

矛盾する次の懸念事項のバランスを保つ、よく考慮されたpayloadSizeThresholdの値を選択する必要があります。

- JVMヒープがサイズの大きすぎるメッセージであふれないようにすること。

- 多くのメッセージが拒否される問題。

つまり、個別のインバウンド・メッセージで多くのポーリング・スレッドまたは処理スレッドが並行して動作できる場合、値をデフォルトの-1 (無制限)のままにしたり非常に大きくすると、JVMが使用可能なヒープ・スペースを使い果たしたときに致命的な実行時エラーが発生する可能性があります。

値を小さく設定すると非常に多くのメッセージが拒否され、これにより通常のビジネス・フローが不必要に混乱し、メッセージが許容可能なサイズであってもリカバリをスケジュールするか、または手動でリカバリする必要があります。

17.1.1.4 チューニングのデメリット

ネイティブ・メッセージのサイズ計算にかかるコストは、このプロパティの構成における潜在的なデメリットです。しきい値を設定すると、特にデータベース・アダプタの場合に重大なパフォーマンス上の影響が生じる可能性があります。

17.1.1.5 症状が発生した場合の推奨事項

メモリー不足(OOM)エラーがSOAで発生し始めたことがログに示されている、全体的なシステムの速度低下が検出される、ガベージ・コレクションが頻繁に発生し始めたなどの症状が発生したときに、これらの症状を、サイズ超過のネイティブ・アダプタ・メッセージのインフローに関連付けることができる場合は、メッセージのしきい値をすぐに設定する必要があります。

新しいしきい値を動的に設定するには、グローバルに変更するために(すべてのエンドポイントに適用される)構成MBeanを使用するか、または1つ以上のインバウンドJCAエンドポイント(非常に大きなメッセージを受信すると考えられるエンドポイント)のバインディング・プロパティpayloadSizeThresholdを変更できます。

17.1.2 minimumDelayBetweenMessages

minimumDelayBetweenMessagesは、アダプタ・ポーリング・スレッドの実行を遅延させるための単純なメカニズムです。

小さなスレッド・スリープをインスタンス実行の一部として、ポーリング・スレッド・ベースで追加します。設定はミリ秒で測定されます。遅延は、次のダウンストリーム・コンポーネントが起動する直前に追加されます。

アダプタがポーラー・スレッドの一部としてトランザクションを開始する場合、トランザクション・タイムアウトは、最悪な場合の許容可能なインスタンス実行の最大値とminimumDelayBetweenMessagesの値に対応する必要があります。

インスタンス実行自体(2つの最新メッセージのパブリッシュの間の時間)がminimumDelayBetweenMessagesの値を超える場合、遅延は追加されません(そのため、名前はminimumDelay...になります)。

17.1.2.1 適切にチューニングされていない場合の症状

構成されていない場合、インバウンドJCAアダプタのエンドポイントからのメッセージ間に遅延はありません。

ビジネス・プロセスに非同期の構造/署名がある場合、(メッセージがディスパッチャ・キューに溜まっている)アダプタ・エンドポイントから届くインバウンド・メッセージの速度に対応できなければ、この状況ではダウンストリームのビジネス・ロジックのオーバーロードが生じる可能性があります。

または、ビジネス・プロセス・フローが同期の場合、ポスティング・アダプタ・ポーリング・スレッドは、前のメッセージのインスタンス実行が完了するより前に新しい受信メッセージを再取得しません(これは最初のダウンストリーム・デハイドレーション・ポイントまでの範囲にのみ関連します)。

ただし、minimumDelayBetweenMessagesに大きい値を構成すると、ダウンストリームのビジネス・プロセスが不必要にアイドル状態になったり、JTA/XAトランザクション・タイムアウトが発生することがあります。

17.1.2.2 チューニングのデメリット

minimumDelayBetweenMessagesの値を設定すると、固定された遅延が発生し、ダウンストリーム・ビジネス・ログのパフォーマンス特性の変更に適応しなくなります。つまり、ダウンストリームのプロセス・フローのパフォーマンスが向上した場合でも、minimumDelayBetweenMessagesは引き続き無条件に適用されます。

17.1.2.3 症状が発生した場合の推奨事項

たとえば、BPELディスパッチャ・キューの未処理のメッセージ数に関して、ダウンストリームのビジネス・ロジックが増加的にバックログされている場合、このバックログはロジックが受信アダプタ・メッセージの速度に対応できないことを示します。

このプロパティはJCAエンドポイントに適用できるため、エンドポイントに対するすべてのポーリング・スレッドの全体的な遅延が非同期のビジネス・プロセスの実行速度と一致するように値を選択します。

ルールでは、10個のポーリング・スレッドがある場合、有効な遅延= minimumDelayBetweenMessages/ポーリング・スレッド数となります。

17.2 JMSアダプタ

JMSアダプタの最も重要なチューニング・プラクティスおよびパラメータは、次のとおりです。

- adapter.jms.receive.threads

- EnableStreaming

- adapter.jms.receive.timeout

17.2.1 adapter.jms.receive.threads

このパラメータは、アダプタ・エンドポイントをアクティブ化するときに作成されるポーラー・スレッドの数を示します。デフォルトは1です。各ポーラー・スレッドは、個別に処理される独自のメッセージを受信するため、スループットが向上します。

17.2.1.1 適切にチューニングされていない場合の症状

メッセージの処理が遅くてキュー・バックログが増加する場合、処理の速度を上げる方法の1つはポーラー・スレッドの数を増やすことです。

17.2.1.2 チューニングのデメリット

ポーリング・スレッドの数が増加すると、同時処理に必要なシステム・リソースが増加します。

17.2.1.3 症状が発生した場合の推奨事項

症状が発生したら、パフォーマンスが直線的に向上している間は、スレッドを増やします。

17.2.2 EnableStreaming

EnableStreamingのデフォルトはfalseです。その重要度は使用例に固有ですが、このプロパティをtrueに設定すると、インメモリーDOMとしてペイロードを処理するのではなく、JMS宛先からのペイロードをストリーミングします(アダプタはSDOMのインスタンスを生成します)。SDOM機能は、大きなペイロードを処理する場合に使用する必要があります。

17.2.2.1 適切にチューニングされていない場合の症状

JMS宛先からのペイロードが大きいと、メモリー不足の状態を引き起こす可能性があります。

17.2.2.2 チューニングのデメリット

このパラメータをTrueに設定すると、SDOMの処理に余分なコストが生じます。

17.2.2.3 症状が発生した場合の推奨事項

PayloadSizeThresholdプロパティのより大きな値をJMSアダプタで使用できるように、ストリーミングをオンにします。

17.2.3 adapter.jms.receive.timeout

このパラメータのデフォルト値は1秒です。このタイムアウト値は、同期受信コールに使用され、メッセージがインバウンドJMSキューで受信されない場合にreceive() APIがタイムアウトする時間です。

17.2.3.1 適切にチューニングされていない場合の症状

アイドル・サイクル時(長時間キューにメッセージがない場合)にCPU使用率が高くなるなどの症状があります。

17.2.3.2 チューニングのデメリット

このパラメータの値が大きいと、トランザクション・タイムアウトが生じる可能性があります。

17.2.3.3 症状が発生した場合の推奨事項

タイムアウト値を増やし、SOA環境に対して設定するトランザクション・タイムアウト値の合計を考慮します。

17.3 AQアダプタ

AQアダプタの最も重要なチューニング・プラクティスおよびパラメータは、次のとおりです。

- adapter.aq.dequeue.threads

- EnableStreaming

- DequeueTimeOut

17.3.1 adapter.aq.dequeue.threads

これは、AQアダプタ・エンドポイントをアクティブ化するときに作成されるポーラー・スレッドの数です。デフォルトは1です。各ポーラー・スレッドは、個別に処理される独自のメッセージを受信するため、スループットが向上します。

17.3.1.1 適切にチューニングされていない場合の症状

適切にチューニングされていない場合に必ずしも症状があるわけではありませんが、メッセージの処理が遅くてAQキュー・バックログが増加する場合、処理速度を上げる方法の1つはスレッドの数を増やすことです。

17.3.1.2 チューニングのデメリット

スレッドが増加すると、同時処理に必要なシステム・リソースが増加する可能性があります。

17.3.1.3 症状が発生した場合の推奨事項

パフォーマンスが直線的に向上している間は、ポーラー・スレッドを増やします。

17.3.2 EnableStreaming

このAQパラメータのデフォルトはfalseで、パラメータは使用例に固有です。この機能は、大きなペイロードの処理中に使用する必要があります。

このプロパティをtrueに設定すると、インメモリーDOMとして処理するのではなく、JMS宛先からのペイロードをストリーミングします(アダプタはSDOMのインスタンスを生成します)。

17.3.2.1 適切にチューニングされていない場合の症状

ペイロードが大きいと、メモリー不足を引き起こす可能性が高くなります。

17.3.2.2 チューニングのデメリット

SDOMを処理する余分なコストがかかります。

17.3.2.3 症状が発生した場合の推奨事項

メモリー不足が発生した場合は、より大きなPayloadSizeThresholdプロパティ値をAQアダプタで使用できるようにストリーミングをオンにします。

17.3.3 DequeueTimeOut

DequeueTimeOutは、インバウンド・キューでメッセージが受信されない場合にdequeue() APIがタイムアウトになるまでの間隔です。デフォルト値は1秒です。

17.3.3.1 適切にチューニングされていない場合の症状

このパラメータが適切にチューニングされていないと、アイドル・サイクル時(長時間キューにメッセージがない場合)にCPU使用率が高くなる可能性があります。

17.3.3.2 チューニングのデメリット

値が大きいと、トランザクション・タイムアウトが生じる可能性があります。

17.3.3.3 症状が発生した場合の推奨事項

このタイムアウト・パラメータ値を増やし、SOA環境に対して設定するトランザクション・タイムアウト値の合計を考慮します。

17.4 ファイル/FTPアダプタ

ファイル/FTPアダプタの最も重要なチューニング・プラクティスおよびパラメータは、次のとおりです。

- スレッド数およびシングル・スレッド・モデル

- maxRaiseSize

- PublishSize

- ChunkSize

17.4.1 スレッド数およびシングル・スレッド・モデル

ファイルおよびFTPアダプタのインバウンド設計は、(インバウンド・ファイル/FTPアダプタ・サービスを使用した)コンポジット・アプリケーションの各デプロイメントによってシングル・ポーラー・スレッドおよびオプションのプロセッサ・スレッド数が作成されるプロデューサ/コンシューマ・モデルに基づいています。

次の手順で、ファイル/FTPアダプタのデフォルトのスレッド動作を示します。

1. ポーラー・スレッドは、構成されたポーリング頻度に基づいて入力ディレクトリのファイルを定期的にスキャンします。

2. ポーラーは、インバウンド・ディレクトリで検出した新規ファイルごとに、ファイル名、ファイル・ディレクトリ、変更時間、ファイル・サイズなどの情報を内部システム全体のインメモリー・キューにエンキューします。

3. プロセッサ・スレッドのグローバル・プール(合計4つ)は、このインメモリー・キューからの処理を待機します。

4. インメモリー・キュー内のアイテムは、これらのスレッドによってデキューされて処理されます。ファイル・コンテンツがXMLに変換され、SOAインフラストラクチャにパブリッシュされた後、ファイルの削除やアーカイブなどの後処理が実行されます。

これは、ファイル/FTPアダプタの両方のデフォルトのスレッド動作です。ただし、インバウンドJCA構成ファイルのThreadCountまたはSingleThreadModelプロパティのいずれかを構成することによって、この動作を変更できます。

ThreadCountの有限値を設定すると、特定のファイル/FTPアダプタのインバウンド・サービスがパーティション化スレッド・モデルに変更され、そこで各サービスは独自のインメモリー・キューと、一連の専用プロセッサ・スレッドを受信します。

プロセッサ・スレッド自体はSOAワーク・マネージャのもので、メモリーやCPU時間を消費するため、このプロパティは慎重に構成する必要があります。値2から開始して、必要に応じてゆっくり速度を上げることをお薦めします。ただしシステムでは、ThreadCountのこの構成の上限が40に設定されています。

JCAの構成でSingleThreadModelをtrueに設定すると、ポーラーがプロセッサの役割を果たすようになります。つまり、ポーラーが、インバウンド・ディレクトリをスキャンし、同じスレッドのファイルを(次々に)処理します。

このパラメータは、システムを抑制する必要がある場合に特に役立ちます。特定の順序でファイルを処理する必要がある場合(最終変更時間の降順でファイルを処理する場合など)にも、このパラメータを使用できます。

17.4.1.1 適切にチューニングされていない場合の症状

単一の共有インメモリー・キューおよび共有プロセッサ・スレッドが原因で、複数のインバウンド・サービスが実行されているようなボリュームが大きい状況では、パフォーマンスが低下します。

17.4.1.2 チューニングのデメリット

プロセッサ・スレッドの数が増加すると、必要なシステム・リソース量が増えます。各サービス専用のインメモリー・キューによっても、メモリー要件が増加します。

17.4.1.3 症状が発生した場合の推奨事項

ThreadCountの値を2から増やし始め、直線的にパフォーマンスが向上するまでゆっくり増やします。

17.4.2 maxRaiseSize

MaxRaiseSizeパラメータは、インバウンド・ファイル/FTPアダプタによって使用され、インバウンド・アダプタのポーラー・スレッドが単一のポーリング・サイクルのインメモリー・キューに生成するファイルの数を決定します。

たとえば、ポーリング頻度を1分、MaxRaiseSizeを10に設定している場合、ポーラー・スレッドは毎分最大10ファイルをインメモリー・キューに生成します。

このパラメータは、ファイル/FTPアダプタがアクティブ/アクティブ・クラスタで実行されるように構成されている場合に役立ちます。この場合、クラスタの同じディレクトリをポーリングするポーラー・スレッドが複数(実際は管理対象サーバーに1つずつ)存在します。このパラメータにより、ファイルはノード間にほぼ均一に分散されるようになり、単一の管理対象サーバーがファイルの処理を独占することがなくなります。

17.4.2.1 適切にチューニングされていない場合の症状

このパラメータが適切にチューニングされていないとバランスが保たれません。たとえば、アクティブ/アクティブ・クラスタの1つの管理対象サーバーがほとんどのメッセージを処理することになります。

17.4.2.2 チューニングのデメリット

MaxRaiseSizeの値が小さいと、各ポーリング・サイクルで処理されるファイルが少なくなり、ポーラー・スレッドのスリープ時間が追加されるため、パフォーマンスが低下する可能性があります。

17.4.2.3 症状が発生した場合の推奨事項

アプリケーションで予想される負荷に基づいて、MaxRaiseSizeとポーリング頻度を同期することにより、各ポーリング・サイクルでのスリープ時間を減らし、ポーラー・スレッド間で適切なロード・バランシングを確保できます。

17.4.3 PublishSize

ファイル/FTPアダプタ内のデバッチの使用例は、単一のインバウンド・ファイルを複数のバッチに分けることが可能で、各バッチが個別に処理されるときに発生します。たとえば、何百万もの請求書が含まれている単一のファイルがある場合、1回の試行でファイル全体を処理することはできません。

デバッチが有効な場合、ファイル/FTPアダプタは、基になるストリームから読み取って最初の1000 (PublishSizeが1000の場合)の請求書をXMLに変換し、SOAにパブリッシュします。この処理は、ファイル全体が処理されるまで続けられます。さらに、アダプタは、クラッシュの回復時に中断した場所からデバッチを再開できるように、反復の間に十分な情報を保存します。

適切なパフォーマンスを実現するには、PublishSizeに十分に大きな値を指定する必要があります。たとえば、ファイルに1,000,000の論理レコードがある場合、PublishSizeを約10,000に設定すると、100回の反復でファイル全体が処理されます。

アダプタからの各パブリッシュは、多数のデータベース・アクティビティ(デハイドレーション・ストアへの格納、後の時点でのリハイドレーションなど)になります。(PublishSizeの値を大きくすることによって)パブリッシュの数を減らすと、パフォーマンスが向上します。

17.4.3.1 適切にチューニングされていない場合の症状

パブリッシュ・コールの数が多くなり、データベース・アクティビティが多いと、パフォーマンスが低下します。

17.4.3.2 チューニングのデメリット

PublishSizeの値が大きいと、追加のシステム・リソースが必要です。

17.4.3.3 症状が発生した場合の推奨事項

パフォーマンスが直線的に向上している間は、PublishSizeを増やします。

17.4.4 ChunkSize

チャンク読取りはデバッチに類似していますが、アウトバウンド・ファイル/FTPアダプタに適用され、さらに重要なことにはBPELでのみサポートされます。

使用例で、チャンク読取りを使用するBPELプロセスは、<while/> BPELコンストラクト内の<invoke>アクティビティを使用して、大量のファイルを1つの論理チャンクで一度に処理します。

各<invoke>の最後に、1つの倫理チャンクがXMLデータとしてBPELに戻されます(メモリーに具現化されます)。

ChunkSizeパラメータは、各<invoke>でBPELに戻される論理レコードの数を定義します。このパラメータを設定する場合、BPELの<while>ループの反復数が大きくなるとメモリーに保持される監査情報量が増加するため、メモリー不足エラーが生じることに注意する必要があります。

ChunkSizeの値を設定する場合、反復数を最小限に抑えると同時に、大きすぎるレコードのチャンクを戻さないようにする必要があります。たとえば、100万のレコードが含まれる大きなファイルがある場合は、大きな値(約1000)から開始する必要があります。

17.4.4.1 適切にチューニングされていない場合の症状

プロパティが構成されていない場合や値が大きすぎるまたは小さすぎる場合、ペイロードが大きいとメモリー不足の問題が生じる可能性があります。

17.4.4.2 チューニングのデメリット

反復数を最小限に抑えると同時に、大きすぎるチャンクを戻さないように、必要な入力サイズに基づいてバランスの取れたChunkSizeを見つける必要があります。

17.4.4.3 症状が発生した場合の推奨事項

必要な入力ファイル・サイズと使用可能なシステム・リソースに基づいて、バランスの取れたChunkSizeから開始し、許容可能なメモリー要件まで値を増やします。

17.5 データベース・アダプタ

この項では、データベース・アダプタのパフォーマンスおよびチューニングに関連する最も重要なプラクティスおよびパラメータの概要について説明します。

次のような内容が含まれます。

- 索引の使用

- MaxTransactionSizeおよびMaxRaiseSize

- MaxTransactionSizeおよびMaxRaiseSize

- RowsPerPollingIntervalを使用しない

- ロッキングのスキップの有効化(usesSkipLockingパラメータの使用)

- NumberOfThreadsの増加

17.5.1 索引の使用

次の情報は、データベース・アダプタでの索引の使用に関連しています。

17.5.1.1 適切にチューニングされていない場合の症状

ポーリングが非常に遅くなる可能性があります。外部キー列が索引化されていない場合、1-Mリレーションシップを使用した削除ポーリング戦略がデッドロックになることがあります。

17.5.1.2 チューニングのデメリット

すべての索引にコストがかかります。フラット表からの純粋な削除の使用および主キーなしの構成(かわりにROWIDを使用)は、索引が必要な場合に有効な代替方法です。未処理の行が数行以上は生じない(DeletePollingStrategyでは再度生じない)速さでアダプタがポーリングできる場合、索引は必要ない可能性があります。

17.5.1.3 症状が発生した場合の推奨事項

索引を作成するかすべての索引および制約を削除し、ROWIDを使用します(拡張、ポーリングの削除のみ)。

また、索引の使用はデフォルトでfalseになっているパラメータではありません。これはデータベース・アダプタ自体とは別に行うことであり、アダプタが実行するSQLが最適に実行されるように、ポーリングしているリレーショナル・スキーマを変更します。それ自体はチューニング・ノブではありませんが、非常に重要です。

ROWIDオプションによって、迅速な選択が可能になり、索引の維持にかかる従来のコストを回避できます。詳細は、データベース・アダプタの章のROWIDに関する項を参照してください。

17.5.2 MaxTransactionSizeおよびMaxRaiseSize

次に、MaxTransactionSizeおよびMaxRaiseSizeの考慮事項を示します。

17.5.2.1 適切にチューニングされていない場合の症状

スケーリングするには、トランザクション/フェッチの数(MaxTransactionSize)およびダウンストリーム・インスタンスの数(MaxRaiseSize)を使用してオーバーヘッドを削減します。大量にデータを移動する場合、システムで複数の行を1つのペイロードとして渡すとパフォーマンスを向上できます。

17.5.2.2 チューニングのデメリット

MaxRaiseSize=1は、BPELプロセスが単一のレコードを処理するように設計されている場合など、ビジネス上の制約のためによく使用されます。メッセージを頻繁に拒否する必要がある場合、バッチで複数のレコードを処理すると全体的に遅くなる可能性があります(大量のトランザクションをロールバックし、行を個別に再試行する必要があります)。また、エンド・ツー・エンド・プロセスが大きいMaxTransactionSizeおよび小さいMaxRaiseSizeと同期する場合、多くのダウンストリーム・プロセスが単一のグローバル・トランザクションに参加し、トランザクション・タイムアウトが発生します。

17.5.2.3 症状が発生した場合の推奨事項

トランザクション・タイムアウトの場合は、(BPELに対する)ポスト非同期を作成したり、MaxTransactionSize/MaxRaiseSizeの比率を削減します。

BPELでは、インスタンスごとのオーバーヘッドが高く、OSBに比べて約10倍です。このうちいくつかは、デハイドレーションとインスタンス・トラッキングに使用されます。ただし、このコストは、各インスタンスが単一XMLの10行を表すか、XMLの1行を表すかのいずれであっても、固定コストのようなものです。そのため、このオーバーヘッドに対処する方法の1つは、複数の行を表すわずかに大きなペイロードをデータベース・アダプタが送受信することです。このようなオーバーヘッドの症状として、純粋なJDBCプログラムに比べて速度が遅くなる場合があります。

17.5.3 RowsPerPollingIntervalを使用しない

このチューニング・パラメータの使用には、非常に慎重になる必要があります。

17.5.3.1 適切にチューニングされていない場合の症状

RowsPerPollingIntervalは、スループットの明示的なキャップで、ダウンストリーム・コンポーネントのバースト・ロードを削減するように設計されており、キャップ・パフォーマンスを強化しすぎないように非常に慎重に使用する必要があります。

17.5.3.2 チューニングのデメリット

システムで実際に対応できるバースト・スループットよりもかなり低く設定されることがあります。

17.5.3.3 症状が発生した場合の推奨事項

RowsPerPollingIntervalを増やすか、排除します。

17.5.4 ロッキングのスキップの有効化(usesSkipLockingパラメータの使用)

ロッキングのスキップの有効化は、重要なパラメータです。

17.5.4.1 適切にチューニングされていない場合の症状

使用する排他的ロックによって他のスレッドが行を取得できない場合、ポーリングはスレッドの数に応じてスケーリングされません。

17.5.4.2 チューニングのデメリット

ありませんが、このパラメータはOracle DatabaseおよびSQLServerプラットフォームに対してのみサポートされます。データソースに十分な容量があることを確認してください。接続が十分でない場合は、より多くのスレッドを追加するとより多くの待機スレッドが作成されます。

17.5.4.3 症状が発生した場合の推奨事項

usesSkipLocking = trueであることを確認します(デフォルトではtrue)。

17.5.5 NumberOfThreadsの増加

この項では、NumberOfThreadsの増加の使用について説明します。

17.5.5.1 適切にチューニングされていない場合の症状

ポーリングがスケーリングしません。スケーリングの定義は、パフォーマンスがスレッド/エージェントの数に応じて直線的に増加することです。そのため、スレッドの増加はスケーリングの事前条件になります。他のチューニング・パラメータは、パフォーマンスの向上が直線的になるようにするためのものです(他の同様のスレッドによって速度が低下しないで各スレッドを機能させることでロッキングをスキップします)。

17.5.5.2 チューニングのデメリット

usesSkipLocking=trueのような分散ポーリング戦略を使用しない場合、スレッドの増加が同時に実行されない可能性があります。基となるデータソース接続に少なくとも同じ最大容量があることを確認します。

17.5.5.3 症状が発生した場合の推奨事項

パフォーマンスが直線的に向上している間は、スレッドを増やします。

A Oracle JCAアダプタのプロパティ

この付録は、Oracle JCAアダプタに適用可能なJCAプロパティおよびバインディング・プロパティのリストと説明を含んでおり、このマニュアル内の各JCAアダプタに関する章とともに使用してアダプタの構成に役立てることができます。

正規化されたメッセージは、プロパティとペイロードという2つの部分のみを持つように簡素化されています。Oracle BPEL Process ManagerとOracle Mediatorでは、様々なユーザー・インタフェース・サポート・レベルでヘッダーにアクセスし、操作して設定できます。たとえば、メッセージ・ヘッダーを介してファイル名を伝播することで、そのファイル名をソース・ディレクトリからターゲット・ディレクトリに保存できます。

Oracle JCAアダプタは、標準化メッセージ・プロパティを介してヘッダー情報を送信します(Oracle JCA Adapter for AQのペイロード・ヘッダーを除きます)。

バインディング・プロパティは、デプロイ済SOAコンポジット・アプリケーションに組み込まれているサービス・バインディング・コンポーネントおよび参照バインディング・コンポーネントに対するメッセージ・ヘッダー・プロパティです。

この付録の内容は次のとおりです。

- Oracleファイル/FTPアダプタのプロパティ

- Oracleソケット・アダプタのプロパティ

- Oracle AQアダプタのプロパティ

- Oracle JMSアダプタのプロパティ

- Oracleデータベース・アダプタのプロパティ

- Oracle MQ Seriesアダプタのプロパティ

- LDAPアダプタのプロパティ

- コヒーレンス・アダプタのプロパティ

- MSMQ JCAアダプタのプロパティ

- UMS JCAアダプタのプロパティ

- Oracle JCAアダプタの汎用プロパティ

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のサービスおよび参照バインディング・コンポーネントの構成に関する項を参照してください。

A.1 Oracleファイル/FTPアダプタのプロパティ

この項では、Oracleファイル/FTPアダプタに適用可能な次のプロパティについて説明します。

- 表A-1

- 表A-2

- 表A-3

- 表A-4

- 表A-5

- 表A-6

すべてのOracle JCAアダプタに適用可能なプロパティについては、「Oracle JCAアダプタの汎用プロパティ」を参照してください。

表A-1 Oracleファイル/FTPアダプタのJCAプロパティ

プロパティ

説明

Append

このプロパティがtrueに設定されている場合、Oracleファイル/FTPアダプタはアウトバウンド側のファイルに追加します。このファイルが存在しない場合、新規ファイルが作成されます。

ファイル名は、アウトバウンド操作用にJCAファイルで指定するか、jca.file.FileNameヘッダーで指定できます。

AsAttachment

trueに設定されている場合、インバウンド・ファイルは添付としてパブリッシュされます。

BatchSize

このプロパティ値は、バッチ・トランスフォーメーションのバッチ・サイズに設定します。

CharacterSet

添付のキャラクタ・セットを設定します。このパラメータはOracleファイル/FTPアダプタの内部では使用されず、Oracleファイル/FTPアダプタがパブリッシュする添付を処理するサード・パーティ・アプリケーションで使用されます。

ChunkSize

チャンク相互作用操作のチャンク・サイズに設定します。

ConcurrentThreshold

特定のアウトバウンド・シナリオで同時に実行可能な変換アクティビティの最大数。アウトバウンド操作中の変換ステップは、CPUの負荷が高くなり、他のアプリケーションやスレッドを停止させる可能性があるため、ガードする必要があります。最大値は100です。

ContentType

添付のMIMEタイプを設定します。このパラメータはOracleファイル/FTPアダプタの内部では使用されず、Oracleファイル/FTPアダプタがパブリッシュする添付を処理するサード・パーティ・アプリケーションで使用されます。

DeleteFile

trueに設定されている場合、Oracleファイル/FTPアダプタはファイルを処理後に削除します。

DirectorySeparator

複数のディレクトリを選択した場合、生成されるJCAファイルではディレクトリのセパレータとしてセミコロン(;)が使用されます。ただし、他のセパレータへの変更も可能です。その場合は、生成されたJCAファイルに手動で<property name="DirectorySeparator" value="選択したセパレータ"/>を追加します。たとえば、セパレータとしてカンマ(,)を使用する場合は、まず物理ディレクトリ内でセパレータをカンマ(,)に変更してから、JCAファイルに<property name="DirectorySeparator" value=","/>を追加します。

ElapsedTime

このプロパティは、アウトバウンドのバッチ処理に使用されます。指定された時間が経過すると、発信ファイルが作成されます。パラメータ・タイプはintで必須ではありません。デフォルト値は1です。

Encoding

添付に使用するエンコーディングを設定します。このパラメータはOracleファイル/FTPアダプタの内部では使用されず、Oracleファイル/FTPアダプタがパブリッシュする添付を処理するサード・パーティ・アプリケーションで使用されます。

ExcludeFiles

このプロパティは、ポーリング中に除外するファイル・タイプのパターンを指定します。プロパティ・タイプはStringで必須ではありません。

FileName

このパラメータを使用して、書込み操作中に静的な単一ファイル名を指定します。

FileNamingConvention

このプロパティは、アウトバウンドのWrite操作ファイルのネーミング規則に使用されます。

FileSize

このプロパティは、アウトバウンドのバッチ処理に使用されます。この発信ファイルは、ファイル・サイズの条件が満たされると作成されます。パラメータ・タイプはintで必須ではありません。デフォルト値は1000KBです。

IncludeFiles

このプロパティは、ポーリング中に取得するファイル・タイプのパターンを指定します。パラメータ・タイプはStringで必須です。

Lenient

Lenientプロパティは、デプロイメントの検証とともに機能します。インバウンド・ディレクトリの読取りまたは書込みができない場合、アダプタは失敗をスローしてデプロイメントをロールバックします。ただし、Lenientをtrueに設定にすると、デプロイメントが継続されます。このプロパティのデフォルト値はfalseです。

ListSorter

このプロパティは、Oracleファイル/FTPアダプタがインバウンド内のファイルのソートに使用するソーターを指定します。このパラメータは次のように設定できます。

- ファイル名を変更タイムスタンプの昇順でソートするには、oracle.tip.adapter.file.inbound.listing.TimestampSorterAscendingと設定します。

- ファイル名を変更タイムスタンプの降順でソートするには、oracle.tip.adapter.file.inbound.listing.TimestampSorterDescendingと設定します。

LogicalArchiveDirectory

このプロパティは、正常に処理されたファイルをアーカイブする論理ディレクトリを指定します。プロパティ・タイプはStringで必須ではありません。

LogicalDirectory

このパラメータは、ポーリングする論理入力ディレクトリを指定します。パラメータ・タイプはStringです。

MaxRaiseSize

このプロパティは、Oracleファイル/FTPアダプタが各ポーリング・サイクルで処理用に発行するファイルの最大数を指定します。たとえば、インバウンド・ディレクトリに1000のファイルがあり、MaxRaiseSizeが100に設定されていて、ポーリング頻度が1分の場合、Oracleファイル/FTPアダプタは毎分100ファイルを発行します。

MinimumAge

このパラメータは、取得するファイルの最短経過時間を指定します。この指定により、大きなファイルを処理用に取得する前に、入力ディレクトリに完全にコピーできるようになります。経過時間は最終更新時のタイムスタンプで決定されます。たとえば、ファイルの書込みに3分から4分かかることがわかっている場合は、ポーリング可能ファイルの最短経過時間を5分に設定します。入力ディレクトリでファイルが検出されても、更新時間から5分以内の場合、まだ書込みが実行されている可能性があるためファイルは取得されません。

NumberMessages

このプロパティは、アウトバウンドのバッチ処理に使用されます。この発信ファイルは、メッセージ数の条件が満たされると作成されます。パラメータ・タイプはintで必須ではありません。デフォルト値は1です。

PhysicalArchiveDirectory

このプロパティは、正常に処理されたファイルのアーカイブ場所を指定します。プロパティ・タイプはStringで必須ではありません。

PhysicalDirectory

このプロパティは、ポーリングする1つ以上の物理入力ディレクトリを指定します。パラメータ・タイプはStringです。ファイルが配置されるインバウンド・ディレクトリは必須です。物理ディレクトリまたは論理ディレクトリを指定する必要があります。

PollingFrequency

このパラメータは、特定の入力ディレクトリで新しいファイルをポーリングする頻度を指定します。パラメータ・タイプはintで必須です。デフォルト値は1分です。

PublishSize

このプロパティは、ファイルに複数のメッセージがあるかどうか、およびBPELプロセスに一度にパブリッシュするメッセージ数を特定します。パラメータ・タイプはintで必須ではありません。デフォルト値は1です。

たとえば、あるファイルに11個のレコードがあり、このパラメータが2に設定されている場合、そのファイルでは一度に2レコードずつ処理され、最終レコードは6回目に処理されます。

Recursive

このプロパティがtrueに設定されている場合、アダプタはメイン入力ディレクトリの下にあるすべてのサブディレクトリを再帰的に処理できます。

SequenceName

アウトバウンドOracleファイル/FTPアダプタを高可用性に対応するよう構成している場合、使用されるOracleデータベースの順序名を指定します。

SingleThreadModel

値がtrueの場合、Oracleファイル/FTPアダプタのポーラーはファイルを同一スレッド内で処理します。つまり、グローバルなインメモリー・キューを処理に使用しません。

SourceFileName

ファイルI/O操作用のソース・ファイル。

SourcePhysicalDirectory

ファイルI/O操作用のソース・ディレクトリ。

SourceSchema

ソース・ファイルのスキーマに設定します。

SourceSchemaRoot

ソース・ファイルのルート要素名に設定します。

SourceType

ソース・ファイルがネイティブの場合はnativeに、xmlの場合はxmlに設定します。

TargetFileName

ファイルI/O操作用のターゲット・ファイル。

TargetPhysicalDirectory

ファイルI/O操作用のターゲット・ディレクトリ。

TargetSchema

このプロパティ値は、ターゲット・ファイルのスキーマに設定します。

TargetSchemaRoot

このプロパティ値は、ターゲット・ファイルのルート要素名に設定します。

TargetType

ターゲット・ファイルがネイティブの場合はnativeに、xmlの場合はxmlに設定します。

ThreadCount

このプロパティを使用できる場合、アダプタはグローバル・スレッド・プールのプロセッサ・スレッドに依存せず、独自のプロセッサ・スレッドを作成します(デフォルトでは4つ)。つまり、このパラメータはインメモリー・キューを分割し、それぞれのコンポジット・アプリケーションが独自のインメモリー・キューを取得します。

- ThreadCountプロパティが0に設定されている場合、スレッド動作はシングル・スレッド・モデルと同じになります。

- ThreadCountプロパティが-1に設定されている場合、グローバル・スレッド・プールが使用され、動作はデフォルトのスレッド・モデルと同じになります。

- ThreadCountプロパティの最大値は40です。

TriggerFile

インバウンドOracleファイル/FTPアダプタをアクティブ化するトリガー・ファイルの名前。

TriggerFilePhysicalDirectory

Oracleファイル/FTPアダプタがトリガー・ファイルを検索するディレクトリ・パス。

TriggerFileStrategy

このプロパティは、Oracleファイル/FTPアダプタがトリガー・ファイル・ディレクトリ内で指定のトリガー・ファイルを検索する際に使用する戦略を定義します。使用可能な値は、EndpointActivation、EveryTimeまたはOnceOnlyです。

Type

ファイルIO相互作用については、COPY、MOVEまたはDELETEに設定します。

UseRemoteErrorArchive

このプロパティは、インバウンド読取り時にエラーがアーカイブされる場所を定義します。インバウンド読取りの操作中、不正な形式のXMLファイルが読み取られるとエラーが発生します。エラーになったファイルは、デフォルトでリモート・ファイル・システムに送信されてアーカイブされます。エラーになったファイルは、jcaファイルにuseRemoteErrorArchiveプロパティを指定し、そのプロパティをfalseに設定することで、ローカル・ファイルシステムでアーカイブできます。このプロパティのデフォルト値はtrueです。

UseHeaders

このパラメータは、trueまたはfalseに設定できます。インバウンドOracleファイルまたはFTPアダプタの使用中に、ファイル・ヘッダーを読み取り、ペイロードの読取りをスキップする必要がある場合は、UseHeaderプロパティをtrueに設定します。

これは通常、インバウンド・アダプタを通知機能として使用する、大きいペイロードのシナリオで使用されます。

UseStaging

trueに設定されている場合、アウトバウンドOracleファイル/FTPアダプタは変換データをステージング・ファイルに書き込んだ後、そのステージング・ファイルをターゲット・ファイルにストリーミングします。falseに設定されている場合、アウトバウンドOracleファイル/FTPアダプタは中間ステージング・ファイルを使用しません。

Xsl

ソースとターゲット間のxslトランスフォーマに設定します。

表A-2 Oracle FTPアダプタに固有のJCAプロパティ

プロパティ

説明

FileType

このプロパティは、要件に応じてasciiまたはbinaryに設定します。

SourceIsRemote

IO操作のソースがリモートFTPサーバーではなくローカル・ファイルシステムであることをOracle FTPアダプタに通知する場合、このプロパティをfalseに設定します。

TargetIsRemote

IO操作のターゲットがリモートFTPサーバーではなくローカル・ファイルシステムであることをOracle FTPアダプタに通知する場合、このプロパティをfalseに設定します。

UseNlst

Oracle FTPアダプタでデフォルトのLISTコマンドのかわりにNLST FTPコマンドを使用する場合、このプロパティをtrueに設定します。

UseRemoteArchive

このプロパティをtrueに設定すると、アーカイブ・ディレクトリは同じFTPサーバー上にあることがOracle FTPアダプタに通知されます。falseに設定すると、Oracle FTPアダプタはアーカイブにローカル・ファイルシステム・フォルダを使用します。

表A-3 Oracleファイル/FTPアダプタのバインディング・プロパティ

プロパティ

説明

IgnoreListingErrors

ポーリング操作中のインバウンドOracleファイル・アダプタの動作を制御できます。trueに設定すると、Oracleファイル・アダプタはネストされたフォルダからの読取りができなくてもそれを通知しません。

IgnoreZeroByteFile

ファイルが見つからない場合に、アウトバウンド読取り操作中にOracleファイル/FTPアダプタが例外をスローしないようにするには、trueに設定します。インバウンド・ファイルのスキーマがOpaque以外の場合、このプロパティは無視されます。

NestedFolderLimit

ファイル/FTPアダプタがファイルをポーリングするために入力ディレクトリに再帰的に処理するレベル数を制限します。

InMemoryTranslation

このプロパティは、UseStagingがfalseに設定されている場合にのみ適用されます。UseStagingがtrueに設定されている場合、変換ステップはメモリー内で行われます(つまり、インメモリー・バイト配列が作成されます)。falseに設定されている場合、アダプタはターゲット・ファイル(FTP、FTPS、SFTPを含む)への出力ストリームを作成し、トランスレータにストリームの変換や直接書込みを許可します。

jca.message.encoding

このプロパティは、インバウンドOracleファイル/FTPアダプタのNXSDスキーマに指定されているエンコーディングをオーバーライドするために使用します。

NotifyEachBatchFailure

trueに設定すると、デバッチ・シナリオでエラーが発生するたびに、Oracleファイル/FTPアダプタは通知エージェントのonBatchFailureをコールします。falseに設定すると、すべてのメッセージのデバッチ後に1回のみ、Oracleファイル/FTPアダプタはonBatchFailureをコールします。

oracle.tip.adapter.file.debatching.rejection.quantum

このプロパティでは、インバウンドOracleファイル/FTPアダプタのパートナ・リンクで拒否されるメッセージのサイズを制御できます。たとえば、これを100に設定すると、実際のファイルが大きすぎる場合、Oracleファイル/FTPアダプタはファイルの100行を拒否します。

oracle.tip.adapter.file.highavailability.maxRetry

分散ポーリング・シナリオでデータベース接続の確立をインバウンドOracleファイル/FTPアダプタが再試行する回数。

oracle.tip.adapter.file.highavailability.maxRetryInterval

分散ポーリング・シナリオでデータベース接続の確立をインバウンドOracleファイル/FTPアダプタが再試行するまでのミリ秒数。

oracle.tip.adapter.file.mutex

このプロパティ値は、アウトバウンド書込み操作のmutexを指定するクラス名に設定します。このクラスは、oracle.tip.adapter.file.Mutex抽象化を拡張する必要があります。

oracle.tip.adapter.file.rejectOriginalContent

trueに設定すると、Oracleファイル/FTPアダプタは元のコンテンツを拒否します。falseに設定すると、アダプタは、変換ステップによって作成されたXMLデータを拒否します。

oracle.tip.adapter.file.timeout.recoverpicked.minutes

このプロパティは、FILEADAPTER_INをコーディネータとして使用している際にインバウンドの高可用性アダプタが使用します。処理用のファイルがノードによって初めて要求(エンキュー)されると、FILEADAPTER_INのFILE_PROCESSED列は0に設定されます。後で、分離されたプロセッサ・スレッドが処理用のファイルを取得すると、FILE_PROCESSED列の値は0から1に更新されます。ファイルの処理が完了すると、FILE_PROCESSED列は1から2に更新されます。ただし、プロセッサ・スレッドはファイルを取得したが、ファイルの処理前にノードがクラッシュした場合、そのファイルは処理されません。このプロパティは、取得操作をundoするために使用します。アダプタはこの際、取得後にここに指定した時間内に処理されなかったFILEADAPTER_IN表内のエントリを削除します。

oracle.tip.adapter.file.timeout.recoverunpicked.minutes

このプロパティは、FILEADAPTER_INをコーディネータとして使用している際にインバウンドの高可用性アダプタが使用します。ノードがファイルを処理用に初めて要求すると、FILEADAPTER_INのFILE_PROCESSED列は0に設定されることに注意してください。この後で、分離されたプロセッサ・スレッドがファイルを処理用に取得すると、FILE_PROCESSED列の値は0から1に更新されます。ファイルの処理が完了すると、FILE_PROCESSED列は1から2に更新されます。FILE_PROCESSEDが0である間にノードがクラッシュすると、ファイルはノードによってエンキューされます(他のノードはこのファイルを取得できません)。ただしこの場合、分離されたプロセッサ・スレッドも、このファイルを処理用にまだ取得していません。このプロパティは、要求(enqueue_ operation)をundoするために使用されます。アダプタはこの際、要求後にまだ取得されていないFILEADAPTER_IN表内のエントリ(たとえばFILE_PROCESSED =="0")を削除します。

RecoveryInterval

このプロパティは、エラーの発生時にインバウンド・アダプタがリカバリ間隔を構成するために使用します。たとえば、物理ディレクトリが存在しない場合、アダプタはこの値を使用して定期的なスリープまたはウェイクアップ・チェックを実行し、物理ディレクトリが作成されていてアクセス可能であるかどうかをチェックします。

SerializeTranslation

trueに設定されている場合、変換ステップはセマフォを使用してシリアライズされます。セマフォ(変換ステップをガード)の許可数は、ConcurrentThresholdプロパティから導出されます。falseの場合、変換ステップはセマフォ外で行われます。

UseFileSystem

このプロパティは、クラスタ環境での読取り専用ポーリング中にインバウンドOracleファイル/FTPアダプタが使用します。これをtrueに設定すると、アダプタはファイルシステムを使用して処理済のファイルのメタデータを格納します。falseに設定すると、アダプタはデータベース表を使用します。

表A-4 Oracle FTPアダプタに固有のバインディング・プロパティ

プロパティ

説明

TimestampOffset

このプロパティは、タイムゾーンの問題を処理するためにOracle FTPアダプタによって使用されます。通常は、Oracle FTPアダプタが実行されているシステムとFTPサーバーとの時差をミリ秒に変換するために使用されます。

control.so.timeout

このプロパティを使用して、FTPサーバーへの制御ソケットのタイムアウトを定義できます。このパラメータは、ミリ秒単位で指定する必要があります。

表A-5 Oracleファイル・アダプタのJCAプロパティ: 正規化されたプロパティ

プロパティ

説明

jca.file.FileName

このプロパティは、インバウンド・ディレクトリから読み取られるか、またはアウトバウンド・ディレクトリに書き込まれるファイルの名前を指定します。

jca.file.Directory

このプロパティは、ファイルの読取り元または書込み先のディレクトリの名前を指定します。

jca.file.Size

このプロパティは、インバウンドOracleファイル・アダプタからパブリッシュされたファイルのサイズを指定します。

jca.file.Batch

このプロパティは、インバウンド・アダプタからパブリッシュされるファイルの一意の識別子を指定するために使用します。

jca.file.BatchIndex

ファイルに複数のメッセージとデバッチ処理が使用されている場合、この正規化されたプロパティは、同じバッチからのメッセージ(レコード)数を指定します。この場合、jca.file.Batchはそのままですが、jca.file.BatchIndexは同じバッチからのパブリッシュごとに1ずつ増分します。

jca.file.IsEOF

このプロパティは、チャンク相互作用で使用されます。ファイルの最後に達したかどうかを検出するのに使用されます。

表A-6 Oracle FTPアダプタのJCAプロパティ: 正規化されたプロパティ

プロパティ

説明

jca.ftp.FileName

このプロパティは、インバウンド・ディレクトリから読み取られるか、またはアウトバウンド・ディレクトリに書き込まれるファイルの名前を指定します。

jca.ftp.Directory

このプロパティは、ファイルの読取り元または書込み先のディレクトリの名前を指定します。

jca.ftp.Size

このプロパティは、インバウンドOracleファイル・アダプタからパブリッシュされたファイルのサイズを指定します。0を指定できます。

jca.ftp.Batch

このプロパティは、インバウンドOracle FTPアダプタからパブリッシュされるファイルの一意の識別子を指定するために使用します。

jca.ftp.BatchIndex

ファイルに複数のメッセージとデバッチ処理が使用されている場合、この正規化されたプロパティは、一致するバッチからのメッセージ(レコード)数を指定します。この場合、jca.ftp.Batchはそのままですが、jca.ftp.BatchIndexは同じバッチからのパブリッシュごとに1ずつ増分します。

A.2 プロパティ

この項では、適用可能な次のプロパティについて説明します。

- 表A-7

すべてに適用可能なプロパティについては、「Oracle JCAアダプタの汎用プロパティ」を参照してください。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracleソケット・アダプタに関する項を参照してください。

表A-7 JCAプロパティ

プロパティ

説明

ByteOrder

通信中のリモート・コンピュータのバイト順。

CustomImpl

CustomImplをTransModeプロパティとして選択すると、それがハンドシェイクを定義するJavaクラスの名前になります。このプロパティは、ICustomParserインタフェースの具体的な実装です。

Encoding

リモート・コンピュータで使用するキャラクタ・エンコーディング。

Host

アウトバウンドの場合は、ソケット・サーバーが実行されていて、接続先となるコンピュータ名。インバウンドの場合は、常にlocalhostです。

Port

アウトバウンドの場合は、ソケット・サーバーが実行されていて、アダプタの接続先となるポート番号です。

インバウンドの場合は、着信接続をソケット・アダプタがリスニングするポート番号です。

ReplyXslt

XSLTをTransModeプロパティとして選択すると、インバウンド・リプライのハンドシェイクを定義するスタイルシートへのパスが指定されます。

TransMode

プロトコル定義メカニズム。スタイルシートを使用する場合はXSLTに、カスタムJavaコードを使用する場合はCustomImplに、通常のスキーマ変換を行う場合はNXSDに設定します。JavaScriptハンドシェイク・ベース・プロトコルの場合は、Scriptに設定します。

Xslt

XSLTをTransModeプロパティとして選択すると、インバウンドおよびアウトバウンドのリクエストまたはリプライの場合、インバウンド・リクエストのハンドシェイクを定義するスタイルシートへのパスが指定されます。

RequestScript

サービス側のみ。要求側の通信を処理するために使用されるJavaScriptファイルの名前。TransModeがスクリプトに設定されている場合に使用します。

ReplyScript

サービス側のみ。応答側の通信を処理するために使用されるJavaScriptファイルの名前。TransModeがスクリプトに設定されている場合に使用します。

OutboundScript

参照側のみ。アウトバウンド通信に使用されるJavaScriptファイルの名前。TransModeがスクリプトに設定されている場合に使用します。

SupportNIO

デフォルトでは、このプロパティはtrueに設定されています(指定がない場合)。NIOは、インバウンド方向に対してのみ、およびNXSDモードの変換に対してのみサポートされています。XSLT、CustomImpl、Script、SupportNIOといった他のモードでは、falseに設定されています。

また、NIOは非SSL接続に対してのみサポートされています。

A.3 プロパティ

この項では、適用可能な次のプロパティについて説明します。

- 表A-8

- 表A-9

- 表A-10

すべてに適用可能なプロパティについては、「Oracle JCAアダプタの汎用プロパティ」を参照してください。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle AQアダプタに関する項を参照してください。

表A-8 JCAプロパティ

プロパティ

説明

QueueName

読取りまたは書込みが行われるAQキューの名前。

DatabaseSchema

キューが存在するスキーマ。指定しない場合、現在の接続のスキーマが使用されます。

SchemaValidation

このプロパティがtrueに設定されている場合、指定したスキーマと対照してペイロードが検証されます。検証に失敗した場合、メッセージは拒否されます。

EnableStreaming

このプロパティがtrueに設定されている場合、キューからのペイロードはインメモリーDOMとして処理されるかわりにストリーミングされます。この機能は、大きなペイロードの処理中に使用する必要があります。このプロパティは、RAWメッセージ、XMLTypeメッセージおよびADT属性を介してペイロードが指定されるADTタイプのメッセージを処理する際に適用可能です。

RecipientList

コンシューマ名またはアダプタによってエンキューされたメッセージの対象受信者の名前を指定します。メッセージは、すべての受信者がメッセージをデキューするまでキュー内に残ります。このフィールドを空のままにした場合、現在アクティブなすべてのコンシューマが受信者になります。

Consumer

マルチ・コンシューマ・キューにのみ適用可能です。指定した場合、特定のコンシューマを対象としたメッセージのみが処理可能になります。

ObjectFieldName

このプロパティは、キューがADTキューである場合に、ビジネス・ペイロードを含むフィールドの識別に使用されます。ペイロードを構成するADTの属性を指定するか、またはペイロードを表すADT全体を指定できます。前者の場合は、「ObjectFieldName」はADTの属性名と同じである必要があります。後者の場合、このプロパティは指定されません。

PayloadHeaderRequired

ObjectFieldNameプロパティに値を指定する場合にのみ適用可能です。trueに設定すると、ADTのペイロード以外のすべての属性が、正規化されたメッセージ・プロパティjca.aq.HeaderDocumentとして処理可能になります。

MessageSelectorRule

マルチ・コンシューマ・キューでデキューが実行される際には、メッセージを選別して特定の条件を満たすもののみを着信することが必要な場合があります。これらの条件はペイロード値またはキュー・ヘッダー値に基づき、アダプタのMessageSelectorRuleプロパティを使用して指定できます。これらの条件は、特定の優先度のメッセージの選択、または$100,000を超えるローン・アプリケーションのみを選択する場合などはメッセージ・ペイロードの一部に関係します。

DequeueCondition

このプロパティは、デキュー操作に対してのみ有効です。SQL問合せのWHERE句に似たブール式を入力します。この式には、メッセージ・プロパティ、ユーザー・データ・プロパティ(オブジェクト・ペイロードのみ)およびPL/SQLまたはSQL関数に関する条件を含めることができます。複数のメッセージがデキュー条件を満たす場合、デキューの順序は未確定で、キューのソート順は考慮されません。

Correlation

各メッセージに識別子を割り当て、後で特定のメッセージを取得する方法を提供できます。入力する値は、非同期通信のためにエンキューの送信元とデキューの受信先で同意されています。この値は、正規化されたメッセージ・プロパティjca.aq.Correlationを介してメッセージごとにオーバーライドできます。デキュー操作に対して指定されている場合、指定した値と一致するメッセージのみがデキューされます。何も指定されていない場合、キュー内のすべてのメッセージをデキュー操作に使用できます。

PayloadSizeThreshold

このプロパティでは、構成可能な制御メカニズムが公開され、これによりアダプタ・レイヤー内のペイロード・サイズしきい値を指定できます。サイズが構成されたしきい値の制限を超えるメッセージは拒否されます。このプロパティが構成されていない場合、メッセージ・サイズに対する制限はありません。

表A-9 JCAプロパティ: 正規化されたプロパティ

プロパティ

説明

jca.aq.Attempts

メッセージのデキュー時における失敗の試行回数。

jca.aq.Correlation

ユーザーにより割り当てられた相関ID。

jca.aq.Delay

メッセージがデキュー可能になるまでの秒数。

jca.aq.EnqueueTime

メッセージがエンキューされた時間。

jca.aq.ExceptionQueue

例外キューの名前。

jca.aq.Expiration

メッセージが失効するまでの秒数。このパラメータはDelayパラメータからのオフセットです。指定しない場合、デフォルト値の-1(never expires)が使用されます。

jca.aq.MessageId

デキューされたメッセージの16進形式のメッセージID。

jca.aq.OrigMessageId

16進形式の元のメッセージID。

jca.aq.Priority

メッセージの優先度。数値が小さいほど高い優先度を示します。優先度には任意の数値を指定できます。デフォルト値は0です。

jca.aq.RecipientList

このメッセージの受信者リスト(カンマ区切り)。これにより、InteractionSpecのRecipientListがオーバーライドされます。

jca.aq.HeaderDocument

現在のヘッダーの文字列またはDOM (XML DOM形式のペイロード・ヘッダー)が含まれています。

表A-10 バインディング・プロパティ

プロパティ

説明

ConnectionRetryDelay

接続の消失後に接続の再作成を試行するまで待機する時間。デフォルト値は15です。

DequeueTimeOut

インバウンド・キューでメッセージが受信されない場合にdequeue() APIがタイムアウトになるまでの間隔。デフォルト値は1です。

adapter.aq.dequeue.threads

エンドポイントがアクティブ化されたときに作成されるポーラー・スレッドの数を指定します。デフォルト値は1です。

A.4 プロパティ

この項では、適用可能な次のプロパティについて説明します。

- 表A-11

- 表A-12

- 表A-13

すべてに適用可能なプロパティについては、「Oracle JCAアダプタの汎用プロパティ」を参照してください。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle JMSアダプタに関する項を参照してください

表A-11 Oracle JMSアダプタのJCAプロパティ

プロパティ

説明

DestinationName

読取りまたは書込みが行われるキューまたはトピックの名前。

UseMessageListener

非推奨。現在のバージョンでサポートされているこのプロパティの値はfalseのみです。falseの値を指定すると、メッセージのキューまたはトピックをポーリングする同期メカニズムがJMSアダプタで確実に使用されます。

PayloadType

このプロパティは、アダプタによってデキューまたはエンキューされるJMSメッセージのタイプを指定します。マップ・メッセージの場合、値はMapMessageで、テキスト・メッセージの場合、値はTextMessageです。

DurableSubscriber

永続サブスクリプションの識別に使用される名前。永続サブスクリプションを処理する場合は、DurableSubscriberプロパティ以外に、ClientIDも指定されていることを確認してください。ClientIDは、管理コネクション・ファクトリ・インスタンスの定義時にFactoryPropertiesプロパティの一部として指定されます。このプロパティは、JMSトピック・シナリオで作業する場合にのみ適用可能です

MessageSelector

構文がSQL92条件式構文のサブセットに基づいている文字列。この文字列では、ヘッダー・フィールド参照およびプロパティ参照を使用して、メッセージ・アダプタが対象であることを指定できます。ヘッダー値およびプロパティ値がセレクタと一致するメッセージのみが配信されます。

PayloadEntry

タイプがMapMessageのメッセージを処理する場合にのみ適用可能です。このプロパティは、マップ・メッセージを処理する場合に、ビジネス・ペイロードを含むフィールドの識別に使用されます。それ以外のすべてのマップ・メッセージ・エントリは、jca.jms.Map.MapMessage entry nameを使用してアクセスされる正規化されたメッセージ・プロパティとして使用可能になります

AttachmentList

タイプがMapMessageのメッセージを処理する場合にのみ適用可能です。このプロパティは、マップ・メッセージを処理する場合に、ビジネス・ペイロードを含むフィールドの識別に使用されます。また、この場合ペイロードは添付としてパブリッシュされます。PayloadEntryまたはAttachmentListを使用できます。それ以外のすべてのマップ・メッセージ・エントリは、jca.jms.Map.MapMessage entry nameを使用してアクセスされる正規化されたメッセージ・プロパティとして使用可能になります

RequestDestinationName

このプロパティは、同期リクエスト-リプライ・シナリオに適用され、メッセージを送信する宛先の名前を指定します。

ReplyDestinationName

このプロパティは、同期リクエスト-リプライ・シナリオに適用され、メッセージを受信する返信先の名前を指定します。

AllowTemporaryReplyDestination

このプロパティは、同期リクエスト-リプライ・シナリオに適用されます。trueに設定すると、ReplyDestinationNameは不要になり、JMSアダプタではリプライの受信に一時返信先が使用されます。

EnableStreaming

このプロパティがtrueに設定されている場合、キューまたはトピックからのペイロードはインメモリーDOMとして処理されるかわりにストリーミングされます。この機能は、大きなペイロードの処理中に使用する必要があります。

DeliveryMode

使用する配信モードを表します。メッセージ・プロデューサのデフォルト配信モードはPERSISTENTです。この値は、正規化されたメッセージ・プロパティjca.JMSDeliveryModeを使用して、メッセージごとにオーバーライドできます。

TimeToLive

メッセージの存続期間を表します(ミリ秒単位)。メッセージ・プロデューサのデフォルト存続時間は無制限です。メッセージは失効しません。0の値は、メッセージが失効しないことを示します。

PayloadSizeThreshold

このプロパティでは、構成可能な制御メカニズムが公開され、これによりアダプタ・レイヤー内のペイロード・サイズしきい値を指定できます。サイズが構成されたしきい値の制限を超えるメッセージは拒否されます。このプロパティが構成されていない場合、メッセージのサイズに制限はありません

Priority

このメッセージの優先度を表します。メッセージ・プロデューサのデフォルトの優先度は4です。この値は、正規化されたメッセージ・プロパティjca.jms.JMSPriorityを使用して、メッセージごとにオーバーライドできます。

UnitOfOrder

順序単位機能の使用を指定します。メッセージ順序単位機能を使用すると、メッセージ・プロデューサや単体として動作するプロデューサのグループが、複数のメッセージを1つの単位にグループ化してメッセージを作成順に処理することが可能になります。

表A-12 JCAプロパティ: 正規化されたプロパティ

プロパティ

説明

jca.jms.JMSDestinationName

このプロパティはメッセージの送信先を指定し、JMSプロデューサによって設定されます。

jca.jms.JMSDestinationProperties

このプロパティは、メッセージを送信する必要がある宛先オブジェクトを参照する場合に使用されるコンテキストを定義するプロパティを表します。

jca.jms.JMSCorrelationID

このプロパティは、レスポンス・メッセージとリクエスト・メッセージをリンクするために、プロデューサおよびコンシューマの両方によって設定されます。これはオプションの属性です。

jca.jms.JMSType

このプロパティは、JMSメッセージ・タイプを指定します。

jca.jms.JMSReplyTo

これは、メッセージの返信を送信する必要がある宛先を示すオプションの属性です。

jca.jms.JMSPriority

このプロパティは、0から9の優先度の数値を設定するために、コンシューマによって使用されます。数値が大きいほど優先度が高くなります。

jca.jms.JMSExpiration

このプロパティは、期限切れ前のメッセージの期間を指定します。メッセージが有効期限に達した場合、JMSプロバイダはそのメッセージを破棄する必要があります。

jca.jms.JMSDeliveryMode

このプロパティは、JMSクライアントによってpersistentまたはnonpersistentモードに設定されます。

jca.jms.JMSMessageID

このプロパティは、一意のメッセージ識別子を指定するために使用します。一意性の正確な範囲はプロバイダによって定義されます。

jca.jms.JMSRedelivered

このプロパティは、メッセージが再配信されたものかどうかを示すために使用します。「JMSRedelivered」フィールドが設定されたメッセージをクライアントが受信した場合、そのメッセージは以前に配信されたが、そのときは受信が確認されなかった可能性があります。

jca.jms.JMSTimestamp

このプロパティは、送信先のJMSプロバイダにメッセージが渡される時間を指定するために使用します。

jca.jms.JMSProperty.name

このプロパティは、メッセージのカスタム(アプリケーション固有)プロパティを表します。サポートされているプロパティは、JMSの仕様に従って許可されたものに準拠します。無効なプロパティ値が指定された場合、アダプタによりユーザーに警告が通知され(ログ・ファイルに記録)、その無効なプロパティが無視されます。

jca.jms.Map.name

このプロパティは、ペイロードとして転送されないMapMessage要素を表します。

jca.jms.WeblogicUnitOfOrder

この値により、JmsProduceInteractionSpecのUnitOfOrderプロパティを使用して指定された値がオーバーライドされます。

jca.jms.JMSProperty.JMS_BEA_UnitOfOrder

この正規化されたプロパティは、BPELのreceiveアクティビティでインバウンドJMSメッセージに設定された順序単位の値を取得するために使用します。

表A-13 バインディング・プロパティ

プロパティ

説明

adapter.jms.encoding

インバウンド・テキスト・メッセージのエンコーディングに使用されます。このプロパティは、インバウンドとアウトバウンドの両方のメッセージに適用可能なjca.message.encodingと呼ばれる新たにサポートされたプロパティに置き換えられました。

adapter.jms.DistributedDestinationConnectionEveryMember

このプロパティは、ブール値になります。

[true | false]。デフォルト値はtrueです。

trueの場合、アダプタは分散宛先の各メンバーに対してコンシューマ/サブスクライバを作成します。falseに設定すると、アダプタは分散宛先のローカル・メンバーに対してのみ、コンシューマ/サブスクライバを作成します。アダプタがリモート・クラスタ上の分散宛先またはリモート・ドメインのサーバーに接続している場合、プロパティadapter.jms.DistributedDestinationConnection EveryMemberは常にtrueに設定する必要があります。アダプタがローカル・クラスタ上の分散宛先に接続している場合、プロパティはtrueまたはfalseのいずれかに設定できます。trueに設定する場合、アダプタの動作は以前と同じままです(分散宛先ごとにコンシューマが作成されます)。

falseに設定すると、アダプタはローカル・メンバーに対してのみコンシューマ/サブスクライバを作成します。

サービス側では、バインディング・プロパティとしてJDeveloperユーザー・インタフェースのプロパティは表示されません。<service> /<binding.jca>タグの下に、次のようにcomposite.xmlにプロパティを手動で追加する必要があります。

<property name="adapter.jms.DistributedDestinationConnectionEveryMember" type="xs:string" many="false" override="may">false</property>

adapter.jms.receive.threads

エンドポイントがアクティブ化されたときに作成されるポーラー・スレッドの数を指定します。デフォルトは1です。

adapter.jms.receive.timeout

同時受信コールに使用されるタイムアウト値。インバウンド・キューでメッセージが受信されない場合にreceive() APIがタイムアウトになるまでの時間。デフォルト値は1です。

adapter.jms.registration.interval

このプロパティは現在サポートされていません。

adapter.jms.retry.interval

インバウンド接続再試行レイヤーで使用されます。Oracle JMSアダプタが接続の消失後に接続の再作成を試行するまで待機する時間。デフォルト値は30です。

JMSReplyToDestinationProperties

インバウンド・リクエスト/リプライ・シナリオで受信された宛先オブジェクトにカスタム・プロパティ設定を宣言的に設定します。

JMSReplyUseCorrelationIdForCorrelation

相関に相関IDを使用するかどうかを指定するために使用されます。値はtrueおよびfalseです。デフォルト値はfalseです。

JMSReplyUseMessageIdForCorrelation

相関のメッセージIDかどうかを指定するために使用されます。値はtrueおよびfalseです。何も指定されていない場合のデフォルト値はfalseです。

JMSReplyPropagateJMSExpiration

ブール・プロパティは、リプライ・メッセージTTLが0に設定される(メッセージは失効しない)か、一部の指定された値がメッセージの有効期限に関連するかどうかを指定します。デフォルト値はfalseです。

RequestReply.cacheReceivers

同じ少数のJMS受信者が同じリクエスト宛先に繰り返し使用される場合、このプロパティをtrueに設定するとパフォーマンスが向上します。何も指定されていない場合のデフォルト値はfalseです。

RequestReply.useCorrelation

同期リクエスト-リプライ・シナリオに適用されます。trueに設定すると、リプライ・メッセージの取得用にJMSメッセージ・セレクタが適用されます。リクエストの正規化されたメッセージ・プロパティjca.jms.JMSCorrelationIDが指定されている場合は、このプロパティが相関に使用されます。指定されていない場合には、JMSメッセージIDプロパティが使用されます。JMSアダプタはメッセージ・セレクタJMSCorrelationID = '<corrId>' [ AND (<wsdlSelector>) ]を使用します(ANDブランチは、ユーザーがMessageSelectorプロパティを指定した場合にのみ含まれます)。デフォルト値はtrue。

SuppressHeaders

ヘッダーのバイパスに使用されます。コンポジットがヘッダーを使用も生成もしないシナリオでは、trueの値を使用できます。その場合、パフォーマンスが向上することがあります。デフォルト値はfalseです。

A.5 プロパティ

この項では、適用可能な次のプロパティについて説明します。

- 表A-14

- 表A-15

すべてに適用可能なプロパティについては、「Oracle JCAアダプタの汎用プロパティ」を参照してください。

詳細は、次を参照してください。

- 『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracleデータベース・アダプタに関する項。

- 『Oracle SOA SuiteでのSOAアプリケーションの開発』の付録H「正規化されたメッセージ・プロパティ」。

表A-14 JCAプロパティ: インスタンス・プロパティ

プロパティ

説明

DataSourceName

このプロパティまたはxADataSource名、あるいはその両方は必須プロパティです。接続先のtx-level="local"データソースのJNDI名(jdbc/...)を指します。このプールを使用するすべての操作は、グローバル・トランザクションに依存せず、ローカルに処理されます。xADataSourceNameとdataSourceNameの両方が指定されている場合、後者がREAD操作に使用されます。

LogTopLinkAll

デフォルト値はFALSEです。DBアダプタ・ロギングを増加し、基礎となるすべてのTopLinkログ・メッセージが最大の粒度で含まれるようにする必要があります。このプロパティによって可視性は最大になりますが、アダプタ・ロギングは、最も関連のあるTopLink SQLロギングを示すようにチューニングされています。

PlatformClassName

これは必須プロパティです。これは、接続先のデータベースのタイプを指します。このプロパティに対して提示される値は次のとおりです。

- Oracle11Platform

- Oracle10Platform

- Oracle9Platform

- Oracle8Platform

- DB2Platform

- InformixPlatform

- SybasePlatform

- SQLServerPlatform

- MySQLPlatform

- DatabasePlatform

oracle.toplink.platform.database.DatabasePlatformのサブクラスのフル・パッケージおよびクラス名も指定できます。AS/400上のDB2の場合、oracle.tip.adapter.db.toplinkext.DB2AS400Platformの値を指定することをお薦めします。

UsesBatchWriting

デフォルト値はTRUEです。複数の同一の文が単一のバッチ文として実行されます。このプロパティは、既知の問題がある特定のJDBCドライバに対してのみ無効にしてください。

UsesSkipLocking

デフォルト値はTRUEです。SELECT FOR UPDATEを使用するOracleデータベースのポーリング文はSELECT FOR UPDATE SKIP LOCKEDに自動的にアップグレードされ、同時パフォーマンスが向上します。このプロパティは、ロッキングのスキップが他の機能または使用例に適合しない、特定の場合にのみ無効にします。

UsesNativeSequencing

デフォルト値はTRUEです。INSERT操作に対して順序番号を自動的に割り当てるSOAサービスが構成されている場合、TRUEを設定すると、順序番号がデータベースのネイティブ順序から導出されます。

XADataSourceName

これは必須プロパティです。データベースに接続するtx-level="global"データソースのJNDI名(jdbc/...)を指定します。このプールを使用するすべての操作では、グローバル・トランザクションにバインドし、1単位としてコミットまたはロールバックします。

表A-15 JCAプロパティ: 正規化されたメッセージ・プロパティ

プロパティ

説明

jca.db.CursorName

インバウンド/アウトバウンド。

jca.db.DataSourceName

アウトバウンド。

jca.db.Password

アウトバウンド。jca.db.passwordプロパティに値を割り当てることはできません。これは、データソースではgetConnectionメソッドに対するパスワードの動的な設定がサポートされていないためです。かわりにjca.db.ProxyPasswordを使用することを検討してください。

jca.db.ProxyCertificate

アウトバウンド。設定する場合は、プロキシ・タイプとしてOracleConnection.PROXYTYPE_CERTIFICATEを指定します。値は、証明書を含むbase64Binaryでエンコードされたbyte[]配列です。設定する場合は、jca.db.ProxyDistinguishedName、jca.db.ProxyUserおよびjca.db.ProxyPasswordは設定しません。

jca.db.ProxyDistinguishedName[1]

アウトバウンド。設定する場合は、プロキシ・タイプとしてOracleConnection.PROXYTYPE_DISTINGUISHED_NAMEを指定します。値はjava.lang.Stringとしてプロキシ識別名を設定します。設定する場合は、jca.db.ProxyCertificate、jca.db.ProxyUserNameおよびjca.db.ProxyPasswordは設定しません。

jca.db.ProxyIsThickDriver[1]

アウトバウンド。値はtrueおよびfalseです。JDBC-level APIにはthickドライバとthinドライバの間に一部不整合があるため、OCIドライバを使用する場合は、trueに設定します。

jca.db.ProxyPassword[1]

アウトバウンド。設定する場合は、プロキシ・タイプとしてOracleConnection.PROXYTYPE_USER_PASSWORDを指定します。値はjava.lang.Stringとしてプロキシ・ユーザーのパスワードを設定します。設定する場合は、jca.db.ProxyUserNameも設定する必要があります。設定する場合は、jca.db.ProxyCertificate名もjca.db.ProxyDistinguished名も設定しません。

jca.db.ProxyRoles[1]

アウトバウンド。プロキシ・ユーザーに関連付けられたロールを定義するために設定します。値はString[]配列として指定し、配列内の各java.lang.Stringをロール名に対応させます。このプロパティは、OracleConnection.PROXYTYPE_USER_PASSWORD、OracleConnection.PROXYTYPE_CERTIFICATEおよびOracleConnection.PROXYTYPE_DISTINGUISHED_NAMEのいずれかを使用する場合に適用可能です。

jca.db.ProxyUserName[1]

アウトバウンド。設定する場合は、プロキシ・タイプとしてOracleConnection.PROXYTYPE_USER_PASSWORDを指定します。値はjava.lang.Stringとしてプロキシ・ユーザーのユーザー名を設定します。設定する場合は、jca.db.ProxyPasswordも設定する必要があります。設定する場合は、jca.db.ProxyCertificate名もjca.db.ProxyDistinguished名も設定しません。

jca.db.UserName

アウトバウンド。jca.db.userNameプロパティに値を割り当てることはできません。これは、データソースではgetConnectionメソッドに対するユーザー名の動的な設定がサポートされていないためです。かわりにjca.db.ProxyUserNameを使用することを検討してください。

jca.db.XADataSourceName

アウトバウンド。

A.6 Oracle MQ Seriesアダプタのプロパティ

この項では、Oracle MQ Seriesアダプタに適用可能な次のプロパティについて説明します。

- 表A-16

- 表A-17

- 表A-18

- 表A-19

すべてのOracle JCAアダプタに適用可能なプロパティについては、「Oracle JCAアダプタの汎用プロパティ」を参照してください。

詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle MQアダプタに関する項を参照してください。

表A-16 Oracle MQ SeriesアダプタのJCAプロパティ

プロパティ

説明

QueueName

このプロパティは、メッセージの送受信用のMQキューの名前を指定します。

MessageType

このプロパティは、メッセージのタイプ「標準」、「リクエスト」、「リプライ」または「レポート」を指定します。

MessageFormat

このプロパティは、MQメッセージ・フォーマットのタイプ(「デフォルト」、「リクエスト/リプライ」など)を指定します。

Priority

このプロパティは、メッセージの優先度を指定します。値は0から9です。デフォルト値はAS_Q_DEFで、宛先キューで定義されている値が使用されます。

Persistence

このプロパティは、メッセージの永続性を設定するために使用します。このプロパティがtrueに設定されている場合、メッセージは保持されます。デフォルト値はAS_Q_DEFで、宛先キューで定義されている値が使用されます。

OnDeliveryFailure

このプロパティは、メッセージの配信に失敗した場合に使用します。デフォルト値はDeadLetterQueueで、メッセージは配信不能キューに送信されます。値がDISCARDに設定されている場合、メッセージは破棄されます。

PartialDeliveryForDL

このプロパティは、配布リストへの一部配信に使用します。デフォルト値はfalseです。

SegmentIfRequired

このプロパティは、メッセージのサイズがキューに設定された上限を超える場合に使用します。デフォルト値はtrue。

Expiry

このプロパティは、メッセージがキュー・マネージャによって削除されるまでの時間を指定します。デフォルト値はNEVERです。

ReplyToQueueName

このプロパティは、リプライまたはレポートを送信する必要があるキューの名前を指定します。

ReportCOA

このプロパティが設定されている場合、メッセージが宛先キューに着信したときに、着信時の確認レポートがreplytoキューに送信されます。デフォルト値はWITH_NO_DATAです。この場合、データは送信されません。

ReportCOD

このプロパティが設定されている場合、メッセージが宛先キューに着信したときに、送信時の確認レポートが返信先キューに送信されます。デフォルト値はWITH_NO_DATAです。この場合、データは送信されません。

ReportException

このプロパティが設定されている場合、宛先キューへのメッセージ配信が失敗したとき、例外レポートが返信先キューに送信されます。デフォルト値はWITH_NO_DATAです。この場合、データは送信されません。

ReportExpiry

このプロパティが設定されている場合、宛先キューへ送信されたメッセージが失効したとき、有効期限レポートが返信先キューに送信されます。デフォルト値はWITH_NO_DATAです。この場合、データは送信されません。

WaitInterval

このプロパティは、アウトバウンドMQキューのメッセージをデキューする待機間隔を指定します。

MessageId

このプロパティは、リプライ・メッセージまたはレポート・メッセージのメッセージIDを生成するために使用します。デフォルトでは、新しいメッセージIDが生成されます。

CorrelationId

このプロパティは、リプライ・メッセージまたはレポート・メッセージの相関IDを生成するために使用します。デフォルトでは、リクエスト・メッセージのメッセージIDが相関IDとして使用されます。

QueueOpenOptions

このプロパティは、キューへのアクセス中に使用するキューのオープン・オプションを指定します。

SecondaryQueueManagerName

このプロパティは、エンキュー・キューのキュー・マネージャを指定します。このプロパティは、アウトバウンド・エンキュー・キューがインバウンド・キュー・マネージャの外部にある場合にのみ使用します。

BackoutQueue

このプロパティは、インバウンド・キューから拒否されたメッセージの送信先のバックアウト・キューを指定するために使用します。

BackoutQueueManagerName

このプロパティは、バックアウト・キューのキュー・マネージャを指定するために使用します。このプロパティは、バックアウト・キューがインバウンド・キュー・マネージャの外部にある場合にのみ使用します。

MaximumBackoutCount

このプロパティは、拒否されたメッセージがバックアウト・キューに送信されるまでの最大バックアウト再試行回数を指定するために使用します。

BackoutInterval

このプロパティは、バックアウト再試行間の間隔を指定するために使用します。デフォルト値は5秒です。

BackoutRetries

このプロパティは、バックアウト再試行の回数を指定するために使用します。デフォルト値は3です。

FallbackReplyToQueueName

このプロパティは、通常メッセージ・キューにレポートを送信するために使用します。

FallbackReplyToQueueManagerName

このプロパティは、JNDI接続で指定されたプライマリ・キュー・マネージャがキューにアクセスできない場合に使用します。

DistributionList

このプロパティは、メッセージをエンキューするための配布リストの要素を指定するために使用します。

MessageSelector

このプロパティは、MQキューから取得する必要があるメッセージを指定します。ヘッダーとプロパティが選択条件に一致するメッセージのみを取得します。

AsAttachment

このプロパティは、trueに設定した場合、すべてのメッセージを添付として処理するようアダプタを設定します。

CharacterSet

このプロパティはオプションで、AsAttachmentプロパティをtrueに設定している場合にのみ指定します。添付のキャラクタ・セットを定義し、Oracle MQ Seriesアダプタがパブリッシュした添付を処理するサード・パーティ・アプリケーションで使用されます。

Encoding

このプロパティはオプションで、AsAttachmentプロパティをtrueに設定している場合にのみ指定します。添付のエンコーディングを定義し、Oracle MQ Seriesアダプタがパブリッシュした添付を処理するサード・パーティ・アプリケーションで使用されます。

ContentType

このプロパティはオプションで、AsAttachmentプロパティをtrueに設定している場合にのみ指定します。添付のコンテンツ・タイプを定義し、Oracle MQ Seriesアダプタがパブリッシュした添付を処理するサード・パーティ・アプリケーションで使用されます。

MaximumSegmentLength

このプロパティはオプションで、メッセージをカスタム・サイズにセグメント化する場合にのみ、値を指定する必要があります。値は、integerValue[M/K/B]の形式にする必要があります。Mはメガバイト、Kはキロバイト、Bはバイトを表します。たとえば、230K、4M、512Bなどです。

ServerHeartbeat

このプロパティは、MQキュー・マネージャが停止した場合、再接続を試行するまでにアダプタが待機する必要がある時間をミリ秒単位で定義します。

ExponentialBackOff

このプロパティは、MaxExponentialBackOffCountプロパティと組み合せて使用する必要があります。このプロパティ(秒単位)は、アダプタがキュー・マネージャに再接続を試行する場合の指数的に増加する時間間隔の基準となる値を定義します。たとえば、値が2の場合、アダプタは2秒、4秒、8秒、16秒の間隔で再接続を試行します。

MaxExponentialBackOffCount

このプロパティは、ExponentialBackOffプロパティと組み合せて使用する必要があります。このプロパティは、ExponentialBackOffの時間間隔を制限するために使用します。たとえば、ExponentialBackOffを2に設定し、MaxExponentialBackOffCountを7に設定した場合、アダプタは2、4、8、16、32、64、128、128、128…秒の間隔で再試行します。

UseDynamicResponseQueue

ブール・プロパティを使用して、永続的なReplyToQueueではなく動的なレスポンス・キューを使用する必要があるかどうかを指定できます。trueに設定する場合、ResponseModelQueueNameを指定する必要があります。

ResponseModelQueueName

モデル・キューの名前で、リプライ・メッセージを取得するために作成する必要がある動的なレスポンス・キューに基づいています。

ResponseWaitInterval

このプロパティは、リプライ・キューに到着するまでアダプタがレスポンス・メッセージを待つ待機間隔を指定します。

LimitHeaderLength

このプロパティは、MQヘッダー情報を削減するのに使用されます。このプロパティは、対応するMQアダプタのJCAファイルのoracle.tip.adapter.mq.inbound.ActivationSpecImplに追加することができます。デフォルト値はfalseです。

表A-17 Oracle MQ SeriesアダプタのJCAプロパティ: 正規化されたプロパティ

プロパティ

説明

jca.mqAccountingToken

インバウンド/アウトバウンド。メッセージのアカウンティング・トークン情報。16進数のエンコードされた文字列。

jca.mq.ApplIdentityData

インバウンド/アウトバウンド。メッセージまたはその発信元の識別情報に関する追加情報を提供します。任意の文字列を受け入れます。

jca.mq.ISpec.ResponseWaitInterval

アウトバウンド。リプライ・キューに到着するまでレスポンス・メッセージを待つ待機間隔。ミリ秒単位の整数値を受け入れます。

jca.mq.MQMD.ApplOriginData

インバウンド/アウトバウンド。このメッセージの発信元に関する追加情報を提供します。任意の文字列を受け入れます。

jca.mq.MQMD.BackoutCount

インバウンド/アウトバウンド。メッセージが作業ユニットの一部として以前にMQQueue.get()コールによって返された後、取り消された回数。ゼロおよび正の整数値を受け入れます。

jca.mq.MQMD.CorrelId

インバウンド/アウトバウンド。取得/蓄積するメッセージの相関識別子。16進数のエンコードされた文字列を受け入れます。

jca.mq.MQMD.Encoding.Decimal

インバウンド/アウトバウンド。アプリケーション・メッセージ・データ内の数値に使用される表現。NORMALとREVERSEDを受け入れます。

jca.mq.MQMD.Encoding.Float

インバウンド/アウトバウンド。アプリケーション・メッセージ・データ内の数値に使用される表現。NORMAL、REVERSEDおよびS390を受け入れます。

jca.mq.MQMD.Expiry

インバウンド/アウトバウンド。メッセージの有効期限が経過し、キュー・マネージャによる破棄の対象になっています。NEVERまたはInbound/Outbound.negative以外の整数値を受け入れます

jca.mq.MQMD.Feedback

インバウンド/アウトバウンド。レポートの性質を示すためにMQC.MQMT_REPORTタイプのメッセージで使用されます。任意の文字列を受け入れます。

jca.mq.MQMD.Feedback.ApplicationDefined

インバウンド/アウトバウンド。アプリケーション定義のフィードバック。任意の文字列を受け入れます。

jca.mq.MQMD.Format

インバウンド/アウトバウンド。受信者へのメッセージに含まれるデータの性質を示すために、メッセージの送信者が使用する名前の書式を設定します。受け入れる書式は、NONE、ADMIN、CHANNEL_COMPLETED、CICS、CMD1、CMD2、DEAD_LETTER_HDR、DIST_HDR、EVENT、IMS、IMS_VAR_STRING、MD_EXTN、PCF、REF_MSG_HDR、RF_HDR_1、RF_HDR_2、STRING、TRIGGER、WORK_INFO_HDR、XMIT_Q_HDRです。

jca.mq.MQMD.GroupId

インバウンド/アウトバウンド。物理メッセージが属するメッセージ・グループを識別するバイト文字列。16進数のエンコードされた文字列を受け入れます。

jca.mq.MQMD.MsgFlags.IsMsgInGroup

インバウンド/アウトバウンド。メッセージがグループに属するかどうかを指定します。true、falseを受け入れます。

jca.mq.MQMD.MsgFlags.IsLastMsgInGroup

インバウンド/アウトバウンド。メッセージがグループの最後のメッセージかどうかを指定します。true、falseを受け入れます

jca.mq.MQMD.MsgFlags.IsSegment

インバウンド/アウトバウンド。メッセージがセグメントかどうかを指定します。true、falseを受け入れます

jca.mq.MQMD.MsgFlags.IsLastSegment

インバウンド/アウトバウンド。メッセージが最後のセグメントかどうかを指定します。true、falseを受け入れます

jca.mq.MQMD.MsgId

インバウンド/アウトバウンド。取得/蓄積するメッセージのメッセージ識別子。16進数のエンコードされた文字列を受け入れます。

jca.mq.MQMD.MsgSeqNumber

インバウンド/アウトバウンド。グループ内の論理メッセージのシーケンス番号。Inbound/Outbound.negative以外の整数値を受け入れます

jca.mq.MQMD.MsgType

インバウンド/アウトバウンド。メッセージのタイプを示します。任意の文字列を受け入れます。

jca.mq.MQMD.MsgType.ApplicationDefined

インバウンド/アウトバウンド。アプリケーション定義のメッセージ・タイプ。任意の文字列を受け入れます。

jca.mq.MQMD.Offset

インバウンド/アウトバウンド。論理メッセージの先頭からの物理メッセージ内のデータのオフセット。Inbound/Outbound.Negative以外の整数値を受け入れます。

jca.mq.MQMD.OriginalLength

インバウンド/アウトバウンド。セグメント化されたメッセージの元の長さです。負以外の整数値Inbound/Outboundを受け入れます

jca.mq.MQMD.Persistence

インバウンド/アウトバウンド。メッセージの永続性。true、false、AS_Q_DEFを受け入れます。

jca.mq.MQMD.Priority

インバウンド/アウトバウンド。メッセージの優先度。0- Inbound/Outbound.9、AS_Q_DEFを受け入れます

jca.mq.MQMD.PutApplName

インバウンド/アウトバウンド。メッセージを蓄積するアプリケーションの名前。任意の文字列を受け入れます

jca.mq.MQMD.PutApplType

インバウンド/アウトバウンド。メッセージを蓄積するアプリケーションのタイプ。任意の文字列を受け入れます。

jca.mq.MQMD.PutApplType.UserDefined

インバウンド/アウトバウンド。ユーザー定義の蓄積アプリケーション・タイプ。任意の文字列を受け入れます。

jca.mq.MQMD.PutDateTime

インバウンド/アウトバウンド。メッセージが蓄積された日時。year:month:date、year:month:date:hour:minute、year:month:date:hour:minute:secondを受け入れます

jca.mq.MQMD.ReplyToQMgr

インバウンド/アウトバウンド。リプライまたはレポート・メッセージの送信先のキュー・マネージャの名前。任意の文字列を受け入れます。

jca.mq.MQMD.ReplyToQ

インバウンド/アウトバウンド。リプライまたはレポート・メッセージの送信先のキューの名前。任意の文字列を受け入れます

jca.mq.MQMD.Report.Generate.CorrelId

インバウンド/アウトバウンド。リプライまたはレポート・メッセージのCorrelationIdを生成するためのスキーム。PASS_CORREL_ID、COPY_MSG_IDを受け入れます

jca.mq.MQMD.Report.Generate.MsgId

インバウンド/アウトバウンド。リプライまたはレポート・メッセージのMessageIdを生成するためのスキーム。NEW_MSG_ID、PASS_MSG_IDを受け入れます

jca.mq.MQMD.Report.Generate.COA

インバウンド/アウトバウンド。COAレポートの内容を指定します。WITH_NO_DATA、WITH_PARTIAL_DATA、WITH_FULL_DATAを受け入れます

jca.mq.MQMD.Report.Generate.COD

インバウンド/アウトバウンド。CODレポートの内容を指定します。WITH_NO_DATA、WITH_PARTIAL_DATA、WITH_FULL_DATAを受け入れます

jca.mq.MQMD.Report.Generate.Exception

インバウンド/アウトバウンド。例外レポートの内容を指定します。WITH_NO_DATA、WITH_PARTIAL_DATA、WITH_FULL_DATAを受け入れます

jca.mq.MQMD.Report.Generate.Expiry

インバウンド/アウトバウンド。有効期限レポートの内容を指定します。WITH_NO_DATA、WITH_PARTIAL_DATA、WITH_FULL_DATAを受け入れます

jca.mq.MQMD.Report.Generate.NAN

インバウンド/アウトバウンド。着信/発信メッセージがNANかどうかを指定します。true、falseを受け入れます

jca.mq.MQMD.Report.Generate.PAN

インバウンド/アウトバウンド。着信/発信メッセージがPANかどうかを指定します。true、falseを受け入れます

jca.mq.MQMD.Report.TakeAction.OnMsgDeliveryFailure

インバウンド/アウトバウンド。

jca.mq.MQMD.Report.TakeAction.OnMsgDeliveryFailure

DISCARD、DEADLETTERQUEUEを受け入れます

jca.mq.MQMD.StrucId

インバウンド/アウトバウンド。MQMDの構造体ID。任意の文字列を受け入れます

jca.mq.MQMD.UserIdentifier

インバウンド/アウトバウンド。このメッセージの発信元のユーザー。任意の文字列を受け入れます。

jca.mq.MQMD.Version

インバウンド/アウトバウンド。MQMDのバージョン。VERSION_1、VERSION_2を受け入れます

jca.mq.Inbound.MQMD.CorrelId

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージの相関識別子。16進数のエンコードされた文字列を受け入れます。

jca.mq.Inbound.MQMD.MsgId

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージのメッセージ識別子。16進数のエンコードされた文字列を受け入れます。

jca.mq.Inbound.MQMD.MsgType

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージのメッセージ・タイプ。任意の文字列を受け入れます。

jca.mq.Inbound.MQMD.Nan

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージのNANレポート・オプション。true、falseを受け入れます

jca.mq.Inbound.MQMD.Pan

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージのPANレポート・オプション。true、falseを受け入れます

jca.mq.Inbound.MQMD.ReplyToQMgr

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージのReplyToQueueManager。任意の文字列を受け入れます。

jca.mq.Inbound.MQMD.ReplyToQ

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージのReplyToQueue。任意の文字列を受け入れます。

jca.mq.Inbound.MQMD.Report.Generate.CorrelId

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージのCorrelationId生成用の相関スキーム。PASS_CORREL_ID、COPY_MSG_IDを受け入れます

jca.mq.Inbound.MQMD.Report.Generate.MsgId

アウトバウンド。非同期リクエスト-リプライ・シナリオで取得されたメッセージのMessageId生成用の相関スキーム。NEW_MSG_ID、PASS_MSG_IDを受け入れます

jca.mq.ISpec.EnqueueMsgToQMgr

アウトバウンド。アウトバウンド・キューのキュー・マネージャ。任意の文字列を受け入れます

jca.mq.ISpec.EnqueueMsgToQ

アウトバウンド。アウトバウンド・キューのキュー名。任意の文字列を受け入れます。

表A-18 Oracle MQ Seriesアダプタの接続プロパティ

プロパティ

説明

HostNam

ホスト・コンピュータの名前。

PortNumber

使用するポート番号。

ChannelName

このプロパティには、使用するサーバー接続チャネルを設定します。

QueueManagerName

有効なキュー・マネージャ名。

CipherSuite

CipherSuiteは、SVRCONNチャネルで設定されているCipherSpecと一致する名前に設定します。NULL(デフォルト)に設定すると、SSL暗号化は実行されません。

ClientEncoding

クライアントで使用するキャラクタ・エンコーディング。

ConnectionFactoryLocation

コネクション・ファクトリの場所。

HostOSType

ホスト・コンピュータで使用されるオペレーティング・システム。

KeyStoreAlgorithm

キーストアで使用されるアルゴリズム。

KeyStoreLocation

この値は、Oracle MQ Seriesアダプタが秘密鍵を格納するキーストアです。これは、アダプタがMQ Seriesサーバーから認証を受ける場合に必要になります。

KeyStorePassword

この値は、キーストアへのアクセスに必要なパスワードです。

KeyStoreProviderName

キーストア・プロバイダの名前。

TrustStoreLocation

これは、アダプタが信頼できる証明書情報を格納する場所です。この情報は、アダプタがMQ Seriesサーバーから認証を受ける場合に必要になります。

TrustStorePassword

このプロパティは、トラスト・ストアの場所のパスワードを指定します。

KeyStoreType

このプロパティは、キーストアのタイプを指定します。

Protocol

キー管理のアルゴリズム。

SSLPeerName

識別名パターン。CipherSuiteが設定されている場合、この変数を使用することによって、常に正しいキュー・マネージャが使用されるようにできます。NULL(デフォルト)に設定すると、キュー・マネージャの識別名はチェックされません。sslCipherSuiteがNULLの場合は、この変数は無視されます。

SSLEnable

このプロパティのtrueまたはfalse値は、Oracle MQ SeriesアダプタでのSSL有効化またはSSL無効化を示します。

UserID

このプロパティは、資格証明マッピングが設定されていない場合に使用されます。

Password

キュー・マネージャに接続するためのパスワードです。このプロパティは、資格証明マッピングが設定されていない場合に使用されます。

XATransaction

このプロパティは、XAトランザクションを有効化または無効化するために使用します。trueに設定すると、XAトランザクションは有効になります。

ReceiveExit

これは、特定のキューでメッセージを受信するとトリガーされるReceive Exit Javaクラスです。

SecurityExit

これは、キュー・マネージャへの接続が試行されたときに発生するセキュリティ・フローをカスタマイズできるSecurity Exit Javaクラスです。

SendExit

これは、特定のキューへメッセージを送信するとトリガーされるSend Exit Javaクラスです。

CCDTurl

この値は、クライアント接続の詳細を指定するためにMQ Seriesアダプタで使用する必要があるCCDTファイルへのパスです。

KeyStoreName

指定のストライプの下のキーストアの名前。KeyStoreTypeをkssに設定する場合に使用します。

StripeNameForKeyStore

キーストアが作成されるストライプの名前。KeyStoreTypeをkssに設定する場合に使用します。

StripeNameForTrustStore

トラスト・ストアが作成されるストライプの名前。TrustStoreTypeをkssに設定する場合に使用します。

TrustStoreAlgorithm

トラスト・ストアで使用されるアルゴリズム。

TrustStoreName

指定のストライプの下のトラスト・ストアの名前。TrustStoreTypeをkssに設定する場合に使用します。

TrustStoreProviderName

トラスト・ストア・プロバイダの名前。

TrustStoreType

このプロパティは、トラスト・ストアのタイプを指定します。

表A-19 Oracle MQ Seriesアダプタのバインディング・プロパティ

プロパティ

説明

adapter.mq.inbound.queueName

このプロパティは、インバウンドMQキューのキュー・マネージャを指定するために使用します。

adapter.mq.inbound.binaryNulls

このプロパティは、バイナリ0(ゼロ)値によるメッセージのデキューに使用します。このプロパティのデフォルト値はtrueです。

A.7 LDAPアダプタのプロパティ

この項では、LDAPアダプタに適用可能なプロパティについて説明します。

- 表A-20

- 表A-21

表A-20 LDAPアダプタの接続プロパティ

プロパティ

指定できる値

説明

HostName

ホスト・マシンの名前またはIPアドレス。

LDAPサーバーをホストするマシン。

BindDN

Cn=admin

InboundDataSource

RCUスキーマがインストールされているJDBCデータソースのJNDI。このデータ・ストアは、最後の変更番号を永続化するために使用されます。このプロパティ値は、最新の増分同期シナリオに役立ちます。(LDAPアダプタをインバウンド方向で使用する必要がある場合に必要です)。

有効なXAデータソースを指すJNDI文字列の場所。

OperationTimeout

操作のタイムアウトを設定します。レスポンスがタイムアウト期間にディレクトリ・サーバーで受信されない場合、操作は中止され、例外が発生します。

Password

機密

不要

SecurityProvider

SSLContextProtocol

キー管理のプロトコル(不要)。

TrustAll

False

指定した場合、クライアントはサーバーが付与する証明書を盲目的に信頼します。useSSLまたはstartTLSを選択する場合にのみ必要です。

TrustStoreProviderName

JSSEプロバイダの名前。

P

整数値

LDAPサービスがホストで実行されているポート。

UseSSL

True/False(デフォルト値はfalse)。

LDAPアダプタがSSLを使用してディレクトリ・サーバーとの通信を保護していることを示します。SSLモードでリスニングするようにサーバーを構成する必要があり、ポート引数の値はサーバーがSSLベース接続をリスニングする場合の値である必要があります。

UseStartTLS

True/False(デフォルト値はfalse)。useSSLがtrueの場合は、falseにする必要があります。

Start TLS拡張操作を使用して、暗号化されていないチャネルでのディレクトリ・サーバーとの通信を保護します。この場合のポートは、クリアテキストのLDAP接続をリスニングします。

TrustAll

True/false(デフォルト値はfalse)。

指定した場合、クライアントはサーバーが付与する証明書を盲目的に信頼します。このオプションを選択すると、TrustStorePathは冗長なため無視されます。

TrustStorePath

useSSLまたはuseStartTLSのいずれかをtrueに設定する場合に、指定する必要があります。

クライアントがサーバー認証に使用するJKSトラスト・ストア・ファイルへのパスを指定します。

TrustStorePassword

トラスト・ストアのコンテンツにアクセスするために必要なパスワードを指定します。通常、トラスト・ストア・パスワードは必要ありません。これはトラスト・ストア・パスワード・ファイルのオプションと一緒には使用できません。

Protocol

ディレクトリ・サーバーとのセキュアな接続のためにプロトコル・バージョンを有効に設定します。プロトコルは、SSLコンテキストでサポートされる必要があります。

EnableCipherSuites

文字列。サーバーのJVMによって提供されるSSL暗号スイートのデフォルト・セットを使用します。JSSEプロバイダによって許可されるカンマ区切りの暗号スイートのリスト。

SSLまたはStartTLS通信で使用できるSSL暗号スイートの名前を指定します。

次の表に、LDAPアダプタのバインディング・プロパティを示します。JCAプロパティの一部は複数の操作に適用可能です。たとえば、TimeLimitはEntryChangeNotification、ChangelogNotificationまたは検索操作で使用できます。ただし、同じプロパティは、これらの操作で同じ意味になります。

表A-21 LDAPアダプタのバインディング・プロパティ(すべてのアダプタで共通)

プロパティ名

指定できる値

説明

Jca.retry.count

拒否までの最大再試行回数を示します。

Jca.retry.interval

秒単位

再試行の時間間隔を示します。

Jca.retry.backoff

正の整数

再試行間隔の増分ファクタを示します。

Jca.retry.maxInterval

再試行間隔の最大値を示します。

Jca.retry.maxPeriod

すべての再試行の累計期間の上限(ハード・リミット)です。

Jca.retry.count

拒否までの最大再試行回数を示します。

Jca.retry.interval

秒単位

再試行の時間間隔を示します。

Jca.retry.backoff

正の整数

再試行間隔の増分ファクタを示します。

Jca.retry.maxInterval

再試行間隔の最大値を示します。

Jca.retry.count

拒否までの最大再試行回数を示します。

表A-22 エントリ変更通知に対するLDAPアダプタのJCAアーティファクト

プロパティ名

指定できる値

説明

BaseDN

イベントをレポートする有効なDN。

このエントリのイベントを通知します。

EventScope

次の値で制限される文字列: {"baseObject"、"singleLevel"、"subordinates"、"wholeSubtree"}

構成済ベースDNのイベント・ソースのスコープ。

EventType

不明なマクロの値:

{"add"、"modify"、"all"}

{"add"、"modify"、"all"}

すべて選択すると、すべてのイベントがパブリッシュされます。

SearchFilter

LDAPフィルタの有効な文字列表現。

拡張フィルタ条件。特定のフィルタ条件を満たすイベントのみがアダプタによってパブリッシュされます。

ReturnAttributes

イベントの一部として戻されるすべての属性のcsvリスト。

-

ReturnAttributesDelimiter

文字列

デフォルトのデリミタ「,」が適切でない場合、属性デリミタを明示的に定義できます。

TypesOnly

trueまたはfalse(デフォルト値はfalse)。

trueに設定すると、属性名のみが戻されます。それ以外の場合は、属性名と値の両方が戻されます。

SizeLimit

正の整数。デフォルト値は1000。<= 0はsizeLimitが適用されないことを意味します。

検索操作の一部として戻されるエントリの最大数。DS側でも構成できます。2つの値のうち低い値が有効になります。SizeLimitは単一のページ内で施行されます。

PageSize

pageSizeを指定する整数値。sizeLimitはページ内のサイズを示し、検索時にすべてのページで戻されるエントリの合計数とは関係ありません。デフォルト値は-1で、無制限のpageSizeを意味します。

1ページに公開されるイベントの最大数。

TimeLimit

整数値(秒数) (デフォルト値は10秒)。

結果を戻すまでにサーバーが待機する最大時間。

NotificationStrategy

文字列値(TimeStampBasedのいずれか)。

永続検索オプションは、最初のリリースでは非推奨です。

PollingInterval

整数値(デフォルト値は10秒)。

新しいイベントの次の検索を実行するまでのポーリング間隔。

表A-23 変更ログ通知に対するLDAPアダプタのJCAアーティファクト

プロパティ名

指定できる値

説明

PollingInterval

整数値(デフォルト値は10秒)。

新しいイベントの次の検索を実行するまでのポーリング間隔。

EventType

不明なマクロの値:

不明なマクロ: {"add"、"delete"、"modify"、"moddn"、"all"}

eventTypeの値は、ディレクトリ・サーバーの実装によって変わります。たとえば、OIDの場合、moddnはmodrdnになることがあります。

すべてを選択すると、すべてのイベントがパブリッシュされます。それ以外の場合は、パブリッシュするイベント・タイプのカンマ区切りリストが送信されます。たとえば、add,deleteです。

NotificationStrategy

不明なマクロの文字列値: {"OJD"、"OID"またはユーザー定義のchangelog実装の完全修飾名}

不明なマクロ: {"OJD"、"OID"またはユーザー定義のchangelog実装の完全修飾名}

Oracle.tip.adapter.ldap.inbound.<customStrategy Impl>。

TimeLimit

整数値(秒数) (デフォルト値は0で時間無制限)。

結果を戻すまでにサーバーが待機する最大時間。

SizeLimit

整数値で、デフォルト値は1000です。

1つのトリップでパブリッシュされるイベントの最大数。

PageSize

pageSizeを指定する整数値。sizeLimitはページ内を示し、検索時にすべてのページで戻されるエントリの合計数とは関係ありません。

-

表A-24 検索操作に対するLDAPアダプタのJCAアーティファクト

プロパティ名

指定できる値

説明

SearchScope

次の値で制限される文字列。{"baseObject"、"singleLevel"、"subordinates"、"wholeSubtree"}: SubordinatesはLDAP仕様の一部ではなく、選択したDSによってのみサポートされます。このオプションを使用する前に、DSサーバーを確認してください。

検索スコープを定義します。これは、悪質な検索リクエストによるサーバー・リソースの操作を制御するために、サービスのデプロイ時に定義する必要があります。

AliasDereferencing

次の値で制限される文字列。

不明なマクロ: {"never"、"search"、"find"、"always"}

検索の処理中に別名エントリを処理する動作。

FollowReferrals

次の値で制限される文字列。

不明なマクロ: {"ignore"、"throwException"、"follow"}

LDAPアダプタは、従うか例外をスローするよう明示的に指定された場合を除き、デフォルトではすべてのリフェラル候補を無視します。

追加エントリを検索リクエストの一部として検索/照合できる代替場所。

HopLimit

正の整数。デフォルト値は1です。

検索リフェラルに参加する代替場所の数。

SizeLimit

整数値(デフォルト値は1000)。

検索操作の一部として戻されるエントリの最大数。DS側でも構成できます。2つの値のうち低い値が有効になります。

TimeLimit

整数値(秒数) (デフォルト値は0で時間無制限)。

結果を戻すまでにサーバーが待機する最大時間(秒)。

TypesOnly

trueまたはfalse(デフォルト値はfalse)。

trueに設定すると、属性名のみが戻されます。それ以外の場合は、属性名と値の両方が戻されます。

ReturnAttributes

文字列値、この検索レスポンスの一部として戻される必要があるすべての属性の区切りリスト。

デフォルトのデリミタは「,」です。

名前属性のみが検索レスポンスの一部として含まれます。

ReturnAttributesDelimiter

文字列

デフォルトのデリミタ「,」が適切でない場合、属性デリミタを明示的に定義できます。

表A-25 LDAPアダプタのDSML JCAアーティファクト

プロパティ名

指定できる値

説明

MaxDSMLRequestSize

整数値(デフォルト値は0で無制限)。

DSMLには、バッチ・リクエストが含まれています。このバッチ・リクエストには、何百万のLDAP操作リクエストが含まれている可能性があります。このプロパティを使用して、単一のDSMLバッチ・リクエストを介してLDAPアダプタに渡すことができる許容される操作リクエストの最大数を制御します。

表A-26 LDAPアダプタの削除操作のJCAアーティファクト

プロパティ

指定できる値

説明

RequestControls

文字列

操作とともに1つまたは複数のコントロールに渡します。

SuppressEntryDoesNotExist

True|false

削除するエントリがターゲットDSに存在しない場合、削除操作は失敗します。相互作用の仕様でこの条件を指定すると、例外を抑止できます。

表A-27 LDAPアダプタの追加操作のJCAアーティファクト

プロパティ

指定できる値

説明

SuppressEntryAlreadyExists

True|false

追加するエントリがターゲットDSにすでに存在する場合、追加操作は失敗します。相互作用の仕様でこのプロパティを指定すると、例外を抑止できます。

objectClass

CSV文字列

ターゲット・ディレクトリ・サーバーで追加するエントリの構造を構成するすべてのobjectClassのカンマ区切りリスト。

表A-28 LDAPアダプタの変更操作のJCAアーティファクト

プロパティ

指定できる値

説明

RequestControls

文字列

操作とともに1つまたは複数のコントロールに渡します。

表A-29 LDAPアダプタのDNの変更操作のJCAアーティファクト

プロパティ

指定できる値

説明

RequestControls

文字列

操作とともに1つまたは複数のコントロールに渡します。

DeleteOldRDN

trueまたはfalse(デフォルト値はfalse)

-

A.8 コヒーレンス・アダプタのプロパティ

この項では、コヒーレンス・アダプタのプロパティを示します。

- 表A-30

- 表A-31

- 表A-32

次の表に、コヒーレンス・アダプタのJCAプロパティを示します。

表A-30 コヒーレンス・アダプタのJCAプロパティ

プロパティ

説明

デフォルト値

CacheName

特定の操作に使用する特定のCoherenceキャッシュを識別します。コヒーレンス・アダプタ操作のCacheNameエントリで指定されたキャッシュが存在しない場合、再試行不可エラーが発生します。

なし

Key

キャッシュ・エントリの識別子。

なし

KeyType

キーとして使用する値のJavaタイプを識別します(現在はjava.langパッケージの単純型)。

なし

ValueType

キャッシュに格納するオブジェクトまたはキャッシュから取得するオブジェクトを識別する完全修飾クラス名。XMLをキャッシュに格納するよう指示する場合、ValueTypeプロパティを指定する必要はありません。指定しない場合、コヒーレンス・アダプタはペイロードをバイナリXML表現に変換し、キャッシュに格納するか、キャッシュから取得します。

なし

Filter

操作を適用する必要があるキャッシュのサブセットを指定するために使用します。フィルタ式はCohQLに基づいており、バインド変数の使用をサポートします。

なし

PageSize

問合せ操作を実行したときに返される項目の数を指定します。リモート・キャッシュに関連するキャッシュ操作にのみ適用可能です。

なし

TimeToLive

キャッシュ・エントリが期限切れになるまでのミリ秒。非トランザクション・キャッシュに関連するキャッシュ操作にのみ適用可能です。

EXPIRY_NEVER

IndexName

キャッシュに追加する索引の名前。Book (author.firstName、author.LastName、price)オブジェクトを格納するキャッシュのprice属性に索引を作成するには、IndexNameの値をpriceに設定する必要があります。firstName属性の索引の場合、IndexNameをauthor.firstNameに設定する必要があります。

なし

Ordered

索引を作成した情報の内容を並べ替えるかどうかを指定するブール。

False

MappingsMetadataFile

POJOからXMLへの変換で役立つメタデータ・マッピング・ファイルの名前を示します。XMLからPOJOへの変換も同様です。

なし

CacheOperation

CacheNameで識別されたキャッシュで実行される操作。CacheOperationでサポートされる値はget、put、queryおよびremoveです。

なし

ReturnCacheKeysOnly

問合せ操作を実行したときに、キャッシュ識別子(キー)のみを返すことができるブール。

False

次の表に、コヒーレンス・アダプタの正規化されたプロパティを示します。

表A-31 コヒーレンス・アダプタの正規化されたプロパティ

プロパティ

説明

jca.coherence.CacheName

Coherence操作に使用するキャッシュの名前。これにより、CoherenceInteractionSpecのCacheNameがオーバーライドされます。

jca.coherence.Key

キャッシュ・エントリを識別します。これにより、CoherenceInteractionSpecのKeyがオーバーライドされます。

jca.coherence.Filter

Coherence操作を実行するときに使用するフィルタを指定します。これにより、CoherenceInteractionSpecのFilterがオーバーライドされます。

次の表に、コヒーレンス・アダプタのコネクション・ファクトリ・プロパティを示します。

表A-32 コヒーレンス・アダプタのコネクション・ファクトリ・プロパティ

名前

説明

値

ConnectionFactoryLocation

coherence-transaction.rarが提供するコネクション・ファクトリのJNDI名を指定します。

tangosol.coherenceTx

ServiceName

接続に関連付けられているキャッシュ・サービスの名前。ServiceNameはTransactionalCachesにのみ必要です。非トランザクション/拡張には不要です。

XATransactionalCache (XA)

TransactionalCache (ローカル・キャッシュ)

リモート・キャッシュの場合は空白のまま

CacheConfigLocation

キャッシュおよび拡張クライアントの設定を定義するキャッシュ構成ファイルの場所。

-

ClassLoaderMode

キャッシュ操作に使用するクラス・ローダーが、コンポジットにバンドルされているドメイン・クラスに基づいているのか、JCA管理コネクション・ファクトリのPojoJarFileプロパティに基づいているのかを指定します。

値はCUSTOMまたはCOMPONENTです。

CUSTOMの場合、アソシエーションはPojoJarFileプロパティに基づきます。COMPONENTの場合、コンポジットにバンドルされているドメイン・クラスに基づきます。

CUSTOMは、コンポジットの境界を越えて、または異なるOSBプロセスから、同じキャッシュを使用する必要がある場合に使用します。COMPONENTは、すべてのキャッシュ操作が同じコンポジットまたはOSBプロセスに組み込まれている場合に使用します。

CUSTOM

WLSExtendProxy

拡張プロキシがスタンドアロンかWLSサーバーの一部として動作するのかを指定します。falseの場合はスタンドアロン拡張プロキシで、そうでない場合はスタンドアロン拡張プロキシではありません。リモートの場合にのみ適用できます。

True

PojoJarFile

キャッシュ操作に使用するドメイン・クラスの場所を指定します。

-

A.9 MSMQ JCAアダプタのプロパティ

この項では、MSMQ JCAアダプタのプロパティについて説明します。

- 表A-33

- 表A-34

- 表A-35

- 表A-36

表A-33 MSMQアダプタのJCAプロパティ

プロパティ

説明

デフォルト値

必須

DestinationType

パブリック・キュー、プライベート・キューまたは配布リストの名前で識別したキューのグループにメッセージを送信するかどうかを示します。値は次のとおりです。

PUBLIC_QUEUE

PRIVATE_QUEUE

DISTRIBUTION_LIST

なし

はい

DestinationName

MSMQキューの名前。

なし

はい(UseActiveDirectoryPathがFalseの場合)

DestinationPath

ActiveDirectoryで表されるDistributionListキューまたはPublicキューを識別する文字列。文字列の例を次に示します。

LDAP://MyLDAPServer/CN=MyQueue,CN=msmq,CN=MyComputer,CN=Computers,DC=MyDomain,DC=MyCompany,DC=COM

なし

はい(UseActiveDirectoryPathがTrueの場合)

UseActiveDirectoryPath

パブリック・キューの識別に、キュー名ではなくActive Directoryパスを使用することを許可するブール。このプロパティは、DestinationTypeがDISTRIBUTION_LISTまたはPUBLIC_QUEUEである場合に適用可能です

False

アウトバウンド(エンキュー)操作にのみ適用可能です。このプロパティは、インバウンド(デキュー)には適用できません。デキューは、配布リストではサポートされていません。

UseDirectFormatName

パブリックおよびプライベートのキューに直接フォーマット名を使用することを許可するブール。

False

-

Priority

優先度は7から0までの任意の整数値に設定できます(デフォルトは3)。7は高い優先度を意味します。0は最も低い優先度を意味します。最高優先度は、処理がより高速であることを意味します。アウトバウンド・エンキューにのみ適用可能です。

3

-

TimeToLive

このプロパティは、ターゲット・キューからメッセージを取得する時間制限(秒)を指定します。値は、指定したMSMQメッセージのMaxTimeToReceiveプロパティに割り当てられます。インバウンドおよびアウトバウンド・キューに適用可能です。

-1 (無限)。メッセージが期限切れにならないことを意味します。

-

Delivery

このプロパティは、式(非永続)またはリカバリ可能なメッセージング(永続)の指定に使用します。高速メッセージングでは、スループットが高速になります。リカバリ可能なメッセージングにより、メッセージがキューに送信される途中でコンピュータがクラッシュしてもメッセージが配信されることが保証されます。値はPersistent、Non-Persistentで、アウトバウンド・エンキューにのみ適用可能です。

Persistent

-

OperationType

実行する操作。サポートされるOperationTypeの値は、enqueueおよびdequeueです。

なし

はい

BodyType

値は、String (デフォルト)およびByteArrayです。不透明(スキーマ)処理オプションが選択されている場合は、ByteArrayのBodyType値を意味します。

文字列

はい

EnableStreaming

ペイロードのストリームを可能にするブール。インバウンド・デキュー・プロセスにのみ適用可能です。

False

-

次の表に、MSMQアダプタの正規化されたプロパティを示します。

表A-34 MSMQアダプタの正規化されたプロパティ

プロパティ名

説明

方向

jca.msmq.message.SentTime

このプロパティは、メッセージが送信されたときを示します。

インバウンド

jca.msmq.message.Priority

このプロパティは、メッセージの優先度を指定します。これにより、MSMQInteractionSpecのPriorityがオーバーライドされます。

インバウンド/アウトバウンド

jca.msmq.message.TimeToLive

このプロパティは、ターゲット・キューからメッセージを取得する時間制限(秒)を指定します。これにより、MSMQInteractionSpecのTimeToLiveがオーバーライドされます。

インバウンド/アウトバウンド

jca.msmq.message.MaxTimeToReachQueue

このプロパティは、メッセージがキューに到達する時間制限(秒)を指定します。ここで何も指定しない場合、メッセージ・キューイングでは、キューへの到達時間間隔に企業全体の設定が使用されます。

インバウンド/アウトバウンド

jca.msmq.message.Id

MSMQにより生成されたメッセージ識別子を使用して、メッセージを識別します。

インバウンド

jca.msmq.message.Delivery

値はPersistentまたはNon Persistentになります。このプロパティは、メッセージ・キューイングがメッセージを配信する方法を指定します。このプロパティにより、MSMQInteractionSpecのDeliveryがオーバーライドされます。

インバウンド/アウトバウンド

jca.msmq.message.BodyLength

このプロパティは、メッセージ本文の長さ(バイト)を指定します。

インバウンド

jca.msmq.message.ArrivedTime

このプロパティは、メッセージがキューに到達したときを示します。

インバウンド

次の表に、MSMQアダプタのバインディング・プロパティを示します。

表A-35 MSMQアダプタのバインディング・プロパティ

プロパティ名

説明

adapter.msmq.receive.timeout

次のポーリング・サイクルを開始する前にメッセージ・キューイングがメッセージの到着を待機する時間(ミリ秒)。デフォルト値は1秒(1)です。

adapter.msmq.dequeue.threads

エンドポイント・アクティブ化が発生するときに初期化されるポーラー・スレッドの数。指定する場合、adapter.msmq.dequeue.threadsの値を使用して、複数のインバウンド・ポーラー・スレッドを生成します。パフォーマンスを向上させるために、複数のインバウンド・スレッドを使用できます。デフォルト値は1です。

次の表に、MSMQアダプタのコネクション・ファクトリ・プロパティを示します。

表A-36 MSMQアダプタのコネクション・ファクトリ・プロパティ

プロパティ名

説明

デフォルト

Host

MSMQホストのIPアドレス。

この値はホスト名で、ホスト・プロパティの値としてIPアドレスを指定できます。

AccessMode

接続ファクトリがネイティブ・アクセスを許可するかどうかを識別します。値は[Native | DCOM]です。Nativeの場合、Oracle WebLogic ServerはMSMQと同じホストにインストールされている必要があります。

DCOM

TransactionMode

メッセージを送信および受信する場合に接続がトランザクションに参加するかどうかを示します。値は[Single|None]です。Singleの場合、メッセージの送信先となるローカルおよびリモートのMSMQキューはトランザクションである必要があります。Singleの場合、メッセージを取得するローカルのMSMQキューはTransactionalである必要があります。Noneで、メッセージ送信先のキューがトランザクションの場合は、ResourceExceptionが発生します。

None

User

ユーザーを識別します

-

Password

指定したユーザーのパスワード。

-

Domain

MSMQホストのドメイン。

-

A.10 UMS JCAアダプタのプロパティ

この項では、UMSアダプタに適用可能なプロパティについて説明します。

- 表A-37

- 表A-38

- 表A-39

- 表A-40

- 表A-41

次の表に、UMSアダプタのアクティブ化仕様プロパティを示します。

表A-37 UMSアダプタのアクティブ化仕様プロパティ

プロパティ名

説明

JavaCalloutImpl

メッセージ・フィルタまたはその他のチェックにカスタム・ロジックを定義するJavaクラス名。このクラスは、ICustomCalloutインタフェースの具体的な実装です。

Name-InboundThreadCount

インバウンド・ポーラーまたはリスナー・スレッドの数を指定します。

ConsumeMode

アダプタによってUMSからメッセージを受信する方法を指定します。ポーリング・モードではポーラーに設定され、リスナー・モードではリスナーに設定されます。

To

受信メッセージの受信元となるアドレス。電子メール配信タイプにおける1つまたは複数のカンマ区切り電子メール・アドレスです。

DeliveryType

送信メッセージの受信および送信用に電子メール・サポートを提供します。

PollingInterval

ポーラー・コンシューム・モードでのポーリング間隔(秒)です。

MessageFilters

1つまたは複数のメッセージ・フィルタが指定されます。単一フィルタの場合は、フィールド・タイプおよび取得されるアクション(同意または拒否)に対して受信メッセージを適合させるため、Javaのパターン文字列で構成されます。

次の表では、UMSアダプタの相互作用仕様プロパティについて説明します。

表A-38 UMSアダプタの相互作用仕様プロパティ

プロパティ名

説明

DeliveryType

送信メッセージの受信および送信のみに対する電子メール・サポート。

Subject

送信メッセージの件名。

From

送信メッセージの送信者アドレス。

To

1つまたは複数の受信者アドレス。

Replyto

返信先アドレス

Cc

電子メール配信の1つまたは複数のCCアドレス。

Bcc

電子メール配信の1つまたは複数のBccアドレス。

SendEmailAsAttachment

添付ファイルとして電子メールを送信するにはTrueにします。

次の表では、UMSアダプタのメッセージ・ヘッダーについて説明します。

表A-39 UMSアダプタのメッセージ・ヘッダー

ヘッダー・フィールド名

最小発生数

最大発生数

マップされたアダプタのヘッダー・フィールド名

Return-path

0

1

jca.ums.return-path

Received

0

無制限

jca.ums.received

Resent-Date

0

無制限

jca.ums.resent-date

Resent-From

0

無制限

jca.ums.resent-from

Resent-Sender

0

1

jca.ums.resent-sender

Resent-To

0

無制限

jca.ums.resent-to

Resent-Cc

0

無制限

jca.ums.resent-cc

Resent-Bcc

0

無制限

jca.ums.resent-bcc

Resent-Message-ID

0

無制限

jca.ums.resent-message-id

Date

1

1

jca.ums.date

From

1

1

jca.ums.from (SMSおよびIMにも適用)

Sender

0

1

jca.ums.sender

Reply-to

0

1

jca.ums.reply-to

To

0

1

jca.ums.to (SMSおよびIMチャネルに適用可能)

Cc

0

1

jca.ums.cc

Bcc

0

1

jca.ums.bcc

Message-ID

0

1

jca.ums.message-id

In-Reply-To

0

1

jca.ums.in-reply-to

References

0

1

jca.ums.references

Subject

0

1

jca.ums.subject (SMSチャネルに適用可能)

Comments

0

無制限

jca.ums.comments

Keywords

0

無制限

jca.ums.keywords

次の表では、UMSアダプタのMIMEパート・メッセージ・ヘッダーについて説明します。

表A-40 UMSアダプタのMIMEパート・メッセージ・ヘッダー

ヘッダー・フィールド名

マップされたアダプタのヘッダー・フィールド名

ノート

Content-Type

jca.ums.msg.content-type

すべてのチャネルに適用可能です。SMSおよびIMの場合、現在サポートされているタイプはtext/plainのみです。ボイスの場合はtext/vxml、text/x-vxmlです。

Content-Transfer-Encoding

jca.ums.msg.content- transfer-encoding

-

Content-ID

jca.ums.msg.content-id

-

Content-Description

jca.ums.msg.content- description

-

Content-Disposition

jca.ums.msg.content- disposition

-

Content-Language

jca.ums.msg.content-language

-

Mime-Extension-field

jca.ums.mime-extension-headers

その他のMIMEヘッダー・フィールドは、文字列のContent-で開始されます。次のように2つ以上のヘッダーを追加できます。Content-* : value CRLF Content*- : value

CRLF - \r\n

MIME-Version

jca.ums.mime-version

-

次の表では、UMSアダプタ固有のヘッダーについて説明します。

表A-41 UMSアダプタ固有のヘッダー

ヘッダー名

説明

jca.ums.msg.proprietary-headers

2つ以上の固有のヘッダーを次の書式で追加できます。

Header Name : value CRLF Header Name : value

(ヘッダー名は、ums.adapter.xxxxxのCRLF - \r\nに類似させる必要があります。)

A.11 Oracle JCAアダプタの汎用プロパティ

この項では、すべての適用可能な次のプロパティについて説明します。

- 表A-42

それぞれの固有のプロパティについては、次を参照してください。

- プロパティ

- プロパティ

- プロパティ

- プロパティ

- プロパティ

- プロパティ

表A-42 すべてのJCAプロパティ

プロパティ

説明

WsdlLocation

タイプがxs:stringのオプションのadapter-config属性。

アダプタのJCAファイルに関連付けられたWSDLの名前に設定した場合は、JCAファイルおよび関連するWSDLとスキーマのバルク・インポートを実行できるように、Oracle Service BusによってWSDLが自動的に解決されます。

次の例は、adapter-config属性wsdlLocationが対応するWSDLファイルFulFillmentBatch.wsdlの名前に設定されたFulfillmentBatch_jms.jcaファイルを示します。

<adapter-config name="FulfillmentBatch" adapter="Jms Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata" wsdlLocation="FulfillmentBatch.wsdl" >
...
</adapter-config>

A.12 Oracleアダプタの汎用バインディング・プロパティ

この項では、すべての適用可能な次のプロパティについて説明します。

- 表A-43

それぞれの固有のプロパティについては、次を参照してください。

- プロパティ

- プロパティ

- プロパティ

- プロパティ

- プロパティ

- プロパティ

表A-43 すべてのバインディング・プロパティ

プロパティ

説明

UseWorkManager

デフォルトはFalseです。現在アダプタで使用しているデフォルト・ワーク・マネージャではなく、カスタム・ワーク・マネージャを指定します。バインディング・プロパティuseWorkManagerを使用して、特定のWebLogic WorkManagerを使用するようにインバウンドJCAエンドポイント(SCAサービス・エンドポイント)を構成できます。JCAバインディングは、コンストラクタでワーク・マネージャを受け入れるSOAインフラストラクチャ・エグゼキュータにWorkManagerの名前を委任します。useWorkManagerプロパティに入力する値は、name部分のみにする必要があります。残りは追加されます。たとえば、名前はfileReadのようになります。このJNDIルックアップが失敗すると、SOAエグゼキュータは、ワーク・マネージャを指定していない場合に通常使用される、デフォルトのSOAワーク・マネージャに戻ります。

MinimumDelayBetweenMessages

デフォルトは、Falseまたは遅延なしです。インバウンドのみです。このプロパティは、ミリ秒単位で構成されます。ダウンストリーム・コンポジット・アプリケーションにポストされている2つの連続したメッセージ間で少なくともMILLI_SECONDSの遅延が発生することを確認します。

アダプタ・ポーリング・スレッドごとにminimumDelayBetweenMessagesが有効であることに注意してください。複数のアダプタ・ポーリング・スレッドを構成している場合は、この設定により、各スレッドで処理されたメッセージ間の遅延のみを制御します。

ActivationInstances

各アダプタがネイティブでマルチ・スレッドをサポートしているため、非推奨です。ただし、このプロパティは依然として機能しており、特定のインバウンドJCAアクティブ化エージェントのインスタンスが生成される数を制御します。このプロパティを使用して同時実行性を向上できます。ActivationInstancesプロパティは、BPELコンソール(ディスクリプタ・ページ)を使用することで動的に更新可能で、アダプタ・フレームワークでさらにインスタンスを作成するか、既存インスタンスを即時停止します(停止する場合は、逆の順序で行います。つまり、最大のインスタンス番号を最初に停止します)。

UseRejectedMessageRecovery

trueに設定する場合、拒否されたメッセージをリカバリまたは中断できます。

Singleton

クラスタ化された高可用性環境では、このプロパティをtrueに設定すると1つの時点で1つのインスタンスのみが作成されます。

EnableReports

trueに設定すると、構成済インバウンド・アダプタのFusion Middleware Controlでアダプタ・レポートを生成できます。

EnableSnapshots

trueに設定すると、構成済インバウンド・アダプタのFusion Middleware Controlでスナップショット・レポートを生成できます。

SnapshotInterval

スナップショット・レポートの間隔。

1
詳細は、「プロキシ認証のサポート」を参照してください。

B Oracle JCAアダプタ・バルブ

この付録には、Oracleファイル/FTPアダプタで使用されるバルブの例が含まれます。バルブは、FTPまたはファイル・アダプタの処理パイプラインにおける主要な実行コンポーネントです。バルブでは、受信したコンテンツを処理して、処理済のコンテンツを次のバルブに転送します。

この章の構成は、次のとおりです。

- 単純な解凍バルブ

- ステージング・ファイルを使用する単純な復号化バルブ

- アウトバウンド・ファイルの暗号化用バルブ

- 複数ファイルの処理用の解凍バルブ

B.1 単純な解凍バルブ

次に単純な解凍バルブのサンプルを示します。

package valves;

import java.io.*;
import java.util.zip.*;

import oracle.tip.pc.services.pipeline.AbstractValve;
import oracle.tip.pc.services.pipeline.InputStreamContext;
import oracle.tip.pc.services.pipeline.PipelineException;

/**
* A simple valve to process zip files.
* The valve processes the first entry from the zip file.
* If you need to process multiple files, you will need
* a re-entrant valve
**/
public class SimpleUnzipValve extends AbstractValve {

public InputStreamContext execute(InputStreamContext inputStreamContext)
throws IOException, PipelineException {
// Get the input stream that is passed to the Valve
InputStream originalInputStream = inputStreamContext.getInputStream();

// Create a new ZIP input stream
ZipInputStream zipStream = null;
try {
zipStream = new ZipInputStream(originalInputStream);
ZipEntry entry = null;
// In this sample valve, lets pick up the first entry
if ((entry = zipStream.getNextEntry()) != null) {
System.out.println("Unzipping " + entry.getName());
ByteArrayOutputStream bos = new ByteArrayOutputStream();
byte[] buf = new byte[4096];
int len = 0;
while ((len = zipStream.read(buf)) > 0) {
bos.write(buf, 0, len);
}
bos.close(); // no-op but still ...
ByteArrayInputStream bin = new ByteArrayInputStream(bos
.toByteArray());
// This is where the Valve returns the inputstream to the caller
// Example, Adapter
// return the newly created inputstream as a part of the context
inputStreamContext.setInputStream(bin);

return inputStreamContext;
}
} finally {
if (zipStream != null) {
zipStream.close();
}
}
// return null if no data
return null;

}

@Override
// Not required for this simple valve
public void finalize(InputStreamContext in) {

}

@Override
// Not required for this simple valve
public void cleanup() throws PipelineException, IOException {

}

}

B.2 ステージング・ファイルを使用する単純な復号化バルブ

次にステージング・ファイルを使用する復号化バルブのサンプルを示します。

package valves;

import java.io.*;
import javax.crypto.*;
import javax.crypto.spec.*;

import oracle.tip.pc.services.pipeline.AbstractStagedValve;
import oracle.tip.pc.services.pipeline.InputStreamContext;
import oracle.tip.pc.services.pipeline.PipelineException;
import oracle.tip.pc.services.pipeline.PipelineUtils;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;

/**
* Simple Decryption valve that uses DES algorightm
*
* You must note that this class uses AbstractStagedValve. By using the
* AbstractStagedValve, the valve notifies the pipeline that the valve will take
* care of its own staging and cleanup
*
*/
public class SimpleDecryptValve extends AbstractStagedValve {

// Staging file where the intermediate decrypted content is kept
private File stagingFile = null;

/**
* Called by the adapter. All the binding/reference properties in the
* composite are available to the pipeline via the pipeline context For
* example <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="myCipherKey" source="" type="xs:string" many="false"
* override="may">somekey</property> </binding.jca> </service>
*
*/
public InputStreamContext execute(InputStreamContext inputStreamContext)
throws IOException, PipelineException {

// Read the cipher key from the adapter binding property 'myCipherKey'
String cipherKey = (String) getPipeline().getPipelineContext()
.getProperty("myCipherKey");

// If key is blank, default to some hard-coded value
if (PipelineUtils.isBlank(cipherKey)) {
System.out.println("using default ciper key");
cipherKey = "desvalve";
}
// Create an instance of the Cipher
byte key[] = cipherKey.getBytes();
SecretKeySpec secretKey = new SecretKeySpec(key, "DES");
Cipher decrypt = null;
try {
decrypt = Cipher.getInstance("DES/ECB/PKCS5Padding");
} catch (NoSuchPaddingException nspe) {
throw new PipelineException("Unable to get cipher instance", nspe);
} catch (NoSuchAlgorithmException nsae) {
throw new PipelineException("Invalid cipher algorithm", nsae);
}
try {
decrypt.init(Cipher.DECRYPT_MODE, secretKey);
} catch (InvalidKeyException ike) {
throw new PipelineException("Invalid secret key", ike);
}
// original input stream from caller. For example, adapter
InputStream originalInputStream = null;
CipherInputStream cis = null;
try {
originalInputStream = inputStreamContext.getInputStream();
cis = new CipherInputStream(originalInputStream, decrypt);
} catch (Exception e) {
throw new PipelineException("Unable to create cipher stream", e);
}
// Since we're using a staged valve, we will store the decrypted content
// in a staging file
// In this case, we're leveraging the File/Ftp Adapter control directory
// to store the content, but, the staging file can be placed anywhere
this.stagingFile = PipelineUtils.getUniqueStagingFile(getPipeline()
.getPipelineContext().getStagingDirectory());

// Write the decrypted content to the staging file
OutputStream os = new FileOutputStream(this.stagingFile);
byte[] b = new byte[8];
int i = cis.read(b);
while (i != -1) {
os.write(b, 0, i);
i = cis.read(b);
}
os.flush();
os.close();
cis.close();

// Open a stream to the staging file and return it back to the caller
InputStream in = new FileInputStream(this.stagingFile);
// close the input stream passed in this invocation
inputStreamContext.closeStream();
// set the input stream to staging file and return
inputStreamContext.setInputStream(in);
return inputStreamContext;

}

/*
* (non-Javadoc)
*
* @see oracle.tip.pc.services.pipeline.AbstractStagedValve#getStagingFile()
*/
public File getStagingFile() {
return stagingFile;
}

/*
* Delete the staging file if there is one (non-Javadoc)
*
* @see oracle.tip.pc.services.pipeline.AbstractValve#finalize(oracle.tip.pc.services.pipeline.InputStreamContext)
*/
public void finalize(InputStreamContext ctx) {
try {
cleanup();
} catch (Exception e) {
}
}

/*
* Use this method to delete the staging file (non-Javadoc)
*
* @see oracle.tip.pc.services.pipeline.AbstractStagedValve#cleanup()
*/
public void cleanup() throws PipelineException, IOException {

if (stagingFile != null && this.stagingFile.exists()) {
this.stagingFile.delete();
}
this.stagingFile = null;
}

}

B.3 アウトバウンド・ファイルの暗号化用バルブ

次にAbstractValveを拡張する単純な暗号化バルブを示します。

package valves;

import java.io.*;
import javax.crypto.*;
import javax.crypto.spec.*;

import oracle.tip.pc.services.pipeline.AbstractValve;
import oracle.tip.pc.services.pipeline.InputStreamContext;
import oracle.tip.pc.services.pipeline.PipelineException;
import oracle.tip.pc.services.pipeline.PipelineUtils;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;

/**
* Simple Encryption valve that uses DES algorightm
*
*/
public class SimpleEncryptValve extends AbstractValve {

/**
* Called by the adapter. All the binding/reference properties
* in the composite are available to the pipeline via
* the pipeline context
* For example
* <service 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="myCipherKey" source="" type="xs:string" many="false" override="may">somekey</property>
*   </binding.jca>
* </service>
*
*/
public InputStreamContext execute(InputStreamContext inputStreamContext)
throws IOException, PipelineException {

//Read the cipher key from the adapter binding property 'myCipherKey'
String cipherKey = (String) getPipeline().getPipelineContext()
.getProperty("myCipherKey");

//If key is blank, default to some hard-coded value
if (PipelineUtils.isBlank(cipherKey)) {
System.out.println("using default ciper key");
cipherKey = "desvalve";
}
//Create an instance of the Cipher

pt.init(Cipher.ENCRYPT_MODE, secretKey);
} catch (InvalidKeyException ike) {
throw new PipelineException("Invalid secret key", ike);
}
//original input stream from caller. For example, adapter
ByteArrayOutputStream bos = new ByteArrayOutputStream();
try {

encryptStream(inputStreamContext.getInputStream(), bos, encrypt);
} catch (Exception e) {
throw new PipelineException("Unable to encrypt", e);
}
byte[] bytes = bos.toByteArray();
InputStream in = new ByteArrayInputStream(bytes);
//close the input stream passed in this invocation
inputStreamContext.closeStream();
//set the input stream and return
inputStreamContext.setInputStream(in);
return inputStreamContext;

}

private static void encryptStream(InputStream in, OutputStream out, Cipher encrypt) {
try {
byte[] buf = new byte[4096];
// Bytes written to out will be encrypted
out = new CipherOutputStream(out, encrypt);

// Read in the cleartext bytes and write to out to encrypt
int numRead = 0;
while ((numRead = in.read(buf)) >= 0) {
out.write(buf, 0, numRead);
}
out.close();
} catch (java.io.IOException e) {
}
}

/*
* Delete the staging file if there is one
* (non-Javadoc)
* @see oracle.tip.pc.services.pipeline.AbstractValve#finalize(oracle.tip.pc.services.pipeline.InputStreamContext)
*/
public void finalize(InputStreamContext ctx) {
try {
cleanup();
} catch (Exception e) {
}
}

/*Use this method to delete the staging file
* (non-Javadoc)
* @see oracle.tip.pc.services.pipeline.AbstractStagedValve#cleanup()
*/
public void cleanup() throws PipelineException, IOException {

}

public static void main(String[] args) throws Exception{
String cipherKey = "desvalve";

//Create an instance of the Cipher
byte key[] = cipherKey.getBytes();
SecretKeySpec secretKey = new SecretKeySpec(key, "DES");
Cipher encrypt = null;
try {
encrypt = Cipher.getInstance("DES/ECB/PKCS5Padding");
} catch (NoSuchPaddingException nspe) {
throw new PipelineException("Unable to get cipher instance", nspe);
} catch (NoSuchAlgorithmException nsae) {
throw new PipelineException("Invalid cipher algorithm", nsae);
}
try {
encrypt.init(Cipher.ENCRYPT_MODE, secretKey);
} catch (InvalidKeyException ike) {
throw new PipelineException("Invalid secret key", ike);
}
//original input stream from caller. for example, adapter

FileInputStream fin = new FileInputStream(args[0]);
FileOutputStream fout = new FileOutputStream(args[1]);
try {

encryptStream(fin, fout, encrypt);
} catch (Exception e) {
throw new PipelineException("Unable to encrypt", e);
}
fin.close();
fout.close();

}

}

B.4 複数ファイルの処理用の解凍バルブ

次に複数ファイルを処理する解凍バルブのサンプルを示します。

package valves;

import java.io.*;
import java.util.zip.*;
import java.util.*;

import oracle.tip.pc.services.pipeline.AbstractStagedValve;
import oracle.tip.pc.services.pipeline.InputStreamContext;
import oracle.tip.pc.services.pipeline.PipelineException;
import oracle.tip.pc.services.pipeline.PipelineUtils;

/**
* A re-entrant valve is one that can be invoked multiple times
* and on each invocation it must return a new stream.
* This concept is used here in this sample to process
* a zipped file containing multiple entries.
*
* If a valve is marked as re-entrant, then the caller (adapter),
* calls hasNext() on the valve to check if there are more
* streams available
*/
public class ReentrantUnzipValve extends AbstractStagedValve {

//member variables
private boolean initialized = false;

private List<String> files = null;

private File currentFile = null;

private File unzipFolder = null;

/**
* On the first invocation, this valve unzips the zip file into
* a staging area and returns a stream the first unzipped file
* On subsequent iterations, the valve returns streams to
* subsequent files.
*/
public InputStreamContext execute(InputStreamContext inputStreamContext)
throws IOException, PipelineException {
String fileName = "";
//the first time that the valve is invoked, unzip the file into
//the staging area
if (!initialized) {
files = new ArrayList<String>();
//Get hold of the File/Ftp adapter control directory
File controlDirectory = getPipeline().getPipelineContext()
.getStagingDirectory();
//Create if required
if (!controlDirectory.exists()) {
controlDirectory.mkdirs();
}
//Generate a unique folder to store the staging files
String digestPath = "";
try {
digestPath = PipelineUtils.genDigest(inputStreamContext
.getMessageOriginReference());
} catch (Exception e) {
digestPath = String.valueOf(inputStreamContext
.getMessageOriginReference().hashCode());
}
unzipFolder = new File(controlDirectory, digestPath);
if (!unzipFolder.exists())
unzipFolder.mkdirs();
//unzip the files into the staging folder
unzipToDirectory(inputStreamContext.getInputStream(), unzipFolder);
//store the file names into the list
PipelineUtils.listFiles(unzipFolder, files);
//close the input stream
inputStreamContext.closeStream();
}
initialized = true;
//return the next one in the list
if (files != null && files.size() > 0) {
fileName = files.remove(0);
currentFile = new File(fileName);
System.out.println("Returning file[" + fileName + "]");
//Open a stream to the file and return to caller. For example,  adapter
FileInputStream fis = new FileInputStream(currentFile);
inputStreamContext.setInputStream(fis);
/*For re-entrant valves, setting the message key is
important since this allows the caller to distinguish
between parts for the same message. for example, in the
case of zip file in this example, the
messageOriginReference will be same, but, the individual
message keys will vary. For example, the messageOriginReference
will be "/input/in.zip", whereas message key might be something
like "dir1/address-csv1.txt", "dir1/address-csv2.txt" and so on
*/
inputStreamContext.setMessageKey(fileName);
return inputStreamContext;
} else {
//return null if no more files
return null;
}
}

/*
* Adapter calls this to check if there are more files
* @see oracle.tip.pc.services.pipeline.AbstractValve#hasNext()
*/
public boolean hasNext() {
return (files != null && files.size() > 0);
}

/*
* Returns the current file being processed
* @see oracle.tip.pc.services.pipeline.AbstractStagedValve#getStagingFile()
*/
public File getStagingFile() {
return currentFile;
}

/*
* delete the current file once the entry has been published to binding component
* @see oracle.tip.pc.services.pipeline.AbstractValve#finalize(oracle.tip.pc.services.pipeline.InputStreamContext)
*/
public void finalize(InputStreamContext ctx) {

if (currentFile != null && currentFile.exists()) {
currentFile.delete();
}
}

/*
* Cleanup intermediate files
* @see oracle.tip.pc.services.pipeline.AbstractStagedValve#cleanup()
*/
public void cleanup() throws PipelineException, IOException {
PipelineUtils.deleteDirectory(unzipFolder);
initialized = false;
if (currentFile != null && currentFile.exists()) {
currentFile.delete();
}
files = null;
}

/*
* Unzip to the directory
*/
private void unzipToDirectory(InputStream in, File directory)
throws IOException {
ZipInputStream zin = new ZipInputStream(in);
ZipEntry entry = null;
if ((entry = zin.getNextEntry()) != null) {
do {
String entryName = entry.getName();
if (!entry.isDirectory()) {
File file = new File(directory, entryName);
unzipFile(zin, file);
}
} while ((entry = zin.getNextEntry()) != null);
}
zin.close();
}

private void unzipFile(InputStream in, File file) throws IOException {
if (!file.getParentFile().exists()) {
file.getParentFile().mkdirs();
}
OutputStream os = new FileOutputStream(file);
byte[] buf = new byte[4096];
int len = 0;
while ((len = in.read(buf)) > 0) {
os.write(buf, 0, len);
}
os.close();
}

}

C Oracle MQ Seriesアダプタでサポートされるエンコーディング

この付録では、MQ Seriesアダプタでサポートされるエンコーディングのリストを提供します。

デフォルトでは、次のリストに示すエンコーディングをサポートしています。メッセージ・エンコーディングとJavaエンコーディング、およびメッセージ・エンコーディングとJavaエンコーディング間のマッピングを示します。サポートされるエンコーディングのリストは、次のとおりです。

C.1 Oracle MQ Seriesアダプタのエンコーディング

エンコーディングのリストを次に示します。

- ibm037

- ibm437

- ibm500

- ibm819

- Unicode

- UTF8

- ibm273

- ibm277

- ibm278

- ibm280

- ibm284

- ibm285

- ibm297

- ibm420

- ibm424

- ibm737

- ibm775

- ibm813

- ibm838

- ibm850

- ibm852

- ibm855

- ibm856

- ibm857

- ibm860

- ibm861

- ibm862

- ibm863

- ibm864

- ibm866

- ibm868

- ibm869

- ibm870

- ibm871

- ibm874

- ibm875

- ibm912

- ibm913

- ibm914

- ibm915

- ibm916

- ibm918

- ibm920

- ibm921

- ibm922

- ibm930

- SJIS

- ibm933

- ibm935

- ibm937

- ibm939

- ibm942

- ibm948

- ibm949

- ibm950

- EUCJIS

- ibm964

- ibm970

- ibm1006

- ibm1025

- ibm1026

- ibm1089

- ibm1097

- ibm1098

- ibm1112

- ibm1122

- ibm1123

- ibm1124

- Cp1250

- Cp1251

- Cp1252

- Cp1253

- Cp1254

- Cp1255

- Cp1256

- Cp1257

- Cp1258

- ibm1381

- ibm1383

- JIS

- KSC5601

- ibm33722813

- GB18030

.

C.1.1 その他の標準Javaエンコーディングのサポートの追加

このリストに示されていないその他の標準Javaエンコーディングのサポートは、次の方法で追加できます。

1. MQSeriesAdapter.rarファイルからMQSeriesAdapter.jarファイルを抽出します。

2. MQSeriesAdapter.jarファイルからmq.propertiesファイルを抽出します。

3. mq.propertiesファイルにエントリを追加します。新しいエンコーディングごとに、mq.propertiesファイルに2つの行(プロパティ)を追加する必要があります。1行はエンコーディングとそれに対応するJavaエンコーディング、もう1行はJavaエンコーディングとそれに対応するエンコーディングです。
たとえば、次のibm037 Javaエンコーディング(ibm037 (Javaエンコーディング)<->37 (メッセージ・エンコーディング))のサポートを追加するには、mq.propertiesファイルに次の2行を追加する必要があります。

oracle.tip.adapter.mq.encoding.37=ibm037

oracle.tip.adapter.mq.encoding.ibm037=37

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。